From: Thomas Petazzoni via buildroot <buildroot@buildroot.org>
To: "Alexis Lothoré" <alexis.lothore@bootlin.com>
Cc: <tim.hammer@nav-timing.safrangroup.com>,
<nicolas.carrier@nav-timing.safrangroup.com>,
<buildroot@buildroot.org>
Subject: Re: [Buildroot] [PATCH 3/4] package/openscap: add openscap package
Date: Thu, 31 Jul 2025 14:48:52 +0200 [thread overview]
Message-ID: <20250731144852.25bb9e9e@windsurf> (raw)
In-Reply-To: <DBQ8SCGP37TS.2V8HRWA7RWPTW@bootlin.com>
On Thu, 31 Jul 2025 14:34:01 +0200
Alexis Lothoré <alexis.lothore@bootlin.com> wrote:
> it looks like gcrypt/nss is not mandatory. But if I try to configure and
> run a build in an environment without libgcrypt, I got same late linkage
> error, about some missing crapi_init (no, I am not making this function's
> name up...) being missing. It appears that there are code paths
> preprocessed conditionnaly on either libgcrypt or nss presence, without any
> fallback if none is found. I am not sure if I am facing some optional
> dependencies that are not "optional enough" in the code base, or some hard
> dpendencies that are not sufficiently enforced in the cmake files. But in
> the project current state, the software does not build without libgcrypt.
>
> If I take a further look at the dev doc
> (https://github.com/OpenSCAP/openscap/blob/main/docs/developer/developer.adoc),
> it seems to hint that libgcrypt is actually needed in any case.
That's fine, we don't expect you to fix all upstream issues :)
However, my concern was not so much about gcrypt being needed, but the
fact that you need openssl *and* libgcrypt. Are both truly needed?
> I'll remove the WITH_CRYPTO=gcrypt though, as it is the default value in
> CMakeLists.txt.
Well, you can keep it explicit, I think it's a good idea.
>
> > - You're setting ENABLE_PYTHON3=ON, but your target package does not
> > depend on host-python3 nor python3 in terms of build dependency.
> > Could you clarify what this ENABLE_PYTHON3 option does?
>
> That's an omission on my side. This ENABLE_PYTHON3 allows building some
> bindings (to write some python automation tools based on openscap ?) if the
> interpreter is found. I'll remove it.
Then ENABLE_PYTHON3=OFF is probably better. Generally speaking the more
options are explicitly set, the better.
> > No explicit option to enable/disable ACL support?
>
> Unfortunately no, this is searched unconditionally:
OK!
Thomas
--
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
next prev parent reply other threads:[~2025-07-31 12:49 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-30 12:47 [Buildroot] [PATCH 0/4] package/compliance-as-code: introduce new package Alexis Lothoré via buildroot
2025-07-30 12:47 ` [Buildroot] [PATCH 1/4] package/libxmlsec1: Add libxmlsec1 used by openSCAP Alexis Lothoré via buildroot
2025-07-30 16:53 ` Thomas Petazzoni via buildroot
2025-07-30 17:18 ` Alexis Lothoré via buildroot
2025-07-30 12:47 ` [Buildroot] [PATCH 2/4] package/libcurl: Reapply "libcurl: add host variant" Alexis Lothoré via buildroot
2025-07-30 16:55 ` Thomas Petazzoni via buildroot
2025-07-30 12:47 ` [Buildroot] [PATCH 3/4] package/openscap: add openscap package Alexis Lothoré via buildroot
2025-07-30 17:02 ` Thomas Petazzoni via buildroot
2025-07-31 12:34 ` Alexis Lothoré via buildroot
2025-07-31 12:48 ` Thomas Petazzoni via buildroot [this message]
2025-07-31 13:14 ` Alexis Lothoré via buildroot
2025-07-31 14:39 ` Thomas Petazzoni via buildroot
2025-07-30 12:47 ` [Buildroot] [PATCH 4/4] package/compliance-as-code: add new package Alexis Lothoré via buildroot
2025-07-30 17:18 ` Thomas Petazzoni via buildroot
2025-07-30 18:09 ` Alexis Lothoré via buildroot
2025-07-30 19:29 ` Thomas Petazzoni via buildroot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250731144852.25bb9e9e@windsurf \
--to=buildroot@buildroot.org \
--cc=alexis.lothore@bootlin.com \
--cc=nicolas.carrier@nav-timing.safrangroup.com \
--cc=thomas.petazzoni@bootlin.com \
--cc=tim.hammer@nav-timing.safrangroup.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.