Bug#1022926: transition: glibc 2.36
Control: forwarded -1 https://release.debian.org/transitions/html/glibc-2.36.html
Control: tags -1 moreinfo
On 2022-10-27 21:36:11 +0200, Aurelien Jarno wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian.org@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: debian-glibc@lists.debian.org
>
> Dear release team,
>
> I would like to get a transition slot for glibc 2.36. It has been
> available in experimental for a bit more than one month and does not
> have any known major issue. It has been built successfully on all
> release architectures and many ports architectures. A few issues found
> through the autopkgtest pseudo excuses for experimental have been fixed.
> The remaining ones are due to britney bugs, broken autopkgtest or
> packages parts of the transition.
>
> 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.37\)/;
> is_bad = .depends ~ /libc[0-9.]* \(<< 2.36\)/;
>
> In addition a few new symbols have been added that might prevent a few
> other packages to migrate to testing until glibc migrates if they pick
> up the new symbols, however those are really limited in this version and
> mostly linked to new filesystem, processes or random functions, so
> unlikely to be massively used by default.
>
> Note that this version builds with GCC 12 instead of GCC 11, so it is a
> prerequisite for not shipping bookworm with GCC 11.
Speaking of GCC 12 … #1022991 seems to have a first patch available
upstream. Is there any chance that we could start this transition
together with a fix for that bug?
Cheers
>
> Thanks for considering.
>
> Regards,
> Aurelien
>
--
Sebastian Ramacher
Reply to: