Drop musl patch, which is not necessary anymore as netinet vs linux
header clash is fixed.
Also add hash for the license files.
musl build successfully tested with:
* armv7-eabihf--musl--stable-2017.05-toolchains-1-1
(GCC 5.4.0, Linux headers 3.10.105, musl 1.1.16)
* armv7-eabihf--musl--bleeding-edge-2018.02-1
(GCC 7.3.0, Linux headers 4.9.80, musl 1.1.18)
Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
CVE-2018-1000120: curl could be fooled into writing a zero byte out of
bounds when curl is told to work on an FTP URL with the setting to only
issue a single CWD command, if the directory part of the URL contains a
"%00" sequence.
https://curl.haxx.se/docs/adv_2018-9cd6.html
CVE-2018-1000121: curl might dereference a near-NULL address when
getting an LDAP URL.
https://curl.haxx.se/docs/adv_2018-97a2.html
CVE-2018-1000122: When asked to transfer an RTSP URL, curl could
calculate a wrong data length to copy from the read buffer.
https://curl.haxx.se/docs/adv_2018-b047.html
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The `tar` implementation in Busybox 1.28.0 and 1.28.1 won't extract a
rootfs with some symlinks that appear to look "dangerous". This
completely (and silently!) breaks on-target updates via RAUC for me, for
example.
In the meanwhile, upstream already reverted the commit in question
(in their commit a84db18fc71d09e801df0ebca048d82e90b32c6a), so this
patch simply applies that revert in Buildroot. The fix has not made it
to a release, yet.
Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz>
Bug: https://bugs.busybox.net/show_bug.cgi?id=8411
Bug: https://github.com/rauc/rauc/issues/249
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Recently a build failure was reported which was traced back to to the fact
that the user had a TOOLCHAIN_VERSION environment variable set which leads
to a strange looking error message:
toolchain/toolchain/toolchain.mk:40: *** TOOLCHAIN_SITE cannot be empty when
TOOLCHAIN_SOURCE is not. Stop.
Environment variables automatically gets converted to make variables by GNU
make - E.G. from the manual
(https://www.gnu.org/software/make/manual/html_node/Environment.html):
Variables in make can come from the environment in which make is run. Every
environment variable that make sees when it starts up is transformed into a
make variable with the same name and value
So we end up in make with TOOLCHAIN_VERSION set to the value of the
environment variable. As virtual packages do not have a version, there is
no explicit TOOLCHAIN_VERSION = .. line in toolchain.mk overriding this
value, and the logic in package/pkg-generic.mk sets a default value for
TOOLCHAIN_SOURCE when TOOLCHAIN_VERSION is set, and finally errors out as
TOOLCHAIN_SITE isn't set.
As a workaround, explicitly set <pkg>_VERSION and <pkg>_SOURCE to the empty
string in the virtual package infrastructure.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following vulnerabilities:
- CVE-2018-1000098: Crash when parsing SDP with an invalid media format
description
- CVE-2018-1000099: Crash when receiving SDP with invalid fmtp attribute
[Peter: add CVE info]
Signed-off-by: Adam Duskett <aduskett@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This script comes from the kernel source, so ignore any code style
warnings for it in order to keep it as close as possible to the original
one, making synchronization between repos easier.
The option --exclude for flake8/pycodestyle is an absolute list and has
a default, so ideally the default values should be added too.
But the use cases for flake8 in the tree are:
- when developing a new script or changing an existing one, the
developer calls flake8 only on that script;
- in the GitLab job, a list of all Python files to be tested is created
and then passed to flake8.
None of these involve calling 'flake8' without parameters, so don't care
about adding the default value.
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Cc: Marcus Folkesson <marcus.folkesson@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix these warnings:
E201 whitespace after '['
E202 whitespace before ']'
E501 line too long (138 > 132 characters)
-> isolate the common part of the external toolchain url in a variable
to make the long lines shorter and more readable.
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
For stop using cma.
git shortlog --invert-grep --grep travis --no-merges 94ccbc8924c12a818d61d36a4b389b74a89fde3c..
Maxime Ripard (1):
mali: Stop using the reserved-memory region to setup the fb area
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The host shared libraries produced by CMake were missing a proper
DT_RPATH. That became a problem because the DT_RPATH handling is not
transitive by design.
Consider the following scenario:
- pkg-a provides a library (`liba`) which links to `libpcre`
- pkg-b provides a binary (`foo`) and a shared library (`libb`) which is
needed by that binary
- `libb` links to `liba`
- pkg-a and pkg-b are both built by CMake
In this scenario, `foo` is correctly marked with DT_RPATH pointing to
host/lib/, but that path is not used when (recursively) resolving PCRE's
symbols in `liba`. When attempting to run the `foo` binary, the linker
correctly finds both `liba` and `libb`, but it cannot find the
libpcre.so as built by Buildroot for host.
Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz>
Reviewed-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The change in commit bf73334232 only works
for newer uboot source trees. Add a check that scripts/dtc/libfdt
directory exists before making this change.
[Peter: add comment explaining why]
Signed-off-by: Stefan Becker <chemobejk@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
docker-proxy is needed by docker-engine at runtime, and was
previously not included. This leads to the following error
when attempting to port-map ports to a container:
$ docker run -p 8080:8080 nginx
docker: Error response from daemon: driver failed programming external
connectivity on endpoint:
exec: "docker-proxy": executable file not found in $PATH.
Docker expects the docker-proxy binary to exist in the PATH.
Signed-off-by: Christian Stewart <christian@paral.in>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Add docker-proxy package to Buildroot. Needed by docker-engine at
runtime, and previously not included. This leads to the following error
when attempting to port-map ports to a container:
$ docker run -p 8080:8080 nginx
docker: Error response from daemon: driver failed programming external
connectivity on endpoint:
exec: "docker-proxy": executable file not found in $PATH.
Docker expects the docker-proxy binary to exist in the PATH.
Signed-off-by: Christian Stewart <christian@paral.in>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The T1 QoriQ from NXP has had a few varients of RDB dev boards.
This target is against the latest D4RDB version. Any of the
other versions before D4RDB (plain RDB), may require backing off
the uboot version to SDK 1.6 and/or adjusting the kernel dtb used.
This board configuration provides an upstream kernel build which
has been verified to boot on target.
The target assumes the user still uses the NXP suggested prebuilts
in the SDK2.0 (last release for PowerPC). If a uboot rebuild is
required, the source for SDK2.0 can be found in the following repo.
http://git.freescale.com/git/cgit.cgi/ppc/sdk/u-boot.git/tag/?id=fsl-sdk-v2.0-1703
Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Replacing the p1010rdb, this board is based on the tower development
system still available by NXP. The board is setup to track upstream
Linux and has been bumped from 4.1 to 4.15 (compared to p1010).
The target does not build uboot and assumes the user still uses the NXP
suggested prebuilts in the SDK2.0 (last release for PowerPC). If a
uboot is required, the source for SDK2.0 can be found in the following
repo.
http://git.freescale.com/git/cgit.cgi/ppc/sdk/u-boot.git/tag/?id=fsl-sdk-v2.0-1703
Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Explicitly indicate that this package is GPL v2.0+ as well as
provide a hash for the source's license file (COPYING).
Signed-off-by: James Knight <james.d.knight@live.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Rename the confusing and misleading ts5x00 directory to a real reference
platform name, ts5500. The readme.txt file already states the support
for both TS-5500 and TS-5400 platforms.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Bump the 3.17 kernel used for the Technologic Systems TS-5500 platform
to the latest LTS kernel 4.14.
This fixes the ts5x00_defconfig build with GCC 6.x.
The linux-3.17.config file has been renamed to linux-4.14.config to
match the new kernel version, and its changes are the result of make
linux-update-defconfig. However only comments are affected.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
U-Boot host programs fail to build when libfdt-devel is installed
system-wide, with errors like this:
HOSTCC tools/aisimage.o
In file included from tools/../include/../lib/libfdt/libfdt.h:10:0,
from tools/../include/libfdt.h:1,
from tools/fdt_host.h:11,
from tools/imagetool.h:24,
from tools/aisimage.c:8:
/usr/include/libfdt_env.h:70:30: error: conflicting types for ‘fdt64_t’
typedef uint64_t FDT_BITWISE fdt64_t;
^~~~~~~
In file included from <command-line>:0:0:
././include/libfdt_env.h:19:16: note: previous declaration of ‘fdt64_t’ was here
typedef __be64 fdt64_t;
^~~~~~~
In file included from ././include/libfdt_env.h:12:0,
from <command-line>:0:
/usr/include/libfdt_env.h:90:24: error: expected ‘)’ before ‘x’
static inline uint32_t fdt32_to_cpu(fdt32_t x)
^
This commit backports an upstream patch that fixes this problem.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When libfdt-devel is installed system-wide, the build of U-Boot host
programs currently fails with lots of:
HOSTCC tools/aisimage.o
In file included from tools/../include/../lib/libfdt/libfdt.h:10:0,
from tools/../include/libfdt.h:1,
from tools/fdt_host.h:11,
from tools/imagetool.h:24,
from tools/aisimage.c:8:
/usr/include/libfdt_env.h:70:30: error: conflicting types for ‘fdt64_t’
typedef uint64_t FDT_BITWISE fdt64_t;
^~~~~~~
In file included from <command-line>:0:0:
././include/libfdt_env.h:19:16: note: previous declaration of ‘fdt64_t’ was here
typedef __be64 fdt64_t;
^~~~~~~
In file included from ././include/libfdt_env.h:12:0,
from <command-line>:0:
/usr/include/libfdt_env.h:90:24: error: expected ‘)’ before ‘x’
static inline uint32_t fdt32_to_cpu(fdt32_t x)
^
This commit adds a fixup in the U-Boot code to fix this problem. The
fixup is equivalent to applying upstream commit
http://git.denx.de/?p=u-boot.git;a=commitdiff;h=e0d20dc1521e74b82dbd69be53a048847798a90a,
but we can't use a patch for the uboot package, since people are using
arbitrary versions.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
