Bug#1141940: transition: glibc

Control: tags -1 confirmed

On 12/07/2026 19:20, Aurelien Jarno wrote:
> Package: release.debian.org
> Severity: normal
> X-Debbugs-Cc: [email protected], [email protected]
> Control: affects -1 + src:glibc
> User: [email protected]
> Usertags: transition
> 
> Dear release team,
> 
> I would like to request a transition slot for glibc 2.43. It has been
> available in experimental for a few months and appears to be in good
> shape. It has built successfully on all release architectures and on
> most ports architectures.
> 
> One important change that causes compatibility issues is that, when
> using the C23 standard (default with GCC 15), the functions bsearch,
> memchr, strchr, strpbrk, strrchr, strstr, wcschr, wcspbrk, wcsrchr,
> wcsstr and wmemchr now return a pointer to a const-qualified type when
> the input argument is a pointer to a const-qualified type. A possible
> quick workaround if we need to fix a package for the transition is to
> force the ISO C level with -std=c17 or -std=gnu17 or use GCC 14.
>   
> An archive rebuild has been done, and the corresponding bugs have been
> reported [1], as well as the ones causing autopkgtest failures. We are
> now down to less than 40 bugs.
> 
> On the autopkgtest side, the experimental pseudo-excuses look good
> overall, and the remaining ones due to the C23 change, issues in
> unstable or britney selecting the wrong set of packages.
> 
> As glibc is using symbol versioning, there is no soname change. That
> said a few packages use internal libc 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.44\)/;
>    is_bad = .depends ~ /libc[0-9.]* \(<< 2.43\)/;
> 
> Speaking about migration, this glibc version adds a few new GLIBC_2.43
> symbols, to support ISO C23 (free_sized, free_aligned_sized,
> memset_explicit and memalignment), and to wrap to Linux kernel syscalls
> (mseal and openat2). These symbols are unlikely to be used widely at
> this stage, and thus this transition should not block many packages to
> migrate to testing.
> 
> Thanks for considering.

Please go ahead, and bump the remaining bugs to serious.

Cheers,
Emilio