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