U-Boot 2016.07 works well on warpboard, so bump to this version.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The defconfig file for at91bootstrap was false:
s/sama5d4_xplainedsnf_uboot_secure/sama5d4_xplainednf_uboot_secure.
Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
According to https://matt.ucc.asn.au/dropbear/CHANGES there were some
severe security issues fixed.
Signed-off-by: Alexander Dahl <post@lespocky.de>
Acked-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
In the gamin package, patch
0003-fix-missing-PTHREAD_MUTEX_RECURSIVE_NP.patch was introduced to fix
the build with musl. Indeed, while musl defines "linux", it does not
define PTHREAD_MUTEX_RECURSIVE_NP, but only PTHREAD_MUTEX_RECURSIVE. So
the check was simplified to only verify if PTHREAD_MUTEX_RECURSIVE_NP is
defined.
However, this doesn't work well with uClibc linuxthreads. In uClibc,
PTHREAD_MUTEX_RECURSIVE_NP and PTHREAD_MUTEX_RECURSIVE are not
pre-processor defines, but enum values. For this reason, even if
PTHREAD_MUTEX_RECURSIVE_NP actually exists, #if
defined(PTHREAD_MUTEX_RECURSIVE_NP) is false. So, the gamin code falls
back to using PTHREAD_MUTEX_RECURSIVE.
Except that for uClibc linuxthreads, PTHREAD_MUTEX_RECURSIVE is defined
only if __USE_UNIX98 is defined. For the NPTL implementation,
PTHREAD_MUTEX_RECURSIVE is defined either if __USE_UNIX98 or
__USE_XOPEN2K8 are defined. This strange difference has been reported to
uClibc-ng upstream [1].
However, regardless of this uClibc behavior, using #if defined to check
for the availability of PTHREAD_MUTEX_RECURSIVE_NP is not good. This
commit therefore switches to using a proper AC_CHECK_DECL() autoconf
test, which works regardless of whether the value is #define'd or
defined as an enum value.
This fixes the build of gamin on linuxthreads platforms, such as
Microblaze or m68k.
Fixes:
http://autobuild.buildroot.net/results/887df97196d7777efbf18a7bee91aa45c1a98700/ (Microblaze)
http://autobuild.buildroot.net/results/eb4389474e1b30b5c395a07a857da13a66763bdb/ (m68k)
[1] http://mailman.uclibc-ng.org/pipermail/devel/2016-July/001087.html
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When efl package is build with Eolian support, eolian_cxx tool is
build for the host.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The efl package has zlib in its dependencies, but does not select it,
which causes a dependency check error with the following defconfig:
BR2_arm=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y
BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y
BR2_TOOLCHAIN_EXTERNAL_URL="http://autobuild.buildroot.org/toolchains/tarballs/br-arm-full-2016.05-1162-g94c7298.tar.bz2"
BR2_TOOLCHAIN_EXTERNAL_GCC_4_8=y
BR2_TOOLCHAIN_EXTERNAL_HEADERS_3_10=y
BR2_TOOLCHAIN_EXTERNAL_LOCALE=y
BR2_TOOLCHAIN_EXTERNAL_INET_RPC=y
BR2_TOOLCHAIN_EXTERNAL_CXX=y
BR2_INIT_NONE=y
BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV=y
BR2_SYSTEM_BIN_SH_NONE=y
BR2_PACKAGE_EFL=y
This commit fixes this by selecting the zlib package at the Config.in
level.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Eolian languages bindings needs C++11, so we needs at least a gcc 4.8
for the host and target variant.
The C++11 support with gcc 4.7 is not sufficient.
Build eolian_cxx for the host only if Eolian support for the target is
selected.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
[Thomas: fix misc typos.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
AllJoyn Base Services are common services used by many devices,
providing a set of interfaces for different devices to interact and
interoperate with one another.
Thin Client Library is designed to bring the benefits of the AllJoyn
distributed programming environment to embedded systems.
https://allseenalliance.org
Signed-off-by: Fabrice Fontaine <fabrice.fontaine@orange.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The AllJoyn framework defines a common way for devices and apps to
communicate with one another regardless of brands, categories,
transports, and OSes. Developers write applications that discover
nearby devices, and communicate with each other directly and through
the cloud, unleashing new possibilities in the Internet of Things.
AllJoyn Thin Core Library (AJTCL) is designed to bring the benefits
of the AllJoyn distributed programming environment to embedded
systems.
https://allseenalliance.org
Signed-off-by: Fabrice Fontaine <fabrice.fontaine@orange.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
AllJoyn Base Services are common services used by many devices,
providing a set of interfaces for different devices to interact and
interoperate with one another.
https://allseenalliance.org
Signed-off-by: Fabrice Fontaine <fabrice.fontaine@orange.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
[Thomas:
- Add dependency on BR2_TOOLCHAIN_HAS_SYNC_4, inherited from the
alljoyn package.
- select BR2_PACKAGE_ALLJOYN_BASE_CONTROLPANEL when neither
BR2_PACKAGE_ALLJOYN_BASE_NOTIFICATION nor
BR2_PACKAGE_ALLJOYN_BASE_ONBOARDING are selected. This ensures that
the package will at least build and install one thing.
- rename the Config.in option prompts from "alljoyn-<foo>" to just
"<foo>"
- rework the build command to use a loop rather than duplicate code
- rework the install command to also use a loop, and to not discard
errors.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The TS-4800 is supported by mainline Linux as of 4.5 and by U-boot
as of v2016-07.
The package requires the custom ts4800-mbrboot routine.
A post-image script is provided to generate an image that can be
directly written to an SD card.
More details on the board here:
http://wiki.embeddedarm.com/wiki/TS-4800
Signed-off-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
Signed-off-by: Patrick Keroulas <patrick.keroulas@savoirfairelinux.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fixes:
http://autobuild.buildroot.net/results/64b1bde02346ca67b670f0b095bd3acad707e8cd
Signed-off-by: Bimal Jacob <bimal.jacob@rockwellcollins.com>
Signed-off-by: Matt Weber <matthew.weber@rockwellcollins.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
[Thomas: use depends on rather than select.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We expect the custom skeleton to be fully filled with the necessary
files, now. There is definitely no reason we should handle setting the
hostname and the issue file in there. A user using a custom skeleton
should be fully responsible for providing a functional skeleton.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We expect the custom skeleton to be fully filled with the necessary
files, now. There is definitely no reason we should handle network
settings in there. A user using a custom skeleton should be fully
responsible for providing a functional skeleton.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
In the following commits, we'll be switching more options to be
conditional on the default or custom skeleton.
So, it makes sense that those options come after the choice of a
skeleton.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Being custom means that our default one is not suitable to start with.
So there is no reason to offer it as the default path.
Add a check that it is not empty.
Add a separating empty line, for good measure, too.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Romain Naour <romain.naour@openwide.fr>
Cc: Arnout Vandecappelle <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
BR2_PACKAGE_BUSYBOX_SHOW_OTHERS is a bit special. When Busybox is
enabled, it is a Busybox option. When Busybox is not enabled, it is a
stand-alone option, forcibly enabled.
So we can safely 'select' it without ensuring (via a 'depends on' or
another 'select') that Busybox is enabled.
However, the name of this option does not express the fact that it is
safe to select it without checking Busybox, which can lead to a bit of
time-consuming head-scratching.
To avoid future puzzlement from an unsuspecting observer, add a a big
fat comment that this option can be selected without any dependency on
Busybox.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Romain Naour <romain.naour@openwide.fr>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
[Thomas: slightly improve the wording of one of the comment.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
fcgiwrap was not updated since April 2015, but the last GitHub release
is from February 2013. Therefore, bump fcgiwrap to the latest commit
as it features fixes and improvements, but is unlikely to be part of a
release soon.
Update as well:
* the license file (latest commit features a COPYING file),
* the Config.in URL, as the previous "official" URL now returns an
HTTP 502 error.
Signed-off-by: Thomas Claveirole <thomas.claveirole@green-communications.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The removal of the unconditional compilation and linking of some .o files were
missed when porting the patch 0003 to the version 2016.07, leading to errors
like these when FIT support is enabled:
tools/fit_common.o: In function `fit_verify_header':
fit_common.c:(.text+0x0): multiple definition of `fit_verify_header'
tools/fit_common.o:fit_common.c:(.text+0x0): first defined here
tools/fit_common.o: In function `fit_check_image_types':
fit_common.c:(.text+0x10): multiple definition of `fit_check_image_types'
When FIT support is disabled, the build does not fail but it includes FIT
support.
Fix the patch 0003 to be equivalent to the original one.
Fixes:
http://autobuild.buildroot.net/results/7494a5b22e3df1c05cdcc47670deaf54d9e04133http://autobuild.buildroot.net/results/f98f30bbf9d4cdde37a96b9310873d83dd649c54
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
CC: Fabio Estevam <festevam@gmail.com>
CC: Carlos Santos <casantos@datacom.ind.br>
Tested-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
- Remove patch
0001-Add-configure-option-to-disable-documentation.patch as this is
now include in the new version.
- Add dependency on gettext when needed, since it uses libintl if
gettext functionality is not provided by the C library.
- Keep autoreconf/gettextize, which are needed for the link against
libintl to work properly.
Signed-off-by: Roland Franke <fli4l@franke-prem.de>
[Thomas:
- add dependency on gettext when needed
- add comment about why autoreconf/gettextize are kept
- cleanup commit log.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fixes following autobuild failure:
http://autobuild.buildroot.net/results/162db0d62075a16c7abae1229676e2cdb29fe953/
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
[Thomas: as noticed yb Romain, propagate the new dependency to the
Config.in comment.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Some of the serial port highest speed are not defined on
sparc/sparc64, so alljoyn should not use them. This commit adds a
patch to fix that.
Inspired by commit c5e96d8935.
Fixes:
http://autobuild.buildroot.net/results/e5b30b5e0d86b44b97410d434b771e1fb7b18de0
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
In a Buildroot configuration with mysql enabled it might be useful to
be able to build Kodi without mysql support because Kodi may not need
it at runtime.
Kodi can store its internal databases not only locally using sqlite
but also on a mysql server, this allows several local Kodi machines to
share the same databases. When using only one Kodi instance, mysql
support is not needed, and not building mysql support helps reducing
build time.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
[Thomas: drop select of libX11 and libXext, since the libvdpau package
already selects them.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Most of the times this is not needed because libdrm & mesa3d already
pull in the dependency to udev. Let's add it anyway to make sure that
udev is really used and to document that Kodi makes use of udev.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
