This also includes security release update
https://github.com/iputils/iputils/releases/tag/20250602
Security release, fixes CVE-2025-47268 and CVE-2025-48964
(therefore remove backported fix CVE-2025-47268.patch
Signed-off-by: Petr Vorel <petr.vorel@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There's no need to setup a fake 'source directory' and
redirect the tests to it; rather it's possible to point
them directly to ptest directory (this needs to be done
twice, in Makefile substitutions, and as a C define during
ptest compilation).
This also eliminates the assumption that S and B are in the
same directory (no longer true when S is in UNPACKDIR).
Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The previous one wasn't particularly readable, and assumed
a particular relationship between S and B. The new one
also works when S is in UNPACKDIR, or anywhere else.
Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
piglit: replace setting PIGLIT_BUILD_DIR with a correct reproducibility fix
PIGLIT_BUILD_DIR was set to source tree location relative to B as a
reproducibility workaround some years ago. Aafter some investigation
I found where the actual issue is (addressed by the patch).
Also, setting PIGLIT_BUILD_DIR relative to ${B} in a hardcoded way
is problematic as S and B are not necessarily related that way (e.g. when
sources are in UNPACKDIR or somewhere else entirely).
Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Ross Burton [Thu, 5 Jun 2025 20:11:51 +0000 (21:11 +0100)]
insane: add test for recipe naming/class mismatches
It's not unheard of for new users to create a recipe called foo-native
that has BBCLASSEXTEND="native" instead of "inherit native". This will
result in a foo-native recipe that is actually a target recipe, and a
foo-native-native recipe for native builds.
Add a test in recipe_qa to verify that recipes called -native inherit
native, and recipes called nativesdk- inherit nativesdk.
As this behaviour is expected, add the new test to the set of tests
required to pass for Yocto Project Compatible status.
Signed-off-by: Ross Burton <ross.burton@arm.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
lib/oeqa/utils/sshcontrol: correct condition for ending the select() loop
This was set backwards; per https://docs.python.org/3/library/subprocess.html#subprocess.Popen.returncode
a return code of None indicates the process is still running,
and so the code entered a busyloop that ended on timeout
5 minutes later, lengthening selftests significantly.
Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Bruce Ashfield [Thu, 5 Jun 2025 02:18:55 +0000 (22:18 -0400)]
linux-yocto/6.12: libbpf: silence maybe-uninitialized warning from clang
Integrating the following commit(s) to linux-yocto/6.12:
1/1 [
Author: Ross Burton
Email: ross.burton@arm.com
Subject: libbpf: silence maybe-uninitialized warning from clang
Date: Wed, 4 Jun 2025 21:22:23 +0100
perf is build with -Werror, but clang 20.1.6 (incorrectly) finds that
mod_len may be used uninitialized:
libbpf.c: In function 'find_kernel_btf_id.constprop':
libbpf.c:10009:33: error: 'mod_len' may be used uninitialized [-Werror=maybe-uninitialized]
10009 | if (mod_name && strncmp(mod->name, mod_name, mod_len) != 0)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
libbpf.c:9979:21: note: 'mod_len' was declared here
9979 | int ret, i, mod_len;
| ^~~~~~~
Inspecting the code it can be seen that mod_len is set if mod_name is
set, and the strncmp() is only called if mod_name is set, so this is a
false positive (interestingly, clang doesn't spot the same issue above).
Silence the false positive by explicitly initializing mod_len to 0.
Signed-off-by: Ross Burton <ross.burton@arm.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
]
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Support for OSMesa has been removed in the latest Mesa versions, drop
corresponding PACKAGECONFIG option from mesa-demos. Note, there is no
need to pass -Dosmesa=disabled, meson will detect that the library is
not available.
Gyorgy Sarvari [Thu, 5 Jun 2025 05:16:47 +0000 (07:16 +0200)]
diffoscope: upgrade 293 -> 297
Also, remove the musl restriction - it builds successfully with both glibc and musl.
Changelog:
294:
- Correct longstanding issue where many ">"-based version tests used in
conditional fixtures were broken due to the lack of a __gt__ method.
Thanks, Colin Watson! (Closes: #1102658)
- Address a long-hidden issue in the test_versions testsuite where we weren't
actually testing ">" as it was masked by the tests for equality in the
testsuite.
- Update copyright years.
295:
- Use --walk over the potentially dangerous --scan argument of zipdetails(1).
(Closes: reproducible-builds/diffoscope#406)
296:
- Don't rely on zipdetails' --walk functionality to be available; only add
that argument after testing for a new enough versions.
(Closes: reproducible-builds/diffoscope#408)
- Disable and then re-enable failing on stable-bpo.
- Update copyright years.
- Add NuGet package support.
297:
- Add a LZMA comparator and tests.
Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
PR32829, SEGV on objdump function debug_type_samep
u.kenum is always non-NULL, see debug_make_enum_type.
Backport a patch from upstream to fix CVE-2025-5245
Upstream-Status: Backport [https://sourceware.org/git/?p=binutils-gdb.git;a=patch;h=6c3458a8b7ee7d39f070c7b2350851cb2110c65a]
Signed-off-by: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Yannic Moog [Thu, 5 Jun 2025 07:23:50 +0000 (09:23 +0200)]
perf: add arm64 source files for unistd_64.h
kernel commit bfb713ea53c7 ("perf tools: Fix arm64 build by generating unistd_64.h")
introduces a new dependency on source files for arm64, specifically
include/uapi/asm-generic.
Build fails with:
[..]/perf/1.0/perf-1.0/scripts/Makefile.asm-headers:33: [...]/perf/1.0/perf-1.0/include/uapi/asm-generic/Kbuild: No such file or directory
make[4]: *** No rule to make target '[...]/perf/1.0/perf-1.0/include/uapi/asm-generic/Kbuild'. Stop.
Add the directory to PERF_SRC.
Fix whitespace error while at it.
Signed-off-by: Yannic Moog <y.moog@phytec.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Here to explain how __rm was set in rpm during build. The build system
of rpm is cmake. Take rpm rpm-4.19.x for example:
The '__RM rm' is defected by findutil [1], and function findutil
calls find_program to search for tool, if not found on host, then
hardcode with "/usr/bin" prefix [2]
Yocto explicitly set OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM = "ONLY" [3][4]
to search tools from CMAKE_FIND_ROOT_PATH [5] which locates in recipe sysroot,
if not found in recipe sysroot, hardcode with "/usr/bin" prefix
If "${base_bindir}" != "${bindir}, explicitly correct tools in rpm
macros, use ${base_bindir} to instead original ${bindir}. Only do the
operation for target, it is not necessary for native and nativesdk,
because most host distribution supports usrmerge
In order to save size, this commit does not add these tools to
runtime depends, user should explicitly add them if necessary
(such as use rpm to build packages)
When looking at bitbake parsing speed issues, I noticed a lot of weird looking
variables from the update-alternatives class. It is possible this was written
before variable dependencies could handle flags. It can handle flags now so
simplfy the code to take advantage of that and avoid the indirection variables.
The win here is a significant reduction in the number of variables, which
in turn significantly reduces the looping bitbake's taskhash calculation code
needs to do.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Changelog:
2025.04.11.15:
- Add classifier for Wagtail 7 (#210)
2025.04.28.22:
- Add entry point to enable installing with pipx or uvx
- Tests added for running the module and calling the entry point.
- Add return type annotation
- reformat
- Try adding BINDIR to python and entry point
- Add missing BINDIR paths
- Add docstring to test.
2025.5.1.12:
- Don't assume basename of sys.executable is "python" (#212)
On Debian, it's "python3" instead.
2025.5.7.19:
- Add Trove classifier for Python 3.15 (#213)
2025.5.8.13:
- Add several missing languages
- Update src/trove_classifiers/__init__.py
Robert Yang [Wed, 4 Jun 2025 15:00:56 +0000 (08:00 -0700)]
quilt: 0.68 -> 0.69
Add 0001-contrib-spec-filters-obs-usr-bin-sh-bin-sh.patch to fix:
ERROR: quilt-0.69-r0 do_package_qa: QA Issue: /usr/share/quilt/spec-filters/obs contained in package quilt requires /usr/bin/sh, but no providers found in RDEPENDS:quilt? [file-rdeps]
Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Ross Burton [Wed, 4 Jun 2025 14:03:22 +0000 (15:03 +0100)]
recipetool/create: show more of the license path when it can't be identified
If there are multiple source trees in a project (incredibly common with
go-mod, for example) then the relative path of the LICENSE file from
the source tree could just be "LICENSE", which is not useful when there
are tens of files across the recipe with that name.
Show the parent directory name too, to clarify which file is unknown.
Signed-off-by: Ross Burton <ross.burton@arm.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Richard Purdie [Tue, 3 Jun 2025 21:17:04 +0000 (22:17 +0100)]
bitbake.conf: Drop lz4 from HOSTTOOLS
As far as I can tell, we don't have anything using lz4 in our key
build dependencies. It isn't in ASSUME_PROVIDED and our code automatically
adds lz4-native dependencies where needed. Even then, it is very rarely
needed, mainly for some kinds of SRC_URI (none in OE-Core) and some
filesystems/images.
As such, drop this from HOSTTOOLS and rely on lz4-native, which is what
was already happening anyway. This simplies host setup slightly.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Richard Purdie [Tue, 3 Jun 2025 21:17:37 +0000 (22:17 +0100)]
classes/recipes-devtools: Drop icecc from OE-Core
There are reports this class has been broken since mickledore which suggests
there are limited numbers of users. It doesn't have any automated testing
and it would be hard to setup and maintain a testing environment for it. The
original users/manintainers aren't using it now.
For those reasons, drop from OE-Core as we're not in a good position to
maintain it. I'd suggest anyone wanting to use it creates a dedicated layer
with maintainers who are in a position to test/develop it appropriately since
it is standalone code.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Mikko Rapeli [Tue, 3 Jun 2025 12:29:39 +0000 (15:29 +0300)]
oeqa selftest uboot.py: add qemu KVM test case
Add a test case to boot target system via u-boot
using qemu with KVM. This was broken recently
and workaround proposed to u-boot. Test case
works with genericarm64 and qemuarm64 target machines
compiled and tested on aarch64 build host with KVM
support.
Test execution time with full sstate cache is
around 170 seconds. qemu boot itself takes just
a few seconds to full userspace.
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Mikko Rapeli [Tue, 3 Jun 2025 12:29:37 +0000 (15:29 +0300)]
u-boot: disable USB support on qemuarm64 and genericarm64
qemu USB devices under KVM currently cause reset loop
in u-boot. If u-boot USB support is disabled then
u-boot just ignores the qemu USB devices which
then work with Linux kernel as before.
Mikko Rapeli [Tue, 3 Jun 2025 12:29:36 +0000 (15:29 +0300)]
u-boot: disable CONFIG_BLOBLIST on genericarm64 and qemuarm64
Booting u-boot on qemu with kvm is currently hanging on aarch64
build host. Root cause is in u-boot and CONFIG_BLOBLIST can be
disabled as a workaround.
To reproduce, build on kvm enabled host where "kvm-ok"
succeeds. For example genericarm64 machine and core-image-base
should then boot with:
$ runqemu slirp nographic novga snapshot kvm
On qemuarm64, default kvm setup will boot directly to kernel
and is not affected by this. If build enables u-boot as bios
then the same issue happens.
Without this config workaround, the boot hangs without
any messages in qemu output but ctrl-a-c to qemu console
can shutdown the emulated machine.
This seems to have regressed after u-boot 2025.04 update.
KVM boot can be detected from speed, for example genericarm64
boots in 550 ms with KVM and without in over 5 seconds.
Richard Purdie [Tue, 3 Jun 2025 14:06:15 +0000 (15:06 +0100)]
kernel-fit-image: Exclude from world
Recipes using this class are designed to be pulled in by dependencies and
the recipe doesn't build unless the kernel is appropriately configured. Mark
as not suitable for world builds as a result to avoid world build failures.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The integration of the FIT image-related build steps into the kernel
recipe has proven to be not very good. The new implementation with
kernel-fit-image.bbclass fixes some design issues:
* sstate does not work well when a fitImage contains an initramfs. The
kernel is rebuilt from scratch if the build runs from an empty TMPDIR.
* A fitImage kernel is not available as a package, but all other kernel
image types are.
* The task dependencies in the kernel are very complex and difficult to
debug if something goes wrong. As a separate, downstream recipe, this
is now much easier.
The long storry about this issue is here:
[YOCTO #12912]
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
kernel.bbclass is no longer involved in FIT image creation. Whether a
FIT image is built now depends entirely on whether the linux-yocto-fitimage
recipe (or any other recipe capable of producing a FIT image) is selected
for the build.
As a result, specifying the kernel image type "fitImage" in
KERNEL_IMAGETYPE or KERNEL_IMAGETYPES is no longer necessary and gets
removed.
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rewrite the kernel-fitimage.bbclass file in Python. This allows the
reuse of the new fitimage Python library and a clear alignment of the
two implementations.
Actually, the motivation for an implementation in Python was different.
During the transition from the kernel-fitimage.bbclass to the new
linux-yocto-fitimage.bb, the existing shell code was rewritten in Python
so that the fitimage.py library could be extracted. The new
kernel-fit-image.bbclass and linux-yocto-fitimage.bb were then developed
on this basis.
This approach makes it possible to run the same tests for all different
implementations:
- kernel-fitimage.bbclass in Shell
- kernel-fitimage.bbclass in Python
- linux-yocto-fitimage.bb
Changing the commit order now enables a smooth transition. The two
implementations can coexist. Maintenance and testing should be feasible
for a few months with reasonable effort as they share most of the code.
But of course, the goal is to remove the kernel-fitimage.bbclass as soon
as possible.
This commit opens the path for different strategies going forward:
- Just replace the old implementations with the new one and ignoring
this commit.
- Add the new implementation and keep the old implementation without any
change.
- Add the new implementation and this commit and support the old
architecture sharing most of the code with the new architecture and
implementatiion.
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Make the new KernelFitImageRecipeTests class the one that contains the
code, and keep the KernelFitImageTests class as the one that just adds
back the same tests. This will make it easier to delete the tests later,
which will hopefully become obsolete when the kernel-fitimage.bbclass
class is no longer needed.
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
oe-selftest: fitimage: run all tests for both FIT implementations
Run all existing tests for kernel-fitimage.bbclass also with the new
linux-yocto-fitimage recipe.
Executing each test for both implementations helps ensure functional
compatibility and consistency between them.
This change will naturally double the test duration for FIT image-related
tests, as each test now runs against both implementations. However, the
goal is to eventually deprecate kernel-fitimage.bbclass, at which point
the duplicate tests can be removed.
Additionally, since the new implementation makes significantly more
efficient use of the sstate cache compared to the old one, the overall
test execution time may still be improved.
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
oe-selftest: fitimage: support new FIT recipe as well
Enable all existing tests to be compatible with FIT images generated
either by the new linux-yocto-fitimage recipe or the legacy
kernel-fitimage.bbclass approach.
- Make the following configurations optional:
- KERNEL_IMAGETYPES += "fitImage"
- KERNEL_CLASSES = "kernel-fitimage"
- Allow the tests to specify which kernel recipe should be used for the
build (e.g., linux-yocto, linux-yocto-fitimage, etc.)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Having the FIT image generator code as a separate class, which is
essentially independent of BitBake, also allows testing the code
separately from BitBake. Take advantage of this enables testing more
use cases with significantly faster tests.
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
kernel-fit-image.bbclass: add a new FIT image implementation
The new recipe linux-yocto-fitimage.bb and the new
kernel-fit-image.bbclass are intended to become successors of the
kernel-fitimage.bbclass.
Instead of injecting the FIT image related build steps into the kernel
recipe, the new recipe takes the kernel artifacts from the kernel recipe
and creates the FIT image as an independent task.
This solves some basic problems:
* sstate does not work well when a fitImage contains an initramfs. The
kernel is rebuilt from scratch if the build runs from an empty TMPDIR.
* A fitImage kernel is not available as a package, but all other kernel
image types are.
* The task dependencies in the kernel are very complex and difficult to
debug if something goes wrong. As a separate, downstream recipe, this
is now much easier.
The recipe takes the kernel artifacts from the deploy folder. There was
also a test implementation passing the kernel artifacts via sysroot
directory. This requires changes on the kernel.bbclass to make it
copying the artifacts also to the sysroot directory while the same
artifacts are already in the sstate-cached deploy directory.
The new class kernel-fit-extra-artifacts.bbclass generates and deploys
the kernel binary intended for inclusion in a FIT image.
Note that the kernel used in a FIT image is a stripped (and optionally
compressed) vmlinux ELF binary - not a self-extracting format like
zImage, which is already available in the deploy directory if needed
separately.
The kernel-fit-extra-artifacts.bbclass can be used like this:
KERNEL_CLASSES += "kernel-fit-extra-artifacts"
(if uImage support is not needed, or with :append otherwise)
The long story about this issue is here:
[YOCTO #12912]
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
kernel-uboot.bbclass: do not require the kernel build folder
The function must be executed in CWD. Make it more flexible by
specifying the kernel build folder as a parameter.
This is a refactoring without functional change. But later this change
will allow to use this function also with a kernel from the sstate-cache
instead of requiring the full kernel build folder structure.
Another preparation for using a kernel from sstate-cache is to persist
the linux_comp variable in a file next to the linux.bin file rather than
using a global shell variable.
This change also requires to adapt the kernel-uimage.bbclass
accordingly. This change also fixes a minor detail:
the kernel-uimage.bbclass used ${ instead of $ for evaluatiing a local
shell variable.
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When the ITS file is created, the mandatory properties are written first
before the optional properties are written.
This is not really useful for the current implementation. But it is a
preparation for a new Python-based implementation that will expect
mandatory properties first. This change makes it possible to run the
tests with both the old and the new implementation.
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It is closer to practice to use static and predictable keys to sign the
FIT images. In addition, the new kernel-signing-keys-native is only
reliable if the temporary directory is not deleted. However, depending
on how this test suite is started, this can happen.
There will therefore only be one test that uses the recipe to generate
the keys, which ensures that the recipe works in principle.
It is also ensured that no keys are present before the test and that the
recipe runs safely and is not skipped by Bitbake.
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
projects / thirdparty / openembedded / openembedded-core.git / log
