Now that gdb 13.x has been added, and 12.x made the default, follow
our usual logic of dropping the oldest gdb version: 10.x.
Only the special ARC release still needs some special handling of the
GMP dependency.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
We can remove the quirk around BR2_or1k: it was there to make sure
that 11.x was the default when no target gdb is selected for all
architectures except or1k, and that 12.x would be used by default on
or1k, as 11.x is not available/broken.
Now that 12.x is the default for everybody, this quirk is no longer
needed. 11.x was already no selectable for or1k, and remains not
selectable.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Sadly, the stack of patches remain exactly the same, none of the
changes have been upstreamed.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Like git which can have submodules, subversion can have externals. The
default behaviour for subversion is to retrieve all the externals,
unless told otherwise.
For some repositories, the externals may be huge (e.g. a dataset or some
assets) and may not be required for building the package. In such a
case, retrieving the externals is both a waste of network bandwitdh and
time, and a waste of disk storage.
Like for git submodules and git lfs, add an option that packages can set
to specify whether they want externals or not.
Since we've so far been retrieving externals, we keep that the default,
and packages can opt-out (rather than the opt-in for git submodules or
git lfs).
We must only set it when the package is actually hosted on svn, to avoid
passing -r when the package is not hosted by svn; otherwise, -r would
also be passed e.g. to a git-hosted package, triggering the download of
git submodules even when they are not requested. We need to do so,
because we have a default value, which we usually do not have in other
download options.
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
When an svn repository requires credentials, and they are passed
in _DL_OPTS, they must be used also to retrieve the revision date.
One could argue that credentials should not be handled in _DL_OPTS, but
rather that they be fed through other means (e.g. by pre-authenticating
manually once in an interactive session, or by filling them in the usual
~/svn/auth/* mechanisms for a CI).
However, some public facing repositories are using authentication, even
though the credentials are public. This is the case for example for:
http://software.rtcm-ntrip.org/
In such a case, it does make sense to pass credentials via _DL_OPTS,
because they are not really, even really not, secret.
Another use-case (e.g. for a CI) is to pass the credentials as
environment variables, with _DL_OPTS not hard-coded in the .mk file.
However, _DL_OPTS may contain options that are not valid for 'svn info',
as they are meant to be passed to 'svn export' in the first place. Since
the only options common to 'svn info' and 'svn export' are the
credentials, we just extract those and pass them to 'svn info'.
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Bizarrely enough, the unquoted expansion of ${quiet} does not trigger
any warning from shellcheck, so we do not add any exception for it.
${SVN} can contain more than one item, but we don't care about splitting
on spaces when we just print it for debug, so we can just quote it
rather than add an exception.
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
uClibc now provides fexecve(), so crun can build just fine with
uClibc. However, argp-standalone is needed, just like it was needed
for musl.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Christian Stewart <christian@aperture.us>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Support added in 2.33.2:
https://wpewebkit.org/release/wpewebkit-2.33.2.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>
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>
