**** BEGIN LOGGING AT Tue Sep 20 02:59:56 2005 Sep 20 03:00:01 but I can reproduce it now Sep 20 03:01:56 I don't think 1.0.8 is too old. I'd rather say it's not old enough ;) Sep 20 03:02:23 alsa broke compatibility somewhere in the late 0.9.x days Sep 20 03:02:53 brb Sep 20 03:03:14 reenoo_: heh.. oh well, at least the OSS crackling bug is no longer present :) Sep 20 03:03:29 now to see if alarms work on resume in Opie Sep 20 03:04:40 actually, there is a "crack" noise when starting/stopping playback, though not as bad as it was with the OSS driver Sep 20 03:13:04 well. the cracking noise with the OSS drivers is so bad that you can hurt your ears when using earplugs Sep 20 03:13:13 I'd rather not ship them again Sep 20 03:25:12 mknod: invalid option -- - Sep 20 03:25:14 hmmm Sep 20 03:25:22 that doesn't look too good Sep 20 03:26:00 koen: s/--mode/-m/ Sep 20 03:26:30 reenoo_: I first have to track down which script in OE does this Sep 20 03:26:41 reenoo_: yeah, that would be a step backward Sep 20 03:26:58 hmm, no sound for alarms on resume... maybe it's trying to open the sound device too early or something Sep 20 03:27:09 actually the first time it completely locked up Sep 20 03:28:06 pb_: remember any first boot/suspend+resume issues with the alsa drivers from the 0.7.x days? Sep 20 03:28:59 bbl Sep 20 03:34:44 03frederic 07org.oe.dev * r344cfe46... 10/packages/gnome/ (gnome-vfs-dbus/gssapi.patch gnome-vfs-dbus_2.8.4.4.bb): Sep 20 03:34:45 gnome-vfs-dbus: do not use GSSAPI_LIBS if gssapi does not compile Sep 20 03:34:45 http://bugs.openembedded.org/show_bug.cgi?id=250 Sep 20 03:55:51 koen: packages/udev/udev-070/init: M) mknod --mode=600 /dev/$name $arg1 ;; <-- there, perhaps? Sep 20 03:56:23 NAiL: s/--mode/-m and it will work Sep 20 03:56:39 hrw|work: I know Sep 20 03:59:31 NAiL, koen, hrw|work: Do you mind if I check that in with the rest of the udev changes 'm working on? Sep 20 03:59:42 RP: feel free Sep 20 03:59:50 I'm rearranging half the directory so it will save me a bnasty merge Sep 20 03:59:58 RP: go ahead Sep 20 04:04:40 It will go in shortly, once I work out where I stand with udev :) Sep 20 04:07:04 RP: Since you're working on it... Apparently, static /dev is mounted on /etc/udev for some reason.. this gives this error in syslog: Sep 20 04:07:07 Sep 20 03:32:24 (none) daemon.err udev[1094]: parse_config_file: can't open '/etc/udev/udev.conf' as config file Sep 20 04:07:52 NAiL: It gets remounted there as part of the boot procedure - it should get remounted elsewhere shortly after Sep 20 04:08:21 hmm Sep 20 04:08:32 apparently it doesn't on the slug :P Sep 20 04:10:16 NAiL: I'll check it next time I reboot Sep 20 04:11:06 mount -n -o move /etc/udev /dev/.static/dev Sep 20 04:11:21 That's what is supposed to happen... wonder why it doesn't Sep 20 04:12:49 aha Sep 20 04:12:50 mount: /etc/udev is not a block device Sep 20 04:13:07 the mount move doesn't work Sep 20 04:27:22 pH5: the image I baked yesterday was missing a lot of kernel modules, so I'm switching back to ipkg 0.99.152 to see if that's the problem Sep 20 05:39:25 koen: i just got bitten by the same problem. any news on it? Sep 20 05:39:49 what does log.do_rootfs say? Sep 20 05:42:30 no log.do_rootfs. just a kernel update. Sep 20 05:42:43 it's at xcalibrate right now Sep 20 05:42:52 I'm rebuilding from scratch Sep 20 05:43:48 lunch time Sep 20 05:56:43 koen: I did a build from scratch yesterday (well I started it the day before), what were you missing? Sep 20 05:57:05 the dependencies for the kernel modules Sep 20 05:57:48 the ones listed in the machine.conf where installed, but not the depencies Sep 20 05:57:48 03koen 07org.oe.dev * re2a816af... 10/packages/ (2 files in 2 dirs): Sep 20 05:57:48 packages/gpe-contacts/: update hildon version to 0.42 Sep 20 05:57:48 packages/gpe-mini-browser/: update hildon version to 0.16 Sep 20 05:57:56 so I got a lot of unresolved symbols Sep 20 05:58:02 koen: okay Sep 20 06:17:38 pH5: I think the depends for the kernel modules are all wrong Sep 20 06:18:44 pH5: they only depend on update-modules and the image Sep 20 06:23:26 koen: does this depend on the ipkg version? Sep 20 06:24:12 it doesn't seem so Sep 20 06:24:23 this is with 0.99.152 Sep 20 06:24:32 so my next suspect is kernel.bbclass Sep 20 06:25:28 pH5: want to bet it's the extra-version mismatch? Sep 20 06:25:44 koen: wouldn't bet against it. Sep 20 06:26:59 koen: last time the problem was the kernel version stripping in parse_depmod() Sep 20 06:27:42 I'm flashing the new image to see if it still fails Sep 20 06:28:13 it could be my selections of modules to look at was wrong Sep 20 06:35:27 pH5: the boot confirms it, still broken Sep 20 06:36:14 koen: is this with EXTRAVERSION -hh2 or -hh3? Sep 20 06:37:02 pH5: whatever is in OE Sep 20 06:37:15 koen: you were right! that's it Sep 20 06:37:30 koen: i just recompiled with the makefile fixed and the dependencies are there again Sep 20 06:37:44 koen: change EXTRAVERSION to -hh3 in the kernel26/Makefile Sep 20 06:41:43 hmmm Sep 20 06:41:52 I'm wondering if we should add a patch Sep 20 06:44:24 koen: if nobody cares enough to fix it in cvs. Sep 20 06:48:14 pH5: I suspect that will be the case Sep 20 06:55:13 re Sep 20 06:55:48 opera 8.50 killed X ;( Sep 20 06:58:38 koen: ok. i'll commit the patch Sep 20 07:02:55 thanks Sep 20 07:03:07 mornign Sep 20 07:03:17 03ph5 07org.oe.dev * rd98bddca... 10/packages/linux/ (2 files in 2 dirs): handhelds-pxa-2.6: fix EXTRAVERSION of 2.6.12-hh3 Sep 20 07:12:00 03ph5 07org.oe.dev * r8a43dee8... 10/packages/linux/handhelds-pxa-2.6_2.6.12-hh3.bb: handhelds-pxa-2.6_2.6.12-hh3.bb: bump PR to r1 Sep 20 07:51:34 03tmbinc 07org.oe.dreambox * rd132e154... 10/packages/dreambox/dreambox-buildimage-native/buildimage.c: dreambox-buildimage-native: add NFI1 support Sep 20 07:51:40 03tmbinc 07org.oe.dreambox * rf3feeb84... 10/packages/linux/linux-dm7020.bb: linux-dm7020: set proper PR Sep 20 07:51:44 03tmbinc 07org.oe.dreambox * r85a65b39... 10/packages/tuxbox/ (tuxbox-stream.bb tuxbox-stream/add_configfiles.diff): tuxbox-stream: fix BOXTYPE Sep 20 07:51:48 03tmbinc 07org.oe.dreambox * r8dfe0d49... 10/packages/ipkg/ (ipkg-0.99.151 ipkg-0.99.154 ipkg_0.99.154.bb): ipkg-0.99.154: add tar gnu extensions to 0.99.154 Sep 20 07:51:52 03tmbinc 07org.oe.dreambox * r654a7cc6... 10/packages/samba/samba_3.0.20.bb: samba: opendreambox's samba packagesplit specific: make smb.conf belonging to sambaserver Sep 20 07:51:56 03tmbinc 07org.oe.dreambox * r5b807ee9... 10/conf/distro/opendreambox-1.2.conf: opendreambox-1.2: pin down ipkg and libsigc++ versions Sep 20 07:53:39 03tmbinc 07org.oe.dreambox * r71397221... 10/packages/dreambox/dreambox-dvbincludes.bb: dreambox-dvbincludes: don't install OST files for dm7025 Sep 20 07:53:49 03rpurdie 07org.oe.dev * r17725bba... 10/packages/pcmciautils/pcmciautils_010.bb: pcmciautils: Switch to udev instead of hotplug. Sep 20 08:00:26 03rpurdie 07org.oe.dev * rb40c2aec... 10/packages/udev/ (20 files in 6 dirs): Sep 20 08:00:26 udev: Rearrange the udev files into a more logical structure. Create copies of Sep 20 08:00:26 the rules we're using rather than the distributed version due to links to Sep 20 08:00:26 external scripts. Add mount.sh which attempts to mount block devices using Sep 20 08:00:28 pmount if available, falling back to mount if not. Fix the --mode switch to Sep 20 08:00:30 mknod in the init script. Sep 20 08:02:03 RP: great! Sep 20 08:03:35 pH5: Its not brilliant but its a start... Sep 20 08:04:35 03rpurdie 07org.oe.dev * rf9869b4d... 10/packages/udev/ (udev_058.bb udev_063.bb udev_065.bb udev_070.bb): udev: Bump PRs Sep 20 08:04:39 03rpurdie 07org.oe.dev * r8e1ce5fd... 10/packages/pcmciautils/pcmciautils_010.bb: pcmciautils: Bump PR Sep 20 08:34:56 cu Sep 20 09:00:23 Nice - lots of Richard Purdie entries in the 2.4.14-rc2 announcement Sep 20 09:00:46 nice Sep 20 09:04:42 RP: | install: cannot stat `/home/koen/OE/build/tmp/familiar/work/armv5te-linux/udev-070-r2/udev-070/etc/udev/udev.rules.devfs': No such file or directory Sep 20 09:04:43 Did anyone try to integrate Scratchbox with OE? Sep 20 09:04:53 realloc: not yet Sep 20 09:05:00 koen: :( Sep 20 09:05:35 koen: -native builds are ugly :-/ Sep 20 09:05:45 i'd like to implement scratchbox support for two purposes. 1) generating the cached test results so that subsequent builds dont require it, and 2) just using it as an alternative to the caching approach Sep 20 09:06:17 3) for braindead packages Sep 20 09:06:58 hehe Sep 20 09:07:03 thats just a bonus ;) Sep 20 09:07:13 http://lkml.org/lkml/2005/9/19/270 Sep 20 09:10:44 koen: A few more Zaurus patches made it in :) Sep 20 09:13:14 dillo http://lkml.org/lkml/2005/9/19/270 Sep 20 09:13:20 hi Sep 20 09:13:24 hey hrw Sep 20 09:13:37 RP: any idea on the udev error? Sep 20 09:13:56 koen: looking into it Sep 20 09:14:22 koen: You use devfs naming for udev? Sep 20 09:14:53 RP: no idea, I just did bitbake gpe-image Sep 20 09:16:41 koen: Does familiar need devfs naming? Sep 20 09:17:26 koen: You have UDEV_DEVFS_RULES = "1" in familiar-distro.conf which triggers this Sep 20 09:33:02 RP: is the breakage intended behaviour? Sep 20 09:36:51 koen: No, but if you include that script you'll get a devfs style /dev. I'm not sure that's what you want? Sep 20 09:37:42 RP: no idea, that's from before my time :) Sep 20 09:38:12 koen: Do you expect your memory cards as /dev/hda ? Sep 20 09:43:59 ~lart busybox 1.01 vi Sep 20 09:44:00 * ibot offers busybox 1.01 vi some herring Sep 20 09:44:38 RP: yeah Sep 20 09:44:40 RP: but with the automount scripts it shouldn't matteru Sep 20 09:47:34 koen: It seems this script just gets installed and not used. Who knows why... Sep 20 09:48:15 Actually, that's not true. It is used :-/ Sep 20 09:48:22 I really don't recommend using it... Sep 20 09:48:48 breaking builds is unacceptable either Sep 20 09:49:21 koen: I never said it was... Sep 20 09:49:31 koen: I just want to understand why its there... Sep 20 09:51:57 it's there because traditionally familiar has always used devfs or in order to get a consistent /dev layout on h3900 ipaqs no matter which kernel (2.4 or 2.6) you use Sep 20 09:52:31 pb_ would be the one to talk to for the exact reasoning I guess Sep 20 09:56:44 reenoo_: thanks. I think this is something that might need to be reconsidered at some point. Sep 20 09:58:05 http://www.cafepress.com/nucleartacos.26746951 Sep 20 09:58:07 * kergoth chuckles Sep 20 09:58:54 ;) theme from planet debian Sep 20 09:58:56 LOL Sep 20 10:02:19 03rpurdie 07org.oe.dev * r7c097245... 10/packages/udev/ (6 files in 2 dirs): udev: Add the devfs udev 'comaptiblity' rules to OE as it changes names in different versions of udev. We *really* don't want to be using these. Sep 20 10:02:48 someone with opie on 2.6 want script to switch usbnet/usbstorage via simple requesters? Sep 20 10:03:59 pH5|away: could you send the usbmode switcher patch to gpe@handhelds.org? Sep 20 10:11:29 cu Sep 20 10:56:03 koen: I'll send the gpe-conf usb applet as soon as I have tested that it at least runs in its current state. Sep 20 10:56:12 cool, thanks Sep 20 10:57:14 NOTE: package gpe-image-1.0-r17: task do_rootfs: started Sep 20 10:57:22 let's see how that one boots Sep 20 11:09:53 <_alwin_> hi Sep 20 11:48:29 pb_: the 2.6.12-hh3 .bb has a strange problem Sep 20 11:48:54 pb_: uname reports 2.6.12-hh2, but the modules all report 2.6.12-hh3 Sep 20 11:49:01 koen|tv: that is unfortunate Sep 20 11:49:15 what does the Makefile say? Sep 20 11:49:22 pb_: we patch kernel26/Makefile to have -hh3 Sep 20 11:49:35 do we need to patch more? Sep 20 11:49:50 it sounds like include/linux/version.h is not being properly generated. Sep 20 11:49:57 maybe the -hh2 version has gotten checked in to cvs by mistake. Sep 20 11:50:13 that file should not be in cvs at all, so if it shows up in the checkout that would be a bug. Sep 20 11:50:33 #define UTS_RELEASE "2.6.12-hh3" Sep 20 11:50:49 from ~/OE/build/tmp/familiar/work/ipaq-pxa270-linux/handhelds-pxa-2.6-2.6.12-hh3-r1/kernel26/include/linux/version.h Sep 20 11:51:35 check init/version.o, see if that file contains the right string Sep 20 11:51:43 hey Sep 20 11:52:02 and compare the datestamps on the two files; version.o should be newer than version.h Sep 20 11:52:27 (but older than the vmlinux file) Sep 20 11:52:44 aargh Sep 20 11:52:47 ~lart me Sep 20 11:52:47 * ibot executes killall -KILL koen|tv Sep 20 11:53:03 I keep forgetting the hx4700 has the kernel in a seperate partition Sep 20 11:53:38 ah Sep 20 11:53:54 :D Sep 20 11:55:36 koen|tv, i love you Sep 20 11:56:04 i take it we broke CF on the ipaq again? Sep 20 11:58:50 hi zap_ Sep 20 11:58:58 hi phil Sep 20 12:12:02 anybody want to commit the simple patches in http://bugs.openembedded.org/show_bug.cgi?id=336 to remove ts.conf-h2200? Sep 20 12:12:42 dibs Sep 20 12:14:06 thanks koen Sep 20 12:19:40 03koen 07org.oe.dev * rbd09b615... 10/packages/tslib/ (tslib/h3900/tslib.sh tslib_cvs.bb): Sep 20 12:19:40 packages/tslib/tslib/: remove h2200 linearizer, courtesy Matthew Reimer Sep 20 12:19:40 closes #336 Sep 20 12:23:41 pH5: your workaround for X messing with ttyS0 (bug 179) works for me, but emits lots of "Switching to mouse protocol..." messages when the pen is down. Have you found other workarounds for keeping X from messing with ttyS0? Sep 20 12:26:30 hey, do we have a test image for the ipaq? Sep 20 12:26:40 using 2.6? Sep 20 12:30:39 now why did cf stop working ... Sep 20 13:19:31 hi all Sep 20 13:21:38 I have customized the kernel which enabled ip filtering for ipv4, ipv6 but when I flushed with this newly created kernel, my zaurus just blank screen, can't even see booting screen. Anyone know why? Sep 20 13:26:22 abm_y4k: Which Zaurus? Sep 20 13:26:38 abm_y4k: Was it an oversized kernel? Sep 20 13:32:14 C3100 Sep 20 13:33:10 hm.. its a bit bigger than the original kernel size Sep 20 13:33:30 what should I do in this situation? Sep 20 13:33:40 restore a nand backup Sep 20 13:34:28 I did a restored of sharp's original nand. and it boot up fine to qt. Sep 20 13:35:02 ok, so you need a smaller kernel next time around. Use modules for some things Sep 20 13:35:15 do I need to increase the size in the kernel config file? Sep 20 13:36:10 abm_y4k: No. Zaurus kernels have to fit into a certain sized space in nand. You need to make your kernel smaller Sep 20 13:36:48 original kernel size: 1157384, but mod kernel size: 1355352 Sep 20 13:37:10 oh ic ic Sep 20 13:43:48 what is the max size the nand can handle? Sep 20 13:55:59 abm_y4k: See the linux-openzaurus 2.6 kernel .bb Sep 20 13:56:18 good night Sep 20 13:56:39 ok Sep 20 13:56:40 thankx Sep 20 14:03:04 I'm assuming pcmciautils has no need of coldplug? Sep 20 14:14:37 hmm, libmimedir seems to be building only a few locales ipkgs and not the main ipkg. Is this a known problem? Sep 20 14:19:33 mreimer: it seemed to build ok this afternoon Sep 20 14:20:01 trying it again Sep 20 14:22:34 restarted monotone on vanille.de Sep 20 14:33:23 mreimer: Packaged contents of libmimedir into /home/koen/OE/build/tmp/familiar/deploy/ipk/libmimedir_0.0+cvs-20050920-r0_armv5te.ipk Sep 20 14:34:47 thanks koen. I've been doing more investigating, and have found that "rebuild libmimedir" creates all the right files, but then "build gpe-image" fails because it can't satisfy the libmimedir dependency. When I check deploy/ipk, most of the cvs libmimedir ipkgs are missing except for a few locale ipkgs. Any ideas? Sep 20 14:36:36 ipkg-make-index -m could make them dissapear because it thinks it's older as the release Sep 20 14:36:55 what's the fix for that? Sep 20 14:37:21 remove the release ipks Sep 20 14:37:23 rm deploy/ipk/libmimedir* Sep 20 14:37:44 and move the cvs ones back out of the morgue Sep 20 14:38:13 ok, I'll remove libmimedir*2004* and see if it keeps the 20050920 versions Sep 20 14:39:01 is this a bug in OE? Sep 20 14:39:33 no, just unfortunate package naming Sep 20 14:39:38 ok Sep 20 14:39:49 should the package be renamed? Sep 20 14:40:08 the 2004 one used the wrong name Sep 20 14:40:31 so the 2005 ones has a correct name, but causes problems when the 2004 one is present Sep 20 14:40:36 ah Sep 20 14:42:32 so ipkg-make-index preens unnecessary duplicates from deploy/ipk? Sep 20 14:43:00 it moves old packages to the morgue, yeah Sep 20 14:43:01 -m only keeps the newest version Sep 20 14:43:07 nice Sep 20 14:47:51 NOTE: package gpe-image-1.0: completed Sep 20 14:47:52 thanks Sep 20 15:05:12 anyone want to commit the trivial patch in http://bugs.openembedded.org/show_bug.cgi?id=337 which changes mbcontrol -> matchbox-remote? Sep 20 15:32:31 'night all Sep 20 15:33:08 'night all Sep 20 15:33:44 03rpurdie 07org.oe.dev * rb0918c0a... 10/packages/pcmciautils/pcmciautils_010.bb: Sep 20 15:33:44 pcmciautils: Install the binaries into the correct place. Remove coldplug Sep 20 15:33:44 references as they now just create errors. Add dependency on module-init-tools - Sep 20 15:33:44 when busybox's modprobe expands to cover pcmcia alias handling, this can be Sep 20 15:33:45 removed. Sep 20 15:33:57 03rpurdie 07org.oe.dev * r0505ee47... 10/packages/module-init-tools/ (5 files in 2 dirs): module-init-tools: Upgrade to 3.2pre9. Change the update-alternatives priority so the genuine tool takes priority over busybox. This gets pcmciatils working properly. Sep 20 16:37:12 03tmbinc 07org.oe.dreambox * rc78f0483... 10/conf/machine/dm7025.conf: dm7025: include kernel in image, build little-endian jffs2, add NFI1 header Sep 20 16:37:16 03tmbinc 07org.oe.dreambox * r1cac9f56... 10/packages/dreambox/dreambox-secondstage.bb: dreambox-secondstage: support other machines (dm7020 and dm7025 for now) Sep 20 19:34:47 night Sep 20 22:26:39 03dyoung 07org.oe.dev * r8f6c3757... 10/packages/linux/openslug-kernel-2.6.12.2/defconfig: openslug-kernel: Add the missing USB Audio modules to the defconfig Sep 20 22:26:43 03dyoung 07org.oe.dev * r9bbf3b49... 10/packages/linux/nslu2-kernel_2.6.12.2.bb: openslug-kernel: adjust the package revision for added usb audio bits Sep 20 23:54:00 morning Sep 21 00:54:15 morning Sep 21 01:05:35 morning Sep 21 01:07:07 morning all Sep 21 01:08:12 RP: pcmciautils need to DEPEND on module-init-tools if it RDEPEND on it Sep 21 01:08:24 morning hrw|work RP Sep 21 01:09:11 hrw|work: I've never understood why you should have to do that but yes, I realise that now... Sep 21 01:09:48 ;) Sep 21 01:10:21 Why not just make task bootstrap's depends all of its runtime depends? Sep 21 01:10:44 This will cause massive problems when it comes to multi threaded bitbaking :-/ Sep 21 01:11:01 I dont use task-bootstrap - hrw-opie-image has own list of depends Sep 21 01:11:55 hrw|work: Well, the same would apply for all the meta packages... Sep 21 01:12:32 meta images usually depend on task-bootstrap Sep 21 01:15:55 hrw|work: I know. I think I need to be reminded of what DEPENDS= is supposed to mean... Sep 21 01:16:12 hrw|work: The good news is that pcmciautils is a lot more usable now Sep 21 01:16:18 It will autoload most modules Sep 21 01:18:19 like I said in an email to oe@ DEPENDS must make sure every package (.ipk) in RDEPENDS is built by the packages (.bb files) listed in DEPENDS Sep 21 01:19:17 exactly Sep 21 01:20:05 reenoo_: So we have no way of stating that a package only needs a dependency at runtime and there is no build time dependency? Sep 21 01:20:55 RP: how you will install module-init-tools with pcmciautils when it is not built? Sep 21 01:21:55 I'd assume that bitbake is clever enough to realise that if I'm going to install a package into an image, it would build all the runtime dependencies... Sep 21 01:22:07 it can't Sep 21 01:22:16 what about the case where module-init-tools is provided by more than one package? Sep 21 01:22:27 package installation isn't done by bitbake Sep 21 01:22:49 reenoo_: Well, ok, ipkg... Sep 21 01:23:04 right. ipkg can't build packages Sep 21 01:23:08 Actually, I'd say it was bitbakes fault Sep 21 01:23:14 for exactly that reason Sep 21 01:23:36 XorA: then it need to be virtualized Sep 21 01:23:47 This is what I was saying before - an image like a task-bootstrap should have all its rdepends as depends Sep 21 01:23:56 no Sep 21 01:24:04 there's no way to maintain that Sep 21 01:24:24 hrw|work: ah ok, then the distro.conf selects which virtual to make Sep 21 01:24:28 RP: rdepends are other then depends... you depend on virtual/kernel but rdepend on kernel and modules Sep 21 01:24:29 * XorA sees the light Sep 21 01:25:29 RP: task-bootstrap is not image - its meta Sep 21 01:26:01 RP: the root of the problem is that bitbake's dependency handling doesn't care about RDEPENDS Sep 21 01:26:24 reenoo_: Yes, and I think that needs to be addressed somehow... Sep 21 01:26:56 RP: feel free to add that type of functionality to bitbake Sep 21 01:27:23 RP: but until that happens please make sure RDEPENDS is a subset of what DEPENDS builds Sep 21 01:27:45 reenoo_: Fair enough - I'd assumed bitbake was clever than it is... Sep 21 01:28:08 This is going to cause nightmares when we come to mutlithreaded bitbake :-( Sep 21 01:31:01 RP: another aspect of the problem is the automatic subpackage generation Sep 21 01:31:09 like kernel-module-foo Sep 21 01:31:26 you can't say DEPENDS = kernel-module-foo Sep 21 01:32:07 if someone want article about cpufreq: http://www.intel.com/cd/ids/developer/asmo-na/eng/195910.htm Sep 21 01:32:07 and bitbake/OE doesn't know what could provide kernel-module-foo for RDEPENDS (RRECOMMENDS) before actually building all kernels Sep 21 01:33:46 right. in the general case there's no way to determine which packages will be built beforehand Sep 21 01:43:16 koen|slug: I'd agree that kernel-module-foo should only be an RDEPEND. I think the kernel packages should PROVIDE something like kernel-module-*. This would mean bitbake could set list of packages meta-bootstrap needs as DEPENDS + RDEPENDS and resolve the kernel-modules Sep 21 01:45:24 kernel-modules would actually need to be a RRECOMMEND, but your idea is a step in the right direction Sep 21 01:45:42 it still doesn't solve any problems for really auto-generated packages Sep 21 01:45:57 (all the python in do_package() ) Sep 21 01:46:05 koen|slug: Surely all the auto-generated packages have a common base name? Sep 21 01:46:27 so you can provide base-name-* ? Sep 21 01:46:32 no Sep 21 01:47:14 reenoo_: Have you an example? Sep 21 01:48:56 Or perhaps we need to state that auto-generated packages do have a common base name... Sep 21 01:48:58 no need for an example. the assumption that "all the auto-generated packages have a common base name" is wrong Sep 21 01:49:56 reenoo_: But would it be a problematic restriction? Sep 21 01:50:15 any restriction is problematic with >2500 .bbs Sep 21 01:50:41 That's why I asked what examples we have of .bbs that need this... Sep 21 01:51:25 this restriction would be particularly problematic since several .bbs make use of glob based packaging Sep 21 01:52:47 also I don't see much of a point in worrying about this right now Sep 21 01:53:29 Any particular reason for ignoring the issue? Sep 21 01:54:15 there is no issue if you follow the RDEPENDS built by DEPENDS Sep 21 01:54:21 it's no effort to put an extra package in DEPENDS Sep 21 01:54:29 versus overhauling bitbake + OE Sep 21 01:55:09 But the idea is a) broken and b) will make any multithreaded bitbake suck Sep 21 01:55:37 (and I will be writing the multithreaded bitbake) Sep 21 01:55:46 a) the idea isn't broken b) there is no multithreaded bitbake Sep 21 01:56:24 I shall write b) and prove a) ;-) Sep 21 01:56:49 how will stating the correct depends break multithreading? Sep 21 01:57:11 OE is designed on the assumption you will build everything with OE Sep 21 01:57:31 koen|slug: and it will be building everything with OE Sep 21 01:57:47 pcmciautils can build without module-init-tools being built Sep 21 01:58:04 The only time you need both is when you come to something like meta-bootstrap Sep 21 01:58:37 therefore meta-bootstrap's dependencies are wrong Sep 21 01:58:54 Currently we just fudge things Sep 21 02:00:09 what exactly is the point you're trying to make? your definition of DEPENDS differs from the one used for bitbake/OE. that's it Sep 21 02:00:25 there is no right or wrong Sep 21 02:00:32 RP: I can use OE to build just 'pcmciautils' for installing it on device - if i do clean build "bitbake pcmciautils" then I get uninstalable package Sep 21 02:01:01 hrw|work: I agree I have borken pcmciautils and need to fix it Sep 21 02:01:07 I have no problem with that. Sep 21 02:01:43 reenoo_: My point is that the current definition of DEPENDS is going to cause problems as and when we start doing multithreading Sep 21 02:01:58 ok ok - i'll read you all more Sep 21 02:02:28 RP: s/cause problems/make it less efficient/ Sep 21 02:03:14 RP: like koen said. I don't see a point in giving up flexibility for a bit more efficiency Sep 21 02:03:51 RP: to my knowledge that's always been a primary desing constraint for bitbake/OE Sep 21 02:05:48 reenoo_: You could also argue that bitbake/OE aren't suppossed to constrain what you can do and I'm demonstrating a constraint Sep 21 02:06:09 Anyhow, I'm aware of the issues and think I know how we can work around them Sep 21 02:06:55 Whilst useful, I realise I'll have to have a multithreaded bitbake coded and working before we can take this any further Sep 21 02:09:21 03koen 07org.oe.dev * r59522ce9... 10/packages/abiword/abiword_2.3.99.bb: packages/abiword/abiword_2.3.99.bb: s/AbiSuite-2.2/AbiSuite-2.4/g to fix packaging Sep 21 02:24:29 03ph5 07org.oe.dev * r9cc938ac... 10/packages/x11/x11_6.2.1.bb: x11: add the XErrorDB/XKeysymDB fix from cvs to 6.2.1, too Sep 21 02:30:25 03rpurdie 07org.oe.dev * r1c546e4d... 10/packages/pcmciautils/pcmciautils_010.bb: pcmciautils: Correct DEPENDS Sep 21 02:30:29 03rpurdie 07org.oe.dev * r7d60c571... 10/packages/maemo/nokia770-init_1.0.bb: nokia770-init: Correct DEPENDS Sep 21 02:33:29 RP: just uopgraded my kernel/udev/pcmciautils and now I get infinite list of had: hda1 messages Sep 21 02:37:28 XorA: I'm seeing it as well :-/ Sep 21 02:37:42 RP: and pccardctl eject goes into Dstate Sep 21 02:38:04 XorA: killall udevd gets rid of them Sep 21 02:38:17 not that I'm sugesting this is a good fix ;-) Sep 21 02:38:36 RP: :-) Sep 21 02:40:18 The thing is, these are kernel messages. For some reason the kernel is umounting and tearing down the block device... Sep 21 02:40:55 RP: auto modprobe of hostap_cs is however working, now it just needs to ifup wlan0 and the old behaviour is back Sep 21 02:42:43 XorA: Its a little more complex than that as I don't know what other config that script needs to do. But yes, its heading the right way :) Sep 21 02:43:39 RP: youve made things move in correct direction, though Sep 21 02:46:08 XorA: kind of. I'm nervous with these scripts as I can really break the images. My only comfort is that I feel they're getting less rather than more broken ;-) Sep 21 02:47:04 XorA: The mounting of memory cards is behaving in a really odd fashion. I disabled the mount.sh script. When I run mount /dev/hda1, udev sees the block device get removed and inserted again :-/ Sep 21 02:51:32 slightly OT: is there a reason why OZ doesn't distribute testing images? Sep 21 02:57:07 koen|slug: I'd guess that mickeyl would be the one to ask. I have made some images available quietly but stressed they're not OZ, just what OZ might be like,,, **** ENDING LOGGING AT Wed Sep 21 02:59:56 2005