I would like to help maintaining the following defconfigs:
imx23evk_defconfig
imx6-sabreauto_defconfig
imx7dpico_defconfig
mx25pdk_defconfig
mx51evk_defconfig
mx53loco_defconfig
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 8cffa8163c)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Wireless support ends up enabling CONFIG_SYSTEM_TRUSTED_KEYRING, which
requires openssl to be available on the host, so disable wireless
support, which isn't needed in Qemu.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 5c5f1b0743)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The ORC unwinder requires libelf to be available on the host, so use
the frame pointer unwinder instead. Using the frame pointer unwinder
is probably good enough in our default Qemu configurations.
Wireless support ends up enabling CONFIG_SYSTEM_TRUSTED_KEYRING, which
requires openssl to be available on the host, so disable wireless
support, which isn't needed in Qemu.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 248161d6fa)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Some Linux kernel configuration options (such as CONFIG_UNWINDER_ORC)
require building a host program that needs libelf.
Users who have libelf installed on their system won't see a problem,
but users who don't have libelf installed will get a build
failure. Therefore, this commit adds an option that allows a user to
indicate that his Linux kernel configuration requires libelf. When
this option is enabled, we add host-elfutils to the dependencies of
the linux package (host-elfutils provides the libelf library).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit f7cd72b3d4)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Some Linux kernel configuration options (such as
CONFIG_SYSTEM_TRUSTED_KEYRING) require building a host program called
extract-cert, which itself needs OpenSSL.
Users having OpenSSL installed on their system won't see a problem,
but users who don't have OpenSSL installed will get a build
failure. This commit adds a new option that allows users to indicate
that their Linux configuration requires building host-openssl.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 93a7edf4bc)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
We were passing HOSTCFLAGS="$(HOSTCFLAGS)" to Linux. However:
- HOSTCFLAGS in Buildroot doesn't exist, and is empty, so this
assignment never did anything. The name of the variable in
Buildroot in HOST_CFLAGS.
- HOSTCFLAGS in Linux isn't used everywhere, and passing it overrides
the default HOSTCFLAGS value defined in the main Linux kernel
Makefile.
In addition, there is no way to pass additional host LDFLAGS in the
Linux kernel build system.
Therefore, we simply shoehorn our HOST_CFLAGS and HOST_LDFLAGS while
passing HOSTCC to the Linux kernel build system. This has been tested
to work fine with host OpenSSL and host libelf only available in
$(HOST_DIR).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Frank Hunleth <fhunleth@troodon-software.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit dde090c299)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This defconfig currently fails to build the Linux kernel:
https://gitlab.com/buildroot.org/buildroot/-/jobs/55306826
In addition, the U-Boot build had already been removed in commit
12c01e4a05
("configs/freescale_mpc8315erdb: remove U-Boot build"), back in
October 2016, and nobody bothered fixing it.
This defconfig was originally contributed and maintained by Gustavo
Zacarias, but he is no longer active in Buildroot, and nobody
expressed interest in this defconfig, so let's get rid of it.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit f08dd9f4cb)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The shell expands "$@" as "$1" "$2" "$3"... while it expands $@ as $1 $2
$3. With the second form, we loses spaces in positional parameters.
As example, the following call
pkg-config --cflags "one two" three
is wrapped as
pkgconf --cflags one two three
while we are expecting
pkgconf --cflags "one two" three
"$@" is really useful when writing wrappers. It passes the positional
arguments *as* they are given.
Double quote $@ to prevent from splitting elements.
Signed-off-by: Gaël PORTAY <gael.portay@savoirfairelinux.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit cc526b428b)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
For some boards, for example the Raspberry Pi, it's necessary to build
in-tree dts files as well as custom/out of tree dts-files (dt-blob.bin).
The existing logic made these two options exclusive, this commit changes
that to allow both in-tree as well as custom sources for dts files.
Signed-off-by: Simon van der Veldt <simon.vanderveldt@gmail.com>
[Arnout: re-wrap help, add extra empty line, change = into +=]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
(cherry picked from commit 382fe9f926)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The musl/kernel headers workaround was added in commit 196932cd91
(toolchain: workaround musl/kernel headers conflict) to fix definition
collisions in networking related headers between musl headers and kernel
headers. Kernel headers from version 4.15 and newer do not need this
workaround anymore since kernel commit c0bace798436bc (uapi libc compat:
add fallback for unsupported libcs). The C library does not have to
define the __GLIBC__ macro to make the __UAPI_DEF_* macros effective.
Updated the comment to accordingly.
Tested with the xl2tp package. This package fails to build with older
kernel headers without the workaround (struct in_pktinfo redefinition,
among others). With 4.15 headers, xl2tp builds fine with this patch
applied. That is, no workaround needed.
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 6afee03e3c)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Kernel version 4.15 (not 4.16 as the musl commit log claims) allows
disabling of more parts of the kernel headers definitions. Add upstream
musl patch that defines the relevant macros. This solves issues of
networking related symbols redefinition in kernel headers that cause
headers conflicts. With that in place a subsequent commit will limit the
musl/kernel headers conflict avoidance workaround in Buildroot to kernel
headers older than 4.15. This workaround has been introduced in commit
196932cd91 (toolchain: workaround musl/kernel headers conflict).
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit b99ca5ce32)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
There is no reason to have a BR2_JLEVEL option in such toolchain
defconfigs.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 14fdb63804)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
While we have several defconfigs building internal toolchains with
uClibc, we don't have any building internal toolchain with glibc and
musl. However, having such defconfigs is nice when we bump the C
library version, in order to immediately get feedback on build
failures.
Note that while the ARC internal defconfig uses glibc, it uses the
special ARC glibc version, so it doesn't test version bumps of the
upstream glibc C library.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 6030986311)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Recent systemd bump has broken DBus dameon and DBus applications can no
longer find the daemon. So we want to catch those kind of failures
early.
We also want to check that the system as a whole is stable: no unit
should be failed.
Finally, ensure that we can read the jounrnal, even when we are doing our
tricks on read-only systems.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently, we handle the factory by redirectoring /var with a symlink at
build time, and with some trickery during the filesystem generation,
depending on whether we need to remount the filesystem read-write or
not.
However, this is causing quite some pain with the latest systemd, now that
they have moved their dbus socket to /run instead of /var/run.
As such, trying to play tricks with /var/run as a symlink is difficult,
because at times it is in .usr/share/factory/var/run (during build) and
then it is in /var/run (at runtime). So a relative symlink is not
possible. But an absolute symlink is not possible either, because we are
installing out-of-tree.
Oh the joys of cross-compilation... :-)
We fix all this mess by making /var a real directory from the onset, so
that we can use the runtime-expected layout even during the build.
Then, during filesystem generation, we move /var away to the factory,
and populate it as we used to do. This still requires a post-fs hook to
restore /var after the filesystem generation.
This leaves a situation that, should the filesystem generation fails,
/var will be left in an inconsistent state. But that is not worse than
what we already had anyway.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Cc: Trent Piepho <tpiepho@impinj.com>
Cc: Adam Duskett <aduskett@gmail.com>
Cc: Romain Naour <romain.naour@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When using a RO root with systemd, it is intended that /var/lib should be
populated at boot time by tmpfiles system mirroring it from
/usr/share/factory/var/lib.
However, this will only happen if /var/lib does not already exist at the
time systemd-tmpfiles runs. If it does exist, then tmpfiles will
(silently) skip it and do nothing.
It turns out /var/lib will exist, because some part of systemd creates
/var/lib/systemd/catalog on boot before tmpfiles runs.
The fix used here is to also create tmpfiles entries for the contents of
/var/lib/* and /var/lib/systemd/*. This way, when those directories
already exist, the entire tree is not skipped and instead the
not-yet-existing contents of /var/lib and /var/lib/systemd will be still
be mirrored from the factory dir.
And if /var/lib/systemd, or a prefix of that, stops getting created and
does not exist, it'll still mirror properly.
It does cause some warnings from systemd:
systemd[1]: Starting Create Volatile Files and Directories...
systemd-tmpfiles[148]: [/etc/tmpfiles.d/var-factory.conf:7] Duplicate line for path "/var/lib/systemd", ignoring.
systemd-tmpfiles[148]: [/etc/tmpfiles.d/var-factory.conf:8] Duplicate line for path "/var/lib/systemd/coredump", ignoring.
But they can be ignored.
IMHO, I think a better solution would be for systemd-tmpfiles to gain a
"merge tree" operation that is like "C" but doesn't abort if the
destination exists, but rather merges the source into it.
Signed-off-by: Trent Piepho <tpiepho@impinj.com>
[yann.morin.1998@free.fr: slight rework of commit title]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Tested-by: Adam Duskett <aduskett@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Some packages really want to use an UTF-8 locale, or they break.
However, there is no guarantee that any given locale is available on a
system. For example,, while most mainstream distros (Debian and
derivatives, Fedora...) do have the generic, language-agnostic C.UTF-8
locale, Gentoo does not provide it.
So, find the first UTF-8 locale available on the system, and take any
that is available. We however do favour using the user-set current
locale, then using the language-agnostic C.UTF-8, and eventually any
random UTF-8 locale.
Note: we only need to enforce LC_ALL, because setting it implies
everything else:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_02
"""
1. If the LC_ALL environment variable is defined and is not null,
the value of LC_ALL shall be used.
"""
[Peter: use same regexp as in dependencies.sh]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Although the UTF-8 locales in mainstream distributions all are suffixed
with just 'utf8', the nomenclature is a bit ambiguous with the way they
are to be specified with the various LC_* variables, suffixed there with
'UTF-8'.
Also, POSIX, ISO, and IEC do not enforce any specific suffix in LC_*
variables:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_02
"""
If the locale value has the form:
language[_territory][.codeset]
it refers to an implementation-provided locale, where settings of
language, territory, and codeset are implementation-defined.
"""
To avoid any confusion, use a regexp that is a bit more lax when
matching locales.
Also, quote the regexp, so that the '?' and '$' are not interpreted by
the shell.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
udevd needs extra groups for its bundled rules:
Mar 03 12:21:30 buildroot systemd-udevd[732]: Specified group 'render' unknown
Mar 03 12:21:30 buildroot systemd-udevd[732]: Specified group 'kvm' unknown
Add those missing groups.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Cc: Julius Kriukas <julius@kriukas.lt>
Cc: Trent Piepho <tpiepho@impinj.com>
Cc: Adam Duskett <aduskett@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
CVE-2018-5732: The DHCP client incorrectly handled certain malformed
responses. A remote attacker could use this issue to cause the DHCP
client to crash, resulting in a denial of service, or possibly execute
arbitrary code. In the default installation, attackers would be isolated
by the dhclient AppArmor profile.
CVE-2018-5733: The DHCP server incorrectly handled reference counting. A
remote attacker could possibly use this issue to cause the DHCP server
to crash, resulting in a denial of service.
Both issues are fixed in version 4.4.1. But we are close to release, so
backport the fixes instead of bumping version.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
