Bug#953958: Bug#953562: libcrypt1 should ship file in /lib, Replaces is useless
Hi Marco! On 3/15/20 2:33 AM, Marco d'Itri wrote: > On Mar 15, John Paul Adrian Glaubitz wrote: > >> Do you have a patch handy, then I'll fix the package manually for the time >> being for ia64 only? > Just edit debian/patch_libtool. Works. I had to modify debian/libcrypt1.symbols.ia64 as well: --- libcrypt1.symbols.ia64~ 2020-02-28 20:26:01.0 +0100 +++ libcrypt1.symbols.ia64 2020-03-15 09:20:38.110547617 +0100 @@ -1,4 +1,4 @@ -libcrypt.so.1.1 libcrypt1 #MINVER# +libcrypt.so.1 libcrypt1 #MINVER# #include "libcrypt1.symbols.common" GLIBC_2.0@GLIBC_2.0 1:4.1.0 crypt@GLIBC_2.0 1:4.1.0 So, please don't forget this. > Let me know if it works and I will apply the change. Thanks. Please go ahead changing debian/patch_libtool and debian/libcrypt1.symbols.ia64. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#953958: Bug#953562: libcrypt1 should ship file in /lib, Replaces is useless
On Mar 15, John Paul Adrian Glaubitz wrote: > Do you have a patch handy, then I'll fix the package manually for the time > being for ia64 only? Just edit debian/patch_libtool. Let me know if it works and I will apply the change. -- ciao, Marco signature.asc Description: PGP signature
Bug#953562: libcrypt1 should ship file in /lib, Replaces is useless
On 3/14/20 5:19 PM, James Clarke wrote: > This is just the opposite of #947606; ia64 is meant to have libcrypt.so.1, not > libcrypt.so.1.1 like alpha, and so that change needs to be reverted. See [1] > for an old glibc build log to demonstrate the correct name (and note that, > unlike alpha, sysdeps/unix/sysv/linux/ia64/shlib-versions does not override > libcrypt's version). Do you have a patch handy, then I'll fix the package manually for the time being for ia64 only? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#953562: libcrypt1 should ship file in /lib, Replaces is useless
Control: retitle -1 libcrypt1: Wrong soname on ia64 On 14 Mar 2020, at 14:20, John Paul Adrian Glaubitz wrote: > > Package: libcrypt1 > Version: 1:4.4.15-1 > Followup-For: Bug #953562 > User: debian-i...@lists.debian.org > Usertags: ia64 > > Hello! > > This actually causes issues on ia64 now: > > Setting up libc6.1:ia64 (2.30-2) ... > /usr/bin/perl: error while loading shared libraries: libcrypt.so.1: cannot > open shared object file: No such file or directory > dpkg: error processing package libc6.1:ia64 (--configure): > installed libc6.1:ia64 package post-installation script subprocess returned > error exit status 127 > Errors were encountered while processing: > libc6.1:ia64 > E: Sub-process /usr/bin/dpkg returned an error code (1) > apt-get failed. > E: Package installation failed > > So it's not just a theoretical issue. This is just the opposite of #947606; ia64 is meant to have libcrypt.so.1, not libcrypt.so.1.1 like alpha, and so that change needs to be reverted. See [1] for an old glibc build log to demonstrate the correct name (and note that, unlike alpha, sysdeps/unix/sysv/linux/ia64/shlib-versions does not override libcrypt's version). James [1] https://buildd.debian.org/status/fetch.php?pkg=glibc=ia64=2.28-2=1544971021=0
Bug#953562: libcrypt1 should ship file in /lib, Replaces is useless
On Mar 14, John Paul Adrian Glaubitz wrote: > This actually causes issues on ia64 now: Why do you believe that this is the cause? > /usr/bin/perl: error while loading shared libraries: libcrypt.so.1: cannot > open shared object file: No such file or directory Is this cured by manually running ldconfig? -- ciao, Marco signature.asc Description: PGP signature
Bug#953562: libcrypt1 should ship file in /lib, Replaces is useless
Package: libcrypt1 Version: 1:4.4.15-1 Followup-For: Bug #953562 User: debian-i...@lists.debian.org Usertags: ia64 Hello! This actually causes issues on ia64 now: Setting up libc6.1:ia64 (2.30-2) ... /usr/bin/perl: error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory dpkg: error processing package libc6.1:ia64 (--configure): installed libc6.1:ia64 package post-installation script subprocess returned error exit status 127 Errors were encountered while processing: libc6.1:ia64 E: Sub-process /usr/bin/dpkg returned an error code (1) apt-get failed. E: Package installation failed So it's not just a theoretical issue. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#953562: libcrypt1 should ship file in /lib, Replaces is useless
Control: retitle -1 libcrypt1 should ship file in /lib, Replaces is useless On Tue, 10 Mar 2020 18:07:59 +0100 Julian Andres Klode wrote: > On Tue, Mar 10, 2020 at 05:58:04PM +0100, Marco d'Itri wrote: > > On Mar 10, Julian Andres Klode wrote: > > > > > It likely works out fine in practice in most cases, but > > > let's be safe, k? > > Do you care enough to test a patch? > > We're going to roll out the change in Ubuntu shortly, so there'll > be a ton of testing going on involving libc6 + libcrypt1 upgrades > when the autopkgtests run. > > But yes, we should also check the other direction in Debian I guess > where we already have libc6 + libcrypt1 installed and then change > the path, though I'm not sure what could go bad there. One should also test whether glibc downgrades from bullseye to buster work (and don't leave broken systems without libcrypt.so.1). (apt-get sometimes does a bad job with downgrades involving Conflicts/Breaks/Replaces) I vaguely remember perl exploding in a glibc maintainer script on a testmachine where I did that downgrade while the libc6/libcrypt1 move was maturing. In the end I had to dpkg -i --force-something some buster glibc packages from /var/cache/apt/archives. I wanted to reproduce it the next day and file a bug, but then I forgot about it... Andreas
