**** BEGIN LOGGING AT Tue Aug 26 02:59:58 2014 Aug 26 07:32:47 I'm a little confused, shouldn't these new "sets PACKAGE_ARCH before inherit packagegroup" errors prevent bitbake from continuing to execute ? Aug 26 07:34:30 yes, but they don't Aug 26 07:34:38 I was confused about that as well :) Aug 26 07:49:53 koen, feels good not to be the only then confused then :) Aug 26 08:00:53 morning Aug 26 08:07:45 Would it make sense, for kernels, to add some sort of "copy back defconfig to its origin after modiyfing with menuconfig" task ? Aug 26 08:12:44 do_lazyconfig? Aug 26 08:12:56 ;) Aug 26 08:15:23 even if that would happen, neverthless you ought to commit the metadata changes Aug 26 08:16:41 besides that, you should run do_savedefconfig after do_menuconfig Aug 26 08:17:35 ..and possibly diff the new/old defconfig before committing the change Aug 26 08:25:52 yeah, the way I do it now is menuconfig, savedefconfig, then manually copying back the defconfig, so I can "git diff" it Aug 26 08:27:04 and the defconfig is buried deep down in tmp-eglibc/ Aug 26 08:27:16 I'll wear out the tab-key Aug 26 08:31:42 I do that for non-yocto kernel development Aug 26 08:32:21 wrt linux-yocto you can manage all in SRC_URI adding a specific fragment which will override the existent .config Aug 26 08:32:59 the specific line of the .config I mean Aug 26 08:34:01 ah, yes, I'm using the kernel in meta-fsl-arm, which I think doesn't use the fragments infrastructure thing for some reason .. Aug 26 09:40:11 JaMa: I have a vague idea about the armv4 / thumb. I suspect the tune files doesn't cope Aug 26 10:23:47 ant_work: that should be easy to check with bitbake -e Aug 26 10:39:10 ant_work: looking at the commit you referenced in the e-mail, but I don't see the connection yet (maybe missing coffee on my side) Aug 26 10:50:54 JaMa: maybe not that specific one but very probably one of the commits of april 29th Aug 26 10:51:31 tune-files rehaul Aug 26 10:53:10 iirc one inverted the logic of the interworking check Aug 26 10:54:37 for armv4/eabi we need interworking but no thumb *and* the --fix-v4bx Aug 26 10:58:32 IIRC interworking wasn't touched by my patches, they only allowed to have machine without arm ISA Aug 26 11:13:10 kroon: it does alter the return code Aug 26 11:13:20 kroon: jenkins is quite unhappy Aug 26 11:13:36 I think I've fixed meta-angstrom, JaMa fixed meta-oe Aug 26 11:13:48 so that leaves meta-fsl-arm and meta-opie by the looks of it Aug 26 11:16:46 koen, was that for me ? Aug 26 11:17:04 was that about PACKAGE_ARCHs? :) Aug 26 11:17:09 yes and yes Aug 26 11:18:48 koen, ah ok Aug 26 11:19:15 * koen really needs to setup the jenkins log parser plugin Aug 26 11:19:28 JaMa, did you get a chance to review e457d71641af8802e47eb4854072e3cfb957b001 in OE-core, when I did the commit ? Aug 26 11:21:49 all this talk about arm tune-features makes me nerveous Aug 26 11:22:38 kroon: the usual arm mess Aug 26 11:23:19 koen, I'll send patches for meta-fsl-arm later tonight, if no beats me to it Aug 26 11:23:25 kroon: yes, I think it's fine, thanks for fixing it Aug 26 11:23:39 JaMa, ok, good Aug 26 12:37:51 dv_: any update on those gst* patches? One of last changes for me to include them in full world rebuild and dependency test Aug 26 12:41:46 not yet. the configure.ac needs to be fixed to get rid of that libglu dependency Aug 26 12:42:06 and the libjpeg-turbo thing is a problem of its own Aug 26 12:42:18 I get warnings that both libjpeg and libjpeg-turbo provide the same binaries Aug 26 12:42:52 JaMa: hopefully tomorrow I'll have something Aug 26 12:44:20 dv_: ok, thanks for update Aug 26 12:44:32 dv_: you need to set P_P for libjpeg Aug 26 12:45:44 we stil lack a default provider for nodistro Aug 26 12:46:12 but somehow bluelightning said it is not needed Aug 26 12:46:15 ? Aug 26 12:46:15 -turbo should be a safe default Aug 26 12:46:30 ant_work: the bitbake warning says what to do Aug 26 12:46:35 yes, big distros already switched Aug 26 12:46:45 ant_work: so people even with nodistro should know what to put in local.conf Aug 26 12:47:14 why do you want bother the poor developer to mangle local.conf unnecesssarly? Aug 26 12:47:24 ant_work: the atmel people seem to have a problem with it for cortex-a5, I'll need to poke noglitch about that Aug 26 12:47:52 ant_work: because it's their choice Aug 26 12:48:27 choices are good, sane defaults are gold;) Aug 26 12:49:06 if it's only for one arch we can add an override Aug 26 12:49:18 default allows building both if there is dependency on them Aug 26 12:49:48 it's not the only recipe where the staged files conflict Aug 26 12:50:01 luckily this one does that with nice bitbake warning which says so Aug 26 12:50:12 it's the only missing provider I encounter Aug 26 12:50:24 (I don't do world builds ;) Aug 26 12:50:30 unlike fftwl fftw fftwf Aug 26 12:51:15 and giflib and libungif did before I've removed libungif Aug 26 12:52:09 I have no strong opinion on this but looking around the major distros did swirtch to -turbo years ago Aug 26 12:52:16 -r Aug 26 12:53:13 the same problem exists for "python-dateutil gnome-keyring modphp qtbase gnome-menus libgweather systemd xz" Aug 26 14:18:21 Whats a good way to append busybox features ? Aug 26 14:18:38 by using a .cfg file ? Aug 26 14:18:41 kroon: using config fragment from a .bbappend? Aug 26 14:19:01 ndec, busybox supports fragments too ? Aug 26 14:19:08 yep Aug 26 14:19:13 nice Aug 26 14:19:50 kroon: e.g. https://git.linaro.org/openembedded/meta-linaro.git/tree/HEAD:/meta-linaro-integration/recipes-core/busybox Aug 26 14:20:59 ndec, I think the '%' in the .bbappend is playing tricks with the webserver.. Aug 26 14:21:16 yes, that's right i noticed that... Aug 26 14:21:21 ndec, but thanks, looks like I can just add the .cfg file to SRC_URI ? Aug 26 14:22:22 kroon: https://git.linaro.org/openembedded/meta-linaro.git/tree/6cb8d4bed405049da1ffb0c5790375973aac90f3:/meta-linaro/recipes-core/busybox Aug 26 14:22:28 it's before we used the %... Aug 26 14:23:03 ndec, cool, will try Aug 26 16:32:09 moin Aug 26 19:03:05 How would I fix meta-fsl-arm's directfb PACKAGE_ARCH/inherit packagegroup issue.. The original recipe only uses "inherit packagegroup", and meta-fsl-arm does PACKAGE_ARCH_mx6 in a .bbappend Aug 26 19:33:44 Would it help if the recipe in oe-core set PACKAGE_ARCH to an empty value before inheriting packagegroup Aug 26 19:39:00 It seems to do the trick, but I wouldnt know what value to set in PACKAGE_ARCH, and wether this is ok Aug 26 20:11:05 I wonder why the PACKAGE_ARCH/inherit error for packagegroup-core-directfb.bb when using meta-fsl-arm doesn't show up in the yocto autobuilders.. Aug 26 20:11:16 logs Aug 26 20:26:00 kroon: apply http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/machineoverride&id=0e3c53a4d84fa2a3c5e6b53697b953fab59a71bc Aug 26 20:34:38 khem, it doesn't seem to help this particular problem Aug 26 20:36:23 how is override done Aug 26 20:36:32 and what is it overriding Aug 26 20:36:58 Problem is that packagegroup-core-directfb.bb in oe-core sets "inherit packagegroup" without setting PACKAGE_ARCH at all, and the .bbappend in meta-fsl-arm does PACKAGE_ARCH_mx6 = "${MACHINE_ARCH}" Aug 26 22:06:41 khem, ping Aug 26 22:11:03 khem, here we need RP... Aug 26 22:11:39 calling with klcc -v I see something ugly... Aug 26 22:14:22 whats up Aug 26 22:14:58 there are two run: one for collie/armv4 *then* one for poodle/armv5te Aug 26 22:15:04 ok Aug 26 22:15:05 in a different sysroot... Aug 26 22:15:08 show me outputs Aug 26 22:16:11 http://pastebin.com/2Xz5sQ5k Aug 26 22:17:14 the same objects are processed twice Aug 26 22:20:07 it shouldn't absolutely peek in poodle sysroot Aug 26 22:29:34 khem, seems there is some sort of contamination. I'll try rebuilding from scratch, one single target (collie/armv4) **** BEGIN LOGGING AT Tue Aug 26 22:33:52 2014 **** ENDING LOGGING AT Wed Aug 27 02:59:58 2014