This patch fixes the `S_IFMT` undeclared error in `statx.c` when musl
is used.
Signed-off-by: José Luis Salvador Rufo <salvador.joseluis@gmail.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
When compiling host-m4 1.4.19 with a host gcc 15 (which is the version
included in Fedora 42, released on 2025-04-15), compilation fails with
error:
In file included from gl_avltree_oset.h:21,
from gl_avltree_oset.c:21:
gl_oset.h:275:1: warning: 'nodiscard' attribute ignored [-Wattributes]
275 | GL_OSET_INLINE _GL_ATTRIBUTE_NODISCARD int
| ^~~~~~~~~~~~~~
gl_oset.h:275:40: error: expected identifier or '(' before 'int'
275 | GL_OSET_INLINE _GL_ATTRIBUTE_NODISCARD int
| ^~~
This error is due to the gnulib copy included in m4 1.4.19, which does
not detect properly the default C language standard of gcc 15 which
has been changed from "gnu17" to "gnu23". See [1]. Note that m4 1.4.19
is the latest version available at the time of this commit, and was
released in May 2021. The issue is tracked upstream in [2].
Upcoming m4 release is expected to fix this issue, by updating its
gnulib copy. See [3], which states: "Update to comply with newer C
standards, and inherit portability improvements from gnulib".
Until this new m4 version is released, this commit fixes the issue by
forcing the C langage standard to "-std=gnu17" (the previous gcc
default) when host-gcc 15 is detected.
Note that the "-std=gnu17" option was introduced in gcc 8. See [4].
This is the reason why this patch adds this option only when the
problematic gcc 15 version is detected.
See also the discussions around this patch at [5].
Fixes:
https://autobuild.buildroot.org/results/1c33ef0a710cfae13e496485787b351c8f951217/
(and many, many others)
[1] https://gcc.gnu.org/gcc-15/changes.html#c
[2] https://savannah.gnu.org/support/?111150
[3] https://git.savannah.gnu.org/cgit/m4.git/commit/?h=branch-1.4&id=a22c9802dd7e724eaefb21dc21d84ac2d3a49c89
[4] https://gcc.gnu.org/gcc-8/changes.html#c
[5] https://lore.kernel.org/buildroot/CAPWx8vsoJUt8YMJG1aUqFRK1=yizNbgjVjGL1Q1+9ygjJGnZLA@mail.gmail.com/
Signed-off-by: Joseph Zikusooka (ZIK) <zik@jambula.net>
Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
[Julien:
- change mail url to lore.kernel.org for stable link
- reword, reflow and add extra info in the commit log
- force -std=gnu17 only when host gcc-15 is detected
- add a comment in .mk to remove the workaround at next bump
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
This fixes a potential NULL pointer dereference
As a side note, this package has many opened CVEs, but upstream doesn't seem
to really consider them as security issues, see their disclaimer here:
https://github.com/yasm/yasm/blob/master/SECURITY.md
We could speculate that this disclaimer has been written as a consequence of
the many small CVEs opened in a short time, that don't have a substantial
security impact (besides the command line tool crashing). All of these small
CVEs have been opened for bug reports issued by a third party who used a
fuzzy tester to manipulate the assembler input
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This fixes the following CVE:
- CVE-2025-1492: The Bundle Protocol and CBOR dissectors could crash
It may be possible to make Wireshark crash by injecting a malformed
packet onto the wire or by convincing someone to read a malformed
packet trace file.
See https://www.wireshark.org/security/wnpa-sec-2025-01
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Annoyingly, using "--disable warning" does not disable the warnings
checks.
It turns out that we look for "warnings" (i.e. with an 's') to know if
we should disable the warnings check, so update the help text
accordingly.
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Since commit fd562315, which updated waf to v2.1.1, Buildroot has
encountered issues building mpv, likely due to an outdated version of
the waf build system.
Starting with mpv v0.35, meson was introduced as an alternative to waf,
and in mpv v0.37, waf was completely removed.
This commit updates the mpv makefile to use meson, resolving the build
issues and simplifying future updates to newer versions of mpv.
All options previously used for Waf have been translated to the new
build system by replacing `--disable-feature` with `-Dfeature=disabled`
(and similarly for enabling features). Some features have special
handling:
- The `/usr` prefix is automatically passed to meson packages by
default.
- The Android feature "has been removed since meson can detect if a
machine is Android"[1].
- The `libmpv` parameter has been enabled in the makefile as `libmpv`
must be built by default with mpv.
- Meson packages automatically set whether the library should be built
statically using the `default_library` meson parameter.
- Meson automatically detects the presence of `libatomic` and passes the
correct argument to the linker. However, it is possible to set the
`stdatomic` meson parameter to specify whether `libatomic` must or
must not be used.
Fixes:
https://autobuild.buildroot.org/results/68d42441fc0da34e1bf2a4247726f5f4ec3b8e77/
[1]: 140ec21c89/DOCS/build-system-differences.md (L48)
Signed-off-by: Thomas Bonnefille <thomas.bonnefille@bootlin.com>
Tested-by: J. Neuschäfer <j.ne@posteo.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The package strongswan relies on the `wc_RsaKeyToDer` & `wc_MakeRsaKey`
functions of WolfSSL. Building this package with the WolfSSL backend
by selecting the variable `BR2_PACKAGE_STRONGSWAN_WOLFSSL` would give
the following error:
```
libtool: compile: /home/buildroot/instance-0/output-1/host/bin/sparc-linux-gcc -DHAVE_CONFIG_H -I. -I../../../.. -I../../../../src/libstrongswan -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DWC_NO_RNG -rdynamic -Wno-format -Wno-format-security -Wno-implicit-fallthrough -Wno-missing-field-initializers -Wno-pointer-sign -Wno-sign-compare -Wno-type-limits -Wno-unused-parameter -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Og -g0 -include /home/buildroot/instance-0/output-1/build/strongswan-5.9.14/config.h -c wolfssl_ed_public_key.c -o wolfssl_ed_public_key.o >/dev/null 2>&1
wolfssl_rsa_private_key.c: In function 'get_encoding':
wolfssl_rsa_private_key.c:366:31: error: implicit declaration of function 'wc_RsaKeyToDer'; did you mean 'wc_EccKeyToDer'? [-Wimplicit-function-declaration]
366 | len = wc_RsaKeyToDer(&this->rsa, encoding->ptr, len);
| ^~~~~~~~~~~~~~
| wc_EccKeyToDer
libtool: compile: /home/buildroot/instance-0/output-1/host/bin/sparc-linux-gcc -DHAVE_CONFIG_H -I. -I../../../.. -I../../../../src/libstrongswan -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DWC_NO_RNG -rdynamic -Wno-format -Wno-format-security -Wno-implicit-fallthrough -Wno-missing-field-initializers -Wno-pointer-sign -Wno-sign-compare -Wno-type-limits -Wno-unused-parameter -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Og -g0 -include /home/buildroot/instance-0/output-1/build/strongswan-5.9.14/config.h -c wolfssl_ec_private_key.c -o wolfssl_ec_private_key.o >/dev/null 2>&1
wolfssl_rsa_private_key.c: In function 'wolfssl_rsa_private_key_gen':
wolfssl_rsa_private_key.c:490:13: error: implicit declaration of function 'wc_MakeRsaKey'; did you mean 'wc_FreeRsaKey'? [-Wimplicit-function-declaration]
490 | if (wc_MakeRsaKey(&this->rsa, key_size, WC_RSA_EXPONENT, &this->rng) < 0)
| ^~~~~~~~~~~~~
| wc_FreeRsaKey
```
Those functions are only present when building the WolfSSL library with
the keygen supports (`--enable-keygen`).
This patch change the selected package to enable all the option of
WolfSSL, which include the keygen as well.
Fixes:
- https://autobuild.buildroot.org/results/d0e/d0e94f501ad1afd25ae4112443f9af101dfa5dea
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This version bump removes CVE-2023-7152, which was incorrectly associated
with the micropython package in pkg-stats.
Although the CVE fix was already present in 1.22.0 the CVE only applied
to the preview version of 1.22.0. The CPE ID of the 1.22.0 matched with the
CPE ID of the 1.22.0 preview version as well.
This patch bumps to the latest patch-level version available in the 1.22.x
series to include additional fixes, rather than just adding the CVE to the
'MICROPYTHON_IGNORE_CVES' list.
The LICENSE hash has been updated, as the licenses used for the ports and
libraries have also been updated in the LICENSE file.
For more details on the version bump, see the release notes:
- https://github.com/micropython/micropython/releases/tag/v1.22.2
- https://github.com/micropython/micropython/releases/tag/v1.22.1
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This configuration builds an image for the Raspberry Pi 2 Rev 1.2
(64-bit).
Note: Raspberry Pi 2 Model B Rev 1.2[1] switched from BCM2836[2] to
BCM2837[3] that is 64-bit.
BCM2836[2]
The Broadcom chip used in the Raspberry Pi 2 Model B. The
underlying architecture in BCM2836 is identical to BCM2835. The
only significant difference is the removal of the ARM1176JZF-S
processor and replacement with a quad-core Cortex-A7 cluster.
BCM2837[3]
This is the Broadcom chip used in the Raspberry Pi 3 Model B,
later models of the Raspberry Pi 2 Model B, and the Raspberry Pi
Compute Module 3. The underlying architecture of the BCM2837 is
identical to the BCM2836. The only significant difference is the
replacement of the ARMv7 quad core cluster with a quad-core ARM
Cortex A53 (ARMv8) cluster.
The ARM cores run at 1.2GHz, making the device about 50% faster
than the Raspberry Pi 2. The VideoCore IV runs at 400MHz.
[1]: https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#flagship-series
[2]: https://www.raspberrypi.com/documentation/computers/processors.html#bcm2836
[3]: https://www.raspberrypi.com/documentation/computers/processors.html#bcm2837
Signed-off-by: Gaël PORTAY <gael.portay+rtone@gmail.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The Config.in comment in the dpdk package was wrong for a number of
reasons:
- It didn't mention the glibc dependency
- It didn't mention the gcc >= 4.9 dependency
- It mentioned a wchar dependency that isn't listed in the dpdk
dependencies
- It mentioned a dynamic library dependency that isn't listed in the
dpdk dependencies
- It used "kernel headers >= 4.19", while for brievity we use "headers
>= 4.19" everywhere in Buildroot
- Minor nit: DPDK was written allcaps, while we write package names
lower-case in Buildroot
Fixes: d17d1b6bde ("package/dpdk: add 24.07")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The upstream URL was missing in the help text, so add it.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Add a runtime test for the 'dust' package to verify that the binary
executes correctly in a minimal buildroot rootfs. The test checks that:
- 'dust --version' runs without error
- 'dust' can analyze a directory structure with files
- The output includes the expected directory names
Signed-off-by: El Mehdi YOUNES <elmehdi.younes@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Add a runtime test for the 'bat' package to verify that the binary executes
correctly in a minimal Buildroot rootfs.The test cheks that:
- 'bat --version' runs without error
- 'bat' can read and display a text file
- the displayed content matches the expected string
Signed-off-by: El Mehdi YOUNES <elmehdi.younes@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This patch bumps:
- TF-A to version v2.12 (LTS)
- U-Boot to version v2025.04
- Linux kernel to version 6.12.24 (LTS)
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Commit f78280bf26 ("package/sane-airscan: new package") added a new entry
in DEVELOPERS, but forgot to add the email address. Fix that.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
CONFIG_SMARTCARD was unconditionally disabled which has meant that
even if OpenSSL is compiled with engine support and the supplicant is
configured to use an engine it would warn that it was compiled without
engine support.
This mechanism is used to enable the more secure forms of 802.1x
networking authentication such as EAP-TLS with hardware-delegated
cryptography and private keys protected in hardware.
Enabling the option will allow delegating private key access to TPM2,
ARM TrustZone and other specialized secure hardware for establishing a
network connection.
Signed-off-by: Lars Wikman <lars@underjord.io>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The v1 of the patch that is in Buildroot ended up being reworked and
merged from a v2, therefore let's update the patch by using the merged
commit instead.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
libcamera migrated to use an ioctl for detecting frame sizes which is
only available in kernels 6.4 and later. If it doesn't exist, default
frame sizes are used. However the min and max resolutions supported by
the pipeline weren't initialized for kernels where that ioctl isn't
available and ended up creating invalid configuration that later
crashed.
The introducing commit was part of the v0.4.0 release.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Release:
https://github.com/bootandy/dust/releases/tag/v1.1.2
Note: version 0.9.0 of dust fails to build when running
the runtime test on the armv7 architecture due to an
unconditional import of Atomicu64.
error:
Compiling config-file v0.2.3
error[E0432]: unresolved import `std::sync::atomic::AtomicU64`
--> src/progress.rs:6:18
|
6 | atomic::{AtomicU64, AtomicU8, AtomicUsize, Ordering},
| ^^^^^^^^^
| |
| no `AtomicU64` in `sync::atomic`
| help: a similar name exists in the module: `AtomicU32`
For more information about this error, try `rustc --explain E0432`.
error: could not compile `du-dust` (bin "dust") due to 1 previous error
This issue was discovered while writing a runtime test
for dust. upgrading to version 1.1.2 resolves the issue.
More details available in the following issue:
https://github.com/bootandy/dust/issues/423
For now, we bump to the latest compatible version
which builds and runs correctly. We can't bump to the latest
version 1.2.0 since it requires a cargo version newer than
1.82.0.
error:
-- The package requires the Cargo feature called `edition2024`, but that feature is not stabilized in this version of Cargo (1.82.0 (8f40fc59f 2024-08-21)).
Consider trying a newer version of Cargo (this may require the nightly release).
The upgrade to 1.2.0 will be considered once the patch for
Rust 1.86.0 is accepted.
Signed-off-by: El Mehdi YOUNES <elmehdi.younes@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
1.3.44 added the following security fixes:
* TIFF: Fixed multiple heap and stack buffer overflows (directed by
the source EXIF profile) while writing EXIF into the native TIFF
IFD.
* FITS: Fix problem that the FITS reader could return invalid image
frames with rows or columns set to zero. Other code in the library
crashes, or even asserts, if invalid image frames with rows or
columns set to zero are returned.
* Coverity fixes: Various fixes for Coverity issues raised after the
update to version 2023.12.2.
* Clang Analyzer (scan-build) fixes: Various fixes for new issues
discovered by Clang Analyzer.
7046c34427
In addition 1.3.45 fixes a off-by-one issue introduced in 1.3.44:
96f765a2e3
Update the Copyright.txt hash for a change in copyright years:
f0bba104ee26fce89276
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
