Migrating glibc 2.34

Foundations
1

Hi everyone,

glibc is in impish-proposed now and the autopkgtests have all completed. As usual there are a bunch of failures, some glibc related and some not but all need attention before it can migrate to release.

The idea of this thread is to keep track of status and knowledge about the failures. If you can edit this post, feel free to edit the status directly in, if not just comment below.

Current issues

Fixed issues

  • aspectc++/1:2.3-4 – @jawn-smith , seems to be some kind of gcc / glibc incompatibility? EDIT: I now thing it’s llvm-toolchain incompatibility. currently testing upstream patch from llvm
  • apport/2.20.11-0ubuntu67 – Brian Murray is looking at this
  • astropy/4.2-6 – https://bugs.launchpad.net/ubuntu/+source/astropy/+bug/1940322 has a patch that has been uploaded.
  • bazel-bootstrap/3.5.1+ds-3ubuntu1 – hinted by @vorlon
  • boost1.71/1.71.0-6ubuntu12 – I uploaded a fix but it seems an incomplete one.
  • chrony/4.1-1ubuntu1
  • deal.ii/9.3.0-1~exp1 – ginggs (no-change rebuild)
  • delve/1.6.0-1 - dbungert – fixed in upstream 1.7, synced package in proposed
  • dh-ada-library/7.3 – hinted. doko investigating lto issues.
  • dolfin/2019.2.0~git20201207.b495043-5 – ginggs (patched vendored catch.hpp)
  • fclib/3.1.0+dfsg-2 – doko
  • fenicsx-performance-tests/0.0~git20210119.80e82ac-1 – ginggs (should be fixed by dolfinx upload)
  • foonathan-memory/0.7-3 – ginggs (should be fixed by catch2 upload)
  • fpc/3.2.2+dfsg-1ubuntu1 – ginggs https://bugs.launchpad.net/bugs/1940070
  • hera/0~git20200602+dfsg-3 – ginggs (should be fixed by catch2 upload)
  • libdata-clone-perl/0.004-2build3
  • liborcus/0.16.1-3build2 GCC11 issue fixed in 0.16.1-4
  • libproxy/0.4.17-1 (autopkgtest failed on amd64, passed on retry)
  • libqb/2.0.3-1
  • librsvg/2.50.7+dfsg-1 (i386 was failing, retriggered and passed)
  • libuev/2.3.1-1 – @mwhudson uploaded a fix but it ftbfs on armhf, fix for that now uploaded
  • libzeep/5.0.2-3
  • oomd/0.4.0-1build1
  • openmsx/17.0-1ubuntu1 – ginggs (patched vendored catch.hpp)
  • openzwave/1.6.1545+ds-2 - @waveform
  • pyfuse3/3.2.0-2build1 - dbungert
  • r-cran-sys/3.4-1 armhf only – this is an infrastructure issue around images, this should be hinted if this is the only thing blocking migration
  • securefs/0.11.1+ds-3ubuntu2 – ginggs (should be fixed by catch upload)
  • siconos/4.3.1+dfsg-2 – ginggs (no-change rebuild)
  • spdlog/1:1.8.1+ds-2.1 – ginggs (patched vendored catch.hpp)
  • sra-sdk/2.10.9+dfsg-2
  • syncthing/1.12.1~ds1-4 – jawn-smith
  • wcc/0.0.2+dfsg-4.1build1 – jawn-smith
  • wmanager/0.3.0-2 – schopin
1 Like
3

I’ve not yet looked into it as I seem to have too many pre-FF fixes to make.
But out of experience (2 out of 3 of last cycles late glibc update) this quite likely is glibc making changes which syscalls libc functions eventually issue and that really breaks chrony which by default runs sandboxed with a seccomp allow-list.
Thereby this usually is real breakage (the service isn’t usable anymore) and thereby needs to be fixed before allowing libc to migrate.

It usually comes down to throw things in a VM to see what it breaks on, extending the list, discussing upstream for acceptance and then uploading it as Delta to our version. Unfortunately most of the time these changes are ppc64 or armhf which are harder to come by (emulation slow, systemc rare).

I’ll put it on my todo-list, but as I said it is a long list these days. If anyone else gets to work on it please let me know of any progress you made.

update
Debugging indeed show new syscalls as assumed, gladly this time the fix already is merged upstream and I can prep an upload based on that.
Spawned this bug to track it

update 2
Test works now, test is green (also triggered gnutls28 vs the new chrony which hit the same issue), now chrony is blocked by glibc as one would expect. It is already striked throughin the list above - so this is thereby complete.

4

edflib/1.19-1 and jmtpfs/0.5-3 should drop off the list of test regressions when a new excuses is generated. jmtpfs had a test that appeared to have died, but stuck on the ‘running’ page (reached 118hrs so far), while the edflib tests seemed to have vanished into nothing. Both passed rapidly on a retry.

5

I’ve removed edflib and jmtpfs - thanks!

6

There seems to be a generic issue with dkms modules on armhf (e.g. https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/armhf/x/xtables-addons/20210816_083905_62156@/log.gz) does anyone know what that’s about? (It doesn’t seem to be glibc related)

7

Removed the following packages from the list because they are regressed in release and have been hinted:

asmjit
commblas
crash
devscripts
gvfs
igraph
iptables-netflow
jool
langford
libcifpp
libpdb-redo
libvpoll-eventfd
log4shib
mathicgb
open3d
openlibm
rna-star
rust-debcargo
shibboleth-sp
sysdig
systemc
tpm-pkcs11
west-chamber
xmltooling
xtables-addons

The vast majority of these are regressions introduced by the gcc update (either C++17 incompatibilities or regressions related to the armhf default target) and are therefore tracked elsewhere.

None of these should be on the critical path for updating glibc in release.