[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1022926: marked as done (transition: glibc 2.36)

Your message dated Mon, 7 Nov 2022 23:57:48 +0100
with message-id <Y2mNbC1yWlEumzRK@ramacher.at>
and subject line Re: Bug#1022926: transition: glibc 2.36
has caused the Debian Bug report #1022926,
regarding transition: glibc 2.36
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.)


-- 
1022926: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022926
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.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.

Thanks for considering.

Regards,
Aurelien

--- End Message ---
--- Begin Message --- 
On 2022-11-01 12:44:15 +0100, Aurelien Jarno wrote:
> 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.

… and glibc migrated.

Cheers
-- 
Sebastian Ramacher

--- End Message ---
Reply to: