Bug#886182: marked as done (transition: glibc 2.26)
Your message dated Wed, 24 Jan 2018 12:59:12 +0100
with message-id <20180124115912.GE7966@aurel32.net>
and subject line Re: Bug#886182: transition: glibc 2.26
has caused the Debian Bug report #886182,
regarding transition: glibc 2.26
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.)
--
886182: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886182
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.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
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.14.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--- End Message ---
--- Begin Message ---
On 2018-01-05 11:47, Emilio Pozuelo Monfort wrote:
> 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.
>
glibc 2.26 migrated into testing 2 weeks ago. Closing the bug.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
--- End Message ---
Reply to: