5.0.2 is API and ABI compatible with 5.0.0 and 5.0.1 and includes
mitigations for CVE-2017-5715 (Spectre Variant 2) for X86 and MIPS.
Signed-off-by: Valentin Korenblit <valentin.korenblit@smile.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Use "GST1_PLUGINS_BAD_LICENSE := $(GST1_PLUGINS_BAD_LICENSE), xxxx" construct
so that the list of licenses is presented as a comma-separated list.
Signed-off-by: Danomi Manchego <danomimanchego123@gmail.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
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.
Fixes:
http://autobuild.buildroot.net/results/c43d2ebd8ab30016969d642dbd71c297dc5f6bab/
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>
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:
sparc-linux-gcc -Wall -Wextra -D_FORTIFY_SOURCE=2 -fpie -pie -Wl,-z,relro,-z,now -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -o mount.cifs mount.cifs.o mtab.o resolve_host.o util.o -lcap-ng
collect2: fatal error: ld terminated with signal 6 [Aborted], core dumped
This issue will reappear when we start testing BR2_RELRO_FULL in the
autobuilders, but in the mean time it avoids the problem.
Fixes:
http://autobuild.buildroot.net/results/a5342890f39bdccae1324e7d3dbe0eab1aad28e5/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
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.
Fixes:
http://autobuild.buildroot.net/results/38ba2531eeeb4a7985eddd2df8bfaf0b56e6a687/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
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>
Do not overwrite destination file if it exists.
Simliar to bug #10986.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: mzweerspenko+bugzilla@gmail.com
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The BR2_TOOLCHAIN_UCLIBC symbol doesn't exist, it was meant to be
BR2_TOOLCHAIN_BUILDROOT_UCLIBC.
Signed-off-by: Petr Vorel <petr.vorel@gmail.com>
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>
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>
libclang.so is statically linking against all LLVM static libraries
instead of linking dynamically against libLLVM.so.
This patch fixes this problem by setting LLVM_LINK_LLVM_DYLIB to ON.
Signed-off-by: Valentin Korenblit <valentin.korenblit@smile.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
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>
Now that we fixed cross-compilation in the go package, cleanup the build
to remove the workaround added in 60c5c96ae1
"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>
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>
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.
Fixes:
http://autobuild.buildroot.net/results/345/3452419498c074ca66f36f0f87263fa10662ac86/
Cc: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Since we reworked the download infra, the location for packages to look
for their files has moved to a per-package directory.
For systems where a download of the dahdi firmware files was already
done in a version prior to the rework, all was working fine so far,
because the files were indeed in the main DL directory.
But for systems where the download is first attempted after the rework,
the files are not found (even though they are properly downloaded).
Fix the location where dahdi-linux looks for its extra files.
Reported-by: ***** ***** <zyama.abel@mail.ru>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: ***** ***** <zyama.abel@mail.ru>
Cc: Carlos Santos <casantos@datacom.ind.br>
Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Since we reworked the download infra, the location for packages to look
for their files has moved to a per-package directory.
For systems where a download of the asterisk sound files was already
done in a version prior to the rework, all was working fine so far,
because the files were indeed in the main DL directory.
But for systems where the download is first attempted after the rework,
the files are not found (even though they are properly downloaded).
Fix the location where asterisk looks for its extra files.
Reported-by: ***** ***** <zyama.abel@mail.ru>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: ***** ***** <zyama.abel@mail.ru>
Cc: Carlos Santos <casantos@datacom.ind.br>
Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
A person on IRC reported a build failure with the util-linux package,
looking like this:
for I in uname26 linux32 linux64 ; do \
cd /home/aep/consulting/chargery/tracker/output/target/usr/bin && ln -sf setarch $I ; \
done
[...]
/bin/sh: line 1: ./ln: cannot execute binary file: Exec format error
/bin/sh: line 1: ./ln: cannot execute binary file: Exec format error
/bin/sh: line 1: ./ln: cannot execute binary file: Exec format error
The issue was an empty path in the PATH variable, which means "current
working directory", causing a "ln" binary built by util-linux for the
target to be used instead of the system-provided "ln".
We already check a number of things in the PATH and LD_LIBRARY_PATH
variables in support/dependencies/dependencies.sh, but we were not
checking that PATH did not contain an empty path.
This commit fixes that and takes this opportunity to simplify the test
code for PATH and LD_LIBRARY_PATH.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[Thomas: improve commit log.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
- Add some explanations about the Blackfin removal, as suggested by
Yann E. Morin.
- Add list of resolved issues.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
