diff mbox series

ppp: make pam optional to avoid host contamination

Message ID 20241023173911.1411724-1-danismostlikely@gmail.com
State New
Headers show
Series ppp: make pam optional to avoid host contamination | expand

Commit Message

Dan McGregor Oct. 23, 2024, 5:39 p.m. UTC 
From: Dan McGregor <dan.mcgregor@usask.ca>

Without explicitly disabling pam in ppp, it will check the host for
pam headers. This leads to this QA error:

ERROR: ppp-2.5.1-r0 do_configure: QA Issue: This autoconf log
indicates errors, it looked at host include and/or library paths
while determining system capabilities.
Rerun configure task after fixing this. [configure-unsafe]

This is a somewhat difficult to hit, only my test machines that have
the pam dev package installed show it.

Fix this by adding a packageconfig for pam, with its default value
off, since enabling PAM is completely untested.

Signed-off-by: Dan McGregor <dan.mcgregor@usask.ca>
---
 meta/recipes-connectivity/ppp/ppp_2.5.1.bb | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

Comments

Ross Burton Oct. 24, 2024, 11 a.m. UTC | #1 
On 23 Oct 2024, at 18:39, Dan McGregor via lists.openembedded.org <danismostlikely=gmail.com@lists.openembedded.org> wrote:
> This is a somewhat difficult to hit, only my test machines that have
> the pam dev package installed show it.

That’s exactly the reproducer with host contaimination problems.

> +PACKAGECONFIG ??= ""
> +PACKAGECONFIG[pam] = "--with-pam=yes,--with-pam=no,libpam”

We have a ‘pam’ DISTRO_FEATURE, should we just respect that as the default PACKAGECONFIG using bb.utils.filter?

Ross
Alexander Kanavin Oct. 24, 2024, 11:14 a.m. UTC | #2 
On Thu, 24 Oct 2024 at 13:01, Ross Burton via lists.openembedded.org
<ross.burton=arm.com@lists.openembedded.org> wrote:
> > +PACKAGECONFIG ??= ""
> > +PACKAGECONFIG[pam] = "--with-pam=yes,--with-pam=no,libpam”
>
> We have a ‘pam’ DISTRO_FEATURE, should we just respect that as the default PACKAGECONFIG using bb.utils.filter?

Only if the host contamination is tracked down and solved? Otherwise
this should not be an option, but rather a hard disable with a comment
on how to reproduce.

Alex
Ross Burton Oct. 24, 2024, 11:20 a.m. UTC | #3 
> On 24 Oct 2024, at 12:14, Alexander Kanavin <alex.kanavin@gmail.com> wrote:
> 
> On Thu, 24 Oct 2024 at 13:01, Ross Burton via lists.openembedded.org
> <ross.burton=arm.com@lists.openembedded.org> wrote:
>>> +PACKAGECONFIG ??= ""
>>> +PACKAGECONFIG[pam] = "--with-pam=yes,--with-pam=no,libpam”
>> 
>> We have a ‘pam’ DISTRO_FEATURE, should we just respect that as the default PACKAGECONFIG using bb.utils.filter?
> 
> Only if the host contamination is tracked down and solved? Otherwise
> this should not be an option, but rather a hard disable with a comment
> on how to reproduce.

Well, if there’s no pam in distro features then it is explicitly turned off, and if there is pam in distro features then we have a libpam in DEPENDS.

The failure path is in https://github.com/ppp-project/ppp/blob/master/m4/ax_check_pam.m4, yet again autoconf-archive has some pretty terrible logic.  It looks like if it can find libpam with pkg-config then it won’t try and hunt around /usr, which is where the contamination comes from.

As long as we either explicitly disable or enable-with-DEPENDS, there is no contamination.

Ross
diff mbox series

Patch

diff --git a/meta/recipes-connectivity/ppp/ppp_2.5.1.bb b/meta/recipes-connectivity/ppp/ppp_2.5.1.bb
index 5b8c49ca850..19e89b18383 100644
--- a/meta/recipes-connectivity/ppp/ppp_2.5.1.bb
+++ b/meta/recipes-connectivity/ppp/ppp_2.5.1.bb
@@ -27,7 +27,10 @@  SRC_URI = "https://download.samba.org/pub/${BPN}/${BP}.tar.gz \
 
 SRC_URI[sha256sum] = "733b7f5840b613da4eab0429a5081293275f06ba8b528e1b8eea6964faf0243a"
 
-inherit autotools systemd
+inherit autotools systemd pkgconfig
+
+PACKAGECONFIG ??= ""
+PACKAGECONFIG[pam] = "--with-pam=yes,--with-pam=no,libpam"
 
 EXTRA_OECONF += "--with-openssl=${STAGING_EXECPREFIXDIR}"