Skip to content

Tracking: skiff vs upstream-master#19

Draft
paralin wants to merge 2946 commits into
upstream-masterfrom
skiff
Draft

Tracking: skiff vs upstream-master#19
paralin wants to merge 2946 commits into
upstream-masterfrom
skiff

Conversation

@paralin
Copy link
Copy Markdown
Member

@paralin paralin commented Jun 16, 2022

This PR tracks changes vs upstream-master.

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>
@paralin paralin marked this pull request as draft June 16, 2022 02:36
@paralin paralin changed the base branch from upstream-master to bump-docker-proxy June 16, 2022 02:37
@paralin paralin changed the base branch from bump-docker-proxy to upstream-master June 16, 2022 02:38
@paralin paralin force-pushed the skiff branch 3 times, most recently from 0915eeb to 7af4c59 Compare June 23, 2022 03:07
@paralin paralin force-pushed the skiff branch 4 times, most recently from c5e35c6 to ba56dae Compare June 27, 2022 21:03
@paralin paralin force-pushed the skiff branch 3 times, most recently from 0d083d6 to 99d3e37 Compare July 11, 2022 14:01
paralin added 2 commits July 11, 2022 08:11
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>
@paralin paralin force-pushed the skiff branch 10 times, most recently from 75f485c to f8af779 Compare July 19, 2022 11:26
bkuhls and others added 30 commits May 30, 2026 18:08
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.