linux/poky.git/meta, branch 5.3_M1

build-appliance-image: Update to master head revision

2025-06-18T13:08:15+00:00

(From OE-Core rev: 826ab8dde34882c3ef705f715d8808e46bbedcde) Signed-off-by: Richard Purdie

libcheck: disable subunit support

2025-06-18T13:04:17+00:00

We don't have a recipe for subunit in core (or any layer in the layer index), and unfortunately a bug in the CMakeLists means that the native build can detect subunit on the host (so host contamination) and only half-enable it, so the build fails. Take a patch from upstream's github to add an option for subunit, and explicitly disable it. (From OE-Core rev: 155f0f65fa0f08a4586d3c9a02976f43a10b08aa) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

libcheck: remove obsolete patch

2025-06-18T13:04:17+00:00

This patch is specific to the autotools build of libcheck, but we use CMake now. (From OE-Core rev: 98091331829bd88b57fef5b811a4117b8db16032) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

coreutils: fix CVE-2025-5278

2025-06-18T13:04:17+00:00

Backport patch to fix CVE-2025-5278. (From OE-Core rev: 1bada55b3e76d9e5e7989f7229d5f25c8fd5ea89) Signed-off-by: Chen Qi Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Richard Purdie

spdx: add option to include only compiled sources

2025-06-17T22:38:18+00:00

When SPDX_INCLUDE_COMPILED_SOURCES is enabled, only include the source code files that are used during compilation. It uses debugsource information generated during do_package. This enables an external tool to use the SPDX information to disregard vulnerabilities that are not compiled. As example, when used with the default config with linux-yocto, the spdx size is reduced from 156MB to 61MB. Tested with bitbake world on oe-core. CC: Quentin Schulz CC: Joshua Watt CC: Peter Marko (From OE-Core rev: c6a2f1fca76fae4c3ea471a0c63d0b453beea968) Signed-off-by: Daniel Turull Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Richard Purdie

cross/crosssdk: Allow deferring of these classes too

2025-06-16T21:26:38+00:00

(From OE-Core rev: 2e568ba8607a6f65caea891df9bc9341988aaf37) Signed-off-by: Richard Purdie

bitbake.conf: Automatically defer native and nativesdk inherits

2025-06-16T21:26:38+00:00

(From OE-Core rev: ede97945ccabc7ace79a380be400357bbb8df80d) Signed-off-by: Richard Purdie

toolchain/gcc/clang: Update PREFERRED_PROVIDER to work with multilibs

2025-06-16T21:26:38+00:00

As currently written, the PREFERRED_PROVIDER entries don't work with multilib since they are added after the manipulations by multilib_global at ConfigParsed time. We therefore need to spell out the configs correctly for multilib. To avoid variable overwritten warnings from the expansion, we then have to expand out the nativesdk providers usng class overrides. (From OE-Core rev: 1f69850b62d1e022055d0f3b93ad270c2980462e) Signed-off-by: Richard Purdie

toolchain: Provide abstraction for recipe specific toolchain selection

2025-06-16T21:26:38+00:00

This change implements a toolchain selection mechanism. Selection is made using a set of variables, primarily PREFERRED_TOOLCHAIN_TARGET which defaults to gcc. It uses the familiar name for toolchain e.g. "gcc" which selects GNU compiler + binutils as default C/C++ toolchain or "clang" which will use LLVM/Clang Compiler. Layers an add their own toolchain definitions too. There are also PREFERRED_TOOLCHAIN_NATIVE and PREFERRED_TOOLCHAIN_SDK which will ulitmately allow selection of the toolchain used for the native/cross and nativesdk/crosssdk compilers. This currently isn't functional but is essential to the patch to ensure things are set to the existing gcc support in those cases. Users would most commonly want to set: PREFERRED_TOOLCHAIN_TARGET ?= "clang" in local.conf or other distro specific global configuration metadata. It is also selectable at recipe scope, since not all packages are buildable with either clang or gcc, a recipe can explicitly require a given toolchain using the TOOLCAHIN variable, e.g. glibc can not be built with clang therefore glibc recipe sets: TOOLCHAIN = "gcc" The TOOLCHAIN variable is distinct from the user preference so recipes with specific requirements can be identified. This also allows different polcies to be be specified for native/SDK cases in the future. (From OE-Core rev: 45bdedd213aff8df3214b95ef2a8551c0abd93a0) Signed-off-by: Richard Purdie

base: Add deferred class event handler

2025-06-16T21:26:38+00:00

Use the new deferred class event to set the class overrides earlier. This improves interaction of the override with PACKAGECONFIG values that control conditional inherits (such as python support). This also allows toolchain configuration in an easier and more user friendly way. (From OE-Core rev: d58f94d5684332bd4fac3747688558bb261b9c63) Signed-off-by: Richard Purdie