Bug#1022926: transition: glibc 2.36

[Aurelien Jarno <aurel32@debian.org>]

On 2022-10-31 21:20, Sebastian Ramacher wrote:
> Control: tags -1 = confirmed
> 
> On 2022-10-30 19:06:09 +0100, Aurelien Jarno wrote:
> > On 2022-10-30 17:10, Sebastian Ramacher wrote:
> > > Control: forwarded -1 https://release.debian.org/transitions/html/glibc-2.36.html
> > > Control: tags -1 moreinfo
> > > 
> > > On 2022-10-27 21:36:11 +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.36. It has been
> > > > available in experimental for a bit more than 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.37\)/;
> > > >   is_bad = .depends ~ /libc[0-9.]* \(<< 2.36\)/;
> > > > 
> > > > 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 new filesystem, processes or random functions, so
> > > > unlikely to be massively used by default.
> > > > 
> > > > Note that this version builds with GCC 12 instead of GCC 11, so it is a
> > > > prerequisite for not shipping bookworm with GCC 11.
> > > 
> > > Speaking of GCC 12 … #1022991 seems to have a first patch available
> > > upstream. Is there any chance that we could start this transition
> > > together with a fix for that bug?
> > 
> > I would not say we have patch yet. I posted a first patch on the mailing
> > list yesterday [1], and we have two epidermic answers from both sides
> > ("Why this patch is approved?" or "So MIPS ABI idiocrasies strike
> > again"). One come with a proposal and another one with a partial patch.
> > So that's 3 different options in total. I am also worried that the
> > problem could be more widespread as there is a claim that clock_adjtime
> > is broken on all 64bit system.
> > 
> > So IMHO, we should just wait that things calm done, and that people
> > really try to understand the problem, its consequences and how to fix
> > it, instead of just proposing random patches.
> > 
> > But once we have something acceptable, I am find including it either in
> > a 2.35 upload or a 2.36 one, both are fine to me.
> 
> Okay, then let's not wait for #1022991. None of the reverse dependencies
> should get stuck behind gcc-12. Please go ahead with this transition.

Thanks, I have just uploaded it.

Regards
Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net