Fixes the following vulnerabilities:
- CVE-2024-50349:
Printing unsanitized URLs when asking for credentials made the
user susceptible to crafted URLs (e.g. in recursive clones) that
mislead the user into typing in passwords for trusted sites that
would then be sent to untrusted sites instead.
- CVE-2024-52006
Git may pass on Carriage Returns via the credential protocol to
credential helpers which use line-reading functions that
interpret said Carriage Returns as line endings, even though Git
did not intend that.
For more details, see the announcement:
https://lore.kernel.org/git/xmqq5xmh46oc.fsf@gitster.g/
Additionally, 2.47.1 contained a number of fixes:
https://lore.kernel.org/git/xmqq5xob6coo.fsf@gitster.g/
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Backport a patch fixing a segfault first introduced by
ca63c4409b in buildroot.
Fixes:
==4792== Invalid read of size 8
==4792== at 0x4FE7661: __gconv_close (gconv_close.c:33)
==4792== by 0x4FE70EE: iconv_close (iconv_close.c:34)
==4792== by 0x5AED422: xmlCharEncCloseFunc (encoding.c:2678)
==4792== by 0x587A78C: __pyx_f_4lxml_5etree__find_PyUCS4EncodingName (etree.c:126676)
==4792== by 0x5888666: __pyx_pymod_exec_etree (etree.c:289773)
==4792== by 0x4A06345: PyModule_ExecDef (moduleobject.c:440)
==4792== by 0x4AE23A8: _imp_exec_dynamic_impl (import.c:3801)
==4792== by 0x4AE23A8: _imp_exec_dynamic (import.c.h:534)
==4792== by 0x4A046A3: cfunction_vectorcall_O (methodobject.c:509)
==4792== by 0x4AAA203: _PyEval_EvalFrameDefault (bytecodes.c:3263)
==4792== by 0x49B9D2B: _PyObject_VectorcallTstate (pycore_call.h:92)
==4792== by 0x49B9D2B: object_vacall (call.c:850)
==4792== by 0x49B9F44: PyObject_CallMethodObjArgs (call.c:911)
==4792== by 0x4AE648A: import_find_and_load (import.c:2781)
==4792== by 0x4AE648A: PyImport_ImportModuleLevelObject (import.c:2864)
==4792== Address 0x8 is not stack'd, malloc'd or (recently) free'd
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit e2e152496a)
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 593755f527)
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 017d74c943)
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 7ffc6ae7d9)
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 2999677233)
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 203abefcf6)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The option BR2_TOOLCHAIN_EXTERNAL_SYNOPSYS_ARC just depends on
BR2_arc, but the choice of toolchains that appears once
BR2_TOOLCHAIN_EXTERNAL_SYNOPSYS_ARC=y only has choices for:
depends on BR2_arc750d || BR2_arc770d
and
depends on BR2_archs38_64mpy || BR2_archs38_full || \
BR2_archs4x_rel31 || BR2_archs4x
which means that if you have a BR2_archs38=y configuration, you end up
with no choice of toolchain, and the build fails with "No C library
selected". Fix this by making sure BR2_TOOLCHAIN_EXTERNAL_SYNOPSYS_ARC
can only be selected when an actual toolchain is available.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit e7f14af27d)
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 5d2f3737a1)
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 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>
Bernd Kuhls