The 6.9.x series is now EOL upstream, so drop the linux-headers option
and add legacy handling for it.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Maeva told me personally she will no longer contribute to Buildroot
for the time being. This commit removes all the associated DEVELOPERS
entries.
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This patch bumps:
- TF-A to version v2.10
- U-Boot to versione v2024.07
- Linux kernel to version 6.10
The TF-A bump required applying a patch, sent upstream, to fix a
regression in the domain access permissions configuration for the boot
console UART.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Some scenarii, like building an RTK base, does not require a gpsd
daemon, but just a few python based tools (e.g. the python scripts
to configure a GNSS device).
Add an option to enable or disable building and instaling the daemon.
We make it enabled by default, for legacy purposes.
When the daemon is installed, it also installs a few ancillary helpers,
which need some of the clients (e.g. the udev rule will use gpsdctl), so
ensure they are enabled with the daemon.
Speaking of the udev rule: without the daemon, it does not need to be
installed, so only try to fix its mode when the daemomn is installed.
Similarly for systemd, no need to install the drop-in when the daemon is
not installed. And for sysv init, no need for a startup script without
the daemon either.
Now that everything is optional, daemon, clients, and python stuff, we
need to ensure that at least something is installed. The obvious
solution would be to ensure that the daemon is installed, but that
causes conflicts in the Kconfig depencies (elided for readability):
config BR2_PACAKGE_GPSD
bool "gpsd:
select BR2_PACKAGE_GPSD_DAEMON if ! BR2_PACKAGE_GPSD_CLIENTS \
&& ! BR2_PACKAGE_GPSD_PYTHON
config BR2_PACKAGE_GPSD_DAEMON
bool "daemon"
select BR2_PACKAGE_GPSD_CLIENTS
would cause errors like:
package/gpsd/Config.in:27:error: recursive dependency detected!
package/gpsd/Config.in:27: symbol BR2_PACKAGE_GPSD_DAEMON is selected by BR2_PACKAGE_GPSD_CLIENTS
package/gpsd/Config.in:226: symbol BR2_PACKAGE_GPSD_CLIENTS is selected by BR2_PACKAGE_GPSD_DAEMON
So we chose the next best option: ensure that the clients get built, if
nothing else does.
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Bernd Kuhls <bernd@kuhls.net>
Reviewed-by: Jan Havran <havran.jan@email.cz>
Tested-by: Jan Havran <havran.jan@email.cz>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
In some cases, the clients are useless on the target, e.g. when there is
no need to adjust the gpsd daemon at runtime.
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
It's in the middle of options that are specific to the daemon, while
it itself is not specific to the daemon. We're going to add an option
to enable/disable the daemon soon, so that python option would get
hidden away.
Move it further down, out of scope of the daemon-related options.
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Currently, we have a Kconfig symbol to enable the python support in
gpsd, but the condition at configure time is based on whether the python
package is enabled. So, if a user does not enable python support in
gpsd, they still get it.
Switch to using the proper symbol.
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Bernd Kuhls <bernd@kuhls.net>
Reviewed-by: Jan Havran <havran.jan@email.cz>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Pass USE_LIBDRM=OFF to the wpewebkit CMake configuration step when the
libdrm package has not been selected.
WPE WebKit can be built without libdrm support, and it will still work
with backends that use other platform-specific methods to handle
graphics buffers and/or presenting content onto an output. For example
this is the case with wpebackend-rdk configured to use rpi-userland,
which uses dispmanx to produce the output instead of DRM/KMS.
Signed-off-by: Adrian Perez de Castro <aperez@igalia.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
OP-TEE OS supports custom tarballs. If the OP-TEE OS custom tarball version
does not match the latest optee-examples version supported by Buildroot,
optee-examples might not build or run properly. This patch adds support for
an optee-examples custom tarball URL to address this potential issue.
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
Acked-by: Etienne Carriere <etienne.carriere@foss.st.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
OP-TEE OS supports custom tarballs. If the OP-TEE OS custom tarball version
does not match the latest optee-test version supported by Buildroot,
optee-test might not build or run properly. This patch adds support for
an optee-test custom tarball URL to address this potential issue.
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
Acked-by: Etienne Carriere <etienne.carriere@foss.st.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
OP-TEE OS supports custom tarballs. If the OP-TEE OS custom tarball
version does not match the latest optee-client version supported by
Buildroot, optee-client might not build or run properly. This patch
adds support for an optee-client custom tarball URL to address this
potential issue.
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
Acked-by: Etienne Carriere <etienne.carriere@foss.st.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Runnning autoreconf is needed to avoid the following static build
failure on musl which is raised as otherwise LDFLAGS (which contains
-static) is not passed:
/home/autobuild/autobuild/instance-16/output-1/host/lib/gcc/armeb-buildroot-linux-musleabi/13.3.0/../../../../armeb-buildroot-linux-musleabi/bin/ld: /home/autobuild/autobuild/instance-16/output-1/host/lib/gcc/armeb-buildroot-linux-musleabi/13.3.0/libgcc.a(_dvmd_lnx.o): in function `__aeabi_idiv0':
/home/autobuild/autobuild/instance-16/output-1/build/host-gcc-final-13.3.0/build/armeb-buildroot-linux-musleabi/libgcc/../../../libgcc/config/arm/lib1funcs.S:1499:(.text+0x8): undefined reference to `raise'
This build failure is raised by autobuilders since bump to version 5.6.2
in commit d1d77eb274 but it can also be
reproduced on version 5.4.7 (but not on 5.4.6). There is probably an
issue with these two official autotools tarballs which have been
released the same day (on May 29 2024).
Fixes: 40240ac30ahttp://autobuild.buildroot.org/results/344813b202644a23c166920aa7e861ebf408536b
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Update wpa_supplicant to the latest release v2.11. Drop all the patches
as they are already included into the release.
Hash of the README file used as license file has changed due to:
-Copyright (c) 2002-2022, Jouni Malinen <j@w1.fi> and contributors
+Copyright (c) 2002-2024, Jouni Malinen <j@w1.fi> and contributors
Signed-off-by: Sergey Matyukevich <geomatsi@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
With GCC 14.x as the host compiler, bcusdk fails to build as follows:
configure: error: Specified CC_FOR_BUILD doesn't seem to work
This is due to missing includes in the test programs used in the
configure script to check the host compiler. We fix this with patch
0003.
However, this patch requires to autoreconf the package, and autoreconf
would need the definition of AM_PATH_XML2, which would require libxml2
even though we don't have libxml2 as a dependency of this package (we
don't enable the features that requires libxml2). As it turns out that
the AM_PATH_XML2 macro is in fact deprecated, we replaced it by its
equivalent using PKG_CHECK_MODULES(), which is in fact exactly how
AM_PATH_XML2 is implemented in upstream libxml2.
Fixes:
http://autobuild.buildroot.net/results/458880bd6c207e5bb7afce1a1186f204c30c0941/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The patch 0001 has been submitted upstream, but the formatting of the
tag was not correct, let's fix this.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Fix the following build failure without threads raised since switch to
meson-package in commit 1fa58814c0 which
wrongly removed -DCAIRO_NO_MUTEX=1:
In file included from ../src/cairo-mutex-type-private.h:45,
from ../src/cairo-scaled-font-private.h:45,
from ../src/cairoint.h:415,
from ../src/cairo-arc.c:37:
../src/cairo-mutex-impl-private.h:231:3: error: #error "XXX: No mutex implementation found. Cairo will not work with multiple threads. Define CAIRO_NO_MUTEX to 1 to acknowledge and accept this limitation and compile cairo without thread-safety support."
231 | # error "XXX: No mutex implementation found. Cairo will not work with multiple threads. Define CAIRO_NO_MUTEX to 1 to acknowledge and accept this limitation and compile cairo without thread-safety support."
| ^~~~~
Note that prior to 1fa58814c0, the
condition was:
ifeq ($(BR2_TOOLCHAIN_HAS_THREADS_NPTL),)
CAIRO_CONF_ENV += CPPFLAGS="$(TARGET_CPPFLAGS) -DCAIRO_NO_MUTEX=1"
endif
but that was in fact wrong, because it meant that toolchain with
linuxthreads (not NPTL) would have thread support, but a thread-unsafe
cairo library. The condition was changed from
BR2_TOOLCHAIN_HAS_THREADS to BR2_TOOLCHAIN_HAS_THREADS_NPTL in an
older commit, 92f14307ba, but now
cairo's mutex support builds fine with linuxthreads, so we can use
CAIRO_NO_MUTEX=1 only when thread support is not available at all.
Fixes: 1fa58814c0
- http://autobuild.buildroot.org/results/a123355b6d315d2fcda646d3f1c7b588cba78258
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
mdio-tools depends on CONFIG_MDIO_DEVICE in order for mdiobus driver to
be built, but CONFIG_MDIO_DEVICE depends on CONFIG_NETDEVICES which we
are not enabling so on platforms without it enabled in kernel config
building mdio-tools will fail with:
ERROR: modpost: "mdio_find_bus" [output-1/build/mdio-tools-1.3.1/kernel/mdio-netlink.ko] undefined!
ERROR: modpost: "__mdiobus_c45_read" [output-1/build/mdio-tools-1.3.1/kernel/mdio-netlink.ko] undefined!
ERROR: modpost: "__mdiobus_read" [output-1/build/mdio-tools-1.3.1/kernel/mdio-netlink.ko] undefined!
ERROR: modpost: "__mdiobus_c45_write" [output-1/build/mdio-tools-1.3.1/kernel/mdio-netlink.ko] undefined!
ERROR: modpost: "__mdiobus_write" [output-1/build/mdio-tools-1.3.1/kernel/mdio-netlink.ko] undefined!
So enable CONFIG_NETDEVICES as well to make sure CONFIG_MDIO_DEVICE can be enabled.
Fixes: http://autobuild.buildroot.net/results/edf47df96cde6094c890c0b74034cced90335a39/
Signed-off-by: Robert Marko <robimarko@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
All patches of the odb package already contained relevant Upstream
information, just not formatted according to how we expect it. Let's
fix that, and drop the .checkpackageignore entries that are no longer
needed.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
