**** BEGIN LOGGING AT Tue Sep 22 02:59:59 2015 Sep 22 08:27:28 morning all Sep 22 08:29:52 hi Sep 22 11:30:13 JaMae: there? Sep 22 12:21:56 is anyone using cgroups to group bitbake executions in autobuilders? Sep 22 12:22:26 eventually python ends not closing properly and next execution fails due the bitbake being still locked Sep 22 13:17:43 rburton: y Sep 22 13:20:02 JaMa: just finishing off a patch for the $B thing, would you be able to test it? Sep 22 13:22:55 yes, I can run the same for cycle again Sep 22 13:23:05 for i in `seq -w 1 1000`; do bitbake -c cleansstate perf; bitbake -c build -f perf 2>&1 | tee log.perf.$i; done Sep 22 13:45:27 JaMa: top patch in poky-contrib:ross/mut Sep 22 13:46:17 JaMa: basically changes the directory for the sstate functions to either workdir, or forces it to be sstate_instdir or _builddir as appropriate in the case where that is the obvious default and it's a recipe hook. Sep 22 15:09:00 WARNING: QA Issue: libgps rdepends on libcap, but it isn't a build dependency? [build-deps] Sep 22 15:09:00 WARNING: QA Iss Sep 22 15:09:29 adding libpcap to DEPEndS is correct? This isn't something that needs PACKAGECONFIGing? Sep 22 15:09:45 that depends on whether the dependency is optional or not Sep 22 15:10:04 and of course whether arguments exist to exlpicitly control the dep, rather than it being implicit Sep 22 15:10:12 if it is, and they do, then packageconfig is best Sep 22 15:10:28 * Crofton|work should also check master :) Sep 22 15:21:52 It is not obvious reading the source where that comes from (libcap) Sep 22 15:23:12 my guess would be libcap comes from the libcap recipe. Sep 22 15:23:23 which is sitting in oe-core Sep 22 15:24:46 yeah, I found the bit in gpsd docs that explai nit Sep 22 15:24:54 took some hunting Sep 22 15:26:13 http://git.savannah.gnu.org/cgit/gpsd.git/tree/build.txt#n118 Sep 22 15:31:36 ah, nice Sep 22 15:33:54 the build doc doesn't suggest a way to disable, so I cam going to make hard depends Sep 22 15:33:59 anyway, I use pps :) Sep 22 15:34:11 well, nnot from gpsd though Sep 22 15:34:24 how mnay packages force libcap to build I wonder? Sep 22 15:57:25 hm, it seems I've found a bug in oe-core; how to get my patch somewhere it might help? Sep 22 15:59:18 email it to the oe-core mailing list, as documented in the README in oe-core Sep 22 15:59:34 specifically the 'Contributing' section of the readme Sep 22 16:00:28 k', would have done so, but Crofton asked me to come here and cross-check with you people ;) point is that's it's a single character fix, Sep 22 16:01:05 changing oe-init-build-env to not invoke oe-setup-builddir, but to source it Sep 22 16:01:23 why would it need to do that? Sep 22 16:01:44 the whole point of oe-setup-builddir, afaik, is that it sets up the build dir, not the environment. the env is set up by the inernal env setup script Sep 22 16:03:09 because most people call oe-init-build-dev like "TEMPLATECONF=/path/to/templateconf source oe-core/oe-init-build-dev ./build ./bitbake" or similar, so TEMPLATECONF is a shell local Sep 22 16:03:57 internally, oe-init-build-dir sources oe-buildenv-internal (makes sense!) and then calls oe-setup-builddir Sep 22 16:04:04 I think it's a mistake to assume everyone runs it the way you do Sep 22 16:04:16 problem is that oe-setup-builddir thus never sees the TEMPLATECONF set by the user Sep 22 16:04:17 but regardless, the mailing list is the appropriate place for the discussion Sep 22 16:04:38 kergoth: agreed; it's Crofton's way, and I believe in the ways of the Crofton Sep 22 16:05:10 funkylab: or just add 'export TEMPLATECONF' to oe-init-build-env / oe-buildenv-internal before oe-setup-builddir is called. Sep 22 16:05:18 that would solve this problem as well, afaict Sep 22 16:17:14 apparently things work in bash and not in zsh Sep 22 16:17:20 at least the way I expect Sep 22 16:33:42 kergoth: export in buildenv-internal wouldn't, because changed env shouldn't "bubble up" to the _calling_ script; in oe-init-build-env, it would have side effects on the shell of the user; I don't think that would be favourable; anyway, making a patch, mailing the list; Sep 22 16:34:11 funkylab: okay, then TEMPLATECONF="$TEMPLATECONF" oe-setup-builddir :) Sep 22 16:36:16 :) kergoth, as much as I think sourcing a script is not what one would usually do in this situation, oe-setup-builddir itself assumes it's being sourced Sep 22 16:36:56 " try sourcing with a writable path? " <-- error message that oe-setup-builddir might print if called from a non-writable path Sep 22 16:37:12 funkylab, over several years, you are the only person to fall over this :) Sep 22 16:37:32 Crofton|work: I call it talent for disaster Sep 22 16:37:45 :) Sep 22 16:38:22 belen1, I'll try and build the database, the demo image is a long build Sep 22 16:38:40 quitter Sep 22 16:42:12 Crofton|work: sure. Let me know if you have any issues Sep 22 16:42:20 funkylab: yes, oe-setup-builddir is expected tob e run by oe-init-build-env, so that message is entirely appropriate in that context, it's telling you to source oe-init-build-env with a writable path. Sep 22 16:42:53 funkylab: and we should not be sourcing anything we don't have to, the more we source, the more we risk colliding with stuff in the user's shell, and the more temporary env vars we have to unset to cleanup after ourselves, including any shell functions Sep 22 16:45:50 kergoth: hm, I see. Sep 22 16:46:26 Will try the VAR="$VAR" approach later, then, because right now, workstation's busy doing what bitbake does Sep 22 16:46:28 heh, I knew there was a good reason :) Sep 22 16:46:37 ah, no, it's not. Sep 22 16:46:56 the ncurses task failed, and now its stuck. Sep 22 16:47:11 belen2, I figure having toaster shwoing how something demo'd live was built is an improvment Sep 22 16:47:33 funkylab, pastebin maybe Sep 22 16:47:43 I wonder if running under zsh is an issue? Sep 22 16:47:54 belen2: I think that would be really cool. It grounds the whole thing nicely, and proves it can be used to do something 'real' Sep 22 16:48:02 yeah Sep 22 16:48:23 Crofton|work: it *is* the issue Sep 22 16:48:27 Crofton|work: I was not talking to myself by the way ;) Not that crazy just yet Sep 22 16:48:35 yet .. Sep 22 16:48:36 But it shouldn't be, which I think is a bash bug Sep 22 16:49:14 bash is perfect Sep 22 16:49:23 Crofton|work: ... just like boost Sep 22 16:57:58 https://gist.github.com/marcusmueller/6ee57630602e59a713ea Sep 22 16:58:13 noees gave away my secret identity Sep 22 16:58:58 what are you buildin gon Sep 22 16:59:20 ncurses-native compile fail Sep 22 16:59:31 FC22/x86_64/gcc5.1.1 Sep 22 16:59:34 funkylab> FC22/x86_64/gcc5.1.1 Sep 22 16:59:43 crap, that manifest is dizzy era Sep 22 16:59:53 and ay not have gcc-5 fixes Sep 22 17:00:18 I think we have gcc-5 fixes in fido, maybe Sep 22 17:01:05 you understand problem? Sep 22 17:01:28 um, problem is that we're retro before being retro is cool? Sep 22 17:02:14 yeah Sep 22 17:02:52 ok, back to internal channel :) Sep 22 18:31:16 hi folks Sep 22 18:31:50 I just sent a patch to enable Wayland + EFL support in EFL to the list (http://lists.openembedded.org/pipermail/openembedded-devel/2015-September/103507.html) ; feel free to give your thoughts Sep 22 18:31:56 *EGL Sep 22 18:32:05 khem: hi :) ! ^^ Sep 22 19:44:13 Crofton|work: it looks like I've lost permissions to close github pull-requests, any idea why? maybe lost in repo rename Sep 22 19:44:37 Crofton|work: not that I really need them, but I usully ask github contributors to resend to ML and close it Sep 22 19:45:16 hmm, ok Sep 22 19:47:11 ok invited you to be in the maintainer team Sep 22 19:47:15 which has psush Sep 22 19:47:27 Let me know if this helps Sep 22 19:52:25 also, you should link to the layer specific README some people have trouble finding them like funkylab Sep 22 19:52:35 :) Sep 22 19:55:30 Crofton|work: as shr-project user? I don't see any difference Sep 22 19:55:54 yeah, you were invtied Sep 22 19:56:12 invite sent via email Sep 22 19:56:17 ah I need to accept first :) Sep 22 19:56:24 try going to https://github.com/openembedded Sep 22 19:56:26 yes Sep 22 19:56:34 ok better Sep 22 19:56:41 is there another account I should invite? Sep 22 19:58:13 Crofton|work: no, this account is ok, but that still doesn't give me permissions to close pull-requests :) Sep 22 19:58:26 or configure permissions Sep 22 19:59:13 ok Sep 22 19:59:40 ok bumped perms to top level Sep 22 20:01:06 still no close button in https://github.com/openembedded/meta-openembedded/pull/16 :/ Sep 22 20:01:26 weird Sep 22 20:01:38 maybe cached cedntials Sep 22 20:02:33 ok, lets see tomorrow :) Sep 22 20:02:51 ah mayb enow Sep 22 20:03:05 I made the team, but hadn't attached it Sep 22 20:03:16 I could likely drop privs down a step Sep 22 20:03:51 good now Sep 22 20:04:00 ok let me try one thing Sep 22 20:04:42 I dropped that team back to write access Sep 22 20:04:49 hopefully it still works **** ENDING LOGGING AT Wed Sep 23 02:59:59 2015