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.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
Reply to: