Bug#961195: transition: glibc

2020-07-27 Thread Andreas Beckmann
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



Bug#961195: transition: glibc

2020-07-27 Thread Sebastian Ramacher
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


signature.asc
Description: PGP signature


Bug#961195: transition: glibc

2020-07-26 Thread Adrian Bunk
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



Bug#961195: transition: glibc

2020-07-14 Thread Emilio Pozuelo Monfort
On 13/07/2020 21:39, Aurelien Jarno wrote:
> 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.

It's built on all release architectures now. I have scheduled the binNMUs with
the --extra-depends on libc-bin as usual.

Cheers,
Emilio



Bug#961195: transition: glibc

2020-07-13 Thread Aurelien Jarno
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
aurel...@aurel32.net http://www.aurel32.net



Processed: Re: Bug#961195: transition: glibc

2020-07-13 Thread Debian Bug Tracking System
Processing control commands:

> tags -1 confirmed
Bug #961195 [release.debian.org] transition: glibc
Added tag(s) confirmed.

-- 
961195: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961195
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#961195: transition: glibc

2020-07-13 Thread Emilio Pozuelo Monfort
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.

> Or can we start the transition and fix them at the same
> time?

Yeah, let's go ahead and do that.

Cheers,
Emilio



Bug#961195: transition: glibc

2020-07-13 Thread Aurelien Jarno
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
aurel...@aurel32.net http://www.aurel32.net



Processed: Re: Bug#961195: transition: glibc

2020-07-11 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> block 961195 with 955368 964223 964225 964226 964220 964227 964229 964231
Bug #961195 [release.debian.org] transition: glibc
961195 was not blocked by any bugs.
961195 was not blocking any bugs.
Added blocking bug(s) of 961195: 964223, 964229, 964225, 955368, 964231, 
964226, 964220, and 964227
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
961195: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961195
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#961195: transition: glibc

2020-07-03 Thread Aurelien Jarno
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@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
aurel...@aurel32.net http://www.aurel32.net



Bug#961195: transition: glibc

2020-06-04 Thread Matthias Klose
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@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.



Bug#961195: transition: glibc

2020-06-04 Thread Aurelien Jarno
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@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
aurel...@aurel32.net http://www.aurel32.net



Bug#961195: transition: glibc

2020-06-04 Thread Matthias Klose
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@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  fixes these.



Bug#961195: transition: glibc

2020-06-04 Thread Matthias Klose
On 5/21/20 11:39 AM, Aurelien Jarno wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@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?



Bug#961195: transition: glibc

2020-05-21 Thread Aurelien Jarno
Package: release.debian.org
Severity: normal
User: release.debian@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.]* \(<