Add a defconfig to run Linux on a HP Visualize B160L PA-RISC
Workstation, emulated with Qemu.
While at it, add this defconfig to myself in DEVELOPERS.
Signed-off-by: Vincent Stehlé <vincent.stehle@laposte.net>
Cc: Romain Naour <romain.naour@gmail.com>
[Julien: update kernel to 6.18.7 to align with other qemu defconfigs]
Signed-off-by: Julien Olivain <ju.o@free.fr>
Add support for the Precision Architecture (a.k.a. PA-RISC),
a 32-bit architecture developed by Hewlett Packard.
While at it, add this arch to myself in DEVELOPERS.
Signed-off-by: Vincent Stehlé <vincent.stehle@laposte.net>
Cc: Romain Naour <romain.naour@gmail.com>
Cc: Julien Olivain <ju.o@free.fr>
[Julien: arch "arch/" prefix in commit title]
Signed-off-by: Julien Olivain <ju.o@free.fr>
Support STM32h747i-disco board. It includes an STM32H747XI SoC with the
following resources:
- 2 Mbytes Flash
- 1 Mbyte SRAM
- LCD-TFT controller
- MIPI-DSI interface
- FD-CAN
- USB 2.0 high-speed/full-speed
- Ethernet MAC
- camera interface
Detailed information can be found at:
https://www.st.com/en/evaluation-tools/stm32h747i-disco.html
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
- i don't use grpc anymore and updates seem complicate to review,
so drop me from it and its dependency re2
- add packages i'm currently using
Signed-off-by: Michael Nosthoff <buildroot@heine.tech>
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>
K3CONF is a Linux user-space standalone application
designed to provide a quick'n easy way to dynamically
diagnose Texas Instruments' K3 architecture based
processors. K3CONF is intended to provide similar
experience to that of OMAPCONF that runs on legacy TI platforms.
K3CONF currently supports Texas Instruments AM654, J721E, J7200,
AM64x,AM62x,J721S2,J784S4,J722S, AM62Ax, AM62Px, and AM62Lx devices.
Along with the BeagleBoard variants of the above mentioned TI SOC's.
Signed-off-by: Mohammed Sadik Shaik <s-sadik@ti.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Introduce a package for the restool program, which permits the user to
modify the network configuration of the DPAA2 subsystem and create one
that is adequate to their use case.
We integrate the master branch, which is effectively the
lf-6.12.20-2.0.0 release tag, plus some extra fixups specifically made
for the Buildroot integration:
- commit b44748ed0bb3 ("Avoid use of non-portable __WORDSIZE when
defining BITS_PER_LONG")
- commit b4a734f3512b ("restool: fix format string for 64 bit time_t in
parse_obj_command()")
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Reviewed-by: Vincent Jardin <vjardin@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This commit adds "kibi" a configurable text editor with UTF-8 support,
incremental search, syntax highlighting, line numbers and more, written
in less than 1024 lines of Rust with minimal dependencies.
https://github.com/ilai-deutel/kibi
Signed-off-by: Alexander Shirokov <shirokovalexs@gmail.com>
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>
An advanced terminal multiplexer with batteries included. Supports
layouts, floating and stacked panes, plugins, and customization.
Provides rich functionality out of the box.
Zellij is aimed at developers, operations-oriented users, and anyone who
loves the terminal.
https://github.com/zellij-org/zellij
Signed-off-by: Alexander Shirokov <shirokovalexs@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This patch adds libplacebo package that is used
by mpv player.
libplacebo is the core rendering algorithms and
ideas of mpv rewritten as an independent library
and contains a large assortment of video processing
shaders, focusing on both quality and performance.
Signed-off-by: Javad Rahimipetroudi <javad.rahimipetroudi@mind.be>
Tested-by: Sen Hastings <sen@hastings.org>
[Bernd:
- bumped to v7.351.0
- moved Kconfig option to Multimedia (Sen)
- rebased patch 0001 after version bump
- added project URL to Config.in helptext
- removed redundancy in Config.in comment
- added comment to hash file
- switched _SITE to official repo
- added patch to fix build error with latest python3]
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
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>
Rasdaemon was added in previous patch.
Add a test_rasdaemon that allows to test it.
Test is done on x86. It first checks the daemon's version, then mounts
debugfs and finally ensures that the init script allows to
start/restart/stop the daemon.
Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Rasdaemon is a tool that aims at replacing edac-tool and provide a way
to collect all hardware error events reported by the Linux kernel in a
common framework.
This commit adds a new package to support rasdaemon in the 'Hardware
handling' section. It depends on libtraceevent to detect the ftrace
events generated by the kernel. There is currently a build issue when
sqlite isn't availaible while it's supposed to be an optional
dependency. This build issue is fixed by patch 0001 (which has been
also submitted to the rasdaemon project itself).
Support for the PCIe AER events is optionnal and implies a dependency on
pciutils so also add a dedicated 'sub-option' to enable it.
Add a SYSV init script to start / stop the daemon
Add myself to the DEVELOPERS file.
Reviewed-by: Fiona Klute <fiona.klute@gmx.de>
Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
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>
AIChat helps seamlessly integrate different LLM models, providing access
via the CLI and network. It can serve as a gateway to heterogeneous and
distributed LLMs.
Handy features like roles, macros, and sessions help simplify repetitive
tasks and reuse of existing solutions. Features like playgrounds and
arenas help to explore and compare models.
https://github.com/sigoden/AIChat
Signed-off-by: Alexander Shirokov <shirokovalexs@gmail.com>
[Julien:
- select BR2_PACKAGE_HOST_RUSTC instead of "depends on"
- add Apache-2.0 license (package is dual licensed)
- add LICENSE-APACHE license hash
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
