**** BEGIN LOGGING AT Wed May 01 02:59:58 2013 May 01 03:02:46 i'm relatively new to yocto too. i'm working on a custom gumstix overo storm image for datalogging. May 01 05:03:16 how would I include the ipkg database in the image so "opkg-cl list-installed" shows all the packages? May 01 07:05:15 i'm getting "Disk full" when trying to create directdisk image. any ideas? May 01 07:08:26 it seems to be some sort of race condition? May 01 07:16:01 between do_bootimg and do_bootdirectdisk May 01 07:17:42 Net147, build/conf/local.conf May 01 07:17:53 BB_DISKMON_DIRS = "\ May 01 07:17:53 STOPTASKS,${TMPDIR},1G,100K \ May 01 07:17:53 STOPTASKS,${DL_DIR},1G,100K \ May 01 07:17:53 STOPTASKS,${SSTATE_DIR},1G,100K \ May 01 07:17:53 ABORT,${TMPDIR},100M,1K \ May 01 07:17:54 ABORT,${DL_DIR},100M,1K \ May 01 07:17:56 ABORT,${SSTATE_DIR},100M,1K" May 01 07:18:37 that isn't it May 01 07:19:21 in build_boot_dd() - ${HDDDIR} contains initrd, ldlinux.sys, syslinux.cfg, vmlinuz at the time it calculate the number of blocks May 01 07:19:53 then shortly after before it copies HDDDIR into the image, anothek is creating rootfs.img in the same directory May 01 07:20:02 *another task May 01 09:34:45 I have problem. it seems do_bootdirectdisk and do_bootimg tasks are running concurrently when creating an image... this means rootfs.img is being created while the folder it is contained in is being copied into a directdisk image... May 01 09:35:51 this can result in 2 problems. 1 - directdisk image contains incomplete rootfs.img (it is still in process of being written), 2 - disk full error because size of the directdisk image was calculated before the rootfs.img was completely written May 01 09:36:44 the solution would probably be to ensure that do_bootimg is completed first before do_bootdirectdisk task is started. any idea how I would do that? May 01 09:39:09 how to force ordering of tasks inside a recipe? May 01 09:39:15 Net147: Take a look at http://git.openembedded.org/openembedded-core/commit/?id=578937213c6db9fa99981778ce61210e391b19a7 May 01 09:39:48 paulbarker: yes, that seems similar May 01 09:42:00 paulbarker: thanks, i'll take a look at it a bit later and post a patch when it's done May 01 12:45:37 kergoth: around? May 01 12:48:08 kergoth: basically I'm looking at bitbake under python3. I have things mostly working (can build pseudo-native) but I'm unsure how to make oe.types work :/ May 01 12:49:22 kergoth: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t1&id=f5387f9102b3a38c4b73fef3f50fb56b3b7c1eff - I made a horrible hack just to see what other issues there were May 01 12:52:05 RP: cool. I use a wrapper script on Arch Linux in my PATH to set python2 as default. May 01 12:52:57 Net147: I'm not promising we'll make this work at any point soon, I just want to see how bad the problems are May 01 12:53:54 RP: I have gotten Yocto to work under Arch Linux. but you need to install GCC 4.6.4, add wrappers to make it default, add wrappers to make python2 default, update guile to fix incompatibility with texinfo 5.x May 01 12:54:40 RP: GCC 4.8 can't compile GCC 4.7.2 =/ May 01 12:55:16 Net147: I know. The GCC folks really slipped up there :( May 01 12:59:28 RP, kergoth is likely not quite up May 01 13:00:14 RP, I wonder if there is a way for OE to bootstrap on 4.8 based systems? May 01 13:00:45 in boot-directdisk.bbclass I changed "addtask bootdirectdisk before do_build" to "addtask bootdirectdisk after do_bootimg before do_build" to fix do_bootdirectdisk executing at same time as do_bootimg and creating a corrupt image. do you guys think that's the correct way to fix the issue? May 01 13:09:18 Crofton|work: there are ways, we could build a gcc native May 01 13:09:29 Crofton|work: problem goes away when we move to 4.8 May 01 13:11:15 RP: I have gotten reports that GCC 4.8 can't be used to compile GCC 4.8 on Windows May 01 13:11:38 yeah, but we need to find a native we can build with 4.8 May 01 13:11:57 I have built 4.6.4 successfully with 4.8 May 01 13:18:03 Crofton|work: things other than our current 4.7 seem ok May 01 14:11:46 sgw_: ping May 01 14:56:54 with .hdddirect images, is the fat partition supposed to contain a rootfs.img that is a duplicate of the ext3 partition? May 01 14:58:38 it seems to have the root partition data twice May 01 16:58:41 otavio: You around? May 01 17:00:08 khem: you around? May 01 18:23:29 g'day folks. I'm adding a package and when I compile I get: ERROR: QA Issue: foo rdepends on foo-dev May 01 18:23:48 I'm assuming foo has a binary that depends on a library that's getting put in foo-dev? May 01 18:24:12 Garibaldi: that's a fair guess May 01 18:24:24 is there someplace I can read about the standard package separation? May 01 18:24:35 I've seen what files get put where in bitbake.conf May 01 18:24:42 every distro packaging guide ever, really May 01 18:24:46 they all have the same rules May 01 18:24:58 -dev packages contain the .so symlinks May 01 18:25:05 as they're for development purposes only May 01 18:25:19 main packages contain *.so.* May 01 18:25:39 ah, so my binary depends on foo.so instaed of foo.so. May 01 18:26:18 I mean, is that safe to infer from the error? May 01 18:26:36 (I didn't write this package -- I'm just trying to add a recipe for it) May 01 18:27:01 more likely that your FILES are bad May 01 18:27:25 and your -dev contains the real library and not just symlinks May 01 18:27:40 my recipe doesn't touch FILES, perhaps I should be? May 01 18:27:52 in that case you may have a case of really nasty software May 01 18:28:07 but its hard to help without seeing anything beyond vague warning messages May 01 18:28:09 of that I have no doubt -- it's in-house company software May 01 18:28:47 if you software is really installing .so files that are the real library then you'll need to rewrite the FILES to put them in the main package and turn off the resulting QA warnings May 01 18:28:55 yeah, I understand. I'll supress the warning and see what gets put in which RPM, then I'll see if I can tweak FILES to get the wrong files in the wrong packages May 01 18:29:00 and tell the engineers they're doing libraries on linux wrong May 01 18:29:10 indeed :-) May 01 18:29:21 thanks for the pointers May 01 18:29:33 sort out files then warnings, ideally you won't have the -dev problem if you fix files May 01 18:29:43 but you may get warnings about dev symlinks in a non-dev package instead May 01 18:30:40 I'm somewhat a novice at libs too, is there a "standard" place where the dependence gets expressed? Maybe I can patch their package to make it more correct. May 01 18:31:11 (they are using autotools) May 01 18:33:34 Garibaldi: its all about symbol versioning - the library should have .so.1.2.3 where 1.2.3 is the abi version May 01 18:35:24 yeah, that makes sense. I'm looking for how/where that should be specified. If it's not specified and should be, maybe I can create a patch to put it in/fix it. May 01 18:37:28 but I've never actually written a library so I'm poking around config files trying to figure out where the ABI version is specified May 01 18:41:52 and I don't know autotools, which adds insult to injury May 01 19:34:38 and I don't know autotools, which adds insult to injury May 01 19:34:56 err, sorry -- wrong window for up-arrow May 01 20:52:08 rburton: seems the build system had an error in it's foo_la_LDFLAGS; they were using the '-module' flag and '-release' instead of '-version-info' May 01 20:52:19 those changes seem to have satsified bitbake May 01 20:56:20 now my ${PN} package gets the lib as lib.X.Y.Z with a symlink lib.so.X and a symlink lib.so, which, as I understand it, it what we're suppose to have May 01 20:56:31 indeed May 01 20:57:16 cool -- thanks for the confirmation May 01 20:59:01 Ok, next problem :-) May 01 20:59:24 I have a package that I want to support creating native packages for May 01 21:00:18 I have BBCLASSEXTEND = "native" and I have a valid target of package-native; but I need to specify a different set of compiler flags for native vs non-native May 01 21:00:47 is there some way to suffix my EXTRA_OEMAKE variable for package vs package-native? May 01 21:01:22 EXTRA_OEMAKE_class-native = "" May 01 21:01:32 or virtclass-native, depending on the yocto/poky/oe-core version you're using May 01 21:01:39 grep around the metadata, there are many examples May 01 21:01:47 will do -- thanks May 01 22:03:22 rburton, kergoth: thanks again for your help. Have a good oen May 01 22:03:27 s/oen/one/ May 01 22:04:35 * mranostay pokes challinan May 01 22:21:20 hi mranostay! May 01 23:51:48 sgw1: yes May 02 00:01:33 otavio: I know it's late there, we can touch base in the morning, it's about the bugs in bugzilla assigned to you May 02 00:02:14 sgw1: ahh May 02 00:02:22 sgw1: no problem to me May 02 00:03:12 otavio: just wondering if you will be addressing them for your BSP release in 1.4 or 1.4.1 or 1.5? May 02 00:03:48 sgw1: which issues? let me query bugzilla here May 02 00:04:41 otavio: see pm May 02 00:05:00 sgw1: all these open bugs, we could try for 1.4.1 but some may need BSP upgrade May 02 00:05:55 Ok, do you want me to change them to 1.4.1 target? May 02 00:07:44 sgw1: please do :-) May 02 00:07:56 sgw1: I update if we miss it again May 02 00:08:25 Ok, I will mark the lows for 1.5 and others for 1.4.1, you can always fix them sooner in your BSP! May 02 01:36:58 What is the minimal necessary in a yocto-linux_3.8.bbappend for it to actually pull in some config changes? May 02 01:37:37 So far I have this: https://gist.github.com/anonymous/f78783d06e6c78eaa15d May 02 02:39:02 github is out to lunch for abit **** ENDING LOGGING AT Thu May 02 02:59:58 2013