**** BEGIN LOGGING AT Mon Jan 19 02:59:58 2015 Jan 19 09:30:57 morning all Jan 19 09:34:49 morning mr intel Jan 19 11:06:12 a lot of MACHINEs put virtual/bootloader into EXTRA_IMAGEDEPENDS, but isn't MACHINE_ESSENTIAL_EXTRA_RDEPENDS a better place? (the manual recommends EXTRA_IMAGEDEPENDS for bootloaders) Jan 19 11:16:17 mago_: it depends if the bootloader actually needs to go into the rootfs or not... a lot of the time it's just a separate binary, in which case you just want it built alongside rather than installed into the image Jan 19 11:40:43 i only ask because im trying to figure out where to put wic dependencies. I'm using wic to build a vfat boot partition, which depends on mtools-native. So I could put it in as a EXTRA_IMAGEDEPENDS, or force all developers to install mtools on their development machines. Perhaps there is a better place? Jan 19 11:45:02 mago_: well EXTRA_IMAGEDEPENDS isn't really the right place for that since that needs to be in place before do_rootfs Jan 19 11:45:56 (well, actually maybe not in this instance... but it might still be best to set it up so that it is) Jan 19 11:46:05 really? currently i run wic manually from the shell, well after all bitbaking has finished Jan 19 11:46:15 right, yes Jan 19 11:46:17 didn't know there was a way to integrate wic into the build Jan 19 11:46:25 there isn't, at the moment Jan 19 11:46:35 you could do something like do_rootfs[depends] += "mtools-native:do_populate_sysroot" Jan 19 11:47:07 where? in my image? cause this applies to all my images, for a specific machine. Thats why i felt EXTRA_IMAGEDEPENDS in my machine conf made sense Jan 19 11:48:44 EXTRA_IMAGEDEPENDS += "mtools-native" would probably work for this yes Jan 19 14:15:31 bluelightning: is it possible to force run populate_sysroot for all packages of a specific image? i screwed up and remove tmp-glibc, and now the cache kicks and it doesn't generate the sysroot so wic fails. and i'd prefer to not wipe my cache Jan 19 14:16:24 mago_: not easily no.. but wic shouldn't need everything, just a small subset Jan 19 14:17:02 I think wic unfortunately looks at the workdir for some things rather than the sysroot Jan 19 14:17:56 that's unfortunate. whats happening for me is that it tries to run mkfs.ext4, but it's not in my native sysroot (because i wiped it). so instead it falls back on my host mkfs.ext4, which doesn't accept the -d cmdline argument (not sure what that does) Jan 19 14:18:21 took me a while to figure out that, and not sure if its such a good idea to allow wic using host tools at all. Jan 19 14:18:28 bitbake -c populate_sysroot e2fsprogs will fix that Jan 19 14:18:44 yes, I think there's a bug filed to handle that more gracefully Jan 19 14:18:49 * bluelightning checks Jan 19 14:19:13 yep: https://bugzilla.yoctoproject.org/show_bug.cgi?id=6204 Jan 19 14:19:34 er, that would be bitbake -c populate_sysroot e2fsprogs-native Jan 19 14:19:36 whoops Jan 19 14:20:26 great, that bug also mentions mtools-native which i've put in as a EXTRA_IMAGEDEPENDS Jan 19 15:37:14 is there an easy fix for buidhistory git commits taking forever? Jan 19 15:37:57 you can trim the repository history, or wipe it out Jan 19 15:38:03 ok Jan 19 15:38:11 Koen runs his from an SSD IIRC Jan 19 15:38:14 that is pretty much what I was going to do Jan 19 15:38:26 I do not really need much histry Jan 19 15:38:39 these days we do at least garbage collect it on a regular basis, that has helped a bit Jan 19 15:38:42 so will likely just wipe buildhistory dir andlet it start over Jan 19 15:43:38 Crofton|work: ssd, hot file cache due to tons of ram and git-filter-branch Jan 19 15:43:55 * Crofton|work doesn't really need complete history :) Jan 19 15:46:02 it isn't too bad on spinning rust, provided it's not on the same disk as TMPDIR Jan 19 15:46:13 again, tons of ram help with file caching :) Jan 19 15:46:54 yeah, having it on the same disk means that the build almost always pushes it out of the cache -> waiting at the end Jan 19 15:48:14 metadata + buildhistory on 1 SSD, work on ext4/spinning rust, sstate-cache on btrfs/different spinning rust seems to work quite well Jan 19 15:48:48 I haven't decided whether to get a 1TB ssd or add 32GB of ram to make it go faster Jan 19 17:29:44 hello, does anyone knows if the buildall option for bitbake is still working on dizzy? Sounds like it does what I need, but bitbake doesn't understand the task when I run "bitbake -c buildall Jan 19 18:20:59 any idea what triggers the build of lttng-modules Jan 19 20:33:59 meh, still not 100% happy with the recipetool-python stuff, but that'll have to do until i find the gumption to finish reworking the package search bits. already spent more time on it than is probably sane, but i get stubborn Jan 19 20:46:10 kergoth: its a nice step towards workflow **** ENDING LOGGING AT Tue Jan 20 02:59:59 2015