**** BEGIN LOGGING AT Fri Jul 25 03:00:01 2014 Jul 25 08:39:07 morning all Jul 25 09:45:58 JaMa: hi, I built l-y-t-kexecboot for qemux86 and do_package_qa did not throw errors...neverthless the patch is sent Jul 25 09:47:50 and included in next build :) Jul 25 09:47:52 thanks Jul 25 09:48:06 ah you mean that you weren't able to reproduce it, right? Jul 25 09:56:44 no, Jul 25 09:56:59 I tried first using sstate from previous arm build Jul 25 09:57:03 then from scratch Jul 25 09:57:26 so basically I did not build qemu's linux-yocto-3.14 Jul 25 09:58:05 don't spend more time on it, I'll do some tests with 3.16 Jul 25 09:59:42 I'll report if it still fails in next build Jul 25 10:00:02 I think it's really from those pkgdata conflicts between both recipes Jul 25 10:00:14 grep for that error message should reveal what exactly is conflicting Jul 25 10:00:50 th ename is different and there is no providers conflict, that's the strang ething Jul 25 10:01:05 argh this sticky 'e' Jul 25 10:02:02 JaMa: hm.. maybe the modules... Jul 25 10:02:37 I've seen qemu ends up building default kernel + modules ++ initramfs Jul 25 12:03:00 It's not a big deal maybe, but ctrl-c during bitbake's "Parsing recipes" in master doesn't seem happy Jul 25 12:24:10 kroon: yes, please add your findings in http://lists.openembedded.org/pipermail/bitbake-devel/2014-July/004941.html thread Jul 25 13:23:14 JaMa, thanks, not sure I can add anything new though.. Jul 25 14:51:46 I'm trying to use something like this to see if the current image I'm building contains gnu tar, but it's not working like I expect it to: Jul 25 14:51:59 ${@bb.utils.contains('PACKAGECONFIG', 'tar', 'has gnu tar', 'does not have gnu tar', d)} Jul 25 14:53:19 I think I'm misunderstanding how packageconfig works -- can one of you enlighten me? Is there an environment variable that would change if the current image being built contained the 'tar' package? Jul 25 14:54:13 that's not what packageconfig is for Jul 25 14:54:39 PACKAGECONFIG is in the reference manual with a sizable example Jul 25 14:55:04 what do you *actually* want to do? Jul 25 14:55:59 As part of a change to udev device node caching, I'd like to be able to use an argument with tar (--one-file-system) that only exists in gnu tar. Jul 25 14:56:19 If gnu tar is not in the image, I'd like to fall back to a less efficient way of doing it (using find). Jul 25 14:56:48 I'm trying to avoid having to check at runtime. Jul 25 14:56:58 you can only make that determination at image construction time Jul 25 14:57:02 that's not ideal. what tar is used on the image can change at runtime. the user can install tar after the fact Jul 25 14:57:10 and it will vary from one image to hte next Jul 25 14:57:12 so you'll probably have to do it at runtime as yeah what kergoth said Jul 25 14:59:34 As far as checking at runtime, is it safe to just check whether /bin/tar.tar exists (which I can do without forking processes in an init script)? Jul 25 15:04:28 the fact that it exists doesn't mean that tar links to it, necessarily. it uses update-alternatives, and update-alternatives can technically reconfigure at runtime Jul 25 15:04:39 a less likely scenario, but definitely could occur Jul 25 15:05:03 you could recursively resolve the /bin/tar symlink and see what it points to at the end, perhaps? Jul 25 15:05:05 * kergoth shrugs Jul 25 15:06:18 does this optimisation really bring much of a gain? Jul 25 15:06:39 (i'm wonder if the device node cache helps at all with current udev) Jul 25 15:06:46 its a good point Jul 25 15:07:10 We've found taht the device node cache does help, at least in our use case. Jul 25 15:08:04 The issue is that we're archiving everything under /dev, which includes things like /dev/cgroup and /dev/shm that we shouldn't be archiving. Jul 25 15:08:13 Which makes the cache larger that it needs to be. Jul 25 15:08:55 Excluding these with --one-file-system is ~0.2 seconds faster than using find | tar to do it. Jul 25 15:09:00 ouch, that does sound problematic. what sort of difference in boot time is there between with and without the cache, out of curiosity? Jul 25 15:09:29 Not sure off the top of my head -- would have to ask the guy who did the tests when he gets in. Jul 25 15:09:50 np Jul 25 15:11:53 Thanks for the help -- I think I'll use readlink -f to do it. Jul 25 16:12:39 kergoth: one thing that continues to bother me is the codeparser cache size. I wish we had a good algorithm to evict things from that :/ Jul 25 16:26:50 moin Jul 25 18:27:33 Great stuff this the new depends checking :) Jul 25 18:28:27 otavio, congrats on the book Jul 25 18:28:54 I'll make sure to order a copy Jul 25 18:29:39 "QA Issue: sed-ptest rdepends on locale-base-ru-ru" Jul 25 18:31:47 :-) nice! Jul 25 18:49:59 So, I'd like to get an opinion on something. I've been working, on and off, on breaking up the external toolchain recipe into separate recipes for each thing being set up or extracted from the sysroot, and am curious if that seems like something that makes sense, and if it would make things cleaner. Jul 25 18:50:54 https://github.com/kergoth/meta-sourcery/blob/recipe-split/recipes-devtools/gcc/gcc-runtime-external.bb -- the bbclass uses the FILES variables as explicit lists of what to extract from the sysroot of the external toolchain, and checks multiple paths in the toolchain to locate it Jul 25 18:51:28 breaking it up makes it easier to opt-in/opt-out of particular external components, and the generic sysroot extraction bits should make it easier to support toolchains other than just the sourcery one Jul 25 18:52:21 https://github.com/kergoth/meta-sourcery/blob/recipe-split/recipes-devtools/gcc/gcc-external-cross.bb symlinks/wraps the toolchain binaries into the cross bindir currently, rather than doing it up front at build start time / config parsed time Jul 25 18:54:52 Hmm, maybe I should send out an RFC email to solicit thoughts also Jul 25 21:30:09 * darknighte signs out of IRC for the weekend Jul 25 21:34:58 JaMa: something changed wrt openobex? obexftp fails suspiciously Jul 25 21:35:04 configure: line 12579: `PKG_CHECK_MODULES(OPENOBEX,openobex)' Jul 25 21:35:12 pkg_config changes? Jul 25 21:37:49 add pkgconfig inherit Jul 25 21:42:00 hmm there is pkgconfig already what version are you building and from where? Jul 25 21:51:24 I'm back Jul 25 21:51:26 ERROR: Task 5 (/oe/meta-opie/recipes-support/obexftp/obexftp_0.23.bb, do_configure) failed with exit code '1' Jul 25 21:51:57 iirc I've seen a patch adding pkg_config Jul 25 21:52:02 checking... Jul 25 21:53:55 jeez..3 recipes... Jul 25 21:54:42 totally different flags Jul 25 21:54:52 well, config options Jul 25 21:55:00 I have to ask bluelightning Jul 25 21:56:56 use meta-oe/recipes-connectivity/obexftp/obexftp_0.23.bb Jul 25 21:57:11 I've added pkgconfig atm Jul 25 21:58:27 the opie recipes disables more stuff, maybe there is a reason (surely there was long ago) Jul 25 21:59:19 JaMa: btw, the last dep tests you posted was the last w/out klibc fix I guess? Jul 25 22:04:24 IIRC, yes without Jul 25 22:55:55 obexftp should be in meta-networking Jul 25 22:56:09 and may be utilize some PACKAGECONFIGs Jul 25 22:56:22 meta-opie is certainly not right place for it Jul 25 22:58:55 hi khem Jul 25 23:01:51 hi **** ENDING LOGGING AT Sat Jul 26 03:00:00 2014