Bug#1121762: transition: glibc 2.42

2025-12-21 Thread Florian Weimer 
* Aurelien Jarno:

> One important change in this version is the removal of the obsolete
> termio interface in favor of the termios one. This causes a few packages
> to FTBFS.

Rebuilding some pacakges against the new glibc headers causes them to
fail at runtime.  This happens with minicom.  Some source changes are
required.

At least minicom has been fixed:

Bug#1121762: transition: glibc 2.42

2025-12-12 Thread Emilio Pozuelo Monfort 

On 03/12/2025 13:38, Emilio Pozuelo Monfort wrote:

Regarding Ada packages: I'll add a tracker, and we can either rebuild them if
possible, remove them if necessary, or perhaps the Ada team wants to make the
transition to gnat-15.


Ada team: what are your plans for Ada? Should we wait for the gnat-15 
transition?

Cheers,
Emilio

Bug#1121762: transition: glibc 2.42

2025-12-09 Thread Aurelien Jarno 
control: unblock 1121762 by 1122038

Hi,

Here is a quick status about this transition. 

glibc 2.42-5 added a workaround for bug#1122038, so it is not a blocker 
for this transition anymore, it currently produces very strict 
dependencies that might be an issue for the trixie to forky upgrade on 
i386. There are multiple options to fix that, but I think this should be 
handled outside of the transition.

On the autopkgtest side, here are the remaining issues at the time of 
writing:

- numpy/1:2.3.5+ds-2 on ppc64el and s390x
  => This is fixed by [1], but not yet uploaded. This is an issue in the 
  testsuite. From a quick look there is probably a better fix, I'll try 
  to submit it upstream. In the meantime that's probably good neought.

- openmsx/20.0+dfsg-1.2
  => this is bug#1121755. Note this is an issue in the testsuite.

- zvbi/0.2.44-1
  => This is bug#1115113. The issue actually seems to be in the package, 
  but I personally haven't been able to reproduce it.

The remaining failures appears to be flaky tests or bugs in britney.

With all of that, I believe it should be safe to force glibc 2.42 into 
testing.

Regards
Aurelien

[1] 
https://salsa.debian.org/python-team/packages/numpy/-/commit/6ed5a9a874a90964f560df9c9ff76d1188c3ab8f
-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
[email protected] http://aurel32.net

Bug#1121762: transition: glibc 2.42

2025-12-08 Thread Emilio Pozuelo Monfort 

On 08/12/2025 12:19, Adrian Bunk wrote:

On Mon, Dec 08, 2025 at 12:06:31PM +0100, Sebastian Ramacher wrote:

On 2025-12-07 07:56:03 +0200, Adrian Bunk wrote:

Based on buildinfo files, the following binNMUs are required for
#1122038 (insufficent package dependencies on i386):

wb nmu asyncpg_0.30.0-1.1 . i386 . -m 'Rebuild against glibc (>= 2.42-5)'
wb nmu 2 dante_1.4.3+dfsg-3.1 . ANY . sid . -m 'Rebuild against glibc (>= 2.42-5)' 
. --extra-depends 'libc-bin (>= 2.42)'
wb nmu 2 dolfin_2019.2.0~legacy20240219.1c52e83-25 . ANY . -m 'Rebuild against 
glibc (>= 2.42-5)'
wb nmu geary_46.0-9 . i386 . -m 'Rebuild against glibc (>= 2.42-5)'
wb nmu gnome-builder_49.1-2 . i386 . -m 'Rebuild against glibc (>= 2.42-5)'
wb nmu libdbd-pg-perl_3.18.0-3 . i386 . -m 'Rebuild against glibc (>= 2.42-5)'
wb nmu libreoffice_26.2.0~beta1-1 . i386 . experimental . -m 'Rebuild against 
glibc (>= 2.42-5)'
wb nmu 1 mariadb_11.8.5-2 . ANY . -m 'Rebuild against glibc (>= 2.42-5)'
wb nmu 1 mesa_25.2.8-2 . ANY . -m 'Rebuild against glibc (>= 2.42-5)'
wb nmu 2 mshr_2019.2.0~git20230811.ff54a68+dfsg1-7 . ANY . -m 'Rebuild against 
glibc (>= 2.42-5)'
wb nmu opendrop_3.3.2-3 . i386 . -m 'Rebuild against glibc (>= 2.42-5)'
wb nmu petsc4py_3.24.1-2 . i386 . -m 'Rebuild against glibc (>= 2.42-5)'
wb nmu 1 python3.13_3.13.11-1 . ANY . -m 'Rebuild against glibc (>= 2.42-5)'
wb nmu 1 python3.14_3.14.2-1 . ANY . -m 'Rebuild against glibc (>= 2.42-5)'
wb nmu shortwave_5.0.0-7 . i386 . -m 'Rebuild against glibc (>= 2.42-5)'
wb nmu slepc4py_3.24.1-2 . i386 . -m 'Rebuild against glibc (>= 2.42-5)'
wb nmu 2 starpu_1.4.10+dfsg-2 . ANY . -m 'Rebuild against glibc (>= 2.42-5)'
wb nmu storm_1.1-1 . i386 . -m 'Rebuild against glibc (>= 2.42-5)'


Rescheduled those from the tracker with extra depends and to sync binNMU
versions.


No one has so far scheduled most of the ones I found above.

Should I check and schedule myself what is still needed, or does someone
from the release team want to do that?


I have just scheduled them.

Cheers,
Emilio

Bug#1121762: transition: glibc 2.42

2025-12-08 Thread Adrian Bunk 
On Mon, Dec 08, 2025 at 12:06:31PM +0100, Sebastian Ramacher wrote:
> On 2025-12-07 07:56:03 +0200, Adrian Bunk wrote:
> > Based on buildinfo files, the following binNMUs are required for 
> > #1122038 (insufficent package dependencies on i386):
> > 
> > wb nmu asyncpg_0.30.0-1.1 . i386 . -m 'Rebuild against glibc (>= 2.42-5)'
> > wb nmu 2 dante_1.4.3+dfsg-3.1 . ANY . sid . -m 'Rebuild against glibc (>= 
> > 2.42-5)' . --extra-depends 'libc-bin (>= 2.42)'
> > wb nmu 2 dolfin_2019.2.0~legacy20240219.1c52e83-25 . ANY . -m 'Rebuild 
> > against glibc (>= 2.42-5)'
> > wb nmu geary_46.0-9 . i386 . -m 'Rebuild against glibc (>= 2.42-5)'
> > wb nmu gnome-builder_49.1-2 . i386 . -m 'Rebuild against glibc (>= 2.42-5)'
> > wb nmu libdbd-pg-perl_3.18.0-3 . i386 . -m 'Rebuild against glibc (>= 
> > 2.42-5)'
> > wb nmu libreoffice_26.2.0~beta1-1 . i386 . experimental . -m 'Rebuild 
> > against glibc (>= 2.42-5)'
> > wb nmu 1 mariadb_11.8.5-2 . ANY . -m 'Rebuild against glibc (>= 2.42-5)'
> > wb nmu 1 mesa_25.2.8-2 . ANY . -m 'Rebuild against glibc (>= 2.42-5)'
> > wb nmu 2 mshr_2019.2.0~git20230811.ff54a68+dfsg1-7 . ANY . -m 'Rebuild 
> > against glibc (>= 2.42-5)'
> > wb nmu opendrop_3.3.2-3 . i386 . -m 'Rebuild against glibc (>= 2.42-5)'
> > wb nmu petsc4py_3.24.1-2 . i386 . -m 'Rebuild against glibc (>= 2.42-5)'
> > wb nmu 1 python3.13_3.13.11-1 . ANY . -m 'Rebuild against glibc (>= 2.42-5)'
> > wb nmu 1 python3.14_3.14.2-1 . ANY . -m 'Rebuild against glibc (>= 2.42-5)'
> > wb nmu shortwave_5.0.0-7 . i386 . -m 'Rebuild against glibc (>= 2.42-5)'
> > wb nmu slepc4py_3.24.1-2 . i386 . -m 'Rebuild against glibc (>= 2.42-5)'
> > wb nmu 2 starpu_1.4.10+dfsg-2 . ANY . -m 'Rebuild against glibc (>= 2.42-5)'
> > wb nmu storm_1.1-1 . i386 . -m 'Rebuild against glibc (>= 2.42-5)'
> 
> Rescheduled those from the tracker with extra depends and to sync binNMU
> versions.

No one has so far scheduled most of the ones I found above.

Should I check and schedule myself what is still needed, or does someone 
from the release team want to do that?

> Cheers

cu
Adrian

Bug#1121762: transition: glibc 2.42

2025-12-08 Thread Sebastian Ramacher 
On 2025-12-07 07:56:03 +0200, Adrian Bunk wrote:
> Based on buildinfo files, the following binNMUs are required for 
> #1122038 (insufficent package dependencies on i386):
> 
> wb nmu asyncpg_0.30.0-1.1 . i386 . -m 'Rebuild against glibc (>= 2.42-5)'
> wb nmu 2 dante_1.4.3+dfsg-3.1 . ANY . sid . -m 'Rebuild against glibc (>= 
> 2.42-5)' . --extra-depends 'libc-bin (>= 2.42)'
> wb nmu 2 dolfin_2019.2.0~legacy20240219.1c52e83-25 . ANY . -m 'Rebuild 
> against glibc (>= 2.42-5)'
> wb nmu geary_46.0-9 . i386 . -m 'Rebuild against glibc (>= 2.42-5)'
> wb nmu gnome-builder_49.1-2 . i386 . -m 'Rebuild against glibc (>= 2.42-5)'
> wb nmu libdbd-pg-perl_3.18.0-3 . i386 . -m 'Rebuild against glibc (>= 2.42-5)'
> wb nmu libreoffice_26.2.0~beta1-1 . i386 . experimental . -m 'Rebuild against 
> glibc (>= 2.42-5)'
> wb nmu 1 mariadb_11.8.5-2 . ANY . -m 'Rebuild against glibc (>= 2.42-5)'
> wb nmu 1 mesa_25.2.8-2 . ANY . -m 'Rebuild against glibc (>= 2.42-5)'
> wb nmu 2 mshr_2019.2.0~git20230811.ff54a68+dfsg1-7 . ANY . -m 'Rebuild 
> against glibc (>= 2.42-5)'
> wb nmu opendrop_3.3.2-3 . i386 . -m 'Rebuild against glibc (>= 2.42-5)'
> wb nmu petsc4py_3.24.1-2 . i386 . -m 'Rebuild against glibc (>= 2.42-5)'
> wb nmu 1 python3.13_3.13.11-1 . ANY . -m 'Rebuild against glibc (>= 2.42-5)'
> wb nmu 1 python3.14_3.14.2-1 . ANY . -m 'Rebuild against glibc (>= 2.42-5)'
> wb nmu shortwave_5.0.0-7 . i386 . -m 'Rebuild against glibc (>= 2.42-5)'
> wb nmu slepc4py_3.24.1-2 . i386 . -m 'Rebuild against glibc (>= 2.42-5)'
> wb nmu 2 starpu_1.4.10+dfsg-2 . ANY . -m 'Rebuild against glibc (>= 2.42-5)'
> wb nmu storm_1.1-1 . i386 . -m 'Rebuild against glibc (>= 2.42-5)'

Rescheduled those from the tracker with extra depends and to sync binNMU
versions.

Cheers

> 
> cu
> Adrian
> 
> BTW: #1122038 is still open since it is only workarounded.
> 

-- 
Sebastian Ramacher

Bug#1121762: transition: glibc 2.42

2025-12-06 Thread Adrian Bunk 
Based on buildinfo files, the following binNMUs are required for 
#1122038 (insufficent package dependencies on i386):

wb nmu asyncpg_0.30.0-1.1 . i386 . -m 'Rebuild against glibc (>= 2.42-5)'
wb nmu 2 dante_1.4.3+dfsg-3.1 . ANY . sid . -m 'Rebuild against glibc (>= 
2.42-5)' . --extra-depends 'libc-bin (>= 2.42)'
wb nmu 2 dolfin_2019.2.0~legacy20240219.1c52e83-25 . ANY . -m 'Rebuild against 
glibc (>= 2.42-5)'
wb nmu geary_46.0-9 . i386 . -m 'Rebuild against glibc (>= 2.42-5)'
wb nmu gnome-builder_49.1-2 . i386 . -m 'Rebuild against glibc (>= 2.42-5)'
wb nmu libdbd-pg-perl_3.18.0-3 . i386 . -m 'Rebuild against glibc (>= 2.42-5)'
wb nmu libreoffice_26.2.0~beta1-1 . i386 . experimental . -m 'Rebuild against 
glibc (>= 2.42-5)'
wb nmu 1 mariadb_11.8.5-2 . ANY . -m 'Rebuild against glibc (>= 2.42-5)'
wb nmu 1 mesa_25.2.8-2 . ANY . -m 'Rebuild against glibc (>= 2.42-5)'
wb nmu 2 mshr_2019.2.0~git20230811.ff54a68+dfsg1-7 . ANY . -m 'Rebuild against 
glibc (>= 2.42-5)'
wb nmu opendrop_3.3.2-3 . i386 . -m 'Rebuild against glibc (>= 2.42-5)'
wb nmu petsc4py_3.24.1-2 . i386 . -m 'Rebuild against glibc (>= 2.42-5)'
wb nmu 1 python3.13_3.13.11-1 . ANY . -m 'Rebuild against glibc (>= 2.42-5)'
wb nmu 1 python3.14_3.14.2-1 . ANY . -m 'Rebuild against glibc (>= 2.42-5)'
wb nmu shortwave_5.0.0-7 . i386 . -m 'Rebuild against glibc (>= 2.42-5)'
wb nmu slepc4py_3.24.1-2 . i386 . -m 'Rebuild against glibc (>= 2.42-5)'
wb nmu 2 starpu_1.4.10+dfsg-2 . ANY . -m 'Rebuild against glibc (>= 2.42-5)'
wb nmu storm_1.1-1 . i386 . -m 'Rebuild against glibc (>= 2.42-5)'

cu
Adrian

BTW: #1122038 is still open since it is only workarounded.

Bug#1121762: transition: glibc 2.42

2025-12-05 Thread Emilio Pozuelo Monfort 

Hi,

On 03/12/2025 23:13, Aurelien Jarno wrote:

Hi Emilio,

On 2025-12-03 13:38, Emilio Pozuelo Monfort wrote:

Control: tags -1 confirmed

Hi Aurelien,

On 02/12/2025 06:44, Aurelien Jarno wrote:

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: [email protected], [email protected]
User: [email protected]
Usertags: transition
Control: affects -1 + src:glibc

Dear release team,

I would like to request a transition slot for glibc 2.42. It has been
available since the beginning of August and appears to be in good shape.
It has built successfully on all release architectures and on most ports
architectures.

One important change in this version is the removal of the obsolete
termio interface in favor of the termios one. This causes a few packages
to FTBFS. The addition of ISO C23 and ISO CY math functions also creates
a few conflicts with names used in some source code, resulting in a few
FTBFS. There are also a couple of additional FTBFS due to some other
small changes. An archive rebuild was done (although 2 months ago) and
all of the FTBFS found on amd64 have been reported [1], many have
already been fixed.

On the autopkgtest side, the experimental pseudo-excuses look good
overall, most of the issues looks like false positive. The only real
ones that I have identified are fuse-zip (due to valgrind), openmsx and
zvbi (amd64 only). They also have been reported [1].

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.]* \(<

Please go ahead.


Thanks! I have just uploaded it.


binNMUs scheduled.

Cheers,
Emilio

Bug#1115113: Bug#1121762: transition: glibc 2.42

2025-12-04 Thread Paul Gevers 

Control: severity -1 serious

Hi,

On 12/3/25 23:13, Aurelien Jarno wrote:

On 2025-12-03 13:38, Emilio Pozuelo Monfort wrote:

On 02/12/2025 06:44, Aurelien Jarno wrote:

I would like to request a transition slot for glibc 2.42.



Please go ahead.



Thanks! I have just uploaded it.


The transition has started, making these bugs RC.

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1121762: transition: glibc 2.42

2025-12-03 Thread Aurelien Jarno 
Hi Emilio,

On 2025-12-03 13:38, Emilio Pozuelo Monfort wrote:
> Control: tags -1 confirmed
> 
> Hi Aurelien,
> 
> On 02/12/2025 06:44, Aurelien Jarno wrote:
> > Package: release.debian.org
> > Severity: normal
> > X-Debbugs-Cc: [email protected], [email protected]
> > User: [email protected]
> > Usertags: transition
> > Control: affects -1 + src:glibc
> > 
> > Dear release team,
> > 
> > I would like to request a transition slot for glibc 2.42. It has been
> > available since the beginning of August and appears to be in good shape.
> > It has built successfully on all release architectures and on most ports
> > architectures.
> > 
> > One important change in this version is the removal of the obsolete
> > termio interface in favor of the termios one. This causes a few packages
> > to FTBFS. The addition of ISO C23 and ISO CY math functions also creates
> > a few conflicts with names used in some source code, resulting in a few
> > FTBFS. There are also a couple of additional FTBFS due to some other
> > small changes. An archive rebuild was done (although 2 months ago) and
> > all of the FTBFS found on amd64 have been reported [1], many have
> > already been fixed.
> > 
> > On the autopkgtest side, the experimental pseudo-excuses look good
> > overall, most of the issues looks like false positive. The only real
> > ones that I have identified are fuse-zip (due to valgrind), openmsx and
> > zvbi (amd64 only). They also have been reported [1].
> > 
> > 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.43\)/;
> >is_bad = .depends ~ /libc[0-9.]* \(<< 2.42\)/;
> > 
> > In addition there have been some termios interface changes, but
> > compatibility for older binaries is preserved through symbol versioning.
> > Unfortunately this doesn't prevent the changes of the gnat-XXX Provides
> > from the gnat-$GCVER-$DEB_TARGET_MULTIARCH packages once they are
> > rebuilt [2]. This means that gcc-13 to gcc-15 also need to get rebuilt,
> > and then all gnat packages depending on the old gnat-14 provides. Not
> > sure how you want to deal with that, but I have the impression that
> > while it has to be done closely after the glibc 2.42 upload, the two
> > transitions are not completely coupled, and glibc 2.42 can migrate to
> > testing before gnat-14.
> > 
> > Speaking about migration, this glibc version provides a GLIBC_2.42
> > version of the existing termios symbols on a few architectures that have
> > a testing suite. It also adds GLIBC_2.42 version for the __inet_ntop_chk
> > and __inet_pton_chk symbols, that are used with  _FORTIFY_SOURCE=2.
> > Additionally there are new symbols for new ISO C23 and ISO CY math
> > functions on all architectures and for vectorized math functions on
> > arm64. Therefore there is probably more risks than for previous glibc
> > transitions that one of these news symbols will be picked up by some
> > packages, preventing them to migrate to testing before glibc 2.42.
> > 
> > Thanks for considering.
> 
> Please go ahead.

Thanks! I have just uploaded it.

Cheers
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
[email protected] http://aurel32.net

Bug#1121762: transition: glibc 2.42

2025-12-03 Thread Emilio Pozuelo Monfort 

Control: tags -1 confirmed

Hi Aurelien,

On 02/12/2025 06:44, Aurelien Jarno wrote:

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: [email protected], [email protected]
User: [email protected]
Usertags: transition
Control: affects -1 + src:glibc

Dear release team,

I would like to request a transition slot for glibc 2.42. It has been
available since the beginning of August and appears to be in good shape.
It has built successfully on all release architectures and on most ports
architectures.

One important change in this version is the removal of the obsolete
termio interface in favor of the termios one. This causes a few packages
to FTBFS. The addition of ISO C23 and ISO CY math functions also creates
a few conflicts with names used in some source code, resulting in a few
FTBFS. There are also a couple of additional FTBFS due to some other
small changes. An archive rebuild was done (although 2 months ago) and
all of the FTBFS found on amd64 have been reported [1], many have
already been fixed.

On the autopkgtest side, the experimental pseudo-excuses look good
overall, most of the issues looks like false positive. The only real
ones that I have identified are fuse-zip (due to valgrind), openmsx and
zvbi (amd64 only). They also have been reported [1].

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.]* \(<

Please go ahead.

Regarding Ada packages: I'll add a tracker, and we can either rebuild them if 
possible, remove them if necessary, or perhaps the Ada team wants to make the 
transition to gnat-15.


Cheers,
Emilio

Bug#1121762: transition: glibc 2.42

2025-12-01 Thread Adrian Bunk 
On Tue, Dec 02, 2025 at 06:44:14AM +0100, Aurelien Jarno wrote:
>...
> In addition there have been some termios interface changes, but
> compatibility for older binaries is preserved through symbol versioning.
> Unfortunately this doesn't prevent the changes of the gnat-XXX Provides
> from the gnat-$GCVER-$DEB_TARGET_MULTIARCH packages once they are
> rebuilt [2]. This means that gcc-13 to gcc-15 also need to get rebuilt,
> and then all gnat packages depending on the old gnat-14 provides. Not
> sure how you want to deal with that, but I have the impression that
> while it has to be done closely after the glibc 2.42 upload, the two
> transitions are not completely coupled, and glibc 2.42 can migrate to
> testing before gnat-14.
>...

Affected are 23 packages, including 4 currently in testing:

title = "gnat rebuilds for glibc 2.42";
is_affected = .depends ~ /gnat-14-/ & !.source ~ /gcc-14/;
is_good = !.uninstallable ~ /yes/;
is_bad = .uninstallable ~ /yes/;

> Regards,
> Aurelien
>...

cu
Adrian

Bug#1121762: transition: glibc 2.42

2025-12-01 Thread Aurelien Jarno 
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: [email protected], [email protected]
User: [email protected]
Usertags: transition
Control: affects -1 + src:glibc

Dear release team,

I would like to request a transition slot for glibc 2.42. It has been
available since the beginning of August and appears to be in good shape.
It has built successfully on all release architectures and on most ports
architectures.

One important change in this version is the removal of the obsolete
termio interface in favor of the termios one. This causes a few packages
to FTBFS. The addition of ISO C23 and ISO CY math functions also creates
a few conflicts with names used in some source code, resulting in a few
FTBFS. There are also a couple of additional FTBFS due to some other
small changes. An archive rebuild was done (although 2 months ago) and
all of the FTBFS found on amd64 have been reported [1], many have
already been fixed.

On the autopkgtest side, the experimental pseudo-excuses look good
overall, most of the issues looks like false positive. The only real
ones that I have identified are fuse-zip (due to valgrind), openmsx and
zvbi (amd64 only). They also have been reported [1].

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.]* \(