Bug#950913: transition: glibc

[Emilio Pozuelo Monfort <pochu@debian.org>]

Control: forwarded -1 https://release.debian.org/transitions/html/glibc-2.30.html
Control: tags -1 confirmed

Hi Aurelien,

On 08/02/2020 10:16, Aurelien Jarno wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian.org@packages.debian.org
> Usertags: transition
> 
> Package: release.debian.org
> Severity: normal
> User: release.debian.org@packages.debian.org
> Usertags: transition
> 
> Dear release team,
> 
> I would like to get a transition slot for glibc 2.30. It is available in
> experimental for 2 months and there are no known issues or regression.
> It has been built successfully on all release architectures and most
> ports architectures. It fails to build on hurd-i386 but it is already
> fixed in git. It also fails to build on alpha, ia64 and sparc64 due
> to a few testsuite issues that need to be investigated and which are
> similar to existing failures in version 2.29. It doesn't build on
> kfreebsd-*, but this has been the case for a few glibc releases already.
> 
> 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 (some packages only on some architectures):
>  - apitrace
>  - bro
>  - dante
>  - gcc-9
>  - gcc-10
>  - gcc-snapshot
>  - libnih
>  - libnss-db
>  - unscd
> 
> Ben file:
> 
> Here is the corresponding ben file:
>   title = "glibc";
>   is_affected = .depends ~ /libc[0-9.]* \(<</;
>   is_good = .depends ~ /libc[0-9.]* \(<< 2.31\)/;
>   is_bad = .depends ~ /libc[0-9.]* \(<< 2.30\)/;
> 
> 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.

Sorry for the delay. Please go ahead.

Cheers,
Emilio