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>
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>
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>
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>
iozone releases 3.507 and 3.508 seems to be only build fixes releases
for latest GCC compiler version but since there is no public vcs
it's not easy to review the history between releases and backport
any patches.
Based on the changelog from [1]:
Revision 3.507
Fix GCC compile warnings.
Revision 3.508
Put an end to the (&*% stupid GCC breaking builds for no valid reason.
So bump to the latest 508 release.
Rebase 0001-Add-new-targets-for-iozone.patch
Rebase 0002-fix-build-without-aio.patch and convert to git format
The TestIozone build issue is not yet fixed by the version bump [2].
[1] https://www.iozone.org/src/current/Changes.txt
[2] https://gitlab.com/buildroot.org/buildroot/-/jobs/11176774405
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Commit 759a08633e ("package/mbpfan: fix build on musl / uclibc-ng") added a
patch for musl / uclibc-ng, but the upstream patch did not correctly apply
to the 2.4.0 release, breaking the build.
Fix that. In the mean time the patch has been applied upstream, so add a
reference to the upstream commit.
Fixes:
https://autobuild.buildroot.net/results/785be6231c1edc4e5461ce083a3d65fd27fc5843/
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The memory leak patch is included with the Linux 6.12.40 release tag, so it no
longer needs to be applied to these defconfigs:
9691533f6e
Also, since all Xilinx defconfigs have been bumped to Linux 6.12.40 with this
patch, the Linux 6.12.10 (2025.1) hash can be removed along with the
Linux 6.12.10 memory leak patch.
This patch has been run tested on the versal vek280 evaluation board.
This patch has been run tested on the versal vck190 evaluation board.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
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>
Bat pulls in the onig crate (version 6.4.0) through syntect with the
default "regex-onig" feature. This crate depends on the Oniguruma C
library (via onig_sys), which fails to build with GCC 15 due to C23
keyword conflicts. Newer versions of onig fix this issue, but bat
cannot directly update the onig version because it is pinned by syntect.
To resolve the build failure, apply a patch that replaces the
"regex-onig" feature with "regex-fancy" in bat's minimal-application
feature set. This switches bat to use the pure-Rust fancy-regex engine
instead of Oniguruma, avoiding the problematic onig_sys dependency.
Fixes:
https://autobuild.buildroot.net/results/ecc/ecc3b0c83e691e9a8ed5c7ff9d0a92ee06409f20
Signed-off-by: El Mehdi YOUNES <elmehdi.younes@smile.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
openal 1.22.0 does not build with GCC 15.x, but the backport of the
fixes to 1.22.0 turns out to be too complicated, so let's bump to
1.24.3 instead.
Since 1.24.3 uses C++17, and after testing with GCC 7.x, then GCC 8.x
then GCC 9.x, we found out that GCC 9.x at least is
necessary. Therefore, reverse dependencies are updated accordingly.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
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>
The build of avrdude sometimes fails with:
avrdude: installs files in /home/autobuild/autobuild/instance-1/output-1/target//home/autobuild/autobuild/instance-1/output-1
This is due to an issue in the installation logic for the Python
code. However, our avrdude.mk doesn't explicitly support building
avrdude's Python support, so it's really only by luck (or lack
thereof) that sometimes host-swig and python3 end up built before
avrdude, causing avrdude to build its Python support, which installs
at the wrong location.
In order to address this, we add a small patch, submitted upstream,
that allows to explicitly disable Python support, which we then use in
avrdude.mk.
The actual Python issue can be investigated at a later point if
someone needs it. But in any case, being able to explicitly disable
Python support if not needed is useful.
Fixes:
http://autobuild.buildroot.net/results/f18d47289d8b4dee768275a468c25b4f4399cf8c/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes https://autobuild.buildroot.net/results/f32ae62961aac7e8344f4be109040e7de2eb415e/
The openssl logic in ecryptfs uses the openssl engines API, which is always
available in libressl, but only available in libopenssl when
BR2_PACKAGE_LIBOPENSSL_ENGINES is enabled, leading to build failures when it
is not:
ecryptfs_key_mod_openssl.c: In function 'ecryptfs_openssl_read_key':
ecryptfs_key_mod_openssl.c:305:9: error: implicit declaration of function 'ENGINE_load_builtin_engines' [-Wimplicit-function-declaration]
305 | ENGINE_load_builtin_engines();
Fix it by only passing --enable-openssl if libressl or (libopenssl + engines
support) is enabled.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes https://autobuild.buildroot.net/results/9d4e2f156d76e2acc83e3a25adb5e5cf0705e7c6/
configure:781: checking whether the C compiler (/home/buildroot/instance-0/output-1/host/bin/armeb-buildroot-linux-gnueabi-gcc -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Og -g0 -D_FORTIFY_SOURCE=1 ) works
configure:797: /home/buildroot/instance-0/output-1/host/bin/armeb-buildroot-linux-gnueabi-gcc -o conftest -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Og -g0 -D_FORTIFY_SOURCE=1 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 conftest.c 1>&5
configure:794:1: error: return type defaults to 'int' [-Wimplicit-int]
794 | main(){return(0);}
| ^~~~
configure: failed program was:
#line 792 "configure"
#include "confdefs.h"
main(){return(0);}
Wipe uses a very old configure script where the compile checks are missing
the return type on main(), breaking the configure step with >= gcc-15.
As a workaround, use AUTORECONF to regenerate the configure script.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This is a major version bump, because it could break user code that depends
on the (wrong) previous logic fixed by the new release
See the release notes:
- https://github.com/corydolphin/flask-cors/releases/tag/6.0.0
- https://github.com/corydolphin/flask-cors/releases/tag/6.0.1
This fixes the following vulnerabilities:
- CVE-2024-6839:
corydolphin/flask-cors version 4.0.1 contains an improper regex path
matching vulnerability. The plugin prioritizes longer regex patterns
over more specific ones when matching paths, which can lead to less
restrictive CORS policies being applied to sensitive endpoints. This
mismatch in regex pattern priority allows unauthorized cross-origin
access to sensitive data or functionality, potentially exposing
confidential information and increasing the risk of unauthorized
actions by malicious actors.
https://www.cve.org/CVERecord?id=CVE-2024-6839
- CVE-2024-6844:
A vulnerability in corydolphin/flask-cors version 4.0.1 allows for
inconsistent CORS matching due to the handling of the '+' character in
URL paths. The request.path is passed through the unquote_plus
function, which converts the '+' character to a space ' '. This
behavior leads to incorrect path normalization, causing potential
mismatches in CORS configuration. As a result, endpoints may not be
matched correctly to their CORS settings, leading to unexpected CORS
policy application. This can cause unauthorized cross-origin access or
block valid requests, creating security vulnerabilities and usability
issues.
https://www.cve.org/CVERecord?id=CVE-2024-6844
- CVE-2024-6866:
corydolphin/flask-cors version 4.01 contains a vulnerability where the
request path matching is case-insensitive due to the use of the
`try_match` function, which is originally intended for matching hosts.
This results in a mismatch because paths in URLs are case-sensitive,
but the regex matching treats them as case-insensitive. This
misconfiguration can lead to significant security vulnerabilities,
allowing unauthorized origins to access paths meant to be restricted,
resulting in data exposure and potential data leaks.
https://www.cve.org/CVERecord?id=CVE-2024-6866
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This fixes the following vulnerabilities:
- CVE-2023-5341:
A heap use-after-free flaw was found in coders/bmp.c in ImageMagick.
https://www.cve.org/CVERecord?id=CVE-2023-5341
- CVE-2025-55004:
ImageMagick is free and open-source software used for editing and
manipulating digital images. Prior to version 7.1.2-1, ImageMagick is
vulnerable to heap-buffer overflow read around the handling of images
with separate alpha channels when performing image magnification in
ReadOneMNGIMage. This can likely be used to leak subsequent memory
contents into the output image. This issue has been patched in version
7.1.2-1.
https://www.cve.org/CVERecord?id=CVE-2025-55004
- CVE-2025-55005:
ImageMagick is free and open-source software used for editing and
manipulating digital images. Prior to version 7.1.2-1, when preparing
to transform from Log to sRGB colorspaces, the logmap construction
fails to handle cases where the reference-black or reference-white
value is larger than 1024. This leads to corrupting memory beyond the
end of the allocated logmap buffer. This issue has been patched in
version 7.1.2-1.
https://www.cve.org/CVERecord?id=CVE-2025-55005
- CVE-2025-55160:
ImageMagick is free and open-source software used for editing and
manipulating digital images. Prior to versions 6.9.13-27 and 7.1.2-1,
there is undefined behavior (function-type-mismatch) in splay tree
cloning callback. This results in a deterministic abort under UBSan
(DoS in sanitizer builds), with no crash in a non-sanitized build.
This issue has been patched in versions 6.9.13-27 and 7.1.2-1.
https://www.cve.org/CVERecord?id=CVE-2025-55160
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This fixes the following vulnerability:
- CVE-2025-6965:
There exists a vulnerability in SQLite versions before 3.50.2 where
the number of aggregate terms could exceed the number of columns
available. This could lead to a memory corruption issue. We recommend
upgrading to version 3.50.2 or above.
https://www.cve.org/CVERecord?id=CVE-2025-6965
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Even though this is not mentioned in the release notes:
- https://github.com/containers/netavark/releases/tag/v1.16.0
- https://github.com/containers/netavark/releases/tag/v1.16.1
According to https://bugzilla.redhat.com/show_bug.cgi?id=2383941,
the fix for the CVE has been merged upstream, and is in netavark
since v1.16.0.
This fixes the following vulnerability:
- CVE-2025-8283:
A vulnerability was found in the netavark package, a network stack for
containers used with Podman. Due to dns.podman search domain being
removed, netavark may return external servers if a valid A/AAAA record
is sent as a response. When creating a container with a given name,
this name will be used as the hostname for the container itself, as
the podman's search domain is not added anymore the container is using
the host's resolv.conf, and the DNS resolver will try to look into the
search domains contained on it. If one of the domains contain a name
with the same hostname as the running container, the connection will
forward to unexpected external servers.
https://www.cve.org/CVERecord?id=CVE-2025-8283
Also bump package/aardvark-dns in the same lockstep, as advised in
the packages .mk version comments.
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
GCC-15 defaults to C23, which changes the meaning of an empty parameter
list:
https://gcc.gnu.org/gcc-15/porting_to.html#c23-fn-decls-without-parameters
Leading to a build failure:
tsserve.c: In function ‘set_child_exit_handler’:
tsserve.c:2988:21: error: assignment to ‘__sighandler_t’ {aka ‘void (*)(int)’} from incompatible pointer type ‘void (*)(void)’ [-Wincompatible-pointer-types]
2988 | action.sa_handler = on_child_exit;
Add a patch from an upstream PR to fix that.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit 0d643a8636 which removed the
BR2_PACKAGE_LIGHTTPD_LIBEV symbol was originally meant for next and
therefore introduced the "Legacy options removed in 2025.11" comment.
However, in the end it was still applied to master for 2025.08, so the
legacy symbol was incorrectly placed.
Fix that.
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
The github repo was deleted and moved to codeberg, so use that instead:
https://lwn.net/Articles/926101/
It is unclear if the auto generated tarballs from codeberg are reproducible,
so instead fetch through git.
[Peter: set _CPE_ID_VERSION to the correct value]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
