Since the toolchain Bootlin update to 2023.11-1 [1], the arm Linux
kernel build is broken with binutils >= 2.41 with:
arch/arm/mm/proc-v7.S: Assembler messages:
arch/arm/mm/proc-v7.S:640: Error: junk at end of line, first unrecognized character is `#'
A similar issue has already be fixed for qemu m68k [2].
Bump to the latest kernel 4.19 that already include the backport
of 790756c7e022 ("ARM: 8933/1: replace Sun/Solaris style flag on section directive")
[1] 7e0e6e3b86
[2] a1ce9474e4
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/6703222383
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit 7e126bd38d)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The commit [1] updated the u-boot version with the one used by
orangepi_zero_plus2_defconfig but the dependency on openssl
was forgotten.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/6703221868
[1] eb16148ddd
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit bc75b09b1c)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
TestATFVexpress is using vexpress_aemv8a_juno as as u-boot defconfig
but the Buildroot defconfig of this board was removed in 2022.11 [1]
Since both TestATFVexpress and TestATFAllwinner are now using mainline
ATF, we don't really need several ATF test anymore. Initially [2],
several runtime test were added to test ATF/U-Boot combinations when
ATF was provided by a vendor: vexpress (mainline), Allwinner and
Marvell.
Keep TestATFAllwinner as ATF mainline test.
[1] 347c108738
[2] 8cf3ce04e9
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 107bcd536d)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
u-boot-2021.04 seems to be broken when pylibfdt support is enabled
and the latest python3/setuptools are used.
Since the TestATFAllwinner is using bananapi_m64 as u-boot defconfig
but the Buildroot defconfig of this board was removed in 2022.11 [1]
update TestATFAllwinner to use a newer BSP. Use the one provided
by orangepi_zero_plus2_defconfig.
[1] daf3c6661f
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/6477656317 (TestATFAllwinner)
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit eb16148ddd)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since the toolchain Bootlin update to 2023.11-1 [1], the arm Linux
kernel build is broken with binutils >= 2.41 with:
arch/arm/mm/proc-v7.S: Assembler messages:
arch/arm/mm/proc-v7.S:640: Error: junk at end of line, first unrecognized character is `#'
A similar issue has already be fixed for qemu m68k [2].
Bump to the latest kernel 4.19 that already include the backport
of 790756c7e022 ("ARM: 8933/1: replace Sun/Solaris style flag on section directive")
[1] 7e0e6e3b86
[2] a1ce9474e4
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/6414160106 (TestFileCapabilities)
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 07ef00df9b)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The trace-cmd runtime test has a typo and fails with output:
Traceback (most recent call last):
File "/build/buildroot/support/testing/tests/package/test_trace_cmd.py", line 53, in test_run
self.assertEquals(exit_code, 0)
^^^^^^^^^^^^^^^^^
AttributeError: 'TestTraceCmd' object has no attribute 'assertEquals'. Did you mean: 'assertEqual'?
The issue can be reproduced with the command:
support/testing/run-tests \
-d dl -o output_test \
tests.package.test_trace_cmd
This commit fixes the issue by removing the extra 's'.
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 2f507f1da5)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
codesourcery arm/aarch64 toolchains are old (2014) and use glibc
2.18/2.20 which are not compatible with 64-bit time_t raising the
following build failure with libcgroup since commit
1c2dbcdcf0:
In file included from ./libcgroup-internal.h:25:0,
from parse.y:21:
/home/buildroot/autobuild/run/instance-3/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"
^
Fixes: 1c2dbcdcf0
- http://autobuild.buildroot.org/results/e28f955f2b360f6e7bb231a5a3800cfbd17a23d7
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[Peter: add Config.in.legacy entries]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 53a8c5150e)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
As expected by Peter in [1], the hardcoded 3 seconds for waiting the
RAID array to rebuild are not enough on slow test host runners. This
test already failed at least once for that reason, in [2].
In order to fix those failures, this commit adds extra logic to allow
several attempts, before failing. The timeout is currently set at 10
attempts, waiting 3 seconds between each attempts. To help even more,
those 3 seconds are also scaled with the timeout_multiplier.
Fixes: [2]
[1] https://lists.buildroot.org/pipermail/buildroot/2024-February/685034.html
[2] https://gitlab.com/buildroot.org/buildroot/-/jobs/6137469690
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Commit dfed5acb56 ("utils/check-package: use https for the manual URL")
replaced the default url to the Buildroot manual while it was used
by TestCheckPackage test.
Update TestCheckPackage with https url.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/6224243484
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Instead of waiting for a hardcoded time of 30s we check periodically every
second if the server is already up. If it isn't up after the full timeout
(which is the same as before) expired the test fails.
We need to redirect all output of the background started task to
/dev/null now as it otherwise confuses the emulator.run() exit code
parsing logic (as it gets out of order messages from the emulator).
Signed-off-by: Marcus Hoffmann <buildroot@bubu1.eu>
yann.morin.1998@free.fr: simplify assert test]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Similar to the new fastapi test, instead of waiting for a hard coded
amount of time we can retry every second until the server is available
and abort if after the timeout we still didn't manage to connect.
Signed-off-by: Marcus Hoffmann <buildroot@bubu1.eu>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
gpg key generation can take longer than the default timeout on a
loaded or slow test host. The commit increase the timeout for the
key generation command to prevent the test to randomly fail.
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The symmetric encryption test can sometimes take longer than the default
timeout. This commit increase the timeout to 10 seconds for that
command.
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
TestGlxinfo fail with a new runtime error:
# glxinfo -B -display :0
name of display: :0
traps: glxinfo[84] trap invalid opcode ip:b73c7027 sp:bf8433c0 error:0 in swrast_dri.so[b6e4c000+64f000]
Illegal instruction
The x86-core2 Bootlin toolchains are built for a core2 CPU [0],
this means that the Bootlin toolchains may use core2-specific
instructions.
The TestGlxinfo test is setup for BR2_x86_core2, so our
executables will also contain core2 instructions.
However, the default Qemu x86 is not guaranteed to emulate all the
instructions specific to core2, causing runtime issues as reported
above.
A similar issue has been fixed by adding Nehalem cpu emulation on
the qemu command line. See 4f565b5222 ("support/testing: use Nehalem
cpu emulation for TestGrubX8664EFI").
Set core2duo cpu emulation for TestGlxinfo on the qemu command line.
[0] https://gitlab.com/buildroot.org/toolchains-builder/-/blob/kubu/toolchain-builder-2023.08/configs/arch/x86-core2.config?ref_type=heads
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The current package has not recieved an update since Sat Oct 9 2021
33ece2446e and is not python 3.12 compatible.
Furthermore, the current version requires at least 42 new packages worth of
depedencies of which several require patches to be python 3.12 compatible.
As nobody has stepped up to maintain the package and its ever-growing list of
dependencies, along with the other problems, it is time to drop the package.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Add a runtime test for fastapi. Use uvicorn as the asgi server
application as does the fastapi hello world example [1].
Fastapi depends on PydanticV2 now which is written in rust so we need to
run the test on armv7.
[1] https://fastapi.tiangolo.com/tutorial/first-steps/
Signed-off-by: Marcus Hoffmann <bubu@bubu1.eu>
[Arnout:
- fix flake8 errors
support/testing/tests/package/sample_python_fastapi.py:5:1: E302 expected 2 blank lines, found 1
support/testing/tests/package/sample_python_fastapi.py:8:1: W391 blank line at end of file
- Remove BR2_CCACHE (as requested by Marcus).
- Add a comment explaining that this also tests uvicorn and pydantic.
- Re-try wget in a loop instead of a fixed timeout of 30 seconds.
- Add a DEVELOPERS entry.
]
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Under some conditions (mostly slow execution due to test host load),
the netcat runtime test can randomly fail. This is due to several
facts:
- the sleep time between the server and client is too short,
- the use of netcat option -c could close the connection before the
server could receive all the data.
This commit improves the test robustness by increasing the sleep time,
and by reducing the amount of transferred data (from 1MB of random data,
to a simpler string of few bytes). Also, to make sure netcat cannot wait
on DNS resolution, this commit also adds the -n option.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/6093854664
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
In commit 7e0e6e3b86 (toolchain/toolchain-external/toolchain-external-bootlin:
update to 2023.11-1) the TestGrubX8664EFI fails with this error:
# efivar -l
traps: efivar[86] trap invalid opcode ip:7fc187f4c7f4 sp:7fff9bbaa930 error:0 in libefivar.so.1.38[7fc187f4c000+16000]
Illegal instruction
This error can be reproduced by installing other packages like "file".
The 2023.11-1 Bootlin toolchains are built for a corei7 CPU [0], which
is in fact a Nehalem CPU; we switched to the new names in commit
653fa001f3 (arch/Config.in.x86: add "newer" names for several Intel
x86 CPU variants). This means that the Bootlin toolchains may use
Nehalem-specific instructions.
The TestGrubX8664EFI test is also setup for BR2_x86_corei7, so our
executables will also contain Nehalem instructions.
However, the default Qemu x86_64 is not guaranteed to emulate all the
instructions specific to Nehalem, causing runtime issues as reported
above.
A similar issue has been fixed in toolchain-builder by adding Nehalem
cpu emulation on the qemu command line [0].
Fixes: https://gitlab.com/buildroot.org/buildroot/-/jobs/6093853712
[0] f2b253732b
Signed-off-by: Romain Naour <romain.naour@smile.fr>
[yann.morin.1998@free.fr:
- reword the commit log to explain corei7 -> Nehalem equivalence
- note that the toolchain-builder *and* our test target corei7, thus
Nehalem
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Marcus Hoffmann <bubu@bubu1.eu>
[yann.morin.1998@free.fr: add the comment to explain failure is success]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Commit 8f403f0 "package/micropython-lib: merge with, and install
as part of micropython" brought micropython library within the
package.
This commit improves the micropython runtime test by enabling the
micropython-lib and by also adding a runtime test using one of its
module. We choose to use the gzip module, and check whther decodign q
simple gziped file works; the micropython-lib gzip can only decompress,
so we need to prepare it from the shell.
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
