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>
https://git-send-email.io/ is a page maintained by sourcehut which
explains how to setup git send-email on many OS's for many popular email
providers.
Signed-off-by: Marcus Hoffmann <buildroot@bubu1.eu>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The #buildroot IRC channel recently changed from only allowing
registered users to join to allowing anyone to join but only allowing
registered users to talk in the channel. This still avoids the spam
problem on IRC while allowing an exception for users bridged from
matrix.org. These already have a username registered on the matrix side
and thus similar properties as a registered IRC user/nick.
The commands to set these options were:
* Set +q on all unregistered nicks: ~/mode #buildroot +q $~a~ this lets
people join but they can't talk
* Set exempt on matrix hosts: ~/mode #buildroot +e $x:matrix.org~
Signed-off-by: Marcus Hoffmann <buildroot@bubu1.eu>
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>
When the favicon image was added in f26e61319f (docs/website: add
favicon.png), it was added to a different directory then where the header's
icon link points. This causes the favicon to fail to load with 404.
While we are here, remove the "shortcut" rel attribute as it is non-standard
and it's recommended not to use it[1].
[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel#sect4
Signed-off-by: Brandon Maier <brandon.maier@collins.com>
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>
After talking with Thomas Petazzoni, it is agreed that Amarulasolutions should
be added to the list of companies that can provide commercial support for
Buildroot.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
