Bug#1019845: marked as done (transition: glibc 2.35)
Your message dated Wed, 28 Sep 2022 00:52:35 +0200
with message-id <YzN+s5hZ17yoJy9X@ramacher.at>
and subject line Re: Bug#1019845: transition: glibc 2.35
has caused the Debian Bug report #1019845,
regarding transition: glibc 2.35
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 owner@bugs.debian.org
immediately.)
--
1019845: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019845
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: transition
X-Debbugs-Cc: debian-glibc@lists.debian.org
Dear release team,
I would like to get a transition slot for glibc 2.35. It has been
available in experimental for one month and does not have any known
major issue. It has been built successfully on all release architectures
and many ports architectures. A few issues found through the autopkgtest
pseudo excuses for experimental have been fixed. The remaining ones are
due to britney bugs, broken autopkgtest or packages parts of the
transition.
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.36\)/;
is_bad = .depends ~ /libc[0-9.]* \(<< 2.35\)/;
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 and
mostly linked to the new math functions introduced for ISO C2x support,
so unlikely to be massively used by default. Therefore overall this
transition should be way simpler than the glibc 2.34 one.
Thanks for considering.
Regards,
Aurelien
--- End Message ---
--- Begin Message ---
On 2022-09-23 00:23:44 +0200, Aurelien Jarno wrote:
> On 2022-09-22 23:51, Sebastian Ramacher wrote:
> > Control: tags -1 confirmed
> >
> > On 2022-09-18 10:11:58 +0200, Sebastian Ramacher wrote:
> > > Control: forwarded -1 https://release.debian.org/transitions/html/glibc-2.35.html
> > >
> > > On 2022-09-14 22:17:47 +0200, Aurelien Jarno wrote:
> > > > Package: release.debian.org
> > > > Severity: normal
> > > > User: release.debian.org@packages.debian.org
> > > > Usertags: transition
> > > > X-Debbugs-Cc: debian-glibc@lists.debian.org
> > > >
> > > > Dear release team,
> > > >
> > > > I would like to get a transition slot for glibc 2.35. It has been
> > > > available in experimental for one month and does not have any known
> > > > major issue. It has been built successfully on all release architectures
> > > > and many ports architectures. A few issues found through the autopkgtest
> > > > pseudo excuses for experimental have been fixed. The remaining ones are
> > > > due to britney bugs, broken autopkgtest or packages parts of the
> > > > transition.
> > > >
> > > > 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.36\)/;
> > > > is_bad = .depends ~ /libc[0-9.]* \(<< 2.35\)/;
> > > >
> > > > 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 and
> > > > mostly linked to the new math functions introduced for ISO C2x support,
> > > > so unlikely to be massively used by default. Therefore overall this
> > > > transition should be way simpler than the glibc 2.34 one.
> > > >
> > > > Thanks for considering.
> > >
> > > Let's start with this one after the udeb block is lifted and the D-I
> > > alpha is done.
> >
> > The udeb block was lifted. Please go ahead.
>
> Thanks. I have uploaded it it, but it seems to be stuck in a dinstall
> that takes a lot of time. I guess it'll be there (and maybe built on
> some architectures) when I wake up tomorrow :)
glibc and the binNMUs migrated.
Cheers
--
Sebastian Ramacher
--- End Message ---
Reply to: