This tests valdates that we can publish a message and read it back.
Signed-off-by: Marcus Hoffmann <marcus.hoffmann@othermo.de>
Tested-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
[yann.morin.1998@free.fr:
- don't manually start mosquitto, there's a startup script for that
- don't pass custom timeout
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Fixes the following error on calling mqtt.publish():
File "/usr/lib/python3.10/site-packages/paho/mqtt/publish.py", line 222, in single
multiple([msg], hostname, port, client_id, keepalive, will, auth, tls,
File "/usr/lib/python3.10/site-packages/paho/mqtt/publish.py", line 126, in multiple
if not isinstance(msgs, collections.Iterable):
AttributeError: module 'collections' has no attribute 'Iterable'
Backported from https://github.com/eclipse/paho.mqtt.python/pull/497/
This was deprecated in python 3.9 and stopped working in python 3.10
Signed-off-by: Marcus Hoffmann <marcus.hoffmann@othermo.de>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
There is currently no version of gdbserver for or1k. Until this
is implemented we will prevent both the direct and indirect
selection of gdbserver for or1k builds. In practice this means
that 'cross gdb for the host' cannot be selected and that
'full debugger' must be automatically selected for the gdb target
package.
This partially reverts commit 991b7b990a
which claimed that gdbserver for or1k was already supported before
version 8.3. That is not true - the commit that adds gdbserver support
for or1k [1] was only merged for version 12.1, which hasn't been
integrated in Buildroot yet.
Without that support, the build of gdbserver fails with
/home/buildroot/autobuild/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-musl/11.2.0/../../../../or1k-buildroot-linux-musl/bin/ld: server.o: in function `main':
server.cc:(.text.startup+0x6dc): undefined reference to `initialize_low()'
/home/buildroot/autobuild/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-musl/11.2.0/../../../../or1k-buildroot-linux-musl/bin/ld: remote-utils.o: in function `prepare_resume_reply(char*, ptid_t, target_waitstatus*)':
remote-utils.cc:(.text+0x28a8): undefined reference to `using_threads'
/home/buildroot/autobuild/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-musl/11.2.0/../../../../or1k-buildroot-linux-musl/bin/ld: remote-utils.cc:(.text+0x28b0): undefined reference to `using_threads'
Fixes: http://autobuild.buildroot.net/results/b3c/b3c0df53d09d9facaf0c3c2bc4529f9fcf7737ee
[1] https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=4933265c3f71b9134363d0c05f09542d5cc677f4
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Stafford Horne <shorne@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Commit [1] enabled glibc on or1k since it's now supported but it
requires a toolchain with linux-headers >= 5.4.
From [2]:
"Here we define the minumum linux kernel version at 5.4.0, as that is the
long term support version where 32-bit architectures start to support
64-bit time API's. The OpenRISC kernel had some bugs up until version 5.8
which caused issues with glibc fork/clone, they have been backported to
5.4 but not previous versions."
Fixes:
checking installed Linux kernel header files... 3.2.0 or later
checking for kernel header at least 5.4.0... too old!
configure: error: *** The available kernel headers are older than the requested
https://gitlab.com/buildroot.org/toolchains-builder/-/jobs/2875256686
[1] 68d0aede59
[2] https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=0c3c62ca7d9ff3bdacdd13e636bc858101e3e288
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
While building host-rust with a musl based toolchain without C++ compiler,
the build fail since libunwind bundled in rust sources needs a C++ compiler.
cargo:warning=i686-buildroot-linux-musl-gcc.br_real: error: [...]/host-rust-1.62.0/src/llvm-project/libunwind/src/Unwind-EHABI.cpp: C++ compiler not installed on this system
Note: the issues can't be reproduced with a glibc based toolchain
without C++ probaly due to extra steps required to support musl libc.
We could add the C++ dependency direclty to host-rustc but it would
requires adding the C++ reverse dependencies to all rust packages.
Instread, we add the C++ dependency to BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS
only when a musl toolchain is used. So we can still install a prebuilt
rust compiler but without the rust standard library (rust-std).
Usually we should not add toolchain dependencies in a _ARCH_SUPPORTS option but
BR2_PACKAGE_HOST_RUSTC_TARGET_TIER... options contains already some
BR2_TOOLCHAIN_USES_GLIBC or BR2_TOOLCHAIN_USES_MUSL.
Fixes:
http://autobuild.buildroot.org/results/636/636fb39c8f1b8c05e4ca451ac506cd63c7166d82
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Reviewed-by: Nicolas Tran <nicolas.tran@smile.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
To report usable tracebacks, pyc files embed the path of the original py
files, so that users can more easily try and debug the reported issue.
We generate the pyc files by calling the python3-supplied compileall
script, to scan the directory where python modules are installed. Since
this is done on the build machine, we tell compileall.py to strip away
the TARGET_DIR prefix, as that has no meaning at runtime.
However, compileall.py forgets [0] to keep a leading / in the front of
the paths, thus generating non-rooted paths., e.g.:
/path/buildroot.ouput/targt/usr/lib/python3.10/argparse.py
gets embedded as:
usr/lib/python3.10/argparse.py
This is a bit confusing but, as far as we could see, should be mostly be
used for display purposes in tracebacks, and does not seem to impact
actual functionality.
We fix that by instructing compileall.py that the embedded paths should
be rooted to / which generates proper paths in tracebacks.
And alternate solution would be to swith gears, and tell compileall.py
exactly the resulting runtime "base" directory, which replaces the
stripping and prefixing; i.e. it's either:
-s $(TARGET_DIR) -p /
or
-d /usr/lib/python$(PYTHON3_MAJOR_VERSION)
We choose to keep the first solution, because that is semantically what
we really want to do: to strip the leading build-time path, rather than
to force anything.
Note: the python test-suite was executed with both solutions (in a
pyc-only setup), and the results were exactly the same; so in practice,
-d or -s+-p yield the same results.
Many thanks go to Vincent for reporting the issue and suggesting the
solutions.
[0] Not sure whether this is a bug or a feature...
Reported-by: Vincent Fazio <vfazio@xes-inc.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This reverts commit 0be1c3e921.
The actual issue is more complex. The problem purportedly fixed was not
caused by a missing libupsclient (it was present), but by a missing type
definition for time_t (on a musl toolchain).
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The script "utils/check-package" checks that patch email prefix are
not be numbered. See:
https://git.buildroot.org/buildroot/tree/utils/checkpackagelib/lib_patch.py?h=2022.08-rc1#n42
The error message recommends to generate patches to be included in
Buildroot with the command 'git format-patch -N'.
The patch policy section in the Buildroot manual does mention that.
This commit adds a note about that requirement.
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Disable -Werror to avoid the following build failure:
In file included from hash.c:7:
xxhash.h:2667:5: error: #warning is a GCC extension [-Werror]
2667 | # warning "XXH3 is highly inefficient without ARM or Thumb-2."
| ^~~~~~~
xxhash.h:2667:5: error: #warning "XXH3 is highly inefficient without ARM or Thumb-2." [-Werror=cpp]
Fixes:
- http://autobuild.buildroot.org/results/3124bae73c207f1a118e57e41e222ef464ccb297
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Add license hashes to the hash file and add the information into the
makefile.
Signed-off-by: Jesse Van Gavere <jesseevg@gmail.com>
[Arnout: use correct file names and hashes]
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Fix the following build failure:
In file included from libavcodec/ppc/audiodsp.c:31:
libavcodec/ppc/audiodsp.c: In function 'scalarproduct_int16_altivec':
./libavutil/ppc/util_altivec.h:123:5: error: implicit declaration of function 'vec_vsx_ld'; did you mean 'vec_vslh'? [-Werror=implicit-function-declaration]
123 | vec_vsx_ld(offset, b)
| ^~~~~~~~~~
Fixes:
- http://autobuild.buildroot.org/results/b772d285f978ff9bc3b07872d009633c943f20b1
VSX is indeed an extension to AltiVec, so havinf VSX implies having
AltiVec [0], so we can condition he altivec support on LE ,on VSX being
available.
To be noted, however, is that ffmpeg has a configre switch dedicated to
VSX: --enable-vsx. We do not use it add support for that here, as we are
just fixing the AltiVec support. Adding VSX configure flag is left as an
excercise for a future feature addition.
[0] https://en.wikipedia.org/wiki/AltiVec#VSX_(Vector_Scalar_Extension)
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[yann.morin.1998@free.fr:
- add comment in .mk
- exend commit log to explain VSX implies AltiVec
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
tools needs C++ since the addition of the package in commit
27ad470d7d resulting in the following
build failure:
no -DHAVE_CONFIG_H -I. -I.. -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -I../include -I../master -Wall -DREV=`if test -s ../revision; then cat ../revision; else hg id -i .. 2>/dev/null || echo "unknown"; fi` -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Ofast -g0 -c -o ethercat-Command.o `test -f 'Command.cpp' || echo './'`Command.cpp
/bin/bash: line 1: no: command not found
Fixes:
- http://autobuild.buildroot.org/results/89d096006839f32a3d03786e69e51ec3c5ea70f6
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[yann.morin.1998@free.fr: move it before package's options]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Fix CVE-2022-2652: Depending on the way the format strings in the card
label are crafted it's possible to leak kernel stack memory. There is
also the possibility for DoS due to the v4l2loopback kernel module
crashing when providing the card label on request (reproduce e.g. with
many %s modifiers in a row).
https://github.com/umlaeute/v4l2loopback/blob/v0.12.7/ChangeLog
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
- Fix CVE-2022-29154: An issue was discovered in rsync before 3.2.5 that
allows malicious remote servers to write arbitrary files inside the
directories of connecting peers. The server chooses which
files/directories are sent to the client. However, the rsync client
performs insufficient validation of file names. A malicious rsync
server (or Man-in-The-Middle attacker) can overwrite arbitrary files
in the rsync client target directory and subdirectories (for example,
overwrite the .ssh/authorized_keys file).
- Drop patches (already in version)
- Update hash of COPYING (make openssl license exception clearer by
having it at the top and use modern links in COPYING:
https://github.com/WayneD/rsync/commit/dde469513625c0e10216da9b6f6546aa844431f7)
https://github.com/WayneD/rsync/blob/v3.2.5/NEWS.md
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The upstream commit 7a01882eb37e7504e2450f474d0cc8db60ed26c2
("common: Kconfig.boot: Add FIT_PRINT config option") introduce
CONFIG_FIT_PRINT and make fit_print_contents() empty if it was
not enabled.
Adding CONFIG_FIT_PRINT=y to UBOOT_TOOLS_MAKE_OPTS does not help
while CONFIG_FIT_PRINT=y affects Makefiles only, not C sources.
Add "#define CONFIG_FIT_PRINT 1" to autoconf.h if FIT_SUPPORT enabled.
It would be better to convert uboot-tools to kconfig infrastructure so
we can use KCONFIG_ENABLE_OPT etc. However, that's a much bigger change
and not suitable for backporting to stable branches. Therefore, for now,
take the simple approach of updating autoconf.h.
Signed-off-by: Atsushi Nemoto <atsushi.nemoto@sord.co.jp>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Fix the following build failure with libressl raised since the addition
of the package in commit 8aaa7ecbce:
In file included from internal.h:45,
from card-authentic.c:32:
/nvmedata/autobuild/instance-29/output-1/host/powerpc64-buildroot-linux-gnu/sysroot/usr/include/openssl/x509v3.h:802:10: error: expected ')' before '*' token
802 | uint32_t X509_get_extension_flags(X509 *x);
| ^~~~~~~~~~~~~~~~~~~~~~~~
Fixes:
- http://autobuild.buildroot.org/results/7b50ab363c174636fb27d554223287d7496676ed
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
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>
Fix the following libkrb5 build failure raised since the addition of the
package in commit 736c4c1655:
checking for krb5-config... /bin/krb5-config
checking krb5-config CFLAGS... Failed to find installation architecture
""
checking krb5-config LDFLAGS... Failed to find installation architecture
checking krb5-config reported version... Failed to find installation architecture
()
checking krb5-config reported vendor... Failed to find installation architecture
checking canonical API type... HEIMDAL
[...]
In file included from src/modules/rlm_krb5/rlm_krb5.c:32:
src/modules/rlm_krb5/krb5.h:41:9: error: unknown type name 'krb5_verify_opt'
41 | krb5_verify_opt options;
| ^~~~~~~~~~~~~~~
Fixes:
- http://autobuild.buildroot.org/results/f173d1600c278d910f4cbeae86dcad1ee0f911f9
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
On some CPU architecures it's possible to use MMU pages of different
sizes, for example on ARC or ARM. And while for user-space
applications the page size is supposed to be transparent, there's
still some use of that extra information. In particular it's possible
to align data structures or code/data sections on page boundary, etc.
For these tricks to become possible tools which pack data (think of
the linker, like GNU "ld") need to be informed of the page size to
be considered.
Obviously, there're some sane defaults which are being used most of
the time, so we even think about that peculiarity, but when non-default
value needs to be used, GNU "ld" accepts 2 properties related to page
size:
-z common-page-size=XXX
-z max-page-size=YYY
And while in thery those might be different (but always "common" <= "max"),
and that might make sense if we build for some unknown platfrom,
in case of Buildroot when we build entire target's filesystem and so
know exactly the configuration we're targeting to, we may safely assume
"common-page-size"="max-page-size".
See a lengthy discussion in this thread [1].
Fixes:
http://autobuild.buildroot.net/results/c8b2f331c98453670cd982558144c4fd84674a3d/ (uclibc)
http://autobuild.buildroot.net/results/3a22f7aac38145b26c549254b819f87329e7a77e/ (glibc)
And while at it, recover use of "XX-page-size" for ARC, as with [2]
moving page size selection in the generic code we've got unexpected
override for ARC (note "=", but not "+="):
--------------------->8--------------------
ARCH_TOOLCHAIN_WRAPPER_OPTS = -matomic
--------------------->8--------------------
[1] https://lists.buildroot.org/pipermail/buildroot/2022-July/646176.html
[2] https://git.buildroot.net/buildroot/commit/?id=dcb74db89e74e512e36b32cea6f574a1a1ca84c4
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
SIMD needs VSX with little endian to avoid the following build failure:
In file included from /nvmedata/autobuild/instance-12/output-1/build/jpeg-turbo-2.1.3/simd/powerpc/jccolor-altivec.c:25:
/nvmedata/autobuild/instance-12/output-1/build/jpeg-turbo-2.1.3/simd/powerpc/jccolext-altivec.c: In function 'jsimd_rgb_ycc_convert_altivec':
/nvmedata/autobuild/instance-12/output-1/build/jpeg-turbo-2.1.3/simd/powerpc/jsimd_altivec.h:93:26: warning: implicit declaration of function 'vec_vsx_ld'; did you mean 'vec_vsl'? [-Wimplicit-function-declaration]
93 | #define VEC_LD(a, b) vec_vsx_ld(a, b)
| ^~~~~~~~~~
Fixes:
- http://autobuild.buildroot.org/results/be6d5ad0cee4ee19eb25e595d44555a1af6e073b
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
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>
The python installer package isn't able to overwrite files of packges
that already exist, this causes problems when doing a rebuild or
update without a full clean.
To fix this we can use functionality from importlib to identify and
remove any conflicting python package files before installation.
We also need to use internals from python-installer, as we want to use
the same logic as pyinstaller uses internally for getting the scheme so
that we ensure we clean the correct package scheme (we want it to be the
same as the one we're installing)
Fixes:
Traceback (most recent call last):
File "/home/buildroot/buildroot/support/scripts/pyinstaller.py", line 69, in <module>
main()
File "/home/buildroot/buildroot/support/scripts/pyinstaller.py", line 61, in main
install(
File "/home/buildroot/buildroot/output/host/lib/python3.10/site-packages/installer/_core.py", line 109, in install
record = destination.write_file(
File "/home/buildroot/buildroot/output/host/lib/python3.10/site-packages/installer/destinations.py", line 207, in write_file
return self.write_to_fs(scheme, path_, stream, is_executable)
File "/home/buildroot/buildroot/output/host/lib/python3.10/site-packages/installer/destinations.py", line 167, in write_to_fs
raise FileExistsError(message)
FileExistsError: File already exists: /home/buildroot/buildroot/output/target/usr/lib/python3.10/site-packages/tinycss2/__init__.py
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Tested-by: Marcus Hoffmann <marcus.hoffmann@othermo.de>
[yann.morin.1998@free.fr:
- extend commit log about the use of the installer internals (the
symbols prefixed with '_')
- check path.files against explicitly None
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The python installer cli isn't able to overwrite files of packages
that already exist, this causes problems when doing a rebuild or
update without a full clean.
Since we need to add functionality to our pyinstaller.py script to fix
this issue we must also use pyinstaller.py for host python packages.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Tested-by: Marcus Hoffmann <marcus.hoffmann@othermo.de>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Commit fda53f0791 ("package/Makefile.in:
add detection for the lack of C library") added an $(error ...)
message when no C library is available for the currently selected
architecture.
However, this error message pops up not just when building, so for
example, the command:
make BR2_HAVE_DOT_CONFIG=y VARS=%_LICENSE printvars
no longer works (this command is used by the pkg-stats script).
We restore a functional behavior by doing the check only when
BR_BUILDING=y.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The network-manager package builds the nmcli utility when the readline
package is enabled. However, this is not necessarily obvious to the
user. Therefore, this commit adds an explicit option to enable the nmcli
tool, which automatically selects readline.
Signed-off-by: Michael Fischer <mf@go-sys.de>
[yann.morin.1998@free.fr: rewrap commit log and help text]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Fix the following aarch64_be build failure probably raised since the
addition of the package:
/home/buildroot/autobuild/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/aarch64_be-none-linux-gnu/10.3.1/../../../../aarch64_be-none-linux-gnu/bin/ld: ./.libs/libtesseract.so: undefined reference to `tesseract::IntSimdMatrix::intSimdMatrixNEON'
Fixes:
- http://autobuild.buildroot.org/results/b9246a37fcf6be4fabfc491daddadfb09e0a320a
Update the comment about _AUTORECONF=YES, list the two patches since
both touch configure.ac
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[yann.morin.1998@free.fr: upsdate comment about _AUTORECONF=YES]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Fix the following build failure with BR2_PACKAGE_WOLFSSL_ALL raised
since bump to version 5.9.0 in commit
da912a3d2a:
In file included from ../../../../src/libstrongswan/utils/utils.h:59,
from ../../../../src/libstrongswan/library.h:101,
from wolfssl_common.h:29,
from wolfssl_aead.c:23:
wolfssl_aead.c:90:16: error: conflicting types for 'encrypt'; have '_Bool(union <anonymous>, chunk_t, chunk_t, chunk_t, chunk_t *)'
90 | METHOD(aead_t, encrypt, bool,
| ^~~~~~~
../../../../src/libstrongswan/utils/utils/object.h:99:20: note: in definition of macro 'METHOD'
99 | static ret name(union {iface *_public; this;} \
| ^~~~
In file included from /home/autobuild/autobuild/instance-5/output-1/host/powerpc64le-buildroot-linux-musl/sysroot/usr/include/wolfssl/wolfcrypt/wc_port.h:573,
from /home/autobuild/autobuild/instance-5/output-1/host/powerpc64le-buildroot-linux-musl/sysroot/usr/include/wolfssl/wolfcrypt/types.h:35,
from /home/autobuild/autobuild/instance-5/output-1/host/powerpc64le-buildroot-linux-musl/sysroot/usr/include/wolfssl/wolfcrypt/logging.h:33,
from /home/autobuild/autobuild/instance-5/output-1/host/powerpc64le-buildroot-linux-musl/sysroot/usr/include/wolfssl/ssl.h:35,
from wolfssl_common.h:64,
from wolfssl_aead.c:23:
/home/autobuild/autobuild/instance-5/output-1/host/powerpc64le-buildroot-linux-musl/sysroot/usr/include/unistd.h:149:6: note: previous declaration of 'encrypt' with type 'void(char *, int)'
149 | void encrypt(char *, int);
| ^~~~~~~
Fixes:
- http://autobuild.buildroot.org/results/02f080c2f6d8272cb8cc1de66e058d66fb7499bc
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
In addition to --enable-video-opengles, SDL2 configure script also
looks at --enable-video-opengles1 and --enable-video-opengles2. Since
all OpenGL ES providers in Buildroot provide at least up to OpenGL ES
2, enable both options when BR2_PACKAGE_SDL2_OPENGLES=y.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr: split long lines]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Add many more explicit --disable-<foo>, as we have for example seen
video-vivante being autodetected when not needed.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
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>
The CPIO filesystem generated by the test_python_s3transfer test is
too large, and doesn't fit as an initramfs in the 256MB of RAM
available in the versatilepb machine. This causes a "Initramfs
unpacking failed: write error" when booting, and many files being
missing from the root filesystem, ultimately causing the test to fail.
It would make sense to switch all test cases to use ext2 + a
hard-drive, but for now, let's fix the few test cases that are causing
problems.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/2884635126
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr:
- drop superfluous# BR2_TARGET_ROOTFS_TAR is not set
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The CPIO filesystem generated by the test_python_botocore test is too
large, and doesn't fit as an initramfs in the 256MB of RAM available
in the versatilepb machine. This causes a "Initramfs unpacking failed:
write error" when booting, and many files being missing from the root
filesystem, ultimately causing the test to fail.
It would make sense to switch all test cases to use ext2 + a
hard-drive, but for now, let's fix the few test cases that are causing
problems.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/2884635042
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr:
- drop superfluous# BR2_TARGET_ROOTFS_TAR is not set
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The CPIO filesystem generated by the test_python_boto3 test is too
large, and doesn't fit as an initramfs in the 256MB of RAM available
in the versatilepb machine. This causes a "Initramfs unpacking failed:
write error" when booting, and many files being missing from the root
filesystem, ultimately causing the test to fail.
It would make sense to switch all test cases to use ext2 + a
hard-drive, but for now, let's fix the few test cases that are causing
problems.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/2884635041
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr:
- drop superfluous# BR2_TARGET_ROOTFS_TAR is not set
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
In commit
9267b0f14d ("package/f2fs-tools: bump to
version 1.15.0"), f2fs-tools was bumped from 1.14.0 to 1.15.0.
It turns out that this version bump causes the output of dump.f2fs to
slightly change.
In version 1.14.0, it looked like this:
Info: Segments per section = 1
Info: Sections per zone = 1
Info: sector size = 512
Info: total sectors = 262144 (128 MB)
Info: MKFS version
"Linux version 5.4.0-124-generic (buildd@lcy02-amd64-089) (gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1)) #140-Ubuntu SMP Thu Aug 4 02:23:37 UTC 2022"
Info: FSCK version
from "Linux version 5.4.0-124-generic (buildd@lcy02-amd64-089) (gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1)) #140-Ubuntu SMP Thu Aug 4 02:23:37 UTC 20
22"
to "Linux version 5.4.0-124-generic (buildd@lcy02-amd64-089) (gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1)) #140-Ubuntu SMP Thu Aug 4 02:23:37 UTC 20
22"
Info: superblock features = 0 :
Info: superblock encrypt level = 0, salt = 00000000000000000000000000000000
Info: total FS sectors = 262144 (128 MB)
Info: CKPT version = 70c101c3
Info: checkpoint state = 181 : trimmed nat_bits unmount
In version 1.15.0, it looked like this:
Info: MKFS version
"Linux version 5.4.0-124-generic (buildd@lcy02-amd64-089) (gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1)) #140-Ubuntu SMP Thu Aug 4 02:23:37 UTC 2022"
Info: FSCK version
from "Linux version 5.4.0-124-generic (buildd@lcy02-amd64-089) (gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1)) #140-Ubuntu SMP Thu Aug 4 02:23:37 UTC 20
22"
to "Linux version 5.4.0-124-generic (buildd@lcy02-amd64-089) (gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1)) #140-Ubuntu SMP Thu Aug 4 02:23:37 UTC 20
22"
Info: superblock features = 0 :
Info: superblock encrypt level = 0, salt = 00000000000000000000000000000000
Info: Segments per section = 1
Info: Sections per zone = 1
Info: total FS sectors = 262144 (128 MB)
Info: CKPT version = b89f8bb
Info: checkpoint state = 181 : trimmed nat_bits unmount
You will notice that the message "Info: total sectors = 262144 (128
MB)" is no longer present, and only "Info: total FS sectors =
262144 (128 MB)" is not present.
Except our test case was precisely looking for this "Info: total
sectors" string in the output, causing the test to fail.
We fix this by simply matching on "Info: total FS sectors" now.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/2884634814
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The "find" and "xargs" commands, from the "findutils" package are used
during the build process. See for example [1].
Even if it's a quite common package which is almost sure to be present
on the host, it should be listed here. When writing new recipes, hooks
and scripts, it is generally safe and portable to restrict to the
host dependencies listed in those prerequisites.
This commit just add the missing "findutils" package in this list.
[1] https://git.buildroot.org/buildroot/tree/Makefile?h=2022.05.1#n737
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
We are trying to not build the perf documentation. However, the hook
being used to do so was named incorrectly. As a result, the build steps
to disable the documentation were never executed.
Rename the hook from
LINUX_POST_PATCH_HOOKS
to
LINUX_TOOLS_POST_PATCH_HOOKS
to fix the issue.
Fixes: 20b1446669 ("linux/tools: make it a real, separate package")
Signed-off-by: Markus Mayer <mmayer@broadcom.com>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
- Fix CVE-2022-1114: A heap-use-after-free flaw was found in
ImageMagick's RelinquishDCMInfo() function of dcm.c file. This
vulnerability is triggered when an attacker passes a specially crafted
DICOM image file to ImageMagick for conversion, potentially leading to
information disclosure and a denial of service.
- Fix CVE-2022-32545: A vulnerability was found in ImageMagick, causing
an outside the range of representable values of type 'unsigned char'
at coders/psd.c, when crafted or untrusted input is processed. This
leads to a negative impact to application availability or other
problems related to undefined behavior.
- Fix CVE-2022-32546: A vulnerability was found in ImageMagick, causing
an outside the range of representable values of type 'unsigned long'
at coders/pcl.c, when crafted or untrusted input is processed. This
leads to a negative impact to application availability or other
problems related to undefined behavior.
- Fix CVE-2022-32547: In ImageMagick, there is load of misaligned
address for type 'double', which requires 8 byte alignment and for
type 'float', which requires 4 byte alignment at
MagickCore/property.c. Whenever crafted or untrusted input is
processed by ImageMagick, this causes a negative impact to application
availability or other problems related to undefined behavior.
- Update hash of LICENSE (year updated with
https://github.com/ImageMagick/ImageMagick/commit/80629dfb3fea55eefa2dd8bdd9ca1be341502e16)
https://github.com/ImageMagick/Website/blob/main/ChangeLog.md
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
In 96c3b52132 (package/uacme: don't allow ualpn with mbedTLS), the
preference order moved openssl before mbedtls, because ualpn was not
compatible with mbedtls. That caused the preference order in the .mk to
diverge semantically from the preference order in the Config.in.
Indeed, openssl is only selected when neither gnutls nor mbedtls are
enabled, so openssl is clearly leastpreferred crypto backend. But when
both openssl and mbedtls were enabled, then uacme would use opensslC
because of ualpn.
The ualpn limitation was lifted in 6c7b46945e (package/uacme: allow
ualpn with mbedTLS), but the preference order in the .mk was not
restored to match that of the Config.in.
Restore the order in the .mk so that openssl is again treated as the
least-preferred crypto backend.
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[yann.morin.1998@free.fr:
- split off to its own patch
- write the full commit log
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The gcc man page states that specifying Neon as part of the fpu setting
has no effect, unless the -funsafe-math-optimizations is also specified,
because Neon is not compliant with IEEE 754:
```
If the selected floating-point hardware includes the NEON extension
(e.g. -mfpu=neon), note that floating-point operations are not
generated by GCC's auto-vectorization pass unless
-funsafe-math-optimizations is also specified. This is because NEON
hardware does not fully implement the IEEE 754 standard for
floating-point arithmetic (in particular denormal values are treated
as zero), so the use of NEON instructions may lead to a loss of
precision.
```
-funsafe-math-optimizations must be explictly specified per package to
really use NEON as FPU, but it's something that is left to the user as
well as setting BR2_ARM_FPU_NEON_VFPV4. This way the default
BR2_ARM_FPU_VFPV4D16 is used as previously. So let's revert the
offending patch.
This reverts commit aaced92e8c.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The gcc man page states that specifying Neon as part of the fpu setting
has no effect, unless the -funsafe-math-optimizations is also specified,
because Neon is not compliant with IEEE 754:
```
If the selected floating-point hardware includes the NEON extension
(e.g. -mfpu=neon), note that floating-point operations are not
generated by GCC's auto-vectorization pass unless
-funsafe-math-optimizations is also specified. This is because NEON
hardware does not fully implement the IEEE 754 standard for
floating-point arithmetic (in particular denormal values are treated
as zero), so the use of NEON instructions may lead to a loss of
precision.
```
-funsafe-math-optimizations must be explictly specified per package to
really use NEON as FPU, but it's something that is left to the user as
well as setting BR2_ARM_FPU_NEON_VFPV4. This way the default
BR2_ARM_FPU_VFPV4D16 is used as previously. So let's revert the
offending patch.
This reverts commit 115ee05214.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The gcc man page states that specifying Neon as part of the fpu setting
has no effect, unless the -funsafe-math-optimizations is also specified,
because Neon is not compliant with IEEE 754:
```
If the selected floating-point hardware includes the NEON extension
(e.g. -mfpu=neon), note that floating-point operations are not
generated by GCC's auto-vectorization pass unless
-funsafe-math-optimizations is also specified. This is because NEON
hardware does not fully implement the IEEE 754 standard for
floating-point arithmetic (in particular denormal values are treated
as zero), so the use of NEON instructions may lead to a loss of
precision.
```
-funsafe-math-optimizations must be explictly specified per package to
really use NEON as FPU, but it's something that is left to the user as
well as setting BR2_ARM_FPU_NEON_VFPV4. This way the default
BR2_ARM_FPU_VFPV4D16 is used as previously. So let's revert the
offending patch.
This reverts commit f8528acdfd.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The gcc man page states that specifying Neon as part of the fpu setting
has no effect, unless the -funsafe-math-optimizations is also specified,
because Neon is not compliant with IEEE 754:
```
If the selected floating-point hardware includes the NEON extension
(e.g. -mfpu=neon), note that floating-point operations are not
generated by GCC's auto-vectorization pass unless
-funsafe-math-optimizations is also specified. This is because NEON
hardware does not fully implement the IEEE 754 standard for
floating-point arithmetic (in particular denormal values are treated
as zero), so the use of NEON instructions may lead to a loss of
precision.
```
-funsafe-math-optimizations must be explictly specified per package to
really use NEON as FPU, but it's something that is left to the user as
well as setting BR2_ARM_FPU_NEON_VFPV4. This way the default
BR2_ARM_FPU_VFPV4D16 is used as previously. So let's revert the
offending patch.
This reverts commit 23329364e2.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Update fourth patch to avoid the following build failure with webrtc
raised since commit a40a516c8a:
../output-1/build/pulseaudio-16.1/src/modules/echo-cancel/meson.build:13:0: ERROR: No host machine compiler for 'src/modules/echo-cancel/webrtc.cc'
That is because we removed the C++ language from the global meson.build.
Add it back to the local meson.build in echo-cancel.
The echo-cancel module is always built, but the echo-cancel meson.build
is only included if webrtc-aec is enabled. We only enable it when
webrtc-audio-processing is selected, and that package depends on C++.
Therefore, it is safe to depend on C++ in the echo-cancel meson.build.
Fixes:
- http://autobuild.buildroot.org/results/e60d72268667ed57a254d7552fa2d785e2e21726
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
- Drop default value of BR2_PACKAGE_XENOMAI_REPOSITORY
- Add BR2_PACKAGE_XENOMAI_{CUSTOM_VERSION_VALUE,REPOSITORY_VERSION} to
mimick what is done by other packages (e.g. barebox, u-boot)
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Fix the following build failure without threads raised since bump to
version 9.21.4 in commit e4c81885ed:
CompactDisplay.cpp:13:14: fatal error: pthread.h: No such file or directory
13 | #include <pthread.h>
| ^~~~~~~~~~~
For an unknown reason, previously drbdmon (which unconditionally uses
threads) was always wrongly disabled:
configure:5846: checking whether /home/fabrice/buildroot/output/host/bin/arm-linux-g++ supports C++11 features by default
configure:6141: /home/fabrice/buildroot/output/host/bin/arm-linux-g++ -c -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -g0 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 conftest.cpp >&5
configure:6141: $? = 0
configure:6149: result: yes
configure:6824: WARNING: No C++11 compiler found, disabling drbdmon build.
The correct activation of drbdmon could be a side-effect of
https://github.com/LINBIT/drbd-utils/commit/b235e83409b0daf5a3454cdc83aec2e5b335d38e
Fixes:
- http://autobuild.buildroot.org/results/2cc7d771176ccde7539cc93d83e9621d9ada8357
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Github repository mripard/sunxi-mali states to use Lima in place of
sunxi-mali because it's deprecated, but this package is still useful in
Buildroot so I want to move the SITE to my Github fork of the original
repository that already contains a patch to fix a build failure showing
up with Linux version >= 5.15.
The upstream patch fixes missing DMA_BUF module inclusion that leads to
build failure. The patch includes DMA_BUF by using:
MODULE_IMPORT_NS(DMA_BUF);
My idea is to continue to maintain this package in parallel to Lima since
it seems to be still useful.
Fixes:
http://autobuild.buildroot.net/results/8f25c26de737c358b3b43a10737609465b4e1398/
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Set CROSS variable otherwise makedumpfile will use it to undefine the
host architecture through -U__$(HOST_ARCH)__ if $(TARGET) is not equal
to $(HOST_ARCH). This will result in the following build failure since
the addition of the package in commit
adb64a97e7 if aarch64_be is cross-compiled
on a aarch64 host for example:
/home/autobuild/autobuild/instance-5/output-1/host/bin/aarch64_be-buildroot-linux-uclibc-gcc -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O3 -g0 -g -O2 -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DVERSION='"1.7.0"' -DRELEASE_DATE='"8 Nov 2021"' -D__aarch64_be__ -U__aarch64__ -DUSELZO -c -o ./print_info.o print_info.c
[...]
makedumpfile.c: In function 'is_kvaddr':
makedumpfile.c:1547:46: error: 'KVBASE' undeclared (first use in this function)
1547 | return (addr >= (unsigned long long)(KVBASE));
| ^~~~~~
Fixes:
- http://autobuild.buildroot.org/results/e4e10364e1a24099ce31bf20eacf5adedf93e5a7
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Commit 4dff1be05e (package/libvirt: libvirtd needs C++ for nmap-ncat)
introduce a recursive dependency (really: a circular dependency):
package/busybox/Config.in:33:error: recursive dependency detected!
package/busybox/Config.in:33: symbol BR2_PACKAGE_BUSYBOX_SHOW_OTHERS is selected by BR2_PACKAGE_EBTABLES_UTILS_SAVE
package/ebtables/Config.in:11: symbol BR2_PACKAGE_EBTABLES_UTILS_SAVE depends on BR2_PACKAGE_EBTABLES
package/ebtables/Config.in:1: symbol BR2_PACKAGE_EBTABLES is selected by BR2_PACKAGE_LIBVIRT_DAEMON
package/libvirt/Config.in:44: symbol BR2_PACKAGE_LIBVIRT_DAEMON depends on BR2_PACKAGE_NETCAT_OPENBSD
package/netcat-openbsd/Config.in:1: symbol BR2_PACKAGE_NETCAT_OPENBSD depends on BR2_PACKAGE_BUSYBOX_SHOW_OTHERS
We can't drop the C++ dependency and switch the netcat-openbsd and
nmap-ncat dependencies conditions without adding a glibc dependency.
So always mandate C++ even if is only needed by nmap and not
netcat-openbsd
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Commit 'dc7ca780a0 package/gstreamer1/gst1-plugins-good: convert package
type to meson' from 2019 removed the symbol, stating:
Remove BR2_PACKAGE_GST1_PLUGINS_GOOD_ZLIB
Existing configs will already have BR2_PACKAGE_ZLIB selected, so no
legacy entry is needed for BR2_PACKAGE_GST1_PLUGINS_GOOD_ZLIB
So drop the reference to the symbol.
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
These inexistent symbols are referenced since 2014, from commit:
'aa441aa84c openocd: bump to version 0.8.0'
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The typo was added in 2018 by commit
'f3da9ffff0 package/busybox: invert dependency with netcat-openbsd'
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Since this commit from 2010:
'87b81bb56f toolchain: move sysroot to host dir'
BR2_STAGING_DIR does not exist anymore.
So fix the typo added in 2014 with commit:
8956c336eb package/qemu: add SDL frontends
Cc: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
BR2_sparc_v7 was removed in 2013 in commit '16bcf46a63 arch/sparc: drop
old SUN-specific variants'.
BR2_sparc_sparchfleon and BR2_sparc_sparchfleonv8 were moved to legacy
handling in 2014 in commit '43b78e7285 arch: sparc: Add leon3 cpu type
and remove sparc{s,h}fleon{,v8}' and later removed from legacy handling
in 2020.
So drop the remaining references for these symbols.
Cc: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
From time to time we have a reference added to the inexistent BR2_nios:
$ git log --oneline -G'BR2_nios\>'
726dcc6eee package/libvncserver: needs dynamic library
8cd840b7e8 package/ffmpeg: fix typo "nios" -> "nios2"
bd2544d3d3 package/ffmpeg: simplify BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS logic
de7523259b libplayer: fix typo on BR2_nios2
615d65d3c6 mplayer: add missing reverse dependencies for nios2 and sh2a
Fix the last commit, from 2019, like it was done before.
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
BR2_LINUX_KERNEL_CUSTOM_LOCAL was moved to legacy handling during release
2016.11 but does not select BR2_LEGACY.
Add the select, like done by all other symbols in the file.
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
All other occurrencies in the tree simply do:
select SYMBOL1 if SYMBOL2
instead of
select SYMBOL1 if SYMBOL2=y
So do the same here for consistency.
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This is the only use in the tree without the space.
Do like the other 2k+ uses in the tree and add the space:
-depends on!BR2_...
+depends on !BR2_...
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Fix the following static build failure raised since bump to version 0.28
in commit 1b677db703:
/home/buildroot/autobuild/run/instance-2/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-uclibcgnueabi/9.3.0/../../../../arm-buildroot-linux-uclibcgnueabi/bin/ld: /home/buildroot/autobuild/run/instance-2/output-1/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libpng.a(png.o): in function `png_reset_crc':
png.c:(.text+0x738): undefined reference to `crc32'
Note that the custom, hand-rolled configure script inserts the LIBS we
pass on the command line, in front of the hard-coded LIBS, which
currently is just LIBS=-lpng, so we end up with a final LIBS set to:
LIBS=-L.../sysroot/usr/lib -lpng16 -lz -lpng
... the latter -lpng being redundant and unnecessary, but innocuous.
Fixes:
- http://autobuild.buildroot.org/results/97543d8df5c40818e05622490e4aad60b48934a6
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[yann.morin.1998@free.fr: split multi-line one item per line]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Disable documentation to avoid the following build failure if a non
working asciidoc or a2x is found on the system:
asciidoc -o html/syslinux.html /nvmedata/autobuild/instance-3/output-1/build/syslinux-6.03/txt/syslinux.txt
/nvmedata/autobuild/instance-3/output-1/per-package/syslinux/host/bin/python3: No module named asciidoc
Setting {ASCIIDOC,A2X_XML}_OK to a value different of 0 will disable
html, man, xhtml and text documentation
Fixes:
- http://autobuild.buildroot.org/results/47f876ccb56831cc1bb9e6c2f7dbce423581a0dd
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Fix the following musl build failure raised since bump to version
20211207 in commit ecf85b4ef5:
receivedata.c: In function 'findSlice':
receivedata.c:348:2: error: unknown type name 'ptrdiff_t'
348 | ptrdiff_t pos = slice - clst->slices;
| ^~~~~~~~~
receivedata.c:17:1: note: 'ptrdiff_t' is defined in header '<stddef.h>'; did you forget to '#include <stddef.h>'?
16 | #include "fec.h"
+++ |+#include <stddef.h>
17 |
Fixes:
- http://autobuild.buildroot.org/results/30208c6f175967fed6de690447a09e0c86547b24
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Disable man pages to avoid the following build failure if a non-working
a2x is found on the system raised since bump to version 11 in commit
b72b849ad5:
/usr/bin/a2x -f manpage -D /nvmedata/autobuild/instance-23/output-1/build/jose-11/build /nvmedata/autobuild/instance-23/output-1/build/jose-11/doc/man/jose.1.adoc
/nvmedata/autobuild/instance-23/output-1/host/bin/python3: Error while finding module specification for 'asciidoc.a2x' (ModuleNotFoundError: No module named 'asciidoc')
Fixes:
- http://autobuild.buildroot.org/results/ae69f7fd1258d99a5b08eeb8c67904be53eabf15
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Commit c343e01ac4 made udhcpc send a
single DHCP request (instead of 3) before going to the background, thus
speeding up the boot process if the DHCP lease is not obtained
immediately. Unfortunately, this can also slow down the acquisition of
the lease as, after going to the background, udhcpc waits for 20 seconds
(instead of 3) before retrying.
Speed up the lease acquisition by setting the retry timeout to 3
seconds.
Signed-off-by: Edgar Bonet <bonet@grenoble.cnrs.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Fix the following libressl build failure raised since the addition of
the package in commit 27b8d0ba8c:
/home/buildroot/autobuild/instance-0/output-1/host/lib/gcc/armeb-buildroot-linux-gnueabi/11.3.0/../../../../armeb-buildroot-linux-gnueabi/bin/ld: libntp/libntp.a(ntp_random.c.1.o): in function `ntp_RAND_priv_bytes':
ntp_random.c:(.text+0xac): undefined reference to `RAND_priv_bytes'
Fixes:
- http://autobuild.buildroot.org/results/a6a825b7f0efc7c82e8ecf792a1f9951ffb047c5
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Commit e8011a08b6 (package/ace: needs C++11) did not explain why it
passed C++ flags via the pre-processor flags rather than as C++ flags
(via ACE's CCFLAGS).
This caused some head-scratching when reviewing and applying
803247337d (package/ace: fix build failure due to gcc bug 101915).
Add a comment to try and explain the non-standard use of pre-processor
flags to pass actual C++ flags.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Giulio Benetti <giulio.benetti@benettiengineering.com>
Cc; Weber, Matthew L Collins <Matthew.Weber@collins.com>
Cc: Fabrice Fontaine <fontaine.fabrice@gmail.com>
The ace package exhibits gcc bug 101915 when built for the Microblaze
architecture with optimization enabled, which causes a build failure.
As done for other packages in Buildroot work around this gcc bug by
setting optimization to -O0 if BR2_TOOLCHAIN_HAS_GCC_BUG_101915=y.
Fixes:
http://autobuild.buildroot.net/results/f8f/f8f8de99abe92175954c370ad99fee43942bcdcc/
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
[yann.morin.1998@free.fr: slight simplification]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Commit 666084f494 ("linux:linux.mk: Add
"firmware-imx" dependency if needed") introduced a dependency from
linux to firmware-imx, but based on the incorrect BR2 option.
This commit fixes this mistake.
Signed-off-by: Francois Perrad <francois.perrad@gadz.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
libgit2 is currently a library without any reverse dependencies so the
missing atomic symbols do not cause build failures yet.
libgit2 uses the atomics intrinsics on gcc >= 4.7 and the sync
intrinsics on previous gcc versions. Since gcc 4.9 is the new
minimum, ignore the sync intrinsics requirements.
The next version of libgit2 will also build a binary, which will
expose the problem.
Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Fixes garbled tag name in std log file output (critical), and addresses a
minor issue with confusing project name from `syslogd -v` vs `logger -v`.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2022-08-13 12:52:17 +02:00
194 changed files with 2318 additions and 330 deletions
Fix -DENABLE_CPU_USAGE_FEATURE=OFF to allow the user to disable
CPU_USAGE and avoid the following build failure without threads:
/home/giuliobenetti/autobuild/run/instance-2/output-1/build/hawktracer-e53b07bc812c4cfe8f6253ddb48ac43de8fa74a8/lib/platform/linux/cpu_usage.c:5:10: fatal error: pthread.h: No such file or directory
Fix the following build failure with musl or uclibc-ng and libexecinfo:
/home/giuliobenetti/autobuild/run/instance-2/output-1/build/intel-mediadriver-22.5.1/media_softlet/linux/common/os/osservice/mos_utilities_specific.cpp:2481: undefined reference to `backtrace'
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Peter Korsgaard