Bernd Kuhls [Sun, 14 Dec 2025 17:15:30 +0000 (18:15 +0100)]
package/open-lldp: fix musl build with >= gcc-14.x
GCC >= 14.x is stricter amount having access to the prototypes of
functions being used, causing a build failure in open-lldp due to a
missing <string.h> include. This is only visible with musl probably
because with other C libraries <string.h> end up being included by
some other header.
Thomas Petazzoni [Sun, 14 Dec 2025 15:37:09 +0000 (16:37 +0100)]
toolchain/Config.in: drop BR2_TOOLCHAIN_HAS_GCC_BUG_121567
GCC bug 121567 is actually a duplicate of GCC bug 81426, which already
existed upstream, and for which we already had
BR2_TOOLCHAIN_HAS_GCC_BUG_81246.
In addition, BR2_TOOLCHAIN_HAS_GCC_BUG_81246 is correctly defined as
affecting SuperH regardless of the optimization level. Indeed, when
BR2_TOOLCHAIN_HAS_GCC_BUG_121567 was introduced, it was thought that
only -O2 and -O3 levels are affected, but -Og, -O1 and -Ofast are also
affected, causing the python3 build to fail.
Thomas Petazzoni [Sun, 14 Dec 2025 15:37:08 +0000 (16:37 +0100)]
package/python3: make SuperH tweak actually effective
In commit a68899d49ec4c7f97dea0dcb9995e6a5d7b282c9 ("package/python3:
work around GCC bug 121567"), we introduced a work around for a gcc
bug, by reducing to -O1 the optimization level on SuperH.
However, it turns out that this is not sufficient, as the build will
only succeeded at -O0.
Which is a config with BR2_OPTIMIZE_2=y, which means
BR2_TOOLCHAIN_HAS_GCC_BUG_121567=y, and therefore -O1 is passed, but
still the build fails. At -O0 the build doesn't fail.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Julien Olivain <ju.o@free.fr>
package/pixman: really enable NEON support on AArch64
The test to enable NEON on AArch64 is as following:
ifeq ($(BR2_aarch64)$(BR2_ARM_CPU_HAS_NEON),yy)
It cannot be to true as $(BR2_aarch64) and $(BR2_ARM_CPU_HAS_NEON) are
mutually exclusive. NEON is compulsory on AArch64 so remove
$(BR2_ARM_CPU_HAS_NEON) from the test.
Fixes: ba2fb599cd002b57fa70e978d91884c98d8aad05 ("package/pixman: bump to version 0.44.2") Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Bernd Kuhls [Sun, 21 Dec 2025 17:15:50 +0000 (18:15 +0100)]
package/libselinux: allow pip to use system-provided packages
Since the bump of pip to version 25.3 in commit 285097051d4a7dd821f01d15c705867f7e26c635, the build of the Python
bindings of libselinux is broken for both the host and target
variants.
For the host variant, because "pip install" no longer finds the
system-provided setuptools and tries to download setuptools by itself,
causing build issues because our host-python doesn't have SSL support:
Could not fetch URL https://pypi.org/simple/setuptools/: There was a problem confirming the ssl certificate: HTTPSConnectionPool(host='pypi.org', port=443): Max retries exceeded with url: /simple/setuptools/ (Caused by SSLError("Can't connect to HTTPS URL because the SSL module is not available.")) - skipping
For the target variant, because "pip install" no longer finds the
sysconfigdata package:
ModuleNotFoundError: No module named '_sysconfigdata__linux_sparc64-linux-gnu'
[end of output]
We fix this by taking a patch from Debian, which is slightly tweaked
to also cover our host package (the original Debian patch was passing
--no-build-isolation only when DESTDIR was not empty, but in Buildroot
host packages are built with DESTDIR empty, and we do need
--no-build-isolation).
This reverts commit fd991649d39c143fa60419691d01ffb816b39bf0, which
isn't the correct fix: indeed, host-libselinux can be built without
BR2_PACKAGE_PYTHON3 being enabled. And also having to use the network
during the build is anyway not correct.
A follow-up commit will fix this issue in a proper way.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Thomas Petazzoni [Fri, 26 Dec 2025 17:14:47 +0000 (18:14 +0100)]
package/opencv3: drop support for ffmpeg
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.
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>
Thomas Petazzoni [Fri, 26 Dec 2025 17:14:46 +0000 (18:14 +0100)]
package/opencv3: drop support for protobuf
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:
Thomas Petazzoni [Fri, 26 Dec 2025 17:14:45 +0000 (18:14 +0100)]
package/opencv3: add patch to fix CMake 4 build issue
Add a small patch to fix CMake 4 build issues. Unfortunately, while
cmake/OpenCVMinDepVersions.cmake provides a MIN_VER_CMAKE that we
could pass on the command line, cmake/OpenCVGenPkgconfig.cmake doesn't
use it, so we anyway have to patch the package.
Since opencv3 is basically unmaintained, there is no point sending
this patch upstream.
Thomas Petazzoni [Wed, 17 Dec 2025 22:25:38 +0000 (23:25 +0100)]
package/cppcms: change upstream to Github, bump to 2.0.1
cppcms.com now points to a Github page at
https://github.com/artyom-beilis/cppcms which has a 2.0.1 version, so
let's use that. The number of differences to 2.0.0.beta2 is very
small:
$ git log --online v2.0.0.beta2..v2.0.1 b872972 (tag: v2.0.1, origin/master, origin/HEAD, master) Version to 2.0.1 a1914f7 (tag: v2.0.0) Replaced system category with one from predating C++11 (v1.2) because std::system_category does not translate WSAGetLastError results c4febcc Merge pull request #104 from dreaming-augustin/upstream 922cd49 Python 3.12 compatibility: wrap regex in r''. a11e9d4 Merge branch 'cpp11' 3000bc6 (origin/1.2_updates) Merge pull request #99 from dreaming-augustin/master 44e24c7 [#89] cppcms_error fix typo + consistent messages a6d5575 (origin/cpp11) Added backtrace to system error b3aef3b Fixed missing include for stripped down build 463a9a6 Removed IPV6 due to travis limitations f8163c6 Merges from cpp11 31d4fe7 Added verbose log on failure 90bc996 Added Linux to build matrix - so I have fallback if normal build environment fails f78ee39 Added Readme for github a737d5d Merged python3 compatibility from master 0c67544 Support of python 2.7 and python 3 0d121a7 Python3 compatibility 2fc7e38 Python3 compatibility d745869 python3 fix for tmp_cc
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Julien Olivain <ju.o@free.fr>
Indeed, ICU now requires C++17, and while cppcms.mk has some logic to
get C++ flags using icu-config, the -std=c++17 gets ultimately
overridden by the built-in -std=c++11 flag encoded in cppcms
CMakeLists.txt.
To fix this, we have submitted a patch upstream that ensures the
CMAKE_CXX_FLAGS passed on the command line take precedence over the
built-in flags defined in cppcms CMakeLists.txt.
Thomas Petazzoni [Thu, 25 Dec 2025 21:32:57 +0000 (22:32 +0100)]
package/freerdp: fix build with CMake >= 4
freerdp upstream is now at 3.x, far far ahead of what we're using in
Buildroot at the moment. So to fix the CMake >= 4 build, we add a very
simple non-upstreamable patch (upstream 3.x has a much higher CMake
minimum version already).
Thomas Petazzoni [Fri, 26 Dec 2025 17:12:06 +0000 (18:12 +0100)]
package/gli: add patch to fix CMake 4 build
Fixes:
CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
Compatibility with CMake < 3.5 has been removed from CMake.
Update the VERSION argument <min> value. Or, use the <min>...<max> syntax
to tell CMake that the project requires at least <min> but has been updated
to work with policies introduced by <max> or earlier.
Or, add -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to try configuring anyway.
Thomas Petazzoni [Wed, 17 Dec 2025 22:33:16 +0000 (23:33 +0100)]
package/cppdb: fix compatibility with CMake 4
Fixes:
CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
Compatibility with CMake < 3.5 has been removed from CMake.
Update the VERSION argument <min> value. Or, use the <min>...<max> syntax
to tell CMake that the project requires at least <min> but has been updated
to work with policies introduced by <max> or earlier.
Or, add -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to try configuring anyway.
We didn't submit the patch upstream, because contrary to cppcms, cppdb
seems completely dead. Last commit is from 2012 at
https://sourceforge.net/p/cppcms/code/HEAD/tree/cppdb/.
There are no known autobuilder failures for this issue.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Julien Olivain <ju.o@free.fr>
Maxime Leroy [Mon, 22 Dec 2025 21:56:33 +0000 (22:56 +0100)]
package/libecoli: bump version to 0.10.1
This new version is required to compile grout v0.14.2.
See the release note of the new versions:
https://github.com/rjarry/libecoli/releases/tag/v0.10.1
https://github.com/rjarry/libecoli/releases/tag/v0.10.0
https://github.com/rjarry/libecoli/releases/tag/v0.9.1
Signed-off-by: Maxime Leroy <maxime@leroys.fr> Signed-off-by: Julien Olivain <ju.o@free.fr>
CMake Error at cmake/Embed.cmake:3 (find_program):
Could not find XXD using the following names: xxd
Call Stack (most recent call first):
src/stdlib/CMakeLists.txt:1 (include)
There are no autobuilder failures for this issue at this point, but
the following defconfig exhibits the issue (of course on a host where
xxd is not installed system-wide):
Switched _SITE to github, the previous URL redirects to github.com.
Removed patches which are included in this release.
License file was renamed and updated:
https://github.com/resiprocate/resiprocate/commits/resiprocate-1.13.2/LICENSE.md
Switch build system to cmake, removed apps-specific option:
- sipdial is built if OpenSSL is enabled:
https://github.com/resiprocate/resiprocate/blob/resiprocate-1.13.2/apps/CMakeLists.txt#L6
- clicktocall build is broken
AddressTranslator.cxx: In member function 'void clicktocall::AddressTranslator::
addTranslation(const resip::Data&, const resip::Data&)':
AddressTranslator.cxx:55:16: error: assignment of read-only variable 'flags'
55 | flags |= std::regex_constants::nosubs;
Bernd Kuhls [Sun, 7 Dec 2025 14:42:33 +0000 (15:42 +0100)]
package/{libtorrent, rtorrent}: bump version to 0.15.3
Removed patches which are included in this release.
Switched SITE to github according to http://rtorrent.net/
Both packages need to be bumped together due to version check for
libtorrent by rtorrent:
https://github.com/rakshasa/rtorrent/commit/6f8c1246dc013d1d5c39ecd66373346ac42fe746
https://github.com/OGRECave/ogre/blob/v14.4.1/Docs/13-Notes.md
"The versioning scheme changed with this release. This is the successor
to Ogre 1.12 and the porting efforts are comparable with porting from
1.11 to 1.12."
Thomas Petazzoni [Tue, 23 Dec 2025 18:10:10 +0000 (19:10 +0100)]
package/vim: refactor install target logic
Instead of calling $(MAKE) multiple times, let's call it once, with
all installation targets needed. We introduce a VIM_INSTALL_TARGETS
variable to collect the list of make install targets that need to be
invoked.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Julien Olivain <ju.o@free.fr>
Thomas Petazzoni [Tue, 23 Dec 2025 18:10:08 +0000 (19:10 +0100)]
package/vim: fix reinstallation
While not very common, it is nice when package re-installation
works. Unfortunately the "installlinks" target of vim installs links
with "ln -s", causing a package reinstallation to fail with:
cd /home/thomas/buildroot/br/output-all/target/usr/bin; ln -s vim ex
cd /home/thomas/buildroot/br/output-all/target/usr/bin; ln -s vim view
cd /home/thomas/buildroot/br/output-all/target/usr/bin; ln -s vim rvim
cd /home/thomas/buildroot/br/output-all/target/usr/bin; ln -s vim rview
cd /home/thomas/buildroot/br/output-all/target/usr/bin; ln -s vim vimdiff
ln: failed to create symbolic link 'ex': File exists
ln: failed to create symbolic link 'view': File exists
make[2]: *** [Makefile:2749: /home/thomas/buildroot/br/output-all/target/usr/bin/ex] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: *** [Makefile:2752: /home/thomas/buildroot/br/output-all/target/usr/bin/view] Error 1
ln: failed to create symbolic link 'rvim': File exists
ln: failed to create symbolic link 'rview': File exists
To fix this, we remove the target links before proceeding with the
installation.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Julien Olivain <ju.o@free.fr>
Maxime Leroy [Mon, 15 Dec 2025 11:43:00 +0000 (12:43 +0100)]
package/grout: bump to 0.14.2 version
See the release note of the new versions:
https://github.com/DPDK/grout/releases/tag/v0.14.0
https://github.com/DPDK/grout/releases/tag/v0.14.1
https://github.com/DPDK/grout/releases/tag/v0.14.2
Since v0.14.0, Grout uses the libmnl [1], the dependency are updated in
consequence. Grout also requires VRF support in the kernel, as it creates
a VRF on the Linux side to allow TCP/UDP termination by Linux
applications in different L3 domains. [2]
A few changes in the license files and an actual (sub)-license update:
* django/contrib/gis/measure.py -> formatting change
* django/contrib/admin/static/admin/img -> svg files got uupdated and
the new ones are licensed under CC-BY-4.0; separate LICENSE file got
removed, License is now mentioned in the readme
* django/utils/archive.py -> File got updated, license (which is only
the header) did not change.
Remove the comment about django site having an inconvenient download
URL. We download pretty much all python package from pypi.org, so doing
that for django shouldn't need a separate comment.
Signed-off-by: Marcus Hoffmann <buildroot@bubu1.eu> Signed-off-by: Julien Olivain <ju.o@free.fr>
Marcus Hoffmann [Mon, 22 Dec 2025 14:54:26 +0000 (15:54 +0100)]
package/python-django: security bump to 5.2.9
Fixes:
* CVE-2025-13372: Potential SQL injection in FilteredRelation column aliases on PostgreSQL
* CVE-2025-64460: Potential denial-of-service vulnerability in XML Deserializer
Full release notes: https://docs.djangoproject.com/en/6.0/releases/5.2.9/
Signed-off-by: Marcus Hoffmann <buildroot@bubu1.eu> Signed-off-by: Julien Olivain <ju.o@free.fr>
projects / 0xmirror / buildroot.git / log