/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: 93efeca19f53132fce84d914b7ebf21070370127)
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>
There was a regression introduced by the change to use
systemd-systemctl-native rather than a python fake implementation,
which caused template units to not be properly enabled when set in
the SYSTEMD_SERVICE variable. Through investigation, it seems that
the best way to re-enable template instances is to handle them
explicitly in the systemd.bbclass and enable them with `preset`, like
most units are handled[1,2].
Per the systemd.preset manpage, the format for template units is
different than for regular units[3]. We need to coalesce all the
template instances onto a single line and emit them as an additional
space-deliminated argument.
Ran this against openbmc's phosphor-ipmi-net recipe and generated
the following preset file:
```
$ cat packages-split/phosphor-ipmi-net/usr/lib/systemd/system-preset/98-phosphor-ipmi-net.preset
enable phosphor-ipmi-net@.service eth0
enable phosphor-ipmi-net@.socket eth0
```
[1]: https://lore.kernel.org/openembedded-core/Z2ch.1747051947055246176.oktf@lists.openembedded.org/
[2]: https://lore.kernel.org/openembedded-core/aDdoTVtCmElpURYD@heinlein/
[3]: https://www.freedesktop.org/software/systemd/man/latest/systemd.preset.html
Fixes: 7a580800db39 ("systemd: Build the systemctl executable")
(From OE-Core rev: f33d9b1f434e40a459614d8dc21ce45e11581008)
(From OE-Core rev: ea207dce1f5f8579d8ddde487ac9852f50bfc792)
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
* PACKAGECONFIG_CONFARGS was added in:
https://git.openembedded.org/openembedded-core/commit/?id=16745b20452de60ae2474433cc1a2fb1ed9f6a64
but it wasn't added in bbnote above which might lead to confusing errors like I got now:
NOTE: cargo build -v --frozen --target aarch64-webos-linux-gnu --release --manifest-path=.../git//Cargo.toml
error: unexpected argument '--cfg' found
Usage: cargo build --verbose... --frozen --target [<TRIPLE>] --release --manifest-path <PATH>
and was wondering where --cfg came from.
* it was from recipe where we already use:
RUSTFLAGS:append = " ${PACKAGECONFIG_CONFARGS}"
it will be difficult to use PACKAGECONFIG for RUSTFLAGS and prevent
them to be used here for cargo as well, what about the recipes which
need them to explicitly append them to CARGO_BUILD_FLAGS ?
(From OE-Core rev: 38d953b2ffd4e0cee9e77f97988e44be105023c6)
Signed-off-by: Martin Jansa <martin.jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In order to allow rust packages to define PACKAGECONFIG options, append
the contents of PACKAGECONFIG_CONFARGS to the build command.
This patch was already submitted by Bartosz Golaszewski on older
version but was never merged. It will be really usefull for Rust recipes.
(From OE-Core rev: 16745b20452de60ae2474433cc1a2fb1ed9f6a64)
Signed-off-by: Jean-Pierre Geslin <jarsoper@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There's no point inheriting autotools if you're not actually going to
run a configure script, so make a missing configure script fatal.
(From OE-Core rev: 6d327a39befae44a88a812bdf4acde800dcee57b)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These are already exported by bitbake.conf, no need to export them again.
(From OE-Core rev: 92e52f5afac4877366c1ee2e6c6f0d1f5df84410)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Set the host OBJCOPY, OBJDUMP, and READELF variables to be derived from
their corresponding BUILD_* definitions. This makes the native class
match the build-gcc.inc file 1 to 1, as these were the only missing.
Currently these variables get their definitions from gcc.inc, which uses
HOST_PREFIX, and that works because the native class sets HOST_PREFIX to
BUILD_PREFIX, but this doesn't seem correct.
(From OE-Core rev: 87a6ffe21b706e6aeeeb77891565cbd7730ca163)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Compiling a FIT image with this default values and dump it with
dumpimage shows decimal converted values. For example the default value
20008000 looks like this:
Image 0 (kernel-1)
...
Load Address: 0x01314c40
Entry Point: 0x01314c40
With this change the expected value is printed by dumpimage.
(From OE-Core rev: e6f2ca9135ef7da8f8b5925957532734c06e55cc)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If FIT_SIGN_INDIVIDUAL is set to “1”, a signature section is added
to all screen sections, but not to the setup section. To match the setup
section with all other sections, the signature is also added. This also
helps to implement the associated tests generically.
This change is intended to make the code more consistent. However, it is
not intended to make the FIT_SIGN_INDIVIDUAL function more popular.
Technically, it would be better to remove the signature from all other
image sections and discard the FIT_SIGN_INDIVIDUAL function, the use of
which is no longer recommended anyway.
(From OE-Core rev: 8bf6a9c07cdde8fc8bbd4bb61a4886ccc02a570f)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Whenever Systemd is used as an init manager, it requires a machine-id
file to be present / initialized / or have the RW rootfs. This change
does not introduce a new functionality, but rather merges everything we
do with machine-id in one place.
(From OE-Core rev: 890b81cdfadc427189eff4bbd2c24e32eb286126)
Signed-off-by: Vyacheslav Yurkov <uvv.mail@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(From OE-Core rev: 219c7c4954c649a1a0c284bb5f35eee533db41c3)
Signed-off-by: Victor J. Hansen <victor.hansen@remarkable.no>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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)
Signed-off-by: Stefan Müller-Klieser <s.mueller-klieser@phytec.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Check if the variable GO_IMPORT is
set in the recipe. If not generate an error.
Test building go-helloworld when GO_IMPORT assigned
Test building go-helloworld when GO_IMPORT is not assigned, generate error about GO_IMPORT
Test building any other recipe(e.g bash) when GO_IMPORT is not assigned, generate error about GO_IMPORT
Test creating a GO recipe with recipetool (not affected)
Test selftest test_recipetool_create_go (not affected)
Test selftest test_recipetool_create_go_replace_modules (not affected)
[YOCTO #15763]
CC: Yoann Congal <yoann.congal@smile.fr>
CC: Randy MacLeod <randy.macleod@windriver.com>
(From OE-Core rev: 374a91204bdaf44067f6b0ae89ed60934751efaa)
Signed-off-by: Christos Gavros <gavrosc@yahoo.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
After upstream go applied commit [cmd: remove support for
GOROOT_FINAL][1], GOROOT_FINAL variable is dropped and use
option -trimpath to instead [2]
The option -trimpath has already been added to GOBUILDFLAGS
in go.bbclass
[1] 507d1b22f4
[2] https://github.com/golang/go/issues/62047
(From OE-Core rev: 791ab77ac05f658ecd61525a3d9b1afaf8ac6e06)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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: 1b6ddd452837e67b500a84455a234f5edc8250a9)
Signed-off-by: Enrico Jörns <ejo@pengutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, uboot-sign.bbclass only supports to create Image Tree Source(ITS)
for "u-boot" and "flat_dt". However, users may want to add their private
images into u-boot FIT image for specific application and purpose.
To make this bbclass more flexible and support to add users specific snippet
ITS, creates a new "UBOOT_FIT_USER_SETTINGS" variable. Users can add their
specific snippet ITS into this variable.
Example:
```
UBOOT_FIT_MY_ITS = '\
myfw {\n\
description = \"MY Firmware\";\n\
data = /incbin/(\"myfw.bin\");\n\
type = \"mytype\";\n\
arch = \"myarch\";\n\
os = \"myos\";\n\
load = <0xb2000000>;\n\
entry = <0xb2000000>;\n\
compression = \"none\";\n\
};\n\
'
UBOOT_FIT_USER_SETTINGS = "${UBOOT_FIT_MY_ITS}"
```
The generated ITS
```
myfw {
description = "My Firmware";
data = /incbin/("myfw.bin");
type = "mytype";
arch = "myarch";
os = "myos";
load = <0xb2000000>;
entry = <0xb2000000>;
compression = "none";
};
```
Add a variable "UBOOT_FIT_CONF_USER_LOADABLES" to load users specific images
and it is an empty by default.
(From OE-Core rev: c12e013453689697a8680f1c7de3e625a0ff28ec)
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, uboot-sign.bbclass only supports to create Image Tree Source(ITS)
for "u-boot" and "flat_dt". However, users may want to support multiple images
such as ARM Trusted Firmware(ATF), Trusted Execution Environment(TEE) and
users private images for specific application and purpose.
To make this bbclass more flexible and support ATF and TEE, creates new
functions which are "uboot_fitimage_atf" and "uboot_fitimage_tee"
for ATF and TEE ITS file creation, respectively.
Add a variable "UBOOT_FIT_ARM_TRUSTED_FIRMWARE" to
enable ATF ITS generation and it is disable by default.
Add a variable "UBOOT_FIT_TEE" to enable TEE ITS generation
and it is disable by default.
(From OE-Core rev: c14641a964b5b802e995e574a599c5b4937fb488)
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
autotools has improved a lot since this class was written, and there's
now no need to search the source tree for m4 files and add them to the
include path.
If packages have macros in subdirectories the idiom is to tell aclocal
via an assignment in Makefile.am:
ACLOCAL_AMFLAGS = -I gl/m4 -I m4
If, for example, a package isn't autoreconfable out of the box (because
it has a non-trivial autogen.sh or similar, say) then the required -I
statements can be added to EXTRA_AUTORECONF.
(From OE-Core rev: e718d1be2c4fb54cf363c23f929358e1be68c724)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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: 0106e5efab99c8016836a2ab71e2327ce58a9a9d)
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>
cargo configuration has been renamed from plain 'config' to
'config.toml' in rust-1.38.
Using the old name is still supported but creates warnings like
| $ cargo
| warning: `/sdk.../home/cargo/config` is deprecated in favor of `config.toml`
| note: if you need to support cargo 1.38 or earlier, you can symlink `config` to `config.toml`
Use the new name.
(From OE-Core rev: 94b7d1a6cdb44949f8a96213ff2e45fafd759442)
Signed-off-by: Enrico Scholz <enrico.scholz@sigma-chemnitz.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When specifying the dependencies of do_bundle_initramfs the current
multiconfig might not be the default. This fixes the dependencies between
the multiconfigs if the current differs to default.
(From OE-Core rev: 2e40466af83a3c66aef878e3f08a891405199ebe)
Signed-off-by: Mueller, Daniel <daniel.mueller@karlstorz.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The environment variable SETUPTOOLS_SCM_SUBPROCESS_TIMEOUT allows to override
the subprocess timeout. The default is 40 seconds and should work for most
needs.[1] However, it was not enough while using git shallow tarball and starting
multiple Yocto world builds in one host.
| File "tmp/work/x86_64-linux/python3-scancode-native/32.1.0/recipe-sysroot-
native/usr/lib/python3.13/subprocess.py", line 1263, in _check_timeout
| raise TimeoutExpired(
| ...<2 lines>...
| stderr=b''.join(stderr_seq) if stderr_seq else None)
| subprocess.TimeoutExpired: Command '['git', '--git-dir', 'tmp/work/x86_64-
linux/python3-scancode-native/32.1.0/git/.git', 'status', '--porcelain',
'--untracked-files=no']' timed out after 40 seconds
Explicitly set variable SETUPTOOLS_SCM_SUBPROCESS_TIMEOUT to 600s in bbclass,
and we could override it in local.conf
[1] https://github.com/pypa/setuptools-scm/blob/main/docs/overrides.md
(From OE-Core rev: a3a2edbf7139b7f8c665c2b0b13e094a334e4441)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The feature is available since meson 0.60.0. You can specify
comma-separated list of install tags (not targets).
(From OE-Core rev: a61ec67cb6f240c7593c9dd1b9a1ef5fff87c855)
Signed-off-by: Vyacheslav Yurkov <uvv.mail@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In case the initramfs image is bundled into the kernel there's no need to
specify a dependeny on the do_image_complete task of the initramfs image
from the do_assemble_fitimage_initramfs task since the task won't access
the image.
(From OE-Core rev: af6cde746f72be761550ee28b017719fba26ea65)
Signed-off-by: Weisser, Pascal <pascal.weisser.ext@karlstorz.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When specifying the dependencies of do_assemble_fitimage_initramfs the
initramfs image might be built with another multiconfig. This needs to be
taken into account.
The path of the initramfs image also needs to be adapted to handle the
case when it's built with another multiconfig.
(From OE-Core rev: 891d58e9dc00e52f17ddecd4f12fc81c8a3c1bce)
Signed-off-by: Weisser, Pascal <pascal.weisser.ext@karlstorz.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The kernel-fitimage.bbclass evaluates the UBOOT_ENV variable from the
u-boot recipe. Based on this variable an u-boot script might be added to
the fitImage. However, the UBOOT_ENV variable is also used to install
the script as an old u-boot image, usually named boot.scr into the /boot
directory of the target device. This dual usage of one variable leads to
several strange side effects. Some examples:
- If UBOOT_ENV_SUFFIX is set to the default value scr, the boot.cmd
script gets added as a legacy uImage to the fitImage. That does not
look useful.
- If the UBOOT_ENV_SUFFIX is set to e.g. txt the script is not converted
into a legacy uImage and a usable plain text script gets added to the
fitImage. But the same script ends up redundant in /boot.
Another strange detail is that the UBOOT_ENV_BINARY gets set to e.g.
boot.txt for this configuration.
- Appending the script to the u-boot recipe and then hand it over to the
kernel recipe via the staged /boot directory looks like over
complicated. Such kind of over complications and u-boot kernel
inter-dependencies lead to an almost unmaintainable
kernel-fitimage.bbclass.
- A single variable does not allow you to add a text file to the fitImage
and at the same time place boot.scr file in the /boot directory of the
target device.
- It is not documented or obvious how the UBOOT_ENV variable should be
used together with the kernel-fitimage.bbclass.
The commit which introduced this feature (among other features...) is:
https://git.yoctoproject.org/poky/commit/?id=8a2f4e143b52109fbd0ee8d792e327d460b8c1e6
This commit is going to remove the u-boot script part of it.
The removal of this function requires a note in the migration guide.
The migration should be straightforward: If UBOOT_ENV and the
kernel-fitimage.bbclass are used, the u-boot script must now be appended
to the kernel recipe and the new FIT_UBOOT_ENV variable must be used.
(From OE-Core rev: ab7f0b5e3d3612c43f9aab9ea2b7bd554d02859d)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Introduce a new variable FIT_UBOOT_ENV, which allows to add a u-boot
script as a text file to the fitImage. Such a script can be sourced
from the u-boot shell, as documented here:
https://docs.u-boot.org/en/latest/usage/cmd/source.html#fit-image
The kernel-fitimage.bbclass also evaluates the existing UBOOT_ENV
variable and adds the corresponding script to the fitImage. However, the
UBOOT_ENV variable is also used to install the script as an old u-boot
image, usually named boot.scr into the /boot directory of the target
device. These are different use cases which should be handled
independently.
Appending the script to the u-boot recipe and then hand it over to the
kernel recipe via the staged /boot directory leads to complicated task
dependencies. Decoupling the two use cases will also allow to simplify
the implementation by dropping the evaluation of the UBOOT_ENV variable
in the kernel-fitimage.bbclass. But this commit is supposed to be
backward compatible.
(From OE-Core rev: 269605ed053fd8dc7bcbcc04a46c308188115f66)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This class calls d.getVar('DEPLOY_DIR_IMAGE') twice within the same
method, but DEPLOY_DIR_IMAGE variable won't change during the run of
this class, so only retrieve it once.
(From OE-Core rev: 6866da9f3a273ed7217e9edfca299fc2e68b2f75)
Signed-off-by: Koen Kooi <koen.kooi@oss.qualcomm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
ukify tool can show important warnings and even errors
if it fails so capture the logs.
(From OE-Core rev: 6ac326a4f9d19fa154c9ce172a264f55ebe5b1ef)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix a problem with `devtool modify` as suggested by Marcus Flyckt on
the mailing list:
```
I encountered an issue with `do_config` when using `devtool modify`
on `u-boot-imx`.
```
[...]
| cp: cannot stat '[...]/u-boot-imx/2024.04/build/imx8mp_wl400s_defconfig/.config': No such file or directory
| WARNING: exit code 1 from a shell command.
ERROR: Task ([...]/sources/poky/../meta-freescale/recipes-bsp/u-boot/u-boot-imx_2024.04.bb:do_configure) failed with exit code '1'
NOTE: Tasks Summary: Attempted 963 tasks of which 962 didn't need to be rerun and 1 failed.
Summary: 1 task failed:
[...]/sources/poky/../meta-freescale/recipes-bsp/u-boot/u-boot-imx_2024.04.bb:do_configure
Summary: There was 1 ERROR message, returning a non-zero exit code
```
The issue seems to originate from the following lines in
`workspace/appends/u-boot-imx_2024.04.bbappend`:
```
do_configure:append() {
if [ ${@oe.types.boolean(d.getVar("KCONFIG_CONFIG_ENABLE_MENUCONFIG"))} = True ]; then
cp ${KCONFIG_CONFIG_ROOTDIR}/.config ${S}/.config.baseline
ln -sfT ${KCONFIG_CONFIG_ROOTDIR}/.config ${S}/.config.new
fi
}
```
For some reason `KCONFIG_CONFIG_ROOTDIR` does not point to the
correct directory. It gets its value in `uboot-config.bbclass`:
```
if len(ubootconfig) == 1:
d.setVar('KCONFIG_CONFIG_ROOTDIR', os.path.join(d.getVar("B"), d.getVar("UBOOT_MACHINE").strip()))
```
So the main issue is that B gets expanded in this expression, and
then later B gets changed by `externalsrc.bbclass`.
`d.getVar("B", False)` does not solve the issue, however the
proposed change does.
```
- https://lists.yoctoproject.org/g/yocto/topic/109254298#msg64152]
Fixes [YOCTO #15603]
Suggested-by: Marcus Flyckt <marcus.flyckt@gmail.com>
(From OE-Core rev: 57b21065a25100c31515b32fd7c77bde3355d684)
Signed-off-by: Tom Hochstein <tom.hochstein@oss.nxp.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
meta-oe has switched from p7zip to 7zip.
p7zip recipe does not exist anymore and p7zip is provided and rprovided
by 7zip recipe.
Use real provider instead of replaced one.
(From OE-Core rev: 5aa516bfa295d5be919459dfe45f452cdec45e81)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This happens when testimage task runs and bitbake is interupted
twice with ctrl-c/SIGINT:
QMP Available for connection at /home/builder/src/base/repo/meta-arm/build/tmp/.xjik9srq
QMP connected to QEMU at 01/31/25 10:36:19 and took 0.55 seconds
QMP released QEMU at 01/31/25 10:36:19 and took 0.07 seconds from connect
Keyboard Interrupt, closing down...
Second Keyboard Interrupt, stopping...
WARNING: Exiting due to interrupt.
NOTE: Sending SIGTERM to remaining 1 tasks
ERROR: core-image-base-1.0-r0 do_testimage: testimage interrupted, shutting down...
Output from runqemu:
runqemu - INFO - Received signal: 15
runqemu - INFO - Cleaning up
runqemu - INFO - Host uptime: 6230788.40
tput: No value for $TERM and no -T specified
ERROR: core-image-base-1.0-r0 do_testimage: Error executing a python function in exec_func_python() autogenerated:
The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_func_python() autogenerated', lineno: 2, function: <module>
0001:
*** 0002:do_testimage(d)
0003:
File: '/home/builder/src/base/repo/meta-arm/build/../poky/meta/classes-recipe/testimage.bbclass', lineno: 122, function: do_testimage
0118: dump-guest-memory {"paging":false,"protocol":"file:%s.img"}
0119:}
0120:
0121:python do_testimage() {
*** 0122: testimage_main(d)
0123:}
0124:
0125:addtask testimage
0126:do_testimage[nostamp] = "1"
File: '/home/builder/src/base/repo/meta-arm/build/../poky/meta/classes-recipe/testimage.bbclass', lineno: 389, function: testimage_main
0385:
0386: # Show results (if we have them)
0387: if results:
0388: configuration = get_testimage_configuration(d, 'runtime', machine)
*** 0389: results.logDetails(get_json_result_dir(d),
0390: configuration,
0391: get_testimage_result_id(configuration),
0392: dump_streams=d.getVar('TESTREPORT_FULLLOGS'))
0393: results.logSummary(pn)
Exception: AttributeError: 'TestResult' object has no attribute 'logDetails'
ERROR: Logfile of failure stored in: /home/builder/src/base/repo/meta-arm/build/tmp/work/qemuarm64_secureboot-poky-linux/core-image-base/1.0/temp/log.do_testimage.2771735
Summary: 1 task failed:
/home/builder/src/base/repo/meta-arm/build/../poky/meta/recipes-core/images/core-image-base.bb:do_testimage
(From OE-Core rev: c0d864a7007adbdf332da62e89c73630b3e01639)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Recipes are much more readable with whitespace around the assignment operators.
Fix various assignments in OE-Core to show this is definitely the preferred
formatting.
(From OE-Core rev: 30ea609d3357fb3de911f2f6a5e6856c151b976a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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: 6eeb832f73ffb48f5f05dc47191f60e4599e640f)
Signed-off-by: Pedro Silva Ferreira <Pedro.Silva.Ferreira@criticaltechworks.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In both true/false cases, we will cp the file, so move the invocation
after the if body.
In addition, misleading comment has been removed.
(From OE-Core rev: fdd7fec29314b3cd07a98943bbbf6996877e90f4)
Signed-off-by: Slawomir Stepien <sst@poczta.fm>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 <richard.purdie@linuxfoundation.org>
Although rust differs between compiling (--> 'rust-cc' wrapper) and
linking (--> 'rust-ccld' wrapper), some core crates are using only the
'rust-cc' wrapper to check for available compiler options [1] and
libraries [2].
Not having LDFLAGS can break the build in subtle ways. E.g. 'cargo-native'
can fail to build with
| = note: .../hosttools/ld: .../liblibz_sys-....rlib(deflate.o):
| relocation R_X86_64_32S against hidden symbol `_length_code' can not be used when making a PIE object
because it does not find '-lz' (added by "DEPENDS = zlib") and builds
a static libz.a with missing PIC flags.
Add LDFLAGS to the 'build-rust-cc' wrapper as it is done already for
the target one.
[1] https://github.com/rust-lang/cc-rs/pull/1322
[2] 12a32798c6/build.rs (L228-L234)
(From OE-Core rev: 49b37575b548f0ab082c700f91fdd856740dc829)
Signed-off-by: Enrico Scholz <enrico.scholz@sigma-chemnitz.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Ross Burton <ross.burton@arm.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
Fixes: 5e12dc911d0c ("u-boot: Rework signing to remove interdependencies")
Reviewed-by: Adrian Freihofer <adrian.freihofer@siemens.com>
(From OE-Core rev: 259bfa86f384206f0d0a96a5b84887186c5f689e)
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The idea of the base class dependency is to say "yes, I need a C cross compiler"
and this was never meant to be gcc specific. Looking at the codebase, whilst we
code triplets into this, it does overcomplicate things as there are only ever
limited, "target", "sdk" and the class extended versions like mutlilib.
After much thought, we can simplify this to virtual/cross-cc and virtual/nativesdk-cross-cc.
This lets us remove the "gcc" specific element as well as removing the over
complicated triplet usage.
At the same time, change the much less widely used "g++" variant to "c++" for
similar reasons and remove the triplet from virtual/XXX-binutils too.
Backwards compatibility mappings could be left but are just going to confuse
things in future so we'll just require users to update.
This simplification, whilst disruptive for any toolchain focused layers, will
make improved toolchain selection in the future much easier.
Since we no longer have overlapping variables, some code for that can just
be removed. The class extension code does need to start remapping some variables
but not the crosssdk target recipe names.
This patch is in two pieces, this one handles the renaming with the functional
changes separate in a second for easier review even if this breaks bisection.
(From OE-Core rev: 4ccc3bc8266c327bcc18c9a3faf7536210dfb9f0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The git commit hashes for the kernel checkout are not reproducible under
certain conditions:
- If the git repository is initialized on an archive (rather than a
git), the initial git commit not only has the current user name set,
it also uses the current system time as committer and author date.
This will affect the initial git hash and thus all subsequent ones.
- The patches applied by the kern-tools have a valid author and date.
However, their committer again depends on the user building the BSP.
This is an issue, for example, if one compiles a kernel with
CONFIG_LOCALVERSION_AUTO enabled where the commit hash lands into the
kernel and thus the package version. This not only makes the package
version non-reproducible, but also leads to version mismatches between
kernel modules built against a fresh kernel checkout and the kernel
retrieved from the sstate cache.
The class uses 'check_git_config' from utils.bbclass, but this only sets
the git user and only if none existed before. Thus it doesn't really
help here.
Since in Git the committer information can be set only from the
environment variables GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL, and
GIT_COMMITTER_DATE, we introduce a helper function to set those and
apply the author settings in the same way.
As values simply use PATCH_GIT_USER_NAME, PATCH_GIT_USER_EMAIL (from
patch.bbclass) and SOURCE_DATE_EPOCH.
For convenience, put the new helper 'reproducible_git_committer_author'
into utils.bbclass next to 'check_git_config' so others can use it, too.
Using this helper in kernel-yocto.bbclass makes the committer and author
date/name/email for the initial commit reproducible, as well as the
committer name/email for the patches applied with kern-tools.
For debugging purpose, allow disabling the reproducibility features by
setting KERNEL_DEBUG_TIMESTAMPS to "1".
Suggested-by: Felix Klöckner <F.Kloeckner@weinmann-emt.de>
(From OE-Core rev: aab4517b4649917abd519ea85a20fd9d51bf3d99)
Signed-off-by: Enrico Jörns <ejo@pengutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Run systemctl preset-all with --global flag so user unit's are enabled
the same way system units are.
(From OE-Core rev: cdc3b3028f6d71788b5fdd99436f69fbf18f613e)
Signed-off-by: Artur Kowalski <arturkow2000@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Handle user units in a manner similar to system units where possible.
Not everything is supported by systemd, but systemd limitations only
affect runtime package management - during update user services are not
reloaded/restart and each user must re-login or manually restart
services.
(From OE-Core rev: ce62b88d8f71368e356b6409ada46a34a6017ddf)
Signed-off-by: Artur Kowalski <arturkow2000@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since SYSTEMD_SERVICE_ESCAPED may contain both system and user services
we need to filter out user services in call to systemctl. Introduce
helper systemd_filter_services() which takes space-separated list of
services and returns services of requested type.
(From OE-Core rev: ec548b274d56b2c7a2663b70200df95a49e7452c)
Signed-off-by: Artur Kowalski <arturkow2000@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously user units were handled the same way as system units, that
is all preset files were created in system-preset directory, but user
presets should be in user-preset directory.
(From OE-Core rev: 0218542d80723ec314a648af8e9649806c3a51aa)
Signed-off-by: Artur Kowalski <arturkow2000@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
systemd_service_searchpaths accepts boolean value indicating whether we
are dealing with system or user units and returns search paths
accordingly.
Previously search path list was created in systemd_check_services() but
following commits will introduce additional places. The
systemd_service_searchpaths helper function is meant to reduce code
duplication.
(From OE-Core rev: 9a89d36932dda306b3c2cf10771647eabc267769)
Signed-off-by: Artur Kowalski <arturkow2000@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Factor out the logic into systemd_service_path(). This will be needed by
following commits to avoid code duplication.
(From OE-Core rev: d383e18138050490f3dcb95377f63a2a31c3149f)
Signed-off-by: Artur Kowalski <arturkow2000@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We already search for system units ${sysconfdir}/systemd/system but we
don't search for user units in corresponding directory under ${sysconfdir}.
Keep the behaviour consistent so that both unit types are searched in
${systemd_{system,user}_unitdir} and ${sysconfdir}/systemd/{system,user}.
(From OE-Core rev: df1cdf1bf4cd7d9f17c6a02538057ccfc2efba64)
Signed-off-by: Artur Kowalski <arturkow2000@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
