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>
