Reiterate once more that <packagename>_PATCH variable can point
to an arbitrary URL, not just to a path relative to <packagename>_SITE.
While we're at it, also explain that the patch should be added to the
.hash file.
Signed-off-by: Alexander Mukhin <alexander.i.mukhin@gmail.com>
[Arnout: add sentence about .hash file.]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
configure.ac use PKG_CHECK_MODULES macro to find some libraries dependencies.
So add host-pkgconf in LVM2_DEPENDENCIES.
Fixes:
checking pkg-config is at least version 0.9.0... ./configure: line 9875: [...]/host/bin/pkg-config: No such file or directory
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Fix libglu build error
CXXLD libGLU.la
/home/buildroot/br4/output/host/lib/gcc/i586-buildroot-linux-gnu/6.4.0/../../../../i586-buildroot-linux-gnu/bin/ld: cannot find -lXext
/home/buildroot/br4/output/host/lib/gcc/i586-buildroot-linux-gnu/6.4.0/../../../../i586-buildroot-linux-gnu/bin/ld: cannot find -lX11
collect2: error: ld returned 1 exit status
using this defconfig
BR2_TOOLCHAIN_BUILDROOT_GLIBC=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_PACKAGE_XORG7=y
BR2_PACKAGE_XSERVER_XORG_SERVER=y
BR2_PACKAGE_NVIDIA_DRIVER=y
BR2_PACKAGE_LIBGLU=y
The nvidia binary blob is linked to libX11.so & libEext.so
$ output/host/bin/i586-buildroot-linux-gnu-readelf -a output/target/usr/lib/libGL.so | grep NEEDED
0x00000001 (NEEDED) Shared library: [libnvidia-tls.so.381.09]
0x00000001 (NEEDED) Shared library: [libnvidia-glcore.so.381.09]
0x00000001 (NEEDED) Shared library: [libX11.so.6]
0x00000001 (NEEDED) Shared library: [libXext.so.6]
0x00000001 (NEEDED) Shared library: [libc.so.6]
0x00000001 (NEEDED) Shared library: [libdl.so.2]
which is also reflected by Libs-section of package/nvidia-driver/gl.pc.
To allow other packages linking to libGL.so provided by this package we
need to reflect the fact that xlib_libX11 & xlib_libXext are not
runtime-only dependencies.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Fix build error
>>> libglu 9.0.0 Autoreconfiguring
configure.ac:50: error: Could not locate the pkg-config autoconf macros.
These are usually located in /usr/share/aclocal/pkg.m4. If your macros
are in a different location, try setting the environment variable
ACLOCAL="aclocal -I/other/macro/dir" before running autoreconf.
configure.ac:50: the top level
autom4te: /home/buildroot/br4/output/host/bin/m4 failed with exit status: 1
using this defconfig
BR2_TOOLCHAIN_BUILDROOT_GLIBC=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_PACKAGE_XORG7=y
BR2_PACKAGE_XSERVER_XORG_SERVER=y
BR2_PACKAGE_NVIDIA_DRIVER=y
BR2_PACKAGE_LIBGLU=y
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Version 2.18.x includes support for remotely controlling WebKitGTK+
based browsers using the standard WebDriver API. Typically this is used
by Web developers, and in most cases it will be desirable to disable it
from builds.
Signed-off-by: Adrian Perez de Castro <aperez@igalia.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Release notes:
https://webkitgtk.org/2017/09/11/webkitgtk2.18.0-released.html
No corresponding WebKit Security Advisory (WSA) has been published.
All patches have been applied upstream.
This also bumps the required target GCC version, due to the WebKit code
now using more modern C++ features which were introduced in version
5.x of the compiler.
Signed-off-by: Adrian Perez de Castro <aperez@igalia.com>
[Arnout:
- propagate dependency to midori;
- mention in commit message why patches were removed.]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
While currently there is no in-tree Buildroot package which depends on
host-python-six, it can be needed to build external packages.
Signed-off-by: Julien Floret <julien.floret@6wind.com>
Tested-by: Carlos Santos <casantos@datacom.ind.br>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Switched to bz2 tarball, upstream does not provide a gz tarball anymore.
Rebased 0001-slsh-libs.patch according to
https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-libs/slang/files/slang-2.3.1-slsh-libs.patch
Removed patches applied upstream:
0002-Enable-a-statically-linked-version-of-slsh.patch
0003-Disable-module-support-in-the-statically-linked-version-of-slsh.patch
0005-make-install-static-do-install-pkgconfig-as-install-.patch
Removed 0004-Rename-posix_close-function-to-posix_close_slfile.patch
after upstream committed a different solution, Alpine Linux did the
same when bumping to 2.3.1:
https://git.alpinelinux.org/cgit/aports/commit/main/slang?id=d4d252e4dea77c868259b0ef1f3d9cfbe6dc2152
Added sha256 hash and license file hash.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
[Arnout: Added sha256 hash and license file hash.]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Currently it is always required to add package version as an argument to
the github helper. Since the version is always defined as PKG_VERSION,
drop this argument and generate it automatically inside the helper
routine.
The github helper function is extended to support both 2 and 3 argument
variants (ie. either use the provided package version argument or
automatically substitute with PKG_VERSION if not available), which can
make the transition of the package files easier as well allows using the
3-argument variant outside of package definitions.
Signed-off-by: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
mbedtls provided libraries are interdependent. libmbedtls depends on
libmbedx509. Both depend on libmbedcrypto. When compression is enabled
libz is also needed.
Fixes:
http://autobuild.buildroot.net/results/79d/79d9aff5edb6a767c38efb54256a4f20fc36a6ee/
Cc: Jörg Krause <joerg.krause@embedded.rocks>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
The author of lbase64 maintains 3 separate versions of the package for
the 3 Lua versions. Only the 5.1 version is uploaded to luarocks, so
that is the one we currently support in Buildroot.
However, the three versions are nearly identical. With a small patch,
this allows us to support all Lua versions from a single tarball.
Signed-off-by: Francois Perrad <francois.perrad@gadz.org>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Add upstream patch to fix build against openjpeg 2.2.
Fixes [1]:
gstopenjpeg.h:42:37: fatal error: openjpeg-2.1/openjpeg.h: No such file or directory
[1] http://autobuild.buildroot.net/results/90f1f7838f08e3a557be27470406d4d84dbcc828
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This patch is based on works [1] and [2].
With this patch, one can run the Qt5 WebEngine quicknanobrowser sample
with the following options.
BR2_TOOLCHAIN_BUILDROOT_LIBC="glibc" and
BR2_TOOLCHAIN_BUILDROOT_CXX (Qt 5 needs a toolchain w/ wchar, NPTL, C++,
dynamic library; for now it builds only with glibc)
BR2_PACKAGE_LIBERATION (Qt needs at least one font)
BR2_PACKAGE_QT5BASE_EXAMPLES (to install quicknanobrowser sample)
BR2_PACKAGE_QT5BASE_GIF (do display gif)
BR2_PACKAGE_QT5BASE_JPEG (do display jpeg)
BR2_PACKAGE_QT5BASE_PNG (do display png)
BR2_PACKAGE_QT5QUICKCONTROLS (needed by webengine)
BR2_PACKAGE_QT5QUICKCONTROLS2 (needed by webengine)
BR2_PACKAGE_QT5WEBENGINE (because it is what we want)
Qt WebEngine requires an Open(E)GL-capable backend. As an example, the
package rpi-userland must be enabled to build for a rpi.
BR2_PACKAGE_RPI_USERLAND (to enable OpenGL ES backend)
To browse for HTTPS websites, please consider adding the following
options as well for SSL/TLS.
BR2_PACKAGE_CA_CERT (for certificates)
BR2_PACKAGE_NTPD (to sync date for certificates)
Since version 5.9, chromium requires udev at runtime (see note 4).
BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV (input backend)
To run quicknanobrowser
# cd /usr/lib/qt/examples/webengine/quicknanobrowser/
# ./quicknanobrowser https://www.buildroot.org/
Note: The chromium.inc has been generated using the following command.
( echo 'CHROMIUM_LICENSE_FILES = \' &&
cd output/build/qt5webengine-5.9.1/ && \
find "src/3rdparty/chromium/" -type f -iname "*LICENSE*" -o -iname "*COPYING*" -o -iname "*GPL*" | \
sed -e '/\.asm$/d' \
-e '/\.h$/d' \
-e '/\.c$/d' \
-e '/\.cc$/d' \
-e '/\.cpp$/d' \
-e '/\.pyc\?$/d' \
-e '/\.pl$/d' \
-e '/\.sha1$/d' \
-e '/\.patch$/d' \
-e '/licensecheck/d' \
-e 's,^,\t,' \
-e 's,$, \\,' | \
sort && \
echo '' ) >package/qt5/qt5webengine/chromium.inc
Note 2: Since 5.9.1, the chromium's copy of opus fails with neon [3].
Qt WebEngine can uses buildroot ffmpeg copy which compiles fine (using
qmake flag WEBENGINE_CONFIG+=use_system_ffmpeg). It implies selecting
the following options.
BR2_PACKAGE_FFMPEG
BR2_PACKAGE_OPUS
BR2_PACKAGE_LIBVPX
BR2_PACKAGE_WEBP
BR2_PACKAGE_WEBP_DEMUX
In file included from ../../3rdparty/chromium/third_party/opus/src/silk/arm/NSQ_neon.c:31:0:
/home/gportay/src/buildroot/output-rpi3-qt5.9/host/lib/gcc/arm-buildroot-linux-gnueabihf/6.4.0/include/arm_neon.h:8997:1: error: inlining failed in call to always_inline ‘vld1q_s32’: target specific option mismatch
vld1q_s32 (const int32_t * __a)
^~~~~~~~~
../../3rdparty/chromium/third_party/opus/src/silk/arm/NSQ_neon.c:40:15: note: called from here
int32x4_t coef0 = vld1q_s32(coef32);
^~~~~
../../3rdparty/chromium/third_party/opus/src/silk/arm/NSQ_neon.c: At top level:
cc1: warning: unrecognized command line option ‘-Wno-#pragma-messages’
Note 3: Version 5.6.2 causes a build issue while building chromium. The
build against this version is disabled until the release 5.6.3 is out.
Note 4: Here is trace when udev does not run
# cd /usr/lib/qt/examples/webengine/quicknanobrowser
# ./quicknanobrowser
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
Unable to query physical screen size, defaulting to 100 dpi.
To override, set QT_QPA_EGLFS_PHYSICAL_WIDTH and QT_QPA_EGLFS_PHYSICAL_HEIGHT (in millimeters).
[0101/000248.161973:WARNING:resource_bundle_qt.cpp(114)] locale_file_path.empty() for locale
[0101/000248.384693:WARNING:resource_bundle_qt.cpp(114)] locale_file_path.empty() for locale
[202:223:0101/000248.484954:FATAL:udev_loader.cc(38)] Check failed: false.
#0 0x0000742b93de <unknown>
#1 0x0000742c3c38 <unknown>
#2 0x000073e1e1aa <unknown>
#3 0x000073e1d96e <unknown>
#4 0x000073e1defa <unknown>
#5 0x000074af6364 <unknown>
#6 0x000074302878 <unknown>
#7 0x0000742c8fee <unknown>
#8 0x0000742c9f44 <unknown>
#9 0x0000742ca21e <unknown>
#10 0x0000742cac4c <unknown>
#11 0x0000742c87b2 <unknown>
#12 0x0000742da4f6 <unknown>
#13 0x000073ed9d38 <unknown>
#14 0x000073eda03c <unknown>
#15 0x0000742e9aec <unknown>
#16 0x0000742e71dc <unknown>
Aborted
Note 5: On rpi and depending on what is insinde the .config, more GPU
memory should be allocated to run properly qt samples.
#0 0x0000742c63de <unknown>
#1 0x0000742d0c38 <unknown>
#2 0x0000749d7bde <unknown>
#3 0x0000749e3c70 <unknown>
#4 0x00007530227c <unknown>
#5 0x000075302480 <unknown>
#6 0x0000752fb1e4 <unknown>
#7 0x00007430f878 <unknown>
#8 0x0000742d5fee <unknown>
#9 0x0000742d6f44 <unknown>
#10 0x0000742d721e <unknown>
#11 0x0000742d7ad6 <unknown>
#12 0x0000742d57b2 <unknown>
#13 0x0000742e74f6 <unknown>
#14 0x0000742f6a74 <unknown>
#15 0x0000742f41dc <unknown>
Received signal 6
#0 0x0000742c63de <unknown>
#1 0x0000742c66a0 <unknown>
#2 0x0000725b5d10 <unknown>
[end of stack trace]
qml: Render process exited with code 256 (abnormal exit)
# mount /dev/mmcblk0p1 /mnt
# sed '/^gpu_mem_/s,=.*,=200,' -i /mnt/config.txt
# umount /mnt
Note 6: The first patch fixes a build issue when samples are compiled
without the support of printing [4]. This patch is already merged in
branch 5.9 [5] and concerns only 5.9.1.
085c2c52 Always compile QWebEnginePage::print
It fixes the error below.
.obj/browsermainwindow.o: In function `BrowserMainWindow::printRequested(QWebEnginePage*)': browsermainwindow.cpp:(.text+0x2cc0): undefined reference to `QWebEnginePage::print(QPrinter*, QWebEngineCallback<bool> const&)'
The second patch loads both libEGL and libGLESv2 symbols implicitly
instead of loading them with explicitly using hard-coded locations. It
fixes a bug when providers of lib*GL does not create libraries named
libEGL.so.1 and libGLESv2.s2 [6]. This patch is already merged in branch
5.9 [7].
d4c621f6 Load libEGL and libGLES2 symbols implicitly
It fixes the error below.
[327:347:1221/085837:ERROR:surface_factory_qt.cpp(68)] Failed to load /usr/lib/libGLESv2.so.2: /usr/lib/libGLESv2.so.2: cannot open shared object file: No such file or directory
[1]: http://lists.busybox.net/pipermail/buildroot/2015-July/132010.html
[2]: https://patchwork.ozlabs.org/patch/640633/
[3]: https://patchwork.ozlabs.org/patch/791332/
[4]: https://bugreports.qt.io/browse/QTBUG-61510
[5]: https://codereview.qt-project.org/#/c/198041/
[6]: https://bugreports.qt.io/browse/QTBUG-57761
[7]: https://codereview.qt-project.org/#/c/199554/
Cc: Akihiko Odaki <akihiko.odaki.4i@stu.hosei.ac.jp>
Cc: Julien Corjon <corjon.j@ecagroup.com>
Signed-off-by: Gaël PORTAY <gael.portay@savoirfairelinux.com>
[Arnout:
- move more dependencies to _ARCH_DEPENDS;
- mention all toolchain dependencies in the comments]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Add the possibility to choose more test tools than only integck
from the MTD utils test-suite.
Move the hidden BR2_PACKAGE_MTD_TESTS configuration to the bottom
of the page and make it visible. When checked, a new list of available
binaries is displayed and may be selected and compiled into the image
with the --enable-install-tests configure script option:
- flash_torture
- flash_stress
- flash_speed
- nandbiterrs
- flash_readtest
- nandpagetest
- nandsubpagetest
Most of these tests may be performed by inserting kernel modules
which are almost legacy so having the userspace tools available
might become useful.
Legacy handling for users who had BR2_PACKAGE_MTD_INTEGCK selected is
not needed: they also have the BR2_PACKAGE_MTD_TESTS option enabled in
their .config. That option has now become a selectable option so it is
not removed any more by oldconfig.
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
[Arnout:
- fix threads and MMU dependency;
- order Config.in options and mtd.mk lines alphabetically;
- add note on legacy handling to commit message.]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
fixup
Commit cef57c9642 added
bananapi_m2_plus_defconfig but forgot to update .gitlab-ci.yml. Do it
now.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
grub is no longer maintained: it is stuck at version 0.97 with huge
patches that have no opportunity to be applied upstream, as upstream
has even renamed it grub-legacy.
Besides, it no longer builds correctly with recent binutils versions,
and even the huge patches we could grab from Debian do not help the
slightest.
Since upstream really considers it dead, and there are at least two
alternatives (grub2 and syslinux), just remove grub.
Add a legacy entry.
Remove the test cases as well.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
The Makefile in the package is not very versatile, so we need to go our
way to only build and install what we can.
Fixing the Makefile is not worth it, considering that we can quite
easily do all of that in our .mk.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
[Arnout: add license file hashes and use SPDX license name]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
The Makefile in the package is not very versatile, so we need to go our
way to only build and install what we can.
Fixing the Makefile is not worth it, considering that we can quite
easily do all of that in our .mk.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
[Arnout: Add license file hash, use SPDX license name]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
DAHDI is the 'framework' to drive actual telehony cards. Using telephony
cards without signalling is pretty much meaningless, so signalling will
be added in later commits.
libtonezone is provided by dhadi-tools, while the dahdi headers are
provided by dahdi-linux. Go figure.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Also provides libraries, so install in staging as well.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
[Arnout: add hashes for license files]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
dahdi-linux provides kernel modules to drive a variety of telephony
cards, ranging from low-end one-channel to higher-end multi-channel
cards. It also provides headers for userland to talk to those cards.
With a bit of love, dahdi-linux can use our kernel-module
infrastructure. Wee! :-)
Still, there are a few specificities about dahdi-linux.
First, it needs to install a few binary firmware blobs, which it wants
to download at install time. Since we do want to be able to do
completely off-line builds, we need to downlaod them manually. So we
have the full list of firmware blobs (even if some can only be used on
an i386/x86_64 target, we still uconditionally download them), for which
we have locally-computed sha256 (no hash provided by upstream for the
blobs).
Second, the install procedure for the firmware blobs needs to have
access to the Linux kernel .config file, so it can decide whether to
install the blobs or not. We can force not to install them, but we can't
force to install them... :-/ And anyway, we'd have to do the same check
as is already done by dahdi-linux, so no need to duplicate that.
Finally, the licensing is relatively weird. Although it is obvious and
straightforward for the most part of dahdi-linux, consisting of mostly
GPLv2 and a few LGPLv2.1, there is one gotcha.
Of the firmware blobs, one is provided as a .o file, with no licensing
information whatsoever, without any source available from upstream, but
is directly linked to a GPLv2 file.
This is very concerning, but there is not much we can do about it,
except delegate to the legal reviewer whether that is acceptable or not.
AS an aside, dahdi-linux drivers do not build with a kernel 4.0 or
later, as it uses internals that have been removed in linux-4.0. There
has been no update upstream dahdi-linux to fix that. There's not much we
can do, except warn the user in the help text.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
[Arnout: use SPDX license names and add hashes for license files]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
