Resolves the following error when building against MUSL:
tools/attr.c: In function 'main':
tools/attr.c:69:20: error: implicit declaration of function 'basename'
[-Wimplicit-function-declaration]
69 | progname = basename(argv[0]);
| ^~~~~~~~
tools/attr.c:69:18: error: assignment to 'char *' from 'int' makes
pointer from integer without a cast [-Wint-conversion]
69 | progname = basename(argv[0]);
| ^
Upstream: https://git.savannah.nongnu.org/cgit/attr.git/commit/?id=8a80d895dfd779373363c3a4b62ecce5a549efb2
Fixes: http://autobuild.buildroot.net/results/c61206968eda9913e37e95a61dc3e10399503fcd/
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
[Romain: use upstream patch]
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit fa241685e7f92311f5fd50ce17c1541748fe285b)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
- fix alphabetical ordering
- put one module per line
- add comment explaining why options are enabled
Signed-off-by: Michael Nosthoff <buildroot@heine.tech>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit 5c20804afa42cb2efd57a4a333841290d35d9df6)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Lots of people are using broken text editors that 1. do not naturally
terminate text files with a final \n as is customary in UNIX text files,
and 2. do not respect our .editorconfig settings, which explicitly
require adding that final newline. See this nice summary of what a text
file is (with references to applicable standards):
https://stackoverflow.com/questions/12916352/shell-script-read-missing-last-line/12916758#12916758
So, it is not surprising that read does not read the last "line" of a
file, when said "line" does not end with a newline, because it is thus
not really a line.
Even though we do mandate actual text files, let's be a little bit lax
in this respect, because people may write packages, and their hash
files, in a br2-external tree, and they may not have our .editorconfig
in the directory heierarchy (e.g. if buildroot is a submodule of their
br2-external tree, or whatever).
mapfile does not suffer from this limitation, though, and correctly
reads all lines from a file, even the final line-that-is-not-a-line.
mapfile was introduced in bash 4.0, released on 2009-01-20, more than
15 years ago. Debian squeeze, released in 2011 already had bash 4.1.
Those are really ancient. So, it means we can indeed expect bash
version 4.0 or later; which means mapfile is available.
"It should be fine!"
Fixes: #15976
Reported-by: masonwardle@gmail.com
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit ac2e6b392791085bc29fa21901265a8eed4ae0ee)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
According to https://spdx.org/licenses/, the correct license code for
the "Clarified Artistic License" is ClArtistic.
The only other package in Buildroot containing code under this license
is google-breakpad, and it is already using the ClArtistic SPDX code.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit 2ca698051c50546a70e9f7b625f2ee9a2a6a2840)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
`b4` is a commandline tool to make patch-based development easier[1]. It
is primarily used for Linux kernel development, but can be configured to
support any project that has a public-inbox endpoint. Buildroot has a
public-inbox mirror at "https://lore.kernel.org/buildroot/".
We configure some basic settings that tell `b4` where to send patches
and how to use get-developers.
[1] https://b4.docs.kernel.org/en/latest/
Signed-off-by: Brandon Maier <brandon.maier@collins.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit 322213e131fabd6aa6879c4f653415a35c93e63e)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Drop patch which is included in this release.
Changelog: https://matt.ucc.asn.au/dropbear/CHANGES
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 516d57dc9c)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
- Fix CVE-2024-1544, CVE-2024-5288, CVE-2024-5991 and CVE-2024-5814
- Disable option checking which is enabled by default since
412447ac41https://github.com/wolfSSL/wolfssl/releases/tag/v5.7.2-stable
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit f13e0014a548244cd0e617ab60b47c68c872f823)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
User may get confused when they see the current hint, and take that as
the proper replacement, while we're only reporting the stem of the
variable name:
.../foo.mk:16: possible typo: BLA -> *FOO*
There is usually no easy way to actually suggest the proper variable
name, though, so let's make it a little bit more obvious that we meant
the variable was improperly prefixed:
.../foo.mk:16: possible typo, variable not properly prefixed: BLA -> *FOO_XXX*
And while at it, throw in the URL to the corresponding manual entry.
Adapt the test accordingly.
Reported-by: "Frager, Neal" <neal.frager@amd.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Ricardo Martincoski <ricardo.martincoski@datacom.com.br>
Reviewed-by: Neal Frager <neal.frager@amd.com>
[Arnout: also update new test, scoped -> prefixed]
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit 5836b797626db56958fec09810e16af1c75d2b4c)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently, when a package defines an unprefixed variable, but its value
contains a properly prefixed expansion (or even just the name of a
variable), there is not error reported (e.g. with the recently fixed
composer issue):
BASE_SITE = https://getcomposer.org/download/$(COMPOSER_VERSION)/composer.phar
The reason is that he check is done on the whole line, rather than on
the variable that is being set.
We fix that by really looking at the variable we found, instead of
looking in the whole line.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Ricardo Martincoski <ricardo.martincoski@datacom.com.br>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit b0964df557bedd88db1a223491fba615c995484f)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Newer 32bit architectures like RISCV32 and ARC are using 64bit time_t
from the get go unlike other 32bit architectures, therefore aliasing
__NR_futex to __NR_futex_time64 avoids the build error mentioned
in cb6fd050.
Fixes:
- http://autobuild.buildroot.org/results/c0f4168575fa85af933539441eea95a3b10dac91
Signed-off-by: Steffen Persvold <spersvold@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit a4ae4122936306952109865006d055a112a111f1)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This reverts (partial) commit
e39ad96136, and
26642e4cc0, but also fixed additional
sites where the !BR2_RISCV_32 dependency is no longer needed, thanks
to the recently added
0001-src-xshmfence_futex.h-fix-build-on-32-bit-architectu.patch in
xlib_libxshmfence.
Signed-off-by: Thomas Devoogdt <thomas@devoogdt.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit f30da3dc2181f157c25b742e6785b4b79f5deedf)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In preparation to revert e39ad96136,
and (partial) 26642e4cc0.
xshmfence_futex.h: In function 'sys_futex':
xshmfence_futex.h:58:24: error: 'SYS_futex' undeclared (first use in this function); did you mean 'sys_futex'?
58 | return syscall(SYS_futex, addr1, op, val1, timeout, addr2, val3);
| ^~~~~~~~~
| sys_futex
Fixes:
- e39ad96136
Signed-off-by: Thomas Devoogdt <thomas@devoogdt.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 36c7b1f08607c92186b849bd395fb2529942a6f9)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
There was an error in the pkg-cmake infra file regarding the selection
of the ASM compiler. Now that this has been fixed, overwriting the
ASM compiler selection is no longer necessary.
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit 638474478093831d76ab70e0cb3bd2d65d4a4511)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
CMAKE_ASM_COMPILER is supposed to point to a compiler wrapper (i.e.
gcc), _not_ to as directly. If it is not set, it will use the value of
CMAKE_C_COMPILER. That's exactly what we want, so there is no need to
set CMAKE_ASM_COMPILER at all.
For target, we don't set CMAKE_ASM_COMPILER either.
Setting CMAKE_ASM_COMPILER leads to build failures for any package that
actually tries to build .S files for the host - like llvm. This is why
llvm has an override for it.
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit 22af5f2939089b996aeda9ce072ab2f9b3ee6c2d)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
To give us a chance to catch runtime issues (such as missing
dependencies) more easily, add a test that writes a sample PDF file,
read it back and verify the text that was read.
Like similar packages that lead to a big
rootfs (e.g. python-botocore), this test requires a separate ext2
rootfs to avoid filling the default amount of RAM available
entirely (which would cause missing files from the root filesystem and
in turn, test failures).
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 115e9493b8e3b50cd56b93c47d669319d02698a7)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Now that the mandatory dependency of MuPDF on X.org, we can also drop
this dependency from python-pymupdf.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit edfa6f29785e618b75739b702fc863ee2410908d)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
It turns out that python-pymupdf doesn't require zlib directly, but it
does require the zlib python module.
This fixes the following runtime error:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python3.11/site-packages/fitz/__init__.py", line 22, in <module>
File "/usr/lib/python3.11/site-packages/fitz/fitz.py", line 3402, in <module>
File "/usr/lib/python3.11/gzip.py", line 9, in <module>
ModuleNotFoundError: No module named 'zlib'
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit ba6baa019b8b0146d053f310ddd2bc96cb9465a5)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The X11 support in mupdf is actually optional, and it does require
libXext in addition to libX11, so adjust the packaging accordingly.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 2c0d7b72c0993a55c8dcb7b38d85792e1bf6e8bc)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Now that MUPDF_CFLAGS and MUPDF_LDFLAGS are just TARGET_CFLAGS and
TARGET_LDFLAGS, drop them.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 90f0a484671098f9a94ce66b8f8af94e106ae106)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
By default mupdf generates static libraries, shared libraries must be
enabled explicitely.
Also, when building shared libraries, mupdf's Makefile properly passes
-fPIC, so adding it manually to MUPDF_CFLAGS is not needed.
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 401162d4a947184654d8202392425a625d000172)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This variable might have been needed in the very distant past to help
mupdf find libraries, but mupdf's Makefile now properly uses
pkg-config to find the 5 libraries freetype2, gumbo, harfbuzz, libjpeg
and zlib, so our code has become redundant: drop it.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit f7deaa1330baad303afb76a7711faeeb1ddfee5d)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The build of gcc with Fortran support is broken on gcc 12.x and gcc
13.x, it fails with:
../../../libgfortran/generated/bessel_r8.c: In function 'bessel_yn_r8':
../../../libgfortran/generated/bessel_r8.c:178:1: internal compiler error: in gen_reg_rtx, at emit-rtl.cc:1167
This issue has been fixed in gcc 14.x, which builds a Microblaze
Fortran-capable toolchain successfully.
Since we're not really interested in figuring out the commit that
fixed the problem, let's simply disallow the selection of Fortran with
gcc12/13 on Microblaze.
Fixes:
http://autobuild.buildroot.net/results/5b4eee1d9b119c9f923f9518618f45a6482ddc85/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit 41f25676184fdbb3243c3709b925369679e7423a)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In commit 809fdb3a7a ("package/gdb:
remove gdb 10.x") and
030497be18 ("package/gdb: remove support
for GDB 11.x"), we forgot to drop the no longer needed hashes from
gdb.hash. Let's do this now.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit 538a99a33a2729b829ee07394de1a19dd955814a)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix the following build failure raised since bump to version
1.4.2-168-ged3039c in commit 2e330dff6a:
/home/buildroot/autobuild/run/instance-1/output-1/host/lib/gcc/arm-buildroot-linux-musleabihf/12.3.0/../../../../arm-buildroot-linux-musleabihf/bin/ld: attempted static link of dynamic object `libfdt/libfdt-1.6.1.so'
Fixes:
- http://autobuild.buildroot.org/results/6788d86c10d551b3d617e33c85083b817eb5d0b2
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit e167800979b48a449c168c229448e7069d2045e7)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
https://gcc.gnu.org/gcc-12/changes.html describes the changes of gcc
12.4 as follows:
This is the list of problem reports (PRs) from GCC's bug tracking
system that are known to be fixed in the 12.4 release. This list
might not be complete (that is, it is possible that some PRs that
have been fixed are not listed here).
With a link to
https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=12.4
There are 654 relevant commits (ignoring the "daily bumps") between
gcc 12.3.0 and 12.4.0, which is too much to list exhaustively here.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit b4454720908e79252ea98bcbe4de86e4bbd4de77)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The patch removes one of the two occurrences of libnfc from the list of
packages managed by Simon Dawson.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 673d371cf22262509e8f764615864be31b3e146e)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The ESI feature is now disabled by default. Use --enable-esi if needed.
See here for other changes:
https://github.com/squid-cache/squid/commits/v6
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 4c1a85a87d5aabfc2a4ec99da7c48df9f1884797)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
libressl doesn't support all architectures since bump to version 3.8.2
in commit 21eca49ed5 and
b98c56fd5e71ce0b8c3e:
In file included from /home/autobuild/autobuild/instance-4/output-1/build/libressl-3.8.2/crypto/rc4/rc4_enc.c:61:
/home/autobuild/autobuild/instance-4/output-1/build/libressl-3.8.2/crypto/../include/openssl/rc4.h:75:9: error: unknown type name 'RC4_INT'
75 | RC4_INT x, y;
| ^~~~~~~
Fixes:
- http://autobuild.buildroot.org/results/1f6ac121b3771ccc4b0e846c061b7002ccb63963
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 080f2d94b7ac6e8ed5aef99000ec35a001186ed9)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
cdrkit.org no longer works, and there is no obvious homepage for this
dead project. Use the Wikipedia page as a replacement.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit aa549fb95f8409c2b364cd1d8257f92a1b693720)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
similar to previous problems with nios2 and not-available atomic ints
the build for Boost.Atomics also fails for ARC Targets which don't
have the ATOMICS_EXT flag set.
according to [0] "Boost.Atomic has a hard requirement of the native
atomic operations on bytes". The same tests mentioned there fail for
ARC without the atomic extension.
Disable BR2_TOOLCHAIN_SUPPORTS_ALWAYS_LOCKFREE_ATOMIC_INTS for BR2_arc
without BR2_ARC_ATOMIC_EXT.
Fixes:
http://autobuild.buildroot.net/results/4ca54a85672d7b9328b1909b457e548c6032a493
[0] https://github.com/boostorg/atomic/issues/42#issuecomment-734130348
Signed-off-by: Michael Nosthoff <buildroot@heine.tech>
[Arnout: add to BR2_TOOLCHAIN_SUPPORTS_ALWAYS_LOCKFREE_ATOMIC_INTS
instead of updating all packages]
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit ad71b415c1bdf1bbf4c37b04c772dc3104187b58)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
make "gcc --help -v" display all the options, some packages depend on this
https://bugs.busybox.net/show_bug.cgi?id=15231
Signed-off-by: Sagi Mor <sagimor6@gmail.com>
[Arnout: move the handling to the beginning and directly call execv]
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit 9954315fc5b2026552a0f0175307ec8784b51578)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The build logic in source/cmake/FindNeon.cmake caused the x265 build
system to always think that the CPU supports neon: it was looking in
/proc/cpuinfo, which of course is wrong when cross-compilation, but
then the sequence of grep was interacting badly with CMake, causing
the build system to always conclude that the CPU supports NEON.
This causes runtime issues on ARMv6.
Setting -DCROSS_COMPILE_ARM=1 fixes this, as it tells the x265 build
system we are cross-compiling and it skips its bogus NEON check. So
for ARMv6, we pass -DCROSS_COMPILE_ARM=1.
But then, we still want NEON for ARMv7 processors with NEON, so this
commit adds a patch that allows to explicitly specify whether the CPU
supports NEON, in the -DCROSS_COMPILE_ARM=1 case, and we use this
option when BR2_ARM_CPU_HAS_NEON.
For those wondering why -DCROSS_COMPILE_ARM=1 is not passed for all
ARM platforms: it's because from the perspective of x265, only ARM >=
v6 is ARM: it has assembly code that needs at least ARMv6. Earlier ARM
platforms are not detected as ARM by the x265 build logic, and
therefore fallback on generic code.
This has been build-tested on:
- ARMv5: generic code is used, no assembly
- ARMv6: assembly code is used, but not with NEON support
- ARMv7 with NEON: assembly code is used, with NEON support
Reported-by: David Barbion <davidb@230ruedubac.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 1fbd26f83169a206bdf9c36c85510a33c0e7a864)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
As we're about to do some other fixes in x265 ARM build, let's replace
the patch fixing gcc option by:
- A patch generated by git format-patch now that x265 upstream uses
Git
- Is re-submitted upstream
- Only drops the flags, and does not add bogus ARM architecture
aliases that don't exist in the CMake world.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 9d62687d0024f7e3bac68157f1250970ef45abff)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
GNU Octave supports the --with-sndfile configure option since v4.0.0.
For reference, commit 40ea68b4b2 "package/octave: new package"
introduced the package at v7.1.0.
This commits adds this optional support.
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit a5ce48fe456d790612c9b63990f0a4f3e2faa554)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The btrfs-progs homepage [1] show a banner:
OBSOLETE CONTENT
This wiki has been archived and the content is no longer updated.
NOTE: this wiki is archived and not updated anymore (02/2023).
Contents will be migrated to https://btrfs.readthedocs.io
This commit updates the URL to the new one at [2].
[1] https://btrfs.wiki.kernel.org/index.php/Main_Page
[2] https://btrfs.readthedocs.io
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 91cd9488005e7f0fce7ead126f1e637deefcaf02)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
A lot has been changed in 2.44.0, please consult the announcement [1], what's new [2],
and the security advisory [3] for more details.
Specific to this bump:
- Libegl is now mandatory [4] and the USE_OPENGL_OR_ES flag has been dropped.
While at it, also explicitly add the libepoxy dependency which is now selected
by libgtk3.
- The WPE renderer has been dropped [2], so drop the wpebackend-fdo dependency.
- JPEG2000 has been dropped [2], so drop the OpenJPEG dependency.
- GTK4 is now the default, so turn it off, since buildroot has no GTK4 support
yet [2].
- USE_LIBBACKTRACE has been added [5], so select it properly.
- Support for ENABLE_WEB_CODECS has been added, which will now be enabled
together with audio and video support.
- ENABLE_WEBASSEMBLY is forbidden when ENABLE_C_LOOP [6], so disable it when
compiling for MIPS r6, ARMv5, and ARMv6.
In the meantime, a follow-up 2.44.1 and 2.44.2 release has been announced [7][8],
which contains a bunch of patches that were accepted upstream. Including build
fixes for 32-bit devices, and disabling video.
[1]: https://webkitgtk.org/2024/03/16/webkitgtk2.44.0-released.html
[2]: https://webkitgtk.org/2024/03/27/webkigit-2.44.html
[3]: https://webkitgtk.org/security/WSA-2024-0002.html
[4]: https://commits.webkit.org/271345@main
[5]: https://commits.webkit.org/268579@main
[6]: https://commits.webkit.org/271347@main
[7]: https://webkitgtk.org/2024/04/09/webkitgtk2.44.1-released.html
[8]: https://webkitgtk.org/2024/05/16/webkitgtk2.44.2-released.html
Signed-off-by: Thomas Devoogdt <thomas@devoogdt.com>
Acked-by: Adrian Perez de Castro <aperez@igalia.com>
Tested-by: Adrian Perez de Castro <aperez@igalia.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit d5ff56ef06c46bc870cc677d34cec2639852c823)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This allows uvw to be again in sync with the libuv package, following
the bump of libuv to v1.48 in commit
bd2f99246c ("package/libuv: security
bump to version 1.48")
The hash of the license file has changed due to a copyright year
update.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit c54134bf6914593caaa9ed4aa11cbe3a17c59eca)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following security issue:
net/http: denial of service due to improper 100-continue handling
The net/http HTTP/1.1 client mishandled the case where a server responds to
a request with an "Expect: 100-continue" header with a non-informational
(200 or higher) status. This mishandling could leave a client connection in
an invalid state, where the next request sent on the connection will fail.
An attacker sending a request to a net/http/httputil.ReverseProxy proxy can
exploit this mishandling to cause a denial of service by sending "Expect:
100-continue" requests which elicit a non-informational response from the
backend. Each such request leaves the proxy with an invalid connection, and
causes one subsequent request using that connection to fail.
Thanks to Geoff Franks for reporting this issue.
This is CVE-2024-24791
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When build host has a many CPUs (more that 20) and GNU Make 4.4
(included for example in Fedora 40), fwts can randomly fail to build.
This commit adds a package patch to fix the issue.
Fixes:
mv: cannot stat 'dtcompilerparser.tab.c': No such file or directory
mv: cannot stat 'prparser.tab.c': No such file or directory
See also:
https://github.com/fwts/fwts/issues/7
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit f6d9fa3692b0e5dd75bb1fee5d151fe58da7800d)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In order for systemd-oomd to run CONFIG_PSI and CONFIG_MEMCG must be
enabled in the kernel config.
See:
e7b3f1a6c3aa329b8922
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit be5f14657a5540fdabb03ba8b5ff64c0da804e32)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
