rpi/domo
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Bump buidlroot version to 2018.02.6

Browse Source
This commit is contained in:
jbnadal
2018-10-22 14:55:59 +02:00
parent 222960cedb
commit bec94fdb63
6150 changed files with 84803 additions and 117446 deletions
Download Patch File Download Diff File Expand all files Collapse all files

49
bsp/buildroot/docs/manual/adding-packages-directory.txt
View File

@@ -28,7 +28,8 @@ contain:
config BR2_PACKAGE_LIBFOO
bool "libfoo"
help
This is a comment that explains what libfoo is.
This is a comment that explains what libfoo is. The help text
should be wrapped.
http://foosoftware.org/libfoo/
---------------------------
@@ -36,8 +37,9 @@ config BR2_PACKAGE_LIBFOO
The +bool+ line, +help+ line and other metadata information about the
configuration option must be indented with one tab. The help text
itself should be indented with one tab and two spaces, lines should
not be longer than 72 columns, and it must mention the upstream URL
of the project.
be wrapped to fit 72 columns, where tab counts for 8, so 62 characters
in the text itself. The help text must mention the upstream URL of the
project after an empty line.
As a convention specific to Buildroot, the ordering of the attributes
is as follows:
@@ -437,11 +439,13 @@ rules].
[[adding-packages-hash]]
=== The +.hash+ file
Optionally, you can add a third file, named +libfoo.hash+, that contains
the hashes of the downloaded files for the +libfoo+ package.
When possible, you must add a third file, named +libfoo.hash+, that
contains the hashes of the downloaded files for the +libfoo+
package. The only reason for not adding a +.hash+ file is when hash
checking is not possible due to how the package is downloaded.
The hashes stored in that file are used to validate the integrity of the
downloaded files.
downloaded files and of the license files.
The format of this file is one line for each file for which to check the
hash, each line being space-separated, with these three fields:
@@ -456,7 +460,10 @@ hash, each line being space-separated, with these three fields:
** for +sha256+, 64 hexadecimal characters
** for +sha384+, 96 hexadecimal characters
** for +sha512+, 128 hexadecimal characters
* the name of the file, without any directory component
* the name of the file:
** for a source archive: the basename of the file, without any directory
component,
** for a license file: the path as it appears in +FOO_LICENSE_FILES+.
Lines starting with a +#+ sign are considered comments, and ignored. Empty
lines are ignored.
@@ -473,6 +480,13 @@ provide any hash, or only provides an +md5+ hash, then compute at least one
strong hash yourself (preferably +sha256+, but not +md5+), and mention
this in a comment line above the hashes.
.Note
The hashes for license files are used to detect a license change when a
package version is bumped. The hashes are checked during the make legal-info
target run. For a package with multiple versions (like Qt5),
create the hash file in a subdirectory +<packageversion>+ of that package
(see also xref:patch-apply-order[]).
.Note
The number of spaces does not matter, so one can use spaces (or tabs) to
properly align the different fields.
@@ -499,6 +513,10 @@ sha256 ff52101fb90bbfc3fe9475e425688c660f46216d7e751c4bbdb1dc85cdccacb9 libfoo-f
# No hash for 1234:
none xxx libfoo-1234.tar.gz
# Hash for license files:
sha256 a45a845012742796534f7e91fe623262ccfb99460a2bd04015bd28d66fba95b8 COPYING
sha256 01b1f9f2c8ee648a7a596a1abe8aa4ed7899b1c9e5551bda06da6e422b04aa55 doc/COPYING.LGPL
----
If the +.hash+ file is present, and it contains one or more hashes for a
@@ -513,10 +531,17 @@ the downloaded file is left in the download directory since this
typically indicates that the +.hash+ file is wrong but the downloaded
file is probably OK.
Sources that are downloaded from a version control system (git, subversion,
etc...) can not have a hash, because the version control system and tar
may not create exactly the same file (dates, files ordering...), so the
hash could be wrong even for a valid download. Therefore, the hash check
is entirely skipped for such sources.
Hashes are currently checked for files fetched from http/ftp servers,
Git repositories, files copied using scp and local files. Hashes are
not checked for other version control systems (such as Subversion,
CVS, etc.) because Buildroot currently does not generate reproducible
tarballs when source code is fetched from such version control
systems.
Hashes should only be added in +.hash+ files for files that are
guaranteed to be stable. For example, patches auto-generated by Github
are not guaranteed to be stable, and therefore their hashes can change
over time. Such patches should not be downloaded, and instead be added
locally to the package folder.
If the +.hash+ file is missing, then no check is done at all.