- Replace first patch to fix build when using a development version
- Fix build with openzwave 1.6 through:
56d3fa099d
- Add patch to revert cmake 3.14 dependency as buildroot currently
requires only 3.8
Fixes:
- http://autobuild.buildroot.org/results/3dbb6612205020cc156d245a75c76a7886f7d529
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Removed patch for sys/xattr.h handling and replaced it with the new
upstream-provided configure option --disable-xattr-h-pref-attr
848e039e6d
Removed autoreconf, not needed anymore.
Added license hashes.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Also added a reference for upstream-provided sha1 & sha256 hashes.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Also change hash for the license file due to a year change.
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
In addition:
- select python-cryptography as it's now a runtime dependency
- Fix a typo in the help.
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Also change the hash for LICENSE.APACHE due to changing http to https
in the license URL.
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Prior to b3ba26150d
("toolchain/toolchain-external/toolchain-external-custom: be more
flexible on gcc version"), the default gcc version selected by
Buildroot for custom external toolchain was affected by the
BR2_ARCH_NEEDS_GCC_AT_LEAST_xyz definitions.
Since BR2_riscv selects BR2_ARCH_NEEDS_GCC_AT_LEAST_7, gcc 7.x was the
default gcc version assumed to be used in a custom RISC-V external
toolchain, so our config snippets for RISC-V toolchains were correct.
With b3ba26150d applied, the default gcc
version assumed for custom external toolchains is the latest one
(currently gcc 9.x), while our RISC-V toolchains use gcc 7.x. So we
now need to explicitly give the gcc version used by our RISC-V
toolchains, otherwise the build fails with:
Incorrect selection of gcc version: expected 9.x, got 7.4.0
Fixes:
http://autobuild.buildroot.net/results/b872befe1adec2633b9cbcc49bc0eb7619f606c2/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
There is no clean way to check if a program will actually run using
host-qemu, making this check too restrictive.
Add a warning in the help text.
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Starting from 0.21.0 zeroconf uses pure-python ifaddr module
instead of netifaces.
Currently we have zeroconf 0.23.0, so this module raises
ModuleNotFoundError exception during import.
Signed-off-by: Grzegorz Blach <grzegorz@blach.pl>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Enumerates all IP addresses on all network adapters of the system.
https://github.com/pydron/ifaddr
Signed-off-by: Grzegorz Blach <grzegorz@blach.pl>
[Thomas: add license file.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Add documentation about how a br2-external tree can provide an external
toolchain or a libjpeg or openssl alternative implementation.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Vadim Kochan <vadim4j@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Similar to toolchains and jpeg, we now offer a way for br2-external
trees to provide their openssl implementation, which gets included in
the openssl choice.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Vadim Kochan <vadim4j@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Similar to toolchains, we now offer a way for br2-external trees to
provide their libjpeg implementation, which gets included in the jpeg
choice.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Vadim Kochan <vadim4j@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since we have a choice for the pre-configured pre-built toolchains,
there is no possbility for a br2-external to provide its own. The
only solution so far for defconfigs in br2-external trees is to use
BR2_TOOLCHAIN_EXTERNAL_CUSTOM and define all the bits by itself...
This is not so convemient, so offer a way for br2-external trees to
provide such pre-configured toolchains.
To allow for this, we now scan each br2-external tree and look for a
specific file, provides.toolchains.in. We generate a kconfig file that
sources each such file, and that generated file is sourced from within
the toolchain choice, thus making the toolchains from a br2-external
tree possible and available in the same location as the ones known to
Buildroot:
Toolchain --->
Toolchain type (External toolchain) --->
Toolchain --->
(X) Arm ARM 2019.03
( ) Linaro ARM 2018.05
( ) Custom toolchain
*** Toolchains from my-br2-ext-tree: ***
( ) My custom ARM toolchain
*** Toolchains from another-br2-ext-tree: ***
( ) Another custom ARM toolchain
( ) A third custom ARM toolchain
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Vadim Kochan <vadim4j@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently, the kconfig part contains two things: the kconfig option
with the paths to br2-external trees, and the kconfig menus for the
br2-external trees.
When we want to include more kconfig files from the br2-external tree
(e.g. to get definitions for pre-built toolchains), we will need to
have the paths defined earlier, so they can be used from the br2-external
tree to include files earlier than the existing menus.
Split the generated kconfig file in two: one to define the paths, which
gets included early in our main Config.in, and one to actually define
the existing menus, which still gets included at the same place they
currently are.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Vadim Kochan <vadim4j@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
