Upcoming upload of glibc 2.40

Simon Chopin simon.chopin at canonical.com
Wed Jul 31 15:29:43 UTC 2024


Howdy folks!

It is that time of the cycle when I announce the upcoming upload of
glibc 2.40 to the archive.

TL;DR: small release, look out for utmp vs i386, and rseq. I plan to
upload next week (Monday or Tuesday).

For the newcomers, this has historically been a fairly disruptive
activity for two reasons:

* Pretty much every arch:any binary package is a direct
  reverse-dependency of
  libc6, which means its autopkgtests are triggered and must not
  regress. This results in queues blowing up and a lot of retrying and
  baseline tests to find the actual regressions.
* If a package is uploaded *after* glibc it might pick up a versioned
  dependency on one of the new symbols. That usually happens if you're
  on the bleeding edge, e.g. systemd, or if the upstream glibc decided
  to introduce a new ABI for an existing symbol. If you have a versioned
  dependency, you'll have to wait for glibc to migrate, which can take a
  looong while.

However, this time around I'm hoping the disruptions will be benign. For
the issue with long queues, the nice folks over at #ubuntu-quality have
been improving the infrastructure quite a bit. For the new symbols
problem, the only new symbols are some C23 math functions in libm.so, so
it is highly unlikely your packages are using them already.

The full upstream changelog is at

https://sourceware.org/git/?p=glibc.git;a=tag;h=e6e432d7a0a7c17e381acc42b312ad7029b53ab3

Of notable interest are the following items

* Architectures which use a 32-bit seconds-since-epoch field in struct
  lastlog, struct utmp, struct utmpx (such as i386, powerpc64le, rv32,
  rv64, x86-64) switched from a signed to an unsigned type for that
  field.  This allows these fields to store timestamps beyond the year
  2038, until the year 2106.  Please note that applications are still
  expected to migrate off the interfaces declared in <utmp.h> and
  <utmpx.h> (except for login_tty) due to locking and session management
  problems.

-> We still have ONE architecture affected by this, i386.

* __rseq_size now denotes the size of the active rseq area (20 bytes
  initially), not the size of struct rseq (32 bytes initially).

-> rseq support was introduced in 2.35, which is the version we shipped
in Jammy. I'm not too sure what the practical consequences of this
particular change are.

I plan to upload the package to the archive next week, either Monday or
Tuesday, but as always that could change if asked by the QA or Release
team. It is a bit ahead of schedule, since upstream released the new
version earlier than previous years. I have updated the Discourse
schedule post accordingly.

Meanwhile, the package is already available in a PPA if you feel like
taking it out for a spin:

https://launchpad.net/~schopin/+archive/ubuntu/glibc-2.40

Cheers,
Simon



More information about the ubuntu-devel mailing list