Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 8ad64e724c)
[Peter: drop Makefile change]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit 083e65a67c introduced tests for the
various read-only root options under systemd, but while applying the
fs-overlay that is used in one of the tests wasn't included. Include it
now.
Fixes: 083e65a67c
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Instead of only checking .mk and Config.in{,.host}, check
all files in a package directory.
.checkpackageignore isn't considered here, therefore the shown number
includes ignored warnings as well.
Add another css class to signal some warning, compared to a lot (>5),
similar to patches.
Signed-off-by: Daniel Lang <dalang@gmx.at>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Some packages are grouped and have a general makefile that defines
reusable variables. These makefiles have no relevant information for
pkg-stats and should be excluded.
Signed-off-by: Daniel Lang <dalang@gmx.at>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Currently, we expect and only use hash files that lie within the package
directory, alongside the .mk file. Those hash files are thus bundled
with Buildroot.
This implies that only what's known to Buildroot can ever get into those
hash files. For packages where the version is fixed (or a static
choice), then we can carry hashes for those known versions.
However, we do have a few packages for which the version is a free-form
entry, where the user can provide a custom location and/or version. like
a custom VCS tree and revision, or a custom tarball URL. This means that
Buildroot has no way to be able to cary hashes for such custom versions.
This means that there is no integrity check that what was downloaded is
what was expected. For a sha1 in a git tree, this is a minor issue,
because the sha1 by itself is already a hash of the expected content.
But for custom tarballs URLs, or for a tag in a VCS, there is indeed no
integrity check.
Buildroot can't provide such hashes, but interested users may want to
provide those, and currently there is no (easy) way to do so.
So, we need our download helpers to be able to accept more than one hash
file to lookup for hashes.
Extend the dl-wrapper and the check-hash helpers thusly, and update the
legal-info accordingly.
Note that, to be able to pass more than one hash file, we also need to
re-order the arguments passed to support/download/check-hash, which also
impies some shuffling in the three places it is called:
- 2 in dl-wrapper
- 1 in the legal-info infra
That in turn also requires that the legal-license-file macro args get
re-ordered to have the hash file last; we take the opportunity to also
move the HOST/TARGET arg to be first, like in the other legal-info
macros.
Reported-by: "Martin Zeiser (mzeiser)" <mzeiser@cisco.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This test case runs firewalld using both system and sysvinit.
run `firewalld-cmd --state` and ensure the output is "running" with a return
code of 0.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
timeout = 35 * self.emulator.timeout_multiplier
[...]
self.assertRunOk(cmd, timeout=timeout)
Gets re-multiplied by self.emulator.timeout_multiplier in self.emulator.run().
Drop multiplying the timeout by self.emulator.timeout_multiplier to fix this
issue.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
self.emulator.timeout_multiplier *= 10 is equivilent to 60 * 10 or 600.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
self.emulator.timeout_multiplier *= 10 is equivilent to 60 * 10 or 600.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
to override the current value of 60 seconds
As per a suggestion by Thomas, add a timeout argument to override the current
value of 60 seconds for the emulator.login method.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
- Refactor 0001-add-qemu-wrapper-support.patch for 20.9.0
- NodeJS now requires GCC 10.1 header. However, as there is no
BR2_TOOLCHAIN_GCC_AT_LEAST_10_1, we round up to BR2_TOOLCHAIN_GCC_AT_LEAST_11.
- Drop the --without-dtrace and --without-etw config options as they no longer
exist.
- Update support/testing/tests/package/test_nodejs.py to use
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN, otherwise the test fails as the
gcc version selected will be 7.
- Update the hash file for LICENSE.txt due to numerous changes, such
as the addition of new libraries and updated dates. No new license
types are added.
Tested with: ./support/testing/run-tests tests.package.test_nodejs
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Also, introduce a new test in support/testing/tests/init/test_openrc.py that
ensures split-user support works properly.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
OpenJDK 21 is out and with it, OpenJDK11 is now EOL.
See: https://endoflife.date/oracle-jdk As such, drop support for 11 and do the
following:
- The 0001-Add-ARCv2-ISA-processors-support-to-Zero.patch patch now applies to
both 17 and 21. Move it out of the version-specific directoriy.
- BR2_OPENJDK_VERSION_LTS is now set to 17.
- BR2_OPENJDK_VERSION_LATEST is now set to 21.
- Drop --disable-hotspot-gtest as it has been removed, and was ignored in 17.
- Add two separate HOST_OPENJDK_BIN_VERSION defines in openjdk-bin.mk as
there is not a point release yet for OpenJDK 21.
- Update the expectedVersion variable in JniTest.java from 0x000A0000 to
0x00150000
Tested with:
./support/testing/run-tests tests.package.test_openjdk.TestOpenJdk.test_run
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit fe50c054bc)
[Peter: drop Makefile change]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
[Arnout:
- use a simple mount unit for
TestInitSystemSystemdRoFullOverlayfsVarBacking;
- change the test of TestInitSystemSystemdRoFullOverlayfsVarBacking to
check that the exact expected mount was performed;
- add a test of var backing with fstab instead of mount unit.
]
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
The TestNodeJSModule test triggers the build of host-nodejs to be able
to install third party modules. Now that host-nodejs has two
providers, it makes sense to test both cases, so we duplicate
TestNodeJSModule into TestNodeJsModuleHostBin (which tests the
host-nodejs-bin) and TestNodeJSModuleHostSrc (which tests the
host-nodejs-src).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Mako provide some external plugins that requires additionnal and
optional runtime dependencies, make sure we test these situations.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This new runtime test allows to make sure that the python-mako package
minimally works at runtime.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The weston runtime test uses the CRC of the framebuffer to detect that
"something" is being drawned on the framebuffer. This requires that the
sampling of the CRC happens does not happen too early after trigerring
an action, or the rendering may be not be finishe, either:
- weston may not have had time to initialise, or
- the test application may not have started rednering,
The sequence of rendering that has been observed yields this sequence of
CRCs (elided for brevity):
- boot:
- alternating between 0x4c4126bf and 0x5d2f9aa5: console cursor
blinking
- start weston:
- 0x4c4126bf: weston switches to a cleared vt, no blinking cursor
...
- 0xe54b7895: weston is starting
...
- 0xe54b7895: wayland socket appears!
...
- 0x6bf28bdf: weston is ready
...
- start weston-simple-egl:
- 0x6bf28bdf: application is starting
...
- 0xNNNNNNNN: random CRCs while the application renders
...
- stop weston-simple-egl:
- 0xNNNNNNNN: zero, one, or two random CRCs while the application
renders before it handles SIGTERM
- 0x6bf28bdf: application is stopped
...
- stop weston:
- 0x6bf28bdf: a few CRC identical to when weston was started, while
weston is processing SIGTERM
- oscillating between 0x4c4126bf and 0x5d2f9aa5: console cursor
blinking, back to initial vt, weston dead.
So, we need to wait "enough" after each action. Moreover, when the
wayland socket appears, weston may not have stabilised yet, so we also
need to wait after the socket appears.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Julien Olivain <ju.o@free.fr>
This is a simple test that builds and runs the futter-gallery application and
checks if the service is active.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
[yann.morin.1998@free.fr: fix flake8 warnings]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 9266ab06e0)
[Peter: drop Makefile change]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The quoting around the expansion of ${relative_dir} was indeed incorrect
since it was introduced back in 8fe9894f65 (suport/download: fix git
wrapper with submodules on older git versions): it is in fact already
quoted as part of the whole sed expression.
${GIT} can contain more than one item, but we don't care about splitting
on spaces when we just print it for debug, so we can just quote it
rather than add an exception.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Since commit b7efb43e86 (download/git: try to recover from
utterly-broken repositories), we catch errors through an ERR
trap, so we can try and recover from a broken repository. In
that commit, we switched from using "set -e" to "set -E", so
that trap is inherited in functions, command substitutions,
and subshells.
However, the trap is not defined until we have parsed the
options, created the cache directory, and eventually chdir()ed
into it. Athough improbable, it is possible for the git helper
to fail in any of those steps, and that would not get caught.
Fix that
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
When we generate the taballs off a local working copy of a VCS tree,
the umask is the one that we enforce in out top-level Makefile.
However, it is possible that a user manually tinkers in said working
copy (e.g. to check an upstream bug fix, or regression). If the user
umask is different from the one Buildroot enfirces, such tinkering
can impact the mode bits of the files, even if their content is not
modified.
When we eventually need to create a tarball from said working copy,
the VCS (e.g. git) will only be interested in checking whether the
content of the files have changed before chcking them out, and will
not look at, and restore/fix the mode bits.
As a consequence, we may create non-reproducible archives.
We fix that by enforcing the mode bits on the files before we create
the tarball: we disable the write and execute bits, and only set the
execute bit if the user execute bit is set.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Vincent Fazio <vfazio@xes-inc.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The magic-wormhole "receive" command can output "waiting" messages
when key receival or verification are longer than a predefined
timeout:
https://github.com/magic-wormhole/magic-wormhole/blob/0.13.0/src/wormhole/cli/cmd_receive.py#L135
The intent is to have an interactive user experience.
This behavior makes the runtime test unreliable as the test always
expect the sent message as the exact output. When the test execution
is slower, it sometimes get the "waiting" message instead of the
expected message.
Some test jobs are succeeding:
https://gitlab.com/buildroot.org/buildroot/-/jobs/4968059737
while some other are failing.
magic-wormhole can override those timers with environment variables.
See:
https://github.com/magic-wormhole/magic-wormhole/blob/0.13.0/src/wormhole/cli/cmd_receive.py#L26
This commit sets those environment variable to larger values
(100 seconds instread of 1 by default), to make sure the test will
always pass.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/4962923235
Reported-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Tested-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 3923a4fac8)
[Peter: drop Makefile change]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The intention of this script is to generate the XML that can be sent to
NVD to request a new CPE identifier.
As discussed on the mailing list [0] keeping up with version numbers of
all registered CPE ID won't work.
In addition the feed used to generated the XML files will be retired
[1]. In the future an API needs to be used for fetching the data in
connection with a local database.
All of this works against keeping this script and porting it to the new
API.
As a last blow Matthew, the original author concluded [2]:
> Makes sense to drop it. There never got to be enough momentum in the overall
> software community to make CVE or even the new identifier really accurate.
The intention is to ignore the version part of CPE IDs in the future,
and only look at the version range specified on a CVE. Therefore, a tool
to add new CPE ID versions isn't useful to us. It might still be useful
to have a tool to create the vendor and project parts of a CPE ID.
However, the current gen-missing-cpe tool doesn't support that, and the
API is anyway going to be retired. So there is no reason at all to keep
this around.
Remove gen-missing-cpe and the cpedb module. Remove the Makefile target
to call the script.
Since the cpedb module is removed, the CPEDB_URL definition must be
moved to the place where it is still used, in pkg-stats.
[0]: https://lists.buildroot.org/pipermail/buildroot/2023-August/672620.html
[1]: https://nvd.nist.gov/General/News/change-timeline
[2]: https://lists.buildroot.org/pipermail/buildroot/2023-August/672651.html
Signed-off-by: Daniel Lang <dalang@gmx.at>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Load sample script support/testing/tests/package/sample_nu.nu onto the
target and verify proper execution by nushell
Signed-off-by: Sebastian Weyer <sebastian.weyer@smile.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Each time a new pipeline is triggered, some jobs may fail due to
temporary issue with a Gitlab runner (network, power supply, docker or
maintainance).
Most of the problems are "runner system failure" [1] and require to
retart each failed jobs manually by maintainers to complete the
pipeline with only real failures if any.
The "retry" keyword allows to configure how many times a job is retried
if it fails. "retry:when" allows to retry a failed job only on
specific failure types like "runner_system_failure".
While at it, retry a job if it failed due to a timeout failure (this
timeout means that the job was pending for more than 24h) [2].
Such timeout failures occur on pipelines testing each Buildroot's
defconfig since there is not enough gitlab runner available to build
all of them within 24h.
Retry only jobs that are more likely to wait for a runner
(generate-gitlab-ci-yml, runtime_test_base, defconfig_base and test_pkg).
[1] https://gitlab.com/buildroot.org/buildroot/-/jobs/4936949397 (runner system failure)
[2] https://gitlab.com/buildroot.org/buildroot/-/jobs/4936949530 (timeout failure or the job got stuck)
https://docs.gitlab.com/ee/ci/yaml/#retrywhen
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The docker image currently contains qemu-system-arm and
qemu-system-x86. Each package contains the 32bit and 64bit variants.
This has been sufficient for the time being.
The RISC-V ecosystem is growing rapidly. It is starting to become
mainstream. To increase the diversity in Buildroot runtime tests,
this commit adds the qemu-system-misc package in the Docker image,
in order to have the commands qemu-system-riscv{32,64}. This package
also contains other architectures (for example: microblaze, nios2,
s390x, xtensa, ...).
For Debian package details, see:
https://packages.debian.org/bullseye/qemu-system-misc
Signed-off-by: Julien Olivain <ju.o@free.fr>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This runtime test was suggested in discussion [1]. It should detect
potential runtime failures such as the one fixed in commit eb74998125
"package/nftables: fix the build of the pyhon bindings".
We need a special kernel, because not all nftables-related options are
enabled in the pre-built one.
[1] https://lists.buildroot.org/pipermail/buildroot/2023-August/672864.html
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Previously, gen-bootlin-toolchains did not add a `depends` guard to
limit the available toolchains based on the minimum required GCC version
for the user selected CPU tuning.
Now, the proper BR2_ARCH_NEEDS_GCC_AT_LEAST_X guard will be added based
on the version of GCC provided by the toolchain.
Signed-off-by: Vincent Fazio <vfazio@gmail.com>
[yann.morin.1998@free.fr: regenerate the toolchain list]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
A new version of Bootlin toolchains, 2023.08, has been recently
released. Besides the usual updates of GCC, binutils, GDB, kernel
headers, and C libraries, support for AArch64 BE with musl has been
enabled, which explains why there are two new toolchains and two new
test cases.
All test cases where successfully tested:
https://gitlab.com/tpetazzoni/buildroot/-/pipelines/957304450/builds
Note that the sparcv8 uClibc toolchains are considered obsolete. They
are still available, but at some point we'll have to drop them from the
choice.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This test is a followup of the discussion at:
https://lists.buildroot.org/pipermail/buildroot/2023-July/671639.html
It provides an example of a runtime tests using standard Linux graphic
components (Kernel, DRM, Mesa3D, weston).
Signed-off-by: Julien Olivain <ju.o@free.fr>
[yann.morin.1998@free.fr:
- use an overlay rather than create config file at runtime
- sleep in python not in target
- increase delay to capture DRI CRCs
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Commit 134900401f (support/scripts/fix-rpath: parallelize patching
files) broke the rpath fixup, because it improperly quoted or expanded
variables:
- $@ was expanded in the main() context, rather than in the sub-bash
as expected, propagating incorrect parameters to patch_file();
- an array was passed without array expansion, so only the first item
was passed; that was in turn assigned to a string, anyway loosign
the array. Liuckily, we only ever put a single item in that array,
so that worked by chance.
We fix that by inverting the parameters to patch_elf(), where the extra
args are passed last, so we can put as many we want in the future. We
also pass every variables as positional parameters outside the bash -c
command, which allows us proper quoting of all variables, specifically
of the extra args array which now comes last.
The ultralong line was split, too, in a hopefully easier-to-read form.
Fixing all that also required fixing the many shellcheck issues at the
same time (wome were pre-existing before 134900401f).
While at it, expand two TABs into spaces like the rest of the script.
Note: shellcheck does not seem to warn when a variable expansion will be
used as the command to run, i.e. ${PATCHELF} does not trigger the
quoting error. Still, for consistency, we also double-quote it (we know
it is a single word, as it is already double-quoted once in the script).
Fixes: 134900401f
Cc: Victor Dumas <dumasv.dev@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Using "xargs" instead of "while read" loop allows for the patching of
files to be parallelized. This significantly reduces the amount of
time it takes to fix all the paths. On a larger RFS(~300MB) this
script was taking 5 minutes, it now only takes about 30s on a 12 core
machine.
Signed-off-by: Victor Dumas <dumasv.dev@gmail.com>
[Thomas: take into account the suggestion of Quentin Schulz to pass
PARALLEL_JOBS through the environment down to the fix-rpath script]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Like git which can have submodules, subversion can have externals. The
default behaviour for subversion is to retrieve all the externals,
unless told otherwise.
For some repositories, the externals may be huge (e.g. a dataset or some
assets) and may not be required for building the package. In such a
case, retrieving the externals is both a waste of network bandwitdh and
time, and a waste of disk storage.
Like for git submodules and git lfs, add an option that packages can set
to specify whether they want externals or not.
Since we've so far been retrieving externals, we keep that the default,
and packages can opt-out (rather than the opt-in for git submodules or
git lfs).
We must only set it when the package is actually hosted on svn, to avoid
passing -r when the package is not hosted by svn; otherwise, -r would
also be passed e.g. to a git-hosted package, triggering the download of
git submodules even when they are not requested. We need to do so,
because we have a default value, which we usually do not have in other
download options.
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
