Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1010716 > unrolled thread

Bug#961195: transition: glibc

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#961195: transition: glibc Aurelien Jarno <aurel32@debian.org> - 2020-05-21 11:50 +0200
    Bug#961195: transition: glibc Matthias Klose <doko@debian.org> - 2020-06-04 13:10 +0200
      Bug#961195: transition: glibc Matthias Klose <doko@debian.org> - 2020-06-04 13:50 +0200
      Bug#961195: transition: glibc Aurelien Jarno <aurel32@debian.org> - 2020-06-04 14:10 +0200
        Bug#961195: transition: glibc Matthias Klose <doko@debian.org> - 2020-06-04 14:20 +0200
          Bug#961195: transition: glibc Aurelien Jarno <aurel32@debian.org> - 2020-07-04 00:20 +0200
            Bug#961195: transition: glibc Adrian Bunk <bunk@debian.org> - 2020-07-27 08:00 +0200
              Bug#961195: transition: glibc Sebastian Ramacher <sramacher@debian.org> - 2020-07-27 10:00 +0200
    Bug#961195: transition: glibc Aurelien Jarno <aurelien@aurel32.net> - 2020-07-13 20:00 +0200
    Bug#961195: transition: glibc Aurelien Jarno <aurelien@aurel32.net> - 2020-07-13 21:50 +0200
    Bug#961195: transition: glibc Andreas Beckmann <anbe@debian.org> - 2020-07-27 11:30 +0200

#1010716 — Bug#961195: transition: glibc

Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: transition

Dear release team,

I would like to get a transition slot for glibc 2.31. It is available in
experimental for more than 2 months and there are no known issues or
regression.  It has been built successfully on all release architectures
and most ports architectures. It fails to build on ia64 and sparc64 due
to a few testsuite issues that need to be investigated and which are
similar to existing failures in version 2.30. It doesn't build on
kfreebsd-*, but this has been the case for a few glibc releases already.

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:
 - apitrace
 - bro
 - dante
 - gcc-9 (s390x only)
 - libnih
 - libnss-db
 - r-bioc-preprocesscore
 - unscd

Compare to the previous transition, gcc-10 and gcc-snapshot got removed,
and r-bioc-preprocesscore got added.

Here is the corresponding ben file:
  title = "glibc";
  is_affected = .depends ~ /libc[0-9.]* \(<</;
  is_good = .depends ~ /libc[0-9.]* \(<< 2.32\)/;
  is_bad = .depends ~ /libc[0-9.]* \(<< 2.31\)/;

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.

Thanks for considering.

[toc] | [next] | [standalone]

#1012609

On 5/21/20 11:39 AM, Aurelien Jarno wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian.org@packages.debian.org
> Usertags: transition
> 
> Dear release team,
> 
> I would like to get a transition slot for glibc 2.31. It is available in
> experimental for more than 2 months and there are no known issues or
> regression.  It has been built successfully on all release architectures
> and most ports architectures. It fails to build on ia64 and sparc64 due
> to a few testsuite issues that need to be investigated and which are
> similar to existing failures in version 2.30. It doesn't build on
> kfreebsd-*, but this has been the case for a few glibc releases already.
> 
> 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:
>  - apitrace
>  - bro
>  - dante
>  - gcc-9 (s390x only)
>  - libnih
>  - libnss-db
>  - r-bioc-preprocesscore
>  - unscd
> 
> Compare to the previous transition, gcc-10 and gcc-snapshot got removed,
> and r-bioc-preprocesscore got added.
> 
> Here is the corresponding ben file:
>   title = "glibc";
>   is_affected = .depends ~ /libc[0-9.]* \(<</;
>   is_good = .depends ~ /libc[0-9.]* \(<< 2.32\)/;
>   is_bad = .depends ~ /libc[0-9.]* \(<< 2.31\)/;
> 
> 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.

there are dozens of packages that ftbfs with this new version.  Please could you
at least file bug reports for all of those?

[toc] | [prev] | [next] | [standalone]

#1012610

On 6/4/20 1:06 PM, Matthias Klose wrote:
> On 5/21/20 11:39 AM, Aurelien Jarno wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian.org@packages.debian.org
>> Usertags: transition
>>
>> Dear release team,
>>
>> I would like to get a transition slot for glibc 2.31. It is available in
>> experimental for more than 2 months and there are no known issues or
>> regression.  It has been built successfully on all release architectures
>> and most ports architectures. It fails to build on ia64 and sparc64 due
>> to a few testsuite issues that need to be investigated and which are
>> similar to existing failures in version 2.30. It doesn't build on
>> kfreebsd-*, but this has been the case for a few glibc releases already.
>>
>> 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:
>>  - apitrace
>>  - bro
>>  - dante
>>  - gcc-9 (s390x only)
>>  - libnih
>>  - libnss-db
>>  - r-bioc-preprocesscore
>>  - unscd
>>
>> Compare to the previous transition, gcc-10 and gcc-snapshot got removed,
>> and r-bioc-preprocesscore got added.
>>
>> Here is the corresponding ben file:
>>   title = "glibc";
>>   is_affected = .depends ~ /libc[0-9.]* \(<</;
>>   is_good = .depends ~ /libc[0-9.]* \(<< 2.32\)/;
>>   is_bad = .depends ~ /libc[0-9.]* \(<< 2.31\)/;
>>
>> 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.
> 
> there are dozens of packages that ftbfs with this new version.  Please could you
> at least file bug reports for all of those?

this is about the missing SIOCGSTAMP macro. So maybe jsut triggered by a removed
glibc include? Including <linux/sockios.h> fixes these.

[toc] | [prev] | [next] | [standalone]

#1012612

On 2020-06-04 13:06, Matthias Klose wrote:
> On 5/21/20 11:39 AM, Aurelien Jarno wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian.org@packages.debian.org
> > Usertags: transition
> > 
> > Dear release team,
> > 
> > I would like to get a transition slot for glibc 2.31. It is available in
> > experimental for more than 2 months and there are no known issues or
> > regression.  It has been built successfully on all release architectures
> > and most ports architectures. It fails to build on ia64 and sparc64 due
> > to a few testsuite issues that need to be investigated and which are
> > similar to existing failures in version 2.30. It doesn't build on
> > kfreebsd-*, but this has been the case for a few glibc releases already.
> > 
> > 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:
> >  - apitrace
> >  - bro
> >  - dante
> >  - gcc-9 (s390x only)
> >  - libnih
> >  - libnss-db
> >  - r-bioc-preprocesscore
> >  - unscd
> > 
> > Compare to the previous transition, gcc-10 and gcc-snapshot got removed,
> > and r-bioc-preprocesscore got added.
> > 
> > Here is the corresponding ben file:
> >   title = "glibc";
> >   is_affected = .depends ~ /libc[0-9.]* \(<</;
> >   is_good = .depends ~ /libc[0-9.]* \(<< 2.32\)/;
> >   is_bad = .depends ~ /libc[0-9.]* \(<< 2.31\)/;
> > 
> > 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.
> 
> there are dozens of packages that ftbfs with this new version.  Please could you
> at least file bug reports for all of those?

Yes I can do that. Do you have a list available?

Aurelien

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

[toc] | [prev] | [next] | [standalone]

#1012617

On 6/4/20 2:05 PM, Aurelien Jarno wrote:
> On 2020-06-04 13:06, Matthias Klose wrote:
>> On 5/21/20 11:39 AM, Aurelien Jarno wrote:
>>> Package: release.debian.org
>>> Severity: normal
>>> User: release.debian.org@packages.debian.org
>>> Usertags: transition
>>>
>>> Dear release team,
>>>
>>> I would like to get a transition slot for glibc 2.31. It is available in
>>> experimental for more than 2 months and there are no known issues or
>>> regression.  It has been built successfully on all release architectures
>>> and most ports architectures. It fails to build on ia64 and sparc64 due
>>> to a few testsuite issues that need to be investigated and which are
>>> similar to existing failures in version 2.30. It doesn't build on
>>> kfreebsd-*, but this has been the case for a few glibc releases already.
>>>
>>> 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:
>>>  - apitrace
>>>  - bro
>>>  - dante
>>>  - gcc-9 (s390x only)
>>>  - libnih
>>>  - libnss-db
>>>  - r-bioc-preprocesscore
>>>  - unscd
>>>
>>> Compare to the previous transition, gcc-10 and gcc-snapshot got removed,
>>> and r-bioc-preprocesscore got added.
>>>
>>> Here is the corresponding ben file:
>>>   title = "glibc";
>>>   is_affected = .depends ~ /libc[0-9.]* \(<</;
>>>   is_good = .depends ~ /libc[0-9.]* \(<< 2.32\)/;
>>>   is_bad = .depends ~ /libc[0-9.]* \(<< 2.31\)/;
>>>
>>> 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.
>>
>> there are dozens of packages that ftbfs with this new version.  Please could you
>> at least file bug reports for all of those?
> 
> Yes I can do that. Do you have a list available?

No.

[toc] | [prev] | [next] | [standalone]

#1016401

On 2020-06-04 14:08, Matthias Klose wrote:
> On 6/4/20 2:05 PM, Aurelien Jarno wrote:
> > On 2020-06-04 13:06, Matthias Klose wrote:
> >> On 5/21/20 11:39 AM, Aurelien Jarno wrote:
> >>> Package: release.debian.org
> >>> Severity: normal
> >>> User: release.debian.org@packages.debian.org
> >>> Usertags: transition
> >>>
> >>> Dear release team,
> >>>
> >>> I would like to get a transition slot for glibc 2.31. It is available in
> >>> experimental for more than 2 months and there are no known issues or
> >>> regression.  It has been built successfully on all release architectures
> >>> and most ports architectures. It fails to build on ia64 and sparc64 due
> >>> to a few testsuite issues that need to be investigated and which are
> >>> similar to existing failures in version 2.30. It doesn't build on
> >>> kfreebsd-*, but this has been the case for a few glibc releases already.
> >>>
> >>> 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:
> >>>  - apitrace
> >>>  - bro
> >>>  - dante
> >>>  - gcc-9 (s390x only)
> >>>  - libnih
> >>>  - libnss-db
> >>>  - r-bioc-preprocesscore
> >>>  - unscd
> >>>
> >>> Compare to the previous transition, gcc-10 and gcc-snapshot got removed,
> >>> and r-bioc-preprocesscore got added.
> >>>
> >>> Here is the corresponding ben file:
> >>>   title = "glibc";
> >>>   is_affected = .depends ~ /libc[0-9.]* \(<</;
> >>>   is_good = .depends ~ /libc[0-9.]* \(<< 2.32\)/;
> >>>   is_bad = .depends ~ /libc[0-9.]* \(<< 2.31\)/;
> >>>
> >>> 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.
> >>
> >> there are dozens of packages that ftbfs with this new version.  Please could you
> >> at least file bug reports for all of those?
> > 
> > Yes I can do that. Do you have a list available?
> 
> No.

Lucas Nussbaum has been kind enough to do an archive rebuild with glibc
2.31. The logs are available there:

http://qa-logs.debian.net/2020/06/24/

Fortunately there are less than a dozen of build failures caused by this
new version. Here is a classification of those failures with some
explanations:

* Packages affected by the stime removal from the API:
  - busybox_1:1.30.1-4                  #955368
  - linuxtv-dvb-apps_1.1.1+rev1500-1.2  #964223
  - log4cpp_1.1.3-1                     #964225
  - mandos_1.8.11-1                     #964226
  - vdr_2.4.1-4                         #964220

* Packages affected by the gettimeofday API change:
  - datefudge_1.23                      #964227
  - purelibc_0.4.1-2                    #964229

* Packages affected by the deprecation of ftime:
  - faketime_0.9.7-3                    #964231

* Packages affected by the replacement of the __*_finite symbols by
  compat symbols. The API is unchanged, however it affects linking
  static objects built with glibc < 2.30 with static objects built with
  glibc >= 2.31. This is a purely a link time issue, there is not impact
  at runtime:
  - qosmic_1.6.0-2: This package is linking against the flam3 library,
    which is only available statically. The flam3 package should
    therefore be binNMUed as part of the transition.
  - nageru_2.0.0-3: This package is using lld as the linker instead of
    ld, and it is over picky about the usage of the __*_finite functions
    in dynamic libraries (here libx264.so). The package builds fine with
    ld, so it looks an LLVM issue to me. The easiest workaround is to
    binNMU x264 as part of the transition.

* Packages that are (indirectly) part of the transition and will be
  fixed by the binNMUs:
  - cgmanager_0.41-2
  - r-bioc-affy_1.66.0-1
  - r-bioc-makecdfenv_1.64.0-1
  - r-cran-wgcna_1.69-1

* Packages that build-depend on glibc-source and will need a source
  upload after the glibc 2.31 upload to sid:
  - gcc-9-cross_22
  - gcc-10-cross_9


As a summary, we will need to binNMU a few more packages than the one
listed by the tracker. All packages that need fixes now have an entry in
the BTS with a patch. I think the transition can be started in a few
days, we can always NMU those packages.

Aurelien

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

[toc] | [prev] | [next] | [standalone]

#1019430

On Sat, Jul 04, 2020 at 12:14:49AM +0200, Aurelien Jarno wrote:
>...
>   - nageru_2.0.0-3: This package is using lld as the linker instead of
>     ld, and it is over picky about the usage of the __*_finite functions
>     in dynamic libraries (here libx264.so). The package builds fine with
>     ld, so it looks an LLVM issue to me. The easiest workaround is to
>     binNMU x264 as part of the transition.
>...

zita-resampler also seems to need a binNMU:
https://buildd.debian.org/status/package.php?p=nageru

...
ld.lld: error: /usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libzita-resampler.so: undefined reference to __exp_finite
...

> Aurelien

cu
Adrian

[toc] | [prev] | [next] | [standalone]

#1019434

[Multipart message — attachments visible in raw view] — view raw

On 2020-07-27 08:49:47 +0300, Adrian Bunk wrote:
> On Sat, Jul 04, 2020 at 12:14:49AM +0200, Aurelien Jarno wrote:
> >...
> >   - nageru_2.0.0-3: This package is using lld as the linker instead of
> >     ld, and it is over picky about the usage of the __*_finite functions
> >     in dynamic libraries (here libx264.so). The package builds fine with
> >     ld, so it looks an LLVM issue to me. The easiest workaround is to
> >     binNMU x264 as part of the transition.
> >...
> 
> zita-resampler also seems to need a binNMU:
> https://buildd.debian.org/status/package.php?p=nageru
> 
> ...
> ld.lld: error: /usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libzita-resampler.so: undefined reference to __exp_finite

Scheduled

Cheers
-- 
Sebastian Ramacher

[toc] | [prev] | [next] | [standalone]

#1017861

On 2020-07-11 18:09, Emilio Pozuelo Monfort wrote:
> block 961195 with 955368 964223 964225 964226 964220 964227 964229 964231
> thanks

Does it mean that we need to have those bugs fixed before starting the
transition? Or can we start the transition and fix them at the same
time?

Beside busybox, they are all leaf packages or almost.

Thanks,
Aurelien

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

[toc] | [prev] | [next] | [standalone]

#1017872

On 2020-07-13 20:43, Emilio Pozuelo Monfort wrote:
> Control: tags -1 confirmed
> 
> Hi Aurelien,
> 
> On 13/07/2020 19:54, Aurelien Jarno wrote:
> > On 2020-07-11 18:09, Emilio Pozuelo Monfort wrote:
> >> block 961195 with 955368 964223 964225 964226 964220 964227 964229 964231
> >> thanks
> > 
> > Does it mean that we need to have those bugs fixed before starting the
> > transition?
> 
> No, I just wanted to get them in the BTS, as that would tell me at any given
> time how many are still open.

Ok, thanks for the explanation. I'll upload fixes to the delayed queue
to fix them.

> > Or can we start the transition and fix them at the same
> > time?
> 
> Yeah, let's go ahead and do that.

Ok, thanks. I have just uploaded the package to unstable.

Thanks,
Aurelien

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

[toc] | [prev] | [next] | [standalone]

#1019444

Followup-For: Bug #961195

Please also binNMU zeek/experimental

nmu zeek_3.0.7+ds1-2 . ANY . experimental . -m "Rebuild against glibc 2.31."

Andreas

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web