The mdnsd runtime test can randomly fail on slow runners.
It's hard to reproduce locally (only one failure after a few attempts)
but we can reproduce it easily by removing the while loop entirely.
It turns out that mdnsd is started by S50mdnsd before the
emulator.login() change the system date:
[BRTEST# date -s @1788032864
Sat Aug 29 19:47:44 UTC 2026
Since the minimal rootfs.cpio generated for TestMdnsd doesn't have any
ntp client installed, it start with "January 1, 1970".
The date change may cause some issue to the mdnsd daemon which blocks
any response from mquery command.
When the problem occurs, "mquery -T _http._tcp" reply is empty:
# mquery -T _http._tcp
Querying _http._tcp.local. for PTR (12) ... press Ctrl-C to stop
To workaround the issue, restart mdnsd manually.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/16185948555
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 45636d67c9)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Dracut-internal executables were linked against system libraries,
instead of Buildroot host packages. For example:
$ ldd host/lib/dracut/dracut-install
linux-vdso.so.1 (0x00007f578cf06000)
libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 (0x00007f578cccd000)
libkmod.so.2 => /usr/lib/x86_64-linux-gnu/libkmod.so.2 (0x00007f578ccb1000)
/lib64/ld-linux-x86-64.so.2 (0x00007f578cf08000)
libcrypto.so.3 => /usr/lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007f578c600000)
libz.so.1 => /usr/lib/x86_64-linux-gnu/libz.so.1 (0x00007f578cc92000)
libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 (0x00007f578c536000)
The reason is that Dracut is not a "real" autoconf package, and the
hand-written ./configure script does not preserve LDFLAGS for
make. Pass the environment variables directly to fix this.
Signed-off-by: Fiona Klute (othermo GmbH) <fiona.klute@gmx.de>
[Julien: add comment in dracut.mk]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 45acb281ca)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
examples/vm_power_manager/meson.build in DPDK detects the presence of
libvirt:
opt_dep = cc.find_library('virt', required : false)
and then builds some examples or not depending on the availability of
libvirt. Let's make this optional dependency explicit in dpdk.mk, even
if there's no explicit enable/disable option for it.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 55a7ece9e5)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
When libvirt is present before DPDK is built, some additional examples
are compiled. One of them fails to build due to a missing <stdlib.h>
include. Let's import a patch from OpenSuse, that we have submitted
upstream, to fix this issue.
We couldn't find any autobuilder failure for this issue, but the
following defconfig allows to reproduce the failure:
BR2_aarch64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_AARCH64_GLIBC_STABLE=y
BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV=y
BR2_PACKAGE_DPDK=y
BR2_PACKAGE_DPDK_EXAMPLES=y
BR2_PACKAGE_LIBVIRT=y
The problem exists since DPDK v19.11, so it has been in Buildroot
since DPDK was introduced in commit
d17d1b6bde.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit db3d0d44ac)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Buildroot commit [1] (package/perl: fix build issue with musl)
introduced a patch that is meant to be applied on top of perl-cross,
which is extracted on top of perl only in the target variant.
Since the patch was introduced as a normal package patch, the Buildroot
infra is trying to always apply it, even for the host package variant.
Since perl-cross is not extracted for the host variant, some patched
files are missing. In that case, the host-perl is failing with error:
>>> host-perl 5.42.3 Patching
Applying 0001-configure-keep-_GNU_SOURCE-in-build-flags.patch using patch:
can't find file to patch at input line 46
This commit fixes the issue by moving the package patch in a dedicated
"perl-cross" subdirectory, to make sure it will no longer be applied by
the infra. We apply the patch only for the target package variant using
a _POST_PATCH_HOOKS hook.
Fixes:
- [1]
- https://gitlab.com/buildroot.org/buildroot/-/jobs/16185948610 (TestPerlXMLLibXML)
- ...and few other tests requiring host-perl
[1] d950fff290
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 8dea6e7c08)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
When OpenSSL is enabled, if DES support is enabled, OpenSSH uses
DES_crypt. However, without OpenSSL or its DES support, there is no
available crypt() implementation for OpenSSH libopenbsd-compat xcrypt()
function, resulting in the following error:
.../host/bin/i686-buildroot-linux-gnu-gcc -o sshd-auth sshd-auth.o
auth2-methods.o auth-rhosts.o auth-passwd.o sshpty.o sshlogin.o
servconf.o serverloop.o auth.o auth2.o auth-options.o session.o
auth2-chall.o groupaccess.o auth-bsdauth.o auth2-hostbased.o
auth2-kbdint.o auth2-none.o auth2-passwd.o auth2-pubkey.o
auth2-pubkeyfile.o auth2-gss.o gss-serv.o gss-serv-krb5.o
monitor_wrap.o auth-krb5.o audit.o audit-bsm.o audit-linux.o
platform.o loginrec.o auth-pam.o auth-shadow.o auth-sia.o
sandbox-null.o sandbox-rlimit.o sandbox-darwin.o
sandbox-seccomp-filter.o sandbox-capsicum.o sandbox-solaris.o
sftp-server.o sftp-common.o uidswap.o ssh-pkcs11-client.o
ssh-sk-client.o -L. -Lopenbsd-compat/ -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g0
-D_FORTIFY_SOURCE=1 -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack
-fstack-protector-strong -pie -lssh -lopenbsd-compat
-L.../host/bin/../i686-buildroot-linux-gnu/sysroot/usr/lib
-lssl -lcrypto -lcrypto -lz
.../host/lib/gcc/i686-buildroot-linux-gnu/15.3.0/../../../../
i686-buildroot-linux-gnu/bin/ld:
openbsd-compat//libopenbsd-compat.a(xcrypt.o): in function `xcrypt':
xcrypt.c:(.text+0x51): undefined reference to `crypt'
.../host/lib/gcc/i686-buildroot-linux-gnu/15.3.0/../../../../
i686-buildroot-linux-gnu/bin/ld:
openbsd-compat//libopenbsd-compat.a(xcrypt.o): in function `xcrypt':
xcrypt.c:(.text+0x51): undefined reference to `crypt' collect2: error:
ld returned 1 exit status make[2]: *** [Makefile:233: sshd-auth] Error
1 make[2]: *** Waiting for unfinished jobs.... collect2: error: ld
returned 1 exit status make[2]: *** [Makefile:230: sshd-session] Error
1 make[1]: *** [package/pkg-generic.mk:273:
.../build/openssh-10.4p1/.stamp_built]
Error 2 make: *** [Makefile:83: _all] Error 2
This commit enables BR2_PACKAGE_LIBXCRYPT with OpenSSH as long as
glibc is used. Since "sshd-auth" is compiled regardless of
BR2_PACKAGE_OPENSSH_SERVER, we need to enable it with BR2_PACKAGE_OPENSSH.
Signed-off-by: Jimmy Durand Wesolowski <jimmy.wesolowski@mobileye.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 913512e302)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
See the release note:
- https://thekelleys.org.uk/dnsmasq/CHANGELOG
Backport the dnsmasq 2.93 version bump to the 2025.02.x maintenance
branch. It is already present in master in [1].
This fixes:
- CVE-2026-12725, a heap buffer overflow in log_query()
- CVE-2026-12969, an out-of-bounds read in find_soa()
[1] 374d0a02e4 package/dnsmasq: bump version to 2.93
Signed-off-by: Stefan Müller <stefan.mueller@rey-technology.com>
(alternative to commit 374d0a02e4)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Commit [1] bumped glibc but also introduced two consecutive empty lines
which cause check-package to fail.
This commit fix this by removing an empty line.
[1] 82eff78dea package/{glibc, localedef}: security bump to v2.41-159
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
patchwork.buildroot.org used to be a redirect to patchwork.ozlabs.org,
but we are now running our own instance, so let's adjust the links in
the website accordingly.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 2eefcb245f)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
patchwork.buildroot.org used to be a redirect to patchwork.ozlabs.org,
but we are now running our own instance, so let's adjust the links in
the manual accordingly.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 2d7d9d8200)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
This fixes the following vulnerability:
- CVE-2026-10846:
NLnet Labs ldns 1.2.0 up to and including versions 1.9.0, when used in
applications as (stub) resolver over UDP, lacks matching the query
destination address and port with the response source address and
port. Furthermore not the query ID, neither the question of the query
is matched with that of the response. This makes applications, that
use ldns for (stub) resolver functionality over UDP, vulnerable for
off-path poisoning attacks. The drill tool, which is shipped with
ldns, suffers from this vulnerability.
https://www.cve.org/CVERecord?id=CVE-2026-10846https://www.nlnetlabs.nl/downloads/ldns/CVE-2026-10846.txt
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
When BR2_PACKAGE_OPENCV4_WITH_WEBP=y we need to enable mux and demux
support in webp, otherwise the build of OpenCV fails as follows:
CMake Error: The following variables are used in this project,
but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly
in the CMake files:
WEBP_DEMUX_LIBRARY
linked by target "opencv_imgcodecs"
in directory [...]/build/opencv4-4.13.0/modules/imgcodecs
WEBP_MUX_LIBRARY
linked by target "opencv_imgcodecs"
in directory [...]/build/opencv4-4.13.0/modules/imgcodecs
The issue already exists in 2025.02.x.
Fixes:
https://autobuild.buildroot.net/results/d3e0446a87d32469267e241866c4224143170f31/
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit e1ec936cf7)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Even though it's only documentation, the form of the names of the
post-image.sh and post-build.sh scripts should be consistent with the
names of those scripts used in the code base, using hyphen, not
underscore.
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit c529a2c286)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
host-erlang build can fail with the following error:
make[5]: Nothing to be done for 'opt'.
MAKE opt
CC ../priv/bin/x86_64-pc-linux-gnu/odbcserver
/usr/bin/ld: ../priv/obj/x86_64-pc-linux-gnu/odbcserver.o: in function `encode_column_dyn':
odbcserver.c:(.text+0x6b4): undefined reference to `ei_x_encode_tuple_header'
/usr/bin/ld: odbcserver.c:(.text+0x6c2): undefined reference to `ei_x_encode_tuple_header'
/usr/bin/ld: odbcserver.c:(.text+0x6d4): undefined reference to `ei_x_encode_ulong'
/usr/bin/ld: odbcserver.c:(.text+0x6e7): undefined reference to `ei_x_encode_ulong'
/usr/bin/ld: odbcserver.c:(.text+0x6fa): undefined reference to `ei_x_encode_ulong'
/usr/bin/ld: odbcserver.c:(.text+0x708): undefined reference to `ei_x_encode_tuple_header'
/usr/bin/ld: odbcserver.c:(.text+0x71b): undefined reference to `ei_x_encode_ulong'
/usr/bin/ld: odbcserver.c:(.text+0x72e): undefined reference to `ei_x_encode_ulong'
[...]
This can be reproduced with the following minimal defconfig (and
libei.so present on host, see details below):
BR2_x86_64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_PACKAGE_ERLANG=y
Those missing symbols are part of the erl_interface, exposed by libei.a.
host-erlang builds correctly libei.a _before_ odbcserver.c (it can be
found in lib/erl_interface/obj/x86_64-pc-linux-gnu/libei.a), but the
failure is actually due to the build command generated and used for
odbcserver.c, especially the link arguments:
/usr/bin/gcc \
[...]
-o ../priv/bin/x86_64-pc-linux-gnu/odbcserver \
../priv/obj/x86_64-pc-linux-gnu/odbcserver.o \
-L/usr/lib64 \
-lodbc \
-L/home/alexis/src/buildroot/erlang-master/build/host-erlang-custom/lib/erl_interface/obj/x86_64-pc-linux-gnu \
-lpthread -lei
/usr/lib64 is searched before the path where libei.a has been built, so
if whether a valid libei.a or libei.so is found there, it shadows the
expected libei.a. In the build from which the logs above come, the
notable point is that the host system indeed have a valid libei.so, but
is completely unrelated to erl_interface; it rather exposes the Emulated
Input protocol aimed at Wayland stack; and so it obviously contains none
of the expected ei_* symbols.
Upstream has already identified and fixed the issue, the fix is already
released in versions >= 27.x.y. Erlang 26 (the version currently
packaged in buildroot), isn't supported anymore (only the three latest
releases are supported, see
https://github.com/erlang/otp/blob/master/SECURITY.md), so there won't
be any new minor update that will release this fix.
Pick and backport the fixing patch so that the current version packaged
in buildroot can still build.
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 5ea2135a56)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
https://github.com/strukturag/libheif/releases/tag/v1.23.2
Fixes the following CVEs:
(CVE numbers will be added upstream when assigned.)
CVE-2026-XXXXX (GHSA-g89c-p67h-r497)
Heap buffer overflow in scale_nearest_neighbor() via duplicate alpha
planes from nested iden/auxl items. (critical)
(GHSA-2jg2-4ch7-h545)
Out-of-bounds read and write in derived-item and pixel-plane handling.
Through iden and auxl item chains, a crafted file could attach pixel
planes whose size differs from the image geometry; crop, scale, and
plane-extraction code then indexed those planes with the wrong size.
A working code-execution exploit was confirmed. Plane sizes are now
validated wherever they are consumed. (critical)
CVE-2026-XXXXX (GHSA-24wx-9w62-c96w)
brotli/zlib decompression of mime metadata and unci image data had no
effective output-size limit, so a decompression bomb could exhaust
memory. Decompressed output is now bounded by the security limits.
(high)
CVE-2026-XXXXX (GHSA-x8xm-cm2c-cfc8)
Chains of derived-image references (grid, iovl, iden) bypassed decode
caching and memory limits, causing CPU and memory amplification. (high)
CVE-2026-XXXXX (GHSA-xw34-mjcp-jqh8)
Sequence sample-timing initialization could produce non-terminating
decode loops and unbounded memory, bypassing max_sequence_frames.
(high)
CVE-2026-XXXXX (GHSA-j264-xvrp-5v7q)
Out-of-bounds write in the unci encoder when
heif_context_add_image_tile() is given a tile whose planes do not match
its declared size. (high)
CVE-2026-XXXXX (GHSA-p58j-h3vm-3fp5)
Heap out-of-bounds read in the inline-mask region API when
mask_data_len does not match the region geometry. (medium)
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 0fe2d74ffd)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Since the bump of libxml2 from 2.13.8 to 2.15.0 in Buildroot commit
d81922c1ef, the "virt" plugin of
collectd no longer builds:
src/virt.c:2208:49: error: expected ';', ',' or ')' before 'ATTRIBUTE_UNUSED'
2208 | static void virt_eventloop_timeout_cb(int timer ATTRIBUTE_UNUSED,
| ^~~~~~~~~~~~~~~~
src/virt.c: In function 'register_event_impl':
src/virt.c:2221:26: error: 'virt_eventloop_timeout_cb' undeclared (first use in this function)
2221 | virt_eventloop_timeout_cb, NULL, NULL) < 0) {
| ^~~~~~~~~~~~~~~~~~~~~~~~~
src/virt.c:2221:26: note: each undeclared identifier is reported only once for each function it appears in
This is due to the fact that the virt plugin code was incorrectly
using the ATTRIBUTE_UNUSED define, which was supposed to be an
internal define of libxml2. But it turns out that up to libxml2 2.14.0
and its commit 208f27f9641a59863ce1f7d4992df77f7eb0ea9d, this define
had been made publicly available. It could therefore mistakenly be
used by collectd's virt plugin... until libxml2 was upgraded.
We backport an upstream patch from collectd that fixes the issue.
Fixes:
https://autobuild.buildroot.net/results/4c8463f0372560f4c3a20b0f67854460f0d1c400/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 83fc4aa55e)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
This commit adds a simple bpftrace test that ensures that not only it
builds fine, but it also runs properly on a minimal test scenario.
Assisted-by: GPT-5.6
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[Julien:
- reindent emulator.boot() options
- add a call to "bpftrace --version"
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit e06cfae9cb)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Based on the lighttpd test case. Verify that we can download index.html
from haproxy in front of lighttpd.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 211cfafa16)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
haproxy has a runtime test to verify that it is built with -fwrapv:
haproxy
FATAL ERROR: invalid code detected -- cannot go further, please recompile!
The source code was miscompiled by the compiler, which usually indicates that
some of the CFLAGS needed to work around overzealous compiler optimizations
were overwritten at build time. Please do not force CFLAGS, and read Makefile
and INSTALL files to decide on the best way to pass your local build options.
Build options :
TARGET = custom
CPU = generic
CC = /home/peko/source/buildroot/output-haproxy/host/bin/arm-linux-gcc
CFLAGS = -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g0 -D_FORTIFY_SOURCE=1 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g0 -D_FORTIFY_SOURCE=1
OPTIONS = USE_THREAD=1 USE_DL=1
DEBUG = -DDEBUG_STRICT -DDEBUG_MEMORY_POOLS
Which comes from:
https://github.com/haproxy/haproxy/blob/v2.6.0/src/haproxy.c#L3008-L3037
So build it with -fwrapv to fix that.
Notice that this message also embeds the build path (through CC), breaking
reproducible builds.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 94aa7f40b5)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
perl does not build with musl due to memrchr() being unavailable. This
is caused by a perl-cross bug, which does function availability
detection with _GNU_SOURCE defined, but then does the build without
_GNU_SOURCE defined. At least OpenEmbedded and NixOS have faced the
same issue, and worked it around in slightly different ways.
On our side, we create a patch, which was submitted upstream, to solve
the issue.
This issue has been introduced in perl-cross commit b40c560f5d5e,
which was first merged in perl-cross release 1.4.1. From a Buildroot
perspective, we bumped from perl-cross 1.4 to 1.4.1 in commit
8a289667f5, which was merged
2023.05. And indeed the build failure can be reproduced even on our
LTS 2025.02.x, so the fix needs to be backported there.
It should be noted that even if the patch is against perl-cross, we
add it to package/perl/ directly, as patches in perl are applied after
perl has been extracted *and* perl-cross has been extracted on top.
Fixes:
https://autobuild.buildroot.net/results/3e47ade0963642988fd8e1be9a6e8042700619ec/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit d950fff290)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
The BR2_PACKAGE_QT6DECLARATIVE_QUICK option has some logic to select
network support in host-qt6base if network support is enabled in
qt6base. However, it turns out that this is actually required at the
top level BR2_PACKAGE_QT6DECLARATIVE option: as soon as network
support is available in qt6base, the qt6declarative build will assume
that qmlprofiler is available... but that requires network support in
host-qt6base.
This fixes the following build failure:
CMake Error at /home/thomas/autobuild/instance-2/output-1/build/qt6base-6.9.1/cmake/QtToolHelpers.cmake:784 (message):
Failed to find the host tool "Qt6::qmlprofiler". It is part of the
Qt6QmlTools package, but the package did not contain the tool. Make sure
that the host module Qml was built with all features enabled (no explicitly
disabled tools).
Call Stack (most recent call first):
/home/thomas/autobuild/instance-2/output-1/build/qt6base-6.9.1/cmake/QtToolHelpers.cmake:83 (qt_internal_find_tool)
tools/qmlprofiler/CMakeLists.txt:11 (qt_internal_add_tool)
Fixes:
https://autobuild.buildroot.net/results/72c956fdf982382d2981c649c456d1edc2c9d6b2/
We did not trace back exactly since when the problem exists, but we
verified that the problem exists in 2025.02.x. It can be reproduced
with the following defconfig:
BR2_aarch64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_AARCH64_GLIBC_STABLE=y
BR2_PACKAGE_QT6=y
BR2_PACKAGE_QT6BASE_NETWORK=y
BR2_PACKAGE_QT6DECLARATIVE=y
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 50a1dd2676)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
The commit "Enable host test module to ensure that qmltestrunner is
built" in qt6declarative's Config.in feels lonely under
BR2_PACKAGE_QT6DECLARATIVE. It's because it's actually related to a
select done in the sub-option BR2_PACKAGE_QT6DECLARATIVE_QUICK, so
move it there.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 29add67666)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Buildroot commit [1] (package/apache: use "Debian" filesystem
layout to fix read-only rootfs) changed the filesystem layout.
This had the effect of installing files to different locations
and breaking the test_php runtime test.
This commit fixes the issue by updating the file paths to their
right locations. The "httpd.conf" was updated by following the
same recipe described in the comment (starting from a config
file as installed by the apache Buildroot package).
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/16060152979
[1] 1006666f67
Signed-off-by: Julien Olivain <ju.o@free.fr>
Tested-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 23fd881bdb)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
In commit 54f96add94 ("package/bind:
security bump version to 9.20.24") the depends on
BR2_TOOLCHAIN_HAS_THREADS_NPTL was incorrectly downgraded to
BR2_TOOLCHAIN_HAS_THREADS:
- depends on BR2_TOOLCHAIN_HAS_THREADS_NPTL # libuv
+ depends on BR2_TOOLCHAIN_HAS_THREADS # liburcu, libuv
This is wrong because libuv depends on
BR2_TOOLCHAIN_HAS_THREADS_NPTL. This causes unmet dependencies:
WARNING: unmet direct dependencies detected for BR2_PACKAGE_LIBUV
Depends on [n]: BR2_TOOLCHAIN_HAS_THREADS_NPTL [=n] && BR2_USE_MMU [=y] && !BR2_STATIC_LIBS [=n] && BR2_TOOLCHAIN_HAS_SYNC_4 [=y] && BR2_TOOLCHAIN_GCC_AT_LEAST_4_9 [=y]
Selected by [y]:
- BR2_PACKAGE_BIND [=y] && BR2_USE_MMU [=y] && BR2_TOOLCHAIN_HAS_SYNC_4 [=y] && BR2_TOOLCHAIN_HAS_THREADS [=y] && BR2_INSTALL_LIBSTDCPP [=y] && !BR2_STATIC_LIBS [=n] && BR2_TOOLCHAIN_GCC_AT_LEAST_4_9 [=y] && BR2_PACKAGE_LIBURCU_ARCH_SUPPORTS [=y]
Fix that by switching back to the BR2_TOOLCHAIN_HAS_THREADS_NPTL
dependency.
Fixes: 54f96add94 ("package/bind: security bump version to 9.20.24")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit d8dde961bc)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
