Your message dated Sat, 5 Sep 2026 15:29:55 +0200
with message-id <[email protected]>
and subject line Re: Bug#1141940: transition: glibc
has caused the Debian Bug report #1141940,
regarding transition: glibc
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1141940: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1141940
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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.
Regards,
Aurelien
[1]
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=glibc-2.43;[email protected]
--- End Message ---
--- Begin Message ---
On 2026-07-12 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.
glibc 2.43 is in testing for a couple of weeks, thanks! Closing the bug.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
[email protected] http://aurel32.net
--- End Message ---
