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>
Rework the anon Python so that it doesn't expect to find non-MLPREFIXed FILES
overrides which are then mapped into MLPREFIXed versions, this allows the
apparent hardcoding of boost-{test,serialization} to be written more naturally
(and is significantly less surprising).
With this, and a change to lookup ${BPN} when generating split package names,
generating an explicitly versioned boost package (e.g. "boost-1.82") alongside
the main boost package ("boost") can be done by copying/renaming the older
recipe. This is useful when upstream code hasn't yet been ported to newer
boost and an older version is required.
(From OE-Core rev: b0770990a8b332dd2de802091164c9506882a465)
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Due to we have upgraded go to 1.24.0, we should also bump GOVERSION
to fix preferred version warning
...
WARNING: preferred version 1.22% of go not available (for item go)
WARNING: versions of go available: 1.24.0
...
(From OE-Core rev: 939449cfcb4a920132145d2ad1212bac3acb1baa)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.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>
In upstream commit [cmd: remove support for GOROOT_FINAL][1], it clear
GOROOT for func ld when -trimpath is used
But it missed to do the same thing for share libarary linking which caused
building go-runtime failed with buildpath issue
|ERROR: go-runtime-1.23.4-r0 do_package_qa: QA Issue: File /usr/lib/go/pkg/
linux_amd64_dynlink/libstd.so in package go-runtime contains reference to
TMPDIR [buildpaths]
This commit applied a patch to clear GOROOT for func ldShared when
-trimpath is used and add option -trimpath to go-runtime build
[1] 507d1b22f4
[2] 507d1b22f4 (diff-cab5921f94f2667bb0bc1b935d2d46b4c03541b4351b33438ab7290b94dea212R669)
(From OE-Core rev: f7b05ebfdc6504a8360741f273163ef7fbb11b10)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In rare cases BUILDNAME can seemingly be None outside of heartbeat events
which leads to UnboundLocalErrors as bsdir and taskdir aren't defined.
Skip the code in these cases rather than generate tracebacks which cause
bitbake server to exit.
(From OE-Core rev: 0f74d804ba0daf7e8bd6481597740b9d89821414)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Spamming the build host's syslog with useradd information during image creation
isn't great. Add a patch to disable that.
It may be possible to convince upstream to make it a configure option but for
now the patch is trivial and reduces host impact to the logs.
(From OE-Core rev: a52572886e60e4aff9d54b57bf45a301e1dec1ee)
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>
In boost 1.85 a charconv implementation in c++11 was added
[https://www.boost.org/doc/libs/master/libs/charconv/doc/html/charconv.html]
This is already used in real life and e.g. building the current wesnoth release fails with:
| /usr/src/debug/wesnoth/1.19.9/src/utils/charconv.hpp:57:(.text+0x238b): undefined reference to `boost::charconv::to_chars(char*, char*, double, boost::charconv::chars_format)'
Add charconv to BOOST_LIBS to provide the library
(From OE-Core rev: 42d14c130f2159c1d9ea314acc93142e6ccb2761)
Signed-off-by: Markus Volk <f_l_k@t-online.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
After the removal of BSD-4-Clause from LICENSE in commit 362435b0aec
(libbsd: Drop licenses that were removed upstream), the licenses for all
packages match the licenses for the recipe. Thus there is no longer any
reason to explicitly specify the package licenses.
(From OE-Core rev: 0c1b68fefe41d92eaa87578ff644bc254e078f9a)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
0001-automake-Add-default-libtool_tag-to-cppasm.patch was upstreamed in
1.16[1].
0003-build-fix-race-in-parallel-builds.patch wasn't directly applied,
but a fix for the same problem was merged in 1.17[2].
[1] automake dc67b18d "automake: Add default libtool_tag to cppasm"
[2] automake 5d022858 "build: fix race in parallel builds"
(From OE-Core rev: 386feebe8221c5ef0f87d371dc3e79bfdee1a3bb)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Drop 0001-sched_attr-Do-not-define-for-glibc-2.41.patch as it has been
merged upstream.
* Skip statmount02 case which does not work on musl.
(From OE-Core rev: 5d72185e65aa0d9012913d9d095caceada7799d7)
Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This reverts commit 7adaec468d.
It does not seem to fix the issue it was supposed to fix.
Additionally it breaks code which decides in full/partial update,
because it manipulates timestamp that code is relying on.
(From OE-Core rev: ebc65fdddd7ce51f0f1008baa30d0ae7918ae0bb)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
psplash-systemd.service depends on FIFO created by psplash-start@fb0.service.
This FIFO can be removed due to signals or /dev/fb0 related errors
when psplash-start@fb0.service exits. This exit can happen
when psplash-systemd.service is being started. Thus ignore
all errors in psplash-systemd.service startup.
There are too many ways things can go wrong and all of them
leave open race conditions unless a single process handles
all of the psplash usecases including progress bar updates.
(From OE-Core rev: 580ae81e102bf999cb89f05430c737210253d90a)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
oe-core no longer supports OE_IMPORTS[1], so remove the documentation.
[1] oe-core 1f56155e ("base: Switch to use addpylib directive and
BB_GLOBAL_PYMODULES")
(From OE-Core rev: d1388e0958c8013179a948e08bf989c07f8654ca)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The current code for multiple argument passing is horrible. Tweak the
multiprocess_launch function to only convert to a tuple if it isn't already
one, which means we can then use function arguments in a standard way.
(From OE-Core rev: 7c99f90079e722764ebdc30e8d0e781454b3a51a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This prevented package_qa sstate from being reusable unless host uid/gid
values would match exactly (and they unfortunately do on the yocto autobuilder
worker machines which all share a 'pokybuild' user).
I noticed this when testing CDN sstate reuse, which otherwise works well.
(From OE-Core rev: 6ea8b4b10b0549c858427a8411bf2a4cd5c0eb7b)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is an OpenEmbedded-specific variable that is no longer used[1].
[1] oe-core 1f56155e ("base: Switch to use addpylib directive and
BB_GLOBAL_PYMODULES")
(Bitbake rev: 34bfa55a3c14f5d1d6bb3e31b747906fa7cb99c3)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
roman-numerals-py is a module providing utilities for working with
well-formed Roman numerals. python3-sphinx relies on this now, so add it
as a recipe.
(From OE-Core rev: 43b4e995769de54e47b0a98ce841b143a877f87d)
Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Due to some musl build issues with 2025.01.0, we skip this version and
move forward to 2025.02.0 directly.
Changes in 2025.01.0
--------------------
* Added LLVM/Clang support for the sandbox architecture.
* Enabled command execution from the sandbox command line.
* Improved TFTP with dentry caching and default-disabled window size.
* Introduced hardening features: register zeroing, stack variable
initialization, and malloc buffer zeroing.
* Enhanced AM625 support with network support, watchdog driver, and
bootsource detection.
Changelog: https://lore.barebox.org/barebox/Z4oUYdHXEAtnkySC@pengutronix.de/T/#u
Changes in 2025.02.0
--------------------
* Several memory overflow fixes for different filesystems.
* Added 'Security Considerations' guideline:
https://www.barebox.org/doc/latest/user/security.html
* Added FIT image build target for booting barebox 2nd stage from a
U-Boot with the bootm command (for development purpose).
* AM625 1st stage support including DDR, clock and power domain drivers.
* Added support for the AM625-SK board
* Added support for the Pine64 PineTab 2 (Rockchip)
* CVE's fixed:
- CVE-2025-26721
- CVE-2025-26722
- CVE-2025-26723
- CVE-2025-26724
- CVE-2025-26725
Changelog: https://lore.barebox.org/barebox/Z7iJIYuoxZAja_F7@pengutronix.de/T/#u
(From OE-Core rev: 8a526783e31d9fbb65ffdf234607fa6229543f8d)
Signed-off-by: Enrico Jörns <ejo@pengutronix.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add "test_uboot_atf_tee_fit_image" test caste to check u-boot FIT image and
Image Tree Source(ITS) are built and the ITS has the correct fields.
Add "test_sign_standalone_uboot_atf_tee_fit_image" test case to check if u-boot
FIT image and Image Tree Source (ITS) are created and signed correctly for the
scenario where only the u-boot proper fitImage is being created and signed.
Currently, ATF and TEE(optee-os) recipes are placed in meta-arm layer.
OpenEmbedded-Core is a basic and core meta layer. To avoid OpenEmbedded-core
depends meta-arm, both test cases are used dummy images for testing.
(From OE-Core rev: 92e51452f8831f74e0907b960135eef8cecd012a)
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 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>
The patch was removed from SRC_URI but not deleted from the directory
tree.
Fixes: 3291a8fa ("barebox: upgrade 2024.10.0 -> 2024.12.0")
(From OE-Core rev: 0a3c4e3550cb52b4f42858ff6cc3356c96f5a6bf)
Signed-off-by: Enrico Jörns <ejo@pengutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rely on host-provided coreutils and make.
openssl-native is not needed either, as the build scripts
use crypto functionality via python.
Python 3.11+ is needed by the python build scripts, which is
ensured by "inherit python3native".
(From OE-Core rev: 34fc028a8a3a6628b11c6ee67676532012f55f47)
Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Patch '0001-respect-GIT_CEILING_DIRECTORIES.patch' is no longer required
as it's upstream in 979d79301da6.
Changelog (https://github.com/pypa/setuptools-scm/blob/main/CHANGELOG.md):
Added
- fix#960: add a --force-write-version-files flag for the cli
Changed
- fix#950: ensure to pass encodings to io usage
- fix#957: add subprocess timeout control env var
- add sp-repo-review pre-commit hook
Fixed
- fix#1018: allow non-normalized versions for semver
- fix#1103: respect GIT_CEILING_DIRECTORIES when trying to find git toplevels
- fix#1081: add name normalized pipx entrypoint
- fix#1080: clean pdm from PYTHONPATH to protect mercurial
(From OE-Core rev: 6bab759c00b44fc2793e095f991975b7eebf360f)
Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This update is required for latest versions of packages such as sphinx
to build with flit, otherwise you encounter errors like:
| File "/home/tgamblin/workspace/yocto/poky/build/tmp/work/core2-64-poky-linux/python3-sphinx/8.2.1/recipe-sysroot-native/usr/lib/python3.13/site-packages/flit_core/config.py", line 444, in _check_type
| raise ConfigError(
| "{} field should be {}, not {}".format(field_name, cls, type(d[field_name]))
| )
| flit_core.config.ConfigError: license field should be <class 'dict'>, not <class 'str'>
|
| ERROR Backend subprocess exited when trying to invoke get_requires_for_build_wheel
Changelog (https://github.com/pypa/flit/blob/main/doc/history.rst#version-311):
- Support for SPDX license expressions and multiple license files, as
detailed in PEP 639:
license = "BSD-3-Clause"
license-files = ["LICENSE"]
For now, only a single license identifier is allowed. More complex
expressions describing multiple licenses & expressions may be
supported in a future version.
- The metadata format in produced packages is now version 2.4, to
support the expanded license information.
(From OE-Core rev: 268f1c96c70334d6a882d00e895e1f0c72cfa36f)
Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
systemd's sysusers.d/systemd-remote.conf contains the user
"systemd-journal-remote" [1]. This file is currently not part of any
specific package.
To make this match the corresponding USERADD_PARAM:${PN}-journal-remote
for the same user, move the file to the correct package.
This prevents warnings in case PACKAGECONFIG contains "microhttpd" but
systemd-journal-remote is not installed, such as:
WARNING: some-image-1.0-r0 do_rootfs: User systemd-journal-remote has never been defined
[1] https://github.com/systemd/systemd/blob/v257.3/sysusers.d/systemd-remote.conf
(From OE-Core rev: 2d50d3595502e65e3b0997800a6dc60ca3e10100)
Signed-off-by: Bastian Krause <bst@pengutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
wayland-protocols 1.41 is the minimum requirement for the upcoming gtk4 release
(From OE-Core rev: acbdd2d76186a685b4283b41e3ce73b4d4d29d43)
Signed-off-by: Markus Volk <f_l_k@t-online.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The location of rpc.statd is /usr/sbin instead of /sbin.
(From OE-Core rev: 19494e414429b74d2a15b32f21b1b3067d3a41b2)
Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When using openssl with some pkcs#11 plugin module, one (usually)
needs to set the OPENSSL_CONF environment variable
appropriately, and e.g. invoke openssl as
openssl dgst -engine pkcs11 -keyform engine ...
However, when putting that logic in a bitbake recipe and depending on
openssl-native (and the recipe providing the pkcs#11 engine and the
associated configuration file), the value of OPENSSL_CONF is
unconditionally overridden by the wrapper script.
If openssl was invoked directly in the task function, I could probably
call "openssl.real" instead, but then I miss the proper settings of
the other four variables, which I'd then also have to repeat in my
recipe. Moreover, sometimes openssl is only called via some helper
script (for example rpi-eeprom-digest for signing bootloader images
for RPi), and it's not reasonable to patch every such script to call
openssl.real.
So rewrite the wrapper such that if a variable is already set in the
environment before openssl is invoked, preserve its value.
(From OE-Core rev: 5582ec9d3a21c546b799d2f6d4928f5e1d19eb0a)
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A long time ago, the environment.d-openssl.sh file was shared between
openssl 1.0 and openssl 1.1 recipes, and sed was used to make the path
right for the 1.1 version. Nowadays, with only a single recipe, this
is a bit roundabout, so just use the proper path in the file directly.
(From OE-Core rev: 291fe7db623b0974e7831e908e91b1f1259e0506)
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now that autotools isn't searching for every m4 file the configure fails.
This is because freetype only uses autoconf and has a manual autogen.sh
script that passes -I. itself.
As we don't call that script, pass -I . to autoreconf ourselves.
(From OE-Core rev: 1a26f800d5fdadc990b73d17e1c373f3e8fba879)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch to change how autotools pulls in macros is no longer needed.
(From OE-Core rev: 9a550b4154d3e501ed6555694dc95b31df527637)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The bulk of these recipes used acpaths to work around argument list
limits as we passed the full path to every directory. As this behaviour
no longer happens we can remove these workarounds.
(From OE-Core rev: c4336f1b0da981b3ea396b17779b67898bceccef)
Signed-off-by: Ross Burton <ross.burton@arm.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>
Noteworthy changes in version 1.24.2 (2025-02-10)
-------------------------------------------------
Take care: This version is from a legacy branch of gpgme created
just before we split out the C++, Qt, and Python bindings to
separate repositories and bumped the version number up to 2.0.
* Fix regression for RSA in gpgme_pubkey_algo_string. [T7508]
* Prevent failing tests after 2027-05-15. [T7471]
[c=C44/A33/R2 cpp=C27/A21/R2 qt=C21/A6/R2]
Release-info: https://dev.gnupg.org/T7524
See NEWS in https://www.gnupg.org/ftp/gcrypt/gpgme/gpgme-1.24.2.tar.bz2 for details
(From OE-Core rev: 90b637936b601c7af4c708d92562f098620a0d6a)
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>
When multiple recipes are built in parallel, Ccache sometimes refuses to
lookup some objects in cache, leading to undesired cache misses. The
root cause of this is an interaction between the way how bitbake
constructs a recipe sysroot and Ccache's `include_file_ctime` check.
Whenever bitbake creates a recipe's sysroot it hardlinks the files
provided by a recipes dependencies. Adding a hardlink to a file changes
it's ctime which in turn leads Ccache to believe that the file was
modified thus aborting the cache lookup.
To avoid this situation, add `include_file_ctime` to the list of checks
that should be ignored using the Ccache sloppiness configuration option
[1].
Example of a log entry that Ccache ignores a file:
/
|recipe-sysroot/usr/include/bits/pthread_stack_min.h had status change
|near or after invocation (ctime 1739822508.107677255, invocation time
|1739822507.970071107)
\
1 - https://ccache.dev/manual/4.10.2.html#config_sloppiness
(From OE-Core rev: 4899698297c7783e02aba5388e0469cc83bd2f70)
Signed-off-by: Fabio Berton <fabio.berton@criticaltechworks.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
