LDAP user resolving broken in 2025.06

[bedroge]

Not sure what's causing the issue yet, but starting startprefix from 2025.06 on a system with LDAP results in:

I have no name!@interactive1 ~ $ 

And tools like whoami, who, last are broken. SSSD was updated but built in the same way as for 2023.06, but apparently something has changed.

[bedroge]

last is trying to use /cvmfs/software.eessi.io/versions/2025.06/compat/linux/x86_64/var/log/wtmp, even though:

$ grep WTMP /cvmfs/software.eessi.io/versions/2023.06/compat/linux/x86_64/usr/include/paths.h 
#define	_PATH_WTMP	"/var/log/wtmp"

[bedroge]

I tried to downgrade sys-auth/sssd to the version that we used in 2023.06, and that solved the issue. Then I tried some intermediate versions (see https://github.com/EESSI/gentoo-overlay/tree/main/sys-auth/sssd), and they worked fine too. Finally, I tried rebuilding the latest version, i.e. the one that we used for 2025.06, and then it worked fine as well 😲

I don't understand what's happening though. This package gets built towards the end of the build process, i.e. after things like glibc have been rebuilt with the right flags. So I don't know what kind of thing it could have picked up which is apparently not there anymore now...

[boegel]

Any trace in the logs of the original build?

[bedroge]

I think I found it: the order of some packages seems to matter, looks like sys-libs/pam needs to be installed before sys-auth/sssd.

[bedroge]

Though that worked interactively (I could reproduce it by uninstalling and reinstalling the packages in the original order, and reinstalling them in reverse order solved it), it looks like it didn't work with a complete rebuild...

[boegel]

Though that worked interactively (I could reproduce it by uninstalling and reinstalling the packages in the original order, and reinstalling them in reverse order solved it), it looks like it didn't work with a complete rebuild...

Are you sure the packages were installed in the intended order during the complete rebuild?

[bedroge]

Looks like the order of the packages is not guaranteed.

Though that worked interactively (I could reproduce it by uninstalling and reinstalling the packages in the original order, and reinstalling them in reverse order solved it), it looks like it didn't work with a complete rebuild...

Are you sure the packages were installed in the intended order during the complete rebuild?

Indeed, they were not installed in that order, emerge determines its own order. EESSI/gentoo-overlay#117 should fix the issue.

[boegel]

@bedroge Is there any way we can come up with a test to catch this earlier?