09:36 <adrianalin> if I am using a Yocto SDK, would it be a requirement for the SDK libc to match the host libc?

09:37 <adrianalin> *hello

09:43 <RP> mcfrisk: can you reproduce it?

09:44 <RP> adrianalin: no, we just require the host libc isn't newer

09:50 <mcfrisk> RP: not really, but it's now second time that qemu boot fails due to this. wiping tmp cured it once. rebuild and it's back. trying to debug. in workdir cpio_append/init seems to be a zero size file...

10:38 <yocton> Do we support local.conf without newline at EOF?

10:41 <yocton> I ask because the reproducibility test fails without a newline at EOF. I guess we should fix the reproducibility test...

10:44 <RP> yocton: I think something somewhere doesn't add a line without a newline

10:45 <RP> yocton: i.e. two lines end up merged together

10:45 <RP> yocton: I've seen it before but never dug into the root cause

10:45 <yocton> yes, I get something like OEQA_REPRODUCIBLE_TEST_TARGET = "bash"SSTATE_DIR ?= "/home/yocon/yocto/sstate-cache"

10:46 <yocton> I'll open a bug, this should make a nice newcomer bug :)

10:46 <RP> yocton: maybe. The question is should appending lines add a newline before, after, or both?

10:49 <yocton> RP: I'd say : start by appending a newline (to ensure you're really at a start of a line), then, end every lines you add with a newline. As a side effect, this will put a newline at EOF

10:49 <RP> yocton: it could lead to lots of double spaced variables

10:50 <RP> this is why it could be a bit harder than newcommer :/

10:50 <yocton> Ok, not newcomer then, but a bug nonetheless

10:51 <RP> definitely a bug

10:51 <yocton> I'll create it

10:53 <mcfrisk> RP: rm_work I presume. something retriggers do_image and wants rootfs but that has already been wiped by rm_work. bitbake-diffsigs output in https://pastebin.com/raw/FHTpPKnz is odd since neither meta-xilinx nor meta-freescale are enabled in the build. I do shared sstate with builds which enable those layers though.

10:54 <RP> mcfrisk: ah, rm_work. That could make an interesting mess

10:56 <RP> mcfrisk: those two .py files changing checksum is odd, that suggests you updated the metadata?

11:07 <mcfrisk> RP: the .py files were changed Jan 14th. something else is odd and retriggering image rebuilds, which then sometimes end up with rm_work racing do_image tasks which end up with empty rootfs directory. it is hard to understand what is going on. I don't think bitbake-diffsigs output is really correct

11:11 <RP> mcfrisk: I suspect it might be looking at the last change it could find

11:12 <RP> mcfrisk: in WORKDIR/temp the task_order file may give hints about the actual ordering

11:22 <mcfrisk> RP: build logs show meta-arm side gen-sbkeys with do_install[nostamp] = "1" is always executed first. that triggers spdx etc tasks elsewhere for the initramfs and rootfs. I think that is the root cause. handling random secrets in builds is tricky...

11:24 <RP> mcfrisk: yes, that could do it :/

11:24 <RP> mcfrisk: although tasks should rebuild safely so there is a bug in there somewhere

11:26 <mcfrisk> I think rm_work should not remove rootfs because different image formats may depend on it, like wic and the initrd cpio. They don't fail if rootfs directory is empty, since that is a valid usecase too

11:27 <RP> mcfrisk: in rm_work.bbclass there are a load of task masks, I suspect some task is missing from the list

11:28 <RP> mcfrisk: basically once it runs, it should re-trigger everything to rebuild and it isn't

11:29 <RP> mcfrisk: rm_work basically promotes tasks to pretend they came from sstate