Patch that pins mmc indexes was not accepted to mainline kernel. Drop that
patch and switch to GPT to use partition labels. For GPT the name of the
partition in genimage.cfg is used as the label for that partition. Note
that the default GPT partition table location conflicts with the SPL
location, so move GPT table after bootloaders.
Signed-off-by: Sergey Matyukevich <geomatsi@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
grpc has plugins for multiple programming languages, which are needed on
development machines only. Examples are grpc_cpp_plugin, grpc_ruby_plugin,
etc.
Even though before commit fedf3318e3,
grpc_cpp_plugin was not installed for target, all other plugins still were.
This causes additional build time and rootfs space.
As Buildroot does not support building a development environment for target,
these tools can be disabled.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
In commit fedf3318e3, an obsolete patch to
support cross-compilation was removed, in favor of the upstream solution.
However, this caused a small change in behavior: for the target grpc, the
tool 'grpc_cpp_plugin' is now also built, while before it was not.
This tool is only really needed on development machines. Since Buildroot
does not support compilers and such on target itself, the tool is not
needed.
There exists an option gRPC_BUILD_GRPC_CPP_PLUGIN which can be set to 'OFF',
but disabling it in a cross-compilation context yields build failures.
Add a patch to fix that. This patch is intended to be upstreamed to grpc.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Commit 903de16f5f added passing
'--with-libgrpc++' with the explanation:
"Use --with-libgrpc++ option as otherwise collectd will try to find
grpc++.pc which is not available."
At the time of above commit, grpc version in Buildroot was 1.23.0.
Since grpc 1.25.0, a grpc++.pc file _is_ generated from cmake builds.
Hence, remove passing --with-libgrpc++.
This change fixes a problem introduced by commit
fedf3318e3. As a side effect of that change, a
target version of 'grpc_cpp_plugin' was now created. When collectd was built
after grpc, even without grpc support in collectd enabled, the collectd
configure script would find this target grpc_cpp_plugin and try to use it
(which is not possible because it is built for target).
When not passing '--with-libgrpc++', collectd will instead find the host
version of grpc_cpp_plugin, which works fine.
There are still two underlying problems:
1. the target version of grpc_cpp_plugin is not actually needed. This will
be disabled in a subsequent commit.
2. collectd should not execute any grpc-related action if grpc support for
collectd is disabled. This problem has been reported upstream:
https://github.com/collectd/collectd/issues/3836
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Most of the toolchains now use gcc 9.x and kernel headers 5.9, instead
of gcc 8.x and kernel headers 5.4.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Instead of using an external toolchain built specifically for the
autobuilders to test Xtensa/uclibc, use a pre-built Bootlin toolchain.
To be noted: that fragment was in fact already using a Bootlin
bleeding-edge toolchain, because BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y is
missing from the fragment:
$ cat support/config-fragments/autobuild/br-xtensa-full.config >.config
$ make olddefconfig
$ grep BOOTLIN .config
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARCH_SUPPORTS=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_XTENSA_LX60_UCLIBC_BLEEDING_EDGE=y
# BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_XTENSA_LX60_UCLIBC_STABLE is not set
The original fragment was supposed to use a stable toolchain, so we
switch to explictly use a stable Bootlin toolchain.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr:
- add blurb about missing BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Instead of using an external toolchain built specifically for the
autobuilders to test x86-64/musl, use a pre-built Bootlin toolchain.
The previous configuration was for an Atom platform, but the Bootlin
toolchains only provide a Core i7 configuration. Since this is close
enough, we change to use this Core i7 configuration.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Instead of using an external toolchain built specifically for the
autobuilders to test x86-64/uclibc, use a pre-built Bootlin toolchain.
The previous configuration was for Core2 platform, but the Bootlin
toolchains only provide a Core i7 configuration. Since this is close
enough, we change to use this Core i7 configuration.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Instead of using an external toolchain built specifically for the
autobuilders to test SPARC64/glibc, use a pre-built Bootlin toolchain.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Instead of using an external toolchain built specifically for the
autobuilders to test SPARC/uclibc, use a pre-built Bootlin toolchain.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Instead of using an external toolchain built specifically for the
autobuilders to test SH4/uclibc, use a pre-built Bootlin toolchain.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr: drop BR2_sh4=y which is the default]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Instead of using an external toolchain built specifically for the
autobuilders to test RISC-V 32/glibc, use a pre-built Bootlin
toolchain.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Instead of using an external toolchain built specifically for the
autobuilders to test PowerPC e500mc/uclibc, use a pre-built Bootlin
toolchain.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Instead of using an external toolchain built specifically for the
autobuilders to test PowerPC64le Power8/glibc, use a pre-built Bootlin
toolchain.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Instead of using an external toolchain built specifically for the
autobuilders to test OpenRISC/uclibc, use a pre-built Bootlin
toolchain.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Instead of using an external toolchain built specifically for the
autobuilders to test nios2/glibc, use a pre-built Bootlin toolchain.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Instead of using an external toolchain built specifically for the
autobuilders to test mipsel/uclibc, use a pre-built Bootlin toolchain.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Instead of using an external toolchain built specifically for the
autobuilders to test mipsel32r6/glibc, use a pre-built Bootlin
toolchain.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Instead of using an external toolchain built specifically for the
autobuilders to test Microblaze EL/uclibc, use a pre-built Bootlin
toolchain.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Instead of using an external toolchain built specifically for the
autobuilders to test m68k 5208/uclibc, use a pre-built Bootlin
toolchain.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Instead of using an external toolchain built specifically for the
autobuilders to test m68k 68040/uclibc, use a pre-built Bootlin
toolchain.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Instead of using an external toolchain built specifically for the
autobuilders to test ARMv7-M/uclibc, use a pre-built Bootlin
toolchain.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Instead of using an external toolchain built specifically for the
autobuilders to test ARMv7/musl, use a pre-built Bootlin toolchain.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Instead of using an external toolchain built specifically for the
autobuilders to test ARM Cortex-A9/glibc, use a pre-built Bootlin
toolchain. Since this was meant to test very recent version of
toolchain components, we use the bleeding edge toolchain variant.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Instead of using an external toolchain built specifically for the
autobuilders to test ARMv5/uclibc, use a pre-built Bootlin toolchain.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Instead of using an external toolchain built specifically for the
autobuilders to test ARCle HS38/uclibc, use a pre-built Bootlin toolchain.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Instead of using an external toolchain built specifically for the
autobuilders to test AArch64/glibc, use a pre-built Bootlin toolchain.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This will fix a build failure with libgpiod in version 1.6.2
Even though the examples are not built by default, we explicitly
disable them, to be future-proof in case that default changes in
the future.
Fixes:
- http://autobuild.buildroot.org/results/321004b185213099c7c5633b5ec35ceadd0293bc
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[yann.morin.1998@free.fr:
- keep dependencies first
- explicitly disable examples
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This reverts commit f2d6c5ff90.
Now that libbsd can't be enabled for static builds, we can drop the
workaround specific to stress-ng.
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Static linking with libbsd fails because of multiple definition of the
strlcpy symbol. uClibc optionally provides these symbols.
So add a dependency on dynamic library to avoid a build failure with a
zeromq-enabled bitcoin or with stress-ng.
Fixes:
- http://autobuild.buildroot.org/results/ba87544d42ad5e77a27a7a504bc6336a06f6e291
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
For instance on risc-v 64 arch the build would otherwise fail because
of undefined ucontext_t because "-DOPENSSL_NO_ASYNC" would not propagate
through to CFLAGS in the Makefile.
Signed-off-by: Yann Sionneau <ysionneau@kalray.eu>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
ffmpeg has been dropped since version 14.4.2 (back in 2013) and
5ae4049727
--disable-gomp has also been removed since version 14.4.1 (back in 2012)
and
84eaacb54f
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Commit f4a61d1ae2 (package/pkg-meson.mk avoid host ccache detection)
forced the host C and C++ compilers so that meson does not try to
autodetect ccache, and instead relies on what we provide.
However, this incorrectly used single-expansion of variables in a
package infra.
For traditional builds, this is OK, because the value does not change
across packages.
However, for builds with per-package directories, this value only refers
to the generic path, which ill not exist until the end of the build when
all packages are aggregated in the host-finalize step.
Fix that by postponing the variable evaluation like all the others.
Reported-by: Xogium on IRC
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This commit extends pkg-stats to leverage the recently introduced
CPEDB class to verify that the CPEs provided by Buildroot packages are
indeed known in the official CPE dictionnary provided by NVD.
Co-Developed-by: Grégory Clement <gregory.clement@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Python class which consumes a NIST CPE XML and provides helper
functions to access and search the db's data.
- Defines the CPE as a object with operations / formats
- Processing of CPE dictionary
Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Co-Developed-by: Grégory Clement <gregory.clement@bootlin.com>
Co-Developed-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
When using the headers from the kernel to be built, with the kernel
set to a custom version, and overriding the kernel sources with
LINUX_OVERRIDE_SRCDIR, the linux-headers package is still trying to
download an archive, and fails to validate its hash.
What is going on under the hood is that, with _OVERRIDE_SRCDIR, the
_VERSION of a package is set to 'custom'. Furthermore, the variable
BR_NO_CHECK_HASH_FOR is recursively expanded, so its value is only
evaluated when it is needed.
For linux-headers, we inherit the values from the linux package, and
the LINUX_HEADERS_VERSION takes the value from the configuration.
Thus we end up with the following situation:
LINUX_VERSION=custom
LINUX_HEADERS_VERSION=5.10 # For example
BR_NO_CHECK_HASH_FOR=... linux-custom.tar.gz ...
And thus the archive downloaded by linux-headers will not match any
exclusion, and since there will most probably not be a hash for it,
the download will fail, as was noticed and reported by Jarkko.
But in this case, what we really want is to really use the headers
from the kernel that we build, we do not even want to attempt a
download at all.
So, when using the headers from the kernel to be built, we also
propagate the LINUX_OVERRIDE_SRCDIR to linux-headers, so that we
also use the headers from the overridden sources.
Furthermore, in that configuration, we explicitly disallow
overriding the linux-headers specifically, as it does not make sense
(even though, if they were overridden to the same location, that'd
be OK, but to simplify the condition, we do not even check for that).
Reported-by: Jarkko Sakkinen <jjs@kapsi.fi>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
When cross-compiling grpc, a native tool 'grpc_cpp_plugin' is needed.
Patch '0001-target-build-using-host-plugin.patch' in Buildroot provides a
way to pass the path to this tool via a configure option
'gRPC_NATIVE_CPP_PLUGIN'.
In version 1.20.0, the upstream grpc project added better support for
cross-compiling via commit 0d7a0ded [1], searching for the native
grpc_cpp_plugin via PATH (rather than specifying it as configure option as
our patch was doing).
This change renders the mentioned Buildroot patch obsolete, so remove it.
[1] 0d7a0ded1c
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Reviewed-by: Michael Nosthoff <buildroot@heine.tech>
Tested-by: Michael Nosthoff <buildroot@heine.tech>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The check for a default route is inverted, causing the script to wait
for the timeout even when a default IPv6 route is available. Fix this up
so that it exits early as expected.
Reported-by: Bhattiprolu RaviKumar <ravikumar.bhattiprolu@gmail.com>
Signed-off-by: Samuel Mendoza-Jonas <sam@mendozajonas.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following security issues:
CVE-2021-3281: Potential directory-traversal via archive.extract()
The django.utils.archive.extract() function, used by startapp --template and
startproject --template, allowed directory-traversal via an archive with
absolute paths or relative paths with dot segments.
For details, see the advisory:
https://www.djangoproject.com/weblog/2021/feb/01/security-releases/
Additionally, 3.0.11 fixed a regression:
https://docs.djangoproject.com/en/3.1/releases/3.0.11/
Update indentation in hash file (two spaces).
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
From the announcement:
ChangeLog for Privoxy 3.0.31
--------------------------------------------------------------------
- Security/Reliability:
- Prevent an assertion from getting triggered by a crafted CGI request.
Commit 5bba5b89193fa. OVE-20210130-0001.
Reported by: Joshua Rogers (Opera)
- Fixed a memory leak when decompression fails "unexpectedly".
Commit f431d61740cc0. OVE-20210128-0001.
- Bug fixes:
- Fixed detection of insufficient data for decompression.
Previously Privoxy could try to decompress a partly
uninitialized buffer.
https://www.privoxy.org/announce.txt
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
