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>
The mplayer package will be removed from buildroot, tovid can use mpv
instead. Support for mpv was added upstream:
05cbce2ea1
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Support for mpv is not present in the tarball version 0.35.2, therefore
we bump this package to current git master branch to prepare the switch
from mplayer to mpv.
Added license hash.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This reverts commit dededf0ff2.
Building the only package depending on libcrossguid, Kodi, breaks due to
this bump:
/home/buildroot/br4/output/build/kodi-17.6-Krypton/xbmc/utils/
StringUtils.cpp: In static member function ‘static std::__cxx11::string
StringUtils::CreateUUID()’:
/home/buildroot/br4/output/build/kodi-17.6-Krypton/xbmc/utils/
StringUtils.cpp:1194:10: error: ‘GuidGenerator’ does not name a type
static GuidGenerator guidGenerator;
^~~~~~~~~~~~~
/home/buildroot/br4/output/build/kodi-17.6-Krypton/xbmc/utils/
StringUtils.cpp:1195:15: error: ‘guidGenerator’ was not declared in this
scope
auto guid = guidGenerator.newGuid();
^~~~~~~~~~~~~
This happens due to changes in libcrossguid:
https://github.com/graeme-hill/crossguid/blob/master/README.md
"This is version 0.2 of CrossGuid. If you all already using CrossGuid and
your code uses GuidGenerator then you are using version 0.1."
Even Kodi master branch has no support for libcrossguid-0.2.x yet so we
revert the bump.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Increased minimum gcc version to 4.8 as mentioned in the Changelog:
https://wiki.znc.in/ChangeLog/1.7.0
Removed all patches:
- 0001 was applied upstream:
483074cbf8
- 0002 is not needed anymore after upstream switched Csocket to a git
submodule:
9166e6ed40 (diff-8a725997e024d92d67b33a90cffb8342)
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Update qemu_arm_vexpress target to Linux kernel 4.16.7.
Signed-off-by: Florian La Roche <Florian.LaRoche@googlemail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Since commit af313accf1,
hasher test application depends on dlfcn.h. To avoid putting all apps
under !BR2_STATIC_LIBS dependency, split BR2_PACKAGE_LIBKCAPI_APPS into
several variables.
Moreover, BR2_USE_MMU is only a dependency of BR2_PACKAGE_LIBKCAPI_TEST
as other applications don't use fork.
Finally, enc or dgst applications could be enabled in a next patch if
needed.
Fixes:
- http://autobuild.buildroot.net/results/7c57f3025030eff41a5cde52759821249859caf1
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Dropbear 2018.76 now uses the --enable-static option to indicate that a static
binary should be built. This will incorrectly pick up the generic buildroot
option intended for building static libraries, causing an unwanted static
binary build with BR2_SHARED_STATIC_LIBS.
Fix by appending an --disable-static configure flag, overriding the buildroot
default.
Signed-off-by: Stefan Sørensen <stefan.sorensen@spectralink.com>
Reviewed-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Bump kernel to version 4.16.7 and U-Boot to 2018.05.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Commit b4fc5a180c (package/busybox: support spaces in module aliases in
mdev) changed the mdev coldplugging to handle sysfs path elements and
modalias values containing spaces. This unfortunately doesn't work as was
recently reported:
http://lists.busybox.net/pipermail/buildroot/2018-May/220903.html
The problem is that sort -z also expects the fields of the input files to be
zero terminated, which is not the case for modalias sysfs entries.
So drop the -z option to sort. Spaces in modalias entries could be handled
with the xargs -d '\n' option, but that is unfortunately not supported by
the busybox applet. Instead, use tr to convert newlines to zeros so we can
use xargs -0.
Reported-by: Daniel Palmer <daniel@0x0f.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The configure.ac check for atomic intrinsics assumes that if an atomic
intrinsic is not available, it's because we must link with
libatomic. Except that libatomic is not always available, for example
with gcc <= 4.7.
To fix this, this commit adds a patch that reworks the atomic check in
configure.ac. It has been submitted upstream, and tested in a number
of different combinations.
Fixes:
http://autobuild.buildroot.net/results/b045488d880a4013ed82937e7115b7636867e01d/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Use += for the SUDO_CONF_ENV conditional assignment to avoid override of
SUDO_CONF_ENV assignments that might be added in the future.
Add license file hash.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Add upstream patch to fix compile with latest x264 library.
Fixes [1]:
gstx264enc.c: In function 'plugin_init':
gstx264enc.c:2900:36: error: 'x264_bit_depth' undeclared (first use in this function); did you mean 'x264_picture_t'?
default_vtable.x264_bit_depth = &x264_bit_depth;
^~~~~~~~~~~~~~
x264_picture_t
[1] http://autobuild.buildroot.net/results/a766a28c584534b6a30839cfd98428d840bce3f2
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
