Update buidlroot to version 2016.08.1

bsp/buildroot/docs/manual/adding-packages-directory.txt

@@ -311,13 +311,17 @@ use in the comment.
 ** Dependency symbol: +BR2_TOOLCHAIN_USES_GLIBC+,
    +BR2_TOOLCHAIN_USES_MUSL+, +BR2_TOOLCHAIN_USES_UCLIBC+
 ** Comment string: for the C library, a slightly different comment text
-   is used: +foo needs an (e)glibc toolchain+, or `foo needs an (e)glibc
+   is used: +foo needs a glibc toolchain+, or `foo needs a glibc
    toolchain w/ C++`
 
 * C++ support
 ** Dependency symbol: +BR2_INSTALL_LIBSTDCPP+
 ** Comment string: `C++`
 
+* Fortran support
+** Dependency symbol: +BR2_TOOLCHAIN_HAS_FORTRAN+
+** Comment string: `fortran`
+
 * thread support
 ** Dependency symbol: +BR2_TOOLCHAIN_HAS_THREADS+
 ** Comment string: +threads+ (unless +BR2_TOOLCHAIN_HAS_THREADS_NPTL+

bsp/buildroot/docs/manual/adding-packages-generic.txt

@@ -29,7 +29,7 @@ system is based on hand-written Makefiles or shell scripts.
 14: LIBFOO_DEPENDENCIES = host-libaaa libbbb
 15:
 16: define LIBFOO_BUILD_CMDS
-17:	$(MAKE) CC="$(TARGET_CC)" LD="$(TARGET_LD)" -C $(@D) all
+17:	$(MAKE) $(TARGET_CONFIGURE_OPTS) -C $(@D) all
 18: endef
 19:
 20: define LIBFOO_INSTALL_STAGING_CMDS
@@ -310,6 +310,12 @@ information is (assuming the package name is +libfoo+) :
      the package source code. Buildroot copies the contents of the
      source directory into the package's build directory.
 
+* +LIBFOO_GIT_SUBMODULES+, when +LIBFOO_SITE_METHOD=git+, will create
+  an archive with the git submodules in the repository.
+  Note that we try not to use such git submodules when they contain
+  bundled libraries, in which case we prefer to use those libraries
+  from their own package.
+
 * +LIBFOO_STRIP_COMPONENTS+ is the number of leading components
   (directories) that tar must strip from file names on extraction.
   The tarball for most packages has one leading component named
@@ -387,7 +393,16 @@ information is (assuming the package name is +libfoo+) :
   Otherwise, describe the license in a precise and concise way, avoiding
   ambiguous names such as +BSD+ which actually name a family of licenses.
   This variable is optional. If it is not defined, +unknown+ will appear in
-  the +license+ field of the manifest file for this package.
+  the +license+ field of the manifest file for this package. +
+  The expected format for this variable must comply with the following rules:
+  ** If different parts of the package are released under different
+  licenses, then +comma+ separate licenses (e.g. +`LIBFOO_LICENSE =
+  GPLv2+, LGPLv2.1+`+). If there is clear distinction between which
+  component is licensed under what license, then annotate the license
+  with that component, between parenthesis (e.g. +`LIBFOO_LICENSE =
+  GPLv2+ (programs), LGPLv2.1+ (libraries)`+).
+  ** If the package is dual licensed, then separate licenses with the
+  +or+ keyword (e.g. +`LIBFOO_LICENSE = AFLv2.1 or GPLv2+`+).
 
 * +LIBFOO_LICENSE_FILES+ is a space-separated list of files in the package
   tarball that contain the license(s) under which the package is released.
@@ -488,6 +503,12 @@ different steps of the build process.
   systemd is selected as the init system in the configuration, only
   +LIBFOO_INSTALL_INIT_SYSTEMD+ will be run).
 
+* +LIBFOO_HELP_CMDS+ lists the actions to print the package help, which
+  is included to the main +make help+ output. These commands can print
+  anything in any format.
+  This is seldom used, as packages rarely have custom rules. *Do not use
+  this variable*, unless you really know that you need to print help.
+
 The preferred way to define these variables is:
 
 ----------------------

bsp/buildroot/docs/manual/adding-packages-hooks.txt

@@ -77,3 +77,10 @@ others, use the following variables:
 
 * +$(SRCDIR)+: the path to the overridden source directory
 * +$(@D)+: the path to the build directory
+
+==== Target-finalize hook
+
+Packages may also register hooks in +LIBFOO_TARGET_FINALIZE_HOOKS+.
+These hooks are run after all packages are built, but before the
+filesystem images are generated. They are seldom used, and your
+package probably do not need them.

bsp/buildroot/docs/manual/adding-packages-python.txt

@@ -160,3 +160,92 @@ possible to customize what is done in any particular step:
   +PYTHON_FOO_BUILD_CMDS+ variable, it will be used instead of the
   default Python one. However, using this method should be restricted
   to very specific cases. Do not use it in the general case.
+
+[[scanpypi]]
+
+==== Generating a +python-package+ from a PyPI repository
+
+If the Python package for which you would like to create a Buildroot
+package is available on PyPI, you may want to use the +scanpypi+ tool
+located in +support/scripts+ to automate the process.
+
+You can find the list of existing PyPI packages
+https://pypi.python.org[here].
+
++scanpypi+ requires Python's +setuptools+ package to be installed on
+your host.
+
+When at the root of your buildroot directory just do :
+
+-----------------------
+./support/script/scanpypi foo bar -o package
+-----------------------
+
+This will generate packages +python-foo+ and +python-bar+ in the package
+folder if they exist on https://pypi.python.org.
+
+Find the +external python modules+ menu and insert your package inside.
+Keep in mind that the items inside a menu should be in alphabetical order.
+
+Please keep in mind that you'll most likely have to manually check the
+package for any mistakes as there are things that cannot be guessed by
+the generator (e.g.  dependencies on any of the python core modules
+such as BR2_PACKAGE_PYTHON_ZLIB).  Also, please take note that the
+license and license files are guessed and must be checked. You also
+need to manually add the package to the +package/Config.in+ file.
+
+If your Buildroot package is not in the official Buildroot tree but in
+a +BR2_EXTERNAL+ tree, use the -o flag as follows:
+
+-----------------------
+./support/script/scanpypi foo bar -o other_package_dir
+-----------------------
+
+This will generate packages +python-foo+ and +python-bar+ in the
++other_package_directory+ instead of +package+.
+
+Option +-h+ will list the available options:
+
+-----------------------
+./support/script/scanpypi -h
+-----------------------
+
+[[python-package-cffi-backend]]
+
+==== +python-package+ CFFI backend
+
+C Foreign Function Interface for Python (CFFI) provides a convenient
+and reliable way to call compiled C code from Python using interface
+declarations written in C. Python packages relying on this backend can
+be identified by the appearance of a +cffi+ dependency in the
++install_requires+ field of their +setup.py+ file.
+
+Such a package should:
+
+ * add +python-cffi+ as a runtime dependency in order to install the
+compiled C library wrapper on the target. This is achieved by adding
++select BR2_PACKAGE_PYTHON_CFFI+ to the package +Config.in+.
+
+------------------------
+config BR2_PACKAGE_PYTHON_FOO
+        bool "python-foo"
+        select BR2_PACKAGE_PYTHON_CFFI # runtime
+------------------------
+
+ * add +host-python-cffi+ as a build-time dependency in order to
+cross-compile the C wrapper. This is achieved by adding
++host-python-cffi+ to the +PYTHON_FOO_DEPENDENCIES+ variable.
+
+------------------------
+################################################################################
+#
+# python-foo
+#
+################################################################################
+
+...
+
+PYTHON_FOO_DEPENDENCIES = host-python-cffi
+
+$(eval $(python-package))
+------------------------

bsp/buildroot/docs/manual/configure.txt

@@ -81,9 +81,9 @@ by itself a cross-compilation toolchain, before building the userspace
 applications and libraries for your target embedded system.
 
 This backend supports several C libraries:
-http://www.uclibc.org[uClibc], the
+http://www.uclibc.org[uClibc],
 http://www.gnu.org/software/libc/libc.html[glibc] and
-http://www.eglibc.org[eglibc].
+http://www.musl-libc.org[musl].
 
 Once you have selected this backend, a number of options appear. The
 most important ones allow to:

bsp/buildroot/docs/manual/customize-rootfs.txt

@@ -61,7 +61,7 @@ In addition, you may also use these environment variables:
     stored
   - +BASE_DIR+: the base output directory
 
-Below two more methods of customizing the target filesystem are
+Below three more methods of customizing the target filesystem are
 described, but they are not recommended.
 
 Direct modification of the target filesystem::
@@ -104,4 +104,35 @@ This method is not recommended because it duplicates the entire
   skeleton, which prevents taking advantage of the fixes or improvements
   brought to the default skeleton in later Buildroot releases.
 
+Post-fakeroot scripts (+BR2_ROOTFS_POST_FAKEROOT_SCRIPT+)::
++
+When aggregating the final images, some parts of the process requires
+  root rights: creating device nodes in `/dev`, setting permissions or
+  ownership to files and directories... To avoid requiring actual root
+  rights, Buildroot uses +fakeroot+ to simulate root rights. This is not
+  a complete substitute for actually being root, but is enough for what
+  Buildroot needs.
++
+Post-fakeroot scripts are shell scripts that are called at the 'end' of
+  the fakeroot phase, 'right before' the filesystem image generator is
+  called. As such, they are called in the fakeroot context.
++
+Post-fakeroot scripts can be useful in case you need to tweak the
+  filesystem to do modifications that are usually only available to the
+  root user.
++
+.Note:
+It is recommended to use the existing mechanisms to set file permissions
+  or create entries in `/dev` (see xref:customize-device-permission[]) or
+  to create users (see xref:customize-users[])
++
+.Note:
+The difference between post-build scripts (above) and fakeroot scripts,
+  is that post-build scripts are not called in the fakeroot context.
++
+.Note;
+Using `fakeroot` is not an absolute substitute for actually being root.
+  `fakeroot` only ever fakes the file access rights and types (regular,
+  block-or-char device...) and uid/gid; these are emulated in-memory.
+
 include::customize-device-permission-tables.txt[]

bsp/buildroot/docs/manual/known-issues.txt

@@ -14,18 +14,18 @@
   DO_XSI_MATH, UCLIBC_HAS_OBSOLETE_BSD_SIGNAL and
   UCLIBC_SV4_DEPRECATED are needed if one wants to build the
   +ltp-testsuite+ package with uClibc. You need to either use a glibc
-  or eglibc based toolchain, or enable the appropriate options in the
-  uClibc configuration.
+  based toolchain, or enable the appropriate options in the uClibc
+  configuration.
 
 * The +xfsprogs+ package does not build with the default uClibc
   configuration used by the Buildroot toolchain backend. You need to
-  either use a glibc or eglibc based toolchain, or enable the
-  appropriate options in the uClibc configuration.
+  either use a glibc based toolchain, or enable the appropriate
+  options in the uClibc configuration.
 
 * The +mrouted+ package does not build with the default uClibc
   configuration used by the Buildroot toolchain backend. You need to
-  either use a glibc or eglibc based toolchain, or enable the
-  appropriate options in the uClibc configuration.
+  either use a glibc based toolchain, or enable the appropriate
+  options in the uClibc configuration.
 
 * The +libffi+ package is not supported on the SuperH 2 and ARC
   architectures.

bsp/buildroot/docs/manual/legal-notice.txt

@@ -41,9 +41,14 @@ There you will find:
   +host-sources/+ subdirectories for target and host packages respectively.
   The source code for packages that set +<PKG>_REDISTRIBUTE = NO+ will not be
   saved.
-  Patches applied to some packages by Buildroot are distributed with the
-  Buildroot sources and are not duplicated in the +sources/+ and +host-sources/+
-  subdirectories.
+  Patches that were applied are also saved, along with a file named +series+
+  that lists the patches in the order they were applied. Patches are under the
+  same license as the files that they modify.
+  Note: Buildroot applies additional patches to Libtool scripts of
+  autotools-based packages. These patches can be found under
+  +support/libtool+ in the Buildroot source and, due to technical
+  limitations, are not saved with the package sources. You may need to
+  collect them manually.
 * A manifest file (one for host and one for target packages) listing the
   configured packages, their version, license and related information.
   Some of this information might not be defined in Buildroot; such items are

bsp/buildroot/docs/manual/makedev-syntax.txt

@@ -44,7 +44,7 @@ this syntax, you will need to write:
 ----
 /usr/bin/foo f 755 0 0 - - - - -
 /usr/bin/bar f 755 root root - - - - -
-/data/buz f buz-user buz-group - - - - -
+/data/buz f 644 buz-user buz-group - - - - -
 ----
 
 Alternatively, if you want to change owner/permission of a directory
@@ -71,3 +71,33 @@ and then for device files corresponding to the partitions of
 /dev/hda b 640 root root 3 1 1 1 15
 ----
 
+Extended attributes are supported if
++BR2_ROOTFS_DEVICE_TABLE_SUPPORTS_EXTENDED_ATTRIBUTES+ is enabled.
+This is done by adding a line starting with +|xattr+ after
+the line describing the file. Right now, only capability
+is supported as extended attribute.
+
+|=====================
+| \|xattr | capability
+|=====================
+
+- +|xattr+ is a "flag" that indicate an extended attribute
+- +capability+ is a capability to add to the previous file
+
+If you want to add the capability cap_sys_admin to the binary foo,
+you will write :
+
+----
+/usr/bin/foo f 755 root root - - - - -
+|xattr cap_sys_admin+eip
+----
+
+You can add several capabilities to a file by using several +|xattr+ lines.
+If you want to add the capability cap_sys_admin and cap_net_admin to the
+binary foo, you will write :
+
+----
+/usr/bin/foo f 755 root root - - - - -
+|xattr cap_sys_admin+eip
+|xattr cap_net_admin+eip
+----

bsp/buildroot/docs/manual/patch-policy.txt

@@ -73,12 +73,12 @@ details.
 * If a +series+ file exists in the package directory, then patches are
   applied according to the +series+ file;
 +
-* Otherwise, patch files matching +<packagename>-*.patch+
-  are applied in alphabetical order.
+* Otherwise, patch files matching +*.patch+ are applied in alphabetical
+  order.
   So, to ensure they are applied in the right order, it is highly
   recommended to name the patch files like this:
-  +<packagename>-<number>-<description>.patch+, where +<number>+
-  refers to the 'apply order'.
+  +<number>-<description>.patch+, where +<number>+ refers to the
+  'apply order'.
 
 . If +BR2_GLOBAL_PATCH_DIR+ is defined, the directories will be
   enumerated in the order they are specified. The patches are applied

bsp/buildroot/docs/manual/using-buildroot-development.txt

@@ -8,7 +8,7 @@ it, configure, compile and install the software component found inside
 this tarball. The source code is extracted in
 +output/build/<package>-<version>+, which is a temporary directory:
 whenever +make clean+ is used, this directory is entirely removed, and
-re-recreated at the next +make+ invocation. Even when a Git or
+re-created at the next +make+ invocation. Even when a Git or
 Subversion repository is used as the input for the package source
 code, Buildroot creates a tarball out of it, and then behaves as it
 normally does with tarballs.