**** BEGIN LOGGING AT Tue Aug 14 03:00:02 2018 Aug 14 07:13:51 good morning Aug 14 07:15:31 is it possible to get the SRCREV from a bitbake which is stored in a recipe A meta-layer1 and use it in recipe B meta-layer2 (I am thinking of storing a variable in recipe B which gets using d.getVar(SRCREV from recipe A) Aug 14 07:15:57 if this is possible, could someone point me to a link for an example? Aug 14 07:41:08 Alex___: I'm afraid you cannot, no... basically you can either set it globally and then have each recipe pick up the value, or have both recipes inherit a custom class or require a custom include file and set it in there Aug 14 08:29:28 thanks bluelightning Aug 14 08:29:43 I tried to use the guide from here https://www.yoctoproject.org/docs/2.4.1/bitbake-user-manual/bitbake-user-manual.html#exporting-variables-to-the-environment Aug 14 08:30:38 but it seems that if I run bitbake -e recipe B | grep variable from recipe A I get no output Aug 14 08:30:59 Alex___: you really cannot do that Aug 14 08:31:38 see above for the right way to do it Aug 14 08:33:17 ok, thank you for the tips :) Aug 14 09:45:18 New news from stackoverflow: Loading an out of tree module as builtin in Yocto Aug 14 10:09:37 RP: | /usr/src/debug/coreutils/6.9-r5/build/src/../../coreutils-6.9/src/su.c:248: undefined reference to `crypt' Aug 14 10:10:41 ah thats meta-gpl2 Aug 14 10:10:46 shall tweak Aug 14 10:13:19 rburton: right, I was ignoring that on the basis it should be a simple fix Aug 14 10:13:24 yeah Aug 14 10:13:34 kicked a build off to sort it out now Aug 14 10:14:09 rburton: -next on .io is going to be slow as glibc changed :( Aug 14 10:15:25 New news from stackoverflow: Execute bitbake recipe discarding what sstate_cache is Aug 14 10:16:27 opkg error messages are not easy to parse: "package foo requires bar, but none of the providers can be installed" Aug 14 10:17:36 OPKG_ARGS += "--verbosity=3" doesn't show the root cause either. Aug 14 12:05:19 RP: '[yocto] oe-run-native uses host python3 instead of sysroot' is a good point Aug 14 12:05:33 RP: should oe-run-native just sweep up all *-native/ folders in the sysroot? Aug 14 12:07:14 rburton: probably, yes Aug 14 12:07:30 took me a minute to understand what that meant :) Aug 14 12:14:33 RP: michael@yoctoproject still the right person to send ssh keys for poky-contrib? Aug 14 12:15:16 rburton: I hope to pick up where I left soon :) Aug 14 12:15:27 yes Aug 14 12:15:32 and woo Aug 14 12:15:53 just sent the key for my underpowered 4 core laptop, as the proper box is stuck in corporate order process Aug 14 12:16:02 kanavin__: yes, I saw the mail, cool :) Aug 14 12:19:57 RP: filed https://bugzilla.yoctoproject.org/show_bug.cgi?id=12889 Aug 14 12:19:58 Bug 12889: normal, Undecided, ---, richard.purdie, NEW , oe-run-native should automatically pick up bindir/*-native/ directories Aug 14 12:21:10 Hmm, build qemux86, then switch to genericx86 and it does a lot of workdir cleaning Aug 14 12:22:35 RP: smthg fishy here, bitbake is ignring changes to a recipe SRC_URI/patchset Aug 14 12:22:51 WARNING: pcmciautils-018-r1 do_patch: Aug 14 12:23:27 that one needs patch rebaqsing..just commenting out the SRC_URI and doing -c cleansstate seems not enough..doh Aug 14 12:25:33 even increasing PR? how that...checking Aug 14 12:26:35 I am going to experiment with -l option to make and ninja. Building llvm and webkit at the same time is a good test bench that can bring any machine to its knees. Aug 14 12:26:58 rburton: was that investigated previously, do you remember? Aug 14 12:27:26 not afaik Aug 14 12:28:24 all car makers seem to have enormous amounts of c++ code :) Aug 14 12:28:39 which is particularly slow and heavy to build Aug 14 12:32:41 kanavin__: another option is to use the jobserver support in make, if bitbake itself acts as the master and manages the number of make instances Aug 14 12:32:49 i *think* RP did a bit of poking at that a few years back Aug 14 12:35:08 rburton: this was just discussed on bitbake-devel :) this wouldn't cover ninja though Aug 14 12:37:51 RP: doh...we have two pcmciautils_0.18.bb, one in oe-core, one in meta-oe :) Aug 14 12:38:31 blame rburton ? Aug 14 13:03:44 huh Aug 14 13:03:53 kanavin__: ha i need to read that more obviously Aug 14 13:04:01 no, wouldn't cover anything but make Aug 14 13:04:10 kanavin__: I don't think anyone has played with -l. Trouble is one task could starve another :/ Aug 14 13:04:27 ant_home: did i send the addition to meta-oe and forget to post the removal? Aug 14 13:04:40 rburton: it would make bitbake, make and potentially our other threaded tasks have thread limiting Aug 14 13:05:49 I am trying to build a RPI image having read only rootfs. Build fails because busybox post installation fails (update-alternatives: Error: not linking build/tmp/work/raspberrypi3-poky-linux-gnueabi/core-image-lsb/1.0-r0/rootfs/sbin/klogd to /bin/busybox.nosuid since build/tmp/work/raspberrypi3-poky-linux-gnueabi/core-image-lsb/1.0-r0/rootfs/sbin/klogd exists and is not a link). Any tips how to start solving this? Aug 14 13:06:28 ant_home: yeah that sounds about right. posting removal now Aug 14 13:06:50 RP: make documentation seems to imply that it will keep running at least one target even when the load avg is above the set limit. I need to observe it in action though. Aug 14 13:07:35 kanavin__: yes, I don't think it can not run anything due to the way make works internally. The jobserver implementation is quite fascinating Aug 14 13:07:57 fascinating sounds like an interesting choice of word Aug 14 13:09:01 rburton: oldschool unix solutions to problems Aug 14 13:10:26 Jape_: klogd seems to be coming from a different package, and they clash Aug 14 13:11:11 rburton: basically you put tokens (single characters) into a pipe, then anything wanting to run something has to read a token which it puts back when done Aug 14 13:11:41 rburton: so no locking as single byte read/writes are atomic Aug 14 13:13:09 kanavin__, yes most likely. Any advice how to start figuring out where it comes from? :) Not familiar with yocto / bitbake. Aug 14 13:24:11 I have a small kernel driver in my build. When upgrading the kernel I get the message "Cannot use CONFIG_STACK_VALIDATION, please install libelf-dev, libelf-devel or elfutils-libelf-devel" This seems to be a new kernel upstream feature since 4.12. What do I need to add to my module recipe to get this resolved? I tried to look from the kernel recipe environment what it pulls in, but the only related I could spot was DEPENDS := "elfutils-native" but that Aug 14 13:24:11 didn't help Aug 14 13:26:54 Jape: probably sysklogd. this is weird though, as busybox does have RCONFLICTS in its recipe that should guard against it Aug 14 13:42:14 I see the same message in this discussion, but I cannot extract a solution https://patchwork.openembedded.org/patch/152442/ Aug 14 13:48:30 rburton: https://autobuilder.yocto.io/builders/nightly-oe-selftest/builds/1274/steps/Running%20oe-selftest/logs/stdio - the hash changes worry me :/ Aug 14 13:48:54 huh Aug 14 13:49:18 my checksum change? Aug 14 13:49:39 some other builds in the same run failed in a similar way Aug 14 13:50:14 eg https://autobuilder.yocto.io/builders/nightly-x32/builds/1198/steps/Running%20Sanity%20Tests/logs/stdio Aug 14 13:52:44 rburton: feels like there is a connection :/ Aug 14 13:53:15 rburton: the fact there were checksum changes in that build worries me more too Aug 14 13:55:00 revert the big change and see what happens? Aug 14 13:59:44 rburton: I just poked around https://autobuilder.yocto.io/builders/nightly-musl/builds/1230/steps/Running%20Sanity%20Tests/logs/stdio and it seemed to hang somewhere after enabling Uninative but before it enabled the server Aug 14 14:04:17 rburton: all on f26 Aug 14 14:05:50 rburton: there are bits of an oe-selftest left behind on that machine :/ Aug 14 14:14:08 halstead: have there been any issues with the f26 worker recently? Aug 14 14:16:09 RP: shouldn't we be ditching F26? upstream support for it ended in May Aug 14 14:17:39 RP, No issues that I'm aware of except that it is EOL and should be replaced with F28. Aug 14 14:18:25 opensuse423 had a hard lock up and needed a cold reboot though. Aug 14 14:19:09 bluelightning: quite likely Aug 14 14:19:32 halstead: ok, thanks. Last build run showed oddities on all its builds :/ Aug 14 14:21:29 RP, Shall I go ahead and do that upgrade to F26? It's been on the TODO list for awhile. Aug 14 14:21:59 halstead: might as well. I can't find anything useful to try and figure out what went wrong :( Aug 14 14:23:18 rburton, ok, thanks, but note the recipes are not in sync Aug 14 14:39:24 rburton, I have sent the two bakport patches to oe-dev ML Aug 14 15:36:38 JPEW: we're seeing odd issues getting bitbake to start. Can't tell if its the persist_data changes, rburton's md5 mmap or something else Aug 14 15:37:08 RP: Hmm, whats the issue? Aug 14 15:38:30 Ah, the links in the chat log I'm assuming. Aug 14 15:41:35 JPEW: things like this: https://autobuilder.yocto.io/builders/nightly-mips-lsb/builds/1199 Aug 14 15:41:45 JPEW: just randomly failing to start the server Aug 14 15:41:58 nothing useful in logs that I could fine Aug 14 15:42:00 find Aug 14 15:42:30 I'm going to rebuild -next with just the core changes and not the bitbake ones, see if this keeps happening Aug 14 15:43:14 RP: Ya... I did have some bugs that exhibited that failure behavior when I was working on the patches. It's very possible the persist_data is causing that. Aug 14 15:44:00 JPEW: the complexity of the persist_data stuff and the fork handling does worry me :/ Aug 14 15:45:17 Indeed, I wasn't sure about that. Aug 14 15:53:52 WARNING: glibc-locale-2.28-r0 do_package_qa: QA Issue: glibc-locale: /glibc-binary-localedata-es-ni/usr/lib/locale/es_NI/LC_NUMERIC is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated] Aug 14 15:53:57 argh i was hoping we had that fixed Aug 14 15:55:51 rburton: I know a patch claimed to and could probably help but I was never convinced Aug 14 15:56:08 halstead: typhoon looks to have a disk space issue? :( Aug 14 15:57:37 RP, On which worker? Aug 14 15:57:45 centosy-ty-1 I suppose. Aug 14 15:58:27 halstead: yes Aug 14 16:04:47 Kergoth: When I try to use ${systemd_system_unitdir} I get an error that says ...../image/lib/systemd/system': No such file or directory. I'm trying to move from sysvinit to systemd Aug 14 16:12:01 RP: the musl failure you are seeing is real, I can reproduce it, but its a pre-exiting problem in mesa that was earlier ignored by loader see https://github.com/kraj/musl/commit/5c2f46a214fceeee3c3e41700c51415e0a4f1acd Aug 14 16:23:30 khem: so what do we do about it? :/ Aug 14 16:23:52 armpit: I think your rocko build fell victim to the space issue Aug 14 16:27:30 RP, that is why we need a Space force for just such issues Aug 14 16:28:21 armpit: :D Aug 14 16:28:30 here mesa needs to switch to general-dynamic TLS model for proper fix, what I see is that library still loads and sato comes up fine on qemux86 so may be we can ignore the error for now Aug 14 16:28:31 * armpit will launch another one later Aug 14 16:28:38 * armpit off to SJ Aug 14 16:28:58 the mesa ticket is reopened so hopefully this will track the problem Aug 14 16:35:36 khem: I guess we could whitelist it for musl, I'm very nervous about doing that though :/ Aug 14 16:36:33 does anyone know why in my private recipe that it doesn't recognize ${systemd_system_unitdir}? In order to get it to recognize it i had to make the lib/systemd/system directories first Aug 14 16:41:15 RP: yes although I hope to chase the issue with mesa guys Aug 14 16:41:32 which means we will get to fix it properly. Aug 14 16:42:57 khem: right, fixing it with them sounds good Aug 14 16:43:35 khem: still chasing down locale issues. I messed up the first version of that locale patch and was corrupting memory :( Aug 14 16:46:22 RP: your approach is good though, Aug 14 16:47:30 khem: hopefully. Cuts locales from 900MB to 220MB :) Aug 14 16:50:02 hmm, sstate isn't preserving sparse files :( Aug 14 16:50:30 * kanavin__ hopes to get into ELC-E at last Aug 14 16:50:35 I guess its good that selftest is finding this Aug 14 16:50:47 kanavin__: should be a few of us! :) Aug 14 16:50:47 just asked if that can be arranged... Aug 14 16:51:02 kanavin__: remember OEDEM the day before the conference Aug 14 16:51:13 RP: yes, I specifically mentioned that Aug 14 16:51:14 devday is the day after Aug 14 16:51:36 * RP suspects you'd know much of the devday material :) Aug 14 16:52:00 "So this is the once a year chance to meet people I work with in the open source community, learn and discuss with them. I wouldn't want to miss it. I can also distribute marketing materials for Pelux, if we have any: business cards, leaflets etc." Aug 14 16:52:04 from the email :) Aug 14 16:52:42 RP: but isn't devday only for an extra fee :D can I get in for free? ;) Aug 14 17:25:32 * RP just found sstate destroys file sparseness :( Aug 14 17:35:15 zeddii_home: guess you're back? :) Aug 14 17:42:18 JPEW: FWIW with your persist_data pieces and rburton's change removed, -next is looking much happier. I guess I'll add the mmap stuff back and retest that next Aug 14 17:43:03 RP: Ok. FWIW, I tried a build locally with the persist_data and it worked alright, but I agree it is still the most likely culprit. Aug 14 17:43:26 JPEW: its intermittent which is always annoying to track down Aug 14 17:43:56 Do you think it might have something to do with the database schema chaning states (and WAL mode)? Aug 14 17:44:05 JPEW: want to get some patches unblocked, then I can add it back alone and retest and see if it comes back Aug 14 17:44:47 JPEW: I'm not really sure. I did try testing this without the bb.fork piece and I don't think we were seeing it until I added that Aug 14 17:45:01 We've a lot of failures so I'm not 100% sure Aug 14 17:45:09 and the test suite fails without bb.fork Aug 14 17:45:34 Ya, thats fine. The persist_data changes are really only needed for hash equivalence, so there isn't an immediate need. Aug 14 17:46:06 I should probably split the patches so that the fork test is added with fork support Aug 14 17:46:43 Other than that one, all the tests should actually run and pass without any of my other persist_data changes Aug 14 17:46:45 JPEW: right, I was just trying to get a bit ahead and get some of it reviewed/tested :) Aug 14 17:47:28 halstead: Interestingly, we just ran nearly a complete build run on yocto.io in under two hours with hot sstate :) Aug 14 17:48:24 its not finished but its nearly there apart from qa-extras which we'll have to break up Aug 14 18:27:08 RP: sent a fix for mesa issue on musl here http://lists.openembedded.org/pipermail/openembedded-core/2018-August/154125.html Aug 14 19:10:35 rburton: yt ? Aug 14 19:38:42 does anyone know how to tell yocto to autostart services created by systemd-sysv-generator? Aug 14 19:47:53 anyone here? Aug 14 20:46:55 does anyone know how to accomplish this shell command "systemctl enable programexample.service" in a .bb file? Aug 14 20:55:46 pabdaddy1995: Have you tried using the systemd class? https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#ref-classes-systemd Aug 14 21:48:28 khem: looks good, thanks. Will try and add that to the next round of patches once we get glibc in Aug 14 21:55:39 JPEW: builds aren't breaking like they were so I think it is something about the persist_data changes :/ Aug 14 21:56:03 RP: OK. Thats unfortunate, but not really suprising Aug 14 21:56:51 I'll go try torturing it a little more Aug 14 22:00:03 JPEW: thanks. Sorry to be the bearer of bad news :) Aug 14 22:00:23 JPEW: I'm kind of drowning in one problem leading to another right now Aug 14 22:00:37 RP: Better now than later. Aug 14 22:01:28 RP: I really need to look at CROPS or something to test builds on older distros. My preference to run the latest FC gets me into trouble some times Aug 14 22:01:56 JPEW: we all get caught out now and again... Aug 14 22:02:14 JPEW: the testing cluster is good for finding at least the basic issues Aug 14 22:17:00 RP: to answer your earlier question, I am back. I’m working to send a queue out shortly with the new libc-headers, 4.18 kernel, old kernel deletions and the re-worked devsrc. I have to get my builder to run some combos before it’ll be ready. but the work is mostly done. Aug 14 22:18:38 zeddii_home: I've been longing for the devsrc patch as we have image space issues and this should ease them. Ended up having to do other things as you were still away though... Aug 14 22:18:51 zeddii_home: welcome back :) Aug 14 22:18:54 I can send just that one tomorrow morning. Aug 14 22:19:17 the 4.18 part of the work requires multiple arches, c libraries, etc, etc. so I won’t pend it on that. Aug 14 22:19:17 zeddii_home: would certainly be good to retest and see where we are with it Aug 14 22:19:41 I think it is close. but I couldn’t fully test mips, but I fixed the error by inspection. Aug 14 22:20:03 so I expect nothing major, but won’t bet on no errors :D Aug 14 22:20:22 root@qemuarm:~# uname -a Aug 14 22:20:22 Linux qemuarm 4.18.0-yocto-standard #1 PREEMPT Tue Aug 14 21:04:18 UTC 2018 armv5tejl GNU/Linux Aug 14 22:20:25 w00t. Aug 14 22:20:32 onto mips for 4.18 Aug 14 22:41:13 zeddii_home: I've forgotten what green builds look like :( Aug 14 22:41:25 https://autobuilder.yocto.io/builders/nightly-oe-selftest/builds/1278/steps/Running%20oe-selftest/logs/stdio - sparse files still not working on the autobuilder :( **** ENDING LOGGING AT Wed Aug 15 02:59:59 2018