Upgrading from sys-auth/nss_ldap-265-r5 to sys-auth/nss_ldap-265-r9 broke user auth on my no-multilib platforms. Normal multilib platforms worked fine. Issue tracked down to symlink /usr/lib64/libnss_ldap.so.2 which points to ../../lib64/libnss_ldap.so.2, but that file doesn't exist. Instead we find these files: /lib64/libnss_ldap-.so /lib64/libnss_ldap.so. -> libnss_ldap-.so On my normal multilib machines I see: /lib64/libnss_ldap-2.33.so /lib64/libnss_ldap.so.2 -> libnss_ldap-2.33.so This seems initially related/dupe of Bug 780108, but the issue there was the symlink itself, which pointed to /lib and not /lib64, but here it seems like the version suffix is wrong instead. Reproducible: Always Steps to Reproduce: 1. default/linux/amd64/17.1/no-multilib profile 2. emerge sys-auth/nss_ldap 3. ls -la /lib64/libnss_ldap* Actual Results: /lib64/libnss_ldap-.so /lib64/libnss_ldap.so. -> libnss_ldap-.so Expected Results: /lib64/libnss_ldap-2.33.so /lib64/libnss_ldap.so.2 -> libnss_ldap-2.33.so Reproduced initially on a fresh Gentoo install, later reproduced on long-running Gentoo installs. Reverting to sys-auth/nss_ldap-265-r5 fixes the issue.
Created attachment 735787 [details] emerge --info
So, in nss_ldap-265-libdir.patch, we have: >-if GCC >-MULTI_OS_DIRECTORY=$(shell $(CC) $(CFLAGS) -print-multi-os-directory) >-else > MULTI_OS_DIRECTORY=. >-endif and on no-multilib, I suppose we lack /lib/, so things like this are broken: > if GLIBC >-LIBC_VERS = $(shell ls /lib/$(MULTI_OS_DIRECTORY)/libc-*.so | tail -n 1 | sed >-e 's|.*libc-\(.*\)\.so|\1|') >+LIBC_VERS = $(shell ls @GENTOO_PORTAGE_EPREFIX@/lib/$(MULTI_OS_DIRECTORY)/libc-*.so | tail -n 1 | sed -e 's|.*libc-\(.*\)\.so|\1|') >NSS_LDAP_LIBC_VERSIONED = libnss_ldap-$(LIBC_VERS).so I'll dig into this a bit more later but it might be enough to just use libdir instead as the versions should match for all ABIs installed anyway.
The bug is LIBC_VERS detection, as it assumes there is a libc-x.xx in /lib, which is only true on 32-bit/multilib setups. 64-bit no-multilib only has libc in /lib64.
(In reply to John Einar Reitan from comment #3) > The bug is LIBC_VERS detection, as it assumes there is a libc-x.xx in /lib, > which is only true on 32-bit/multilib setups. 64-bit no-multilib only has > libc in /lib64. I think we're the saying the same thing, aye. On it.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=185c7bc43d6c85bfa46f3420493fbe3502071ad3 commit 185c7bc43d6c85bfa46f3420493fbe3502071ad3 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-08-26 18:18:43 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-08-26 18:21:02 +0000 sys-auth/nss_ldap: fix finding glibc version on no-multilib Bit of a hack but the rest of it is rather fragile anyway. The issue was that ${EPREFIX}/lib doesn't exist on non-multilib systems. Bug: https://bugs.gentoo.org/810058 Signed-off-by: Sam James <sam@gentoo.org> .../nss_ldap/files/nss_ldap-265-r10-libdir.patch | 31 +++++ sys-auth/nss_ldap/nss_ldap-265-r10.ebuild | 148 +++++++++++++++++++++ 2 files changed, 179 insertions(+)
Could you verify if -r10 works for you? Thank you!
Your commit is broken, but trivially to fix. You called the new patch for nss_ldap-265-r10-libdir.patch, but nss_ldap-265-r10.ebuild tries to pull in nss_ldap-265-r9-libdir.patch. Updating the -r10.ebuild to use the right filename it built and installed correctly versioned .so files.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2b53bbf2ac38ceb693b0de04adbb067ee3a35c27 commit 2b53bbf2ac38ceb693b0de04adbb067ee3a35c27 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-08-26 19:04:52 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-08-26 19:04:52 +0000 sys-auth/nss_ldap: fix patch filename Caused by flip-flopping between revbumping or not for the fix (which was silly). Fixes: 185c7bc43d6c85bfa46f3420493fbe3502071ad3 Bug: https://bugs.gentoo.org/810058 Signed-off-by: Sam James <sam@gentoo.org> sys-auth/nss_ldap/nss_ldap-265-r10.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
(In reply to John Einar Reitan from comment #7) > Your commit is broken, but trivially to fix. > > You called the new patch for nss_ldap-265-r10-libdir.patch, but > nss_ldap-265-r10.ebuild tries to pull in nss_ldap-265-r9-libdir.patch. > Thank you -- apologies, it's because I ended up going back and forth on revbumping or not (for unknown reasons, as we obviously should, I think I was just a bit distracted). > Updating the -r10.ebuild to use the right filename it built and installed > correctly versioned .so files. Excellent, thank you for the fast confirmation.
amd64 stable
x86 stable
sparc done
Looking good on ppc64. # cat nss_ldap-810058.report USE='-kerberos sasl ssl' succeeded for =sys-auth/nss_ldap-265-r10 USE='kerberos sasl ssl' succeeded for =sys-auth/nss_ldap-265-r10
ppc64 done
(In reply to ernsteiswuerfel from comment #13) > Looking good on ppc64. > > # cat nss_ldap-810058.report > USE='-kerberos sasl ssl' succeeded for =sys-auth/nss_ldap-265-r10 > USE='kerberos sasl ssl' succeeded for =sys-auth/nss_ldap-265-r10 Thanks!
ppc stable
arm done all arches done
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b5ffac8065af254bee8634251515ee460973e428 commit b5ffac8065af254bee8634251515ee460973e428 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2021-09-04 15:30:22 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2021-09-04 15:31:11 +0000 sys-auth/nss_ldap: Drop 265-r9 Bug: https://bugs.gentoo.org/810058 Package-Manager: Portage-3.0.22, Repoman-3.0.3 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> sys-auth/nss_ldap/nss_ldap-265-r9.ebuild | 147 ------------------------------- 1 file changed, 147 deletions(-)
