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

Bug#1059852: marked as done (transition: glibc 2.38)

Your message dated Tue, 7 May 2024 09:47:20 +0200
with message-id <ZjnciNXwPQDXQOer@ramacher.at>
and subject line Re: Bug#1059852: transition: glibc 2.38
has caused the Debian Bug report #1059852,
regarding transition: glibc 2.38
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.)


-- 
1059852: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059852
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: glibc@packages.debian.org
Control: affects -1 + src:glibc

Dear release team,

I would like to get a transition slot for glibc 2.38. It has been
available in experimental for a few months and does not have any known
issue anymore. It has been built successfully on all release
architectures and most ports architectures, and the experimental
pseudo-excuses look good overall.

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.39\)/;
  is_bad = .depends ~ /libc[0-9.]* \(<< 2.38\)/;

The main symbol related changes in this version are the addition of
strlcat and strlcpy and related functions, coming from the BSD world. A
few packages have their own implementation exported in their symbols
file. With glibc 2.38 starting to provide those functions, the packages
stops providing compatibility functions and the associated symbols,
causing them to FTBFS. Many of them have been identified thanks to the
hurd-amd64 bootstrap and have been fixed. The known remaining ones are:
 - #1055297 ruby3.1: fails to build against glibc 2.38
 - #1055316 heimdal: fails to build against glibc 2.38

Other than that a few symbols have been added to support the C2X binary
constant handling in scanf family of functions. There are unlikely to be
widely used at this point and thus that new packages start to use them,
blocking their migration to testing during the transition.

Thanks for considering.

Regards,
Aurelien

--- End Message ---
--- Begin Message --- 
On 2024-05-03 22:08:00 +0200, Aurelien Jarno wrote:
> Hi,
> 
> On 2024-01-02 13:23, Aurelien Jarno wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian.org@packages.debian.org
> > Usertags: transition
> > X-Debbugs-Cc: glibc@packages.debian.org
> > Control: affects -1 + src:glibc
> > 
> > Dear release team,
> > 
> > I would like to get a transition slot for glibc 2.38. It has been
> > available in experimental for a few months and does not have any known
> > issue anymore. It has been built successfully on all release
> > architectures and most ports architectures, and the experimental
> > pseudo-excuses look good overall.
> > 
> > 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.39\)/;
> >   is_bad = .depends ~ /libc[0-9.]* \(<< 2.38\)/;
> > 
> > The main symbol related changes in this version are the addition of
> > strlcat and strlcpy and related functions, coming from the BSD world. A
> > few packages have their own implementation exported in their symbols
> > file. With glibc 2.38 starting to provide those functions, the packages
> > stops providing compatibility functions and the associated symbols,
> > causing them to FTBFS. Many of them have been identified thanks to the
> > hurd-amd64 bootstrap and have been fixed. The known remaining ones are:
> >  - #1055297 ruby3.1: fails to build against glibc 2.38
> >  - #1055316 heimdal: fails to build against glibc 2.38
> > 
> > Other than that a few symbols have been added to support the C2X binary
> > constant handling in scanf family of functions. There are unlikely to be
> > widely used at this point and thus that new packages start to use them,
> > blocking their migration to testing during the transition.
> > 
> > Thanks for considering.
> 
> As discussed on IRC, I just uploaded it.

Thanks! glibc migrated, closing.

Cheers
-- 
Sebastian Ramacher

--- End Message ---
Reply to: