• Troubles with updating Debian Hurd

    From Sergey Bugaev@21:1/5 to All on Thu Sep 30 15:00:02 2021
    Hello.

    Lately I've been having ever-increasing troubles trying to update my Debian GNU/Hurd installation. I'm not entirely sure if it's my system that's
    broken, or something's wrong with upstream Debian repositories (the latter appears to be more likely, though). Either way, the issues seem to be
    unrelated to the Hurd itself, and rather specific to Debian. And I'm not proficient in these things enough to figure it out myself.

    The issue with sudo
    ===================

    To start off, I cannot use su or sudo to raise privileges:

    $ su
    su: Authentication failure

    $ sudo echo hi
    Sorry, try again.
    Sorry, try again.
    sudo: 3 incorrect password attempts

    Neither actually ever asks me for a password. Sudo's own troubleshooting
    FAQ has the following [0]:

    Q) Sudo never gives me a chance to enter a password using PAM, it just
    says 'Sorry, try again.' three times and exits.
    A) You didn't setup PAM to work with sudo. On RedHat Linux or Fedora
    Core this generally means installing the sample pam.conf file as /etc/pam.d/sudo. See the example pam.conf file for hints on what to use
    for other Linux systems.

    [0]: https://www.sudo.ws/troubleshooting.html

    I have definitely not messed with PAM on this system (at least, not intentionally). Both su and sudo used to work before some recent update,
    and I've verified that I see the same behavior on darnassus, so this does
    look like an upstream issue with what Debian ships.

    I can still log in as root directly, which gets me to the next issue:

    The issue with apt update
    =========================

    Here are the relevant parts of my /etc/apt/sources.list:

    deb [trusted=yes] http://snapshot.debian.org/archive/debian-ports/20210812T100000Z/ sid
    main
    deb-src http://snapshot.debian.org/archive/debian/20210812T100000Z/ sid main deb [trusted=yes] https://snapshot.debian.org/archive/debian-ports/20210812T100000Z/
    unreleased main

    deb http://ftp.ports.debian.org/debian-ports unstable main
    deb http://ftp.ports.debian.org/debian-ports experimental main
    deb http://ftp.ports.debian.org/debian-ports unreleased main

    deb http://deb.debian.org/debian-ports unstable main
    deb-src http://deb.debian.org/debian unstable main
    deb http://deb.debian.org/debian-ports experimental main
    deb-src http://deb.debian.org/debian experimental main
    deb http://deb.debian.org/debian-ports unreleased main
    deb-src http://deb.debian.org/debian unreleased main

    deb http://ftp.ports.debian.org/debian-ports unstable-debug main
    deb http://ftp.ports.debian.org/debian-ports experimental-debug main

    I'm unable to install debian-ports-archive-keyring, hence trusted=yes. And
    I admit to not really understanding how this works: the above snippet was mostly assembled using the "try things till it works" approach (except it doesn't work anymore). In particular, some of the entries I've scraped from this doc [1].

    [1]: https://www.debian.org/ports/hurd/hurd-install

    This is what I see when I run apt update:

    # apt update
    Get:1 http://deb.debian.org/debian-ports unstable InRelease [55.3 kB]
    Hit:2 http://snapshot.debian.org/archive/debian-ports/20210812T100000Z
    sid InRelease
    Hit:3 http://ftp.ports.debian.org/debian-ports experimental InRelease
    Hit:4 http://deb.debian.org/debian unstable InRelease
    Hit:5 http://snapshot.debian.org/archive/debian/20210812T100000Z sid
    InRelease
    Hit:6 http://ftp.ports.debian.org/debian-ports unreleased InRelease
    Get:7 http://deb.debian.org/debian-ports experimental InRelease [55.3
    kB]
    Ign:8 http://ftp.ports.debian.org/debian-ports unstable-debug
    InRelease
    Ign:9 http://ftp.ports.debian.org/debian-ports experimental-debug
    InRelease
    Hit:10 http://deb.debian.org/debian experimental InRelease
    Get:11 http://ftp.ports.debian.org/debian-ports unstable InRelease [55.3 kB] Get:12 http://deb.debian.org/debian-ports unreleased InRelease [56.6 kB]
    Get:13 https://snapshot.debian.org/archive/debian-ports/20210812T100000Z unreleased InRelease [56.6 kB]
    Ign:14 http://deb.debian.org/debian unreleased InRelease
    Err:15 http://ftp.ports.debian.org/debian-ports unstable-debug Release
    404 Not Found [IP: 130.89.148.77 80]
    Err:16 http://deb.debian.org/debian unreleased Release
    404 Not Found [IP: 151.101.86.132 80]
    Err:17 http://ftp.ports.debian.org/debian-ports experimental-debug Release
    404 Not Found [IP: 130.89.148.77 80]
    Get:18 http://deb.debian.org/debian-ports unstable/main hurd-i386
    Packages [18.9 MB]
    Err:6 http://ftp.ports.debian.org/debian-ports unreleased InRelease
    The following signatures were invalid: BADSIG 5A88D659DCB811BB
    Debian Ports Archive Automatic Signing Key (2021) <ftpmaster@ports-master.debian.org>
    Get:19 https://snapshot.debian.org/archive/debian-ports/20210812T100000Z unreleased/main hurd-i386 Packages [188 kB]
    Get:20 http://deb.debian.org/debian-ports unstable/main all Packages [9,323 kB] Get:21 http://deb.debian.org/debian-ports experimental/main hurd-i386
    Packages [795 kB]
    Get:22 http://deb.debian.org/debian-ports experimental/main all
    Packages [464 kB]
    Get:23 http://deb.debian.org/debian-ports unreleased/main hurd-i386
    Packages [159 kB]
    Get:24 http://ftp.ports.debian.org/debian-ports unstable/main
    hurd-i386 Packages [18.9 MB]
    Err:18 http://deb.debian.org/debian-ports unstable/main hurd-i386
    Packages
    Hash Sum mismatch
    Hashes of expected file:
    - Filesize:77531148 [weak]
    - SHA512:c8108d738ef08afa9556ec395e0b8097e54f66347cce924303b6294dcfa32a4a3853b29597902372562542c7b73ca364be44234d3c0b709e992ad19fa6b566a2
    - SHA256:06de0c824e0ff3e683a5698ebd63892c34f264eff7d311a7e3a225dd894f8457
    - SHA1:4b881bd3628a18f0917b55349563fe6a95f25887 [weak]
    - MD5Sum:65d941cde7d7279bbecfe22c67ff40fa [weak]
    Hashes of received file:
    - SHA512:9fae8af5d37a72f3410c9c0c70d75c4677b9ee8933bd3a05c8cb20e59430f7b56fb060b6d0cba41a20ac0e7d878cd447a6936b740ffc3536b74afe0fd31d90bb
    - SHA256:06de0c824e0ff3e683a5698ebd63892c34f264eff7d311a7e3a225dd894f8457
    - SHA1:4b881bd3628a18f0917b55349563fe6a95f25887 [weak]
    - MD5Sum:65d941cde7d7279bbecfe22c67ff40fa [weak]
    - Filesize:77531148 [weak]
    Last modification reported: Thu, 30 Sep 2021 07:23:09 +0000
    Release file created at: Thu, 30 Sep 2021 07:40:38 +0000
    Err:19 https://snapshot.debian.org/archive/debian-ports/20210812T100000Z unreleased/main hurd-i386 Packages
    Hash Sum mismatch
    Hashes of expected file:
    - Filesize:755398 [weak]
    - SHA512:830bbee3f0a649701c3a5b55871d4936c4cc45fdd666e6800264e5c365f65af11af1489b5155e87f12d172923c1f7671b6bda3060a452ea3459f3229cabf1eba
    - SHA256:9a24ed717113ab571a5e5b4d0c260856f3fcd79a9a04bd667da9e8b4ae768b40
    - SHA1:43aec500d242311ea4f7392fda5d6dd78b458437 [weak]
    - MD5Sum:a0d2abb78827691baaa96835c45711f3 [weak]
    Hashes of received file:
    - SHA512:513653e475542d5652a419480700336b476f110e7dfbf438982f1d7361b231818c069fdd4fb970a47c08330234dc182c2cc9c5f9f8de13fe94be092086e5b9c2
    - SHA256:9a24ed717113ab571a5e5b4d0c260856f3fcd79a9a04bd667da9e8b4ae768b40
    - SHA1:43aec500d242311ea4f7392fda5d6dd78b458437 [weak]
    - MD5Sum:a0d2abb78827691baaa96835c45711f3 [weak]
    - Filesize:755398 [weak]
    Last modification reported: Wed, 11 Aug 2021 02:01:50 +0000
    Release file created at: Thu, 12 Aug 2021 07:29:40 +0000
    Err:21 http://deb.debian.org/debian-ports experimental/main hurd-i386
    Packages
    Hash Sum mismatch
    Hashes of expected file:
    - Filesize:3675782 [weak]
    - SHA512:cbc3ef2bba3c0e5d24bad319160d81437d9622458de2a805f966005127e3125a72e3dec069ca0c8caa3037e6665ecfe7e572dd2bdf2a678d9e4e0a9add347347
    - SHA256:c906ca5c09b7fb98508962c595bbcc9174da517521cc2d2c5d6f0e91abecb534
    - SHA1:0b0cb5e5042a82a00064ce8c1f9d454ff53c1822 [weak]
    - MD5Sum:342c054c5ff9b8129e35f45cbd6b9c06 [weak]
    Hashes of received file:
    - SHA512:02e05e3a74aa854ff28401a4cb971cfca4e63016390c68b1fec9a8c3b2ed43526cebfed598d694b8fb48f196d85aac1176e791eb1fbeab797a41fd3ca5d2ea3e
    - SHA256:c906ca5c09b7fb98508962c595bbcc9174da517521cc2d2c5d6f0e91abecb534
    - SHA1:0b0cb5e5042a82a00064ce8c1f9d454ff53c1822 [weak]
    - MD5Sum:342c054c5ff9b8129e35f45cbd6b9c06 [weak]
    - Filesize:3675782 [weak]
    Last modification reported: Thu, 30 Sep 2021 07:39:43 +0000
    Release file created at: Thu, 30 Sep 2021 07:41:07 +0000
    Err:22 http://deb.debian.org/debian-ports experimental/main all
    Packages

    Err:23 http://deb.debian.org/debian-ports unreleased/main hurd-i386
    Packages
    Hash Sum mismatch
    Hashes of expected file:
    - Filesize:659166 [weak]
    - SHA512:52a7aab50f21dc02224b53fbd63db25f283ce5270e7c8cfdd8145a406c12fa69321c0fa03fdc2b647ad8c27d9c911f72890841fb6fdfa420a49cd8ad13bbec6f
    - SHA256:1725ce5414bdef5adabd725caca33af1253ffa0405122c2c3715c39e500648a5
    - SHA1:8767c794a044244d6baa35c3dbe4f3697221da07 [weak]
    - MD5Sum:2820433296bbc691ac90b281bf9216d2 [weak]
    Hashes of received file:
    - SHA512:2f9f9e5a1dfbae4ad624ead36e53f29192e0cc89d90d5f659ac330989560b2e6b822de820c54349c3a2d2e90d3d524ac902f6cadffa6ce888a6211979fd95553
    - SHA256:1725ce5414bdef5adabd725caca33af1253ffa0405122c2c3715c39e500648a5
    - SHA1:8767c794a044244d6baa35c3dbe4f3697221da07 [weak]
    - MD5Sum:2820433296bbc691ac90b281bf9216d2 [weak]
    - Filesize:659166 [weak]
    Last modification reported: Tue, 28 Sep 2021 06:10:47 +0000
    Release file created at: Thu, 30 Sep 2021 07:41:06 +0000
    Get:25 http://ftp.ports.debian.org/debian-ports unstable/main all
    Packages [9,323 kB]
    Reading package lists... Done
    E: The repository 'http://ftp.ports.debian.org/debian-ports
    unstable-debug Release' does not have a Release file.
    N: Updating from such a repository can't be done securely, and is
    therefore disabled by default.
    N: See apt-secure(8) manpage for repository creation and user
    configuration details.
    E: The repository 'http://deb.debian.org/debian unreleased Release'
    does not have a Release file.
    N: Updating from such a repository can't be done securely, and is
    therefore disabled by default.
    N: See apt-secure(8) manpage for repository creation and user
    configuration details.
    E: The repository 'http://ftp.ports.debian.org/debian-ports
    experimental-debug Release' does not have a Release file.
    N: Updating from such a repository can't be done securely, and is
    therefore disabled by default.
    N: See apt-secure(8) manpage for repository creation and user
    configuration details.
    W: An error occurred during the signature verification. The repository
    is not updated and the previous index files will be used. GPG error: http://ftp.ports.debian.org/debian-ports unreleased InRelease: The
    following signatures were invalid: BADSIG 5A88D659DCB811BB Debian
    Ports Archive Automatic Signing Key (2021)
    <ftpmaster@ports-master.debian.org>

    I'm primarily concerned about the hashsum check failures. In all of the
    cases, filesize, md5, sha1, and sha256 seem to match, but sha512 differs between expected and received. I can't really imagine how this could be possible unless sha512 was just computed incorrectly either remotely or locally.

    I've searched for similar issues online, and the one advice people give is: /var/lib/apt/lists/partial/ must be corrupted, run apt clean (or: just wipe /var/lib/apt/lists/partial/) and try again. I've tried both methods of cleaning, and neither helped.

    It's worth stressing that this issue is also (somewhat) new; apt used to
    work flawlessly before on this same system.

    The issue with debootstrap, part 1
    ==================================

    To check if the previous issue is my system being in a messed up state, I've tried to bootstrap a subhurd, to check if everything would work cleanly
    there. Again, I've successfully used debootstrap to create subhurds on
    this same system before.

    The Hurd wiki page on subhurds [2] suggests the following command:

    debootstrap sid mnt/ http://httpredir.debian.org/debian

    [2]: https://www.gnu.org/software/hurd/hurd/subhurd.html

    which doesn't work (seemingly because hurd-i386 is gone from httpredir.debian.org), so I adapted it to:

    # debootstrap --no-check-gpg sid /mnt/subhurd/ http://snapshot.debian.org/archive/debian-ports/20210812T100000Z/

    (When I had debian-ports-archive-keyring installed, I've used something like --keyring=/usr/share/keyrings/debian-ports-archive-keyring.gpg instead of --no-check-gpg, to actually verify the packages being downloaded.)

    This starts downloading packages, and then errors out at:

    I: Retrieving libgcc-s1 10.2.1-6
    I: Validating libgcc-s1 10.2.1-6
    W: Retrying failed download of http://snapshot.debian.org/archive/debian-ports/20210812T100000Z/pool-hurd-i386/main/g/gcc-10/libgcc-s1_10.2.1-6_hurd-i386.deb
    W: http://snapshot.debian.org/archive/debian-ports/20210812T100000Z/pool-hurd-i386/main/g/gcc-10/libgcc-s1_10.2.1-6_hurd-i386.deb
    was corrupt
    W: Couldn't download package libgcc-s1 (ver 10.2.1-6 arch hurd-i386)
    at http://snapshot.debian.org/archive/debian-ports/20210812T100000Z/pool-hurd-i386/main/g/gcc-10/libgcc-s1_10.2.1-6_hurd-i386.deb

    then later the same thing for libstdc++6; the rest of the packages get downloaded successfully and pass the validation.

    That surely looks like something's broken about the repos, and not in my system!

    The issue with debootstrap, part 2
    ==================================

    If I attempt to use the latest packages instead of the 20210812 snapshot, namely

    # debootstrap --no-check-gpg sid /mnt/subhurd/ http://deb.debian.org/debian-ports

    I get a different error. It succeeds at downloading and verifying
    packages, and errors out at:

    I: Configuring libc-bin...
    W: Failure while configuring base packages. This will be re-attempted
    up to five times.
    W: See /mnt/subhurd/debootstrap/debootstrap.log for details (possibly
    the package rsyslog is at fault)

    The log contains the following:

    Processing triggers for libc-bin (2.32-4) ...
    Errors were encountered while processing:
    rsyslog
    dpkg: dependency problems prevent configuration of rsyslog:
    rsyslog depends on libjson-c3 (>= 0.10); however:
    Package libjson-c3 is not installed.
    rsyslog depends on liblogging-stdlog0 (>= 1.0.2); however:
    Package liblogging-stdlog0 is not installed.
    rsyslog depends on liblognorm2 (>= 1.1.2); however:
    Package liblognorm2 is not installed.

    dpkg: error processing package rsyslog (--configure):
    dependency problems - leaving unconfigured
    Errors were encountered while processing:
    rsyslog
    dpkg: dependency problems prevent configuration of rsyslog:
    rsyslog depends on libjson-c3 (>= 0.10); however:
    Package libjson-c3 is not installed.
    rsyslog depends on liblogging-stdlog0 (>= 1.0.2); however:
    Package liblogging-stdlog0 is not installed.
    rsyslog depends on liblognorm2 (>= 1.1.2); however:
    Package liblognorm2 is not installed.

    And that, again, seems to be an issue with the repos rather than with my system.

    Could somebody more Debian-proficient please take a look? Am I doing things horribly wrong? Can you reproduce this on your systems?

    Anyone?

    Sergey

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Samuel Thibault@21:1/5 to All on Thu Oct 7 23:40:03 2021
    Sergey Bugaev, le jeu. 30 sept. 2021 15:35:41 +0300, a ecrit:
    The issue with debootstrap, part 1
    ==================================

    To check if the previous issue is my system being in a messed up state, I've tried to bootstrap a subhurd, to check if everything would work cleanly there. Again, I've successfully used debootstrap to create subhurds on
    this same system before.

    The Hurd wiki page on subhurds [2] suggests the following command:

    debootstrap sid mnt/ http://httpredir.debian.org/debian

    [2]: https://www.gnu.org/software/hurd/hurd/subhurd.html

    Please always check the latest version of the wiki pages on darnassus,
    there it was fixed:

    debootstrap --keyring=/usr/share/keyrings/debian-ports-archive-keyring.gpg --extra-suites=unreleased sid chroot http://deb.debian.org/debian-ports/

    W: Retrying failed download of http://snapshot.debian.org/archive/debian-ports/20210812T100000Z/pool-hurd-i386/main/g/gcc-10/libgcc-s1_10.2.1-6_hurd-i386.deb
    W: http://snapshot.debian.org/archive/debian-ports/20210812T100000Z/pool-hurd-i386/main/g/gcc-10/libgcc-s1_10.2.1-6_hurd-i386.deb
    was corrupt
    W: Couldn't download package libgcc-s1 (ver 10.2.1-6 arch hurd-i386)
    at http://snapshot.debian.org/archive/debian-ports/20210812T100000Z/pool-hurd-i386/main/g/gcc-10/libgcc-s1_10.2.1-6_hurd-i386.deb

    then later the same thing for libstdc++6; the rest of the packages get downloaded successfully and pass the validation.

    That surely looks like something's broken about the repos, and not in my system!

    Yes, there were a couple of issues on that archive part, fixed later on,
    and not a problem when using it to install from the CDs (which have
    these packages already).

    The log contains the following:

    Processing triggers for libc-bin (2.32-4) ...
    Errors were encountered while processing:
    rsyslog
    dpkg: dependency problems prevent configuration of rsyslog:
    rsyslog depends on libjson-c3 (>= 0.10); however:
    Package libjson-c3 is not installed.

    Yes, that's why you need the unreleased part.

    Samuel

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Samuel Thibault@21:1/5 to All on Thu Oct 7 23:50:02 2021
    Hello,

    Sergey Bugaev, le jeu. 30 sept. 2021 15:35:41 +0300, a ecrit:
    $ su
    su: Authentication failure

    $ sudo echo hi
    Sorry, try again.
    Sorry, try again.
    sudo: 3 incorrect password attempts

    I have no idea about this.

    I've verified that I see the same behavior on darnassus,

    I don't see it happen on darnassus.

    Samuel

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeffrey Walton@21:1/5 to sthibault@debian.org on Thu Oct 7 23:50:02 2021
    On Thu, Oct 7, 2021 at 5:34 PM Samuel Thibault <sthibault@debian.org> wrote:

    Hello,

    Answering separately since they are completely separate issues.

    Sergey Bugaev, le jeu. 30 sept. 2021 15:35:41 +0300, a ecrit:
    - Filesize:77531148 [weak]
    - SHA512:c8108d738ef08afa9556ec395e0b8097e54f66347cce924303b6294dcfa32a4a3853b29597902372562542c7b73ca364be44234d3c0b709e992ad19fa6b566a2
    - SHA256:06de0c824e0ff3e683a5698ebd63892c34f264eff7d311a7e3a225dd894f8457
    - SHA1:4b881bd3628a18f0917b55349563fe6a95f25887 [weak]
    - MD5Sum:65d941cde7d7279bbecfe22c67ff40fa [weak]
    Hashes of received file:
    - SHA512:9fae8af5d37a72f3410c9c0c70d75c4677b9ee8933bd3a05c8cb20e59430f7b56fb060b6d0cba41a20ac0e7d878cd447a6936b740ffc3536b74afe0fd31d90bb
    - SHA256:06de0c824e0ff3e683a5698ebd63892c34f264eff7d311a7e3a225dd894f8457
    - SHA1:4b881bd3628a18f0917b55349563fe6a95f25887 [weak]
    - MD5Sum:65d941cde7d7279bbecfe22c67ff40fa [weak]
    - Filesize:77531148 [weak]

    I'm primarily concerned about the hashsum check failures. In all of the cases, filesize, md5, sha1, and sha256 seem to match, but sha512 differs between expected and received. I can't really imagine how this could be possible unless sha512 was just computed incorrectly either remotely or locally.

    That's odd indeed. Which gnumach kernel were you using? I noticed an FPU context switch bug in gnumach, possibly that was affecting only the
    sha512 implementation. It is fixed in version 2:1.8+git20210923-1.

    GnuPG released a new version today. The release notes said something
    about problems with Let's Encrypt. Maybe it affects packaging, too.

    The changes are not listed in NEWS at the moment, https://dev.gnupg.org/source/gnupg/browse/master/NEWS. But here's the
    email: https://lists.gnupg.org/pipermail/gnupg-users/2021-October/065473.html.

    Jeff

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sergey Bugaev@21:1/5 to bugaevc@gmail.com on Fri Oct 8 13:10:03 2021
    On Fri, Oct 8, 2021 at 12:56 PM Sergey Bugaev <bugaevc@gmail.com> wrote:

    On Fri, Oct 8, 2021 at 12:33 AM Samuel Thibault <sthibault@debian.org> wrote:

    Hello,

    Answering separately since they are completely separate issues.

    Thanks a lot for taking a look!

    That's odd indeed. Which gnumach kernel were you using? I noticed an FPU context switch bug in gnumach, possibly that was affecting only the
    sha512 implementation. It is fixed in version 2:1.8+git20210923-1.

    2:1.8+git20210828-1, according to 'apt policy'. I cannot install a
    different (newer) one for obvious reasons; though I should be able to
    build one from source, boot it, and if that fixes the issue, update
    properly.

    That helped! 'apt update' no longer complains about sha512 mismatches
    on my custom-built gnumach (master + the gsync_wait patch).

    Thanks a lot again! I would never suspect it has to do with the kernel.

    Sergey

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sergey Bugaev@21:1/5 to sthibault@debian.org on Fri Oct 8 12:20:01 2021
    On Fri, Oct 8, 2021 at 12:33 AM Samuel Thibault <sthibault@debian.org> wrote:

    Hello,

    Answering separately since they are completely separate issues.

    Thanks a lot for taking a look!

    That's odd indeed. Which gnumach kernel were you using? I noticed an FPU context switch bug in gnumach, possibly that was affecting only the
    sha512 implementation. It is fixed in version 2:1.8+git20210923-1.

    2:1.8+git20210828-1, according to 'apt policy'. I cannot install a
    different (newer) one for obvious reasons; though I should be able to
    build one from source, boot it, and if that fixes the issue, update
    properly. Or perhaps you happen to know of an apt flag/option to
    ignore sha512 and temporarily rely on other hashes?

    Was the FPU context bug introduced recently (as in, several months
    ago)? If it wasn't, the checksum issues must be caused by something
    else.

    Sergey

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sergey Bugaev@21:1/5 to sthibault@debian.org on Fri Oct 8 12:30:01 2021
    On Fri, Oct 8, 2021 at 12:42 AM Samuel Thibault <sthibault@debian.org> wrote:
    I've verified that I see the same behavior on darnassus,

    I don't see it happen on darnassus.

    Interesting: I've just checked and I no longer see it on darnassus
    either! But I'm 100% positive I saw it there. Could it be that
    darnassus has been updated in the meantime (between Sep 30 and today)?

    (By the way, there seems to be some issue with /home again.)

    Sergey

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sergey Bugaev@21:1/5 to sthibault@debian.org on Fri Oct 8 12:50:01 2021
    On Fri, Oct 8, 2021 at 12:38 AM Samuel Thibault <sthibault@debian.org> wrote:
    Please always check the latest version of the wiki pages on darnassus,
    there it was fixed:

    debootstrap --keyring=/usr/share/keyrings/debian-ports-archive-keyring.gpg --extra-suites=unreleased sid chroot http://deb.debian.org/debian-ports/

    I had no idea that the wiki on darnassus was different/newer! Thanks
    for letting me know!

    The log contains the following:

    Processing triggers for libc-bin (2.32-4) ...
    Errors were encountered while processing:
    rsyslog
    dpkg: dependency problems prevent configuration of rsyslog:
    rsyslog depends on libjson-c3 (>= 0.10); however:
    Package libjson-c3 is not installed.

    Yes, that's why you need the unreleased part.

    ...but that doesn't seem to have helped much:

    # debootstrap --no-check-gpg --extra-suites=unreleased sid
    /mnt/subhurd/ http://deb.debian.org/debian-ports/
    <snip>
    W: Failure while configuring base packages. This will be re-attempted
    up to five times.
    W: See /mnt/subhurd/debootstrap/debootstrap.log for details (possibly
    the package rsyslog is at fault)
    W: Failure while configuring base packages. This will be re-attempted
    up to five times.
    W: See /mnt/subhurd/debootstrap/debootstrap.log for details (possibly
    the package rsyslog is at fault)
    W: Failure while configuring base packages. This will be re-attempted
    up to five times.
    W: See /mnt/subhurd/debootstrap/debootstrap.log for details (possibly
    the package rsyslog is at fault)
    W: Failure while configuring base packages. This will be re-attempted
    up to five times.
    W: See /mnt/subhurd/debootstrap/debootstrap.log for details (possibly
    the package rsyslog is at fault)
    W: Failure while configuring base packages. This will be re-attempted
    up to five times.
    W: See /mnt/subhurd/debootstrap/debootstrap.log for details (possibly
    the package rsyslog is at fault)

    # tail -30 /mnt/subhurd/debootstrap/debootstrap.log
    dpkg: error processing package rsyslog (--configure):
    dependency problems - leaving unconfigured
    dpkg: dependency problems prevent configuration of vim-tiny:
    vim-tiny depends on vim-common (= 2:8.2.2434-3); however:
    Version of vim-common on system is 2:8.2.3455-2.

    dpkg: error processing package vim-tiny (--configure):
    dependency problems - leaving unconfigured
    Errors were encountered while processing:
    rsyslog
    vim-tiny
    dpkg: dependency problems prevent configuration of rsyslog:
    rsyslog depends on libjson-c3 (>= 0.10); however:
    Package libjson-c3 is not installed.
    rsyslog depends on liblogging-stdlog0 (>= 1.0.2); however:
    Package liblogging-stdlog0 is not installed.
    rsyslog depends on liblognorm2 (>= 1.1.2); however:
    Package liblognorm2 is not installed.

    dpkg: error processing package rsyslog (--configure):
    dependency problems - leaving unconfigured
    dpkg: dependency problems prevent configuration of vim-tiny:
    vim-tiny depends on vim-common (= 2:8.2.2434-3); however:
    Version of vim-common on system is 2:8.2.3455-2.

    dpkg: error processing package vim-tiny (--configure):
    dependency problems - leaving unconfigured
    Errors were encountered while processing:
    rsyslog
    vim-tiny

    Sergey

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Samuel Thibault@21:1/5 to All on Fri Oct 8 13:30:01 2021
    Sergey Bugaev, le ven. 08 oct. 2021 12:56:01 +0300, a ecrit:
    Or perhaps you happen to know of an apt flag/option to
    ignore sha512 and temporarily rely on other hashes?

    You can as well just download the .deb files yourself and dpkg -i them.

    Was the FPU context bug introduced recently (as in, several months
    ago)? If it wasn't, the checksum issues must be caused by something
    else.

    Depends what you call "recent". The bug was introduced around
    novembre 2020. But was could also be "recent" would be the use of SSE instructions in the sha512 algorithm.

    Samuel

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sergey Bugaev@21:1/5 to sthibault@debian.org on Fri Oct 8 13:50:04 2021
    On Fri, Oct 8, 2021 at 2:20 PM Samuel Thibault <sthibault@debian.org> wrote:
    That's because vim is currently failing to build, and thus we get
    trapped again by the version difference between vim and vim-common.

    "Unstable" has its name for a reason :)

    Even ignoring vim for a second (I could/should attempt to exclude it
    'cause I don't use it anyways), the "syslog depends on {libjson-c3,liblogging-stdlog0,liblognorm2}" still happens with
    unreleased. That is, adding unreleased only increased the number of
    issues (adding vim).

    Sergey

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Samuel Thibault@21:1/5 to All on Fri Oct 8 13:50:05 2021
    Sergey Bugaev, le ven. 08 oct. 2021 14:25:38 +0300, a ecrit:
    On Fri, Oct 8, 2021 at 2:20 PM Samuel Thibault <sthibault@debian.org> wrote:
    That's because vim is currently failing to build, and thus we get
    trapped again by the version difference between vim and vim-common.

    "Unstable" has its name for a reason :)

    Even ignoring vim for a second (I could/should attempt to exclude it
    'cause I don't use it anyways), the "syslog depends on {libjson-c3,liblogging-stdlog0,liblognorm2}" still happens with
    unreleased. That is, adding unreleased only increased the number of
    issues (adding vim).

    I don't see how adding unreleased can have an impact on vim, since
    unreleased doesn't contain anything about vim.

    About syslog, indeed debootstrap would need to be taught that it should
    take it from unreleased rather than from unstable. In the debian
    installer case, we use the apt resolver to put on the CD image the
    version that is actually installable, and then debootstrap doesn't have
    the choice and can thus install. That said, the buildd chroots can get
    built fine with debootstrap without any particular tinkering, that's
    probably because we use --variant=buildd there, which thus doesn't even
    try to install rsyslog.

    Samuel

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Amos Jeffries@21:1/5 to Sergey Bugaev on Fri Oct 8 16:10:02 2021
    On 9/10/21 12:25 am, Sergey Bugaev wrote:
    On Fri, Oct 8, 2021 at 2:20 PM Samuel Thibault <sthibault@debian.org> wrote:
    That's because vim is currently failing to build, and thus we get
    trapped again by the version difference between vim and vim-common.

    "Unstable" has its name for a reason :)

    Even ignoring vim for a second (I could/should attempt to exclude it
    'cause I don't use it anyways), the "syslog depends on {libjson-c3,liblogging-stdlog0,liblognorm2}" still happens with
    unreleased. That is, adding unreleased only increased the number of
    issues (adding vim).

    Sergey


    Please remember that Debian had a release and un-freeze of sid/unstable
    this year. There is a relatively large amount of transitions currently
    trying to all happen at once. As a result the package dependencies are
    changing almost every half hour.

    One weird issue I have found is that the some Hurd dependencies interact
    with the Python2 removal going on. To unblock those without waiting for
    the whole transition I had to manually remove the "python" package and
    install the "python-is-python2" package. The end result is a
    functionally unchanged system, but with a bump in the versions.

    Amos

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Braun@21:1/5 to Sergey Bugaev on Fri Oct 8 17:10:01 2021
    On Fri, Oct 08, 2021 at 01:09:38PM +0300, Sergey Bugaev wrote:
    On Fri, Oct 8, 2021 at 12:42 AM Samuel Thibault <sthibault@debian.org> wrote:
    I've verified that I see the same behavior on darnassus,

    I don't see it happen on darnassus.

    Interesting: I've just checked and I no longer see it on darnassus
    either! But I'm 100% positive I saw it there. Could it be that
    darnassus has been updated in the meantime (between Sep 30 and today)?

    It most likely has, yes.

    (By the way, there seems to be some issue with /home again.)

    Ugh. I'm not available to fix them right now, but I'll check next week.

    --
    Richard Braun

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sergey Bugaev@21:1/5 to the Hurd rather than Debian. The wi on Fri Oct 8 18:40:02 2021
    Ignoring both syslog and vim did the trick! The final command was:

    # debootstrap --keyring=/usr/share/keyrings/debian-ports-archive-keyring.gpg --extra-suites=unreleased --exclude vim,vim-tiny,rsyslog sid
    /tmp/subhurd/ http://deb.debian.org/debian-ports/

    Now, I ran into another issue, which is this time actually related to
    the Hurd rather than Debian. The wiki page on subhurds says:

    To create a file my.image of size 2 gigabytes, do
    $ dd if=/dev/zero of=my.image bs=1M count=1 seek=2000
    (Note that it is currently problematic to create files larger than 2 gigabytes this way.)

    and that's what I have done previously. This time I thought I'd be
    clever and create the 2GB file using truncate(1) instead of dd(1),
    which resulted in my newly installed subhurd refusing to boot:

    ext2fs: pseudo-root: panic: main: device too small for superblock
    (-2147483648 bytes)

    And yet the same file is perfectly mountable with the very same
    ext2fs.static binary outside of the subhurd boot process. What gives?

    So I've traced what causes this issue; dumping it here so it doesn't get lost:

    2 GB (2 * 1024³, as opposed to whatever 2000 * 1M means) is just
    enough to wrap around a signed 32-bit integer, giving -2147483648.
    ext2fs uses libstore to access the fs image. libstore uses 64-bit
    sizes.

    libstore's file backend sets the block size to 1, and size to st_size.
    Its device backend queries the device size using device_get_status (DEV_GET_RECORDS), which returns size / block size in two (32-bit)
    ints! How's it not an issue in all other cases, e.g. how come my main
    Hurd box even boots? Well, normally block ("record") size is something
    like 512, so the minimum device size to cause wraparound is 1204 GB (2
    * 1024³ 512-byte blocks). Not that unrealistically large though.

    When running a subhurd, boot(1) presents it with a pseudo-root device
    that supports device.defs RPCs and is backed by another store on the
    host. When queried for DEV_GET_RECORDS, boot(1) responds with
    libstore's idea of block size and size in blocks. Which in case of a 2
    GB regular file is (1, 2 * 1024³), which wraps around the 32-bit
    integer. Boom.

    A low-hanging-fruit fix would be to treat the size as unsigned in
    libstore (and all other users of device_get_status), this would get us
    to 4 GB & 2048 GB. It should also be possible for boot(1) to emulate a
    block size of 512 (or something) instead of blindly forwarding what it
    gets from libstore; but I'm not sure how that would work if the file
    size is not divisible by 512. A proper fix would be to extend
    device_get_status () to support sizes that don't fit into a single
    32-bit int; perhaps by using a third int and a new "flavor".

    Hope this makes sense.

    Sergey

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Samuel Thibault@21:1/5 to All on Fri Oct 8 20:00:01 2021
    Sergey Bugaev, le ven. 08 oct. 2021 19:17:33 +0300, a ecrit:
    A proper fix would be to extend
    device_get_status () to support sizes that don't fit into a single
    32-bit int; perhaps by using a third int and a new "flavor".

    That's the "Extend `device_read`/`device_write` into supporting > 2TiB
    disk sizes." item in the "small hack entries" list. There's indeed the device_get_status() call that needs fixing, but device_read/write as
    well, they need to be extended to 64bit record numbers.

    Samuel

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Samuel Thibault@21:1/5 to All on Fri Oct 8 20:10:01 2021
    Sergey Bugaev, le ven. 08 oct. 2021 21:01:09 +0300, a ecrit:
    On Fri, Oct 8, 2021 at 8:49 PM Samuel Thibault <sthibault@debian.org> wrote:
    That's the "Extend `device_read`/`device_write` into supporting > 2TiB
    disk sizes." item in the "small hack entries" list. There's indeed the device_get_status() call that needs fixing, but device_read/write as
    well, they need to be extended to 64bit record numbers.

    Right. But 2 GB for a subhurd is a much more severe limitation than 2 TB.

    I wonder if it'd be possible to change device_{read,write} to use a
    64-bit integer without introducing separate new RPCs,

    No: RPC interfaces have fixed typing, expressed in the mig files.

    Trying to magically extent is asking for much more trouble than just
    adding the new RPCs.

    Samuel

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sergey Bugaev@21:1/5 to sthibault@debian.org on Fri Oct 8 20:20:01 2021
    On Fri, Oct 8, 2021 at 8:49 PM Samuel Thibault <sthibault@debian.org> wrote:
    That's the "Extend `device_read`/`device_write` into supporting > 2TiB
    disk sizes." item in the "small hack entries" list. There's indeed the device_get_status() call that needs fixing, but device_read/write as
    well, they need to be extended to 64bit record numbers.

    Right. But 2 GB for a subhurd is a much more severe limitation than 2 TB.

    I wonder if it'd be possible to change device_{read,write} to use a
    64-bit integer without introducing separate new RPCs, and
    convince/extend MIG to also accept messages with 32-bit ints for
    compatibility.

    Sergey

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Vasileios Karaklioumis@21:1/5 to bugaevc@gmail.com on Fri Oct 8 21:20:02 2021
    Separate seems a cleaner solution.
    We could deprecate it down the line.

    On Fri, Oct 8, 2021, 22:15 Sergey Bugaev <bugaevc@gmail.com> wrote:

    On Fri, Oct 8, 2021 at 9:03 PM Samuel Thibault <sthibault@debian.org>
    wrote:
    Sergey Bugaev, le ven. 08 oct. 2021 21:01:09 +0300, a ecrit:
    I wonder if it'd be possible to change device_{read,write} to use a 64-bit integer without introducing separate new RPCs,

    No: RPC interfaces have fixed typing, expressed in the mig files.

    RPC interfaces are whatever we want them to be :) — as long as we keep things compatible with old clients. Specifically, we could say,

    type recnum_t = uint64_t | array[*:2] of uint32_t;

    and voila, (new) clients send 64-bit numbers, but the servers can accept either.

    I'm more concerned that it would change glibc ABI, as clients would
    now be expected to pass 64-bit numbers.

    Trying to magically extent is asking for much more trouble than just
    adding the new RPCs.

    I'm not saying that I'm convinced that it's worth it — perhaps adding
    new RPCs and switching all users to them would be easier. But it's an interesting possibility.

    Sergey



    <div dir="auto">Separate seems a cleaner solution.<div dir="auto">We could deprecate it down the line.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 8, 2021, 22:15 Sergey Bugaev &lt;<a href="mailto:bugaevc@gmail.
    com">bugaevc@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Oct 8, 2021 at 9:03 PM Samuel Thibault &lt;<a href="mailto:sthibault@debian.org" target="_blank"
    rel="noreferrer">sthibault@debian.org</a>&gt; wrote:<br>
    &gt; Sergey Bugaev, le ven. 08 oct. 2021 21:01:09 +0300, a ecrit:<br>
    &gt; &gt; I wonder if it&#39;d be possible to change device_{read,write} to use a<br>
    &gt; &gt; 64-bit integer without introducing separate new RPCs,<br>
    &gt;<br>
    &gt; No: RPC interfaces have fixed typing, expressed in the mig files.<br>

    RPC interfaces are whatever we want them to be :) — as long as we keep<br> things compatible with old clients. Specifically, we could say,<br>

    type recnum_t = uint64_t | array[*:2] of uint32_t;<br>

    and voila, (new) clients send 64-bit numbers, but the servers can accept either.<br>

    I&#39;m more concerned that it would change glibc ABI, as clients would<br>
    now be expected to pass 64-bit numbers.<br>

    &gt; Trying to magically extent is asking for much more trouble than just<br> &gt; adding the new RPCs.<br>

    I&#39;m not saying that I&#39;m convinced that it&#39;s worth it — perhaps adding<br>
    new RPCs and switching all users to them would be easier. But it&#39;s an<br> interesting possibility.<br>

    Sergey<br>

    </blockquote></div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sergey Bugaev@21:1/5 to bugaevc@gmail.com on Fri Oct 8 21:30:02 2021
    On Fri, Oct 8, 2021 at 9:57 PM Sergey Bugaev <bugaevc@gmail.com> wrote:
    type recnum_t = uint64_t | array[*:2] of uint32_t;

    Hm, no, that wouldn't actually work, it's still a type mismatch. And 'polymorphic' is not polymorphic enough. type recnum_t = array[*:2] of
    uint32_t would work, but that changes libc *API*, at which point it's
    _really_ not worth it. Fine.

    Sergey

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sergey Bugaev@21:1/5 to sthibault@debian.org on Fri Oct 8 21:20:02 2021
    On Fri, Oct 8, 2021 at 9:03 PM Samuel Thibault <sthibault@debian.org> wrote:
    Sergey Bugaev, le ven. 08 oct. 2021 21:01:09 +0300, a ecrit:
    I wonder if it'd be possible to change device_{read,write} to use a
    64-bit integer without introducing separate new RPCs,

    No: RPC interfaces have fixed typing, expressed in the mig files.

    RPC interfaces are whatever we want them to be :) — as long as we keep
    things compatible with old clients. Specifically, we could say,

    type recnum_t = uint64_t | array[*:2] of uint32_t;

    and voila, (new) clients send 64-bit numbers, but the servers can accept either.

    I'm more concerned that it would change glibc ABI, as clients would
    now be expected to pass 64-bit numbers.

    Trying to magically extent is asking for much more trouble than just
    adding the new RPCs.

    I'm not saying that I'm convinced that it's worth it — perhaps adding
    new RPCs and switching all users to them would be easier. But it's an interesting possibility.

    Sergey

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Samuel Thibault@21:1/5 to All on Sat Oct 9 16:10:02 2021
    Richard Braun, le ven. 08 oct. 2021 16:55:30 +0200, a ecrit:
    On Fri, Oct 08, 2021 at 01:09:38PM +0300, Sergey Bugaev wrote:
    On Fri, Oct 8, 2021 at 12:42 AM Samuel Thibault <sthibault@debian.org> wrote:
    I've verified that I see the same behavior on darnassus,

    I don't see it happen on darnassus.

    Interesting: I've just checked and I no longer see it on darnassus
    either! But I'm 100% positive I saw it there. Could it be that
    darnassus has been updated in the meantime (between Sep 30 and today)?

    It most likely has, yes.

    (By the way, there seems to be some issue with /home again.)

    Ugh. I'm not available to fix them right now, but I'll check next week.

    I have fscked+remounted it.

    Samuel

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Samuel Thibault@21:1/5 to All on Sun Oct 10 16:40:03 2021
    Sergey Bugaev, le dim. 10 oct. 2021 17:20:23 +0300, a ecrit:
    $ nm -D /usr/lib/i386-gnu/libkrb5.so.3 | grep krb5int_c_combine_keys
    U krb5int_c_combine_keys@k5crypto_3_MIT

    Which version do you have?

    $ nm -D /usr/lib/i386-gnu/libkrb5.so.3 | grep krb5int_c_combine_keys
    $
    $ dpkg -l libkrb5-3:hurd-i386
    ii libkrb5-3:hurd-i386 1.18.3-7 hurd-i386 MIT Kerberos runtime libraries

    Samuel

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sergey Bugaev@21:1/5 to All on Sun Oct 10 16:40:03 2021
    I've done some debugging of the sudo / PAM issue, here's where I'm at:

    Thread 4 hit Breakpoint 4, __dlopen (file=0x100169e0 "/lib/i386-gnu/security/pam_unix.so", mode=2) at dlopen.c:75
    75 in dlopen.c
    (gdb) finish
    Run till exit from #0 __dlopen (file=0x100169e0 "/lib/i386-gnu/security/pam_unix.so", mode=2) at dlopen.c:75
    warning: Temporarily disabling breakpoints for unloaded shared library "/lib/i386-gnu/security/pam_unix.so"
    0x017fed7a in ?? () from /lib/i386-gnu/libpam.so.0
    Value returned is $1 = (void *) 0x0
    (gdb) p dlerror()
    $2 = 0x100184f0 "/usr/lib/i386-gnu/libkrb5.so.3: undefined symbol: krb5int_c_combine_keys, version k5crypto_3_MIT"
    (gdb)

    $ nm -D /usr/lib/i386-gnu/libkrb5.so.3 | grep krb5int_c_combine_keys
    U krb5int_c_combine_keys@k5crypto_3_MIT
    $ nm -D /usr/lib/i386-gnu/libk5crypto.so | grep krb5int_c_
    00019c00 T krb5int_c_copy_keyblock@@k5crypto_3_MIT
    00019b80 T krb5int_c_copy_keyblock_contents@@k5crypto_3_MIT
    00017300 T krb5int_c_deprecated_enctype@@k5crypto_3_MIT
    00019b50 T krb5int_c_free_keyblock@@k5crypto_3_MIT
    00019b00 T krb5int_c_free_keyblock_contents@@k5crypto_3_MIT
    00019a50 T krb5int_c_init_keyblock@@k5crypto_3_MIT
    0001a700 T krb5int_c_mandatory_cksumtype@@k5crypto_3_MIT
    000172a0 T krb5int_c_weak_enctype@@k5crypto_3_MIT

    (As always, sorry in advance for Gmail forcefully wrapping those lines :( )

    Does that ring any bells by any chance?

    Sergey

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Samuel Thibault@21:1/5 to All on Mon Oct 11 13:40:01 2021
    Sergey Bugaev, le lun. 11 oct. 2021 14:09:50 +0300, a ecrit:
    $ file /usr/lib/i386-gnu/libkrb5.so.3
    /usr/lib/i386-gnu/libkrb5.so.3: symbolic link to libkrb5.so.3.3~0

    That looks like a leftover of something

    $ dpkg -S /usr/lib/i386-gnu/libkrb5.so.3.3~0
    dpkg-query: no path found matching pattern /usr/lib/i386-gnu/libkrb5.so.3.3~0

    I don't know what to make of that.

    Perhaps just

    apt install --reinstall libkrb5-3

    so that it reinstalls the libkrb5.so.3 symlink (which in version
    1.18.3-7 is supposed to point to libkrb5.so.3.3).

    Samuel

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sergey Bugaev@21:1/5 to sthibault@debian.org on Mon Oct 11 13:30:01 2021
    On Sun, Oct 10, 2021 at 5:38 PM Samuel Thibault <sthibault@debian.org> wrote:
    Which version do you have?

    Seemingly the same 1.18.3-7 as you do:

    $ dpkg -l libkrb5-3:hurd-i386
    Desired=Unknown/Install/Remove/Purge/Hold
    | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
    ||/ Name Version Architecture Description +++-===================-============-============-=================================
    ii libkrb5-3:hurd-i386 1.18.3-7 hurd-i386 MIT Kerberos runtime libraries
    $ apt policy libkrb5-3:hurd-i386
    libkrb5-3:
    Installed: 1.18.3-7
    Candidate: 1.18.3-7
    Version table:
    *** 1.18.3-7 500
    500 http://ftp.ports.debian.org/debian-ports unstable/main
    hurd-i386 Packages
    500 http://deb.debian.org/debian-ports unstable/main hurd-i386 Packages
    100 /var/lib/dpkg/status
    1.18.3-6 500
    500 http://snapshot.debian.org/archive/debian-ports/20210812T100000Z sid/main hurd-i386 Packages

    However, I've noticed that

    $ file /usr/lib/i386-gnu/libkrb5.so.3
    /usr/lib/i386-gnu/libkrb5.so.3: symbolic link to libkrb5.so.3.3~0
    $ dpkg -S /usr/lib/i386-gnu/libkrb5.so.3.3~0
    dpkg-query: no path found matching pattern /usr/lib/i386-gnu/libkrb5.so.3.3~0

    I don't know what to make of that.

    Sergey

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sergey Bugaev@21:1/5 to sthibault@debian.org on Mon Oct 11 18:00:02 2021
    On Mon, Oct 11, 2021 at 1:31 PM Samuel Thibault <sthibault@debian.org> wrote:
    Perhaps just

    apt install --reinstall libkrb5-3

    so that it reinstalls the libkrb5.so.3 symlink (which in version
    1.18.3-7 is supposed to point to libkrb5.so.3.3).

    That didn't help:

    # apt install --reinstall libkrb5-3
    Reading package lists... Done
    Building dependency tree... Done
    Reading state information... Done
    0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 1 not upgraded. Need to get 384 kB of archives.
    After this operation, 0 B of additional disk space will be used.
    Get:1 http://ftp.ports.debian.org/debian-ports unstable/main hurd-i386 libkrb5-3 hurd-i386 1.18.3-7 [384 kB]
    Fetched 384 kB in 3s (126 kB/s)
    (Reading database ... 129994 files and directories currently installed.) Preparing to unpack .../libkrb5-3_1.18.3-7_hurd-i386.deb ...
    Unpacking libkrb5-3:hurd-i386 (1.18.3-7) over (1.18.3-7) ...
    Setting up libkrb5-3:hurd-i386 (1.18.3-7) ...
    Processing triggers for libc-bin (2.32-4) ...

    $ sudo echo hi
    Sorry, try again.
    Sorry, try again.
    sudo: 3 incorrect password attempts
    $ file /usr/lib/i386-gnu/libkrb5.so.3
    /usr/lib/i386-gnu/libkrb5.so.3: symbolic link to libkrb5.so.3.3~0

    Could this be an effect of some "diversion"? How do I check?

    Sergey

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sergey Bugaev@21:1/5 to sthibault@debian.org on Mon Oct 11 18:10:02 2021
    On Mon, Oct 11, 2021 at 6:41 PM Samuel Thibault <sthibault@debian.org> wrote:
    Diversions show up in /var/lib/dpkg/diversions.

    There's nothing about libkrb5 in there :|

    Are there any other tools left to investigate why dpkg is fine with
    this, and where libkrb5.so.3.3~0 comes from? Should I just forcefully
    delete libkrb5.so.3.3~0 along with the symlink, and reinstall the
    package again?

    Sergey

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Samuel Thibault@21:1/5 to All on Mon Oct 11 17:40:02 2021
    Sergey Bugaev, le lun. 11 oct. 2021 18:36:26 +0300, a ecrit:
    $ file /usr/lib/i386-gnu/libkrb5.so.3
    /usr/lib/i386-gnu/libkrb5.so.3: symbolic link to libkrb5.so.3.3~0

    Could this be an effect of some "diversion"? How do I check?

    Diversions show up in /var/lib/dpkg/diversions.

    Samuel

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Samuel Thibault@21:1/5 to All on Mon Oct 11 18:00:01 2021
    Sergey Bugaev, le lun. 11 oct. 2021 18:44:10 +0300, a ecrit:
    On Mon, Oct 11, 2021 at 6:41 PM Samuel Thibault <sthibault@debian.org> wrote:
    Diversions show up in /var/lib/dpkg/diversions.

    There's nothing about libkrb5 in there :|

    Are there any other tools left to investigate why dpkg is fine with
    this, and where libkrb5.so.3.3~0 comes from? Should I just forcefully
    delete libkrb5.so.3.3~0 along with the symlink, and reinstall the
    package again?

    I don't know.

    Samuel

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)