linux/poky.git/meta/classes, branch kirkstone

classes/buildhistory: Do not sign buildhistory commits

2026-02-27T15:54:02+00:00

This change adds the --no-gpg-sign option to prevent buildhistory commits from failing due to GPG signing issues. Depending on the setup, buildhistory may fail to create a commit if the user has the commit.gpgsign option enabled. For example, if the user creates a signing key that requires a password, the commit won't be created and will fail with the following error: / |error: Enter passphrase: Load key "/home//.ssh/id_ed25519": |incorrect passphrase supplied to decrypt private key? |fatal: failed to write commit object \ The bitbake command won't fail, but buildhistory won't have a commit. Also, the commit may silently fail when building inside a container due to missing packages or issues with accessing the GPG agent. This is similar to [1], and signing the buildhistory commit should be avoided to prevent such issues. 1 - https://git.openembedded.org/openembedded-core/commit/?id=7595a0a63a933af9dd9d1e458dc34a4ba80d9eae (From OE-Core rev: 5294d15737e176ee96d9b590808ded2164386362) Signed-off-by: Fabio Berton Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Ross Burton Signed-off-by: Richard Purdie (cherry picked from commit a5e18714aee52db898aaf9d222fb5a4168bde96e) Signed-off-by: Yoann Congal Signed-off-by: Paul Barker

cross.bbclass: Propagate dependencies to outhash

2025-12-31T15:24:54+00:00

Similar to what native and staging is doing since: https://git.openembedded.org/openembedded-core/commit/meta/classes/native.bbclass?id=d6c7b9f4f0e61fa6546d3644e27abe3e96f597e2 https://git.openembedded.org/openembedded-core/commit/meta/classes/staging.bbclass?id=1cf62882bbac543960e4815d117ffce0e53bda07 Cross task outputs can call native dependencies and even when cross recipe output doesn't change it might produce different results when the called native dependency is changed, e.g. clang-cross-${TARGET_ARCH} contains symlink to clang binary from clang-native, but when clang-native outhash is changed, clang-cross-${TARGET_ARCH} will still be considered equivalent and target recipes aren't rebuilt with new clang binary, see work around in https://github.com/kraj/meta-clang/pull/1140 to make target recipes to depend directly not only on clang-cross-${TARGET_ARCH} but clang-native as well. I have added a small testcase in meta-selftest which demostrates this issue. Not included in this change, but will send it if useful. openembedded-core $ ls -1 meta-selftest/recipes-devtools/hashequiv-test/ print-datetime-link-cross.bb print-datetime-link-native.bb print-datetime-native.bb print-datetime-usecross.bb print-datetime-usenative.bb print-datetime-native provides script which prints defined PRINT_DATETIME variable. print-datetime-link-native and print-datetime-link-cross both provide a symlink to the script from print-datetime-native. print-datetime-usenative and print-datetime-usecross are target recipes using the native and cross versions of print-datetime-link-* recipe. # clean build all is rebuilt: $ bitbake -k print-datetime-usenative print-datetime-usecross WARNING: print-datetime-native-1.0-r0 do_install: print-datetime-native current DATETIME in script is 2025-11-13_20_05 WARNING: print-datetime-link-native-1.0-r0 do_install: print-datetime-link-native current DATETIME in symlink is 2025-11-13_20_05 WARNING: print-datetime-link-cross-x86_64-1.0-r0 do_install: print-datetime-link-cross-x86_64 current DATETIME in symlink is 2025-11-13_20_05 WARNING: print-datetime-usenative-1.0-r0 do_install: print-datetime-usenative current DATETIME from print-datetime-link is 2025-11-13_20_05 WARNING: print-datetime-usecross-1.0-r0 do_install: print-datetime-usecross current DATETIME from print-datetime-link is 2025-11-13_20_05 # keep sstate-cache and hashserv.db: # print-datetime-usenative is correctly rebuilt, because print-datetime-link-native has different hash (because print-datetime-native hash changed) # print-datetime-usecross wasn't rebuilt, because print-datetime-link-cross-x86_64 doesn't include the changed hash of print-datetime-native $ bitbake -k print-datetime-usenative print-datetime-usecross WARNING: print-datetime-native-1.0-r0 do_install: print-datetime-native current DATETIME in script is 2025-11-13_20_07 WARNING: print-datetime-link-native-1.0-r0 do_install: print-datetime-link-native current DATETIME in symlink is 2025-11-13_20_07 WARNING: print-datetime-link-cross-x86_64-1.0-r0 do_install: print-datetime-link-cross-x86_64 current DATETIME in symlink is 2025-11-13_20_07 WARNING: print-datetime-usenative-1.0-r0 do_install: print-datetime-usenative current DATETIME from print-datetime-link is 2025-11-13_20_07 It's because print-datetime-link-cross-x86_64 depsig doesn't include print-datetime-native signature: $ cat tmp/work/x86_64-linux/print-datetime-link-cross-x86_64/1.0/temp/depsig.do_populate_sysroot OEOuthashBasic 18 SSTATE_PKGSPEC=sstate:print-datetime-link-cross-x86_64:x86_64-oe-linux:1.0:r0:x86_64:14: task=populate_sysroot drwx . drwx ./recipe-sysroot-native drwx ./recipe-sysroot-native/sysroot-providers -rw- 32 19fbeb373f781c2504453c1ca04dab018a7bc8388c87f4bbc59589df31523d07 ./recipe-sysroot-native/sysroot-providers/print-datetime-link-cross-x86_64 drwx ./recipe-sysroot-native/usr drwx ./recipe-sysroot-native/usr/bin drwx ./recipe-sysroot-native/usr/bin/x86_64-oe-linux lrwx ./recipe-sysroot-native/usr/bin/x86_64-oe-linux/print-datetime-link -> ../print-datetime While print-datetime-link-native doesn't have this issue, because print-datetime-native signature is there: $ cat tmp/work/x86_64-linux/print-datetime-link-native/1.0/temp/depsig.do_populate_sysroot OEOuthashBasic 18 print-datetime-native: 60f2734a63d708489570ca719413b4662f8368abc9f4760a279a0a5481e4a17b quilt-native: 65d78a7a5b5cbbf0969798efe558ca28e7ef058f4232fcff266912d16f67a8b8 SSTATE_PKGSPEC=sstate:print-datetime-link-native:x86_64-linux:1.0:r0:x86_64:14: task=populate_sysroot drwx . drwx ./recipe-sysroot-native drwx ./recipe-sysroot-native/sysroot-providers -rw- 26 3d5458be834b2d0e4c65466b9b877d6028ae2210a56399284a23144818666f10 ./recipe-sysroot-native/sysroot-providers/print-datetime-link-native drwx ./recipe-sysroot-native/usr drwx ./recipe-sysroot-native/usr/bin lrwx ./recipe-sysroot-native/usr/bin/print-datetime-link -> print-datetime With the cross.bbclass fix the link-cross recipe has a checksum from native recipe as well: $ cat tmp/work/x86_64-linux/print-datetime-link-cross-x86_64/1.0/temp/depsig.do_populate_sysroot OEOuthashBasic 18 print-datetime-native: 9ceb6c27342eae6b8da86c84685af38fb8927ccc19979aae75b8b1e444b11c5c quilt-native: 65d78a7a5b5cbbf0969798efe558ca28e7ef058f4232fcff266912d16f67a8b8 SSTATE_PKGSPEC=sstate:print-datetime-link-cross-x86_64:x86_64-oe-linux:1.0:r0:x86_64:14: task=populate_sysroot drwx . drwx ./recipe-sysroot-native drwx ./recipe-sysroot-native/sysroot-providers -rw- 32 19fbeb373f781c2504453c1ca04dab018a7bc8388c87f4bbc59589df31523d07 ./recipe-sysroot-native/sysroot-providers/print-datetime-link-cross-x86_64 drwx ./recipe-sysroot-native/usr drwx ./recipe-sysroot-native/usr/bin drwx ./recipe-sysroot-native/usr/bin/x86_64-oe-linux lrwx ./recipe-sysroot-native/usr/bin/x86_64-oe-linux/print-datetime-link -> ../print-datetime And print-datetime-usecross is correctly rebuilt whenever print-datetime-native output is different. (From OE-Core rev: c15faee8854e85e02693a041d88326f30b24ee92) Signed-off-by: Martin Jansa Signed-off-by: Steve Sakoman

goarch.bbclass: do not leak TUNE_FEATURES into crosssdk task signatures

2025-11-19T16:21:24+00:00

The default assignments look like this: TARGET_GO386 = "${@go_map_386(d.getVar('TARGET_ARCH'), d.getVar('TUNE_FEATURES'), d)}" TUNE_FEATURES is a target-specific variable, and so should be used only for target builds. The change is similar to what is already done for native packages. (From OE-Core rev: cfff8e968257c44880caa3605e158764ed5c6a2a) (From OE-Core rev: 8aad87c12a809d790175b9848f5802d0a28eecac) Signed-off-by: Alexander Kanavin Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Richard Purdie Signed-off-by: Peter Marko Signed-off-by: Steve Sakoman

insane: Ensure that `src-uri-bad` fails correctly

2025-09-19T14:03:31+00:00

`src-uri-bad` is missing the required call to `oe.qa.exit_if_errors` so the corresponding task is not marked as failed when the QA check is classified as an error. This issue was fixed by the introduction of the do_recipe_qa task in OE-core (e0c71367ab59021fc430ef215bbfc3b525036ba4) which is not part of kirkstone yet. (From OE-Core rev: 4b593ea8df9b1d3dda0adf38786845168360311f) Signed-off-by: Philip Lorenz Signed-off-by: Steve Sakoman

insane: Improve patch warning/error handling

2025-09-19T14:03:31+00:00

Currently, whilst patch errors or warnings are shown, the errors don't stop builds. The configuration isn't very configurable from WARN_QA and ERROR_QA either. This patch: * Uses the standard mechanisms to handle the patch fuzz warnings/errors * Makes Upstream-Status checking configurable from WARN/ERROR_QA * Allows that checking to be used with non-core layers * Makes patch-fuzz an error by default (From OE-Core rev: 76a685bfcf927593eac67157762a53259089ea8a) (From OE-Core rev: 4899961965d70281e63582234f0ed299431eff32) Signed-off-by: Richard Purdie (cherry picked from commit 3c3fd6a65e8103f74ae382d196d486b31a168b39) The backported commit was modified to not mark "patch-fuzz" as an error by default (which retains compatibility with kirkstone behaviour). Signed-off-by: Philip Lorenz Signed-off-by: Steve Sakoman

kernel.bbclass: add original package name to RPROVIDES for -image and -base

2025-06-13T15:42:35+00:00

* -image and -base change PKG to: PKG:${KERNEL_PACKAGE_NAME}-image = "${KERNEL_PACKAGE_NAME}-image-${@legitimize_package_name(d.getVar(KERNEL_VERSION))}" PKG:${KERNEL_PACKAGE_NAME}-base = "${KERNEL_PACKAGE_NAME}-${@legitimize_package_name(d.getVar(KERNEL_VERSION))}" * but only when debian.bbclass is inheritted they add the original package name into RPROVIDES by: https://git.openembedded.org/openembedded-core/commit/?id=3409c4379559afbb1d1d29045582995147a33bbc * fixes the build if some packagegroup or something RDEPENDS on kernel-image or kernel-base and the DISTRO doesn't inherit debian.bbclass * as shown in pkgdata: linux-raspberrypi $ egrep "^(PKG:)|(RPRO)" 6.6.36+git-*/pkgdata/runtime/kernel-image 6.6.36+git-debian/pkgdata/runtime/kernel-image:RPROVIDES:kernel-image: kernel-image (=6.6.36+git@PRSERV_PV_AUTOINC@+733366844f_769634f344) 6.6.36+git-debian/pkgdata/runtime/kernel-image:PKG:kernel-image: kernel-image-6.6.36-v8 6.6.36+git-without-debian/pkgdata/runtime/kernel-image:PKG:kernel-image: kernel-image-6.6.36-v8 linux-raspberrypi $ egrep "^(PKG:)|(RPRO)" 6.6.36+git-*/pkgdata/runtime/kernel-image-image 6.6.36+git-debian/pkgdata/runtime/kernel-image-image:RPROVIDES:kernel-image-image: kernel-image-image (=6.6.36+git@PRSERV_PV_AUTOINC@+733366844f_769634f344) 6.6.36+git-debian/pkgdata/runtime/kernel-image-image:PKG:kernel-image-image: kernel-image-image-6.6.36-v8 6.6.36+git-without-debian/pkgdata/runtime/kernel-image-image:PKG:kernel-image-image: kernel-image-image-6.6.36-v8 (From OE-Core rev: 05498781657a3f8b38b000f91594ecd78850ce47) (From OE-Core rev: 350513959f6800eef6579153c2ae95960ca24ea7) Signed-off-by: Martin Jansa Signed-off-by: Richard Purdie (cherry picked from commit 9cb954884bc3905defa1ff533e668dea13e17cba) Signed-off-by: Jörg Sommer Signed-off-by: Steve Sakoman

module.bbclass: add KBUILD_EXTRA_SYMBOLS to install

2025-05-16T15:58:06+00:00

Symbols are used during install as well, adding KBUILD_EXTRA_SYMBOLS enables successful installation. | DEBUG: Executing shell function do_install | NOTE: make -j 22 KERNEL_SRC=xxx/kernel-source -C xxx/drivers KDIR=xxx/kernel-source DEPMOD=echo MODLIB=xxx/image/lib/modules/6.6.75-yocto-standard-00189-g530c419bc9db INSTALL_FW_PATH=xxx/image/lib/firmware CC=aarch64-poky-linux-gcc -fuse-ld=bfd -fcanon-prefix-map LD=aarch64-poky-linux-ld.bfd OBJCOPY=aarch64-poky-linux-objcopy STRIP=aarch64-poky-linux-strip O=xxx/kernel-build-artifacts modules_install | make: Entering directory 'xxx/drivers' | make -C xxx/kernel-source M=xxx/drivers modules | make[1]: Entering directory 'xxx/kernel-source' | make[2]: Entering directory 'xxx/kernel-build-artifacts' | MODPOST xxx/drivers/Module.symvers | ERROR: modpost: "xxx" [xxx/xxx.ko] undefined! (From OE-Core rev: 1403ffa42014ad5c88c28da6c360ea5fd1857147) Signed-off-by: Alon Bar-Lev Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Richard Purdie (cherry picked from commit 0ef80eeda967a9e04ff91c3583aabbc35c9868e8) Signed-off-by: Steve Sakoman

classes-global/insane: Look up all runtime providers for file-rdeps

2025-02-15T14:04:44+00:00

Uses the new foreach_runtime_provider_pkgdata() API to look up all possible runtime providers of a given dependency when resolving file-rdeps. This allows the check to correctly handle RPROVIDES for non-virtual dependencies (From OE-Core rev: 018fa1b7cb5e6a362ebb45b93e52b0909a782ac9) (From OE-Core rev: 0ff31972b60dda5d8bada2ffb428cc54bb49e8cf) Signed-off-by: Joshua Watt Signed-off-by: Richard Purdie Signed-off-by: Steve Sakoman

cmake: apply parallel build settings to ptest tasks

2025-02-15T14:04:44+00:00

ptest compile and install tasks do not have parallel build settings for cmake. On powerful build machines this can cause overload situations and oomkills. Observed when building qtgrpc with ptest generally enabled in distro. Having this in ptest class is suboptimal, but creating ptest-cmake class just for these two variables is probably overkill. (From OE-Core rev: 3c311fbf0c2090268e9b83123d762b05b61b4074) (From OE-Core rev: bd12abeff6ee14385fba63fa5ba15d9fadec4d0e) Signed-off-by: Peter Marko Signed-off-by: Richard Purdie Signed-off-by: Steve Sakoman

rust-common.bbclass: soft assignment for RUSTLIB path

2025-02-15T14:04:44+00:00

As a user i want to override `RUSTLIB` path on a bbclass, lets call it `XYZ.bbclass`. If a certain recipe inherits `cargo.bbclass` and `XYZ.bbclass` the value of `RUSTLIB` is dependent on the order of the inherit. If `cargo.bbclass` is inherit before `XYZ.bbclass` this will reflect the desired value of `RUSTLIB`, on the oposite, if the `XYZ.bbclass` is inherit before `cargo.bbclass` then the `RUSTLIB` defined on `rust-common.bbclass` will prevail. Changed definition of `RUSTLIB` to soft assignment to make it overridable. (From OE-Core rev: d8ccc3ad338a8020c998566249af2019baaa6e44) Signed-off-by: Pedro Silva Ferreira Signed-off-by: Mathieu Dubois-Briand (cherry picked from commit 6eeb832f73ffb48f5f05dc47191f60e4599e640f) Signed-off-by: Steve Sakoman