As expected by Peter in [1], the hardcoded 3 seconds for waiting the
RAID array to rebuild are not enough on slow test host runners. This
test already failed at least once for that reason, in [2].
In order to fix those failures, this commit adds extra logic to allow
several attempts, before failing. The timeout is currently set at 10
attempts, waiting 3 seconds between each attempts. To help even more,
those 3 seconds are also scaled with the timeout_multiplier.
Fixes: [2]
[1] https://lists.buildroot.org/pipermail/buildroot/2024-February/685034.html
[2] https://gitlab.com/buildroot.org/buildroot/-/jobs/6137469690
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
utmpx is not available since bump to version 4.14.3 in commit
8a01774d98 and
3be7b9d75a:
configure: WARNING: unrecognized options: --disable-gtk-doc, --disable-gtk-doc-html, --disable-doc, --disable-docs, --disable-documentation, --with-xmlto, --with-fop, --enable-ipv6, --enable-utmpx
Fixes: 8a01774d98
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
As suggested by Thomas Petazzoni in [1], add a comment on
BR2_TOOLCHAIN_HAS_UCONTEXT to specify that this boolean will be set to
true only when a toolchain provides a full featured ucontext
implementation with ucontext_t and {get,make,set}context. As a result,
drop its selection from BR2_TOOLCHAIN_USES_MUSL to fix the following
musl build failure on php:
/home/autobuild/autobuild/instance-8/output-1/host/lib/gcc/m68k-buildroot-linux-musl/12.3.0/../../../../m68k-buildroot-linux-musl/bin/ld: Zend/zend_fibers.o: in function `zend_fiber_init_context':
zend_fibers.c:(.text+0x946): undefined reference to `getcontext'
[1]: https://patchwork.ozlabs.org/project/buildroot/patch/20230516193307.1543455-1-bernd.kuhls@t-online.de/
Fixes:
- http://autobuild.buildroot.org/results/271f9fb8bfa5ba2f74feef81e6b375b54e21cece
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
GNU Octave changed its detection of readline library in [1]. This
commit was first included in version 8.1.0.
GNU Octave was updated to 8.1.0 in Buildroot in commit b36e4b10f3
"package/octave: bump to version 8.1.0".
Since this commit, Octave can fail to find readline automatically in
some specific situations. For example, when host system is Fedora 39
and the host "readline-devel" package is installed (see detailed
explanation below).
Octave is now using a m4 macro from gnulib to detect readline.
See [2].
This macro is calling AC_LIB_LINKFLAGS_BODY([readline]). Note that
this macro will look into $libdir and $includedir by default. See [3].
Buildroot is calling target autotools configure command with
--prefix=/usr and --exec-prefix=/usr arguments. See [4].
Autotools derives libdir='${exec_prefix}/lib' and
includedir='${prefix}/include'.
Finally, gnulib will also search automatically into alternate library
directories (i.e. lib32, lib64). See [5].
All of this will make the configure script searching the readline
library by default (i.e. if the library prefix is not provided) into
the host "/usr/lib", "/usr/lib32" and "/usr/lib64", when configuring
for target.
This issue is not happening on the Buildroot docker reference image,
because the package "libreadline-dev" is not present in this image.
Even if the package "libreadline-dev" is installed on a Debian based
host systems, the issue is still not happening because libraries are
installed in the path "/usr/lib/x86_64-linux-gnu", which is not
searched by gnulib macros.
On host systems which installs libraries into one of the
"/usr/lib{,32,64}" directories, the Octave configuration script will
fail, because it will detect the host library and try to link against
it with target architecture and compilation flags and will fail. Since
the --enable-readline configure option is present, the configuration
script will fail because it cannot find a working readline library.
This can be seen in the octave configuration log, in file:
output/build/octave-8.4.0/config.log
configure:73671: checking for readline
configure:73705: /buildroot/output/host/bin/aarch64-none-linux-gnu-gcc -o conftest -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -g0 -D_FORTIFY_SOURCE=1 -pthread -fopenmp -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 conftest.c -lpthread -lm /usr/lib64/libreadline.so >&5
/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/aarch64-none-linux-gnu/13.2.1/../../../../aarch64-none-linux-gnu/bin/ld: /usr/lib64/libreadline.so: error adding symbols: file in wrong format
collect2: error: ld returned 1 exit status
This situation can be reproduced on a Fedora 39 x86_64 host system,
with the "readline-devel" package installed. Note: uninstalling the
"readline-devel" will work around the issue.
The issue can be reproduced with a Buildroot configuration such as:
cat > .config <<EOF
BR2_aarch64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_PACKAGE_OCTAVE=y
BR2_PACKAGE_READLINE=y
EOF
make olddefconfig
make
In order to avoid those host/target readline detection mix-ups, the
readline search prefix need to be explicitly passed during octave
configuration. This commit adds this search prefix to fix this build
issue.
Fixes:
checking for readline... (cached) no
checking for readline/readline.h... (cached) yes
checking for readline/history.h... (cached) yes
configure: WARNING: I need GNU Readline 4.2 or later
configure: error: this is fatal unless you specify --disable-readline
[1] 3645c78658
[2] https://git.savannah.gnu.org/cgit/gnulib.git/tree/m4/readline.m4?id=2cdc1bafb20b187ad067056e090fcb4396ed9099
[3] https://git.savannah.gnu.org/cgit/gnulib.git/tree/m4/lib-link.m4?id=2cdc1bafb20b187ad067056e090fcb4396ed9099#n190
[4] https://gitlab.com/buildroot.org/buildroot/-/blob/2023.11/package/pkg-autotools.mk#L175
[5] https://git.savannah.gnu.org/cgit/gnulib.git/tree/m4/lib-prefix.m4?id=2cdc1bafb20b187ad067056e090fcb4396ed9099#n276
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Since the ARC-special GCC version was bumped from gcc 10.x to gcc 13.x
in commit 045ab73702 ("toolchain: bump
ARC toolchain components to arc-2023.09-release"), the
BR2_GCC_VERSION_ARC option definition is not entirely correct: it
selects BR2_TOOLCHAIN_GCC_AT_LEAST_10, while it should select
BR2_TOOLCHAIN_GCC_AT_LEAST_13. This commit fixes this.
Cc: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Fix the following build failure with gcc 4.8 raised since the addition
of the package in commit 06f50ff1bf:
src/conmon.c:5:2: error: #error conmon.c requires C99 or later
#error conmon.c requires C99 or later
^
Fixes: 06f50ff1bf
- http://autobuild.buildroot.org/results/b573aceefde04435ea13dfd2a48f9c2372bde4d7
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit 7ea38660e0 confused bigint [1] with
Math::BigInt [2]:
Can't locate bigint.pm in @INC (you may need to install the bigint module) (@INC contains: /home/buildroot/autobuild/instance-1/output-1/build/libopenssl-3.2.1/crypto/chacha/asm/../.. /home/buildroot/autobuild/instance-1/output-1/host/lib/perl /usr/local/lib64/perl5/5.36 /usr/local/share/perl5/5.36 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5) at /home/buildroot/autobuild/instance-1/output-1/build/libopenssl-3.2.1/crypto/chacha/asm/../../perlasm/s390x.pm line 16.
BEGIN failed--compilation aborted at /home/buildroot/autobuild/instance-1/output-1/build/libopenssl-3.2.1/crypto/chacha/asm/../../perlasm/s390x.pm line 16.
[1] https://perldoc.perl.org/bigint
[2] https://perldoc.perl.org/Math::BigInt
Fixes: 7ea38660e0
- http://autobuild.buildroot.org/results/777d86a1e53dc3d6a16c829348673f1c33245a6c
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Support has been dropped since the major release 2.24.0:
7d7ec9c951
Signed-off-by: Thomas Devoogdt <thomas@devoogdt.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
strace needs headers >= 5.0 and
9966a05c7b
to avoid the following build failure on musl and aarch64 due to headers
conflict raised at least since bump to version 6.0 in commit
544806bfd8:
In file included from /home/autobuild/autobuild/instance-7/output-1/host/aarch64_be-buildroot-linux-musl/sysroot/usr/include/signal.h:48,
from strace.c:17:
/home/autobuild/autobuild/instance-7/output-1/host/aarch64_be-buildroot-linux-musl/sysroot/usr/include/bits/signal.h:18:16: error: redefinition of 'struct sigcontext'
18 | typedef struct sigcontext {
| ^~~~~~~~~~
In file included from /home/autobuild/autobuild/instance-7/output-1/host/aarch64_be-buildroot-linux-musl/sysroot/usr/include/asm/ptrace.h:26,
from /home/autobuild/autobuild/instance-7/output-1/host/aarch64_be-buildroot-linux-musl/sysroot/usr/include/linux/ptrace.h:107,
from ptrace.h:33,
from strace.c:16:
/home/autobuild/autobuild/instance-7/output-1/host/aarch64_be-buildroot-linux-musl/sysroot/usr/include/asm/sigcontext.h:28:8: note: originally defined here
28 | struct sigcontext {
| ^~~~~~~~~~
Fixes:
- http://autobuild.buildroot.org/results/74a480aa76970b36dcd890d9bd7a9df1d49e8e16
- http://autobuild.buildroot.org/results/79ee8ae5fb9712fd874b56e836eca1b997c50cd9
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[Peter: fix architecture conditional]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
python-setuptools-scm-git-archive is obsolete as
python-setuptools-scm >= 7.0.0 supports Git archives by itself.
Moreover, it raises the following build failure without pip since its
addition in commit 9359325c60:
/nvmedata/autobuild/instance-3/output-1/per-package/host-python-setuptools-scm-git-archive/host/bin/python: No module named pip
Traceback (most recent call last):
File "/nvmedata/autobuild/instance-3/output-1/per-package/host-python-setuptools-scm-git-archive/host/lib/python3.10/site-packages/setuptools/installer.py", line 82, in fetch_build_egg
subprocess.check_call(cmd)
File "/nvmedata/autobuild/instance-3/output-1/per-package/host-python-setuptools-scm-git-archive/host/lib/python3.10/subprocess.py", line 369, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['/nvmedata/autobuild/instance-3/output-1/per-package/host-python-setuptools-scm-git-archive/host/bin/python', '-m', 'pip', '--disable-pip-version-check', 'wheel', '--no-deps', '-w', '/tmp/tmpaxobatcs', '--quiet', 'typing-extensions']' returned non-zero exit status 1.
Fixes:
- http://autobuild.buildroot.org/results/d05e412170c427e4f210da164c783b3527f15892
- http://autobuild.buildroot.org/results/50f80cfabccbe5c75cd889ce6af2b418e376d4e5
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Group _CONF_{ENV,OPTS} together after the autreconf ones.
Keep AUTORECONF=YES close to AUTORECONF_OPTS
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Fix gettext build raised since bump to version 2.15 in commit
d65b960859:
*** error: gettext infrastructure mismatch: using a Makefile.in.in from gettext version 0.18 but the autoconf macros are from gettext version 0.20
Fixes: d65b960859
- http://autobuild.buildroot.org/results/bb80a7842d18651e5069f3a91f06a9c23218d260
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
host-rust package depends on several host packages to provide tools and
libraries but it doesn't take into account out host libraries in
HOST_DIR while building rustc compiler. Indeed, rustc needs zlib and
fails to link if zlib is not installed on the host.
error: could not compile `rustc_driver` (lib) due to previous error
If zlib is installed on the host, we can notice it with ldd tool (while
it should be linked with the one provided by Buildroot host-zlib):
ldd [...]TestRust/host/bin/rustc
libz.so.1 => /lib64/libz.so.1
Provide HOST_LDFLAGS using llvm.ldflags in config.toml.
(HOST_LDFLAGS provides -L$(HOST_DIR)/lib -Wl,-rpath,$(HOST_DIR)/lib)
With that fixed, rustc_driver link with libz from HOST_DIR but the
host-rust build still fail later due to another issue.
error: could not compile `rustdoc-tool` (bin "rustdoc_tool_binary") due to previous error
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/6256881545http://autobuild.buildroot.org/results/a6b/a6b28783f29e6b729824bf42679a62f72ad5bee0
Signed-off-by: Romain Naour <romain.naour@smile.fr>
[yann.morin.1998@free.fr: slight rewording in commit log]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Several rust tools are linking against zlib, so add the depedency
explicitly in HOST_RUST_DEPENDENCIES.
For now, host-rust build system is not able to find zlib provided
by Buildroot in HOST_DIR due to at least two issues that will be
fixed in followup commits.
Note that host-zlib is already in the dependency chain, by way of
host-openssl, but since rust needs for itself, we need to add it
as an explicit dependency.
Signed-off-by: Romain Naour <romain.naour@smile.fr>
[yann.morin.1998@free.fr: add not about transitive dependency]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
spirv-tools unconditionally includes filesystem since its addition in
commit 0a01085abe resulting in the
following build failure:
/home/buildroot/autobuild/run/instance-1/output-1/build/spirv-tools-1.3.261.1/tools/objdump/objdump.cpp:15:10: fatal error: filesystem: No such file or directory
#include <filesystem>
^~~~~~~~~~~~
Fixes: 0a01085abe
- http://autobuild.buildroot.org/results/aaeb0ca8773842768f9311fc804bb7529d9e3bfa
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit 722b84eafa forgot to update
nginx-naxsi resulting in the following build failure:
In file included from ../nginx-naxsi-d714f1636ea49a9a9f4f06dba14aee003e970834/naxsi_src/naxsi_runtime.c:7:
../nginx-naxsi-d714f1636ea49a9a9f4f06dba14aee003e970834/naxsi_src/naxsi.h:147:3: error: unknown type name 'ngx_regex_compile_t'
147 | ngx_regex_compile_t* target_rx;
| ^~~~~~~~~~~~~~~~~~~
Fixes: 722b84eafa
- http://autobuild.buildroot.org/results/87bbcf946ccbd8e3bf1ca9f39464f4bb198c8d42
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This fixes an incompatibility with openssl 3.2 when using codesign
certificate purpose [1].
[1] https://github.com/rauc/rauc/releases/tag/v1.11.1
Signed-off-by: Marcus Hoffmann <buildroot@bubu1.eu>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Fix the following build failure raised since the addition of the package
in commit ea45b95c0e:
In file included from third_party/boringssl-with-bazel/src/include/openssl/base.h:78,
from third_party/boringssl-with-bazel/src/include/openssl/ssl.h:145,
from ./src/core/tsi/ssl/key_logging/ssl_key_logging.h:23,
from ./src/core/lib/security/security_connector/ssl_utils.h:42,
from ./src/core/lib/security/credentials/tls/grpc_tls_certificate_distributor.h:36,
from ./src/core/ext/xds/certificate_provider_store.h:44,
from src/core/ext/xds/certificate_provider_store.cc:21:
third_party/boringssl-with-bazel/src/include/openssl/target.h:62:2: error: #error "Unknown target CPU"
62 | #error "Unknown target CPU"
| ^~~~~
Fixes: ea45b95c0e
- http://autobuild.buildroot.org/results/36686aca1b45f0bf692a60e67a48424b561930a3
- http://autobuild.buildroot.org/results/4f79c7b1b2fc3306f300ae3ec0aa4439725814c1
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
A vulnerability was found in obgm libcoap 4.3.4. It has been rated as
critical. Affected by this issue is the function get_split_entry of the
file src/coap_oscore.c of the component Configuration File Handler. The
manipulation leads to stack-based buffer overflow. The attack may be
launched remotely. The exploit has been disclosed to the public and may
be used. It is recommended to apply a patch to fix this issue.
VDB-252206 is the identifier assigned to this vulnerability.
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix CVE-2024-22667: Vim before 9.0.2142 has a stack-based buffer
overflow because did_set_langmap in map.c calls sprintf to write to the
error buffer that is passed down to the option callback functions.
Update hash of README.txt (version number updated with
b4ddc6c11e)
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix CVE-2024-25062: An issue was discovered in libxml2 before 2.11.7 and
2.12.x before 2.12.5. When using the XML Reader interface with DTD
validation and XInclude expansion enabled, processing crafted XML
documents can lead to an xmlValidatePopElement use-after-free.
https://gitlab.gnome.org/GNOME/libxml2/-/blob/v2.12.5/NEWS
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Update NEWLIB_BARE_METAL_VERSION to match version retrieved on
https://release-monitoring.org/project/13816
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Hash of COPYING.NEWLIB is wrong since the addition of the package in
commit 3b95ff658b:
ERROR: COPYING.NEWLIB has wrong sha256 hash:
ERROR: expected: 422aa40293093fb54fc66e692a0d68fd0b24ed5602e5d1d33ad05ba3909057e9
ERROR: got : 9a59b4ee3af067045fe0ea78786201c42d54756fe48cbccf44f3dfc398474717
Fixes: 3b95ff658b
- No autobuilder failures (yet)
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
We carried a patch for xilinx xemaclite that was made initially for
qemu < 2.2.0 [1].
Indeed, between Qemu 0.11.0 and 2.2.0 the devicetree binary blob
petalogix-s3adsp1800.dtb (bundled in Qemu sources) used a
compatible string 'xlnx,xps-ethernetlite-2.00.b' that was not
supported by the Linux kernel [2].
These patches could have been removed since Buildroot 2015.02
when this defconfig was tested with Qemu 2.2.0 [3].
[1] https://git.buildroot.net/buildroot/commit/board/qemu/microblazebe-mmu/xilinx-xemaclite.patch?id=fa2798548368d51998fad18d7f6d1ae0ed065b33
[2] c21fd2c79e
[3] 312990555c
Cc: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
[Peter: drop drom .checkpackageignore]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix the following build failure without makeinfo raised since the
addition of the package in commit
3b95ff658b:
make[5]: Entering directory '/home/buildroot/autobuild/instance-2/output-1/build/newlib-bare-metal-4.4.0/microblazeel-xilinx-elf/libgloss'
MAKEINFO ../.././libgloss/doc/porting.info
/home/buildroot/autobuild/instance-2/output-1/build/newlib-bare-metal-4.4.0/missing: line 81: makeinfo: command not found
Fixes: 3b95ff658b
- http://autobuild.buildroot.org/results/23e6641cbce62258310c300f8aed5d6a76973d72
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Use OPTIMIZATIONS parameter to pass -marm to fix the following build
failure in Thumb mode:
/tmp/ccEjPM4h.s:941: Error: selected processor does not support `mrc p15,0,r2,c9,c13,0' in Thumb mode
CFLAGS can't be overridden as it is defined as:
CFLAGS = $(FEATUREFLAGS) \
$(OPTIMIZATIONS) \
$(WARNFLAGS) \
$(if $(findstring clang,$(CC)),$(CLANG_WARNINGS)) \
$(ARCH_CFLAGS) \
$(WERRFLAGS) \
$(INCLUDES) \
$(DEFINES)
Fixes:
- http://autobuild.buildroot.org/results/580156f89cfd72122fef07aa2fe37b4fdd4c316b
- http://autobuild.buildroot.org/results/8980c0f422516c7263d8d0c9cc6123f30c4b7ee4
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 10d272ec99)
[Peter: drop Makefile/Vagrantfile changes]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit f05246df4f)
[Peter: drop Makefile change]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Move fi statement where it belongs to fix the following build failure
raised since bump of autoconf to version 2.72 in commit
524f353602:
checking for stack setup via makecontext... ./configure: line 15863: syntax error near unexpected token `;;'
Fixes: 524f353602
- http://autobuild.buildroot.org/results/013e0d3f72582ce3675f65786c014518682d703b
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit b7232c51dd added default setting
for bare-metal toolchain arch but unfortunately it used configlines.add
instead of configlines.append resulting in the following build failure:
/bin/sh: line 8: /home/autobuild/autobuild/instance-1/output-1/per-package/host-gcc-bare-metal/host/bin/-ar: No such file or directory
While at it, also append /n for consistency
Fixes: b7232c51dd
- http://autobuild.buildroot.org/results/95ac565653ddb5c14ec71470c32a34ad10b048cb
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit 22b6945552 (support/scripts/cve.py: switch from NVD to FKIE for
the JSON files) had to change the decompressor from gz to xz, as the new
location is using xz compression.
That commit mentioned that it was spawning an external xz process to do
the decompression, on the pretence that "there is no xz decompressor in
Python stdlib."
Before version 3.1, ijson.items() only accepted a file-like object as
input (that file-like object could yield bytes() or str(), both were
supported). Starting with version 3.1, ijson.items() also accepts that
it be directly passed bytes() or str() directly. subprocess.check_output()
means we are now passing bytes() to ijson.items(), so it fails on ijson
versions before 3.1, with failures such as:
[...]
File "/usr/lib/python3/dist-packages/ijson/backends/python.py", line 25, in Lexer
if type(f.read(0)) == bytetype:
AttributeError: 'bytes' object has no attribute 'read'
Ubuntu 20.04, on which the pkg-stats run to generate the daily report,
only has ijson 2.3. More recent distros have more recent versions of
ijson, like Fedora 39 that has 3.2.3, recent enough to support being fed
bytes(). Commit 22b6945552 was tested on Fedora 39, so did not catch
the issue.
However, the reasoning in 22b6945552 is wrong: there *is* the lzma
module, at least since python 3.3 (that is, aeons ago), which is able to
read xz-compressed files; it also has an API similar to the gzip module,
and can provide a file-like object that exposes the decompressed data.
So, do just that: provide an lzma-wrapped file-like object to ijson, so
that we can eventually recover our daily reports that everything is
broken! :-]
Note that this construct still works on recent versions!
Reported-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
libheif raises the following build failure with libjpeg since bump to
version 1.17.5 in commit 5714126eda and
ebd13a20b8
/home/buildroot/autobuild/instance-3/output-1/build/libheif-1.17.5/libheif/plugins/encoder_jpeg.cc: In function 'heif_error jpeg_encode_image(void*, const heif_image*, heif_image_input_class)':
/home/buildroot/autobuild/instance-3/output-1/build/libheif-1.17.5/libheif/plugins/encoder_jpeg.cc:366:37: error: invalid conversion from 'long unsigned int*' to 'size_t*' {aka 'unsigned int*'} [-fpermissive]
366 | jpeg_mem_dest(&cinfo, &outbuffer, &outlength);
| ^~~~~~~~~~
| |
| long unsigned int*
Fixes:
- http://autobuild.buildroot.org/results/8ca909564c8dabe28ad08c96ebbc04b25592e727
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
