Bug#1059852: transition: glibc 2.38
Hi,
On 2024-01-02 13:23, Aurelien Jarno wrote:
> 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.
As discussed on IRC, I just uploaded it.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://aurel32.net
Reply to: