Bug#886182: transition: glibc 2.26
Control: forwarded -1 https://release.debian.org/transitions/html/glibc-2.26.html
On 04/01/18 21:56, Aurelien Jarno wrote:
> On 2018-01-02 22:47, Emilio Pozuelo Monfort wrote:
>> Control: tags -1 confirmed
>>
>> On 02/01/18 22:37, 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.26. It is available in
>>> experimental for one month and a half, and there is no known regression.
>>> It has been built successfully on all release architectures, and most
>>> other architectures besides kfreebsd-* which do not have build daemons
>>> anymore. The failures on hurd-i386 and hppa are being worked on and can
>>> be fixed in the upload to sid or later, so I don't think we should block
>>> the transition on that.
>>>
>>> As the 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
>>> - libnih
>>> - libnss-db
>>> - p11-kit
>>> - unscd
>>>
>>> Here is the corresponding ben file:
>>> title = "glibc";
>>> is_affected = .depends ~ /libc[0-9.]* \(<</;
>>> is_good = .depends ~ /libc[0-9.]* \(<< 2.27\)/;
>>> is_bad = .depends ~ /libc[0-9.]* \(<< 2.26\)/;
>>>
>>> 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. That's mostly the case for libm.so, which added
>>> 128-bit floating point support on amd64, i386, and ppc64el. On the
>>> libc.so side the new functions are reallocarray, preadv2 and pwritev2,
>>> which should not be widely used so far.
>>>
>>> Thanks for considering
>>
>> Please go ahead.
>
> Thanks. I uploaded it yesterday and it has now been built on all
> official architectures.
binNMUs scheduled.
Emilio
Reply to: