Bug#1022926: transition: glibc 2.36
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.
Cheers
--
Sebastian Ramacher
Reply to: