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

Bug#961195: marked as done (transition: glibc)

Your message dated Fri, 24 Jul 2020 10:35:28 +0200
with message-id <607c8a02-8d16-b48b-31a8-8624b5fbd60f@debian.org>
and subject line Re: Bug#961195: transition: glibc
has caused the Debian Bug report #961195,
regarding transition: glibc
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
961195: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961195
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
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.

--- End Message ---
--- Begin Message --- 
On 14/07/2020 21:12, Emilio Pozuelo Monfort wrote:
> 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.

This transition went pretty smoothly. Let's close this report, the remaining
failing packages can be tracked in their respective bug reports.

Cheers,
Emilio

--- End Message ---
Reply to: