[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#968894: release.debian.org: binNMUs requests for libxcrypt "transition"



On 2020-08-27 21:53, Aurelien Jarno wrote:
> Hi,
> 
> On 2020-08-23 17:06, Sebastian Ramacher wrote:
> > On 2020-08-23 13:37:42 +0200, Aurelien Jarno wrote:
> > > Package: release.debian.org
> > > Severity: normal
> > > X-Debbugs-Cc: debian-glibc@lists.debian.org, md@linux.it
> > > 
> > > Dear release team,
> > > 
> > > Back in December we moved libcrypt.so.1 from the libc6 package to the
> > > libcrypt1 package, which is built from the libxcrypt source package.
> > > libcrypt will eventually get removed from glibc upstream, this will
> > > allow faster development independently from glibc.
> > > 
> > > As the ABI is compatible the "transition" has been transparent, libc6
> > > depending on libcrypt1, and libc6-dev depending on libcrypt-dev.
> > > However it would be good to rebuild the affected packages:
> > > - They will get a direct dependency on libcrypt1. That would open the
> > >   possibility to remove the libc6 dependency on libcrypt1 in bookworm.
> > >   That would also allow to identify the affected packages to remove the
> > >   libc6-dev dependency on libcrypt-dev, or to handle a possible ABI
> > >   transition.
> > > - They might start using additional functionalities (e.g. hashing
> > >   algorithms) provided by libcrypt1.
> > > 
> > > Many packages have already been rebuilt against libxcrypt due to source
> > > uploads or unrelated binNMUs. We are now down to less than 80 affected
> > > packages on amd64, so it's probably acceptable to start binNMUing them.
> > > 
> > > You will find the list below. It has been computed on amd64 only as it's
> > > a long operation involving unpacking all the packages in the archive and
> > > checking all the binaries they contains. As the change has been
> > > introduced at the same time on all architectures, I believe the same
> > > binNMUs are need for all of them, and anyway we need to keep them in
> > > sync for multiarch libraries. Once we have been able to get all of the
> > > packages fixed on amd64, I'll also check the other architectures to see
> > > if some of them have been missed.
> 
> [snip]
> 
> > Scheduled binNMUs on all architectures.
> 
> Thanks for scheduling the binNMUs. We are down to the following list in
> sid/amd64:

A small update of the current status.

- In bullseye, only pam_1.3.1-5 is still affected. This has been fixed
  by a new upload to sid, but the package doesn't migrate due to
  autopkgtests regressions on armhf and ppc64el. It would be important
  for bookworm to get this package fixed in bullseye.

- In sid the following packages are still affected, they all FTBFS: 
 
  cernlib_20061220+dfsg3-4.4 (#957080)
  gadmin-proftpd_1:0.4.2-1 (#957248)
  gauche_0.9.6-10 (#957256)
  gauche-c-wrapper_0.6.1-11 (#925691)
  geant321_1:3.21.14.dfsg-11 (#957263)
  gridengine_8.1.9+dfsg-9 (#957310)
  mclibs_20061220+dfsg3-3.1 (#957522)
  mysql-5.7_5.7.26-1 (#969115)
  quagga_1.2.4-4 (#957737)
  yap_6.2.2-6 (#877034)

  If they are not fixed in a reasonable time, I'll ask ftp-masters for
  their removal.

Regards,
Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

Attachment: signature.asc
Description: PGP signature


Reply to: