The maintenance and testing workflow sometimes requires to output a
list of every existing package on Buildroot:
- Generating an SBOM of the whole Buildroot tree, e.g. `for
security.buildroot.org
- List every source for every package, e.g. for sources.buildroot.net
The previous solution relied on `make allyesconfig` but always ran into
conflicts that needed manual resolution. Also some packages would not be
present because they are architecture dependent.
To avoid having to manually modify the 'show-info' command this commit
adds the 'show-info-all' command. It accesses the PACKAGES_ALL variable
with all the packages present in Buildroot independently of the
architecture or any config entries.
It forces the `BR2_HAVE_DOT_CONFIG` variable to be set to force the
reading of the package mk files.
It is also added to noconfig_targets, to avoid the .config influencing
the output of show-info-all.
Note that this is not yet a complete solution - it doesn't take into
account the multiple versions that are possible for some packages like
GCC. Also for e.g. linux or uboot the version is empty and the URL is
invalid.
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
[Arnout: refactor with existing show-info]
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
(cherry picked from commit 723b321bb0)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The option is currently unused, which leads to a check-symbol warning.
Suggested-by: Arnout Vandecappelle <arnout@rnout.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
[Arnout: squash two patches]
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
(cherry picked from commit 4642f903cd)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Currently, the relocate-sdk.sh script scans the whole extracted SDK tree
to find instances of paths it needs to replace, which can take a
significant amount of time when the SDK is large, particularly relative
to the number of files that actually need to change.
However, the resulting list only depends on the SDK tarball itself, so
we can calculate it at build time and ship it with the tarball so
relocate-sdk.sh can use it directly.
Testing this on my machine with somewhat IOPS-limited rotating media,
the time goes down from:
$ time ./relocate-sdk.sh
Relocating the buildroot SDK from [...] to [...] ...
./relocate-sdk.sh 5.19s user 26.21s system 9% cpu 5:34.40 total
To:
$ time ./relocate-sdk.sh
Relocating the buildroot SDK from [...] to [...] ...
./relocate-sdk.sh 0.49s user 0.29s system 103% cpu 0.749 total
Signed-off-by: Florian Larysch <fl@n621.de>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
(cherry picked from commit 63877f9e86)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The new target provides a convenient way to run utils/check-package on
any external trees, using .checkpackageignore files from the
respective trees if present.
While .checkpackageignore should be used as little as possible, in a
few cases adding overrides for false-positives to the affected files
is not feasible, a practical example of this is a Markdown file
misidentified as Python by libmagic (likely due to code blocks).
Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
[Arnout: set ${ignore} explicitly to empty, in case it exists in the
environment.]
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
(cherry picked from commit fe48905080)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Drop the timestamp from the .tar.gz to make it reproducible, similar to how
it is done in support/download/helpers.
Notice: .xz files do not contain a timestamp
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 802d093060)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The tarball created by git archive is reproducible, but when we append the
generated manual we leak current time and the username/uid of the person
running make release:
tar tvf buildroot-2025.08-rc1.tar.gz | tail
-rwxrwxr-x root/root 5512 2025-08-11 13:22 buildroot-2025.08-rc1/utils/update-rust
drwxr-xr-x peko/peko 0 2025-08-11 17:39 buildroot-2025.08-rc1/
drwxr-xr-x peko/peko 0 2025-08-11 17:38 buildroot-2025.08-rc1/docs/
drwxr-xr-x peko/peko 0 2025-08-11 17:39 buildroot-2025.08-rc1/docs/manual/
-rw-r--r-- peko/peko 5738 2025-08-11 17:38 buildroot-2025.08-rc1/docs/manual/docbook-xsl.css
-rw-r--r-- peko/peko 19029 2025-08-11 17:38 buildroot-2025.08-rc1/docs/manual/github_hash_mongrel2.png
-rw-r--r-- peko/peko 638866 2025-08-11 17:39 buildroot-2025.08-rc1/docs/manual/manual.pdf
-rw-r--r-- peko/peko 587892 2025-08-11 17:38 buildroot-2025.08-rc1/docs/manual/manual.html
-rw-r--r-- peko/peko 393514 2025-08-11 17:39 buildroot-2025.08-rc1/docs/manual/manual.text
-rw-r--r-- peko/peko 117499 2025-08-11 17:38 buildroot-2025.08-rc1/docs/manual/logo.png
Fix that by forcing uid as root and setting mtime to the latest commit,
similar to how we do it in support/download/{git,helpers}.
Notice that we do not use --numeric-owner to match the output of git
archive, so it does rely on uid 0=root, which is very likely but not
guaranteed.
Reported-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit fa855cbe6e)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The manual contains build timestamps like:
Buildroot 2025.08-rc1 manual generated on 2025-08-12 06:43:37 UTC
Making it not reproducible. Luckily asciidoc respects SOURCE_DATE_EPOCH, so
use that to use the timestamp of the latest git commit instead.
Notice: The release and manual targets are marked as noconfig targets (and
need to stay like that for make release), so we cannot use the
BR2_REPRODUCIBLE logic. Instead manually set SOURCE_DATE_EPOCH.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 3fc5d821eb)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
When a br2-external tree has no defconfig, list-defconfig currently
whines with an error from find:
find: ‘[...]/my-external/configs’: No such file or directory
Fix that by only running find if the directory exists.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 117ccb6cc4)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
When a br2-external tree description contains an odd number of single
quotes, list-defconfigs will fail with a shell error message:
/bin/sh: -c: line 1: unexpected EOF while looking for matching `"'
make[1]: *** [Makefile:1243: list-defconfigs] Error 2
Whoever wrote that code will have to write this sentence 100 times
on the blackboard:
Never, ever pass user-provided data in a printf format.
(see commit 49117c1028 (core: support description for br2-external
trees); dang, I knew it... And I should have known better when I wrote
that code, damit...)
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 161d7ded43)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
gnu-efi fails to build if TOPDIR is exported in the environment since the
move to version 3.0.18 in commit 9efeb7e914 ("package/gnu-efi: bump to
version 3.0.18").
The reason is the change in TOPDIR logic introduced by upstream commit
31913f8489 ("Make: make TOPDIR actually work and get rid of unused CDIR"):
31913f8489
export TOPDIR=foo; make gnu-efi
...
/path/to/buildroot/output-gnuefi/host/bin/aarch64-linux-ld: cannot find
/path/to/buildroot/output-gnuefi/build/gnu-efi-4.0.0//apps/../aarch64/gnuefi/crt0-efi-aarch64.o:
No such file or director
make[2]: *** [Makefile:89: apps] Error 2
make[1]: *** [package/pkg-generic.mk:273: /path/to/buildroot/output-gnuefi/build/gnu-efi-4.0.0/.stamp_built] Error 2
make: *** [Makefile:23: _all] Error 2
As a workaround, unexport TOPDIR like we do for other sensitive environment
variables.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 2b5544ab7a)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The list of environment variables to unexport has grown organically over the
years and is no longer sorted. Sort it alphabetically for clarity.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit da04cfa26c)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Currently, list-defconfigs only lists the defconfigs that live
live in the top-level configs/ directory. For the in-tree defconfigs
this is indeed the case, but it is possible to manage the configs in a
br2-external tree with sub-directories.
A few examples:
- for a given board, a first defconfig is the full system, and a
second is the rescue system;
- for a given board, two defconfigs implement an A/B feature set;
- a set of configurations targetting various famillies of systems each
running on different hardware, sorted per familly.
Extend list-defconfigs to look for and report defconfigs in
sub-directories of the top-level configs/.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
(cherry picked from commit 5009fd2436)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Currently, the gdbinit is generated and installed during post install
hooks, either from the gdb package, or from the external-toolchain
package. When using per-package directories (PPD), the staging directory
of the either package is stored in the generated gdbinit, which is not
going to be valid when all the PPD staging dirs get merged into the
final staging: it would lack any library installed afterwards, i.e.
mostly everything would be missing (but the libraries from the C
toolchain in the case of an external toolchain).
Similarly, all the RPATH will point to various PPD drectories. This
does not cause any issue when the final host is aggregated, because the
PPD directories still exist when we call programs from there (e.g. from
the fs infra, or from post-image scripts).
However, we knew that would not always be possible to keep the PPD
directories: we have the prepare-sdk rule that runs a cleanup pass on
the RPATH, and also applies the generic PPD fixups.
When we introduced prepare-sdk in c32ad51cbf (core/sdk: generate the
SDK tarball ourselves), we did not yet have support for PPD for the host
directory, and especially, we did not have the host-finalize rule, which
was only introduced in d0f4f95e39 (Makefile: rework main directory
creation logic) which kick-started the introduction of PPD.
At that point, we did not realise that the rpath fixups from
prepare-sdk, would be better moved to the new host-finalize rule,
because that had no impact unless one would need an SDK.
Later, in 25e60fbe1c (Makefile: fix SDK relocation for
per-package-dirs), we eventually introduced the PPD generic fixups in
the prepare-sdk rule. Again, we did not realise that those fixups would
be better placed in the host-finalize rule rather than the prepare-sdk.
While fixing the RPATH in host-finalize is not critical, fixing up the
PPD paths actually is, as the gdbinit case demonstrate.
As such, move the PPD fixups to the host-finalize step, and while at it,
also move the RPATH fixups.
This now does not leave much to do in the prepare-sdk step, and that
could very well be moved to the host-finalize rule as well. However,
some people may have started to rely on prepare-sdk in its 6 years of
existence, and the little script it installs is not needed unless one
really needs an SDK. So leave it as it is for now.
Reported-by: Casey Reeves <casey@xogium.me>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Tested-by: Casey Reeves <casey@xogium.me>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Brandon Maier <Brandon.Maier@collins.com>
Tested-by: Brandon Maier <brandon.maier@collins.com>
Acked-by: TIAN Yuanhao <tianyuanhao3@163.com>
The packages 'python-jsonschema-specifications', 'pydantic-core', and
likely other packages based on Python maturin silently stopped
installing files to the host and target directories after commit
a14c862c08.
A similar issue was reported by the Conda project[1]. It seems some
build tools scan for gitignore files to decide what files to build
and install.
I attempted various combinations of gitignore patterns including
mimicking the Conda project's gitignore[2], but the only thing that has
worked reliably is the original `/output` ignore in the root Buildroot
directory.
This reverts commit a14c862c08.
[1] https://github.com/PyO3/maturin/issues/1911
[2] https://github.com/conda-forge/conda-smithy/blob/main/conda_smithy/feedstock_content/.gitignore
Reported-by: Bryan Brattlof <bb@ti.com>
Signed-off-by: Brandon Maier <brandon.maier@collins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Add missing ' to fix `make help'.
This fixes the following error:
/bin/bash: -c: line 1: unexpected EOF while looking for matching `''
make: *** [Makefile:1180: help] Error 2
Fixes: ca6c896bdd
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Steve Hay <me@stevenhay.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
This .gitignore file ignores all files in an output directory and
hence doesn't change the git status.
Remove "/output" entry from the main .gitignore file as it is already
handled by this general approach.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Brandon Maier <brandon.maier@collins.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Teach the generic package handling code how to extract zstd (.tar.zst)
archives. When zstd is not installed on the host, host-zstd gets built
automatically.
Signed-off-by: Matt Staveley-Taylor <matt.stav.taylor@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The current implementation of buildroot depe dependency graphing
either does forward- or reverse-dependency traversal.
This patch enables buildroot to graph forward and reverse dependencies
on the graph for the same package: (Diagram Credit: Yann E. MORIN)
$ make pkg-d-graph-both-depends
pkg A -. .-> pkg E
\ /
pkg B ----> pkg D ----> pkg F
/ \
pkg C -' '-> pkg G
In the above example a single graph shows pkg {A,B,C} are needed
by pkg D, and pkg D is a dependency of pkg {E,F,G}.
Makefile help and manual are also updated.
Signed-off-by: Steve Hay <me@stevenhay.com>
[Arnout:
- remove DEPTH and RDEPTH, their functionality is already covered by
BR2_GRAPH_DEPS_OPTS;
- remove --rdepth, it was felt to not add sufficient added value;
- add the new target to the manual;
- fix flake8 errors.
]
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Root makefile imposes 'umask 0022', and this may be more restrictive than the
user's original umask - which could have provisions set to share files/dirs
with other users.
As an example, the imposed value makes the per-package download directories not
writeable for the group, but just for the owner - the user that issued the first
build that populated the per-package dl dir for the first time (say user A).
Thus, if a BR package changes its version (e.g. for buildroot update), and
another user (say user B, in the same group of A) starts a build, BR fails the
creation of package-xxx.tar.gz inside the dl dir, because user B has no write
permissions on that path. Furthermore, in the case of the git backend, this
makes the git cache not updatable by a different user. This is disruptive for a
host used by many users, all belonging to a certain group.
So, to allow sharing of a rw BR2_DL_DIR location among users, we save the
original umask value and restore it during the download process.
Signed-off-by: Luca Pesce <luca.pesce@vimar.com>
[Arnout:
- CURR_UMASK -> CUR_UMASK.
- BR2_ORIG_UMASK -> BR_ORIG_UMASK.
- Don't check if the umask is more permissive, apply it regardless. If
the user explicitly doesn't want to make their DL_DIR readable by
others, that's fine.
- Don't export BR_ORIG_UMASK.
- Only set BR_ORIG_UMASK if it we recurse, and only set umask if
BR_ORIG_UMASK is set.
- Add DOWNLOAD_SET_UMASK to simplify the latter.
]
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
