Commits [1] and [2] are installing host SDK files
"$(HOST_DIR)/usr/share".
check-package (see [3]) reports the error:
package/pico-sdk/pico-sdk.mk:23: install files to $(HOST_DIR)/ instead of $(HOST_DIR)/usr/
package/pico-sdk/pico-sdk.mk:24: install files to $(HOST_DIR)/ instead of $(HOST_DIR)/usr/
package/picotool/picotool.mk:15: install files to $(HOST_DIR)/ instead of $(HOST_DIR)/usr/
This commit installs the host SDK files to "$(HOST_DIR)/share" to fix
this error.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/12970341499
[1] ceb800d3c6
[2] 926381d360
[3] 29a0dd4a30
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Currently, when both libnss and GnuTLS are present, NetworkManager will
get linked to libnss.
The NetworkManager project doesn't recommend one over the other
officially and has supported both from day one back in 2007.
Arguments which one to prefer can be made in either direction:
Points in favor of libnss:
- It's the default value in the NM build system, so it would be the
preferred backend if both are available and we didn't supply any
options to the build process
- It's probably the more mature of the two, given that it's being used
in Mozilla products
Points in favor of GnuTLS:
- While both backends seem feature-equivalent, the
_nm_crypto_verify_pkcs8 function is stubbed out in the libnss
code[1].
- Both Debian and Fedora explicitly select GnuTLS in their packages. At
least in the case of Fedora it seems to have been a conscious
choice[2].
Given what it's actually used for in the code base, the choice does not
matter a lot. However, since it is marginally more feature-complete and
seems to be preferred by other distributions, let's switch to GnuTLS.
[1] 36f8de25c4/src/libnm-crypto/nm-crypto-nss.c (L523-540)
[2] 29a9c41bea
Signed-off-by: Florian Larysch <fl@n621.de>
Reviewed-by: Marcus Hoffmann <buildroot@bubu1.eu>
Signed-off-by: Marcus Hoffmann <buildroot@bubu1.eu>
The network-manager package currently pulls in either gnutls or libnss,
neither of which are very common and it might be the only reason why
they are present on a system.
However, most of NetworkManager works just fine without any cryptography
support, it only seems to be used in test cases and 802.1X support code.
Remove the dependency but use a library if it is present.
Note that this changes the default behavior. If network-manager was the
only package pulling in gnutls, it won't do this anymore and use the
"null" backend. Add a note about this to the manual.
Signed-off-by: Florian Larysch <fl@n621.de>
Tested-by: Marcus Hoffmann <buildroot@bubu1.eu>
Reviewed-by: Marcus Hoffmann <buildroot@bubu1.eu>
[Marcus: Change buildroot version to 2026.02 in migrating.adoc]
Signed-off-by: Marcus Hoffmann <buildroot@bubu1.eu>
Add BR2_PACKAGE_DPDK_APPS_LIST to control which DPDK applications are
built:
- empty : use DPDK defaults
- none : disable all apps (-Ddisable_apps='*')
- list : pass to -Denable_apps= (comma-separated)
Signed-off-by: Maxime Leroy <maxime@leroys.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Add BR2_PACKAGE_DPDK_LIBS_LIST to control which DPDK libraries are
built:
- empty : use DPDK defaults
- none : disable all libs (-Ddisable_libs='*')
- list : pass to -Denable_libs= (comma-separated)
Signed-off-by: Maxime Leroy <maxime@leroys.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Add BR2_PACKAGE_DPDK_DRIVERS_LIST to control which DPDK applications are
built:
- empty : use DPDK defaults
- none : disable all drivers (-Ddisable_drivers='*/*')
- list : pass to -Denable_drivers= (comma-separated)
Signed-off-by: Maxime Leroy <maxime@leroys.fr>
[Julien: slightly change the drivers Config.in help text:
- rename net/ixgbe to net/intel/ixgbe
- change find -maxdepth value to 3
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
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>
There are multiple defconfig fragments we can select to modify the final
tiboot3.bin image to support different boot methods or enable features
supported by a board. Allow the ti-k3-r5-loader package to select
defconfig gragments during a build
Signed-off-by: Bryan Brattlof <bb@ti.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
LLVM is already implicitly enabled for host-mesa3d when
BR2_PACKAGE_MESA3D_NEEDS_PRECOMP_COMPILER is selected. This blind
option is automatically enabled when LLVM is required by drivers such
as intel-iris, panfrost, imagination, or intel-vulkan.
The BR2_PACKAGE_MESA3D_LLVM option also independently selects host-llvm,
but this change makes the dependency more explicit for host-mesa3d
builds.
Note that disabling LLVM is not possible for host-mesa3d, as the build
will fail with:
../../../br-test-pkg/bootlin-armv5-uclibc/build/host-mesa3d-25.3.2/meson.build:847:3: ERROR: Feature llvm cannot be disabled: CLC requires LLVM
Signed-off-by: Thomas Devoogdt <thomas@devoogdt.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Backport two security fixes from upstream. They are in newer releases,
but to facilitate backporting to our LTS releases, this backports the
fixes.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The dependencies on Boost.System, Boost.Filesystem were removed in
v23.0 [0][1] and Boost.Thread in v21.99 [2].
This was never reflected in the Buildroot package so do it now.
[0] 07269321f3
[1] b87f9c5edf
[2] 06e1d7d81d
Signed-off-by: Michael Nosthoff <buildroot@heine.tech>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Commit [1] added the "Upstream:" package patch tag, but forgot to
remove the corresponding .checkpackageignore entry.
This commit fixes that.
Fixes:
package/efl/0001-ecore_fb-fix-build-with-tslib.patch:0: lib_patch.Upstream was expected to fail, did you fix the file and forget to update .checkpackageignore?
[1] bac34296bf
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
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>
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>
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>
mpg123 supports (and prefers) SDL2 as well for the sdl backends since 1.26.9
with:
792615f651
So support that here as well.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Arm Trusted Firmware (TF-A) can be used to load U-Boot or another
bootloader, which in turn loads the Linux kernel. However, TF-A is
capable of loading the kernel directly. To this end, we need to define
the BL33 and BL33_CFG compile options containing, respectively, the
zImage and the DTB.
This config introduces a new config option,
BR2_TARGET_ARM_TRUSTED_FIRMWARE_LINUX_AS_BL33, which sets the BL33 and
BL33_CFG parameters, and ensures that the kernel is built before the
TF-A by having linux as a _DEPENDENCY of the TF-A.
Signed-off-by: Jakob Kastelic <kastelic.jakob@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
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>
The test failed in the past, due to kbd build failure. See [1].
This specific issue was fixed by commit [2].
This commit was originally written to workaround this issue, which was
unrelated to the actual package being tested. Since systemd-vconsole
is not needed anyway, this commit removes it from the test config.
[1] https://gitlab.com/buildroot.org/buildroot/-/jobs/12363929666
[2] d98d9ba28f
Signed-off-by: Marcus Hoffmann <buildroot@bubu1.eu>
[Julien: reword the commit log]
Signed-off-by: Julien Olivain <ju.o@free.fr>
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>
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>
- 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>
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>
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>
