linux/poky.git/meta/classes, branch 5.3_M1

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

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

toaster.bbclass: fix toaster error caused by tabs in BBLAYERS

2025-06-16T16:57:29+00:00

Users may unknowingly put tabs in BBLAYERS instead of spaces, and this is interpreted as a literal "\t" at the start of the filepath which causes _get_layer_dict() function to fail at finding the filepath. Instead of using split(" "), which restricts it to split on just spaces replace with split() as this handles spaces, tabs and newlines. Min steps to reproduce: - Clone the poky repo: git clone git://git.yoctoproject.org/poky cd poky source oe-init-build-env - Insert tabs in the BBLAYERS variable in bblayers.conf - Note: tab needs to be in the recipe that is being built for the error to be observed - Ex: ` /home//src/poky/meta-skeleton \` - Start toaster source toaster start bitbake hello Error message: FileNotFoundError: [Errno 2] No such file or directory: '\t/home//src/poky/meta-skeleton’ Fix by using split() instead of split(" "). Suggested-by: Anakin Childerhose CC: Richard Purdie (From OE-Core rev: 5ef1adca618cbf2d3e9ad2e5d504728b91d15e85) Signed-off-by: Osose Itua Signed-off-by: Richard Purdie

classes/recipes-devtools: Drop icecc from OE-Core

2025-06-05T10:02:22+00:00

There are reports this class has been broken since mickledore which suggests there are limited numbers of users. It doesn't have any automated testing and it would be hard to setup and maintain a testing environment for it. The original users/manintainers aren't using it now. For those reasons, drop from OE-Core as we're not in a good position to maintain it. I'd suggest anyone wanting to use it creates a dedicated layer with maintainers who are in a position to test/develop it appropriately since it is standalone code. (From OE-Core rev: ecf8c386cf83ea235bdc4ee0da6671a395a4c358) Signed-off-by: Richard Purdie

kernel-fit-image.bbclass: add a new FIT image implementation

2025-06-05T10:02:21+00:00

The new recipe linux-yocto-fitimage.bb and the new kernel-fit-image.bbclass are intended to become successors of the kernel-fitimage.bbclass. Instead of injecting the FIT image related build steps into the kernel recipe, the new recipe takes the kernel artifacts from the kernel recipe and creates the FIT image as an independent task. This solves some basic problems: * sstate does not work well when a fitImage contains an initramfs. The kernel is rebuilt from scratch if the build runs from an empty TMPDIR. * A fitImage kernel is not available as a package, but all other kernel image types are. * The task dependencies in the kernel are very complex and difficult to debug if something goes wrong. As a separate, downstream recipe, this is now much easier. The recipe takes the kernel artifacts from the deploy folder. There was also a test implementation passing the kernel artifacts via sysroot directory. This requires changes on the kernel.bbclass to make it copying the artifacts also to the sysroot directory while the same artifacts are already in the sstate-cached deploy directory. The new class kernel-fit-extra-artifacts.bbclass generates and deploys the kernel binary intended for inclusion in a FIT image. Note that the kernel used in a FIT image is a stripped (and optionally compressed) vmlinux ELF binary - not a self-extracting format like zImage, which is already available in the deploy directory if needed separately. The kernel-fit-extra-artifacts.bbclass can be used like this: KERNEL_CLASSES += "kernel-fit-extra-artifacts" (if uImage support is not needed, or with :append otherwise) The long story about this issue is here: [YOCTO #12912] (From OE-Core rev: 05d0c7342d7638dbe8a9f2fd3d1c709ee87d6579) Signed-off-by: Adrian Freihofer Signed-off-by: Richard Purdie

bitbake.conf/pseudo: Switch from exclusion list to inclusion list

2025-05-12T21:01:56+00:00

Currently, pseudo tracks all files referenced within its presence unless they're listed in an exclusion list. The exclusion list has grown to be fairly unwieldy. This patch swaps PSEUDO_IGNORE_PATHS for PSEUDO_INCLUDE_PATHS which in theory should be easier and more explicit to maintain. This change does drop many directories from pseudo coverage including /home and /tmp. There may be adapatations needed for recipes/classes using pseudo in specific ways. (From OE-Core rev: 2502da81709f25de499277b28d33c915638c45f6) Signed-off-by: Richard Purdie

vex: fix rootfs manifest

2025-05-08T09:28:18+00:00

Rootfs VEX file is created by gathering files from CVE_CHECK_DIR (deploy directory), however recipes generate the files only in CVE_CHECK_DIR (log directory). This make the rootfs VEX be always empty without any message. The code is copied from cve_check class, which writes to both, so let keep them aligned and make also vex write both files. Also add a warning for case that a cve file would be still missing. (From OE-Core rev: ee6541d0940c65685aaafd7d41a59a9406392e7d) Signed-off-by: Peter Marko Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Richard Purdie

spdx30: Provide software_packageUrl field in SPDX 3.0 SBOM

2025-05-08T09:28:18+00:00

Define var-SPDX_PACKAGE_URL to provide software_packageUrl field [1][2] in SPDX 3.0 SBOM, support to override with package name SPDX_PACKAGE_URL: Currently, the format of purl is not defined in Yocto, set empty for now until we have a comprehensive plan for what Yocto purls look like. But users could customize their own purl by setting var-SPDX_PACKAGE_URL [1] https://spdx.github.io/spdx-spec/v3.0.1/model/Software/Properties/packageUrl/ [2] https://spdx.github.io/spdx-spec/v3.0.1/annexes/pkg-url-specification/ (From OE-Core rev: c8e6953a0b6f59ffca994c440069db39e60b12d2) Signed-off-by: Hongxu Jia Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Richard Purdie

cve-check: fix debug message

2025-05-01T13:22:54+00:00

Debug level was not added as a parameter, causing a warning. (From OE-Core rev: 40157fcbd9066f261812ba665ec963b2e496aa53) Signed-off-by: Daniel Turull Signed-off-by: Richard Purdie