support/scripts/boot-qemu-image.py: wait before using expect
As reported by a gitlab runtime test [1] and on the mailing list
[2], some runtime tests are failing on slow host machines when
the qemu-system-<arch> is missing on the host.
The boot-qemu-image.py script need to wait some time after
calling pexpect.spawn() in order to make sure that the qemu
process has been executed in start-qemu.sh.
If start-qemu.sh failed due to missing qemu-system binary
an exception will be thrown by child.expect() and should be
catched by the error handling (pexpect.EOF).
After spending a lot of time to investigate with Yann E. MORIN
[3]. It seems that short-lived child processes are a corner-case
that is not very correctly handled...
Without adding a sleep(1), child.expect() can trigger an
exception before setting the exitstatus of the spawned
process. This issue can be reproduced on a gitlab runner or
by adding "exit 1" in the first line of start-qemu.sh
(after the shebang).
There is even the same workaround in some pexpect examples [4].
Thanks to Yann for the help while investigating the issue.
Adam Duskett [Sat, 18 Apr 2020 19:07:01 +0000 (12:07 -0700)]
packageJopenjdk: add support for building the full jdk
Some users may require the full JDK on the target to debug their programs.
This change is relatively trivial to add.
While the full JDK does have programs used for compiling on a target,
which is against Buildroot policy, the JDK also has several utilities used for
debugging purposes, which the JRE target does not build, and Buildroot supports
applications used for debugging purposes such as GDB.
As such, JDK support should be available for debugging purposes, and a note in
the Config.in file has been added under the JDK section, which informs the user
that JDK support is for debugging purposes only and that developing on a
target is not supported by Buildroot.
Adam Duskett [Sat, 18 Apr 2020 19:07:00 +0000 (12:07 -0700)]
package/openjdk: copy all directories and files when installing
Several directories and files are currently not installed during the
target installation, these include:
- conf
Several configuration files, including security configuration files which
may be necessary for running various java applications.
- legal
This directory contains legal notices that some java applications may
require, as they may print legal information and will throw exceptions at
runtime if the legal files are not present on the system.
- release
This file contains a list of modules included in the image.
Because these directories take up less than of megabyte extra, it is not an
issue to install all of them.
Giving an explicit getty port is not really needed, as we already
spawn a getty on the "console" device, which will match the serial
port passed as console= argument on the kernel command line.
Adam Duskett [Sat, 18 Apr 2020 19:06:59 +0000 (12:06 -0700)]
package/openjdk: fix installation with merged usr directories
Currently, Buildroot installs the jre libraries using
cp -dprf /build/linux-*-release/images/jre/lib/* $(TARGET_DIR)/usr/lib/
However, if a system has a merged /usr directory, and there is a built kernel
before installing OpenJDK, the installation fails because jre/lib has binary
modules file, which causes the following error: cp: cannot overwrite directory
'/usr/lib/modules with non-directory
The obvious fix is to install the modules to /usr/lib/jvm/ and set the
appropriate rpaths via the --with-extra-ldflags conf option. However, this fix
does not work because the built binaries themselves do not link against
libjava.so
Indeed, running readelf on the built java binary reports the following:
"(RUNPATH) Library runpath: [/usr/lib/jvm]" and /usr/lib/jvm/libjava.so exists.
However, when running the Java binary on the target, the following error
occurs: "Error: could not find libjava.so."
The following is the result of "strace java" ran on the target:
faccessat(AT_FDCWD, "/usr/lib/libjava.so", F_OK) = -1 ENOENT
faccessat(AT_FDCWD, "/usr/jre/lib/libjava.so", F_OK) = -1 ENOENT
newfstatat(AT_FDCWD, "/usr/lib/libjava.so", 0x7ffe7b4af8, 0) = -1 ENOENT
newfstatat(AT_FDCWD, "/usr/lib/jvm/libjli.so", [sic] AT_SYMLINK_NOFOLLOW) = 0
As seen above, the java binary searches for libjli.so in /usr/lib/jvm,
which demonstrates that the java binary searches for some of the
DT_NEEDED libraries using the correct rpath. But libjava.so is not
searched from the rpath; it is instead dl-opened manually, looked for in
the search paths hardcoded to the following directories:
- /usr/lib/
- /usr/jre/lib/
- $(dirname $0)/../lib/
The reason behind the hardcoded paths given by the maintainers is due to
historical purposes for the need to support several java versions at the
same time on a single system, and that changing the above behavior is not
likely to ever happen.
As such, most distributions such as Redhat do the following:
- Create the directory /usr/lib/jvm/java-$(JAVA_VERSION)/
- Install all directories and files found in images/jre to that directory.
- Symlink the binaries to in /usr/lib/jvm/java-$(JAVA_VERSION)/bin to
/usr/bin.
However, because Buildroot does not need to support multiple versions of java
concurrently, there is no need for the additional java-$(JAVA_VERSION)
directory.
To fix the above issue, the following changes are performed:
- Introduce the variable "OPENJDK_INSTALL_BASE" which points to /usr/lib/jvm
- Set the --with-extra-ldflags conf_opt to
"-Wl,-rpath,$(OPENJDK_INSTALL_BASE)/lib,-rpath,
$(OPENJDK_INSTALL_BASE)/lib/$(OPENJDK_JVM_VARIANT)"
- Run "mkdir -p $(TARGET_DIR)/usr/lib/jvm/" in the INSTALL_TARGET_CMDS step.
- Copy both the lib and bin directories to /usr/lib/jvm/
- Symlink the binaries in /usr/lib/jvm/bin/ to /usr/bin.
Yegor Yefremov [Tue, 10 Mar 2020 11:41:01 +0000 (12:41 +0100)]
package/python-markdown: fix Python version dependency
Since upstream commit
https://github.com/Python-Markdown/markdown/commit/dab931f597cdc5b57d4e2458840fb991606506bc,
merged since version 3.2 of python-markdown, the Python 2.x support
has been dropped.
So our commit 6e538bf642d3584032d63bb54d24b88ab57e4283
("package/python-markdown: bump to version 3.2.1") should have made
python-markdown available only for Python 3.x.
John Keeping [Wed, 11 Mar 2020 11:22:56 +0000 (11:22 +0000)]
package/libglib2: restore use of system printf
Prior to commit 4102db0f7a ("package/libglib2: bump to version 2.60.3")
which converted libglib2 to meson, Buildroot used to set a range of
autoconf options to bypass tests that require running binaries.
The meson version of libglib2's build system has many fewer of these
checks, but there are still some and these can be fed the "correct"
answer by adding properties to cross-compilation.conf.
Add the necessary properties to indicate that we have C99 compliant
print functions to avoid pulling in the gnulib fallback.
The libssh server is used by libnetconf2. With libssh version 0.9.4 a
regression was introduced that wrongly leads to session closed after the
poll timeout.
This fixes CVE-2020-1967:
Server or client applications that call the SSL_check_chain() function during
or after a TLS 1.3 handshake may crash due to a NULL pointer dereference as a
result of incorrect handling of the "signature_algorithms_cert" TLS extension.
The crash occurs if an invalid or unrecognised signature algorithm is received
from the peer. This could be exploited by a malicious peer in a Denial of
Service attack. OpenSSL version 1.1.1d, 1.1.1e, and 1.1.1f are affected by this
issue. This issue did not affect OpenSSL versions prior to 1.1.1d.
See https://www.openssl.org/news/secadv/20200421.txt
Also update the hash file to the new two spaces convention
configs/engicam_imx6qdl_icore_qt5_defconfig: needs udev to select glmark2
The BR2_PACKAGE_GLMARK2 is lost while loading the defconfig with:
make engicam_imx6qdl_icore_qt5_defconfig
In order to select gmark2 package, BR2_PACKAGE_GLMARK2_FLAVOR_ANY option
must be set.
Based on the defconfig without X11 and wayland package, the only missing
option to select BR2_PACKAGE_GLMARK2_FLAVOR_ANY is BR2_PACKAGE_HAS_UDEV.
The only possible option is to enable one of the udev provider
(eudev or systemd). Select eudev package for /dev management.
This defconfig use a custom defconfig file located
in board/friendlyarm/nanopi-r1/uboot/nanopi_r1_defconfig.
BR2_TARGET_UBOOT_BOARD_DEFCONFIG is used to provide the name
of a in-tree defconfig. Since a custom defconfig is used,
this option is lost while loading the defconfig with:
make nanopi_r1_defconfig
configs:minnowboard_max-graphical_defconfig: re-enable GLX support
This defconfig loses mesa3d-demo and glmark2 package since commit 5cb821d5635626b7327d5d704555c412e5ed5a1f that introduced an
explicit option to enable GLX support.
board/amarula/a64-relic/readme.txt makes use the host fastboot utility
to flash the board. However, BR2_PACKAGE_HOST_ANDROID_TOOLS_FASTBOOT
(which is enabled in the defconfig) has a dependency on
BR2_PACKAGE_HOST_ANDROID_TOOLS, which is not enabled in the
defconfig. Due to this, BR2_PACKAGE_HOST_ANDROID_TOOLS_FASTBOOT=y is
lost when loading the defconfig.
yaml-cpp builds only a static library by default, this will raise a
build failure with upcoming mongodb 4.2.x as reported by Ryan Barnett
due to mongodb linking with a static library that obviously will miss
-fPIC
Thomas Petazzoni [Tue, 21 Apr 2020 19:30:41 +0000 (21:30 +0200)]
DEVELOPERS: fix typo in nanopi-neo4 board name
Commit 84ba2e8bf5f1e3a9d0d01a577f72cfd51f88a7b6 got the path to
board/friendlyarm/nanopi-neo4/ wrong in the DEVELOPERS file when
adding a new defconfig nanopi_neo4_defconfig. Let's fix the typo.
Commit 791292c48d5165515ca08f35d8cbc1ef78d3ed95 forgot to add
!BR2_PACKAGE_PYTHON dependency, without it the following error will be
raised if the user selects BR2_PACKAGE_PYTHON and python-selinux:
Also:
* Drop patch 0001 (fix static linking of libmagic) applied upstream
* Add optional dependency on libmatroska
* Add upstream patch to fix building with libmatroska
* Adjust spacing in hash file to 2 spaces
Vincent Fazio [Tue, 4 Feb 2020 21:35:48 +0000 (15:35 -0600)]
toolchain/toolchain-buildroot: PPC64(LE) support in musl requires ALTIVEC
musl currently assumes all PPC64(LE) CPUs support ALTIVEC instructions.
However, there are exceptions (such as the e5500) for which musl builds
ultimately generate illegal instructions for the targets.
Disable musl if the PPC64(LE) CPU does not support ALTIVEC instructions.
This patch addresses the issues seen here:
https://gitlab.com/kubu93/toolchains-builder/-/jobs/418092743
https://gitlab.com/kubu93/toolchains-builder/-/jobs/418092744
musl mailing list thread:
https://www.openwall.com/lists/musl/2020/02/03/10
package/libselinux: fix glibc build with old toolchains
For an unknown reason, since bump to version 3.0.0, we got build failure
due to -D_FILE_OFFSET_BITS==64:
/home/naourr/work/instance-2/output-1/host/arm-buildroot-linux-gnueabi/sysroot/usr/include/fts.h:41:3: error: #error "<fts.h> cannot be used with -D_FILE_OFFSET_BITS==64"
# error "<fts.h> cannot be used with -D_FILE_OFFSET_BITS==64"
^
Update our workaround to also filter CPPFLAGS fix the issue and seems
right as we're doing it for all the other affected packages
(restorecond, elfutils ...)
Commit 24c66484e1 (package/qt5: bump minimum gcc requirement to 5.0)
increased the dependency on the gcc version, but used the incorrect
BR2_TOOLCHAIN_GCC_AT_LEAST_5_0, instead of BR2_TOOLCHAIN_GCC_AT_LEAST_5.
Yann E. MORIN [Sat, 28 Mar 2020 08:28:08 +0000 (09:28 +0100)]
package/apparmor: add option to install generic profiles
The apparmor packages comes with a set of profiles for a class of usual,
mostly server-class programs and daemons.
Even though an embedded device will mostly require custom profiles, the
generic ones may come handy, as they also provide "abstractions", that
can serve as templates for custom profiles.
Yann E. MORIN [Sun, 29 Mar 2020 07:55:01 +0000 (09:55 +0200)]
package/apparmor: add options to install utils
Most utilities are written in python3, except a few that are written in
a mixture of POSIX shell, bash, perl and awk.
The Makefile does not allow installing parts of it, but requiring all of
python3, bash, and perl to install the utils is too much of a
requirement.
Instead, we split the set in two, on one hand the python ones, which we
install when python3 is enabled, and on the other hand, the rest of the
script which we call 'extras', and which we install when all the extra
requirements (bash, perl, and busybox or gawk) are met; if not, then we
remove these extras utils as a post-install hook.
The various AppArmor utilities are spread in a few sub-directories of
the apparmor source tree. For now, we build only the parser, but we'll
soon introduce support for a few other utilities, so we prepare the
package to be able to build more than just the parser, hence the
slightly convoluted build and install commands, and the use of the
APPARMOR_TOOLS and APPARMOR_MAKE_OPTS variables, which will come handy
in the following commits.
We must ensure the version matches that of libapparmor, but there is not
much we can do to enforce that, so as we do for various other packages,
we just add a comment to that effect.
Using AppArmor requires support in the kernel, so do for AppArmor what
we did for SElinux, and enabled the necessary options.
Note that a single LSM can be the default one, so as of today, SELinux
wins, by virtue of being the last to be enabled.
Signed-off-by: Angelo Compagnucci <[email protected]>
[[email protected]:
- don't force DEFAULT_SECURITY_APPARMOR, it does not exist in all
kernel versions
- move closer to SELinux
- split into its own patch, write a commit log
] Signed-off-by: Yann E. MORIN <[email protected]> Tested-by: Angelo Compagnucci <[email protected]>
The layout of the package is not amenable to building both the library
and the utilities at once, so this package will only install the
library.
The other apparmor-related tools however will almost all want to always
link with the static library (it's hard-coded in their Makefiles, like:
AALIB = -Wl,-Bstatic -lapparmor -Wl,-Bdynamic -lpthread), so we also
force the build of the static library.
The kernel headers 3.16 at least are required, for CAP_AUDIT_READ.
We need to force the C standard to gnu99, otherwise:
- autoconf uses wchar_t in C99 test, so considers it to be missing
on toolchains without wchar, but wchar is not otherwise needed for
libapparmor;
- c99 is not enough, otherwise the build fails with errors like:
kernel.c:503:15: error: expected declaration specifiers or ‘...’ before ‘(’ token
extern typeof((__change_hat)) __old_change_hat __attribute__((alias ("__change_hat")));
^
package/nfs-utils: fix build failure with musl libc
Musl libc defines time_t as 64-bit causing printf() to fail since it
tries to pass time_t as a 32-bit("%ld"). So let's add upstream patch[1]
to fix this issue.
package/nftables: use bundled mini-gmp without full-blown system gmp
ntables bundles a mini implementation of gmp that can be used if the
system lacks the full-blown gmp.
Signed-off-by: Adrien Gallouët <[email protected]>
[[email protected]:
- explicitly disable mini-gmp when full one is enabled
- reword and expand commit log
] Signed-off-by: Yann E. MORIN <[email protected]>
When threads are enabled, haproxy expects that pthread_getcpuclockid is
available which is not the case on m68k. Fix this by enabling threads
support only if NPTL is available.
When host compiler is gcc 10 (for example on Fedora 32), dtc 1.5.1
fail to build with the error:
/usr/bin/ld: dtc-parser.tab.o:(.bss+0x20): multiple definition of `yylloc'; dtc-lexer.lex.o:(.bss+0x0): first defined here
collect2: error: ld returned 1 exit status
lvmetad is usually combined with event-based system services that
automatically run pvscan --cache on disks added or removed. This
way, the cache is automatically updated with metadata from new disks
when they appear. LVM udev rules and systemd services implement this
automation. Automatic scanning is usually combined with automatic
activation. For more information, see pvscan(8).
Fix CVE-2020-11647: In Wireshark 3.2.0 to 3.2.2, 3.0.0 to 3.0.9, and
2.6.0 to 2.6.15, the BACapp dissector could crash. This was addressed
in epan/dissectors/packet-bacapp.c by limiting the amount of recursion.
Philippe Reynes [Fri, 3 Jan 2020 15:16:57 +0000 (16:16 +0100)]
package/ibm-sw-tpm2: new package
This project is an implementation of the TCG TPM 2.0 specification. It
is based on the TPM specification Parts 3 and 4 source code donated by
Microsoft, with additional files to complete the implementation.
projects / buildroot-mgba.git / log