Bump buidlroot version to 2018.02.6

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

View File

@@ -0,0 +1,110 @@
// -*- mode:doc; -*-
// vim: set syntax=asciidoc:
=== Integration of Cargo-based packages
Cargo is the package manager for the Rust programming language. It allows the
user to build programs or libraries written in Rust, but it also downloads and
manages their dependencies, to ensure repeatable builds. Cargo packages are
called "crates".
[[cargo-package-tutorial]]
==== Cargo-based package's +Config.in+ file
The +Config.in+ file of Cargo-based package 'foo' should contain:
---------------------------
01: config BR2_PACKAGE_FOO
02: bool "foo"
03: depends on BR2_PACKAGE_HOST_RUSTC_ARCH_SUPPORTS
04: select BR2_PACKAGE_HOST_CARGO
05: help
06: This is a comment that explains what foo is.
07:
08: http://foosoftware.org/foo/
---------------------------
==== Cargo-based package's +.mk+ file
Buildroot does not (yet) provide a dedicated package infrastructure for
Cargo-based packages. So, we will explain how to write a +.mk+ file for such a
package. Let's start with an example:
------------------------------
01: ################################################################################
02: #
03: # foo
04: #
05: ################################################################################
06:
07: FOO_VERSION = 1.0
08: FOO_SOURCE = foo-$(FOO_VERSION).tar.gz
09: FOO_SITE = http://www.foosoftware.org/download
10: FOO_LICENSE = GPL-3.0+
11: FOO_LICENSE_FILES = COPYING
12:
13: FOO_DEPENDENCIES = host-cargo
14:
15: FOO_CARGO_ENV = CARGO_HOME=$(HOST_DIR)/share/cargo
16: FOO_CARGO_MODE = $(if $(BR2_ENABLE_DEBUG),debug,release)
17:
18: FOO_BIN_DIR = target/$(RUSTC_TARGET_NAME)/$(FOO_CARGO_MODE)
19:
20: FOO_CARGO_OPTS = \
21: --$(FOO_CARGO_MODE) \
22: --target=$(RUSTC_TARGET_NAME) \
23: --manifest-path=$(@D)/Cargo.toml
24:
25: define FOO_BUILD_CMDS
26: $(TARGET_MAKE_ENV) $(FOO_CARGO_ENV) \
27: cargo build $(FOO_CARGO_OPTS)
28: endef
29:
30: define FOO_INSTALL_TARGET_CMDS
31: $(INSTALL) -D -m 0755 $(@D)/$(FOO_BIN_DIR)/foo \
32: $(TARGET_DIR)/usr/bin/foo
33: endef
34:
35: $(eval $(generic-package))
--------------------------------
The Makefile starts with the definition of the standard variables for package
declaration (lines 7 to 11).
As seen in line 35, it is based on the
xref:generic-package-tutorial[+generic-package+ infrastructure]. So, it defines
the variables required by this particular infrastructure, where Cargo is
invoked:
* +FOO_BUILD_CMDS+: Cargo is invoked to perform the build. The options required
to configure the cross-compilation of the package are passed via
+FOO_CONF_OPTS+.
* +FOO_INSTALL_TARGET_CMDS+: The binary executable generated is installed on
the target.
In order to have Cargo available for the build, +FOO_DEPENDENCIES+ needs to
contain +host-cargo+.
To sum it up, to add a new Cargo-based package, the Makefile example can be
copied verbatim then edited to replace all occurences of +FOO+ with the
uppercase name of the new package and update the values of the standard
variables.
==== About Dependencies Management
A crate can depend on other libraries from crates.io or git repositories, listed
in its Cargo.toml file. Before starting a build, Cargo usually downloads
automatically them. This step can also be performed independently, via the
+cargo fetch+ command.
Cargo maintains a local cache of the registry index and of git checkouts of the
crates, whose location is given by +$CARGO_HOME+. As seen in the package
Makefile example at line 15, this environment variable is set to
+$(HOST_DIR)/share/cargo+.
This dependency download mechanism is not convenient when performing an offline
build, as Cargo will fail to fetch the dependencies. In that case, it is advised
to generate a tarball of the dependencies using the +cargo vendor+ and add it to
+FOO_EXTRA_DOWNLOADS+.

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.

View File

@@ -22,7 +22,7 @@ system is based on hand-written Makefiles or shell scripts.
07: LIBFOO_VERSION = 1.0
08: LIBFOO_SOURCE = libfoo-$(LIBFOO_VERSION).tar.gz
09: LIBFOO_SITE = http://www.foosoftware.org/download
10: LIBFOO_LICENSE = GPLv3+
10: LIBFOO_LICENSE = GPL-3.0+
11: LIBFOO_LICENSE_FILES = COPYING
12: LIBFOO_INSTALL_STAGING = YES
13: LIBFOO_CONFIG_SCRIPTS = libfoo-config
@@ -197,12 +197,25 @@ information is (assuming the package name is +libfoo+) :
* +LIBFOO_VERSION+, mandatory, must contain the version of the
package. Note that if +HOST_LIBFOO_VERSION+ doesn't exist, it is
assumed to be the same as +LIBFOO_VERSION+. It can also be a
revision number, branch or tag for packages that are fetched
directly from their revision control system. +
Examples: +
+LIBFOO_VERSION = 0.1.2+ +
+LIBFOO_VERSION = cb9d6aa9429e838f0e54faa3d455bcbab5eef057+ +
+LIBFOO_VERSION = stable+
revision number or a tag for packages that are fetched directly
from their version control system. Examples:
** a version for a release tarball: +LIBFOO_VERSION = 0.1.2+
** a sha1 for a git tree: +LIBFOO_VERSION = cb9d6aa9429e838f0e54faa3d455bcbab5eef057+
** a tag for a git tree +LIBFOO_VERSION = v0.1.2+
+
.Note:
Using a branch name as +FOO_VERSION+ is not supported, because it does
not and can not work as people would expect it should:
+
1. due to local caching, Buildroot will not re-fetch the repository,
so people who expect to be able to follow the remote repository
would be quite surprised and disappointed;
2. because two builds can never be perfectly simultaneous, and because
the remote repository may get new commits on the branch anytime,
two users, using the same Buildroot tree and building the same
configuration, may get different source, thus rendering the build
non reproducible, and people would be quite surprised and
disappointed.
* +LIBFOO_SOURCE+ may contain the name of the tarball of the package,
which Buildroot will use to download the tarball from
@@ -263,7 +276,7 @@ information is (assuming the package name is +libfoo+) :
the file using this URL. Otherwise, Buildroot will assume the file
to be downloaded is located at +LIBFOO_SITE+. Buildroot will not do
anything with those additional files, except download them: it will
be up to the package recipe to use them from +$(BR2_DL_DIR)+.
be up to the package recipe to use them from +$(DL_DIR)+.
* +LIBFOO_SITE_METHOD+ determines the method used to fetch or copy the
package source code. In many cases, Buildroot guesses the method
@@ -399,8 +412,8 @@ information is (assuming the package name is +libfoo+) :
* +LIBFOO_LICENSE+ defines the license (or licenses) under which the package
is released.
This name will appear in the manifest file produced by +make legal-info+.
If the license appears in xref:legal-info-list-licenses[the following list],
use the same string to make the manifest file uniform.
If the license appears in https://spdx.org/licenses/[the SPDX License List],
use the SPDX short identifier to make the manifest file uniform.
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
@@ -408,12 +421,12 @@ information is (assuming the package name is +libfoo+) :
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
GPL-2.0+, LGPL-2.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)`+).
GPL-2.0+ (programs), LGPL-2.1+ (libraries)`+).
** If the package is dual licensed, then separate licenses with the
+or+ keyword (e.g. +`LIBFOO_LICENSE = AFLv2.1 or GPLv2+`+).
+or+ keyword (e.g. +`LIBFOO_LICENSE = AFL-2.1 or GPL-2.0+`+).
* +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.
@@ -453,6 +466,13 @@ information is (assuming the package name is +libfoo+) :
FLAT binary format is only 4k bytes. If the application consumes more stack,
append the required number here.
* +LIBFOO_BIN_ARCH_EXCLUDE+ is a space-separated list of paths (relative
to the target directory) to ignore when checking that the package
installs correctly cross-compiled binaries. You seldom need to set this
variable, unless the package installs binary blobs outside the default
locations, `/lib/firmware`, `/usr/lib/firmware`, `/lib/modules`,
`/usr/lib/modules`, and `/usr/share`, which are automatically excluded.
The recommended way to define these variables is to use the following
syntax:
@@ -540,6 +560,9 @@ In the action definitions, you can use the following variables:
* +$(@D)+, which contains the directory in which the package source
code has been uncompressed.
* +$(DL_DIR)+ contains the path to the directory where all the downloads made
by Buildroot are stored.
* +$(TARGET_CC)+, +$(TARGET_LD)+, etc. to get the target
cross-compilation utilities

View File

@@ -7,52 +7,53 @@ Many packages that support internationalization use the gettext
library. Dependencies for this library are fairly complicated and
therefore, deserve some explanation.
The 'uClibc' C library doesn't implement gettext functionality;
therefore with this C library, a separate gettext must be compiled,
which is provided by the additional +libintl+ library, part of the
The 'glibc' C library integrates a full-blown implementation of
'gettext', supporting translation. Native Language Support is
therefore built-in in 'glibc'.
On the other hand, the 'uClibc' and 'musl' C libraries only provide a
stub implementation of the gettext functionality, which allows to
compile libraries and programs using gettext functions, but without
providing the translation capabilities of a full-blown gettext
implementation. With such C libraries, if real Native Language Support
is necessary, it can be provided by the +libintl+ library of the
+gettext+ package.
On the other hand, the 'glibc' C library does integrate its own
gettext library functions, so it is not necessary to build a separate
+libintl+ library.
However, certain packages need some gettext utilities on the target,
such as the +gettext+ program itself, which allows to retrieve
translated strings, from the command line.
Additionally, some packages (such as +libglib2+) do require gettext
functions unconditionally, while other packages (in general, those who
support +--disable-nls+) only require gettext functions when locale
support is enabled.
Therefore, Buildroot defines two configuration options:
* +BR2_NEEDS_GETTEXT+, which is true as soon as the toolchain doesn't
provide its own gettext implementation
* +BR2_NEEDS_GETTEXT_IF_LOCALE+, which is true if the toolchain
doesn't provide its own gettext implementation and if locale support
is enabled
Packages that need gettext only when locale support is enabled should:
* use +select BR2_PACKAGE_GETTEXT if BR2_NEEDS_GETTEXT_IF_LOCALE+ in the
+Config.in+ file;
* use +$(if $(BR2_NEEDS_GETTEXT_IF_LOCALE),gettext)+ in the package
+DEPENDENCIES+ variable in the +.mk+ file.
Packages that unconditionally need gettext (which should be very rare)
Due to this, and in order to make sure that Native Language Support is
properly handled, packages in Buildroot that can use NLS support
should:
* use +select BR2_PACKAGE_GETTEXT if BR2_NEEDS_GETTEXT+ in the +Config.in+
file;
1. Ensure NLS support is enabled when +BR2_SYSTEM_ENABLE_NLS=y+. This
is done automatically for 'autotools' packages and therefore should
only be done for packages using other package infrastructures.
* use +$(if $(BR2_NEEDS_GETTEXT),gettext)+ in the package
+DEPENDENCIES+ variable in the +.mk+ file.
1. Add +$(TARGET_NLS_DEPENDENCIES)+ to the package
+<pkg>_DEPENDENCIES+ variable. This addition should be done
unconditionally: the value of this variable is automatically
adjusted by the core infrastructure to contain the relevant list of
packages. If NLS support is disabled, this variable is empty. If
NLS support is enabled, this variable contains +host-gettext+ so
that tools needed to compile translation files are available on the
host. In addition, if 'uClibc' or 'musl' are used, this variable
also contains +gettext+ in order to get the full-blown 'gettext'
implementation.
Packages that need the +gettext+ utilities on the target (should be
rare) should:
1. If needed, add +$(TARGET_NLS_LIBS)+ to the linker flags, so that
the package gets linked with +libintl+. This is generally not
needed with 'autotools' packages as they usually detect
automatically that they should link with +libintl+. However,
packages using other build systems, or problematic autotools-based
packages may need this. +$(TARGET_NLS_LIBS)+ should be added
unconditionally to the linker flags, as the core automatically
makes it empty or defined to +-lintl+ depending on the
configuration.
No changes should be made to the +Config.in+ file to support NLS.
Finally, certain packages need some gettext utilities on the target,
such as the +gettext+ program itself, which allows to retrieve
translated strings, from the command line. In such a case, the package
should:
* use +select BR2_PACKAGE_GETTEXT+ in their +Config.in+ file,
indicating in a comment above that it's a runtime dependency only.

View File

@@ -24,7 +24,7 @@ builds a kernel module, and no other component:
07: FOO_VERSION = 1.2.3
08: FOO_SOURCE = foo-$(FOO_VERSION).tar.xz
09: FOO_SITE = http://www.foosoftware.org/download
10: FOO_LICENSE = GPLv2
10: FOO_LICENSE = GPL-2.0
11: FOO_LICENSE_FILES = COPYING
12:
13: $(eval $(kernel-module))
@@ -63,7 +63,7 @@ Let's look at a more complex example:
07: FOO_VERSION = 1.2.3
08: FOO_SOURCE = foo-$(FOO_VERSION).tar.xz
09: FOO_SITE = http://www.foosoftware.org/download
10: FOO_LICENSE = GPLv2
10: FOO_LICENSE = GPL-2.0
11: FOO_LICENSE_FILES = COPYING
12:
13: FOO_MODULE_SUBDIRS = driver/base

View File

@@ -40,8 +40,8 @@ Unlike other packages, the +linux-tools+ package options appear in the
+linux+ kernel menu, under the `Linux Kernel Tools` sub-menu, not under
the `Target packages` main menu.
Then for each linux tool, add a new +.mk+ file named
+package/linux-tools/linux-tool-foo.mk+. It would basically look like:
Then for each linux tool, add a new +.mk.in+ file named
+package/linux-tools/linux-tool-foo.mk.in+. It would basically look like:
------------------------------
01: ################################################################################

View File

@@ -13,34 +13,40 @@ with an example :
------------------------
01: ################################################################################
02: #
03: # luafoo
03: # lua-foo
04: #
05: ################################################################################
06:
07: LUAFOO_VERSION = 1.0.2-1
08: LUAFOO_DEPENDENCIES = foo
09:
10: LUAFOO_BUILD_OPTS += FOO_INCDIR=$(STAGING_DIR)/usr/include
11: LUAFOO_BUILD_OPTS += FOO_LIBDIR=$(STAGING_DIR)/usr/lib
12: LUAFOO_LICENSE = luaFoo license
13: LUAFOO_LICENSE_FILES = COPYING
14:
15: $(eval $(luarocks-package))
07: LUA_FOO_VERSION = 1.0.2-1
08: LUA_FOO_NAME_UPSTREAM = foo
09: LUA_FOO_DEPENDENCIES = bar
10:
11: LUA_FOO_BUILD_OPTS += BAR_INCDIR=$(STAGING_DIR)/usr/include
12: LUA_FOO_BUILD_OPTS += BAR_LIBDIR=$(STAGING_DIR)/usr/lib
13: LUA_FOO_LICENSE = luaFoo license
14: LUA_FOO_LICENSE_FILES = $(LUA_FOO_SUBDIR)/COPYING
15:
16: $(eval $(luarocks-package))
------------------------
On line 7, we declare the version of the package (the same as in the rockspec,
which is the concatenation of the upstream version and the rockspec revision,
separated by a hyphen '-').
On line 8, we declare our dependencies against native libraries, so that they
On line 8, we declare that the package is called "foo" on LuaRocks. In
Buildroot, we give Lua-related packages a name that starts with "lua", so the
Buildroot name is different from the upstream name. +LUA_FOO_NAME_UPSTREAM+
makes the link between the two names.
On line 9, we declare our dependencies against native libraries, so that they
are built before the build process of our package starts.
On lines 10-11, we tell Buildroot to pass custom options to LuaRocks when it is
On lines 11-12, we tell Buildroot to pass custom options to LuaRocks when it is
building the package.
On lines 12-13, we specify the licensing terms for the package.
On lines 13-14, we specify the licensing terms for the package.
Finally, on line 15, we invoke the +luarocks-package+
Finally, on line 16, we invoke the +luarocks-package+
macro that generates all the Makefile rules that actually allows the
package to be built.
@@ -67,24 +73,29 @@ macro.
First, all the package metadata information variables that exist in
the generic infrastructure also exist in the LuaRocks infrastructure:
+LUAFOO_VERSION+, +LUAFOO_SOURCE+, +LUAFOO_SITE+,
+LUAFOO_DEPENDENCIES+, +LUAFOO_LICENSE+, +LUAFOO_LICENSE_FILES+.
+LUA_FOO_VERSION+, +LUA_FOO_SOURCE+, +LUA_FOO_SITE+,
+LUA_FOO_DEPENDENCIES+, +LUA_FOO_LICENSE+, +LUA_FOO_LICENSE_FILES+.
Two of them are populated by the LuaRocks infrastructure (for the
+download+ step). If your package is not hosted on the LuaRocks mirror
+$(BR2_LUAROCKS_MIRROR)+, you can override them:
* +LUAFOO_SITE+, which defaults to +$(BR2_LUAROCKS_MIRROR)+
* +LUA_FOO_SITE+, which defaults to +$(BR2_LUAROCKS_MIRROR)+
* +LUAFOO_SOURCE+, which defaults to +luafoo-$(LUAFOO_VERSION).src.rock+
* +LUA_FOO_SOURCE+, which defaults to
+$(lowercase LUA_FOO_NAME_UPSTREAM)-$(LUA_FOO_VERSION).src.rock+
A few additional variables, specific to the LuaRocks infrastructure, are
also defined. They can be overridden in specific cases.
* +LUAFOO_ROCKSPEC+, which defaults to +luafoo-$(LUAFOO_VERSION).rockspec+
* +LUA_FOO_NAME_UPSTREAM+, which defaults to +lua-foo+, i.e. the Buildroot
package name
* +LUAFOO_SUBDIR+, which defaults to
+luafoo-$(LUAFOO_VERSION_WITHOUT_ROCKSPEC_REVISION)+
* +LUA_FOO_ROCKSPEC+, which defaults to
+$(lowercase LUA_FOO_NAME_UPSTREAM)-$(LUA_FOO_VERSION).rockspec+
* +LUAFOO_BUILD_OPTS+ contains additional build options for the
* +LUA_FOO_SUBDIR+, which defaults to
+$(LUA_FOO_NAME_UPSTREAM)-$(LUA_FOO_VERSION_WITHOUT_ROCKSPEC_REVISION)+
* +LUA_FOO_BUILD_OPTS+ contains additional build options for the
+luarocks build+ call.

View File

@@ -0,0 +1,101 @@
// -*- mode:doc; -*-
// vim: set syntax=asciidoc:
=== Integration of Meson-based packages
[[meson-package-tutorial]]
==== +meson-package+ tutorial
http://mesonbuild.com[Meson] is an open source build system meant to be both
extremely fast, and, even more importantly, as user friendly as possible.
Buildroot does not (yet) provide a dedicated package infrastructure for
meson-based packages. So, we will explain how to write a +.mk+ file for such a
package. Let's start with an example:
------------------------------
01: ################################################################################
02: #
03: # foo
04: #
05: ################################################################################
06:
07: FOO_VERSION = 1.0
08: FOO_SOURCE = foo-$(FOO_VERSION).tar.gz
09: FOO_SITE = http://www.foosoftware.org/download
10: FOO_LICENSE = GPL-3.0+
11: FOO_LICENSE_FILES = COPYING
12: FOO_INSTALL_STAGING = YES
13:
14: FOO_DEPENDENCIES = host-meson host-pkgconf bar
15:
16: FOO_CONF_OPTS += \
17: --prefix=/usr \
18: --buildtype $(if $(BR2_ENABLE_DEBUG),debug,release) \
19: --cross-file $(HOST_DIR)/etc/meson/cross-compilation.conf
20:
21: FOO_NINJA_OPTS = $(if $(VERBOSE),-v) -j$(PARALLEL_JOBS)
22:
23: ifeq ($(BR2_PACKAGE_BAZ),y)
24: FOO_CONF_OPTS += -Dbaz
25: endif
26:
27: define FOO_CONFIGURE_CMDS
28: rm -rf $(@D)/build
29: mkdir -p $(@D)/build
30: $(TARGET_MAKE_ENV) meson $(FOO_CONF_OPTS) $(@D) $(@D)/build
31: endef
32:
33: define FOO_BUILD_CMDS
34: $(TARGET_MAKE_ENV) ninja $(FOO_NINJA_OPTS) -C $(@D)/build
35: endef
36:
37: define FOO_INSTALL_TARGET_CMDS
38: $(TARGET_MAKE_ENV) DESTDIR=$(TARGET_DIR) ninja $(FOO_NINJA_OPTS) \
39: -C $(@D)/build install
40: endef
41:
42: define FOO_INSTALL_STAGING_CMDS
43: $(TARGET_MAKE_ENV) DESTDIR=$(STAGING_DIR) ninja $(FOO_NINJA_OPTS) \
44: -C $(@D)/build install
45: endef
46:
47: $(eval $(generic-package))
--------------------------------
The Makefile starts with the definition of the standard variables for package
declaration (lines 7 to 11).
As seen in line 47, it is based on the
xref:generic-package-tutorial[+generic-package+ infrastructure]. So, it defines
the variables required by this particular infrastructure, where Meson and its
companion tool, Ninja, are invoked:
* +FOO_CONFIGURE_CMDS+: the build directory required by Meson is created, and
Meson is invoked to generate the Ninja build file. The options required to
configure the cross-compilation of the package are passed via
+FOO_CONF_OPTS+.
* +FOO_BUILD_CMDS+: Ninja is invoked to perform the build.
* +FOO_INSTALL_TARGET_CMDS+: Ninja is invoked to install the files generated
during the build step in the target directory.
* +FOO_INSTALL_STAGING_CMDS+: Ninja is invoked to install the files generated
during the build step in the staging directory, as +FOO_INSTALL_STAGING+ is
set to "YES".
In order to have Meson available for the build, +FOO_DEPENDENCIES+ needs to
contain +host-meson+. In the example, +host-pkgconf+ and +bar+ are also
declared as dependencies because the Meson build file of +foo+ uses `pkg-config`
to determine the compilation flags and libraries of package +bar+.
If the "baz" package is selected, then support for the "baz" feature in "foo"
is activated by adding +-Dbaz+ to +FOO_CONF_OPTS+, as specified in the
+meson_options.txt+ file in "foo" source tree.
To sum it up, to add a new meson-based package, the Makefile example can be
copied verbatim then edited to replace all occurences of +FOO+ with the
uppercase name of the new package and update the values of the standard
variables.

View File

@@ -21,7 +21,7 @@ with an example :
08: PERL_FOO_BAR_SOURCE = Foo-Bar-$(PERL_FOO_BAR_VERSION).tar.gz
09: PERL_FOO_BAR_SITE = $(BR2_CPAN_MIRROR)/authors/id/M/MO/MONGER
10: PERL_FOO_BAR_DEPENDENCIES = perl-strictures
11: PERL_FOO_BAR_LICENSE = Artistic or GPLv1+
11: PERL_FOO_BAR_LICENSE = Artistic or GPL-1.0+
12: PERL_FOO_BAR_LICENSE_FILES = LICENSE
13:
14: $(eval $(perl-package))
@@ -46,7 +46,7 @@ built.
Most of these data can be retrieved from https://metacpan.org/.
So, this file and the Config.in can be generated by running
the script +supports/scripts/scancpan Foo-Bar+ in the Buildroot directory
the script +utils/scancpan Foo-Bar+ in the Buildroot directory
(or in a br2-external tree).
This script creates a Config.in file and foo-bar.mk file for the
requested package, and also recursively for all dependencies specified by

View File

@@ -24,7 +24,7 @@ with an example :
07: PYTHON_FOO_VERSION = 1.0
08: PYTHON_FOO_SOURCE = python-foo-$(PYTHON_FOO_VERSION).tar.xz
09: PYTHON_FOO_SITE = http://www.foosoftware.org/download
10: PYTHON_FOO_LICENSE = BSD-3c
10: PYTHON_FOO_LICENSE = BSD-3-Clause
11: PYTHON_FOO_LICENSE_FILES = LICENSE
12: PYTHON_FOO_ENV = SOME_VAR=1
13: PYTHON_FOO_DEPENDENCIES = libmad
@@ -167,7 +167,7 @@ possible to customize what is done in any particular step:
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.
located in +utils/+ to automate the process.
You can find the list of existing PyPI packages
https://pypi.python.org[here].
@@ -178,7 +178,7 @@ your host.
When at the root of your buildroot directory just do :
-----------------------
./support/scripts/scanpypi foo bar -o package
utils/scanpypi foo bar -o package
-----------------------
This will generate packages +python-foo+ and +python-bar+ in the package
@@ -198,7 +198,7 @@ If your Buildroot package is not in the official Buildroot tree but in
a br2-external tree, use the -o flag as follows:
-----------------------
./support/scripts/scanpypi foo bar -o other_package_dir
utils/scanpypi foo bar -o other_package_dir
-----------------------
This will generate packages +python-foo+ and +python-bar+ in the
@@ -207,7 +207,7 @@ This will generate packages +python-foo+ and +python-bar+ in the
Option +-h+ will list the available options:
-----------------------
./support/scripts/scanpypi -h
utils/scanpypi -h
-----------------------
[[python-package-cffi-backend]]

View File

@@ -32,6 +32,100 @@ using the following rules:
with `.` and `-` characters substituted with `_` (e.g.:
+FOO_BAR_BOO_VERSION+).
[[testing-package]]
==== How to test your package
Once you have added your new package, it is important that you test it
under various conditions: does it build for all architectures? Does it
build with the different C libraries? Does it need threads, NPTL? And
so on...
Buildroot runs http://autobuild.buildroot.org/[autobuilders] which
continuously test random configurations. However, these only build the
`master` branch of the git tree, and your new fancy package is not yet
there.
Buildroot provides a script in +utils/test-pkg+ that uses the same base
configurations as used by the autobuilders so you can test your package
in the same conditions.
First, create a config snippet that contains all the necessary options
needed to enable your package, but without any architecture or toolchain
option. For example, let's create a config snippet that just enables
+libcurl+, without any TLS backend:
----
$ cat libcurl.config
BR2_PACKAGE_LIBCURL=y
----
If your package needs more configuration options, you can add them to the
config snippet. For example, here's how you would test +libcurl+ with
+openssl+ as a TLS backend and the +curl+ program:
----
$ cat libcurl.config
BR2_PACKAGE_LIBCURL=y
BR2_PACKAGE_CURL=y
BR2_PACKAGE_OPENSSL=y
----
Then run the +test-pkg+ script, by telling it what config snippet to use
and what package to test:
----
$ ./utils/test-pkg -c libcurl.config -p libcurl
----
This will try to build your package against all the toolchains used
by the autobuilders (except for the internal toolchains, because it takes
too long to do so). The output lists all toolchains and the corresponding
result (excerpt, results are fake):
----
$ ./utils/test-pkg -c libcurl.config -p libcurl
armv5-ctng-linux-gnueabi [ 1/11]: OK
armv7-ctng-linux-gnueabihf [ 2/11]: OK
br-aarch64-glibc [ 3/11]: SKIPPED
br-arcle-hs38 [ 4/11]: SKIPPED
br-arm-basic [ 5/11]: FAILED
br-arm-cortex-a9-glibc [ 6/11]: OK
br-arm-cortex-a9-musl [ 7/11]: FAILED
br-arm-cortex-m4-full [ 8/11]: OK
br-arm-full [ 9/11]: OK
br-arm-full-nothread [10/11]: FAILED
br-arm-full-static [11/11]: OK
11 builds, 2 skipped, 2 build failed, 1 legal-info failed
----
The results mean:
* `OK`: the build was successful.
* `SKIPPED`: one or more configuration options listed in the config
snippet were not present in the final configuration. This is due to
options having dependencies not satisfied by the toolchain, such as
for example a package that +depends on BR2_USE_MMU+ with a noMMU
toolchain. The missing options are reported in +missing.config+ in
the output build directory (+~/br-test-pkg/TOOLCHAIN_NAME/+ by
default).
* `FAILED`: the build failed. Inspect the +logfile+ file in the output
build directory to see what went wrong:
** the actual build failed,
** the legal-info failed,
** one of the preliminary steps (downloading the config file, applying
the configuration, running `dirclean` for the package) failed.
When there are failures, you can just re-run the script with the same
options (after you fixed your package); the script will attempt to
re-build the package specified with +-p+ for all toolchains, without
the need to re-build all the dependencies of that package.
The +test-pkg+ script accepts a few options, for which you can get some
help by running:
----
$ ./utils/test-pkg -h
----
[[github-download-url]]
==== How to add a package from GitHub

View File

@@ -9,6 +9,9 @@ applications) can be integrated into Buildroot. It also shows how
existing packages are integrated, which is needed for fixing issues or
tuning their configuration.
When you add a new package, be sure to test it in various conditions;
see xref:testing-package[]
include::adding-packages-directory.txt[]
include::adding-packages-generic.txt[]
@@ -31,6 +34,10 @@ include::adding-packages-rebar.txt[]
include::adding-packages-waf.txt[]
include::adding-packages-meson.txt[]
include::adding-packages-cargo.txt[]
include::adding-packages-kernel-module.txt[]
include::adding-packages-asciidoc.txt[]

View File

@@ -3,4 +3,4 @@
include::makedev-syntax.txt[]
include::makeusers-syntax.txt[]
include::br2-external-converting.txt[]
include::migrating.txt[]

View File

@@ -326,7 +326,7 @@ Buildroot release, use the +size-stats-compare+ script. It takes two
Refer to the help text of this script for more details:
----------------
support/scripts/size-stats-compare -h
utils/size-stats-compare -h
----------------
include::eclipse-integration.txt[]

View File

@@ -146,19 +146,17 @@ cross-compilation toolchains. Buildroot knows about a number of
well-known cross-compilation toolchains (from
http://www.linaro.org[Linaro] for ARM,
http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/editions/lite-edition/[Sourcery
CodeBench] for ARM, x86, x86-64, PowerPC, MIPS and SuperH,
https://blackfin.uclinux.org/gf/project/toolchain[Blackfin toolchains
from Analog Devices], etc.) and is capable of downloading them
automatically, or it can be pointed to a custom toolchain, either
available for download or installed locally.
CodeBench] for ARM, x86-64, PowerPC, and MIPS, and is capable of
downloading them automatically, or it can be pointed to a custom
toolchain, either available for download or installed locally.
Then, you have three solutions to use an external toolchain:
* Use a predefined external toolchain profile, and let Buildroot
download, extract and install the toolchain. Buildroot already knows
about a few CodeSourcery, Linaro, Blackfin and Xilinx toolchains.
Just select the toolchain profile in +Toolchain+ from the
available ones. This is definitely the easiest solution.
about a few CodeSourcery and Linaro toolchains. Just select the
toolchain profile in +Toolchain+ from the available ones. This is
definitely the easiest solution.
* Use a predefined external toolchain profile, but instead of having
Buildroot download and extract the toolchain, you can tell Buildroot
@@ -221,8 +219,6 @@ Advantages of this backend:
often very significant in the overall build time of an embedded
Linux system.
* Not limited to uClibc: glibc and eglibc toolchains are supported.
Drawbacks of this backend:
* If your pre-built external toolchain has a bug, may be hard to get a

View File

@@ -227,7 +227,7 @@ 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,
under the Buildroot license (i.e. GPL-2.0+, 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.
@@ -260,9 +260,9 @@ options that no longer exist or are no longer needed.
If you are interested in getting notified of build failures and of
further changes in the packages you added or modified, please add
yourself to the DEVELOPERS file. This should be done in a separate
patch of the series. See xref:DEVELOPERS[the DEVELOPERS file] for more
information.
yourself to the DEVELOPERS file. This should be done in the same patch
creating or modifying the package. See xref:DEVELOPERS[the DEVELOPERS file]
for more information.
==== Preparing a patch series
@@ -295,7 +295,7 @@ information). This tool reads your patches and outputs the appropriate
+git send-email+ command to use:
---------------------
$ ./support/scripts/get-developers outgoing/*
$ ./utils/get-developers outgoing/*
---------------------
Use the output of +get-developers+ to send your patches:

View File

@@ -26,7 +26,7 @@ to include in his patch the appropriate modification to the
The +DEVELOPERS+ file format is documented in detail inside the file
itself.
The +get-developer+ tool, located in +support/scripts+ allows to use
The +get-developer+ tool, located in +utils/+ allows to use
the +DEVELOPERS+ file for various tasks:
- When passing one or several patches as command line argument,
@@ -44,3 +44,5 @@ the +DEVELOPERS+ file for various tasks:
list the ones that are not handled by any developer. The purpose of
this option is to help completing the +DEVELOPERS+ file.
- When using without any arguments, it validates the integrity of the
DEVELOPERS file and will note WARNINGS for items that don't match.

View File

@@ -127,7 +127,7 @@ installed what and remove it when the package is unselected. However, it
is much more complicated than that:
* It is not only about the +target/+ directory, but also the sysroot in
+host/usr/<tuple>/sysroot+ and the +host/+ directory itself. All files
+host/<tuple>/sysroot+ and the +host/+ directory itself. All files
installed in those directories by various packages must be tracked.
* When a package is unselected from the configuration, it is not

View File

@@ -7,26 +7,6 @@
if such options contain a +$+ sign. For example, the following is known
to break: +BR2_TARGET_LDFLAGS="-Wl,-rpath=\'$ORIGIN/../lib'"+
* The +ltp-testsuite+ package does not build with the default uClibc
configuration used by the Buildroot toolchain backend. The LTP
testsuite uses several functions that are considered obsolete, such
as sigset() and others. uClibc configuration options such as
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
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 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 based toolchain, or enable the appropriate
options in the uClibc configuration.
* The +libffi+ package is not supported on the SuperH 2 and ARC
architectures.

View File

@@ -83,72 +83,6 @@ of +make legal-info+ before using it as your own compliance delivery. See
the _NO WARRANTY_ clauses (clauses 11 and 12) in the +COPYING+ file at the
root of the Buildroot distribution.
[[legal-info-list-licenses]]
=== License abbreviations
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];
* `GPLv2+`:
http://www.gnu.org/licenses/old-licenses/gpl-2.0.html[
GNU General Public License, version 2]
or (at your option) any later version;
* `GPLv3`:
http://www.gnu.org/licenses/gpl.html[
GNU General Public License, version 3];
* `GPLv3+`:
http://www.gnu.org/licenses/gpl.html[
GNU General Public License, version 3]
or (at your option) any later version;
* `GPL`:
http://www.gnu.org/licenses/gpl.html[
GNU General Public License] (any version);
* `LGPLv2`:
http://www.gnu.org/licenses/old-licenses/lgpl-2.0.html[
GNU Library General Public License, version 2];
* `LGPLv2+`:
http://www.gnu.org/licenses/old-licenses/lgpl-2.0.html[
GNU Library General Public License, version 2]
or (at your option) any later version;
* `LGPLv2.1`:
http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html[
GNU Lesser General Public License, version 2.1];
* `LGPLv2.1+`:
http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html[
GNU Lesser General Public License, version 2.1]
or (at your option) any later version;
* `LGPLv3`:
http://www.gnu.org/licenses/lgpl.html[
GNU Lesser General Public License, version 3];
* `LGPLv3+`:
http://www.gnu.org/licenses/lgpl.html[
GNU Lesser General Public License, version 3]
or (at your option) any later version;
* `LGPL`:
http://www.gnu.org/licenses/lgpl.html[
GNU Lesser General Public License] (any version);
* `BSD-4c`:
http://directory.fsf.org/wiki/License:BSD_4Clause[
Original BSD 4-clause license];
* `BSD-3c`:
http://opensource.org/licenses/BSD-3-Clause[
BSD 3-clause license];
* `BSD-2c`:
http://opensource.org/licenses/BSD-2-Clause[
BSD 2-clause license];
* `MIT`:
http://opensource.org/licenses/mit-license.html[
MIT-style license];
* `Apache-2.0`:
http://apache.org/licenses/LICENSE-2.0.html[
Apache License, version 2.0];
[[legal-info-buildroot]]
=== Complying with the Buildroot license

View File

@@ -77,3 +77,57 @@ To delete all build products as well as the configuration:
If +ccache+ is enabled, running +make clean+ or +distclean+ does
not empty the compiler cache used by Buildroot. To delete it, refer
to xref:ccache[].
.Dumping the internal make variables:
One can dump all the variables known to make, along with their values:
----
$ make -s printvars
VARIABLE=value_of_variable
...
----
It is possible to tweak the output using some variables:
- +VARS+ will limit the listing to variables which names match the
specified make-pattern
- +QUOTED_VARS+, if set to +YES+, will single-quote the value
- +RAW_VARS+, if set to +YES+, will print the unexpanded value
For example:
----
$ make -s printvars VARS=BUSYBOX_%DEPENDENCIES
BUSYBOX_DEPENDENCIES=skeleton toolchain
BUSYBOX_FINAL_ALL_DEPENDENCIES=skeleton toolchain
BUSYBOX_FINAL_DEPENDENCIES=skeleton toolchain
BUSYBOX_FINAL_PATCH_DEPENDENCIES=
BUSYBOX_RDEPENDENCIES=ncurses util-linux
----
----
$ make -s printvars VARS=BUSYBOX_%DEPENDENCIES QUOTED_VARS=YES
BUSYBOX_DEPENDENCIES='skeleton toolchain'
BUSYBOX_FINAL_ALL_DEPENDENCIES='skeleton toolchain'
BUSYBOX_FINAL_DEPENDENCIES='skeleton toolchain'
BUSYBOX_FINAL_PATCH_DEPENDENCIES=''
BUSYBOX_RDEPENDENCIES='ncurses util-linux'
----
----
$ make -s printvars VARS=BUSYBOX_%DEPENDENCIES RAW_VARS=YES
BUSYBOX_DEPENDENCIES=skeleton toolchain
BUSYBOX_FINAL_ALL_DEPENDENCIES=$(sort $(BUSYBOX_FINAL_DEPENDENCIES) $(BUSYBOX_FINAL_PATCH_DEPENDENCIES))
BUSYBOX_FINAL_DEPENDENCIES=$(sort $(BUSYBOX_DEPENDENCIES))
BUSYBOX_FINAL_PATCH_DEPENDENCIES=$(sort $(BUSYBOX_PATCH_DEPENDENCIES))
BUSYBOX_RDEPENDENCIES=ncurses util-linux
----
The output of quoted variables can be reused in shell scripts, for example:
----
$ eval $(make -s printvars VARS=BUSYBOX_DEPENDENCIES QUOTED_VARS=YES)
$ echo $BUSYBOX_DEPENDENCIES
skeleton toolchain
----

File diff suppressed because one or more lines are too long

Binary file not shown.

File diff suppressed because it is too large Load Diff

View File

@@ -9,8 +9,8 @@ Buildroot {sys:echo $\{BR2_VERSION%%-git*\}} manual generated on {localdate}
The Buildroot manual is written by the Buildroot developers.
It is licensed under the GNU General Public License, version 2. Refer to the
http://git.buildroot.org/buildroot/tree/COPYING[COPYING] file in the Buildroot
sources for the full text of this license.
http://git.buildroot.org/buildroot/tree/COPYING?id={sys:git rev-parse HEAD}[COPYING]
file in the Buildroot sources for the full text of this license.
Copyright (C) 2004-2018 The Buildroot developers

View File

@@ -1,8 +1,15 @@
// -*- mode:doc; -*-
// vim: set syntax=asciidoc:
[[migrating-from-ol-versions]]
== Migrating from older Buildroot versions
Some versions have introduced backward incompatibilities. This section
explains those incompatibilities, and for each explains what to do to
complete the migration.
[[br2-external-converting]]
== Converting old br2-external trees
=== Migrating to 2016.11
Before Buildroot 2016.11, it was possible to use only one br2-external
tree at once. With Buildroot 2016.11 came the possibility to use more
@@ -37,3 +44,15 @@ Now, your br2-external tree can be used with Buildroot 2016.11 onward.
.Note:
This change makes your br2-external tree incompatible with Buildroot
before 2016.11.
[[migrating-host-usr]]
=== Migrating to 2017.08
Before Buildroot 2017.08, host packages were installed in +$(HOST_DIR)/usr+
(with e.g. the autotools' +--prefix=$(HOST_DIR)/usr+). With Buildroot
2017.08, they are now installed directly in +$(HOST_DIR)+.
Whenever a package installs an executable that is linked with a library
in +$(HOST_DIR)/lib+, it must have an RPATH pointing to that directory.
An RPATH pointing to +$(HOST_DIR)/usr/lib+ is no longer accepted.

View File

@@ -19,9 +19,14 @@ global patch directory.
==== Downloaded
If it is necessary to apply a patch that is available for download, then add it
to the +<packagename>_PATCH+ variable. It is downloaded from the same site
as the package itself. It can be a single patch, or a tarball containing a
patch series.
to the +<packagename>_PATCH+ variable. If an entry contains +://+,
then Buildroot will assume it is a full URL and download the patch
from this location. Otherwise, Buildroot will assume that the patch should be
downloaded from +<packagename>_SITE+. It can be a single patch,
or a tarball containing a patch series.
Like for all downloads, a hash should be added to the +<packagename>.hash+
file.
This method is typically used for packages from Debian.

View File

@@ -23,8 +23,8 @@ between distributions).
** +make+ (version 3.81 or any later)
** +binutils+
** +build-essential+ (only for Debian based systems)
** +gcc+ (version 2.95 or any later)
** `g++` (version 2.95 or any later)
** +gcc+ (version 4.4 or any later)
** `g++` (version 4.4 or any later)
** +bash+
** +patch+
** +gzip+

View File

@@ -35,7 +35,7 @@ Then, on the host, you should start the cross gdb using the following
command line:
----------------------------
<buildroot>/output/host/usr/bin/<tuple>-gdb -x <buildroot>/output/staging/usr/share/buildroot/gdbinit foo
<buildroot>/output/host/bin/<tuple>-gdb -x <buildroot>/output/staging/usr/share/buildroot/gdbinit foo
----------------------------
Of course, +foo+ must be available in the current directory, built

View File

@@ -9,14 +9,18 @@ can use the toolchain that was generated by Buildroot.
The toolchain generated by Buildroot is located by default in
+output/host/+. The simplest way to use it is to add
+output/host/usr/bin/+ to your PATH environment variable and then to
+output/host/bin/+ to your PATH environment variable and then to
use +ARCH-linux-gcc+, +ARCH-linux-objdump+, +ARCH-linux-ld+, etc.
It is possible to relocate the toolchain - but then +--sysroot+ must
be passed every time the compiler is called to tell where the
libraries and header files are.
It is possible to relocate the toolchain, this allows to distribute
the toolchain to other developers to build applications for your
target. To achieve this:
* run +make sdk+, which prepares the toolchain to be relocatable;
* tarball the contents of the +output/host+ directory;
* distribute the resulting tarball.
Once the toolchain is installed to the new location, the user must run
the +relocate-sdk.sh+ script to make sure all paths are updated with
the new location.
It is also possible to generate the Buildroot toolchain in a directory
other than +output/host+ by using the +Build options -> Host dir+
option. This could be useful if the toolchain must be shared with
other users.

View File

@@ -29,7 +29,8 @@ config BR2_PACKAGE_LIBFOO
depends on BR2_PACKAGE_LIBBAZ
select BR2_PACKAGE_LIBBAR
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/
---------------------
@@ -40,7 +41,8 @@ config BR2_PACKAGE_LIBFOO
* The help text itself should be indented with one tab and two
spaces.
* The help text should be wrapped to fit 72 columns.
* The help text should be wrapped to fit 72 columns, where tab counts
for 8, so 62 characters in the text itself.
The +Config.in+ files are the input for the configuration tool
used in Buildroot, which is the regular _Kconfig_. For further
@@ -141,3 +143,9 @@ http://www.methods.co.nz/asciidoc/[asciidoc] format.
For further details about the http://www.methods.co.nz/asciidoc/[asciidoc]
syntax, refer to http://www.methods.co.nz/asciidoc/userguide.html[].
=== Support scripts
Some scripts in the +support/+ and +utils/+ directories are written in
Python and should follow the
https://www.python.org/dev/peps/pep-0008/[PEP8 Style Guide for Python Code].

View File

@@ -0,0 +1,62 @@
# BEGIN Compress text files
<ifModule mod_deflate.c>
<filesMatch ".(css|js|x?html?|php)$">
SetOutputFilter DEFLATE
</filesMatch>
</ifModule>
# END Compress text files
# BEGIN Expire headers
<ifModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 1 seconds"
ExpiresByType image/x-icon "access plus 2592000 seconds"
ExpiresByType image/jpeg "access plus 2592000 seconds"
ExpiresByType image/png "access plus 2592000 seconds"
ExpiresByType image/gif "access plus 2592000 seconds"
ExpiresByType application/x-shockwave-flash "access plus 2592000 seconds"
ExpiresByType text/css "access plus 604800 seconds"
ExpiresByType text/javascript "access plus 216000 seconds"
ExpiresByType application/javascript "access plus 216000 seconds"
ExpiresByType application/x-javascript "access plus 216000 seconds"
ExpiresByType text/html "access plus 600 seconds"
ExpiresByType application/xhtml+xml "access plus 600 seconds"
</ifModule>
# END Expire headers
# BEGIN Cache-Control Headers
<ifModule mod_headers.c>
<filesMatch ".(ico|jpe?g|png|gif|swf)$">
Header set Cache-Control "max-age=2592000, public"
</filesMatch>
<filesMatch ".(css)$">
Header set Cache-Control "max-age=604800, public"
</filesMatch>
<filesMatch ".(js)$">
Header set Cache-Control "max-age=216000, private"
</filesMatch>
<filesMatch ".(x?html?|php)$">
Header set Cache-Control "max-age=600, private, must-revalidate"
</filesMatch>
</ifModule>
# END Cache-Control Headers
# BEGIN Turn ETags Off
<ifModule mod_headers.c>
Header unset ETag
</ifModule>
FileETag None
# END Turn ETags Off
# BEGIN gzip
<ifModule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_item_include file .(html?|txt|css|js)$
mod_gzip_item_include handler ^cgi-script$
mod_gzip_item_include mime ^text/.*
mod_gzip_item_include mime ^application/x-javascript.*
mod_gzip_item_exclude mime ^image/.*
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
</ifModule>
# END gzip

View File

@@ -78,8 +78,8 @@
<div class="panel panel-primary">
<div class="panel-heading">Training</div>
<div class="panel-body">
<p><a href="http://www.free-electrons.com">Free Electrons</a> offers a
complete <a href="http://free-electrons.com/training/buildroot/">3-days
<p><a href="http://www.bootlin.com">Bootlin</a> (formerly Free Electrons)
offers a complete <a href="http://bootlin.com/training/buildroot/">3-days
training course on Buildroot</a>. They also make the training
materials freely available:</p>
@@ -89,7 +89,7 @@
<div class="panel-heading">Slides preview</div>
<div class="panel-body">
<div id="slides" style="width: 100%; padding-bottom: 75%; position: relative">
<a href="http://free-electrons.com/doc/training/buildroot/buildroot-slides.pdf"><img src="images/buildroot-slides.png" alt="buildroot slides" style="position:absolute; width:100%; height:100%; top:0; left:0;"></a>
<a href="http://bootlin.com/doc/training/buildroot/buildroot-slides.pdf"><img src="images/buildroot-slides.png" alt="buildroot slides" style="position:absolute; width:100%; height:100%; top:0; left:0;"></a>
</div>
</div>
</div>
@@ -100,9 +100,9 @@
<div class="panel-heading">Training materials</div>
<div class="panel-body">
<ul>
<li><a href="http://free-electrons.com/doc/training/buildroot/buildroot-slides.pdf">slides (PDF)</a></li>
<li><a href="http://free-electrons.com/doc/training/buildroot/buildroot-labs.pdf">practical labs (PDF)</a></li>
<li><a href="http://free-electrons.com/doc/training/buildroot/buildroot-labs.tar.xz">practical labs data (.tar.xz)</a></li>
<li><a href="http://bootlin.com/doc/training/buildroot/buildroot-slides.pdf">slides (PDF)</a></li>
<li><a href="http://bootlin.com/doc/training/buildroot/buildroot-labs.pdf">practical labs (PDF)</a></li>
<li><a href="http://bootlin.com/doc/training/buildroot/buildroot-labs.tar.xz">practical labs data (.tar.xz)</a></li>
</ul>
</div>
</div>

View File

@@ -8,71 +8,105 @@
<div class="panel-heading">Download</div>
<div class="panel-body">
<h3 style="text-align: center;">Latest stable release: <b>2017.02</b></h3>
<h3 style="text-align: center;">Latest stable / long term support release: <b>2018.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-2017.02.tar.gz"><img src="images/zip.png" width="180" alt=""></a>
<a href="/downloads/buildroot-2018.02.tar.gz"><img src="images/zip.png" width="180" alt=""></a>
</div>
<div class="back">
<a href="/downloads/buildroot-2017.02.tar.gz"><img src="images/zip.png" width="180" alt=""></a>
<a href="/downloads/buildroot-2018.02.tar.gz"><img src="images/zip.png" width="180" alt=""></a>
</div>
</div>
</div>
<h3><a href="/downloads/buildroot-2017.02.tar.gz">buildroot-2017.02.tar.gz</a></h3>
<p><a href="/downloads/buildroot-2017.02.tar.gz.sign">PGP signature</a></p>
<h3><a href="/downloads/buildroot-2018.02.tar.gz">buildroot-2018.02.tar.gz</a></h3>
<p><a href="/downloads/buildroot-2018.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-2017.02.tar.bz2"><img src="images/package.png" width="180" alt=""></a>
<a href="/downloads/buildroot-2018.02.tar.bz2"><img src="images/package.png" width="180" alt=""></a>
</div>
<div class="back">
<a href="/downloads/buildroot-2017.02.tar.bz2"><img src="images/package.png" width="180" alt=""></a>
<a href="/downloads/buildroot-2018.02.tar.bz2"><img src="images/package.png" width="180" alt=""></a>
</div>
</div>
</div>
<h3><a href="/downloads/buildroot-2017.02.tar.bz2">buildroot-2017.02.tar.bz2</a></h3>
<p><a href="/downloads/buildroot-2017.02.tar.bz2.sign">PGP signature</a></p>
<h3><a href="/downloads/buildroot-2018.02.tar.bz2">buildroot-2018.02.tar.bz2</a></h3>
<p><a href="/downloads/buildroot-2018.02.tar.bz2.sign">PGP signature</a></p>
</div>
</div>
<!--
<h3 style="text-align: center;">Latest release candidate: <b>2017.02-rc3</b></h3>
<h3 style="text-align: center;">Latest stable release: <b>2017.11.2</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-2017.02-rc3.tar.gz"><img src="images/zip.png" width="180" alt=""></a>
<a href="/downloads/buildroot-2017.11.2.tar.gz"><img src="images/zip.png" width="180" alt=""></a>
</div>
<div class="back">
<a href="/downloads/buildroot-2017.02-rc3.tar.gz"><img src="images/zip.png" width="180" alt=""></a>
<a href="/downloads/buildroot-2017.11.2.tar.gz"><img src="images/zip.png" width="180" alt=""></a>
</div>
</div>
</div>
<h3><a href="/downloads/buildroot-2017.02-rc3.tar.gz">buildroot-2017.02-rc3.tar.gz</a></h3>
<p><a href="/downloads/buildroot-2017.02-rc3.tar.gz.sign">PGP signature</a></p>
<h3><a href="/downloads/buildroot-2017.11.2.tar.gz">buildroot-2017.11.2.tar.gz</a></h3>
<p><a href="/downloads/buildroot-2017.11.2.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-2017.02-rc3.tar.bz2"><img src="images/package.png" width="180" alt=""></a>
<a href="/downloads/buildroot-2017.11.2.tar.bz2"><img src="images/package.png" width="180" alt=""></a>
</div>
<div class="back">
<a href="/downloads/buildroot-2017.02-rc3.tar.bz2"><img src="images/package.png" width="180" alt=""></a>
<a href="/downloads/buildroot-2017.11.2.tar.bz2"><img src="images/package.png" width="180" alt=""></a>
</div>
</div>
</div>
<h3><a href="/downloads/buildroot-2017.02-rc3.tar.bz2">buildroot-2017.02-rc3.tar.bz2</a></h3>
<p><a href="/downloads/buildroot-2017.02-rc3.tar.bz2.sign">PGP signature</a></p>
<h3><a href="/downloads/buildroot-2017.11.2.tar.bz2">buildroot-2017.11.2.tar.bz2</a></h3>
<p><a href="/downloads/buildroot-2017.11.2.tar.bz2.sign">PGP signature</a></p>
</div>
</div>
<h3 style="text-align: center;">Latest release candidate: <b>2018.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-2018.02-rc3.tar.gz"><img src="images/zip.png" width="180" alt=""></a>
</div>
<div class="back">
<a href="/downloads/buildroot-2018.02-rc3.tar.gz"><img src="images/zip.png" width="180" alt=""></a>
</div>
</div>
</div>
<h3><a href="/downloads/buildroot-2018.02-rc3.tar.gz">buildroot-2018.02-rc3.tar.gz</a></h3>
<p><a href="/downloads/buildroot-2018.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-2018.02-rc3.tar.bz2"><img src="images/package.png" width="180" alt=""></a>
</div>
<div class="back">
<a href="/downloads/buildroot-2018.02-rc3.tar.bz2"><img src="images/package.png" width="180" alt=""></a>
</div>
</div>
</div>
<h3><a href="/downloads/buildroot-2018.02-rc3.tar.bz2">buildroot-2018.02-rc3.tar.bz2</a></h3>
<p><a href="/downloads/buildroot-2018.02-rc3.tar.bz2.sign">PGP signature</a></p>
</div>
</div>
-->

View File

@@ -78,7 +78,7 @@
</div>
</div>
<h4>Supports hundreds of packages</h4>
<h4>Supports several thousand packages</h4>
<p>X.org stack, Gtk3, Qt 5, GStreamer, Webkit, Kodi, a large number of network-related and system-related utilities are supported.</p>
</div><!--/col-lg-4 -->

View File

@@ -90,5 +90,5 @@ jQuery(document).ready(function($) {
load_activity("http://buildroot-busybox.2317881.n4.nabble.com/Buildroot-busybox-ft2.xml", "mailing-list-activity");
load_activity("http://git.buildroot.org/buildroot/atom/?h=master", "commit-activity");
$('#slides').html('<iframe src="https://docs.google.com/gview?url=http://free-electrons.com/doc/training/buildroot/buildroot-slides.pdf&embedded=true" style="position:absolute; width:100%; height:100%; top:0; left:0;" frameborder="0"></iframe>')
$('#slides').html('<iframe src="https://docs.google.com/gview?url=http://bootlin.com/doc/training/buildroot/buildroot-slides.pdf&embedded=true" style="position:absolute; width:100%; height:100%; top:0; left:0;" frameborder="0"></iframe>')
});

View File

@@ -9,6 +9,663 @@
<h2>News</h2>
<ul class="timeline">
<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">2018.02 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>4 March 2018</small></p>
</div>
<div class="timeline-body">
<p>The stable 2018.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=2018.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-2018.02.tar.bz2">2018.02 release</a>.</p>
<p>Notice that this is a long term support release which will be
supported with security and other important fixes until February 2019.</p>
</div>
</div>
</li>
<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">2018.02-rc3 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>27 February 2018</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=2018.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-2018.02-rc3.tar.bz2">2018.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>
<div class="timeline-badge"><i class="glyphicon glyphicon-thumbs-up"></i></div>
<div class="timeline-panel">
<div class="timeline-heading">
<h4 class="timeline-title">2018.02-rc2 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>15 February 2018</small></p>
</div>
<div class="timeline-body">
<p>Another week, another release candidate with more cleanups
and build fixes. See the
<a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2018.02-rc2">CHANGES</a>
file for details.</p>
<p>Head to the <a href="/downloads/">downloads page</a> to pick up the
<a href="/downloads/buildroot-2018.02-rc2.tar.bz2">2018.02-rc2
release candidate</a>, and report any problems found to the
<a href="support.html">mailing list</a> or
<a href="https://bugs.buildroot.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">
<div class="timeline-heading">
<h4 class="timeline-title">2018.02-rc1 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>5 February 2018</small></p>
</div>
<div class="timeline-body">
<p>We have a new release candidate! Lots of changes all over the
tree, see the
<a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2018.02-rc1">CHANGES</a>
file for details and read the
<a href="http://lists.busybox.net/pipermail/buildroot/2018-February/213171.html">announcement</a>.
</p>
<p>Head to the <a href="/downloads/">downloads page</a> to pick up the
<a href="/downloads/buildroot-2018.02-rc1.tar.bz2">2018.02-rc1
release candidate</a>, and report any problems found to the
<a href="support.html">mailing list</a> or
<a href="https://bugs.buildroot.org">bug tracker</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">2017.02.10 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>31 January 2018</small></p>
</div>
<div class="timeline-body">
<p>The 2017.02.10 bugfix release is out, fixing a number of important /
security related issues discovered since the 2017.02.9 release. See the
<a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2017.02.10">CHANGES</a>
file for more details, read the
<a href="http://lists.busybox.net/pipermail/buildroot/2018-January/212844.html">announcement</a>
and go to the <a href="/downloads/">downloads page</a> to pick up the
<a href="/downloads/buildroot-2017.02.10.tar.bz2">2017.02.10 release</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">
<div class="timeline-heading">
<h4 class="timeline-title">2017.11.2 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>21 January 2018</small></p>
</div>
<div class="timeline-body">
<p>The 2017.11.2 bugfix release is out, fixing a number of important /
security related issues discovered since the 2017.11.1 release. See the
<a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2017.11.2">CHANGES</a>
file for more details, read the
<a href="http://lists.busybox.net/pipermail/buildroot/2018-January/212069.html">announcement</a>
and go to the <a href="/downloads/">downloads page</a> to pick up the
<a href="/downloads/buildroot-2017.11.2.tar.bz2">2017.11.2 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">2017.02.9 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>1 January 2018</small></p>
</div>
<div class="timeline-body">
<p>The 2017.02.9 bugfix release is out, fixing a number of important /
security related issues discovered since the 2017.02.8 release. See the
<a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2017.02.9">CHANGES</a>
file for more details, read the
<a href="http://lists.busybox.net/pipermail/buildroot/2018-January/210559.html">announcement</a>
and go to the <a href="/downloads/">downloads page</a> to pick up the
<a href="/downloads/buildroot-2017.02.9.tar.bz2">2017.02.9 release</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">
<div class="timeline-heading">
<h4 class="timeline-title">2017.11.1 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>31 December 2017</small></p>
</div>
<div class="timeline-body">
<p>The 2017.11.1 bugfix release is out, fixing a number of important /
security related issues discovered since the 2017.11 release. See the
<a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2017.11.1">CHANGES</a>
file for more details, read the
<a href="http://lists.busybox.net/pipermail/buildroot/2017-December/210505.html">announcement</a>
and go to the <a href="/downloads/">downloads page</a> to pick up the
<a href="/downloads/buildroot-2017.11.1.tar.bz2">2017.11.1 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">2017.11 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>30 November 2017</small></p>
</div>
<div class="timeline-body">
<p>The stable 2017.11 release is out - Thanks to everyone
contributing and testing the release candidates. See the
<a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2017.11">CHANGES</a>
file for more details, read the
<a href="http://lists.busybox.net/pipermail/buildroot/2017-December/208338.html">announcement</a>
and go to the <a href="/downloads/">downloads page</a> to pick up the
<a href="/downloads/buildroot-2017.11.tar.bz2">2017.11 release</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">
<div class="timeline-heading">
<h4 class="timeline-title">2017.08.2 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>29 November 2017</small></p>
</div>
<div class="timeline-body">
<p>The 2017.08.2 bugfix release is out, fixing a number of important /
security related issues discovered since the 2017.08.1 release. See the
<a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2017.08.2">CHANGES</a>
file for more details, read the
<a href="http://lists.busybox.net/pipermail/buildroot/2017-November/208174.html">announcement</a>
and go to the <a href="/downloads/">downloads page</a> to pick up the
<a href="/downloads/buildroot-2017.08.2.tar.bz2">2017.08.2 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">2017.02.8 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>27 November 2017</small></p>
</div>
<div class="timeline-body">
<p>The 2017.02.8 bugfix release is out, fixing a number of important /
security related issues discovered since the 2017.02.7 release. See the
<a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2017.02.8">CHANGES</a>
file for more details, read the
<a href="http://lists.busybox.net/pipermail/buildroot/2017-November/208113.html">announcement</a>
and go to the <a href="/downloads/">downloads page</a> to pick up the
<a href="/downloads/buildroot-2017.02.8.tar.bz2">2017.02.8 release</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">
<div class="timeline-heading">
<h4 class="timeline-title">2017.11-rc2 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>13 November 2017</small></p>
</div>
<div class="timeline-body">
<p>Another week, another release candidate with more cleanups
and build fixes. See the
<a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2017.11-rc2">CHANGES</a>
file for details.</p>
<p>Head to the <a href="/downloads/">downloads page</a> to pick up the
<a href="/downloads/buildroot-2017.11-rc2.tar.bz2">2017.11-rc2
release candidate</a>, and report any problems found to the
<a href="support.html">mailing list</a> or
<a href="https://bugs.buildroot.org">bug tracker</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">2017.11-rc1 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>6 November 2017</small></p>
</div>
<div class="timeline-body">
<p>We have a new release candidate! Lots of changes all over
the tree, see
the <a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2017.11-rc1">CHANGES</a>
file for details.
</p>
<p>Head to the <a href="/downloads/">downloads page</a> to pick up the
<a href="/downloads/buildroot-2017.11-rc1.tar.bz2">2017.11-rc1
release candidate</a>, and report any problems found to the
<a href="support.html">mailing list</a> or
<a href="https://bugs.buildroot.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">
<div class="timeline-heading">
<h4 class="timeline-title">2017.02.7 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>28 October 2017</small></p>
</div>
<div class="timeline-body">
<p>The 2017.02.7 bugfix release is out, fixing a number of important /
security related issues discovered since the 2017.02.6 release. See the
<a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2017.02.7">CHANGES</a>
file for more details, read the
<a href="http://lists.busybox.net/pipermail/buildroot/2017-October/205628.html">announcement</a>
and go to the <a href="/downloads/">downloads page</a> to pick up the
<a href="/downloads/buildroot-2017.02.7.tar.bz2">2017.02.7 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">2017.08.1 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>23 October 2017</small></p>
</div>
<div class="timeline-body">
<p>The 2017.08.1 bugfix release is out, fixing a number of important /
security related issues discovered since the 2017.08 release. See the
<a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2017.08.1">CHANGES</a>
file for more details, read the
<a href="http://lists.busybox.net/pipermail/buildroot/2017-October/205323.html">announcement</a>
and go to the <a href="/downloads/">downloads page</a> to pick up the
<a href="/downloads/buildroot-2017.08.1.tar.bz2">2017.08.1 release</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">
<div class="timeline-heading">
<h4 class="timeline-title">2017.02.6 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>24 September 2017</small></p>
</div>
<div class="timeline-body">
<p>The 2017.02.6 bugfix release is out, fixing a number of important /
security related issues discovered since the 2017.02.5 release. See the
<a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2017.02.6">CHANGES</a>
file for more details, read the
<a href="http://lists.busybox.net/pipermail/buildroot/2017-September/203197.html">announcement</a>
and go to the <a href="/downloads/">downloads page</a> to pick up the
<a href="/downloads/buildroot-2017.02.6.tar.bz2">2017.02.6 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">2017.08 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>1 September 2017</small></p>
</div>
<div class="timeline-body">
<p>The stable 2017.08 release is out - Thanks to everyone
contributing and testing the release candidates. See the
<a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2017.08">CHANGES</a>
file for more details
and go to the <a href="/downloads/">downloads page</a> to pick up the
<a href="/downloads/buildroot-2017.08.tar.bz2">2017.08 release</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">
<div class="timeline-heading">
<h4 class="timeline-title">2017.08-rc3 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>23 August 2017</small></p>
</div>
<div class="timeline-body">
<p>Another release candidate, on the road to the final 2017.08
release. A number of fixes and cleanups in various packages
and defconfigs. See
the <a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2017.08-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-2017.08-rc3.tar.bz2">2017.08-rc3
release candidate</a>, and report any
problems found to the
<a href="support.html">mailing list</a> or
<a href="https://bugs.buildroot.org">bug tracker</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">2017.08-rc2 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>11 August 2017</small></p>
</div>
<div class="timeline-body">
<p>Another release candidate, on the road to the final 2017.08
release. A number of fixes and cleanups in various packages
and defconfigs. See
the <a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2017.08-rc2">CHANGES</a>
file for details.
</p>
<p>Head to the <a href="/downloads/">downloads page</a> to pick up the
<a href="/downloads/buildroot-2017.08-rc2.tar.bz2">2017.08-rc2
release candidate</a>, and report any
problems found to the
<a href="support.html">mailing list</a> or
<a href="https://bugs.buildroot.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">
<div class="timeline-heading">
<h4 class="timeline-title">2017.08-rc1 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>2 August 2017</small></p>
</div>
<div class="timeline-body">
<p>We have a new release candidate! Lots of changes all over
the tree, see
the <a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2017.08-rc1">CHANGES</a>
file for details.
</p>
<p>Head to the <a href="/downloads/">downloads page</a> to pick up the
<a href="/downloads/buildroot-2017.08-rc1.tar.bz2">2017.08-rc1
release candidate</a>, and report any
problems found to the
<a href="support.html">mailing list</a> or
<a href="https://bugs.buildroot.org">bug tracker</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">2017.05.2 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>27 July 2017</small></p>
</div>
<div class="timeline-body">
<p>The 2017.05.2 bugfix release is out, fixing a number of important /
security related issues discovered since the 2017.05.1 release. See the
<a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2017.05.2">CHANGES</a>
file for more details, read the
<a href="http://lists.busybox.net/pipermail/buildroot/2017-July/199284.html">announcement</a>
and go to the <a href="/downloads/">downloads page</a> to pick up the
<a href="/downloads/buildroot-2017.05.2.tar.bz2">2017.05.2 release</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">
<div class="timeline-heading">
<h4 class="timeline-title">2017.02.5 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>27 July 2017</small></p>
</div>
<div class="timeline-body">
<p>The 2017.02.5 bugfix release is out, fixing a number of important /
security related issues discovered since the 2017.02.4 release. See the
<a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2017.02.5">CHANGES</a>
file for more details, read the
<a href="http://lists.busybox.net/pipermail/buildroot/2017-July/199281.html">announcement</a>
and go to the <a href="/downloads/">downloads page</a> to pick up the
<a href="/downloads/buildroot-2017.02.5.tar.bz2">2017.02.5 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">2017.05.1 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>4 July 2017</small></p>
</div>
<div class="timeline-body">
<p>The 2017.05.1 bugfix release is out, fixing a number of important /
security related issues discovered since the 2017.05 release. See the
<a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2017.05.1">CHANGES</a>
file for more details, read the
<a href="http://lists.busybox.net/pipermail/buildroot/2017-July/196743.html">announcement</a>
and go to the <a href="/downloads/">downloads page</a> to pick up the
<a href="/downloads/buildroot-2017.05.1.tar.bz2">2017.05.1 release</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">
<div class="timeline-heading">
<h4 class="timeline-title">2017.02.4 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>4 July 2017</small></p>
</div>
<div class="timeline-body">
<p>The 2017.02.4 bugfix release is out, fixing a number of important /
security related issues discovered since the 2017.02.3 release. See the
<a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2017.02.4">CHANGES</a>
file for more details, read the
<a href="http://lists.busybox.net/pipermail/buildroot/2017-July/196719.html">announcement</a>
and go to the <a href="/downloads/">downloads page</a> to pick up the
<a href="/downloads/buildroot-2017.02.4.tar.bz2">2017.02.4 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">2017.02.3 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>2 June 2017</small></p>
</div>
<div class="timeline-body">
<p>The 2017.02.3 bugfix release is out, fixing a number of important /
security related issues discovered since the 2017.02.2 release. See the
<a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2017.02.3">CHANGES</a>
file for more details, read the
<a href="http://lists.busybox.net/pipermail/buildroot/2017-June/193485.html">announcement</a>
and go to the <a href="/downloads/">downloads page</a> to pick up the
<a href="/downloads/buildroot-2017.02.3.tar.bz2">2017.02.3 release</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">
<div class="timeline-heading">
<h4 class="timeline-title">2017.05 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>31 May 2017</small></p>
</div>
<div class="timeline-body">
<p>The stable 2017.05 release is out - Thanks to everyone
contributing and testing the release candidates. See the
<a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2017.05">CHANGES</a>
file for more details, read the
<a href="http://lists.busybox.net/pipermail/buildroot/2017-June/193164.html">announcement</a>
and go to the <a href="/downloads/">downloads page</a> to pick up the
<a href="/downloads/buildroot-2017.05.tar.bz2">2017.05 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">2017.05-rc3 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>30 May 2017</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=2017.05-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-2017.05-rc3.tar.bz2">2017.05-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">
<div class="timeline-heading">
<h4 class="timeline-title">2017.05-rc2 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>17 May 2017</small></p>
</div>
<div class="timeline-body">
<p>Another week, another release candidate with more cleanups
and build fixes. See the
<a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2017.05-rc2">CHANGES</a>
file for details.</p>
<p>Head to the <a href="/downloads/">downloads page</a> to pick up the
<a href="/downloads/buildroot-2017.05-rc2.tar.bz2">2017.05-rc2
release candidate</a>, and report any problems found to the
<a href="support.html">mailing list</a> or
<a href="https://bugs.buildroot.org">bug tracker</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">2017.05-rc1 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>8 May 2017</small></p>
</div>
<div class="timeline-body">
<p>We have a new release candidate! Lots of changes all over
the tree, see
the <a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2017.05-rc1">CHANGES</a>
file for details.
</p>
<p>Head to the <a href="/downloads/">downloads page</a> to pick up the
<a href="/downloads/buildroot-2017.05-rc1.tar.bz2">2017.05-rc1
release candidate</a>, and report any
problems found to the
<a href="support.html">mailing list</a> or
<a href="https://bugs.buildroot.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">
<div class="timeline-heading">
<h4 class="timeline-title">2017.02.2 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>1 May 2017</small></p>
</div>
<div class="timeline-body">
<p>The 2017.02.2 bugfix release is out, fixing a number of important /
security related issues discovered since the 2017.02.1 release. See the
<a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2017.02.2">CHANGES</a>
file for more details, read the
<a href="http://lists.busybox.net/pipermail/buildroot/2017-May/191062.html">announcement</a>
and go to the <a href="/downloads/">downloads page</a> to pick up the
<a href="/downloads/buildroot-2017.02.2.tar.bz2">2017.02.2 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">2017.02.1 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>4 April 2017</small></p>
</div>
<div class="timeline-body">
<p>The 2017.02.1 bugfix release is out, fixing a number of important /
security related issues discovered since the 2017.02 release. See the
<a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2017.02.1">CHANGES</a>
file for more details, read the
<a href="http://lists.busybox.net/pipermail/buildroot/2017-April/188708.html">announcement</a>
and go to the <a href="/downloads/">downloads page</a> to pick up the
<a href="/downloads/buildroot-2017.02.1.tar.bz2">2017.02.1 release</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">
<div class="timeline-heading">
<h4 class="timeline-title">2016.11.3 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>10 March 2017</small></p>
</div>
<div class="timeline-body">
<p>The 2016.11.3 bugfix release is out, fixing a number of important /
security related issues discovered since the 2016.11.2 release. See the
<a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2016.11.3">CHANGES</a>
file for more details, read the
<a href="http://lists.busybox.net/pipermail/buildroot/2017-March/186418.html">announcement</a>
and go to the <a href="/downloads/">downloads page</a> to pick up the
<a href="/downloads/buildroot-2016.11.3.tar.bz2">2016.11.3 release</a>.</p>
<p>Notice that this is the final 2016.11.x release. Users are
urged to migrate to the 2017.02.x series instead.</p>
</div>
</div>
</li>
<li>
<div class="timeline-badge"><i class="glyphicon glyphicon-thumbs-up"></i></div>
<div class="timeline-panel">
@@ -20,9 +677,13 @@
<p>The stable 2017.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=2017.02">CHANGES</a>
file for more details
file for more details, read the
<a href="http://lists.busybox.net/pipermail/buildroot/2017-February/185228.html">announcement</a>
and go to the <a href="/downloads/">downloads page</a> to pick up the
<a href="/downloads/buildroot-2017.02.tar.bz2">2017.02 release</a>.</p>
<p>Notice that this is a long term support release which will be
supported with security and other important fixes until February 2018.</p>
</div>
</div>
</li>

View File

@@ -21,8 +21,8 @@
<div class="col-sm-8">
<a href="http://www.google.com">Google</a> is
sponsoring
the <a href="http://elinux.org/Buildroot:DeveloperDaysFOSDEM2017">Buildroot
Developers Meeting at FOSDEM 2017</a> in Brussels, by
the <a href="http://elinux.org/Buildroot:DeveloperDaysFOSDEM2018">Buildroot
Developers Meeting at FOSDEM 2018</a> in Brussels, by
providing logistics for the meeting: a free meeting
room and lunch for the participants.
</div>
@@ -39,8 +39,8 @@
</div>
<div class="col-sm-8">
As it did in previous years, <a href="http://www.mind.be">Mind</a>
is sponsoring the Monday night dinner at the <a href="http://elinux.org/Buildroot:DeveloperDaysFOSDEM2017">Buildroot
Developers Meeting at FOSDEM 2017</a> in Brussels.
is sponsoring the Monday night dinner at the <a href="http://elinux.org/Buildroot:DeveloperDaysFOSDEM2018">Buildroot
Developers Meeting at FOSDEM 2018</a> in Brussels.
</div>
</div>
</div>
@@ -83,9 +83,9 @@
<div class="col-sm-12">
<a href="http://www.mind.be">Mind</a> sponsored the
dinner of the FOSDEM 2014, 2015, 2016 and 2017
Developers Meeting (Brussels) and ELCE 2016 (Berlin),
the meeting room and the dinner for the ELCE 2014
Developers Meeting (Düsseldorf).
Developers Meeting (Brussels) and ELCE 2016 (Berlin)
and 2017 (Prague), and the meeting room and the dinner for
the ELCE 2014 Developers Meeting (Düsseldorf).
</div>
</div>
</div>
@@ -101,8 +101,8 @@
<div class="col-sm-12">
<p><a href="http://www.google.com">Google</a> provided
the logistics for the FOSDEM 2013, FOSDEM 2014,
FOSDEM 2015 and FOSDEM 2016 Developer Days in
Brussels, Belgium.</p>
FOSDEM 2015, FOSDEM 2016 and FOSDEM 2017 Developer Days
in Brussels, Belgium.</p>
</div>
</div>
</div>

View File

@@ -72,7 +72,7 @@
<img class="img-responsive" src="images/bug-buddy.png" style="max-width:50px; margin-bottom:10px;">
</div>
<div class="col-sm-11">
<p>If you encounter any problem while using Buildroot, you can use the
<p>If you think you found a bug in Buildroot, you can use the
<a href="https://bugs.buildroot.org/">Bug Tracker</a> to post your bugs and/or
participate to find solutions to existing problems.</p>