This is the final pull request for the 3.1.22 release build on Monday. The following changes since commit deb919a693e4371ace649680ca06ca6b6e3da4e2: lib/buildstats: fix parsing of trees with

From: Lee Chee Yang <chee.yang.lee@...> Signed-off-by: Lee Chee Yang <chee.yang.lee@...> --- .../ppp/ppp/CVE-2022-4603.patch | 50 +++++++++++++++++++

What is the use-case for this level of control then, and why would it be specific to RPM? Ross

Patches sent to oe-devel. Note that the pyforked one needs to merge after the picobuild->build migration. Ross

Indeed, I'm not going to align those names for this. Moreover, for this particular case rpm(1) supports several parameters to disable arch/os/etc checks. The patch proposed is not about a cosmetic

CARGO_VERSION isn't broken out in rust/src/stage0.json, there's only one snapshot version, so just use that. Signed-off-by: Alex Kiernan <alex.kiernan@...> --- (no changes since v1)

Changes: Added validation of SSH host keys for git URLs in Cargo (CVE-2022-46176) Signed-off-by: Alex Kiernan <alex.kiernan@...> --- Changes in v2: - Add patch to drop redundant

I have the patch for pytest-forked, failed to send. I’ve not seen the opengl-es-cts one before, I’ll have a look. Ross

<richard.purdie@...> wrote: One more thing I want to mention is that if you want to align the architectures so that you can install RPMs from Fedora, RHEL or any other RPM-based binary

We build target binaries to different levels of tuning, there are packages which run everywhere (noarch), there are binaries which are optimised to a specific tune and there is machine specific

This document hasn't been maintained in decades, and is not in any way official. Alex

Sure, RPM naming convention from rpm.org: http://ftp.rpm.org/max-rpm/ch-rpm-file-format.html As you can see, there are nothing about "core2_64" architecture. -- With best wishes, Sergei

Can you please link to (or describe with references) the common naming convention? Alex

I guess, we should wait a little bit with the merging here, because this problem is known in the same busybox mailing list thread. Andrej

Exactly! Even more: when I build for "genericx86_64", I get mix of packages with architecture one of: "x86_64", "genericx86_64", "core2_64", and "noarch". Our audit team highlited this as this is

Hi, Alexandre I need some help to debug this issue. I cannot reproduce this issue on my host. First,  the gcc command used to build the binary conftest will have as-needed enabled by default,  so

I think meta-python has meta-python/recipes-devtools/python/python3-pytest-forked_1.4.0.bb which needs some TLC after this. There is another failure with opengl-es-cts | ModuleNotFoundError: No

Libksba before 1.6.3 is prone to an integer overflow vulnerability in the CRL signature parser. CVE: CVE-2022-47926 References: https://nvd.nist.gov/vuln/detail/CVE-2022-47629 Signed-off-by: Yogita

Hi Michael, Any updates on patch merge? Thanks, Sandeep

Thanks Alex! According to: https://nvd.nist.gov/vuln/detail/CVE-2022-46176 "All Rust versions containing Cargo before 1.66.1 are vulnerable. " so we'll have to fix: kirkstone and