linux/poky.git/meta/classes-recipe/populate_sdk_ext.bbclass, branch master-next

populate_sdk_ext: include image SPDX tasks in locked signatures

2025-11-07T13:15:35+00:00

Fixes [YOCTO #15726] Fixes [YOCTO #15853] After the switch to SPDX 3.0, eSDK installation can fail with errors like: gcc-source-1*:do_fetch attempted to execute unexpectedly This is usually due to missing setscene tasks. This is caused by image-related SPDX tasks, such as do_create_image_sbom_spdx, being excluded from the locked signatures. Without these, the corresponding sstate-cache artifacts are missing during eSDK installation. Previously (under SPDX 2.2), these image SPDX/SBOM tasks were not dependencies of do_populate_sdk_ext task, so their sstate artifacts were not required at install time. Fix: - Added `do_create_image_sbom_spdx` as a task dependency before `do_sdk_depends` to ensure SPDX/SBOM data generation is integrated in the eSDK build flow. - Adjusted `prepare_locked_cache()` to retain SDK_TARGETS (and their multilib variants) in the locked signatures file, ensuring image SPDX/SBOM tasks are preserved and not excluded during locked-sigs filtering. With this fix, eSDK installs work without unexpected task runs, even for custom distros or "tar" images. (From OE-Core rev: 464c92ed53c8786b450bb2d971633ddf392a2bbb) Signed-off-by: Jayasurya Maganuru Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Richard Purdie

populate_sdk_ext: Update to toolcfg.conf

2025-10-09T09:58:07+00:00

Add handling for toolcfg to the eSDK generation. Take the opporunity to clean up the code duplication too. (From OE-Core rev: ba8a64935f43bfda92a11758b13590bbb3632ff2) Signed-off-by: Richard Purdie

populate_sdk_ext: do not require CONF_VERSION (e.g. local.conf version) to be set

2025-10-02T10:28:03+00:00

The version checks for local.conf/site.conf/bblayers.conf are all optional, and aren't enforced (by insane class) if the versions aren't set. As bitbake-setup writes out a blank local.conf, it doesn't put a version in it either. Also, esdk bundle has a fixed set of layers and is not at risk of needing to update its own local.conf. The same condition is already in place for esdk's bblayers.conf for similar reasons. (From OE-Core rev: d83ff28157aaa9322f98b8da5dd50b562085085a) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

uninative/utils: Drop workarounds for gcc 4.8/4.9

2025-07-03T09:40:16+00:00

We require at least gcc 8.0 in sanity.bbclass so drop the 4.8/4.9 special case handling in uninative. (From OE-Core rev: 552e037bf598ac523f35b69d2dafc99e5ba59c5f) 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

bitbake.conf: Handle empty BB_CURRENT_MC

2025-01-25T11:30:31+00:00

Bitbake is about to change the default value of this from "default" to "". The original reason for this was to make this kind of include file usage easier. Instead we were going to complicate bitbake code having to map one value into the other. Instead, stop using "default" and put a slightly horrible bit of code in bitbake.conf as an alternative. This means a "default.conf" in the multiconfig directory will stop working but this was never something anyone was expected to use. The eSDK code also needs updating for this change. (From OE-Core rev: ff469ab2e865063bbc529031bbfd76cba5040073) Signed-off-by: Richard Purdie

populate_sdk_ext: write_local_conf add shutil import

2024-12-18T11:11:55+00:00

Add shutil import to resolve error: Exception: NameError: name 'shutil' is not defined, Did you forget to import 'shutil' (From OE-Core rev: b64263a43b4d82f1ebba13815bccb8a8cd3127f9) Signed-off-by: Mark Hatle Signed-off-by: Richard Purdie

conf/defaultsetup.conf: Drop TCLIBCAPPEND

2024-09-05T20:50:10+00:00

We've been able to run musl and glibc builds in the same TMPDIR for many years and a separate directory is not required. Most distros disable this value for that reason. Drop support for the variable to make it clear and easy for distros to be able to set multiconfigs which behave consistently for distros which do and don't clear it by dropping it entirely. (From OE-Core rev: ebcd355a32e2711263e22d9b45b502696ecbb4d2) Signed-off-by: Richard Purdie

populate_sdk_ext.bclass: make sure OECORE_NATIVE_SYSROOT is exported.

2024-07-02T21:29:13+00:00

Fixes bug 15464. OECORE_NATIVE_SYSROOT is correctly set up and exported in the SDK's environment file. But it's then unset in buildtools/environment-setup-*. The value is restored in the SDK's environment file but is not exported again. (From OE-Core rev: 825c996b7995d3ad510933b1a88229831ca5ea29) Signed-off-by: Gauthier HADERER Signed-off-by: Richard Purdie

sstatesig/populate_sdk_ext: Improve unihash cache handling

2024-06-04T11:04:52+00:00

Copying in the bb_unihashes cache file was at best a hack and creates a number of challenges. One is staying in sync with bitbake since it may not have saved the most recent version of the file. A second is a determinism problem since there may be more entries in the file than the SDK should have had access to. To improve the situation, add code to write the data into the locked-sigs.inc file such that even when locked-sigs aren't used, the right hash mappings are injected by the get_cached_unihash call. The functions in copy_buildsystem need to be updated to preserve data they're not editting. (From OE-Core rev: 11373def3171e75b3b74ef694da213dd21f3064c) Signed-off-by: Richard Purdie