As we have many python packages using the poetry(poetry-core) build
system we should add a setup type for it so that we don't have to
manually specify the host-python-poetry-core dependency.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Call out the requirements to run check-package and mention that Docker
can be used to run check-package without installing dependencies.
Signed-off-by: Brandon Maier <brandon.maier@collins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
As we have many python packages using the hatch(hatchling) build
system we should add a setup type for it so that we don't have to
manually specify the host-python-hatchling dependency.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Doctoring a defconfig is tedious, and it is not easy to update a
defconfig, as it requires manual copy-pasting, adding comments and so
on...
Instead, just require defconfigs to be generated with 'savedefconfig'.
Any details can/must be provided in the commit log.
Reported-by: Edgar Bonet <bonet@grenoble.cnrs.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Commit 89d39fc7a3 "initscripts: new package" moved the inittab
packaged for Busybox init from system/skeleton/etc to package/busybox.
The manual, however, still points to the old location, so let's fix it.
Signed-off-by: Edgar Bonet <bonet@grenoble.cnrs.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The behaviour of asciidoc on my laptop (Debian 10.2.0-1) changed at the end
of last year, causing the BR2_VERSION logic to no longer work:
grep 'manual generated' buildroot-2023.02.*/docs/manual/manual.text
buildroot-2023.02.6/docs/manual/manual.text:Buildroot 2023.02.6 manual generated on 2023-10-16 08:41:26 UTC from
buildroot-2023.02.7/docs/manual/manual.text:Buildroot ${BR2_VERSION%%-git*} manual generated on 2023-11-14
buildroot-2023.02.8/docs/manual/manual.text:Buildroot ${BR2_VERSION%%-git*} manual generated on 2023-12-04
We don't really NEED to strip the -git suffix; indeed, for a git tag, there
would be not -git suffix, while for any other commit there will be one
and we want to see it (e.g. in the nightly manual, or on a development
branch locally).
So just drop that to unbreak the version output.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
[yann.morin.1998@free.fr: explain why wew don't want to drop it]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
As FOO_RESOURCES hints, the correct spelling is resources so use that.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Even when configured for cross-compilation, the go compiler is always
able to build natively as well, and this is was we use in Buildroot to
build host go packages. This implies that when the target has
limitations, those limitations thus also apply to the host builds.
This means that, when there is no CGO linking support for the target,
the compiler is built without CGO linking support, and thus CGO linking
is also not available for the host builds.
Of course, when there is no go support for the target, the CGO linking
support only depends on the host architecture.
Add a new Kconfig symbol that repesent whether CGO linking is available
for the host; host packages can then depend on that symbol, like the
target variants do on the corresponding target symbol.
The dependencies of this symbol are a bit complicated. Fortunately,
because it is a blind symbol, we can write it with a combination of
"default y" and "depends on" statements. As mentioned, CGO for the host
is available if CGO is available for the target, but also if Go is not
available for the target at all. In addition, Go must of course be
available for the host. There are also the toolchain constraints of CGO.
We exclude MIPS64 explicitly based on BR2_HOSTARCH. For the host, we
always assume that dynamic library and threads are available so we don't
have conditions for that.
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Thomas Perale <thomas.perale@mind.be>
Cc: Christian Stewart <christian@aperture.us>
Cc: Anisse Astier <anisse@astier.eu>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Patch v1 not set to 'superseded' when replying to <message-id> with v2.
I'm using git version 2.46.0. The manual says the following is the
correct way to use the '--in-reply-to' option:
git send-email --in-reply-to=<message-id>
Signed-off-by: Roy Kollen Svendsen <roykollensvendsen@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
When the default (newest) kernel headers series changes the build can
break. Example error message:
Incorrect selection of kernel headers: expected 6.8.x, got 6.5.x
In the above case the defconfig used:
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="6.5.9"
The kernel headers were not specified, so the build defaulted to using
the kernel sources as header source and the default (newest) header
series. From .config:
BR2_KERNEL_HEADERS_AS_KERNEL=y
BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_6_8=y
Signed-off-by: Gero Schwäricke <gero.schwaericke@posteo.de>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
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>
The manual describes package/busybox/S01syslogd as the reference of
how an init script should be written. Include it from source instead
of having a copy in the manual to ensure actual code and manual stay
in sync.
Also use long options in the paragraph after the script to follow the
same style.
Signed-off-by: Fiona Klute (WIWA) <fiona.klute@gmx.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
People can assume that e.g. Busybox options enabled in the package are
enabled when writing code for Buildroot. Anyone who uses custom
configurations that disable default options needs to make sure
relevant scripts etc. still work for themselves.
Signed-off-by: Fiona Klute (WIWA) <fiona.klute@gmx.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The current phrasing is not entirely clear: one could read it as if
Buildroot will detect if there's an update available in one of the
dependencies, which is quite the reverse of what we do. Rephrase the
sentence in a way that hopefully makes it clearer that we're just making
a hash of the dependencies.
While we're at it, also extend the sentence about offline builds a
little.
Suggested-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Post-build, post-image, and other build scripts may run some commands in
parallel, for example to parallelize xargs, Makefiles, etc. Export
PARALLEL_JOBS to these scripts so they can enforce the same job limits
that other Buildroot packages use.
Signed-off-by: Brandon Maier <brandon.maier@collins.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Although the asciidoc toolchain accepts any number of ~ to delimit a
listing block (i.e. a code block), it is actually specified to be
exactly four, i.e. ~~~~. Currently, a mix of diffrent numbers of ~ are
being used - sometimes even a different number at the beginning and at
the end of the block.
Normalize this to always use exactly four ~ for the delimiter.
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Currently the text for each package infra that mentions the usage of
variables already provided by the generic infra diverge from each other:
- some (golang, kconfig, python) add a cross-referece to the generic
infra chapter;
- kconfig does not list any example;
- some mention _LICENSE as an example, others don't;
- some (cargo, golang, python) add an 'etc.' at the end of the examples,
giving the idea that can be more symbols provided by the generic
infra than the ones listed;
- most have the text 'works by defining a number of variables before
calling the +<macro-name>+ macro', except golang and kconfig;
- some actually list 'A few additional variables' but keep using some
old reference as 'An additional variable';
- some say 'First, all the package metadata' and other only 'All the
package metadata';
- most mention _SUBDIR as an example of variable supported by the
generic infra, even the generic infra manual not mentioning it.
Improve the correctness for the manual by standardizing the text among
the package infras:
- use the same text "All the package metadata information variables that
exist in the generic package infrastructure also exist in the
<name> infrastructure:" for all of them;
- add the cross-reference for all of them;
- remove the examples of variables inherited from the generic infra -
this also solves the _SUBDIR problem, there no longer is any reference
to _SUBDIR;
- wrap the modified text at 80 columns;
- add "macro" to golang and luarocks infra;
- use "A few additional variables" for qmake and waf.
At same time, add a missing format on golang manual for
BR2_PACKAGE_HOST_GO_HOST_ARCH_SUPPORTS.
Cc: Eric Le Bihan <eric.le.bihan.dev@free.fr>
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
[Arnout:
- remove the examples;
- add "the" where "macro" was added;
- rewrite the preceding paragraphs for kconfig to make it more
consistent.
]
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Recent versions of wget, starting with wget 2.0, aka wget2 thereafter,
no longer support FTP (nor FTPS, aka FTP-over-SSL). wget2 is packaged in
Fedora 40, recently released; F40 does not even have the old wget
available in its repository anymore.
Introduce cURL as a download backend, that we use for FTP and FPTS
protocols.
Note that the -q flag does not means being quiet; it means that a curlrc
file should not be parsed. The long option is --disable, which meaning
is not much more obivous than the short -q. It also has to be the first
option on the command line.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Unfortunately not all mail providers deliver mails with subaddressing,
mention people can acknowledge a sponsor in the author name instead.
Signed-off-by: Fiona Klute (WIWA) <fiona.klute@gmx.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Our Bugzilla is so slow and unstable that it has become
unusable. Let's switch to using the Gitlab issue tracker instead.
There are still lots of references to the Bugzilla bug tracker in our
News page at https://buildroot.org/news.html, but these are for older
news.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr: don't needlessly re-flow]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Since tar *will* generate different archives, virtually all hashes will
change, so drop the blurb that states they usually would not.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
[Arnout: say explicitly that the has will change]
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Add the changes about export-subst in the git backend, to the migrating
section of the manual.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
[Arnout: slightly extend the message, add sed command to update hash
files]
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Currently, one may only specify one list of arguments that are passed to
several scripts (BR2_ROOTFS_PRE_BUILD_SCRIPT, BR2_ROOTFS_POST_BUILD_SCRIPT,
BR2_ROOTFS_POST_FAKEROOT_SCRIPT and BR2_ROOTFS_POST_IMAGE_SCRIPT_ARGS).
So one has to be careful that the arguments for these scripts do noti
collide.
To allow specifiying dedicated arguments to each type of scripts, new
config options are introduced. For backward compatibility the value of
BR2_ROOTFS_POST_SCRIPT_ARGS is still passed to the scripts. But now one
can add specific arguments from the new config option.
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
[yann.morin.1998@free.fr:
- mention common args in help texts
- slight coding style beautification
- slight rewording in commit log
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Now that we can specify that the default values for the CPE_ID variables
are valid, without having to actually set one (or more) to their
default, add a check-package check that validates that the CPE_ID
variables are indeed not set to their default.
It also validates that CPE_ID_VALID is not set when another CPE_ID
variable is set to a non-default value.
Add an anchor in the manual so that we can easily point to it.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Cc: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The way we handle CPE_ID variable is unusual compared to the other
variables: we mostly compute defaults for all of them, and eventually
aggregate the various CPE_ID variables to form the CPE ID name.
However, we do not consider that CPE ID to valid, unless there is one
(or more) CPE_ID variables actually set by the package; this shows that
the CPE ID has been checked to be valid against the NVD CPE database. In
that situation, we internally define the duly undocumented _CPE_ID_VALID
variable.
However, it is totally possible (and very often the case) that the
default value we set to those variables are appropriate, and do defne a
valid CPE ID. In this case, the package will define any arbitrary CPE_ID
variable to its default value, usually by setting either the VENDOR or
PRODUCT field, though there is no rule or requirement that be the case.
This is not very clean, non-obvious, and does not allow for easily
adding checks in check-package.
Add the _CPE_ID_VALID variable to the manual, to make it official that
it should be used when the default values of the others are valid.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
With recent asiidoc versions (at least 10.2.0 is known to report that),
rendering the manual yields a few warnings related to ordered lists:
asciidoc: WARNING: customize-quick-guide.adoc: line 13: list item index: expected 2 got 1
asciidoc: WARNING: customize-quick-guide.adoc: line 15: list item index: expected 3 got 1
[...]
asciidoc: WARNING: customize-quick-guide.adoc: line 65: list item index: expected 13 got 1
asciidoc: WARNING: customize-quick-guide.adoc: line 66: list item index: expected 14 got 1
asciidoc: WARNING: adding-packages-gettext.adoc: line 30: list item index: expected 2 got 1
asciidoc: WARNING: adding-packages-gettext.adoc: line 41: list item index: expected 3 got 1
The reason is that we use the same index to tell asciidoc to
automatically number items.
However, the official way to provide an automatic index is to write no
index:
https://docs.asciidoctor.org/asciidoc/latest/lists/ordered/
[...] since the numbering is obvious, the AsciiDoc processor will
insert the numbers for you if you omit them:
[...]
If you number the ordered list explicitly, you have to manually keep
the list numerals sequential. Otherwise, you will get a warning.
So, abide by the documentation, and drop the repeating indices to
ordered lists where we want automatic numbering.
Note that there is another ordered list, in adding-packages-directory.adoc,
but it does use explicit, sequential numbering. For consistency within
the whole document, we also convert it.
To avoid extra useless churn, the indentation of the items is not
changed to match the elided indices.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Note that we do not document the special flit-bootstrap value, as it
is considered an internal implementation detail, and shouldn't
normally be used by packages.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
All Python packages have been migrated to a different setup type, and
we're about to bump to Python 3.12 which no longer supports distutils,
so let's drop support for distutils in our python-package
infrastructure.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
[Thomas: also update the Buildroot manual]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Marcus Hoffmann <buildroot@bubu1.eu>
[yann.morin.1998@free.fr: make it explicit it is not the official way]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The section of the manual describing the makedev syntax is not
up-to-date with the current features, and does not properly describe
existing ones.
- extend the list of types with the requirements on the existence of
the target file or directory; for 'c', 'b', and 'p', the existence
requirement is inherited from mknod(2):
ERRORS
...
ENOENT A directory component in pathname does not exist or is a
dangling symbolic link.
for the other types, the existence requirements are extracted from
the source of makedev.c;
- format the types flags, so they are rendered in monospace;
- extend the 'mode' description, as it can be set to -1 for 'f', 'd',
or 'r', so that only the uid and gid are set. This is most useful
for 'r', where setting the same mode recursively for all the
sub-directories and files alike does not really make sense; indeed
in this case, the modes are usually set correctly when the package
(or rootfs overlay) installs the files, and only the uid and gid are
interesting to set;
- extend and update the examples to show-case the -1 mode use-case.
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
rsync is used in the infrastructure, mostly for the per-package infra,
and for the override-srcdir mechanism, but also to build the manual.
As such, it is not optional but mandatory, and already listed so.
Drop the reference to rsync from the list of optional packages.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
These variables were removed. In addition, the text describing them
wasn't terribly useful. Just remove the sentences describing them.
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Add a script to manage the .hash files in the BR2_GLOBAL_PATCH_DIR for
packages using custom versions.
To use it, run in a configured Buildroot directory, E.G.
make foo_defconfig; ./utils/add-custom-hashes
We support multiple patch directories in BR2_GLOBAL_PATCH_DIR. If multiple
directories are specified then use the last one as that is likely to be the
most specific one.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
[Peter: silence command -v invocation]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently, we expect and only use hash files that lie within the package
directory, alongside the .mk file. Those hash files are thus bundled
with Buildroot.
This implies that only what's known to Buildroot can ever get into those
hash files. For packages where the version is fixed (or a static
choice), then we can carry hashes for those known versions.
However, we do have a few packages for which the version is a free-form
entry, where the user can provide a custom location and/or version. like
a custom VCS tree and revision, or a custom tarball URL. This means that
Buildroot has no way to be able to cary hashes for such custom versions.
This means that there is no integrity check that what was downloaded is
what was expected. For a sha1 in a git tree, this is a minor issue,
because the sha1 by itself is already a hash of the expected content.
But for custom tarballs URLs, or for a tag in a VCS, there is indeed no
integrity check.
Buildroot can't provide such hashes, but interested users may want to
provide those, and currently there is no (easy) way to do so.
We leverage the existing global-patch-dir mechanism to look for extra
hash files. We use the same heuristic that is used for bundled hash
files, and for each global patch directory <dir>, we use the first file
to exist among:
1. look into <dir>/<package>/<version>/<package>.hash
2. look into <dir>/<package>/<package>.hash
Reported-by: "Martin Zeiser (mzeiser)" <mzeiser@cisco.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since commit 89f5e98932 (support/download/svn: generate reproducible
svn archives), we've been able to generate reproducible archives, and
thus we have been able to verify the hashes for those archives.
However, the manual was not changed, and still falsely hinted that this
was not the cae.
Fix that.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
