**** BEGIN LOGGING AT Tue Jan 17 02:59:58 2006 Jan 17 03:02:25 commited. now time to add it into OE Jan 17 03:04:37 RP: CVSDATE is totally unused now? Jan 17 03:06:26 hrw: correct Jan 17 03:12:13 the finding of files behavious in bitbake appears to have changed Jan 17 03:13:56 XorA: In what way? Jan 17 03:14:14 XorA: The build order will have changed after the changes I've made... Jan 17 03:14:31 RP: in mozille there is firefox-1.0.6, firefox and files directories, it used to work, now it is not looking in firefox-1.0.6 but in firefox/ for files Jan 17 03:14:51 That shouldn't have changed Jan 17 03:15:14 I'd check what FILESPATH is getting set to Jan 17 03:21:01 RP: some craziness is happening as it just worked in the bitbake -b case :-( Jan 17 03:26:49 XorA: It should always work :-/ Jan 17 03:26:59 RP: I shall dig about Jan 17 03:28:14 <[lala]> morning :) Jan 17 03:28:41 morning [lala] Jan 17 03:28:47 <[lala]> are there any defaults for CONFFILES? Jan 17 03:29:02 03rpurdie 07org.oe.dev * r9c6d2f9e... 10/ (13 files in 3 dirs): Jan 17 03:29:02 Cleanup of GPE meta files: Jan 17 03:29:02 * Creation of task-gpe for gpe tasks Jan 17 03:29:02 * Removal of unneeded DEPENDS variables Jan 17 03:29:02 * Switch existing gpe meta files to use task-gpe Jan 17 03:29:02 * include gpe-image.bb instead of reinventing the wheel Jan 17 03:30:03 <[lala]> as far as i see it the pcmcia-cs package for instance does not define any files as CONFFILES Jan 17 03:31:13 <[lala]> when i happen to change some files in /etc/pcmcia and i update the pcmcia-cs pkg afterwards ... would that not mean that i loose my changes that way? Jan 17 03:32:09 yes Jan 17 03:32:28 <[lala]> hmm, is that intended? Jan 17 03:32:33 [lala]: you can create lala.conf and add there but changes are other thing... Jan 17 03:33:24 somehow I managed to bork my OE tree. Is there a site up right now that has an OE.db.bz2 style snapshot? Jan 17 03:33:48 <[lala]> hrw: right, that would work, since /etc/pcmcia/config kindly includes *.conf :-) Jan 17 03:34:35 re Jan 17 03:34:39 irssi dumped Jan 17 03:34:42 <[lala]> wb Jan 17 03:34:43 wb :) Jan 17 03:34:56 <[lala]> hrw: right, that would work, since /etc/pcmcia/config kindly includes *.conf :-) Jan 17 03:35:31 <[lala]> hrw: but i was wondering if not declaring those files as conffiles is on purpose :) Jan 17 03:36:07 dont know Jan 17 03:37:29 [lala]: It does sounds like a bit of a bug... Jan 17 03:38:49 <[lala]> RP: what exactly happens if i change some declared conffiles and then update the pkg? does it keep my changes or does it ask me what to do? Jan 17 03:39:35 [lala]: The would presumable fall to ipkg and I'm not sure what it does. There are two ways to find out :) Jan 17 03:39:56 will overwrite Jan 17 03:40:24 <[lala]> hrw: if it would overwrite - what would be the meaning of conffiles then? :) Jan 17 03:40:41 [lala]: they are not CONFFILES now.. Jan 17 03:40:57 koen|sleep: ping Jan 17 03:41:02 <[lala]> hrw: i know, but my question was, what would happen if they were ... Jan 17 03:41:20 if were then ipkg will ask Jan 17 03:41:27 <[lala]> ok Jan 17 03:41:38 install my/keep your/show diff etc Jan 17 03:42:23 <[lala]> same as dpkg then ... good Jan 17 03:52:28 [lala]: I think they should be declared as CONFFILES and that is a bug in OE... Jan 17 03:56:21 <[lala]> RP: that's why i was wondering if there are any defaults for CONFFILES ... like /etc/*, except /etc/init.d/* or something like that Jan 17 03:57:31 ~lart linsys for the worlds worst power supplies Jan 17 03:57:32 * ibot cuts linsys into thin stripes for the worlds worst power supplies Jan 17 04:01:20 hi Jan 17 04:03:10 [lala]: I don't think it supports globbing Jan 17 04:03:16 hi mardy Jan 17 04:08:33 [lala]: that would be a good idea. I think that even the stuff in init.d is a conffile in debian. Jan 17 04:09:08 debian has whole /etc/ as conffiles Jan 17 04:09:19 right Jan 17 04:16:27 It should go on the todo list... Jan 17 04:29:24 <[lala]> RP: i investigated the white screen a bit further ... if i boot the kernel the whitescreen always happens while switching to framebuffer Jan 17 04:29:55 <[lala]> RP: but it doesn't stop the boot process Jan 17 04:30:15 <[lala]> RP: u can do suspend/resume to reanimate the screen Jan 17 04:31:08 <[lala]> RP: if the borzoi crashed for instance due to a kernel oops than it is most likely that i end up with a white screen after reset Jan 17 04:32:13 [lala]: It sounds like the problem is in the setvar function in pxafb then Jan 17 04:33:45 [lala]: Which helps narrow down the problem a lot. Its performing some illegal access to the framebuffer registers which locks the lcd panel up, probably as some timings go out of sync Jan 17 04:34:46 <[lala]> RP: i'm glad if that helps :) Jan 17 04:35:22 [lala]: I know the kind of bug to look for now :) Jan 17 05:23:04 ~lart builds that only work on i386 Jan 17 05:23:04 * ibot puts builds that only work on i386 through a wood chipper Jan 17 06:05:56 hi all... Jan 17 06:19:49 hi greentux Jan 17 06:21:10 hciattach doesnt die after remove bluetooth card... Jan 17 06:22:44 killall hciattch brings kernel trace Jan 17 06:37:24 somebody else a bluetooth card? Jan 17 06:37:54 <_law_> greentux, i?ll try mom Jan 17 06:38:08 greentux: I do Jan 17 06:38:19 XorA: 2.6 kernel latest? Jan 17 06:38:31 greentux: I see same effect as you occasionally Jan 17 06:39:11 XorA: problem is that nobody kills hciattach Jan 17 06:39:24 greentux: I use gpe-bluetooth Jan 17 06:39:59 <_law_> greentux, removed bluetooth-card, but there is no hciattach job running Jan 17 06:40:08 cardctl eject shows the same effects Jan 17 06:40:29 _law_: 2.6 kernel ? opie or gpe? Jan 17 06:42:02 <_law_> greentux, kernel 2.6 (2.6.15-rc7) with gpe and gpe-bluetooth running Jan 17 06:42:20 <_law_> but i?ll update to latest kernel later Jan 17 06:42:56 ok, thanx. usually should pcmcia handle these events, sot a app... mmh Jan 17 06:50:18 <[lala]> law: do you have a card which uses serial_cs? Jan 17 06:53:34 <_law_> [lala], no i use an nokia bluetooth cf Jan 17 07:01:08 <[lala]> but after inserting the card you have an hciattach running? Jan 17 07:02:53 <_law_> [lala], no Jan 17 07:03:59 <_law_> ok hciattach is only for serial devices Jan 17 07:04:04 <_law_> dont know this Jan 17 07:11:22 <[lala]> ah, here we go Jan 17 07:11:31 <[lala]> that explains it Jan 17 07:12:08 <[lala]> so anyone here with a bluetooth card which uses serial_cs? Jan 17 07:12:17 <_law_> gpe-bluetooth doesnt build :-( http://pastebin.com/509833 Jan 17 07:13:45 hrw, pb__, RP any of you know of any reason why we would be using SYSV IPC over TCP IPC ? Jan 17 07:14:02 this will cause an issue on any non-SYSV system Jan 17 07:15:39 * emte hopes one of them is still around Jan 17 07:15:51 otherwise its off to the mailing list i go Jan 17 07:16:56 emte: I could say: ke? as I'm rather web programmer then application Jan 17 07:17:02 <[lala]> _law_: and you can establish a network connection with your bluetooth card? Jan 17 07:17:14 <[lala]> like gprs/umts? Jan 17 07:17:39 cu Jan 17 07:17:41 hrw, was kind of hoping you might have saw this issue come up before Jan 17 07:17:52 cya Jan 17 07:19:06 i'll send it to the mailing list since this will cause an isse for any pure debian system and i suspect OSX Jan 17 07:19:13 issue* Jan 17 07:24:45 _law_: that error seems pretty self-explanatory: you need libcontactsdb Jan 17 07:26:17 lo Jan 17 07:26:32 france are you there ? Jan 17 07:31:17 aww man pb__ now you show up ... after i wrote that long email ... Jan 17 07:31:53 anyway its on the mailing list now Jan 17 07:34:59 now i wonder if i spell checked it ... Jan 17 07:41:03 <_law_> [lala], yes gprs/umts works Jan 17 07:41:43 [lala]: _law_ I use GPRS a lot with my BT card Jan 17 07:45:15 <_law_> i also use gprs a lot. Jan 17 07:45:34 I also use a billionton card which I think is serial_cs Jan 17 07:45:41 I have to setserial it anyway Jan 17 07:45:49 <_law_> but gkdial isnt the best dialer :-) Jan 17 08:10:39 morning Jan 17 09:05:34 <[lala]> XorA: i have the billionton card as well. i have modified the pcmcia configs so that the correct speed is used (921600) and hciattach is started after insert Jan 17 09:06:04 <[lala]> XorA: the only problem is, that hciattach does not get killed if i remove the card - either physically or by cardctl means Jan 17 09:06:14 [lala]: yes noticed that Jan 17 09:06:32 <[lala]> and if u then reinsert the card hciattach chokes Jan 17 09:07:09 <[lala]> and if u try to kill hciattach while the card is out then u get a kernel trace Jan 17 09:07:18 <[lala]> null pointer exception Jan 17 09:07:34 <[lala]> and hciattach is a non-killable zombie Jan 17 09:07:51 [lala]: seen that on accasion as well, I just never knew what caused it until greentux was talking about it Jan 17 09:08:15 [lala]: that last bit is definitely a kernel bug. The hciattach not getting killed in the first place is probably a bug in the pcmcia scripts. Jan 17 09:08:33 <[lala]> funny thing is, u can kill hciattach safely as long as the card is inserted Jan 17 09:08:55 <[lala]> pb_: the problem here is some kind of race Jan 17 09:09:27 <[lala]> pb_: the pcmcia scripts try to do a fuser call to get the pids still using the serial device (ttyS3) Jan 17 09:09:48 <[lala]> pb_: but that device just vanished before the fuser is called Jan 17 09:10:34 <[lala]> the right thing to do would be killing hciattach _before_ any device gets removed, but i dunno how to accomplish that Jan 17 09:17:11 <[lala]> RP: any idea regarding that kernel oops caused by hciattach? Jan 17 09:22:02 hi Jan 17 09:24:56 hi CoreDump|home Jan 17 09:32:17 [lala]: Do you have a link to the oops? Jan 17 09:36:52 <[lala]> not at the moment. greentux just grabbed the z and took it with him :( Jan 17 09:37:37 <[lala]> can give it to you on thursday i think Jan 17 09:38:14 <[lala]> one message i remember is that the kernel complained about "too much work for irq 137" Jan 17 09:38:28 <[lala]> thats the one the cf card used Jan 17 09:38:43 [lala]: ok, there's not much I can do without it... Jan 17 09:38:49 <[lala]> yep Jan 17 09:42:34 <[lala]> any idea when one of the servers will be online again? (ewi, vanille) Jan 17 09:48:08 bitbake mono fails for me with the error "| socket-io.c:793: internal compiler error: in arm_print_operand, at config/arm/arm.c:9887", anyone know how to fix that? Jan 17 09:56:12 hi Jan 17 09:56:28 koen felt asleep and have good dream.. Jan 17 09:56:39 any news on ewi? Jan 17 09:57:05 without koen we cannot do anything. Jan 17 09:57:40 * raduga hopes koen sleeps well, and gets much rest Jan 17 10:05:36 hello, are there problems currently pulling oe from the servers or is it just me?.. also, the daily snapshot download link doesn't seem to respond Jan 17 10:07:01 ewi546 is down. Jan 17 10:07:33 vanille.de appearst to be up, but some people have claimed it has problems Jan 17 10:11:01 ok Jan 17 10:12:34 <[lala]> just tried to sync with vanille ... doesnt work here Jan 17 10:12:58 <[lala]> i get a reset packet if i try to connect to port 5253 Jan 17 10:13:55 yeah, I had no luck also Jan 17 10:20:29 re Jan 17 10:47:33 from here I do not lose history Jan 17 11:09:22 ~users Jan 17 11:09:25 so this is what we get for sharing our unpaid volunteer work with you? complaints and accuses? well done, this clearly supports our motivation to continue working on open source projects. Jan 17 11:09:30 hey hrw Jan 17 11:09:34 ho Jan 17 11:22:43 lol Jan 17 11:22:45 @ ibot Jan 17 11:28:56 today I compiled an image for my akita Jan 17 11:29:01 anyone has any idea if there's a alternate mirror for downloading daily snapshots of oe? Jan 17 11:29:11 and uname reports a 2.6.15 kernel working Jan 17 11:29:35 but the modules are in /lib/modules/2.6.14-git3 directory Jan 17 11:29:48 is this normal? Jan 17 11:30:04 if I try to load modules with modprobe, they're never found Jan 17 11:30:51 good evening Jan 17 11:33:16 hi pH5 Jan 17 11:33:44 hi hrw Jan 17 11:36:04 good morning koen Jan 17 11:36:25 koen: hi Jan 17 11:36:48 hi all Jan 17 11:37:25 koen: could you order resetmonkey again? Jan 17 11:39:53 * koen enables vpn to mail the reset monkeys Jan 17 11:40:21 cool Jan 17 11:40:49 I have one fix for branch to push there Jan 17 11:42:43 hmm.. vanille is responding.. will push there Jan 17 11:49:29 evening Jan 17 11:50:54 hi Rene Jan 17 11:52:14 hi Marcin Jan 17 12:05:25 03hrw 07org.oe.oz354fam083 * r8bc80d18... 10/packages/opie-console/ (2 files in 2 dirs): Jan 17 12:05:26 opie-console: yet another CVS backport Jan 17 12:05:26 - fallback in configuration to fixed font from qpe.conf Jan 17 12:05:26 taken from .dev Jan 17 12:05:30 03hrw 07org.oe.dev * rb78c38c1... 10/packages/opie-console/ (2 files in 2 dirs): Jan 17 12:05:31 opie-console: yet another CVS backport Jan 17 12:05:31 - fallback in configuration to fixed font from qpe.conf Jan 17 12:07:25 * Philippe is back (gone 20:53:41) Jan 17 12:09:49 hello Jan 17 12:10:35 could anybody give me a hand in flashing the Sharp ROM 3.10 onto a Zaurus SL-5500 (I just bought it and it came with another ROM) Jan 17 12:11:01 put OSPACK on cf card and flash Jan 17 12:11:09 just OSPACK file? Jan 17 12:11:12 nothing else? Jan 17 12:11:27 iirc nothing Jan 17 12:11:35 never wanted to go to sharp Jan 17 12:11:42 Hhhhh: next time go #zaurus Jan 17 12:12:04 questions about the CF: is a 32MB CF Type I ok for flashing a SL-5500? Jan 17 12:12:13 yes Jan 17 12:12:33 Hhhhh: anyway on #oe this is offtopic a bit Jan 17 12:12:34 I understand that it has to be formatted in FAT16 for flashing, right? Jan 17 12:12:42 I'm sorry Jan 17 12:12:48 yes Jan 17 12:13:17 I formatted CF with the Z, will that make it FAT16? Jan 17 12:14:10 depends which tool used etc.. Jan 17 12:14:51 In theKompany ROM, under Utilities tab, I used Formatter Jan 17 12:14:59 it didn't ask me for any format or anything' Jan 17 12:15:22 wait, it let me select minix, ext2 or vfat Jan 17 12:15:26 vfat, I assume? Jan 17 12:15:30 yes Jan 17 12:15:47 vfat Jan 17 12:18:36 another question: the ROM Flashing How-To for SL-5x00 in OESF talks about some initrd.bin and zImage files that need to be put in the CF (the How-To is talking about Sharp ROM 1.37/1.38, I'm installing 3.10). Is OSPACK the only thing I need to worry about? Jan 17 12:18:51 yes Jan 17 12:19:18 I assume initrd.bin and zImage is an old thing? Jan 17 12:19:34 other roms use them, sharp's doesn't Jan 17 12:19:50 gotcha Jan 17 12:20:29 zImage + initrd.bin is safer then OSPACK ;) Jan 17 12:22:11 and to flash, just plug in AC, and having OZPACK in CF memory card, just hold C and D and press full reset in battery compartment? Jan 17 12:22:14 anything else? Jan 17 12:22:21 nothing more Jan 17 12:24:12 now, in order to open battery compartment, I had to move switch on the back to "replace battery", do I need to switch back to "normal operation" (with battery compartment open)? Do I have to have Z turned on? Jan 17 12:24:47 for the flashing, that is Jan 17 12:24:55 no Jan 17 12:24:59 leave it as replace batter Jan 17 12:25:04 ok Jan 17 12:25:08 there I go then Jan 17 12:25:15 plug it into the ac, hold down c and d, while holding them down press the reset battery button Jan 17 12:26:04 ack, hard to hold C and D with one hand while using other to reach back of the Z Jan 17 12:26:31 hehe Jan 17 12:26:56 easiest thing ive found is to put your two fingers from your right hand on the c and d keys, flip it over, and use the left to press the button with the stylus Jan 17 12:26:57 I assume C + D + full reset starts the update program, and that they do not need to be held down, right? Jan 17 12:27:08 * RP returns Jan 17 12:27:12 it starts the flash, the green and yellow lights should come on Jan 17 12:27:23 and then I can let go of them? Jan 17 12:27:28 yes Jan 17 12:27:33 re RP Jan 17 12:28:16 all right, both ligts are on Jan 17 12:28:21 how long does it usually take? Jan 17 12:28:25 andrewy, Hhhhh: please check the /topic Jan 17 12:28:26 ~3 minutes Jan 17 12:28:28 If anyone has any good ideas about PREFERRED_PROVIDERS and RDEPENDS, I'm open to suggestions btw :) Jan 17 12:28:44 reenoo_, sorry again Jan 17 12:28:54 didn't mean to flood here Jan 17 12:29:00 I'm moving it to #zaurus Jan 17 12:33:10 RP: I think we should loop through the list of PREFERRED_PROVIDER_... variables to find if there's a PREFERRED_PROVIDER_ that has the package in its PACKAGES. Jan 17 12:33:23 loooks like I need to go to 2.6.15 on Z... oopsed again Jan 17 12:36:22 RP: btw, will the stamp checks in buildRProvider have to loop through all archs when evaluating ${STAMP} from multimachine.conf? Jan 17 12:40:55 pH5: No. Only the currently set STAMP. STAMP is unique to any build of a package Jan 17 12:41:10 pH5: I've just replied to your email... Jan 17 12:45:37 RP: I see. reenoo_ doesn't seem to agree that virtual/kernel is valid in the package name space, though? Jan 17 12:45:59 correct Jan 17 12:46:07 RP: So the STAMP compes from the pkgdata, stamp = bb.data.getVar('STAMP', the_data, 1)? Jan 17 12:48:19 pH5: There are a number of packages which already use virtual/ in the package namespace... Jan 17 12:48:29 pH5: correct Jan 17 12:48:37 (re: the STAMP) Jan 17 12:50:35 RP: well. forcing people to set RPROVIDES = PROVIDES is a totally different story than people intentionally setting say RPROVIDES=virtual/xserver Jan 17 12:51:34 mm. setting RPROVIDES = ${PROVIDES} would be a bad idea for all kinds of reasons. Jan 17 12:51:58 reenoo_: Its only "forcing" that in the virtual case... Jan 17 12:52:05 and even then its not forced Jan 17 12:53:48 RP: I think that looping through PACKAGES_DYNAMIC for every preferred provider is nonsense. Who would RDEPEND on something specific as kernel-module-soundcore-2.6 without knowing how to build it. But just looking at PACKAGES and RPROVIDES would solve the "kernel" --> "virtual/kernel" issue, too. Jan 17 12:55:07 RP: I'm sorry, but that doesn't make much sense. your code appears to require RPROVIDES to be set to PROVIDES. Jan 17 12:55:42 reenoo_: It does not. We just have an issue with the virtual/* entities Jan 17 12:57:07 for "virtual/* entities" then Jan 17 12:58:07 reenoo_: There is a world of difference between RPROVIDES = PROVIDES and RPROVIDES = PROVIDES only for virtual/* entities... Jan 17 12:59:07 RP: I was referring to build time virtuals. sorry I didn't mention that explicitely Jan 17 13:03:38 I'm going to respond via email as anything else if just going to get confused Jan 17 13:05:36 drw: hi Jan 17 13:32:48 <_law_|iBook> hrw: 3.5.4 has got kernel 2.4.20? also on c7x0? Jan 17 13:37:19 c7x0 will get 2.6 Jan 17 13:38:51 <_law_|iBook> hrw: ah ok Jan 17 13:42:48 reenoo_, pH5 , pb_ : I've sent a reply to oe@. My conclusion is we should scrap PREFERRED_PROVIDER. Please read the email and understand my alternative proposal before telling me why its a bad idea :) Jan 17 13:44:13 :-) Jan 17 13:44:26 cu Jan 17 13:44:56 Cial all Jan 17 13:45:43 hi pigi Jan 17 13:45:51 hi pb_ | Jan 17 13:45:56 s/|/! Jan 17 13:45:58 heh Jan 17 13:46:02 hi Pigi Jan 17 13:46:11 hi RP ! Jan 17 13:50:40 pb_ I woudl have a relase candidate for ipkg "turbo" probably for tonite, but needs someone brave to test. Any hint ? Jan 17 13:53:26 pb_: Can arm processors generate NMIs? Jan 17 13:54:19 RP: I'm not sure what you mean by "generate". There's no such thing as NMI in the ARM architecture. Jan 17 13:54:35 Pigi: I am almost completely brave. Send it to me and I will test it. Jan 17 13:54:35 pb_: That's what I thought :). Thanks. Jan 17 13:54:57 pb_ heh ok. Jan 17 14:16:15 Pigi: ipkg turbo? Jan 17 14:16:47 yeah, a little fix that speed up some options by not reading the feed files. Jan 17 14:17:12 I think it should be tested also for the various package manager. Jan 17 14:17:26 cool Jan 17 14:17:45 I can test Opie-PM Jan 17 14:18:02 Pigi: is it in cvs? Jan 17 14:18:04 could you give me your e-mail address ? Jan 17 14:18:12 drw, not yet Jan 17 14:18:14 drw@hh.org Jan 17 14:18:27 I will send you a copy. Jan 17 14:18:45 thanks! Jan 17 14:19:20 drw, pb_, sent a mail Jan 17 14:19:30 rock Jan 17 14:23:07 it's time to sleep for me now. I will wait your feedback by mail, so I will commit and relase the new version, if everithing is ok ;) Jan 17 14:23:25 Pigi: thanks. I'll try it directly. Jan 17 14:23:44 for future reference, it would be easier for me if you just sent the output from "cvs diff", not a whole tarfile Jan 17 14:24:18 (not that the tarfile is a problem, though) Jan 17 14:24:32 pb_ ok, but I wasn't sure you got the 0.99.156, as you were referring to 154 in bugzilla. Jan 17 14:24:54 nite all Jan 17 14:24:58 good night Jan 17 14:31:15 France are you available ? Jan 17 14:32:08 Hail franc Jan 17 14:32:10 Hail franc e Jan 17 14:32:13 Hail france Jan 17 14:56:41 * Philippe is away: visual contact - dreams Jan 17 15:21:59 re Jan 17 15:22:27 hey zecke Jan 17 15:23:16 hi zecke Jan 17 15:33:28 is anyone else having problems with glibc compiling? Jan 17 15:36:53 i guess not Jan 17 15:37:27 it looks like it is from bits/endian.h "Machine byte order unknown" Jan 17 15:40:58 LoDown: Is this the release branch? Jan 17 15:42:49 0.8.3...yes Jan 17 15:45:48 03jbowler 07org.oe.dev * r4e84e5d6... 10/packages/linux/ (6 files in 2 dirs): Jan 17 15:45:48 ixp4xx-kernel: improve fixup patches, remove loft one, add cmdline byteswap in 2.6.15 Jan 17 15:45:48 - the fixup patches for NSLU2 and NAS100D have been slightly simplified. Jan 17 15:45:48 the fixup for Loft has been removed, it isn't useful. Jan 17 15:45:48 code in arch/arm/kernel/setup.c to automagically swap the command line Jan 17 15:45:49 has been added in 48-setup-byteswap-cmdline.patch Jan 17 15:45:53 03jbowler 07org.oe.dev * rb4a51321... 10/packages/linux/ixp4xx-kernel/2.6.15/defconfig: ixp4xx-kernel: generic CMDLINE in defconfig in 2.6.15 Jan 17 15:47:30 LoDown: The glibc cvs repository is corrupt for cvs dates as old as 20050627. koen posted a correct tarball of it to oe@ (its hosted on ewi). Jan 17 15:47:48 LoDown: Alternatively, remove the files in the bits directory and it will work Jan 17 15:48:14 oh...ok...thank you Jan 17 15:53:31 RP..is this a widespread OE problem? Jan 17 15:53:45 because surely the .bb could be patched to do it automatically Jan 17 15:54:03 rm the files from the bits dir that is Jan 17 15:54:23 LoDown I had a lot of problems with glibc as well Jan 17 15:54:53 LoDown most of my problems had to do with gcc4 although Jan 17 16:16:44 good night Jan 17 17:06:21 LoDown: The .bb file in the .dev branch is. The one in the release branch isn't Jan 17 17:06:40 Someone needs to make a patch for the release branch and add it to bug 350 Jan 17 17:25:07 Grub 0.96 , 0.93 doesn't work grub 0.97 works like a sun Jan 17 17:38:15 RP: do you know why my last image for my akita has a kernel 2.6.15 ( or that is reported by uname) but the modules are in /lib/modules/linux-2.6.14git3 ? Jan 17 17:38:22 that prevents me from loading modules Jan 17 17:55:40 katossi: You made a new kernel and rootfs at the same time? Jan 17 17:55:51 and flashed both the new kernel and new rootfs? Jan 17 18:15:11 jbowler-away: Could you see if http://www.rpsys.net/openzaurus/temp/bitbake-prefprov-r0.patch removes the need for the DEPENDS the slugos-image has on virtual/kernel please? It seems too simple so I'm thinking there must be a flaw :) Jan 17 18:15:54 I need to sleep so 'night all :) Jan 17 19:43:16 RP: I'll verify that I can still reproduce the problem then try the fix. Jan 17 23:14:32 <[AD]Ska> re Jan 17 23:38:01 * emte grumbles at stupid bluetooth support for h3600 Jan 18 00:37:22 quit Jan 18 00:37:23 exit Jan 18 00:50:32 RP: ok, it still repros without the patch: Jan 18 00:50:37 NOTE: multiple providers are available (nslu2-kernel, linux-jlime-sh3, handhelds-sa, linux-openzauru Jan 18 00:50:47 NOTE: consider defining a PREFERRED_PROVIDER to match runtime kernel Jan 18 00:50:47 NOTE: multiple providers are available (nslu2-kernel, linux-jlime-sh3, handhelds-sa, linux-openzauru Jan 18 00:50:58 NOTE: consider defining a PREFERRED_PROVIDER to match runtime kernel-image-2.6.15 Jan 18 00:50:59 NOTE: multiple providers are available (ixp400-eth, ixp425-eth); Jan 18 00:50:59 NOTE: consider defining a PREFERRED_PROVIDER to match runtime ixp-eth Jan 18 00:55:12 And with the patch it selects collie-kernel-58-6-debug, which is totally wrong. Jan 18 00:56:19 It also selects modutils-cross-2.4.27, presumably because the kernel is a 2.4 kernel. Jan 18 00:56:34 NOTE: package modutils-cross-2.4.27: started Jan 18 00:56:35 NOTE: package modutils-cross-2.4.27: completed Jan 18 00:56:35 ERROR: Nothing provides dependency virtual/armeb-linux-uclibc-gcc-2.95 Jan 18 00:56:35 ERROR: dependency virtual/armeb-linux-uclibc-gcc-2.95 (for collie-kernel-58-6-debug) not satisfied Jan 18 00:56:41 So with the patch it's totally broken. Jan 18 00:57:22 (Without it it is too, as it selects nslu2-kernel while the PREFERRED_PROVIDER is ixp4xx-kernel). Jan 18 01:33:14 Building orbit2-native-2.10.2-r0 fails with the following error: Jan 18 01:33:29 | autoreconf: running: /home/tdb/roinaa/OpenZaurus/src/build/tmp/staging/i686-linux/bin/autoconf --include=/home/tdb/roinaa/OpenZaurus/src/build/tmp/work/i686-linux/orbit2-native-2.10.2-r0/ORBit2-2.10.2/ --include=/home/tdb/roinaa/OpenZaurus/src/build/tmp/work/i686-linux/orbit2-native-2.10.2-r0/ORBit2-2.10.2/m4/ --include=/home/tdb/roinaa/OpenZaurus/src/build/tmp/staging/i686-linux/share/aclocal-1.9 --include=/home/tdb/roinaa/OpenZaurus/src/build/ Jan 18 01:33:29 tmp/staging/i686-linux/share/aclocal --force --warnings=cross Jan 18 01:33:29 | configure.in:124: error: possibly undefined macro: PKG_CONFIG_MIN_VERSION Jan 18 01:33:29 | If this token and others are legitimate, please use m4_pattern_allow. Jan 18 01:33:31 | See the Autoconf documentation. Jan 18 01:33:33 | autoreconf: /home/tdb/roinaa/OpenZaurus/src/build/tmp/staging/i686-linux/bin/autoconf failed with exit status: 1 Jan 18 01:33:41 Any idea what's wrong? Jan 18 01:43:28 jbowler-away: Ok, thanks :-(. Back to the drawing board :-/. I'll have to work out why it doesn' Jan 18 01:43:30 t work... Jan 18 01:44:44 DataBeaver: yes Jan 18 01:44:54 morning Jan 18 01:47:34 hello Jan 18 01:58:09 maybe I should RTFM more, but how does one have bitbake build a specific version of a package Jan 18 01:58:11 ? Jan 18 01:59:04 the latest gaim is failing to build (can't download the source), is there a way to have bitbake build a past version? Jan 18 01:59:54 johnX: is it CVS version Jan 18 02:00:22 yeah, sourceforge's anon cvs is down and oesources doesn't have the tarball... Jan 18 02:02:03 * CP|Dresden yawns Jan 18 02:03:27 johnX: do a bitbake -b /path/to/specific/file.bb Jan 18 02:03:38 ah, thank you Jan 18 02:07:36 jbowler-away: That patch has at least one major flaw - s/if prefervar:/if prefervar == pn:/ ... Jan 18 02:18:02 hi Jan 18 02:18:41 koen: ping Jan 18 02:20:15 hi hrw Jan 18 02:20:38 hrw: There's a new bitbake circular dependencies patch. I've hopefully worked out a proper fix this time :) Jan 18 02:20:51 ewi is up so I will build borzoi images now Jan 18 02:20:52 http://sam.rpsys.net/bitbake-circular-r3.patch Jan 18 02:21:06 RP: noticed - will look when images will bake Jan 18 02:24:57 hrw: thanks Jan 18 02:25:35 tomorrow I will go to work so there wont be time for testing ;( Jan 18 02:27:22 hrw: I know the feeling :-/ Jan 18 02:27:36 5 new testers for 3.5.4 Jan 18 02:28:19 thats 36 machines in total Jan 18 02:28:41 03hrw 07org.oe.oz354fam083 * ra4e045b9... 10/packages/openswan/ (2 files in 2 dirs): Jan 18 02:28:42 openswan-2.2.0: fix makefile for make 3.81beta Jan 18 02:28:42 taken from .dev Jan 18 02:29:43 hrw: That sounds like we're finally getting a good level of testing :) Jan 18 02:29:57 RP: yes Jan 18 02:30:16 RP: 1st place: collie, 2nd: borzoi Jan 18 02:31:02 jbowler-away: I've just tested the revised patch against a locally hacked copy of slugosimage and it shows signs of vaugely working. It chose unslug-kernel but couldn't resolve the RDEPENDS ixp-eth Jan 18 02:31:18 http://www.rpsys.net/openzaurus/temp/bitbake-prefprov-r1.patch is the revised version... Jan 18 02:33:07 Looking at the metadata, ixp-eth should work so I need to work out why that failed but it looks more promising than before... Jan 18 02:34:15 jbowler-away: I'm fairly sure it failed on ixp as it wasn't in the restricted list of packages my hacked slug setup parsed... Jan 18 02:38:11 morning Jan 18 02:38:18 03hrw 07org.oe.oz354fam083 * rb04d0e19... 10/conf/distro/openzaurus-3.5.4.conf: Jan 18 02:38:19 openzaurus 3.5.4: mark 'tslib' as prefered provider for 'tslib' Jan 18 02:38:19 NOTE: multiple providers are available (tslib, tslib-maemo); Jan 18 02:40:10 morning all Jan 18 02:40:46 RP: sorry richard, could not answer to you yesterday, I went to bed Jan 18 02:41:08 RP: about different kernel and modules, yes I compiled the image and kernel together Jan 18 02:41:08 hi katossi Jan 18 02:41:16 should I do it in a different way? Jan 18 02:42:10 no, that's the right thing to do. Did you wipe tmp/* before building the image? If not, there were probably some leftover files around which have confused ipkg... Jan 18 02:42:37 Removing tmp/deploy/ipk/*git3* might help Jan 18 02:42:55 ok Jan 18 02:43:07 Although 2.6.15 should be a higher version that 2.6.14-git3 so I don't know why it didn't work... Jan 18 02:43:17 It was 2.6.15 and not 2.6.15-rc7? Jan 18 02:43:27 rc7 Jan 18 02:43:48 katossi: You need to remove all traces of git3 then Jan 18 02:44:07 That makes sense to me as git3 had broken versioning Jan 18 02:44:19 ok Jan 18 02:45:52 but I need no preferred_version in local.conf, do I? Jan 18 02:46:22 katossi: If it built 2.6.15-rc7 ok last time, probably not Jan 18 02:46:30 ok Jan 18 02:46:49 is it just me, or does the monotone db need a whole lot more merging these days Jan 18 02:47:29 XorA: more changes? Jan 18 02:47:34 XorA: Our number of commits has jumped up and people are using the servers more randomly Jan 18 02:49:00 I pull/push to any working. vanille/ewi Jan 18 02:49:34 hrw: same here, the servers are so flaky its neccessary Jan 18 02:49:45 * XorA goes back to fixing amd64 problems Jan 18 02:50:27 any idea what the bandwidth of a server is? Jan 18 02:52:00 ewi has fastethernet access. but how much of it is used in normal day... Jan 18 02:54:41 Looking at the data transfer on a pull, I don't think bandwidth is too much of an issue... Jan 18 02:55:27 wow.. snow outside.. Jan 18 02:57:57 RP: unslung-kernel is not the correct kernel. You need MACHINE="nslu2" and DISTRO="openslug" (well, actually there are many possibilities, but those should work) and the PREFERRED_PROVIDER_virtual/kernel = "ixp4xx-kernel" (from the distro slugos.conf) Jan 18 02:58:34 And if you use that DISTRO your set of restricted packages will be overridden - because BBFILES gets assigned under freeze.conf Jan 18 02:58:35 jbowler-away: I wasn't using that MACHINE and DISTRO so it might be correct for the settings I had :) Jan 18 02:58:50 It would be correct for DISTRO="unslung" Jan 18 02:58:58 hm.. ewi died again ;( Jan 18 02:58:59 That's what I had... Jan 18 02:59:40 hrw: :-( Jan 18 02:59:53 RP: http://bugs.openembedded.org/show_bug.cgi?id=584 - could you close it? **** ENDING LOGGING AT Wed Jan 18 03:00:03 2006