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

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.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.


Reply to: