linux/poky.git/meta/lib, branch walnascar-next

spdx3: support to override the version of a package in SBOM 3

2025-03-24T17:29:16+00:00

By default, still use ${PV} as the the version of a package in SBOM 3 $ bitbake acl $ jq . tmp/deploy/spdx/3.0.1/core2-64/packages/package-acl.spdx.json ... { "type": "software_Package", ... "name": "acl", "software_packageVersion": "2.3.2" }, ... Support to override it by setting SPDX_PACKAGE_VERSION, such as set SPDX_PACKAGE_VERSION = "${EXTENDPKGV}" in local.conf to append PR to software_packageVersion in SBOM 3 $ echo 'SPDX_PACKAGE_VERSION = "${EXTENDPKGV}"' >> conf/local.conf $ bitbake acl $ jq . tmp/deploy/spdx/3.0.1/core2-64/packages/package-acl.spdx.json ... { "type": "software_Package", ... "name": "acl", "software_packageVersion": "2.3.2-r0" }, ... (From OE-Core rev: e6ff5f4d870624795bd36572f5c2bfeec90d83ce) Signed-off-by: Hongxu Jia Signed-off-by: Richard Purdie

oeqa: spdx: Add tar test for SPDX 2.2

2025-03-24T17:29:16+00:00

The base-files test for SPDX 2.2 did not give good coverage, since base-files doesn't have any dependencies. Add building tar as another test which more fully exercises the code (From OE-Core rev: d678e25419c89e09c1c438363bf3a940ce903d43) Signed-off-by: Joshua Watt Signed-off-by: Richard Purdie

oeqa: Build cpio with C17 std

2025-03-24T17:29:16+00:00

cpio is not yet buildable with C23 standard which is default with GCC 15, therefore ensure to apply needed bandage to keep it compiling in C17 mode even with GCC 15 (From OE-Core rev: 0c637099887f1be421c8e1203f99631a1e040150) Signed-off-by: Khem Raj Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Richard Purdie

spdx30: handle links to inaccessible locations

2025-03-20T17:49:16+00:00

This is the same as e105befbe4ee0d85e94c2048a744f0373e2dbcdf on additional place in the code. When a link is pointing to location inaccessible to build user (e.g. "/root/something"), filepath.is_file() throws "PermissionError: [Errno 13] Permission denied". Fix this by first checking if it is a link. (From OE-Core rev: 26f35f866cf7888431963cf4fc5d2019cd28de74) Signed-off-by: Peter Marko Signed-off-by: Richard Purdie

spdx: Update for bitbake changes

2025-03-20T13:50:40+00:00

Bitbake is dropping the need for fetcher name iteration and multiple revisions per url. Update the code to match (removal of the for loop). (From OE-Core rev: 4859cdf97fd9a260036e148e25f0b78eb393df1e) Signed-off-by: Richard Purdie

devtool: reset: Escape command line input used in regular expression

2025-03-20T11:29:04+00:00

Running, e.g., `devtool reset sdbus-c++` would result in the following error: re.error: multiple repeat at position 35 This was due to the ++ in the recipe name, which would be treated as an incorrect regular expression in _reset(). Use re.escape() to make sure all characters in the recipe name are treated literally. (From OE-Core rev: 6e73bd9b3e6d529752db93879f2c0ed53873dd1a) Signed-off-by: Peter Kjellerstedt Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Richard Purdie

spdx30: test the existence of directory before walking

2025-03-19T09:48:14+00:00

Due to commit [spdx30: Improve os.walk() handling][1] applied, it reported an error if walk directory failed While SPDX_INCLUDE_SOURCES = "1", if recipe does not provide sysroots, the walk in function add_package_files is broken $ echo 'SPDX_INCLUDE_SOURCES = "1"' >> conf/local.conf $ bitbake packagegroup-core-boot |DEBUG: Adding sysroot files to SPDX |ERROR: packagegroup-core-boot-1.0-r0 do_create_spdx: ERROR walking tmp/sysroots-components/intel_x86_64/packagegroup-core-boot: [Errno 2] | No such file or directory: 'tmp/sysroots-components/intel_x86_64/packagegroup-core-boot' Test the existence of directory before walking [1] https://git.openembedded.org/openembedded-core/commit/?id=86b581e80637cd8136ce7a7e95db94d9553d2f60 (From OE-Core rev: cb1792e4950d5075be9bbe4c5337a5215db9669e) Signed-off-by: Hongxu Jia Signed-off-by: Richard Purdie

meta/lib/oe/recipeutils.py: handle fetcher errors when checking for new commits

2025-03-19T09:48:14+00:00

Recent freedesktop instabilities are causing 'devtool check-upgrade-status' to fail with: bb.fetch2.FetchError: Fetcher failure: Fetch command export PSEUDO_DISABLED=1; git -c gc.autoDetach=false -c core.pager=cat -c safe.bareRepository=all -c clone.defaultRemoteName=origin ls-remote https://gitlab.> fatal: unable to access 'https://gitlab.freedesktop.org/mesa/kmscube/': The requested URL returned error: 502 and not print any results for this one or any unrelated recipes included in the check. This change handles the error, so that if some upstream server isn't working properly, latest upstream revision for that is marked as unknown, a warning is printed and upstream version check for other recipes isn't thwarted: WARNING: Unable to obtain latest revision: Fetcher failure: Fetch command export PSEUDO_DISABLED=1; git -c gc.autoDetach=false -c core.pager=cat -c safe.bareRepository=all -c clone.defaultRemoteName=origin ls-remote https://gitlab.freedesktop.org/mesa/piglit.git failed with exit code 128, output: remote: GitLab is not responding fatal: unable to access 'https://gitlab.freedesktop.org/mesa/piglit.git/': The requested URL returned error: 502 piglit 1.0 UNKNOWN_BROKEN Ross Burton (From OE-Core rev: c1056293f7cb32ee2bdf31441cc0b59d9ccfe556) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

oe-selftest: fitimage add more u-boot tests

2025-03-18T10:27:31+00:00

Add a new test function which checks that the device-tree of U-Boot contains the public keys which are required for checking the signature of the kernel FIT image at run-time. Use this new _check_kernel_dtb function in the existing test_sign_cascaded_uboot_fit_image test case which already creates a build configuration with UBOOT_SIGN_ENABLE = "1" and keys for the kernel. But so far there was no check that the keys for the kernel verification got added to U-Boot's DTB. This test case checks the configuration where only the configuration nodes of the kernel FIT image are signed. A new test case test_sign_uboot_kernel_individual checks the configuration with two keys and signed image and signed configuration nodes. This test case covers the use case which recently broke with commit: OE-Core rev: 259bfa86f384206f0d0a96a5b84887186c5f689e u-boot: kernel-fitimage: Fix dependency loop if UBOOT_SIGN_ENABLE and UBOOT_ENV enabled and got fixed with commit OE-Core rev: 0106e5efab99c8016836a2ab71e2327ce58a9a9d u-boot: kernel-fitimage: Restore FIT_SIGN_INDIVIDUAL="1" behavior This patch also fixes a few more details: - Simplify the code by moving all the U-Boot related variables to the _fit_get_bb_vars function. - Do not set FIT_GENERATE_KEYS = "1" without inheriting the kernel-fitimage.bbclass which handles this variable. (From OE-Core rev: dda1fcbc85c26d1851dda6ed235238b15939998e) Signed-off-by: Adrian Freihofer Signed-off-by: Richard Purdie

oe-selftest: fitimage improve bb_vars access

2025-03-18T10:27:31+00:00

Make the code slightly more robust by using e.g. bb_vars.get('UBOOT_SIGN_ENABLE') instead of bb_vars['UBOOT_SIGN_ENABLE'] for variables which are potentially undefined. This is a general cleanup but also a preparation for additional test cases. Log bb_vars in verbose mode. Drop one no longer used log message. (From OE-Core rev: 22a554e1d5a2449c4c1b34f4d5cfe1572a72a142) Signed-off-by: Adrian Freihofer Signed-off-by: Richard Purdie