01:54 <khem> it would be cool to have buildtools tarballs for all build host deps included, might speed up incremental builds

01:54 <khem> sometimes I change a patch for a package like zlib trying to build a ptest and it rebuilts zlib-native and I am in for rebuilding whole world

01:55 <khem> ofcourse I know way around it, but its not intutive

02:06 <JaMa> khem: are you using hashserv? that should stop zlib-native causing rebuilds for everything when the ptest change for target zlib doesn't affect the build output of zlib-native

02:14 <khem> RP: something in master-next broke riscv32 core-image-sato run on AB :( did you see ?

02:54 <khem> JaMa: interestingly, this is a report on older LTS like dunfell

02:55 <khem> so I have to say new upcoming LTS might be good

13:50 <RP> khem: not always, I think there is an intermittent kernel crash in there

13:51 <RP> JaMa: sadly the native builds are not reproducible :(

13:52 <RP> khem: next up is to clean up https://autobuilder.yoctoproject.org/typhoon/#/builders/144/builds/2 - rust tests need filtering a bit

13:59 <RP> khem: I've added some in master-next, we'll see how the next attempt goes

20:09 <JPEW> RP: sent the siggen patches. Be aware of the dependency of the OE patch on the bitbake patches

20:49 <Ad0> MACHINE_FEATURES and DISTRO_FEATURES sometimes has to be in tandem, for example bluetooth, but I guess it's unorthodox to modify DISTRO_FEATURES in your machine.conf if it's even available there, which I assume it is

21:03 <JaMa> Ad0: there is COMBINED_FEATURES but modifying DISTRO_FEATURES from machine.conf is just wrong

21:04 <Ad0> yeah where do you put that even

21:04 <Ad0> I ended up doing it all in distro with MACHINE_FEATURES:machine:append

21:04 <Ad0> err DISTRO_FEATURES*

21:06 <Ad0> COMBINED_FEATURES is interesting but should it be used?

21:07 <JaMa> COMBINED_FEATURES is the intersection between DISTRO and MACHINE FEATURES, you don't set it anywhere, but you can use it in conditionals

21:08 <JaMa> but if DISTRO_FEATURES intentionally doesn't have bluetooth, then machine.conf shouldn't try to enable it even when the machine does support bluetooth

21:10 <Ad0> ok

21:14 <Ad0> Some distro features are also machine features. These select features make sense to be controlled both at the machine and distribution configuration level. See the COMBINED_FEATURES variable for more information.

21:15 <Ad0> "Provides a list" is the key here I guess

21:18 <Ad0> also another thing is some recipes use ${THISDIR}/${PN} vs ${THISDIR}/files

21:34 <simonew> abelloni: We now have a CVE for libxml2 in the current version 2.11.5 in oe-core. A upgrade to 2.12.5 would help, I however saw your note that already the upgrade to 2.12.3 would break webkit. Any hope to fix this? How exactly would this break? Otherwhise I was thinking of just backporting the fix for the CVE only.

22:00 <RP> JPEW: thanks

22:09 <RP> JPEW: looks like it conflicts with the hashserv duplicates patch :/

22:16 <JPEW> RP: Ah yes. Do you want me to rebase on master next, or wait until it's merged?

22:17 <RP> JPEW: is that patch ok? I wasn't sure you'd reviewed it. I could ask them to resend?

22:32 <JPEW> RP: ya it looks good. Addressed my comments, I must have missed v2

22:33 <RP> Saur_Home: why do issues like https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/6440/steps/14/logs/stdio wait until after I merge patches :/

22:34 <RP> I cant know for sure it was that sstate one but the timing is suspicious :(

22:34 <RP> JPEW: is it straight forward for you to rebase or should I drop that and test your patches? I'm conscious yours is a bit more complex to get in

22:47 <JPEW> Probably easier to rebase that change on mine; I've just done that, running the tests now to make sure they pass

22:47 <JPEW> RP: I'll send the patches shortly

22:47 <JPEW> Or I guess just the one

22:48 <JPEW> If that's OK with you

22:49 <Saur_Home> RP: It is suspicious indeed. :( However, the .siginfo file is not handled by the functions Tobias changed, which made me realize that I actually do not know when and how the .siginfo file is created (compared to the code we just changed).

22:50 <JPEW> blerg, I also forgot a patch in the bitbake series b/c I cannot count :/

22:58 <RP> Saur_Home: you're right, particularly given this is a non sstate task

22:59 <RP> JPEW: that is fine with me

23:00 <JPEW> RP: Ok, just resent the whole series that now includes tobias patch

23:00 <JPEW> And the 2 I missed :D

23:01 <JPEW> I have to take my kid to a birthday party, but if there are any problems I'll look first thing in the monrinig

23:14 <RP> JPEW: ok, thanks

23:19 <Saur_Home> RP: Btw, I found a bug in the Git version of latest_versionstring() while working on the fixes for my devtool patches. I'll send a patch for it, once I figure out how to make bb.tests.fetch.FetchLatestVersionTest.test_git_latest_versionstring actually test for the case. Is there some way I can make bitbake-selftest print a debug message while

23:19 <Saur_Home> running the test so that I can see what is happening?

23:24 <RP> Saur_Home: print() should work in selftest

23:24 <RP> will display if the test fails

23:25 <Saur_Home> Well, it doesn't fail, which it should, and no matter what I change, I cannot seem to get it to fail...

23:28 <Saur_Home> The only thing I know is that I am running the correct version of the test because if I make a syntax error, it does fail...

23:32 <RP> Saur_Home: put in an assert for False being True, that should fail...

23:32 <Saur_Home> Meh, I figured it out by modifying one of the old entries so it failed.

23:34 <Saur_Home> The problem is that the test is written so that any version higher than the one specified satisfies the test. The problem with the case I found (from the sysdig recipe), is that it is supposed to find 0.35.2, but it incorrectly finds 11.0.0, which obviously is much higher than the expected...