The CPE 'iputils_project:iputils' has been deprecated in favour of
'iputils:iputils'.
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 4ac3c1de56)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
We dropped support for python2 a while back in [1], as such we
can remove the python six module which was only needed for
backwards comaptibility with python2.
[1] 2743ce00ca
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
[Julien: add commit ref removing python2 support]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 53eb75ef53)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Since boot-wrapper-aarch64 introduction in commit [1]
"boot-wrapper-aarch64: new package", the package never received a hash
file. This commit adds it, including the source archive and license
hashes.
[1] 7689b72e00
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 4b14018a38)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Buildroot commit [1] ("package: replace git:// URLs with https://
URLs where possible") switched _SITE URL from git to https, but did
not updated the package homepage in Config.in.
This commit updates it to match the package _SITE URL.
[1] 6626bf7c5f
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit afff65c340)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
policycoreutils uses getpass(), which with musl is only defined with
some feature macro defined, such as _GNU_SOURCE. So let's pick-up an
upstream fix to address this issue.
There are no autobuilder failures, the issue was most likely hidden by
other failures with musl affecting the SELinux stack.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit fc472cc8c7)
[thomas: fix patch]
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The build of libsemanage on musl configurations fails with:
direct_api.c: In function 'semanage_direct_install_file':
direct_api.c:1746:20: error: implicit declaration of function 'basename' [-Wimplicit-function-declaration]
1746 | filename = basename(path);
| ^~~~~~~~
This fails to build even with a GCC 14.x toolchain, even with
libsemanage 3.7, which is the version we have in our LTS branch.
Let's backport an upstream patch fixing this issue.
Fixes:
https://autobuild.buildroot.net/results/913852e35c925888ced37e15be3731b9d3963019/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 79031b79c2)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Luvi 2.14.0 fails to build with GCC 14.x for several reasons due to
too old lua-openssl 0.8.2-0 submodule:
TestLuvi/build/luvi-2.14.0/deps/lua-openssl/src/ocsp.c: In function 'openssl_ocsp_request_read':
TestLuvi/build/luvi-2.14.0/deps/lua-openssl/src/ocsp.c:124:29: error: passing argument 1 of 'PEM_ASN1_read_bio' from incompatible pointer type [-Wincompatible-pointer-types]
124 | OCSP_REQUEST *req = pem ? PEM_read_bio_OCSP_REQUEST(bio, NULL, NULL)
| ^~~~~~~~~~~~~~~~~~~~~~~~~
| |
| char * (*)()
Fixed in lua-openssl by [1].
TestLuvi/build/luvi-2.14.0/deps/lua-openssl/src/x509.c: In function 'openssl_push_general_name':
TestLuvi/build/luvi-2.14.0/deps/lua-openssl/src/x509.c:377:45: error: passing argument 2 of 'openssl_push_asn1type' from incompatible pointer type [-Wincompatible-pointer-types]
377 | openssl_push_asn1type(L, general_name->d.x400Address);
| ~~~~~~~~~~~~~~~^~~~~~~~~~~~
| |
| ASN1_STRING * {aka struct asn1_string_st *}
Fixed in lua-openssl by [2].
TestLuvi/build/luvi-2.14.0/deps/lua-openssl/src/openssl.c: In function 'luaclose_openssl':
TestLuvi/build/luvi-2.14.0/deps/lua-openssl/src/stdatomic.h:387:9: error: implicit declaration of function '__c11_atomic_fetch_sub'; did you mean '__atomic_fetch_sub'? [-Wimplicit-function-declaration]
387 | __c11_atomic_fetch_sub(object, operand, order)
Fixed in lua-openssl by [3].
Instead of fixing one by one each issues, update to the latest release
that include lua-openssl 0.9.0-0. Luvi v2.15.0 still have some GCC 14.x
issues, backport two additional patches.
Download luvi sources using git method since the release archive
no longer include the release version in its name [4].
Luvi switched to PCRE2 [5], update the optional dependency.
Update TestLuvi to select PCR2 package.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/11271124430 (TestLuvi)
[1] bfeedbe8c0
[2] e5b5420cc5
[3] cfcaa16d1a
[4] https://github.com/luvit/luvi/releases/download/v2.15.0/luvi-source.tar.gz
[5] https://github.com/luvit/luvi/releases/tag/v2.15.0
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 00317f0aff)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Fixes the following security issue:
- CVE-2025-58050: PCRE2: heap-buffer-overflow read in match_ref due to
missing boundary restoration in SCS
Compared to 10.45, this release has only a minimal code change to prevent a
read-past-the-end memory error, of arbitrary length. An attacker-controlled
regex pattern is required, and it cannot be triggered by providing crafted
subject (match) text. The (*ACCEPT) and (*scs:) pattern features must be
used together.
Release 10.44 and earlier are not affected.
https://github.com/PCRE2Project/pcre2/security/advisories/GHSA-c2gv-xgf5-5cc2https://www.cve.org/CVERecord?id=CVE-2025-58050
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
[Julien: add link to CVE in commit log]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 9fd06f212a)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The last mariadb version bump [1] added -DHAVE_SYSTEM_LIBFMT_EXITCODE=0
to workaround cross-compiling issue during libfmt cmake check.
But it actually requies at least cmake >= 3.30 to work.
Indeed, our docker image used by Gitlab-CI uses cmake 3.25.1 and
segfault while testing for libfmt.
-- Performing Test HAVE_SYSTEM_LIBFMT
/bin/bash: line 1: 163369 Segmentation fault
$ cmake --version
cmake version 3.25.1
Using the same TestPerlDBDmysql configuration locally with
cmake 3.30.8 installed build fine.
Looking at cmake cmTryRunCommand.cxx history from 3.30.x show that
several fixes about cross-compiling isses were applied to cmake 3.26.x
[2] probably solving the issue. Requires BR2_HOST_CMAKE_AT_LEAST_3_30
for now, since only cmake 3.30.8 installed locally was tested.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/11271124486 (TestPerlDBDmysql)
https://gitlab.com/buildroot.org/buildroot/-/jobs/11271124439 (TestMariaDB)
[1] 6cd8f95346 ("package/mariadb: bump version to 10.11.11")
[2] https://gitlab.kitware.com/cmake/cmake/-/commits/v3.30.9/Source/cmTryRunCommand.cxx?ref_type=tags
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit de9c0f971c)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Using /dev/null as file source because the package doesn't provide a default
systemv service configuration file.
Signed-off-by: Angelo Compagnucci <angelo.compagnucci@gmail.com>
[Julien: remove S43htpdate .checkpackageignore entry
to fix check-package error
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 1f2b459b56)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The symlink bin/lld -> $(GNU_TARGET_NAME)/bin/lld is broken inside a
SDK containing host-lld package. The symlink still points to the
location of lld inside the build's host folder instead of the location
of lld inside the SDK. In consequence GCC is not able to find lld
linker. Changing the symlink to be relative during host-lld
installation fixes the problem.
Signed-off-by: Victor Krawiec <victor.krawiec@arturia.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit 289dd6bd76)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Without systemd package/docker-engine requires another way to mount
/sys/fs/cgroup, so far provided by BR2_PACKAGE_CGROUPFS_MOUNT for
cgroup v1. Replace this with BR2_PACKAGE_CGROUPFS_V2_MOUNT for cgroup
v2 support. 5.2 is the minimum recommended version for cgroup v2
support according to the Docker documentation: "v4.15 or later (v5.2
or later is recommended)" [1].
Depending on the selected container runtime users may need to adjust
kernel configurations to enable options required by that runtime with
cgroup v2 (e.g. CONFIG_CGROUP_BPF for runc).
Propagate dependencies accordingly: The Docker btrfs filesystem driver
does not need a separate and lower minimum headers version,
package/mender-update-modules needs to apply the new "depends on".
[1] https://docs.docker.com/engine/containers/runmetrics/#running-docker-on-cgroup-v2
Signed-off-by: Fiona Klute (WIWA) <fiona.klute@gmx.de>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit b07b0bb456)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Since commit 947dbc92a2 the Bootlin
stable toolchain uses headers 5.4, which can lead to build outputs
incompatible with older kernels. Update to the latest 5.4 kernel to
avoid this. The kernel config is updated according to the requirements
of current Docker, runc, and crun.
Additionally switch the CPU of the test VM to Haswell, to avoid
dockerd failing to start with a "This program can only be run on AMD64
processors with v3 microarchitecture support" error.
Signed-off-by: Fiona Klute (WIWA) <fiona.klute@gmx.de>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit efe00fb3fb)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
php-lua fails to build in buildroot 2025.08-rc3 on the following error:
in file included from [...]/usr/include/php/Zend/zend.h:32,
from [...]/usr/include/php/main/php.h:31,
from [...]/build/php-lua-2.0.7/lua.c:24:
[...]/build/php-lua-2.0.7/lua.c: In function ‘php_lua_write_property’:
[...]/build/php-lua-2.0.7/lua.c:247:37:
error: ‘val’ undeclared (first use in this function); did you mean
‘zval’?
247 | lua_pushlstring(L, ZSTR_VAL(val), ZSTR_LEN(val));
| ^~~
[...]/usr/include/php/Zend/zend_string.h:66:26:
note: in definition of macro ‘ZSTR_VAL’
66 | #define ZSTR_VAL(zstr) (zstr)->val
| ^~~~
[...]/build/php-lua-2.0.7/lua.c:247:37:
note: each undeclared identifier is reported only once for each function
it appears in
247 | lua_pushlstring(L, ZSTR_VAL(val), ZSTR_LEN(val));
| ^~~
[...]/usr/include/php/Zend/zend_string.h:66:26:
note: in definition of macro ‘ZSTR_VAL’
66 | #define ZSTR_VAL(zstr) (zstr)->val
| ^~~~
make[2]: *** [Makefile:214: lua.lo] Error 1
The issue triggers only if lua interpreter version is lower than 5.2. In
this case, php_lua_write_property calls ZSTR_VAL on the wrong variable.
Fix php-lua build by calling ZSTR_VAL on the correct variable.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/11271124501 (TestPhpLuaLuajit)
Suggested-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
[Romain: add link to failing TestPhpLuaLuajit]
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit a1daf153bf)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
On both Buildroot 2025.02.x and master branch, php-lua build fails on
the following error:
lua.c:862:44: error: assignment to 'zend_object_write_property_t' {aka
'struct _zval_struct * (*)(struct _zend_object *, struct _zend_string *,
struct _zval_struct *, void **)'} from incompatible pointer type 'void
(*)(zval *, zval *, zval *, void **)' {aka 'void (*)(struct _zval_struct
*, struct _zval_struct *, struct _zval_struct *, void **)'}
[-Wincompatible-pointer-types]
862 | lua_object_handlers.write_property =
php_lua_write_property;
| ^
lua.c:863:44: error: assignment to 'zend_object_read_property_t' {aka
'struct _zval_struct * (*)(struct _zend_object *, struct _zend_string *,
int, void **, struct _zval_struct *)'} from incompatible pointer type
'zval * (*)(zval *, zval *, int, void **, zval *)' {aka 'struct
_zval_struct * (*)(struct _zval_struct *, struct _zval_struct *, int,
void **, struct _zval_struct *)'} [-Wincompatible-pointer-types]
863 | lua_object_handlers.read_property =
php_lua_read_property;
| ^
make[2]: *** [Makefile:214: lua.lo] Error 1
The error can be reproduced with the following minimal defconfig:
BR2_arm=y
BR2_cortex_a9=y
BR2_ARM_ENABLE_NEON=y
BR2_ARM_ENABLE_VFP=y
BR2_ARM_FPU_NEON=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_PACKAGE_LUA=y
BR2_PACKAGE_PHP=y
BR2_PACKAGE_PHP_LUA=y
This build failure is the result of two events/conditions:
- the update to PHP8 has changed the prototype for
zend_object_read_property_t (see [1]). But at this time, php-lua just
generated a new warning (-Wincompatible-pointer-types)
- using bootlin bleeding-edge toolchain brings in GCC14, which now turns
this warning into a systematic error (see [2])
This issue is still present on the upstream repository, but it has been
fixed on one of its forks. Bring the relevant patch from the fork to
allow building php-lua.
[1] https://github.com/php/php-src/commit/91ef4124e56
[2] https://gcc.gnu.org/gcc-14/porting_to.html#incompatible-pointer-types
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
[Romain: update Upstream link]
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit b4d8147a95)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The git.ti.com cgit server continues to be plagued with reliability
issues which are reportedly from heavy bot traffic. To combat this the
system administrators have removed the archived downloads feature from
this server.
Switch to TI's Github mirror so new downloads continue to be possible.
Signed-off-by: Bryan Brattlof <bb@ti.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit ebf0131e3e)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Since the bump to Python 3.13.2 in commit
d63e207eb8, there is a runtime assertion
in Python when the toolchain doesn't support time64 [1]. The only such
toolchain is one with uClibc and linux headers < 5.1.
Encoding this dependency in Config.in was deemed to complicated (cfr.
commit ffd0028031).
Instead, do a build-time check of the same condition. The check itself
is a bit complicated, but it is localized to python3.mk and doesn't need
to be propagated to all reverse dependencies.
Testing such a corner case toolchain is a bit complicated. It can be
done with the following configuration.
BR2_arm=y
BR2_cortex_a9=y
BR2_ARM_ENABLE_VFP=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y
BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y
BR2_TOOLCHAIN_EXTERNAL_URL="http://toolchains.bootlin.com/downloads/releases/toolchains/armv7-eabihf/tarballs/armv7-eabihf--uclibc--stable-2018.02-1.tar.bz2"
BR2_TOOLCHAIN_EXTERNAL_GCC_6=y
BR2_TOOLCHAIN_EXTERNAL_HEADERS_4_1=y
BR2_TOOLCHAIN_EXTERNAL_LOCALE=y
BR2_TOOLCHAIN_EXTERNAL_CXX=y
BR2_PACKAGE_PYTHON3=y
It needs to be built in an environment that has libmpfr.so.4 installed
as the pre-built toolchain from that era did not include it. An easy
way to achieve this is to build this configuration under an old
Buildroot Docker container:
IMAGE=buildroot/base:20180205.0730 ./utils/docker-run make python3
With a build-time check, the autobuilders could get build failures when
generating such a config. However, the autobuilders cannot use a
toolchain with this configuration (they only use more recent
toolchains). Therefore, no update to genrandconfig is needed.
[1] https://gitlab.com/buildroot.org/buildroot/-/issues/95#note_2348479811
Cc: Vincent Fazio <vfazio@xes-inc.com>
Cc: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit b45400dad4)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Since Buildroot commit [1] "update to Bootlin toolchains 2025.08-1",
the TestMicroPython segfault when testing if micropython can return a
non-zero exit code.
micropython -c "import sys ; sys.exit(123)"
This issue is related to the gcc version used to build micropython
(gcc 14 or newer). Using gcc 13 (like Bootlin toolchain 2024.05-1
previously used) micropython run without issue.
The issue has been reported upstream [2] and fixed in newer micropython
releases [3]. For now, apply a temporary workaround (suggested in the
bug report) using -DMICROPY_NLR_SETJMP=1 only for gcc 14 or newer.
MICROPY_NLR_SETJMP avoid the architecture specific implementation of
nlr_push.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/11176774762 (TestMicroPython)
[1] 947dbc92a2
[2] https://github.com/micropython/micropython/issues/14115
[3] 35f3f0a87d
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 50bc5aa17b)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
TestRelroPartial is broken since the last checksec update to 2.7.1 [1]
(Buildroot 2024.08) due to a relro check fix [2] that doesn't work for
powerpc architecture where .got.plt doesn't exist for some reasons
(that's why the expected result "full" is replaced by "Partial").
From [3]:
if ${readelf} -d "${1}/exe" 2> /dev/null | grep -q 'BIND_NOW' || ! ${readelf} -l "${1}/exe" 2> /dev/null | grep -q '\.got\.plt'; then
echo_message '\033[32mFull RELRO \033[m ' 'Full RELRO,' ' relro="full"' '"relro":"full",'
else
echo_message '\033[33mPartial RELRO\033[m ' 'Partial RELRO,' ' relro="partial"' '"relro":"partial",'
checksec tool is problably tested upstream on more common architectures
like x86_64 or aarch64 than powerpc64 e5500. This may explain why
checksec broke on powerpc64 e5500 target.
Also, the Booltin powerpc64-e5500--glibc--stable-2018.02-2 toolchain
used by test_hardening tests was not updated since the hardening tests
were introduced back in 2018.11 release.
So, switch to the current Bootling aarch64 stable toolchain
(currently Bootlin aarch64 glibc stable 2025.08-1).
Checked that all 6 hardening tests pass with this new toolchain:
tests.core.test_hardening.TestFortifyConserv
tests.core.test_hardening.TestFortifyNone
tests.core.test_hardening.TestRelro
tests.core.test_hardening.TestRelroPartial
tests.core.test_hardening.TestSspNone
tests.core.test_hardening.TestSspStrong
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/11176773995 (TestRelroPartial)
[1] 6150564974
[2] 1c80e39c49
[3] 1c80e39c49 (diff-9e8d1b28dfaf1c704560ac51a5613b70d70de2dcd84e87b9fa20f28811e6484aL1491)
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 10e289e0a9)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
In the process of bumping Linux kernel 6.12.10 to 6.12.40, the size of the
default Linux kernel Image file for versal products is increasing from 23.4M
to 26.9M. This is leaving limited free space in the vfat partition meaning
users may unknowingly exceed the 32M size by just adding Linux kernel configs.
To avoid potential problems, this patch doubles the size of the vfat partition
to 64M, which should be plenty of space for any configuration.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit dfed1003d9)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
On the autobuilder the mariadb package fails to build when the
BR2_PACKAGE_LIBOPENSSL_ENABLE_RMD160 variable is not set.
See the following autobuilder error:
```
/workdir/instance-0/output-1/build/mariadb-10.11.11/libmariadb/libmariadb/secure/openssl_crypt.c: In function 'ma_hash_get_algorithm':
/workdir/instance-0/output-1/build/mariadb-10.11.11/libmariadb/libmariadb/secure/openssl_crypt.c:40:12: error: implicit declaration of function 'EVP_ripemd160'; did you mean 'LN_ripemd160'? [-Wimplicit-function-declaration]
40 | return EVP_ripemd160();
| ^~~~~~~~~~~~~
| LN_ripemd160
/workdir/instance-0/output-1/build/mariadb-10.11.11/libmariadb/libmariadb/secure/openssl_crypt.c:40:12: error: returning 'int' from a function with return type 'const EVP_MD *' {aka 'const struct evp_md_st *'} makes pointer from integer without a cast [-Wint-conversion]
40 | return EVP_ripemd160();
| ^~~~~~~~~~~~~~~
```
This error can be reproduced with the following config:
```
cat <<EOF >.config
BR2_arm=y
BR2_cortex_a7=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_PACKAGE_LIBOPENSSL=y
# BR2_PACKAGE_LIBOPENSSL_ENABLE_RMD160 is not set
BR2_PACKAGE_MARIADB=y
EOF
make olddefconfig
make mariadb
```
This patch adds a requirement to the RMD160 crypto for the MariaDB
package.
Fixes: https://autobuild.buildroot.org/results/f2b/f2b749cb7019856c5434c27987e8bfb2dc179cda
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 5ce1d6f017)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
