We no longer have the patch fixing CVE-2022-3559 because we've updated
to a version of exim that includes it. However, the ignore CVE entry
is not stale because the NVD database is incorrect on this CVE. We
reported the issue to upstream NVD at:
https://lore.kernel.org/buildroot/20250517183423.07951665@windsurf/
Let's document this above the ignore CVE entry.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 114784cb7b)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The CVE-2022-3620 entry is not reported as affecting our exim package
by pkg-stats. Currently it's because the NVD entry is
incorrect (incorrect exim version), but we sent a bug report [1] to
the NVD database so that it gets updated. Once updated, pkg-stats
still won't report the CVE as affecting us because the issue has been
fixed in exim 4.97, and we're using a newer version.
[1] https://lore.kernel.org/buildroot/20250517183000.40b28b4d@windsurf/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 463e21fdcb)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The 0001-set-default-maximum-dns-udp-package-size.patch is no longer
in Buildroot since the bump to 2.90 in commit
213cfb3435, which renders the
CVE-2023-28450 ignore CVE entry no longer needed.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 1799aa7eb4)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
All of CVE-2023-42363, CVE-2023-42364, CVE-2023-42365, CVE-2023-42366
were fixed by patches that we no longer have since we bumped
Busybox. Those IGNORE_CVES entries are therefore no longer needed.
The CVE-2022-28391 ignore CVE entry is also reported as stale, but we
believe the NVD database is incorrect in saying this vulnerability
only affects Busybox up to 1.35.0. Indeed, Busybox 1.37.0 still
doesn't have the fixes and is therefore still affected.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit f88537c46b)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
CVE-2020-15705 is only applicable to grub versions up to 2.04, and
we're using a more recent version, so it is no longer needed to ignore
it.
CVE-2021-46705 is only applicable to grub versions up to 2.06, and
we're using a more recent version, so it is no longer needed to ignore
it.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 06afaf5347)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The configure flag -feature-webengine-system-jpeg[1] checks if a jpeg
library is in the sysroot.
It compiles a test file linked against the symbols jpeg_crop_scanline()
and jpeg_skip_scanlines()[2] that are specific to jpep-turbo.
As a consequence, the configure scripts fails if the libjpeg is selected
as the jpeg variant as the symbols mentionend above are not part of the
jpeg library installed in the sysroots.
ERROR: Feature 'webengine-system-jpeg' was enabled, but the pre-condition 'config.unix && features.system-jpeg && libs.webengine-jpeglib' failed.
Additionally, see the log below, extracted from config.log:
> /home/gportay/src/buildroot/output/host/bin/arm-buildroot-linux-gnueabihf-g++ -c -pipe -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g0 -D_FORTIFY_SOURCE=1 -mtune=arm1176jzf-s -march=armv6 --sysroot=/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot -w -fPIC -I. -I/home/gportay/src/buildroot/output/host/mkspecs/devices/linux-buildroot-g++ -o main.o main.cpp
> main.cpp: In function ‘int main(int, char**)’:
> main.cpp:12:5: error: ‘jpeg_crop_scanline’ was not declared in this scope; did you mean ‘jpeg_write_scanlines’?
> 12 | jpeg_crop_scanline(nullptr, &dummy, &dummy);
> | ^~~~~~~~~~~~~~~~~~
> | jpeg_write_scanlines
> main.cpp:13:5: error: ‘jpeg_skip_scanlines’ was not declared in this scope; did you mean ‘jpeg_write_scanlines’?
> 13 | jpeg_skip_scanlines(nullptr, dummy);
> | ^~~~~~~~~~~~~~~~~~~
> | jpeg_write_scanlines
> make[1]: *** [Makefile:334: main.o] Error 1
> make[1]: Leaving directory '/home/gportay/src/buildroot/output/build/qt5webengine-5.15.14/config.tests/webengine-jpeglib'
We could build some complicated logic to make sure what qt5webengine is
only used with jpeg-turbo. However, Chromium bundles jpeg-turbo[3][4]
and uses it if not using the system jpeg library or qt-jpeg[5]. It is
simpler to just always use that version instead of the system jpeg
library.
This sets the configure option -nofeature-webengine-system-jpeg and
removes jpeg from the dependencies.
Note that host-libjpeg and qt-jpeg (and therefore, system libjpeg or
jpeg-turbo) are still needed for the Qt integration layer, even if
chromium uses the bundled jpeg-turbo.
[1]: https://github.com/qt/qtwebengine/blob/v5.15.14-lts/src/buildtools/configure.json#L609-L613
[2]: https://github.com/qt/qtwebengine/blob/v5.15.14-lts/src/buildtools/configure.json#L95-L116
[3]: 18c9261dc5/chromium/third_party/libjpeg_turbo
[4]: 18c9261dc5/chromium/third_party/libjpeg.gni
[5]: https://github.com/qt/qtwebengine/blob/v5.15.14-lts/src/buildtools/configure.json#L614-618
Fixes:
looking for library webengine-jpeglib
Trying source 0 (type pkgConfig) of library webengine-jpeglib ...
+ PKG_CONFIG_SYSROOT_DIR=/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot PKG_CONFIG_LIBDIR=/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/pkgconfig:/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/share/pkgconfig:/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/arm-buildroot-linux-gnueabihf/pkgconfig /home/gportay/src/buildroot/output/host/bin/pkg-config --exists --silence-errors libjpeg
+ PKG_CONFIG_SYSROOT_DIR=/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot PKG_CONFIG_LIBDIR=/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/pkgconfig:/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/share/pkgconfig:/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/arm-buildroot-linux-gnueabihf/pkgconfig /home/gportay/src/buildroot/output/host/bin/pkg-config --modversion libjpeg
> 9.6.0
+ PKG_CONFIG_SYSROOT_DIR=/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot PKG_CONFIG_LIBDIR=/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/pkgconfig:/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/share/pkgconfig:/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/arm-buildroot-linux-gnueabihf/pkgconfig /home/gportay/src/buildroot/output/host/bin/pkg-config --libs-only-L libjpeg
> -L/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib
+ PKG_CONFIG_SYSROOT_DIR=/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot PKG_CONFIG_LIBDIR=/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/pkgconfig:/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/share/pkgconfig:/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/arm-buildroot-linux-gnueabihf/pkgconfig /home/gportay/src/buildroot/output/host/bin/pkg-config --libs-only-l libjpeg
> -ljpeg
+ PKG_CONFIG_SYSROOT_DIR=/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot PKG_CONFIG_LIBDIR=/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/pkgconfig:/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/share/pkgconfig:/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/arm-buildroot-linux-gnueabihf/pkgconfig /home/gportay/src/buildroot/output/host/bin/pkg-config --cflags libjpeg
> -I/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/include
+ cd /home/gportay/src/buildroot/output/build/qt5webengine-5.15.14/config.tests/webengine-jpeglib && PKG_CONFIG_SYSROOT_DIR=/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot PKG_CONFIG_LIBDIR=/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/pkgconfig:/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/share/pkgconfig:/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/arm-buildroot-linux-gnueabihf/pkgconfig /home/gportay/src/buildroot/output/host/bin/qmake "CONFIG -= qt debug_and_release app_bundle lib_bundle" "CONFIG += shared warn_off console single_arch" -early "CONFIG += cross_compile" 'QMAKE_USE += webengine-jpeglib' 'QMAKE_LIBS_WEBENGINE_JPEGLIB = -L/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib -ljpeg' /home/gportay/src/buildroot/output/build/qt5webengine-5.15.14/config.tests/webengine-jpeglib
+ cd /home/gportay/src/buildroot/output/build/qt5webengine-5.15.14/config.tests/webengine-jpeglib && MAKEFLAGS= make
> make[1]: Entering directory '/home/gportay/src/buildroot/output/build/qt5webengine-5.15.14/config.tests/webengine-jpeglib'
> /home/gportay/src/buildroot/output/host/bin/arm-buildroot-linux-gnueabihf-g++ -c -pipe -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g0 -D_FORTIFY_SOURCE=1 -mtune=arm1176jzf-s -march=armv6 --sysroot=/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot -w -fPIC -I. -I/home/gportay/src/buildroot/output/host/mkspecs/devices/linux-buildroot-g++ -o main.o main.cpp
> main.cpp: In function ‘int main(int, char**)’:
> main.cpp:12:5: error: ‘jpeg_crop_scanline’ was not declared in this scope; did you mean ‘jpeg_write_scanlines’?
> 12 | jpeg_crop_scanline(nullptr, &dummy, &dummy);
> | ^~~~~~~~~~~~~~~~~~
> | jpeg_write_scanlines
> main.cpp:13:5: error: ‘jpeg_skip_scanlines’ was not declared in this scope; did you mean ‘jpeg_write_scanlines’?
> 13 | jpeg_skip_scanlines(nullptr, dummy);
> | ^~~~~~~~~~~~~~~~~~~
> | jpeg_write_scanlines
> make[1]: *** [Makefile:334: main.o] Error 1
> make[1]: Leaving directory '/home/gportay/src/buildroot/output/build/qt5webengine-5.15.14/config.tests/webengine-jpeglib'
=> source failed verification.
Trying source 1 (type inline) of library webengine-jpeglib ...
+ cd /home/gportay/src/buildroot/output/build/qt5webengine-5.15.14/config.tests/webengine-jpeglib && PKG_CONFIG_SYSROOT_DIR=/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot PKG_CONFIG_LIBDIR=/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/pkgconfig:/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/share/pkgconfig:/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/arm-buildroot-linux-gnueabihf/pkgconfig /home/gportay/src/buildroot/output/host/bin/qmake "CONFIG -= qt debug_and_release app_bundle lib_bundle" "CONFIG += shared warn_off console single_arch" -early "CONFIG += cross_compile" 'QMAKE_USE += webengine-jpeglib' 'QMAKE_LIBS_WEBENGINE_JPEGLIB = -ljpeg' /home/gportay/src/buildroot/output/build/qt5webengine-5.15.14/config.tests/webengine-jpeglib
+ cd /home/gportay/src/buildroot/output/build/qt5webengine-5.15.14/config.tests/webengine-jpeglib && MAKEFLAGS= make clean && MAKEFLAGS= make
> make[1]: Entering directory '/home/gportay/src/buildroot/output/build/qt5webengine-5.15.14/config.tests/webengine-jpeglib'
> rm -f main.o
> rm -f *~ core *.core
> make[1]: Leaving directory '/home/gportay/src/buildroot/output/build/qt5webengine-5.15.14/config.tests/webengine-jpeglib'
> make[1]: Entering directory '/home/gportay/src/buildroot/output/build/qt5webengine-5.15.14/config.tests/webengine-jpeglib'
> /home/gportay/src/buildroot/output/host/bin/arm-buildroot-linux-gnueabihf-g++ -c -pipe -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g0 -D_FORTIFY_SOURCE=1 -mtune=arm1176jzf-s -march=armv6 --sysroot=/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot -w -fPIC -I. -I/home/gportay/src/buildroot/output/host/mkspecs/devices/linux-buildroot-g++ -o main.o main.cpp
> main.cpp: In function ‘int main(int, char**)’:
> main.cpp:12:5: error: ‘jpeg_crop_scanline’ was not declared in this scope; did you mean ‘jpeg_write_scanlines’?
> 12 | jpeg_crop_scanline(nullptr, &dummy, &dummy);
> | ^~~~~~~~~~~~~~~~~~
> | jpeg_write_scanlines
> main.cpp:13:5: error: ‘jpeg_skip_scanlines’ was not declared in this scope; did you mean ‘jpeg_write_scanlines’?
> 13 | jpeg_skip_scanlines(nullptr, dummy);
> | ^~~~~~~~~~~~~~~~~~~
> | jpeg_write_scanlines
> make[1]: *** [Makefile:334: main.o] Error 1
> make[1]: Leaving directory '/home/gportay/src/buildroot/output/build/qt5webengine-5.15.14/config.tests/webengine-jpeglib'
=> source failed verification.
test config.qtwebengine_buildtools.libraries.webengine-jpeglib FAILED
Signed-off-by: Gaël PORTAY <gael.portay@rtone.fr>
[Arnout: always use the bundled jpeg-turbo]
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
(cherry picked from commit 3271ce10f2)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
For portability reason, it isn't preferable to include an absolute path
in the link to fw_printenv which is in the same directory as fw_setenv.
Fixes: 42646265d5 ("package/uboot-tools: add fw_printenv to host uboot tools")
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 0b02091235)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Fixes:
https://autobuild.buildroot.net/results/924b1015d4b81385409ef00f1a14be3ca1959c8e/
As part of building flex for the target a few files are built for the host,
including a rpl_malloc() implementation containing a malloc() forward
declaration without any function parameters.
GCC 15 defaults to -std=gnu23, which handles function declarations without
parameters differently from earlier C standards leading to compilation
errors:
../lib/malloc.c:6:12: warning: conflicting types for built-in function 'malloc'; expected 'void *(long unsigned int)' [-Wbuiltin-declaration-mismatch]
6 | void *malloc ();
| ^~~~~~
../lib/malloc.c:5:1: note: 'malloc' is declared in header '<stdlib.h>'
4 | #include <sys/types.h>
+++ |+#include <stdlib.h>
5 |
../lib/malloc.c: In function 'rpl_malloc':
../lib/malloc.c:16:15: error: too many arguments to function 'malloc'; expected 0, have 1
https://gcc.gnu.org/gcc-15/porting_to.html#c23-fn-decls-without-parameters
Add a patch submitted upstream to correct the prototype.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 7b98e2ce2c)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
It allows to download files from smb share in buildroot packages.
Usage is specified in manual.
Signed-off-by: Guillaume Chaye <guillaume.chaye@zeetim.com>
[Peter: reword documentation]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit e240b889f1)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The NVD database contains some CPEs that are wrongly not associated
with any version number. They are for example sometimes associated
with very old CVEs.
Those CPEs are annoying, because they pollute our pkg-stat CVE results
with CVE entries which actually don't affect us.
The proper way to solve it is, and should remain, to fix the NVD
database by reporting these issues. Having to deal with a lot of
CVEs/CPEs, the NVD database is however slow to be updated.
To reduce the noise in our pkg-stats results in the meantime, one
possibility is to add <PKG_IGNORE_CVES> entries for those CVEs. This
however comes with the downside that even once the NVD database gets
fixed, those ignored entries risk remaining in Buildroot forever
because they are undetected.
This commit tries to address this downside by checking for and
reporting CVEs that are ignored in Buildroot, but where the
NVD reports our package version as unaffected. Those CVEs will appear
in the 'CVEs Ignored' column as '(stale)', and the cell will be
colored the same way warnings are. This should allow us to detect and
remove those entries.
It can be tested for example by adding the following variable to the
apache package (for a CVE that was recently fixed in the NVD database):
APACHE_IGNORE_CVES = CVE-1999-0236
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 56ea5a0226)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
When building the bluez5_utils package with HoG plugin without enabling
the HID plugin the following linker error would occur:
```
/workdir/instance-0/output-1/per-package/bluez5_utils/host/bin/../lib/gcc/x86_64-buildroot-linux-uclibc/13.3.0/../../../../x86_64-buildroot-linux-uclibc/bin/ld: profiles/input/bluetoothd-hog.o: in function `hog_disconnect':
hog.c:(.text.hog_disconnect+0x12): undefined reference to `input_get_userspace_hid'
collect2: error: ld returned 1 exit status
```
This patch adds two upstream commits that decouple both the HID
and the HoG plugin.
As a consequence of this patch the HID plugin can be compiled without
the HoG one as well but to keep the compatibility the same in buildroot
the selection of the HoG plugin is kept when selecting the HID plugin.
The error can be reproduced with the following defconfig
```
BR2_arm=y
BR2_cortex_a7=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_PACKAGE_BLUEZ5_UTILS=y
BR2_PACKAGE_BLUEZ5_UTILS_PLUGINS_HOG=y
```
Fixes: https://autobuild.buildroot.org/results/78e/78ed7664f3a2dd5858fd71bd63836c822c106cc0
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 57eb26837b)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The package opus is selected but it is not listed in the dependencies.
This adds opus to QT5WEBENGINE_DEPENDENCIES.
Fixes:
$ make qt5webengine
(...)
ERROR: Feature 'webengine-system-opus' was enabled, but the pre-condition 'config.unix && libs.webengine-opus' failed.
Signed-off-by: Gaël PORTAY <gael.portay@rtone.fr>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
(cherry picked from commit 7319e4af19)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
TL;DR; This turns the configure flag -no-feature-webengine-noexecstack
to -feature-webengine-noexecstack to workaround a link issue on ARM
32-bit if chromium requests for an executable stack.
And now, the long story...
The configure flag -no-feature-webengine-noexecstack was introduced with
commit 675cbaf9aa (package/qt5/qt5webengine: bump to version 5.15.8).
That configure flag controls the feature webengine-noexecstack[1][2];
the -no-feature-webengine-noexecstack causes qmake to **NOT** append the
linker flags -Wl,-z,noexecstack[3] to QMAKE_LFLAGS.
It results in the linkage issue below on ARM 32-bit at the creation of
its Qt module, i.e. after qmake has built the chromium third party via
gn:
ulimit -n 4096 && /home/gportay/src/buildroot/output/host/bin/arm-buildroot-linux-gnueabihf-g++ --sysroot=/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot @/home/gportay/src/buildroot/output/build/qt5webengine-5.15.14/src/core/release/QtWebEngineCore_o.rsp -Wl,--start-group @/home/gportay/src/buildroot/output/build/qt5webengine-5.15.14/src/core/release/QtWebEngineCore_a.rsp -Wl,--end-group -Wl,--fatal-warnings -Wl,--build-id=sha1 -fPIC -Wl,-z,relro -Wl,-z,now -Wl,-z,defs -Wl,-O2 -Wl,--gc-sections --sysroot=/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot --sysroot=/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot -Wl,-O1 -Wl,--enable-new-dtags -Wl,-whole-archive -lqtwebenginecoreapi -Wl,-no-whole-archive -Wl,--no-undefined -Wl,--version-script,QtWebEngineCore.version -Wl,-O1 -Wl,--enable-new-dtags -shared -Wl,-soname,libQt5WebEngineCore.so.5 -o libQt5WebEngineCore.so.5.15.14 -latomic /home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libQt5Quick.so /home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libQt5Gui.so /home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libQt5QmlModels.so /home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libQt5WebChannel.so /home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libQt5Qml.so /home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libQt5Network.so /home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libQt5Core.so -lpthread -L/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib -latomic -lGLESv2 -lpthread -ldl -lrt -lnss3 -lnssutil3 -lsmime3 -lplds4 -lplc4 -lnspr4 -levent -lresolv -ljpeg -lopus -lm -lz -lvpx -lpng16 -lwebp -lwebpmux -lwebpdemux -lfreetype -lexpat -lfontconfig -lharfbuzz-subset -lharfbuzz -lsnappy -lxml2 -lxslt -ldbus-1 -L/home/gportay/src/buildroot/output/build/qt5webengine-5.15.14/src/core/api/release -lGLESv2 -lrt -lpthread -ldl
/home/gportay/src/buildroot/output/host/lib/gcc/arm-buildroot-linux-gnueabihf/13.3.0/../../../../arm-buildroot-linux-gnueabihf/bin/ld: warning: /home/gportay/src/buildroot/output/build/qt5webengine-5.15.14/src/core/release/obj/third_party/blink/renderer/platform/heap/asm/asm/SaveRegisters_arm.o: missing .note.GNU-stack section implies executable stack
/home/gportay/src/buildroot/output/host/lib/gcc/arm-buildroot-linux-gnueabihf/13.3.0/../../../../arm-buildroot-linux-gnueabihf/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker
collect2: error: ld returned 1 exit status
The link succeeds if the missing linker flags are appended manually to
the command-line:
ulimit -n 4096 && /home/gportay/src/buildroot/output/host/bin/arm-buildroot-linux-gnueabihf-g++ --sysroot=/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot @/home/gportay/src/buildroot/output/build/qt5webengine-5.15.14/src/core/release/QtWebEngineCore_o.rsp -Wl,--start-group @/home/gportay/src/buildroot/output/build/qt5webengine-5.15.14/src/core/release/QtWebEngineCore_a.rsp -Wl,--end-group -Wl,--fatal-warnings -Wl,--build-id=sha1 -fPIC -Wl,-z,relro -Wl,-z,now -Wl,-z,defs -Wl,-O2 -Wl,--gc-sections --sysroot=/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot --sysroot=/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot -Wl,-O1 -Wl,--enable-new-dtags -Wl,-whole-archive -lqtwebenginecoreapi -Wl,-no-whole-archive -Wl,--no-undefined -Wl,--version-script,QtWebEngineCore.version -Wl,-O1 -Wl,--enable-new-dtags -shared -Wl,-soname,libQt5WebEngineCore.so.5 -o libQt5WebEngineCore.so.5.15.14 -latomic /home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libQt5Quick.so /home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libQt5Gui.so /home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libQt5QmlModels.so /home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libQt5WebChannel.so /home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libQt5Qml.so /home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libQt5Network.so /home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libQt5Core.so -lpthread -L/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib -latomic -lGLESv2 -lpthread -ldl -lrt -lnss3 -lnssutil3 -lsmime3 -lplds4 -lplc4 -lnspr4 -levent -lresolv -ljpeg -lopus -lvpx -lm -lpng16 -lwebp -lwebpmux -lwebpdemux -lfreetype -lexpat -lfontconfig -lharfbuzz-subset -lharfbuzz -lsnappy -lxml2 -lxslt -ldbus-1 -L/home/gportay/src/buildroot/output/build/qt5webengine-5.15.14/src/core/api/release -lGLESv2 -lrt -lpthread -ldl -Wl,-z,noexecstack && echo completed
completed
Note: The configure flag is not forwarded to chromium in any manner; its
scope is limited to the Qt WebEngine module. That configure flag appears
to be a workaround if the does not assemble, compile and link the Elf
object correctly[4][5].
The linker flag -z noexecstack is responsible for marking the object as
not requiring an executable stack by adding the section .note.GNU-stack
in the Elf object.
The file SaveRegisters_arm.S is assembled from the command-line below;
there is no noexecstack flag set:
/home/gportay/src/buildroot/output/host/bin/arm-buildroot-linux-gnueabihf-gcc -MMD -MF obj/third_party/blink/renderer/platform/heap/asm/asm/SaveRegisters_arm.o.d -DARM=1 -DUSE_UDEV -DUSE_AURA=1 -DUSE_NSS_CERTS=1 -DUSE_OZONE=1 -DOFFICIAL_BUILD -DTOOLKIT_QT -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DNO_UNWIND_TABLES -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -DCR_SYSROOT_HASH=c2e54f675b83a61301dcdb22e8e7a2b85c01d58c -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -Igen -I../../3rdparty/chromium -fPIC -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -fno-unwind-tables -fno-asynchronous-unwind-tables -fPIC -pipe -pthread -std=gnu11 -march=armv7-a -mfloat-abi=hard -mtune=generic-armv7-a -mfpu=vfpv3-d16 -marm -g0 --sysroot=/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot -c ../../3rdparty/chromium/third_party/blink/renderer/platform/heap/asm/SaveRegisters_arm.S -o obj/third_party/blink/renderer/platform/heap/asm/asm/SaveRegisters_arm.o
The GNU assembler supports the assembler flag -Wa,--{,no}execstack to
require, or not, an executable stack for the object to assemble.
The BUILD.gn does **NOT** set it for the assembler files of the blink
third-party; but it does it for boringssl[6] (see also the project file
CMakeLists.txt[7]).
See below what readelf says if the file is assembled manually with the
flag --noexecstack:
$ /home/gportay/src/buildroot/output/host/bin/arm-buildroot-linux-gnueabihf-gcc -MMD -MF obj/third_party/blink/renderer/platform/heap/asm/asm/SaveRegisters_arm.o.d -DARM=1 -DUSE_UDEV -DUSE_AURA=1 -DUSE_NSS_CERTS=1 -DUSE_OZONE=1 -DOFFICIAL_BUILD -DTOOLKIT_QT -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DNO_UNWIND_TABLES -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -DCR_SYSROOT_HASH=c2e54f675b83a61301dcdb22e8e7a2b85c01d58c -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -Igen -I../../3rdparty/chromium -fPIC -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -fno-unwind-tables -fno-asynchronous-unwind-tables -fPIC -pipe -pthread -std=gnu11 -march=armv7-a -mfloat-abi=hard -mtune=generic-armv7-a -mfpu=vfpv3-d16 -marm -g0 --sysroot=/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot -c ../../3rdparty/chromium/third_party/blink/renderer/platform/heap/asm/SaveRegisters_arm.S -o obj/third_party/blink/renderer/platform/heap/asm/asm/SaveRegisters_arm.o -Wa,--noexecstack
$ readelf -a /home/gportay/src/buildroot/output/build/qt5webengine-5.15.14/src/core/release/obj/third_party/blink/renderer/platform/heap/asm/asm/SaveRegisters_arm.o
(...)
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
(...)
[ 4] .note.GNU-stack PROGBITS 00000000 000058 000000 00 0 0 1
The section the linker claims for is now part of the Elf object; and
qmake is now able to link its Qt WebEngine module.
Note: Alternatively, the patching the file SaveRegisters_arm.S to set
explicitly the section in the source file works as well (this reduces
the impact to the very single file causing the link issue):
#if defined(__linux__) && defined(__ELF__)
.section .note.GNU-stack,"",%progbits
#endif
Instead of fixing directly the origin of the issue and setting the
missing assembler flag -Wa,--noexecstack to blink; this works around the
link issue by turning on the feature noexecstack to qtwebengine to force
qmake to link its module using the linker flag -Wl,-z,noexecstack.
[1]: https://github.com/qt/qtwebengine/blob/5.15.14/src/buildtools/configure.json#L353-L357
[2]: https://github.com/qt/qtwebengine/blob/5.15.14/src/buildtools/configure.json#L720-L724
[3]: https://github.com/qt/qtwebengine/blob/5.15.14/src/buildtools/config/linking.pri#L61-L62
[4]: 597359a16a
[5]: https://codereview.qt-project.org/c/qt/qtwebengine/+/263545
[6]: https://github.com/qt/qtwebengine-chromium/blob/87-based/chromium/third_party/boringssl/src/util/BUILD.toplevel#L64
[7]: https://github.com/qt/qtwebengine-chromium/blob/87-based/chromium/third_party/boringssl/src/crypto/CMakeLists.txt#L33
Signed-off-by: Gaël PORTAY <gael.portay@rtone.fr>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
(cherry picked from commit aa017484ea)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
See the code snippet below, which typically is used to check if
C++ support can be enabled.
If we manually set CMAKE_CXX_COMPILER to /bin/false, then cmake
will assume that it's fine, without having a real check. Otherwise,
it will do a test run but somehow it falls back to /bin/c++, even
when cross-compiling. Fix that by setting CXX to /bin/false.
```cmake
include(CheckLanguage)
check_language(CXX)
if(CMAKE_CXX_COMPILER)
enable_language(CXX)
endif()
```
Signed-off-by: Thomas Devoogdt <thomas@devoogdt.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit b34e0d27ab)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
This updates the VC4/V3D driver messages with the addition of the
current supported hardwares (VideoCore and Raspberry Pi).
Signed-off-by: Gaël PORTAY <gael.portay+rtone@gmail.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 15cfdf4915)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The Gallium VC4 driver does not require NEON[1]; Gallium V3D does. Also,
the Gallium VC4 driver supports the Raspberry Pi from 0 to 3[2].
Mesa’s VC4 graphics driver supports multiple implementations of
Broadcom’s VideoCore IV GPU. It is notably used in the Raspberry
Pi 0 through Raspberry Pi 3 hardware, and the driver is included
as an option as of the 2016-02-09 Raspbian release using
raspi-config. On most other distributions such as Debian or
Fedora, you need no configuration to enable the driver.
This reverts commit a5cdb54ed7.
That commit is superseded by 85c95e3614
that patches the sources to disable NEON via an option[3]; the sources
using NEON (tiling) are disabled if the CPU does not have that feature.
Thus, the VC4 driver compiles with toolchain without the NEON support
enabled as the one targetting the Raspberry Pi (ARMv6).
This removes the depends on BR2_ARM_CPU_HAS_NEON config since a meson
option disables NEON if the CPU does not support for it. It allows
building Gallium VC4 on Raspberry Pi, Raspberry Pi Zero and Compute
Module.
Note: kmscube with OpenGLES and Gallium/VC4 runs on Raspberry Pi B+ Rev
1.2.
# uname -a
Linux buildroot 6.12.20 #1 Fri Apr 25 02:54:03 CEST 2025 armv6l GNU/Linux
# cat /sys/firmware/devicetree/base/model
Raspberry Pi Model B Plus Rev 1.2#
# dmesg
(...)
[ 39.817806] rpi-gpiomem 20200000.gpiomem: window base 0x20200000 size 0x00001000
[ 39.837139] rpi-gpiomem 20200000.gpiomem: initialised 1 regions as /dev/gpiomem
[ 40.693845] Console: switching to colour dummy device 80x30
[ 40.717223] vc4-drm soc:gpu: bound 20400000.hvs (ops vc4_hvs_ops [vc4])
[ 40.793911] vc4-drm soc:gpu: bound 20400000.hvs (ops vc4_hvs_ops [vc4])
[ 40.824330] Registered IR keymap rc-cec
[ 40.828596] rc rc0: vc4-hdmi as /devices/platform/soc/20902000.hdmi/rc/rc0
[ 40.844139] input: vc4-hdmi as /devices/platform/soc/20902000.hdmi/rc/rc0/input0
[ 40.873434] input: vc4-hdmi HDMI Jack as /devices/platform/soc/20902000.hdmi/sound/card0/input1
[ 40.895848] vc4-drm soc:gpu: bound 20902000.hdmi (ops vc4_hdmi_ops [vc4])
[ 40.914034] vc4-drm soc:gpu: bound 20004000.txp (ops vc4_txp_ops [vc4])
[ 40.921843] vc4-drm soc:gpu: bound 20206000.pixelvalve (ops vc4_crtc_ops [vc4])
[ 40.943543] vc4-drm soc:gpu: bound 20207000.pixelvalve (ops vc4_crtc_ops [vc4])
[ 40.951969] vc4-drm soc:gpu: bound 20807000.pixelvalve (ops vc4_crtc_ops [vc4])
[ 40.983322] vc4-drm soc:gpu: bound 20c00000.v3d (ops vc4_v3d_ops [vc4])
[ 41.010210] [drm] Initialized vc4 0.0.0 for soc:gpu on minor 0
[ 41.151906] Console: switching to colour frame buffer device 240x67
[ 41.223414] vc4-drm soc:gpu: [drm] fb0: vc4drmfb frame buffer device
# kmscube
Using display 0x1f12530 with EGL version 1.4
===================================
EGL information:
version: "1.4"
vendor: "Mesa Project"
client extensions: "EGL_EXT_client_extensions EGL_EXT_device_base EGL_EXT_device_enumeration EGL_EXT_device_query EGL_EXT_platform_base EGL_KHR_client_get_all_proc_addresses EGL_KHR_debug EGL_EXT_platform_device EGL_EXT_explicit_device EGL_MESA_platform_gbm EGL_KHR_platform_gbm EGL_MESA_platform_surfaceless"
display extensions: "EGL_ANDROID_blob_cache EGL_ANDROID_native_fence_sync EGL_EXT_buffer_age EGL_EXT_image_dma_buf_import EGL_EXT_image_dma_buf_import_modifiers EGL_KHR_cl_event2 EGL_KHR_config_attribs EGL_KHR_context_flush_control EGL_KHR_create_context EGL_KHR_create_context_no_error EGL_KHR_fence_sync EGL_KHR_get_all_proc_addresses EGL_KHR_gl_colorspace EGL_KHR_gl_renderbuffer_image EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_no_config_context EGL_KHR_reusable_sync EGL_KHR_surfaceless_context EGL_EXT_pixel_format_float EGL_KHR_wait_sync EGL_MESA_configless_context EGL_MESA_drm_image EGL_MESA_gl_interop EGL_MESA_image_dma_buf_export EGL_MESA_query_driver "
===================================
OpenGL ES 2.x information:
version: "OpenGL ES 2.0 Mesa 24.0.9"
shading language version: "OpenGL ES GLSL ES 1.0.16"
vendor: "Broadcom"
renderer: "VC4 V3D 2.1"
extensions: "GL_EXT_blend_minmax GL_EXT_multi_draw_arrays GL_EXT_texture_compression_s3tc GL_EXT_texture_compression_dxt1 GL_EXT_texture_format_BGRA8888 GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth24 GL_OES_element_index_uint GL_OES_fbo_render_mipmap GL_OES_mapbuffer GL_OES_rgb8_rgba8 GL_OES_stencil8 GL_OES_texture_npot GL_OES_vertex_half_float GL_OES_EGL_image GL_OES_depth_texture GL_AMD_performance_monitor GL_OES_packed_depth_stencil GL_OES_get_program_binary GL_APPLE_texture_max_level GL_EXT_discard_framebuffer GL_EXT_read_format_bgra GL_NV_pack_subimage GL_NV_texture_barrier GL_EXT_frag_depth GL_NV_fbo_color_attachments GL_OES_EGL_image_external GL_OES_EGL_sync GL_OES_vertex_array_object GL_ANGLE_pack_reverse_row_order GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_EXT_unpack_subimage GL_NV_draw_buffers GL_NV_read_buffer GL_NV_read_depth GL_NV_read_depth_stencil GL_NV_read_stencil GL_APPLE_sync GL_EXT_draw_buffers GL_EXT_map_buffer_range GL_KHR_debug GL_KHR_texture_compression_astc_ldr GL_NV_generate_mipmap_sRGB GL_NV_pixel_buffer_object GL_OES_required_internalformat GL_OES_surfaceless_context GL_EXT_debug_label GL_EXT_separate_shader_objects GL_EXT_compressed_ETC1_RGB8_sub_texture GL_EXT_draw_elements_base_vertex GL_EXT_texture_border_clamp GL_KHR_context_flush_control GL_OES_draw_elements_base_vertex GL_OES_texture_border_clamp GL_KHR_no_error GL_KHR_texture_compression_astc_sliced_3d GL_EXT_texture_compression_s3tc_srgb GL_KHR_parallel_shader_compile GL_MESA_tile_raster_order GL_MESA_sampler_objects GL_MESA_bgra "
===================================
Rendered 120 frames in 2.000020 sec (59.999400 fps)
[1]: 932ed9c00b
[2]: https://docs.mesa3d.org/drivers/vc4.html
[3]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4114
Signed-off-by: Gaël PORTAY <gael.portay+rtone@gmail.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 3f1f404b5c)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Buildroot commit [1] introduced the firmware-ele-imx package and was
using the "mx93a1-ahab-container.img" firmware image for i.MX91.
For i.MX91, it is in fact the firmware file "mx91a0-ahab-container.img"
which needs to be used.
This commit adds this special case.
[1] 69d127fe29
Signed-off-by: Juan Pablo MONTERO CASTRO <juanpablo.monterocastro@nxp.com>
[Julien: split original commit 2/3]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 1ce2484a8b)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Since commit [1] "package/binutils: make 2.43 the default version",
the freescale_t1040d4rdb_defconfig fails to build the Linux
kernel, with the error:
arch/powerpc/boot/util.S: Assembler messages:
arch/powerpc/boot/util.S:49: Error: junk at end of line, first unrecognized character is `0'
arch/powerpc/boot/util.S:54: Error: syntax error; found `b', expected `,'
arch/powerpc/boot/util.S:54: Error: junk at end of line: `b'
This commit fixes the issue by updating the Linux kernel to the latest
LTS version.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/9967089767
[1] 360fd01de2
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 6ad8090920)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The last usage of each_product() was removed in commit
52ae092046 ("support/scripts/cve.py: use
the JSON data in 1.1 schema").
Since it's now unused, remove it.
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit d0a7a46813)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Since the bump of rpm from 4.17.0 to 4.18.0 in Buildroot commit
4b4046e919, tools/rpmuncompress.c uses
basename() without including <libgen.h> which causes a build failure
with the musl C library:
tools/rpmuncompress.c: In function ‘doUntar’:
tools/rpmuncompress.c:100:30: error: implicit declaration of function ‘basename’ [-Wimplicit-function-declaration]
100 | const char *bn = basename(fn);
| ^~~~~~~~
tools/rpmuncompress.c:100:30: error: initialization of ‘const char *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
make[4]: *** [Makefile:1082: tools/rpmuncompress.o] Error 1
This issue was not found by the autobuilders, but it can be reproduced
with:
BR2_arm=y
BR2_cortex_a9=y
BR2_ARM_ENABLE_VFP=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV7_EABIHF_MUSL_BLEEDING_EDGE=y
BR2_PACKAGE_LUA=y
BR2_PACKAGE_RPM=y
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 745aa4d060)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
GCC 14.x brought some more strict checks on pointer types, causing a
build issue in the rpm package when python support is enabled. These
issues have been fixed upstream, initially because Clang >= 16 also
added similar stricter checks.
The build issue goes like this:
header-py.c:744:9: error: initialization of 'Py_hash_t (*)(PyObject *)' {aka 'int (*)(struct _object *)'} from incompatible pointer type 'long int (*)(PyObject *)' {aka 'long int (*)(struct _object *)'} [-Wincompatible-pointer-types]
744 | hdr_hash, /* tp_hash */
| ^~~~~~~~
header-py.c:744:9: note: (near initialization for 'hdr_Type.tp_hash')
make[3]: *** [Makefile:664: header-py.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
It never happened in the autobuilders, but it can be reproduced with
the following configuration:
BR2_arm=y
BR2_cortex_a9=y
BR2_ARM_ENABLE_VFP=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_PACKAGE_LUA=y
BR2_PACKAGE_PYTHON3=y
BR2_PACKAGE_RPM=y
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 67e10ac898)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
If an attempt is made to create a UBI volume and it already exists, the
operation fails. Therefore, before requesting the creation of a UBI
volume, we erase the entire NAND to ensure that no errors occur.
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 97ac89eb11)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The V4L2 code in the ffmpeg plugin uses V4L2_PIX_FMT_BGRA32 which was
only introduced in kernel headers 5.2, in upstream kernel commit
e25ec9141114c7124eeba09385e272dd76fbe617.
Fixes:
/home/thomas/buildroot/buildroot/outputs/qt/build/qt6multimedia-6.8.1/src/plugins/multimedia/ffmpeg/qv4l2camera.cpp:36:43: error: ‘V4L2_PIX_FMT_BGRA
32’ was not declared in this scope; did you mean ‘V4L2_PIX_FMT_BGR32’?
36 | { QVideoFrameFormat::Format_BGRA8888, V4L2_PIX_FMT_BGRA32 },
| ^~~~~~~~~~~~~~~~~~~
| V4L2_PIX_FMT_BGR32
when building:
BR2_arm=y
BR2_cortex_a9=y
BR2_ARM_ENABLE_VFP=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV7_EABIHF_MUSL_STABLE=y
BR2_PACKAGE_QT6=y
BR2_PACKAGE_QT6BASE_XCB=y
BR2_PACKAGE_QT6MULTIMEDIA=y
BR2_PACKAGE_QT6MULTIMEDIA_FFMPEG=y
BR2_PACKAGE_XORG7=y
at a time when the Bootlin stable toolchain was using Linux 4.19
headers.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
(cherry picked from commit fe783b16b3)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The following defconfig:
BR2_arm=y
BR2_cortex_a9=y
BR2_ARM_ENABLE_VFP=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV7_EABIHF_MUSL_STABLE=y
BR2_PACKAGE_QT6=y
BR2_PACKAGE_QT6BASE_XCB=y
BR2_PACKAGE_QT6MULTIMEDIA=y
BR2_PACKAGE_QT6MULTIMEDIA_FFMPEG=y
BR2_PACKAGE_XORG7=y
would fail to build, due to <X11/extensions/Xext.h> being not found,
and then <X11/extensions/Xrandr.h> being not found. Fix that up by
introducing the necessary dependencies.
There are no build failures reported for qt6multimedia in the
autobuilders, so there is no reference to a build failure.
Signed-off-by: Roy Kollen Svendsen <roykollensvendsen@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
(cherry picked from commit 04d1ee0105)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Fixes:
ERROR: Feature "xcb": Forcing to "ON" breaks its condition:
QT_FEATURE_thread AND TARGET XCB::XCB AND TEST_xcb_syslibs AND QT_FEATURE_xkbcommon_x11
Condition values dump:
QT_FEATURE_thread = "ON"
TARGET XCB::XCB found
TEST_xcb_syslibs = "FALSE"
QT_FEATURE_xkbcommon_x11 not evaluated
The xcb feature is defined in [2].
According to [1] XCB::CURSOR is needed for xcb support.
[1] https://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/configure.cmake?h=6.9.0#n522
[2] https://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/configure.cmake?h=6.9.0#n1016
This bug was introduced in e634be8906,
and fixes the build with the following defconfig:
BR2_arm=y
BR2_cortex_a9=y
BR2_ARM_ENABLE_VFP=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV7_EABIHF_MUSL_STABLE=y
BR2_PACKAGE_QT6=y
BR2_PACKAGE_QT6BASE_GUI=y
BR2_PACKAGE_QT6BASE_XCB=y
BR2_PACKAGE_XORG7=y
Signed-off-by: Roy Kollen Svendsen <roykollensvendsen@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
(cherry picked from commit adff0d37ba)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Buildroot packaging pretty much assumes that the sources it downloads
are publicly available. In general, however, Buildroot is also used to
download sources from private repositories. Nowadays, that mostly means
from a github or gitlab instance.
Although git-over-ssh can be used for that, this poses a problem for CI,
because the CI runners integrated with github and gitlab only have
access to the repository itself, not to other private repositories. And
creating ssh key pairs for CI runners is tricky.
Therefore, document how standard tools can be used to make private
repositories available both to developers and to CI. There are quite a
few alternative approaches possible, but they're more complicated or
less generically applicable.
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
[Peter: Fix insteadOf example, capitalize SSH/HTTPS]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 1026abbcf9)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Fixup S20audit to pass shellcheck -oall and check-package. The file now
closely resembles package/busybox/S01syslogd.
Tested with qemu_x86_64_defconfig. start, stop, restart, reload, and rotate
all work with busybox ash shell.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
[Arnout: remove it from .checkpackageignore]
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
(cherry picked from commit cbabeb5077)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The new version bundles an updated gnulib that includes support for
-std=c23 which is the default for gcc 15.
Signed-off-by: Vincent Fazio <vfazio@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
(cherry picked from commit d9aabc1af3)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Commit 7dd56b6cd9 ("boot/grub2/readme.txt: don't specify /dev/loop0")
changed the description of the loopback mounting to use losetup -f <img>,
but forgot to add the --show option, causing losetup to not print the
loopback device name.
Fix that by adding the --show option.
Signed-off-by: Cherniaev Andrei <dungeonlords789@naver.com>
[Peter: Reword commit message]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit a480ae9ffe)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Currently, list-defconfigs only lists the defconfigs that live
live in the top-level configs/ directory. For the in-tree defconfigs
this is indeed the case, but it is possible to manage the configs in a
br2-external tree with sub-directories.
A few examples:
- for a given board, a first defconfig is the full system, and a
second is the rescue system;
- for a given board, two defconfigs implement an A/B feature set;
- a set of configurations targetting various famillies of systems each
running on different hardware, sorted per familly.
Extend list-defconfigs to look for and report defconfigs in
sub-directories of the top-level configs/.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
(cherry picked from commit 5009fd2436)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Note: this test was not working in Buildroot test infrastructure
before commit [1] was merged, because dieharder has the string "# "
in its output.
[1] 0cad947b96
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
(cherry picked from commit e9498b4faa)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
PYTHON_FOO_BUILD_OPTS are passed to the build module call of the package
build, this allows passing options to the python build *backend* by
using the --config-setting= option. setup.py is no longer involved since
even the setuptools backend now used the pep517 build method.
The note about the options being passed to
support/scripts/pyinstaller.py seems to be no longer accurate.
Signed-off-by: Marcus Hoffmann <buildroot@bubu1.eu>
[Arnout: also mention -C (suggested by James)]
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
(cherry picked from commit b15cd1d8fe)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
While in theory, the fastapi tests finds problems with the pydantic
package, it's not obvious that this test should be run when the pydantic
package is updated.
Add a new test that just covers pydantic.
Signed-off-by: Marcus Hoffmann <buildroot@bubu1.eu>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
(cherry picked from commit 45321879e1)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
