curlpp is broken since the bump of libcurl to 8.10.0 in commit [1].
This patch backport a pull request from upstream from [2] to solve it.
Fixes:
https://autobuild.buildroot.org/results/4a4d3b248898f0e73620fcb1a7a94dcfb6e6866e/
[1] d68b999787
[2] https://github.com/jpbarrette/curlpp/pull/178
Signed-off-by: Thomas Bonnefille <thomas.bonnefille@bootlin.com>
[Julien:
- reword patch title one liner
- add link to commit which introduced the issue
- add link to the upstream pull request
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit f06c28d1afef98e80f358c35ae65e035aa64f6ea)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Bugfix release fixing regressions in 3.4.0:
- fixed handling of -H flag with conflict in internal flag values
- fixed a use after free in logging of failed rename
- fixed build on systems without openat()
- removed dependency on alloca() in bundled popt
For more details, see:
https://download.samba.org/pub/rsync/NEWS#3.4.1
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 593755f527a77fe8bf2513f14118ab51b76f17b7)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Release note:
https://download.samba.org/pub/rsync/NEWS#3.4.0
Fixes the following vulnerabilities:
CVE-2024-12084: Heap Buffer Overflow in Rsync due to Improper Checksum
Length Handling
Description: A heap-based buffer overflow flaw was found in the rsync
daemon. This issue is due to improper handling of attacker-controlled
checksum lengths (s2length) in the code. When MAX_DIGEST_LEN exceeds the
fixed SUM_LENGTH (16 bytes), an attacker can write out of bounds in the
sum2 buffer.
CVE-2024-12085: Info Leak via Uninitialized Stack Contents
Description: A flaw was found in the rsync daemon which could be triggered
when rsync compares file checksums. This flaw allows an attacker to
manipulate the checksum length (s2length) to cause a comparison between a
checksum and uninitialized memory and leak one byte of uninitialized stack
data at a time.
CVE-2024-12086: Rsync Server Leaks Arbitrary Client Files
Description: A flaw was found in rsync. It could allow a server to
enumerate the contents of an arbitrary file from the client's machine. This
issue occurs when files are being copied from a client to a server. During
this process, the rsync server will send checksums of local data to the
client to compare with in order to determine what data needs to be sent to
the server. By sending specially constructed checksum values for arbitrary
files, an attacker may be able to reconstruct the data of those files
byte-by-byte based on the responses from the client.
CVE-2024-12087: Path Traversal Vulnerability in Rsync
Description: A path traversal vulnerability exists in rsync. It stems from
behavior enabled by the `--inc-recursive` option, a default-enabled option
for many client options and can be enabled by the server even if not
explicitly enabled by the client. When using the `--inc-recursive` option,
a lack of proper symlink verification coupled with deduplication checks
occurring on a per-file-list basis could allow a server to write files
outside of the client's intended destination directory. A malicious server
could write malicious files to arbitrary locations named after valid
directories/paths on the client.
CVE-2024-12088: --safe-links Option Bypass Leads to Path Traversal
Description: A flaw was found in rsync. When using the `--safe-links`
option, rsync fails to properly verify if a symbolic link destination
contains another symbolic link within it. This results in a path traversal
vulnerability, which may lead to arbitrary file write outside the desired
directory.
CVE-2024-12747: Race Condition in Rsync Handling Symbolic Links
Description: A flaw was found in rsync. This vulnerability arises from a
race condition during rsync's handling of symbolic links. Rsync's default
behavior when encountering symbolic links is to skip them. If an attacker
replaced a regular file with a symbolic link at the right time, it was
possible to bypass the default behavior and traverse symbolic links.
Depending on the privileges of the rsync process, an attacker could leak
sensitive information, potentially leading to privilege escalation.
For more details, see the advisory:
https://www.openwall.com/lists/oss-security/2025/01/14/3
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
[Julien: add link to release note]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 017d74c943a03c7b36ef7d71886b29b27d817c12)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Drop first patch (already in version)
https://github.com/RsyncProject/rsync/blob/v3.3.0/NEWS.md
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit a8be7900a3)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
BR2_ARCH_NEEDS_GCC_AT_LEAST_X guards has been introduced by [1] to
prevent selecting an external toolchain that did not support the GCC
arch tuning the user had selected.
But it was not changed while updating to version 13.2-rel1.
Fixes: 50ae5ea963
[1] eed1670d8a
Cc: Antoine Coutant <antoine.coutant@smile.fr>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 7ffc6ae7d9c375e953ea9c32530b15a5c79afa4c)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
BR2_ARCH_NEEDS_GCC_AT_LEAST_X guards has been introduced by [1] to
prevent selecting an external toolchain that did not support the GCC
arch tuning the user had selected.
But it was not changed while updating to version 13.2-rel1.
Fixes: 7b4b3c2c78
[1] eed1670d8a
Cc: Antoine Coutant <antoine.coutant@smile.fr>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 299967723354c9ad50f7faf945ac809d32bf4108)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
BR2_ARCH_NEEDS_GCC_AT_LEAST_X guards has been introduced by [1] to
prevent selecting an external toolchain that did not support the GCC
arch tuning the user had selected.
But it was not updated while updating to version 13.2-rel1.
Fixes: 0dd599d171
[1] eed1670d8a
Cc: Antoine Coutant <antoine.coutant@smile.fr>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 203abefcf6c0ca54d28523bcd8ac7c56c249fefe)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Vincent Stehlé <vincent.stehle@laposte.net>
[Julien: switch to human readable genimage.cfg partition uuid]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 055f82ebbd07b582c992eed30ef5191f18873ba4)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Usually, ubxtool, a python-based tool to drive u-blox devices, connects
to a gpsd instance and delegates to it the responsibility to write to
and read from the actual device. This is sane, because a serial device
can only be opened once, and if gpsd is running, it has that device
open.
However, in some cases, ubxtool can be used to directly talk to the
device, to pre-configure it before gpsd runs, or even in the absence of
gpsd altogether. This is not used very often, except when setting up an
RTK base, where gpsd is not needed.
In that case, ubxtool will directly talk to the serial device. It uses
the pyserial python module. Since this is not the traditional way to
talk to the device, failure to import the module is ignored, and the
error reporting is deferred until it is actually needed, which is why we
did not catch the issue earlier. See [1] and [2].
Fixes: f3ef0723cf (package/gpsd: enable python support and modules)
[1] https://gitlab.com/gpsd/gpsd/-/blob/release-3.25/clients/ubxtool.py.in#L47
[2] https://gitlab.com/gpsd/gpsd/-/blob/release-3.25/gps/gps.py.in#L36
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Bernd Kuhls <bernd@kuhls.net>
[Julien: add link to described code portion]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 5d2f3737a1e52d140bd412bf01241eecf5cff994)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
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 5c0a91f7293523254e9c48667df4468370fda58d)
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 001e777d507b972a580d75e3ac8d892eff72fbf2)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Buildroot commit
1f4b4ccde7ceb379010aeb93458792202622d64b ("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 5d7ab604d24e13cfd6dd57ee95171fac0bf45b63)
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 3722998a3d0b771154b5069798f55ff9ea2c81bd)
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 da9adec1491eefc618aab610615fe293899845fd)
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 717f1fdaeb460c71f673a6ad6e82d16af878c188)
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 3177ecd26096ab305c51620eb29b0e639f3133e9)
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 d10d22221f93c2a1f5950045a4f95fbb4984d685)
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 35f381b93e52895179569876b23a509c9a7e0225)
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 cdcb3f56e8d5b5f51cd12721feaf8679953547b1)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The build of GOI on Microblaze fails as qemu-user hangs forver when
running the GOI programs. Considering how small Microblaze targets
are, the use-case for GOI is very small if not inexistant, and it's
unlikely anybody is ever going to debug this, so just disable GOI on
Microblaze.
This issue is causing timeouts in the autobuilders on a regular basis:
http://autobuild.buildroot.net/?status=TIMEOUT&reason=gobject-introspection%
Fixes:
http://autobuild.buildroot.net/results/f8e5ef74478c63c89e7b99fb928b97ac4518f943/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 8548c7586a56938b2f52f5c41050441b53a457f0)
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 9114d48b313744fd163e4eeea0f5b0407568e771)
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 696de595e028daaec4d66792bb2d3db74c72f07e)
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 75d418b59d4ffe251ffcd49c06ccf0f1d0b86e04)
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 65127a8a772132c3d0905241563d1978a2b332ba)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
I no longer use this package.
Signed-off-by: Bartosz Bilas <b.bilas@grinn-global.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 192e1d2147a3de03ac68126b1bedecf1abee4948)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The Linux kernel "defconfig" on ARC is haps_hs_smp_defconfig, which
cannot be built on ARC 750d/770d targets, so let's use a kernel
defconfig that works properly on ARC 750d/770d.
Fixes:
http://autobuild.buildroot.net/results/2913e5958cd6b20dbfdcdad304a5f5a0f8030d8d/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 954b5514a92d9d8439d57a815f097046e6270bb9)
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 82326a3d8392d02f53c47bdaed21ff8012a6d978)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 13250bf4aafbde9b0f946d5d07aaf3b6dc34d31f)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since procps-ng was bumped from 3.3.17 to 4.0.4 in commit
d79f40dbbe98983bc657d4c82d46b38b8283351b ("package/procps-ng: security
bump to version 4.0.4"), the build has been failing on !wchar
configurations with:
src/ps/output.c:68:10: fatal error: wctype.h: No such file or directory
68 | #include <wctype.h>
| ^~~~~~~~~~
compilation terminated.
The problematic code has been added by upstream commit
605ea4a8f7,
which landed in upstream release v4.0.0.
To solve this, we simply add a BR2_USE_WCHAR dependency, and update
the comment related to this dependency on the only reverse dependency
of procps-ng.
Fixes:
http://autobuild.buildroot.net/results/afc035e866bec6f2c14f9d52fa74a9c1897706de/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit f6fe892141cd4c8b6dd934df92eb1fe7d9469e0c)
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 e14380b3c4c3d5e037662c45b2cf90056056920a)
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 66a5f9bc742f517ad245e1ba0dcc8837205beedc)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
No functional change, but bump for consistency. For details, see the
release notes:
https://gstreamer.freedesktop.org/releases/1.22/
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 038c7df88e063fa10b0e1aa5e26159618fea21de)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
No functional change, but bump for consistency. For details, see the
release notes:
https://gstreamer.freedesktop.org/releases/1.22/
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit fd720980eb51401261438bb4f1928b54c2576438)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
No functional change, but bump for consistency. For details, see the
release notes:
https://gstreamer.freedesktop.org/releases/1.22/
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
[Julien: fixed commit log title]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 8fd12c62022da53aee2872f8c912744b40393606)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
For various bugfixes. For details, see the release notes:
https://gstreamer.freedesktop.org/releases/1.22/
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit f20de77f15e5b32f299a3ac2f2524f82710bab18)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
For various bugfixes. For details, see the release notes:
https://gstreamer.freedesktop.org/releases/1.22/
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 17c57efe399ab6e18428f1073532f63f59a38a3e)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
For various bugfixes. For details, see the release notes:
https://gstreamer.freedesktop.org/releases/1.22/
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 3e5223d4e871c10dd4a9ae6e6b275a2ae74b9646)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
For various bugfixes. For details, see the release notes:
https://gstreamer.freedesktop.org/releases/1.22/
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 8fbadc1c060052e01cfdad7c705792d1d9821a67)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
For various bugfixes. For details, see the release notes:
https://gstreamer.freedesktop.org/releases/1.22/
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit a0c1f2383649e810459482f6614214122adcd78b)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
For various bugfixes. For details, see the release notes:
https://gstreamer.freedesktop.org/releases/1.22/
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 1fa7c453e4f1dd099b6818ede10a4404b572424f)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
For various bugfixes. For details, see the release notes:
https://gstreamer.freedesktop.org/releases/1.22/
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 84f8e7c18bfdcbab26b4fd52d5696992ce6d0bbe)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following security issue:
CVE-2024-4453: Heap-based buffer overflow in the EXIF image tag parser when
handling certain malformed streams before GStreamer 1.24.3 or 1.22.12
https://gstreamer.freedesktop.org/security/sa-2024-0002.html
For more details, see the release notes:
https://gstreamer.freedesktop.org/releases/1.22/
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 197cd0de3b02fc66e35632644fc8437ad4464fe9)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
