Add new host-python-setuptools-scm build dependency.
License hash changed due to year update:
ef10940712
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This patch bumps the zynq_zed_defconfig to Linux kernel 6.6.60.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This patch bumps the zynq_microzed_defconfig to Linux kernel 6.6.60.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This patch bumps the zynq_zc706_defconfig to Linux kernel 6.6.60.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This patch bumps the zynq_zc702_defconfig to Linux kernel 6.6.60.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This patch adds the hash for Linux version 6.6.60 for Xilinx boards.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Commit 75320f567d "configs/imx6ulz_bsh_smm_m2: bump U-Boot to 2024.10
and Linux to 6.1.120" updated the kernel from 6.1.68 to 6.1.120 but
forgot to update its per-config kernel hash file.
The defconfig fails with the error:
ERROR: No hash found for linux-6.1.120.tar.xz
This failure happen since commit 07149e5f30 "{linux, linux-headers}:
bump 5.{4, 10, 15}.x / 6.{1, 6, 12}.x series" which updated the
Buildroot 6.1 kernel series from 6.1.120 to 6.1.122.
This commit fixes the issue by updating the hash.
While at it, it also changes the "Locally computed" comment
by the upstream link to hashes.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/8751983243
Cc: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Cc: Michael Trimarchi <michael@amarulasolutions.com>
Reviewed-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
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>
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>
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>
