Tracking: skiff vs upstream-master#19
Draft
paralin wants to merge 2946 commits into
Draft
Conversation
Signed-off-by: Christian Stewart <christian@aperture.us>
Signed-off-by: Christian Stewart <christian@aperture.us>
Daemonize is a command line utility to run a program as a Unix daemon. Signed-off-by: Christian Stewart <christian@aperture.us> --- TODO: Changes requested for v2: https://patchwork.ozlabs.org/project/buildroot/patch/20210124102241.1207866-1-christian@paral.in/
Adds both host and target packages for buildah. Buildah is a tool that facilitates building OCI images. https://github.com/containers/buildah The buildah tree does not ship with a default policy.json file, and instead relies on packagers to provide one. A patch is added to create a basic barebones policy.json which is installed to /etc/containers/policy.json with a hook. Signed-off-by: Christian Stewart <christian@aperture.us> --- v1 -> v2: - add package to developers - add host runc dependency for host package - add libgpgme runtime dependency v2 -> v3: - add policy.json to target: required by some commands - example: buildah pull docker.io/library/alpine - pull: tested on raspberry pi 4 v3 -> v4: - TODO: move policy.json to package dir - https://lists.buildroot.org/pipermail/buildroot/2022-January/634936.html - bump to version v1.32.1 - https://github.com/containers/buildah/releases/tag/v1.32.1 v4 -> v5: - bump to version 1.35.x Signed-off-by: Christian Stewart <christian@aperture.us>
Add a symlink to the expected location for vpdma-1ba in the root of the firmware directory. Signed-off-by: Christian Stewart <christian@aperture.us>
0915eeb to
7af4c59
Compare
c5e35c6 to
ba56dae
Compare
0d083d6 to
99d3e37
Compare
Signed-off-by: Christian Stewart <christian@paral.in>
Lack of an RNG source can block boot-up on headless systems with few hardware entropy sources. This patch allows rngd to start earlier than the current "basic.target" when systemd is used. Removing the dependency on "basic.target" and by extension, "sockets.target" will allow rngd to start before, for example, docker.sock - which can take some time to become ready without entropy. This is a cherry-pick of a peer project patch: https://patchwork.openembedded.org/patch/163303/ Signed-off-by: Christian Stewart <christian@aperture.us>
75f485c to
f8af779
Compare
Buildroot commit 97e2f63 bumped bpftrace from 0.23.3 to 0.24.2. This release includes upstream commit bpftrace/bpftrace@7578314 which was added to version 0.24.0 and makes use of bpf_iter_link_info.task that was added to the linux kernel in version 6.1: torvalds/linux@f0d74c4 causing build errors when the toolchain contains kernel headers version 6.0 because the libbpf package does not update their headers: output/build/bpftrace-0.24.2/src/attached_probe.cpp: In static member function 'static bpftrace::Result<std::unique_ptr<bpftrace::AttachedIterProbe> > bpftrace::AttachedIterProbe::make(bpftrace::Probe&, const bpftrace::BpfProgram&, std::optional<int>)': output/build/bpftrace-0.24.2/src/attached_probe.cpp:1437:11: error: 'union bpf_iter_link_info' has no member named 'task' 1437 | linfo.task.pid = *pid; The build error can be reproduced with this defconfig BR2_aarch64=y BR2_KERNEL_HEADERS_VERSION=y BR2_DEFAULT_KERNEL_VERSION="6.0.19" BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_6_0=y BR2_TOOLCHAIN_BUILDROOT_CXX=y BR2_PER_PACKAGE_DIRECTORIES=y BR2_PACKAGE_BPFTRACE=y on the 2026.02.x branch as of 0be927b89a319c9ac35249354558e9f4cb102fd0. Fixes: https://autobuild.buildroot.net/results/146/14671c54fdf0a2e44bcce7ff61ca9b89a925eca9/ Signed-off-by: Bernd Kuhls <bernd@kuhls.net> Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Since Buildroot commit dcee995 in 2025.11-rc1 that bumped package/icu to version 77-1, the build of xerces with ICU support enabled fails: In file included from /home/bernd/buildroot/output/host/i586-buildroot-linux-gnu/sysroot/usr/include/unicode/uset.h:38, from /home/bernd/buildroot/output/build/xerces-3.3.0/src/xercesc/util/regx/RangeToken.cpp:40: /home/bernd/buildroot/output/host/i586-buildroot-linux-gnu/sysroot/usr/include/unicode/char16ptr.h:271:55: error: 'is_same_v' is not a member of 'std'; did you mean 'is_same'? Indeed, ICU now requires C++17. Instead of using a patch from Gentoo[1] we use a backported upstream commit, limited to CMakeLists.txt, to raise the c++ version. The build error was not recorded yet by the autobuilders but can be reproduced with this defconfig: BR2_TOOLCHAIN_BUILDROOT_CXX=y BR2_PACKAGE_XERCES=y BR2_PACKAGE_ICU=y [1] https://bugs.gentoo.org/931105 Signed-off-by: Bernd Kuhls <bernd@kuhls.net> Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Commit fb53371 introduced the python-gymnasium package, but it was not careful enough to propagate dependencies of selected packages, causing messages such as: WARNING: unmet direct dependencies detected for BR2_PACKAGE_PYTHON_NUMPY Depends on [n]: BR2_PACKAGE_PYTHON3 [=y] && BR2_PACKAGE_PYTHON_NUMPY_ARCH_SUPPORTS [=y] && BR2_INSTALL_LIBSTDCPP [=n] && (BR2_TOOLCHAIN_USES_GLIBC [=y] || BR2_TOOLCHAIN_USES_MUSL [=n]) && BR2_TOOLCHAIN_GCC_AT_LEAST_9 [=y] Selected by [y]: - BR2_PACKAGE_PYTHON_GYMNASIUM [=y] && BR2_PACKAGE_PYTHON3 [=y] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Buildroot commit 29888ab bumped cairo to version 1.18.2. This version includes commit https://gitlab.freedesktop.org/cairo/cairo/-/commit/87f7c60bf7c20079c34cfc54e4db05920d14db56 "Add support for C11 atomics" which causes build errors: ../src/cairo-image-source.c: In function '_pixman_transparent_image': ../src/cairo-image-source.c:89:40: error: passing argument 1 of '_cairo_atomic_ptr_cmpxchg_impl' from incompatible pointer type [-Wincompatible-pointer-types] 89 | if (_cairo_atomic_ptr_cmpxchg (&__pixman_transparent_image, Fixes: 1.18.2: https://autobuild.buildroot.net/results/5d4/5d4cd38d71008f385f92577b07f21dcfc3c19b38/ 1.18.4: https://autobuild.buildroot.net/results/0e9/0e962c66e1e96b5899e87c13ace824379adc09f9/ Signed-off-by: Bernd Kuhls <bernd@kuhls.net> Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
…not set If we don't disable it, the assimp module from the sources will be used instead of none. Unfortunately, it currently doesn't build so let's disable it when BR2_PACKAGE_ASSIMP is not set such that one can still build qt53d. Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
If we're adding a dependency to the package, it's for its build system to use it. Unfortunately, when -feature-system-assimp is not passed, the assimp module from the sources will be used. Moreover, it doesn't build currently. Unfortunately, qt53d still doesn't build with assimp from Buildroot. Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Neither Buildroot's nor the module from qt53d sources compile, so always disable assimp support. Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Commit c53455e ("package/qt5/qt5webengine-chromium: bump version after qtwebengine bump") bumped qt5webengine-chromium but forgot to update the licenses. The diff of the license is reported by git diff 0ad2814370799a2161057d92231fe3ee00e2fe98..18c9261dc5b8aa57a0bdd5b62ce6f648cca1ef5e -- chromium/third_party/zlib/LICENSE as the following: diff --git a/chromium/third_party/zlib/LICENSE b/chromium/third_party/zlib/LICENSE index 9f056865b57..8aca25d8c7a 100644 --- a/chromium/third_party/zlib/LICENSE +++ b/chromium/third_party/zlib/LICENSE @@ -1,6 +1,6 @@ -version 1.2.11, January 15th, 2017 +version 1.2.12, March 27th, 2022 -Copyright (C) 1995-2017 Jean-loup Gailly and Mark Adler +Copyright (C) 1995-2022 Jean-loup Gailly and Mark Adler This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages so it doesn't change its actual license, let's simply fix the sha256 to the new value. Fixes: c53455e ("package/qt5/qt5webengine-chromium: bump version after qtwebengine bump") Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Add upstream patch to fix build failure with Linux 6.19. Upstream: aircrack-ng/rtl8812au@f17facc Signed-off-by: Christian Stewart <christian@aperture.us> [Arnout: update upstream reference to merged commit] Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Fixes: https://autobuild.buildroot.net/results/2e3/2e33c61e1c9bee099f973c1e43b696c63e5eed4b/ Building lrzsz with this defconfig works: BR2_GCC_VERSION_13_X=y BR2_PACKAGE_LRZSZ=y and gets broken when switched to gcc 14: BR2_PACKAGE_LRZSZ=y Signed-off-by: Bernd Kuhls <bernd@kuhls.net> Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
VERSION should ideally contain only the version, i.e 2.12 and not some additional prefix like liburing- as it prevents our logic matching against release-monitoring.org data to work properly. Fixes: d2ed456 ("package/liburing: bump to version 2.12") Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Marcus Hoffmann <buildroot@bubu1.eu>
The CI minute cost estimate is wrong for two reasons:
1) Job duration was in minutes instead of seconds
2) The cost factor is really 0,5 [1] instead of
based on runner type * 0,5.
Due to this two mistake, the real CI minute cost is 7982.1 [2] instead
of 350.
Since we want to backport this patch, having a correct CI minute cost
estimate in the commit log would be better. Lets revert last changes
about runner tag and try again.
[1] https://docs.gitlab.com/ci/pipelines/compute_minutes/#cost-factors-of-hosted-runners-for-gitlabcom
[2] https://gitlab.com/buildroot.org/buildroot/-/pipelines/2562421098
This reverts commit 3803941.
This reverts commit 825abb2
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
We have our own GitLab-CI runner, but with only one we can't run many
jobs in parallel so it takes a very long time before all the tests have
completed. In addition, if that runner goes down, we have nothing at
all.
GitLab offers the following machine types for hosted runners on Linux
x86-64 [1]. The default is the "small" runner. Using a larger runner
increases the "Cost factor" [2].
For opensource projects, the Cost factor is reduced to 0.5 (1 minute per
2 minutes of job time) whatever the runner type.
Runner Tag vCPUs Memory Storage Cost factor (OSS)
saas-linux-small-amd64 (default) 2 8 GB 30 GB 1 (0.5)
saas-linux-medium-amd64 4 16 GB 50 GB 2 (0.5)
saas-linux-large-amd64 (Premium and Ultimate only) 8 32 GB 100 GB 3 (0.5)
saas-linux-xlarge-amd64 (Premium and Ultimate only) 16 64 GB 200 GB 6 (0.5)
saas-linux-2xlarge-amd64 (Premium and Ultimate only) 32 128 GB 200 GB 12 (0.5)
Compute minutes consumed by a job is calculated by:
Job duration / 60 * Cost factor
(Job duration: The time, in seconds, that a job took to run, not
including time spent in the created or pending statuses.)
Thanks to the GitLab OSS program [3], Buildroot benefits from a free
Ultimate subscription and can use GitLab shared runners tagged with
saas-linux-{large, xlarge, 2xlarge}-amd64. In addition, we receive
50,000 free runner minutes per month.
In order to use one of those tags in Buildroot GitLab-CI jobs, we have
to classify all tests by resource requirement, to make sure the job
doesn't fail because it times out or has insufficient memory or disk
space. While we usually shouldn't use the largest runner for
everything, we can use larger runner without cost penalty thanks to
the cost factor reduced to 0.5 for opensource projects. This will
reduce the CI minutes consumed by a CPU intensive job.
First we introduce some new templates used to add the corresponding
runner tag to a runtime test job (reusing the GitLab terminology).
.runner-{small,medium,large,xlarge,2xlarge}
Most of our tests are fast (checkpackage, test_external_bootlin...), so
saas-linux-small-amd64 runner tag is enough. Default to this tag if
nothing else is specified.
Add a comment next to the test class to provide the runner tag.
This runner tag is retrieved when generating the
generated-gitlab-ci.yml file used to create the child pipeline where
the runtime test jobs are executed.
We use the list of runtime tests returned by node2:
"tests.boot.test_edk2.TestEdk2.test_run"
We convert each element of this list to get the path to the test source
file and the name of the test:
"support/testing/tests/boot/test_edk2.py"
TestEdk2
With that, we can grep into the test source file to retrieve the runner
tag placed one line above the test class:
# GitLab-runner: large
class TestEdk2(infra.basetest.BRTest):
Once the runner tag is retrieved, it's used to use the corresponding
runner template to the runtime test job:
tests.boot.test_edk2.TestEdk2.test_run: { extends: [ .runtime_test_base, .runner-large ]}
GitLab runners hosted by the Buildroot project should be able to run
any jobs, so they should be tagged with Gitlab runner tags
(saas-linux-{small,medium,large,xlarge,2xlarge}-amd64).
A specific runner tag "buildroot-runner" can be used to allow running
a job only on such runners.
If a test can't be executed by any shared GitLab-CI runners, we have
to use a runner owned by the Buildroot project. In this case we have
to use a specific template ".runner-buildroot-runner-only" in order to
add the specific runner tag "buildroot-runner" to the job running the
test. There is no such runtime test at the moment.
The proposed classification is based on a previous pipeline analysis
[5]:
- Tests lasting more than 3 hours will use 2xlarge runners.
- Tests lasting more than 2 hours will use xlarge runners.
- Tests lasting more than 1 hours will use large runners.
- Tests building a kernel or a toolchain will use medium runners.
- All other tests will use small runners when possible.
CI minute cost estimate:
tests.package.test_clang.TestClangCompilerRT.test_run lasts 4h25 on the
Buildroot runner. If we this duration for 2xlarge runners, the CI
minute consumed would be:
(15900 / 60) * 0.5 = 133
With 6 jobs using a 2xlarge runners we used ~795 CI minutes.
tests.package.test_kmscube.TestKmsCube.test_run list 2h04 on the
Buildroot runner. If we this duration for xlarge runners, the CI
minute consumed would be:
(7440 / 60) * 0.5 = 62
With 4 jobs using a xlarge runners we used ~248 CI minutes.
tests.package.test_weston.TestWeston.test_run last 1h15 on th
Buildroot runner. If we this duration for large runners, the CI
minute consumed would be:
(4500 / 60) * 0.5 = 37.5
With 28 jobs using a large runners we used ~1050 CI minutes.
tests.package.test_gstreamer1.TestGstreamer1.test_run last 46min on the
Buildroot runner. If we this duration for large runners, the CI
minute consumed would be:
(2760 / 60) * 0.5 = 23
With 31 jobs using a medium runners we used ~713 CI minutes.
tests.package.test_python.TestPython3Py.test_run last 13min on the
Buildroot runner. If we this duration for large runners, the CI
minute consumed would be:
(780 / 60) * 0.5 = 6.5
With 691 jobs using a medium runners we used ~4491 CI minutes.
In total, one pipeline for the runtime tests cost ~7297 CI minutes.
After a first try [6], we are actually using 8000 CI minutes per
pipeline.
We run such pipeline once a week (on Monday), one for each Buildroot
releases every 3 month, one for each stable and LTS release per month,
and one for each release candidate (3).
Worst case (release month):
(4 weeks + 1 release + 1 stable + 1 LTS + 3 release candidate) * 8000 CI
minutes: 80000 CI minutes / 50000.
So we would spend the minutes very quickly in the worst case scenario.
We have to keep one pipeline under 5000 CI minutes.
[1] https://docs.gitlab.com/ci/runners/hosted_runners/linux/#machine-types-available-for-linux---x86-64
[2] https://docs.gitlab.com/ci/pipelines/compute_minutes/#cost-factors
https://docs.gitlab.com/ci/pipelines/compute_minutes/#compute-usage-calculation
https://docs.gitlab.com/ci/pipelines/compute_minutes/#cost-factors-of-hosted-runners-for-gitlabcom
[3] https://gitlab.com/buildroot.org/gitlab-oss
[4] https://docs.gitlab.com/ci/runners/hosted_runners/#gitlabcom-hosted-runner-workflow
[5] https://gitlab.com/buildroot.org/buildroot/-/pipelines/2416603721
[6] https://gitlab.com/buildroot.org/buildroot/-/pipelines/2562421098
Signed-off-by: Romain Naour <romain.naour@smile.fr>
[Arnout:
- simplify parsing of test_file and test_name;
- match the entire test_name instead of substring;
- assume "small" by default;
- remove the "small" tags;
- use "gitlab-runner" instead of "Gitlab-runner".
]
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
…er pipeline Based on the first pipeline result [1], use larger runner for the following tests: tests.fs.test_oci.TestOci.test_run (01:08:15) saas-linux-small-amd64 -> saas-linux-xlarge-amd64 tests.package.test_dpdk.TestDPDK.test_run (01:08:36) saas-linux-small-amd64 -> saas-linux-xlarge-amd64 tests.package.test_z3.TestZ3.test_run (01:11:41) saas-linux-small-amd64 -> saas-linux-xlarge-amd64 tests.package.test_octave.TestOctave.test_run (01:21:57) saas-linux-small-amd64 -> saas-linux-xlarge-amd64 tests.package.test_podman.TestPodmanSlirpNftables.test_run (01:21:15) saas-linux-small-amd64 -> saas-linux-xlarge-amd64 tests.package.test_podman.TestPodmanSlirpIptables.test_run (01:21:25) saas-linux-small-amd64 -> saas-linux-xlarge-amd64 tests.package.test_mariadb.TestMariaDB.test_run (01:26:15) saas-linux-small-amd64 -> saas-linux-xlarge-amd64 tests.package.test_podman.TestPodmanIptables.test_run (01:28:51) saas-linux-small-amd64 -> saas-linux-xlarge-amd64 tests.package.test_podman.TestPodmanTini.test_run (01:29:08) saas-linux-small-amd64 -> saas-linux-xlarge-amd64 tests.package.test_podman.TestPodmanNftables.test_run (01:41:26) saas-linux-small-amd64 -> saas-linux-xlarge-amd64 tests.package.test_weston.TestWeston.test_run (01:26:17) saas-linux-large-amd64 -> saas-linux-2xlarge-amd64 tests.package.test_python_pyqt5.TestPythonPyQt5.test_run (01:41:33) saas-linux-large-amd64 -> saas-linux-2xlarge-amd64 tests.package.test_nodejs.TestNodeJSModuleHostBin.test_run (01:21:06) saas-linux-large-amd64 -> saas-linux-2xlarge-amd64 tests.package.test_flutter.TestFlutter.test_run (01:03:05) saas-linux-xlarge-amd64 -> saas-linux-2xlarge-amd64 For tests long that already use 2xlarge runner tag, we may have to run them on Gitlab runners owned by the Buildroot project. [1] https://gitlab.com/buildroot.org/buildroot/-/pipelines/2562421098 Signed-off-by: Romain Naour <romain.naour@smile.fr> Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Commit 9e7172c bumped postgresql and had to disable postgresql on Sparc. This dependency was unfortunately not properly propagated to BR2_PACKAGE_PHP_EXT_PDO_POSTGRESQL, causing the following Kconfig warning: WARNING: unmet direct dependencies detected for BR2_PACKAGE_POSTGRESQL Depends on [n]: BR2_USE_MMU [=y] && !BR2_sparc [=y] && BR2_USE_WCHAR [=y] && BR2_ENABLE_LOCALE [=y] && BR2_TOOLCHAIN_HAS_THREADS_NPTL [=y] && !BR2_STATIC_LIBS [=n] && !BR2_OPTIMIZE_FAST [=n] Selected by [y]: - BR2_PACKAGE_PHP_EXT_PDO_POSTGRESQL [=y] && BR2_PACKAGE_PHP [=y] && BR2_PACKAGE_PHP_EXT_PDO [=y] && BR2_USE_MMU [=y] && BR2_USE_WCHAR [=y] && BR2_ENABLE_LOCALE [=y] && BR2_TOOLCHAIN_HAS_THREADS_NPTL [=y] && !BR2_STATIC_LIBS [=n] && !BR2_OPTIMIZE_FAST [=n] We fix this by properly propagating the dependency. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
qt5serialport is only needed when GPS support is enabled: https://github.com/Stellarium/stellarium/blob/v25.4/CMakeLists.txt#L623, so having qt5serialport without gpsd doesn't bring anything. Please note that we disable telescope support by default so only gpsd enables the usage of qt5serialport. Signed-off-by: Bernd Kuhls <bernd@kuhls.net> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Building Stellarium includes the download of external tarballs during
configure.
This fails with host-cmake during configure stage:
CMake Error at md4c-subbuild/md4c-populate-prefix/src/md4c-populate-stamp/download-md4c-populate.cmake:163 (message):
Each download failed!
error: downloading 'https://github.com/mity/md4c/archive/refs/tags/release-0.5.2.tar.gz' failed
status_code: 1
status_string: "Unsupported protocol"
log:
--- LOG BEGIN ---
Protocol "https" not supported
closing connection #-1
due to buildroot commit f871383 which
disabled SSL support for host-cmake.
This patch uses _EXTRA_DOWNLOADS to provide these tarball to allow
offline builds.
No autobuilder error was recorded, the build error can be reproduced
with this defconfig:
BR2_x86_64=y
BR2_x86_corei7=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_X86_64_CORE_I7_GLIBC_BLEEDING_EDGE=y
BR2_FORCE_HOST_BUILD=y
BR2_PACKAGE_STELLARIUM=y
BR2_PACKAGE_MESA3D=y
BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_SOFTPIPE=y
BR2_PACKAGE_MESA3D_OPENGL_GLX=y
BR2_PACKAGE_QT5=y
BR2_PACKAGE_XORG7=y
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Commit 53bb7ea ("package/arm-trusted-firmware: add ARM_TRUSTED_FIRMWARE_CPE_ID_*") added logic to set the cpe-id version from the package version by dropping a v or lts- prefix, but it used subst instead of patsubst - So it would replace "v" and "lts-" anywhere in the version and not only in the beginning of it. Change to patsubst to fix that. E.G. with the following defconfig: BR2_aarch64=y BR2_TARGET_ARM_TRUSTED_FIRMWARE=y BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_VERSION=y BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_VERSION_VALUE="version-with-v-or-lts-in-it" before: make printvars VARS=ARM_TRUSTED_FIRMWARE_CPE_ID_VERSION ARM_TRUSTED_FIRMWARE_CPE_ID_VERSION=ersion-with--or-in-it after: make printvars VARS=ARM_TRUSTED_FIRMWARE_CPE_ID_VERSION ARM_TRUSTED_FIRMWARE_CPE_ID_VERSION=ersion-with-v-or-lts-in-it Signed-off-by: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
https://github.com/mm2/Little-CMS/releases/tag/lcms2.19.1 "lcms2-2.19.1 is a hot-fix release" https://github.com/mm2/Little-CMS/blob/lcms2.19.1/ChangeLog Signed-off-by: Bernd Kuhls <bernd@kuhls.net> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Bump to version 2026-05-19 on branch v5.2.2.4 to fix build failure with Linux 7.1. Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
…7.1+ Update rtl8822cs driver latest of the jethome-iot/rtl88x2cs. Signed-off-by: Viacheslav Bocharov <v@baodeep.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Add local patch pending upstream to fix build failure with Linux >= 7.1.0. Fixes: still not occured Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Fixes the following security issue (in 2.8.10): CVE-2026-35444: Heap buffer overflow READ via unchecked colormap index in XCF loader GHSA-gq8w-x74c-h6p7 In addition, 2.8.12 includes a number of memory related bugfixes: Fixed memory overflow with corrupt LBM image Fixed crash when decoding an invalid XCF image Fixed out of bound read in GIF decoder Update hash of license file for change of copyright year with: libsdl-org/SDL_image@281b4eb Signed-off-by: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Seen with this defconfig BR2_x86_64=y BR2_GCC_VERSION_15_X=y BR2_TOOLCHAIN_BUILDROOT_CXX=y BR2_PACKAGE_PICOTOOL=y output/host/x86_64-buildroot-linux-gnu/sysroot/usr/include/bits/struct_mutex.h:35:9: error: declaration does not declare anything [-fpermissive] 35 | short __unused; No related autobuilder error was recorded. The build error does not occur with glibc-2.42 on the 2026.02.x branch. The build error was reported to picotool upstream: raspberrypi/picotool#300 Signed-off-by: Bernd Kuhls <bernd@kuhls.net> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
gcc_stack_unix.c: In function 'x_cgo_getstackbound': gcc_stack_unix.c:28:9: error: implicit declaration of function 'pthread_getattr_np'; did you mean 'pthread_attr_init'? [-Wimplicit-function-declaration] 28 | pthread_getattr_np(pthread_self(), &attr); // GNU extension Fixes: https://autobuild.buildroot.net/results/e07/e07198d7864331027d21cd2109054d86e7ac1c3d/ The build error also occured in Oct 2024 so a backport to buildroot LTS branches should be considered: https://autobuild.buildroot.net/results/ebb/ebbd051010c27f97fafc0b203b22c8b0af7e5ccd/ Signed-off-by: Bernd Kuhls <bernd@kuhls.net> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Fixes: https://autobuild.buildroot.net/results/d93/d938025a881a14003c1b50065f163115e36cf33e/ Signed-off-by: Bernd Kuhls <bernd@kuhls.net> Reviewed-by: Horatiu Vultur <horatiu.vultur@microchip.com> Reviewed-by: Michael Cullen <michael@michaelcullen.name> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes: https://autobuild.buildroot.net/results/f75/f75d1d0b83c90c0cb5dc7781ea8ce7ff1d67512a/ Signed-off-by: Bernd Kuhls <bernd@kuhls.net> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
iconv types are defined differently in glibc (as pointers) and uclibc
(as integers). With changes in GCC14, -Wint-conversion has now become
an error, which shed some light on the issue.
The actual fix for that problem is released in uclibc 1.0.58 [1].
However, because these type definitions are in toolchain headers,
this means that the toolchain used to build samba must also include
uclibc>=1.0.58 (either an external toolchain that includes the uclibc fix,
or a Buildroot toolchain after the uclibc fix is merged in Buildroot [2]).
Until then, provide a workaround for samba itself.
No autobuilder failure on this (yet). It can be reproduced with
> ./utils/test-pkg -p samba4 -T bootlin-armv5-uclibc
[1] wbx-github/uclibc-ng@328e14e
[2] https://lore.kernel.org/buildroot/ahPrm_0gVDGw5B5-@waldemar-brodkorb.de/
Assisted-by: Claude:claude-opus-4.8
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Marcus Hoffmann <buildroot@bubu1.eu>
automated build + check-package + legal-info. Signed-off-by: Christian Stewart <christian@aperture.us>
Carry the upstream namespace__fprintf warning fix and compare BTF function prototype parameter types so host-pahole 1.28 builds with GCC 16 -Werror. Signed-off-by: Christian Stewart <christian@aperture.us>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR tracks changes vs upstream-master.