As found out by Yann E. Morin in [1], apcupsd configure script is ugly,
and uses gcc to do the link line-wrapping which will raise the following
build failure with gcc 13:
/home/buildroot/autobuild/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/powerpc64le-buildroot-linux-gnu/13.2.0/../../../../powerpc64le-buildroot-linux-gnu/bin/ld: /home/buildroot/autobuild/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/powerpc64le-buildroot-linux-gnu/13.2.0/../../../../powerpc64le-buildroot-linux-gnu/lib/../lib64/libsupc++.a(eh_alloc.o): in function `std::basic_string_view<char, std::char_traits<char> >::compare(unsigned long, unsigned long, char const*, unsigned long) const':
eh_alloc.cc:(.text._ZNKSt17basic_string_viewIcSt11char_traitsIcEE7compareEmmPKcm[_ZNKSt17basic_string_viewIcSt11char_traitsIcEE7compareEmmPKcm]+0x44): undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)'
It will also raise the following build failure on sparc/arc:
/home/autobuild/autobuild/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arceb-snps-linux-uclibc/9.2.1/../../../../arceb-snps-linux-uclibc/bin/ld: /home/autobuild/autobuild/instance-3/output-1/host/arceb-buildroot-linux-uclibc/sysroot/lib/libsupc++.a(eh_throw.o): in function `__exchange_and_add_dispatch':
/SCRATCH/arcjenkins2/slaves/ru20-custom-arcgnu2/workspace/arcoss_verification/arc_gnu_toolchain_release/arc_gnu_toolchain_release/bd-uclibceb/gcc-stage2/arceb-snps-linux-uclibc/libstdc++-v3/include/ext/atomicity.h:82: undefined reference to `__gnu_cxx::__exchange_and_add(int volatile*, int)'
/home/autobuild/autobuild/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arceb-snps-linux-uclibc/9.2.1/../../../../arceb-snps-linux-uclibc/bin/ld: /SCRATCH/arcjenkins2/slaves/ru20-custom-arcgnu2/workspace/arcoss_verification/arc_gnu_toolchain_release/arc_gnu_toolchain_release/bd-uclibceb/gcc-stage2/arceb-snps-linux-uclibc/libstdc++-v3/include/ext/atomicity.h:82: undefined reference to `__gnu_cxx::__exchange_and_add(int volatile*, int)'
Instead of trying to patch the configure script as advocated by
Yann E. Morin, set LD to TARGET_CXX as:
- this solution is quicker
- usptream is dead (last release in 2016)
- this solution has already been used in other packages (nodejs, zmqpp)
[1]: https://patchwork.ozlabs.org/project/buildroot/patch/20200812171821.2517-1-Evgeniy.Didin@synopsys.com/
Fixes:
- http://autobuild.buildroot.org/results/6096c3ddc5edf3204635c2c90246c2e8c8e074e7
- http://autobuild.buildroot.org/results/d8a/d8a3ab31c5b86871c7e1117f4ffa7b6cedfcb7e0/build-end.log
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit cd2dcaa6c6)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The condition checking whether the webrtc-audio-processing package is
enabled, added in commit
3ccd3b4c38 ("package/pipewire: bump to
version 0.3.32") is obviously incorrect, and can never be true.
Fix the condition to use the correct variable instead.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 52f8db409f)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
A number of packages try to detect if they are running in a git repo and run
git describe at build time instead of using the hard coded version number if
it succeed, leading to odd version numbers as they end up picking up the
Buildroot git version if building inside a Buildroot git checkout, E.G.:
rauc --version
rauc 2023.11-562-g9c954953b4+
This is because rauc builds with meson and uses vcs_tag:
https://github.com/rauc/rauc/blob/v1.11/meson.build#L168-L171https://mesonbuild.com/Reference-manual_functions.html#vcs_tag
Another example is micropython, where we already work around it by passing
GIT_DIR=.
In the context of Buildroot the packages are never built in their own git
checkout, so pass GIT_DIR=. to ensure git doesn't walk back up the
directory tree and finds the Buildroot git repo, which fixes the rauc (and
similar) issues.
>>> rauc 1.11 Building
..
ninja: Entering directory `/home/peko/source/buildroot/output-rauc/build/rauc-1.11//build'
[1/29] Generating version.h with a custom command
fatal: not a git repository: '.'
cat output-rauc/build/rauc-1.11/build/version.h
#define PACKAGE_STRING "rauc 1.11"
#define PACKAGE_VERSION "1.11"
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit c07aafa087)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Building for i386 raises the following build failure since the additon
of the package in commit 3e4b479f39:
Makefile:23: *** "The architecture i386 isn't supported". Stop.
Setting ARCH=x86 won't work either as it results in the following build
failure:
compel/arch/x86/plugins/std/memcpy.S: Assembler messages:
compel/arch/x86/plugins/std/memcpy.S:20: Error: bad register name `%rdi'
compel/arch/x86/plugins/std/memcpy.S:21: Error: bad register name `%rdx'
compel/arch/x86/plugins/std/memcpy.S:22: Error: `shrq' is only supported in 64-bit mode
compel/arch/x86/plugins/std/memcpy.S:24: Error: `movsq' is only supported in 64-bit mode
compel/arch/x86/plugins/std/syscalls/syscall-common-x86-64.S: Assembler messages:
compel/arch/x86/plugins/std/syscalls/syscall-common-x86-64.S:13: Error: bad register name `%rcx'
compel/arch/x86/plugins/std/syscalls/syscall-common-x86-64.S:19: Error: bad register name `%rax'
Fixes:
- http://autobuild.buildroot.org/results/94cc463762b57efacf743d107a8dda7660a995a3
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit bb3ede3b36)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit 768f9f80f6 (support/download: generate even more reproducible
tarballs) causes non-reproducibility in tarballs we previousy
generated, especially the archives for two cargo-vendored packages,
ripgrep and sentry-cli.
The cause is that those two pakcages eventually vendor a file that has
the u+x bit set, but is otehrwise go-x. With 768f9f80f6, the files are
now go+x, so the hash for those generated archives has changed.
Besides, that commit was wrong: it did not account for the 'r' bit for
go part, leaving some non-reproducibility still unaccounted for.
So, to generate really reproducible archives, we would need to fix that
read bit as well, and that has the potential to affect all the archives
we generated so far. If we wanted to do so, we'd need a way to version
all generated archives, like we do for git and svn, but now for all the
different CVSes, as well as for all the vendoring post-processes.
For 768f9f80f6, all that was of conern was the working copies of CVSes
(i.e. git, svn, cvs...) that we cache in the Buildroot download dir, not
the temporary files during post-processing. Indeed, in that latter case,
the user has virtually no way to mangle with the mode of the
intermediate extract before repack.
And we do have a big fat warning that users should not attempt to meddle
with the git tree that Buildroot caches.
As 768f9f80f6 however demonstrates, is that it took quite a long time
between the introduction of the git caching, and the time someone
eventually discovered they could meddle in there. This shows that the
issue it not actually critical in most setups.
Also, the tar manual [0] hints at a better solution to handle
reproducibility, which even avoids touching the files on disk which is
even nicer:
‘--mode='go+u,go-w'’
Omit irrelevant information about file permissions.
If we were to actually handle the mode bit for reproducibility, we'd
need to:
- introduce archive versioning for all download backends and
prost-processing
- use the tar officially suggested method
So, revert that change, as it was incomplete, was not really fixing much
issues, and causes actual issues.
This reverts commit 768f9f80f6.
[0] https://www.gnu.org/software/tar/manual/tar.html#Reproducibility
Thanks to Vincent and Arnout for pointing at the tar manual.
Reported-by: Antoine Coutant <antoine.coutant@smile.fr>
Reported-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Vincent Fazio <vfazio@xes-inc.com>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Tested-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Antoine Coutant <antoine.coutant@smile.fr>
(cherry picked from commit 9fbd3d8574)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit 6d163e12a4 (package/udev: move render and sgx to
package/systemd) moved the sgx group creation to the systemd package because
eudev at that time did not reference it. This changed in eudev 3.1.12 with
commit a8ffcd1b985fb4 (rules/50-udev-default.rules: fix issue 160) so move
it back to get rid of a warning from udevd:
udevd[303]: specified group 'sgx' unknown
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit edfa9ea45c)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
flutter-gallery was erroneously placed under the "Graphic libraries"
section of the menu "Graphic libraries and applications (graphic/text)"
menu. However, as flutter-gallery is a flutter-based graphical user
interface (GUI) application, it is better suited to be placed under the
"Graphic applications" section.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 75d78e4225)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
flutter-pi was erroneously placed under the "Graphic libraries" section
of the menu "Graphic libraries and applications (graphic/text)" menu.
However, as flutter-pi is an application that runs graphic applicaitons
it is better suited to be placed under the "Graphic applications"
section.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 1a2ae469d0)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix the following build failure on sparc64 raised since bump to version
0.85 in commit 470f0fb1ec:
error[E0308]: mismatched types
--> /home/autobuild/autobuild/instance-7/output-1/build/nushell-0.85.0/VENDOR/uucore/src/lib/features/fs.rs:121:16
|
111 | pub fn number_of_links(&self) -> u64 {
| --- expected `u64` because of return type
...
121 | return self.0.st_nlink;
| ^^^^^^^^^^^^^^^ expected `u64`, found `u32`
|
help: you can convert a `u32` to a `u64`
|
121 | return self.0.st_nlink.into();
| +++++++
For more information about this error, try `rustc --explain E0308`.
error: could not compile `uucore` (lib) due to previous error
Fixes:
- http://autobuild.buildroot.org/results/f9f0287a8e39c65895014ca513ed25071f020add
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit b7c163f190)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
C++ is no longer required for python-brotli as of version 1.1.0:
c8df4b3049
Drop python-brotli C++ depends comment from python-weasyprint
reverse dependency.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit a51c664ef5)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
- Use official tarball
- Update hash of license file (some packages have been added or removed
but the list of licenses is the same)
- Fix CVE-2023-7158: A vulnerability was found in MicroPython up to
1.21.0. It has been classified as critical. Affected is the function
slice_indices of the file objslice.c. The manipulation leads to
heap-based buffer overflow. It is possible to launch the attack
remotely. The exploit has been disclosed to the public and may be
used. Upgrading to version 1.22.0 is able to address this issue. It is
recommended to upgrade the affected component. The identifier of this
vulnerability is VDB-249180.
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 1e12b7dd49)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Update site to avoid redirections (HSTS, etc.)
Version 5.0.3 - 12/17/2023
A memory leak fix in the prior version wasn't applied correctly, resulting
in an invalid memory access causing a crash. Bug fixed.
Version 5.0.2 - 11/8/2023
Fixed bug that caused crash when a CLIENT_KEY arrived out of order
Fixed option handling on Windows when an argument is missing
https://sourceforge.net/projects/uftp-multicast/files/Changes.txt/download
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit bfe2fe2269)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
HAVE_{MMX,SSE2,...} are not defined if ax_cv_have_{i}_cpu_ext is not set
resulting in the following build failure raised since bump to version
1.5.0 in commit c2aaa0fbe2 and
02c4e8b99b:
src/dotprod/src/dotprod_cccf.sse.c: In function 'dotprod_cccf_execute_sse':
src/dotprod/src/dotprod_cccf.sse.c:258:5: error: unknown type name '__m128'; did you mean '__int128'?
258 | __m128 v; // input vector
| ^~~~~~
| __int128
or
src/dotprod/src/dotprod_cccf.mmx.c: In function 'dotprod_cccf_execute_mmx':
src/dotprod/src/dotprod_cccf.mmx.c:262:5: error: unknown type name '__m128'; did you mean '__int128'?
262 | __m128 v; // input vector
| ^~~~~~
| __int128
While at it, add AVX2 support
Fixes:
- http://autobuild.buildroot.org/results/738ce9d3dc74ec165391f21256c955e5524f1632
- http://autobuild.buildroot.org/results/a2d150c724ab6787aeabaf31f65116f802e8584e
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 620bd7220a)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This usage of <PKG>_NAME was introduced in commit f9e9c6349a
("package/rng-tools: bump to 6.7"). No other package uses <PKG>_NAME
this way.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit a2b8596873)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix the following build failure without neon raised since bump to
version 1.4.0 in commit 2f7f8f3813 and
c821187dd9:
/home/peko/autobuild/instance-0/output-1/host/bin/arm-none-linux-gnueabi-gcc -std=gnu11 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g0 -D_FORTIFY_SOURCE=2 -ffast-math -mcpu=cortex-a7 -mfloat-abi=hard -mfpu=neon-vfpv4 -Wall -fPIC -Wno-deprecated -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -I. -Iinclude -c -o src/audio/src/cvsd.o src/audio/src/cvsd.c
In file included from /home/peko/autobuild/instance-0/output-1/host/arm-buildroot-linux-gnueabi/sysroot/usr/include/features.h:388:0,
from /home/peko/autobuild/instance-0/output-1/host/arm-buildroot-linux-gnueabi/sysroot/usr/include/stdlib.h:24,
from src/libliquid.c:25:
/home/peko/autobuild/instance-0/output-1/host/arm-buildroot-linux-gnueabi/sysroot/usr/include/gnu/stubs.h:10:29: fatal error: gnu/stubs-hard.h: No such file or directory
# include <gnu/stubs-hard.h>
^
Indeed, upstream considers that NEON is available on all ARM platforms,
and their configure.ac contains that code snippet:
239 arm|armv7*|armv8*)
240 # assume neon instructions are available
241 # TODO: check for Neon availability
242
243 # ARM architecture : use neon extensions
Fixes:
- http://autobuild.buildroot.org/results/36b3c2220c462e7a20262fd1b9064d9aeb6c9ec4
- http://autobuild.buildroot.org/results/881826b4b6c141e59a0da2d7d1ad55d3709fdb95
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[yann.morin.1998@free.fr:
- refactor with LIQUID_DSP_SIMDOVERRIDE
- add comment about --disable-simdoverride
- extend commit log with upstream code snippet
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 9501bc80f5)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
libaio is only needed for standard install
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[yann.morin.1998@free.fr: fix check-package]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit ee9c92e4a4)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix the following build failure with kernel < 4.16 raised since bump to
version 4.0.0 in commit 8a8fa20068 and
3ac968ee7c:
/home/buildroot/autobuild/instance-3/output-1/build/optee-client-4.0.0/tee-supplicant/src/tee_supplicant.c: In function 'register_local_shm':
/home/buildroot/autobuild/instance-3/output-1/build/optee-client-4.0.0/tee-supplicant/src/tee_supplicant.c:356:44: error: storage size of 'data' isn't known
356 | struct tee_ioctl_shm_register_data data;
| ^~~~
Fixes:
- http://autobuild.buildroot.org/results/d63eb7c8574366377760f5ab2eaec02f46173975
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit d1c067e01b)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
--{dis,en}able-avahi is unrecognized since bump to version 2.3.3op2 in
commit 8cf034ab0f (which switched upstream
location from apple to openprinting):
configure: WARNING: unrecognized options: --disable-gtk-doc, --disable-gtk-doc-html, --disable-doc, --disable-docs, --disable-documentation, --with-xmlto, --with-fop, --disable-dependency-tracking, --enable-ipv6, --disable-nls, --disable-systemd, --disable-avahi
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 36743d6175)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
With [1], [2] & [3] we made sure Buildroot packages get built with
proper MMU page size assumed. This was done nicely through insertion of
required flags into the toolchain wrapper so that there's no need to
pass these flags to each and every package separately - toolchain
wrapper used for real building has all set internally and so proper
flags are implicitly used.
But there's yet another corner case which is not handled that way -
these are binaries or rather libraries which are being used as a part of
GCC compilation: libgcc_s.so.1 and libstdc++.so.
And so to make sure both the libraries get built properly we need to
set TARGET_CFLAGS (cures libgcc_s.so) & TARGET_LDFLAGS (cures
libstdc++.so).
In case of ARM by defaut 64 KiB page size seems to be used, as w/o
that patch we see the following for BR2_ARM64_PAGE_SIZE_4K=y:
--------------------------->8----------------------------
$ ./output/host/bin/aarch64-linux-readelf -l ./output/target/lib/libgcc_s.so.1
Elf file type is DYN (Shared object file)
Entry point 0x0
There are 6 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000013d1c 0x0000000000013d1c R E 0x10000
LOAD 0x000000000001fd98 0x000000000002fd98 0x000000000002fd98
0x0000000000000438 0x00000000000005c8 RW 0x10000
DYNAMIC 0x000000000001fdb8 0x000000000002fdb8 0x000000000002fdb8
0x0000000000000200 0x0000000000000200 RW 0x8
$ ./output/host/bin/aarch64-linux-readelf -l ./output/target/usr/lib/libstdc++.so.6.0.32
Elf file type is DYN (Shared object file)
Entry point 0x0
There are 7 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x00000000001d3462 0x00000000001d3462 R E 0x10000
LOAD 0x00000000001d5760 0x00000000001e5760 0x00000000001e5760
0x000000000000e528 0x0000000000012de8 RW 0x10000
DYNAMIC 0x00000000001deef0 0x00000000001eeef0 0x00000000001eeef0
0x0000000000000240 0x0000000000000240 RW 0x8
--------------------------->8----------------------------
Note alignment of 0x10000 in sections marked for loading.
And with the patch applied we get expected alignment of 0x1000 (4
KiB):
--------------------------->8----------------------------
$ ./output/host/bin/aarch64-linux-readelf -l ./output/target/lib/libgcc_s.so.1
Elf file type is DYN (Shared object file)
Entry point 0x0
There are 6 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000013d1c 0x0000000000013d1c R E 0x1000
LOAD 0x0000000000013d98 0x0000000000014d98 0x0000000000014d98
0x0000000000000438 0x00000000000005c8 RW 0x1000
DYNAMIC 0x0000000000013db8 0x0000000000014db8 0x0000000000014db8
0x0000000000000200 0x0000000000000200 RW 0x8
$ ./output/host/bin/aarch64-linux-readelf -l ./output/target/usr/lib/libstdc++.so.6.0.32
Elf file type is DYN (Shared object file)
Entry point 0x0
There are 7 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x00000000001d3462 0x00000000001d3462 R E 0x1000
LOAD 0x00000000001d3760 0x00000000001d4760 0x00000000001d4760
0x000000000000e528 0x0000000000012de8 RW 0x1000
DYNAMIC 0x00000000001dcef0 0x00000000001ddef0 0x00000000001ddef0
0x0000000000000240 0x0000000000000240 RW 0x8
--------------------------->8----------------------------
A nice side effect is that we can get rid of the special handling of
"-matomic" as it's already part of ARCH_TOOLCHAIN_WRAPPER_OPTS.
[1] https://git.buildroot.net/buildroot/commit/?id=3cc2c6d19ab2e1bb4634f26f9318da9b07df5fff
[2] https://git.buildroot.net/buildroot/commit/?id=dcb74db89e74e512e36b32cea6f574a1a1ca84c4
[3] https://git.buildroot.net/buildroot/commit/?id=5e52c28397b79f8c4c99552217cbe95202166626
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Vladimir Isaev <VVIsaev@gmail.com>
Signed-off-by: Pavel Kozlov <kozlov@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 747dff5a36)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
- Drop all patches except first one (already in version)
- This bump will fix the following build failure with kernel >= 6.6:
/home/autobuild/autobuild/instance-2/output-1/build/dahdi-linux-3.2.0/drivers/dahdi/wct4xxp/base.c: In function ‘free_wc’:
./include/linux/workqueue.h:639:9: error: call to ‘__warn_flushing_systemwide_wq’ declared with attribute warning: Please avoid flushing system-wide workqueues. [-Werror=attribute-warning]
639 | __warn_flushing_systemwide_wq(); \
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/autobuild/autobuild/instance-2/output-1/build/dahdi-linux-3.2.0/drivers/dahdi/wct4xxp/base.c:2025:9: note: in expansion of macro ‘flush_scheduled_work’
2025 | flush_scheduled_work();
| ^~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
https://github.com/asterisk/dahdi-linux/releases/tag/v3.3.0
Fixes:
- http://autobuild.buildroot.org/results/e9755e1f4814b6b0c151c590b5c34acfd89556ad
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit a608e519a0)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix the following musl build failure with powerpc raised since bump to
version 2.14 in commit c6addf4606:
In file included from fault.h:36,
from handler-unix.c:77,
from handler.c:19:
handler-unix.c: In function 'sigsegv_handler':
fault-linux-powerpc.h:35:73: error: 'mcontext_t' has no member named 'uc_regs'; did you mean 'gregs'?
35 | # define SIGSEGV_FAULT_STACKPOINTER ((ucontext_t *) ucp)->uc_mcontext.uc_regs->gregs[1]
| ^~~~~~~
handler-unix.c:157:43: note: in expansion of macro 'SIGSEGV_FAULT_STACKPOINTER'
157 | uintptr_t old_sp = (uintptr_t) (SIGSEGV_FAULT_STACKPOINTER);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
Fixes:
- http://autobuild.buildroot.org/results/77b600071f07605be3ec28e2da46d6938e240087
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 74f401025d)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
giflib and qhull are mandatory since the addition of the package in
commit 1e64fa2956 and
cb136fc051
Indeed, as explained in above commit, internal (bundled) libraries will
be used if GDAL_USE_GIF and GDAL_USE_QHULL are set to OFF
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 4c6ff16cf2)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This reverts commit 245b13a077 as docker
selinux module is for docker-engine, not for "a system tray dock for X"
Moreover, it raises the following build failure:
Compiling targeted policy.33
env LD_LIBRARY_PATH="/home/buildroot/autobuild/instance-0/output-1/per-package/refpolicy/host/lib:/home/buildroot/autobuild/instance-0/output-1/per-package/refpolicy/host/usr/lib" /home/buildroot/autobuild/instance-0/output-1/per-package/refpolicy/host/usr/bin/checkpolicy -c 33 -U deny -S -O -E policy.conf -o policy.33
policy.conf:1912:ERROR 'attribute container_engine_domain is not declared' at token ';' on line 1912:
type dockerd_t, container_engine_domain;
type dockerd_exec_t;
Fixes:
- http://autobuild.buildroot.org/results/87d78b6f15875f0fa3e6fc85e352db14ab0383bb
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 3e91de6428)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Yann reported in [1] that edk2 build could sometimes fail. The issue
can be reproduced when per-package directories is enabled, or also
when building on a system with GNU Make >= 4.4 using the
"--shuffle=reverse" option (such as Fedora 39). Those are pointing
toward a Makefile dependency issue.
The issue can be reproduced with commands:
cat > .config <<EOF
BR2_riscv=y
BR2_RISCV_64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TARGET_EDK2=y
EOF
make olddefconfig
Then, building either with:
make --shuffle=reverse
Or:
utils/config -e BR2_PER_PACKAGE_DIRECTORIES
make olddefconfig
make -j$(nproc)
It is interesting to mention that when using "make --shuffle=reverse"
to build, the build can be completed if restarted only with "make". It
will not pull any other Buildroot package. This fact hints toward a
Makefile dependency issue internal to the EDK2 build system, rather
than in the Buildroot recipe.
The EDK2 build system is quite unique. See [2]. It generates files,
makefiles and internally uses GNU Make to compile code. This system is
likely not tested as being a sub-Make process in a complex Makefile
such as Buildroot.
In order to prevent Buildroot to pass unexpected Make flags to the
EDK2 sub-Make, this commit unset the MAKEFLAGS variable in the EDK2
build environment. This will put the EDK2 build script in a more
common and tested state. See GNU Make documentation about recursive use
of Make, more specifically [3].
Note: as mentioned, the build failure is likely due to an internal
issue of the EDK2 build system. The failure points to a missing
dependency in the EDK2 generator itself. This commit does not fix this
issue, but rather put the EDK2 build system in a normalized
environment, avoiding Buildroot flags being passed to the internal
EDK2 sub-Make invocation. The upstream EDK2 build system most likely
need a fix too.
Fixes:
make[2]: *** No rule to make target '/buildroot/output/build/edk2-edk2-stable202308/Build/RiscVVirtQemu/RELEASE_GCC5/RISCV64/MdeModulePkg/Application/UiApp/UiApp/DEBUG/UiApp.efi', needed by '/buildroot/output/build/edk2-edk2-stable202308/Build/RiscVVirtQemu/RELEASE_GCC5/FV/Ffs/462CAA21-7614-4503-836E-8AB6F4662331UiApp/UiApp.offset'. Stop.
build.py...
: error 7000: Failed to execute command
make tbuild [/buildroot/output/build/edk2-edk2-stable202308/Build/RiscVVirtQemu/RELEASE_GCC5/RISCV64/MdeModulePkg/Application/UiApp/UiApp]
build.py...
: error F002: Failed to build module
/buildroot/output/build/edk2-edk2-stable202308/MdeModulePkg/Application/UiApp/UiApp.inf [RISCV64, GCC5, RELEASE]
[1] https://lists.buildroot.org/pipermail/buildroot/2023-December/681507.html
[2] https://tianocore-docs.github.io/edk2-BuildSpecification/draft/4_edk_ii_build_process_overview/42_build_process_overview.html
[3] https://www.gnu.org/software/make/manual/make.html#Options_002fRecursion
Reported-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 44af6938fb)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following security issues:
1) CVE-2023-6377: X.Org server: Out-of-bounds memory write in XKB button actions
A device has XKB button actions for each button on the device. When a
logical device switch happens (e.g. moving from a touchpad to a mouse), the
server re-calculates the information available on the respective master
device (typically the Virtual Core Pointer). This re-calculation only
allocated enough memory for a single XKB action rather instead of enough for
the newly active physical device's number of button. As a result, querying
or changing the XKB button actions results in out-of-bounds memory reads and
writes.
This may lead to local privilege escalation if the server is run as root or
remote code execution (e.g. x11 over ssh).
2) CVE-2023-6478: X.Org server: Out-of-bounds memory read in
RRChangeOutputProperty and RRChangeProviderProperty
This fixes an OOB read and the resulting information disclosure.
Length calculation for the request was clipped to a 32-bit integer. With
the correct stuff->nUnits value the expected request size was truncated,
passing the REQUEST_FIXED_SIZE check.
The server then proceeded with reading at least stuff->nUnits bytes
(depending on stuff->format) from the request and stuffing whatever it finds
into the property. In the process it would also allocate at least
stuff->nUnits bytes, i.e. 4GB.
See also CVE-2022-46344 where this issue was fixed for other requests.
For more details, see the advisory:
https://lists.x.org/archives/xorg-announce/2023-December/003435.html
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 9b62f5905e)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since commit 5770a645a3 ("package/qt5:
bump packages to latest kde submodule versions"), the
QT_HEADERS_SYNC_HOOK hook no longer calls the syncqt.pl script, so
host-perl is no longer needed as a dependency of running this
hook (and as a dependency of building Qt).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit b678091a1c)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
BR2_DOWNLOAD_FORCE_CHECK_HASHES currently has the following
dependency:
depends on BR2_GLOBAL_PATCH_DIR != ""
However, strictly speaking checking all hashes does not necessarily
require using BR2_GLOBAL_PATCH_DIR, as long as you don't use custom
versions.
But more importantly:
- Having this dependency means that this options is hidden when people
don't use BR2_GLOBAL_PATCH_DIR. Instead the option should always be
made visible, encouraging people to turn it on.
- The Config.in comment was there to mitigate this previous argument,
but this comment then shows up all the time when you have an empty
global patch dir.
This seems over-complicated, and it sounds much easier to have the
option unconditionally available, and visible, and clarify in its help
text that in order to this to work fully with custom package versions,
BR2_GLOBAL_PATCH_DIR can be used to provide extra hash files.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr:
- fix typo noticed by Peter K.
- reword kast sentence after review by Peter K.
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 5b0c02a77a)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
With upstram commit [1] (since version v0.1.0) the pipeline option 'raspberrypi'
was renamed to 'rpi/vc4'.
Change the buildroot option name from BR2_PACKAGE_LIBCAMERA_PIPELINE_RASPBERRYPI
to BR2_PACKAGE_LIBCAMERA_PIPELINE_RPI_VC4 (and add Config.in.legacy entry
accordingly) and move handling in Config.in/libcamer.mk to follow alphabetic
ordering.
Fixes:
.../build/libcamera-v0.1.0/meson.build:3:0: ERROR: Options "raspberrypi" are not in allowed choices: "all, auto, imx8-isi, ipu3, rkisp1, rpi/vc4, simple, uvcvideo, vimc"
[1] https://git.libcamera.org/libcamera/libcamera.git/commit/?id=726e9274ea95fa46352556d340c5793a8da51fcd
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 782d268aba)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This reverts commit c9645fd29b.
Building libcamera-apps 1.3.0 with current libcamera 0.1.0 fails because
some of the symbols like controls::AeFlickerMode are not recognized.
According to my research, they have been introduced after libcamera 0.1.0
but there is no release version of libcamera newer than 0.1.0 available
to which we could bump.
Signed-off-by: Sebastian Bauer <mail@sebastianbauer.info>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit bf7a1f10dd)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since GDB 13.x and upstream commit
b686ecb5b10be9a33ab8f1bfdcff22eef920d1a5 ("gdb: link executables with
libtool"), gdb will be linked against the shared variants of libbfd
and libopcodes if they exist. However, this causes host gdb and target
gdb to not work, because our gdb package does not install libbfd and
libopcodes (to not clash with the ones potentially installed by
binutils).
In order to get around this, this commit proposes to get back to the
situation we had before GDB 13.x: libbfd and libopcodes are only
compiled as static libraries, so that they are linked directly inside
the gdb binary, avoiding the problem entirely.
This resolves:
# gdb --version
gdb: error while loading shared libraries: libopcodes-2.39.50.so: cannot open shared object file: No such file or directory
for target gdb, and:
$ ./host/bin/arm-linux-gdb --version
./host/bin/arm-linux-gdb: error while loading shared libraries: libopcodes-2.39.50.so: cannot open shared object file: No such file or directory
for host gdb.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit e5729d3008)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
- Drop patches (already in version) and so drop autoreconf
- Fix the following security issues:
- CVE-2023-40660: Fix Potential PIN bypass
- CVE-2023-40661: Important dynamic analyzers reports
- CVE-2023-4535: Out-of-bounds read in MyEID driver handling
encryption using symmetric keys
https://github.com/OpenSC/OpenSC/releases/tag/0.24.0
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 37eb68c9fb)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit d344ffe624 (configs/rock5b: add hash for custom uboot)
explicitly noted that the kernel was retrieved from a git-clone, so the
sha1 of the commit was enough to get what we expect.
However, that does not account for the fact that the upstream repository
can disapear or be temporarily unavailable (maliciously or not). In that
case, the kernel archive will be looked up on the backup mirror.
In that case, the download is via wget over https, which protects the
transport, but does not guarantee that the remote server serves the
expected archive.
The hash file was dropped when d344ffe624 was applied; restore it.
Since the defconfig now has hashes for all its downloads, enforce
checking hashes.
Signed-off-by: Kilian Zinnecker <kilian.zinnecker@mail.de>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 9ebbfeff38)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The defconfig uses a custom uboot version, downloaded with wget, so we
weant to be sure that it does not get modified on the server, so we add
a hash for it.
The kernel we get from a git clone, so the sha1 of the commit is enough
to be sure that what we get is what we expect (because we do a local
tarball out of a git clone).
Since we only get a hash for uboot and not for the kernel, we don't
enable BR2_DOWNLOAD_FORCE_CHECK_HASHES.
Signed-off-by: Kilian Zinnecker <kilian.zinnecker@mail.de>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit d344ffe624)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since upstream commit
eec95e3d5e1a4f2e13b1f6b34cc287475ca57daf ("backend/drm: use pnp.ids to
fetch EDID data"), the pnp.ids file from hwdata is parsed at build
time to generate a C source file. As per backend/drm/meson.build:
hwdata = dependency('hwdata', required: false, native: true)
if hwdata.found()
hwdata_dir = hwdata.get_variable(pkgconfig: 'pkgdatadir')
pnp_ids = files(hwdata_dir / 'pnp.ids')
else
pnp_ids = files('/usr/share/hwdata/pnp.ids')
endif
This is only needed when the DRM backend of wlroots is enabled, but
currently, Buildroot enables this backend unconditionally.
This failure can be reproduced using the following defconfig:
BR2_x86_64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV=y
BR2_PACKAGE_MESA3D=y
BR2_PACKAGE_MESA3D_OSMESA_GALLIUM=y
BR2_PACKAGE_MESA3D_OPENGL_EGL=y
BR2_PACKAGE_MESA3D_OPENGL_ES=y
BR2_PACKAGE_WLROOTS=y
The issue was not caught in the autobuilders because the last
successful build of a configuration that includes wlroots dates back
from 2022-05-05, at which time Buildroot had wlroots 0.15.1.
This change in wlroots was introduced in wlroots 0.16.0, which means
that it's only since Buildroot bumped from 0.15.1 to 0.16.2 in
d6279bc82c ("package/wlroots: bump to
version 0.16.2") that the issue occurs. This commit is not yet in any
tagged release, so there is no need to backport this fix.
It should be noted that the proposed patch also installs pnp.ids to
the target filesystem, while it is in practice not needed at runtime
by wlroots. However, our current hwdata packaging doesn't allow
installing it only in staging, and since wlroots anyway implies we're
building a fairly heavy graphics stack, the size overhead of hwdata is
deemed to be an acceptable trade-off.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
[Thomas: further extend the commit log, with details gathered by Yann
and myself.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 50eed2060a)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
As described in the announcement, this fixes a security issue:
There is one security fix in this release:
- Fix for a newly discovered security issue known as the 'Terrapin'
attack, also numbered CVE-2023-48795. The issue affects widely-used
OpenSSH extensions to the SSH protocol: the ChaCha20+Poly1305
cipher system, and 'encrypt-then-MAC' mode.
In order to benefit from the fix, you must be using a fixed version
of PuTTY _and_ a server with the fix, so that they can agree to
adopt a modified version of the protocol. Alternatively, you may be
able to reconfigure PuTTY to avoid selecting any of the affected
modes.
If PuTTY 0.80 connects to an SSH server without the fix, it will
warn you if the initial protocol negotiation chooses an insecure
mode to run the connection in, so that you can abandon the
connection. If it's possible to alter PuTTY's configuration to
avoid the problem, then the warning message will tell you how to do
it.
https://lists.tartarus.org/pipermail/putty-announce/2023/000037.html
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 922132c39e)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
5 CVEs affecting glibc according to the NVD database are considered as
not being security issues by upstream glibc developers:
* CVE-2010-4756: The glob implementation in the GNU C Library (aka
glibc or libc6) allows remote authenticated users to cause a denial
of service (CPU and memory consumption) via crafted glob expressions
that do not match any pathnames. glibc maintainers position: "That's
standard POSIX behaviour implemented by (e)glibc. Applications using
glob need to impose limits for themselves"
* CVE-2019-1010022: GNU Libc current is affected by: Mitigation
bypass. The impact is: Attacker may bypass stack guard
protection. The component is: nptl. The attack vector is: Exploit
stack buffer overflow vulnerability and use this bypass
vulnerability to bypass stack guard. NOTE: Upstream comments
indicate "this is being treated as a non-security bug and no real
threat. glibc maintainers position: "Not treated as a security issue
by upstream https://sourceware.org/bugzilla/show_bug.cgi?id=22850"
* CVE-2019-1010023: GNU Libc current is affected by: Re-mapping
current loaded library with malicious ELF file. The impact is: In
worst case attacker may evaluate privileges. The component is:
libld. The attack vector is: Attacker sends 2 ELF files to victim
and asks to run ldd on it. ldd execute code. NOTE: Upstream comments
indicate "this is being treated as a non-security bug and no real
threat. glibc maintainers position: "Not treated as a security issue
by upstream https://sourceware.org/bugzilla/show_bug.cgi?id=22851"
* CVE-2019-1010024: GNU Libc current is affected by: Mitigation
bypass. The impact is: Attacker may bypass ASLR using cache of
thread stack and heap. The component is: glibc. NOTE: Upstream
comments indicate "this is being treated as a non-security bug and
no real threat. glibc maintainers position: "Not treated as a
security issue by upstream
https://sourceware.org/bugzilla/show_bug.cgi?id=22852"
* CVE-2019-1010025: GNU Libc current is affected by: Mitigation
bypass. The impact is: Attacker may guess the heap addresses of
pthread_created thread. The component is: glibc. NOTE: the vendor's
position is "ASLR bypass itself is not a vulnerability. Glibc
maintainers position: "Not treated as a security issue by upstream
https://sourceware.org/bugzilla/show_bug.cgi?id=22853"
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit adaae82c58)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
As reported in bug 15895, the GLIBC_VERSION field having a value
looking like 2.38-27-g750a45a783906a19591fb8ff6b7841470f1f5701, it
prevents the CPE/CVE matching with the NVD database to work correctly.
This commit fixes that by defining GLIBC_CPE_ID_VERSION, derived from
GLIBC_VERSION, by extracting the base version.
Also, we update GLIBC_IGNORE_CVES to account for the CVEs that have
clearly been fixed between 2.38 and
2.38-27-g750a45a783906a19591fb8ff6b7841470f1f5701. There are a number
of other CVEs still affecting the glibc package, but they are not
related to this
2.38...2.38-27-g750a45a783906a19591fb8ff6b7841470f1f5701 range.
Fixes: #15895
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit af8c0e5c74)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
It turns out that wildcard expansion, * and ?, is not performed in
matching lists {...}, at least in the vim plugin. The spec is not clear
about that, but refer to "pattern matching through Unix shell-style
wildcards" [0].
So, let's consider that this is not supported. Expand the patterns into
one section each, rather than use a list.
[0] https://spec.editorconfig.org/
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit ceb678ca19)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
OpenSSH 9.6 was released on 2023-12-18.
This release contains fixes for a newly-discovered weakness in the
SSH transport protocol (the "Terrapin" attack), a logic error relating
to constrained PKCS#11 keys in ssh-agent(1) and countermeasures for
programs that invoke ssh(1) with user or hostnames containing invalid
characters.
https://www.openssh.com/txt/release-9.6
Signed-off-by: Christian Stewart <christian@aperture.us>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 3c047ea463)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since the update of Python to version 3.11 in commit
738500c296 ("package/python3: bump to
version 3.11.0"), python-sip fails to compile with:
siplib.c: In function ‘sip_api_get_frame’:
siplib.c:13750:22: error: invalid use of undefined type ‘struct _frame’
13750 | frame = frame->f_back;
This is due to a change in the Python C API, which is fixed by a new
patch. The patch can't be upstreamed, as SIP 4.x is no longer
maintained upstream.
Fixes:
http://autobuild.buildroot.net/results/7b01739e7514e48c06182bc1804b32497ce2e414/
Signed-off-by: Ralf Dragon <hypnotoad@lindra.de>
[Thomas: improved commit log, reformatted patch using Git]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 3ef6884e6d)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following security issues:
- CVE-2023-5367 X.Org server: OOB write in
XIChangeDeviceProperty/RRChangeOutputProperty
- CVE-2023-5380: Use-after-free bug in DestroyWindow
- CVE-2023-5574: Use-after-free bug in DamageDestroy
For details, see the advisory:
https://lists.x.org/archives/xorg-announce/2023-October/003430.html
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 36a9ec8921)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
rsync is used in the infrastructure, mostly for the per-package infra,
and for the override-srcdir mechanism, but also to build the manual.
As such, it is not optional but mandatory, and already listed so.
Drop the reference to rsync from the list of optional packages.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit b79fb3c224)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following security issues:
- CVE-2023-46218: cookie mixed case PSL bypass
This flaw allows a malicious HTTP server to set "super cookies" in curl
that are then passed back to more origins than what is otherwise allowed
or possible. This allows a site to set cookies that then would get sent
to different and unrelated sites and domains.
https://curl.se/docs/CVE-2023-46218.html
- CVE-2023-46219: HSTS long file name clears contents
When saving HSTS data to an excessively long file name, curl could end up
removing all contents, making subsequent requests using that file unaware
of the HSTS status they should otherwise use.
https://curl.se/docs/CVE-2023-46219.html
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit aaa9438b96)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The prebuilt kernel has been updated to 5.10.202, sync the kernel
built by InitSystemSystemdBaseOverlayfs.
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit f6254689f8)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/5834758777
Commit e7d16c35a (boot/arm-trusted-firmware: fix the RPATH of fiptool) tried
to fix the build of host-fiptool, but forgot to pass HOST_CFLAGS.
On hosts without (compatible) openssl development headers, this breaks
the build when it cannot find the openssl headers:
fiptool_platform.h:19:11: fatal error: openssl/sha.h: No such file or directory
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit e6ef64d955)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Update the zynq readme.txt to add documentation for the zc702 and correct
documentation that was no longer up to date.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 9675f6150c)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The arm-trusted-firmware package builds a host tool called "fiptool",
which is used during the build process of arm-trusted-firmware
itself. This tool links against the OpenSSL host library, and
therefore needs to be built with the correct RPATH pointing to
$HOST_DIR/lib.
This is why commit a957d9a90a
("boot/arm-trusted-firmware: build fiptool separately with dependency
o n host-openssl") added the ARM_TRUSTED_FIRMWARE_BUILD_FIPTOOL
variable, which builds the fiptool tool first, with the right
variables set, before invoking the full build of TF-A. This ensured
that fiptool was built with the correct RPATH.
However, more recent versions of TF-A have modified their Makefile
machinery, and fiptool is being rebuilt even if it was built
before. Unfortunately, this rebuild is no longer done with the right
flags, so we end up with a fiptool binary that no longer has the right
RPATH, and fiptool fails to find the OpenSSL libraries from
$HOST_DIR/lib.
In order to fix this, we take a different approach: we do not build
fiptool separately first, but we inject the necessary flags through
the HOSTCC variable. Indeed, there's no HOST_LDFLAGS or HOST_LDLIBS
variable or similar that would allow us to pass the -Wl,-rpath flag
that is needed. Shoe-horning this flag into HOSTCC gets the job done,
and actually simplifies our arm-trusted-firmware.mk.
This patch break the compatibility with version prior to 1.4 (upstream
commit 72610c4102990 ("build: Introduce HOSTCC flag")). v1.4 is very old
(July 2017), not used anymore in-tree and probably not used anymore
outside the tree.
Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
Co-authored-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit e7d16c35ae)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
# used to fix ../../../../libsanitizer/libbacktrace/../../libbacktrace/elf.c:772:21: error: 'st.st_mode' may be used uninitialized in this function [-Werror=maybe-uninitialized]
ifeq($(BR2_ENABLE_DEBUG),y)
GCC_COMMON_TARGET_CFLAGS+= -Wno-error
endif
# Make sure libgcc & libstdc++ always get built with -matomic on ARC700
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.
