Bug#1059852: transition: glibc 2.38

[Aurelien Jarno <aurel32@debian.org>]

Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: transition
X-Debbugs-Cc: glibc@packages.debian.org
Control: affects -1 + src:glibc

Dear release team,

I would like to get a transition slot for glibc 2.38. It has been
available in experimental for a few months and does not have any known
issue anymore. It has been built successfully on all release
architectures and most ports architectures, and the experimental
pseudo-excuses look good overall.

As glibc is using symbol versioning, there is no soname change. That
said a few packages are using libc internal symbols and have to be
rebuilt for this transition. Here is the corresponding ben file:

  title = "glibc";
  is_affected = .depends ~ /libc[0-9.]* \(<</;
  is_good = .depends ~ /libc[0-9.]* \(<< 2.39\)/;
  is_bad = .depends ~ /libc[0-9.]* \(<< 2.38\)/;

The main symbol related changes in this version are the addition of
strlcat and strlcpy and related functions, coming from the BSD world. A
few packages have their own implementation exported in their symbols
file. With glibc 2.38 starting to provide those functions, the packages
stops providing compatibility functions and the associated symbols,
causing them to FTBFS. Many of them have been identified thanks to the
hurd-amd64 bootstrap and have been fixed. The known remaining ones are:
 - #1055297 ruby3.1: fails to build against glibc 2.38
 - #1055316 heimdal: fails to build against glibc 2.38

Other than that a few symbols have been added to support the C2X binary
constant handling in scanf family of functions. There are unlikely to be
widely used at this point and thus that new packages start to use them,
blocking their migration to testing during the transition.

Thanks for considering.

Regards,
Aurelien