buildroot, branch 2017.02

Update for 2017.02

2017-02-28T21:00:23+00:00

Signed-off-by: Peter Korsgaard

qt5base: fix VNC platform plugin build on big-endian machines

2017-02-28T21:00:00+00:00

Fixes [1], [2]: In file included from qvncintegration.cpp:38:0: qvncscreen.h:76:22: error: expected ';' at end of member declaration bool swapBytes() const [1] http://autobuild.buildroot.net/results/718/7180ad7d7e78f1c3ce6a1f83a5a8fcc5e0ac03a2 [2] http://autobuild.buildroot.net/results/14f/14f8c436b184192681fb79c7f0c0d0daa35f867b Signed-off-by: Peter Seiderer Signed-off-by: Peter Korsgaard

mpv: disable with ARC external toolchain

2017-02-28T19:59:45+00:00

This package fails when building with ARC external toolchain Marking this with special comment "# ARC toolchain issue" as the package is to be enabled as soon as the issue with the ARC toolchain is resolved. Fixes: http://autobuild.buildroot.net/results/fb6/fb677a917545adee321bdcd2c2519c81326448c4// Signed-off-by: Vlad Zakharov Signed-off-by: Peter Korsgaard

xterm: disable with ARC external toolchain

2017-02-28T19:59:23+00:00

This package fails when building with ARC external toolchain Marking this with special comment "# ARC toolchain issue" as the package is to be enabled as soon as the issue with the ARC toolchain is resolved. Fixes: http://autobuild.buildroot.net/results/28a/28a92049a6ceef005787c5779f77ecf3fe8ad642// Signed-off-by: Vlad Zakharov Signed-off-by: Peter Korsgaard

qt5quickcontrols: fix installation of PrivateWidgets

2017-02-28T14:55:29+00:00

Commit e482ebf51d9e8e00c3e58eb65af0dfb70d05d8cc attempted to fix the installation of qt5quickcontrols by only installing the PrivateWidgets directory for the 5.8.0 version. However, the availability of PrivateWidgets has nothing to do with the version; in both 5.6.2 and 5.8.0, the installation is gated by the following statement in src/src.pro: qtHaveModule(quick):qtHaveModule(widgets): SUBDIRS += widgets i.e. it is installed when both the Quick and the Widgets module are available. The Widgets module is controlled by Buildroot's BR2_PACKAGE_QT5BASE_WIDGETS symbol, the Quick module is controlled by Buildroot's BR2_PACKAGE_QT5DECLARATIVE_QUICK. The qt5quickcontrols package selects BR2_PACKAGE_QT5DECLARATIVE_QUICK so it is not really needed to include it in the condition. However, it is theoretically possible to build this package without QtQuick. Also, adding this condition makes it consistent with src.pro. Note that commit e482ebf51d9e8e00c3e58eb65af0dfb70d05d8cc introduces a second fix (not mentioned in the commit message): for version 5.6.2, the Layouts directory is installed, but in 5.8.0 this directory doesn't exist any more. Therefore, a separate condition on the version is still needed. Fixes: http://autobuild.buildroot.net/results/1ff3e9ad4ba518d0a37f9fc12038bf9020f28094 Cc: Peter Seiderer Signed-off-by: Arnout Vandecappelle (Essensium/Mind) Signed-off-by: Peter Korsgaard

genimage: Fix typo in description

2017-02-28T14:54:18+00:00

Signed-off-by: Marcus Hoffmann Signed-off-by: Peter Korsgaard

classpath: only allow on supported architectures

2017-02-28T09:00:30+00:00

In commit a75ab1fc1dcc7eee8668b1c3c19b703f1390b2cd ("package/classpath: Don't depend on jamvm"), we removed the dependency of classpath on jamvm. Since jamvm is only available for a reduced set of architectures, classpath could until this commit until be built on those architectures. However, now that this dependency has been removed, classpath can potentially be built for all architectures supported by Buildroot, even though it doesn't support all of them. Since adding support for additional architectures in classpath doesn't make much sense, because classpath is in Buildroot only usable with JamVM anyway, and JamVM is only available for a small set of architectures, this commit simply makes classpath available on the architectures that it supports. By doing so, it also removes the or1k support patch which was added by commit f12a146f817c8ef07a7d41a31a5336b5ef6a96e8, since anyway or1k is not supported by JamVM. Fixes: http://autobuild.buildroot.net/results/55eb89f89e96b94a821778bc18ed844af08b7460/ (classpath on microblaze) http://autobuild.buildroot.net/results/279dd731bd9ecf5f9d54bda3715caeaa7cbcdbb3/ (classpath on nios2) Signed-off-by: Thomas Petazzoni Signed-off-by: Peter Korsgaard

openocd: avoid documentation rebuild to fix build issues

2017-02-28T08:51:42+00:00

On PowerPC64(le), we patch all configure scripts. Due to this, the version.texi in OpenOCD files gets regenerated, and then since it has a newer date than openocd.info, openocd build system rebuilds the documentation. Unfortunately, this documentation rebuild fails on old machines. We work around this by faking the date of the generated version.texi file, to make the build system believe the documentation doesn't need to be regenerated. Fixes: http://autobuild.buildroot.net/results/3cbe65a46e75b8e67846d593884c96df97dec7a4 Signed-off-by: Thomas Petazzoni Reviewed-by: Sam Bobroff Signed-off-by: Peter Korsgaard

dependencies/cmake: blacklist cmake 3.7

2017-02-28T08:40:27+00:00

cmake-3.7 has a bug in how it handles rpath, linking with libraries from the host. Until we completely understand the issue, just blacklist cmake-3.7. The issue has been reported upstream: http://public.kitware.com/pipermail/cmake/2017-February/064970.html Reported-by: Baruch Siach Signed-off-by: "Yann E. MORIN" Cc: Jörg Krause Cc: Ben Boeckel Cc: Samuel Martin Signed-off-by: Peter Korsgaard

assimp: fix gcc version condition

2017-02-27T21:53:24+00:00

In commit 68cebedeb977396f64f5f591f5e93f34fab8e0a8 ("assimp: work around gcc bug on SuperH"), a work around was added to make the package build with gcc on SuperH. The condition included a test on the gcc version, which was mistakenly done on the host gcc version, while a test on the target gcc version was intended. Thanks to Peter Korsgaard for spotting the issue. Signed-off-by: Thomas Petazzoni