Import buildroot 2016.02
This commit is contained in:
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user