The syslinux runtime test (which is in fact a build-only test) ensures
that syslinux does get build at least once a week (via the gitlab-CI
weekly pipeline). Runtime testing would need much more work, though, but
nothing in syslinux is currently runtime tested anyway.
Reported-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The following error occurs on the autobuilder for builds with musl
libc.
```
CC util/bitmap.o
In file included from include/linux/bitmap.h:7,
from util/bitmap.c:9:
include/linux/bitops.h:4:10: fatal error: bits/wordsize.h: No such file or directory
4 | #include <bits/wordsize.h>
| ^~~~~~~~~~~~~~~~~
```
The error occurs because bits/wordsize.h is specific to glibc.
This patch applies an upstream fix that replaces the use of __WORDSIZE
with an internal macro, making the code portable across different libc.
Fixes: https://autobuild.buildroot.org/results/30d/30d6e407e6a0fc7d85062c2d56008755c70ca733/build-end.log
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The 0.192 release of elfutils introduced the src/srcfiles.cxx program,
that lists all source files of a given ELF binary. As this is a C++
program, we need a toolchain that supports it.
Without it, the build system tries to use "no" as the CXX compiler,
resulting in the following errors :
/bin/sh: line 1: no: command not found
as can be seen here for example :
https://autobuild.buildroot.net/results/849/849221c794a469a423857a290db775d150b84900
Add a dependency to a CPP toolchain for the elfutils programs.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The elfutils programs require Glibc to be used as the C library. Show a
comment when this libc isn't used in the toolchain.
Suggested-by: Yann E. MORIN <yann.morin@orange.com>
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This package provides a reference, functional implementation of a
registry for distributing container images. Formerly the Docker
registry, it now also handles OCI images, so can be used to distribute
all kinds of container related images: classic Docker images, OCI
images, but also helms [0] and the likes, which are also packages as OCI
images in fact.
The upstream name of the package is just "distribution" [1], but this is
a bit too generic and unsearchable; distributions like Debian and Ubuntu
traditionally provides it as the "docker-registry" package, but this is
now misleading as it is not just for Docker anymore. So we decided to
name it "distribution-registry": it contains the upstream name and will
be searchable with the 'registry' part as well.
The built executable is named "registry", which is also a bit too
generic. Again, for the same reasons as above, we name it
"distribution-registry"; this also incidentally makes our golang-package
infra "just work" and do the right thing when it installs the package.
The upstream package provides a wrapper Makefile to build the package,
but it does not do more than our infra already does; the only little nit
is that it allows updating the version file (with git infra et al.). We
can just ignore that and update the version ourselves.
We also provide a minimalist configuration file: it exposes the registry
to localhost only, as a security measure. This file will have to be
overridden (e.g. in a rootfs-overlay) with proper authentication, and
with further locally meaningful setup anyway.
Finally, we also implement a run-time test that validates that we can
push and pull images to/from the registry. Since the registry is a big
go package, it takes time to start, so wait for it a little bit (and yet
a little bit more after it starts logging), and increase the timeouts
for commands that deal with the registry.
For this simple test, the registry is directly exposed with plain HTTP,
not HTTPS, so we must declare it as insecure, so that container tools
can reach it without custom options (e.g. without using skopeo's
--{src,dest}-tls-verify=false options).
We re-use skopeo to talk to the registry. This allows us to grab an
image from the Docker hub registry, and push it to our local registry,
then retrieve it back. Since we want to diffferentiate failures to grab
the image from the Docker Hub [2], from failures to push to our
registry, we do it in two steps: copy from Docker Hub to a local OCI
image, then push that to our registry.
Since both distribution-registry and skopeo are big go-based, statically
linked binaries, running both in the standard virtual machine does not
work: the 256MiB emulated in vexpress are not enough and cause segfaults
when running both at once. The vexpress also only accepts at most
256MiB, so we must use another machine; we decided to use the same as is
used by the podman teest case, which allows at least 1Gib, which is now
enough.
[0] https://helm.sh/
[1] https://github.com/distribution/distribution
[2] in case we reach the 100-pulls-a-day limitation
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Christian Stewart <christian@aperture.us>
Signed-off-by: Julien Olivain <ju.o@free.fr>
... and extend the skopeo runtime test to make use of those.
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The container/image repository is the standards regpository that drives
the image management in container tools, like podman or skopeo. Besides
a Go library, it also prodvides the template configuration files used
by those tools; those files can also serve as default ones.
Install those files instead of the canned ones we cary in podman, and
change podman to use this new package too.
The registry file needs a fixup, as it by default does not allow
searching unqualified images (i.e. those that do not contain a registry
name) in a default registry, for security reasons. However, the Docker
Hub is traditionally a registry that can be accessed without being
specified, so we make that possible.
As was noted in ebbaac08e3 (package/podman: new package), "[p]roviding
actual files is going to be use-case dependent, and interested parties
will have to provide their own config files, e.g. in a rootfs overlay."
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
For release note, see:
https://dev.gnupg.org/T7166
This version fixes a build error which can happen with 32-bit arm
configurations.
The issue can be reproduced with commands:
cat >.config <<EOF
BR2_arm=y
BR2_cortex_a8=y
BR2_ARM_INSTRUCTIONS_THUMB2=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_PACKAGE_LIBGCRYPT=y
EOF
make olddefconfig
make libgcrypt
Build is failing with output:
ec-nist.c: In function '_gcry_mpi_ec_nist256_mod':
ec-inline.h:902:5: error: 'asm' operand has impossible constraints or there are not enough registers
902 | __asm__ ("subs %3, %7, %10\n" \
| ^~~~~~~
Details for this buggix: https://dev.gnupg.org/T7226
Signed-off-by: Bram Oosterhuis <dev@bybram.com>
[Julien: reword commit log]
Signed-off-by: Julien Olivain <ju.o@free.fr>
lpxelinux is like pxelinux, except it allows retrieving the files for
the kernel (with the KERNEL directive) and initrd (the path to initrd=
in the APPEND directive) from FTP or HTTP, rather than just from TFTP.
Using HTTP or FTP is musch faster than TFTP, so the boot time for big
kernels or big initrds is much shorter than with TFTP.
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
[Julien: fix typo in commit title]
Signed-off-by: Julien Olivain <ju.o@free.fr>
syslinux is... special. It is a target package, but it is installed in
HOST_DIR *in the target install commands*: in addition to the boot files
that run on the target, syslinux installs a set of host tools that are
to be used at build time (e.g. extlinux, to prepare bootable media, like
an iso96660 image). Then, from HOST_DIR, the actual boot files are
copied into BINARIES_DIR (i.e. images/); we do it that way because the
boot files are scattered about everywhere in the build tree, while they
are all packed together in a single directory once installed.
However, there is no dependency between the target and image install
steps. So, when using top-level parallel builds, there is no guarantee
that the target install commands are finished before the image install
commands are started.
We fix that by first installing into a temporary location, as part of
the build step, and by then copying from there as part of the install
step. This ensures that the boot files are easily available, without
needing a dependency on the target install step, that we can't express.
Note that we do not change the actual installation into HOST_DIR: it can
be set up differently that our temporary location, and we do not want
to duplicate that setup here (it's going to diverge over time).
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
At the moment, package stats indicates that libmpeg2 is affected by
https://nvd.nist.gov/vuln/detail/CVE-2022-37416
However, this CVE applies to a completely different piece of software,
that has the same name "libmpeg2" [1].
To avoid the confusion, let's add a proper CPE vendor to Buildroot's libmpeg2.
The library itself does not clearly identify any vendor name, and there isn't
any existing CPE on the NVD website. Since this library is not updated for
many years (maybe even before the introduction of the CPE system), but the
code is somehow related to the Videolan project, let's add this as the
vendor, which sould solve the matched CVE issue.
[1] https://github.com/ittiam-systems/libmpeg2
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
[Julien: fix typo in commit title]
Signed-off-by: Julien Olivain <ju.o@free.fr>
When a new gcc version is introduced, for example gcc 15 in
commit [1], it should have also added a "depends on
!BR2_ARCH_NEEDS_GCC_AT_LEAST_15" to the previous gcc version.
This logic is described for external toolchains in commit [2],
for example. The internal Buildroot toolchains should have the
same logic. This logic existed for previous gcc version. See for
example the removal of gcc 12 in commit [3].
There is usually no problem, because all the three latest active gcc
versions supports all CPUs present in Buildroot.
However, the commit [4] recently added the support for the Arm
Cortex-A720 CPU, which needs at least gcc 14. Since there is no
logic preventing the selection of the gcc version, it is possible
to select an unsupported gcc version (i.e. gcc 13).
In such a case, the host-gcc-initial package configuration fails
with output:
Unknown cpu used in --with-cpu=cortex-a720
This commit fixes the issue by adding those missing dependencies.
Fixes:
https://autobuild.buildroot.org/results/918b90aee0b65f01efc241622015cb847b4e23a8/
[1] 75891397ab
[2] f577d8218f
[3] 58cf7c51da (66f7e875db173e5538d3511c8297acc1ba30da33_27_25)
[4] de374e06d8
Cc: Romain Naour <romain.naour@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Strongswan allows to specify a path for PID and UNIX socket files at
compile time via the --with-piddir argument.
This is especially useful when Strongswan is running inside a container
where we may not want to share/mount the default path of /var/run inside
the container.
Let's add an option to configure the piddir.
Considering this is a critical path, let's add a default value to the
string option (which is currently the same as strongswan's default when
the option is missing) so that it is stable across strongswan releases
in Buildroot.
Signed-off-by: Martin Elshuber <martin.elshuber@theobroma-systems.com>
[Quentin: rewriting of commit title and commit log]
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Julien Olivain <ju.o@free.fr>
strongSwan allows to drop unneeded capabilities[1] after the IKE daemon
has been started, based on libcap, so let's allow that via a config
option.
While the "native" (capset) way of dropping capabilities is supported,
it is deprecated so its support is not added in Buildroot.
While the documentation specifically mentions the IKE daemon (charon) as
being the one impacted by this change, the ifdefery with this autotools
option exists in various libraries in the source code, hence why this is
kept independent from the charon Kconfig option status.
[1] https://docs.strongswan.org/docs/latest/install/reducedPrivileges.html#_dropping_capabilities
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Changelog:
https://codeberg.org/gumbo-parser/gumbo-parser/releases
Release 0.11.0 onwards dropped the 'v' version prefix in the tarball
name, so drop it on our side as well.
The patch no longer applied cleanly and needed to be refreshed.
It was also submitted to the new upstream, the upstream link is
updated accordingly.
A local test build was done with the toolchain from the config that
originally triggered the build to fail due to lack of C++ support:
http://autobuild.buildroot.org/results/a32b5d3b959433fd5c3543661c37f80d27fbd010
It is worth noting that we still build using autotools which is
deprecated in this version of gumbo-parser (in favor of meson).
The license file location was moved in a "doc" subdirectory, in upstream
commit [1]. This commit reflect that change.
[1] 814e2b43f7
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
[Julien: fix license file location which has moved to "doc/"]
Signed-off-by: Julien Olivain <ju.o@free.fr>
The new test requires a br2-external directory because we compile a
small test program on the host and install it on the target, but it's
not useful to have it in the main Buildroot package tree.
The test program loads and parses a sample HTML document. Taking
inspiration from 'examples/get_title.c' in gumbo-parser, it also
searches for the title of the document just to check that we can do
more than the parsing.
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Development on Google's GitHub repository has stopped a long time ago.
A fork exists on Codeberg, and multiple distributions (Fedora, Arch
Linux, ...) are already using it (see [1]).
Update the source URL to use the new upstream location.
The new upstream has a different hash for the 0.10.1 tarball, so
update it as well.
[1]: https://repology.org/project/gumbo-parser/versions
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This test verifies that we can run nginx with the modsecurity
directives.
It also checks a very simple rule that blocks requests containing the
keyword "blockme".
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
[Julien:
- add / at directory end in DEVELOPERS
- sort DEVELOPERS entries alphabetically
- remove unneeded test configs already present in
BASIC_TOOLCHAIN_CONFIG
- sort test config directives alphabetically
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
Backport the upstream patch that fixes the following build error when
compiling for mips with gcc 15:
In file included from mips-opc.c:29:
mips-opc.c: In function 'decode_mips_operand':
mips-formats.h:86:7: error: expected identifier or '(' before
'static_assert'
86 | static_assert[(1 << (SIZE)) == ARRAY_SIZE (MAP)]; \
| ^~~~~~~~~~~~~
The patch is already part of upstream binutils 2.44, so we only need
it for 2.42 and 2.43.1.
All 3 versions we have of host-binutils were build-tested using the
defconfig from the autobuilder failure (see the link below) and gcc 15
on the host.
Fixes:
- https://autobuild.buildroot.org/results/873/873ec25cf01d5f2b9ae7044e0b1d8d8791b781e6/
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The upstream Github repository payden/libwebsock is no longer available,
and its URL now redirects to some completely unrelated software.
We don't know for sure what happened, but at least the package does not
build anymore, because its source code has vanished.
Since no other buildroot package depends on libwebsock, and it hasn't
received any update; let's simply remove it from here.
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This fixes the following CVE:
- CVE-2025-29481:
Buffer Overflow vulnerability in libbpf 1.5.0 allows a local attacker to
execute arbitrary code via the bpf_object__init_prog` function of libbpf.
Fixes:
https://www.cve.org/CVERecord?id=CVE-2025-29481
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
[Julien: add direct link to CVE in commit log]
Signed-off-by: Julien Olivain <ju.o@free.fr>
Actually DTB_LIST accepts only file and not files with relative path
preprended. This leads to have vfat without .dtb files and so Linux
doesn't start. Let's fix this by including slash in sed command as done
for mxc as well as basename in front of $dt.dtb to remove possible
useless folders present in the dts path. Let's also add set -e at the
top of the script to make it more verbose on error and modify this
section according to spellcheck as done for mxc.
This commit align this "mxs/post-image.sh" with its "imx/post-image.sh"
counterpart which was improved for arm64 in commit [1].
[1] 4755bf2bd4
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
[Julien:
- change space indentation to tabs for consistency
- add note in commit log about imx/post-image.sh
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
This patch allows to use an external toolchain based on gcc 15.
Signed-off-by: Edgar Bonet <bonet@grenoble.cnrs.fr>
[Julien: change spaces to tabs to fix check-package errors]
Signed-off-by: Julien Olivain <ju.o@free.fr>
For release notes since edk2-stable202411, see:
https://github.com/tianocore/edk2/releases/tag/edk2-stable202502https://github.com/tianocore/edk2/releases/tag/edk2-stable202505
Note: the edk2-stable202505 release note mention a security fix.
This fix was already backported in Buildroot in a previous commit.
For that reason, this bump is not marked as securiy, and also
removes the backported patch and its associated _IGNORE_CVES entry.
Those versions include fixes when using gcc 15 (host and target).
This commit also updates the edk2-platforms and edk2-non-osi packages
with the last commit merged at the edk2 release date (2025-05-23).
In the case of edk2-platforms, the commit id used in this update
is few days later, to include a fix for the Arm Sgi575 platform.
Exact commit should have been [1] (to be exactly aligned to the edk2
tag date), but commit [2] is used instead. The package edk2-non-osi is
updated to commit [3].
Also, the SocioNext SynQuacer platforms (including the DeveloperBox)
were removed upstream in edk2-platforms commit [4]. This commit
reflect that change by removing those platforms choices and associated
runtime tests.
This commit has been runtime tested with tests using EDK2 package,
with commands:
support/testing/run-tests \
-d dl -o output_folder \
tests.boot.test_edk2 \
tests.boot.test_grub.TestGrubAArch64EFI \
tests.boot.test_grub.TestGrubi386EFI \
tests.boot.test_grub.TestGrubRiscV64EFI \
tests.boot.test_grub.TestGrubX8664EFI \
tests.fs.test_iso9660.TestIso9660Grub2EFI \
tests.fs.test_iso9660.TestIso9660Grub2Hybrid \
tests.package.test_fwts
It has also been runtime tested (by booting in qemu) with defconfigs
using EDK2 package:
qemu_aarch64_sbsa_defconfig
qemu_riscv64_virt_efi_defconfig
[1] 2bfe3fa99e
[2] 92f7d69e8a
[3] ea2040c2d4
[4] aaba5807f1
Cc: Dick Olsson <hi@senzilla.io>
Cc: Romain Naour <romain.naour@smile.fr>
Cc: Vincent Stehlé <vincent.stehle@arm.com>
Tested-by: Vincent Stehlé <vincent.stehle@arm.com>
Reviewed-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
gnu-efi fails to build if TOPDIR is exported in the environment since the
move to version 3.0.18 in commit 9efeb7e914 ("package/gnu-efi: bump to
version 3.0.18").
The reason is the change in TOPDIR logic introduced by upstream commit
31913f8489 ("Make: make TOPDIR actually work and get rid of unused CDIR"):
31913f8489
export TOPDIR=foo; make gnu-efi
...
/path/to/buildroot/output-gnuefi/host/bin/aarch64-linux-ld: cannot find
/path/to/buildroot/output-gnuefi/build/gnu-efi-4.0.0//apps/../aarch64/gnuefi/crt0-efi-aarch64.o:
No such file or director
make[2]: *** [Makefile:89: apps] Error 2
make[1]: *** [package/pkg-generic.mk:273: /path/to/buildroot/output-gnuefi/build/gnu-efi-4.0.0/.stamp_built] Error 2
make: *** [Makefile:23: _all] Error 2
As a workaround, unexport TOPDIR like we do for other sensitive environment
variables.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The list of environment variables to unexport has grown organically over the
years and is no longer sorted. Sort it alphabetically for clarity.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The current homepage URL leads to an HTTP 404 error.
Fix it by using the homepage URL currently mentioned in mupdf's git
repository.
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Following the bump of systemd to 257.5 in commit
7d8d48cd2b, the installation of
systemd-boot fails with:
/usr/bin/install -D -m 0644 /home/thomas/projets/buildroot/outputs/3/build/systemd-257.5/buildroot-build/src/boot/efi/systemd-bootx64.efi /home/thomas/projets/buildroot/outputs/3/images/efi-part/EFI/BOOT/bootx64.efi
/usr/bin/install: cannot stat '/home/thomas/projets/buildroot/outputs/3/build/systemd-257.5/buildroot-build/src/boot/efi/systemd-bootx64.efi': No such file or directory
Indeed, the systemd-bootx64.efi binary is no longer produced in
buildroot-build/src/boot/efi/, but in buildroot-build/src/boot/.
No autobuilder failures have been found corresponding to this issue,
but it can be reproduced with:
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_INIT_SYSTEMD=y
BR2_SYSTEM_BIN_SH_NONE=y
BR2_SYSTEM_DEFAULT_PATH="/bin:/sbin:/usr/bin:/usr/sbin"
# BR2_PACKAGE_BUSYBOX is not set
BR2_PACKAGE_SYSTEMD_BOOT=y
# BR2_TARGET_ROOTFS_TAR is not set
Most likely this was caused by upstream commit
97318131fd06a5bc35454da81dcbbc84f16d9940, even though we didn't check
if this commit was really the culprit.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
