Fabrice Fontaine [Mon, 15 Aug 2022 16:01:24 +0000 (18:01 +0200)]
package/uacme: ualpn needs libopenssl
ualpn is not compatible with libressl as stated by upstream in
https://github.com/ndilieto/uacme/commit/32546c7caa1626bbef860cf81e53d10e29fca5cb
resulting in the following build failure:
ualpn.c: In function 'ssl_client_hello_cb':
ualpn.c:2038:16: error: 'SSL_CLIENT_HELLO_RETRY' undeclared (first use in this function); did you mean 'SSL_F_CLIENT_HELLO'?
2038 | return SSL_CLIENT_HELLO_RETRY;
| ^~~~~~~~~~~~~~~~~~~~~~
| SSL_F_CLIENT_HELLO
Fabrice Fontaine [Mon, 15 Aug 2022 16:01:24 +0000 (18:01 +0200)]
package/uacme: fix crypto backend preference order
In 96c3b52132b4 (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 6c7b46945e65 (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.
Giulio Benetti [Mon, 15 Aug 2022 15:48:54 +0000 (17:48 +0200)]
Revert "configs/bananapi_m1: use NEON+VFPv4 as FPU strategy"
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.
Giulio Benetti [Mon, 15 Aug 2022 15:48:53 +0000 (17:48 +0200)]
Revert "configs/olimex_a20_olinuxino_lime: use NEON+VFPv4 as FPU strategy"
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.
Giulio Benetti [Mon, 15 Aug 2022 15:48:52 +0000 (17:48 +0200)]
Revert "configs/olimex_a20_olinuxino_lime2: use NEON+VFPv4 as FPU strategy"
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.
Giulio Benetti [Mon, 15 Aug 2022 15:48:51 +0000 (17:48 +0200)]
Revert "configs/olimex_a33_olinuxino: use NEON+VFPv4 as FPU strategy"
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.
../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.
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.
- 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)
/home/autobuild/autobuild/instance-1/output-1/per-package/netsniff-ng/host/bin/../lib/gcc/x86_64-buildroot-linux-uclibc/10.3.0/../../../../x86_64-buildroot-linux-uclibc/bin/ld: netsniff-ng/tprintf.o: in function `tprintf_flush':
tprintf.c:(.text+0x42c): undefined reference to `pthread_spin_lock'
Opencv4 library objdetect needs library dnn, otherwise it throws:
```
-- Module opencv_objdetect disabled because opencv_dnn dependency can't be resolved!
```
So let's "select BR2_PACKAGE_OPENCV4_LIB_DNN" if
BR2_PACKAGE_OPENCV4_LIB_OBJDETECT is enabled.
Giulio Benetti [Fri, 5 Aug 2022 23:24:04 +0000 (01:24 +0200)]
package/sunxi-mali-utgard-driver: move package SITE to Github giuliobenetti/sunxi-mali
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.
Fabrice Fontaine [Mon, 15 Aug 2022 09:40:54 +0000 (11:40 +0200)]
package/makedumpfile: set CROSS
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 adb64a97e79bcb4e28450dd858654003ec8706c3 if aarch64_be is cross-compiled
on a aarch64 host for example:
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));
| ^~~~~~
Fabrice Fontaine [Sun, 14 Aug 2022 18:27:34 +0000 (20:27 +0200)]
package/libvirt: fix libvirtd dependency
Commit 4dff1be05e90 (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
Makefile:575: *** libbsd is in the dependency chain of netcat-openbsd that has added it to its _DEPENDENCIES variable without selecting it or depending on it from Config.in. Stop.
Joachim Wiberg [Mon, 15 Aug 2022 09:07:36 +0000 (11:07 +0200)]
package/sysklogd: bump to version 2.4.4
Only one change compared to v2.4.3, fix for running `syslogd -T`, which
should use local time for all remote messages, but time is always logged
with "Jan 0 00:00:00".
package/gstreamer1/gst1-plugins-good: drop bogus BR2_PACKAGE_GST1_PLUGINS_GOOD_ZLIB
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
package/directfb: drop bogus BR2_PACKAGE_DIRECTFB_CYBER5K
The inexistent symbol is reference since 2008, see commit '8a12bab608
widen options to configure directfb, patch by Micha Nelissen
<[email protected]>'
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
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.
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.
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.
/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.
Makefile:575: *** libusb is in the dependency chain of libftdi1 that has added it to its _DEPENDENCIES variable without selecting it or depending on it from Config.in. Stop.
Fabrice Fontaine [Sun, 14 Aug 2022 20:20:57 +0000 (22:20 +0200)]
package/syslinux: disable documentation
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
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 |
Fabrice Fontaine [Sun, 14 Aug 2022 18:12:34 +0000 (20:12 +0200)]
package/jose: disable man pages
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 b72b849ad597810823ecf9efe471a40e2427c8e8:
/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')
Edgar Bonet [Sat, 13 Aug 2022 20:53:17 +0000 (22:53 +0200)]
package/busybox: speed up DHCP lease acquisition
Commit c343e01ac4908f76520cf9a405ed87650e78dc62 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.
/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'
Yann E. MORIN [Sun, 14 Aug 2022 13:29:01 +0000 (15:29 +0200)]
paclage/ace: explain why we use C+ pre-processor flags for C++ flags
Commit e8011a08b6fd (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 803247337d35 (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.
Makefile:575: *** minizip is in the dependency chain of domoticz that has added it to its _DEPENDENCIES variable without selecting it or depending on it from Config.in. Stop.
Francois Perrad [Fri, 12 Aug 2022 15:58:55 +0000 (17:58 +0200)]
linux/linux: fix firmware-imx dependency
Commit 666084f4943773fd659393e16982ab2baaa99d0e ("linux:linux.mk: Add
"firmware-imx" dependency if needed") introduced a dependency from
linux to firmware-imx, but based on the incorrect BR2 option.
/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'
p11_attr.c: In function 'pkcs11_zap_attrs':
p11_attr.c:167:2: error: 'for' loop initial declarations are only allowed in C99 mode
for (unsigned i = 0; i < 32; i++) {
^
p11_attr.c:167:2: note: use option -std=c99 or -std=gnu99 to compile your code
Makefile:575: *** snappy is in the dependency chain of python-snappy that has added it to its _DEPENDENCIES variable without selecting it or depending on it from Config.in. Stop.
In function 'complete_incr_bin',
inlined from 'dispatch_bin_command' at proto_bin.c:1010:17,
inlined from 'try_read_command_binary' at proto_bin.c:119:9:
proto_bin.c:272:31: error: array subscript 'protocol_binary_request_incr[0]' is partly outside array bounds of 'char[45]' [-Werror=array-bounds]
272 | req->message.body.delta = ntohll(req->message.body.delta);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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.
/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
5 | #include <pthread.h>
| ^~~~~~~~~~~
hw.cc: In member function 'long long int hw::value::asInteger() const':
hw.cc:2462:36: error: 'stoll' was not declared in this scope
return stoll(This->s, NULL, 0);
^
In file included from sm-common.c:51:
sm-common.h:33:1: error: unknown type name 'DES_LONG'
33 | DES_LONG DES_cbc_cksum_3des(const unsigned char *in, DES_cblock *output, long length,
| ^~~~~~~~
Makefile:575: *** mysql is in the dependency chain of freeradius-server that has added it to its _DEPENDENCIES variable without selecting it or depending on it from Config.in. Stop.
/home/autobuild/autobuild/instance-5/output-1/host/lib/gcc/sh4eb-buildroot-linux-musl/11.3.0/../../../../sh4eb-buildroot-linux-musl/bin/ld: /home/autobuild/autobuild/instance-5/output-1/host/lib/gcc/sh4eb-buildroot-linux-musl/11.3.0/libgcc.a(unwind-dw2.o): in function `size_of_encoded_value':
/home/autobuild/autobuild/instance-5/output-1/build/host-gcc-final-11.3.0/build/sh4eb-buildroot-linux-musl/libgcc/../../../libgcc/unwind-pe.h:89: undefined reference to `abort'
CMake Error at /home/giuliobenetti/autobuild/run/instance-1/output-1/build/glog-0.6.0/CMakeFiles/CMakeTmp/CMakeLists.txt:18 (add_executable):
Target "cmTC_ed950" links to target "Threads::Threads" but the target was
not found. Perhaps a find_package() call is missing for an IMPORTED
target, or an ALIAS target is missing?
However this raise a build failure with ljsyscall because aarch64_be
directory does not exist so use arm64 instead
/usr/bin/install: cannot stat '/home/buildroot/autobuild/instance-1/output-1/build/ljsyscall-0.12/syscall/linux/aarch64_be/*.lua': No such file or directory
Niklas Cassel [Wed, 10 Aug 2022 11:50:55 +0000 (13:50 +0200)]
board/riscv/nommu: bump kernel version and drop no longer needed patch
Bump the kernel version for all riscv nommu configs from 5.18 to 5.19.
That way, we can remove the one and only riscv nommu patch,
since this patch is included in kernel 5.19.
Niklas Cassel [Thu, 11 Aug 2022 09:40:49 +0000 (11:40 +0200)]
package/elf2flt: fix fatal error regression on m68k, xtensa, riscv64
This series fixes a fatal error at link time on m68k, xtensa,
and riscv64, caused by a bad upstream elf2flt commit.
Without this patch, m68k, xtensa, and riscv64 would result in
a fatal error:
ERROR: text=0x3bab8 overlaps data=0x33f60 ?
With this patch, qemu_m68k_mcf5208_defconfig,
qemu_riscv64_nommu_virt_defconfig, and
qemu_xtensa_lx60_nommu_defconfig builds properly.
riscv64 and m68k boots to login prompt.
xtensa crashes when loading init, the same behavior as when
reverting the bad upstream elf2flt commit completely.
The patch modifies main(), but does not perform a similar change in
output_relocs(), which might cause sectionp in output_relocs() to be
initialized with an invalid address, causing random memory to be
overwritten.
This leads to a segfault when linking e.g. busybox for m68k.
We cannot perform a similar change in output_relocs(), since at this
point in time, data_len will always be non-zero.
Revert this patch completely, so that we can add a working patch.
Note that even with this patch reverted, elf2flt is still broken
on archs like m68k and xtensa, resulting in the fatal error:
ERROR: text=0x3bab8 overlaps data=0x33f60 ?
================================================================================
Redis 7.0.4 Released Monday Jul 18 12:00:00 IST 2022
================================================================================
Upgrade urgency: SECURITY, contains fixes to security issues.
Security Fixes:
* (CVE-2022-31144) A specially crafted XAUTOCLAIM command on a stream
key in a specific state may result with heap overflow, and potentially
remote code execution. The problem affects Redis versions 7.0.0 or newer.
projects / buildroot-mgba.git / log