Since the ARM AArch64 toolchain toolchain bump [1], the TestPppd fail
at runtime since ttyppp0 and ttyppp1 interfaces were not created
properly:
pppd[87]: pppd 2.5.2 started by root, uid 0
pppd[87]: Baud rate for /dev/ttyppp1 is 0; need explicit baud rate
The new toolchain uses glibc 2.42 that include a rework in termios
"implement arbitrary and split speeds in termios" to support BOTHER
[2]. This rework seems to conflict with pppd workaround [3] introduced
when BOTHER was not supported in Glibc.
Fix this by setting the baudrate on pppd command line (we already set
this baudrate on socat command line).
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/14607335920 (TestPppd)
[1] 8d413d6179
[2] https://sourceware.org/git/?p=glibc.git;a=commit;h=5cf101a85aae0d703cdd8ed7b25fe288e41fdacb
[3] d65f6713c8
Fix-suggested-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Remove some patches that have been applied upstream, or adapt them
for upstream files that have been moved around.
Patch 0001 is no longer needed: a similar upstream patch is fixing this
issue. See [1]. The .checkpackageignore entry is also removed.
The COPYING license file was updated in [2]. This commit updates this
license file hash. Since the GPL-2.0 license text was moved to the
package file LICENSES/GPL-2.0, this commit also adds this new file in
XEN_LICENSE_FILES and its hash.
This commit also adds --disable-werror in XEN_CONF_OPTS. The code is
generating warnings with newer gcc version. This makes the compilation
works in all configurations.
This commit adds a comment in hash file about pgp signature check.
This fixes many vulnerabilities:
- CVE-2021-28687
- CVE-2021-28690
- CVE-2021-28693
- CVE-2021-28697
- CVE-2021-28702
- CVE-2021-28704
- CVE-2021-28707
- CVE-2021-28708
- CVE-2022-26357
- CVE-2022-33746
- CVE-2022-42331
- CVE-2022-42333
- CVE-2022-42334
- CVE-2023-34321
- CVE-2023-34322
- CVE-2023-34323
- CVE-2023-46837
- CVE-2024-31142
- CVE-2025-27466
- CVE-2025-58142
- CVE-2025-58143
- CVE-2025-58144
- CVE-2025-58145
Note: xen version 4.19.5 is not the latest at the time of this commit.
It is an intermediate bump because: 1. the xen build has significantly
changed after this 4.19.5 version, so this intermediate step will help
future updates; 2. this intermediate version includes many CVE
security fixes; and 3. it also reduces the number of package patches.
[1] https://xenbits.xen.org/gitweb/?p=qemu-xen.git;a=commitdiff;h=03556ea920b23c466ce7c1283199033de33ee671
[2] https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=7b068ac89024308862c4f448dd248645d2b8e882
Co-authored-by: Vincent Stehlé <vincent.stehle@arm.com>
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Tested-by: Julien Olivain <ju.o@free.fr>
Reviewed-by: Julien Olivain <ju.o@free.fr>
[Julien:
- reorder XEN_DEPENDENCIES alphabetically
- fix COPYING license hash
- add LICENSES/GPL-2.0 in XEN_LICENSE_FILES
- add commit log comment about --disable-werror
- add commit log note about the intermediate version
- drop patch 0001
- renumber patches
- remove all .checkpackageignore entries
- add "Upstream:" tag in all remaining patches
- add pgp signature check comment in hash file
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
All Qt6 packages install their own SPDX SBOM in
$(TARGET_DIR)/usr/lib/qt6/sbom/. In the context of Buildroot having
such SBOMs on the target is not useful, and they take up some space,
so get rid of them.
We use a TARGET_FINALIZE_HOOKS (and not a POST_INSTALL_TARGET_HOOKS)
because it's not just qt6base that installs SBOMs, but all qt6
modules, so we want the cleanup to happen after they all got
installed.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Using '$(Q)rm -rf' is not the typical thing we do in Buildroot, we
more commonly use '$(RM) -rf'.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
iconv types are defined differently in glibc (as pointers) and uclibc
(as integers). With changes in GCC14, -Wint-conversion has now become
an error, which shed some light on the issue.
The actual fix for that problem is released in uclibc 1.0.58 [1].
However, because these type definitions are in toolchain headers,
this means that the toolchain used to build samba must also include
uclibc>=1.0.58 (either an external toolchain that includes the uclibc fix,
or a Buildroot toolchain after the uclibc fix is merged in Buildroot [2]).
Until then, provide a workaround for samba itself.
No autobuilder failure on this (yet). It can be reproduced with
> ./utils/test-pkg -p samba4 -T bootlin-armv5-uclibc
[1] 328e14e55f
[2] https://lore.kernel.org/buildroot/ahPrm_0gVDGw5B5-@waldemar-brodkorb.de/
Assisted-by: Claude:claude-opus-4.8
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Marcus Hoffmann <buildroot@bubu1.eu>
Seen with this defconfig
BR2_x86_64=y
BR2_GCC_VERSION_15_X=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_PACKAGE_PICOTOOL=y
output/host/x86_64-buildroot-linux-gnu/sysroot/usr/include/bits/struct_mutex.h:35:9:
error: declaration does not declare anything [-fpermissive]
35 | short __unused;
No related autobuilder error was recorded.
The build error does not occur with glibc-2.42 on the 2026.02.x branch.
The build error was reported to picotool upstream:
https://github.com/raspberrypi/picotool/issues/300
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Fixes the following security issue (in 2.8.10):
CVE-2026-35444: Heap buffer overflow READ via unchecked colormap index in
XCF loader
https://github.com/libsdl-org/SDL_image/security/advisories/GHSA-gq8w-x74c-h6p7
In addition, 2.8.12 includes a number of memory related bugfixes:
Fixed memory overflow with corrupt LBM image
Fixed crash when decoding an invalid XCF image
Fixed out of bound read in GIF decoder
Update hash of license file for change of copyright year with:
281b4ebcb0
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Update rtl8822cs driver latest of the jethome-iot/rtl88x2cs.
Signed-off-by: Viacheslav Bocharov <v@baodeep.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Commit 53bb7eafb2 ("package/arm-trusted-firmware: add
ARM_TRUSTED_FIRMWARE_CPE_ID_*") added logic to set the cpe-id version from
the package version by dropping a v or lts- prefix, but it used subst
instead of patsubst - So it would replace "v" and "lts-" anywhere in the
version and not only in the beginning of it.
Change to patsubst to fix that.
E.G. with the following defconfig:
BR2_aarch64=y
BR2_TARGET_ARM_TRUSTED_FIRMWARE=y
BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_VERSION=y
BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_VERSION_VALUE="version-with-v-or-lts-in-it"
before:
make printvars VARS=ARM_TRUSTED_FIRMWARE_CPE_ID_VERSION
ARM_TRUSTED_FIRMWARE_CPE_ID_VERSION=ersion-with--or-in-it
after:
make printvars VARS=ARM_TRUSTED_FIRMWARE_CPE_ID_VERSION
ARM_TRUSTED_FIRMWARE_CPE_ID_VERSION=ersion-with-v-or-lts-in-it
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Building Stellarium includes the download of external tarballs during
configure.
This fails with host-cmake during configure stage:
CMake Error at md4c-subbuild/md4c-populate-prefix/src/md4c-populate-stamp/download-md4c-populate.cmake:163 (message):
Each download failed!
error: downloading 'https://github.com/mity/md4c/archive/refs/tags/release-0.5.2.tar.gz' failed
status_code: 1
status_string: "Unsupported protocol"
log:
--- LOG BEGIN ---
Protocol "https" not supported
closing connection #-1
due to buildroot commit f87138339b which
disabled SSL support for host-cmake.
This patch uses _EXTRA_DOWNLOADS to provide these tarball to allow
offline builds.
No autobuilder error was recorded, the build error can be reproduced
with this defconfig:
BR2_x86_64=y
BR2_x86_corei7=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_X86_64_CORE_I7_GLIBC_BLEEDING_EDGE=y
BR2_FORCE_HOST_BUILD=y
BR2_PACKAGE_STELLARIUM=y
BR2_PACKAGE_MESA3D=y
BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_SOFTPIPE=y
BR2_PACKAGE_MESA3D_OPENGL_GLX=y
BR2_PACKAGE_QT5=y
BR2_PACKAGE_XORG7=y
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
We have our own GitLab-CI runner, but with only one we can't run many
jobs in parallel so it takes a very long time before all the tests have
completed. In addition, if that runner goes down, we have nothing at
all.
GitLab offers the following machine types for hosted runners on Linux
x86-64 [1]. The default is the "small" runner. Using a larger runner
increases the "Cost factor" [2].
For opensource projects, the Cost factor is reduced to 0.5 (1 minute per
2 minutes of job time) whatever the runner type.
Runner Tag vCPUs Memory Storage Cost factor (OSS)
saas-linux-small-amd64 (default) 2 8 GB 30 GB 1 (0.5)
saas-linux-medium-amd64 4 16 GB 50 GB 2 (0.5)
saas-linux-large-amd64 (Premium and Ultimate only) 8 32 GB 100 GB 3 (0.5)
saas-linux-xlarge-amd64 (Premium and Ultimate only) 16 64 GB 200 GB 6 (0.5)
saas-linux-2xlarge-amd64 (Premium and Ultimate only) 32 128 GB 200 GB 12 (0.5)
Compute minutes consumed by a job is calculated by:
Job duration / 60 * Cost factor
(Job duration: The time, in seconds, that a job took to run, not
including time spent in the created or pending statuses.)
Thanks to the GitLab OSS program [3], Buildroot benefits from a free
Ultimate subscription and can use GitLab shared runners tagged with
saas-linux-{large, xlarge, 2xlarge}-amd64. In addition, we receive
50,000 free runner minutes per month.
In order to use one of those tags in Buildroot GitLab-CI jobs, we have
to classify all tests by resource requirement, to make sure the job
doesn't fail because it times out or has insufficient memory or disk
space. While we usually shouldn't use the largest runner for
everything, we can use larger runner without cost penalty thanks to
the cost factor reduced to 0.5 for opensource projects. This will
reduce the CI minutes consumed by a CPU intensive job.
First we introduce some new templates used to add the corresponding
runner tag to a runtime test job (reusing the GitLab terminology).
.runner-{small,medium,large,xlarge,2xlarge}
Most of our tests are fast (checkpackage, test_external_bootlin...), so
saas-linux-small-amd64 runner tag is enough. Default to this tag if
nothing else is specified.
Add a comment next to the test class to provide the runner tag.
This runner tag is retrieved when generating the
generated-gitlab-ci.yml file used to create the child pipeline where
the runtime test jobs are executed.
We use the list of runtime tests returned by node2:
"tests.boot.test_edk2.TestEdk2.test_run"
We convert each element of this list to get the path to the test source
file and the name of the test:
"support/testing/tests/boot/test_edk2.py"
TestEdk2
With that, we can grep into the test source file to retrieve the runner
tag placed one line above the test class:
# GitLab-runner: large
class TestEdk2(infra.basetest.BRTest):
Once the runner tag is retrieved, it's used to use the corresponding
runner template to the runtime test job:
tests.boot.test_edk2.TestEdk2.test_run: { extends: [ .runtime_test_base, .runner-large ]}
GitLab runners hosted by the Buildroot project should be able to run
any jobs, so they should be tagged with Gitlab runner tags
(saas-linux-{small,medium,large,xlarge,2xlarge}-amd64).
A specific runner tag "buildroot-runner" can be used to allow running
a job only on such runners.
If a test can't be executed by any shared GitLab-CI runners, we have
to use a runner owned by the Buildroot project. In this case we have
to use a specific template ".runner-buildroot-runner-only" in order to
add the specific runner tag "buildroot-runner" to the job running the
test. There is no such runtime test at the moment.
The proposed classification is based on a previous pipeline analysis
[5]:
- Tests lasting more than 3 hours will use 2xlarge runners.
- Tests lasting more than 2 hours will use xlarge runners.
- Tests lasting more than 1 hours will use large runners.
- Tests building a kernel or a toolchain will use medium runners.
- All other tests will use small runners when possible.
CI minute cost estimate:
tests.package.test_clang.TestClangCompilerRT.test_run lasts 4h25 on the
Buildroot runner. If we this duration for 2xlarge runners, the CI
minute consumed would be:
(15900 / 60) * 0.5 = 133
With 6 jobs using a 2xlarge runners we used ~795 CI minutes.
tests.package.test_kmscube.TestKmsCube.test_run list 2h04 on the
Buildroot runner. If we this duration for xlarge runners, the CI
minute consumed would be:
(7440 / 60) * 0.5 = 62
With 4 jobs using a xlarge runners we used ~248 CI minutes.
tests.package.test_weston.TestWeston.test_run last 1h15 on th
Buildroot runner. If we this duration for large runners, the CI
minute consumed would be:
(4500 / 60) * 0.5 = 37.5
With 28 jobs using a large runners we used ~1050 CI minutes.
tests.package.test_gstreamer1.TestGstreamer1.test_run last 46min on the
Buildroot runner. If we this duration for large runners, the CI
minute consumed would be:
(2760 / 60) * 0.5 = 23
With 31 jobs using a medium runners we used ~713 CI minutes.
tests.package.test_python.TestPython3Py.test_run last 13min on the
Buildroot runner. If we this duration for large runners, the CI
minute consumed would be:
(780 / 60) * 0.5 = 6.5
With 691 jobs using a medium runners we used ~4491 CI minutes.
In total, one pipeline for the runtime tests cost ~7297 CI minutes.
After a first try [6], we are actually using 8000 CI minutes per
pipeline.
We run such pipeline once a week (on Monday), one for each Buildroot
releases every 3 month, one for each stable and LTS release per month,
and one for each release candidate (3).
Worst case (release month):
(4 weeks + 1 release + 1 stable + 1 LTS + 3 release candidate) * 8000 CI
minutes: 80000 CI minutes / 50000.
So we would spend the minutes very quickly in the worst case scenario.
We have to keep one pipeline under 5000 CI minutes.
[1] https://docs.gitlab.com/ci/runners/hosted_runners/linux/#machine-types-available-for-linux---x86-64
[2] https://docs.gitlab.com/ci/pipelines/compute_minutes/#cost-factorshttps://docs.gitlab.com/ci/pipelines/compute_minutes/#compute-usage-calculationhttps://docs.gitlab.com/ci/pipelines/compute_minutes/#cost-factors-of-hosted-runners-for-gitlabcom
[3] https://gitlab.com/buildroot.org/gitlab-oss
[4] https://docs.gitlab.com/ci/runners/hosted_runners/#gitlabcom-hosted-runner-workflow
[5] https://gitlab.com/buildroot.org/buildroot/-/pipelines/2416603721
[6] https://gitlab.com/buildroot.org/buildroot/-/pipelines/2562421098
Signed-off-by: Romain Naour <romain.naour@smile.fr>
[Arnout:
- simplify parsing of test_file and test_name;
- match the entire test_name instead of substring;
- assume "small" by default;
- remove the "small" tags;
- use "gitlab-runner" instead of "Gitlab-runner".
]
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
VERSION should ideally contain only the version, i.e 2.12 and not some
additional prefix like liburing- as it prevents our logic matching
against release-monitoring.org data to work properly.
Fixes: d2ed456532 ("package/liburing: bump to version 2.12")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Marcus Hoffmann <buildroot@bubu1.eu>
Add upstream patch to fix build failure with Linux 6.19.
Upstream: f17facc866
Signed-off-by: Christian Stewart <christian@aperture.us>
[Arnout: update upstream reference to merged commit]
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Commit c53455ea4f ("package/qt5/qt5webengine-chromium: bump version
after qtwebengine bump") bumped qt5webengine-chromium but forgot to
update the licenses.
The diff of the license is reported by
git diff 0ad2814370799a2161057d92231fe3ee00e2fe98..18c9261dc5b8aa57a0bdd5b62ce6f648cca1ef5e -- chromium/third_party/zlib/LICENSE
as the following:
diff --git a/chromium/third_party/zlib/LICENSE b/chromium/third_party/zlib/LICENSE
index 9f056865b57..8aca25d8c7a 100644
--- a/chromium/third_party/zlib/LICENSE
+++ b/chromium/third_party/zlib/LICENSE
@@ -1,6 +1,6 @@
-version 1.2.11, January 15th, 2017
+version 1.2.12, March 27th, 2022
-Copyright (C) 1995-2017 Jean-loup Gailly and Mark Adler
+Copyright (C) 1995-2022 Jean-loup Gailly and Mark Adler
This software is provided 'as-is', without any express or implied
warranty. In no event will the authors be held liable for any damages
so it doesn't change its actual license, let's simply fix the sha256 to
the new value.
Fixes: c53455ea4f ("package/qt5/qt5webengine-chromium: bump version after qtwebengine bump")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
If we're adding a dependency to the package, it's for its build system
to use it. Unfortunately, when -feature-system-assimp is not passed, the
assimp module from the sources will be used. Moreover, it doesn't build
currently.
Unfortunately, qt53d still doesn't build with assimp from Buildroot.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
If we don't disable it, the assimp module from the sources will be used
instead of none. Unfortunately, it currently doesn't build so let's
disable it when BR2_PACKAGE_ASSIMP is not set such that one can still
build qt53d.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Commit fb53371286 introduced the
python-gymnasium package, but it was not careful enough to propagate
dependencies of selected packages, causing messages such as:
WARNING: unmet direct dependencies detected for BR2_PACKAGE_PYTHON_NUMPY
Depends on [n]: BR2_PACKAGE_PYTHON3 [=y] && BR2_PACKAGE_PYTHON_NUMPY_ARCH_SUPPORTS [=y] && BR2_INSTALL_LIBSTDCPP [=n] && (BR2_TOOLCHAIN_USES_GLIBC [=y] || BR2_TOOLCHAIN_USES_MUSL [=n]) && BR2_TOOLCHAIN_GCC_AT_LEAST_9 [=y]
Selected by [y]:
- BR2_PACKAGE_PYTHON_GYMNASIUM [=y] && BR2_PACKAGE_PYTHON3 [=y]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Since Buildroot commit dcee99507c in
2025.11-rc1 that bumped package/icu to version 77-1, the build of xerces
with ICU support enabled fails:
In file included from /home/bernd/buildroot/output/host/i586-buildroot-linux-gnu/sysroot/usr/include/unicode/uset.h:38,
from /home/bernd/buildroot/output/build/xerces-3.3.0/src/xercesc/util/regx/RangeToken.cpp:40:
/home/bernd/buildroot/output/host/i586-buildroot-linux-gnu/sysroot/usr/include/unicode/char16ptr.h:271:55:
error: 'is_same_v' is not a member of 'std'; did you mean 'is_same'?
Indeed, ICU now requires C++17. Instead of using a patch from Gentoo[1]
we use a backported upstream commit, limited to CMakeLists.txt, to raise
the c++ version.
The build error was not recorded yet by the autobuilders but can be
reproduced with this defconfig:
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_PACKAGE_XERCES=y
BR2_PACKAGE_ICU=y
[1] https://bugs.gentoo.org/931105
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Buildroot commit 97e2f63bdf bumped
bpftrace from 0.23.3 to 0.24.2.
This release includes upstream commit
7578314df6
which was added to version 0.24.0 and makes use of
bpf_iter_link_info.task that was added to the linux kernel in version
6.1:
f0d74c4da1
causing build errors when the toolchain contains kernel headers version
6.0 because the libbpf package does not update their headers:
output/build/bpftrace-0.24.2/src/attached_probe.cpp: In static member
function 'static bpftrace::Result<std::unique_ptr<bpftrace::AttachedIterProbe> >
bpftrace::AttachedIterProbe::make(bpftrace::Probe&,
const bpftrace::BpfProgram&, std::optional<int>)':
output/build/bpftrace-0.24.2/src/attached_probe.cpp:1437:11: error:
'union bpf_iter_link_info' has no member named 'task'
1437 | linfo.task.pid = *pid;
The build error can be reproduced with this defconfig
BR2_aarch64=y
BR2_KERNEL_HEADERS_VERSION=y
BR2_DEFAULT_KERNEL_VERSION="6.0.19"
BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_6_0=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_PER_PACKAGE_DIRECTORIES=y
BR2_PACKAGE_BPFTRACE=y
on the 2026.02.x branch as of 0be927b89a.
Fixes:
https://autobuild.buildroot.net/results/146/14671c54fdf0a2e44bcce7ff61ca9b89a925eca9/
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Buildroot commit 97e2f63bdf in 2026.02-rc1
bumped bpftrace from 0.23.3 to 0.24.2.
This release includes upstream commit
d4f5838227
which was added to version 0.24.0 and makes use of btf_enum64 that was
added to the linux kernel in version 6.0:
6089fb325c
causing build errors when the toolchain contains kernel headers between
versions 5.12 and 5.19 because the libbpf package does not update their
headers so we need to raise the BR2_TOOLCHAIN_HEADERS_AT_LEAST_ version
number again.
The build error can be reproduced with this defconfig
BR2_aarch64=y
BR2_KERNEL_HEADERS_VERSION=y
BR2_DEFAULT_KERNEL_VERSION="5.11.22"
BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_5_11=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_PER_PACKAGE_DIRECTORIES=y
BR2_PACKAGE_BPFTRACE=y
on the 2026.02.x branch as of 0be927b89a.
Fixes:
https://autobuild.buildroot.net/results/8f7/8f7ce88a070e825ef178275a13d969349f05593b/
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Buildroot added the bpftrace package in 2024 with commit
338acb27ff
which initially provided version 0.19.1.
This release includes upstream commit
fea3193989
which was added to version 0.17.0 in 2022 and makes use of certain
variables of struct bpf_btf_info which were added to the linux kernel in
2020 with version 5.11:
5329722057
+ __aligned_u64 name;
+ __u32 name_len;
+ __u32 kernel_btf;
The libbpf package updates toolchain headers with its bundled version
only when the toolchain headers are version 5.8 or older, this condition
is part of the initial version of the package added in 2020 with
buildroot commit f7b8508e4f. This version
limit should have been raised when the bpftrace package was added to
avoid build errors when the toolchain contains header versions 5.9 or
5.10.
This situation caused build errors in the autobuilder, the last one in
February 2025:
/home/autobuild/autobuild/instance-18/output-1/build/bpftrace-0.19.1/src/bpffeature.cpp:
In member function 'bool bpftrace::BPFfeature::has_module_btf()':
/home/autobuild/autobuild/instance-18/output-1/build/bpftrace-0.19.1/src/bpffeature.cpp:573:8:
error: 'struct bpf_btf_info' has no member named 'name'
573 | info.name = (__u64)name;
| ^~~~
/home/autobuild/autobuild/instance-18/output-1/build/bpftrace-0.19.1/src/bpffeature.cpp:574:8:
error: 'struct bpf_btf_info' has no member named 'name_len'
574 | info.name_len = sizeof(name);
The problem disappeared from the autobuilders due to newer headers
versions used for the buildroot toolchain or other build errors occurring
earlier, like llvm version mismatches.
The build error can today still be reproduced with this defconfig
BR2_aarch64=y
BR2_KERNEL_HEADERS_5_10=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_PER_PACKAGE_DIRECTORIES=y
BR2_PACKAGE_BPFTRACE=y
on the 2026.02.x branch as of 0be927b89a.
To fix the problem we raise the BR2_TOOLCHAIN_HEADERS_AT_LEAST_ version
number.
Fixes:
https://autobuild.buildroot.net/results/dbe/dbecf88c7edba357cee8fea31294ddb9f4d188ad/https://autobuild.buildroot.net/results/df5/df59e038de47f63d14e1be7bd12dd16a69636f79/https://autobuild.buildroot.net/results/359/3595d39dd53a686bbf996dd4e532ced44906b9e3/https://autobuild.buildroot.net/results/e4f/e4f95a5f30a605eadb81802075ea6bb1e2880684/https://autobuild.buildroot.net/results/bd0/bd075cb8c55f9f8a017711dc804b8d81ae89b4c5/
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Buildroot commit f7b8508e4f in 2021.08-rc1
added the libbpf package which contains the usage of the
'install_uapi_headers' make target to update toolchain headers older
than kernel version 5.9. This does not work with per-package
directories.
Building this defconfig that includes all packages depending on libbpf:
BR2_x86_64=y
BR2_x86_rocketlake=y
BR2_KERNEL_HEADERS_VERSION=y
BR2_DEFAULT_KERNEL_VERSION="5.8.18"
BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_5_8=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_PER_PACKAGE_DIRECTORIES=y
BR2_PACKAGE_BPFTRACE=y
BR2_PACKAGE_DPDK=y
BR2_PACKAGE_IPROUTE2=y
BR2_PACKAGE_HOST_PAHOLE=y
on the 2026.02.x branch as of 0be927b89a
is broken:
output/build/bpftrace-0.24.2/src/attached_probe.cpp: In static member
function 'static bpftrace::Result<std::unique_ptr<bpftrace::AttachedIterProbe> >
bpftrace::AttachedIterProbe::make(bpftrace::Probe&,
const bpftrace::BpfProgram&, std::optional<int>)':
output/build/bpftrace-0.24.2/src/attached_probe.cpp:1435:30: error:
aggregate 'bpf_iter_link_info linfo' has incomplete type and cannot be
defined
1435 | union bpf_iter_link_info linfo;
libbpf overwrites kernel header files installed in $STAGING_DIR when
they are too old by adding 'install_uapi_headers' as make target. In
the case of per-package directories these header files are stored only
in output/per-package/libbpf/.
When output/per-package/bpftrace/ is populated, the content of
output/per-package/ from other packages overwrites the header files
installed by libbpf because the list of rsync'ed packages is sorted
alphabetically:
https://gitlab.com/buildroot.org/buildroot/-/blob/2026.02.1/package/pkg-generic.mk#L796
To prevent this problem let libbpf install the updated kernel headers in
a new directory.
Other packages need to find this directory. This mostly happens through
pkg-config, but bpftrace doesn't use that:
https://github.com/bpftrace/bpftrace/blob/v0.25.1/cmake/FindLibBpf.cmake#L9
Therefore, use a configure option in bpftrace to set the correct path.
Please note that libbpf will add '/linux' to the path provided in
$UAPIDIR:
https://github.com/libbpf/libbpf/blob/v1.7.0/src/Makefile#L169
so the headers end up in the previously non-existing directory
$(STAGING_DIR)/usr/include/bpf/linux/:
$ find output/per-package/libbpf/host/x86_64-buildroot-linux-gnu/sysroot/ -iname bpf.h -exec ls -lao {} \;
-rw-r--r-- 1 bernd 26434 25. Apr 13:15 output/per-package/libbpf/host/x86_64-buildroot-linux-gnu/sysroot/usr/include/bpf/bpf.h
-rw-r--r-- 1 bernd 283012 25. Apr 13:15 output/per-package/libbpf/host/x86_64-buildroot-linux-gnu/sysroot/usr/include/bpf/linux/bpf.h
-rw-r--r-- 12 bernd 160166 25. Apr 13:08 output/per-package/libbpf/host/x86_64-buildroot-linux-gnu/sysroot/usr/include/linux/bpf.h
bpf.h with 283012 bytes is the update-to-date version needed for bpftrace:
$ grep -m1 bpf_iter_link_info output/per-package/libbpf/host/x86_64-buildroot-linux-gnu/sysroot/usr/include/bpf/linux/bpf.h
union bpf_iter_link_info {
$
$ grep -m1 bpf_iter_link_info output/per-package/libbpf/host/x86_64-buildroot-linux-gnu/sysroot/usr/include/linux/bpf.h
$
By adding '-I$(STAGING_DIR)/usr/include/bpf' to the CXXFLAGS of bpftrace
its include finds the correct header:
https://github.com/bpftrace/bpftrace/blob/v0.25.1/src/bpfprogram.cpp#L3
#include <linux/bpf.h>
The dpdk package uses pkg-config` to detect libbpf and will use the updated
.pc file:
https://github.com/DPDK/dpdk/blob/v25.11/drivers/net/tap/bpf/meson.build#L7
The iproute2 package is not affected by the problem because it contains
"matching sanitized kernel headers":
https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/tree/README?h=v6.17.0#n44
As a host package pahole is also not affected.
Fixes:
https://autobuild.buildroot.net/results/d8b/d8b416e40bf7bd019cd93e6f2d42c98fc12d4160/
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Buildroot commit 97e2f63bdf in 2026.02-rc1
bumped the package to 0.24.2 but forgot to remove the configure option
INSTALL_TOOL_DOCS which was removed upstream in version 0.24.0:
579e0e9dfe
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Buildroot commit 305c40613c in 2025.08-rc1
bumped the package to 0.23.3 but forgot to remove the configure option
USE_SYSTEM_BPF_BCC which was removed upstream in version 0.20.0:
ef6d9d42d3
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Since last commit, utils/generate-cyclonedx can now be used with
Buildroot host tools, provided the user either externally install the
SPDX schema in the DL_DIR themselves or have
BR2_PACKAGE_HOST_PYTHON3_SSL and BR2_PACKAGE_HOST_CA_CERTIFICATES both
enabled. If the latter is missing, Python will complain with:
Traceback (most recent call last):
File "/buildroot/build/host/lib/python3.14/urllib/request.py", line 1321, in do_open
h.request(req.get_method(), req.selector, req.data, headers,
~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
encode_chunked=req.has_header('Transfer-encoding'))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/buildroot/build/host/lib/python3.14/http/client.py", line 1358, in request
self._send_request(method, url, body, headers, encode_chunked)
~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/buildroot/build/host/lib/python3.14/http/client.py", line 1404, in _send_request
self.endheaders(body, encode_chunked=encode_chunked)
~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/buildroot/build/host/lib/python3.14/http/client.py", line 1353, in endheaders
self._send_output(message_body, encode_chunked=encode_chunked)
~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/buildroot/build/host/lib/python3.14/http/client.py", line 1113, in _send_output
self.send(msg)
~~~~~~~~~^^^^^
File "/buildroot/build/host/lib/python3.14/http/client.py", line 1057, in send
self.connect()
~~~~~~~~~~~~^^
File "/buildroot/build/host/lib/python3.14/http/client.py", line 1499, in connect
self.sock = self._context.wrap_socket(self.sock,
~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^
server_hostname=server_hostname)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/buildroot/build/host/lib/python3.14/ssl.py", line 455, in wrap_socket
return self.sslsocket_class._create(
~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
sock=sock,
^^^^^^^^^^
...<5 lines>...
session=session
^^^^^^^^^^^^^^^
)
^
File "/buildroot/build/host/lib/python3.14/ssl.py", line 1076, in _create
self.do_handshake()
~~~~~~~~~~~~~~~~~^^
File "/buildroot/build/host/lib/python3.14/ssl.py", line 1372, in do_handshake
self._sslobj.do_handshake()
~~~~~~~~~~~~~~~~~~~~~~~~~^^
ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1081)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/buildroot/utils/generate-cyclonedx", line 53, in <module>
urllib.request.urlretrieve(SPDX_SCHEMA_URL, SPDX_SCHEMA_PATH)
~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/buildroot/build/host/lib/python3.14/urllib/request.py", line 212, in urlretrieve
with contextlib.closing(urlopen(url, data)) as fp:
~~~~~~~^^^^^^^^^^^
File "/buildroot/build/host/lib/python3.14/urllib/request.py", line 187, in urlopen
return opener.open(url, data, timeout)
~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^
File "/buildroot/build/host/lib/python3.14/urllib/request.py", line 487, in open
response = self._open(req, data)
File "/buildroot/build/host/lib/python3.14/urllib/request.py", line 504, in _open
result = self._call_chain(self.handle_open, protocol, protocol +
'_open', req)
File "/buildroot/build/host/lib/python3.14/urllib/request.py", line 464, in _call_chain
result = func(*args)
File "/buildroot/build/host/lib/python3.14/urllib/request.py", line 1369, in https_open
return self.do_open(http.client.HTTPSConnection, req,
~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
context=self._context)
^^^^^^^^^^^^^^^^^^^^^^
File "/buildroot/build/host/lib/python3.14/urllib/request.py", line 1324, in do_open
raise URLError(err)
urllib.error.URLError: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1081)>
Provide some hint as to what could be missing from Buildroot host.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
The host ca-certificates is needed to download the SPDX schema on
CycloneDX's GitHub when using Buildroot's host Python, see
urllib.request.urlretrieve(SPDX_SCHEMA_URL, SPDX_SCHEMA_PATH) in
utils/generate-cyclonedx.
Note that unlike the target package which uses a _TARGET_FINALIZE_HOOKS
since commit 2bc8e72baf ("package/ca-certificates: create the bundle
as target-finalize hook"), the host package doesn't have this option as
there's no such hook for host packages. Therefore, the target's
CA_CERTIFICATES_INSTALL_TARGET_CMDS and CA_CERTIFICATES_GEN_BUNDLE are
merged and adapted into HOST_CA_CERTIFICATES_INSTALL_CMDS.
This of course has the same shortcomings as the target package had
before commit 2bc8e72baf ("package/ca-certificates: create the bundle
as target-finalize hook").
The adaptations were:
- replaced $(TARGET_MAKE_ENV) with $(HOST_MAKE_ENV)
- replaced $(TARGET_DIR) to $(HOST_DIR)
- replaced $(HOST_DIR)/usr with $(HOST_DIR)
- replaced find usr/share/ca-certificates with find share/ca-certificates
(since it's done from within $(HOST_DIR)
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
urllib will eventually complain that it does not know what https is:
Traceback (most recent call last):
File "/buildroot/utils/generate-cyclonedx", line 53, in <module>
urllib.request.urlretrieve(SPDX_SCHEMA_URL, SPDX_SCHEMA_PATH)
~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/buildroot/build/host/lib/python3.14/urllib/request.py", line 212, in urlretrieve
with contextlib.closing(urlopen(url, data)) as fp:
~~~~~~~^^^^^^^^^^^
File "/buildroot/build/host/lib/python3.14/urllib/request.py", line 187, in urlopen
return opener.open(url, data, timeout)
~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^
File "/buildroot/build/host/lib/python3.14/urllib/request.py", line 487, in open
response = self._open(req, data)
File "/buildroot/build/host/lib/python3.14/urllib/request.py", line 509, in _open
return self._call_chain(self.handle_open, 'unknown',
~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
'unknown_open', req)
^^^^^^^^^^^^^^^^^^^^
File "/buildroot/build/host/lib/python3.14/urllib/request.py", line 464, in _call_chain
result = func(*args)
File "/buildroot/build/host/lib/python3.14/urllib/request.py", line 1397, in unknown_open
raise URLError('unknown url type: %s' % type)
urllib.error.URLError: <urlopen error unknown url type: https>
It's quite confusing really but what it means is that host Python was
built without ssl support.
This adds an additional check importing _ssl and if the module is not
found, tell the user what to do. This still doesn't make Buildroot's
host Python3 fully usable for utils/generate-cyclonedx as it'll then
fail when trying to validate certificates, this will be handled in the
next few commits.
Note that ssl Python library is always built in CPython, but itself
imports the _ssl module which is the one that may be disabled with
py_cv_module__ssl=n/a (which is what happens when
BR2_PACKAGE_HOST_PYTHON3_SSL is not enabled), hence why _ssl is checked
and not ssl.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Buildroot-local patches can only be suffixed by .patch, otherwise they
either need to be downloaded via <PKG>_PATCH or manually applied via
$(APPLY_PATCHES) in a <PKG>_{PRE,POST}_PATCH_HOOKS like in
linux/linux.mk. In the former case, they are then listed in the
show-info output with a full URL (prefixed by '<PKG>_SITE_METHOD+'). In
the latter case, they not listed as patches at the moment, just as
externalReferences.
By removing "support" for those compressed patches, we can avoid the bz2
dependency and can now use Buildroot's host-python3 package without
BR2_PACKAGE_HOST_PYTHON3_BZIP2 to run utils/generate-cyclonedx.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Some packages do not have a http/https download URL for a source tarball,
but are acquired over a version control system like git. If so, add
externalReferences of type "vcs" for such URLs.
As most git repositories use a https:// transport that may not indicated the
repository type, add a "comment" due to the lack of a better mechanism in
CycloneDX.
While the hashes are calculated over a tarball created locally, it still may
be useful, so add them for "vcs" externalReferences as well.
Signed-off-by: Martin Willi <martin@strongswan.org>
Acked-By: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Finding the hash file for a package is non-trivial, as they can be in a
<version> sub-directory or under GLOBAL_PATCH_DIR. To allow other tools
such as utils/generate-cyclonedx to find hash files, expose this information
from show-info. If a package does not provide a hash file, create an
empty hashes array.
Suggested-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Martin Willi <martin@strongswan.org>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Commit dc4af8bfa9 ("utils/generate-cyclonedx: use direct dependencies")
removes indirect dependencies from any listed component, as required by
CycloneDX. The root component, however, still includes indirect dependencies,
as it just takes the components from the show-info output.
Fix this by collecting all component dependencies, and then filter the root
component dependencies to include direct dependencies only.
Signed-off-by: Martin Willi <martin@strongswan.org>
Acked-By: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
