Buildroot commit f89ca996b6 fixed the
build of linux-pam with musl in 2020 but did not remove the restric-
tions in place for login/runuser/su which were added earlier with
these commits:
login (2015): 25ecd24579
runuser (2017): 09860f354a
su (2017): c6488923fb
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
(cherry picked from commit 91d356ee7e)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
TestIptables expect netfilter legacy tables enabled in the kernel.
Make sure we use iptables-legacy:
iptables --version
iptables v1.8.11 (legacy)
The test would fail if nftables compat (iptables-nft) is enabled.
iptables --version
iptables v1.8.11 (nf_tables)
Add the following configuration fragment to enable iptables-nft:
BR2_PACKAGE_IPTABLES_NFTABLES=y
BR2_PACKAGE_IPTABLES_NFTABLES_DEFAULT=y
Acked-by: Fiona Klute <fiona.klute@gmx.de>
Tested-by: Fiona Klute <fiona.klute@gmx.de>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
(cherry picked from commit 1b2f65bbe9)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Since kernels 6.17, support for netfilter legacy tables were disabled
by default [1] but iptables package needs Netfilter legacy tables
support enabled in the kernel when nftables compat is not enabled.
Make sure to enable CONFIG_IP_NF_IPTABLES_LEGACY and
CONFIG_NETFILTER_XTABLES_LEGACY for kernels >= 6.17.
Fixes:
[BRTEST# iptables --flush
modprobe: module ip_tables not found in modules.dep
iptables v1.8.11 (legacy): can't initialize iptables table `filter': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
On the other hand, when nftables compat (iptables-nft) is used by
default (BR2_PACKAGE_IPTABLES_NFTABLES_DEFAULT=y) we have to enable
nft protocol support in the kernel.
iptables --version
iptables: Failed to initialize nft: Protocol not supported
Enable CONFIG_NF_TABLES and CONFIG_NF_TABLES_INET as for
NFTABLES_LINUX_CONFIG_FIXUPS and complete the list with
CONFIG_NFT_SOCKET needed to pass the TestIptables with
nftables compat (iptables-nft) enabled.
Without CONFIG_NFT_SOCKET:
iptables --policy INPUT ACCEPT
iptables v1.8.11 (nf_tables): TABLE_ADD failed (Operation not supported): table filter
So, enable kernel support for iptables-legacy only if nftables compat
is not enabled by default. Enable iptables-nft support when nftables
compat is enabled, even if not used by default.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9fce66583f06c212e95e4b76dd61d8432ffa56b6
Signed-off-by: Romain Naour <romain.naour@smile.fr>
[Fiona: fix typo in commit message]
Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
(cherry picked from commit c57bcf0d43)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
With an older cmake version, like the 3.25.1 as available in the docker
reference image, mosquitto fails to build when ccache is enabled:
[ 98%] Building CXX object lib/cpp/CMakeFiles/mosquittopp.dir/mosquittopp.cpp.o
In file included from [...]/buildroot/output/build/mosquitto-2.1.2/lib/cpp/mosquittopp.cpp:17:
[...]/buildroot/output/host/opt/ext-toolchain/i686-buildroot-linux-gnu/include/c++/15.1.0/cstdlib:83:15: fatal error: stdlib.h: No such file or directory
83 | #include_next <stdlib.h>
| ^~~~~~~~~~
compilation terminated.
Officially, mosquitto only requires cmake 3.18, but that proves to not
be enough, in fact...
We workaround that by requiring cmake 4.3, which is the one version that
could be tested with our host-cmake.
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit da9dcddff1)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Libepoxy is a library for handling OpenGL function pointer management.
It has backends for egl/glx, which may at one point have been mandatory
to enable, but the library now builds with none of the above enabled
features, as seen below.
libepoxy 1.5.10
User defined options
Cross files : /home/joseph/br-test-pkg/arm-aarch64/build/libepoxy-1.5.10//buildroot-build/cross-compilation.conf
b_pie : false
b_staticpic : true
buildtype : release
build.cmake_prefix_path: /home/joseph/br-test-pkg/arm-aarch64/host/lib/cmake
default_library : shared
docs : false
egl : no
glx : no
libdir : lib
build.pkg_config_path : /home/joseph/br-test-pkg/arm-aarch64/host/lib/pkgconfig
prefix : /usr
strip : false
tests : false
x11 : false
Removing these dependencies allows for some applications that require it
as a build dependency, but otherwise can run headless or without GL, to
build and function, using other graphics APIs or display pipelines.
Weston, for example, can still use Vulkan and DRM when linked to
libepoxy without GL/EGL/X11 support.
Acked-by: Arnout Vanecappelle <arnout@rnout.be>
Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit cd2583ca0a)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Upstream passt only documents runtime dependencies; and they advertise
being able to run on kernel 3.8 or later. However, they do not document
the build dependencies.
Since 2025_06_11.0293c6f, upstream requires kernel headers >= 5.9, as
they make use of linux/close_range.h, only introduced in 5.9.
Add a dependency to kernel headers, and propagate it to podman's passt
backend.
Fixes: 6a192b0d28
Cc: Yann E. MORIN <yann.morin@orange.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 113def3696)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Commit e8c54ffb3d ("utils/generate-cyclonedx: generate vcs
externalReferences for source repos") added externalReferences to the source
code of packages.
This unfortunately causes issues with packages (in br2-external) fetching
from git using the scp-like syntax, E.G.:
FOO_SITE_METHOD = git
FOO_SITE = git@github.com:<project>/<repo>.git
Which ends up in the SBOM as:
[
{
"type": "vcs",
"url": "git@github.com:<project>/<repo>.git",
"comment": "git repository"
}
]
This (correctly) causes Dependency track to reject the SBOM import with:
{
"status": 400,
"title": "The uploaded BOM is invalid",
"detail": "Schema validation failed",
"errors": [
"$.components[2].externalReferences[0].url: does not match the iri-reference pattern must be a valid RFC 3987 IRI-reference",
"$.components[2].externalReferences[0].url: does not match the iri-reference pattern must be a valid RFC 3987 IRI-reference",
"$.components[2].externalReferences[0].url: does not match the regex pattern ^urn:cdx:[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}/[1-9][0-9]*$",
]
}
The CycloneDX spec indeed requires a URI:
The URI (URL or URN) to the external reference. External references are
URIs and therefore can accept any URL scheme including https (RFC-7230),
mailto (RFC-2368), tel (RFC-3966), and dns (RFC-4501)
https://cyclonedx.org/docs/1.6/json/#metadata_tools_oneOf_i0_components_items_externalReferences_items_url
The user@host:project/repo.git is a git-specific shorthand for a git-over-ssh URL. From man git-clone:
Git supports ssh, git, http, and https protocols (in addition, ftp and ftps
can be used for fetching, but this is inefficient and deprecated; do not use
them).
The native transport (i.e. git:// URL) does no authentication and should
be used with caution on unsecured networks.
The following syntaxes may be used with them:
• ssh://[user@]host.xz[:port]/path/to/repo.git/
• git://host.xz[:port]/path/to/repo.git/
• http[s]://host.xz[:port]/path/to/repo.git/
• ftp[s]://host.xz[:port]/path/to/repo.git/
An alternative scp-like syntax may also be used with the ssh protocol:
• [user@]host.xz:path/to/repo.git/
So convert the scp-like syntax to ssh:// URLs in parse_uris() for spec
compliance.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Acked-By: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit ebcfdb8b0a)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
