Support added in 2.33.2:
https://webkitgtk.org/2021/06/08/webkitgtk2.33.2-released.html
"HTTP/2 support when building with libsoup3."
Signed-off-by: Thomas Devoogdt <thomas@devoogdt.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Libsoup3 has a new API [1], packages using libsoup may not compile
with libsoup3 or may crash at runtime in unexpected ways, so we add a
new package. It can be installed side by site with libsoup, without
any conflict.
[1] https://libsoup.org/libsoup-3.0/ch02.html
Signed-off-by: Thomas Devoogdt <thomas@devoogdt.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Use the newly introduce backend option to specify what cmake backend to
use, in lieue of special-coding its use as done in 78d499409f
(package/wpewebkit: Build with ninja).
Signed-off-by: Thomas Devoogdt <thomas.devoogdt@barco.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Use the newly introduce backend option to specify what cmake backend to
use, in lieue of special-coding its use as done in 16e5c92ff5
(package/webkitgtk: Build with ninja).
Signed-off-by: Thomas Devoogdt <thomas.devoogdt@barco.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cmake supports multiple generators. For now, Buildroot only uses the
venerable "GNU Makefile" generator, which generates Makefiles as the
build backend.
Cmake also has support for Ninja as a build backend, and provides the
corresponding generator. Ninja is a small build system with a focus on
speed. It is mainly used with the meson build system, but also cmake has
very good support for it.
Packages that are selecting Ninja (or over time another generator),
should also use the _BUILD_{ENV,OPTS} variables instead of the _MAKE
variables.
No _INSTALL{,_STAGING,_TARGET}_OPTS used so far, so reuse as cmake install opts:
$ grep '_INSTALL_OPTS' $(git grep -l -E '\$\(eval \$\((host-)?cmake-package))')
$ grep '_INSTALL_STAGING_OPTS' $(git grep -l -E '\$\(eval \$\((host-)?cmake-package))')
$ grep '_INSTALL_TARGET_OPTS' $(git grep -l -E '\$\(eval \$\((host-)?cmake-package))')
The _MAKE_{ENV,OPTS} are copied to _BUILD_{ENV,OPTS}, involved packages:
$ grep '_MAKE_ENV =' $(git grep -l -E '\$\(eval \$\((host-)?cmake-package))')
package/netopeer2/netopeer2.mk:NETOPEER2_MAKE_ENV = \
package/racehound/racehound.mk:RACEHOUND_MAKE_ENV = $(LINUX_MAKE_FLAGS)
(qt6, webkitgtk, and wpewebkit also match, but already use -Gninja)
$ grep '_MAKE_OPTS =' $(git grep -l -E '\$\(eval \$\((host-)?cmake-package))')
package/mariadb/mariadb.mk:HOST_MARIADB_MAKE_OPTS = import_executables
package/zeek/zeek.mk:HOST_ZEEK_MAKE_OPTS = binpac bifcl
Only "musepack" seems to overwrite MAKE to enforce -j1, so replace it:
$ grep '_MAKE =' $(git grep -l -E '\$\(eval \$\((host-)?cmake-package))')
package/musepack/musepack.mk:MUSEPACK_MAKE = $(MAKE1)
Signed-off-by: Thomas Devoogdt <thomas.devoogdt@barco.com>
Reviewed-by: John Keeping <john@metanate.com>
[yann.morin.1998@free.fr:
- switch to FOO_CMAKE_BACKEND = (make|ninja)
- use firstword of $(MAKE), not $(BR2_MAKE)
- explain why we use firstword of $(MAKE)
- update manual with the three new variables
- yweak commit log
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
In 2b43579e94 (package/gdal: switch to cmake build to fix libgeotiff
detection) a workaround was added to use the generated 'Makefile' rather
than the bundled-for-autotools GNUMakefile, which was supposedly removed
for the then upcoming 3.6 version.
In 4c17985880 (package/gdal: bump version to 3.6.2) the bump occured,
but the workaround was left untouched. However, in 3.6.2, there is
indeed no GNUMakefile anymore.
Drop the workaround now.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Changelog: https://github.com/lxml/lxml/blob/master/CHANGES.txt
Added sha256 hash provided by upstream.
This release includes fixes for upcoming Python 3.12.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The patch adds an option that allows you to not install the data along
with the binaries (less than 100kb), saving 1.4Mb of rootfs data.
By default, the data is installed for backward compatibility.
Cc: Angelo Compagnucci <angelo@amarulasolutions.com>
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The HOST Makefile variable was renamed upstream to ACPI_HOST in [1].
This commit was first included in tag R02_14_20 (version 20200214).
See the change log [2].
This no longer correct use of HOST did not introduced any
compilation error, as the code uses constructs like:
#if defined(_LINUX) || defined(__linux__)
This patch change the variable name to follow upstream, just for
correctness.
[1] 98753481f7
[2] https://github.com/acpica/acpica/blob/R02_14_20/documents/changes.txt#L25
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The HARDWARE_NAME Makefile variable was removed few years ago in
upstream (by Thomas). See [1].
This commit was first included in tag R01_19_17 (version 20170119).
See the change log [2].
This patch removes occurences of this HARDWARE_NAME, since it's now
unneeded. There is no change in the behavior of this build recipe.
[1] 0ba20f5f86
[2] https://github.com/acpica/acpica/blob/R01_19_17/documents/changes.txt#L26
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Buildroot 2022.05 use binutils 2.37 by default, but the binutils
version was downgraded to the previous binutils version in qemu_ppc64*
defconfigs due to a bug in binutils 2.37 [1].
Later when binutils 2.36 has been removed the binutils version has
been updated to 2.38 (even though it was already the default version
selected by Buildroot at that time) [2].
Since then, several binutils release has been added and the binutils
version 2.38 has been removed recently [3].
Since the initial bug is gone with the removal of binutils 2.37,
we can safely remove the binutils version from qemu_ppc64 defconfigs.
[1] 1e2fe860f3
[2] e461c9adc8
[3] 1391c99d62
Fixes:
https://gitlab.com/buildroot.org/toolchains-builder/-/jobs/4798047373
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Cédric Le Goater <clg@kaod.org>
Cc: Joel Stanley <joel@jms.id.au>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
There is no such thing as a BR2_TARGET_GENERIC_TTY_PATH variable. The
comment here should mention BR2_TARGET_GENERIC_GETTY_PORT instead.
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The recent update to systemd v254 requires a toolchain w/ linux headers
>= 4.14 to provide LOOP_SET_BLOCK_SIZE [1] (added in systemd v253 [2]).
Note:
Buildroot already warn the user if a toolchain w/ linux headers < 4.15
is used while enabling systemd as init system [3]. It was matter of
time before problem occurs.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=89e4fdecb51cf5535867026274bc97de9480ade5
[2] 1163ddb386
[3] 9a095643b4
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
go1.20.7 (released 2023-08-01) includes a security fix to the crypto/tls
package, as well as bug fixes to the assembler and the compiler.
Fixes CVE-2023-29409: restrict RSA keys in certificates to <= 8192 bits
Extremely large RSA keys in certificate chains can cause a client/server to
expend significant CPU time verifying signatures. Limit this by restricting the
size of RSA keys transmitted during handshakes to <= 8192 bits.
Based on a survey of publicly trusted RSA keys, there are currently only three
certificates in circulation with keys larger than this, and all three appear to
be test certificates that are not actively deployed. It is possible there are
larger keys in use in private PKIs, but we target the web PKI, so causing
breakage here in the interests of increasing the default safety of users of
crypto/tls seems reasonable.
https://go.dev/doc/devel/release#go1.20.7
Signed-off-by: Christian Stewart <christian@aperture.us>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Since its introduction in 7d8a59b40, the BR2_x86_geode CPU target has
pointed to GCC -march=geode which targets AMD Geode processors [0].
This arch tuning enables MMX and 3DNow! extensions in GCC but these are
not currently reflected in the selected flags by BR2_x86_geode.
This is likely due to the confusing naming and history of "Geode".
The AMD Geode can trace its origins back to the Cyrix MediaGXm [1] and
then to the NSC Geode GXm/GXLV/GX1/GX2 [2]. All of these processors have
MMX instruction support listed in their datasheets. The NSC GX2 was the
first in the series to enable 3DNow!.
When 7fed07d3a4 introduced BR2_X86_CPU_HAS_MMX, Geode was skipped
presumably because it wasn't clear that the target is AMD Geode and
because the Wikipedia documentation for Geode is incomplete [2] with
regards to supported instructions as they all support MMX.
When f6cd56b9ce introduced BR2_X86_CPU_HAS_3DNOW, Geode was skipped
presumably for similar reasons.
Note: the in-tree olpc_xo1_defconfig uses BR2_x86_geode which is fine
as this hardware uses the AMD Geode [3].
Make it more clear that the target is AMD Geode by renaming the Kconfig
menu option and add both MMX and 3DNow! flags to BR2_x86_geode.
This also means that BR2_x86_geode_mmx is no longer needed, and can be
removed. No legacy handling is needed since BR2_x86_geode_mmx has
never been part of any release.
[0]: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/geode.md;;hb=HEAD
[1]: https://en.wikipedia.org/wiki/MediaGX#MediaGXm
[2]: https://en.wikipedia.org/wiki/Geode_%28processor%29
[3]: https://wiki.laptop.org/go/Hardware_specification
Signed-off-by: Vincent Fazio <vfazio@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Now that 2.41.x has been added, that 2.40.x is the default version,
drop support for 2.38.x.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Now that 2.41 has been released, let's use 2.40.x as the default
binutils version.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Release notes:
https://sourceware.org/pipermail/binutils/2023-July/128719.html
Copied patches from version 2.40.
Build-tested using these four defconfigs:
----------
BR2_arceb=y
----------
BR2_BINUTILS_VERSION_2_39_X=y
----------
(empty defconfig meaning binutils-2.40)
----------
BR2_BINUTILS_VERSION_2_41_X=y
----------
each using these commands:
$ make host-libiberty
$ make host-binutils
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
composer describes itself as a dependency manager for PHP, it is used
by projects such as CakePHP.
Signed-off-by: Nicolas Carrier <carrier.nicolas0@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Having a working PHP with the correct version, is mandatory for
executing some PHP tools, such as composer, when building packages.
Signed-off-by: Nicolas Carrier <carrier.nicolas0@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This is needed for the creation of an host-php package.
Signed-off-by: Nicolas Carrier <carrier.nicolas0@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
mhz is a tool to mathematically calculate the real running CPU frequency
and as such has proved as invaluable tool for developing CPUFreq and
similar features in the kernel.
Its source finally got a license recently so it can be packaged.
Signed-off-by: Robert Marko <robimarko@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
