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

Bug#968894: marked as done (release.debian.org: binNMUs requests for libxcrypt "transition")

Your message dated Sun, 17 Jan 2021 20:56:57 +0100
with message-id <YASWiYoWxt7Bgyl8@aurel32.net>
and subject line Re: Bug#968894: release.debian.org: binNMUs requests for libxcrypt "transition"
has caused the Debian Bug report #968894,
regarding release.debian.org: binNMUs requests for libxcrypt "transition"
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
968894: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968894
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
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.

Thanks
Aurelien


adanaxisgpl_1.2.5.dfsg.1-6
apg_2.2.3.dfsg.1-5
apr_1.6.5-1
apr-util_1.6.1-4
atheme-services_7.2.9-3
calife_1:3.0.1-5
ccrypt_1.11-1
cernlib_20061220+dfsg3-4.4
clisp_1:2.49.20180218+really2.49.92-3
conserver_8.2.4-2
courier-authlib_0.69.0-2
crack_5.0a-12
crossfire_1.71.0+dfsg1-2
cvm_0.97-0.1
cvs_2:1.12.13+real-27
dacs_1.4.40-2
dcap_2.47.12-2
dircproxy_1.0.5-6
dnprogs_2.65
epic4_1:2.10.6-1
epic5_2.0.1-1
fgetty_0.7-6
francine_0.99.8+orig-2
freewnn_1.1.1~a021+cvs20130302-7
fwlogwatch_1.4-2
gadmin-openvpn-client_0.1.9-1
gadmin-openvpn-server_0.1.5-3.1
gadmin-proftpd_1:0.4.2-1
gadmin-rsync_0.1.7-1
gadmin-samba_0.2.9-3
gauche_0.9.6-10
gauche-c-wrapper_0.6.1-11
gauche-gl_0.6-4
gauche-gtk_0.6+git20160927-3
geant321_1:3.21.14.dfsg-11
generator-scripting-language_4.1.5-3
gridengine_8.1.9+dfsg-9
gup_0.5.15
inn_1:1.7.2q-46
ircd-irc2_2.11.2p3~dfsg-5
ircd-ircu_2.10.12.10.dfsg1-3
ircii_20190117-1
jabberd2_2.7.0-1
john_1.8.0-2
kinput2_3.1-13
ldapvi_1.7-10
liboobs_3.0.0-4
libpam-ldap_186-4
libpam-pwdfile_1.0-1
lua-posix_33.4.0-3
lyskom-server_2.1.2-16
mailsync_5.2.2-3.1
mclibs_20061220+dfsg3-3.1
mini-httpd_1.30-2
mokutil_0.3.0+1538710437.fb6250f-1
monitoring-plugins_2.2-6
mysql-5.7_5.7.26-1
netatalk_3.1.12~ds-4
netkit-telnet-ssl_0.17.41+0.2-3.2
pam_1.3.1-5
pam-pgsql_0.7.3.2-1
pam-ssh-agent-auth_0.10.3-3
paw_1:2.14.04.dfsg.2-9.1
pidgin-librvp_0.9.7cvs-1.1
ppp_2.4.7-2+4.1+deb10u1
proxy-suite_1.9.2.4-10
quagga_1.2.4-4
regina-rexx_3.6-2.1
remote-tty_4.0-13
scrollz_2.2.3-1
slim_1.3.6-5.1
tcltrf_2.1.4-dfsg3-2
tinymux_2.10.1.14-1
tsdecrypt_10.0-2
ttysnoop_0.12d-6
wnn6-sdk_1.0.0-18
xdm_1:1.1.11-3
xscreensaver_5.42+dfsg1-1
yap_6.2.2-6

--- End Message ---
--- Begin Message --- 
Hi,

On 2021-01-14 11:09, Aurelien Jarno wrote:
> 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.

pam finally migrated to testing, thanks.

> - 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.

This is not release team territory, so I am closing the bug.

Regards,
Aurelien

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

Attachment: signature.asc
Description: PGP signature


--- End Message ---
Reply to: