As the comment in package/perl/perl.mk instructs, bumping the perl
version must be propagated to utils/scancpan as well.
However, commit 7c1ef8129f (package/perl: bump to version 5.34.0)
forgot to do so.
Fixes: 7c1ef8129f
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
igh-ethercat comes with a small number of patched Linux kernel network
drivers, which aim at replacing the ones available in upstream Linux
kernel. All those drivers are provided only for specific kernel
releases. For example:
r8169-2.6.24-ethercat.c
r8169-2.6.24-orig.c
r8169-2.6.27-ethercat.c
r8169-2.6.27-orig.c
r8169-2.6.28-ethercat.c
r8169-2.6.28-orig.c
r8169-2.6.29-ethercat.c
r8169-2.6.29-orig.c
r8169-2.6.31-ethercat.c
r8169-2.6.31-orig.c
r8169-2.6.32-ethercat.c
r8169-2.6.32-orig.c
r8169-2.6.33-ethercat.c
r8169-2.6.33-orig.c
r8169-2.6.35-ethercat.c
r8169-2.6.35-orig.c
r8169-2.6.36-ethercat.c
r8169-2.6.36-orig.c
r8169-2.6.37-ethercat.c
r8169-2.6.37-orig.c
r8169-3.10-ethercat.c
r8169-3.10-orig.c
r8169-3.12-ethercat.c
r8169-3.12-orig.c
r8169-3.14-ethercat.c
r8169-3.14-orig.c
r8169-3.16-ethercat.c
r8169-3.16-orig.c
r8169-3.2-ethercat.c
r8169-3.2-orig.c
r8169-3.4-ethercat.c
r8169-3.4-orig.c
r8169-3.6-ethercat.c
r8169-3.6-orig.c
r8169-3.8-ethercat.c
r8169-3.8-orig.c
r8169-4.4-ethercat.c
r8169-4.4-orig.c
Obviously, this doesn't play well with the random configuration
testing done by utils/genrandconfig. This commit avoids this issue by
making sure we never build any of those drivers as part of the
genrandconfig generated configurations.
Fixes:
http://autobuild.buildroot.net/results/07b7475d780c067d99ee5618a5fd2bb024a5b4e7/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
When BR2_XTENSA_CUSTOM=y is used with the internal toolchain, an
overlay file is mandatory, which genrandconfig can't provide. So we
simply disallow such configurations.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
a10disp will raise the following build failure with a mainline kernel:
cp: cannot stat '/home/autobuild/autobuild/instance-0/output-1/build/linux-5.17.15/include/video/sunxi_disp_ioctl.h': No such file or directory
Fixes:
- http://autobuild.buildroot.org/results/1f2607d6adece4d5dfe17fbdb032a2d228fc030f
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
In the internal toolchain backend, we have a choice..endchoice block
to allow the user to select the C library, between glibc, uClibc and
musl.
However, there are situations were no C library at all is
supported. In this case, the choice does not appear, and does not
allow to see the Config.in comments that are within the
choice..endchoice block and that may explain why no C library is
available.
For example, on RISC-V 32-bit, the only C library supported is glibc,
and the minimum kernel header version required by glibc on this
architecture is 5.4.0. In a future commit, we are going to add this
dependency on glibc (to fix build issues on configurations that have
headers < 5.4.0). But since glibc is the only supported C library on
RISC-V 32-bit, it means that the choice..endchoice for the C library
contains no entry, preventing from seeing the Config.in comment.
To address this issue, this commit adds a "dummy"
BR2_TOOLCHAIN_BUILDROOT_NONE option that shows up in the
choice..endchoice only when no C library is available. Thanks to this,
the choice..endchoice is never empty, and the Config.in comments can
be seen.
If the user keeps BR2_TOOLCHAIN_BUILDROOT_NONE selected, then the
build will anyway abort early because package/Makefile.in has a check
to verify that a C library is selected, and aborts the build if not.
Some could say that the problem should be resolved by instead
preventing the selection of headers < 5.4.0 on RISC-V 32-bit, but that
is difficult to do as the user can choose a custom header version, or
simply specific that (s)he wants to use the headers of the kernel
being built. In those situations, it's difficult to prevent selecting
headers < 5.4.0.
Prevent random configurations from triggering a build failure in our
autobuilders, by excluding that symbol from accepted configuration.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr: update genrandconfig]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Commit af494d92d3 (utils/genrandconfig: disable libopenssl without
atomics) intorduced a code-style issue that flake8 does not like:
$ make check-flake8
utils/genrandconfig:253:8: E713 test for membership should be 'not in'
1 E713 test for membership should be 'not in'
Fixes: af494d92d3https://gitlab.com/buildroot.org/buildroot/-/jobs/3045260108
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
libopenssl needs atomic or the build will fail (e.g. on sparcv8 without
libatomic):
${LDCMD:-/nvmedata/autobuild/instance-7/output-1/host/bin/sparc-buildroot-linux-uclibc-gcc} -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O0 -g2 -g2 -L. \
-o apps/openssl apps/asn1pars.o apps/ca.o apps/ciphers.o apps/cms.o apps/crl.o apps/crl2p7.o apps/dgst.o apps/dhparam.o apps/dsa.o apps/dsaparam.o apps/ec.o apps/ecparam.o apps/enc.o apps/engine.o apps/errstr.o apps/gendsa.o apps/genpkey.o apps/genrsa.o apps/nseq.o apps/ocsp.o apps/openssl.o apps/passwd.o apps/pkcs12.o apps/pkcs7.o apps/pkcs8.o apps/pkey.o apps/pkeyparam.o apps/pkeyutl.o apps/prime.o apps/rand.o apps/rehash.o apps/req.o apps/rsa.o apps/rsautl.o apps/s_client.o apps/s_server.o apps/s_time.o apps/sess_id.o apps/smime.o apps/speed.o apps/spkac.o apps/srp.o apps/storeutl.o apps/ts.o apps/verify.o apps/version.o apps/x509.o \
apps/libapps.a -lssl -lcrypto -ldl
/nvmedata/autobuild/instance-7/output-1/host/lib/gcc/sparc-buildroot-linux-uclibc/10.3.0/../../../../sparc-buildroot-linux-uclibc/bin/ld: ./libssl.so: undefined reference to `__atomic_fetch_sub_4'
It should be noted that openssl3 has added OPENSSL_DEV_NO_ATOMICS but
"this is intended for internal development only, to check the
refcounting is properly coded. It should never become a configuration
option, hence the name of the macro.":
503d4745a1
Atomics are not available in Buildroot if:
- architecture is 32 bit and something other than ARM or xtensa, and
- GCC < 4.8 or no threads or FLAT.
The nothreads case can theoretically happen in many different
situations, but in practice nobody disables threads. So the only
interesting case is the FLAT case. Since ARM and RISC-V 64 both have
atomics intrinsics, that leaves just m68k NOMMU as FLAT. So this is
truly a corner case.
The proper solution would be to patch GCC to also provide libatomic in
those cases.
- For nothreads, atomics are in fact not needed, so libatomic can simply
be implemented as stubs.
- For FLAT, it's probably just a matter of having a match to uclinux in
libatomic/configure.tgt.
Again, though, this happens only in such niche cases that it's not worth
working on it.
Fixes:
- http://autobuild.buildroot.org/results/bce526d538f43a541fdfbc0c9b4a7cecebbbc539
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Avoid the "Where did it put my builds?" step.
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
From flake8:
utils/genrandconfig:429:21: E703 statement ends with a semicolon
1 E703 statement ends with a semicolon
Fixes: d3e029575c
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Add a custom case to make sure that a random configuration with an empty
version for aufs-util doesn't fail.
Fixes:
- http://autobuild.buildroot.org/results/e242cf66a02983bcf6e95b37f8e458bd18aee683
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Improve commit 541e794a95 by adding a
custom case to make sure that a random configuration with an empty
platform for arm-trusted-firmware doesn't fail:
make_helpers/plat_helpers.mk:15: *** "Error: Unknown platform. Please use PLAT=<platform name> to specify the platform". Stop.
Fixes:
- http://autobuild.buildroot.org/results/1b67220008223d1bcbe70b76d643f9d04362ba6b
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
In case of an unexpected error, we currently only print the exception as
an str(). For example, the recent issue with the glibc version check
only reported:
TypeError: cannot use a string pattern on a bytes-like object
That does not help in fixing the issue; the exception text is also not
usually very user-friendly either anyway.
We change the reporting to print the traceback, which in the glibc
version check mentioned above, the error is reported as:
Traceback (most recent call last):
File "./utils/genrandconfig", line 740, in <module>
ret = gen_config(args)
File "./utils/genrandconfig", line 676, in gen_config
if not is_toolchain_usable(configfile, toolchainconfig):
File "./utils/genrandconfig", line 186, in is_toolchain_usable
if StrictVersion('2.14') > StrictVersion(glibc_version):
File "/usr/lib/python3.8/distutils/version.py", line 40, in __init__
self.parse(vstring)
File "/usr/lib/python3.8/distutils/version.py", line 135, in parse
match = self.version_re.match(vstring)
TypeError: cannot use a string pattern on a bytes-like object
With this, the error is much easier to pinpoint (it's the last one that
is not in a system module).
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Unless explicitly told otherwise, subprocess.check_output() returns
bytes objects [0].
When we try to check the C library version (to check the Linaro
toolchain is usable), genrandconfig currently fails with:
TypeError: cannot use a string pattern on a bytes-like object
So, as suggested in the python documentation, decocde() the output of
subprocess.check_output() before we can use it.
[0] https://docs.python.org/3/library/subprocess.html#subprocess.check_output
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
We extend the modules search path to be able to load the package
metadata. Currently, it is only restored when loading those
succeeded, not when it failed.
Restore it to its previous state also in case of error, to avoid
leaking the path further.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Add custom cases to make sure that a random configuration with an empty
git, tarball location or version for xenomai doesn't fail. It reverts to
BR2_PACKAGE_XENOMAI_LATEST_VERSION in these cases.
Fixes:
- http://autobuild.buildroot.org/results/19419759b4add0197b4e629d0b2216c2a07624b2
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Add a custom case to make sure that a random configuration with an empty
git location for refpolicy doesn't fail. It reverts to
BR2_PACKAGE_REFPOLICY_UPSTREAM_VERSION in that case.
Fixes:
- http://autobuild.buildroot.org/results/98da07a1f9b88e2e8a028a55c8cf76c6ebc28304
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Fix typo on line 23 `get-developpers` to `get-developers`
Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
In preparation to the introduction of test cases for the
get-developers script, make it possible to pass a custom DEVELOPERS
file. A normal user of get-developers will most likely never use this,
but the test suite will use it.
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
[Thomas: extracted from a larger patch from Ricardo, initially posted
at https://patchwork.ozlabs.org/project/buildroot/patch/20220528014832.289907-1-ricardo.martincoski@gmail.com/]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Commit "45aabcddc5 utils/get-developers: really make it callable from
elsewhere than the toplevel directory" had a unforeseen side-effect:
the fact that check-developers with no arguments used to validate the
syntax of the DEVELOPERS no longer works. Indeed, the
parse_developers() call was moved *after* the check that verifies if
at least one action is passed. Due to this, the check-DEVELOPERS
verification in Gitlab CI, which invokes get-developers without
argument to validate the DEVELOPERS file... no longer does anything
useful.
In order to fix this, we introduce an explicit action in
get-developers to request the validation of the DEVELOPERS file. The
implementation is trivial, as the validation is already done by
calling parse_developers(), but at least now we have an action that
does "nothing", except execute until the validation is done.
This is also much more explicit than "invoke get-developers without
arguments to just do validation".
The initial investigation of the issue was done by Ricardo Martincoski
<ricardo.martincoski@gmail.com> and reported at
https://patchwork.ozlabs.org/project/buildroot/patch/20220528014832.289907-1-ricardo.martincoski@gmail.com/,
but we have chosen to introduce a separate -v option rather than
making the validation part of the existing -c action, which serves a
different purpose.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Add a custom case to make sure that a random configuration with an
empty tarball location for OP-TEE OS doesn't fail. It reverts to
BR2_TARGET_OPTEE_OS_LATEST in that case.
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The support for this architecture has been removed from the upstream
Linux kernel, as of commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aec499c75cf8e0b599be4d559e6922b613085f8f
Which states:
The nds32 architecture, also known as AndeStar V3, is a custom
32-bit RISC target designed by Andes Technologies. Support was added
to the kernel in 2016 as the replacement RISC-V based V5 processors
were already announced, and maintained by (current or former) Andes
employees.
As explained by Alan Kao, new customers are now all using RISC-V,
and all known nds32 users are already on longterm stable kernels
provided by Andes, with no development work going into mainline
support any more.
There has also been little to no maintenance done in Buildroot for
this architecture in recent times, so let's follow the Linux kernel
community decision and drop support for this CPU architecture.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Yu Chien Peter Lin <peterlin@andestech.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
If we don't have a DTS name or path we need to also disable cuimage
to disable DTS support as BR2_LINUX_KERNEL_CUIMAGE requires DTS
support.
Fixes:
linux/linux.mk:591: *** No kernel device tree source specified, check your BR2_LINUX_KERNEL_INTREE_DTS_NAME / BR2_LINUX_KERNEL_CUSTOM_DTS_PATH settings. Stop.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
If the kconfig values being replaced are not empty we should not
try to fix them.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Internally genrandconfig will use gettimeofday when generating a
KCONFIG_SEED, since autobuild-run executes genrandconfig at the same
time for multiple autobuilder runners this could potentially result
in the same KCONFIG_SEED being generated for those test runs started
at the same time.
To ensure this doesn't happen set the KCONFIG_SEED using the urandom
entropy source.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
This should have been BR2_TARGET_ROOTFS_EXT2 as the
BR2_TARGET_ROOTFS_EXT2_GEN variable is an integer variable used
to indicate the ext2/ext3/ext4 variant.
Fixes:
- http://autobuild.buildroot.net/results/5d7/5d7833212bd8a2b575945f848d8c91dabe7d3c30
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Until commit "arch/Config.in.sh: fixup MMU selection" in this series,
SH2A could either be used with BR2_USE_MMU disabled or BR2_USE_MMU
enabled.
The later made absolutely no sense, since SH2A does not have a MMU:
MMU support was introduced starting from SH3 according to
https://en.wikipedia.org/wiki/SuperH#SH-3
Also, since commit 22d5501e03 ("arch:
tidy up binary formats config"), which was merged in Buildroot
2015.05, the architecture tuple used when BR2_sh2a=y and BR2_USE_MMU
disabled is sh2a-buildroot-uclinux-uclibc, and this was already
unsupported back in the days of Buildroot 2015.08 and binutils 2.24,
causing the build to fail with:
*** BFD does not support target sh2a-buildroot-uclinux-uclibc.
just like it fails to build today with recent version of binutils.
So, this has been broken since 2015.08, and nobody complained. SH2A is
seldom used, so it's time to kill it.
It is worth mentioning that there had been an attempt at resurrecting
SH2 support around 2015 (see https://lwn.net/Articles/647636/) as part
of the J2 core. This effort led to the addition of FDPIC support for
SH2A in the musl C library (and therefore proper ELF binaries, with
shared libraries), but that was never supported in Buildroot. Now that
the J2 project is essentially dead, there is no reason to bother with
this.
Fixes:
http://autobuild.buildroot.net/results/63d01d33ae30f86b63b9f42a9fea116f2f3e9005/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Currently we only test a limited set of toolchains that are mostly
prebuilt, add a flag to allow using randconfig for randomizing
additional toolchain settings instead of randpackageconfig.
To avoid invalid configs we need to add additional config validation
filtering and fixups. Although the loop around 'make randconfig'
attempts does make sure we eventually end up with a valid configuration,
there is a bias towards e.g. disabling the kernel. It would be possible
to e.g. always force BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG=y, but
that removes the possibility for a toolchains-csv config to add a valid
custom defconfig. (Note that currently this isn't possible anyway since
'make randpackageconfig' is used if a toolchains-csv is provided, but
eventually we want to use 'make randconfig' also if a toolchains-csv is
provided.)
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Some packages only have a home page properly set inside project_urls.
Squelch flake8's E127, because a visual indent here is really nicer.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
[yann.morin.1998@free.fr: simplify getting home_page fallbacks]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
As already done for {FOO}_DEPENDENCIES in commit
4910a175b3, check that {FOO}_CONF_OPTS are
never overridden in a conditional
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Since this is a helper script there is not much reason to show the
command that's been issued. Furthermore, the incantation has been
slightly extended since the script was introduced.
The only interesting reason to print the command is to know what image
it is being spawned into. However, this is prominently displayed by
docker the first time the script is run, as it can't find the image
locally and has to fetch it first. Afterwards, users can still use
'docker image ls' to see what images they have locally.
So let's remove 'set -x' before running docker.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
[yann.morin.1998@free.fr: reword and expand commit log]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Currently, the docker-run script starts a container based on the
reference image, in which the user has UID:GID set to 1000:1000,
which may or may not be the same as local user uses, which may
prevent the commands in the container from creating files, which
foils the plan of using the container to run a build...
Additionally, the paths in the container differ from the paths
the user expects, as the current Buildroot tree is mounted over
the in-container user home directory. This is a bit confusing...
Finally, the container is left hanging around after the command
finishes, and thus there are as many lingering containers as the
user runs docker-run. This is not very nice...
We fix all of that (yeah, should be different patches, but meh):
- we use --mount instead of -v, which allows us to bind-mount
the Buildroot tree at the same place in the container, as
Docker will create the destination if it does not exist, while
-v seems to expect it to exist [0].
- as a consequence, we can also set the working directory as the
Buildroot top-directory;
- use --user to force the same UID:GID in the container as the
local user, so that files created in the container belong to
the local user, and so that files from the local user are
accessible from the container;
- use --rm to remove the container once it terminates; starting
a new container is very quick anyway, so it is as good as
re-using a previous container.
[0] the documentation is not clear about that. It clearly states
that the host directory (i.e. the origin, the source) is created
if missing, but it says nothing of the destination:
https://docs.docker.com/engine/reference/commandline/run/#mount-volume--v---read-only
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Luca Ceresoli <luca@lucaceresoli.net>
Cc: Giulio Benetti <giulio.benetti@benettiengineering.com>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Tested-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Without -i, the container cannot be used interactively. Allow using it as
in:
$ ./utils/docker-run
+ exec docker run -v /home/ceresoli/devel/buildroot:/home/br-user -it registry.gitlab.com/buildroot.org/buildroot/base:20220206.1756
br-user@1e9508a4ccbb:~$ ls
arch board boot CHANGES Config.in Config.in.legacy configs COPYING DEVELOPERS docs fs linux Makefile Makefile.legacy output package README support system toolchain utils
br-user@1e9508a4ccbb:~$
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
/usr/bin/bash does not exist on Ubuntu 2018.04. Use the more portable
alternative "#!/usr/bin/env bash" which we are already using in quite
a few scripts.
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Fixes: 242e9d72e7 ("utils/docker-run: new script")
[yann.morin.1998@free.fr: use "#!/usr/bin/env bash", not "@!/bin/bash"]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The option was removed by commit 306839586b (package/python: drop target
package).
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
While committing the shellcheck feature, it was changed to output the
full shellcheck output even at verbosity level 1. However, the
expectation of the shellcheck test was not updated accordingly.
Do that now, simply merging all the shellcheck output in a single
string.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
For simplicity, when shellcheck returns one or more warnings, count it
as a single check-package warning.
The developer can get the full output either by running shellcheck
directly or by calling check-package with -v.
Examples:
|$ ./utils/docker-run utils/check-package --include Shellcheck package/polkit/S50polkit
|package/polkit/S50polkit:0: run 'shellcheck' and fix the warnings
|51 lines processed
|1 warnings generated
|$ ./utils/docker-run utils/check-package --include Shellcheck -v package/polkit/S50polkit
|package/polkit/S50polkit:0: run 'shellcheck' and fix the warnings
|In package/polkit/S50polkit line 43:
|< tab >start|stop|restart|reload)
| ^----^ SC2221: This pattern always overrides a later one on line 45.
|In package/polkit/S50polkit line 45:
|< tab >reload)
| ^----^ SC2222: This pattern never matches because of a previous pattern on line 43.
|For more information:
| https://www.shellcheck.net/wiki/SC2221 -- This pattern always overrides a l...
| https://www.shellcheck.net/wiki/SC2222 -- This pattern never matches becaus...
|51 lines processed
|1 warnings generated
NOTICE: shellcheck results depends on the version of the tool.
This is why the examples above run inside the docker image.
Also update .gitlab-ci.yml with the docker image after the change of
the previous commit. We don't actually use shellcheck in CI, but the
image from .gitlab-ci.yml is used by the docker-run script and we use
that to run shellcheck.
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
[Arnout: make sure a single -v is enough to get shellcheck output;
update docker image tag in .gitlab-ci.yml]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Enable the common checks:
- consecutive empty lines
- empty last line
- missing new line at end of file
- trailing space
- warn for executable files, with the hint to instead use
'$(INSTALL) -D -m 0755' in the .mk file
Check indent with tabs:
- add a simple check function to warn only when the indent is done
using spaces or a mix of tabs and spaces. It does not check indenting
levels, but it already makes the review easier, since it
diferentiates spaces and tabs.
Check variables:
- check DAEMON is defined
- when DAEMON is defined, check the filename is in the form S01daemon
- when PIDFILE is defined, expect it to be in /var/run and defined
using $DAEMON.
Also add unit test for this.
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
[Arnout: avoid 'del NotExecutable_base' by importing the module instead
of the class; refer to manual in warnings]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Currently there are no .mk, Config.in, .patch or .hash files with
executable permissions in the tree.
But we don't want to have that.
So warn when a file checked by check-package has executable permission.
This check will be reused when testing SysV init scripts in the tree.
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
[Arnout: use context manager for temp dir so it gets deleted]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Some file formats have well-established syntax checkers.
One example of this is the tool 'shellcheck' that can analyse shell
scripts for common mistakes.
There is no reason to reimplement such tools in check-package, when we
can just call them.
Add the ability to check-package to call external tools that will run
once for each file to be analysed.
For simplicity, when the tool generated one or more warnings, count it
as a single warning from check-package, that can display something like
this:
|$ ./utils/check-package package/unscd/S46unscd
|package/unscd/S46unscd:0: run 'shellcheck' and fix the warnings
|25 lines processed
|1 warnings generated
|$ ./utils/check-package -vvvvvvvvvvvvvvvv package/unscd/S46unscd
|package/unscd/S46unscd:0: run 'shellcheck' and fix the warnings
|In package/unscd/S46unscd line 9:
| printf "Starting ${NAME}: "
| ^------------------^ SC2059: Don't use variables in the printf format string. Use printf "..%s.." "$foo".
|In package/unscd/S46unscd line 11:
| [ $? -eq 0 ] && echo "OK" || echo "FAIL"
| ^-- SC2181: Check exit code directly with e.g. 'if mycmd;', not indirectly with $?.
|In package/unscd/S46unscd line 14:
| printf "Stopping ${NAME}: "
| ^------------------^ SC2059: Don't use variables in the printf format string. Use printf "..%s.." "$foo".
|In package/unscd/S46unscd line 16:
| [ $? -eq 0 ] && echo "OK" || echo "FAIL"
| ^-- SC2181: Check exit code directly with e.g. 'if mycmd;', not indirectly with $?.
|For more information:
| https://www.shellcheck.net/wiki/SC2059 -- Don't use variables in the printf...
| https://www.shellcheck.net/wiki/SC2181 -- Check exit code directly with e.g...
|25 lines processed
|1 warnings generated
In this first commit, add only the ability for check-package to call
external tools and not an example of such tool, as adding each tool to
call may need update to the docker image and can lead to it's own
discussion on how to implement.
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Add a small script to run commands in the same docker image used in the
GitLab CI.
For instance, one can run check-package unit tests without installing
pytest directly in the host:
$ ./utils/docker-run python3 -m pytest -v utils/checkpackagelib/
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
[Arnout: fix shellcheck errors; add exec]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
So anyone willing to contribute to check-package can run all tests in
less than 1 second by using:
$ python3 -m pytest -v utils/checkpackagelib/
Most test cases are in the form:
@pytest.mark.parametrize('testname,filename,string,expected', function)
- testname: a short description of the scenario tested, added in order
to improve readability of the log when some tests fail
- filename: the filename the check-package function being tested thinks
it is testing
- string: the content of the file being sent to the function under test
- expected: all expected warnings that a given function from
check-package should generate for a given file named filename and
with string as its content.
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
