Re: HELP NEEDED: debuging a ppc64el autopkgtest failure involving polkitd?

On Fri, 13 Jun 2025 at 09:45:43 -0230, Theodore Ts'o wrote:
>Thanks, I hadn't thought of the... interesting design choice of
>using tests that require LDAP without having some kind of
>stubbing/mocking setup to avoid tests being super-flaky.

As far as I can see, the test doesn't set up or configure a LDAP server 
at all, it just has a (presumably unconfigured) libnss-ldapd installed.

On other architectures, and most of the time on ppc64el, this works OK 
(name resolution via LDAP fails gracefully and nss(5) falls back to 
/etc/group, presumably), but you seem to have been particularly unlucky.

I retried the autopkgtest that had appeared to regress with the new 
e2fsprogs, and it seems to have worked after a while, so e2fsprogs 
migration should now be unblocked. I'll open a bug against 
debian-edu-config and/or libnss-ldapd.

>Perhaps the LDAP server is someplace random which has some kind of
>firewall filter preventing access from the ppc64el testing machine?

The CI environment doesn't make any guarantee that an LDAP server exists 
at all, and I would expect that in practice there is no LDAP server. 
autopkgtests cannot assume the existence of any infrastructure outside 
the testbed itself, unless they have the "needs-internet" restriction 
(which this one does not), in which case they can assume a typical level 
of access to the public internet (but they still cannot assume anything 
about the local LAN or private resources).

     smcv