Praveen Kumar [Thu, 5 Jun 2025 14:38:25 +0000 (20:08 +0530)]
python3: upgrade 3.13.3 -> 3.13.4
Security content in this release:
- gh-135034: Fixes multiple issues that allowed tarfile extraction filters
(filter="data" and filter="tar") to be bypassed using crafted symlinks and
hard links. Addresses CVE-2024-12718, CVE-2025-4138, CVE-2025-4330, and
CVE-2025-4517.
- gh-133767: Fix use-after-free in the “unicode-escape” decoder with a non-
“strict” error handler.
- gh-128840: Short-circuit the processing of long IPv6 addresses early in
ipaddress to prevent excessive memory consumption and a minor denial-of-service.
Includes additional standard library improvements and bug fixes.
Gyorgy Sarvari [Fri, 6 Jun 2025 13:31:18 +0000 (15:31 +0200)]
bc: upgrade 1.08.1 -> 1.08.2
Changes:
- Remove last vestages of K&R C; this allows gcc-15+ to compile
the code without special options.
- Some typo and formatting fixes in the documentation.
The above change also allowed dropping the relevant patch, that fixed
gcc15 compatibility: 0001-getopt-Add-missing-params-to-getopt-getenv-signature.patch
License-Update: added copyright years to the file header.
Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Markus Volk [Sat, 7 Jun 2025 15:37:28 +0000 (17:37 +0200)]
mesa: update 25.1.1 -> 25.1.3
Mesa 25.1.3 Release Notes / 2025-06-07
Mesa 25.1.3 is a bug fix release which fixes bugs found since the 25.1.2 release.
Mesa 25.1.3 implements the OpenGL 4.6 API, but the version reported by glGetString(GL_VERSION) or glGetIntegerv(GL_MAJOR_VERSION) / glGetIntegerv(GL_MINOR_VERSION) depends on the particular driver being used. Some drivers don’t support all the features required in OpenGL 4.6. OpenGL 4.6 is only available if requested at context creation. Compatibility contexts may report a lower version depending on each driver.
Mesa 25.1.3 implements the Vulkan 1.4 API, but the version reported by the apiVersion property of the VkPhysicalDeviceProperties struct depends on the particular driver being used.
New features
None
Bug fixes
25.1.2 - instant crash on upgrade, very first attempt at a new surface
Mesa 25.1.2 Release Notes / 2025-06-04
Mesa 25.1.2 is a bug fix release which fixes bugs found since the 25.1.1 release.
Mesa 25.1.2 implements the OpenGL 4.6 API, but the version reported by glGetString(GL_VERSION) or glGetIntegerv(GL_MAJOR_VERSION) / glGetIntegerv(GL_MINOR_VERSION) depends on the particular driver being used. Some drivers don’t support all the features required in OpenGL 4.6. OpenGL 4.6 is only available if requested at context creation. Compatibility contexts may report a lower version depending on each driver.
Mesa 25.1.2 implements the Vulkan 1.4 API, but the version reported by the apiVersion property of the VkPhysicalDeviceProperties struct depends on the particular driver being used.
New features
None
Bug fixes
Confidential issue #13281
anv, regression: Missing terrain in It Takes Two on BMG
“breaking-limit” benchmark will Freeze before starting.
rusticl: CL_MEM_HOST_READ_ONLY cl_image2d reads zeroes from host on AMD Vega8
Bug (bad code optimization?) in the GLSL (compute) shader compiler
nvk: Broken lighting in Trine 5
RX9070 hard crash with Mafia Definitive Edition
RADV: Potential bug with vulkan fragment shader interpolation (on outputs from mesh shaders?)
In the game “Foundation” a buildings areas of effect is missing
ANV: Dota 2 May 22 2025 update crashing in vkCmdBindDescriptorSets with no validation error
Vulkan Video engages during playback of format which is not supported by my Fiji GPU
Weston hangs on virtio (non-accelerated version) on QEMU with Mesa main
KVM/qemu: GDM fails to start / gnome-shell crashes after update to mesa-dri-drivers-25.0.3
Signed-off-by: Markus Volk <f_l_k@t-online.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Peter Marko [Sat, 7 Jun 2025 21:34:17 +0000 (23:34 +0200)]
curl: upgrade 8.12.1 -> 8.14.1
Handle CVE-2025-4947 and CVE-2025-5025.
CVE-2025-5399 fixed in 8.14.1 was introduced only in 8.13.0, so Yocto
never had version vulnerable to it.
Rebase patches.
Add openssl-native dependency fo ptest to fix following error:
Missing or broken 'openssl' tool. openssl 1.0.2+ is required.
Without it, this script cannot generate the necessary certificates
the curl test suite needs for all its TLS related tests. at
../../../curl-8.14.0/tests/certs/genserv.pl line 33.
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>
projects / thirdparty / openembedded / openembedded-core-contrib.git / log
