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