Python 2.7 is EOL since April 2020, so drop support for the target package.
https://www.python.org/dev/peps/pep-0373/
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Python2 for the target is about to get removed, so drop the tests using it.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The package was updated to support python3 in commit 4a8bedc51d
(python-pyzmq: enable PyZMQ for Python 3), but the comment dependency was
missed.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Convert BR2_TOOLCHAIN_EXTERNAL_PATH to an absolute path when used.
Otherwise the symbolic links to the external toolchain binaries are
not installed in host/bin when BR2_TOOLCHAIN_EXTERNAL_PATH is relative.
This happens because TOOLCHAIN_EXTERNAL_INSTALL_WRAPPER
changes directory into host/bin to create the symbolic links.
From there the tools are no longer found via the relative path and
a single symbolic link host/bin/$(prefix)-* is created instead.
Although relative paths sounds like something less than ideal to put in
a Buildroot configuration, it's actually rather typical to put the
buildroot sources as a submodule (or subdirectory) of custom sources
(either in a BR2_EXTERNAL or not), in which case the relative path is
well-defined.
Signed-off-by: Juergen Stuber <juergen@jstuber.net>
Reviewed-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Buildroot uses variable LINUX_ARCH_PATH to refer to the arch-specific
directory in the Linux tree, which may not necessarily be arch/$(KERNEL_ARCH).
Buildroot already accounts for the case of KERNEL_ARCH=i386 and
KERNEL_ARCH=x86_64, but does not for KERNEL_ARCH=sparc64, in which case the
correct directory is arch/sparc.
Reported-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
The variable 'KERNEL_ARCH' is actually a normalized version of
'ARCH'/'BR2_ARCH'. For example, 'arcle' and 'arceb' both become 'arc', just
as all powerpc variants become 'powerpc'.
It is presumably called 'KERNEL_ARCH' because the Linux kernel is typically
the first place where support for a new architecture is added, and thus is
the entity that defines the normalized name.
However, the term 'KERNEL_ARCH' can also be interpreted as 'the architecture
used by the kernel', which need not be exactly the same as 'the normalized
name for a certain arch'. In particular, for cases where a 64-bit
architecture is running a 64-bit kernel but 32-bit userspace. Examples
include:
* aarch64 architecture, with aarch64 kernel and 32-bit (ARM) userspace
* x86_64 architecture, with x86_64 kernel and 32-bit (i386) userspace
In such cases, the 'architecture used by the kernel' needs to refer to the
64-bit name (aarch64, x86_64), whereas all userspace applications need to
refer the, potentially normalized, 32-bit name.
This means that there need to be two different variables:
KERNEL_ARCH: the architecture used by the kernel
NORMALIZED_ARCH: the normalized name for the current userspace architecture
At this moment, both will actually have the same content. But a subsequent
patch will add basic support for situations described above, in which
KERNEL_ARCH may become overwritten to the 64-bit architecture, while
NORMALIZED_ARCH needs to remain the same (32-bit) case.
This commit replaces use of KERNEL_ARCH where actually the userspace arch is
needed. Places that use KERNEL_ARCH in combination with building of kernel
modules are not touched.
There may be cases where a package builds both a kernel module as userspace,
in which case it may need to know about both KERNEL_ARCH and
NORMALIZED_ARCH, for the case where they differ. But this is to be fixed on
a per-need basis.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
[Arnout: Also rename BR2_KERNEL_ARCH to BR2_NORMALIZED_ARCH]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Similar to other arch-specific strings, the 'KERNEL_ARCH' variable can be
determined from Config.in.<arch> files.
Besides aligning with similar strings, this also means simplification: the
big 'sed' covers several architectures not even supported by Buildroot.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
ace needs C++11 since its addition in commit
3621918d1b to avoid the following build
failure:
In file included from /home/peko/autobuild/instance-1/output-1/host/opt/ext-toolchain/mips-linux-gnu/include/c++/5.3.0/chrono:35:0,
from /home/peko/autobuild/instance-1/output-1/build/ace-7.0.1/ace/Time_Value.h:23,
from /home/peko/autobuild/instance-1/output-1/build/ace-7.0.1/ace/OS_NS_unistd.h:25,
from /home/peko/autobuild/instance-1/output-1/build/ace-7.0.1/ace/ACE.inl:2,
from /home/peko/autobuild/instance-1/output-1/build/ace-7.0.1/ace/ACE.h:886,
from /home/peko/autobuild/instance-1/output-1/build/ace-7.0.1/ace/ACE.cpp:1:
/home/peko/autobuild/instance-1/output-1/host/opt/ext-toolchain/mips-linux-gnu/include/c++/5.3.0/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
#error This file requires compiler and library support for the \
^
Fixes:
- http://autobuild.buildroot.org/results/13376405e313da112f546076a10859e60631d5d5
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit b429dce6f8 forgot to add wchar
dependency resulting in the following build failure of postgresql:
configure: error: C compiler "/home/buildroot/autobuild/instance-2/output-1/host/bin/arm-linux-gcc" does not support C99
Fixes:
- http://autobuild.buildroot.org/results/e4b59fecd2a5bcda8103ddf4eae3dbd78fe3b896
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The python support in avahi needs pygobjet to do anything:
Building avahi-python: no (You need python, pygobject and python-dbus!)
So add optional support for it. Python-gobject is only available for
python3, so change the python logic to use python 3.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
It is not used by the configure script and refer to PYTHON_TARGET_BINARY
which was dropped back in 2010 by commit e3418f69cf (python: convert to
autotargets, bump to 2.7.1, many improvements), so drop it.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Gnuradio only works with python3 since commit 786c783f37
(package/python-numpy: bump to version 1.18.2), so the python2/3 logic for
_PYVER can be dropped.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
support/testing/tests/package/test_lua_cffi.py:14:1: W391 blank line at end of file
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
As pointed out by Jan Lübbe, D-Bus support is optional:
> You can build without D-Bus (./configure --disable-service).
So drop it from the required dependencies and add a RAUC_DBUS sub option
like it is done for network/json.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit 13114d0f93 forgot to add spaces
before and after '=' and added a spurious space in Config.in
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Drop celt comment which is not needed since removal of celt051 in commit
b32efbdb03
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Update LM_SENSORS_VERSION to make it match what is returned by
https://release-monitoring.org
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently, grpc depends on the full host-grpc, which in turn depends on host
versions of many other libraries. One of these, host-libabseil-cpp, also
requires a host gcc 4.9 or larger, a dependency which is not met on CentOS
7.
But in fact, the target grpc only needs the 'grpc_cpp_plugin' binary from
host-grpc. And that binary does not depend on host-libabseil-cpp or other
libraries, only on host-protobuf.
Given the above, simplify the grpc/host-grpc situation.
- Add a patch to the (host-)grpc CMakeLists.txt file to add an option to
only build grpc_cpp_plugin.
- Update grpc.mk and Config.in to remove the unnecessary dependencies, and
change the host-grpc configure options to make cmake happy.
The advantages of these changes are:
- making grpc available to older hosts with gcc < 4.8, like CentOS 7
- significantly reducing the build time of host-grpc and its dependencies
The patch was proposed upstream but not accepted with below rationale.
Perhaps input from others can help in persuading upstream in a future
attempt.
'What you're doing sounds like quite a narrow use case. But we simply
cannot provide a cmake option for every possible scenario in the world.
Introducing a new cmake option isn't for free and requires careful
design and maintenance.'
Nevertheless, given the benefits in terms of build time and dependency
reduction, it makes sense to apply this patch in spite of the disadvantage
of a local non-upstreamed patch.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
[Arnout: propagate removed dependency to collectd]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
ACE is an open-source framework that provides many components and
patterns for developing high-performance, distributed real-time
and embedded systems. It provides powerful, yet efficient abstractions
for sockets, demultiplexing loops, threads, synchronization primitives.
Signed-off-by: Matt Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Kalpesh Panchal <kalpesh.panchal@rockwellcollins.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
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>
Allow developers to run check-package for init scripts, that call
shellcheck, without having to install the tool.
Since the docker have a fixed version of the tool, there will be no
difference between runs in different machines.
One can call:
$ utils/docker-run utils/check-package package/package/S*
$ utils/docker-run shellcheck package/package/S*
This change also allows to eventually run check-package for init scripts
in the GitLab CI.
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Acked-by: Romain Naour <romain.naour@smile.fr>
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>
nfsiostat is a python3 script, so keep it if python3 is enabled and not
python2:
head -n 1 target/usr/sbin/nfsiostat
#!/usr/bin/python3
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Reviewed-by: Petr Vorel <petr.vorel@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
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 we can catch regressions on check-package.
Update to the new docker image that was pushed after the previous
commit.
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
... so the unit tests for check-package can run in the GitLab CI.
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Acked-by: Romain Naour <romain.naour@smile.fr>
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>
This is stable bugfix release of libmdbx. So it is reasonable to backport
this patch to all applicable releases/branches of buildroot.
Please refer to the ChangeLog for more historical information and actual TODOs.
https://github.com/erthink/libmdbx/blob/master/ChangeLog.md
Release notes: https://github.com/erthink/libmdbx/releases/tag/v0.11.4
Signed-off-by: Леонид Юрьев (Leonid Yuriev) <leo@yuriev.ru>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
All local patches except on have been upstreamed, so let's remove them and
rename/rebase the remaining one.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Drop patch that is now upstream.
Set new x11 and libcanberra meson config options.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Update the license hash because of a change in copyright year:
- Copyright (C) 1997-2019 Sam Lantinga <slouken@libsdl.org>
+ Copyright (C) 1997-2022 Sam Lantinga <slouken@libsdl.org>
Signed-off-by: Peter Thompson <peter.macleod.thompson@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Gcc bug 99410 reappeared in gcc 10.x while building belle-sip, but it's
fixed on gcc 11.x, so let's update bug conditions.
Fixes:
http://autobuild.buildroot.net/results/846597f3573d3b0d52e80627a9577d14b9348547/
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Currently, we configure glibc to not add compatibility support for
kernels older than the one used for the headers. This is on the
expectation that the system will never run on a kernel that is older
than the one used for the headers or, when Buildroot builds the kernel,
on another, older kernel.
However, in some situations, it is possible to build for a generic
system, where the kernel may be a different version. This can be the
case, for example, when Building an image that is to be used in a
container that can run on a range of machines each with different kernel
versions. In such a case, it is interesting to build glibc in a way as
to take better advantage of the newer kernels, and thus using newer
kernel headers, while still allowing running on older kernels, and thus
carrying more compatibility code.
We add an option to glibc to allow the user to enable compatibility
shims. To simplify the case, when that option is enabled, we just let
glibc enable as old compatibility shims as supported by the current
architecture.
The code size increase is very small. For an ARM Cortex-A7, with
gcc-10.3.0, the delta is as follows (other files installed by glibc had
no size delta; sizes in bytes):
file | no compat | compat | delta
----------------------+-----------+-----------+-------
ld-linux-armhf.so.3 | 200216 | 200284 | + 68
libc.so.6 | 1814496 | 1823120 | +8624
------+-------
Total | +8692
No runtime overhead has been measured; the overhead is most probably
in the measurement noise. Indeed, the compatibility shims are very
lightweight. For example, there are 9 arch-generic shims:
renameat2(), execveat(), mlock2(), statx(), faccessat2(),
close_range(), time64-related syscall shenanigans, a waitid()
feature, and a futex operation (LOCK_PI2)
and then each arch may define a few others. i386 has less than 20
(mostly related to socket options, and one for the ordering of the
clone() arguments), while ARM seems to have only two (mlock2() and a
configurable futex feature).
Note: however, as Arnout pointed out, some programs may still actually
fail to run even with such compatibility shim, if they really expect the
shimed syscalls to really exist and have no fallback (and/or no proper
error-handling). Still, in the vast majority of cases, those
compatibility shims are enough to have a system running.
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Tested-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
