This version allows to build with Linux 6.15. Makefile hase been refactored
and variable USER_EXTRA_CFLAGS has been renamed to USER_ccflags-y so let's
rename it accordingly.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
With this version we can build with Linux 6.14 and support for
cfg80211_rtw_get_txpower() has been added.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This commit adds BR2_DOWNLOAD_FORCE_CHECK_HASHES=y in the defconfig
and adds custom hash files. The exception entry in .checkpackageignore
is also removed.
Cc: Fabio Estevam <festevam@gmail.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The 'bird' package with only the `BR2_PACKAGE_BIRD_BFD=y` protocol
enabled fails to build with the following error
```
bison -Dparse.lac=full -Dparse.error=verbose -dv -pcf_ -b obj/conf/cf-parse obj/conf/cf-parse.y
proto/bfd/config.Y:204.27-33: error: symbol 'ADDRESS' is used, but is not defined as a token and has no rules
204 | | bfd_show_sessions_args ADDRESS net_or_ipa { net_copy(&($$->address...
| ^~~~~~~
```
The `ADDRESS` token is defined only when certain protocols (e.g. OSPF,
RIP, RPKI, or BGP) are enabled. As a result, builds including any of
these protocols do not encounter the issue.
The issue can be reproduced with the commands:
cat >.config <<EOF
BR2_aarch64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_PACKAGE_BIRD=y
BR2_PACKAGE_BIRD_BFD=y
# BR2_PACKAGE_BIRD_BGP is not set
EOF
make olddefconfig
make bird
This patch backports upstream commits that define the `ADDRESS` token
for the BFD protocol.
Fixes:
https://autobuild.buildroot.org/results/68c5dd84585a7018ad57ea3e7134748c08858ef7/
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
[Julien: add commands to reproduce the issue]
Signed-off-by: Julien Olivain <ju.o@free.fr>
This version incorporates stability fixes and support for newer chip
generations.
The license hash change is only cosmetic, see the corresponding
commit[1] in the upstream repo.
Fix up defconfigs as needed since older TPL blob versions have gotten
removed.
[1] 385bf9f170
Signed-off-by: Florian Larysch <fl@n621.de>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The i.MX defconfig files follow the following name pattern:
- freescale_<board_name>_defconfig when it uses software components,
such as kernel and U-Boot from NXP.
- <SoC_name><board_name>_defconfig when it uses software components,
such as kernel and U-Boot from upsream.
This imx28evk target uses U-Boot and kernel from upstream, so rename it to
imx28evk_defconfig for consistency.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
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>
