Notice: 5.5.x is now EOL, so should be dropped at the next version bump.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Petr Vorel <petr.vorel@gmail.com>
[yann.morin.1998@free.fr: two spaces in hash file]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
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.
Tested:
https://gitlab.com/kubu93/buildroot/pipelines/138472925
[1] https://gitlab.com/kubu93/buildroot/pipelines/135487475
[2] http://lists.busybox.net/pipermail/buildroot/2020-April/280037.html
[3] http://patchwork.ozlabs.org/project/buildroot/patch/20200418161023.1221799-1-romain.naour@gmail.com/
[4] https://github.com/pexpect/pexpect/blob/master/examples/ssh_tunnel.py#L80
Fixes:
https://gitlab.com/kubu93/buildroot/-/jobs/509053135
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
[yann.morin.1998@free.fr: reorder imports]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
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.
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
Reviewed-by: Ryan Barnett <ryan.barnett@rockwellcollins.com>
Tested-by: Ryan Barnett <ryan.barnett@rockwellcollins.com>
[yann.morin.1998@free.fr:
- s/OPENJDK_INSTALL_DIR/OPENJDK_VARIANT/
- slightly rewrap help text
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Sparc support is deprecated and may be removed in future releases. There are
two choices to fix this issue:
1) Set --enable-deprecated-ports=yes in the CONF_OPTS to supress the error.
2) Remove support for Sparc.
Because this port is deprecated, it's safer to remove support alltogether.
Fixes:
http://autobuild.buildroot.net/results/692820b4b6d4da42cd557fa7badbbd11806bbeba/
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
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.
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
Reviewed-by: Ryan Barnett <ryan.barnett@rockwellcollins.com>
Tested-by: Ryan Barnett <ryan.barnett@rockwellcollins.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
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.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
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.
Fixes: https://bugs.busybox.net/show_bug.cgi?id=12751
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
Reviewed-by: Ryan Barnett <ryan.barnett@rockwellcollins.com>
Tested-by: Ryan Barnett <ryan.barnett@rockwellcollins.com>
[yann.morin.1998@free.fr: fix two remaining mis-placed '/']
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Since upstream commit
dab931f597,
merged since version 3.2 of python-markdown, the Python 2.x support
has been dropped.
So our commit 6e538bf642
("package/python-markdown: bump to version 3.2.1") should have made
python-markdown available only for Python 3.x.
Fixes:
http://autobuild.buildroot.net/results/6d1e796f6658accb3eafef265935db5e464638fe
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Reviewed-by: Asaf Kahlon <asafka7@gmail.com>
Tested-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou@trabucayre.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
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.
Signed-off-by: John Keeping <john@metanate.com>
Reviewed-by: Peter Seiderer <ps.report@gmx.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This version includes a new binary named "ualpn", a proxying
ACMEv2 tls-alpn-01 responder.
Signed-off-by: Nicola Di Lieto <nicola.dilieto@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Since upstream commit 71f81bf83d3a1d4c564131ed7408f4d7ffe79242, cbor2
is needed by crossbar. This commit first appeared in crossbar release
v19.3.1, which means it is needed since the version bump that took
place in Buildroot commit 44a9f390ef.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/517918425
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
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.
The patch comes from upstrem:
https://git.libssh.org/projects/libssh.git/commit/?id=6417f5a3cac8537ac6f6ff7fc1642dfaa0917fb4
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
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
Signed-off-by: Titouan Christophe <titouan.christophe@railnova.eu>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This option never existed in opensbi package.
This fixes the new defconfig check.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The BR2_SOFT_FLOAT option is lost while loading the defconfig with:
make qemu_ppc_virtex_ml507_defconfig
On powerpc, BR2_POWERPC_SOFT_FLOAT must be used to enable soft
floating point support.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Since 2e71b396a1, this defconfig needs
a glibc toolchain to select sunxi-mali-mainline package.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Francois Perrad <francois.perrad@gadz.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
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.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This option has been removed since 6836f2a70a.
This fixes the new defconfig check.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Acked-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
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
This fixes the new defconfig check.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This defconfig loses mesa3d-demo and glmark2 package since commit
5cb821d563 that introduced an
explicit option to enable GLX support.
This fixes the new defconfig check.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The ext4 option is BR2_TARGET_ROOTFS_EXT2_4 not
BR2_TARGET_ROOTFS_EXT_4.
This fixes the new defconfig check.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
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.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Jagan Teki <jagan@amarulasolutions.com>
[Thomas: change to add BR2_PACKAGE_HOST_ANDROID_TOOLS=y]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
License file change was a date update to 2020
e114fa2672 (diff-9879d6db96fd29134fc802214163b95a)
Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
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
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
paho-c-mqtt 1.3.2 is a maintenance release. It fixes many bugs
including memory leaks and segmentation faults.
Release notes: https://github.com/eclipse/paho.mqtt.c/milestone/7?closed=1
Signed-off-by: Julien Grossholtz <julien.grossholtz@openest.io>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Commit 84ba2e8bf5 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.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Commit 791292c48d 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:
WARNING: unmet direct dependencies detected for BR2_PACKAGE_PYTHON3
Depends on [n]: !BR2_PACKAGE_PYTHON [=y] && BR2_USE_WCHAR [=y] && BR2_USE_MMU [=y] && BR2_TOOLCHAIN_HAS_THREADS [=y] && !BR2_STATIC_LIBS [=n]
Selected by [y]:
- BR2_PACKAGE_SELINUX_PYTHON [=y] && BR2_USE_MMU [=y] && BR2_USE_WCHAR [=y] && BR2_TOOLCHAIN_HAS_THREADS [=y] && !BR2_STATIC_LIBS [=n]
Fixes:
- No autobuilder failures yet
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[yann.morin.1998@free.fr: add dependency on MMU]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
