zrepl 0.6.1 requires too-new glibc symbols

[notr1ch]

Attempting to upgrade from 0.6.0 to 0.6.1 on Debian Stretch using the https://zrepl.cschwarz.com/apt/debian stretch main repository results in a broken binary:

/usr/bin/zrepl: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /usr/bin/zrepl)

I'm guessing the Go toolchain upgraded the minimum required glibc version? And yes, I'm aware Stretch is very much EOL, if 0.6.0 is the last version that works with it that's fine.

[problame]

Hm, yeah, that shouldn't happen.

Not sure how to handle this, all the Debian repositories currently use the same set of packages, i.e., I build with latest Go, than wrap it into one .deb and serve that .deb for all the releases.

The simplest solution for me would be to delete the stretch repository alltogether.
Any better suggestions?

[problame]

Turned https://zrepl.cschwarz.com/apt/debian/dists/stretch/ into 404 server-side to prevent any more immediate damage to other users.

I think it should be safe for you to

1. use a newer release name in your apt lists config
2. apt update
3. install zrepl 0.6.0 (it's still served by the repo).

Since it's all the same .deb under the hood anyways, that should fix your setup.

Alternatively, just download the .deb manually and install it.

https://zrepl.cschwarz.com/apt/debian/pool/main/z/zrepl/zrepl_0.6.0_amd64.deb

[problame]

Just tested that buster supports the 0.6.1 build.

So, I think that settles it for me. I'll stop hosting the stretch repository. Sorry for the breakage!

[problame]

FYI de-published reposfor several other EOL distros as well:

 DISTS=()
-DISTS+=("-distribution=kinetic $REPONAME :ubuntu")
 DISTS+=("-distribution=jammy   $REPONAME :ubuntu")
-DISTS+=("-distribution=impish  $REPONAME :ubuntu")
-DISTS+=("-distribution=hirsute $REPONAME :ubuntu")
-DISTS+=("-distribution=groovy  $REPONAME :ubuntu")
 DISTS+=("-distribution=focal   $REPONAME :ubuntu")
-DISTS+=("-distribution=eoan    $REPONAME :ubuntu")
-DISTS+=("-distribution=disco   $REPONAME :ubuntu")
 DISTS+=("-distribution=bionic  $REPONAME :ubuntu")
 
 DISTS+=("-distribution=bookworm  $REPONAME :debian")
 DISTS+=("-distribution=bullseye  $REPONAME :debian")
 DISTS+=("-distribution=buster    $REPONAME :debian")
-DISTS+=("-distribution=stretch   $REPONAME :debian")

[cf-sewe]

The same issue occurs with Rocky Linux 8 (RHEL 8.x).
It seems the RPMS built on fedora:latest are incompatible with RHEL 8.x.

$ uname -a
Linux cplace-integrated 4.18.0-477.15.1.el8_8.x86_64 #1 SMP Wed Jun 28 15:04:18 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

$ dnf update
Last metadata expiration check: 0:38:09 ago on Wed 04 Oct 2023 01:19:49 PM CEST.
Error:
 Problem: cannot install the best update candidate for package zrepl-v0.6.0-1.x86_64
  - nothing provides libc.so.6(GLIBC_2.34)(64bit) needed by zrepl-v0.6.1-1.x86_64
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

[problame]

It seems the RPMS built on fedora:latest are incompatible with RHEL 8.x.

Hm, should I map the entire RPM repo to 404 until I have time to look into this?
I don't think so, because dnf detects the problem before any damage is done, right?

[cf-sewe]

Hm, should I map the entire RPM repo to 404 until I have time to look into this?

I think you can leave it as it is for now. There is no damage done.
It is quite easy also to deactivate simply the zrepl repo for now via dnf disablerepo zrepl.

But I assume fixing it wont be so easy, because you might need to provide multiple versions of the RPM per distribution version now.

[Debilski]

Running into the same problem on Debian bullseye.

# apt policy libc6
libc6:
  Installed: 2.31-13+deb11u7
  Candidate: 2.31-13+deb11u7
  Version table:
 *** 2.31-13+deb11u7 500
        500 http://security.debian.org/debian-security bullseye-security/main amd64 Packages
        100 /var/lib/dpkg/status
     2.31-13+deb11u6 500
        500 http://ftp.de.debian.org/debian bullseye/main amd64 Packages
     2.31-13+deb11u5 500
        500 http://ftp.de.debian.org/debian bullseye-updates/main amd64 Packages

[notr1ch]

From the discussion at golang/go#58550, it seems Go targets whatever glibc is in use on the host system during the build. Using a CI environment with an older OS image might help create a more portable binary for distribution.

Disabling CGO to get a purely static binary may also be an option, I don't think zrepl would be affected by the nuances between glibc and Go for things like DNS resolution but I don't use Go enough to say for sure.

[problame]

I just pushed CGO_ENABLED=0 re-build of v0.6.1 into the APT and RPM repositories.
They use a bumped package release number, so, the next apt update or dnf update will prefer them over the initial 0.6.1 release.

[cf-sewe]

I just pushed CGO_ENABLED=0 re-build of v0.6.1 into the APT and RPM repositories.

Thank you! I can confirm that the new build works on Rocky Linux 8.8.