Commit Graph

6 Commits

Author SHA1 Message Date
Yann E. MORIN
1c24d83cc8 doc/manual: fixup ordered lists
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>
2024-02-11 16:28:35 +01:00
Thomas Petazzoni
89e67a9638 docs/manual: update documentation about support python <pkg>_SETUP_TYPE
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>
2024-02-06 23:21:23 +01:00
Adam Duskett
09de823cbc package/pkg-python.mk: remove distutils support
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>
2024-02-06 23:21:21 +01:00
Yann E. MORIN
5d36710e36 package/pkg-download: lookup hash files in global-patch-dir
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>
2023-11-07 11:48:46 +01:00
Yann E. MORIN
6898781f03 docs/manual: svn downloads can be hash-checked
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>
2023-11-05 22:48:22 +01:00
Francois Perrad
32cec3be97 docs/manual: rename *.txt as *.adoc
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>
2023-09-30 10:25:22 +02:00