Hi, On 2024-01-02 13:23, Aurelien Jarno wrote: > Package: release.debian.org > Severity: normal > User: release.debian....@packages.debian.org > Usertags: transition > X-Debbugs-Cc: gl...@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 aurel...@aurel32.net http://aurel32.net
