--disable-scanner was removed back in 2015, so drop it.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This fixes a qemu-user compile error.
Reported-by: François Perrad <francois.perrad@gadz.org>
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 cosmo package has been removed in commit
2c84388663, but the entry in the
DEVELOPERS file was forgotten.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This commit provides basic support for the C-SKY architecture.
Signed-off-by: Guo Ren <ren_guo@c-sky.com>
[Thomas: minor tweaks.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The LINES variable is automatically set by bash to represent the number
of lines in the terminal. That variable can be set when the shell
receives SIGWINCH.
If the shell does receive SIGWINCH after our LINES array is filled, the
content of the array is mangled.
Rename the variable to avoid that.
Fixes#9456
Reported-by: George Y. <georgebrmz@oss3d.com>
Reported-by: Paul Stewart <paulstewartis@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
gdk-pixbuf-loader support is enabled by default but it silently fail to
generate gdk-pixbuf.loaders file when host != target.
For exemple on ARM target:
output/host/usr/bin/gdk-pixbuf-query-loaders ./libpixbufloader-svg.la
g_module_open() failed for output/build/librsvg-2.40.16/gdk-pixbuf-loader/./libpixbufloader-svg.la: output/build/librsvg-2.40.16/gdk-pixbuf-loader/./.libs/libpixbufloader-svg.so: wrong ELF class: ELFCLASS32
But it doesn't break the build.
When host = target using the Sourcery CodeBench AMD64 2016.11 toolchain
optimized for x86_68 AMD Puma/Jaguar or AMD Steamroller, it break the
build due to "Illegal instruction".
output/host/usr/bin/gdk-pixbuf-query-loaders libpixbufloader-svg.la
Illegal instruction (core dumped)
Since this option is broken for cross-compilation, disable it.
Fixes:
http://autobuild.buildroot.net/results/393/393145bc9bcb93d6df55ec8c63725c3d9a299957
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This reverts commit aca82a056b, which is
needed to revert commit 98c9b1bec6,
which itself causes build failures.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The bump of python-enum to version 0.4.6 in commit
636df89872 forgot to update the license
information. Even though the PKG-INFO file still pretends it's GPLv2
or Python license, the only license file available is LICENSE.GPL-3
(which indicates a GPLv3 license), and the comment header in the
source code is pretty clear:
This is free software: you may copy, modify, and/or distribute
this work under the terms of the GNU General Public License as
published by the Free Software Foundation; version 3 of that
license or any later version. No warranty expressed or
implied. See the file ‘LICENSE.GPL-3’ for details.
Fixes:
http://autobuild.buildroot.net/results/7fec1c7cde710f523263e74b1849f1f4488b7d26/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Bump U-Boot to 2017.01 version and kernel to 4.9.13.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This is a runtime dependency of docker-engine in version 17.03.0-ce
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This is a runtime dependency of docker-engine in version 17.03.0-ce
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The bump causes build failure with musl, this new version uses with
undefined REG_STARTEND which is a glibc-ism that isn't available for
musl-based toolchains.
The introduction of this is to address
https://savannah.gnu.org/bugs/?50030 so it's not quite straightforward
to fix.
This reverts commit d003554343.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The original google code link redirects to the libyuv bug tracker. Use libyuv
git repo as a better sort of a homepage.
Cc: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since we now require Lua package names to start with "lua", it is likely
that the Buildroot name is different from the upstream LuaRocks name.
Add a feature to the luarocks-package infra that makes it easier to
handle this situation: the package can explicitly specify the upstream
name in PKG_NAME_UPSTREAM, and that name will be used in PKG_ROCKSPEC,
PKG_SOURCE and PKG_SUBDIR.
Add an explanation of this feature to the manual. To make the example
relevant, it is changed to lua-foo, where the upstream name is plain
foo. To avoid confusion with the dependency on a native library, that
dependency is renamed to bar.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
With the reworked luarocks extraction, they are no longer needed.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The luarocks package infra extracts the package directly under
$(BUILD_DIR), because the contents are always in a subdirectory name
<pkg>-<version>. However, this only works when the upstream package name
is the same as the Buildroot package name.
Instead, we can rely on the fixed structure of a .src.rock: it always
contains the source subdirectory in a directory called foo, where foo
is the basename of the .src.rock file. Therefore, we can extract into
a subdirectory of $($(PKG)_DIR), then move its contents up two
directory levels.
Note, we can't extract directly into $($(PKG)_DIR) because it's
possible that $($(PKG)_SUBDIR) == <pkg>-<version>. In that case, we
would try to move the directory unto itself and get "Directory not
empty". This is the case e.g. for the lpty package.
Two alternatives were considered but are more complicated:
- instead of using wildcards for the move, we could have used
<.src.rock basename>/$($(PKG)_SUBDIR);
- instead of extracting with luarocks, we could use unzip to extract
(the .src.rock is a ZIP file), but then we also have to move the
.rockspec into the subdir. In addition, sometimes the ZIP file
contains a tarball instead of the extracted source.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since the bump of luaposix to 33.4.0, it doesn't work anymore at
runtime with LuaJIT or Lua 5.1. This can be tested with the following
defconfig:
BR2_x86_64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_PACKAGE_LUA=y
BR2_PACKAGE_LUA_5_1=y
BR2_PACKAGE_LUAPOSIX=y
/usr/bin/lua: /usr/share/lua/5.1/posix/init.lua:17: module 'bit32' not found:
...
In older luaposix versions, it would try to load the 'bit' instead of
'bit32' module if LUAVER == 5.1. However, this feature was removed in
33.4.0.
So instead of adding a runtime dependency on luabitop, depend on
lua-bit32.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
