**** BEGIN LOGGING AT Tue May 09 03:00:02 2017 May 09 06:55:39 if I build core-image-base for one imx6 device, and then also build it for another device, then things like the cross compiler, binutils, glibc etc. should be reused, right? they should not be rebuilt? May 09 06:55:56 assuming both devices use the same tuning flags May 09 07:18:47 dv_: yes May 09 07:51:12 what's strange is that I first built an image for the nitrogen6x, then an image for the ventana. both are imx6 machines. but when I tried to run the second build, all of a sudden TUNE_FEATURES contained the thumb feature. May 09 07:51:27 so in local.conf I explicitely removed it by setting TUNE_FEATURES_remove = " thumb " May 09 07:52:03 now I built the image for the ventana, but if I built it again for the nitrogen6x it rebuilds packages like libboost or opencv etc. which does not seem right May 09 09:13:29 dv_: if you change toolchain settings, everything have to be rebuilt by bitbake May 09 09:13:47 dv_: AFAIK May 09 09:14:28 yes. but after editing local.conf, I rebuilt the image again for ventana and for nitrogen6x. May 09 09:14:47 then I checked with bitbake -n what running "bitbake core-image-base" would do ... and it *again* would rebuild a lot of packages May 09 09:15:12 I suppose the reason is that whatever was adding thumb to the tune features is also causing this May 09 14:19:25 dv_: run bitbake-diffsigs May 09 14:19:45 many BSPs assume role of distros its a thin line May 09 14:20:44 ok thanks May 09 14:20:57 yes, indeed, it is a thin line. one example I can think of is setting hardfloat as default. May 09 14:21:16 another is trying to set opengl ES as default instead of regular desktop opengl May 09 14:21:33 (tbh, I find desktop opengl pointless on embedded platforms) May 09 14:39:18 dv_: yes indeed but desktop has a large pull in linux May 09 14:39:33 so embedded distros suffer from the gravity May 09 14:40:05 you usually hear about desktop distros more than embedded linux distros May 09 14:43:44 yeah. but then again, this is open*embedded* :) May 09 14:44:36 but yes, sadly whenever you try to build a DE, desktop gl is typically back, because gnome, kde etc. dont even bother adding gles backends to their compositors May 09 14:53:17 dv_: gnome3 can run on gles afaik May 09 14:53:53 hm k May 09 14:54:16 rburton: btw I have gstreamer 1.12 recipes ready. need to try them with X and wayland, then I can push them to the mailing list May 09 14:54:53 dv_: great May 09 14:55:05 we're about to diverge master May 09 14:55:19 btw. if I manually adjust a patch (like, adding a hunk to it), is it still okay to retain the original header? or do I have to sign off as well? May 09 14:55:57 no May 09 14:58:05 erm, yes you can maintain the header May 09 14:58:11 polite to add a note that you modified it i guess May 09 16:59:12 dv_: typically this would be done by adding your SOB line and above that May 09 16:59:23 [XX: blah blah blah] May 09 16:59:31 where XX are your initials May 09 17:00:50 this makes it clear that the original authors didn't signoff on your changes, yet the attribution is left intact May 09 17:01:02 rburton: whats the status of pending pulls for master May 09 17:01:09 rburton: specifically gcc7 May 09 17:30:32 khem: need to respin the gcc7 series but still blocking on a 4.1 kernel fix May 09 17:30:41 khem: apart from that master will be merging stuff again shortly May 09 17:53:48 rburton: ok. which machine uses 4.1 still May 09 18:47:31 khem: the poky-lsb configuration May 09 18:47:43 so either zedd changes that, or fixes the kernel May 09 18:54:44 hmmm I think lets break lsb May 09 18:54:52 and then it will get to conclusion May 09 18:55:33 we do try to keep master working always May 09 19:18:22 let me see if I can reproduce the failure May 09 19:23:59 rburton: we are on 4.1.38 in YP as far as kernel 4.1 is concerned May 09 19:24:06 we should move to 4.1.39 May 09 19:25:34 khem: yeah tell zedd :) May 09 19:25:44 any comments on: https://patchwork.openembedded.org/patch/139617/ ? May 09 19:25:57 or did I get the subject prefix wrong again May 09 19:29:05 rburton: I see its same error undefined reference to `____ilog2_NaN' May 09 19:29:19 rburton: I will send a patch shortly for 4.1 May 09 19:29:44 and let Bruce update the kernel rev at his own pace May 09 19:42:02 rburton: fixed 4.1 problem and pushed to http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/master May 09 19:42:12 rburton: lets give it another whirld May 09 19:42:30 lets see if it comes out with more errors May 09 19:44:47 fischerm: arent there options like --disable-manpages and --disable-info ? May 09 20:17:46 khem: yeah, there's boatloads, I didn't know how to sensibly map all of them May 09 20:23:22 fischerm: I just see you are deleting them so it would be better to either move the content to ${PN}-doc May 09 20:23:29 or disable it from building May 09 20:23:55 secondly check syntax with the checker May 09 20:24:09 the PACKAGECONFIG are defined before do_ functions May 09 20:24:14 rburton: http://sprunge.us/FNgD May 09 20:24:33 rburton: core-image-minimal w/4.1 kernel on qemux86_64 May 09 20:30:57 khem: thanks May 09 20:38:14 khem: checker? May 09 20:38:40 is qtwebkit finally abandoned and broken in 5.8/master? I'm having linker issues building it... May 09 20:56:03 "end of story" - huh, really? such an authoritative tone... May 09 20:57:39 denix: alex can be quite blunt but i kind of agree - OE has a layer model for a reason and if you want to use qt5 then there are well maintained layers for that purpose. there should be a high bar for entry into core. May 09 21:04:31 khem: fired a new gcc7 series on yocto.io. there's another build already going so it will take a while to start though. note that i've added two patches that you don't have in your branch. May 09 21:16:13 khem: why would building binutils-cross-canadian-arm complain about "too much recursions" in /usr/arm-oe-linux-uclibc/arm-oe-linux-uclibc-ld and loop in /usr/arm-oe-linux-gnueabi/arm-oe-linux-gnueabi-ld? I'm building for glibc, not uclibc... May 09 22:39:29 hmm, qt5 not building fro me (MACHINE-rpi3) May 10 02:15:46 denix: it still creates those symlinks for SDK May 10 02:16:08 denix: are you building with long paths ? or nfs by any chance ? May 10 02:16:33 being blunt can be ok if you speak substance May 10 02:17:21 OE community is thin comparatively, we should always consider what can be abandoned and do absolutely whats required by users **** ENDING LOGGING AT Wed May 10 03:00:00 2017