**** BEGIN LOGGING AT Thu Apr 07 02:59:57 2022
Apr 07 08:44:13 <mort> ok now I understand nothing, I have a recipe called evctl, if I change the do_compile step then run `bitbake evctl | cat` (to keep the output on screen), I see that bitbake runs do_populate_sysroot_setscene, do_package_write_ipk_setscene, then do_packagedata_setscene
Apr 07 08:44:20 <mort> wtf why isn't it re-running do_compile at least
Apr 07 09:09:36 <mort> running `bitbake -c clean evctl` runs do_clean, then `bitbake evctl` runs... absolutely nothing
Apr 07 09:09:39 <mort> what the hell
Apr 07 09:11:40 <mort> eh maybe that in itself makes sense if evctl's binary is already in the sysroot
Apr 07 09:21:20 <JaMa> -c cleansstate
Apr 07 09:40:59 <mort> JaMa: but when I change the do_compile function it should re-run, no?
Apr 07 09:44:11 <JaMa> yes if you haven't built the same signature before
Apr 07 09:47:59 <mort> so bitbake keeps around a build for every single .bb file hash?
Apr 07 09:49:09 <mort> every recursive hash even, hash of both the .bb file itself and all its dependents
Apr 07 09:50:10 <JaMa> not for every task, but yes, see the evctl archives in sstate-cache directory, it's quite likely you have quite a few
Apr 07 09:53:05 <mort> this could explain how something like a recipe which was at some point problematic but was since fixed (such as a recipe with a broken do_clean) can end up causing issues for a long time
Apr 07 09:53:18 <mort> I didn't realize it cached old versions of everything
Apr 07 10:11:02 <dvorkindmitry> why do I have "host contamination" problem? https://pastebin.com/nWWdYY7R
Apr 07 10:13:53 <JaMa> dvorkindmitry: wrong owner of files in package yes, not caused by host contamination (but it does influence if you see the error or not)
Apr 07 10:33:25 <rburton> mort: the clue to your problem was that it was populate-sysroot-setscene, which is pulling a sysroot from the sstate as it’s already been built instead of rebuilding from scratch. Setscene tasks are from sstate.
Apr 07 20:09:52 <stefan-schmidt> khem: About the build failures for the openthread recipes. I took some time today to give this testing on more permutations (poky as well as yoe with various profiles) I *hope* I found and fixed all problems autobuilder has with it now, but you never know :-)
Apr 07 20:10:04 <dvorkindmitry> pulled latest "dunfell" branch and got strange "m4-native" recipe build error: https://pastebin.com/jTcSTQK3
Apr 07 20:10:34 <stefan-schmidt> khem: If the v3 patchset still breaks on the autobuilder I need to find a way to set it up locally and test against it when I am back from vacation. Just as a heads up.
Apr 07 21:12:33 <paulg> saw a move to gcc 12 snap mentioned in an e-mail.
Apr 07 21:12:44 <paulg> folks might want to follow https://lore.kernel.org/linux-arm-kernel/20220401164406.61583-1-jeremy.linton@arm.com/T/#u
Apr 07 23:19:42 <khem> stefan-schmidt: sure I have bunch of combinations that I test along with clang and musl and mips and riscv etc
Apr 07 23:20:00 <khem> So it’s likely to find more issues than someone’s own setup
**** ENDING LOGGING AT Fri Apr 08 02:59:56 2022