**** BEGIN LOGGING AT Thu May 13 02:59:56 2021 May 13 03:08:43 alex88: yes, we're hoping to have everything available afterwards May 13 04:02:59 i'm getting wrapped around the axle: does the mere presence of a linux-yocto_5.8.bbappend in my custom layer invoke the basic yocto linux 5.8 mechanism? May 13 07:48:52 tlwoerner, thanks! May 13 07:51:11 tlwoerner: \o/ May 13 09:07:30 * RP wonders why the memory errors on ubuntu1804-ty-1 May 13 09:07:41 OOM, not EEC May 13 09:10:49 hmm, it has a broken qemumips64 glibc build still with active qemu processes May 13 09:11:08 "tst-mallocfork2-mcheck" May 13 09:11:23 RP: there was a number of hanging ltp builds last night btw, some several days old May 13 09:28:05 I don't remember, does exist a guideline fot usage of ${COREBASE}/LICENSE in LIC_FILES_CHKSUM? May 13 09:28:16 /fot/for May 13 10:36:42 I meant something like this I've just created as reference ;-) May 13 10:36:44 https://wiki.koansoftware.com/index.php/Yocto_Project_licenses_for_LIC_FILES_CHKSUM May 13 10:45:55 comments, suggestions are welcome May 13 11:04:04 kanavin: did you cancel them? I don't see them now so perhaps they timed out May 13 11:16:22 RP: I did not, I'm reluctant to meddle in other people's builds :) May 13 11:16:57 RP: and they are still running https://autobuilder.yoctoproject.org/typhoon/#/ May 13 11:17:17 Hi, I have simply supressed a few lines in a recip which was creating files and folders, now the recipe compiles fine and the build/blah/blah/reblah/1.0_r0/ dicrectopry no longer contains these folders and files and nor do yje generated rpm and such, however the resulting fsl-image-gui still contains them probably from a previous build, do I have May 13 11:17:17 no choice but to rebuild everything? May 13 11:22:08 kanavin: hmm, they don't show on https://autobuilder.yoctoproject.org/typhoon/#/workers which is confusing May 13 11:30:00 rburton: any interest in poking a hung qemuarm64 ltp build? May 13 11:30:49 today is most likely not the day, i'm flaking May 13 11:32:26 rburton: ok, np May 13 11:55:44 zeddii: did you skip recipes-devtools/go/go-systemd_git.bb branch fix in gatesgarth branch intentionally or just forgot to push this one (as it was fixed very far into the history till thud) May 13 12:59:19 i'm getting wrapped around the axle: does the mere presence of a linux-yocto_5.8.bbappend in my custom layer invoke the basic yocto linux 5.8 mechanism? May 13 13:06:48 no May 13 13:08:27 rburton: so what determines the linux/kernel version? May 13 13:10:10 the usual: preferred version, preferred provider, etc May 13 13:10:18 the kernel is just another recipe May 13 13:32:54 JaMa: a mistake. I'll cherry pick it to that. May 13 13:33:56 JaMa: even dumber. I put it there, but didn't push the branch May 13 13:36:22 rburton: i have this in my include file for my machine. does this cause my layers linux-yocto_5.8.bbappend to be utilized then? PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto" May 13 13:36:52 wel, yes May 13 13:37:14 if your layer is active then any bbappends will always be applied May 13 13:37:24 and that preferred provider selects linux-yocto May 13 13:37:52 ok. how does a layer become "active"? May 13 13:38:10 you put it in bblayers.conf May 13 13:38:23 ah, ok right. as it is. May 13 13:53:03 what are the choices for PREFERRED_PROVIDER_virtual/kernel, besides "linux-yocto"? May 13 13:53:41 what determines these choices? May 13 13:54:15 zeddii: this may be a question for you. ? May 13 13:55:10 yates: the choice is any recipe which PROVIDES virtual/kernel May 13 13:55:22 it is unfortunately sort of the same as what rburton said. It's just a recipe, with providers. So you'd need to have a different layer with a different kernel recipe in it to be able to select it. May 13 13:57:58 yates: you may also want to set PREFERRED_VERSION_linux-yocto = "5.8" May 13 14:22:03 ok thanks RP/zedi May 13 14:22:14 ok thanks RP, zeddii May 13 14:22:46 and rburton May 13 14:28:20 RP: i have a 'LINUX_VERSION = "5.8.13"' in my custom layer's ./recipes-kernel/linux/linux-yocto_5.8.bbappend file. is that equivalent to using the PREFERRED_VERSION_linux-yocto = "5.8.13"? May 13 14:37:17 That's just a variable used in the PV of the linux recipes. not the same thing. May 13 14:37:46 people really need to move on from expecting bitbake to start mucking around and looking for upstream branches on their behalf. May 13 14:37:54 :D May 13 14:39:32 We probably should have never allowed non specified branches, but that is a lesson learned over time. I remember when dangling head and random specified SRCREVs were more common. It can work, but it isn't a great idea. May 13 14:40:10 zeddii: Raise a warning if a git:// SRC_URI is missing branch= ? May 13 14:40:40 not a bad idea. would help get everything migrated. May 13 14:41:08 But ultimately, I suspect the bigger problem is the upstreams that are.... zealously... deleting the "master" branch without realizing the consequences May 13 14:41:31 I find it odd that anyone would really object to specifying that. You've specified the repo and an exact git hash. The branch is just another minor detail. May 13 14:41:44 JPEW: agreed. May 13 14:42:07 but we can take it as an opportunity to improve and make the meta-data more specific and readable. May 13 14:42:12 Right May 13 14:42:50 i.e. if you've picked a SRCREV that is on a branch called "devel", someone reading the recipe could see that more clearly with branch=devel than something like nobranh=1 May 13 14:43:30 which is why I abandoned my first thought of using nobranch on the meta-virt recipes that blew up, and just merged the branch specified change back through all the branches. May 13 14:43:46 s/branches./releases/ May 13 14:53:42 RP: I'm working with a BSP that builds a bunch of stuff against extra headers in their vendor kernel and building from sstate has poor reuse due to dependencies on virtual/kernel:do_shared_workdir, is there anything that can be done beyond major surgery to split out the headers? May 13 14:59:06 smurray: We have the same problem; we basically end up patching the required headers into the individial recipes May 13 15:00:41 JPEW: I suspect I won't have a lot of luck with that with this vendor, sadly May 13 15:03:39 Oh, we don't upstream it with the vendor, just a lot of bbappends unfortunately :( May 13 15:04:41 bummer May 13 15:06:36 I'm kind of wondering if something like kernel-devsrc could be (ab)used. I'm thinking it'd get triggered to rebuild since it'd have to depend on do_shared_workdir, but then it'd end up with the same contents and hash equiv could maybe kick in... May 13 15:07:24 would need a hosted hash equiv server, I'm guessing May 13 15:23:40 smurray: the kernel shared_workdir is *huge* and its about as fast to extract the kernel sources again as it is to pull and extract any sstate object representing that May 13 15:24:07 smurray: I know shared_workdir had a ton of feature creep as it was meant to be the sources and now has compiles modules in it :( May 13 15:24:22 smurray: no easy answers on that :/ May 13 15:25:09 smurray: we could add a an sstate task which could restore a copy of that workdir May 13 15:25:27 RP: the problem for the folks with this BSP is they don't get a lot of benefit from sharing sstate, too much rebuilds May 13 15:25:30 smurray: I'm betting it would get loads of complaints though as it did in the past when we did this differently May 13 15:25:52 smurray: next it will be that sstate is too large/slow and why is all this stuff there May 13 15:26:00 RP: yeah May 13 15:29:59 RP: any pointers if I want to tinker to try making do_shared_workdir setscene-able to see how bad it ends up? Just over-ride the stub in kernel.bbclass? May 13 15:32:13 smurray. would it be possible to have a custom package of the headers and have just that install into their recipe's sysroot ? May 13 15:32:37 are they uapi headers ? or just "internal" .h ones. May 13 15:33:26 zeddii: yeah, I was toying with that idea (my mention of abusing kernel-devsrc above). I'll need to dig through all their stuff to see what all it is they're digging into. Some of it is definitely not under uapi (where it probably should be) May 13 15:34:19 I have my WIP patches that do some of that, but I feel like I'm not quite understanding the paint point (I'm a bit slow). May 13 15:34:33 lol, paint point May 13 15:34:46 that's the governemnt of ontario's suggested activity! May 13 15:34:50 watching paint dry. May 13 15:34:53 NO FUN FOR YOU. May 13 15:35:00 haha May 13 15:35:07 PEOPLE ARE DYING AT THE TENNIS COURTS May 13 15:35:22 the golf courses where littered with destruction. May 13 15:35:26 s/where/were/ May 13 15:35:32 :D May 13 15:35:51 zeddii: so they point into the shared workdir which has no setscene attached. If you do a rebuild purely from sstate, the stuff depending on virtual/kernel:do_shared_workdir all gets rebuilt... May 13 15:35:53 smurray, so the goal is to skip the extract of the entire kernel source into the shared workdir to get the headers, right ? May 13 15:36:03 aha. May 13 15:36:21 zeddii: the goal is to not rebuild three quarters of their stuff for every dev ;) May 13 15:36:53 so you want something re-installed there (shared workdir) or into the recipe, without needing to re-establish the shared-workdir and dependcies May 13 15:38:06 zeddii: heh, whatever makes it such that the dependencies don't get rebuilt ;) May 13 15:38:40 I'd say probably the recipe one :D May 13 15:38:43 zeddii: I'll propose untangling their kernel headers, but I'm pretty sure they know already it's a problem and there's not a quick path to moving them May 13 15:39:12 I think that's where I was heading, in my badly understood comment. May 13 15:39:20 kind of like how libc-headers is "curated" May 13 15:39:41 I suspect it's a non-starter for them in any practical sense, sadly May 13 15:40:01 hence my question here ;) May 13 15:40:21 do they change often ? May 13 15:41:13 I'd need to dig to see how frequently, but I suspect there's some of that, big issue is how many teams would need to be involved, I suspect May 13 15:41:40 it's not going to be an entirely technical issue ;) May 13 15:42:19 I'll do some experiments and see if perhaps I can improve things for some of their recipes May 13 15:43:09 yah. cherry-picking the headers into a package and just having them depend on that is one way out of the mess, but like you said, having that recipe NOT depend on the kernel source is key, otherwise, you are back to the same situation. May 13 15:44:12 right, though I'm thinking maybe there's a chance that hash equiv might then firewall it a bit with that approach May 13 15:44:35 i.e. you'd regen that header package, it'd end up the same, other dependencies all short-circuit May 13 15:44:45 might be wishful thinking on my part May 13 15:44:56 true and maybe :D May 13 15:51:50 RP, JPEW, and zeddi: thanks for the input! May 13 16:35:36 smurray: don't override that stub, add a new recipe/task which creates a copy and installs it somewhere May 13 16:35:57 smurray: you can then just depend on the new recipe May 13 16:39:32 RP, vmesons: I cannot seem to find the mailing list thread that discusses that jitter entropy change :/ May 13 16:41:51 JPEW: sorry, the thread/patch is rng-tools: disable the CPU affinity mask May 13 16:41:59 RP: okay May 13 16:42:12 JPEW: I think the direction changed but is related to that bg May 13 16:44:10 Got it May 13 17:23:19 rburton: the qemu person you spoke with said that on a heavily loaded system… May 13 17:23:40 * tlwoerner didn't record the last half of that sentence for the notes May 13 17:24:36 maybe something to do with rcu stalls? May 13 17:26:05 tlwoerner: you'd expect some level of rcu stalls May 13 17:27:12 RP: thanks May 13 17:27:36 khem: did you mean to start two meta-oe builds? May 13 17:28:02 sgw1: around? We now have four hanging ltp builds, one arm and three x86. I was wondering if you'd documented how to query them? May 13 17:28:13 no cancel old one May 13 17:28:16 I thought I did May 13 17:28:40 khem: done May 13 17:35:07 RP: sort of around, the quick check is to login and connect to the qmp port, I have used qmp-shell by running it from the QEMU source directory to get the correct qemu.py May 13 17:43:49 RP: I can do a quick check if you can point me at one of the failures May 13 17:52:55 sgw1: you can see the builds on https://autobuilder.yoctoproject.org/typhoon/#/builders/95 May 13 17:53:28 ( https://autobuilder.yoctoproject.org/typhoon/#/builders/96 shows the arm one) May 13 18:07:57 kanavin: are you rerunning the whole thing to check which were intermittent issues? it is a heavy build to rerun just for a handful of failures :/ May 13 18:09:22 RP: seems qemu is hung hard, no access to QMP May 13 18:10:42 sgw1: which one did you look at? May 13 18:10:46 I put a tarball in /tmp/qsh.tar on centos7-ty-4 May 13 18:11:00 sgw1: definitely useful to know that is the case... May 13 18:11:06 and usage was: cd scripts/qmp/ May 13 18:11:06 [pokybuild@centos7-ty-4 qmp]$ ./qmp-shell -p /home/pokybuild/yocto-worker/qemux86-64-ltp/build/build/tmp/.s9fqrjp5 May 13 18:11:49 It just hangs, normally we could get a (QEMU) prompt May 13 18:12:07 sgw1: can multiple clients connect at once? May 13 18:13:07 Hmm, had not thought of that, meaning the qemurunner client is attached. May 13 18:13:27 sgw1: right. I don't know if it applies or not May 13 18:13:54 Then more investigation is needed, I will check it out locally. May 13 18:14:29 sgw1: thanks. I'll grab some food and come back to it. Having the info is really useful though May 13 18:15:13 hi all -- Can VOLATILE_LOG_DIR = "no" be set in an image recipe? May 13 18:20:54 RP: enjoy your dinner, your right only the first connection is active, so my hard hang comment is wrong. I need to figure out where we can active the queies other than when the ssh fails May 13 18:25:40 I usually use the _raspberrypi4 suffix to set variables for the raspberry but I saw that also _rpi is used, the first one works because of the machine name I suppose, how is the second declared/implemented? May 13 18:47:52 v2d: no, it's a global used when building a few recipes, defining it in an image recipe will have no effect May 13 18:50:34 alex88: meta-raspberrypi sets SOC_FAMILY = "rpi", there's logic in meta/conf/machine/include/soc-family.inc in oe-core/poky that adds that to MACHINEOVERRIDES (and this to OVERRIDES) May 13 18:52:53 smurray, oh ok got it, Thank you for explaining! May 13 19:29:18 smurray: thanks! May 13 20:06:43 RP: I was expecting most of it would complete quickly from sstate May 13 20:11:21 RP: and much of the rest would spend time in qemu, e.g. not very heavy May 13 20:22:10 kanavin: things like the reproducibility tests run 50% from scratch at best :/ Please try to avoid doing that as it isn't that quick May 13 20:22:25 kanavin: a-quick is nicer in that regard btw May 13 20:23:14 RP: right, I admit clicking rebuild is temptingly easy and I did that as I was about to fall asleep :) May 13 20:23:38 RP: there was just one issue that I need to look into, and that could've been restarted individually May 13 20:34:11 a new low for me. May 13 20:34:28 kanavin: really just a note for in future... I was going to run a build but didn't as yours was taking most workers at the time May 13 20:34:32 * zeddii was just explained now a developer works on a git repo. May 13 20:35:21 RP: yes, of course. Most of it is already complete, I can cancel the rest, or just let it runs its course. May 13 20:49:18 kanavin: can let it run now, it was just for future May 13 20:49:35 zeddii: you've used git?! May 13 20:58:37 RP: I'm more of a CVS fan, *maybe* SVN May 13 21:12:39 zeddii: not monotone? :) May 13 21:15:46 Psh. Who uses VCS to begin with? Just copy the files around May 13 21:37:53 JPEW: at least with cp -b ? or is that too crazy! ;) May 13 21:40:12 how do i build without GPL-3.0? May 13 21:40:36 i added meta-gplv2 but some recipe i have complains about autoconf.. May 13 21:40:47 Nothing PROVIDES 'autoconf' .. autoconf was skipped: it has incompatible license(s): GPL-3.0 May 13 21:43:58 ah. lol. recipe was broken May 13 21:58:46 JPEW: sounds like trying to find out about code changes between gnu tar releases where the files come from a different module not covered by the source control May 13 22:36:16 I'm trying to patch a recipe file, I've followed https://wiki.yoctoproject.org/wiki/TipsAndTricks/Patching_the_source_for_a_recipe but that replaces the whole file instead of creating a patch file May 13 22:37:20 I'm trying to patch http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-core/dropbear/dropbear/dropbearkey.service and I've tried to use a|b/oe-local-files/dropbearkey.service as the path because in the workspace/sources directory that's where the files were however it's complaining that it doesn't find the file to patch May 13 22:37:56 I've also tried with a|b/dropbear/dropbearkey.service (so trying to use the recipe path), no luck May 13 22:38:42 alex88: You can't patch that file with a .patch file because it's not part of the upstream source May 13 22:39:02 oh it's because it's just part of the actual recipe May 13 22:39:10 alex88: right May 13 22:39:24 so patches are just for the real source, got it, so the only way is to go with the replacement May 13 22:39:28 thank you JPEW! May 13 22:39:33 alex88: yep May 13 22:39:59 then the devtool steps makes it easy enough :) May 13 22:40:06 alex88: Since it is a systemd service, you can also provide a serivce drop file to modify the behavior May 13 22:40:19 Which allows you to keep the oe-core service file intact May 13 22:41:10 alex88: Either way, I would recommend using a bbappend of the recipe in your own layer to make changes to it May 13 22:41:24 oh right, that would be eve better for updates to keep as much as possible as the original one, as I only want to change an env variable May 13 22:41:42 JPEW, yeah bitbake update-recipe creates the bbappend in our own layer May 13 22:42:51 Ya, so if you make a file: ${systemd_unitdir}/systemd/dropbear.service.d/my-custom-stuff.conf you should be able to change the environment in there May 13 22:43:42 Ah, it's a templated service (dropbear@.service) I'm not sure how that works with drop file, but you can probably figure it out :) May 13 22:46:12 that's probably the easy part :) thank you again May 13 22:46:26 btw yeah seems possible the same way as with a regular service https://unix.stackexchange.com/a/528466/36599 May 13 23:00:53 sgw1: still around? I have a qmp shell to one of these May 13 23:02:58 sgw1: basically you have to find the python process with the other end of the socket open, connect with gdb and call shutdown(,2) on the socket and then you can connect elsewhere May 13 23:03:20 * RP took out two of the instances before getting it right May 13 23:07:16 RP: here, so you could connect to the QEMU shell? what's the query-status report? May 13 23:09:45 sgw1: "return": { "running": true, "singlestep": false, "status": "running" } May 13 23:10:02 sgw1: I would also note that I can ssh into the qemu instance so it is definitely alive May 13 23:10:12 sgw1: I'm in this one: https://autobuilder.yoctoproject.org/typhoon/#/builders/95/builds/1889 May 13 23:11:16 So if you can ssh into the target, can you see why it's hung? IO issue or something else? May 13 23:11:33 sgw1: hanging ltp test. I think the loss of the qmp connection is about to kill things May 13 23:12:11 sgw1: if you ssh root@192.168.7.2 on that machine it is still there atm May 13 23:12:40 hanging LTP in master vs 3.3, so something upgraded May 13 23:13:03 sgw1: we've been seeing this intermittently for ages :( May 13 23:14:42 sgw1: The build is still running, it was another I watched exit May 13 23:18:09 RP seems the qemu process is gone from ubt2004 May 13 23:19:38 sgw1: yes, I'm on debian10-ty-2 May 13 23:19:56 sgw1: I broke the running images on centos and ubuntu2004 :/ May 13 23:20:38 sgw1: I think it has run in the cpuset_regression_test May 13 23:20:42 s/run/hung/ May 13 23:24:17 Ok so that's still alive for sure, seems to be waiting for a test to complete (yes stating the obvious) May 13 23:27:19 sgw1: I'm trying to write down what I can in an email I'll send to the swat list May 13 23:27:36 abelloni: do you have anyone skilled at reading ltp hangs inside vms? May 13 23:37:43 sgw1: confirmed the arm ltp isn't hanging either, debug data sent to swat list May 13 23:43:24 sgw1: looks like qemu died? :/ May 13 23:43:50 RP: dang, did it time out? May 13 23:44:08 I saw the email so you captured some data May 13 23:48:46 sgw1: I don't know what happened, possibly May 13 23:49:51 sgw1: I think it may have been cgroup_xattr in the D state causing problems May 13 23:50:17 sgw1: but just the data I grabbed to go on now May 14 00:06:19 so the dropin works, however the default file in /etc/default/dropbear changes the env variable set in the systemd unit, I see that the default file has this line added to it https://github.com/openembedded/openembedded-core/blob/master/meta/classes/rootfs-postcommands.bbclass#L121 May 14 00:06:47 what's the "right" way of customizing that? adding my own hook to the bbappend of dropbear to revert that config? May 14 01:12:06 so I've added a custom class to our layer and inherited in our image, not sure it's the best way, maybe would've been better to have that in the recipe? but afaik the postprocess command can only be used in an image recipe right? **** ENDING LOGGING AT Fri May 14 02:59:56 2021