Summary: | sys-auth/nss_ldap-265-r11: installs soname that are missing symlink(s) -> lib/libnss_ldap.so.2 -> nss_ldap.so.1 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Hika <hikavdh> |
Component: | Current packages | Assignee: | Gentoo LDAP project <ldap-bugs> |
Status: | CONFIRMED --- | ||
Severity: | major | CC: | hikavdh, nightdragon, prometheanfire, robbat2, sam, soap |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | ARM | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=777633 https://bugs.gentoo.org/show_bug.cgi?id=780108 https://bugs.gentoo.org/show_bug.cgi?id=889296 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
emerge --info
sys-auth:nss_ldap-265-r5:20160528-205134.log emerge log |
Description
Hika
2016-04-26 22:48:44 UTC
Forget my mentioning of the problem with encrypted bindpw. While examining and testing, /etc/openldap/ldap.conf and /etc/ldap.conf got mixed up. The first accepts an encrypted bindpw, the second not. please attach the full build log of nss_ldap and your emerge info. all bugs reports should include these things. it is hard for us to triage/debug w/out them. I can confirm this bug too. Workaround by creating the symlink as explained: /lib/libnss_ldap.so.2 -> /lib/nss_ldap.so Raspberry Pi2 (ARMv7) CFLAGS="-O2 -pipe -march=armv7-a -mtune=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard" CHOST="armv7a-hardfloat-linux-gnueabi" Btw: I guess using qemu and compiling nss_ldap will bring the issue up... If needed i'll rebuild nss_ldap again to provide the files. Created attachment 435666 [details]
emerge --info
Sorry I missed your request
Created attachment 435668 [details]
sys-auth:nss_ldap-265-r5:20160528-205134.log
And the emerge log
I had to rerun it as my log had disappeared nothing to do here for arm@ Hi all, I faced the same problem (4 years later) and found a correction which could be applied as a Gentoo patch. Actually, the configure script does not detect that we are running with a glibc because its way for such detection is: test "$target_os" = "linux" -o "$target_os" = "linux-gnu" and target_os is the end of the CHOST, which for a Pi used to be "armv7a-hardfloat-linux-gnueabi" and is now "armv7a-unknown-linux-gnueabihf". I managed to make it work adding -o "$target_os" = "linux-gnueabihf" in both configure (line 4489) and configure.in (line 118) file, so a quick patch could easily be made. Note that the downloaded source does not seem to be up to date with the visible sources under GitHub as the latter have an additional (but not working nowadays) -o "$target_os" = "linux-gnueabi" Not sure if I've just been bitten by this, or a variation of this... but I've ended up with: $ qlist nss_ldap | grep lib | xargs ls -l -rwxr-xr-x 1 root root 89192 Mar 22 09:11 /usr/lib64/libnss_ldap-.so lrwxrwxrwx 1 root root 25 Mar 22 09:11 /usr/lib64/libnss_ldap.so. -> ../../lib/libnss_ldap.so. This was the result of installing nss_ldap-265-r6. I've binary installed my backup of -r5 but had no chance to do any further testing, but it has happened on 3 of my Gentoo installs. (In reply to Dan Goodliffe from comment #10) > Not sure if I've just been bitten by this, or a variation of this... but > I've ended up with: > > $ qlist nss_ldap | grep lib | xargs ls -l > -rwxr-xr-x 1 root root 89192 Mar 22 09:11 /usr/lib64/libnss_ldap-.so > lrwxrwxrwx 1 root root 25 Mar 22 09:11 /usr/lib64/libnss_ldap.so. -> > ../../lib/libnss_ldap.so. > > This was the result of installing nss_ldap-265-r6. I've binary installed my > backup of -r5 but had no chance to do any further testing, but it has > happened on 3 of my Gentoo installs. Thanks, I can undo that part of my changes but not got time to investigate fully yet. I’ll undo it shortly so things continue to work, thanks! The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=46d10b9f93d82e1017711ee052b40d912e453b8c commit 46d10b9f93d82e1017711ee052b40d912e453b8c Author: Sam James <sam@gentoo.org> AuthorDate: 2021-03-22 18:10:05 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-03-22 18:10:29 +0000 sys-auth/nss_ldap: change libdir logic This restores the (odd-looking) previous behaviour for now, although it seems like _that_ still needs tweaking for ARM. Fixes: 8b5133c451fba89337cf87bea32a1aec61184b32 Bug: https://bugs.gentoo.org/581306 Signed-off-by: Sam James <sam@gentoo.org> sys-auth/nss_ldap/{nss_ldap-265-r6.ebuild => nss_ldap-265-r7.ebuild} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=70371278eb61ef1c4d2e0285bfecbe11dc542641 commit 70371278eb61ef1c4d2e0285bfecbe11dc542641 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-03-22 18:14:14 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-03-22 18:14:14 +0000 sys-auth/nss_ldap: actually stage the libdir change Bug: https://bugs.gentoo.org/581306 Signed-off-by: Sam James <sam@gentoo.org> sys-auth/nss_ldap/{nss_ldap-265-r7.ebuild => nss_ldap-265-r8.ebuild} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fd52dbeb4c26bcb6b5331def1eb65c1339f2036a commit fd52dbeb4c26bcb6b5331def1eb65c1339f2036a Author: David Seifert <soap@gentoo.org> AuthorDate: 2021-04-11 21:11:06 +0000 Commit: David Seifert <soap@gentoo.org> CommitDate: 2021-04-11 21:11:06 +0000 sys-auth/nss_ldap: Fix libdir symlinks Bug: https://bugs.gentoo.org/581306 Bug: https://bugs.gentoo.org/780108 Package-Manager: Portage-3.0.18, Repoman-3.0.3 Signed-off-by: David Seifert <soap@gentoo.org> sys-auth/nss_ldap/files/nss_ldap-265-libdir.patch | 31 ++++++++++++++++++++++ ...s_ldap-265-r8.ebuild => nss_ldap-265-r9.ebuild} | 10 +++---- 2 files changed, 36 insertions(+), 5 deletions(-) Let us know if not resolved. And the story continues. Again no symlink. This time not for lack of trying, but because the library name has changed from /lib/libnss_ldap.so.1 to /lib/nss_ldap.so.1. It gives an error: "QA Notice: Missing soname symlink(s): lib/libnss_ldap.so.2 -> nss_ldap.so.1" and a few line later: "QA Notice: Symbolic link /usr/lib/libnss_ldap.so.2 points to /lib/libnss_ldap.so.2 which does not exist." Creating the symlink: /lib/libnss_ldap.so.2 -> nss_ldap.so.1 gets it working. I do not have a log at present. I haven't yet installed a logger and emerge has cleaned /var/temp/portage/. I'll run it later when I have a logger installed. I emerged sys-auth/nss_ldap-265-r11 It's not clear to me why the library name would've suddenly changed. (In reply to Sam James from comment #17) > It's not clear to me why the library name would've suddenly changed. This is the first time in 6 years I create a fresh raspberry pi installation and I now encounter in essence the same issue as 6 years ago. I now look again at my original post, six and a half years ago and I'm mistaken. Then already the library had the name without "lib" preceding it. I still do not understand why a different name is used on an ARM. It anyhow explains why the symlink creation fails. Is it possible to add an architecture dependent statement in the ebuild? Like: `dosym ../../$(get_libdir)/nss_ldap.so.1 libnss_ldap.so.2` Or possible on the presence of nss_ldap.so.1 Created attachment 825063 [details]
emerge log
Here is the emerge log.
On looking further I see there is now an alternative package "nss-pam-ldap", a spinoff from "nss_ldap". Only it is masked on ARM.:-(
Ah, thanks. tinderbox_arm has reproduced this issue with version 265-r11 - Updating summary. |