**** BEGIN LOGGING AT Sat Apr 01 03:00:03 2017 Apr 01 08:35:12 Is it possible to do shell-outs or python in a global context, e.g. from local.conf? Apr 01 08:39:32 We have a global scheme, a through a program, for getting the next appointed product and application version in a build. It must call call "increaseversion" only once per build (and we call bitbake multiple times for multiple machines), and it must use this version as PV for the main application Apr 01 08:40:55 I'm considering if I need to build all this logic outside bitbake alltogether and have these variables injected into local.conf, but it would be awfully nice if bitbake could handle this from within Apr 01 08:56:01 Ok so looks like builds still failing in new morty branch Apr 01 08:56:07 as http://lists.openembedded.org/pipermail/openembedded-core/2016-April/120615.html was never applied Apr 01 09:22:32 Yep, verified that patch fixes it for new gcc 6 in morty, this trying to configure libgcc at the same time as building all-gcc just consistently fails, only for aarch64 host & target Apr 01 14:37:26 gtristan: it was never applied since it seems like there is a bug in gcc that needs fixing and nobody else seemed able to reproduce that issue Apr 01 15:41:37 gtristan: I never ran into this issue on aarch64 build host, thus far myself. What target to you build for ? Apr 01 15:42:23 RP: I am playing with runit have you used/played with it for init system ? Apr 01 15:42:58 RP: it seems a good alternative to sysvinit and not a size hog like systemd Apr 01 16:22:54 khem: I've not tried it... Apr 01 19:25:20 * gtristan pops in at 4:20am... dont really mind, I know that A.) this is consistently reproducible targeting aarch64 on the aarch64 build host I have (but *not* reproducible when targeting armv7a)... and B.) the cost of not building configure-libgcc and gcc-all in parallel, is much much less than the cost of developer hours trying to coerce gcc build scripts to behave the way we *think* they should behave Apr 01 19:26:23 also, since I went through this last year, I can tell that maintaining a downstream patch to yocto is cheaper in developer hours than trying to convince people and demonstrate that it is indeed a reproducible bug Apr 01 19:26:26 so, meh Apr 01 21:44:12 gtristan: by that argument, any time we find a bug, we just hack around it and hope for the best. If we did that as a project, I can bet you'd have a much worse experience as a user of it... Apr 01 21:45:10 gtristan: I know I have probably spent *months* trying to keep the gcc recipes comparatively simple and worked hard to fix things upstream where possible **** ENDING LOGGING AT Sun Apr 02 03:00:01 2017