The 7.0.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: Peter Korsgaard <peter@korsgaard.com>
Now that we have added support for GCC 16.x, made GCC 15.x the
default, let's drop support for GCC 13.x.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
[Julien:
- remove remaining gcc-13 patches from commit 10ccbe079c
- move legacy option to 2026.08 version section
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
https://santuario.apache.org/
"July 2024
As announced early this year, the C++ library has been officially
retired. A fork of this code base has been migrated to the Shibboleth
Project, which has been the sole maintainer for a number of years now.
See the Shibboleth wiki for notable caveats regarding usage of this
code."
https://shibboleth.atlassian.net/wiki/spaces/DEV/pages/3726671873/Santuario
"The C++ xml-security-c library has been retired at Apache and is now
solely maintained by the Shibboleth Project for our use only. Use by
any other project, while permitted freely under the license, is
ill-advised and unsupported by the Shibboleth Project. While we
continue to publish a fork of the code in our repository, and will
accept bug reports and certainly security reports, we do not promise
any responsiveness to third parties, and urge that no other projects
rely on this code. Existing users should seek alternatives or consider
forking the code for their own use."
The package is unmaintained and will cause build errors with the
upcoming bump of OpenSSL to 4.0.0. No other package depends on it so we
can safely remove it from buildroot.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Commit 9a5369effd which removed the
BR2_PACKAGE_QEMU_TARGET_MICROBLAZEEL symbol but forgot to introduce the
new "Legacy options removed in 2026.08" comment.
So the legacy symbol was incorrectly placed under
"Legacy options removed in 2026.05" comment.
Fix that.
Reported-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Changelog:
https://wiki.qemu.org/ChangeLog/11.0
Note:
- Support for all 32-bit host systems has been removed.
- Support for microblazeel has been folded into the microblaze target
Qemu v11.0.0 drops 32-bit support for hosts, all qemu builds must now be
64-bit. Hosts running 64-bit qemu builds can still emulate 32-bit
targets.
Confusingly, the qemu package is also capable of being built and running
on buildroot hosts, and targets. In any case, qemu only supports running
on 64-bit hosts (which may be buildroot targets), so adjust
BR2_PACKAGE_QEMU_ARCH_SUPPORTS_TARGET to indicate no support for 32-bit
buildroot targets, and drop configs for architectures like BR2_arm that
are implicitly 32-bit only.
Separately, the qemu microblazeel target was removed with commit
46a25ae3f0e75e230c06e21435850b1cd1c44f07, as the microblaze (qemu)
target supports both endiannesses, so that's fixed up in the package
Makefile as well.
Signed-off-by: Joseph Kogut <joseph@anodize.com>
[Romain: remove duplicate --disable-download from QEMU_CONFIGURE_CMDS]
Signed-off-by: Romain Naour <romain.naour@smile.fr>
The 6.19.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: Julien Olivain <ju.o@free.fr>
Quoting https://www.pcre.org/
"The older, but still widely deployed PCRE library, originally released
in 1997, is at version 8.45. This version of PCRE is now at end of
life, and is no longer being actively maintained. Version 8.45 is
expected to be the final release of the older PCRE library, and new
projects should use PCRE2 instead. [...]"
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Snort is not maintained for a while now and blocks the removal of the
pcre(v1) package so we remove it from buildroot.
Point to snort3 as an alternative.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Cc: Sergio Prado <sergio.prado@e-labworks.com>
Cc: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Release notes: https://github.com/ggml-org/llama.cpp/releases
Merge BR2_PACKAGE_LLAMA_CPP_SERVER into BR2_PACKAGE_LLAMA_CPP_TOOLS, as
both of these options must be enabled to build tools like llama-cli and
llama-server. See upstream commit [1].
Since the Buildroot option BR2_PACKAGE_LLAMA_CPP_SERVER is removed, this
commit also removes it from support/testing/tests/package/test_aichat.py
which was using it.
[1] a180ba78c7
Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
[Julien:
- reindent options in .mk
- remove BR2_PACKAGE_LLAMA_CPP_SERVER in test_aichat.py
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
These modules were dropped in Python 3.13 as per PEP 594.
The current version in Buildroot is 3.14.3.
- Remove the TODO and related config overrides in python3.mk.
- Remove BR2_PACKAGE_PYTHON3_OSSAUDIODEV from Config.in.
- Add BR2_PACKAGE_PYTHON3_OSSAUDIODEV to Config.in.legacy.
See [1] [2] [3].
[1] https://peps.python.org/pep-0594/
[2] fc07fe4e37
[3] 17e1fe0f9b
Signed-off-by: Shubham Chakraborty <chakrabortyshubham66@gmail.com>
[Julien:
- add links in commit log
- move legacy option in 2026.05 section
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
For release notes since edk2-stable202508, see:
https://github.com/tianocore/edk2/releases/tag/edk2-stable202511
This commit also updates the edk2-platforms packages with the last
commit merged at the edk2 release date (2025-11-19), which corresponds
to commit [1].
The edk2-non-osi package is also updated the same way, which
corresponds to commit [2].
This commit also adds an edk2-platforms package patch to fix a Marvell
build failure seen with the SolidRun MacchiatoBin platform.
This commit has been runtime tested with tests using EDK2 package,
with commands:
support/testing/run-tests \
-d dl -o output_folder \
tests.boot.test_edk2 \
tests.boot.test_grub.TestGrubAArch64EFI \
tests.boot.test_grub.TestGrubRiscV64EFI \
tests.boot.test_grub.TestGrubX8664EFI \
tests.package.test_fwts
It has also been runtime tested (by booting in qemu) with defconfigs
using EDK2 package:
qemu_aarch64_sbsa_defconfig
qemu_loongarch64_virt_efi_defconfig
qemu_riscv64_virt_efi_defconfig
qemu_x86_64_efi_defconfig
[1] 1e64c1109a
[2] 94d0489811
Cc: Dick Olsson <hi@senzilla.io>
Cc: Romain Naour <romain.naour@smile.fr>
Cc: Vincent Stehlé <vincent.stehle@arm.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Now that binutils 2.46.0 has been introduced and binutils 2.45.1 made
the default version, drop the oldest supported version, binutils 2.43,
keeping only the 3 last versions supported: 2.44, 2.45.1 and 2.46.0.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Upstream is dead, website unreachable, and the use case in 2026 is
dubious, so drop the package.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Analysis of https://rg42.org/gitweb/?p=dbustriggerd.git:
last commit: 2014
Musl libc 1.2.5 removed the definition of the basename() function from
string.h and only provides it in libgen.h as the POSIX standard
defines it.
Instead of fixing an unmaintainted package we remove it from buildroot,
no other package depends on it.
Fixes:
https://autobuild.buildroot.net/results/811/81170fe89e1f5b70c63657684de43175e621f762/
dbus-triggerd.c:150:27: error: implicit declaration of function 'basename' [-Wimplicit-function-declaration]
150 | argv[argc++] = strdup(basename(handler_cmd));
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The CVS project is no longer maintained upstream. It no longer builds
with GCC 14.x, has been failing to build for months in our
autobuilders with nobody caring about it.
We managed to fix the GCC 14.x build issue, then there are GCC 15.x,
some of them fixed by Debian patches, but some not. Overall, this is
too much effort, while upstream is completely dead.
So let's get rid of cvs entirely.
Fixes:
https://autobuild.buildroot.net/results/59f6e77106ac98535688ff5b9392b0b3ad3041ae/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The criu package was added in Nov 2023, and then bumped once in
December 2023. Since then, it has never been bumped again, and all
follow-up fixes were provided by other people than the original
package submitter listed in the DEVELOPERS file.
criu has seen several upstream releases since then, and most notably
is causing a number of build issues in our autobuilders:
https://autobuild.buildroot.net/?reason=criu-3.19
The package was never updated to those newer upstream releases, and
the autobuilder issues have not been addressed.
Therefore, let's drop this package.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
gconf has not seen any release since 2013, and the last commit in
https://gitlab.gnome.org/Archive/gconf is from 2015.
The package example application basic-gconf-app fails to build with a
recent compiler such as GCC 14.x:
basic-gconf-app.c:458:60: error: passing argument 1 of ‘gtk_dialog_get_content_area’ from incompatible pointer type [-Wincompatible-pointer-types]
It is not entirely clear since when this breakage takes place, but
most likely since GCC 14.x was introduced. This issue can be
reproduced including on 2025.02.x with the following defconfig:
BR2_aarch64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_PACKAGE_MESA3D=y
BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_SWRAST=y
BR2_PACKAGE_MESA3D_OPENGL_EGL=y
BR2_PACKAGE_MESA3D_OPENGL_ES=y
BR2_PACKAGE_LIBGTK3=y
BR2_PACKAGE_GCONF=y
However, for the build issue to happen you need to run:
$ make libgtk3
$ make
So that libgtk3 gets built before gconf. Indeed, there's a hidden
dependency between the two, and the example programs of gconf only get
build if libgtk3 is built before. We've however encountered the
problem in a (real) bigger build where the dependency relationship of
packages have caused libgtk3 to get built before gconf.
Note that we could perhaps have fixed the problem by disabling the
examples, but gconf is anyway so old and deprecated that it isn't
worth the effort.
There are no known autobuilder issues.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This package is no longer maintained, no release since 2005, and it
has build issues as it uses too old XML APIs:
/home/thomas/projets/buildroot/output/host/bin/../aarch64-buildroot-linux-gnu/sysroot/usr/include/libxml2/libxml/SAX.h:18:4: warning: #warning "libxml/SAX.h is deprecated" [-Wcpp]
18 | #warning "libxml/SAX.h is deprecated"
| ^~~~~~~
svgint.h:42:9: error: unknown type name 'xmlParserCtxtPtr'
42 | typedef xmlParserCtxtPtr svg_xml_parser_context_t;
| ^~~~~~~~~~~~~~~~
Fixes:
https://autobuild.buildroot.net/results/895fdba2f3fcaa42aa93946f2532351d39b16647/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This package is no longer maintained, no release since 2005, and its
dependency libsvg has build issues as it uses too old XML APIs:
/home/thomas/projets/buildroot/output/host/bin/../aarch64-buildroot-linux-gnu/sysroot/usr/include/libxml2/libxml/SAX.h:18:4: warning: #warning "libxml/SAX.h is deprecated" [-Wcpp]
18 | #warning "libxml/SAX.h is deprecated"
| ^~~~~~~
svgint.h:42:9: error: unknown type name 'xmlParserCtxtPtr'
42 | typedef xmlParserCtxtPtr svg_xml_parser_context_t;
| ^~~~~~~~~~~~~~~~
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
In version 2.0.0 Linux support was removed:
https://lists.x.org/archives/xorg-announce/2025-August/003624.html
"This mouse driver is primarily used with BSD, GNU Hurd, illumos, &
Solaris systems. Linux systems should instead use either xf86-input-
libinput or xf86-input-evdev.
While versions 1.9.5 and earlier had rudimentary support for Linux as
well, that has been removed in this release."
Alternative packages can not be selected due to udev dependencies.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
[Julien: add extra info in Config.in.legacy comment]
Signed-off-by: Julien Olivain <ju.o@free.fr>
Because the way JavaScript project development is working the chances that your
project is using the same version of the buildroot package, and you provide
this library from `/var/www` to your users is actually really low ...
If you want to bundle JavaScript libraries in your project you should probably
either use a cdn, handle the package version and location of your choice in
your external or overlay, or just bundle it in your assets from a NPM workflow
to benefit from some minifications from your bundler.
Historically many of those JavaScript libraries were added in the 2010 eras
where it could make sense for them to be part of Buildroot.
Most of them are also way outdated/not maintained.
For more informations see https://elinux.org/Buildroot:DeveloperDaysELCE2025
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Because the way JavaScript project development is working the chances that your
project is using the same version of the buildroot package, and you provide
this library from `/var/www` to your users is actually really low ...
If you want to bundle JavaScript libraries in your project you should probably
either use a cdn, handle the package version and location of your choice in
your external or overlay, or just bundle it in your assets from a NPM workflow
to benefit from some minifications from your bundler.
Historically many of those JavaScript libraries were added in the 2010 eras
where it could make sense for them to be part of Buildroot.
Most of them are also way outdated/not maintained.
For more informations see https://elinux.org/Buildroot:DeveloperDaysELCE2025
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Because the way JavaScript project development is working the chances that your
project is using the same version of the buildroot package, and you provide
this library from `/var/www` to your users is actually really low ...
If you want to bundle JavaScript libraries in your project you should probably
either use a cdn, handle the package version and location of your choice in
your external or overlay, or just bundle it in your assets from a NPM workflow
to benefit from some minifications from your bundler.
Historically many of those JavaScript libraries were added in the 2010 eras
where it could make sense for them to be part of Buildroot.
Most of them are also way outdated/not maintained.
For more informations see https://elinux.org/Buildroot:DeveloperDaysELCE2025
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Because the way JavaScript project development is working the chances that your
project is using the same version of the buildroot package, and you provide
this library from `/var/www` to your users is actually really low ...
If you want to bundle JavaScript libraries in your project you should probably
either use a cdn, handle the package version and location of your choice in
your external or overlay, or just bundle it in your assets from a NPM workflow
to benefit from some minifications from your bundler.
Historically many of those JavaScript libraries were added in the 2010 eras
where it could make sense for them to be part of Buildroot.
Most of them are also way outdated/not maintained.
For more informations see https://elinux.org/Buildroot:DeveloperDaysELCE2025
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Because the way JavaScript project development is working the chances that your
project is using the same version of the buildroot package, and you provide
this library from `/var/www` to your users is actually really low ...
If you want to bundle JavaScript libraries in your project you should probably
either use a cdn, handle the package version and location of your choice in
your external or overlay, or just bundle it in your assets from a NPM workflow
to benefit from some minifications from your bundler.
Historically many of those JavaScript libraries were added in the 2010 eras
where it could make sense for them to be part of Buildroot.
Most of them are also way outdated/not maintained.
For more informations see https://elinux.org/Buildroot:DeveloperDaysELCE2025
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Because the way JavaScript project development is working the chances that your
project is using the same version of the buildroot package, and you provide
this library from `/var/www` to your users is actually really low ...
If you want to bundle JavaScript libraries in your project you should probably
either use a cdn, handle the package version and location of your choice in
your external or overlay, or just bundle it in your assets from a NPM workflow
to benefit from some minifications from your bundler.
Historically many of those JavaScript libraries were added in the 2010 eras
where it could make sense for them to be part of Buildroot.
Most of them are also way outdated/not maintained.
For more informations see https://elinux.org/Buildroot:DeveloperDaysELCE2025
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Because the way JavaScript project development is working the chances that your
project is using the same version of the buildroot package, and you provide
this library from `/var/www` to your users is actually really low ...
If you want to bundle JavaScript libraries in your project you should probably
either use a cdn, handle the package version and location of your choice in
your external or overlay, or just bundle it in your assets from a NPM workflow
to benefit from some minifications from your bundler.
Historically many of those JavaScript libraries were added in the 2010 eras
where it could make sense for them to be part of Buildroot.
Most of them are also way outdated/not maintained.
For more informations see https://elinux.org/Buildroot:DeveloperDaysELCE2025
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Because the way JavaScript project development is working the chances that your
project is using the same version of the buildroot package, and you provide
this library from `/var/www` to your users is actually really low ...
If you want to bundle JavaScript libraries in your project you should probably
either use a cdn, handle the package version and location of your choice in
your external or overlay, or just bundle it in your assets from a NPM workflow
to benefit from some minifications from your bundler.
Historically many of those JavaScript libraries were added in the 2010 eras
where it could make sense for them to be part of Buildroot.
Most of them are also way outdated/not maintained.
For more informations see https://elinux.org/Buildroot:DeveloperDaysELCE2025
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Because the way JavaScript project development is working the chances that your
project is using the same version of the buildroot package, and you provide
this library from `/var/www` to your users is actually really low ...
If you want to bundle JavaScript libraries in your project you should probably
either use a cdn, handle the package version and location of your choice in
your external or overlay, or just bundle it in your assets from a NPM workflow
to benefit from some minifications from your bundler.
Historically many of those JavaScript libraries were added in the 2010 eras
where it could make sense for them to be part of Buildroot.
Most of them are also way outdated/not maintained.
For more informations see https://elinux.org/Buildroot:DeveloperDaysELCE2025
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Because the way JavaScript project development is working the chances that your
project is using the same version of the buildroot package, and you provide
this library from `/var/www` to your users is actually really low ...
If you want to bundle JavaScript libraries in your project you should probably
either use a cdn, handle the package version and location of your choice in
your external or overlay, or just bundle it in your assets from a NPM workflow
to benefit from some minifications from your bundler.
Historically many of those JavaScript libraries were added in the 2010 eras
where it could make sense for them to be part of Buildroot.
Most of them are also way outdated/not maintained.
For more informations see https://elinux.org/Buildroot:DeveloperDaysELCE2025
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
