When trying to build host-dtc on a host with glibc 2.43, the build fails
on the following error:
libfdt/fdt_overlay.c: In function ‘overlay_fixup_phandle’:
libfdt/fdt_overlay.c:424:21: error: assignment discards ‘const’
qualifier from pointer target type [-Werror=discarded-qualifiers]
424 | sep = memchr(fixup_str, ':', fixup_len);
| ^
libfdt/fdt_overlay.c:434:21: error: assignment discards ‘const’
qualifier from pointer target type [-Werror=discarded-qualifiers]
434 | sep = memchr(name, ':', fixup_len);
| ^
fdtput.c: In function ‘create_node’:
fdtput.c:235:11: error: assignment discards ‘const’ qualifier from
pointer target type [-Werror=discarded-qualifiers]
235 | p = strrchr(node_name, '/');
| ^
cc1: all warnings being treated as errors
make[2]: *** [Makefile:359: fdtput.o] Error 1
make[2]: *** Waiting for unfinished jobs....
cc1: all warnings being treated as errors
make[2]: *** [Makefile:359: libfdt/fdt_overlay.o] Error 1
make[1]: *** [package/pkg-generic.mk:273:
/home/alexis/src/buildroot/dtc/build/host-dtc-1.7.2/.stamp_built] Error 2
make: *** [Makefile:83: _all] Error 2
The issue can be reproduced on master with this minimal defconfig on a
host having glibc 2.43:
BR2_x86_64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_PACKAGE_QORIQ_MC_UTILS=y
(QORIQ_MC_UTILS will pull HOST_DTC)
This error is due to some functions prototype update in glibc 2.43 for
ISO C23 (see [1], point 3 in the NEWS list). The corresponding fix has
already been integrated upstream, but it has not been released since
then.
Bring the corresponding upstream patch to allow host-dtc to build on
affected hosts.
[1] https://lists.gnu.org/archive/html/info-gnu/2026-01/msg00005.html
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The used Linux kernel (4.14.336) does not contain the default license files
as those were only added in 4.16 with commit e00a844aca ("LICENSES: Add
Linux syscall note exception"), so specify the correct license file to fix:
make legal-info
..
cp: cannot stat '/path/to/output/build/linux-headers-4.14.336/LICENSES/preferred/GPL-2.0': No such file or directory
And add the sha256sum to the .hash file.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
[Julien:
- reword commit title
- actually add BR2_LINUX_KERNEL_LICENSE_FILES in defconfig
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
The used Linux kernel (4.14.336) does not contain the default license files
as those were only added in 4.16 with commit e00a844aca ("LICENSES: Add
Linux syscall note exception"), so specify the correct license file to fix:
make legal-info
..
cp: cannot stat '/path/to/output/build/linux-headers-4.14.336/LICENSES/preferred/GPL-2.0': No such file or directory
And add the sha256sum to the .hash file.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
[Julien: reword commit title]
Signed-off-by: Julien Olivain <ju.o@free.fr>
Commit 50958bcdac ("linux: Add support for custom license files") added a
default value for the license files and made the option visible (E.G.
editable) when a custom VCS or tarball version is used, but it is also
needed for users of an older _CUSTOM_VERSION (E.G. mainline release), as
the referenced files were only added in Linux 4.16 with commit e00a844aca
("LICENSES: Add Linux syscall note exception"), so change that.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
It was recently announced on the list that Marcus joined the maintainer
team, so add a news entry about it as well.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When using a specific git repo and version for at91bootstrap3,
BR2_TARGET_AT91BOOTSTRAP3_LICENSE_FILES defaults to "LICENSES/MIT.txt".
However the git version we use (namely v3.10.3) does not provide this
file. Actually, it does not provide a license file at all. This causes
‘make legal-info’ to fail with:
>>> at91bootstrap3 v3.10.3 Collecting legal info
sha256sum: /builds/buildroot.org/buildroot/output/build/at91bootstrap3-v3.10.3/LICENSES/MIT.txt: No such file or directory
ERROR: while checking hashes from boot/at91bootstrap3/at91bootstrap3.hash
ERROR: LICENSES/MIT.txt has wrong sha256 hash:
ERROR: expected: 5a3809b1c2ba13b7242572322951311c584419f1f8516f665d6c06f0668d78de
ERROR: got :
ERROR: Incomplete download, or man-in-the-middle (MITM) attack
Let's be explicit that there is no license file to check.
Fixes:
- https://gitlab.com/buildroot.org/buildroot/-/jobs/12992815386
- https://gitlab.com/buildroot.org/buildroot/-/jobs/12992815390
Signed-off-by: Edgar Bonet <bonet@grenoble.cnrs.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The Buildroot commit [1] introduced two small typos, while doing the
updates to announce new releases.
The version 2025.02.10 release date is 2026-01-20 (and not 2022).
See the original announce [2].
The 2025.02.10 archive link in news.html has also a missing dot.
This commit fixes those typo in order to fix the website.
[1] 21dda0665e
[2] https://lore.kernel.org/buildroot/9b9654f8-6cdd-4108-b932-79509e455148@rnout.be/
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
libxmslec1 build fails on some configurations with the following build
logs:
CC libxmlsec1_openssl_la-kw_des.lo
kw_des.c:75:8: error: unknown type name 'xmlSecKWDes3Klass'; did you mean 'xmlSecKWAesKlass'?
75 | static xmlSecKWDes3Klass xmlSecOpenSSLKWDes3ImplKlass = {
| ^~~~~~~~~~~~~~~~~
| xmlSecKWAesKlass
kw_des.c:77:5: error: initialization of 'int' from 'int (*)(struct _xmlSecTransform *, xmlSecByte *, size_t, size_t *)' {aka 'int (*)(struct _xmlSecTransform *, unsigned char *, long unsigned int, long unsigned int *)'} makes integer from pointer without a cast [-Wint-conversion]
77 | xmlSecOpenSSLKWDes3GenerateRandom, /* xmlSecKWDes3GenerateRandomMethod generateRandom; */
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
kw_des.c:77:5: note: (near initialization for 'xmlSecOpenSSLKWDes3ImplKlass')
kw_des.c:77:5: error: initializer element is not computable at load time
kw_des.c:77:5: note: (near initialization for 'xmlSecOpenSSLKWDes3ImplKlass')
kw_des.c:78:5: error: excess elements in scalar initializer
78 | xmlSecOpenSSLKWDes3Sha1, /* xmlSecKWDes3Sha1Method sha1; */
| ^~~~~~~~~~~~~~~~~~~~~~~
kw_des.c:78:5: note: (near initialization for 'xmlSecOpenSSLKWDes3ImplKlass')
kw_des.c:79:5: error: excess elements in scalar initializer
79 | xmlSecOpenSSLKWDes3BlockEncrypt, /* xmlSecKWDes3BlockEncryptMethod encrypt; */
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
kw_des.c:79:5: note: (near initialization for 'xmlSecOpenSSLKWDes3ImplKlass')
kw_des.c:80:5: error: excess elements in scalar initializer
80 | xmlSecOpenSSLKWDes3BlockDecrypt, /* xmlSecKWDes3BlockDecryptMethod decrypt; */
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[...]
This build failure is due to those struct definitions being set
conditionally in src/kw_aes_des.h behind a XMLSEC_NO_DES define, and
this define ending up being 1 on some builds. We could assume that the
makefiles in libxmlsec should just not try to build any DES related file
when XMLSEC_NO_DES is set to 1 (and so, in this specific case, not try
to build src/openssl/kw_des.c), but the autotools tooling in the project
is not the one setting XMLSEC_NO_DES: there is a mismatch between
detected features at configure time and build time.
- at build time, the tooling just checks if user has passed
`--enable-des=no`. If so, it sets XMLSEC_NO_DES, otherwise it assumes
that DES support is available.
- at build time, libxmlsec tries to build openssl backend. This backend
checks OpenSSL features, especially whether OPENSSL_NO_DES is set (and
if so, it enforces XMLSEC_NO_DES to 1 as well)
- This OPENSSL_NO_DES comes from libopenssl configuration headers
installed in sysroot. Its presence is driven by the `no-des` option
passed at libopenssl configure time
- This `no-des` flag is driven by buildroot option
BR2_PACKAGE_LIBOPENSSL_ENABLE_DES
There are multiple options to fix this package here:
1. fixing upstream package to make the features detection more robust (eg
check openssl headers at configure time to ensure that DES is
supported)
2. enforce XMLSEC_NO_DES if BR2_PACKAGE_LIBOPENSSL_ENABLE_DES is not set
3. systematically enforce XMLSEC_NO_DES=1
Now:
- 1 may take time, and would then need a temporary patch to live in
buildroot while the fix is accepted upstream and released
- 2 works only for libopenssl, what if libressl is used ?
- DES usage is discouraged anyway, as stated by configure logs:
[...]
checking for DES support... yes (use discouraged)
[...]
As the package has been introduced very recently, there's a very low
chance to break any user use case by completely disabling DES support.
Systematically disable DES support in libxmlsec1 to discourage usage and
fix build failure when the corresponding SSL library does not expose DES
support.
Fixes: https://autobuild.buildroot.org/results/3e15f03dc0211c622125ebb69ff7230ce900029a/
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The patch:
* bumps Linux kernel to version 6.18.8
* bumps U-Boot to version 2026.01
* bumps ATF to version 2.14.0
* forces check hashes
* switches to extlinux
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
[Julien: change linux.hash comment to use hash from upstream]
Signed-off-by: Julien Olivain <ju.o@free.fr>
The patch:
* bumps Linux kernel to version 6.18.8
* bumps U-Boot to version 2026.01
* forces check hashes
* switches to extlinux
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
[Julien: change linux.hash comment to use hash from upstream]
Signed-off-by: Julien Olivain <ju.o@free.fr>
The patch:
* bumps Linux kernel to version 6.18.8
* bumps U-Boot to version 2026.01
* forces check hashes
* switches to extlinux
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
[Julien: change linux.hash comment to use hash from upstream]
Signed-off-by: Julien Olivain <ju.o@free.fr>
This commit also updates
olimex_a20_olinuxino_lime_defconfig
olimex_a20_olinuxino_lime2_defconfig
to use this new rootfs_overlay_mali directory.
This is to differentiate for the upcoming patch for
a20_olinuxino_micro_defconfig
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
[Julien: add extra info in commit log]
Signed-off-by: Julien Olivain <ju.o@free.fr>
The patch:
* bumps Linux kernel to version 6.18.8
* bumps U-Boot to version 2026.01
* forces check hashes
* switches to extlinux
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
[Julien: change linux.hash comment to use hash from upstream]
Signed-off-by: Julien Olivain <ju.o@free.fr>
The patch:
* bumps Linux kernel to version 6.18.8
* bumps U-Boot to version 2026.01
* forces check hashes
* switches to extlinux
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
[Julien:
- change linux.hash comment to use hash from upstream
- add "_lime" in commit title
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
The patch:
* bumps Linux kernel to version 6.18.8
* bumps U-Boot to version 2026.01
* forces check hashes
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
[Julien: change linux.hash comment to use hash from upstream]
Signed-off-by: Julien Olivain <ju.o@free.fr>
The patch:
* bumps Linux kernel to version lf-6.12.49-2.2.0
* bumps U-Boot to version lf-6.12.49-2.2.0
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The patch:
* bumps Linux kernel to version 6.18.8
* bumps U-Boot to version 2026.01
* forces check hashes
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
[Julien: change linux.hash comment to use hash from upstream]
Signed-off-by: Julien Olivain <ju.o@free.fr>
The patch:
* bumps Linux kernel to version 6.18.8
* bumps U-Boot to version 2026.01
* forces check hashes
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
[Julien: change linux.hash comment to use hash from upstream]
Signed-off-by: Julien Olivain <ju.o@free.fr>
The patch:
* bumps Linux kernel to version 6.18.8
* bumps U-Boot to version 2026.01
* forces check hashes
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
[Julien: change linux.hash comment to use hash from upstream]
Signed-off-by: Julien Olivain <ju.o@free.fr>
The patch:
* bumps Linux kernel to version 6.18.8
* bumps U-Boot to version 2026.01
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
[Julien: change linux.hash comment to use hash from upstream]
Signed-off-by: Julien Olivain <ju.o@free.fr>
The `pocoo:jinja2` CPE introduced in commit [1] is not deprecated but is
no longer used. All the security issue on the Github Advisory reference
CVE with the `palletsprojects:jinja` CPE instead (see [2]).
This commit updates the CPE accordingly.
[1] 165f60a092 package/python-jinja2: add CPE variables
[2] https://github.com/pallets/jinja/security/advisories/GHSA-cpwx-vrp4-4pq7
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Optional udisks support is useful for mounting USB sticks via
pcmanfm.
gvfs meson.build has recognized this udisks2 option for quite
some time, since upstream commit [1] first included in version
1.35.2 (released on 2017-11-13).
[1] cdc33bf54f
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
[Julien: add comment in commit log]
Signed-off-by: Julien Olivain <ju.o@free.fr>
commit cf686670b9 introduced a patch that
was later included in a release which made the usage of libesmtp
configurable. Later the switch was moved to the main CMakeLists.mk [0].
while the patch introduced the build flag LOG4CXX_ENABLE_ESMTP the
change to the .mk file used LOG4CXX_ENABLE_LIBESMTP.
So correct this.
Fixes:
CMake Warning:
Manually-specified variables were not used by the project:
LOG4CXX_ENABLE_LIBESMTP
[0] https://github.com/apache/logging-log4cxx/blob/rel/v1.3.1/CMakeLists.txt#L93
Signed-off-by: Michael Nosthoff <buildroot@heine.tech>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This commit backports an upstream patch fixing CVE-2024-10963. See:
https://github.com/linux-pam/linux-pam/issues/834https://github.com/linux-pam/linux-pam/pull/854
Fixes:
- CVE-2024-10963:
Pam: improper hostname interpretation in pam_access leads to access
control bypass
A flaw was found in pam_access, where certain rules in its
configuration file are mistakenly treated as hostnames. This
vulnerability allows attackers to trick the system by pretending
to be a trusted hostname, gaining unauthorized access. This issue
poses a risk for systems that rely on this feature to control who
can access certain services or terminals.
https://www.cve.org/CVERecord?id=CVE-2024-10963
Signed-off-by: Raphael Pavlidis <raphael.pavlidis@gmail.com>
[Julien:
- fix check-package errors
- add info in commit log
- rebase patch on v1.6.1 to avoid patch offsets
- add "CVE:" tag in patch
- add comment with patch name near _IGNORE_CVES in .mk
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
