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>
Due to the increasing number of patches applied for this package and the
lack of updates to fix the build issues as well as updating the version
to newer release. This patch removes softether from buildroot package
list.
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The rpi-userland package no longer builds with CMake >= 4. While
fixing it is probably not too difficult,
https://github.com/raspberrypi/userland tells us:
"""
This repo is ancient and deprecated.
It largely contains code using proprietary APIs to interface to the
VideoCore firmware. We have since move to standard linux APIs.
V4L2, DRM/KMS and Mesa are the APIs you should be using.
The few useful tools from here (dtoverlay, dtmerge, vcmailbox,
vcgencmd) have been moved to the raspberrypi/utils repo.
Code from here is no longer installed on latest RPiOS Bookworm images.
If you are using code from here you should rethink your solution.
Consider this repo closed.
"""
Hence it is time to drop this package from Buildroot.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
As we're about to remove the rpi-userland package, drop support for it
from package/gstreamer/gst1-plugins-base.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This tool has been removed from upstream rpi-firmware, so drop the
corresponding option and logic in rpi-firmware.mk.
The tool has been removed by upstream commit
d1fcc26038186aecc1501a0b749833300afba801 ("opt: Remove builds of
deprectated userland tools").
It is Buildorot commit
28e6953ba8 ("package/rpi-firmware: bump
version to 5476720") that did a bump to a version of rpi-firmware that
no longer provided vcdbg.
Cc: Köry Maincent <kory.maincent@bootlin.com>
Cc: Gaël PORTAY <gael.portay@rtone.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Kory Maincent <kory.maincent@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
6d188cb199
"This project is archived. QJson was originally created when Qt3 and Qt4
lacked robust JSON support.
Since Qt5, JSON support is included in the native Qt library SDK, making
this project obsolete."
The package is broken with cmake 4 and no other package depends on it.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Cc: Zoltan Gyarmati <mr.zoltan.gyarmati@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
With the removal of the roseapplepi defconfig in commit 56091a5818
("configs/roseapplepi: remove defconfig, broken") there are no (in-tree)
users of the s500-bootloader binary blob package, so drop it.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
opencv3's code is not compatible with newer versions of ffmpeg, and
opencv3 is no longer maintained, so we have no choice but to disable
its ffmpeg support.
Fixes:
https://autobuild.buildroot.net/results/9ae3911583cccb6362f33cd82e5eaafb059fdc76/
It's not clear which ffmpeg version bump broken the build exactly, but
this issue is definitely present in 2025.02.x as the following
defconfig fails to build in a similar way on 2025.02.x:
BR2_aarch64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_AARCH64_GLIBC_STABLE=y
BR2_PACKAGE_FFMPEG_NONFREE=y
# BR2_PACKAGE_FFMPEG_FFMPEG is not set
# BR2_PACKAGE_FFMPEG_INDEVS is not set
# BR2_PACKAGE_FFMPEG_OUTDEVS is not set
BR2_PACKAGE_OPENCV3=y
BR2_PACKAGE_OPENCV3_LIB_VIDEOIO=y
BR2_PACKAGE_OPENCV3_BUILD_PERF_TESTS=y
BR2_PACKAGE_OPENCV3_WITH_FFMPEG=y
BR2_PACKAGE_OPENCV3_INSTALL_DATA=y
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The protobuf support breaks the build, as protobuf includes
libabseil-cpp headers, which now require C++14. opencv3 doesn't have
any ENABLE_CXX14 option, so for the time being, disable protobuf
support until someone bothers enough to fix this up.
While we suspect a libabseil-cpp version bump to be responsible for
the issue, we are not 100% sure. However, the issue is definitely
present in Buildroot 2025.02.x, as it can be reproduced using the
following defconfig:
BR2_aarch64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_PACKAGE_OPENCV3=y
BR2_PACKAGE_OPENCV3_LIB_SHAPE=y
BR2_PACKAGE_OPENCV3_LIB_STITCHING=y
BR2_PACKAGE_OPENCV3_LIB_SUPERRES=y
BR2_PACKAGE_OPENCV3_LIB_TS=y
BR2_PACKAGE_OPENCV3_LIB_VIDEOSTAB=y
BR2_PACKAGE_OPENCV3_WITH_PROTOBUF=y
Fixes:
https://autobuild.buildroot.net/results/39432e7746e6bc5224592a7d2f744ca992bd529a/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Changes:
- Add watchdogctl list-clients command to display currently subscribed
clients to the process supervisor. Outputs to stdout in either table
format (default) with colored headers, or JSON format with -j/--json
- New global -j, --json option for machine-readable output, currently
supported by list-clients and status commands
- New API: wdog_clients() returns array of wdog_client_t structs for
programmatic access to subscribed clients. See API documentation at
https://codedocs.xyz/troglobit/watchdogd/wdog_8h.html
- Enhance watchdogctl status command to display formatted output by
default, with device information, capabilities, and reset history in
a human-readable table format. Use -j/--json for JSON output
Fixes:
- Generic scripts running more than 1 second would fail with false
"critical error" reports and cause unwanted system reboots due
to uninitialized exit status variable
- watchdogctl reload with tempmon crashes watchdogd
- Issue causing unwanted reboot when watchdogctl reload was called
while a generic monitor script was running
- Fix memory leak in generic monitor with optional script path, would
be triggered on watchdogctl reload
The first of the fixes means we can now drop the backported patch.
Also, the test mode has been dropped from public use, hence it being
removed as well in this commit.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The 6.17.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>
Alexey Brodkin from Synopsys says in [1]:
I think indeed, we may remove all the big-endian support for ARC.
Reasons are since introduction of ARC HS4x processors we no longer
support big-endian in any new processor IP, and even for older IP
which used to support big-endian it was rarely used... so basically
there's no good justification to spend any cycles on big-endian
support looking forward in this project. I.e. BE support in uClibc
could also be removed if it makes any difference.
Therefore, let's removed support for ARC big-endian.
[1] https://lore.kernel.org/buildroot/SJ2PR12MB818487232470DA4456967C73A1A3A@SJ2PR12MB8184.namprd12.prod.outlook.com/
Cc: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
Cc: ARC Maintainers <arc-buildroot@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Maxim Kochetkov <fido_max@inbox.ru>
[Julien:
- move legacy option to 2026.02 section
- add link to mailing list
- remove BR2_arceb from pkg-meson.mk to fix check-symbols error
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
The 5.4.x series is now EOL upstream, so drop the linux-headers
option and add legacy handling for it.
Bump kernel version in test_zfs.py.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Now that binutils 2.45 has been introduced and binutils 2.44 made the
default version, drop the oldest supported version, binutils 2.42,
keeping only the 3 last versions supported: 2.43, 2.44 and 2.45.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The package is causing build errors with newer gcc versions:
sectables.c:331:22: error: initialization of 'void (*)(void)' from
incompatible pointer type 'void (*)(unsigned char *, int)'
[-Wincompatible-pointer-types]
331 | { 0x00, 0x00, section_PAT },
and many more.
The latest release dates back to 2007, the latest change in the CVS-
based source repository[1] (downloaded as dvbsnoop.zip) is also from
2007. No newer or maintained forks were found.
State of upstream ticket system[2]:
Bugs: last update 2012
Support Requests: No open tickets found.
Patches: last update 2010
Feature Requests: 1 from 2021, the rest 2012 and older
Instead of fixing build errors for an unmaintained project which is not
used by any other package we remove it from buildroot.
Fixes:
https://autobuild.buildroot.net/results/ea6/ea6786248b9ecf0eb1c1c1f7cdd0202462b75e00/
[1] https://sourceforge.net/p/dvbsnoop/cvs/
[2] https://sourceforge.net/p/dvbsnoop/_list/tickets
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The package is causing build errors with newer gcc versions:
procrank.c:381:9: error: implicit declaration of function 'asprintf';
did you mean 'vsprintf'? [-Wimplicit-function-declaration]
The latest upstream commit dates back to 2018 and no open issues/
bug reports are present so the projects seems unmaintained.
Instead of fixing build errors for such a project which is not used by
any other package we remove it from buildroot.
Fixes:
https://autobuild.buildroot.net/results/f2b/f2b41d27cf32808783b582e8ad714fb653c05713/
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
