This test uses the option added in the previous commits to build a
disk image with squashfs root and matching verity tree, and boots from
it. Building a kernel is necessary to get the required device-mapper
and squashfs support.
The test also serves to demonstrate usage of a verity image, more
complex setup may use an initramfs instead of dm-mod.create.
Signed-off-by: Fiona Klute (othermo GmbH) <fiona.klute@gmx.de>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Using dm-verity may be useful for any read-only filesystem read from a
block device, the new hook will build the required hash tree if
enabled by a per-filesystem config option.
To use this hook, the filesystem config must define a boolean option
BR2_TARGET_ROOTFS_<FS>_VERITY, and a string option
BR2_TARGET_ROOTFS_<FS>_VERITY_EXTRA_ARGS. The latter option allows
users to override veritysetup defaults, e.g. to set a fixed hash
algorithm.
In the filesystem .mk file ROOTFS_<FS>_VERITY_EXTRA_ARGS must be
defined as the value of BR2_TARGET_ROOTFS_<FS>_VERITY_EXTRA_ARGS
without surrounding quotes, because utils/check-symbols warns about
the _EXTRA_ARGS symbol being unused if fs/common.mk uses
$(qstrip $(BR2_TARGET_ROOTFS_$(2)_VERITY_EXTRA_ARGS)) directly.
Signed-off-by: Fiona Klute (othermo GmbH) <fiona.klute@gmx.de>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The IW610 module is also available with a USB host interface, while
the current package only supports its SDIO firmware. This commit
adds this USB support.
Bump the firmware release to lf-6.18.20-2.0.0, which
provides the FwImage_IW610_USB firmware, and add a dedicated
BR2_PACKAGE_NXP_BT_WIFI_FIRMWARE_IW610_USB option.
The new release also moves firmware files out of the nxp/ directory
and no longer provides 8801 or 8997 firmware. Update the installation
paths, make the existing IW610 option explicitly SDIO, and retain legacy
configuration handling for removed or renamed options.
This commit also updates the license hash, after an update from:
LA_OPT_NXP_Software_License v57 July 2024
to:
LA_OPT_NXP_Software_License v63 May 2025
Signed-off-by: Antoine Gennart <antoine.gennart@quimesis.be>
[Julien:
- update license hash
- fix _VERSION to use a tag rather than a branch
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
The previous version fails to build with Linux 6.13 and newer because
mlinux/moal_main.h includes the removed net/lib80211.h header.
The header was removed by Linux commit 02f220b52670 ("wifi:
ipw2x00/lib80211: move remaining lib80211 into libipw").
The new NXP release skips this obsolete header for kernels newer
than 6.12.12 and includes the corresponding Linux 6.13 cfg80211 API
compatibility fixes.
Signed-off-by: Antoine Gennart <antoine.gennart@quimesis.be>
[Julien: fix _VERSION to use a tag rather than a branch]
Signed-off-by: Julien Olivain <ju.o@free.fr>
Add basic tests for openscap, ensuring that it builds and runs a minimal
command with different cryptographic backends:
- libgcrypt
- libnss
- no crypto backend
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
When enabling the openscap package and the libnss library _but not_
libgcrypt, the build can fail on the following error:
../src/libopenscap.so.33.1.3: undefined reference to `crapi_init'
The issue is due to the fact that the corresponding Makefile
systematically forces -DWITH_CRYPTO=gcrypt: openscap CMake
instrumentation then searches only this backend, fails to find it,
assumes that no crypto backend is available, and so does not include the
crapi_object in the final link step.
Commit 7c85f3adf4 ("package/openscap: new package") took into account
the fact that openscap isn't currently able to build if no crypto backend
is provided (see [0]), and so made sure to force libgcrypt inclusion if
libnss is not included. Since then, two fixes ([1] and [2]) have been
integrated upstream to allow building openscap with any backend.
Do not systematically enforce libgcrypt anymore through WITH_CRYPTO:
rather than testing nss presence, and falling back to libgcrypt, allow
both to be absent, and so relax the libgcrypt dependency to make it
optional as well. Bring the two upstream patches allowing openscap build
without any crypto backend. Those patches can be dropped once openscap
v1.4.5 is released.
[0] https://github.com/OpenSCAP/openscap/issues/2310
[1] d12d820a94
[2] 5b858d1786
Fixes: https://autobuild.buildroot.org/results/4c905c1b0ee384149c3d85e8f2ebf0af3a12c2ad/
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
For unconditional dependencies, using += isn't useful, and our common
practice is to use a simple = assignment.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Added MALI_T76X_STRIP_COMPONENTS = 0 as tar archive follows nonstandard layout with license file being in the topmost directory
Signed-off-by: Sebastian Michel <sebastian.michel@oss.othermo.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The comment about the toolchain requirements to have Python support in
gnuradio is always displayed, even if architecture requirements are
not met and if Python is not enabled. For the latter: the option
BR2_PACKAGE_GNURADIO_PYTHON also depends on python, so it makes sense
for the Config.in comment to also depend on it.
Fixes: 7a546b87d5 ("package/python-numpy: add reverse dependency on packages using python-numpy")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
BR2_PACKAGE_GNURADIO_PYTHON selects BR2_PACKAGE_PYTHON_NUMPY, so it
should inherit its dependencies, but BR2_TOOLCHAIN_GCC_AT_LEAST_9 was
forgotten in commit 8b3993178d, when
python-numpy got this gcc >= 9 dependency added.
Note that the existing BR2_HOST_GCC_AT_LEAST_9 dependency is correct:
it is there because gnuradio needs host-python-numpy at build time.
Fixes: 8b3993178d ("package/python-numpy: needs gcc >= 9")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This commit fixes 3 issues in the Config.in comment:
- It is displayed even on unsupported CPU architectures, so we add a
"depends on BR2_PACKAGE_TENSORFLOW_LITE_ARCH_SUPPORTS"
- It doesn't mention the need for a glibc toolchain even though that's
part of the dependencies
- The requirement for dynamic lib support should be part of the same
comment as the other dependencies
Fixes: fd29fee3a3 ("package/tensorflow-lite: new package")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
BR2_PACKAGE_TENSORFLOW_LITE selects BR2_PACKAGE_LIBABSEIL_CPP without
propagating its depends on BR2_PACKAGE_LIBABSEIL_CPP_ARCH_SUPPORTS,
which this commit fixes.
Note that this doesn't create any functional change: tensorflow-lite
is anyway limited to ARM, ARM64, x86 32-bit and x86 64-bit, all of
which are supported by libabseil-cpp.
Fixes: fd29fee3a3 ("package/tensorflow-lite: new package")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
BR2_PACKAGE_RPI_RGB_LED_MATRIX_VIDEO_VIEWER selects
BR2_PACKAGE_FFMPEG, but without propagating its depends on, and most
notably BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS.
Fixes: e821078031 ("package/rpi-rgb-led-matrix: new package")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Another instance of libaseil-cpp requiring gcc >= 10, which means
protobuf needs >= 10, and that wasn't propagated to all reverse
dependencies of protobuf, in this commit: opencv4.
Fixes: 76241e89e1 ("package/libabseil-cpp: bump to version 20260817.0")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
libgtk3 selects at-spi2-core, so it should inherit its
!BR2_STATIC_LIBS, which this commit does.
This has been an issue since libgtk3 started using at-spi2-core
instead of atk in commit 2c3ca7bea1.
Fixes: 2c3ca7bea1 ("package/atk: remove package")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
