libxcrypt has been added as a replacement for the libcrypt
implementation that was part of glibc, but dropped from glibc starting
from version 2.39.
However, libxcrypt was made available for all C libraries, and this is
unfortunately causing some problems as it can clash with the libcrypt
implementation provided by the C library.
In particular, linux-pam has been consistently failing with uclibc, in
BR2_PER_PACKAGE_DIRECTORIES=y builds, with the following build
failure:
opasswd.c: In function 'compare_password':
opasswd.c:133:27: error: invalid application of 'sizeof' to incomplete type 'struct crypt_data'
What happens is relatively tricky, but let's try to break it down:
- uclibc-ng install a stub libcrypt.a (no shared variant, as for
shared libraries, everything is in libc.so), and crypt.h
- libxcrypt installs libcrypt.so.* and crypt.h
So there is no "clash" on the library itself, but there is a clash on
the header file.
Since we're using BR2_PER_PACKAGE_DIRECTORIES=y, when building
linux-pam, we are creating the per-package STAGING_DIR by copying the
STAGING_DIR of linux-pam dependencies, i.e both the libxcrypt
STAGING_DIR and the uclibc-ng STAGING_DIR. But the latter ends up
being copied last, which means that at the end of the day, we have in
the per-package STAGING_DIR of linux-pam:
- The libcrypt.so from libxcrypt
- The crypt.h header from uclibc-ng
- The libcrypt.a from uclibc-ng
When the ./configure script of linux-pam tests whether the library has
crypt_r(), it concludes that yes it's available: and indeed
libcrypt.so from libxcrypt has it.
So it tries to use 'struct crypt_data' and 'crypt_r()', but those are
not supported in uClibc-ng, and so cannot be found in the <crypt.h>
header. So even if the ./configure script and the linux-pam code has
some logic to fallback to crypt() if crypt_r() isn't available, this
fallback doesn't trigger because the installed libcrypt.so does have
crypt_r().
Basically what happens is that uclibc-ng + libxcrypt is a combo that
violates a golden rule of our BR2_PER_PACKAGE_DIRECTORIES=y
implementation: packages shouldn't overwrite files from each other.
To avoid this situation, we make libxcrypt only installable on
glibc. This isn't a problem because as of today, BR2_PACKAGE_LIBXCRYPT
is always selected "if BR2_TOOLCHAIN_USES_GLIBC".
It should be noted though that the case of an older glibc (which still
had its own internal libcrypt) + libxcrypt continues to exist. It's
less likely to cause trouble though, as the libcrypt implementations
are much more similar.
Fixes:
http://autobuild.buildroot.net/results/560f66b0311d02dc884732221d6870ae3c38067c/
Note: we do not add a Config.in comment for this glibc dependency,
because libxcrypt really is a "replacement" library to fill in the
void left by libcrypt's removal from glibc. There isn't realy a point
showing "libxcrypt needs a toolchain w/ glibc", because with musl or
uclibc-ng, the libcrypt functionality is directly part of the C
library.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 5c0a91f729)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
We are seeing build issues with linux-pam in the autobuilders such as:
md5_crypt.c: In function 'Goodcrypt_md5':
md5_crypt.c:145:13: error: implicit declaration of function 'asprintf'; did you mean 'vsprintf'? [-Wimplicit-function-declaration]
145 | if (asprintf(&passwd, "%s%.*s$%s", magic, sl, sp, buf) < 0)
| ^~~~~~~~
| vsprintf
This is due to the fact that <stdio.h> gets included without
_GNU_SOURCE being defined, and so the prototype of asprintf() is not
accessible, at least with uclibc-ng.
The _GNU_SOURCE definition is properly in linux-pam's config.h, but
config.h doesn't get properly included first everywhere. This issue
has been fixed upstream in the mean time, so we simply backport the
upstream patch.
Fixes:
http://autobuild.buildroot.net/results/49b190b3fbae3cdca4c7a08b3ab5100a937ede9e/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 001e777d50)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Buildroot commit
1f4b4ccde7 ("package/opensc: security
bump to version 0.26.0") bumped opensc from 0.24 to 0.26, and the
build started failing with:
pkcs11-tool.c:7854:45: warning: implicit declaration of function 'EVP_bf_cbc'; did you mean 'EVP_sm4_cbc'? [-Wimplicit-function-declaration]
on configurations that have BR2_PACKAGE_LIBOPENSSL_ENABLE_BLOWFISH
disabled (it is not explicitly selected by this package).
Our initial fix was to simply select
BR2_PACKAGE_LIBOPENSSL_ENABLE_BLOWFISH, but when investigating when
EVP_bf_cbc() started being used in OpenSC, we discovered it has been
in use for a while... but in code that kept being disabled from
version to version as it was broken (upstream bug
https://github.com/OpenSC/OpenSC/issues/1796), but it was apparently
forgotten to be disabled again for 0.26 (the issue is still
open). Therefore, we opted to continue disabling this known broken
part of the code, and submit an upstream PR for that
https://github.com/OpenSC/OpenSC/pull/3303, which ultimately will
clarify what is the right fix.
In the mean time, this allows to fix the build issue.
Fixes:
http://autobuild.buildroot.net/results/ca51b3e8e3ac83e2a69814caa84d9862385b956f/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 5d7ab604d2)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since commit 9c0c7846cd (support/dependencies: don't check for python
on the host), we no longer check for a host python interpreter installed
on the system.
Drop the comment in support/dependencies/check-host-python3.sh, as it is
now confusing.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 3722998a3d)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit ed12e2fbed (package/libvirt: add lxc and qemu options)
introduced the definition of the 'qemu' user when the libvirt daemon
is enabled, but unconditionally uses that user in its permissions
table.
When enabling libvirt without its qemu support, for example with the
commands:
cat <<EOF >.config
BR2_aarch64=y
BR2_PACKAGE_LIBVIRT=y
BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV=y
BR2_TARGET_ROOTFS_EXT2=y
BR2_TOOLCHAIN_EXTERNAL=y
EOF
make olddefconfig
make
The build fails with output:
>>> Generating filesystem image rootfs.ext2
...
makedevs: unknown user name: qemu
Move the permissions needing the 'qemu' user under the same condition
the 'qemu' user is defined under. It means that a few permissions
needing root must also be moved, as they belong under a directory
needing the 'qemu' user. It also moves a few qemu-related permissions
introduced in that same commit. The list of qemu permissions is
reordered alphabetically (the others are left unchanged).
Of course, it also requires that the qemu-related directory and symlink
be moved under the same condition as well.
Reported-by: Alessandro <alex@0x65c.net>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Jared Bents <jared.bents@rockwellcollins.com>
[Julien: add the commands to reproduce the issue]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit da9adec149)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
It is very common to use the output of get-developers to add cc: lines
in the commit log.
Add an option so that get-developers reports Cc: lines ready to be
pasted in a commit log. That new option behaves similarly to the
existing -e option: it only affects the output when parsing a patch.
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Julien Olivain <ju.o@free.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 717f1fdaeb)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The list of reported developers is not ordered: that may leave the
impression (when receiving a patch) that a Cc is more important than
another, by virtue of being earlier in the list.
Also, the ordering changes on every call.
Report the developers in an alphabetically order, so that there is no
confusion anymore, and so the ordering is reproducible across calls.
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 3177ecd260)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
It is very common that get-developers be used with its stdin a pipe from
git-show:
git show |./utils-get-developers -
In this case, the '-' is superfluous: we can very easily deduce that the
user wants to read stdin as the patch.
So, if no other action was requested, and stdin is not a tty, use it as
the source of the patch, and thus '-' is then no longer required.
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit d10d22221f)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
parser.error() reports a nice error message, that also displays a short
reminder of the available options.
Adapt the test-suite accordingly: previously, the error string was an
exact string in the stdout list, while it now is a substring in one of
the strings in stderr. The exit code changes, too.
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Julien Olivain <ju.o@free.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 35f381b93e)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Offloading parser.parse_args() to a helper function does not bring much,
if at all; it even is restrictive: indeed, we can't use parser.error()
to report errors and thus have to resort to a canned print+return
sequence...
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit cdcb3f56e8)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The variable <pkg>_LINUX_CONFIG_FIXUPS defined in the
cryptodev-linux... has no effect. Indeed, the variable is only named
CRYPTODEV_LINUX_CONFIG_FIXUPS.
But the variable name being <pkg>_LINUX_CONFIG_FIXUPS and the package
name being CRYPTODEV_LINUX, the correct variable name is
CRYPTODEV_LINUX_LINUX_CONFIG_FIXUPS.
Prior to this commit, a configuration with cryptodev-linux enabled
would result in:
$ make VARS=PACKAGES_LINUX_CONFIG_FIXUPS printvars
$
Aka, empty, while PACKAGES_LINUX_CONFIG_FIXUPS collects in
package/pkg-generic.mk the value of the <pkg>_LINUX_CONFIG_FIXUPS
variables from all enabled packages.
With this patch applied:
$ make VARS=PACKAGES_LINUX_CONFIG_FIXUPS printvars
PACKAGES_LINUX_CONFIG_FIXUPS= @if ! grep -q '^CONFIG_CRYPTO=[my]' /; then /usr/bin/sed -i -e '/^\(# \)\?CONFIG_CRYPTO\>/d' / && echo 'CONFIG_CRYPTO=y' >> /; fi
@if ! grep -q '^CONFIG_CRYPTO_USER_API_AEAD=[my]' /; then /usr/bin/sed -i -e '/^\(# \)\?CONFIG_CRYPTO_USER_API_AEAD\>/d' / && echo 'CONFIG_CRYPTO_USER_API_AEAD=y' >> /; fi
$
As one would expect.
Fixes: 4b12336d1f ("package/cryptodev-linux: needs CONFIG_CRYPTO_USER_API_AEAD")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 9114d48b31)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since the bump of xxhash from 0.8.2 to 0.8.3 in Buildroot commit
4b8f2f3a5e, the host of host-php fails
when host-xxhash has been built before.
This is due to the fact that host-xxhash installs
HOST_DIR/include/xxhash.h, and the PHP code has an internal xxhash.h,
but due to the order of CFLAGS, the one from HOST_DIR/include/xxhash.h
gets included instead of the internal xxhash.h from PHP.
We initially tried to fix the order of CFLAGS, but that has proven to
be challenging within the complicated PHP build system. Then, we opted
for renaming the internal xxhash.h header of PHP, which we had
implemented and were about to submit upstream. But while rebasing this
fix on PHP's master, it turned out that PHP has an upstream commit
"Sync headers installation", merged for PHP 8.4.0, which has the side
effect of avoiding the issue. This commit moves xxhash.h into a
subfolder, so it gets included as #include "xxhash/xxhash.h" now,
which avoids the conflict with HOST_DIR/include/xxhash.h. Maybe not
the best fix, but it does fix the issue and it's upstream.
Since this patch is tweaking the PHP build system, we need to do the
equivalent of "autoreconf" but in the PHP world. It was already done
for the target package, we simply add the same logic for the host
package.
Fixes:
http://autobuild.buildroot.net/results/583c054a564f90b8c884565070c5e17b43b89674/
Cc: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 3a20dfb426)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
pixman fails to build with -Og or -O3 due to forced inlining
statements:
pixman-combine-float.c:370:5: error: inlining failed in call to 'always_inline' 'combine_soft_light_c': function not considered for inlining
The first occurence in the autobuilders is on May 12, 2024, but the
problem already existed before as we haven't updated pixman in a long
time. Therefore, the issue started occurring because we started
testing more random configurations.
Fixes:
https://autobuild.buildroot.org/results/2f3df7961b3181d9eef79893439ae7ebbe4415ad/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 696de595e0)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Setting CONFIG_VIDEO_DEV is no sufficient as drivers/media/Kconfig has
some very convoluted logic to hide some options behind a
CONFIG_MEDIA_SUPPORT_FILTER option, unless CONFIG_EXPERT is
enabled. Due to this, several arch defconfigs don't have
CONFIG_VIDEO_DEV enabled when doing $(call
KCONFIG_ENABLE_OPT,CONFIG_VIDEO_DEV).
To fix this, we enable one of the possible options that ensures
CONFIG_VIDEO_DEV is enabled, and we've more or less arbitrarily chosen
CONFIG_MEDIA_CAMERA_SUPPORT.
Fixes:
http://autobuild.buildroot.net/results/2a337d29e7870564027bcd42bd0addd228eb6a24/
We've tried to track down which kernel version introduced this
exactly, but it's been introduced a while ago and step by step making
it difficult to pin-point which version version exactly introduced
this. But the issue has been appearing for quite some time in the
autobuilders, so it's clearly not a recent issue.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 75d418b59d)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
HOST_CFLAGS and HOST_LDFLAGS are currently not accounted for when
building host-perl. In particular, it means that executables
built/installed by host-perl do not have a RPATH pointing to
HOST_DIR/lib, which can cause issues as libcrypt.so can now be
provided by host-libxcrypt.
This was causing check-host-rpath to complain in the situation where:
1. host-perl was built, with no RPATH, linked against the system
libcrypt.so
2. host-libxcrypt was built afterwards, installed as
HOST_DIR/lib/libcrypt.so, which made check-host-rpath complain as
HOST_DIR/bin/perl is linked against a library present in
HOST_DIR/lib but doesn't have a RPATH to HOST_DIR/lib
Fixes:
http://autobuild.buildroot.net/results/d4348d7f872ccd734795a1d071960a696148ed6a/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Acked-by: Francois Perrad <francois.perrad@gadz.org>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 65127a8a77)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Newer versions of U-Boot (2024.10 and newer) will require the GnuTLS
library to be installed on the host machine to build the mkeficapsule
tool for U-Boot's image packaging phase to generate the final capsule
for all the boot images including the tiboot3.bin image.
Add host-gnutls to the list of dependencies.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/8723483578 (ti_am62x_sk_defconfig)
Signed-off-by: Bryan Brattlof <bb@ti.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit eb9bb65629)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The configurations that have:
- BR2_ENABLE_RUNTIME_DEBUG=y
- One of BR2_FORTIFY_SOURCE_xyz=y
Currently fail to build, as libzenoh-pico's build system forces -O0
when BR2_ENABLE_RUNTIME_DEBUG=y, but -O0 builds aren't compatible with
_FORTIFY_SOURCE, causing:
../../../per-package/libzenoh-pico/host/mips64-buildroot-linux-gnu/sysroot/usr/include/features.h:422:4: error: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Werror=cpp]
422 | # warning _FORTIFY_SOURCE requires compiling with optimization (-O)
| ^~~~~~~
cc1: all warnings being treated as errors
We fix this by adding a patch that drops the forced -O3 (release
builds) and -O0 (debug builds) from the project CMakeLists.txt.
This issue exists since libzenoh-pico was introduced in Buildroot in
commit
a96361901d ("package/libzenoh-pico: new
package"), but was hidden by other issues until a first occurence in
November 2024 right after the bump to 1.0.1:
http://autobuild.buildroot.net/results/f109e8b4aba0286dcaac5cb6d4579e6d91c492f8/
Fixes:
http://autobuild.buildroot.net/results/f109e8b4aba0286dcaac5cb6d4579e6d91c492f8/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 0b785f5b06)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The patch fixes the following errors and warnings raised by the
compilation of libxml2 with the combination of GCC 14.x and uClibc.
encoding.c: In function ‘xmlEncInputChunk’:
encoding.c:2209:32: warning: comparison between pointer and integer
2209 | else if (handler->iconv_in != NULL) {
| ^~
encoding.c: In function ‘xmlEncOutputChunk’:
encoding.c:2269:33: warning: comparison between pointer and integer
2269 | else if (handler->iconv_out != NULL) {
| ^~
encoding.c: In function ‘xmlCharEncCloseFunc’:
encoding.c:2681:29: warning: comparison between pointer and integer
2681 | if ((handler->iconv_out != NULL) || (handler->iconv_in != NULL)) {
| ^~
encoding.c:2681:60: warning: comparison between pointer and integer
2681 | if ((handler->iconv_out != NULL) || (handler->iconv_in != NULL)) {
| ^~
encoding.c:2683:32: warning: comparison between pointer and integer
2683 | if (handler->iconv_out != NULL) {
| ^~
encoding.c:2686:32: error: assignment to ‘iconv_t’ {aka ‘long int’} from ‘void *’ makes integer from pointer without a cast [-Wint-conversion]
2686 | handler->iconv_out = NULL;
| ^
encoding.c:2688:31: warning: comparison between pointer and integer
2688 | if (handler->iconv_in != NULL) {
| ^~
encoding.c:2691:31: error: assignment to ‘iconv_t’ {aka ‘long int’} from ‘void *’ makes integer from pointer without a cast [-Wint-conversion]
2691 | handler->iconv_in = NULL;
| ^
make[4]: *** [Makefile:1147: libxml2_la-encoding.lo] Error 1
This code has been in libxml2 pretty much forever: it was partially
introduced in version 2.1.0: 496a1cf59284 ("496a1cf59284 revamped the
encoding support, added iconv support, so now libxml if") and
partially in version 2.2.3: 87b953957305 ("Large sync between my W3C
base and Gnome's one:"). And the first time Buildroot packaged
libxml2, it was version 2.6.29.
However, both glibc and musl define iconv_t as "void *", which meant
the libxml2 code was not problematic. uClibc defines iconv_t as
"long", which generated only a warning... until GCC got updated to GCC
14.x, which turned this warning into an error, causing the build
failure.
Fixes:
http://autobuild.buildroot.net/results/fd4f8d2e8d8ee68d9e18f761ceff350188e55a87/
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit ca63c4409b)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The handling of BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG is currently
not doing a proper job: it is selecting ppc64le_defconfig if
BR2_powerpc64le, and using the default of "defconfig" for everything
else.
However:
- Since upstream commit 22f17b02f88b48c01d3ac38d40d2b0b695ab2d10,
which landed in Linux 6.8, the default defconfig is
ppc64le_defconfig and no longer ppc64_defconfig. This means that
despite the condition in linux.mk, we are in fact now always
building ppc64le_defconfig.
- It doesn't handle the 32-bit case, as a 64-bit defconfig gets used
by default. This causes build failures in the autobuilders.
To fix this we explicitly handle BR2_powerpc64le, BR2_powerpc64 and
BR2_powerpc, and use appropriate defconfigs for each case.
Fixes:
http://autobuild.buildroot.net/results/c15eaf2e7455aa265cc045e6d8be7cac5348d925/ (powerpc)
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 82326a3d83)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In the latest kernel, U-Boot images are always generated when building
a kernel for NIOS2. Note that we build the kernel with:
make all
make <selected-image>
so the selected image through Buildroot options doesn't matter: a
U-Boot image is always generated.
Therefore, in order to fix autobuilder issues, make sure
host-uboot-tools are always selected when building the latest kernel
version. We do not select it in general as custom versions may be
different.
Fixes:
http://autobuild.buildroot.net/results/1d4c249887bdd78dab40152ad3a4fcef16458a1a/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit d94c478ebc)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The datafiles include the dbus policy, without which bluetoothd fails
to start (unless it is provided by other means):
# /usr/libexec/bluetooth/bluetoothd -n
bluetoothd[1011]: Bluetooth daemon 5.78
D-Bus setup failed: Connection ":1.7" is not allowed to own the service "org.bluez" due to security policies in the configuration file
bluetoothd[1011]: src/main.c:main() Unable to get on D-Bus
The installation issue 1a8676aa6e was
meant to fix is the result of upstream incorrectly installing
/etc/bluetooth with 0555 (strictly read-only) permissions.
Fixes: 1a8676aa6e
Signed-off-by: Fiona Klute (WIWA) <fiona.klute@gmx.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 421a92a897)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This is a basic test for Xvisor RISC-V 64bit. It is running few
management and status commands. It does not start a Linux kernel.
RISC-V 64bit was chosen for this test because it was the simplest
solution to run xvisor in a qemu emulator.
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit e14380b3c4)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Building on a s390x host, we currently end up with:
output/host/lib
output/host/lib32 -> lib
output/host/lib64
host-libopenssl installs to lib64, but since the kernel build doesn't
explicitly search there, it breaks:
>>> linux 6.6.32 Building
[...]
HOSTCC scripts/sign-file
/usr/bin/ld: cannot find -lcrypto: No such file or directory
collect2: error: ld returned 1 exit status
Fix this by creating a lib64 link instead of lib32, so we get:
output/host/lib
output/host/lib64 -> lib
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 66a5f9bc74)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
From
https://lists.freedesktop.org/archives/wayland-devel/2024-October/043858.html:
This is Weston 14.0.1, a bug-fix release. Most of the fixes here are
addressing some build issues with a C++ compiler, but also addressing a
more critical issue that was causing the gtk4 test suite or other clients
to crash when using the headless backend.
Some distros already carry a patch to address that, but in case they
have not, this would be a good time to update.
David Edmundson (1):
libweston: Send seat name before announcing devices
EatingSumo (1):
libweston/screenshooter: Fix build when __builtin_clz is not available
Jan Alexander Steffens (heftig) (1):
libweston/noop-renderer: Check shm_buffer for NULL
Jan Engelhardt (1):
build: insert missing wayland-server-protocol dependency
Jeri Li (1):
libweston/desktop: avoid weston crash while xdg_surface ack_configure
Marius Vlad (4):
libweston: Move weston_get_backend_type after enum declaration
desktop-shell: Don't attempt to re-add the view to panel layer
libweston/matrix: Fix narrow conversion with C++
build: bump to version 14.0.1 for the point release
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 6f74ee11b4)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
From
https://lists.freedesktop.org/archives/wayland-devel/2024-August/043760.html:
This is a bugfix release for Wayland 1.23.
Joaquim Monteiro (1):
meson: Fix use of install_data() without specifying install_dir
Kirill Primak (1):
Put WL_DEPRECATED in front of the function declarations
Sebastian Wick (1):
client: Handle proxies with no queue
Simon Ser (4):
scanner: extract validator function emission to helper function
scanner: fix validator for bitfields
tests: add enum bitfield test
build: bump version to 1.23.1 for the bugfix release
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit f27dcb9310)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since the python-autocommand package has been introduced in commit
b6f3278539 ("package/python-autocommand:
new package"), it has consistently been failing to build with:
Traceback (most recent call last):
File "/home/autobuild/autobuild/instance-12/output-1/host/lib/python3.12/site-packages/pyproject_hooks/_in_process/_in_process.py", line 353, in <module>
main()
File "/home/autobuild/autobuild/instance-12/output-1/host/lib/python3.12/site-packages/pyproject_hooks/_in_process/_in_process.py", line 335, in main
json_out['return_val'] = hook(**hook_input['kwargs'])
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/autobuild/autobuild/instance-12/output-1/host/lib/python3.12/site-packages/pyproject_hooks/_in_process/_in_process.py", line 118, in get_requires_for_build_wheel
return hook(config_settings)
^^^^^^^^^^^^^^^^^^^^^
File "/home/autobuild/autobuild/instance-12/output-1/host/lib/python3.12/site-packages/setuptools/build_meta.py", line 327, in get_requires_for_build_wheel
return self._get_build_requires(config_settings, requirements=[])
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/autobuild/autobuild/instance-12/output-1/host/lib/python3.12/site-packages/setuptools/build_meta.py", line 297, in _get_build_requires
self.run_setup()
File "/home/autobuild/autobuild/instance-12/output-1/host/lib/python3.12/site-packages/setuptools/build_meta.py", line 497, in run_setup
super().run_setup(setup_script=setup_script)
File "/home/autobuild/autobuild/instance-12/output-1/host/lib/python3.12/site-packages/setuptools/build_meta.py", line 313, in run_setup
exec(code, locals())
File "<string>", line 8, in <module>
File "/home/autobuild/autobuild/instance-12/output-1/host/lib/python3.12/site-packages/setuptools/__init__.py", line 108, in setup
return distutils.core.setup(**attrs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/autobuild/autobuild/instance-12/output-1/host/lib/python3.12/site-packages/setuptools/_distutils/core.py", line 158, in setup
dist.parse_config_files()
File "/home/autobuild/autobuild/instance-12/output-1/host/lib/python3.12/site-packages/setuptools/dist.py", line 632, in parse_config_files
pyprojecttoml.apply_configuration(self, filename, ignore_option_errors)
File "/home/autobuild/autobuild/instance-12/output-1/host/lib/python3.12/site-packages/setuptools/config/pyprojecttoml.py", line 71, in apply_configuration
return _apply(dist, config, filepath)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/autobuild/autobuild/instance-12/output-1/host/lib/python3.12/site-packages/setuptools/config/_apply_pyprojecttoml.py", line 53, in apply
_apply_project_table(dist, config, root_dir)
File "/home/autobuild/autobuild/instance-12/output-1/host/lib/python3.12/site-packages/setuptools/config/_apply_pyprojecttoml.py", line 79, in _apply_project_table
corresp(dist, value, root_dir)
File "/home/autobuild/autobuild/instance-12/output-1/host/lib/python3.12/site-packages/setuptools/config/_apply_pyprojecttoml.py", line 181, in _license
_set_config(dist, "license", val["text"])
~~~^^^^^^^^
KeyError: 'text'
This is due to incorrect license information in pyproject.toml. This
was probably missed as the package was merged ~6 months after it was
submitted, so probably at the time it was submitted, it worked fine,
but got broken with more recent versions of setuptools.
Fixes:
http://autobuild.buildroot.net/results/c9114834eb00569cdb8ec3251ccd5ecfd906c9c9/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 621ebccf3f)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following security issue:
CVE-2024-11614: An out-of-bounds read vulnerability was found in DPDK's
Vhost library checksum offload feature. This issue enables an untrusted or
compromised guest to crash the hypervisor's vSwitch by forging Virtio
descriptors to cause out-of-bounds reads. This flaw allows an attacker with
a malicious VM using a virtio driver to cause the vhost-user side to crash
by sending a packet with a Tx checksum offload request and an invalid
csum_start offset.
https://www.openwall.com/lists/oss-security/2024/12/17/3
Release notes: http://doc.dpdk.org/guides-24.11/rel_notes/release_24_11.html
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 3645e3b781)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following security vulnerabilities:
CVE-2022-33065: Multiple signed integers overflow in function au_read_header
in src/au.c and in functions mat4_open and mat4_read_header in src/mat4.c in
Libsndfile, allows an attacker to cause Denial of Service or other
unspecified impacts.
CVE-2024-50612: libsndfile through 1.2.2 has an ogg_vorbis.c
vorbis_analysis_wrote out-of-bounds read.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit e675ffd964)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes CVE-2023-49582: Lax permissions set by the Apache Portable Runtime
library on Unix platforms would allow local users read access to named
shared memory segments, potentially revealing sensitive application data.
This issue does not affect non-Unix platforms, or builds with
APR_USE_SHMEM_SHMGET=1 (apr.h) Users are recommended to upgrade to APR
version 1.7.5, which fixes this issue.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit a60c38b381)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes build error
/home/buildroot/buildroot/output/build/wpewebkit-2.44.4/Source/WTF/wtf/StackBounds.cpp: In static member function 'static WTF::StackBounds WTF::StackBounds::newThreadStackBounds(WTF::PlatformThreadHandle)':
/home/buildroot/buildroot/output/build/wpewebkit-2.44.4/Source/WTF/wtf/StackBounds.cpp:117:5: error: 'pthread_getattr_np' was not declared in this scope; did you mean 'pthread_attr_t'?
117 | pthread_getattr_np(thread, &sattr);
using this defconfig (and libvpx bump to 1.15.0 reverted)
BR2_arm=y
BR2_TOOLCHAIN_BUILDROOT_UCLIBC=y
BR2_TOOLCHAIN_BUILDROOT_WCHAR=y
BR2_PTHREADS=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_PER_PACKAGE_DIRECTORIES=y
BR2_PACKAGE_RPI_USERLAND=y
BR2_PACKAGE_LIBGTK3=y
BR2_PACKAGE_WPEWEBKIT=y
A backport of this patch should be considered because the code is
present since 2011:
https://github.com/WebKit/WebKit/blame/03f678fac7076e4d69318bfaae065e4c0eab0f9e/Source/WTF/wtf/StackBounds.cpp#L117
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 9f4a95e5c6)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes build error
/home/buildroot/buildroot/output/build/webkitgtk-2.44.2/Source/WTF/wtf/StackBounds.cpp: In static member function 'static WTF::StackBounds WTF::StackBounds::newThreadStackBounds(WTF::PlatformThreadHandle)':
/home/buildroot/buildroot/output/build/webkitgtk-2.44.2/Source/WTF/wtf/StackBounds.cpp:117:5: error: 'pthread_getattr_np' was not declared in this scope; did you mean 'pthread_attr_t'?
117 | pthread_getattr_np(thread, &sattr);
using this defconfig (and libvpx bump to 1.15.0 reverted)
BR2_arm=y
BR2_TOOLCHAIN_BUILDROOT_UCLIBC=y
BR2_TOOLCHAIN_BUILDROOT_WCHAR=y
BR2_PTHREADS=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_PER_PACKAGE_DIRECTORIES=y
BR2_PACKAGE_XORG7=y
BR2_PACKAGE_RPI_USERLAND=y
BR2_PACKAGE_LIBGTK3=y
BR2_PACKAGE_WEBKITGTK=y
A backport of this patch should be considered because the code is
present since 2011:
https://github.com/WebKit/WebKit/blame/03f678fac7076e4d69318bfaae065e4c0eab0f9e/Source/WTF/wtf/StackBounds.cpp#L117
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 054e5c4d22)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes build error
-- Could NOT find LibDRM (missing: LibDRM_INCLUDE_DIR LibDRM_LIBRARY)
CMake Error at Source/cmake/OptionsGTK.cmake:320 (message):
libdrm is required for USE_LIBDRM
Call Stack (most recent call first):
Source/cmake/WebKitCommon.cmake:237 (include)
CMakeLists.txt:21 (include)
with this defconfig:
BR2_arm=y
BR2_TOOLCHAIN_BUILDROOT_UCLIBC=y
BR2_TOOLCHAIN_BUILDROOT_WCHAR=y
BR2_PTHREADS=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_PER_PACKAGE_DIRECTORIES=y
BR2_PACKAGE_XORG7=y
BR2_PACKAGE_RPI_USERLAND=y
BR2_PACKAGE_LIBGTK3=y
BR2_PACKAGE_WEBKITGTK=y
due to libdrm being enabled by default:
https://github.com/WebKit/WebKit/blob/f736325e66bfa8e85f85387299448476f3e1fb3c/Source/cmake/OptionsGTK.cmake#L59
This is a port of buildroot commit 65f8174648
for the wpewebkit package, quoting its commit message:
Pass USE_LIBDRM=OFF to the wpewebkit CMake configuration step when the
libdrm package has not been selected.
WPE WebKit can be built without libdrm support, and it will still work
with backends that use other platform-specific methods to handle
graphics buffers and/or presenting content onto an output. For example
this is the case with wpebackend-rdk configured to use rpi-userland,
which uses dispmanx to produce the output instead of DRM/KMS.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 865457e762)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes:
http://autobuild.buildroot.net/results/23f0f7386f7d430c402b24f3b58b1c20c1c8344a/
Linux commit d69d8048459 "driver core: have match() callback in struct
bus_type take a const *", which was added in 6.11-rc1, changed the interface
for sysfs match callback to accept a const struct device_driver, breaking
the build of dahdi-linux:
CC [M] build/dahdi-linux-3.3.0/drivers/dahdi/dahdi-sysfs.o
build/dahdi-linux-3.3.0/drivers/dahdi/dahdi-sysfs.c:275:27: error: initialization
of "int (*)(struct device *, const struct device_driver *)" from incompatible
pointer type "int (*)(struct device *, struct device_driver *)"
[-Werror=incompatible-pointer-types]
275 | .match = span_match,
Add a patch submitted upstream to fix that.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 4533795cde)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following security issues:
CVE-2024-53907: Potential denial-of-service in
django.utils.html.strip_tags()
The strip_tags() method and striptags template filter are subject to a
potential denial-of-service attack via certain inputs containing large
sequences of nested incomplete HTML entities.
CVE-2024-53908: Potential SQL injection in HasKey(lhs, rhs) on Oracle
Direct usage of the django.db.models.fields.json.HasKey lookup on Oracle is
subject to SQL injection if untrusted data is used as a lhs value.
Applications that use the jsonfield.has_key lookup through the __ syntax are
unaffected.
https://www.djangoproject.com/weblog/2024/dec/04/security-releases/
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit c2c1c27d11)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Release notes:
https://lists.gnu.org/archive/html/bug-wget/2024-11/msg00002.html
Fixes the following vulnerabilities:
- CVE-2024-38428: url.c in GNU Wget through 1.24.5 mishandles semicolons in
the userinfo subcomponent of a URI, and thus there may be insecure
behavior in which data that was supposed to be in the userinfo
subcomponent is misinterpreted to be part of the host subcomponent.
https://nvd.nist.gov/vuln/detail/CVE-2024-38428
- CVE-2024-10524: Applications that use Wget to access a remote resource
using shorthand URLs and pass arbitrary user credentials in the URL are
vulnerable. In these cases attackers can enter crafted credentials which
will cause Wget to access an arbitrary host.
https://www.openwall.com/lists/oss-security/2024/11/18/6
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 295b2c4f8e)
[Peter: mark as security bump]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In some specific situations, there is subtle bugs which depends on a
specific Qemu emulator version and the code it runs.
For example, EDK2 on Aarch64 could work with specific versions of Qemu,
EDK2 and ATF. See commit cc0823c2d "boot/edk2: bump to version
edk2-stable202405" [1].
Also, some Qemu bugs made the guest OS crash. See for example commit
9534b9c00 "package/qemu: fix qemu 9.x issue for AArch32 Secure
PL1&0" [2].
Commit 0d4177598 "support/testing/infra/emulator.py: add build host
dir to qemu search path" added the ability for a runtime test to
select host-qemu in order to use it. It is also possible for a user
to use the "utils/run-tests" script on its host system providing its
own version of Qemu. The Buildroot CI can also use its Qemu version
included in the reference Docker image.
This means the Qemu emulator for running a runtime test can be from
several sources:
- Buildroot Docker reference image,
- Buildroot host-qemu package version,
- Developer host OS qemu version.
Those versions can also change in time.
In order to help debugging of those subtle emulator bugs, this commit
adds a recording of the actual Qemu version used to run a test.
[1] https://gitlab.com/buildroot.org/buildroot/-/commit/cc0823c2d14321b91b94801834050331f5ea28e1
[2] https://gitlab.com/buildroot.org/buildroot/-/commit/9534b9c00c23cfd69a4e122c26fca9d3da93d329
[3] https://gitlab.com/buildroot.org/buildroot/-/commit/0d4177598ce7e73f2b97ac58c21fb177343643e3
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit ed9da08944)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The weston runtime test is unreliable, depending on the execution speed
of its runner. Example of failure is [1], and success is [2]. This
commit improves the test in several ways, to make it more robust to
execution speed variations:
- The command started in background (weston, weston-simple-egl) are
now started in a subshell. This suppresses the job control messages
when they are stopped. Those messages could interfere with the parsing
of the output;
- Wait time are moved outside the emulator;
- The kernel argument vt.global_cursor_default=0 is added, to make sure
cursors are globally disabled, since the test use vkms display CRCs;
- The memory of the emulator is increased to 512M. This test uses cpio
initramfs, and the filesystem size increased;
- The vkms driver emulates a "vsync" event, but can generate a warning
when the system is too slow. This warning is printed on the console by
the klogd daemon in its default configuration. This commit adds the
overlay file /etc/default/klogd to limit only kernel emergency
messages to be printed on the console. This change fixes the failure
seen in [1] ;
- Some sleep time values were adjusted to run on a "performant" idle
host. Those values are not suitable in all situations. In the
meantime a generic retry mechanism is added in the test infra, this
commit adds a retry logic inspired from the test_flutter runtime
test.
Fixes: [1]
[1] https://gitlab.com/buildroot.org/buildroot/-/jobs/8562483474
[2] https://gitlab.com/buildroot.org/buildroot/-/jobs/8435236652
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The lmbench package (largely unmaintained upstream, last release in
2006) uses a home-grown build system. The scripts/build script sets
LDLIBS to -lm and Buildroot's makefile changes that to:
LDLIBS+=-lm
Except that when Buildroot passes LDLIBS="`$(PKG_CONFIG_HOST_BINARY)
--libs libtirpc`", the LDLIBS variable ends up being equal to:
-ltirpc-lm
Yes, without any space between -ltirpc and -lm.
Due to this, the checks in scripts/build that use ${LDLIBS} all fail,
and in particular the test that checks when socklen_t is a known type
fails, causing lmbench to provide its own definition, which clashes
with the C library headers definition, and therefore causing build
failures such as:
bench.h:81:13: error: conflicting types for 'socklen_t'; have 'int'
This commit fixes that by adjusting scripts/build using a patch to
properly allow passing additional ${LDLIBS} value, with the needed
space to separate the value from -lm.
Fixes:
http://autobuild.buildroot.net/results/f1715de95b46a1d08143e529bd4574bc7dbcfb3e/
We have been unable to determine exactly when this issue was
introduced. The first build failure we could find is the one
referenced above, which dates back from Aug 19, 2024. Since this date,
lmbench has been consistently failing on a very regular
basis. However, prior to Aug 19, 2024, the previous failure was from
December 2022, and was unrelated. It is unclear what changed in Aug
2024 to cause this issue to surface. The one thing that changed right
before commit ce3dedc2 (first failing commit) are changes to
genrandconfig, which ensures all autobuilders now generated fully
random configurations instead of configurations based on a
well-defined list of arch/toolchain configurations. But even with
this, this lmbench issue should have appeared earlier, and we have
been unable to find a scientific explanation.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The android-tools code base uses the __b64_pton() function, which
isn't provided by all C libraries. So the Debian patch
debian/patches/add_adbd.patch adds an implementation of b64_pton(),
but doesn't actually use it, nor defines a prototype for it. Our
existing patch 0003-Fix-build-issue-with-uclibc.patch switches the
code to use the b64_pton() function... but still without providing a
prototype, causing the following build failures with GCC >= 14.x:
adb_auth_client.c:75:15: error: implicit declaration of function 'b64_pton'
To fix this, we rework 0003-Fix-build-issue-with-uclibc.patch into a
patch that:
(1) Renames b64_pton() to adb_b64_pton() to make sure it won't clash
with implementations provided by some C libraries, and adjusts
the call sites accordingly.
(2) Adds a prototype definition of adb_b64_pton() in places where
this function is used.
Fixes:
http://autobuild.buildroot.net/results/b25b25337c7ad89c33f8bd20b646850bd993ec53ae9/
Even though GCC 14.x support was merged in Buildroot in May 2024, this
particular b64_pton() only started appearing on July 15 2024, with the
first occurence being:
http://autobuild.buildroot.net/results/1cbe87bbe3c56f28444b3aaba1ba1d05f947d36e/
Indeed, it's not before July 15 2024 that we merged commit
d201f2f5cd ("package/android-tools: add
patches to fix build with GCC 14.x"), which fixed other GCC 14.x
issues, which were hiding this b64_pton() problem.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
The kernel headers on mips64 and powerpc64 were historically "broken",
defining u64 as an "unsigned long" instead of "unsigned long
long". This has been fixed in the upstream Linux kernel by introducing
the __SANE_USERSPACE_TYPES__ definition.
Our commit a2e178d6b4 ("android-tools:
disable on some architecture with old kernel headers") already
disabled building fastboot on powerpc64 and mips64 systems that have
too old kernel headers. However, it turns out that even with the new
kernel headers, there are build issues because
__SANE_USERSPACE_TYPES__ isn't defined everywhere it should be in the
android-tools code base. The Debian patche
debian/patches/ppc64el-ftbfs.patch adds some definitions, but it's
missing one file, and in another the definition comes too late.
This commit adds an extra patch that fixes this up, and makes fastboot
build properly on mips64 and powerpc64.
Fixes:
http://autobuild.buildroot.net/results/8528ff876e695f79bdfe64f5330d9d51eeef66cb/ (powerpc64)
http://autobuild.buildroot.net/results/36ac6af73b618c28d1636093da333f7ebd9d6cfe/ (mips64)
This issue has been occurring as far as Feb 2021, with the first
occurence apparently being:
http://autobuild.buildroot.net/results/d9521b4bfeafb1140c21745dbfe28d476a9b71ec/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
This will make it easier to modify the patch series moving forward. No
functional changes.
On one patch, we added the SoB from Giulio, which was missing. Giulio
was the original contributor of the patch, and nobody touched it since
it was introduced.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Upstream moved old versions in an "older" directory. The current version
in Buildroot was moved to this directory and fail to download.
This commit simply updates the _SITE url to reflect this change.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/8514189435
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
losetup -f returns the next free loop device, which may not be
/dev/loop0. If you blindly follow the readmy you may end up destroying
an existing device.
Make it more robust with a variable to store the loop device.
Signed-off-by: Cherniaev Andrei <dungeonlords789@naver.com>
[Arnout: keep the actual losetup atomic]
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
nfs-utils configure script uses "systemd-escape" to determine the
rpc_pipefs mount point unit name in the non-default case.
If the host build system has no systemd this will silently result in an
empty name, causing rpc_pipefs.target to incorrectly depend on ".mount".
Fix that by depending on host-systemd for build.
Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>
Acked-by: Petr Vorel <petr.vorel@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
When the rust package was added in Buildroot it was using
the 1.23.0 release [1] where some vendored sources contained a
Cargo.toml.orig file that caused issues with
support/scripts/apply-patches.sh used by Buildroot package
infrastructure.
Since then, Buildroot is now using rust 1.74.1 (2024.02.x),
1.79.0 (2024.08.x) and 1.82.0 (master) where vendored
sources no longer contains any Cargo.toml.orig file.
So this post-extract hook is no longer needed.
Moreover, since Rust 1.81.0 are present in
src/tools/rustc-perf/collector/compile-benchmarks/<vendored pkg>
where there is no .cargo-checksum.json file.
Since then, the sed command fail and stop the build:
sed: can't read [...]/host-rust-1.81.0/src/tools/rustc-perf/collector/compile-benchmarks/serde_derive-1.0.136/.cargo-checksum.json: No such file or directory
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/8232367821
[1] b50522d838
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
The particular combination of LVM2 (which enables -PIE), musl-libc with
dynamic linking (and thus -ztext, banning TEXTRELs), and microblaze
leads to an error because a TEXTREL is produced in musl-libc's Scrt1.o.
The upstream patch added in this commit fixes (or works around) the
problem.
Fixes: http://autobuild.buildroot.net/results/5bb283eff4b4a2b17d1028bbe0b3e1bea8fbeba8/
Signed-off-by: J. Neuschäfer <j.neuschaefer@gmx.net>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
As it happens, I am unable to keep maintaining those entries, and it is
misleading to others about whether they should Cc me on their changes.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
When halting the boot process in u-boot, the 'usb start' command does not
automatically run. Since the SD card is connected over a USB to SD card
bridge on the kd240 and kr260 boards, the readme.txt instructions should
document that the 'usb start' command needs to be manually enterred when
following the reflashing instructions. Otherwise, the command to read the
boot.bin and u-boot.itb files from the SD card will fail.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This failure appeared when trying to build lrzsz:
lsyslog.c:73:5: error: implicit declaration of function ‘vasprintf’; did you mean ‘vsprintf’? [-Wimplicit-function-declaration]
To fix the problem, let's follow Debian. Switch to 0.12.21rc (which is
already out there 25 years!) and import their patch adding includes.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
[Peter: add Upstream tag to patch]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The mosquitto runtime test can randomly fail on slow
runners, see [1].
This commit improves this test in the following ways:
- the mosquitto_sub subscriber process is now started in a subshell
to suppress the job control messages (to prevent any spurious
messages when the job stops),
- the standard error is redirected to /dev/null, to prevent the
printing of any messages,
- the mosquitto_pub publisher process is started later, by increasing
the sleep time,
- finally, a new sleep time is introduced between the mosquitto_pub
publisher process and the check of the mosquitto_sub subscriber, to
make sure it will have time to write its output and exit.
Fixes: [1]
[1] https://gitlab.com/buildroot.org/buildroot/-/jobs/8453386454
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Release notes: https://www.postgresql.org/docs/release/16.6/
Note: this minor version bump fixes a bug introduced in postgresql
security bump to 16.5 fixing CVE-2024-10978.
Signed-off-by: Maxim Kochetkov <fido_max@inbox.ru>
[Julien: add note in commit log]
Signed-off-by: Julien Olivain <ju.o@free.fr>
Since the bump of util-linux to version 2.40.2 in Buildroot commit
f14929c657 ("package/util-linux: update
to 2.40.2"), the build will fail on systems that are not Y2038,
such as uClibc configurations.
In order to preserve the previous behavior, pass --disable-year2038.
See the gnulib documentation for details [1]. Contrary to what the
option name might suggest, it doesn't really disable Y2038 support,
but only the check that the system is Y2038 compliant. So even with
--disable-year2038, if the system is Y2038 compliant (uses a 64-bit
arch, uses the musl C library, or uses the glibc C library with
BR2_TIME_BITS_64=y), util-linux tools will be Y2038 compliant.
"--disable-year2038" was already added to util-linux in commit
11ae90b00 "package/util-linux: allowing building even on non-Y2038
compliant systems".
Fixes:
https://autobuild.buildroot.org/results/630fc287deb1cf5a684f274058b918a5d7aef989
[1] https://www.gnu.org/software/gnulib/manual/html_node/Avoiding-the-year-2038-problem.html
Reviewed-by: Vincent Jardin <vjardin@free.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Host bmap-tools runs using host-python3, but did not select it,
leading to the confusing situation that BR2_PACKAGE_HOST_PYTHON3=n
even though it was built and working.
Signed-off-by: Fiona Klute (WIWA) <fiona.klute@gmx.de>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit 7b2a164b74 (package/go/go-bin: new host-go provider) broke the
case for prompt-less, host-only go packages, as the main host-go symbol
would not be selected.
This very same use-case was initially broken when the first go-src
provider was introduced with fa2536ec94 (package/go: make host package
a virtual package), and subsequently fixed in 99a5d51c6e (package/go:
ensure there is a host-go provider), so 7b2a164b74 is causing a
regression of a fixed regression.
Fix that the very same way it was originally fixed.
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
host-skopeo fail to build, using the commands:
echo BR2_PACKAGE_HOST_SKOPEO=y >.config
make olddefconfig
make host-skopeo
This commit fixes the issue by selecting BR2_PACKAGE_HOST_GO
in the Config.in file.
Fixes:
make: *** No rule to make target 'host-', needed by '/buildroot/output/build/host-go-1.23.2/.stamp_configured'. Stop.
Reviewed-by: Yann E. MORIN <yann.morin@orange.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
I will lose access to my email next week, so hand
it over to Leo Yu-Chi Liang.
Signed-off-by: Yu Chien Peter Lin <peterlin@andestech.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Asaf has privately requested to be removed from the DEVELOPERS file as
he will no longer be contributing to Buildroot in the forseeable
future.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
// Check the bignum_st definition against the one below and either update the
// version check or provide the new definition for this version.
# error Untested OpenSSL version
--
2.39.5
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Peter Korsgaard