This commit backports an upstream patch fixing CVE-2024-10963. See:
https://github.com/linux-pam/linux-pam/issues/834https://github.com/linux-pam/linux-pam/pull/854
Fixes:
- CVE-2024-10963:
Pam: improper hostname interpretation in pam_access leads to access
control bypass
A flaw was found in pam_access, where certain rules in its
configuration file are mistakenly treated as hostnames. This
vulnerability allows attackers to trick the system by pretending
to be a trusted hostname, gaining unauthorized access. This issue
poses a risk for systems that rely on this feature to control who
can access certain services or terminals.
https://www.cve.org/CVERecord?id=CVE-2024-10963
Signed-off-by: Raphael Pavlidis <raphael.pavlidis@gmail.com>
[Julien:
- fix check-package errors
- add info in commit log
- rebase patch on v1.6.1 to avoid patch offsets
- add "CVE:" tag in patch
- add comment with patch name near _IGNORE_CVES in .mk
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit b95ffe208b)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Please note that the fix for CVE-2024-52615 introduces CVE-2025-59529
which is not fixed yet (https://github.com/avahi/avahi/pull/808). You
can mitigate this vulnerability by setting the `enable-wide-area=no`
option.
Patch `0011-properly-randomize-query-id-of-DNS-packets.patch` modify
`configure.ac` and then `AVAHI_AUTORECONF` is set.
This commit fixes the following vulnerabilities:
- CVE-2021-3468:
A flaw was found in avahi in versions 0.6 up to 0.8. The event used to
signal the termination of the client connection on the avahi Unix
socket is not correctly handled in the client_work function, allowing
a local attacker to trigger an infinite loop. The highest threat from
this vulnerability is to the availability of the avahi service, which
becomes unresponsive after this flaw is triggered.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2021-3468
- 447affe299
- CVE-2023-38469:
A vulnerability was found in Avahi, where a reachable assertion exists
in avahi_dns_packet_append_record.
https://www.cve.org/CVERecord?id=CVE-2023-38469
- CVE-2023-38470:
A vulnerability was found in Avahi. A reachable assertion exists in
the avahi_escape_label() function.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2023-38470
- a337a1ba7d
- CVE-2023-38471:
A vulnerability was found in Avahi. A reachable assertion exists in
the dbus_set_host_name function.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2023-38471
- github.com/avahi/avahi/commit/894f085f402e023a98cbb6f5a3d117bd88d93b09
- CVE-2023-38472:
A vulnerability was found in Avahi. A reachable assertion exists in
the avahi_rdata_parse() function.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2023-38472
- b024ae5749
- CVE-2023-38473:
A vulnerability was found in Avahi. A reachable assertion exists in
the avahi_alternative_host_name() function.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2023-38473
- b448c9f771
- CVE-2024-52615:
A flaw was found in Avahi-daemon, which relies on fixed source ports
for wide-area DNS queries. This issue simplifies attacks where
malicious DNS responses are injected.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2024-52615
- 4e2e1ea090
- https://github.com/avahi/avahi/issues/810 (introduce regression CVE-2025-59529)
- CVE-2024-52616:
A flaw was found in the Avahi-daemon, where it initializes DNS
transaction IDs randomly only once at startup, incrementing them
sequentially after that. This predictable behavior facilitates DNS
spoofing attacks, allowing attackers to guess transaction IDs.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2024-52616
- f8710bdc8b
- CVE-2025-68276:
Avahi is a system which facilitates service discovery on a local
network via the mDNS/DNS-SD protocol suite. In 0.9-rc2 and earlier, an
unprivileged local users can crash avahi-daemon (with wide-area
disabled) by creating record browsers with the
AVAHI_LOOKUP_USE_WIDE_AREA flag set via D-Bus. This can be done by
either calling the RecordBrowserNew method directly or creating
hostname/address/service resolvers/browsers that create those browsers
internally themselves.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2025-68276
- 2d48e42d44
- CVE-2025-68468:
Avahi is a system which facilitates service discovery on a local
network via the mDNS/DNS-SD protocol suite. In 0.9-rc2 and earlier,
avahi-daemon can be crashed by sending unsolicited announcements
containing CNAME resource records pointing it to resource records with
short TTLs. As soon as they expire avahi-daemon crashes.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2025-68468
- f66be13d7f
- CVE-2025-68471:
Avahi is a system which facilitates service discovery on a local
network via the mDNS/DNS-SD protocol suite. In 0.9-rc2 and earlier,
avahi-daemon can be crashed by sending 2 unsolicited announcements
with CNAME resource records 2 seconds apart.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2025-68471
- 9c6eb53bf2
- CVE-2026-24401:
Avahi is a system which facilitates service discovery on a local
network via the mDNS/DNS-SD protocol suite. In versions 0.9rc2 and
below, avahi-daemon can be crashed via a segmentation fault by sending
an unsolicited mDNS response containing a recursive CNAME record,
where the alias and canonical name point to the same domain (e.g.,
"h.local" as a CNAME for "h.local"). This causes unbounded recursion
in the lookup_handle_cname function, leading to stack exhaustion. The
vulnerability affects record browsers where AVAHI_LOOKUP_USE_MULTICAST
is set explicitly, which includes record browsers created by resolvers
used by nss-mdns. This issue is patched in commit
78eab31128479f06e30beb8c1cbf99dd921e2524.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2026-24401
- 78eab31128
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit e728d3506b)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The CPIO filesystem generated by the test_firewalld test is too
large, and doesn't fit as an initramfs in the 256MB of RAM available
in the versatilepb machine. This causes a "Initramfs unpacking failed:
write error" when booting, and many files being missing from the root
filesystem, ultimately causing the test to fail.
The test_firewalld test initially started to fail following a systemd
update [1][3]:
[BRTEST# systemctl is-active firewalld
failed
But really started to crash at boot following a python 3.14 update
[2][4]:
Run /init as init process
/init: exec: line 15: /sbin/init: not found
Also, update TestFirewalldSysVInit to use ext2 instead of cpio.
[1] 926e0504d0
[2] a0a6abc8b1
Fixes:
[3] https://gitlab.com/buildroot.org/buildroot/-/jobs/12944797059
[4] https://gitlab.com/buildroot.org/buildroot/-/jobs/11856840940
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 6a7fe6382a)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
See the release notes:
https://docs.djangoproject.com/en/5.2/releases/5.2.11/
This is a security release on Django's LTS branch,
fixing the following vulnerabilties:
- CVE-2025-13473:
An issue was discovered in 6.0 before 6.0.2, 5.2 before 5.2.11, and
4.2 before 4.2.28. The
`django.contrib.auth.handlers.modwsgi.check_password()` function for
authentication via `mod_wsgi` allows remote attackers to enumerate
users via a timing attack. Earlier, unsupported Django series (such as
5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected.
Django would like to thank Stackered for reporting this issue.
https://www.cve.org/CVERecord?id=CVE-2025-13473
- CVE-2025-14550:
An issue was discovered in 6.0 before 6.0.2, 5.2 before 5.2.11, and
4.2 before 4.2.28. `ASGIRequest` allows a remote attacker to cause a
potential denial-of-service via a crafted request with multiple
duplicate headers. Earlier, unsupported Django series (such as 5.0.x,
4.1.x, and 3.2.x) were not evaluated and may also be affected. Django
would like to thank Jiyong Yang for reporting this issue.
https://www.cve.org/CVERecord?id=CVE-2025-14550
- CVE-2026-1207:
An issue was discovered in 6.0 before 6.0.2, 5.2 before 5.2.11, and
4.2 before 4.2.28. Raster lookups on ``RasterField`` (only implemented
on PostGIS) allows remote attackers to inject SQL via the band index
parameter. Earlier, unsupported Django series (such as 5.0.x, 4.1.x,
and 3.2.x) were not evaluated and may also be affected. Django would
like to thank Tarek Nakkouch for reporting this issue.
https://www.cve.org/CVERecord?id=CVE-2026-1207
- CVE-2026-1285:
An issue was discovered in 6.0 before 6.0.2, 5.2 before 5.2.11, and
4.2 before 4.2.28. `django.utils.text.Truncator.chars()` and
`Truncator.words()` methods (with `html=True`) and the
`truncatechars_html` and `truncatewords_html` template filters allow a
remote attacker to cause a potential denial-of-service via crafted
inputs containing a large number of unmatched HTML end tags. Earlier,
unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not
evaluated and may also be affected. Django would like to thank
Seokchan Yoon for reporting this issue.
https://www.cve.org/CVERecord?id=CVE-2026-1285
- CVE-2026-1287:
An issue was discovered in 6.0 before 6.0.2, 5.2 before 5.2.11, and
4.2 before 4.2.28. `FilteredRelation` is subject to SQL injection in
column aliases via control characters, using a suitably crafted
dictionary, with dictionary expansion, as the `**kwargs` passed to
`QuerySet` methods `annotate()`, `aggregate()`, `extra()`, `values()`,
`values_list()`, and `alias()`. Earlier, unsupported Django series
(such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be
affected. Django would like to thank Solomon Kebede for reporting this
issue.
https://www.cve.org/CVERecord?id=CVE-2026-1287
- CVE-2026-1312:
An issue was discovered in 6.0 before 6.0.2, 5.2 before 5.2.11, and
4.2 before 4.2.28. `.QuerySet.order_by()` is subject to SQL injection
in column aliases containing periods when the same alias is, using a
suitably crafted dictionary, with dictionary expansion, used in
`FilteredRelation`. Earlier, unsupported Django series (such as 5.0.x,
4.1.x, and 3.2.x) were not evaluated and may also be affected. Django
would like to thank Solomon Kebede for reporting this issue.
https://www.cve.org/CVERecord?id=CVE-2026-1312
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
[thomas: update hash for inlines.js]
(cherry picked from commit f8e89786f9)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Fixes the following security vulnerabilities:
CVE-2026-1584: libgnutls: Fix NULL pointer dereference in PSK binder
verification
A TLS 1.3 resumption attempt with an invalid PSK binder value in ClientHello
could lead to a denial of service attack via crashing the server.
The updated code guards against the problematic dereference.
CVE-2025-14831: libgnutls: Fix name constraint processing performance issue
Verifying certificates with pathological amounts of name constraints
could lead to a denial of service attack via resource exhaustion.
Reworked processing algorithms exhibit better performance characteristics.
For more details, see the release notes:
https://lists.gnupg.org/pipermail/gnutls-help/2026-February/004914.html
Drop now upstreamed 0001-audit-crau-fix-compilation-with-gcc-11.patch:
f5666f8f1f
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit e91cf0ae73)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Fixes the following vulnerabilities:
CVE-2025-61732: cmd/cgo: remove user-content from doc strings in cgo ASTs
A discrepancy between how Go and C/C++ comments were parsed allowed for code
smuggling into the resulting cgo binary.
To prevent this behavior, the cgo compiler will no longer parse
user-provided doc comments.
CVE-2025-68121: crypto/tls: unexpected session resumption when using
Config.GetConfigForClient
Config.GetConfigForClient is documented to use the original Config's session
ticket keys unless explicitly overridden. This can cause unexpected
behavior if the returned Config modifies authentication parameters, like
ClientCAs: a connection initially established with the parent (or a sibling)
Config can be resumed, bypassing the modified authentication requirements.
If ClientAuth is VerifyClientCertIfGiven or RequireAndVerifyClientCert (on
the server) or InsecureSkipVerify is false (on the client), crypto/tls now
checks that the root of the previously-verified chain is still in
ClientCAs/RootCAs when resuming a connection.
Go 1.26 Release Candidate 2, Go 1.25.6, and Go 1.24.12 had fixed a similar
issue related to session ticket keys being implicitly shared by
Config.Clone. Since this fix is broader, the Config.Clone behavior change
has been reverted.
Note that VerifyPeerCertificate still behaves as documented: it does not
apply to resumed connections. Applications that use
Config.GetConfigForClient or Config.Clone and do not wish to blindly resume
connections established with the original Config must use VerifyConnection
instead (or SetSessionTicketKeys or SessionTicketsDisabled).
For more details, see the announcement:
https://groups.google.com/g/golang-announce/c/K09ubi9FQFk
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit f56dc6b122)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
This release fixes the following security related issues:
* gh-144125: BytesGenerator will now refuse to serialize (write) headers that
are unsafely folded or delimited; see verify_generated_headers.
* gh-143935: Fixed a bug in the folding of comments when flattening an
email message using a modern email policy. Comments consisting of a
very long sequence of non-foldable characters could trigger a forced
line wrap that omitted the required leading space on the continuation
line, causing the remainder of the comment to be interpreted as a new
header field. This enabled header injection with carefully crafted
inputs.
* gh-143925: Reject control characters in data: URL media types.
* gh-143919: Reject control characters in http.cookies.Morsel fields and values.
* gh-143916: Reject C0 control characters within wsgiref.headers.Headers
fields, values, and parameters.
Full release notes:
https://docs.python.org/release/3.13.12/whatsnew/changelog.html
Signed-off-by: Marcus Hoffmann <buildroot@bubu1.eu>
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Use of threading requires a C++20 compiler, and the oneTBB
implementation. oneTBB is missing from Buildroot, but a system
one may be used if found.
Even if the default for threading is disabled, explicitly state so,
in case the default changes in the future.
Also disable examples, we don't and won't need them.
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Heiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 830726905a)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Ensure that the SHA_CRYPT option is enabled when the system configuration is
set to SHA256/512, as otherwise passwd complains when a password is changed:
passwd
...
Invalid ENCRYPT_METHOD value: 'SHA512'.
Defaulting to DES.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 7e72901eef)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
As described in https://gitlab.com/buildroot.org/buildroot/-/issues/160, the
github mirror is getting shut down - So move to the sourceware.org git repo.
The github mirror was originally used because of performance and reliability
issues with sourceware, but that seems be resolved now after server/RAM
upgrades - E.G. from the sourceware news:
April 22, 2024
server2.sourceware.org now has 512GB RAM, thanks Red Hat.
https://sourceware.org/
So change back to fetch glibc (and localedef) from sourceware.org over git.
Notice: The git archiving leads to slightly different paths and permissions
in the tarball, but the file content is identical:
mkdir a && tar -C a -x --strip-components=1 -f \
path/to/glibc-2.42-51-gcbf39c26b25801e9bc88499b4fd361ac172d4125.tar.gz
mkdir b && tar -C b -x --strip-components=1 -f \
path/to/glibc-2.42-51-gcbf39c26b25801e9bc88499b4fd361ac172d4125-git4.tar.gz
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
[Julien:
- add missing SoB line
- fix command lines in commit log
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 807b0bab37)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Swig has a compiled in absolute path to its data files, which can be
overridden using the SWIG_LIB environment variable:
https://github.com/swig/swig/blob/v4.1.1/Source/Modules/main.cxx#L931-L945
This unfortunately means that host-swig misbehaves when used in the SDK, as
this points to the ${HOST_DIR}/bin of the build, which may not be available
when the SDK is used.
The issue was reported upstream but rejected in
https://github.com/swig/swig/issues/253, so instead add a wrapper script
which calculates a sensible SWIG_LIB relative to the wrapper location unless
SWIG_LIB is set, similar to how we do it for E.G. gcc or pkgconf.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
[Peter: add quotes to make shellcheck happy]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 20d5e36fe8)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Commit [1] introduced a patch to fix CVE-2025-62291. Since [2] the
security patches neeed to reference the vulnerability with the `CVE: `
trailer in the patch header.
[1] b009935e27 package/strongswan: add patch to fix CVE-2025-62291
[2] 1167d0ff3d docs/manual: mention CVE trailer
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Marcus Hoffmann <buildroot@bubu1.eu>
(cherry picked from commit 766a6e5c0b)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
On Buildroot 2025.05.3, Meson's custom LLVM parser uses llvm-config
with a default search path of /usr/bin, causing it to detect the host
system's llvm-config (version 18.1.3) instead of the buildroot-compiled
one. This forces all LLVM-related packages to match version 18.1.3, but
since the host system lacks llvmspirvlib, the build fails. This patch
forces Meson to use the buildroot-compiled llvm-config.
On the master branch, the meson is somehow able to find the right
llvm-config, so reproduction only seems to be possible if the host
machine ships with a newer version as the one buildroot is using.
llvm-config found: YES
([...]/output/host/bin/llvm-config)
21.1.8
Run-time dependency LLVM (modules: bitwriter, core, coverage, engine,
executionengine, instcombine, irreader, libdriver, linker, lto,
mcdisassembler, mcjit, native, option, scalaropts, target,
transformutils, all-targets, coroutines, frontenddriver, frontendhlsl,
lto, windowsdriver) found: YES 21.1.8
Note that LLVM_CONFIG is a CMake option, not a Meson one. This is because
Meson has custom dependency resolution logic for LLVM (see
https://mesonbuild.com/Dependencies.html#llvm). The EXTRA_BINARIES mechanism
cannot be used here, as it only applies to cross-compilation scenarios, which
does not apply to host-mesa3d builds.
Reproduction (On BR2 tag: 2025.05.3):
BR2_x86_64=y
BR2_x86_atom=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_X86_64_GLIBC_STABLE=y
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="6.1.24"
BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/pc/linux.config"
BR2_LINUX_KERNEL_INSTALL_TARGET=y
BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL=y
BR2_LINUX_KERNEL_NEEDS_HOST_LIBELF=y
BR2_PACKAGE_MESA3D=y
BR2_PACKAGE_MESA3D_LLVM=y
BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_I915=y
BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_IRIS=y
BR2_PACKAGE_MESA3D_OPENGL_EGL=y
BR2_PACKAGE_MESA3D_OPENGL_ES=y
Fixes:
llvm-config found: YES (/usr/bin/llvm-config-18) 18.1.3
Run-time dependency LLVM (modules: bitwriter, core, coverage, engine, executionengine, instcombine, irreader, libdriver, linker, lto, mcdisassembler, mcjit, native, option, scalaropts, target, transformutils, all-targets, coroutines, frontenddriver, frontendhlsl, lto, windowsdriver) found: YES 18.1.3
Dependency LLVMSPIRVLib found: NO. Found 15.0.0.0 but need: '>= 18.1' ; matched: '>= 15.0.0.0', '< 18.2'
Run-time dependency llvmspirvlib found: NO (tried cmake)
output/build/host-mesa3d-25.0.6/meson.build:1882:21: ERROR: Dependency lookup for LLVMSPIRVLib with method 'pkgconfig' failed: Invalid version, need 'LLVMSPIRVLib' ['>= 18.1'] found '15.0.0.0'.
Signed-off-by: Thomas Devoogdt <thomas.devoogdt@barco.com>
[Romain:
- Update the commit title
- Update commit log about this issue on master branch
https://lore.kernel.org/buildroot/CACXRmJh1-5Cy92kF9TM5nDs_uB90WAe5iOGmNNL2E-cMhJE7GA@mail.gmail.com/
]
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit eb0e63888b)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The old URL now leads to an HTTP 404 not found error.
Update it to the new one which contains the hashes for the current
release as well as older ones.
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit 6fed872e08)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The current 'install' target comprises 'install-libs', 'install-apps'
and 'install-docs'.
In our case we don't want to install documentation to the target, so
just run the other two.
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit ba48197d1f)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
When BR2_UCLIBC_INSTALL_UTILS is enabled, utils such as getconf, ldd,
locale get installed to TARGET_DIR. However, they do not get installed
to STAGING_DIR, which is annoying as it means that they are not part
of external toolchains built by Buildroot.
This commit adjusts the uclibc package to make sure those tools also
get installed to STAGING_DIR.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 272d281ba9)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The UCLIBC_INSTALL_UTILS_STAGING is really badly named, as it doesn't
install anything to STAGING_DIR. Instead, it installs the host variant
of ldd and ldconfig into $(HOST_DIR)/bin. Therefore, rename it to
UCLIBC_INSTALL_HOST_UTILS.
This is important as a follow-up commit will re-introduce a
UCLIBC_INSTALL_UTILS_STAGING variable which really installs things
into STAGING_DIR.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 026c635508)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Upstream is dead, website unreachable, and the use case in 2026 is
dubious, so drop the package.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 95519e0464)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Although it is possible to configure an AArch64 CPU without support
for EL2 in practice all the common AArch64 have supported
virtualisation from the start.
If we really wanted to be strict we could blacklist known non-EL2 CPUs
but AFAICT all the current ones in the config have EL2.
I should also note KVM on Arm is deprecated and was removed from the
kernel in v6.10.
Reviewed-by: Jesse Taube <jesse@rivosinc.com>
Reviewed-by: Thomas Huth <huth@tuxfamily.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 137d6e249d)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The .mk file currently states:
If LWS_MAX_SMP=1, then there is no code related to pthreads
compiled in the library. If unset, LWS_MAX_SMP defaults to 32 and a
small amount of pthread mutex code is built into the library.
However, this is incorrect: when unset, LWS_MAX_SMP is actually set to
1, so mutexes aren't built in.
To fix, set it to 32 explicitly when threads are enabled. Why 32?
Because
https://libwebsockets.org/lws-api-doc-master/html/md_README.coding.html
states:
You can control the context basic data allocation for
multithreading from Cmake using -DLWS_MAX_SMP=, if not given it's
set to 32.
Signed-off-by: Bart Van Severen <bart.vanseveren@barco.com>
Signed-off-by: Thomas Devoogdt <thomas.devoogdt@barco.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit b3abf16c8e)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
When given a certificate directory with --with-ca-path, curl doesn't
list the files in that directory. Instead, it uses the certificate hash
to directly open the requested CA certificate. Therefore, putting a
bundle in that directory and removing all the individual certificates is
not possible.
In order to support use of the bundle, a separate configuration option
--with-ca-bundle is needed. With this option, it is possible to remove
the individual certificates and include just the bundle, which reduces
the size of the root filesystem a bit.
Note that the bundle is generated by the ca-certificates package, which
also installs the individual certificates and the hash symlinks. It
keeps both individual certificates and the bundle in the target.
Signed-off-by: Lance Fredrickson <lancethepants@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
(cherry picked from commit 5a63ee3c09)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Unfortunately, parts of the library is not very no-MMU friendly atm.
The below check fails due to runbg.c requiring fork().
$ ./utils/test-pkg -c libite.config -p libite
bootlin-armv5-uclibc [1/6]: OK
bootlin-armv7-glibc [2/6]: OK
bootlin-armv7m-uclibc [3/6]: FAILED
bootlin-x86-64-musl [4/6]: OK
br-arm-full-static [5/6]: OK
arm-aarch64 [6/6]: OK
The dependency was introduced in libite v2.6.0, so this patch should
be backported to v2025.02.x.
Fixes:
https://autobuild.buildroot.net/results/6c6fd2ae410a82c44da54ee13a09a38a7ab220c1/
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit e0b129e36e)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
This commit adds the -N/--needs-update option, disabled by default,
to list only packages with newer upstream versions. All other packages
will be excluded from the HTML or JSON output.
Signed-off-by: Kadambini Nema <kadambini.nema@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
(cherry picked from commit ed9466e7f9)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Currently, the relocate-sdk.sh script scans the whole extracted SDK tree
to find instances of paths it needs to replace, which can take a
significant amount of time when the SDK is large, particularly relative
to the number of files that actually need to change.
However, the resulting list only depends on the SDK tarball itself, so
we can calculate it at build time and ship it with the tarball so
relocate-sdk.sh can use it directly.
Testing this on my machine with somewhat IOPS-limited rotating media,
the time goes down from:
$ time ./relocate-sdk.sh
Relocating the buildroot SDK from [...] to [...] ...
./relocate-sdk.sh 5.19s user 26.21s system 9% cpu 5:34.40 total
To:
$ time ./relocate-sdk.sh
Relocating the buildroot SDK from [...] to [...] ...
./relocate-sdk.sh 0.49s user 0.29s system 103% cpu 0.749 total
Signed-off-by: Florian Larysch <fl@n621.de>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
(cherry picked from commit 63877f9e86)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
