Bug#642952: libpam0g-dev: Move of static libraries results in static linking due to library order
Am Montag, den 26.09.2011, 00:17 -0700 schrieb Steve Langasek: On Mon, Sep 26, 2011 at 09:01:13AM +0200, Paul Menzel wrote: affects 642952 libpam-gnome-keyring thanks Am Sonntag, den 25.09.2011, 14:55 -0700 schrieb Russ Allbery: […] This, among other things, will cause a FTBFS for all PAM modules on platforms where shared module code has to be built PIC. See the build logs for libpam-krb5, for example. After upgrading to 1.1.3-3 and rebooting Evolution could not get any passwords from GNOME Keyring with the following error messages. Gkr-Message: received an invalid, unencryptable, or non-utf8 secret Gkr-Message: call to daemon returned an invalid response: (null).(null)() Gkr-Message: received an invalid, unencryptable, or non-utf8 secret Gkr-Message: call to daemon returned an invalid response: (null).(null)() (evolution:3945): e-data-server-ui-WARNING **: Unable to find password(s) in keyring (Keyring reports: Fehler bei der Kommunikation mit dem GNOME-Schlüsselbunddienst) Upgrading to 1.1.3-4, restarting GNOME Keyring daemon (`gnome-keyring-daemon --replace`) and then Evolution fixes the problem. No, that's not related to this bug. This bug only concerned the placement of .so files in the traditional vs. multiarch library path; that only impacts build-time linking software against libpam, it has no affect on the system at runtime. Can you think of a reason why this broke with 1.1.3-3 and was fixed by 1.1.3-4? Thanks, Paul signature.asc Description: This is a digitally signed message part
Bug#642952: libpam0g-dev: Move of static libraries results in static linking due to library order
On Wed, Sep 28, 2011 at 11:54:17AM +0200, Paul Menzel wrote: Upgrading to 1.1.3-4, restarting GNOME Keyring daemon (`gnome-keyring-daemon --replace`) and then Evolution fixes the problem. No, that's not related to this bug. This bug only concerned the placement of .so files in the traditional vs. multiarch library path; that only impacts build-time linking software against libpam, it has no affect on the system at runtime. Can you think of a reason why this broke with 1.1.3-3 and was fixed by 1.1.3-4? I think this is a red herring, and something else changed on your system in between. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#642952: libpam0g-dev: Move of static libraries results in static linking due to library order
affects 642952 libpam-gnome-keyring thanks Am Sonntag, den 25.09.2011, 14:55 -0700 schrieb Russ Allbery: […] This, among other things, will cause a FTBFS for all PAM modules on platforms where shared module code has to be built PIC. See the build logs for libpam-krb5, for example. After upgrading to 1.1.3-3 and rebooting Evolution could not get any passwords from GNOME Keyring with the following error messages. Gkr-Message: received an invalid, unencryptable, or non-utf8 secret Gkr-Message: call to daemon returned an invalid response: (null).(null)() Gkr-Message: received an invalid, unencryptable, or non-utf8 secret Gkr-Message: call to daemon returned an invalid response: (null).(null)() (evolution:3945): e-data-server-ui-WARNING **: Unable to find password(s) in keyring (Keyring reports: Fehler bei der Kommunikation mit dem GNOME-Schlüsselbunddienst) Upgrading to 1.1.3-4, restarting GNOME Keyring daemon (`gnome-keyring-daemon --replace`) and then Evolution fixes the problem. Thanks, Paul signature.asc Description: This is a digitally signed message part
Bug#642952: libpam0g-dev: Move of static libraries results in static linking due to library order
affects 642952 libpam-krb5 libpam-gnome-keyring quit I am sorry for overwriting instead of appending to the list. Thanks, Paul signature.asc Description: This is a digitally signed message part
Bug#642952: libpam0g-dev: Move of static libraries results in static linking due to library order
On Mon, Sep 26, 2011 at 09:01:13AM +0200, Paul Menzel wrote: affects 642952 libpam-gnome-keyring thanks Am Sonntag, den 25.09.2011, 14:55 -0700 schrieb Russ Allbery: […] This, among other things, will cause a FTBFS for all PAM modules on platforms where shared module code has to be built PIC. See the build logs for libpam-krb5, for example. After upgrading to 1.1.3-3 and rebooting Evolution could not get any passwords from GNOME Keyring with the following error messages. Gkr-Message: received an invalid, unencryptable, or non-utf8 secret Gkr-Message: call to daemon returned an invalid response: (null).(null)() Gkr-Message: received an invalid, unencryptable, or non-utf8 secret Gkr-Message: call to daemon returned an invalid response: (null).(null)() (evolution:3945): e-data-server-ui-WARNING **: Unable to find password(s) in keyring (Keyring reports: Fehler bei der Kommunikation mit dem GNOME-Schlüsselbunddienst) Upgrading to 1.1.3-4, restarting GNOME Keyring daemon (`gnome-keyring-daemon --replace`) and then Evolution fixes the problem. No, that's not related to this bug. This bug only concerned the placement of .so files in the traditional vs. multiarch library path; that only impacts build-time linking software against libpam, it has no affect on the system at runtime. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#642952: libpam0g-dev: Move of static libraries results in static linking due to library order
Package: libpam0g-dev Version: 1.1.3-3 Severity: grave Justification: renders package unusable 1.1.3-3 changed the install rules so that the *.a files for libpam are now installed in the multiarch path, but the *.so files are still installed in /usr/lib. The linker search uses the first library that it finds and the multiarch path is earlier than /usr/lib in the search order. This means that any software building against PAM will end up building against the static libraries instead of the shared libraries because the static libraries are earlier on the search path and there are no *.so links in the same directory. This, among other things, will cause a FTBFS for all PAM modules on platforms where shared module code has to be built PIC. See the build logs for libpam-krb5, for example. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.39-2-686-pae (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libpam0g-dev depends on: ii libc6-dev [libc-dev] 2.13-21 ii libpam0g 1.1.3-3 libpam0g-dev recommends no packages. libpam0g-dev suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
