The fallback code path didn't work correctly, so fix it.
Fixes:
http://autobuild.buildroot.net/results/3122287ddea1e316a64ccf0d0dc9415bfefebb49/
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The LTO support in the kmsxx package uses the host gcc-ar and gcc-ranlib
instead of the ones from the cross-toolchain. Add a patch that tries to
find the right one based on CMAKE_C_COMPILER.
Fixes:
http://autobuild.buildroot.net/results/16a/16a38a4277dd1152a5955d62cb92f85447791ef3
Possibly also fixes:
http://autobuild.buildroot.net/results/f3c/f3c48da3a9706cd366c0e0a96c3cd0ff959f2a78
(it fails later, possibly because an incompatible host ar)
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Samuel Martin <s.martin49@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Grab the patch from Debian.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The pixman ARM optimized code assumes that ARM instructions are
available. Unfortunately, the configure.ac checks do not detect that the
platform is Thumb-only for Cortex-M builds, so it enables the ARM
optimizations, leading to failures like:
error: /home/test/autobuild/run/instance-3/output/host/usr/arm-buildroot-uclinux-uclibcgnueabi/sysroot/usr/lib/libpixman-1.a(pixman-arm-simd-asm-scaled.o): Conflicting CPU architectures 13/1
When building programs linked with pixman on Thumb-only
architectures. This is due to the fact that some object files in
libpixman-1.a are built for the ARM instruction set.
To resolve this, we give better hints to the pixman configure script
about which ARM optimizations to use: the ARM SIMD optimizations need at
least a CPU that supports ARM instructions, and obviously the ARM NEON
optimizations need NEON support.
Fixes:
http://autobuild.buildroot.net/results/54bee2ce382fcd067965d30f758f9d15514478d9/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
[Thomas: add a comment above the --enable-arm-simd option, as suggested
by Arnout.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Instead of bumping vlc to git master (no vlc 3.x release yet) we use a
patch from deb-multimedia.org which provides the necessary changes for
ffmpeg 3.x support to vlc 2.2, compile-tested using this defconfig:
BR2_TOOLCHAIN_BUILDROOT_WCHAR=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_PACKAGE_FFMPEG=y
BR2_PACKAGE_FFMPEG_GPL=y
BR2_PACKAGE_FFMPEG_POSTPROC=y
BR2_PACKAGE_FFMPEG_SWSCALE=y
BR2_PACKAGE_VLC=y
This patch can be removed when vlc is bumped to 3.x.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
ffmpeg only needs the imgproc module of opencv:
15708f1347
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
ffmpeg 3 fixed support for mips64r2 and mips64r6, for details see
http://patchwork.ozlabs.org/patch/626756/
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This option is needed to prevent this message from configure:
WARNING: unknown CPU. Disabling all MIPS optimizations.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
[Thomas:
- group with the other --cpu conditions so that only one is passed.
- improve the comment.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
With a small patch, blktrace can work on uClibc: we simply need to link
with librt to use the posix_spawn*() functions.
[Thomas: add reference to upstream commit.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
As recently discussed on lwn.net: https://lwn.net/Articles/695478/
The kernel has special behaviour for uid/gid 65534:
1. The kernel maps UIDs > 65535 to it when some subsystem/API/fs
only supports 16bit UIDs, but a 32bit UID is passed to it.
2. it's used by the kernel's user namespacing as the internal UID
that external UIDs are mapped to that don't have any local mapping.
3. It's used by NFS for all user IDs that cannot be mapped locally if
UID mapping is enabled.
Most distributions already map (or are in the progress of changing)
nobody/nogroup to the 65534 uid/gid, so lets do so as well.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fixes a number of buffer overflows / use-after-free issues:
http://git.imagemagick.org/repos/ImageMagick/blob/master/ChangeLog
* Prevent buffer overflow in BMP & SGI coders (bug report from
pwchen&rayzhong of tencent).
* Prevent buffer overflow and other problems in SIXEL, PDB, MAP, TIFF and
CALS coders (bug report from Donghai Zhu).
* Prevent buffer overflow (bug report from Max Thrane).
* Prevent memory use after free (reference
https://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=30245).
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
As pointed out in bug #9161, we don't always have an inittab file (if
systemd or no init is used), so the post build script should only try to
tweak it if present.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
As pointed out in bug #9161, we don't always have an inittab file (if
systemd or no init is used), so the post build script should only try to
tweak it if present.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The default boa.conf we install specifies that boa should run under the
nobody group, but we don't have such a group in our default skeleton (and
boa doesn't add it), causing boa to fail to start:
[01/Jan/1970:00:00:10 +0000] No such group: nobody
Instead use the nogroup group, which is presumably what was meant.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
configure.ac has AM_GNU_GETTEXT(), which will enable i18n if a gettext
library is found. For uClibc, it is found if the gettext package has
been built, and it will add -lintl to the link flags. For musl and
glibc, it is always found, in libc itself so nothing is added to the
link flags.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Matthew Weber <matt@thewebers.ws>
Tested-by: Matthew Weber <matt@thewebers.ws>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The source files in the domoticz tarballs have DOS line endings, which
don't appear when fetching the source code from Git. Therefore, a patch
generated from the Git repository doesn't apply directly on the source
code extracted from the tarball.
This commit fixes the patch so that it applies cleanly to the
tarball. Notice that the CMakeLists.txt file is not affected, only the
domoticz.cpp file uses DOS line endings.
While we're at it, we change the patch title prefix from [PATCH 1/1] to
just [PATCH].
Fixes:
http://autobuild.buildroot.net/results/a0539b3551d482411dd4bcd5c9b8c89f77e68475/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Bump runc to cc29e3dded8e27ba8f65738f40d251c885030a28
This version is required by Docker Engine v1.12.0.
Signed-off-by: Christian Stewart <christian@paral.in>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 6ad14a3687)
Bump docker-engine to the latest stable v1.12.0 from v1.12.0-rc3.
Signed-off-by: Christian Stewart <christian@paral.in>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit f892015d78)
domoticz.cpp currently assumes that on GNU/Linux systems header
<execinfo.h> is available. But that is not true. Since it provided by
C library and uClibc can be built without backtrace support. And in
such cases we get following build error.
domoticz-3.4834/main/domoticz.cpp:48:22: fatal error: execinfo.h: No such file or directory
#include <execinfo.h>
^
compilation terminated.
This commit adds patch for detecting presence of <execinfo.h>
and guards code accordingly.
Fixes:
http://autobuild.buildroot.net/results/393/393f839e160b51ca12ac36058718ad2f0c1b50a6/
Signed-off-by: Rahul Bedarkar <rahul.bedarkar@imgtec.com>
Reviewed-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When commit 031130a4 added the dependency on shared libs for FIT support
in uboot-tools, the dependency of the comment was added exactly as the
dependency of the symbol.
That means the comment is shown when FIT support is possible, and hidden
when it is not, while we want it the other way around...
Fix the dependency.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The reproducible build is only in its infancy; it is far from being
complete.
As such, move it to the "advanced" build sub-menu, where it belong for
now...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
libbsd installs at least one .pc file that contains a -isystem include
path (-isystem /usr.include/bsd), but -isystem is not munged by
pkg-config, so we end up using /usr/include/bsd which is not suitable
for the target. And breaks big time (see failures, below).
But using libbsd is completely optional. In fact, our lldpd.mk did not
even express the dependency on libbsd, so we may well have had builds
without libbsd.
The functionality brought in by using libbsd is very minor (just setting
the neighbour name in /proc/self/cmdline), so we just make lldpd not use
libbsd at all. There is no --disable-libbsd or such, so we just patch it
out of configure.ac.
Fixes:
http://autobuild.buildroot.org/results/6b7/6b70fa379e834ec71cc260ba6af771b531ca3511/http://autobuild.buildroot.org/results/769/769074c4bb67336ae6679f2c1cd2a8220d2bec24/http://autobuild.buildroot.org/results/c8a/c8a6001f437701ecc75f6c9252935645bda8a8c8/
[...]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since commit ae0e895054 (nfacct: bump to version 1.0.2, 2016-08-23) we no
longer patch configure.ac.
Cc: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since commit b8d446cd56 (libnetfilter_acct: bump to version 1.0.3,
2016-08-23) we no longer patch configure.ac.
Cc: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The current amd-catalyst options related to the CCCLE tool create the
following Config.in circular dependency:
package/qt/Config.in:134:error: recursive dependency detected!
package/qt/Config.in:134: symbol BR2_PACKAGE_QT_GUI_MODULE is selected by BR2_PACKAGE_AMD_CATALYST_CCCLE
package/amd-catalyst/Config.in:52: symbol BR2_PACKAGE_AMD_CATALYST_CCCLE depends on BR2_PACKAGE_QT_NOPNG
package/qt/Config.in:277: symbol BR2_PACKAGE_QT_NOPNG is part of choice <choice>
package/qt/Config.in:271: choice <choice> contains symbol <choice>
package/qt/Config.in:271: choice <choice> contains symbol BR2_PACKAGE_QT_GUI_MODULE
But in fact, it turns out that selecting BR2_PACKAGE_QT_GUI_MODULE is
not necessary, since we already "depends on BR2_PACKAGE_QT_X11", which
itself selects BR2_PACKAGE_QT_GUI_MODULE. Therefore, to fix this problem
we simply remove the "select BR2_PACKAGE_QT_GUI_MODULE" from the
BR2_PACKAGE_AMD_CATALYST_CCCLE option.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Currently, libgtk3 depends on either a full OpenGL stack, or on a
OpenGL-EGL stack provided by mesa3d.
This is because, when using the wayland backend, libgtk3 needs an
OpenGL-EGL stack tht provides the wayland extensions. So far, only
mesa3d would provide those extensions.
But now, those extensions are trickling down to other implementations,
like the Nvidia driver or other (even non-public) implementations.
Change the condition to be on the recently introduced libegl-wayland
option.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
mesa3d implements the EGL extensions for wayland. State so.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Wayland requires that an OpenGL/EGL implementation provides a few
extensions, so that wayland servers and clients can exchange buffers.
Currently, only one OpenGL/EGL implementation provides those extensions:
mesa3d.
However, other implementations are catching up, especially the
proprietary NVidia driver, which has as of late introduced those
extensions. Other, non-public implementations may also provide those
extensions.
A lot of wayland-related packages require those extensions, and
currently they have to depend on mesa3d to provide OpenGL/EGL, which
precludes using those packages when a non-mesa3d provider is enabled,
even when that providers implements the necessary extensions.
Add an option to the libegl virtual package, that providers on
OpenGL/EGL can select to state they provide those extensions.
Packages that need those extensions can additionally depend on this new
option, instead of the existing libegl package.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The AMD Catalyst Linux driver includes OpenCL libraries for GPGPU
computing. This commits adds support to install the binary blobs and ICD
profiles.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The AMD Catalyst Linux driver includes a graphical controler center for AMD
graphics accelerators, called Catalyst Controler Center. This commits
adds support to install this tool by adding a separated prompt.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
[Thomas:
- As noticed by Yann, fixed the dependency of the comment related to
the Qt PNG functionality.
- Also add the Qt PNG dependency to the BR2_PACKAGE_AMD_CATALYST_CCCLE
option itself, noticed by Yann.
- Add an empty line, also noticed by Yann.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The AMD Catalyst driver includes some command line tools for displaying
specific infos about the GL stack or to test 3D, like fglxinfo or
fgl_gears. This commit adds support to install such tools.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
