The modem-manager build generates a number of build warnings like:
mm-base-manager.c: In function 'handle_set_logging':
mm-base-manager.c:680:15: error: assignment from incompatible pointer type [-Werror]
ctx->self = g_object_ref (manager);
Which cause a build failure because of -Werror. Pass
--disable-more-warnings to disable -Werror.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Petr Vorel [Sun, 13 May 2018 19:07:36 +0000 (21:07 +0200)]
libmediaart: rename options to have proper prefix
Options should be prefixed by BR2_PACKAGE_LIBMEDIAART and not
BR2_PACKAGE_MEDIAART, but package was using both prefixes.
This was found as default symbol was defined as
BR2_PACKAGE_LIBMEDIAART_BACKEND_NONE (correct prefix), but symbol
was actually BR2_PACKAGE_MEDIAART_BACKEND_NONE).
This commit therefore renames the incorrectly named options, and adds
Config.in.legacy handling. Since the options are part of a choice, the
legacy handling cannot select the new options, and is only here to
inform the user.
Fixes: c443830a57 libmediaart: new package Signed-off-by: Petr Vorel <petr.vorel@gmail.com>
[Thomas: improve commit log, add Config.in.legacy handling] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Thomas Petazzoni [Sun, 13 May 2018 19:07:35 +0000 (21:07 +0200)]
ti-sgx-km: rename options to have proper prefix
The sub-options of the ti-sgx-km package had their name option
prefixed by BR2_PACKAGE_TI_SGX, while the prefix should be
BR2_PACKAGE_TI_SGX_KM. This commit fixes that, and adds the necessary
Config.in.legacy handling.
Since those options are part of a choice, the legacy handling cannot
select the new name of the options, so the legacy handling only
informs the user of the rename.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Thomas Petazzoni [Sun, 13 May 2018 19:07:34 +0000 (21:07 +0200)]
janus-gateway: rename options to have proper prefix
The sub-options of the janus-gateway package had their name option
prefixed by BR2_PACKAGE_JANUS, while the prefix should be
BR2_PACKAGE_JANUS_GATEWAY. This commit fixes that, and adds the
necessary Config.in.legacy handling.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Thomas Petazzoni [Sun, 13 May 2018 19:07:33 +0000 (21:07 +0200)]
ipsec-tools: rename options to have proper prefix
A number of options in the ipsec-tools package had their Config.in
option prefixed by BR2_PACKAGE_IPSEC, while the prefix should be
BR2_PACKAGE_IPSEC_TOOLS. This commit fixes that, and adds the
necessary Config.in.legacy handling.
Since those options are part of a choice, the legacy handling cannot
select the new name of the options, so the legacy handling only
informs the user of the rename.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Thomas Petazzoni [Sun, 13 May 2018 19:07:32 +0000 (21:07 +0200)]
libftdi: rename option to have proper prefix
The option name BR2_PACKAGE_LIBTFDI_CPP obviously had a typo: it
should have been named BR2_PACKAGE_LIBFTDI_CPP, and add the necessary
Config.in.legacy handling.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Thomas Petazzoni [Sun, 13 May 2018 19:07:31 +0000 (21:07 +0200)]
jquery-ui-themes: rename options to have proper prefix
The choice options to select the specific jquery-ui theme to install
had a prefix of BR2_PACKAGE_JQUERY_UI_THEME_ instead of
BR2_PACKAGE_JQUERY_UI_THEMES_. This commit fixes that, and adds
Config.in.legacy handling. It's worth mentioning that since those
options are part of a choice, the legacy handling cannot select the
new name of the option: we can simply inform the user about the
renaming.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Thomas Petazzoni [Sun, 13 May 2018 19:07:30 +0000 (21:07 +0200)]
bluez5_utils: rename options to have the proper suffix
The bluez5_utils Config.in options had a bogus prefix:
BR2_PACKAGE_BLUEZ5 instead of the expected
BR2_PACKAGE_BLUEZ5_UTILS. This commit fixes that, and adds the
appropriate Config.in.legacy handling.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Peter Korsgaard [Mon, 21 May 2018 13:27:20 +0000 (15:27 +0200)]
wavpack: add upstream security fixes
Fixes the following security issues:
CVE-2018-10536: An issue was discovered in WavPack 5.1.0 and earlier. The
WAV parser component contains a vulnerability that allows writing to memory
because ParseRiffHeaderConfig in riff.c does not reject multiple format
chunks.
CVE-2018-10537: An issue was discovered in WavPack 5.1.0 and earlier. The
W64 parser component contains a vulnerability that allows writing to memory
because ParseWave64HeaderConfig in wave64.c does not reject multiple format
chunks.
CVE-2018-10538: An issue was discovered in WavPack 5.1.0 and earlier for WAV
input. Out-of-bounds writes can occur because ParseRiffHeaderConfig in
riff.c does not validate the sizes of unknown chunks before attempting
memory allocation, related to a lack of integer-overflow protection within a
bytes_to_copy calculation and subsequent malloc call, leading to
insufficient memory allocation.
CVE-2018-10539: An issue was discovered in WavPack 5.1.0 and earlier for
DSDiff input. Out-of-bounds writes can occur because
ParseDsdiffHeaderConfig in dsdiff.c does not validate the sizes of unknown
chunks before attempting memory allocation, related to a lack of
integer-overflow protection within a bytes_to_copy calculation and
subsequent malloc call, leading to insufficient memory allocation.
CVE-2018-10540: An issue was discovered in WavPack 5.1.0 and earlier for W64
input. Out-of-bounds writes can occur because ParseWave64HeaderConfig in
wave64.c does not validate the sizes of unknown chunks before attempting
memory allocation, related to a lack of integer-overflow protection within a
bytes_to_copy calculation and subsequent malloc call, leading to
insufficient memory allocation.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Thomas Petazzoni [Sat, 19 May 2018 20:55:02 +0000 (22:55 +0200)]
ltrace: fix visibility of Config.in comment
The BR2_PACKAGE_LTRACE option has some architecture dependencies, but
those architecture dependencies are not taken into account for the
Config.in comment.
To fix this, this commit introduces a BR2_PACKAGE_LTRACE_ARCH_SUPPORTS
hidden boolean that gets used by both the BR2_PACKAGE_LTRACE option
and the Config.in comment.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Thomas Petazzoni [Sat, 19 May 2018 20:55:01 +0000 (22:55 +0200)]
ltrace: remove bogus comment in Config.in file
In commit dfaa18af00dfcff71a0159adaafb0880e58fa6a1 ("ltrace: disable
on mips/mipsel"), ltrace was disabled on mips/mipsel due to build
issues, and a comment was added in the Config.in file to explain that
even though ltrace has mips/mipsel support, it isn't enabled because
it doesn't build.
Then, in commit d23cce19c299e3010ba2dca84ab4ad35eff3cdbb ("ltrace:
enable for mips/mipsel"), the build of ltrace on mips/mipsel was
re-enabled, because it has been fixed upstream.
However, the comment in the Config.in comment was not removed in this
commit. Due to this, we have a comment that says "we don't allow
enabling ltrace on mips/mipsel" and the line right below precisely
allows to enable ltrace on mips/mipsel.
Fix this inconsistency by removing the no longer valid comment.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Commit 6e223241e1bb58a27eb890291f9f5c1fcc6a0818 ("Add Transmission
package"), which added the transmission package, introduced a
BR2_PACKAGE_TRANSMISSION_REMOTE Config.in option, supposedly matching
the --enable-remote/--disable-remote transmission option.
However, transmission as of version 2.33 packaged by this initial
commit, did not have a --enable-remote/--disable-remote option, and it
was apparently never part of transmission.
Therefore, this commit removes this useless option. Since the
transmission-remote tool is automatically built when the daemon is
enabled, the Config.in.legacy handling selects
BR2_PACKAGE_TRANSMISSION_DAEMON.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Fabrice Fontaine [Sun, 20 May 2018 08:11:01 +0000 (10:11 +0200)]
mbedtls: security bump to version 2.7.3
Extract from release announcement:
- (2.9, 2.7, 2.1) Fixed an issue in the X.509 module which could lead
to a buffer overread during certificate validation. Additionally, the
issue could also lead to unnecessary callback checks being made or to
some validation checks to be omitted. The overread could be triggered
remotely, while the other issues would require a non DER-compliant
certificate to be correctly signed by a trusted CA, or a trusted CA with
a non DER-compliant certificate. Found by luocm. Fixes #825.
- (2.9, 2.7, 2.1) Fixed the buffer length assertion in the
ssl_parse_certificate_request() function which could lead to an
arbitrary overread of the message buffer. The overreads could be caused
by receiving a malformed algorithms section which was too short. In
builds with debug output, this overread data was output with the debug
data.
- (2.9, 2.7, 2.1) Fixed a client-side bug in the validation of the
server's ciphersuite choice which could potentially lead to the client
accepting a ciphersuite it didn't offer or a ciphersuite that could not
be used with the TLS or DTLS version chosen by the server. This could
lead to corruption of internal data structures for some configurations.
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Danomi Manchego [Mon, 14 May 2018 02:12:08 +0000 (22:12 -0400)]
gst1-plugins-bad: update plugin licenses
Update several of the licenses annotated in the gst1-plugins-bad.mk file.
1. Specify GPL-2.0 in license info.
* All of the *.[ch] that specify GPL also specify version 2 or later.
2. Remove GPL from audiovisualizers.
* Changlog notes move from GPL to LGPL. (2015-04-25)
* docs/plugins/inspect/plugin-audiovisualizers.xml claims "LGPL".
* All *.[ch] files under ./gst/audiovisualizers say "GNU Library General Public License".
3. Add GPL to yadif.
* Changelog notes that yadif is "GPL". (2013-02-07)
* docs/plugins/inspect/plugin-yadif.xml claims "GPL".
* All *.[ch] files under ./gst/yadif say "GNU General Public License" except for one "GNU Library General Public License".
4. Remove UNKNOWN from fdk_aac.
* docs/plugins/inspect/plugin-fdkaac.xml claims "LGPL".
* All *.[ch] files under ./ext/fdkaac say "GNU Lesser" or "GNU Library General Public License".
5. Add BSD-2c to dtls.
* docs/plugins/inspect/plugin-dtls.xml claims "BSD".
* All *.[ch] files under ./gst/dtls have BSD-2c text.
6. Add BSD-2c to openh264.
* Changelog notes that openh264 is "BSD-2". (2014-10-03)
* docs/plugins/inspect/plugin-openh264.xml claims "BSD".
* All *.[ch] files under ./ext/openh264 have BSD-2c text.
Signed-off-by: Danomi Manchego <danomimanchego123@gmail.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
../../../hardwareintegration/client/xcomposite-egl/qwaylandxcompositeeglwindow.cpp: In member function 'void QtWaylandClient::QWaylandXCompositeEGLWindow::createEglSurface()':
../../../hardwareintegration/client/xcomposite-egl/qwaylandxcompositeeglwindow.cpp:124:82: error: invalid conversion from 'Window {aka long unsigned int}' to 'EGLNativeWindowType {aka void*}' [-fpermissive]
m_surface = eglCreateWindowSurface(m_glxIntegration->eglDisplay(), m_config, m_xWindow,0);
^~~~~~~~~
In file included from ../../../hardwareintegration/client/xcomposite-egl/qwaylandxcompositeeglclientbufferintegration.h:57:0,
from ../../../hardwareintegration/client/xcomposite-egl/qwaylandxcompositeeglwindow.h:46,
from ../../../hardwareintegration/client/xcomposite-egl/qwaylandxcompositeeglwindow.cpp:40:
.../host/arm-buildroot-linux-musleabihf/sysroot/usr/include/EGL/egl.h:265:31: note: initializing argument 3 of 'void* eglCreateWindowSurface(EGLDisplay, EGLConfig, EGLNativeWindowType, const EGLint*)'
EGLAPI EGLSurface EGLAPIENTRY eglCreateWindowSurface(EGLDisplay dpy, EGLConfig config,
Anssi Hannula [Tue, 15 May 2018 13:34:42 +0000 (16:34 +0300)]
gdb: actually disable gdbserver if BR2_PACKAGE_GDB_SERVER is unset
The gdb configure script is given --enable-gdbserver when
BR2_PACKAGE_GDB_SERVER is set, but it is not given --disable-gdbserver
when BR2_PACKAGE_GDB_SERVER is unset.
gdb gdb/configure.ac defaults to enabling gdbserver in "native"
(host=target) cases, which is always the case when buildroot builds a
gdb which runs on the target hardware. The gdbserver will overwrite
BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY gdbserver, if any.
Fix that by passing --disable-gdbserver when BR2_PACKAGE_GDB_SERVER is
unset.
Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Thomas Petazzoni [Thu, 17 May 2018 21:51:53 +0000 (23:51 +0200)]
faketime: add patch to disable -Werror
faketime currently doesn't build on host machines that use gcc 8.x due
to stricter checks done by gcc, and the fact that it is built with
-Werror.
As a simple stop-gap measure, this commit patches the faketime
Makefile to not use -Werror anymore.
The actual fixes for the gcc 8.x issues have been submitted upstream
at https://github.com/wolfcw/libfaketime/pull/161, but disabling
-Werror is a much smaller fix.
Also, it is worth mentioning that removing -Werror makes the existing
patch 0001-Disable-the-non-null-compare-warning-error.patch (which was
just disabling one specific warning). We nonetheless keep this patch
around as it is a backport from upstream.
Thomas Petazzoni [Thu, 17 May 2018 20:32:01 +0000 (22:32 +0200)]
libnss: backport upstream patch to fix build with gcc 8.x
This commit backports upstream patch
https://github.com/nss-dev/nss/commit/f0ce70989526fc9a0223398c99ea0d09777ea5df
to our libnss package to fix the build with gcc 8.x.
Fabrice Fontaine [Tue, 15 May 2018 18:41:38 +0000 (20:41 +0200)]
libkcapi: depends on BR2_TOOLCHAIN_HAS_SYNC_4
Since commit
https://github.com/smuellerDD/libkcapi/commit/4d0a5c235536b5f679e6a9b0c847f56c9cfc3835,
libkcapi uses __sync_add_and_fetch_4 and __sync_sub_and_fetch_4
Thomas Petazzoni [Thu, 17 May 2018 20:07:38 +0000 (22:07 +0200)]
exim: do not link buildconfig with $(LIBS)
The existing patch 0001-Build-buildconfig-for-the-host.patch changes
the exim build system to use the host compiler to build the
"buildconfig" program instead of the cross-compiler.
However, it still uses $(LIBS) which lists the target libraries to
link with, which shouldn't be used. Since buildconfig doesn't use any
library beyond the C library, we can simply drop using $(LIBS).
This will fix build failures of exim on Fedora 28, where libnsl is no
longer provided by the C library, causing build failures such as:
Kconfig uses either pkg-config or hard-coded /usr/include paths to find
the ncurses or ncursesw library. If ncursesw is found, it will include
<ncursesw.h>. Since Buildroot's host-ncurses doesn't install a .pc file,
and linux.mk anyway doesn't pass the pkg-config options to find the host
pkg-config files, Kconfig will always find the system's ncursesw.h.
However, since commit dde090c299 (linux: fix passing of host CFLAGS and
LDFLAGS) HOST_LDFLAGS is passed to the linux build system. Thus, if
host-ncurses was already built before 'make linux-menuconfig' is called,
the build will pick up libncurses from the host directory, which is NOT
widechar. Thus, two different ncurses configurations are mixed into the
final mconf program. This will result in serious breakage in the
rendering of the menus (lots of @ and question mark characters).
As a workaround (suggested by Yann), don't pass HOST_CFLAGS and
HOST_LDFLAGS when running kconfig commands. For kconfig, we should never
need host packages anyway. This way, the kconfig calls will always use
the system's ncurses and never our host-ncurses.
Note that the same problem could pop up for other kconfig packages as
well if we ever pass HOST_CFLAGS/HOST_LDFLAGS to them. We could force
HOSTCC=$(HOSTCC) directly in kconfig-package. However, for now there
are no other packages that exhibit this problem, so this can be
revisited when they do.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: David De Grave <david.degrave@essensium.com> Cc: Scott Fan <fancp2007@gmail.com> Cc: Yann E. MORIN <yann.morin.1998@free.fr> Tested-by: Matt Weber <matthew.weber@rockwellcollins.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
clamav: add patch to fix build failure caused by lack of libcurl
When json-c is enabled but libcurl is disabled, clamav tries to build
the clamsubmit program, which fails with:
CC clamsubmit.o
clamsubmit.c:6:23: fatal error: curl/curl.h: No such file or directory
#include <curl/curl.h>
This is due to an incorrect curl-config detection logic, leading to
/bin/curl-config being present making the configure script believe
that curl is available, even when --without-libcurl is explicitly
passed.
This commit adds a patch, submitted upstream, which fixes this
problem.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
ClamAV is using Git upstream
(https://github.com/Cisco-Talos/clamav-devel), so it makes sense to
use Git-formatted patches.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Baruch Siach [Tue, 8 May 2018 18:26:16 +0000 (21:26 +0300)]
zstd: fix host headers installation
If host-zstd builds when $(HOST_DIR)/include has not been created yet,
the install-includes target does not create this directory. Instead, the
install command copies the headers over $(HOST_DIR)/include, thus
creating a regular file instead of a directory. This leads to the
following installation failure:
Installing includes
install: cannot create directory ‘.../host/usr/include/’: File exists
Makefile:166: recipe for target 'install-pc' failed
make[1]: *** [install-pc] Error 1
Add a patch to fix that.
Cc: Peter Seiderer <ps.report@gmx.net> Cc: Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by: Baruch Siach <baruch@tkos.co.il> Reviewed-by: Peter Seiderer <ps.report@gmx.net> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
PIE support in Buildroot should be enabled via the global option
BR2_RELRO_FULL option, and not done on a per-package basis, therefore
PIE should unconditionally be disabled in the cifs-utils package.
This has the added side-effect that it works around a binutils bug on
SPARC causing the linker to segfault when PIE is enabled:
The lynx package incorrectly uses target LDFLAGS to build a host tool,
which causes a problem when we do a statically link build for the
target, on a host machine that doesn't support static linking.
A simple patch fixes the problematic makefile, and it has been
submitted upstream on the project mailing list.
Since the rework of the download infrastructure, the "file" download
helper gets passed an URL that starts with file://, but forgets to
strip it before passing it to "cp", causing a failure as the "cp"
program isn't prepared for file paths starting with file://. This is
fixed by stripping the file:// at the beginning of the URL.
In addition, the path passed to cp lacked a slash between the
directory path and the filename part of the url. This is fixed by
adding a slash at the appropriate places.
Fixes the following build failure when the "file" download method is
used:
cp: cannot stat 'file:///home/angelo/DEV/TOOLCHAINSarmv7-eabihf--glibc--bleeding-edge-2017.11-1.tar.bz2': No such file or directory
Signed-off-by: Angelo Compagnucci <angelo@amarulasolutions.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Baruch Siach [Sun, 13 May 2018 18:37:59 +0000 (21:37 +0300)]
libkrb5: disable rpath
The default rpath value for krb5 is /usr/lib. On some hosts this might
confuse the build time linker as it looks for target libraries in the
host /usr/lib directory.
Yann E. MORIN [Sun, 13 May 2018 16:59:23 +0000 (18:59 +0200)]
package/xen: force location of init scripts
The Xen configure scripts looks at the build host to decide where to
install the Sys-V startup scripts, and that location differs between
various distros.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Matt Weber <matthew.weber@rockwellcollins.com> Cc: Alistair Francis <alistair@alistair23.me> Reviewed-by: Alistair Francis <alistair@alistair23.me> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
If BR2_SHARED_LIBS is set, only install shared version of library
(continue to build both libraries through all target as there is no
libcap.so target but only a libcap.so.$(VERSION).$(MINOR))
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Bernd Kuhls [Wed, 9 May 2018 19:34:16 +0000 (21:34 +0200)]
package/apr-util: fix ldap detection
configure checks if ldap_set_rebind_proc takes 2 or 3 arguments
http://svn.apache.org/viewvc/apr/apr-util/tags/1.6.1/build/apu-conf.m4?revision=1812528&view=markup#l370
It uses the macro APR_TRY_COMPILE_NO_WARNING which adds -Werror to
treat all warnings as errors when gcc is used:
http://svn.apache.org/viewvc/apr/apr/tags/1.6.3/build/apr_common.m4?revision=1812527&view=markup#l504
In some buildroot configs a compiler warning occurs during this check:
http://autobuild.buildroot.net/results/241/241ed78b93ce86c859e175530fa485711ff61615//apr-util-1.6.1/config.log
/home/rclinux/rc-buildroot-test/scripts/instance-1/output/host/arm-buildroot-linux-uclibcgnueabihf/sysroot/usr/include/features.h:218:5:
error: #warning requested reentrant code, but thread support was disabled [-Werror=cpp]
cc1: all warnings being treated as errors
Due to this warning 'ac_cv_ldap_set_rebind_proc_style' is set to two
instead of three leading to a build error later on. This patch forces
ac_cv_ldap_set_rebind_proc_style=three to be inline with openldap which
fixes
http://autobuild.buildroot.net/results/241/241ed78b93ce86c859e175530fa485711ff61615/
This solution was inspired by a discussion on the fink mailinglist:
https://sourceforge.net/p/fink/mailman/message/31720482/
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Julien Boibessot [Thu, 10 May 2018 14:37:26 +0000 (16:37 +0200)]
package/qt5cinex: fix download
The Buildroot dl-wrapper tries to download
Qt5_CinematicExperience_%22rpi_%221.0.tgz, which fails, so this commit
fixes the archive name by removing useless double quotes.
Signed-off-by: Julien Boibessot <julien.boibessot@armadeus.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Anisse Astier [Fri, 11 May 2018 20:50:37 +0000 (22:50 +0200)]
go: security bump to version 1.10.2
This bump contains many bug fixes, as well as the following security
issue, patched in Go 1.10.1:
CVE-2018-7187: The "go get" implementation in Go 1.9.4, when the
-insecure command-line option is used, does not validate the import path
(get/vcs.go only checks for "://" anywhere in the string), which allows
remote attackers to execute arbitrary OS commands via a crafted web
site.
Signed-off-by: Anisse Astier <anisse@astier.eu> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Anisse Astier [Fri, 11 May 2018 20:50:34 +0000 (22:50 +0200)]
go: cleanup cross-compilation support
Now that we fixed cross-compilation in the go package, cleanup the build
to remove the workaround added in 60c5c96ae109dcea48e0997b5e6e6645ac9b86
"package/go: Build host tools with host CC". We only need a single pass
to build the go toolchain.
Signed-off-by: Anisse Astier <anisse@astier.eu> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Actually if GOHOSTOS == GOOS || GOHOSTARCH == GOARCH the go build system assume
it's not cross compiling and uses the same toolchain for both the host and the
target. This commit adds a patch to enable the explicit
GO_ASSUME_CROSSCOMPILING in go build system and updates to go package
accordingly.
Yann E. MORIN [Fri, 11 May 2018 15:50:58 +0000 (17:50 +0200)]
docs/manual: using a branch name as FOO_VERSION does not work
For various reasons, we've always suggested users to avoid using a
branch as version string for their packages, because it does not work
as a they would expect:
- it is not reproducible, because the branch may change between two
builds that are done at different times;
- it does not even follow the branch, as Buildroot anyway generates
a local tarball, which it will reuse on subsequent builds.
Furthermore, since we fetch and not pull, any existing local branch
is not updated.
Yet, until recently, using a branch name would just work (with the
above limitations): the git tree was cloned, the branch checked out,
and the tarball created.
But with the advent of the git caching, using a branch name does not
work anymore. Indeed, we now do a git-fetch, and that does not create
a local master branch. So we can't check out master, because it does
not exist locally. And for other branches, as noticed above, the local
branch does not get udpated to the remote one.
Furthermore, the local branches are only created by chance, again as a
side-effect of trying to fetch the "special refs".
So, we can't say that we reliably support the use of a branch name.
Update the manual to state that using a branch does not work. Remove
the 'stable' example, as it looked like the name of a stable branch;
instead, replace it with a version string that ressemble a tag.
Fix the layout of the manual by making the version examples an actual
bulleted list.
Note: the above is only entirely true for git. For Mercurial, CVS and
subversion, the status may be mixed, but nonetheless, using branches is
still a bad idea, if at least because it is not reproducible, and
because Buildroot does not even follow the branch. So, we do not
differentiate between the various SCMs, and just flatly state that using
a branch name is not supported.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com> Cc: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Baruch Siach [Thu, 10 May 2018 15:42:12 +0000 (18:42 +0300)]
strace: disable (again) mpers for musl
It turns out that mpers support in strace still does not play nicely
with musl libc. As explained in commit 7892a778b (package/strace:
disable libmpers with musl toolchains) headers mixup causes gcc header
to be included, instead of the musl one, resulting in conflicting types.
Commit 1088372941 (strace: bump to version 4.21) incorrectly enabled
mpers for musl. Revert that.
projects / coffee / buildroot.git / log