It's not currently possible to set the build tree to be somewhere we
control, but we know it will always be in the build directory alongside
the setup.py so we can [cleandirs] that.
MJ: helps with build/lib directory being added when a recipe is rebuilt
in the same WORKDIR multiple times, e.g.:
Just rebuilding python3-tqdm in the same TMPDIR after cherry-picking this:
$ buildhistory-diff -p buildhistory build-minus-1 | grep PKGSIZE
python3-google-auth/python3-google-auth: PKGSIZE changed from 11752510 to 1315694 (-89%)
python3-googleapis-common-protos/python3-googleapis-common-protos: PKGSIZE changed from 7108856 to 794024 (-89%)
$ wc -l python3-google-auth/2.29.0*/image/usr/lib/python3.12/site-packages/google_auth-2.29.0.dist-info/RECORD
554 python3-google-auth/2.29.0-old/image/usr/lib/python3.12/site-packages/google_auth-2.29.0.dist-info/RECORD
66 python3-google-auth/2.29.0/image/usr/lib/python3.12/site-packages/google_auth-2.29.0.dist-info/RECORD
$ wc -l python3-googleapis-common-protos/1.63.0*/image/usr/lib/python3.12/site-packages/googleapis_common_protos-1.63.0.dist-info/RECORD
1166 python3-googleapis-common-protos/1.63.0-old/image/usr/lib/python3.12/site-packages/googleapis_common_protos-1.63.0.dist-info/RECORD
134 python3-googleapis-common-protos/1.63.0/image/usr/lib/python3.12/site-packages/googleapis_common_protos-1.63.0.dist-info/RECORD
(From OE-Core rev: a0151ab56cf3fcaa6587e240b5454fed5315a534)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Martin Jansa <martin.jansa@gmail.com>
(cherry picked from commit f3854f4f60801e3b6788bee3a0a1850fc498d536)
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Paul Barker <paul@pbarker.dev>
We do builds in a separate directory in this class, so add it to cleandirs
to ensure that it is empty.
(From OE-Core rev: 9a32956dd5dcbcc380780bc25e4303280f2ca9f9)
Signed-off-by: Ross Burton <ross.burton@arm.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 2575adeceedae72f6359c0a35ec5c5325a4ec363)
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Paul Barker <paul@pbarker.dev>
With the current solution, using a separate task
(do_create_kernel_config_spdx) there is a dependency issue. Sometimes
the final rootfs SBOM does not contain the CONFIG_ values.
do_create_kernel_config_spdx is executed after do_create_spdx which
deploys the SPDX file. do_create_kernel_config_spdx calls
oe.sbom30.find_root_obj_in_jsonld to read from the deploy directory,
which is OK, but the do_create_kernel_config_spdx ends up writing to
this deployed file (updating it).
do_create_rootfs_spdx has an explicit dependency to all do_create_spdx
tasks, but there is nothing that prevents executing
do_create_kernel_config_spdx after do_create_rootfs_spdx.
To fix it, instead, now read from the workdir, and write to the
workdir, and do the processing from the do_create_spdx task:
we append to the do_create_spdx task.
Furthermore, update oeqa selftest to execute do_create_spdx instead
of removed function.
Also only execute this task if create-spdx-3.0 was inherited,
previously this code could be executed if create-spdx-2.2 is
inherited.
(cherry picked from commit 8417f4a186e78a9d309541f5d0e711178bb80488)
Fixes: 1fff29a04287 ("kernel.bbclass: Add task to export kernel configuration to SPDX")
(From OE-Core rev: 22e8bc2bcfe762c83c00b73a33384e63548e82c0)
Signed-off-by: Benjamin Robin (Schneider Electric) <benjamin.robin@bootlin.com>
Reviewed-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Paul Barker <paul@pbarker.dev>
CVE-2021-36217 is rejected, and should no longer be referenced.
CVE-2021-36217 is a duplicate of CVE-2021-3502 which is already
referenced in the local-ping.patch.
The CVE database indicates the following reason:
ConsultIDs: CVE-2021-3502. Reason: This candidate is a duplicate of
CVE-2021-3502. Notes: All CVE users should reference CVE-2021-3502
instead of this candidate. All references and descriptions in this
candidate have been removed to prevent accidental usage.
(cherry picked from commit bf41240132e2efa6b46aab46290eed9c53e312e9)
(From OE-Core rev: 128af716be75ec76203f1d34a8448741e6573d9e)
Signed-off-by: Benjamin Robin (Schneider Electric) <benjamin.robin@bootlin.com>
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Paul Barker <paul@pbarker.dev>
This patch fixes an issue when checking if a varflag
can be safely excluded.
BB_SIGNATURE_EXCLUDE_FLAGS lists variable flags that
can be safely excluded from checksum and dependency
data for keys in the datastore.
When bitbake checks if a varflag must be excluded it
checks if the varflag name is part of the string stored
in BB_SIGNATURE_EXCLUDE_FLAGS.
As an example, if the varflag 'filename' is in
BB_SIGNATURE_EXCLUDE_FLAGS, the varflag 'name'
will also be excluded because the check will return 'True'
when checking if the varflag is part of the string with
the varflags to exclude.
To fix this issue the string from BB_SIGNATURE_EXCLUDE_FLAGS
is converted to a list before checking if a varflag is part of it.
(Bitbake rev: 0880963fea4d91a034e4a6e007d23f98658ab986)
Signed-off-by: Marcio Henriques <marcio.henriques@ctw.bmwgroup.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 8ab71d0ce302521da6a7e18c887cd85d9a94e8ee)
Signed-off-by: Jeremy Rosen <jeremy.rosen@smile.fr>
Signed-off-by: Paul Barker <paul@pbarker.dev>
Add local HTTP server tests for Wget.checkstatus() redirects. They check
that Authorization is kept for same-origin redirects and dropped when the
target has a different origin.
(Bitbake rev: 2b0f7fb5f54a415d851038ba7cb836b18289e000)
Signed-off-by: Anders Heimer <anders.heimer@est.tech>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit c687d42b81b17e7a2399099cab0f1a6aafcf6520)
Signed-off-by: Jeremy Rosen <jeremy.rosen@smile.fr>
Signed-off-by: Paul Barker <paul@pbarker.dev>
FixedHTTPRedirectHandler copies request headers when checkstatus()
follows a redirect, including Authorization from SRC_URI or .netrc.
Keep same-origin redirects unchanged, but drop Authorization and Cookie
for different-origin targets (scheme, host and effective port), following
RFC 9110 redirect guidance for resource-specific headers. This only
affects the Python checkstatus() path; normal wget downloads are
unchanged.
(Bitbake rev: 348edecf9e663c3b432c6cf76c3f911354e83487)
Signed-off-by: Anders Heimer <anders.heimer@est.tech>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 1019d5a5c42c672ea673ae9d22363d626b57ccb9)
Signed-off-by: Jeremy Rosen <jeremy.rosen@smile.fr>
Signed-off-by: Paul Barker <paul@pbarker.dev>
urllib2.HTTPRedirectHandler.redirect_request doesn't handle HTTP reponse
code 308 (Permanent Redirect). This was fixed in c379bc5 but can't be
worked around without copying the entire redirect_request() method.
When we can depend on Python 3.13, FixedHTTPRedirectHandler can be
removed.
(Bitbake rev: 5ca465fc4ac49dc2f4172c83da651f316c0b4a7c)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
(cherry picked from commit 365829a2803b954ee6cb0364749551a91d806075)
Signed-off-by: Jeremy Rosen <jeremy.rosen@smile.fr>
Signed-off-by: Paul Barker <paul@pbarker.dev>
This is no more than a backport of the current (i.e., from 'master')
version of this same chunk in save_debugsources_info(), where BP is used
instead of PF to form the path to the kernel sources.
This replacement in package.py is followed by a similar change in
meta/classes/create-spdx-2.2.bbclass, so that 'BP' is also used in
spdx_get_src() and we don't face any regressions in SPDX v2.2. As a
matter of fact, SPDX3 also uses 'BP' in get_patched_src() (from
spdx_common.py).
Overall, this backport ensures a coherence between Scarthgap and master,
namely regarding the how the kernel sources are provided by package.py
and consumed by SPDX v2.2 and 3.0.
(From OE-Core rev: dd74c1388d5bfefd2adcdb6abd622297138e2eb1)
Signed-off-by: João Marcos Costa (Schneider Electric) <joaomarcos.costa@bootlin.com>
Co-authored-by: Benjamin Robin (Schneider Electric) <benjamin.robin@bootlin.com>
Signed-off-by: Jeremy Rosen <jeremy.rosen@smile.fr>
Signed-off-by: Paul Barker <paul@pbarker.dev>
Running 'devtool modify -n' on a kernel recipe that inherits
'kernel-yocto' can unintentionally corrupt an existing Git repo or
worktree.
The work-shared optimization introduced in 3c3a9bae ("devtool/standard.py:
Update devtool modify to copy source from work-shared if its already
downloaded") is not skipped when '--no-extract' ('args.no_extract') is set.
As a result, for kernel builds where STAGING_KERNEL_DIR was already
populated when running 'devtool modify -n', the existing source tree is
overwritten (via oe.path.copyhardlinktree()) with the contents of
STAGING_KERNEL_DIR.
Fix by adding 'and not args.no_extract' to the kernel-yocto guard
condition.
(cherry picked from commit d383ea37e4987ecabe011226f1a8e658a52ede12)
(From OE-Core rev: 7ac858c9fe1c08cf6fd91122d351c262a2a953cf)
Signed-off-by: Enrico Jörns <ejo@pengutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Jeremy Rosen <jeremy.rosen@smile.fr>
Signed-off-by: Paul Barker <paul@pbarker.dev>
Pulls in fixes to rename/renameat/renameat2:
Changqing Li (1):
renameat2/renameat: only ignore when both old and new path are not in PSEUDO_INCLUDE_PATHS
Mark Hatle (4):
run_tests.sh: Allow the user to specify specific tests to run
tests: Add mv then hardlink testing
rename: only ignore when both old and new path are not in PSEUDO_INCLUDE_PATHS
Makefile.in: Bump version to 1.9.7
(From OE-Core rev: e2864ea1ac022e43af92badc701fa1e2a9571f46)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 17567738711d525d9f2b85e54ace2048901e4c34)
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Paul Barker <paul@pbarker.dev>
Pulls in the changes:
* Makefile.in: Bump version to 1.9.6
* pseudo_util.c: Fix symlink processing for symlinkat and related
* test: Add test symlinkat and related
* ports/unix: realpath: Fix chroot processing
* test: Add test cases for canonicalize functions
* ports/unix: fts_open: Fix chroot behavior
* ports/unix: fts_*: Certain functions were incorrectly returning stat data
* test: Add fts test case
* test: Add test for linkat chroot path stripping
* linkat: Avoid a segmentation fault
* Only copy xattrs on a rename if it's cross-filesystem
(From OE-Core rev: 1414f3513099a9a956ec4f602354aa00008e2aff)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 50e769a598e79ed4600f7362d5f40799a48f9273)
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Paul Barker <paul@pbarker.dev>
This adds a wrapper for the __open_2 function
This was breaking shadow and the real reason for the open() call changes.
Add the missing wrapper to properly fix this.
(From OE-Core rev: 876e6497f3323d74d9ac8ce303ed5165a7fda283)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 8ea63d320aba32d3894cace9e71e850bdff1d6b2)
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Paul Barker <paul@pbarker.dev>
Update to pull in a full openat2 wrapper which works on Fedora 44.
This update includes the commits:
* Makefile.in: Bump version to 1.9.4
* test: Add renameat2 test cases
* test: Add openat2 test cases
* makewrappers/openat2: Add preserve_path option
* openat2: Implement openat2 wrapper
* ports/linux/guts/renameat2.c: Add comment why this isn't implemented
* Add b4 configuration
* pseudo_setupenvp: Handle malloc failure safely
* pseudo_setupenvp: Allocate space for new env vars if needed
(From OE-Core rev: 9075b66e1f9161407056924954b3d5507f6d8384)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit b2bd1d114fafe1e797149e02e4c08194d529cfde)
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Paul Barker <paul@pbarker.dev>
The 2026b release contains the following changes:
Briefly:
British Columbia moved to permanent -07 on 2026-03-09.
Some more overflow bugs have been fixed in zic.
Changes to future timestamps
British Columbia’s 2026-03-08 spring forward was its last
foreseeable clock change, as it moved to permanent -07 thereafter.
(Thanks to Arthur David Olson.) Although the change to permanent
-07 legally took place on 2026-03-09, temporarily model the change
to occur on 2026-11-01 at 02:00 instead. This works around a
limitation in CLDR v48.2 (2026-03-17). This temporary hack is
planned to be removed after CLDR is fixed.
Changes to code
zic no longer mishandles a last transition to a new time type.
zic no longer overflows a buffer when generating a TZ string like
"PST-167:59:58PDT-167:59:59,M11.5.6/-167:59:59,M12.5.6/-167:59:59",
which can occur with adversarial input. (Thanks to Naveed Khan.)
zic no longer generates a longer TZif file than necessary when
an earlier time zone abbreviation is a suffix of a later one.
As a nice side effect, zic no longer overflows a buffer when given
a long series of abbreviations, each a suffix of the next.
(Buffer overflow reported by Arthur Chan.)
zic no longer overflows an int when processing input like ‘Zone
Ouch 2147483648:00:00 - LMT’. The int overflow can lead to buffer
overflow in adversarial cases. (Thanks to Naveed Khan.)
zic now checks for signals more often.
(From OE-Core rev: 37dab321242e06d2940c4221e4a13e68265d696f)
Signed-off-by: Ankur Tyagi <ankur.tyagi85@gmail.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
(cherry picked from commit dda7d55396e0c5258cba58af7e990ab3813bf108)
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Paul Barker <paul@pbarker.dev>
Regenerated to fix this warning:
WARNING: linux-yocto-6.6.127+git-r0 do_cve_check: Kernel CVE status needs updating: generated for 6.6.123 but kernel is 6.6.127
$ ./meta/recipes-kernel/linux/generate-cve-exclusions.py .../cvelistV5/ 6.6.127 > meta/recipes-kernel/linux/cve-exclusion_6.6.inc
Generated at 2026-05-27 12:02:49.732909+00:00 for kernel version 6.6.127
From cvelistV5 cve_2026-05-27_0900Z
(From OE-Core rev: d0d02d0f45b4c5108ae648fb16d2a2a0dc1ae0e7)
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Paul Barker <paul@pbarker.dev>
While working on splitting-out wic from oe-core, on my openSUSE Leap
16.0 machine, the moment I split wic out, 2 oe-selftests always failed
with 100% reproducibility:
- wic.ModifyTests.test_wic_cp_ext
- wic.Wic2.test_expand_mbr_image
In both cases the symptom is the same: the filesystem has inode tables
that are completely zeroed out. Both issues are linked together to the
same underlying fault.
FilemapSeek._get_ranges() is a generator. Due to the nature of finding
each hole/data extent one at a time using the lseek() system call,
it calls os.lseek() on a raw file descriptor, then yields, then the
caller, sparse_copy(), calls file.seek() + file.read() on a Python
BufferedReader wrapping that same fd — then the generator resumes and
calls os.lseek() again. This interleaving of raw os.lseek() and buffered
I/O on the same fd is undefined behaviour from Python's perspective.
The BufferedReader tracks its own idea of the fd's position and buffer
contents; os.lseek() changes the position behind its back. This can
corrupt its internal state and cause read() to return stale/zero data.
This code, however, has existed in wic since it was written, so why
was it not noticed before? It turns out this bug was being masked by a
number of implementation details that changed, especially when wic was
split out for oe-core. These changes conspired together to cause the bug
to be triggered.
One of the root causes of this bug is that Python 3.14 increased the
default buffer size from 8KB to 128KB[1]. With 8 KB buffers, read()s
either go through the direct-read path leaving the buffer empty, or
if it fills in 8KB chunks the buffer is fully drained. Either way,
with a small buffer, read()s do a real raw seek. No fast path. No
corruption. With a 128KB buffer, however, a much larger window exists
where BufferedReader.seek() can take the fast-path after the raw file
descriptor has already been repositioned by os.lseek() in the generator.
With the smaller buffer, this window was too narrow to hit in practice.
This is fixed by opening a second file object in FilemapSeek.__init__()
dedicated to SEEK_DATA/SEEK_HOLE probes, leaving the data-reading handle
(self._f_image) untouched.
This explains why the corruption is deterministic and tied to specific
block boundaries, why it only manifests with the split-out version using
Python 3.14 (on systems that are using Python versions less than 3.14 on
the host), and why using a separate file descriptor for reading bypasses
the issue entirely.
This is not an intermittent bug. For a more detailed explanation
including log files, in-depth analysis, and a standalone Python
reproducer, please see the linked bugzilla entry.
Fixes: [YOCTO #16197]
[1] b1b4f9625c
b1b4f9625c5f ("gh-117151: IO performance improvement, increase io.DEFAULT_BUFFER_SIZE to 128k (GH-118144)")
AI-Generated: codex/claude-opus-4.6 (xhigh)
(From OE-Core rev: 37a45219dd204b07bad40576fefccb2cf85b255c)
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 481969844385f2fa40a1230ca50253ec4ff516cd)
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Paul Barker <paul@pbarker.dev>
Ubuntu 25.10 has changed the default coreutils implementation from GNU
coreutils to uutils/coreutils. Unfortunately this causes build problems:
couldn't allocate absolute path for 'null'.
tail: cannot open 'standard input' for reading: No such file or directory
install: failed to chown '...': Invalid argument (os error 22)
Clear build failures happen in 'install' and 'tail', but there may be
further breakage.
Luckily, Ubuntu also installs GNU coreutils with a binary prefix of
'gnu', so whilst these issues are root-caused and fixed in either pseudo
or uutils we can prefer the gnu-prefixed binaries where they are present.
[ YOCTO #16028 ]
(From OE-Core rev: b797cc729f6e6951baa988e1c04bac9fb8183a1c)
Signed-off-by: Ross Burton <ross.burton@arm.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 16f2684ebeffa72b5d90525cf9102751b68c298e)
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Paul Barker <paul@pbarker.dev>
Update to the 5.0.18 release of the 5.0 series for buildtools
(From OE-Core rev: 7b2955ae65d4060aaa8f3eda9f3583750606a646)
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Paul Barker <paul@pbarker.dev>
