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

Import buildroot 2016.02

Browse Source
This commit is contained in:
NADAL Jean-Baptiste
2016-03-01 23:22:10 +01:00
parent f70a267304
commit f4644b27c2
138 changed files with 1867 additions and 247 deletions
Download Patch File Download Diff File Expand all files Collapse all files

85
firmware/buildroot/docs/manual/contribute.txt
View File

@@ -182,10 +182,87 @@ _Please, do not attach patches to bugs, send them to the mailing list
instead_.
If you made some changes to Buildroot and you would like to contribute
them to the Buildroot project, proceed as follows. Starting from the
changes committed in your local git view, _rebase_ your development
branch on top of the upstream tree before generating a patch set. To do
so, run:
them to the Buildroot project, proceed as follows.
==== The formatting of a patch
We expect patches to be formatted in a specific way. This is necessary
to make it easy to review patches, to be able to apply them easily to
the git repository, to make it easy to find back in the history how
and why things have changed, and to make it possible to use +git
bisect+ to locate the origin of a problem.
First of all, it is essential that the patch has a good commit
message. The commit message should start with a separate line with a
brief summary of the change, starting with the name of the affected
package. The body of the commit message should describe _why_ this
change is needed, and if necessary also give details about _how_ it
was done. When writing the commit message, think of how the reviewers
will read it, but also think about how you will read it when you look
at this change again a few years down the line.
Second, the patch itself should do only one change, but do it
completely. Two unrelated or weakly related changes should usually be
done in two separate patches. This usually means that a patch affects
only a single package. If several changes are related, it is often
still possible to split them up in small patches and apply them in a
specific order. Small patches make it easier to review, and often
make it easier to understand afterwards why a change was done.
However, each patch must be complete. It is not allowed that the
build is broken when only the first but not the second patch is
applied. This is necessary to be able to use +git bisect+ afterwards.
Of course, while you're doing your development, you're probably going
back and forth between packages, and certainly not committing things
immediately in a way that is clean enough for submission. So most
developers rewrite the history of commits to produce a clean set of
commits that is appropriate for submission. To do this, you need to
use _interactive rebasing_. You can learn about it
https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History[in the Pro
Git book]. Sometimes, it is even easier to discard you history with
+git reset --soft origin/master+ and select individual changes with
+git add -i+ or +git add -p+.
Finally, the patch should be signed off. This is done by adding
+Signed-off-by: Your Real Name <your@email.address>+ at the end of the
commit message. +git commit -s+ does that for you, if configured
properly. The +Signed-off-by+ tag means that you publish the patch
under the Buildroot license (i.e. GPLv2, except for package patches,
which have the upstream license), and that you are allowed to do so.
See http://developercertificate.org/[the Developer Certificate of
Origin] for details.
When adding new packages, you should submit every package in a
separate patch. This patch should have the update to
+package/Config.in+, the package +Config.in+ file, the +.mk+ file, the
+.hash+ file, any init script, and all package patches. If the package
has many sub-options, these are sometimes better added as separate
follow-up patches. The summary line should be something like
+<packagename>: new package+. The body of the commit message can be
empty for simple packages, or it can contain the description of the
package (like the Config.in help text). If anything special has to be
done to build the package, this should also be explained explicitly in
the commit message body.
When you bump a package to a new version, you should also submit a
separate patch for each package. Don't forget to update the +.hash+
file, or add it if it doesn't exist yet. Also don't forget to check if
the +_LICENSE+ and +_LICENSE_FILES+ are still valid. The summary line
should be something like +<packagename>: bump to version <new
version>+. If the new version only contains security updates compared
to the existing one, the summary should be +<packagename>: security
bump to version <new version>+ and the commit message body should show
the CVE numbers that are fixed. If some package patches can be removed
in the new version, it should be explained explicitly why they can be
removed, preferably with the upstream commit ID. Also any other
required changes should be explained explicitly, like configure
options that no longer exist or are no longer needed.
==== Preparing a patch series
Starting from the changes committed in your local git view, _rebase_
your development branch on top of the upstream tree before generating
a patch set. To do so, run:
---------------------
$ git fetch --all --tags

20
firmware/buildroot/docs/manual/legal-notice.txt
View File

@@ -74,6 +74,9 @@ file to inform you of relevant material that could not be saved.
Here is a list of the licenses that are most widely used by packages in
Buildroot, with the name used in the manifest files:
* `AGPLv3`:
http://www.gnu.org/licenses/agpl-3.0.en.html[
GNU Affero General Public License, version 3];
* `GPLv2`:
http://www.gnu.org/licenses/old-licenses/gpl-2.0.html[
GNU General Public License, version 2];
@@ -131,11 +134,13 @@ Buildroot, with the name used in the manifest files:
http://apache.org/licenses/LICENSE-2.0.html[
Apache License, version 2.0];
[[legal-info-buildroot]]
=== Complying with the Buildroot license
Buildroot itself is an open source software, released under the
http://www.gnu.org/licenses/old-licenses/gpl-2.0.html[GNU General Public
License, version 2] or (at your option) any later version.
http://www.gnu.org/licenses/old-licenses/gpl-2.0.html[GNU General
Public License, version 2] or (at your option) any later version, with
the exception of the package patches detailed below.
However, being a build system, it is not normally part of the end product:
if you develop the root filesystem, kernel, bootloader or toolchain for a
device, the code of Buildroot is only present on the development machine, not
@@ -156,3 +161,14 @@ material that must be redistributed.
Keep in mind that this is only the Buildroot developers' opinion, and you
should consult your legal department or lawyer in case of any doubt.
==== Patches to packages
Buildroot also bundles patch files, which are applied to the sources
of the various packages. Those patches are not covered by the license
of Buildroot. Instead, they are covered by the license of the software
to which the patches are applied. When said software is available
under multiple licenses, the Buildroot patches are only provided under
the publicly accessible licenses.
See xref:patch-policy[] for the technical details.

109
firmware/buildroot/docs/manual/manual.html
View File

File diff suppressed because one or more lines are too long

BIN
firmware/buildroot/docs/manual/manual.pdf
View File

Binary file not shown.

113
firmware/buildroot/docs/manual/manual.text
View File

@@ -155,8 +155,8 @@ List of Examples
---------------------------------------------------------------------
Buildroot 2016.02-rc2 manual generated on 2016-02-18 14:38:24 UTC
from git revision 6cd8cbc
Buildroot 2016.02 manual generated on 2016-03-01 20:53:10 UTC from
git revision aaf6c28
The Buildroot manual is written by the Buildroot developers. It is
licensed under the GNU General Public License, version 2. Refer to
@@ -2746,6 +2746,8 @@ inform you of relevant material that could not be saved.
Here is a list of the licenses that are most widely used by packages
in Buildroot, with the name used in the manifest files:
* AGPLv3: GNU Affero General Public License, version 3 [http://
www.gnu.org/licenses/agpl-3.0.en.html];
* GPLv2: GNU General Public License, version 2 [http://www.gnu.org/
licenses/old-licenses/gpl-2.0.html];
* GPLv2+: GNU General Public License, version 2 [http://www.gnu.org
@@ -2789,11 +2791,12 @@ in Buildroot, with the name used in the manifest files:
Buildroot itself is an open source software, released under the GNU
General Public License, version 2 [http://www.gnu.org/licenses/
old-licenses/gpl-2.0.html] or (at your option) any later version.
However, being a build system, it is not normally part of the end
product: if you develop the root filesystem, kernel, bootloader or
toolchain for a device, the code of Buildroot is only present on the
development machine, not in the device storage.
old-licenses/gpl-2.0.html] or (at your option) any later version,
with the exception of the package patches detailed below. However,
being a build system, it is not normally part of the end product: if
you develop the root filesystem, kernel, bootloader or toolchain for
a device, the code of Buildroot is only present on the development
machine, not in the device storage.
Nevertheless, the general view of the Buildroot developers is that
you should release the Buildroot source code along with the source
@@ -2811,6 +2814,17 @@ Keep in mind that this is only the Buildroot developers' opinion, and
you should consult your legal department or lawyer in case of any
doubt.
12.3.1. Patches to packages
Buildroot also bundles patch files, which are applied to the sources
of the various packages. Those patches are not covered by the license
of Buildroot. Instead, they are covered by the license of the
software to which the patches are applied. When said software is
available under multiple licenses, the Buildroot patches are only
provided under the publicly accessible licenses.
See Chapter 18, Patching a package for the technical details.
Chapter 13. Beyond Buildroot
13.1. Boot the generated images
@@ -5688,8 +5702,8 @@ If something goes wrong in the steps 3 or 4, then the build fails.
18.3. Format and licensing of the package patches
Patches are released under the same license as the software that is
modified.
Patches are released under the same license as the software they
apply to (see Section 12.3, “Complying with the Buildroot license”).
A message explaining what the patch does, and why it is needed,
should be added in the header commentary of the patch.
@@ -5977,6 +5991,83 @@ instead.
If you made some changes to Buildroot and you would like to
contribute them to the Buildroot project, proceed as follows.
21.5.1. The formatting of a patch
We expect patches to be formatted in a specific way. This is
necessary to make it easy to review patches, to be able to apply them
easily to the git repository, to make it easy to find back in the
history how and why things have changed, and to make it possible to
use git bisect to locate the origin of a problem.
First of all, it is essential that the patch has a good commit
message. The commit message should start with a separate line with a
brief summary of the change, starting with the name of the affected
package. The body of the commit message should describe why this
change is needed, and if necessary also give details about how it was
done. When writing the commit message, think of how the reviewers
will read it, but also think about how you will read it when you look
at this change again a few years down the line.
Second, the patch itself should do only one change, but do it
completely. Two unrelated or weakly related changes should usually be
done in two separate patches. This usually means that a patch affects
only a single package. If several changes are related, it is often
still possible to split them up in small patches and apply them in a
specific order. Small patches make it easier to review, and often
make it easier to understand afterwards why a change was done.
However, each patch must be complete. It is not allowed that the
build is broken when only the first but not the second patch is
applied. This is necessary to be able to use git bisect afterwards.
Of course, while you’re doing your development, you’re probably going
back and forth between packages, and certainly not committing things
immediately in a way that is clean enough for submission. So most
developers rewrite the history of commits to produce a clean set of
commits that is appropriate for submission. To do this, you need to
use interactive rebasing. You can learn about it in the Pro Git book
[https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History].
Sometimes, it is even easier to discard you history with git reset
--soft origin/master and select individual changes with git add -i or
git add -p.
Finally, the patch should be signed off. This is done by adding
Signed-off-by: Your Real Name <> at the end of the commit message.
git commit -s does that for you, if configured properly. The
Signed-off-by tag means that you publish the patch under the
Buildroot license (i.e. GPLv2, except for package patches, which have
the upstream license), and that you are allowed to do so. See the
Developer Certificate of Origin [http://developercertificate.org/]
for details.
When adding new packages, you should submit every package in a
separate patch. This patch should have the update to package/
Config.in, the package Config.in file, the .mk file, the .hash file,
any init script, and all package patches. If the package has many
sub-options, these are sometimes better added as separate follow-up
patches. The summary line should be something like <packagename>: new
package. The body of the commit message can be empty for simple
packages, or it can contain the description of the package (like the
Config.in help text). If anything special has to be done to build the
package, this should also be explained explicitly in the commit
message body.
When you bump a package to a new version, you should also submit a
separate patch for each package. Don’t forget to update the .hash
file, or add it if it doesn’t exist yet. Also don’t forget to check
if the _LICENSE and _LICENSE_FILES are still valid. The summary line
should be something like <packagename>: bump to version <new
version>. If the new version only contains security updates compared
to the existing one, the summary should be <packagename>: security
bump to version <new version> and the commit message body should show
the CVE numbers that are fixed. If some package patches can be
removed in the new version, it should be explained explicitly why
they can be removed, preferably with the upstream commit ID. Also any
other required changes should be explained explicitly, like configure
options that no longer exist or are no longer needed.
21.5.2. Preparing a patch series
Starting from the changes committed in your local git view, rebase
your development branch on top of the upstream tree before generating
a patch set. To do so, run:
@@ -6008,7 +6099,7 @@ line-wrapped, otherwise they cannot easily be applied. In such a
case, fix your e-mail client, or better yet, learn to use git
send-email.
21.5.1. Cover letter
21.5.3. Cover letter
If you want to present the whole patch set in a separate mail, add
--cover-letter to the git format-patch command (see man
@@ -6024,7 +6115,7 @@ the following cases:
* whenever you feel it will help presenting your work, your
choices, the review process, etc.
21.5.2. Patch revision changelog
21.5.4. Patch revision changelog
When improvements are requested, the new revision of each commit
should include a changelog of the modifications between each

4
firmware/buildroot/docs/manual/patch-policy.txt
View File

@@ -90,8 +90,8 @@ If something goes wrong in the steps _3_ or _4_, then the build fails.
=== Format and licensing of the package patches
Patches are released under the same license as the software that is
modified.
Patches are released under the same license as the software they apply
to (see xref:legal-info-buildroot[]).
A message explaining what the patch does, and why it is needed, should
be added in the header commentary of the patch.

40
firmware/buildroot/docs/website/download.html
View File

@@ -8,74 +8,74 @@
<div class="panel-heading">Download</div>
<div class="panel-body">
<h3 style="text-align: center;">Latest stable release: <b>2015.11.1</b></h3>
<h3 style="text-align: center;">Latest stable release: <b>2016.02</b></h3>
<div class="row mt centered">
<div class="col-sm-6">
<div class="flip-container center-block" ontouchstart="this.classList.toggle('hover');">
<div class="flipper">
<div class="front">
<a href="/downloads/buildroot-2015.11.1.tar.gz"><img src="images/zip.png" width="180" alt=""></a>
<a href="/downloads/buildroot-2016.02.tar.gz"><img src="images/zip.png" width="180" alt=""></a>
</div>
<div class="back">
<a href="/downloads/buildroot-2015.11.1.tar.gz"><img src="images/zip.png" width="180" alt=""></a>
<a href="/downloads/buildroot-2016.02.tar.gz"><img src="images/zip.png" width="180" alt=""></a>
</div>
</div>
</div>
<h3><a href="/downloads/buildroot-2015.11.1.tar.gz">buildroot-2015.11.1.tar.gz</a></h3>
<p><a href="/downloads/buildroot-2015.11.1.tar.gz.sign">PGP signature</a></p>
<h3><a href="/downloads/buildroot-2016.02.tar.gz">buildroot-2016.02.tar.gz</a></h3>
<p><a href="/downloads/buildroot-2016.02.tar.gz.sign">PGP signature</a></p>
</div>
<div class="col-sm-6">
<div class="flip-container center-block" ontouchstart="this.classList.toggle('hover');">
<div class="flipper">
<div class="front">
<a href="/downloads/buildroot-2015.11.1.tar.bz2"><img src="images/package.png" width="180" alt=""></a>
<a href="/downloads/buildroot-2016.02.tar.bz2"><img src="images/package.png" width="180" alt=""></a>
</div>
<div class="back">
<a href="/downloads/buildroot-2015.11.1.tar.bz2"><img src="images/package.png" width="180" alt=""></a>
<a href="/downloads/buildroot-2016.02.tar.bz2"><img src="images/package.png" width="180" alt=""></a>
</div>
</div>
</div>
<h3><a href="/downloads/buildroot-2015.11.1.tar.bz2">buildroot-2015.11.1.tar.bz2</a></h3>
<p><a href="/downloads/buildroot-2015.11.1.tar.bz2.sign">PGP signature</a></p>
<h3><a href="/downloads/buildroot-2016.02.tar.bz2">buildroot-2016.02.tar.bz2</a></h3>
<p><a href="/downloads/buildroot-2016.02.tar.bz2.sign">PGP signature</a></p>
</div>
</div>
<h3 style="text-align: center;">Latest release candidate: <b>2016.02-rc2</b></h3>
<!--
<h3 style="text-align: center;">Latest release candidate: <b>2016.02-rc3</b></h3>
<div class="row mt centered">
<div class="col-sm-6">
<div class="flip-container center-block" ontouchstart="this.classList.toggle('hover');">
<div class="flipper">
<div class="front">
<a href="/downloads/buildroot-2016.02-rc2.tar.gz"><img src="images/zip.png" width="180" alt=""></a>
<a href="/downloads/buildroot-2016.02-rc3.tar.gz"><img src="images/zip.png" width="180" alt=""></a>
</div>
<div class="back">
<a href="/downloads/buildroot-2016.02-rc2.tar.gz"><img src="images/zip.png" width="180" alt=""></a>
<a href="/downloads/buildroot-2016.02-rc3.tar.gz"><img src="images/zip.png" width="180" alt=""></a>
</div>
</div>
</div>
<h3><a href="/downloads/buildroot-2016.02-rc2.tar.gz">buildroot-2016.02-rc2.tar.gz</a></h3>
<p><a href="/downloads/buildroot-2016.02-rc2.tar.gz.sign">PGP signature</a></p>
<h3><a href="/downloads/buildroot-2016.02-rc3.tar.gz">buildroot-2016.02-rc3.tar.gz</a></h3>
<p><a href="/downloads/buildroot-2016.02-rc3.tar.gz.sign">PGP signature</a></p>
</div>
<div class="col-sm-6">
<div class="flip-container center-block" ontouchstart="this.classList.toggle('hover');">
<div class="flipper">
<div class="front">
<a href="/downloads/buildroot-2016.02-rc2.tar.bz2"><img src="images/package.png" width="180" alt=""></a>
<a href="/downloads/buildroot-2016.02-rc3.tar.bz2"><img src="images/package.png" width="180" alt=""></a>
</div>
<div class="back">
<a href="/downloads/buildroot-2016.02-rc2.tar.bz2"><img src="images/package.png" width="180" alt=""></a>
<a href="/downloads/buildroot-2016.02-rc3.tar.bz2"><img src="images/package.png" width="180" alt=""></a>
</div>
</div>
</div>
<h3><a href="/downloads/buildroot-2016.02-rc2.tar.bz2">buildroot-2016.02-rc2.tar.bz2</a></h3>
<p><a href="/downloads/buildroot-2016.02-rc2.tar.bz2.sign">PGP signature</a></p>
<h3><a href="/downloads/buildroot-2016.02-rc3.tar.bz2">buildroot-2016.02-rc3.tar.bz2</a></h3>
<p><a href="/downloads/buildroot-2016.02-rc3.tar.bz2.sign">PGP signature</a></p>
</div>
</div>
-->
This and earlier releases (and their PGP signatures) can always be downloaded from
<a href="/downloads/">http://buildroot.net/downloads/</a>.
</div>

40
firmware/buildroot/docs/website/news.html
View File

@@ -9,6 +9,46 @@
<h2>News</h2>
<ul class="timeline">
<li class="timeline-inverted">
<div class="timeline-badge"><i class="glyphicon glyphicon-thumbs-up"></i></div>
<div class="timeline-panel">
<div class="timeline-heading">
<h4 class="timeline-title">2016.02 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>1 March 2016</small></p>
</div>
<div class="timeline-body">
<p>The stable 2016.02 release is out - Thanks to everyone
contributing and testing the release candidates. See the
<a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2016.02">CHANGES</a>
file for more details
and go to the <a href="/downloads/">downloads page</a> to pick up the
<a href="/downloads/buildroot-2016.02.tar.bz2">2016.02 release</a>.</p>
</div>
</div>
</li>
<li>
<div class="timeline-badge"><i class="glyphicon glyphicon-thumbs-up"></i></div>
<div class="timeline-panel">
<div class="timeline-heading">
<h4 class="timeline-title">2016.02-rc3 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>27 February 2016</small></p>
</div>
<div class="timeline-body">
<p>Release candidate 3 is out with more cleanups and security
/ build fixes. See
the <a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2016.02-rc3">CHANGES</a>
file for details.</p>
<p>Head to the <a href="/downloads/">downloads page</a> to
pick up
the <a href="/downloads/buildroot-2016.02-rc3.tar.bz2">2016.02-rc3
release candidate</a>, and report any problems found to
the <a href="support.html">mailing list</a>
or <a href="https://bugs.uclibc.org">bug tracker</a>.</p>
</div>
</div>
</li>
<li class="timeline-inverted">
<div class="timeline-badge"><i class="glyphicon glyphicon-thumbs-up"></i></div>
<div class="timeline-panel">