* Work around internal error in gold triggered due to DWARF-5 by forcing to use bfd even with ld-is-gold:

The SRCREV is as intended. It is not intended to be that tag exactly, it is the tip of the 1.22.x branch (and that's what all of them have been throughout the history of the recipes). We can use

Hi Bruce,

The short log is wrong, the SRCREV and PV are correct. There's some fundamental issues with 1.23.x that prevented it from building inside or outside of bitbake, so I scaled back the version bump at

Hi Bruce, Whilst investigating a build problem on our CI related to sstate mirror of the k3s recipe, I found that the commit "k3s: update to 1.23.1" (8cba065209dd668afe939f878da340a017ecdd7d) didn't

There's already a libvirt upgrade in master-next. Check it out and send any patches incrementally to that. Bruce -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its

Dropped patches which are part of the new

Fundamentally, the same criteria that apply to OEcore apply to meta-virt (bugfixes, CVEs), except perhaps with a less well defined turn around time if other things are going on in master. There's

Hi Bruce, Sorry if my tone did not sound right, that was not my intention. I just wanted to understand what we should expect and hence what we should do in stable branches. Thanks. I think that

thanks for V2! I forgot that I was testing with v1, and pushed it instead of this .. but since the functional change is the same, we'll leave it as-is. Cheers, Bruce In message:

Broken is a far too dramatic description of this issue. Also, when talking about support, we are talking about OEcore / Yocto Project support. The rest of the layers in the ecosystem do this sort of

Hi, The branch is still supported at the moment and is broken. I do not think it is right to say “we will stop fixing issues a bit before the branch is out of support” as this is equivalent to

Agreed. I don't like to leave things broken either .. but we really shouldn't encourage people to keep using the branches that are going out of support. If I fix this one, there will be other issues

Unfortunately not. I have a dependency on this version, which means i need to fork the recipe, create a version specific one and then do some regression testing. I'm tied up with a few other high

Good fix. Please pull this in, as it is causing autobuilder errors See

A newer version of this was merged to OE-Core and there shouldn't be a hard version dependency in meta-virtualization so this can be droped from here. Signed-off-by: Richard Purdie

hardknott is not LTS, it is about to go EOL. https://wiki.yoctoproject.org/wiki/Releases Cheers, Richard

Hi Bruce In fact hardnott is not LTS (my mistake) but as support is broken it would still make sense to backport this I think. Cheers Bertrand

Hi Paulo Great thanks for the info. @Bruce: Maybe it would make sense to backport this as hardknott is LTS ? If yes, please ping me if you need support to do it. Cheers Bertrand

In oe-core, the commit: a83623a54a Revert "cmake.bbclass: Set CXXFLAGS and CFLAGS" drops compiler flags overrides for all cmake-based recipes, causing the ceph compile to fail with the error: