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>
The last architecture-specific patch we had was removed 2015-02-14 with
commit 9863553fe8 (packages: all salute the passing of avr32), where
we eventually got rid of the avr32-specific patch for fbv.
Since then, we've only had common patches (that apply systematically),
or conditional patches, that are applied in an ad-hoc manner with
post-patch hooks. Currently, we even only have one such patch (for
Linux).
Since we do not advertise that possibility in the manual, and since we
do not want to have such patches, drop the support for it.
This has the potential for breaking existing br2-external trees, but
there is a workaround for those: they can provide a pre-patch ook that
copies the necessary per-arch patches if needed. We document this in the
manual.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
The buildroot-association repository used to be hosted on Github, then
was closed for some banking issues. We're now making it public again,
but on Gitlab like the rest of Buildroot.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Now that the snapshot tarball section is gone, the "Source code" block
has only one sub-block "Repository" which makes it look odd. So bring
the sub-block content into the parent block, and rename this parent
block "Git repository".
As this requires re-indenting the whole HTML soup, take advantage of
this to use <p>...</p> in a more correct manner.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr: fix "git pull" layout]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
In a Git era, those snapshot tarballs are no longer relevant, so drop
it.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
We're now using Gitlab as our official Git repository, so let's update
the website accordingly. Gitlab only provides https:// access, so drop
the explanation about the Git native protocol being more efficient
than HTTP (also because that's no longer true).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
by using this standard extension `adoc`,
these files are rendered on gitlab & github
Signed-off-by: Francois Perrad <francois.perrad@gadz.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Sometimes it happens that a Company or a Physical Person sponsors the
creation and/or the upstreaming process of a patch, but at the moment
there is no way to give credits to it. In Linux they prepend '+sponsor'
to the e-mail of the contributor in both authorship and commit log tag as
discussed here[0]. So let's describe in the manual how to do that as a
standard.
[0]: https://lore.kernel.org/linux-doc/20230817220957.41582-1-giulio.benetti@benettiengineering.com/
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
[yann.morin.1998@free.fr:
- reword to reference sub-addressing and the RFC
- move to the "submitting patches" section, that already deals with
SoB tags
- differentiate between Your/Their names
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Commit 7dd27cbe5b (support/download: add support to exclude svn
externals) introduced an improperly formatted list item. That was
carried over with bf2d7f8f53 (package/pkg-generic: don't download svn
externals by default).
Fix that.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
