Similar to what native and staging is doing since:
https://git.openembedded.org/openembedded-core/commit/meta/classes/native.bbclass?id=d6c7b9f4f0e61fa6546d3644e27abe3e96f597e2https://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: dccb7a185fe58a97f33e219b4db283ff4a2071d7)
Signed-off-by: Martin Jansa <martin.jansa@gmail.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The class called 'make menuconfig' without any of the make variables and
options set in EXTRA_OEMAKE, resulting in a quite different build
environment than actually intended.
For the kernel.bbclass this was fixed in commit 8c616bc0 ("kernel: Use
consistent make flags for menuconfig") by appending ${EXTRA_OEMAKE} to
KCONFIG_CONFIG_COMMAND.
Instead of fixing this individually for additional recipes, we simply
include ${EXTRA_OEMAKE} in KCONFIG_CONFIG_COMMAND by default.
For most class users, this change is directly visible in the generated
.config file:
* For barebox and u-boot, the CONFIG_GCC_VERSION erroneously reflected
the host GCC version before where it now correctly reflects the target
toolchain's GCC.
* For u-boot, also the "Compiler: " line at the beginning of the .config
now prints the target toolchain instead of the host ones.
* The kernel had this already set.
* busybox did not produce any difference.
Note that these projects might base some compile-time decisions on e.g.
the actual compiler version used. Having the wrong one in the
menuconfig-generated .config affects at least the visibility and
consistency.
Reported-by: Ulrich Ölmann <u.oelmann@pengutronix.de>
(From OE-Core rev: a7dd1c221e42fd8df1d6f1c76c6a5ab7a3e19542)
Signed-off-by: Enrico Jörns <ejo@pengutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 1b6ddd452837e67b500a84455a234f5edc8250a9)
Signed-off-by: Enrico Jörns <ejo@pengutronix.de>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Introduce a new bitbake task do_create_kernel_config_spdx that extracts
the kernel configuration from ${B}/.config and exports it into the
recipe's SPDX document as a separate build_Build object.
The kernel config parameters are stored as SPDX DictionaryEntry objects
and linked to the main kernel build using an ancestorOf relationship.
This enables the kernel build's configuration to be explicitly captured
in the SPDX document for compliance, auditing, and reproducibility.
The task is gated by SPDX_INCLUDE_KERNEL_CONFIG (default = "0").
Reviewed-by: Joshua Watt <JPEWhacker@gmail.com>
(From OE-Core rev: 1fff29a0428778929ffa530482ebf7db95f1e0ae)
Signed-off-by: Kamel Bouhara (Schneider Electric) <kamel.bouhara@bootlin.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 228a968e7c47d811c06143279bdb0f9c5f374bef)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
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: e8d475b9b6d7b1ac3b0cfe367faabc07deb663b0)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Following the usage of TEST_SUITES in testimage, add TESTSDK_SUITES to
specify the list of tests to execute. By default the variable is empty,
which means to run all discovered tests.
This makes it easier to work on a single test without having to run all
of the tests.
(From OE-Core rev: 28d437c52c77889b2ede0fc2f2d6777c5b0a553d)
(From OE-Core rev: a93e21419476658f24220193fb0183efeb7a184f)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
If TCLIBC='baremetal' is set in local.conf, nativesdk-libstd-rs build fails
with:
| error[E0412]: cannot find type `c_char` in the crate root
| --> /usr/src/debug/libstd-rs/1.75.0/rustc-1.75.0-src/vendor/libc/src/unix/mod.rs:56:29
| |
| 6 | pub type c_schar = i8;
| | ---------------------- similarly named type alias `c_schar` defined here
| ...
| 56 | pub gr_name: *mut ::c_char,
| | ^^^^^^
This happens because rust_gen_target() sets os="none" when TCLIBC is
'baremetal' - even for nativesdk targets. However, nativesdk packages are
built against glibc, so the correct 'os' value should be "linux".
Fix this by setting the os field based on {TARGET,HOST,BUILD}_OS variables,
as it is already done in rust_base_triple(), instead of relying on TCLIBC.
(From OE-Core rev: 4c3f321304f2aa8b75cb58699b59fea80a23690c)
Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(master rev: 3eaf2cd5647585a1e6df03fc20e2753da27bb692) -- backport
Signed-off-by: Stefan Ghinea <stefan.ghinea@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Downstream tasks may want to know what image files were written so write
out a manifest in do_image_complete. The format of the manifest is the
same as the one in image.bbclass
(From OE-Core rev: e15a9934be84c59fc1bf957a60fa395e521abcfc)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Downstream tasks may want to know what image files were written by the
do_image family of tasks (e.g. SPDX) so have each task write out a
manifest file that describes the files it produced, then aggregate them
in do_image_complete
(From OE-Core rev: 5da5e2c528e8f4c78d389d60b03725323ff1527c)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 5e55ed4c5b9d5af3c96b82805af34af1512fc3d1)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Moves several of the functions in license.bbclass to be library code
New function dependencies were manually verified using bitbake-dumpsigs
to ensure that bitbake identified the same dependencies even though they
are now in library code (although the new function names mean that the
task hashes still change)
(From OE-Core rev: 5e220e20833fd800687b05c8f5cef602dfc47202)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 0333e04e353991260c5f67a72f80f3ab9dcf526a)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Backports the SPDX 3.0 support and fixes from upstream walnascar
commit 49f47169953b807d430461ca33f3a2b076119712 into upstream
scarthgap.
(From OE-Core rev: 9c9b9545049a2f6e5c99edcb079275d29a4d1ac6)
Signed-off-by: Kamel Bouhara (Schneider Electric) <kamel.bouhara@bootlin.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
/etc/os-release is a symlink to /usr/lib.
Symlink is retrieved as a dead link which points to nowhere if also the
original file is not accompanying it.
Fetch the real file in addition to this link.
Alternative could be to use "tar -h" (supported also by busybox tar),
however that could lose some important information if links are relevant
for failure analysis.
(From OE-Core rev: ed43f9ccb3c08845259e24440912631afd780d12)
(From OE-Core rev: f7ee6db8ca5dc72b7a468531e31403b60e6a0020)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Add the task dependency:
do_uboot_assemble_fitimage -> virtual/kernel:do_kernel_generate_rsa_keys
to ensure the kernel FIT image signing keys are available when creating
the U-Boot DTB. This is done only if the signing of the kernel FIT image
is enabled (UBOOT_SIGN_ENABLE="1").
The lack of the dependency causes build errors when executing a build
with no kernel FIT keys initially present in the keys directory. In such
cases one would see an output like this in the Bitbake logs:
Log data follows:
| DEBUG: Executing shell function do_uboot_assemble_fitimage
| Couldn't open RSA private key: '/workdir/build/keys/fit/dev.key': No such file or directory
| Failed to sign 'signature' signature node in 'conf-1' conf node
| FIT description: Kernel Image image with one or more FDT blobs
| ...
This issue was introduced by commit 259bfa86f384 where the dependency
between U-Boot and the kernel was removed (for good reasons). Before
that commit the dependency was set via DEPENDS so that, in terms of
tasks, one had:
u-boot:do_configure -> virtual/kernel:do_populate_sysroot
and the chain leading to the key generation was:
virtual/kernel:do_populate_sysroot -> virtual/kernel:do_install
virtual/kernel:do_install -> virtual/kernel:do_assemble_fitimage
virtual/kernel:do_assemble_fitimage -> virtual/kernel:do_kernel_generate_rsa_keys
With the removal of the first dependency, no more guarantees exist that
the keys would be present when assembling the U-Boot FIT image. That's
the situation we are solving with the present commit.
(From OE-Core rev: 036f20156b3c7d0a8b912e90aa29a9b986106d5a)
Fixes: d7bd9c627661 ("u-boot: kernel-fitimage: Fix dependency loop if UBOOT_SIGN_ENABLE and UBOOT_ENV enabled")
(From OE-Core rev: 56431a98ac661eaa42803e83a9ede6eae0b72b67)
Signed-off-by: Rogerio Guerra Borin <rogerio.borin@toradex.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
When building external modules, macros can include absolute names of
kernel headers. The macro-prefix-map for the STAGING_KERNEL_DIR is
currently missing. Add it in the same way as its done in bitbake.conf.
This fixes reproducible builds and following build error:
ERROR: cryptodev-module-1.14-r0 do_package_qa: QA Issue: File <..>
cryptodev.ko <..> contains reference to TMPDIR [buildpaths]
(From OE-Core rev: a741e11751bfb8f52be58cf51abeddca4559e5e9)
(From OE-Core rev: 58eb15cdc2dd95bf5eb0bed2a0f1c43bf29cf273)
Signed-off-by: Stefan Müller-Klieser <s.mueller-klieser@phytec.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
OE FIT_SIGN_INDIVIDUAL is implemented in an unusual manner,
where the resulting signed fitImage contains both signed
images and signed configurations, possibly using different
keys. This kind of signing of images is redundant, but so is
the behavior of FIT_SIGN_INDIVIDUAL="1" and that is here to
stay.
Adjust the process of public key insertion into u-boot.dtb
such that if FIT_SIGN_INDIVIDUAL==1, the image signing key
is inserted into u-boot.dtb first, and in any case the
configuration signing key is inserted into u-boot.dtb last.
The verification of the keys inserted into u-boot.dtb against
unused.itb is performed only for FIT_SIGN_INDIVIDUAL!=1 due to
mkimage limitation, which does not allow mkimage -f auto-conf
to update the generated unused.itb, and instead rewrites it.
Fixes: 259bfa86f384 ("u-boot: kernel-fitimage: Fix dependency loop if UBOOT_SIGN_ENABLE and UBOOT_ENV enabled")
(From OE-Core rev: 699822a163a4efa32735f75d21fde4ffa195c0e0)
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 0106e5efab99c8016836a2ab71e2327ce58a9a9d)
Signed-off-by: Jose Quaresma <jose.quaresma@foundries.io>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
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: 234f64b64e61cff4a27d2533dfc13e0c2a4fc63b)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
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: b71da7dd831d768d829c74f6137152f2ca6141b0)
Signed-off-by: Pedro Silva Ferreira <Pedro.Silva.Ferreira@criticaltechworks.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
(cherry picked from commit 6eeb832f73ffb48f5f05dc47191f60e4599e640f)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
How to reproduce:
- UBOOT_CONFIG must be used. With UBOOT_MACHINE it works fine.
A simple example based on oe-core is to modify the
beaglebone-yocto.conf file like this:
-UBOOT_MACHINE = "am335x_evm_defconfig"
+UBOOT_CONFIG = "foo"
+UBOOT_CONFIG[foo] = "am335x_evm_defconfig"
- A build configuration which inherits the kernel-fitimage.bbclass is
needed. For example:
MACHINE = "beaglebone-yocto"
KERNEL_IMAGETYPE = "Image"
KERNEL_IMAGETYPES += " fitImage "
KERNEL_CLASSES = " kernel-fitimage "
devtool modify linux-yocto
devtool build linux-yocto
...
| cp: cannot stat '.../linux-yocto-6.6.21+git/am335x_evm_defconfig/.config':
No such file or directory
| WARNING: .../linux-yocto/6.6.21+git/temp/run.do_configure.2081673:172 exit 1
from 'cp .../linux-yocto-6.6.21+git/am335x_evm_defconfig/.config
.../build/workspace/sources/linux-yocto/.config.baseline'
The reason for this problem is that the uboot-config.bbclass sets the
variable KCONFIG_CONFIG_ROOTDIR to a path that makes sense for u-boot,
but not for other recipes. However, the kernel-fitimage.bbclasse, for
example, inherits the uboot-config.bbclass, which brings the
u-boot-specific path into the kernel build context.
This change removes the uboot-specific KCONFIG_CONFIG_ROOTDIR path from
recipes other than u-boot itself.
(From OE-Core rev: 37835788d0772568f3551532eacbf810a4a6e47b)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from b23581a22619c52724c8e078f29e871e2ee74259)
Signed-off-by: Leonard Anderweit <l.anderweit@phytec.de>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
In case both UBOOT_SIGN_ENABLE and UBOOT_ENV are enabled and
kernel-fitimage.bbclass is in use to generate signed kernel
fitImage, there is a circular dependency between uboot-sign
and kernel-fitimage bbclasses . The loop looks like this:
kernel-fitimage.bbclass:
- do_populate_sysroot depends on do_assemble_fitimage
- do_assemble_fitimage depends on virtual/bootloader:do_populate_sysroot
- virtual/bootloader:do_populate_sysroot depends on virtual/bootloader:do_install
=> The virtual/bootloader:do_install installs and the
virtual/bootloader:do_populate_sysroot places into
sysroot an U-Boot environment script embedded into
kernel fitImage during do_assemble_fitimage run .
uboot-sign.bbclass:
- DEPENDS on KERNEL_PN, which is really virtual/kernel. More accurately
- do_deploy depends on do_uboot_assemble_fitimage
- do_install depends on do_uboot_assemble_fitimage
- do_uboot_assemble_fitimage depends on virtual/kernel:do_populate_sysroot
=> do_install depends on virtual/kernel:do_populate_sysroot
=> virtual/bootloader:do_install depends on virtual/kernel:do_populate_sysroot
virtual/kernel:do_populate_sysroot depends on virtual/bootloader:do_install
Attempt to resolve the loop. Pull fitimage configuration options into separate
new configuration file image-fitimage.conf so these configuration options can
be shared by both uboot-sign.bbclass and kernel-fitimage.bbclass, and make use
of mkimage -f auto-conf / mkimage -f auto option to insert /signature node key-*
subnode into U-Boot control DT without depending on the layout of kernel fitImage
itself. This is perfectly valid to do, because the U-Boot /signature node key-*
subnodes 'required' property can contain either of two values, 'conf' or 'image'
to authenticate either selected configuration or all of images when booting the
fitImage.
For details of the U-Boot fitImage signing process, see:
https://docs.u-boot.org/en/latest/usage/fit/signature.html
For details of mkimage -f auto-conf and -f auto, see:
https://manpages.debian.org/experimental/u-boot-tools/mkimage.1.en.html#EXAMPLES
(From OE-Core rev: 259bfa86f384206f0d0a96a5b84887186c5f689e)
Fixes: 5e12dc911d0c ("u-boot: Rework signing to remove interdependencies")
Reviewed-by: Adrian Freihofer <adrian.freihofer@siemens.com>
(From OE-Core rev: d7bd9c6276611c8c8de0c2a24947783eae5d932a)
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Using the package architecture to select the right qemu options to pass
to qemu-user is incorrect, and fails for recipes that set PACKAGE_ARCH
to MACHINE_ARCH (as the qemuppc workarounds suggest) because there are
not typically any options set for the machine name.
Solve this by using TUNE_PKGARCH instead: for the majority of recipes
this is the same value, but for machine-specific recipes it remains the
same instead of changing to the machine name.
This means we can remove the qemuppc workarounds, as they're obsolete.
Also update the gcc-testsuite recipe which uses the same pattern to use
TUNE_PKGARCH, and generalise the else codepath to avoid needing to
update the list of architectures.
[ YOCTO #15647 ]
(From OE-Core rev: 972ca555ff3aa41d32980477850c92915b6395ed)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 414b754a6cbb9cc354b1180efd5c3329568a2537)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The nativesdk class overrides PACKAGE_ARCH and unsets TUNE_FEATURES, but
as recipes might want to look at TUNE_PKGARCH too (for example, when
setting QEMU_EXTRAOPTIONS) we should also override that variable.
Otherwise, a nativesdk recipe will have the TUNE_PKGARCH of the target,
which leads to errors (eg passing mips arguments to an arm qemu).
(From OE-Core rev: 812cf123af5821c300c630cda35be8faed73b9d5)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 05322beb290e1db30bef49b4364f8a8e6e9f7408)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Add shutil import to resolve error:
Exception: NameError: name 'shutil' is not defined, Did you forget to import 'shutil'
(From OE-Core rev: 759fb4bb4f5d5cf7f124f64b9314a34e41f58d23)
Signed-off-by: Mark Hatle <mark.hatle@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit b64263a43b4d82f1ebba13815bccb8a8cd3127f9)
Signed-off-by: Mark Hatle <mark.hatle@kernel.crashing.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Fixed:
1) $ bitbake virtual/kernel -cmenuconfig
Do some changes and save the new config to default .config.
2) $ bitbake virtual/kernel -cdiffconfig
The config fragment is dumped into ${WORKDIR}/fragment.cfg.
But the .config which was saved by step #1 is overridden by .config.orig, so
the changes will be lost if run 'bitbake virtual/kernel'
And the following comment is for subprocess.call(), not for shutil.copy(),
so move subprocess.call() to the correct location.
# No need to check the exit code as we know it's going to be
# non-zero, but that's what we expect.
(From OE-Core rev: 7ec97c40696d3b2dda777f68b9ad07430969dc16)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 6cccf6b02f92dad514e65fd779ff659b19eb6be7)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
opkg stores the current time as Installed-Time in its status file when
installing packages to the rootfs. Make this reproducible by replacing
Installed-Time with ${REPRODUCIBLE_TIMESTAMP_ROOTFS}, which then also
matches the files' datestamps.
Based on OpenWrt's approach for the issue [1].
[1] https://github.com/openwrt/openwrt/blob/main/include/rootfs.mk#L103
(From OE-Core rev: 0520ec21a0f595a68c2869dbe613633f0594d3d3)
Signed-off-by: Jonas Gorski <jonas.gorski@bisdn.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 61a9b1b1cb618ce90ba7886036f41263075c07df)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
After commit 905e224849fbbed1719e0add231b00e2d570b3b4 (image_qa: fix
error handling), any unexpected exceptions in do_image_qa() would result
in a variable being set, but never used, effectively hiding the error.
Since image_qa now calls oe.qa.exit_if_errors(), remove the support for
oe.utils.ImageQAFailed and instead rely on the called functions to call
oe.qa.handle_error() themselves. This matches what do_package_qa() does.
Also update the description of do_image_qa() to explain that the called
functions are expected to call oe.qa.handle_error() themselves.
[ YOCTO #15601 ]
(From OE-Core rev: a1b28a88bc7697371ab166b18587b615d6d39c8e)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 0c3e111c965af2bc56533633c376b70b7fa5e1de)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Make ImageQAFailed inherit BBHandledException so exceptions raised in tests are
catched when the actual test function is executed by bb.utils.better_exec.
Change the do_image_qa tasks so errors are handled with oe.qa.handle_error. Add
some comment to explain this requires to list the test in ERROR_QA or WARN_QA.
[YOCTO #14807]
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14807
(From OE-Core rev: 8fe7aef17eefa70e3f7c07077b8c695e5c00ed5e)
Signed-off-by: Louis Rannou <louis.rannou@non.se.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 905e224849fbbed1719e0add231b00e2d570b3b4)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Without unsetting `j` and `k` for each `UBOOT_MACHINE`, `j` and `k`
are incremented in the same frequency as `i` and therefore `$j -eq $i`
and `$k -eq $i` is always true for the first `type` from `UBOOT_CONFIG`
and the first `binary` from `UBOOT_BINARIES`.
(From OE-Core rev: 7f81c38e91563d6d77621a3bfcb155cd226c9b74)
Signed-off-by: Paul Gerber <paul.gerber@ew.tq-group.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 3aef55c7ceb654b0012f20618bfd6ead1ef578b6)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Since this bbclass sets PACKAGES = "", inherit the nopackages
class to skip the various packaging functions which wouldn't
do anything anyway.
This fixes errors from buildhistory changes where packages-split would be empty.
e.g. meta-toolchain build now fails with:
| DEBUG: Executing shell function buildhistory_list_pkg_files
| find: ".../meta-toolchain/1.0/packages-split/*": No such file or directory
| WARNING: exit code 1 from a shell command.
| DEBUG: Python function buildhistory_emit_pkghistory finished
(From OE-Core rev: 2462cceaeec362d85a469ec0668ed92a092e725c)
Signed-off-by: Martin Jansa <martin.jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Atharva Nandanwar <atharvanandanwar@outlook.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
If EXTERNAL_KERNEL_DEVICETREE and dtb_image_sect are empty variables
dtb_path ends up as "/" which is available on most Unix systems but
probably not the dtb_path which is needed here. Checking for a file
makes more sense and also solves the issue with the "/".
(From OE-Core rev: 74054f3614922e331620a4dcb37975c5f679ab4e)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit c8f629b6991449cc6726f48a607d9e1bd50807ee)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
white space changes only.
- python part should be 4 spaces, not 8.
- use tabs for shell
(From OE-Core rev: 667aab25e83c84c0daccd43eda574ae34c75c8a7)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 000079a973e8c97d496ca721259437880a7ea70d)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
if IMAGE_LINK_NAME is set empty to disable the symlinking
for image artifacts in deploy, testexport fails, as the path assembly
is incorrect.
In that case fallback to IMAGE_NAME
(From OE-Core rev: bd723b611e937b8532ebcd485db61a3eae46091d)
Signed-off-by: Konrad Weihmann <kweihmann@outlook.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 0c1d098e6dd08fa3a5aafca656457ac6badcef89)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
if IMAGE_LINK_NAME is set empty to disable the symlinking
for image artifacts in deploy, testimage fails, as the path assembly
is incorrect.
In that case fallback to IMAGE_NAME
(From OE-Core rev: 1b026479e6d86d43d68ba26bed4b31dac91fc327)
Signed-off-by: Konrad Weihmann <kweihmann@outlook.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit c7a4e7e294992acc589c62adcaf6cd32659f2f9b)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The qemuboot.conf file contains the realpath of the kernel image
referenced by QB_DEFAULT_KERNEL. So, it must be recreated in case the
realpath of the referenced kernel image changes.
The variables KERNEL_IMAGE_NAME and KERNEL_IMAGE_BIN_EXT determine the
realpath of the kernel image relative to DEPLOY_DIR_IMAGE. Adding both of
them to the vardeps of the write_qemuboot_conf task triggers the
write_qemuboot_conf task in case the realpath of the kernel image
referenced by QB_DEFAULT_KERNEL changes.
Fixes: [YOCTO 15525]
(From OE-Core rev: fd21b5fa159e4c612475152e998ae85526fd60d9)
Signed-off-by: "Weisser, Pascal" <pascal.weisser.ext@karlstorz.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit f8b3975a9ce36ea7af5fd76243a823da2842415b)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
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: bdf07c1eb23dbb53ad1df415b665c8f459320420)
Signed-off-by: Gauthier HADERER <ghaderer@wyplay.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 825c996b7995d3ad510933b1a88229831ca5ea29)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Several conversion commands already make use of 'force' option in the
compression, which enables overwriting existing files without
prompting.
Since occasionally an existing residual destination file from a
previously aborted or failed task can prevent the re-execution of the
conversion command task, by enabling the 'force' option also for lz4
and lzop compression commands we can avoid following kind of BitBake
failures with these compressors:
| DEBUG: Executing shell function do_image_cpio
| 117685 blocks
| 2 blocks
| example-image.cpio.lz4 already exists; do you want to overwrite (y/N) ? not overwritten
| Error 20 : example-image.cpio : open file error
| WARNING: exit code 20 from a shell command.
ERROR: Task (.../recipes-core/images/example-image.bb:do_image_cpio) failed with exit code '1'
(From OE-Core rev: 623ab22434909f10aaf613cd3032cc2a2c6e3ff9)
(From OE-Core rev: 32904037728bf4d26cbada18ee71e62569ee2cfd)
Signed-off-by: Niko Mauno <niko.mauno@vaisala.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Currently, "tarball" sdk based recipes don't generate SPDX manifests as they
don't include the rootfs generation classes. Split the SPDX 3.0 image class into
two so the SDK components can be included where needed.
To do this, introduce an SDK_CLASSES variable similar to IMAGE_CLASSES which
the SDK code can use.
Migrate testsdk usage to this.
Also move the image/sdk spdx classes to classes-recipe rather than the general classes
directory since they'd never be included on a global level.
For buildtools-tarball, it has its own testsdk functions so disable the class there as
a deferred inherit would overwrite it.
(From OE-Core rev: 95660951a09e2a3fe63eb1017ad8f1d7fc9cd503)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 662396533177b72cc1d83e95841b27f7e42dcb20)
Eliminate spdx-3.0 items, not applicable to Scarthgap.
Signed-off-by: Mark Hatle <mark.hatle@kernel.crashing.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
When a create-spdx-* classes is processing documents, it needs to
find the document in a path that is related to the SSTATE_ARCH
when a packge is generated. The SSTATE_ARCH can be affected by
multilib configurations, resulting is something like armv8a-mlib.
When the image (or SDK) is being generated and the components are
collected, the system has no knowledge of the multilib arch and
will fail to find it, such as:
ERROR: meta-toolchain-1.0-r0 do_populate_sdk: No SPDX file found
for package libilp32-libgcc-dbg,
False sstate:libilp32-libgcc:armv8a-ilp32-mllibilp32-elf:14.1.0:r0:armv8a-ilp32:12:
sstate:libilp32-libgcc::14.1.0:r0::12:
Adding in the new SPDX_MULTILIB_SSTATE_ARCHS will provide a full
set of SSTATE_ARCHS including ones that contain the multilib
extension which will allow create-spdx-* to correctly find the
document it is looking for. This would also be valuable to any
other function doing a similar search through SSTATE_ARCH that may
have been extended with multilib configurations.
(From OE-Core rev: 5c1ce317fff6df6818f72d93197e5ec59ad4c462)
Signed-off-by: Mark Hatle <mark.hatle@amd.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit f1499c36c1054fc90f7b7268cc95285f2eca72f7)
spdx-3.0 items are not application and were removed.
spdx-common.bbclass item was moved into create-sdpx-2.2.bbclass.
Signed-off-by: Mark Hatle <mark.hatle@kernel.crashing.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The commit “Use a copy of image for kernel*.rpm if fs doesn't support
symlinks” [1] added postinst and postrm scripts to the kernel package which
create a symlink after package installation. This should not happen if
`KERNEL_IMAGETYPE_SYMLINK` is not `1`.
Background: The u-boot implementation of jffs2 does not support symlinks.
Using a hardlink or removing `${KERNEL_VERSION}` from the file name fails,
because the current postinst script replaces the file with the symlink.
[1] 8b6b95106a
Cc: Bruce Ashfield <bruce.ashfield@gmail.com>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Yanfei Xu <yanfei.xu@windriver.com>
(From OE-Core rev: 6916c19c8a09d8d0334c957ae541aafcbbcf92df)
Signed-off-by: Jörg Sommer <joerg.sommer@navimatix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 6a763401862d9ee96749ad18378b6344778c2c66)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
It always executes the scripts whether 'qemu-usermode' in
'MACHINE_FEATURES' or not. Fix the criterion to make it work.
(From OE-Core rev: 6f73c5df726eef7db32ab0fd1aa2ea4e45b3493c)
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 9e163246dcbbd2187c9ba28432c613b0d6c850c6)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
When this error is triggered, its a bit vague in specifying where the
issue is e.g.
ERROR: nbd-3.26.1-r0 do_package: nbd does not appear in package list, please add it
Some packages may intentionally remove PN from packages and find it
confusing as to why the system is still asking this to be in PACKAGES
(From OE-Core rev: 1ca6b396e2ac7088e4228a1b86fe25c6f7fb7a21)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 025a5e4529dff37a6423d305b12b7a51ceedd9e5)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The variable uninative_checksum is returned without being set, causing a
build error. Set it to None by default instead.
(From OE-Core rev: 5726348e04381d5c656a530c318775702136ec8c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 69ead1f2d403e6a0e5365ce4e89288f846d3ef33)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
There are two types of soft FPU options for arm, soft and softfp, and if
using the latter the wrong dynamic loader will be used.
E.g. go will link against ld-linux-armhf.so.3, but libc6 will only ship
a ld-linux.so.3, so go programs will fail to start.
Fix this by instead checking for TARGET_FPU being 'hard' and then
applying the suffix.
(From OE-Core rev: f8d96f091844bf4cc0fa3bd3104573533841259a)
Signed-off-by: Jonas Gorski <jonas.gorski@bisdn.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 07b4c7a2bd23f8645810e13439e814caaaf9cd94)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
If the kernel folder does not exist, find will result in an error.
This can occur if the kernel has no modules but, for example, custom modules are created.
Add check before deleting.
(From OE-Core rev: 63856721cab409ae0598cfbff4fcf55c90bfd7e7)
Signed-off-by: Heiko Thole <heiko.thole@entwicklung.eq-3.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 7ef767d84d56b25498e45db83bb8f9d9caebeaf9)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The change in commit 39fc503036
("classes: image_types: apply EXTRA_IMAGECMD:squashfs* in oe_mksquashfs()")
assigns $@ to a local variable without quoting it. While this works with
bash, it fails with dash. Here, only the first token of $@ is assigned
to the variable, and the reamining tokens are passed as arguments to the
"local" keyword.
Fix it by adding the missing quotes.
(From OE-Core rev: a3b51197f3ce868c83ed5ca415bd6506ecc2575d)
Signed-off-by: Martin Hundebøll <martin@geanix.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 14ca134f9f72d518c9180156a8efac19f8bb3ab0)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Since commit c991f9d6031 ("image_types: Set SOURCE_DATE_EPOCH for squashfs"),
I assume, the EXTRA_IMAGECMD:squashfs* variable(s) has been ignored.
This is due to the override magic, which isn't applied to functions
called by IMAGE_CMD:<type>, but only to the IMAGE_CMD:<type> itself.
Other image types (e.g. ext*) works around this by passing the
EXTRA_IMAGECMD variable as an argument to the called function.
To do the same for oe_mksquashfs(), the number of mandatory arguments is
fixed to one (with a little logic to handle the zstd filename). This
allows passing ${EXTRA_IMAGECMD} as an argument to oe_mksquashfs(),
which makes the variable functional again.
(From OE-Core rev: 39fc503036312e38ff0b9d8fb90b4c929b5ca7df)
Signed-off-by: Martin Hundebøll <martin@geanix.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
This reverts commit 827c60b79e7fcafd14e68870f6b69dcc48ac9c39.
Fixed with the drop of the linkmode
(From OE-Core rev: 137bb70ddf9dce30374cbb366196da0d8cc94205)
Signed-off-by: Jose Quaresma <jose.quaresma@foundries.io>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 8f46f60a703defc3e74adad382320c129cef0b06)
Signed-off-by: Jose Quaresma <jose.quaresma@foundries.io>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
