Currently, the relocate-sdk.sh script scans the whole extracted SDK tree
to find instances of paths it needs to replace, which can take a
significant amount of time when the SDK is large, particularly relative
to the number of files that actually need to change.
However, the resulting list only depends on the SDK tarball itself, so
we can calculate it at build time and ship it with the tarball so
relocate-sdk.sh can use it directly.
Testing this on my machine with somewhat IOPS-limited rotating media,
the time goes down from:
$ time ./relocate-sdk.sh
Relocating the buildroot SDK from [...] to [...] ...
./relocate-sdk.sh 5.19s user 26.21s system 9% cpu 5:34.40 total
To:
$ time ./relocate-sdk.sh
Relocating the buildroot SDK from [...] to [...] ...
./relocate-sdk.sh 0.49s user 0.29s system 103% cpu 0.749 total
Signed-off-by: Florian Larysch <fl@n621.de>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
(cherry picked from commit 63877f9e86)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Commit [1] bumped glibc from 2.42-3-gbc13db739 to 2.42-51-gcbf39c26b
to fix some CVEs, but forgot to add those CVEs to GLIBC_IGNORE_CVES.
This was needed because the GLIBC_CPE_ID_VERSION used for CVE checks
remains to the same value "2.42" which is marked as vulnerable to
those CVEs.
This commit adds those _IGNORE_CVES with the corresponding upstream
commit references, to make sure they will not be reported by the
"make pkg-stats" command.
Fixes:
- [1]
[1] 18de297a5a
Cc: Waldemar Brodkorb <wbx@openadk.org>
Cc: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 574aa2cfee)
[thomas: match to 2.41 branch]
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
When running "make pkg-stats" on a host with Python 3.14 (e.g.
Fedora 43 for example), the execution fails with the error:
Checking URL status
Traceback (most recent call last):
File "/buildroot/support/scripts/pkg-stats", line 1387, in <module>
__main__()
~~~~~~~~^^
File "/buildroot/support/scripts/pkg-stats", line 1368, in __main__
loop = asyncio.get_event_loop()
File "/usr/lib64/python3.14/asyncio/events.py", line 715, in get_event_loop
raise RuntimeError('There is no current event loop in thread %r.'
% threading.current_thread().name)
RuntimeError: There is no current event loop in thread 'MainThread'.
This is due to a breaking change introduced in Python 3.14
asyncio.get_event_loop(). See [1]. Before Python 3.14, this call was
creating and setting an event loop if there was none. This situation
is now a runtime error.
In order to fix this issue with newer Python version, while keeping
backward compatibility, this commit replaces the code:
loop = asyncio.get_event_loop()
by an explicit event loop creation:
loop = asyncio.new_event_loop()
asyncio.set_event_loop(loop)
This commit was tested on a Fedora 43 host with Python-3.14.2, and
with the Buildroot Docker image plus the python3-aiohttp package
which is a Debian 12 with Python-3.11.2.
[1] https://docs.python.org/3.14/library/asyncio-eventloop.html#asyncio.get_event_loop
Signed-off-by: Julien Olivain <ju.o@free.fr>
Tested-by: Vincent Fazio <vfazio@xes-inc.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit e9f426aa52)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
When the host system has asciidoctor and po4a/poman installed,
util-linux detect them and automatically enable manual pages and
their translations. This can significantly increase the package
build time (in my case, from 20s to 1m50s). See upstream
commit [1] and [2].
Since manual pages are not needed in Buildroot, this commit adds in
_CONF_OPTS for host host and target variants the options to always
disable the detection of those programs (--disable-asciidoc
--disable-poman). This will always disable the generation of manual
pages.
Note: Buildroot attempts to globally disable documentation for
autotools packages by passing various --disable-docs configure
options (see [3]), but those are not recognized by util-linux.
This commit also reorder the options for UTIL_LINUX_CONF_OPTS.
[1] 9acfc349e0
[2] 236421a491
[3] https://gitlab.com/buildroot.org/buildroot/-/blob/2025.11/package/pkg-autotools.mk#L184-186
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit dd81c1766e)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Marcus Hoffmann <buildroot@bubu1.eu>
[Peter: Fix flake8 warning, use http.server instead of relying on
connectivity]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 425abcd025)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Patch 0001 has the upstream information, just not properly formatted,
so we fix this.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
[Thomas: extracted from a bigger patch from Bernd]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit c15b507838)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
According to the official requirements, bindgen needs libclang to
parse C/C++ headers. libclang is loaded at runtime by bindgen, which
is why we didn't notice any build issue. However, using bindgen on a
simple header file blows up:
thread 'main' panicked at bindgen/lib.rs:616:27:
Unable to find libclang: "couldn't find any valid shared libraries matching: ['libclang.so', 'libclang-*.so', 'libclang.so.*', 'libclang-*.so.*'], s
et the `LIBCLANG_PATH` environment variable to a path where one of these files can be found (invalid: [])"
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
So far, bindgen was only used by mesa3d, and it turns out that mesa3d
also depends on clang, which pulls in host-clang, so the problem was
not visible. However, as we're about to use bindgen for other
things (namely Rust support in Linux), this issue needs to be fixed.
See:
https://rust-lang.github.io/rust-bindgen/requirements.html
Signed-off-by: El Mehdi YOUNES <elmehdi.younes@smile.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 34ed3bbf0a)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The new target provides a convenient way to run utils/check-package on
any external trees, using .checkpackageignore files from the
respective trees if present.
While .checkpackageignore should be used as little as possible, in a
few cases adding overrides for false-positives to the affected files
is not feasible, a practical example of this is a Markdown file
misidentified as Python by libmagic (likely due to code blocks).
Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
[Arnout: set ${ignore} explicitly to empty, in case it exists in the
environment.]
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
(cherry picked from commit fe48905080)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Testing with a really old toolchain is helpful to catch issues related
to kernel headers version issues, gcc version issues, etc. We chose a
glibc toolchain though as old musl or uClibc-ng versions tend to lack
a number of features that are needed by modern software.
This toolchain is placed near the top of toolchain-configs.csv, so
that it is used as part of the "base" set of toolchain that test-pkg
uses, even without the -a option.
test-pkg takes the 6 first toolchains of this CSV file for its base
test, and actually the comment in toolchain-configs.csv was wrong
since commit 53a8c5150e, which removed a
toolchain from the base set, but not realizing that test-pkg would
anyway continue to test the first 6 toolchains.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 85d47bbc40)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The prebuilt MIPS64 toolchains are very old, causing build issues (for
example recently with the systemd v258 update). Replace them both a
single toolchain configuration that uses one of the mips64el Bootlin
toolchains.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 573a113edd)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
- br-i386-pentium4-full.config as an x86 32-bit toolchain test is
already reasonably covered by bootlin-x86-i686-musl.config
- br-microblazeel-full-internal.config as a Microblaze toolchain test is
already reasonably covered by bootlin-microblazeel-uclibc.config
- br-powerpc-internal-full.config and br-powerpc-603e-basic-cpp.config
as PowerPC 32-bit toolchain tests are already reasonably covered by
bootlin-powerpc-e500mc-uclibc.config
- br-powerpc64-power7-glibc.config as a PowerPC 64-bit toolchain test
is already reasonably covered by
bootlin-powerpc64le-power8-glibc.config
- br-riscv64-full-internal.config as a RISC-V 64-bit toolchain test is
already reasonably covered by bootlin-riscv64-glibc.config and
bootlin-riscv64-musl.config
- br-s390x-z13-internal-glibc.config as a s390 toolchain test is
already reasonably covered by bootlin-s390x-z13-glibc.config
- br-xtensa-full-internal.config as an Xtensa toolchain test is
already reasonably covered by bootlin-xtensa-uclibc.config
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 8bab0acff6)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Building internal toolchains takes a long time, and since the
differences between the 3 internal ARM toolchains is just the libc,
and we're already testing uclibc/musl with external toolchains, it
doesn't make much sense to build 3 different ARM internal toolchains.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 61fe61af31)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
We're already testing the ARC architecture with one Bootlin toolchain,
it doesn't make sense to also test with two Buildroot internal
toolchains the ARC architecture, which is not a primary architecture
for Buildroot.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit ceaf0a2283)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The linux-headers package was not providing any license file for any
version other than the latest one.
Fix this by adding a Kconfig option to specify the license file,
with a default value set to the commonly used license paths.
For the headers-as-kernel case, use LINUX_LICENSE_FILES and disable the
Kconfig option entirely.
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
(cherry picked from commit d94762640e)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The AT91Bootstrap3 package was not providing any license file when a custom
Linux version was selected.
Fix this by adding a Kconfig option to specify the license file,
with a default value set to the commonly used license paths.
Note that version 3.X of at91bootstrap didn't have an open source
license and no license file either. Keep that behavior.
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
[Arnout: use a single Kconfig option with conditional prompt]
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
(cherry picked from commit d9999aeec9)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The ATF package was not providing any license file when a custom
Linux version was selected.
Fix this by adding a Kconfig option to specify the license file,
with a default value set to the commonly used license paths.
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
[Arnout: use a single Kconfig option with conditional prompt]
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
(cherry picked from commit 77670c33d2)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The Barebox package was not providing any license file when a custom
Linux version was selected.
Fix this by adding a Kconfig option to specify the license file,
with a default value set to the commonly used license paths.
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
[Arnout: use a single Kconfig option with conditional prompt]
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
(cherry picked from commit 76dee8aadc)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The OpenSBI package was not providing any license file when a custom
Linux version was selected.
Fix this by adding a Kconfig option to specify the license file,
with a default value set to the commonly used license paths.
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
[Arnout: use a single Kconfig option with conditional prompt]
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
(cherry picked from commit 399cc39621)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The OP-TEE OS package was not providing any license file when a custom
Linux version was selected.
Fix this by adding a Kconfig option to specify the license file,
with a default value set to the commonly used license paths.
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
[Arnout: use a single Kconfig option with conditional prompt]
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
(cherry picked from commit 71e8ca62dd)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The U-Boot package was not providing any license file when a custom
Linux version was selected.
Fix this by adding a Kconfig option to specify the license file,
with a default value set to the commonly used license paths.
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
[Arnout: use a single Kconfig option with conditional prompt]
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
(cherry picked from commit a4d5b20462)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The Linux package was not providing any license file when a custom
Linux version was selected.
Fix this by adding a Kconfig option to specify the license file,
with a default value set to the commonly used license paths.
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
[Arnout: use a single Kconfig option with conditional prompt]
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
(cherry picked from commit 50958bcdac)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Building berkeleydb is broken with a non-threaded toolchain with gcc >=
14.x:
../src/rep/rep_method.c:1740:25: error: implicit declaration of function
'__repmgr_get_nsites'; did you mean '__rep_get_nsites'?
[-Wimplicit-function-declaration]
1740 | return (__repmgr_get_nsites(env, n));
According to src/repmgr/repmgr_util.c, line 503+, the function
'__repmgr_get_nsites' mentioned in the gcc error message "may only be
called after threads have been started".
This source file repmgr_util.c belongs to REPMGR_OBJS according to
dist/Makefile.in, line 249+, which is, according to dist/configure.ac,
line 956, only build if thread support is present.
In a non-threaded build '__repmgr_get_nsites' does not exist causing the
build error.
To fix the build error we disable replication for non-threaded
toolchains.
Using gcc 13.x the build error does not occur, tested with this
defconfig:
BR2_TOOLCHAIN_BUILDROOT_UCLIBC=y
BR2_PTHREADS_NONE=y
BR2_GCC_VERSION_13_X=y
BR2_PACKAGE_BERKELEYDB=y
Using this minimal gcc 14.x-based defconfig
BR2_TOOLCHAIN_BUILDROOT_UCLIBC=y
BR2_PTHREADS_NONE=y
BR2_PER_PACKAGE_DIRECTORIES=y
BR2_PACKAGE_BERKELEYDB=y
the build error can be reproduced.
The oldest build error of this kind, afaics, dates back to 2024-06-13:
https://autobuild.buildroot.net/results/e0d/e0d6bdbef01bee277b0da83605b2906af876058a/
Fixes:
https://autobuild.buildroot.net/results/792/792ed942d17bb8d00cd321536a102f6dd63b6a8a/
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 9a1a71be21)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Since its introduction in [1], by default the `generate-cyclonedx`
script doesn't include buildroot's virtual packages in its 'components'
list, unless using the `--virtual` argument.
References to virtual packages present in the 'show-info' output are
filtered out in the resulting dependencies.
This patch fix the default CycloneDX dependencies generation
without virtual packages to reference the packages that provide the
virtual package instead of just dropping the virtual package itself.
If we use the package `lbase64` that depends on the virtual package
`luainterpreter` as an example. The 'dependency' entry looks like the
following:
```
{
"ref": "lbase64",
"dependsOn": [
"host-skeleton",
"skeleton-init-common",
"skeleton-init-sysv",
"toolchain-external-bootlin"
]
}
```
The `luainterpreter` dependency is missing.
After applying this patch, package that provides the `luainterpreter` is
present:
```
{
"ref": "lbase64",
"dependsOn": [
"host-skeleton",
"lua",
"skeleton-custom",
"skeleton-init-sysv"
]
}
```
In the case of a virtual package provided by multiple packages all those
packages will be listed. This happens when generating an SBOM on the
entire Buildroot packages.
[1] dbab39e2d9 support/scripts/generate-cyclonedx.py: add script to generate CycloneDX-style SBOM
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 67738a6e1d)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Since the introduction of the `generate-cyclonedx` script in [1] the
dependencies were 'recursive'. This means that the dependencies of a
package dependency were included.
The CycloneDX spec [2] states that only direct dependencies needs to be
included.
This patch drop the recursive dependencies.
[1] dbab39e2d9 support/scripts/generate-cyclonedx.py: add script to generate CycloneDX-style SBOM
[2] https://cyclonedx.org/docs/1.6/json/#dependencies
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit dc4af8bfa9)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The definition of the project name & version is stored under the
`metadata:component` CycloneDX property.
Since the introduction of the `generate-cyclonedx` script [1] a
'buildroot' dependency entry that depends on every components has been
part of the generated SBOM.
Tools such as 'DependencyTrack' relies on such entry to create graph of
the entire project.
With the commit [2] that introduced the option to pass a custom project
name and version, this dependency reference was not updated to match the
custom 'bom-ref'.
This patch fixes the reference to match the custom project name.
[1] dbab39e2d9 support/scripts/generate-cyclonedx.py: add script to generate CycloneDX-style SBOM
[2] 9cbbc47762 utils/generate-cyclonedx: add project name and version options
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 189a983c7d)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
