Building with an old gcc version (for example with
bootlin-aarch64-glibc-old) currently fails with the following error:
../src/graph/graph.hh:638:12: error: could not convert ‘g’ from ‘graph::graph_t’ to ‘graph::graph_result_t<graph::graph_t> {aka hb_result_t<graph::graph_t, graph::graph_error_t>}’
return g;
Add an upstream patch to fix it.
No corresponding build failures on autobuilders were found at the time
the commit was made.
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This release replaces strncpy() with strscpy() in kernel space, which
fixes the build with Linux >= 7.2, where strncpy() is no longer
available to kernel code.
From:
https://gitlab.com/etherlab.org/ethercat/-/blob/1.6.13/NEWS.md#version-1613
- Made the macb (Cadence GEM) EtherCAT RX path allocation-free to
avoid receive latency spikes under host memory pressure.
- Included macb in the device driver table and fixed a
`CONFIG_MACB_USE_HWSTAMP` build issue.
- Use `strscpy` instead of the deprecated `strncpy` in kernel space,
with a fallback for Linux < 4.2.
- Added a test build for kernel 6.18.
- Improved `ecrt_slave_config_dc()` documentation.
- Adopted the CPPlint configuration of stable-1.7, fixed CPPlint
complaints and added exceptions for device drivers.
- Use an own pre-commit container with cache in CI.
Fixes: https://autobuild.buildroot.org/results/5c48b38fba102c38630e546eeea05cf206eb9e53/
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Julien Olivain <ju.o@free.fr>
https://www.python.org/downloads/release/python-3148/https://docs.python.org/release/3.14.8/whatsnew/changelog.html
Security content in this releases
CVE-2026-19445 gh-156293
Use-after-free of a server-side SSLContext when sni_callback switches
contexts
CVE-2026-19553 gh-156793
SSLContext.wrap_bio() missing validation of server_hostname parameter
CVE-2026-82049 gh-157190
tarfile extraction filters allow file modification and content
disclosure via hard link to symlink
CVE-2026-15310 gh-156002
Memory exhaustion in zipfile in bzip2/LZMA/Zstandard decompression
CVE-2026-19672 gh-155999
tarfile extraction filter bypass allows creation of directories outside
the destination
CVE-2026-15806 gh-155694
urllib.request.HTTPPasswordMgr credentials for one URL scheme sent over
another scheme
CVE-2026-17084 gh-155292
StringPrep algorithm considered Unicode codepoint attributes outside
Unicode 3.2.0
gh-158446
Reject float format precision near INT_MAX
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
https://github.com/openssl/openssl/releases/tag/openssl-3.6.5
This release incorporates the following bug fixes and mitigations:
Fixed DTLS retransmissions of handshake messages from a stale buffer offset.
(CVE-2026-84782)
Fixed excessive memory allocation in relative CRLDP processing.
(CVE-2026-35189)
Fixed QUIC unvalidated amplification credit may be over-accounted.
(CVE-2026-35191)
Fixed potential CPU DoS via O(n^2) fragment reassembly in QUIC.
(CVE-2026-42772)
Fixed a timing side-channel in scalar multiplication for mon-NIST EC curves.
(CVE-2026-54872)
Fixed QUIC STREAM fragment metadata DoS.
(CVE-2026-54873)
Fixed non-constant-time SM2 scalar multiplication on ARM64 and RISC-V.
(CVE-2026-54875)
Fixed out-of-bounds access after SSL_set_SSL_CTX() during a handshake.
(CVE-2026-72897)
Fixed QUIC connection-level flow control was not enforced for streams.
(CVE-2026-75804)
Fixed a NULL pointer dereference in CMP client revocation response handling.
(CVE-2026-75805)
Fixed an unauthenticated and undersized DTLS 1.2 AEAD record causing DoS.
(CVE-2026-75806)
Fixed a timing side-channel in SM2 signature generation.
(CVE-2026-77696)
Fixed an unbounded RETIRE_CONNECTION_ID backlog in QUIC stack
implementation.
(CVE-2026-84784)
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Since the bump to version 20260817.0, the AES-based hash for long
strings is used whenever __SSE4_2__ and __AES__ are defined. It relies
on _mm_cvtsi128_si64() and _mm_extract_epi64(), which are only
available on x86_64, so the build fails on 32-bit x86 for CPUs that
support SSE4.2 and AES:
hash.cc:115:32: error: '_mm_cvtsi128_si64' was not declared in this scope
Add a patch from a pending upstream pull request restricting this code
path to x86_64.
Fixes:
https://autobuild.buildroot.org/results/48198506ef76c6ebad0a802cb1fdd5270494eae1
Assisted-by: Claude:claude-opus-5
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Currently when building with make, the cmake config files are not
generated. This leads to problems when integrating the package in an
application built with cmake.
The CMake build system links the PDF component against the system
libpng when POCO_UNBUNDLED is enabled, while the legacy make build
system always used the bundled copy, so select libpng for the PDF
component.
POCO_NO_FPENVIRONMENT and POCO_NO_WSTRING are plain preprocessor
defines rather than CMake options, so pass them through CMAKE_CXX_FLAGS.
Poco is built as a set of shared libraries, so -latomic has to be
passed via CMAKE_SHARED_LINKER_FLAGS as well.
Disable File2Page along with PageCompiler, and tie the ActiveRecord
compiler to the ActiveRecord component, to match what the legacy make
build system omitted.
This patch is based on this one:
https://lists.buildroot.org/pipermail/buildroot/2026-April/801019.html
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Bubblewrap expects the value of the assume_kernel option, if set, to
be exactly three numbers separated by dots, nothing else [1]. If that
requirement is not met configuring the build fails.
Buildroot sets assume_kernel to $(LINUX_VERSION_PROBED) since the
version bump to 0.12.0. However, the expansion of
LINUX_VERSION_PROBED may contain additional suffixes, e.g. if
CONFIG_LOCALVERSION is set, or localversion* files are present (like
in CIP kernels). So filter the version string to ignore any suffixes.
[1] https://github.com/containers/bubblewrap/blob/v0.13.0/meson.build#L94-L104
Fixes: 4cb6193d2e ("package/bubblewrap: security bump to version 0.12.0")
Fixes: https://autobuild.buildroot.org/results/e7513e4730000e46b13bb9cf25955ebd3ec5fb71/
Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
Acked-by: Adrian Perez de Castro <aperez@igalia.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
util-linux-libs was introduced as an intermediate package to help break
circular dependencies with util-linux, and therefor only exists to provide
more basic versions of the libraries util-linux provide, to break these
dependency chains.
There is no need to install these to target as they will never be used
there.
Under all circumstances the libraries are built and installed by the main
util-linux package.
This only solves the confict for target, the conflict will remain for
staging as that conflict is much harder to solve.
Cc: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: John Ernberg <j@j-ernberg.se>
Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
Wireshark 4.6 is the current Stable version, while 4.4 is the Old Stable,
see https://www.wireshark.org/download.html
See the major changes from Wireshark 4.4 to 4.6 in these release notes:
https://www.wireshark.org/docs/relnotes/wireshark-4.6.0.html. Of notable
interest, libxml2 is now a required dependency.
This is not considered a security update because all important security fixes
that landed in Wireshark 4.6 patch releases are also available in
Wireshark 4.4.19 (currently in Buildroot).
Side discussion: Wireshark 4.2 is now EOL, see
https://www.wireshark.org/docs/wsug_html/#ChIntroEndOfSupportPlanning
As of today, Buildroot LTS 2025.02.x distributes Wireshark 4.2, and
therefore we should consider bumping it to 4.4.19, or even apply this
patch to bump to Wireshark 4.6.9 which will be supported for longer.
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Since version 4.4.0 of wireshark, support for Lua 5.3 and 5.4 has been
added, and support for Lua 5.1 and 5.2 has been removed. See
https://www.wireshark.org/docs/relnotes/wireshark-4.4.0.html
This fixes an infinite loop during the build, as for some reason when
Lua 5.1 is available, the CMake check for Lua 5.3 or 5.4 loops
indefinitely, with cmake taking up 100% of one CPU core.
Fixes: 49fa20e667 ("package/wireshark: bump to latest upstream stable v4.4.9")
Signed-off-by: Francois Perrad <francois.perrad.86@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Autotools support was removed upstream in 2.5.0, so switch to the meson
build system:
- the tarball is now only provided as .tar.xz
- --disable-strict has no meson equivalent and is dropped
- there is no debugatr option anymore, so define ATR_DEBUG via CFLAGS
- pass -latomic via LDFLAGS instead of LIBS
- meson installs the systemd units into the user unit directory by
default, so pass -Dsystemdunit=system to keep them in the system
unit directory as before
Since 2.4.0, pcscd.service runs pcscd as the unprivileged pcscd user,
so add it to the users table.
COPYING hash changed because doc/example/pcsc_demo.c was removed from
the list of GPL-3.0+ files; Buildroot already listed it as
BSD-3-Clause.
https://github.com/LudovicRousseau/PCSC/blob/2.5.2/ChangeLog
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Patch was committed upstream in a slightly different version
0984041283
and was first released in version 3.0 which was added to buildroot with
commit 3c66f65a6a.
Added Upstream: tag to patch 0001.
Renumbered patch 0003 and updated Upstream: tag.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Since the bump to 3.7.3, libsoup unconditionally includes <dlfcn.h>
in soup-init.c to detect whether libsoup2 is loaded in the same
process. Static-only toolchains such as uClibc-ng without shared
library support don't provide this header, so the build fails:
../libsoup/soup-init.c:21:10: fatal error: dlfcn.h: No such file or directory
Add a patch, submitted upstream, that checks for dlfcn.h at configure
time and skips the libsoup2 detection when it is not available.
Fixes:
https://autobuild.buildroot.org/results/4effebe5fc12146749e704dd56f695363cc8fbc3
Fixes: 55cec1d013 ("package/libsoup3: bump to 3.7.3")
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Buildroot commit 7f48325de6 bumped the
asterisk package from 22.9.0 to 22.10.1.
This bump includes upstream commit
5d543ad80c
which bumped the bundled pjsip package to 2.17.
To allow offline builds we download the pjsip tarball so we need to keep
the version numbers in sync.
The autobuilders logs show a download process:
https://autobuild.buildroot.net/results/400/400e53158f11926446c11d22681eb8a9430caf1d/build-end.log
checking for embedded pjproject (may have to download)... configuring
[pjproject] Downloading https://raw.githubusercontent.com/asterisk/third-party/master/pjproject/2.17/pjproject-2.17.tar.bz2 to
/home/autobuild/autobuild/instance-3/dl/asterisk/pjproject-2.17.tar.bz2
[pjproject] Verifying /home/autobuild/autobuild/instance-3/dl/asterisk/pjproject-2.17.tar.bz2
where the tarball was once stored in the configured download directory:
--with-download-cache=$(ASTERISK_DL_DIR)
to be used during later autobuilder runs.
Fixes: 7f48325de6 ("package/asterisk: security bump to 22.10.1")
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
[Thomas: add comment in .mk file]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Fixes: CVE-2026-18321:
https://nvd.nist.gov/vuln/detail/cve-2026-18321
- bump version to 1.2.5 (for details see [1])
- rebased 0001-wscript-remove-checks-for-bsd-string.h-fixes-host-co.patch
- rebased 0002-disable-PIE-support.patch
- removed 0003-ntpd-refclock_gpsd.c-Add-missing-time.h-for-strptim.patch
(from upstream [2])
- moved 0004-refclock_gpsd-add-build-fix-for-gcc-14.x.patch to
0003-refclock_gpsd-add-build-fix-for-gcc-14.x.patch, rebased and enhanced
as the original conflicts with upstream commit 5505260c ("Fix redefined
_XOPEN_SOURCE warning in refclock_gpsd.c") [3] and leads to the following
compile failure:
../../ntpd/refclock_gpsd.c:113:21: error: operator ‘<’ has no left operand
113 | #if _XOPEN_SOURCE < 700
| ^
[1] https://lists.ntpsec.org/pipermail/devel/2026-July/011029.html
[2] 5137c155d8
[3] 5505260cd1
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
[Julien: mark commit as "security bump"]
Signed-off-by: Julien Olivain <ju.o@free.fr>
Add support for building xen for x86_64 targets. In this initial version,
do not build extra bootloaders which would require additional download
infrastructure.
Assisted-by: Claude:opus-5.5
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
plutovg is a standalone 2D vector graphics library providing path
filling and stroking, gradients and text rendering. It is the renderer
plutosvg is built on.
Examples are not built: they are demo programs that are never installed.
Signed-off-by: Alsey Coleman Miller <alseycmiller@gmail.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Buildroot commit [1] (package/mrouted: fix invalid daemon path in
S41mrouted) removed script execution permission but forgot to remove
the corresponding .checkpackage entry.
check-package is reporting the error:
package/mrouted/S41mrouted:0: NotExecutable was expected to fail, did you fix the file and forget to update /builds/buildroot.org/buildroot/.checkpackageignore?
This commit fixes the issue by removing the entry.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/16661195972
[1] d8f408b1f1
Signed-off-by: Julien Olivain <ju.o@free.fr>
S41mrouted hard-coded /sbin/mrouted, but mrouted has always installed
to /usr/sbin/mrouted. This went unnoticed with BR2_ROOTFS_MERGED_USR=y,
but the daemon fails to start without it.
Also drop the script's executable bit to match other sysv init
scripts that do not set it.
Introduced in c25115daf2
(package/mrouted: add sysv init script).
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Version 2.0.0 requires C++20 and GCC 11 or newer.
This major release changes the API exposed to applications. However,
the 0.x release series is end-of-life, so staying on version 0.19.0 is
not a viable option.
The build system detects GnuTLS through its headers and links to it
directly. Make this detection deterministic by following the
libmicrohttpd SSL option and adding the corresponding dependency.
https://github.com/etr/libhttpserver/releases/tag/2.0.0
Signed-off-by: Stephan Hoffmann <sho@relinux.de>
Signed-off-by: Julien Olivain <ju.o@free.fr>
I have left the field of software engineering and will no longer
contribute.
Signed-off-by: Koen Martens <gmc@sonologic.nl>
Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
Updated the hash of the WHENCE file, due to firmware additions and
firmware changes, but no changes to the redistribution/licensing
conditions.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
https://gitlab.com/iniparser/iniparser/-/releases/v4.3.0
Bugfix release: fixes stack-buffer-overflows in escape_value(),
iniparser_getseckeys(), iniparser_getsecnkeys() and
iniparser_dumpsection_ini(). Adds iniparser_load_buffer() to parse ini
data from memory and generates version number constants. The SONAME
major version is unchanged.
Signed-off-by: Chen Pei <cp0613@linux.alibaba.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
stunnel's configure unconditionally probes -fstack-clash-protection
using AX_APPEND_COMPILE_FLAGS. The probe compiles a trivial conftest.c,
which succeeds, so the flag ends up in CFLAGS. However, on ARM Thumb-1
gcc implements stack clash protection through -fstack-check=specific,
which it refuses for any real function body, so every source file fails
to build:
stunnel.c:1003:1: sorry, unimplemented: '-fstack-check=specific' for Thumb-1
Force the corresponding autoconf cache variable to "no" on Thumb-1, in
the same way cmocka already works around this gcc limitation, and
consistently with the existing -fstack-protector-strong override.
Fixes:
https://autobuild.buildroot.org/results/3d691184ba83ba4d881632f2b2bb4da5aa50f491/
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Remove -Werror from CFLAGS to prevent build errors due to warnings of
deprecated functions:
futility/cmd_create.c: In function ‘vb1_make_keypair’:
futility/cmd_create.c:96:9: error: ‘PEM_read_RSAPrivateKey’ is deprecated:
Since OpenSSL 3.0 [-Werror=deprecated-declarations]
96 | rsa_key = PEM_read_RSAPrivateKey(fp, NULL, NULL, NULL);
futility/cmd_create.c:155:9: error: ‘RSA_free’ is deprecated:
Since OpenSSL 3.0 [-Werror=deprecated-declarations]
155 | RSA_free(rsa_key);
futility/cmd_create.c:191:17: error: ‘PEM_read_RSA_PUBKEY’ is deprecated:
Since OpenSSL 3.0 [-Werror=deprecated-declarations]
191 | rsa_key = PEM_read_RSA_PUBKEY(fp, NULL, NULL, NULL);
futility/cmd_create.c:199:9: error: ‘RSA_get0_key’ is deprecated:
Since OpenSSL 3.0 [-Werror=deprecated-declarations]
199 | RSA_get0_key(rsa_key, NULL, NULL, &rsa_d);
cc1: all warnings being treated as errors
The oldest build error dates back to 2024 so a backport to LTS branches
should be considered.
Fixes:
https://autobuild.buildroot.net/results/375/37554c5ce784835a36f0068d9a0c1cd931212b44/https://autobuild.buildroot.net/results/1fa/1fabca11c7839d2d7ed809f30482595719a29c92/
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Boost.DateTime is header-only since 1.77.0
The Boost Release Notes[0] didn't mention it but it was introduced in
the documentation of DateTime in this commit: [1]
This was bumped in buildroot in d39d8f7cee
So analog to the "header-only" move of Boost.System we have now to
gradually phase out the dependencies on this library. Ideally before
the stub is removed as it now happened for Boost.System in 1.89.0.
[0] https://www.boost.org/releases/1.77.0/
[1] 33dc6136f1
Signed-off-by: Michael Nosthoff <buildroot@heine.tech>
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Quote from Github site https://github.com/microsoft/cpprestsdk
"This repository was archived by the owner on Jun 1, 2026. It is now
read-only."
Building the package with boost >= 1.89 and OpenSSL >= 4.x is broken.
To not block these version bumps we remove this package.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Building the package with OpenSSL 4.0.2 is broken:
openssl.c: In function 'ssl_select_method':
openssl.c:223:34: error: implicit declaration of function 'SSLv3_client_method'; did you mean 'SSLv23_client_method'? [-Wimplicit-function-declaration]
223 | method = SSLv3_client_method();
| ^~~~~~~~~~~~~~~~~~~
| SSLv23_client_method
openssl.c:223:32: error: assignment to 'const SSL_METHOD *' {aka 'const struct ssl_method_st *'} from 'int' makes pointer from integer without a cast [-Wint-conversion]
223 | method = SSLv3_client_method();
| ^
openssl.c:225:34: error: implicit declaration of function 'TLSv1_client_method'; did you mean 'TLS_client_method'? [-Wimplicit-function-declaration]
225 | method = TLSv1_client_method();
| ^~~~~~~~~~~~~~~~~~~
| TLS_client_method
openssl.c:225:32: error: assignment to 'const SSL_METHOD *' {aka 'const struct ssl_method_st *'} from 'int' makes pointer from integer without a cast [-Wint-conversion]
225 | method = TLSv1_client_method();
| ^
openssl.c: In function 'ssl_check_host':
openssl.c:342:59: error: invalid use of incomplete typedef 'ASN1_IA5STRING' {aka 'struct asn1_string_st'}
342 | gen->d.ia5->data);
| ^~
openssl.c:344:67: error: invalid use of incomplete typedef 'ASN1_IA5STRING' {aka 'struct asn1_string_st'}
344 | (char *)gen->d.ia5->data)
openssl.c: In function 'smime_verify':
openssl.c:610:67: error: invalid use of incomplete typedef 'ASN1_IA5STRING' {aka 'struct asn1_string_st'}
610 | gen->d.ia5->data,
Debian removed the package in 2015:
https://tracker.debian.org/news/727466/heirloom-mailx-removed-from-testing/
The last upstream release dates back to 2005:
https://sourceforge.net/projects/nail/files/nail/
Dropped BR2_TOOLCHAIN_HAS_GCC_BUG_101916 because no other uses this
option after the removal of heirloom-mailx.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
There are two revisions of the VisionFive 2: v1.2a and v1.3b. The main
difference between them is that v1.2a has one Gigabit Ethernet port and
one Fast Ethernet port, while v1.3b has two Gigabit Ethernet ports.
Unless explicitly set, U-Boot automatically sets $fdtfile based on the
EEPROM product data during initialization, enabling <fdtdir>/<fdtfile>
to be loaded via extlinux.conf.
Additionally, since $fdtfile contains the directory name, preserve the
directory structure of the DTBs when copying them to the target
directory.
Signed-off-by: Fengwei Tan <tfx2001@outlook.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Migrate and clean up removed kernel config options during the upgrade.
Drop uboot and spl partitions from the SD card genimage configuration,
as U-Boot has deprecated the SD card and eMMC boot modes since
v2025.10 [1]. Update the rootfs block device in the kernel command line
accordingly.
Update readme.txt to reflect the new boot flow and instructions.
[1] https://docs.u-boot.org/en/v2026.07/board/starfive/visionfive2.html#zero-stage-program-loader
Signed-off-by: Fengwei Tan <tfx2001@outlook.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Remove vendor-specific config options from linux_defconfig as they are
not present in the upstream kernel.
Regenerate the defconfig by running:
make visionfive2_defconfig
make linux-menuconfig
# Save and exit without making any changes.
make linux-update-defconfig
Fixes: 4567c35d06 ("configs/visionfive2: bump OpenSBI to 1.6, Linux to 6.12.24 and U-Boot to 2025.04")
Signed-off-by: Fengwei Tan <tfx2001@outlook.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
MMC cards are detected asynchronously, so the root device may not be
available when the kernel tries to mount the root filesystem.
Add rootwait to wait for the root device and avoid a kernel panic.
Fixes: 4567c35d06 ("configs/visionfive2: bump OpenSBI to 1.6, Linux to 6.12.24 and U-Boot to 2025.04")
Signed-off-by: Fengwei Tan <tfx2001@outlook.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
When systemd is enabled, configure strongswan with --enable-systemd
and add the systemd dependency. This builds the charon-systemd IKE
daemon, which is designed for native systemd integration (using the
systemd libraries) and is managed by systemd through a service file,
with configuration handled by the swanctl backend.
Pass --disable-systemd when systemd is not selected to keep the
build deterministic.
Signed-off-by: Wei Dai <daiwei@sunkaisens.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Add the eap-aka-3gpp plugin, an EAP-AKA backend implementing the
3GPP MILENAGE algorithms in software. Select the EAP-AKA plugin
it depends on.
Signed-off-by: Wei Dai <daiwei@sunkaisens.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
pkg-stats columns are sorted either alphabetically or numerically. This
does not make much sense for the "Latest version" column.
This commit orders the column by whether the package is up-to-date or
not.
Signed-off-by: Franciszek Stachura <fbstachura@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This test uses the option added in the previous commits to build a
disk image with squashfs root and matching verity tree, and boots from
it. Building a kernel is necessary to get the required device-mapper
and squashfs support.
The test also serves to demonstrate usage of a verity image, more
complex setup may use an initramfs instead of dm-mod.create.
Signed-off-by: Fiona Klute (othermo GmbH) <fiona.klute@gmx.de>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Using dm-verity may be useful for any read-only filesystem read from a
block device, the new hook will build the required hash tree if
enabled by a per-filesystem config option.
To use this hook, the filesystem config must define a boolean option
BR2_TARGET_ROOTFS_<FS>_VERITY, and a string option
BR2_TARGET_ROOTFS_<FS>_VERITY_EXTRA_ARGS. The latter option allows
users to override veritysetup defaults, e.g. to set a fixed hash
algorithm.
In the filesystem .mk file ROOTFS_<FS>_VERITY_EXTRA_ARGS must be
defined as the value of BR2_TARGET_ROOTFS_<FS>_VERITY_EXTRA_ARGS
without surrounding quotes, because utils/check-symbols warns about
the _EXTRA_ARGS symbol being unused if fs/common.mk uses
$(qstrip $(BR2_TARGET_ROOTFS_$(2)_VERITY_EXTRA_ARGS)) directly.
Signed-off-by: Fiona Klute (othermo GmbH) <fiona.klute@gmx.de>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The IW610 module is also available with a USB host interface, while
the current package only supports its SDIO firmware. This commit
adds this USB support.
Bump the firmware release to lf-6.18.20-2.0.0, which
provides the FwImage_IW610_USB firmware, and add a dedicated
BR2_PACKAGE_NXP_BT_WIFI_FIRMWARE_IW610_USB option.
The new release also moves firmware files out of the nxp/ directory
and no longer provides 8801 or 8997 firmware. Update the installation
paths, make the existing IW610 option explicitly SDIO, and retain legacy
configuration handling for removed or renamed options.
This commit also updates the license hash, after an update from:
LA_OPT_NXP_Software_License v57 July 2024
to:
LA_OPT_NXP_Software_License v63 May 2025
Signed-off-by: Antoine Gennart <antoine.gennart@quimesis.be>
[Julien:
- update license hash
- fix _VERSION to use a tag rather than a branch
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
The previous version fails to build with Linux 6.13 and newer because
mlinux/moal_main.h includes the removed net/lib80211.h header.
The header was removed by Linux commit 02f220b52670 ("wifi:
ipw2x00/lib80211: move remaining lib80211 into libipw").
The new NXP release skips this obsolete header for kernels newer
than 6.12.12 and includes the corresponding Linux 6.13 cfg80211 API
compatibility fixes.
Signed-off-by: Antoine Gennart <antoine.gennart@quimesis.be>
[Julien: fix _VERSION to use a tag rather than a branch]
Signed-off-by: Julien Olivain <ju.o@free.fr>
Add basic tests for openscap, ensuring that it builds and runs a minimal
command with different cryptographic backends:
- libgcrypt
- libnss
- no crypto backend
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
When enabling the openscap package and the libnss library _but not_
libgcrypt, the build can fail on the following error:
../src/libopenscap.so.33.1.3: undefined reference to `crapi_init'
The issue is due to the fact that the corresponding Makefile
systematically forces -DWITH_CRYPTO=gcrypt: openscap CMake
instrumentation then searches only this backend, fails to find it,
assumes that no crypto backend is available, and so does not include the
crapi_object in the final link step.
Commit 7c85f3adf4 ("package/openscap: new package") took into account
the fact that openscap isn't currently able to build if no crypto backend
is provided (see [0]), and so made sure to force libgcrypt inclusion if
libnss is not included. Since then, two fixes ([1] and [2]) have been
integrated upstream to allow building openscap with any backend.
Do not systematically enforce libgcrypt anymore through WITH_CRYPTO:
rather than testing nss presence, and falling back to libgcrypt, allow
both to be absent, and so relax the libgcrypt dependency to make it
optional as well. Bring the two upstream patches allowing openscap build
without any crypto backend. Those patches can be dropped once openscap
v1.4.5 is released.
[0] https://github.com/OpenSCAP/openscap/issues/2310
[1] d12d820a94
[2] 5b858d1786
Fixes: https://autobuild.buildroot.org/results/4c905c1b0ee384149c3d85e8f2ebf0af3a12c2ad/
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
For unconditional dependencies, using += isn't useful, and our common
practice is to use a simple = assignment.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Added MALI_T76X_STRIP_COMPONENTS = 0 as tar archive follows nonstandard layout with license file being in the topmost directory
Signed-off-by: Sebastian Michel <sebastian.michel@oss.othermo.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The comment about the toolchain requirements to have Python support in
gnuradio is always displayed, even if architecture requirements are
not met and if Python is not enabled. For the latter: the option
BR2_PACKAGE_GNURADIO_PYTHON also depends on python, so it makes sense
for the Config.in comment to also depend on it.
Fixes: 7a546b87d5 ("package/python-numpy: add reverse dependency on packages using python-numpy")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
BR2_PACKAGE_GNURADIO_PYTHON selects BR2_PACKAGE_PYTHON_NUMPY, so it
should inherit its dependencies, but BR2_TOOLCHAIN_GCC_AT_LEAST_9 was
forgotten in commit 8b3993178d, when
python-numpy got this gcc >= 9 dependency added.
Note that the existing BR2_HOST_GCC_AT_LEAST_9 dependency is correct:
it is there because gnuradio needs host-python-numpy at build time.
Fixes: 8b3993178d ("package/python-numpy: needs gcc >= 9")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This commit fixes 3 issues in the Config.in comment:
- It is displayed even on unsupported CPU architectures, so we add a
"depends on BR2_PACKAGE_TENSORFLOW_LITE_ARCH_SUPPORTS"
- It doesn't mention the need for a glibc toolchain even though that's
part of the dependencies
- The requirement for dynamic lib support should be part of the same
comment as the other dependencies
Fixes: fd29fee3a3 ("package/tensorflow-lite: new package")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
BR2_PACKAGE_TENSORFLOW_LITE selects BR2_PACKAGE_LIBABSEIL_CPP without
propagating its depends on BR2_PACKAGE_LIBABSEIL_CPP_ARCH_SUPPORTS,
which this commit fixes.
Note that this doesn't create any functional change: tensorflow-lite
is anyway limited to ARM, ARM64, x86 32-bit and x86 64-bit, all of
which are supported by libabseil-cpp.
Fixes: fd29fee3a3 ("package/tensorflow-lite: new package")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
BR2_PACKAGE_RPI_RGB_LED_MATRIX_VIDEO_VIEWER selects
BR2_PACKAGE_FFMPEG, but without propagating its depends on, and most
notably BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS.
Fixes: e821078031 ("package/rpi-rgb-led-matrix: new package")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Another instance of libaseil-cpp requiring gcc >= 10, which means
protobuf needs >= 10, and that wasn't propagated to all reverse
dependencies of protobuf, in this commit: opencv4.
Fixes: 76241e89e1 ("package/libabseil-cpp: bump to version 20260817.0")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
libgtk3 selects at-spi2-core, so it should inherit its
!BR2_STATIC_LIBS, which this commit does.
This has been an issue since libgtk3 started using at-spi2-core
instead of atk in commit 2c3ca7bea1.
Fixes: 2c3ca7bea1 ("package/atk: remove package")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Commit 0b9efc991f ("linux: use BR2_MAKE", 2023-04-10) replaced $(MAKE)
with $(BR2_MAKE) in a number of recipes. As a consequence, the child
make is unable to discover the job server, in some cases. In those
cases, we get a warning such as:
> warning: jobserver unavailable: using -j1. Add `+' to parent make rule.
See [1] and [2].
Falling back to single job can make build considerably longer.
This longer build time issue can be reproduced in specific
conditions. This situation happens when:
1. The top GNU Make is using a "pipe" jobserver.
This is the default when GNU Make <= 4.3 is used (and v4.3 is the
version inside the current Buildroot Docker reference image).
Make > 4.3 changed the default jobserver style to "fifo".
See [3][4]. With Make > 4.3, the issue can be reproduced by
calling "make --jobserver-style=pipe ...".
2. The root filesystem is an initramfs linked into the Kernel
(i.e. using the config BR2_TARGET_ROOTFS_INITRAMFS=y)
3. Buildroot per-package directories is used
(i.e. using the config BR2_PER_PACKAGE_DIRECTORIES=y)
4. The build is made in parallel, with 2 or more jobs. For example:
make -j$(nproc)
Overall, the issue can be reproduced with the commands:
utils/docker-run
cat >.config <<EOF
BR2_aarch64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_PER_PACKAGE_DIRECTORIES=y
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG=y
BR2_TARGET_ROOTFS_INITRAMFS=y
EOF
make olddefconfig
make -j$(nproc)
The Linux Kernel is built once (with a fake empty initramfs cpio
image), when build log is showing ">>> linux 7.2.6 Building". Then,
at the end of the Buildroot build, once the CPIO filesystem is
complete, it is integrated inside the Kernel with an extra "make"
invocation when the build log shows
">>> Rebuilding kernel with initramfs".
This second kernel "make" is not expected to rebuild the whole
kernel, since compiled objects from the first compilation are still
here. However, in the described conditions, the second kernel is
fully rebuilt. This is an undesired behaviour. The Make jobserver
issue adds up to that: this second full kernel is rebuilt with only
one job, which can significantly increase the build time.
Running the previous example on a host with 128 CPUs:
without this change, build takes 1h5m,
with this change, build takes 7m.
Note: using GNU Make >= 4.4 (with a fifo jobserver style by default)
or removing per-package directories no longer produces the issue.
For reference, running the example, without this change and without
per-package directories on the same host, the build takes 10 mins.
This commit improves the situation by prefixing the recipe with "+",
to inform the parent Make that $(BR2_MAKE) can deal with the job
server. This will give a chance to do jobs in parallel, in general.
Note: the pkg-generic.mk infra already has '+' for _BUILD_CMDS, which is
why other $(BR2_MAKE) invocations in linux.mk does not need this '+'.
See [5].
[1] https://www.gnu.org/software/make/manual/html_node/Error-Messages.html
[2] https://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html
[3] https://www.gnu.org/software/make/manual/html_node/Options-Summary.html#index-_002d_002djobserver_002dstyle
[4] https://cgit.git.savannah.gnu.org/cgit/make.git/commit/?id=7ad2593b2d2bb5b9332f4444d8bf93ac6f958bc6
[5] 069b33a30e
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Oleg Lyovin <ovlevin@sberdevices.ru>
Cc: buildroot@buildroot.org
Signed-off-by: Laszlo Ersek <laszlo.ersek@arm.com>
[Julien: extend commit log]
Signed-off-by: Julien Olivain <ju.o@free.fr>
Texas Instrument is a semiconductor company that designs, manufactures
and sells analog and embedded processing chips for markets such as
industrial, automotive, personal electronics, enterprise systems and
communications equipment [1][2].
Thank you for sponsoring LTS maintenance !
[1] https://www.ti.com/
[2] https://www.linkedin.com/company/texas-instruments
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Buildroot commit c5c0a76751 bumped weston
to 16.0.0 causing a configure error with cog:
Run-time dependency libweston-15-protocols found: NO (tried pkg-config)
Run-time dependency libweston-14-protocols found: NO (tried pkg-config)
Run-time dependency libweston-13-protocols found: NO (tried pkg-config)
Run-time dependency libweston-12-protocols found: NO (tried pkg-config)
Run-time dependency libweston-11-protocols found: NO (tried pkg-config)
Run-time dependency libweston-10-protocols found: NO (tried pkg-config)
Run-time dependency libweston-9-protocols found: NO (tried pkg-config)
Run-time dependency libweston-8-protocols found: NO (tried pkg-config)
output/build/cog-0.18.5/platform/wayland/meson.build:67:8: ERROR:
Problem encountered: No usable weston-protocols dependency found
This error was not yet found by the autobuilders and is solved by adding
a patch James Hilliard sent upstream.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
python-grpcio builds its own bundled copy of abseil-cpp, which only
implements DirectMmap() with mmap2 for the o32 ABI on MIPS:
#if ... (defined(__mips__) && _MIPS_SIM == _MIPS_SIM_ABI32) || ...
With the n32 ABI, the "remaining 64-bit architectures" fallback is
selected instead, which fails to build because long is 32-bit there:
third_party/abseil-cpp/absl/base/internal/direct_mmap.h:130:39:
error: static assertion failed: Platform is not 64-bit
130 | static_assert(sizeof(unsigned long) == 8, "Platform is not 64-bit");
| ~~~~~~~~~~~~~~~~~~~~~~^~~~
third_party/abseil-cpp/absl/base/internal/direct_mmap.h:130:39:
note: the comparison reduces to '(4 == 8)'
This is the same defect fixed for libabseil-cpp in the previous patch,
but the dependency added there does not help here: python-grpcio does
not use the Buildroot abseil, it compiles the copy bundled in the
tarball.
Using the Buildroot-provided abseil instead is not an option today.
setup.py does have a GRPC_PYTHON_BUILD_SYSTEM_ABSL knob, but it is
hardcoded to the build machine paths:
if BUILD_WITH_SYSTEM_ABSL:
CORE_C_FILES = filter(
lambda x: "third_party/abseil-cpp" not in x, CORE_C_FILES
)
ABSL_INCLUDE = (os.path.join("/usr", "include"),)
[...]
if BUILD_WITH_SYSTEM_ABSL:
EXTENSION_LIBRARIES += tuple(
lib.stem[3:]
for lib in sorted(pathlib.Path("/usr").glob("lib*/libabsl_*.so"))
)
i.e. it would pick up the host headers and host libraries, so it cannot
be used when cross-compiling without patching setup.py. And even with
such a patch it would not fix this build failure, since Buildroot's
abseil has the very same limitation.
So just disable the package for the n32 ABI. The o32 and n64 ABIs are
unaffected. Note that n32 is the default ABI for BR2_mips64/BR2_mips64el,
so this affects every mips64 build that does not explicitly select n64.
For the LTS maintainers: python-grpcio gained MIPS support in commit
2bfad952c3, released in 2024.02, and the autobuilders have been hitting
this ever since, already with grpcio 1.60.0, the version shipped in
2024.02:
https://autobuild.buildroot.net/results/e6cb7f473a28af8b53e7cbb8d8a582adffdeb66e/
It is still reproduced on 2025.02.x:
https://autobuild.buildroot.net/results/9cf98bff7ce05262d6ff4221953901ae5543880e/
so a backport is needed there.
Fixes: 2bfad952c3 ("package/python-grpcio: add BR2_PACKAGE_PYTHON_GRPCIO_ARCH_SUPPORTS")
Fixes:
https://autobuild.buildroot.net/results/90405c0a3d0b2e929d5074305906e6fe3679298c/
Assisted-by: Claude:claude-opus-5
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
absl::base_internal::DirectMmap() only implements mmap() via mmap2 for
the o32 ABI on MIPS:
#if ... (defined(__mips__) && _MIPS_SIM == _MIPS_SIM_ABI32) || ...
With the n32 ABI, the "remaining 64-bit architectures" fallback is
selected instead, which fails to build because long is 32-bit there:
absl/base/internal/direct_mmap.h: In function 'void* absl::lts_20260107::base_internal::DirectMmap(void*, size_t, int, int, int, off_t)':
absl/base/internal/direct_mmap.h:130:39: error: static assertion failed: Platform is not 64-bit
130 | static_assert(sizeof(unsigned long) == 8, "Platform is not 64-bit");
| ~~~~~~~~~~~~~~~~~~~~~~^~~~
absl/base/internal/direct_mmap.h:130:39: note: the comparison reduces to '(4 == 8)'
direct_mmap.h is included by absl/base/internal/low_level_alloc.cc and
absl/base/internal/poison.cc, which are always built, so the failure is
unconditional. Upstream abseil has no support for the n32 ABI, so
disable the package for that ABI.
Since n32 is the default ABI for BR2_mips64/BR2_mips64el, this affects
every mips64 build that does not explicitly select n64. The o32
(BR2_MIPS_OABI32) and n64 (BR2_MIPS_NABI64) ABIs are unaffected, and all
in-tree mips64 defconfigs use n64.
For the LTS maintainers: the ABI list in direct_mmap.h is identical in
abseil 20200225 (the version in tree when the arch dependencies were
introduced) and in the current 20260817.0, so the failure has existed
ever since mips64 was allowed. It is still reproduced on all maintained
branches, e.g.:
2026.02.x https://autobuild.buildroot.net/results/5818407a73cfd3371cd1f726a24df6ceb9afa42d/
2025.02.x https://autobuild.buildroot.net/results/5065bda3b91bdbee53559dd97af8ab5a63a1e112/
so a backport is needed there.
Fixes: ae0557403a ("package/libabseil-cpp: add BR2_PACKAGE_LIBABSEIL_CPP_ARCH_SUPPORTS")
Fixes:
https://autobuild.buildroot.net/results/f375584f3721d61238b9e43d9926e037802f6141/
Assisted-by: Claude:claude-opus-5
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
For change log, see:
https://github.com/mguentner/cannelloni/releases/tag/v2.0.1https://github.com/mguentner/cannelloni/releases/tag/v2.1.0https://github.com/mguentner/cannelloni/releases/tag/v2.1.1https://github.com/mguentner/cannelloni/releases/tag/v2.1.2
2.1.2 fixes CVE-2026-37539 (CVSS 3.1 score 9.8, CWE-121): a stack based
buffer overflow in CAN frame parsing, in parseCANFrame() in parser.cpp
and decodeFrame() in decoder.cpp, allowing remote attackers to cause a
denial of service (crash) or possibly execute arbitrary code via
crafted CAN FD frames.
The advisory names v2.0.0 explicitly, so the version used so far is
affected. The CVE is not reported by
https://security.buildroot.org/master/component/cannelloni because its
NVD entry has no CPE data (vendor and product are both "n/a") and can
therefore not be matched against the package version.
Apart from the security fix, 2.0.0..2.1.2 contains only a handful of
changes: undeliverable frames are dropped after a timeout on a broken
CAN bus, variable length arrays are gone, the default remote address is
fixed, and pthreads are looked up with the CMake module instead of by
hand. 2.1.1 is a maintenance release only, as the 2.1.0 tag pointed to
a commit that was not the final one.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Buildroot commit 526f8b43ed bumped CMake
from 4.3.4 to 4.4.0 causing a configure error with this package:
CMake Error at Source/cmake/WebKitMacros.cmake:311 (if):
if given arguments:
"(" "NOT" "_linked_into" ")" "OR" "(" "WTF" "STREQUAL" ")" "OR" "("
"NOT" "IN_LIST" "LLIntSettingsExtractor_FRAMEWORKS" ")"
Unknown arguments specified
Call Stack (most recent call first):
Source/cmake/WebKitMacros.cmake:393 (_WEBKIT_TARGET_LINK_FRAMEWORK)
Source/JavaScriptCore/CMakeLists.txt:409 (WEBKIT_EXECUTABLE)
The error can be reproduced with this defconfig:
BR2_x86_64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_FORCE_HOST_BUILD=y
BR2_PACKAGE_MESA3D=y
BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_SOFTPIPE=y
BR2_PACKAGE_MESA3D_OPENGL_EGL=y
BR2_PACKAGE_MESA3D_OPENGL_ES=y
BR2_PACKAGE_WPEWEBKIT=y
BR2_PACKAGE_WPEWEBKIT_SANDBOX=y
BR2_PACKAGE_WPEWEBKIT_MULTIMEDIA=y
BR2_PACKAGE_WPEWEBKIT_MEDIA_STREAM=y
BR2_PACKAGE_WPEWEBKIT_WEBDRIVER=y
To fix the problem we add an upstream commit.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Commit 1f7efaf89f ("package/qemu: do not support x86_steamroller or
x86_core_avx2") excluded BR2_x86_steamroller from
BR2_PACKAGE_HOST_QEMU_ARCH_SUPPORTS. This is still needed, but for a
different reason than AVX, and the exclusion is incomplete.
steamroller is bdver3, and what the Qemu TCG engine cannot emulate
there is not AVX, but the Bulldozer-specific XOP, FMA4, TBM and LWP
extensions. In Qemu 11.0.0 (the version we currently package) and
11.1.1, target/i386/cpu.c has:
#define TCG_EXT3_FEATURES (CPUID_EXT3_LAHF_LM | CPUID_EXT3_SVM | \
CPUID_EXT3_CR8LEG | CPUID_EXT3_ABM | CPUID_EXT3_SSE4A | \
CPUID_EXT3_3DNOWPREFETCH | CPUID_EXT3_KERNEL_FEATURES | \
CPUID_EXT3_CMP_LEG)
CPUID_EXT3_XOP, CPUID_EXT3_FMA4, CPUID_EXT3_TBM and CPUID_EXT3_LWP are
defined in target/i386/cpu.h, but are not part of that mask, i.e. TCG
does not implement them. Binaries using those instructions therefore
die with:
qemu: uncaught target signal 4 (Illegal instruction) - core dumped
This affects the whole Bulldozer family, not only steamroller:
bulldozer (bdver1), piledriver (bdver2) and excavator (bdver4) are
equally unsupported, but were never excluded.
Use the newly introduced BR2_X86_CPU_HAS_XOP symbol, which covers all
four variants, instead of listing BR2_x86_steamroller alone. As for
AVX512, this disables gobject-introspection and nodejs, which are the
two packages needing host-qemu in user mode.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The AMD Bulldozer family (bdver1 to bdver4, i.e. bulldozer, piledriver,
steamroller and excavator) is the only x86 family implementing the XOP
instruction set, together with the equally Bulldozer-specific FMA4 and
LWP extensions, and TBM starting with bdver2. All of them were dropped
again with Zen.
This can be verified with:
$ gcc -march=bdver1 -Q --help=target | grep -E '\-m(xop|fma4|tbm|lwp)'
-mfma4 [enabled]
-mlwp [enabled]
-mtbm [disabled]
-mxop [enabled]
$ gcc -march=bdver2 -Q --help=target | grep -E '\-m(xop|fma4|tbm|lwp)'
-mfma4 [enabled]
-mlwp [enabled]
-mtbm [enabled]
-mxop [enabled]
with bdver3 and bdver4 behaving like bdver2.
Add a hidden BR2_X86_CPU_HAS_XOP capability symbol and select it from
those four CPU variants, so that packages which cannot cope with this
instruction set can depend on it, instead of listing the CPU variants
one by one. The first user is host-qemu, whose TCG engine does not
implement XOP.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Commit 1f7efaf89f ("package/qemu: do not support x86_steamroller or
x86_core_avx2") excluded BR2_x86_core_avx2 from
BR2_PACKAGE_HOST_QEMU_ARCH_SUPPORTS because binaries built for that CPU
variant crashed under qemu-user. This was done at the time of Qemu 4.2,
whose TCG engine did not implement AVX at all.
Since Qemu 7.2, the TCG engine implements AVX, AVX2, F16C, FMA3 and
VAES. In Qemu 11.0.0 (the version we currently package) and 11.1.1,
target/i386/cpu.c has:
#define TCG_EXT_FEATURES (... | CPUID_EXT_AVX | CPUID_EXT_F16C | \
CPUID_EXT_FMA | ...)
#define TCG_7_0_EBX_FEATURES (... | CPUID_7_0_EBX_BMI1 | \
CPUID_7_0_EBX_BMI2 | CPUID_7_0_EBX_AVX2 | ...)
which covers everything gcc generates for -march=core-avx2.
In addition, the exclusion was inconsistent: gcc's core-avx2 is a
deprecated alias for haswell, both variants select exactly the same
BR2_X86_CPU_HAS_* symbols in arch/Config.in.x86, and haswell was never
excluded. The same goes for broadwell, skylake, zen*, x86-64-v3, ...,
which all enable AVX2 and build fine on the autobuilders.
So drop the BR2_x86_core_avx2 exclusion.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Upstream added the configure option --enable-tests with commit
6ba949601d
which was first released in version 2.15.0.
While bumping the package from 2.14.0 to 2.16.0 with buildroot commit
edd3a015cd this new option was not taken
into consideration. We can therefore now remove our own patch to
implement this configure option.
Renumbered remaining patch.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Adds double-width UTF-8 rendering with Unicode 17 character widths,
a new line-wrap-mode, shift-PgUp/PgDn selection, and yaml, text,
git-commit, diff, conf and makefile modes with syntax highlighting.
Fixes shifted-key selection in VTE terminals built --without-curses
and several ~/.mg startup file bugs.
Release notes: https://github.com/troglobit/mg/releases/tag/v4.1
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Fixes:
https://autobuild.buildroot.net/results/d43/d4364f6e3636c696471bf8cba6d308439130e53a/
In function 'MakeIv',
inlined from 'TestSymmetricAlgorithm' at AlgorithmTests.c:197:25:
AlgorithmTests.c:181:23: error: writing 32 bytes into a region of size
16 [-Werror=stringop-overflow=]
The build error occurs with gcc 15.x on some platforms, gcc 14.x is not
affected.
These defconfigs build without this patch:
BR2_x86_64=y
BR2_GCC_VERSION_14_X=y
BR2_PACKAGE_IBM_SW_TPM2=y
BR2_x86_64=y
BR2_x86_x86_64_v4=y
BR2_GCC_VERSION_14_X=y
BR2_PACKAGE_IBM_SW_TPM2=y
BR2_x86_64=y
BR2_PACKAGE_IBM_SW_TPM2=y
This gcc-15 based defconfig is broken:
BR2_x86_64=y
BR2_x86_x86_64_v4=y
BR2_PACKAGE_IBM_SW_TPM2=y
The build error is not related to the recent bump of the package from
rev183-2024-03-27 to rev183-2026-08-26 because no changes were committed
upstream to AlgorithmTests.c since rev183-2024-03-27:
https://github.com/kgoldman/ibmswtpm2/commits/master/src/AlgorithmTests.c
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
When CUPS is built with D-Bus enabled,
install cups.conf under /usr/share/dbus-1/system.d
as it already happens in other packages that have D-Bus configs
e.g. dnsmasq, wpa_supplicant etc.
Signed-off-by: Andreas Vida <andreas.vida@ginzinger.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Fixes build error:
In file included from client.c:14:
client.c: In function 'JNI_OnLoad':
./../../src/est/est.h:834:10: error: implicit declaration of function 'ERR_load_crypto_strings'; did you mean 'ERR_load_CRYPTO_strings'? [-Wimplicit-function-declaration]
834 | do { ERR_load_crypto_strings(); \
| ^~~~~~~~~~~~~~~~~~~~~~~
client.c:88:9: note: in expansion of macro 'est_apps_startup'
88 | est_apps_startup();
| ^~~~~~~~~~~~~~~~
./../../src/est/est.h:836:10: error: implicit declaration of function 'ENGINE_load_builtin_engines' [-Wimplicit-function-declaration]
836 | ENGINE_load_builtin_engines(); \
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
client.c:88:9: note: in expansion of macro 'est_apps_startup'
88 | est_apps_startup();
| ^~~~~~~~~~~~~~~~
client.c: In function 'JNI_OnUnload':
./../../src/est/est.h:860:40: error: implicit declaration of function 'ENGINE_cleanup'; did you mean 'EVP_PBE_cleanup'? [-Wimplicit-function-declaration]
860 | OBJ_cleanup(); EVP_cleanup(); ENGINE_cleanup(); \
| ^~~~~~~~~~~~~~
client.c:101:9: note: in expansion of macro 'est_apps_shutdown'
101 | est_apps_shutdown();
| ^~~~~~~~~~~~~~~~~
./../../src/est/est.h:862:10: error: implicit declaration of function 'ERR_free_strings'; did you mean 'ERR_load_EC_strings'? [-Wimplicit-function-declaration]
862 | ERR_free_strings(); } while (0)
| ^~~~~~~~~~~~~~~~
client.c:101:9: note: in expansion of macro 'est_apps_shutdown'
101 | est_apps_shutdown();
| ^~~~~~~~~~~~~~~~~
client.c: In function 'est_client_raise_exception':
client.c:122:17: error: implicit declaration of function 'ERR_print_errors_fp' [-Wimplicit-function-declaration]
122 | ERR_print_errors_fp(stderr);
| ^~~~~~~~~~~~~~~~~~~
seen with this defconfig
BR2_PACKAGE_OPENJDK=y
BR2_PACKAGE_LIBEST=y
The failing code was added upstream on Jul, 6th, 2020:
ab998c0918
and included in version 3.2.0.
Buildroot commit 5bbb1834a4 bumped the
package to a tree including the aforementioned upstream commit on Jul
24th, 2022 so a backport to LTS branches should be considered.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
https://lists.exim.org/lurker/message/20260820.154633.91995f73.en.html
Rebased patch 0001.
Updated patch 0005, the previous version was applied upstream with
commit 497e9eb7e77ad27ae1d45281e23eefadfaa7a3bc but it did not fix all
linker errors so we sent a new patch upstream which replaces the
previous patch.
Updated hash of GPL-2.0 license file (address, name of president and
typos), a commit can not be provided from the source tree.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Add an infrastructure test case to verify that the per-package
<PKG>_FLAT_STACKSIZE variable correctly configures the stack size in the
generated FLAT binary header.
Signed-off-by: Fengwei Tan <tfx2001@outlook.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The comment should be shown when !BR2_INSTALL_LIBSTDCPP is true, also
treat BR2_PACKAGE_LIBURCU_ARCH_SUPPORTS as arch dependency.
Fixes: 54f96add94 ("package/bind: security bump version to 9.20.24")
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
No autobuilder errors were recorded, the build error can be reproduced
with this defconfig:
BR2_x86_64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV=y
BR2_PACKAGE_MESA3D=y
BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_SOFTPIPE=y
BR2_PACKAGE_MESA3D_OPENGL_GLX=y
BR2_PACKAGE_MESA3D_OPENGL_EGL=y
BR2_PACKAGE_QT5=y
BR2_PACKAGE_QT5WEBENGINE=y
BR2_PACKAGE_XORG7=y
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
https://github.com/tpm2-software/tpm2-openssl/releases/tag/1.3.0
Update license hash due to copyright year bump:
3fb3a5ff7f
Pass -Wno-error to make sure warnings are not treated as errors, to
workaround the fact that -Werror is pasedd by the build system since
upstream commit
c3a8758cad
first included in this release.
This fixes a build error seen with the Gitlab pipelines for
bootlin-aarch64-glibc-old:
src/tpm2-provider-encoder.c:
In function ‘tpm2_rsa_encoder_encode_SubjectPublicKeyInfo_der’:
src/tpm2-provider-encoder.c:86:71: error: the comparison will always evaluate as ‘true’ for the address of ‘tpm2_rsa_encode_public_
SubjectPublicKeyInfo_der’ will never be NULL [-Werror=address]
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Building gobject-introspection for an x86 CPU variant with AVX512 fails
when g-ir-scanner runs the freshly built target binaries under
qemu-user:
qemu: uncaught target signal 4 (Illegal instruction) - core dumped
The Qemu TCG engine implements AVX, AVX2, F16C, FMA3 and VAES since Qemu
7.2, but it does not implement the AVX512 instruction set at all [0].
Therefore no -cpu value passed through
BR2_PACKAGE_HOST_QEMU_USER_MODE_ARGS can make such binaries run, and
user-mode emulation is simply not possible for these CPU variants.
Mark those CPUs as unsupported by host-qemu, the same way it is already
done for x86_steamroller and x86_core_avx2. This relies on the existing
BR2_X86_CPU_HAS_AVX512 symbol, so all AVX512 capable variants are
covered, and it disables gobject-introspection and nodejs, which are the
two packages needing host-qemu in user mode.
[0] https://gitlab.com/qemu-project/qemu/-/issues/2878
Fixes:
https://autobuild.buildroot.org/results/7ed7f9c36dae1ddb965a0f0021db6cd319927b47/
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Changelog:
- 74f6277 cli: in batch mode, print empty line if get fails
- ccc1719 libuci: fix extra new lines added to errorstr
- 66127cd formal: fix workflow permissions
- 5bea135 github: ci: add MIPS64, PowerPC64 and RISCV64
- ebb3a01 build: install uci
- 238963f github: ci: add powerpc arch
- dec51f4 github: ci: add cmake build and source directories
- 8022b2e uci: add a simple build script
- e1ab90c github: ci: add tests
- b65c091 github: ci: disable json-c tests
- c1e2eee github: fix CI apt dependencies
- 2e46a74 github: improve CI
- 57c1e8c github: add CI build
- 5e69eda CMakeLists: fix CMake warning for INCLUDE macro
- 272fc13 lua: CMakeLists: drop redundant cmake_minimum_required
- a072095 lua: CMakeLists: update cmake minimum required version to 3.10
- 9033e8c blob: use blobmsg_parse_attr in __uci_blob_check_equal
This bump fixes the configure failure with cmake 4.x when the Lua
bindings are enabled: upstream commits a072095 and 272fc13 drop the
"cmake_minimum_required(VERSION 2.6)" statement from lua/CMakeLists.txt,
so the Lua subdirectory now inherits the top-level 3.13 minimum instead
of being rejected with "Compatibility with CMake < 3.5 has been removed
from CMake".
The license file hashes are updated as well, cli.c and libuci.c changed
but their license headers are untouched.
Fixes:
https://autobuild.buildroot.org/results/43ce08497863ff54c8acf3b0bbe7cfbdbc640d14/
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
BR2_PACKAGE_WPEWEBKIT_MULTIMEDIA selects BR2_PACKAGE_GST1_LIBAV, which
depends on BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS, but doesn't propagate
this dependency. In practice, there is no issue, as webkitgtk is only
available on a subset of CPU architectures, while
BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS makes ffmpeg available on pretty much
all CPU architectures, except Cortex-M, m68k coldfire, and some
specific cases of OpenRISC, which are not supported by webkitgtk.
But for the sake of having correct dependency propagation, let's fix
this.
The other packages selected by BR2_PACKAGE_WPEWEBKIT_MULTIMEDIA have
dependencies that are already handled at the top-level
BR2_PACKAGE_WPEWEBKIT option.
Signed-off-by: Michael Nosthoff <buildroot@heine.tech>
CC: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Acked-by: Adrian Perez de Castro <aperez@igalia.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
In commit
0e2c958e05 ("package/libseccomp: bump to
version 2.5.3"), the kernel headers dependency of seccomp was bumped
from 3.12 to 3.17, but BR2_PACKAGE_WEBKITGTK_SANDBOX, which is a
reverse dependency of BR2_PACKAGE_LIBSECCOMP was forgotten.
This commit fixes this inconsistency.
Fixes: 0e2c958e05 ("package/libseccomp: bump to version 2.5.3")
Signed-off-by: Michael Nosthoff <buildroot@heine.tech>
CC: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The 0002-Update-linker-flags.patch assumes that the qemu-xen files are included
in the xen source tree. However, if BR2_PACKAGE_XEN_TOOLS is not enabled, the
qemu-xen dependency will not be handled and the patch will fail to apply with
the following error.
Fixes: build error below
Applying 0002-Update-linker-flags.patch using patch:
patching file tools/Makefile
Hunk #1 succeeded at 36 (offset -1 lines).
Hunk #2 succeeded at 185 (offset -8 lines).
can't find file to patch at input line 76
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/tools/qemu-xen/include/hw/xen/xen_native.h b/tools/qemu-xen/include/hw/xen/xen_native.h
|index 6bcc83ba..2590904e 100644
|--- a/tools/qemu-xen/include/hw/xen/xen_native.h
|+++ b/tools/qemu-xen/include/hw/xen/xen_native.h
--------------------------
No file to patch. Skipping patch.
1 out of 1 hunk ignored
make: *** [package/pkg-generic.mk:239: output/build/xen-4.21.1/.stamp_patched] Error 1
To avoid making BR2_PACKAGE_XEN_TOOLS a required option, fix the
0002-Update-linker-flags.patch so that modifying source from the qemu-xen
package is no longer included.
Instead of patching qemu-xen, a better solution is undefining the
__XEN_INTERFACE_VERSION__ from the qemu-xen package.
To test:
BR2_aarch64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_AARCH64_GLIBC_STABLE=y
BR2_PACKAGE_XEN=y
# BR2_PACKAGE_XEN_TOOLS is not set
Signed-off-by: Neal Frager <neal.frager@amd.com>
Tested-by: Matt Weber <matt@thewebers.ws>
Reviewed-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
BR2_PACKAGE_GLSLSANDBOX_PLAYER_SCRIPTS needs the full blown version of
bash and coreutils, so it selects BR2_PACKAGE_BUSYBOX_SHOW_OTHERS, but
it does so only if BR2_PACKAGE_BUSYBOX=y. Which kind of makes sense,
but is not aligned with the vast majority of other places where
BR2_PACKAGE_BUSYBOX_SHOW_OTHERS is selected, where
BR2_PACKAGE_BUSYBOX_SHOW_OTHERS is selected unconditionally. Harmonize
this with other packages.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
BR2_PACKAGE_XEN_TOOLS needs the full blown version of bash and
coreutils, so it selects BR2_PACKAGE_BUSYBOX_SHOW_OTHERS, but it does
so only if BR2_PACKAGE_BUSYBOX=y. Which kind of makes sense, but is
not aligned with the vast majority of other places where
BR2_PACKAGE_BUSYBOX_SHOW_OTHERS is selected, where
BR2_PACKAGE_BUSYBOX_SHOW_OTHERS is selected unconditionally. Harmonize
this with other packages.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
ndctl selects kmod and keyutils, both of which depend on
!BR2_STATIC_LIBS, but this dependency was not propagated into ndctl
when the package was introduced. This commit fixes this issue.
Fixes: 039c1ae13e ("package/ndctl: new package")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The Config.in comment has the correct dependency on
!BR2_TOOLCHAIN_HAS_THREADS, but that was not reflected in the comment
text itself.
Fixes: 039c1ae13e ("package/ndctl: new package")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
BR2_PACKAGE_STRONGSWAN_BOTAN selects BR2_PACKAGE_BOTAN, but since
commit 10a70b1af6, botan needs gcc 11,
which was not propagated to strongswan's botan option. This commit
fixes this issue.
Fixes: 10a70b1af6 ("package/botan: needs gcc >= 11")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
gerbera selects BR2_PACKAGE_ICU, which depends on !BR2_BINFMT_FLAT,
but this dependency was not propagated to gerbera. In practice this is
not an issue because gerbera depends on BR2_USE_MMU, and only noMMU
platforms can use BR2_BINFMT_FLAT. But for the sake of completeness,
let's propagate this dependency.
Note: in the Config.in comment, we handle it like an architecture
dependency, like is done in package/icu/Config.in.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Since the bump of libabseil-cpp in commit
76241e89e1, it requires gcc 10. As part
of this commit, the protobuf package was updated, but not its reverse
dependency netdata. This commit fixes this issue.
Fixes: 76241e89e1 ("package/libabseil-cpp: bump to version 20260817.0")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
BR2_PACKAGE_SYSPROF selects BR2_PACKAGE_LIBDEX but did not propagate:
depends on BR2_TOOLCHAIN_HAS_UCONTEXT || \
BR2_PACKAGE_LIBUCONTEXT_ARCH_SUPPORTS
from libdex. This commit fixes this missing dependency. In terms of
Config.in comment, we do the same as what libdex is doing: handle it
as a toolchain dependency (rather than an architecture dependency).
This was missed in commit a73ef093f7,
which added the ucontext related dependency to libdex, without
propagating it to sysprof.
Fixes: a73ef093f7 ("package/libdex: needs ucontext")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
BR2_PACKAGE_RPI_RGB_LED_MATRIX_IMAGE_VIEWER selects
BR2_PACKAGE_GRAPHICSMAGICK, but did not propagate its BR2_USE_MMU
dependency. This issue exists since the package was introduced in
commit e821078031.
It fixes the following Kconfig warning:
WARNING: unmet direct dependencies detected for BR2_PACKAGE_GRAPHICSMAGICK
Depends on [n]: BR2_USE_MMU [=n] && BR2_TOOLCHAIN_HAS_THREADS [=y]
Selected by [y]:
- BR2_PACKAGE_RPI_RGB_LED_MATRIX_IMAGE_VIEWER [=y] && BR2_PACKAGE_RPI_RGB_LED_MATRIX [=y]
which occurs when you configure an ARM noMMU FDPIC toolchain (because
we have noMMU, but shared libraries, so rpi-rgb-led-matrix can be
enabled).
Fixes: e821078031 ("package/rpi-rgb-led-matrix: new package")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Since the bump of libabseil-cpp in commit
76241e89e1, it requires gcc 10. As part
of this commit, the webrtc-audio-processing package was updated, but
not its reverse dependency gst1-plugins-bad. This commit fixes this
issue.
Fixes: 76241e89e1 ("package/libabseil-cpp: bump to version 20260817.0")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
There's recently been autobuilder failures on
toolchain-external-bootlin, but I wasn't getting notified in the daily
autobuilder e-mail for those failures, which sounded odd as DEVELOPERS
contains:
N: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[...]
F: toolchain/
And indeed, testing:
$ ./utils/get-developers -p toolchain-external-bootlin
returned nothing.
Turns out that the regexp FIND_INFRA_IN_PATCH and FIND_INFRA_IN_MK
used to find the package infrastructure, and ultimately decide if a
given .mk file contains a package, was a bit too strict:
"^\+\$\(eval \$\((host-)?([^-]*)-package\)\)$"
This would only allow packages named <something>-package or
host-<something>-package, but the <something> should not contain any
dash ("-"). So this works fine for cmake-package,
host-autotools-package, but not for toolchain-external-package where
<something> is toolchain-external and it contains a dash.
We fix this by relaxing the regexp a bit and allowing any character in
<something>. Consider the rest of the regexp that expects $(eval
$(<host>-<something>-package)), it seems highly unlikely to match
anything else but the line we're interested in.
With this fix:
$ ./utils/get-developers -p toolchain-external-bootlin
Giulio Benetti <giulio.benetti@benettiengineering.com>
Romain Naour <romain.naour@gmail.com>
Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This issue has existed since the toolchain-external-package
infrastructure had been added.
Fixes: 1c99d70e52 ("toolchain-external: introduce toolchain-external-package")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Building zabbix without libcurl enabled would lead to the following
error:
/usr/bin/ld: .../src/libs/zbxxml/xml.c:515:(.text+0x1c64): undefined reference to `zbx_vector_str_append'
This issue has been addressed in the upstream commit [1] and backported
as a patch in Buildroot.
For more information see the upstream issue [2].
This error is reproducible with the following defconfig:
cat >.config <<EOF
BR2_arm=y
BR2_cortex_a7=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_PACKAGE_PHP=y
BR2_PACKAGE_ZABBIX=y
BR2_PACKAGE_ZABBIX_SERVER=y
BR2_PACKAGE_ZABBIX_SERVER_COPY_FRONTEND=y
EOF
make oldefconfig
make zabbix
[1] https://git.zabbix.com/projects/ZBX/repos/zabbix/commits/e8333ca2128
[2] https://support.zabbix.com/browse/ZBX-27635
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Zabbix 7.2 is EOL since December 2025 [1]
For more info on the version bump, see:
- https://www.zabbix.com/rn/rn7.2.14
- https://www.zabbix.com/rn/rn7.2.15
This fixes the following vulnerabilties:
- CVE-2026-23920:
Host and event action script input is validated with a regex (set by
the administrator), but the validation runs in multiline mode. If ^
and $ anchors are used in user input validation, an injected newline
lets authenticated users bypass the check and inject shell commands.
https://www.cve.org/CVERecord?id=CVE-2026-23920
- CVE-2026-23921:
A low privilege Zabbix user with API access can exploit a blind SQL
injection vulnerability in include/classes/api/CApiService.php to
execute arbitrary SQL selects via the sortfield parameter. Although
query results are not returned directly, an attacker can exfiltrate
arbitrary database data through time-based techniques, potentially
leading to session identifier disclosure and administrator account
compromise.
https://www.cve.org/CVERecord?id=CVE-2026-23921
[1] https://endoflife.date/zabbix
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Updated the hash of the WHENCE file, due to firmware additions and
firmware changes, but no changes to the redistribution/licensing
conditions.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
check-package reports six warnings on S60lldpd: indentation with
spaces, no DAEMON variable, and shellcheck complaints.
The script also masks failures, the exit status of
"[ $? = 0 ] && echo OK || echo FAIL" is the one of echo, so start and
stop always return success. Stopping does not wait for the daemon to
exit either, so a restart can race the instance on its way out.
Rewrite it after package/busybox/S01syslogd, as the manual asks. lldpd
daemonizes and writes the PID file itself, but does not remove it on
exit, so pass the PID file to both start-stop-daemon and the daemon and
drop the stale file once the process is gone. Also pick up arguments
from /etc/default/lldpd and add the customary reload alias.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
[Julien: remove .checkpackageignore entry to fix check-package error]
Signed-off-by: Julien Olivain <ju.o@free.fr>
Fixes the following vulnerabilities:
- CVE-2026-59679: Font Server Client encoding Out-Of-Bounds Read/Write
- CVE-2026-44950: Font Server Client Cumulative Glyph Data Heap Buffer
Overflow
For more details, see the advisory:
https://lists.x.org/archives/xorg-announce/2026-August/003734.html
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
In commit
76241e89e1 ("package/libabseil-cpp: bump
to version 20260817.0"), libabseil-cpp was bumped, which required the
gcc >= 8.x dependency to be upgraded to a gcc >= 10.x dependency. This
was properly done in package/protobuf as part of this commit, as
protobuf is a reverse dependency of libabseil-cpp.
However, mosh, which is a reverse dependency of protobuf, was
forgotten, and it no longer carries the correct gcc dependency.
This commit fixes this issue.
Fixes: 76241e89e1 ("package/libabseil-cpp: bump to version 20260817.0")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
In commit 203725a46b ("package/clamav:
bump version to 1.0.1"), select BR2_PACKAGE_JSON_C was added to
BR2_PACKAGE_CLAMAV without propagating the BR2_TOOLCHAIN_HAS_SYNC_4
dependency from BR2_PACKAGE_JSON_C.
Since at the same time a dependency on
BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS was added to clamav and
Rust is not supported on the few architectures that don't have 4-byte
sync intrinsics, this has basically no effect, but ensure a correct
propagation of dependencies.
Fixes: 203725a46b ("package/clamav: bump version to 1.0.1")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
BR2_PACKAGE_FALCOSECURITY_LIBS selects BR2_PACKAGE_HOST_GRPC and
BR2_PACKAGE_HOST_PROTOBUF, neither of which exists. These selects are
anyway not needed, so drop them.
Fixes: a15e35c4eb ("falcosecurity-libs: add new package")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
BR2_PACKAGE_WEBKITGTK_MULTIMEDIA selects BR2_PACKAGE_GST1_LIBAV, which
depends on BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS, but doesn't propagate
this dependency. In practice, there is no issue, as webkitgtk is only
available on a subset of CPU architectures, while
BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS makes ffmpeg available on pretty much
all CPU architectures, except Cortex-M, m68k coldfire, and some
specific cases of OpenRISC, which are not supported by webkitgtk.
But for the sake of having correct dependency propagation, let's fix
this.
The other packages selected by BR2_PACKAGE_WEBKITGTK_MULTIMEDIA have
dependencies that are already handled at the top-level
BR2_PACKAGE_WEBKITGTK option.
Fixes: e6e549b9e4 ("ffmpeg: add BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
In commit
0e2c958e05 ("package/libseccomp: bump to
version 2.5.3"), the kernel headers dependency of seccomp was bumped
from 3.12 to 3.17, but BR2_PACKAGE_WEBKITGTK_SANDBOX, which is a
reverse dependency of BR2_PACKAGE_LIBSECCOMP was forgotten.
This commit fixes this inconsistency.
Fixes: 0e2c958e05 ("package/libseccomp: bump to version 2.5.3")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
BR2_PACKAGE_LIBSSH_OPENSSL unconditionnally selects
BR2_PACKAGE_LIBOPENSSL_ENGINES even though libressl is also supported
as an OpenSSL provider (and BR2_PACKAGE_LIBOPENSSL_ENGINES doesn't
make sense for libressl).
This causes the following Kconfig warning:
WARNING: unmet direct dependencies detected for BR2_PACKAGE_LIBOPENSSL_ENGINES
Depends on [n]: <choice> && BR2_PACKAGE_LIBOPENSSL [=n]
Selected by [y]:
- BR2_PACKAGE_LIBSSH_OPENSSL [=y] && <choice> && BR2_PACKAGE_OPENSSL [=y]
We checked that libssh, with OpenSSL support and libressl selected as
an OpenSSL provider works fine, using the following defconfig:
BR2_aarch64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_AARCH64_GLIBC_STABLE=y
BR2_PACKAGE_LIBSSH=y
BR2_PACKAGE_LIBSSH_SERVER=y
BR2_PACKAGE_LIBRESSL=y
Fixes: 62103be918 ("package/libssh: select BR2_PACKAGE_LIBOPENSSL_ENGINES")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
In commit
76241e89e1 ("package/libabseil-cpp: bump
to version 20260817.0"), libabseil-cpp was bumped, which required the
gcc >= 8.x dependency to be upgraded to a gcc >= 10.x dependency. This
was properly done in package/protobuf as part of this commit, as
protobuf is a reverse dependency of libabseil-cpp.
However, usbguard, which is a reverse dependency of protobuf, was
forgotten, and it no longer carries the correct gcc dependency.
This commit fixes this issue.
Fixes: 76241e89e1 ("package/libabseil-cpp: bump to version 20260817.0")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
BR2_PACKAGE_QT5CINEX selects BR2_PACKAGE_QT5BASE_PNG,
BR2_PACKAGE_QT5BASE_WIDGETS and BR2_PACKAGE_QT5BASE_EGLFS, which are
all sub-options of BR2_PACKAGE_QT5BASE_GUI, but we don't explicitly
selects BR2_PACKAGE_QT5BASE_GUI.
It turns out that things work because the package selects
BR2_PACKAGE_QT5GRAPHICALEFFECTS, which selects
BR2_PACKAGE_QT5DECLARATIVE_QUICK, which selects
BR2_PACKAGE_QT5BASE_GUI, but that is rather non-obvious, and it makes
more sense for BR2_PACKAGE_QT5CINEX to directly select
BR2_PACKAGE_QT5BASE_GUI if it also selects sub-options of it.
No functional change.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
- BR2_PACKAGE_IVI_HOMESCREEN_AUDIO_PLAYERS selects gstreamer1, which
has a depends on BR2_USE_MMU, but does not propagate it
- BR2_PACKAGE_IVI_HOMESCREEN_FLUTTER_SECURE_STORAGE_PLUGIN selects
libsecret, which has a depends on BR2_USE_MMU, but does not propagate
it
In practice there is no problem since ivi-homescreen depends on glibc,
and glibc doesn't support any noMMU architecture. But just by walking
the chain of option dependencies, this is not something that is
theoretically guaranteed (making automated verification of
dependencies difficult).
The other "depends on" from gstreamer1 and libsecret, BR2_USE_WCHAR
and BR2_TOOLCHAIN_HAS_THREADS are on the other hand already handled by
the top-level BR2_PACKAGE_IVI_HOMESCREEN option, so there is no
ambiguity.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
BR2_PACKAGE_PULSEVIEW selects BR2_PACKAGE_QT5BASE_PNG and
BR2_PACKAGE_QT5BASE_WIDGETS, which both depend on
BR2_PACKAGE_QT5BASE_GUI. It ends working because we also select
BR2_PACKAGE_QT5SVG, which selects BR2_PACKAGE_QT5BASE_GUI, so there is
no bug, but it's bit inconsistent to select sub-options that have a
"depends on" without selecting the option they depend on.
This not a bug fix, it has no functional implication.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
pocketpy enables thread support by default (PK_ENABLE_THREADS=ON) and
then requires Threads from cmake, which fails on toolchains without
thread support:
CMake Error at /usr/share/cmake-3.28/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
Could NOT find Threads (missing: Threads_FOUND)
Thread support is optional, so enable it only when the toolchain
provides threads.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The definition of BR2_PACKAGE_KODI_ARCH_SUPPORTS is incorrect, it
goes like this:
bool
default y if BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS
default y if BR2_PACKAGE_HOST_OPENJDK_BIN_ARCH_SUPPORTS
so it means it would be "y" if either
BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS *OR*
BR2_PACKAGE_HOST_OPENJDK_BIN_ARCH_SUPPORTS is true. While clearly what
we need is for both to be true: ffmpeg should be available for the
target architecture, and openjdk should be available for the host
architecture.
One option was to change to:
bool
default y if BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS && BR2_PACKAGE_HOST_OPENJDK_BIN_ARCH_SUPPORTS
Or:
bool
default y if BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS
depends on BR2_PACKAGE_HOST_OPENJDK_BIN_ARCH_SUPPORTS
But we preferred:
bool
default y
depends on BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS
depends on BR2_PACKAGE_HOST_OPENJDK_BIN_ARCH_SUPPORTS
Fixes: b6a2f49429 ("package/kodi: depend on host-openjdk-bin instead of selecting BR2_NEEDS_HOST_JAVA")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Even though kodi itself has architecture dependencies (expressed
through BR2_PACKAGE_KODI_ARCH_SUPPORTS, the option
BR2_PACKAGE_KODI_MYSQL selects BR2_PACKAGE_MARIADB, which has its own
architecture dependencies as well. Make sure to propagate those to
BR2_PACKAGE_KODI_MYSQL, which doesn't require adding a Config.in
comment as these are purely architecture dependencies.
We haven't replicate all dependencies of BR2_PACKAGE_MARIADB because
all the others are covered by the top-level BR2_PACKAGE_KODI, and
propagating them would require adding a Config.in comment for
BR2_PACKAGE_KODI_MYSQL.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Since hidapi was introduced in commit
6267f34afd, it forgot to propagate some
dependencies of libgudev (which existed back then). Initially libgudev
was only needed when BR2_INIT_SYSTEMD=y, but still the dependencies
were not propagated for the systemd case.
Anyway, since e739dd5a11, libgudev is a
mandatory dependency of hidapi, independently from the selected init
system.
We make sure to propagate all dependencies of libgudev to hidapi, and
propagate them to the reverse dependencies of hidapi.
Fixes: 6267f34afd ("hidapi: new package")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The backported fix is dropped, as 3.4 ships it:
0001-Fix-163-unterminated-username-used-with-getpwnam.patch
-> upstream commit d73777c2c356, released in 3.4
With the patch gone, LIBCONFUSE_IGNORE_CVES is no longer needed either.
3.4 also fixes three robustness defects that carry no CVE:
#180 isspace() argument fix, could crash the lexer
#182 stack exhaustion from deeply nested sections
#187 null dereference on an empty comment with CFGF_COMMENTS
Upstream release notes:
https://github.com/libconfuse/libconfuse/releases/tag/v3.4
Signed-off-by: Michael Fischer <mf@go-sys.de>
[Fiona: add link to upstream release notes]
Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
The ARMv7 EABIhf toolchains can currently be selected with ARMv8 cores
selected, even when EABI is used due to how the condition is
constructed. This obviously fails as those toolchains are EABIhf,
causing the following build issue:
Incorrect ABI setting: EABI selected, but toolchain is incompatible
This is for example what happens with:
BR2_arm=y
BR2_cortex_a32=y
BR2_ARM_EABI=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV7_EABIHF_GLIBC_BLEEDING_EDGE=y
In order to address this, we adjust the script generating the Bootlin
toolchain package so that EABIhf is required for both ARMv7 and
ARMv8.
Please note that we already require BR2_arm for those toolchains, so
we are *only* talking about ARMv8 cores being used in 32-bit mode.
This will be needed to fix:
https://autobuild.buildroot.org/results/3ce1dbd480c71b782ef722c39034cb039a036523/
Reported-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
BR2_PACKAGE_ARGP_STANDALONE is defined as follows:
config BR2_PACKAGE_ARGP_STANDALONE
depends on !BR2_TOOLCHAIN_USES_GLIBC
Some packages did:
select BR2_PACKAGE_ARGP_STANDALONE if !BR2_TOOLCHAIN_USES_GLIBC
while a number of others did:
select BR2_PACKAGE_ARGP_STANDALONE if BR2_TOOLCHAIN_USES_UCLIBC || BR2_TOOLCHAIN_USES_MUSL
This commit harmonizes the situation, by settling on the first
solution ("if !BR2_TOOLCHAIN_USES_GLIBC") as it matches how
BR2_PACKAGE_ARGP_STANDALONE is defined in the first place.
No functional change.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
BR2_PACKAGE_INTEL_VPL_GPU_RT selects BR2_PACKAGE_INTEL_MEDIADRIVER but
did not propagate "depends on BR2_TOOLCHAIN_GCC_AT_LEAST_8". This
commit fixes this issue, which was introduced in commit
ac65841def, when onevpl-intel-gpu was
introduced (it was later renamed to intel-vpl-gpu-rt).
Fixes: ac65841def ("package/onevpl-intel-gpu: new package")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
BR2_PACKAGE_INTEL_MEDIASDK selects BR2_PACKAGE_INTEL_MEDIADRIVER but
forgets to propagate the "depends on BR2_TOOLCHAIN_GCC_AT_LEAST_8".
This issue was introduced in commit
51b60c8acf, when "depends on
BR2_TOOLCHAIN_GCC_AT_LEAST_8" was added to mesa3d, propagated to
intel-mediadriver, but not intel-mediasdk.
Fixes: 51b60c8acf ("package/mesa3d: needs gcc >= 8")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
BR2_PACKAGE_PYTHON_MEMRAY selects BR2_PACKAGE_LIBUNWIND but forgot to
propagate "depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_9".
Fixes: c2df8bab97 ("package/python-memray: new package")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
BR2_PACKAGE_PYTHON_GRPCIO_REFLECTION selects
BR2_PACKAGE_PYTHON_PROTOBUF, but forgot to replicate "depends on
BR2_PACKAGE_HOST_PROTOBUF_ARCH_SUPPORTS".
Fixes: 3217fedcb8 ("package/python-grpcio-reflection: new package")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
BR2_PACKAGE_PYTHON_GOOGLEAPIS_COMMON_PROTOS selects
BR2_PACKAGE_PYTHON_PROTOBUF but did not propagate
BR2_PACKAGE_HOST_PROTOBUF_ARCH_SUPPORTS.
Fixes: d37766a886 ("package/python-googleapis-common-protos: new package")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Commit 66ddec89e8 ("package/udisks: bump
to version 2.92") mistakenly removed the BR2_USE_MMU dependency of
udisks when dropping "select BR2_PACKAGE_LVM2". Indeed, BR2_USE_MMU is
a dependency of many other packages selected by udisks.
Interestingly, the Config.in comments in the same file still had the
"depends on BR2_USE_MMU" dependencies.
Fixes: 66ddec89e8 ("package/udisks: bump to version 2.92")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Since bcc was introduced in commit
146498d13c, it lacked a dependency
propagation from clang for BR2_TOOLCHAIN_HAS_GCC_BUG_64735, this
commit fixes this mistake.
Fixes: 146498d13c ("package/bcc: new package")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
samba4 is available on !musl, but samba support in mpd is available
only with glibc. Turns out that samba support in mpd builds just fine
with uClibc-ng, and that samba4 no longer needs native RPC support: it
can use libtirpc when needed (it's handled in the samba4 package
itself).
Tested with the following defconfig:
BR2_aarch64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_AARCH64_UCLIBC_BLEEDING_EDGE=y
BR2_PACKAGE_MPD=y
BR2_PACKAGE_MPD_LIBSMBCLIENT=y
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
BR2_PACKAGE_HOST_GO_TARGET_ARCH_SUPPORTS redefines the conditions to
determine if a host go compiler is available for the current host
architecture. Instead, make it explicit that those conditions are the
same by re-using BR2_PACKAGE_HOST_GO_HOST_ARCH_SUPPORTS.
No functional change.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
In commit
fef9cad1fe ("package/libxmlsec1: bump
version to 1.3.12"), libxmlsec1 was bumped, and alongside some
additional "depends on" were added.
However, these new "depends on" were not propagated to reverse
dependencies of libxmlsec1, i.e. openscap, causing Kconfig warnings:
WARNING: unmet direct dependencies detected for BR2_PACKAGE_LIBXMLSEC1
Depends on [n]: BR2_TOOLCHAIN_GCC_AT_LEAST_7 [=n] && BR2_TOOLCHAIN_HAS_ATOMIC [=n]
Selected by [y]:
- BR2_PACKAGE_OPENSCAP [=y] && BR2_PACKAGE_LIBGPG_ERROR_ARCH_SUPPORTS [=y] && !BR2_STATIC_LIBS [=n] && BR2_TOOLCHAIN_HAS_THREADS_NPTL [=y]
and potentially some build issues, even though we didn't check in the
autobuilders for potential failures.
This commit fixes that by properly propagating the new dependencies.
Cc: Alexis Lothoré <alexis.lothore@bootlin.com>
Cc: Julien Olivain <ju.o@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Acked-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Rebased patch 0001 and added Upstream: tag.
Removed patches which are included in this release.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The demo programs, which have always been built and are still enabled by
default, gained a zlib dependency in imlib2 1.12.3: upstream commit
f8a451043871 ("imlib2_load: Add crc32 printout") started using zlib's
crc32() in imlib2_load, and 31006b425e11 ("imlib2_view: Optionally show
crc32 of image data") did the same for imlib2_view. Both hardcoded -lz.
Upstream commit b9555030dace ("autofoo: don't hardcode zlib flags"),
first released in 1.12.4, replaced -lz with $(ZLIB_LIBS) and added an
unconditional PKG_CHECK_MODULES(ZLIB, zlib) to the demo programs branch
of configure, turning the previously silent link-time requirement into a
configure failure:
checking for zlib... no
configure: error: Package requirements (zlib) were not met:
Package 'zlib' not found
As Buildroot went straight from 1.7.3 to 1.12.5 the intermediate state
was never packaged, but the dependency has in fact been missing since the
crc32 support landed.
Fixes: https://autobuild.buildroot.org/results/4e05404c353ef985d74757d0b1ec3eda2cdff523/
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
https://github.com/softhsm/SoftHSMv2/releases/tag/2.7.0
Switched repo to new standalone repo:
2355064ce4
Also update the package home page in Config.in.
We need to use the github helper to download the code which also needs
autoreconf.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
[Julien: update the package home page in Config.in]
Signed-off-by: Julien Olivain <ju.o@free.fr>
https://github.com/apache/thrift/blob/v0.24.0/CHANGES.md
Please note that this bump includes CVE-2026-41608:
https://lists.apache.org/thread/vwsbcwqdpwdtp8qkjo11ol6rodbfm21f
which fixes a security bug in the python bindings that are not used by
buildroot.
Building this defconfig
BR2_aarch64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y
BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y
BR2_TOOLCHAIN_EXTERNAL_URL="http://toolchains.bootlin.com/downloads/releases/toolchains/aarch64--glibc--bleeding-edge-2017.05-toolchains-1-2.tar.bz2"
BR2_TOOLCHAIN_EXTERNAL_GCC_6=y
BR2_TOOLCHAIN_EXTERNAL_HEADERS_4_9=y
BR2_TOOLCHAIN_EXTERNAL_CUSTOM_GLIBC=y
BR2_TOOLCHAIN_EXTERNAL_CXX=y
BR2_PACKAGE_THRIFT=y
without this bump does not cause build errors.
The Gitlab pipelines detected a build error for this bump with the
defconfig bootlin-aarch64-glibc-old:
/builds/bkuhls/buildroot/br-test-pkg/bootlin-aarch64-glibc-old/build/thrift-0.24.0/lib/cpp/src/thrift/transport/TBufferTransports.h:110:32:
error: ‘ptrdiff_t’ does not name a type
To fix the problem we add a patch to include cstddef.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Removed patch 0004 due to upstream commit:
60d60eed11
which removes the patched code part.
Added new patch 0004 to fix build errors resulting from the commit
mentioned above.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
https://github.com/tukaani-project/xz/releases/tag/v5.8.4
- lzma_alone_decoder(), lzma_lzip_decoder(),
lzma_auto_decoder(), and lzma_microlzma_decoder(): Fix an
invalid memory access after memory allocation has failed and
the application reinitializes the existing decoder to decode
a different file. This bug could at least result in a crash.
This is tracked as GHSA-5qpq-xqfv-j9pg. CVE number is pending.
(Also in v5.2, v5.4, and v5.6.)
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes a sandbox escape through symlink traversal tracked in
CVE-2026-87766, which affects all previous versions.
Using the bwrap binary with the setuid bit set is no longer supported
and user namespaces are now always required, so a kernel config fixup
is applied.
A new build option allows indicating the minimum kernel version that
will be used, which removes code used for backwards compatibility with
kernels older than 5.6.0 when a newer version is specified. Passing
$(LINUX_VERSION_PROBED) seems reasonable here.
This version also changed the license from LGPL-2.0+ to LGPL-2.1+,
hence the updated hash.
Release notes:
https://github.com/containers/bubblewrap/releases/tag/v0.12.0
Signed-off-by: Adrian Perez de Castro <aperez@igalia.com>
[Julien: fix _LINUX_CONFIG_FIXUPS by adding the missing "_LINUX"]
Signed-off-by: Julien Olivain <ju.o@free.fr>
The python-propcache package specifies an unnecessarily strict cython
version, disable the check so that we can update cython.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To indicate that a patch fixes a vulnerability in Buildroot, the convention is:
1. In the patch file, add a tag 'CVE: <cve id>'
2. In <pkg>.mk, and an entry to <PKG>_IGNORE_CVES, and add a comment above
that new entry to reference the patch file(s)
However, as packages get bumped and their patches are added, removed or
rebased; it happens that IGNORE_CVES get outdated. One important issue is
marking a CVE as ignored, while the corresponding patch is not in Buildroot.
To detect such cases, add a new checker to checkpackagelib that finds
occurences of:
# 000x-some-patch.patch
PKG_IGNORE_CVES += CVE-XXXX-YYYY
For each one of them, ensure that the mentioned patch files actually exist
and contain the `CVE: ...` tag.
Assisted-by: Claude:claude-opus-4.8
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Prior to improving check-package to verify that the comment preceding
a <pkg>_IGNORE_CVES entry mentions an existing patch, and that the
patch itself contains a CVE: tag, we fix all problematic cases that
currently exist in Buildroot:
- In the case of binutils: the CVE was only applicable to binutils
2.43/2.44, and the oldest version now supported is 2.45, so the
patch doesn't exist anymore in Buildroot
- For x11vnc, fix a typo in the patch name
- For gpsd the patches were dropped in [1] as they are included in the
version bump
- Similarly for micropython, the patches were dropped in [2] along with
the version bump
- For util-linux, strip the prefix "package/util-linux/", so that the patch
is relative to the .mk file and can be found by the new check
- Add missing 'CVE:' tag to net-tools patch 0001
[1] 37ef4f862f package/gpsd: bump version to 3.27.2
[2] 28eeca9a98 package/micropython: bump to version 1.28.0
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
https://github.com/PCRE2Project/pcre2/releases/tag/pcre2-10.48
Fixes the following security issues:
(Security fix for specific API usage, GHSA-2p8c-ff85-vh9x)
If pcre2_jit_compile() is called with options for some match modes, and
then pcre2_match() is used to perform a match for a different match
mode, an out-of-bounds read can occur if the match is attempted against
invalid UTF input.
(Security fix for pattern conversion, GHSA-q8g2-wprr-34m9)
If pcre2_convert() is called on untrusted input on platforms with
32-bit size_t, an out-of-bounds heap write can occur.
(Security fix, GHSA-3r4p-g7gg-ppmf) Fixed an out-of-bounds write in DFA
matching when using a heap limit; also fixed possible integer overflows
which could cause under-allocation of the workspace.
(Security fix, GHSA-fmgr-6ggq-9859) Added bounds checks for several
integer overflows while compiling patterns on 32-bit CPUs, which could
cause under-allocation followed by out-of-bounds writes.
(Security fix, GHSA-9qww-pwc4-77qq) Applied lower buffer bound to
prevent two out-of-bounds reads while scanning backwards through
invalid UTF data with PCRE2_MATCH_INVALID_UTF.
(Security fix for specific API usage, #937) Fixed a leak and later
invalid free when calling the fast-path pcre2_jit_match() function with
a match data object previously used with pcre2_match() and
PCRE2_COPY_MATCHED_SUBJECT.
(Low-severity security fix, GHSA-q7rw-r7qq-2hx6) Fixed exposure of two
uninitialised bytes from malloc() via pcre2_serialize_encode().
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
https://github.com/kernelsauce/turbo/releases/tag/v2.1.5https://github.com/kernelsauce/turbo/releases/tag/v2.1.4
Security fixes:
HTTP header injection: header values were only checked for a literal
\r\n, so a lone \r or \n could still split a header. Now rejected on
either character.
Transfer-Encoding requests are now rejected with 501 instead of silently
mishandled, closing a request smuggling avenue.
A real default request body size cap (128 MB) with a 413 response,
previously unbounded.
Secure cookie signature now binds the cookie name, so a value signed for
one cookie can no longer be replayed under a different name.
Verification failures return the default value instead of raising.
Constant-time comparison for the secure cookie HMAC, previously a
timing-leaky ==.
util.secure_random_bytes reads real OS entropy (/dev/urandom,
BCryptGenRandom on Windows) for WebSocket masks and util.rand_str,
previously math.random.
WebSocket: unmasked client frames are rejected per RFC 6455, and
fragmented message reassembly is capped to max_buffer_size to close a
memory exhaustion path.
StaticFileHandler decodes the request path before the traversal check,
closing a bypass.
Fixed a 32-byte-per-malformed-request memory leak in the C header parser
wrapper (found via libFuzzer).
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Fixes:
- Reassemble SNMP requests split across TCP segments, and drop
over-large messages, by Noam Rathaus
- Fix encoded-length accounting for decoded OIDs, by Noam Rathaus
- Zero-fill memory from the internal `allocate()` helper
- Build the interface trap OIDs without a run-time format string
- Avoid needless variable shadowing under `-Wshadow`
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
nettest measures download and upload throughput, latency, jitter and
packet loss using the RMBT protocol. The same binary runs as either the
client or the measurement server it tests against.
Written in Rust with no native library dependencies: the target binary
links only libc, libm and libgcc_s, and is fully static when built
against musl.
Signed-off-by: Bogdan Radulescu <bogdan@nimblex.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Upstream started using std::string_view
https://github.com/search?q=repo%3APurpleI2P%2Fi2pd+string_view&type=commits&s=committer-date&o=asc
with commit
a3e0b3710c
first released in version 2.54.0 which was added to buildroot with
commit dea4f02bbb.
Building the package with the gcc6-based defconfig
bootlin-aarch64-glibc-old is broken:
/builds/bkuhls/buildroot/br-test-pkg/bootlin-aarch64-glibc-old/build/i2pd-2.61.0/libi2pd/Base.h:14:23:
fatal error: string_view: No such file or directory
BR2_TOOLCHAIN_HAS_GCC_BUG_64735 can be removed as well now as it depends
on gcc < 7.
A backport to LTS branches should be considered.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
All toolchains have been rebuilt based on Buildroot 2026.08, which
means:
* The bleeding-edge toolchains are based on gcc 16.2, binutils 2.46.1,
gdb 17.1, kernel headers 6.12, glibc 2.44, musl 1.2.6 or uclibc-ng
1.0.59.
* The stable toolchains are based on gcc 15.3, binutils 2.45.1, gdb
16.3, kernel headers 5.10, glibc 2.44, musl 1.2.6 or uclibc-ng 1.0.59.
The runtime tests related to those toolchains all pass fine:
https://gitlab.com/tpetazzoni/buildroot/-/pipelines/2824569690
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
https://github.com/the-tcpdump-group/libpcap/blob/libpcap-1.10.7/CHANGES
Fixes the following CVEs:
CVE-2026-0799: Access M[] safely in the BPF interpreter.
CVE-2026-31912: Mind the program bounds in pcap_offline_filter().
CVE-2026-31911: Fail opcodes safely in the BPF interpreter.
CVE-2026-6244: Avoid division by zero via pcap_offline_filter().
CVE-2026-6554: Limit "ja L" looping in pcap_offline_filter().
CVE-2026-18313: Fix a memory leak in rpcapd.
CVE-2026-18238: Fix RPCAP_MSG_PACKET validation.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
igh-ethercat is failing while attempting to apply patches,
with error:
Applying 0002-Linux-6.19.0-support.patch using patch:
patching file devices/generic.c
Reversed (or previously applied) patch detected! Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file devices/generic.c.rej
The package patch 0002 was added in [1] in branch "master" while it
was in release client cycle. It was cherry-picked in [2] in branch
"next" to apply the bump [3] (which removes the package patches 0001
and 0002). When the branch "next" was merged in "master" in commit [4],
the patch 0002 was kept.
This commit removes this stale patch.
[1] e4cf512c39
[2] 8a5fc970b4
[3] 0a91e760f4
[4] 5f26877955
Fixes:
- https://autobuild.buildroot.org/results/4f509f1f788c1b8dc5a840ffa2e435c5ed7b6eea/
Signed-off-by: Julien Olivain <ju.o@free.fr>
Now that binutils 2.47 has been introduced and binutils 2.46.1 made
the default version, drop the oldest supported version, binutils 2.44,
keeping only the 3 last versions supported: 2.45.1, 2.46.1 and 2.47.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Now that support for binutils 2.47 has been introduced, we follow our
policy of making binutils 2.46.1 the default version.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The 7.1.x series is now EOL upstream, so drop the linux-headers
option and add legacy handling for it.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
https://github.com/strukturag/libde265/releases/tag/v1.1.2
Security fixes:
(CVE numbers will be added when assigned.)
CVE-2026-XXXXX (GHSA-xp3h-6f5r-8cxp) Heap use-after-free and double free
in multi-threaded (WPP) decoding. A crafted stream whose slice segments
repeat or rewind their slice_segment_address within a picture re-ran
CTB rows that were already marked finished, so the CABAC context handoff
between rows was no longer ordered and the shared context table was
released twice. Slice segments that do not follow the previous one in
tile-scan order are now rejected with the new warning
DE265_WARNING_SLICE_SEGMENT_ADDRESS_NOT_INCREASING, and the WPP row
progress is reset for each slice segment. (medium)
CVE-2026-XXXXX (GHSA-mm7m-v26f-wf8x) Heap use-after-free after
de265_reset(): the pointer to the previous slice header was left
dangling when the DPB was cleared, and a dependent slice pushed after
the reset copied from freed memory. (medium)
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
https://github.com/strukturag/libheif/releases/tag/v1.23.3
Fixes the following CVEs:
(CVE numbers will be added when assigned.)
CVE-2026-XXXXX (GHSA-x8r2-mggj-j6wr) Heap buffer overflow (write) in the
uncompressed (unci) mixed-interleave decoder when the two chroma
components declare different bit depths. Both the written bytes and the
overflow length are controlled by the file. (critical)
CVE-2026-XXXXX (GHSA-8fmq-r4pf-7m57) Permanent decoder deadlock through
a reference cycle between an image and its alpha auxiliary image. The
alpha edge was not covered by the cycle guard and re-entered a held
mutex. (high)
CVE-2026-XXXXX (GHSA-w7mc-p8jc-p853) Heap out-of-bounds read in the
YCbCr 4:2:0 to 16-bit interleaved RGB conversion when the chroma
planes have a lower bit depth than luma. Heap memory could end up in
the decoded image. YCbCr conversions with mismatched luma and chroma
bit depths are now rejected. (high)
CVE-2026-XXXXX (GHSA-4jqm-2x34-6f6r) Heap buffer overflow in the SVT-AV1
encoder plugin when encoding a high-bit-depth alpha channel, and a
double free on its send-picture error path. (high)
CVE-2026-84451 (GHSA-hh47-fhqr-cj2r) Incomplete fix for
GHSA-73p7-m7gg-w2jv: the tile range check of the unci decoder (without
icef) could still overflow, allowing an out-of-bounds read. (medium)
CVE-2026-XXXXX (GHSA-4h82-g446-83fm) Heap out-of-bounds read when
converting odd-height 4:2:0 frames of an uncompressed (uncv) image
sequence to RGB. (medium)
CVE-2026-XXXXX (GHSA-9rj8-5mp5-26c9) Out-of-bounds read in the RGB to
YCbCr identity-matrix color conversion when the R, G, and B planes
have different bit depths. (medium)
CVE-2026-84450 (GHSA-gh5q-69gg-c964) A clap property combined with an
oversized ispe reached an assert() in the Fraction arithmetic and
aborted the process (incomplete fix for GHSA-jc8f-p23p-5hjg). An error
is returned instead. (medium)
(GHSA-mw6f-29j3-76f4) Several smaller findings:
heif_image_handle_get_depth_image_handle() and
heif_image_handle_get_depth_image_representation_info() dereferenced a
null pointer on files without a depth image; the TIFF input decoder of
the example tools had an unbounded EXIF tag allocation and a division
by zero on zero YCbCr subsampling; assert()s in the PNG input decoder
are now error returns; integer overflow in the Go binding's
ImageAccess.GetPlane(); heif-view now verifies the decoded frame size
before display. (medium)
(GHSA-8857-r8x5-7499) Undefined behavior (negative shift) in the HDR
bit-depth up-conversion for target bit depths above 16. Such
conversions are now rejected. (low)
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Buildroot commit 9a43bf6593 bumped the gcc
dependency from 9 to 10 but forgot to propagate this change to the
libcamera-apps package.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Buildroot 262a7f6d2f added the package but
forgot to provide the hash for LICENSE.GPL3-EXCEPT, instead a hash for
a non-existing file was added to qt5knx.hash.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Largely a bugfix release. Fixes an encryption issue if the cleartext was
exactly 8KB + N*64KB long.
https://git.sr.ht/~min/agec/refs/1.0.0
Drop now upstreamed 0001-io.c-isarmor-do-not-set-eof-for-35-byte-files.patch:
7a529662f9
Upstream renamed the agec-keygen utility to agecgen, so update the test to
match.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Release announce:
https://lore.freedesktop.org/wayland-devel/alXq76OX4dVWoP3M@xpredator/T/#u
Removed already-deprecated config options:
* 'deprecated-backend-drm-screencast-vaapi' [1].
* 'deprecated-shell-fullscreen' [2].
* 'deprecated-screenshare' [3].
The 'pipewire' and 'remoting' plugins has been deprecated in [4].
They have already been removed in the main development branch in
upstream commit [5] and [6] (not yet in this version 16.0.0).
This commit removes the "remoting" option (rather than changing it to
"deprecated-remoting") because Buildroot was not enabling this option
and this deprecated option is now disabled by default.
This commit also removes the "pipewire" option (rather than changing
it to "deprecated-pipewire"). The commit log of [4] says the
replacement is the "pipewire-backend" option, which is already used
in Buildroot.
Tested on STM32MP157C-DK2.
[1] 7c3e3d7544
[2] 29b740ffee
[3] 3bd77f7817
[4] ec74bd0403
[5] 4606c49d28
[6] d587dfea5b
Signed-off-by: Raphaël Gallais-Pou <rgallaispou@gmail.com>
[Julien:
- update link in hash file comment
- add removed options in Config.in.legacy
- add back package patch which is not included in release
- reword commit log (fix and add links to upstream commits)
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
Regenerate the Bootlin toolchain Kconfig and test configurations using
support/scripts/gen-bootlin-toolchains.
This adds BR2_USE_MMU to the affected uClibc entries and to the
architecture support conditions, and updates the generated tests.
The glibc and musl changes only reorder their existing BR2_USE_MMU
dependencies.
Signed-off-by: Fengwei Tan <tfx2001@outlook.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The Bootlin uClibc toolchains for m68k-68xxx, riscv32-ilp32d, and
xtensa-lx60 require an MMU. However, their generated Kconfig entries
lack a BR2_USE_MMU dependency, allowing them to be selected for noMMU
configurations. External toolchain validation then fails with:
MMU support available in C library, please enable BR2_USE_MMU
Add the missing BR2_USE_MMU dependencies for these architectures to
prevent them from being selected for noMMU targets.
Signed-off-by: Fengwei Tan <tfx2001@outlook.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Regenerate the Bootlin toolchain Kconfig file with
support/scripts/gen-bootlin-toolchains to remove duplicate
BR2_TOOLCHAIN_HAS_THREADS selections.
Commit 184d47a7ad ("support/scripts/gen-bootlin-toolchains: add new
script to support Bootlin toolchains") initially introduced this issue.
Although commit a33e1af4a0 ("support/scripts/gen-bootlin-toolchains:
avoid selecting _HAS_THREADS multiple times") fixed the generator script,
the Config.in.options file was not regenerated accordingly.
This is a non-functional cleanup, as repeated Kconfig select statements
are harmless.
Signed-off-by: Fengwei Tan <tfx2001@outlook.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Release notes:
https://lists.gnupg.org/pipermail/gnupg-announce/2026q3/000508.html
Contains a number of bugfixes, some of which may have (low severity)
security impact. As stated by Werner Koch:
All in all we received 26 reports alone from ANSSI but as even the reporter
mentioned, the real world attack severity is not critical. Thus we don't
consider 1.12.3 a security fix release. There are some bugs which should
be fixed to avoid crashes, and thus may lead to DoS. However, 16384 bit
RSA keys can also be used for a practical DoS; it all depends on your use
case.
https://www.openwall.com/lists/oss-security/2026/08/31/11
Added upstream patch to fix a build error introduced by this bump that
was detected by the Gitlab pipelines:
sm4-intel-avx512-amd64.S: Assembler messages:
sm4-intel-avx512-amd64.S:138: Error: operand size mismatch for `vsm4rnds4'
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
[Julien: add extra info in commit log from Peter original submission from
https://lore.kernel.org/buildroot/20260901192724.1021544-1-peter@korsgaard.com/
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
Add a basic runtime test for nano. The test attempts to write a file
using the editor.
Signed-off-by: Franciszek Stachura <fbstachura@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
dtui depends on tui-textarea which unconditionally imports AtomicU64 in
src/widget.rs to pack a viewport rectangle into a single atomic word:
use std::sync::atomic::{AtomicU64, Ordering};
pub struct Viewport(AtomicU64);
As there is no cfg(target_has_atomic) guard in tui-textarea, its
build fails on any target for which rustc does not provide 64-bit
atomics with:
Compiling tui-textarea v0.7.0
error[E0432]: unresolved import `std::sync::atomic::AtomicU64`
--> .../dtui-3.0.0/VENDOR/tui-textarea/src/widget.rs:10:25
|
10 | use std::sync::atomic::{AtomicU64, Ordering};
| ^^^^^^^^^ no `AtomicU64` in `sync::atomic`
|
help: a similar name exists in the module
|
10 - use std::sync::atomic::{AtomicU64, Ordering};
10 + use std::sync::atomic::{AtomicU32, Ordering};
This has been reported to tui-textarea upstream, but unfortunately the
project seems to be unmaintained (issue linked below). A sane workaround
is to disable the package on targets which lack 64-bit atomic support,
which is exactly what BR2_PACKAGE_HOST_RUSTC_TARGET_HAS_ATOMIC_U64
describes: it is n for armv5te-unknown-linux-{gnu,musl}eabi and
powerpc-unknown-linux-gnu, the only rust targets Buildroot can generate
which lack 64-bit atomics, and y everywhere else.
The same problem was hit by package/dust and worked around in commit
3abc3b97ba ("package/dust: bump to version 1.1.2") by bumping to a
version in which upstream had added the missing guard. That is not an
option here as tui-textarea 0.7.0 is the latest release.
Note that a runtime test for dtui cannot use the default
infra.basetest.BASIC_TOOLCHAIN_CONFIG, since that builds with
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV5_EABI_GLIBC_STABLE, where dtui is now
disabled; such a test would need an armv7 or aarch64 toolchain instead.
Build tested with utils/test-pkg against:
- BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV5_EABI_GLIBC_STABLE
- BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV5_EABI_MUSL_STABLE
- BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_POWERPC_E500MC_GLIBC_STABLE
all three fail with the above error before this change and are skipped
after it, while armv7 (glibc and musl), aarch64, powerpc64le and x86-64
still select and build the package.
Link: https://github.com/rhysd/tui-textarea/issues/66
Fixes: https://autobuild.buildroot.org/results/188f6442371500731453f75983590c922eab6d57
Fixes: https://autobuild.buildroot.org/results/e254db2654f18f1d2110eb8b1a32b43ad0f2a3d6
Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Rust does not provide 64-bit atomics on every target Buildroot can
generate. rustc sets max_atomic_width = 32 for three of the 25 targets
listed in RUST_TARGETS in utils/update-rust, so
core::sync::atomic::AtomicU64 and AtomicI64 simply do not exist there:
$ rustc --print cfg --target <target> | grep target_has_atomic
armv5te-unknown-linux-gnueabi "16" "32" "8" "ptr"
armv5te-unknown-linux-musleabi "16" "32" "8" "ptr"
powerpc-unknown-linux-gnu "16" "32" "8" "ptr"
Every other supported target, including armv6, armv7, aarch64, all the
x86 variants, riscv64, s390x, sparc64 and both 64-bit powerpcs, has
them, e.g.:
arm-unknown-linux-gnueabi "16" "32" "64" "8" "ptr"
armv7-unknown-linux-gnueabihf "16" "32" "64" "8" "ptr"
A crate that uses 64-bit atomics without a cfg(target_has_atomic = "64")
guard therefore fails to build on those three targets with:
error[E0432]: unresolved import `std::sync::atomic::AtomicU64`
|
| atomic::{AtomicU64, AtomicU8, AtomicUsize, Ordering},
| ^^^^^^^^^ no `AtomicU64` in `sync::atomic`
This has been hit at least twice already: by package/dust, worked around
in commit 3abc3b97ba ("package/dust: bump to version 1.1.2") by moving
to a release in which upstream had added the guard and by package/dtui,
which has no such release available and had to open-code the affected
architectures instead.
It is likely to keep recurring: infra.basetest.BASIC_TOOLCHAIN_CONFIG
builds with BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV5_EABI_GLIBC_STABLE, so
every runtime test that does not override the toolchain compiles for
armv5te, one of the three affected targets. That is exactly how the two
failures above were found.
Add a hidden symbol so packages can express this constraint once, rather
than each open-coding BR2_ARM_CPU_ARMV5 and BR2_powerpc and needing to
update whenever rust gains or changes a target.
Note that armv5te and 32-bit powerpc are only supported by rust for
glibc and musl, so the uclibc variants of those architectures are
already excluded by BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS.
Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>
Reviewed-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
DEJAVU_LICENSE is primarily BitstreamVera. The license file also
specifies that DejaVu-specific changes and certain math extensions are
in the Public Domain. This matches the licensing logic used by
OpenEmbedded/Yocto.
Signed-off-by: Martin Bachmann <martin.bachmann@designwerk.com>
[Fiona: wrap lines in commit message]
Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
Was missed when the download page was updated for 2026.08-rc3 in commit
e6b06b8d9c ("Update for 2026.08-rc3").
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
See the changelogs:
- https://www.erlang.org/patches/OTP-26.2.5.16
- https://www.erlang.org/patches/OTP-26.2.5.17
- https://www.erlang.org/patches/OTP-26.2.5.18
- https://www.erlang.org/patches/OTP-26.2.5.19
- https://www.erlang.org/patches/OTP-26.2.5.20
- https://www.erlang.org/patches/OTP-26.2.5.21
This fixes the following vulnerabilities:
- CVE-2026-21620:
Relative Path Traversal, Improper Isolation or Compartmentalization
vulnerability in erlang otp erlang/otp (tftp_file modules), erlang otp
inets (tftp_file modules), erlang otp tftp (tftp_file modules) allows
Relative Path Traversal. This vulnerability is associated with program
files lib/tftp/src/tftp_file.erl, src/tftp_file.erl.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2026-21620
- CVE-2026-23941:
Inconsistent Interpretation of HTTP Requests ('HTTP Request
Smuggling') vulnerability in Erlang OTP (inets httpd module) allows
HTTP Request Smuggling. This vulnerability is associated with program
files lib/inets/src/http_server/httpd_request.erl and program routines
httpd_request:parse_headers/7. The server does not reject or
normalize duplicate Content-Length headers. The earliest Content-
Length in the request is used for body parsing while common reverse
proxies (nginx, Apache httpd, Envoy) honor the last Content-Length
value. This violates RFC 9112 Section 6.3 and allows front-end/back-
end desynchronization, leaving attacker-controlled bytes queued as the
start of the next request.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2026-23941
- CVE-2026-23942:
Improper Limitation of a Pathname to a Restricted Directory ('Path
Traversal') vulnerability in Erlang OTP (ssh_sftpd module) allows Path
Traversal. This vulnerability is associated with program files
lib/ssh/src/ssh_sftpd.erl and program routines
ssh_sftpd:is_within_root/2. The SFTP server uses string prefix
matching via lists:prefix/2 rather than proper path component
validation when checking if a path is within the configured root
directory. This allows authenticated users to access sibling
directories that share a common name prefix with the configured root
directory. For example, if root is set to /home/user1, paths like
/home/user10 or /home/user1_backup would incorrectly be considered
within the root.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2026-23942
- CVE-2026-23943:
Improper Handling of Highly Compressed Data (Compression Bomb)
vulnerability in Erlang OTP ssh (ssh_transport modules) allows Denial
of Service via Resource Depletion. The SSH transport layer advertises
legacy zlib compression by default and inflates attacker-controlled
payloads pre-authentication without any size limit, enabling reliable
memory exhaustion DoS. Two compression algorithms are affected: *
zlib: Activates immediately after key exchange, enabling
unauthenticated attacks * zlib@openssh.com: Activates post-
authentication, enabling authenticated attacks Each SSH packet can
decompress ~255 MB from 256 KB of wire data (1029:1 amplification
ratio). Multiple packets can rapidly exhaust available memory, causing
OOM kills in memory-constrained environments. This vulnerability is
associated with program files lib/ssh/src/ssh_transport.erl and
program routines ssh_transport:decompress/2,
ssh_transport:handle_packet_part/4.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2026-23943
- CVE-2026-28810:
Generation of Predictable Numbers or Identifiers vulnerability in
Erlang/OTP kernel (inet_res, inet_db modules) allows DNS Cache
Poisoning. The built-in DNS resolver (inet_res) uses a sequential,
process-global 16-bit transaction ID for UDP queries and does not
implement source port randomization. Response validation relies almost
entirely on this ID, making DNS cache poisoning practical for an
attacker who can observe one query or predict the next ID. This
conflicts with RFC 5452 recommendations for mitigating forged DNS
answers. inet_res is intended for use in trusted network environments
and with trusted recursive resolvers. Earlier documentation did not
clearly state this deployment assumption, which could lead users to
deploy the resolver in environments where spoofed DNS responses are
possible. This vulnerability is associated with program files
lib/kernel/src/inet_db.erl and lib/kernel/src/inet_res.erl.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2026-28810
- CVE-2026-32147:
Improper Limitation of a Pathname to a Restricted Directory ('Path
Traversal') vulnerability in Erlang OTP ssh (ssh_sftpd module) allows
an authenticated SFTP user to modify file attributes outside the
configured chroot directory. The SFTP daemon (ssh_sftpd) stores the
raw, user-supplied path in file handles instead of the chroot-resolved
path. When SSH_FXP_FSETSTAT is issued on such a handle, file
attributes (permissions, ownership, timestamps) are modified on the
real filesystem path, bypassing the root directory boundary entirely.
Any authenticated SFTP user on a server configured with the root
option can modify file attributes of files outside the intended chroot
boundary. The prerequisite is that a target file must exist on the
real filesystem at the same relative path. Note that this
vulnerability only allows modification of file attributes; file
contents cannot be read or altered through this attack vector. If the
SSH daemon runs as root, this enables direct privilege escalation: an
attacker can set the setuid bit on any binary, change ownership of
sensitive files, or make system configuration world-writable. This
vulnerability is associated with program files
lib/ssh/src/ssh_sftpd.erl and program routines ssh_sftpd:do_open/4 and
ssh_sftpd:handle_op/4.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2026-32147
- CVE-2026-42789:
Improper Following of a Certificate's Chain of Trust vulnerability in
Erlang OTP public_key (pubkey_cert module) allows a non-CA certificate
to be accepted as an intermediate issuer, enabling certificate chain
forgery. In lib/public_key/src/pubkey_cert.erl,
pubkey_cert:validate_extensions/7 contains two flaws that together
allow a certificate with basicConstraints cA:false and no keyUsage
extension to be used as an intermediate issuer in a chain passed to
public_key:pkix_path_validation/3: the cA:false clause recurses into
the remaining extensions without rejecting the certificate when it is
in issuer position, and the keyUsage check only fires when the
extension is present, so a certificate lacking keyUsage entirely
bypasses the keyCertSign enforcement. Any party holding an end-entity
certificate with basicConstraints cA:false and no keyUsage extension,
issued by any CA in the victim's trust store, can use that
certificate's private key to sign forged leaf certificates for
arbitrary identities. public_key:pkix_path_validation/3 accepts the
resulting chain, and by extension every TLS or mTLS endpoint built on
the OTP ssl application that relies on the default verifier is
affected, including server identity verification on the client side
and client certificate verification on mTLS servers.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2026-42789
- CVE-2026-42790:
Improper Certificate Validation vulnerability in Erlang OTP public_key
(pubkey_cert and public_key modules) allows a DNS nameConstraints
bypass via subject CommonName fallback in TLS hostname verification.
Two flaws combine to allow a subordinate CA whose DNS nameConstraints
are restricted (e.g. permitted;DNS:allowed.example.com) to issue a
leaf certificate that an OTP TLS client accepts as a valid identity
for an out-of-scope hostname (e.g. victim.example.com): First,
pubkey_cert:validate_names/6 in lib/public_key/src/pubkey_cert.erl
only checks SAN DNS entries against nameConstraints. Per RFC 5280, a
permitted DNS subtree only restricts certificates that contain a DNS-
typed name. A leaf with no subjectAltName therefore trivially
satisfies any permitted;DNS:... constraint regardless of its subject
commonName. Second, public_key:pkix_verify_hostname/3 in
lib/public_key/src/public_key.erl falls back to the subject commonName
when no subjectAltName is present, extracting id-at-commonName
attributes as presented IDs and matching them against the reference
hostname. The strict pkix_verify_hostname_match_fun(https) matcher
does not suppress this fallback. The result is that path validation
accepts a CN-only leaf under a DNS-constrained intermediate (no SAN
means the nameConstraints are not triggered), and hostname
verification then accepts it via the CN fallback. The bypass is
reachable from stock ssl:connect with verify_peer, a trusted CA, SNI,
and the canonical strict https hostname matcher.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2026-42790
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This patch fixes a build error with OpenSSL-enabled libcurl which was
detected by the Gitlab pipelines:
checking for openssl options with pkg-config... found
configure: pkg-config: SSL_LIBS: "-lssl -lcrypto -pthread"
configure: pkg-config: SSL_LDFLAGS: "-L/builds/bkuhls/buildroot/br-test-pkg/bootlin-m68k-5208-uclibc/host/bin/../m68k-buildroot-uclinux-uclibc/sysroot/usr/lib"
configure: pkg-config: SSL_CPPFLAGS: ""
checking for HMAC_Update in -lcrypto... no
checking for HMAC_Init_ex in -lcrypto... no
checking OpenSSL linking with -ldl... no
checking OpenSSL linking with -ldl and -lpthread... no
checking for SSL_set_quic_use_legacy_codepoint... no
checking for SSL_set_quic_tls_cbs... no
configure: OpenSSL version does not speak any known QUIC API
configure: OPT_OPENSSL: /builds/bkuhls/buildroot/br-test-pkg/bootlin-m68k-5208-uclibc/host/m68k-buildroot-uclinux-uclibc/sysroot/usr
configure: OPENSSL_ENABLED:
configure: error: --with-openssl was given but OpenSSL could not be detected
make[1]: *** [package/pkg-generic.mk:263: /builds/bkuhls/buildroot/br-test-pkg/bootlin-m68k-5208-uclibc/build/libcurl-8.21.0/.stamp_configured] Error 1
Although OpenSSL was found using pkg-config the build tests fail.
A local build shows the concrete error in config.log, for example:
configure:27577: checking for HMAC_Update in -lcrypto
configure:27599: /home/bernd/buildroot/output/host/bin/m68k-linux-gcc
-o conftest -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 -O2 -g0 -fno-dwarf2-cfi-asm -Wl,-elf2flt=-r
-static -Werror-implicit-function-declaration -Wno-system-headers
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
-D_GNU_SOURCE -Wl,-elf2flt=-r -static
-L/home/bernd/buildroot/output/host/bin/../m68k-buildroot-uclinux-uclibc/sysroot/usr/lib
-L/home/bernd/buildroot/output/host/bin/../m68k-buildroot-uclinux-uclibc/sysroot/usr/lib
conftest.c -lcrypto -lssl -lcrypto -lz -pthread -lz >&5
/home/bernd/buildroot/output/host/opt/ext-toolchain/m68k-buildroot-uclinux-uclibc/bin/ld.real:
/home/bernd/buildroot/output/host/bin/../m68k-buildroot-uclinux-uclibc/sysroot/usr/lib/libcrypto.a(libcrypto-lib-threads_pthread.o):
in function `ossl_rcu_read_lock':
threads_pthread.c:(.text+0xa4): undefined reference to `__atomic_fetch_add_8'
This error occurs many times for various atomic operations:
$ grep "undefined reference to \`__atomic" output/build/libcurl-8.20.0/config.log | sort -u | grep -v real
threads_pthread.c:(.text+0x28a): undefined reference to `__atomic_fetch_sub_8'
threads_pthread.c:(.text+0x3b4): undefined reference to `__atomic_fetch_add_8'
threads_pthread.c:(.text+0x9c8): undefined reference to `__atomic_is_lock_free'
threads_pthread.c:(.text+0xa4): undefined reference to `__atomic_fetch_add_8'
threads_pthread.c:(.text+0xa9c): undefined reference to `__atomic_is_lock_free'
threads_pthread.c:(.text+0xb66): undefined reference to `__atomic_is_lock_free'
threads_pthread.c:(.text+0xc30): undefined reference to `__atomic_is_lock_free'
threads_pthread.c:(.text+0xcdc): undefined reference to `__atomic_is_lock_free'
The build error can be reproduced with the current buildroot tree using
this defconfig:
BR2_m68k=y
BR2_m68k_cf5208=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_M68K_COLDFIRE_UCLIBC_STABLE=y
BR2_PACKAGE_OPENSSL=y
BR2_PACKAGE_LIBCURL=y
Although the toolchain lacks atomics support
$ grep ATOMIC .config
$
it emits atomic-related defines, for example:
$ echo | output/host/bin/m68k-linux-gcc -dM -E - | grep __ATOMIC_ACQ_REL
#define __ATOMIC_ACQ_REL 4
$
This specific define __ATOMIC_ACQ_REL is used in OpenSSL to enable
atomic support at various places:
https://github.com/openssl/openssl/blob/openssl-3.6.3/crypto/threads_pthread.c
causing the build errors we see with the mentioned defconfig.
To fix the problem we use an OpenSSL-provided define to forcefully
disable the usage of atomic intrinsics.
The misdetection of atomic intrinsics for m68k coldfire is not a new
problem:
https://lists.buildroot.org/pipermail/buildroot/2017-May/180841.htmlhttps://lists.buildroot.org/pipermail/buildroot/2026-May/803110.html
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Version 0.24.15 change log:
* protocol
fix crash on "sticker delete" and "sticker find"
* database
upnp: fix crash bug
* input
alsa, curl, nfs: fix stalled transfers
* playlist
asx, pls, rss, xspf: limit to 16 MB
cue: fix problem playing CUE tracks in music directory root
* player
fix noise with replay gain and cross-fade
Signed-off-by: Andreas Ziegler <br025@umbiko.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Floating-point type _Float16 added in gcc-16 on s390 now requires
decimal floating-point support enabled in the toolchain [1][2].
Without decimal floating-point, gcc 16.2.0 fails to build with:
../../../libgcc/config/s390/_dpd_sd_to_hf.c:27:25: error: decimal floating-point not supported for this target
27 | HFtype __dpd_truncsdhf (_Decimal32);
| ^~~~~~~~~~
../../../libgcc/config/s390/_dpd_sd_to_hf.c:31:16: error: decimal floating-point not supported for this target
31 | force_convert (_Decimal32 x)
| ^~~~~~~~~~
../../../libgcc/config/s390/_dpd_hf_to_td.c:34:1: error: decimal floating-point not supported for this target
34 | _Decimal128
| ^~~~~~~~~~~
../../../libgcc/config/s390/_dpd_sd_to_hf.c:35:18: error: decimal floating-point not supported for this target
35 | __dpd_truncsdhf (_Decimal32 x)
Enable decimal floating-point support as suggested by Alexander
Egorenkov.
Fixes:
https://lore.kernel.org/buildroot/ansJ5dXXblvYeMLB@windsurf/
[1] https://gcc.gnu.org/gcc-16/changes.html#s390
[2] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5d6d56d837c3dbeabd382c1fb4f7d21d9891f4b9
Cc: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The mdnsd runtime test can randomly fail on slow runners.
It's hard to reproduce locally (only one failure after a few attempts)
but we can reproduce it easily by removing the while loop entirely.
It turns out that mdnsd is started by S50mdnsd before the
emulator.login() change the system date:
[BRTEST# date -s @1788032864
Sat Aug 29 19:47:44 UTC 2026
Since the minimal rootfs.cpio generated for TestMdnsd doesn't have any
ntp client installed, it start with "January 1, 1970".
The date change may cause some issue to the mdnsd daemon which blocks
any response from mquery command.
When the problem occurs, "mquery -T _http._tcp" reply is empty:
# mquery -T _http._tcp
Querying _http._tcp.local. for PTR (12) ... press Ctrl-C to stop
To workaround the issue, restart mdnsd manually.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/16185948555
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Dracut-internal executables were linked against system libraries,
instead of Buildroot host packages. For example:
$ ldd host/lib/dracut/dracut-install
linux-vdso.so.1 (0x00007f578cf06000)
libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 (0x00007f578cccd000)
libkmod.so.2 => /usr/lib/x86_64-linux-gnu/libkmod.so.2 (0x00007f578ccb1000)
/lib64/ld-linux-x86-64.so.2 (0x00007f578cf08000)
libcrypto.so.3 => /usr/lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007f578c600000)
libz.so.1 => /usr/lib/x86_64-linux-gnu/libz.so.1 (0x00007f578cc92000)
libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 (0x00007f578c536000)
The reason is that Dracut is not a "real" autoconf package, and the
hand-written ./configure script does not preserve LDFLAGS for
make. Pass the environment variables directly to fix this.
Signed-off-by: Fiona Klute (othermo GmbH) <fiona.klute@gmx.de>
[Julien: add comment in dracut.mk]
Signed-off-by: Julien Olivain <ju.o@free.fr>
Now that all Xilinx boards have been bumped to Linux 6.18.40, remove the hash
for the xlnx_rebase_v6.18_LTS_2026.1 release tag.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Bump the versal2 defconfig to Linux 6.18.40.
Run tested on a versal2 vek385 evaluation board.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Bump the versal defconfigs to Linux 6.18.40.
Run tested on a versal vek280 evaluation board.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Bump the zynqmp defconfigs to Linux 6.18.40.
Run tested on a zynqmp zcu102 evaluation board.
Run tested on a kria kv260 evaluation board.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Bump the zynq defconfigs to Linux 6.18.40.
Run-tested on a ZC702 Evaluation Board.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Add the hash for the Xilinx Linux 6.18.40 release tag.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
examples/vm_power_manager/meson.build in DPDK detects the presence of
libvirt:
opt_dep = cc.find_library('virt', required : false)
and then builds some examples or not depending on the availability of
libvirt. Let's make this optional dependency explicit in dpdk.mk, even
if there's no explicit enable/disable option for it.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When libvirt is present before DPDK is built, some additional examples
are compiled. One of them fails to build due to a missing <stdlib.h>
include. Let's import a patch from OpenSuse, that we have submitted
upstream, to fix this issue.
We couldn't find any autobuilder failure for this issue, but the
following defconfig allows to reproduce the failure:
BR2_aarch64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_AARCH64_GLIBC_STABLE=y
BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV=y
BR2_PACKAGE_DPDK=y
BR2_PACKAGE_DPDK_EXAMPLES=y
BR2_PACKAGE_LIBVIRT=y
The problem exists since DPDK v19.11, so it has been in Buildroot
since DPDK was introduced in commit
d17d1b6bde.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Buildroot commit [1] (package/perl: fix build issue with musl)
introduced a patch that is meant to be applied on top of perl-cross,
which is extracted on top of perl only in the target variant.
Since the patch was introduced as a normal package patch, the Buildroot
infra is trying to always apply it, even for the host package variant.
Since perl-cross is not extracted for the host variant, some patched
files are missing. In that case, the host-perl is failing with error:
>>> host-perl 5.42.3 Patching
Applying 0001-configure-keep-_GNU_SOURCE-in-build-flags.patch using patch:
can't find file to patch at input line 46
This commit fixes the issue by moving the package patch in a dedicated
"perl-cross" subdirectory, to make sure it will no longer be applied by
the infra. We apply the patch only for the target package variant using
a _POST_PATCH_HOOKS hook.
Fixes:
- [1]
- https://gitlab.com/buildroot.org/buildroot/-/jobs/16185948610 (TestPerlXMLLibXML)
- ...and few other tests requiring host-perl
[1] d950fff290
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Bump to go1.27.0. The go-bootstrap-stage5 package (go1.25.x) still
satisfies the bootstrap requirement, so no bootstrap stage changes are
needed.
Remove the workaround for https://github.com/golang/go/issues/77436,
which the go.mk comment scheduled for removal at this bump: restore the
plain CGO_CFLAGS and CGO_CXXFLAGS settings in HOST_GO_TARGET_ENV.
https://go.dev/doc/go1.27#bootstrap
Signed-off-by: Christian Stewart <christian@aperture.us>
Signed-off-by: Julien Olivain <ju.o@free.fr>
When OpenSSL is enabled, if DES support is enabled, OpenSSH uses
DES_crypt. However, without OpenSSL or its DES support, there is no
available crypt() implementation for OpenSSH libopenbsd-compat xcrypt()
function, resulting in the following error:
.../host/bin/i686-buildroot-linux-gnu-gcc -o sshd-auth sshd-auth.o
auth2-methods.o auth-rhosts.o auth-passwd.o sshpty.o sshlogin.o
servconf.o serverloop.o auth.o auth2.o auth-options.o session.o
auth2-chall.o groupaccess.o auth-bsdauth.o auth2-hostbased.o
auth2-kbdint.o auth2-none.o auth2-passwd.o auth2-pubkey.o
auth2-pubkeyfile.o auth2-gss.o gss-serv.o gss-serv-krb5.o
monitor_wrap.o auth-krb5.o audit.o audit-bsm.o audit-linux.o
platform.o loginrec.o auth-pam.o auth-shadow.o auth-sia.o
sandbox-null.o sandbox-rlimit.o sandbox-darwin.o
sandbox-seccomp-filter.o sandbox-capsicum.o sandbox-solaris.o
sftp-server.o sftp-common.o uidswap.o ssh-pkcs11-client.o
ssh-sk-client.o -L. -Lopenbsd-compat/ -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g0
-D_FORTIFY_SOURCE=1 -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack
-fstack-protector-strong -pie -lssh -lopenbsd-compat
-L.../host/bin/../i686-buildroot-linux-gnu/sysroot/usr/lib
-lssl -lcrypto -lcrypto -lz
.../host/lib/gcc/i686-buildroot-linux-gnu/15.3.0/../../../../
i686-buildroot-linux-gnu/bin/ld:
openbsd-compat//libopenbsd-compat.a(xcrypt.o): in function `xcrypt':
xcrypt.c:(.text+0x51): undefined reference to `crypt'
.../host/lib/gcc/i686-buildroot-linux-gnu/15.3.0/../../../../
i686-buildroot-linux-gnu/bin/ld:
openbsd-compat//libopenbsd-compat.a(xcrypt.o): in function `xcrypt':
xcrypt.c:(.text+0x51): undefined reference to `crypt' collect2: error:
ld returned 1 exit status make[2]: *** [Makefile:233: sshd-auth] Error
1 make[2]: *** Waiting for unfinished jobs.... collect2: error: ld
returned 1 exit status make[2]: *** [Makefile:230: sshd-session] Error
1 make[1]: *** [package/pkg-generic.mk:273:
.../build/openssh-10.4p1/.stamp_built]
Error 2 make: *** [Makefile:83: _all] Error 2
This commit enables BR2_PACKAGE_LIBXCRYPT with OpenSSH as long as
glibc is used. Since "sshd-auth" is compiled regardless of
BR2_PACKAGE_OPENSSH_SERVER, we need to enable it with BR2_PACKAGE_OPENSSH.
Signed-off-by: Jimmy Durand Wesolowski <jimmy.wesolowski@mobileye.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Buildroot commit 297f6f1921 updated vim.
However README.txt (used as part of the license hash check) has been updated
upstream in [1], without any corresponding hash change in Buildroot, leading
to build failure.
Fixes: https://gitlab.com/buildroot.org/buildroot/-/work_items/189
NB: This also affects 2025.02.x & 2026.05.x, so this patch
should be applied there too.
[1] e7e21018fc
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
patchwork.buildroot.org used to be a redirect to patchwork.ozlabs.org,
but we are now running our own instance, so let's adjust the links in
the website accordingly.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
patchwork.buildroot.org used to be a redirect to patchwork.ozlabs.org,
but we are now running our own instance, so let's adjust the links in
the manual accordingly.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following CVEs:
CVE-2026-19499:
63b53df549
CVE-2026-77117:
6f9b2bfa50
CVE-2026-80489:
cb61572ea3
Added GLIBC_IGNORE_CVES for CVE-2026-19542 which was forgotten in
buildroot commit 58f3137738.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Udev is an optional dependency used to directly control cm108 sound
device gpios. It is enabled by default since version 2.6.3:
c1b5c0a214
Signed-off-by: Mattia Narducci <mattianarducci1@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
When BR2_PACKAGE_OPENCV4_WITH_WEBP=y we need to enable mux and demux
support in webp, otherwise the build of OpenCV fails as follows:
CMake Error: The following variables are used in this project,
but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly
in the CMake files:
WEBP_DEMUX_LIBRARY
linked by target "opencv_imgcodecs"
in directory [...]/build/opencv4-4.13.0/modules/imgcodecs
WEBP_MUX_LIBRARY
linked by target "opencv_imgcodecs"
in directory [...]/build/opencv4-4.13.0/modules/imgcodecs
The issue already exists in 2025.02.x.
Fixes:
https://autobuild.buildroot.net/results/d3e0446a87d32469267e241866c4224143170f31/
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Even though it's only documentation, the form of the names of the
post-image.sh and post-build.sh scripts should be consistent with the
names of those scripts used in the code base, using hyphen, not
underscore.
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Besides just updating a little terminology, remove the awkward
reference to "his" when referring to developers.
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The openscap build can fail with the following error:
In file included from [...]/src/OVAL/probes/unix/linux/systemdunitproperty_probe.c:38:
[...]/src/OVAL/probes/unix/linux/systemdshared.h: In function ‘get_all_systemd_units’:
[...]/src/OVAL/probes/unix/linux/systemdshared.h:188:50: error: implicit declaration of function ‘basename’; did you mean ‘rename’? [-Wimplicit-function-declaration]
188 | char *unit_name_s = oscap_strdup(basename(value.str));
| ^~~~~~~~
| rename
In file included from [...]/src/OVAL/probes/unix/linux/systemdunitdependency_probe.c:37:
[...]/src/OVAL/probes/unix/linux/systemdshared.h: In function ‘get_all_systemd_units’:
[...]/src/OVAL/probes/unix/linux/systemdshared.h:188:50: error: implicit declaration of function ‘basename’; did you mean ‘rename’? [-Wimplicit-function-declaration]
188 | char *unit_name_s = oscap_strdup(basename(value.str));
| ^~~~~~~~
| rename
This error happens when:
- dbus is enabled in the configuration, making openscap build probes
code
- the toolchain uses musl, which does not declare basename() in string.h
the way glibc does
The build error can be reproduced with the following minimal defconfig:
BR2_arm=y
BR2_cortex_a9=y
BR2_ARM_ENABLE_NEON=y
BR2_ARM_ENABLE_VFP=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV7_EABIHF_MUSL_BLEEDING_EDGE=y
BR2_PACKAGE_DBUS=y
BR2_PACKAGE_OPENSCAP=y
Backport the upstream fix to allow openscap to build with such
configuration. The custom patch can be removed once openscap is
re-released on its branch 1.3.x.
The issue affects master, 2026.05.x and 2025.02.x
Fixes: https://autobuild.buildroot.org/results/a874d4f34d36fa9f8566be90ad2d5facb99aec24/
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
host-erlang build can fail with the following error:
make[5]: Nothing to be done for 'opt'.
MAKE opt
CC ../priv/bin/x86_64-pc-linux-gnu/odbcserver
/usr/bin/ld: ../priv/obj/x86_64-pc-linux-gnu/odbcserver.o: in function `encode_column_dyn':
odbcserver.c:(.text+0x6b4): undefined reference to `ei_x_encode_tuple_header'
/usr/bin/ld: odbcserver.c:(.text+0x6c2): undefined reference to `ei_x_encode_tuple_header'
/usr/bin/ld: odbcserver.c:(.text+0x6d4): undefined reference to `ei_x_encode_ulong'
/usr/bin/ld: odbcserver.c:(.text+0x6e7): undefined reference to `ei_x_encode_ulong'
/usr/bin/ld: odbcserver.c:(.text+0x6fa): undefined reference to `ei_x_encode_ulong'
/usr/bin/ld: odbcserver.c:(.text+0x708): undefined reference to `ei_x_encode_tuple_header'
/usr/bin/ld: odbcserver.c:(.text+0x71b): undefined reference to `ei_x_encode_ulong'
/usr/bin/ld: odbcserver.c:(.text+0x72e): undefined reference to `ei_x_encode_ulong'
[...]
This can be reproduced with the following minimal defconfig (and
libei.so present on host, see details below):
BR2_x86_64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_PACKAGE_ERLANG=y
Those missing symbols are part of the erl_interface, exposed by libei.a.
host-erlang builds correctly libei.a _before_ odbcserver.c (it can be
found in lib/erl_interface/obj/x86_64-pc-linux-gnu/libei.a), but the
failure is actually due to the build command generated and used for
odbcserver.c, especially the link arguments:
/usr/bin/gcc \
[...]
-o ../priv/bin/x86_64-pc-linux-gnu/odbcserver \
../priv/obj/x86_64-pc-linux-gnu/odbcserver.o \
-L/usr/lib64 \
-lodbc \
-L/home/alexis/src/buildroot/erlang-master/build/host-erlang-custom/lib/erl_interface/obj/x86_64-pc-linux-gnu \
-lpthread -lei
/usr/lib64 is searched before the path where libei.a has been built, so
if whether a valid libei.a or libei.so is found there, it shadows the
expected libei.a. In the build from which the logs above come, the
notable point is that the host system indeed have a valid libei.so, but
is completely unrelated to erl_interface; it rather exposes the Emulated
Input protocol aimed at Wayland stack; and so it obviously contains none
of the expected ei_* symbols.
Upstream has already identified and fixed the issue, the fix is already
released in versions >= 27.x.y. Erlang 26 (the version currently
packaged in buildroot), isn't supported anymore (only the three latest
releases are supported, see
https://github.com/erlang/otp/blob/master/SECURITY.md), so there won't
be any new minor update that will release this fix.
Pick and backport the fixing patch so that the current version packaged
in buildroot can still build.
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
host-erlang build can fail with the following error:
make[5]: Nothing to be done for 'opt'.
MAKE opt
CC ../priv/bin/x86_64-pc-linux-gnu/odbcserver
/usr/bin/ld: ../priv/obj/x86_64-pc-linux-gnu/odbcserver.o: in function `encode_column_dyn':
odbcserver.c:(.text+0x6b4): undefined reference to `ei_x_encode_tuple_header'
/usr/bin/ld: odbcserver.c:(.text+0x6c2): undefined reference to `ei_x_encode_tuple_header'
/usr/bin/ld: odbcserver.c:(.text+0x6d4): undefined reference to `ei_x_encode_ulong'
/usr/bin/ld: odbcserver.c:(.text+0x6e7): undefined reference to `ei_x_encode_ulong'
/usr/bin/ld: odbcserver.c:(.text+0x6fa): undefined reference to `ei_x_encode_ulong'
/usr/bin/ld: odbcserver.c:(.text+0x708): undefined reference to `ei_x_encode_tuple_header'
/usr/bin/ld: odbcserver.c:(.text+0x71b): undefined reference to `ei_x_encode_ulong'
/usr/bin/ld: odbcserver.c:(.text+0x72e): undefined reference to `ei_x_encode_ulong'
[...]
This can be reproduced with the following minimal defconfig (and
libei.so present on host, see details below):
BR2_x86_64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_PACKAGE_ERLANG=y
Those missing symbols are part of the erl_interface, exposed by libei.a.
host-erlang builds correctly libei.a _before_ odbcserver.c (it can be
found in lib/erl_interface/obj/x86_64-pc-linux-gnu/libei.a), but the
failure is actually due to the build command generated and used for
odbcserver.c, especially the link arguments:
/usr/bin/gcc \
[...]
-o ../priv/bin/x86_64-pc-linux-gnu/odbcserver \
../priv/obj/x86_64-pc-linux-gnu/odbcserver.o \
-L/usr/lib64 \
-lodbc \
-L/home/alexis/src/buildroot/erlang-master/build/host-erlang-custom/lib/erl_interface/obj/x86_64-pc-linux-gnu \
-lpthread -lei
/usr/lib64 is searched before the path where libei.a has been built, so
if whether a valid libei.a or libei.so is found there, it shadows the
expected libei.a. In the build from which the logs above come, the
notable point is that the host system indeed have a valid libei.so, but
is completely unrelated to erl_interface; it rather exposes the Emulated
Input protocol aimed at Wayland stack; and so it obviously contains none
of the expected ei_* symbols.
Upstream has already identified and fixed the issue, the fix is already
released in versions >= 27.x.y. Erlang 26 (the version currently
packaged in buildroot), isn't supported anymore (only the three latest
releases are supported, see
https://github.com/erlang/otp/blob/master/SECURITY.md), so there won't
be any new minor update that will release this fix.
Pick and backport the fixing patch so that the current version packaged
in buildroot can still build.
The issue affects 2025.02.x, 2026.05.x and master.
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Qt5 can be built with or without openssl support. Following some build
failures, commit a94d39d693 ("package/qt5: fix build failure due to
libressl use") enforced libopenssl as the only valid implementation for
Qt5 openssl support.
While this solution is fine to filter between the two openssl variants
officially supported by Buildroot, it prevents users bringing their own
OpenSSL implementations (through the virtual package mechanism) from
building Qt5 with openssl support, even if the custom implementation
matches the expected OpenSSL API.
Allow compatible external implementations to be provided for Qt5 openssl
support. Relax the constraint by partially reverting a94d39d693 and
checking that the selected openssl implementation isn't libressl. It
then becomes up to users to ensure that the implementation they are
providing is fully compatible with libopenssl's. Some qt5
sub-packages enforce BR2_PACKAGE_OPENSSL_FORCE_LIBOPENSSL, they don't
need any update as it does not really strictly select libopenssl, it
rather prevents libressl, so it still allows custom providers.
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Add heaptrack, a memory allocation tracer toolkit.
This implementation builds all the command line components, not the
heaptrack_gui graphical visualization program.
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Remove patches upstreamed in this release.
Release announce:
https://lore.kernel.org/linux-nfs/dc0f6f41-84be-4a70-92db-89890bded3ab@redhat.com/
Backport 3 patches from upstream fixing this release regressions:
* 67ed1bdb ("exportfs: link failure with --disable-nfsdctl")
* cec8eeb6 ("getport: fix missing stddef.h inclusion")
* cf80edae ("statd: fix memory leak in sm_mon_1_svc() when existing host re-monitors")
And 4th patch which fixes error on old toolchains, e.g.
br-arm-full-static or bootlin-aarch64-glibc-old.
Signed-off-by: Petr Vorel <petr.vorel@gmail.com>
[Julien: fix check-package errors]
Signed-off-by: Julien Olivain <ju.o@free.fr>
The two patches are upstream, so they can be dropped.
From NEWS.md:
Version 1.6.12
- Backported CCAT fixes from Beckhoff
Version 1.6.11
- Protect datagram receiving mechanism against re-ordering
- Prevent creating datagrams that are too large for one frame
- Reacted to stmmac API changed during Linux 6.12
- Adapted debug ring to kernel 5.6+ time API changes
- Use str.read() to read into char* (deprecated in C++20)
- Unload `ec_bhf` before loading CCAT
- Added cpplint checks in pre-commit and CI tests.
- Improved and formatted markdown documents and added pre-commit checks
Version 1.6.10
- Added RasPi 5 macb (Cadence GEM / RP1) driver for kernel 6.18.
- Added igb and igc for kernel 6.8
- Security fixes against malicious subdevices
- Protected `rec_size` calculation in FoE.
- Check for malicious EoE frame details.
- Avoid writing invalid MAC onto r8169 NIC on removal
- Fixed insufficient re-allocation of SoE request buffer.
Version 1.6.9
- Protect datagram injection mechanism against re-ordering.
- Fixed for genet and igb drivers for openSUSE Leap 16.0 kernel 6.12.
- tty: Implemented new timer interface since kernel 6.15.
- Do not require .config to exist in kernel sources.
- Fix: Attach slaves before calculating DCs.
- Discard EoE traffic in CoE statemachine, if EoE is disabled.
- Support for Linux 6.19
- Added `--with-kmod-dir` and `--with-ip-cmd` configuration switches
to specify the paths of the tools used in the `ethercatctl` script.
- Changed the default path of the `ip` command to `/sbin/ip`.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
