Bug#975311: marked as done (tzdata: /usr/share/zoneinfo/leap-seconds.list [ IERS Bulletin C59 ] expires on 28 December 2020)
Your message dated Fri, 20 Nov 2020 16:16:53 +0100
with message-id <20201120151653.gi2...@aurel32.net>
and subject line Re: Bug#975311: tzdata: /usr/share/zoneinfo/leap-seconds.list
[ IERS Bulletin C59 ] expires on 28 December 2020
has caused the Debian Bug report #975311,
regarding tzdata: /usr/share/zoneinfo/leap-seconds.list [ IERS Bulletin C59 ]
expires on 28 December 2020
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 ow...@bugs.debian.org
immediately.)
--
975311: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975311
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tzdata
Version: 2020a-0+deb10u1
Severity: normal
Tags: upstream
Dear Maintainer,
* What led up to the situation?
Checking the out of systemctl status ntp.service after restart of an
Debian 10 system with NTPd running
* What exactly did you do (or not do) that was effective (or
ineffective)?
systemctl stop ntp.service
systemctl start ntp.service
systemctl status ntp.service
view /usr/share/zoneinfo/leap-seconds.list
* What was the outcome of this action?
Nov 11 20:18:05 myhostname ntpd[11542]: leapsecond file
('/usr/share/zoneinfo/leap-seconds.list'): good hash signature
Nov 11 20:18:05 myhostname ntpd[11542]: leapsecond file
('/usr/share/zoneinfo/leap-seconds.list'): loaded,
expire=2020-12-28T00:00:00Z last=2017-01-01T00:00:00Z ofs=3
/usr/share/zoneinfo/leap-seconds.list [ IERS Bulletin C59 ] expires on
28 December 2020
[...]
# Updated through IERS Bulletin C59
# File expires on: 28 December 2020
[...]
* What outcome did you expect instead?
Please refer to the new version C60:
https://www.iers.org/IERS/EN/Publications/Bulletins/bulletins.html
The leap second file is recommended to be used in a valid version:
See for example
https://kb.meinbergglobal.com/kb/time_sync/ntp/configuration/ntp_leap_second_file#expiration_date
/usr/share/zoneinfo/leap-seconds.list refering to IERS Bulletin C Number
60
If the impact of an invalid leap-seconds.list on ntp clients and server
is known as more severe
please change the severity to level 3 (serious).
Thank you in adance.
Best Regards
Jens
-- System Information:
Debian Release: 10.6
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-12-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages tzdata depends on:
ii debconf [debconf-2.0] 1.5.71
tzdata recommends no packages.
tzdata suggests no packages.
-- debconf information:
tzdata/Zones/Africa:
tzdata/Zones/SystemV:
tzdata/Zones/America:
* tzdata/Areas: Europe
* tzdata/Zones/Europe: Berlin
tzdata/Zones/Australia:
tzdata/Zones/Asia:
tzdata/Zones/Atlantic:
tzdata/Zones/US:
tzdata/Zones/Antarctica:
tzdata/Zones/Pacific:
tzdata/Zones/Arctic:
tzdata/Zones/Indian:
* tzdata/Zones/Etc: UTC
--- End Message ---
--- Begin Message ---
Version: 2020b-0+deb10u1
Hi,
On 2020-11-20 11:41, j...@abromeit.info wrote:
> Package: tzdata
> Version: 2020a-0+deb10u1
> Severity: normal
> Tags: upstream
>
> Dear Maintainer,
>
>* What led up to the situation?
>
> Checking the out of systemctl status ntp.service after restart of an Debian
> 10 system with NTPd running
>
>* What exactly did you do (or not do) that was effective (or
> ineffective)?
>
> systemctl stop ntp.service
> systemctl start ntp.service
> systemctl status ntp.service
> view /usr/share/zoneinfo/leap-seconds.list
>
>* What was the outcome of this action?
>
> Nov 11 20:18:05 myhostname ntpd[11542]: leapsecond file
> ('/usr/share/zoneinfo/leap-seconds.list'): good hash signature
> Nov 11 20:18:05 myhostname ntpd[11542]: leapsecond file
> ('/usr/share/zoneinfo/leap-seconds.list'): loaded,
> expire=2020-12-28T00:00:00Z last=2017-01-01T00:00:00Z ofs=3
>
> /usr/share/zoneinfo/leap-seconds.list [ IERS Bulletin C59 ] expires on 28
> December 2020
> [...]
> # Updated through IERS Bulletin C59
> # File expires on: 28 December 2020
> [...]
>
>* What outcome did you expect instead?
>
> Please refer to the new version C60:
> https://www.iers.org/IERS/EN/Publications/Bulletins/bulletins.html
>
> The leap second file is recommended to be used in a valid version:
> See for example
> https://kb.meinbergglobal.com/kb/time_sync/ntp/configuration/ntp_leap_second_file#expiration_date
>
> /usr/share/zoneinfo/leap-seconds.list refering to IERS Bulletin C Number 60
Re: Bug#974552: upgrade-reports: libc6/libcrypt split breaks perl during buster->bullseye upgrade
Am Freitag, den 20.11.2020, 09:13 + schrieb Niko Tyni: > I don't think this is related to the recent perl 5.30 -> 5.32 > transition. > The report is about a buster -> bullseye upgrade, and perl in > bullseye > was still at 5.30 at the time. > > In any case, the report says perl (presumably perl-base as well) was > still at the buster version when the breakage happened, so it didn't > have the libcrypt1 dependency. This is indeed the case. perl-base was only upgraded to the bullseye version after I manually fixed the breakage. (Indeed, when I wrote "Perl" I actually meant "perl-base", but perl itself was also at the buster version FWIW.) > FWIW the breakage can be reproduced just by manually unpacking the > new > libc6 on a buster system. > > I don't know why it hasn't been encountered earlier. I found out by now that the problem actually has been encountered earlier(#946599, where it broke libc's maintainer scripts). In my case, it broke the check-support-status hook providd by debian-security- support. (I'm not sure whether it's such a great idea for dpkg to run hooks when dependencies are broken, but that's what was happening on my system.) > > > Yeah, I missed the libcrypt1 -> libc6 dependency. That prevents this > option. (I wonder if the circular dependency is a factor in apt > choosing > the upgrade order that results in this breakage.) I'm not sure what's going on here, as libcrypt1's libc6 Depends should be satisfied by the buster version. So it seems to me like installing libcrypt1 before upgrading libc6 should be strictly better than doing it the other way round, even purely in terms of satisfaction of dependencies. Maybe it's worth investigating why apt decides to proceed the "wrong" way anyway, should I try setting up a VM to reproduce the problem? > > > Another option might be to have the new libc6 Conflict with old > > > versions > > > of Essential:yes packages that need libcrypt1, forcing those > > > Essential:yes > > > packages to get upgraded first. A quick check based on libcrypt1 > > > reverse > > > dependencies in sid shows perl-base, login and util-linux. I'm > > > not sure > > > if this list is exhaustive, though. Having libc6 Conflict with one of those packages should be enough, right? -- Alois signature.asc Description: This is a digitally signed message part
Bug#975077: libc6: circular dependencies
Hi, I guess this known issue might also be the reason why I'm not able to reinstall all installed packages with using "aptitude -reinstall ~i" like reported in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975052 Is this correct? Best regards,
Bug#975311: tzdata: /usr/share/zoneinfo/leap-seconds.list [ IERS Bulletin C59 ] expires on 28 December 2020
Package: tzdata
Version: 2020a-0+deb10u1
Severity: normal
Tags: upstream
Dear Maintainer,
* What led up to the situation?
Checking the out of systemctl status ntp.service after restart of an
Debian 10 system with NTPd running
* What exactly did you do (or not do) that was effective (or
ineffective)?
systemctl stop ntp.service
systemctl start ntp.service
systemctl status ntp.service
view /usr/share/zoneinfo/leap-seconds.list
* What was the outcome of this action?
Nov 11 20:18:05 myhostname ntpd[11542]: leapsecond file
('/usr/share/zoneinfo/leap-seconds.list'): good hash signature
Nov 11 20:18:05 myhostname ntpd[11542]: leapsecond file
('/usr/share/zoneinfo/leap-seconds.list'): loaded,
expire=2020-12-28T00:00:00Z last=2017-01-01T00:00:00Z ofs=3
/usr/share/zoneinfo/leap-seconds.list [ IERS Bulletin C59 ] expires on
28 December 2020
[...]
# Updated through IERS Bulletin C59
# File expires on: 28 December 2020
[...]
* What outcome did you expect instead?
Please refer to the new version C60:
https://www.iers.org/IERS/EN/Publications/Bulletins/bulletins.html
The leap second file is recommended to be used in a valid version:
See for example
https://kb.meinbergglobal.com/kb/time_sync/ntp/configuration/ntp_leap_second_file#expiration_date
/usr/share/zoneinfo/leap-seconds.list refering to IERS Bulletin C Number
60
If the impact of an invalid leap-seconds.list on ntp clients and server
is known as more severe
please change the severity to level 3 (serious).
Thank you in adance.
Best Regards
Jens
-- System Information:
Debian Release: 10.6
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-12-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages tzdata depends on:
ii debconf [debconf-2.0] 1.5.71
tzdata recommends no packages.
tzdata suggests no packages.
-- debconf information:
tzdata/Zones/Africa:
tzdata/Zones/SystemV:
tzdata/Zones/America:
* tzdata/Areas: Europe
* tzdata/Zones/Europe: Berlin
tzdata/Zones/Australia:
tzdata/Zones/Asia:
tzdata/Zones/Atlantic:
tzdata/Zones/US:
tzdata/Zones/Antarctica:
tzdata/Zones/Pacific:
tzdata/Zones/Arctic:
tzdata/Zones/Indian:
* tzdata/Zones/Etc: UTC
Re: Bug#974552: upgrade-reports: libc6/libcrypt split breaks perl during buster->bullseye upgrade
On Fri, Nov 20, 2020 at 09:30:23AM +0100, Aurelien Jarno wrote: > On 2020-11-16 16:39, Niko Tyni wrote: > > On Fri, Nov 13, 2020 at 08:48:19PM +0100, Sven Joachim wrote: > > > On 2020-11-13 18:23 +0100, Niels Thykier wrote: > > > > > > > Control: reassign -1 perl-base > > > > Control: affects -1 upgrade-reports > > > > Control: severity -1 grave > > > > > > > > Hi Perl team, > > > > > > > > I have reassigned this bug to perl because perl-base being essential > > > > must remain functional during an upgrade and AFAICT perl-base fails in > > > > this case here. > > > > > > > > If it is a direct linkage, then you might be needing a Pre-Depends. If > > > > it is an indirect linkage then I am not sure how to fix it. :-/ > > > > > > I don't think perl-base is doing anything wrong here, it already uses > > > Pre-Depends. AFAICS the problem is that libcrypt.so.1 can temporarily > > > go missing if libc6 2.31-4 is unpacked before libcrypt1, breaking the > > > assumption that binaries from essential packages are always usable. > > I don't understand what happened there. Sure there has been the perl > transition, but the fact that perl depends on libcrypt1, it is the case > for more than 6 months. I don't think this is related to the recent perl 5.30 -> 5.32 transition. The report is about a buster -> bullseye upgrade, and perl in bullseye was still at 5.30 at the time. In any case, the report says perl (presumably perl-base as well) was still at the buster version when the breakage happened, so it didn't have the libcrypt1 dependency. FWIW the breakage can be reproduced just by manually unpacking the new libc6 on a buster system. I don't know why it hasn't been encountered earlier. > > As to the fix, I suspect we need a pre-dependency from libc6 to libcrypt1 > > for one release cycle, so that libc6 cannot be unpacked before libcrypt1 > > is fully installed. > > This has been tried, that works for upgrade, but then apt refuses to > allow new installation of libc6+libxcrypt1, which makes it impossible to > install foreign-arch versions on an existing system. Yeah, I missed the libcrypt1 -> libc6 dependency. That prevents this option. (I wonder if the circular dependency is a factor in apt choosing the upgrade order that results in this breakage.) > > Another option might be to have the new libc6 Conflict with old versions > > of Essential:yes packages that need libcrypt1, forcing those Essential:yes > > packages to get upgraded first. A quick check based on libcrypt1 reverse > > dependencies in sid shows perl-base, login and util-linux. I'm not sure > > if this list is exhaustive, though. > > This is something we can try indeed. It looks like perl-base 5.30.0-10 was the first version to acquire the pre-dependency on libcrypt1. -- Niko
Bug#975077: libc6: circular dependencies
Hi, On 2020-11-18 19:57, Bill Allombert wrote: > Package: libc6 > Version: 2.31-4 > Severity: important > > Hello GNU libc maintainers, > > There is a circular dependency between libc6, debconf, dpkg, libacl1, > libbz2-1.0, libcom-err2, libcrypt1, libgcc-s1, libgssapi-krb5-2, > libk5crypto3, libkeyutils1, libkrb5-3, libkrb5support0, liblzma5, > libnsl2, libnss-nis, libnss-nisplus, libpcre2-8-0, libselinux1, > libssl1.1, libtirpc3, perl-base, tar and zlib1g: This is a known issue, unfortunately this is not something we can remove for now. libcrypt1, libnss-nis and libnss-nisplus used to be provided by glibc, and are now in separate packages. We need to have libc6 to depend on them for systems to not explode during the ugprade. And dynamically linked packages have to depend on libc6. We should be able to demote libnss-nis and libnss-nisplus to a recommends or even a suggest after the bullseye release. As for libcrypt1, if we can get pam rebuilt in bullseye (currently not possible due to #956355 and #972555), we might be able to drop that depends after the bullseye release. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Bug#974552: upgrade-reports: libc6/libcrypt split breaks perl during buster->bullseye upgrade
Hi, On 2020-11-16 16:39, Niko Tyni wrote: > On Fri, Nov 13, 2020 at 08:48:19PM +0100, Sven Joachim wrote: > > On 2020-11-13 18:23 +0100, Niels Thykier wrote: > > > > > Control: reassign -1 perl-base > > > Control: affects -1 upgrade-reports > > > Control: severity -1 grave > > > > > > Hi Perl team, > > > > > > I have reassigned this bug to perl because perl-base being essential > > > must remain functional during an upgrade and AFAICT perl-base fails in > > > this case here. > > > > > > If it is a direct linkage, then you might be needing a Pre-Depends. If > > > it is an indirect linkage then I am not sure how to fix it. :-/ > > > > I don't think perl-base is doing anything wrong here, it already uses > > Pre-Depends. AFAICS the problem is that libcrypt.so.1 can temporarily > > go missing if libc6 2.31-4 is unpacked before libcrypt1, breaking the > > assumption that binaries from essential packages are always usable. I don't understand what happened there. Sure there has been the perl transition, but the fact that perl depends on libcrypt1, it is the case for more than 6 months. > Indeed. As perl-base isn't upgraded yet at that point, there's nothing > we can do on that side. > > Apparently the new libc6 is still considered to satisfy the old perl-base > pre-dependency even when it (libc6) is only unpacked and its dependencies > are not yet satisfied. This seems similar to this paragraph from Debian > policy, section 7.2: > > When a package declaring a pre-dependency is about to be unpacked > the pre-dependency can be satisfied if the depended-on package > is either fully configured, or even if the depended-on package(s) > are only in the “Unpacked” or the “Half-Configured” state, > provided that they have been configured correctly at some point > in the past (and not removed or partially removed since). In this > case, both the previously-configured and currently “Unpacked” > or “Half-Configured” versions must satisfy any version clause > in the Pre-Depends field. > > The libc6 package has been configured correctly in the past, when > it still contained libcrypt1. > > As to the fix, I suspect we need a pre-dependency from libc6 to libcrypt1 > for one release cycle, so that libc6 cannot be unpacked before libcrypt1 > is fully installed. This has been tried, that works for upgrade, but then apt refuses to allow new installation of libc6+libxcrypt1, which makes it impossible to install foreign-arch versions on an existing system. > Another option might be to have the new libc6 Conflict with old versions > of Essential:yes packages that need libcrypt1, forcing those Essential:yes > packages to get upgraded first. A quick check based on libcrypt1 reverse > dependencies in sid shows perl-base, login and util-linux. I'm not sure > if this list is exhaustive, though. This is something we can try indeed. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
