Bug#961195: transition: glibc
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.]* \(<
