Bug#797646: xmms2: transition needed for g++-5 ABIs

[Benjamin Drung]

Hi Rémi,

will you take care of the upload? Otherwise I am happy to accept patches
and upload them.

Am Dienstag, den 01.09.2015, 09:32 +0100 schrieb Simon McVittie:
> Source: xmms2
> Version: 0.8+dfsg-13
> Severity: serious
> Justification: breaks reverse-dependencies
> 
> Background[1]: libstdc++6 introduces a new ABI to conform to the
> C++11 standard, but keeps the old ABI to not break existing binaries.
> Packages which are built with g++-5 from experimental (not the one
> from testing/unstable) are using the new ABI.  Libraries built from
> this source package export some of the new __cxx11 or B5cxx11 symbols,
> dropping other symbols.  If these symbols are part of the API of
> the library, then this rebuild with g++-5 will trigger a transition
> for the library.
> 
> In the case of xmms2, std::string appears in header files that
> get installed, so it seems very likely that a transition is needed.
> The transition consists of renaming the affected library packages, adding a
> v5 suffix.
> 
> In the case of xmms2, libxmmsclient++4 and libxmmsclient++-glib1 appear
> to be affected. A couple of packages build-depend on libxmmsclient++-dev,
> so libxmmsclient++4 needs renaming to libxmmsclient++4v5. Nothing actually
> seems to build-depend on libxmmsclient++-glib-dev, but if you're going
> through the NEW queue to rename libxmmsclient++4 anyway, it seens sensible
> to rename libxmmsclient++-glib1 to libxmmsclient++-glib1v5 in the
> same upload.
> 
> These follow-up transitions for libstdc++ are not going through exactly
> the normal transition procedure, because many entangled transitions are
> going on at the same time, and the usual ordered transition procedure
> does not scale that far. When all the C++ libraries on which this library
> depends have started their transitions in unstable if required, this
> library should do the same, closing this bug; the release team will deal
> with binNMUs as needed.
> 
> In the case of xmms2:
> 
> * boost already started its transition with version 1.58
> * the other library dependencies appear to have C APIs
> 
> so I think this transition is ready to start.
> 
> The package is likely to be NMU'd if there is no maintainer response. The
> release team have declared a 2 day NMU delay[2] for packages involved
> in the libstdc++ transition, in order to get unstable back to a usable
> state in a finite time.
> 
> S
> 
> [1] https://wiki.debian.org/GCC5#libstdc.2B-.2B-_ABI_transition
> [2] https://lists.debian.org/debian-devel-announce/2015/08/msg0.html

-- 
Benjamin Drung
Debian & Ubuntu Developer

Bug#797646: xmms2: transition needed for g++-5 ABIs

[Rémi Vanicat]

Hi Benjami and Simon,

I won't have the time to deal with it before saturday or sunday.
So if you want to upload it before this, please do.

Le mar. 1 sept. 2015 à 22:18, Benjamin Drung  a écrit :

> Hi Rémi,
>
> will you take care of the upload? Otherwise I am happy to accept patches
> and upload them.
>
> Am Dienstag, den 01.09.2015, 09:32 +0100 schrieb Simon McVittie:
> > Source: xmms2
> > Version: 0.8+dfsg-13
> > Severity: serious
> > Justification: breaks reverse-dependencies
>
> --
> Benjamin Drung
> Debian & Ubuntu Developer
>
>

Bug#797646: xmms2: transition needed for g++-5 ABIs

[Simon McVittie]

Source: xmms2
Version: 0.8+dfsg-13
Severity: serious
Justification: breaks reverse-dependencies

Background[1]: libstdc++6 introduces a new ABI to conform to the
C++11 standard, but keeps the old ABI to not break existing binaries.
Packages which are built with g++-5 from experimental (not the one
from testing/unstable) are using the new ABI.  Libraries built from
this source package export some of the new __cxx11 or B5cxx11 symbols,
dropping other symbols.  If these symbols are part of the API of
the library, then this rebuild with g++-5 will trigger a transition
for the library.

In the case of xmms2, std::string appears in header files that
get installed, so it seems very likely that a transition is needed.
The transition consists of renaming the affected library packages, adding a
v5 suffix.

In the case of xmms2, libxmmsclient++4 and libxmmsclient++-glib1 appear
to be affected. A couple of packages build-depend on libxmmsclient++-dev,
so libxmmsclient++4 needs renaming to libxmmsclient++4v5. Nothing actually
seems to build-depend on libxmmsclient++-glib-dev, but if you're going
through the NEW queue to rename libxmmsclient++4 anyway, it seens sensible
to rename libxmmsclient++-glib1 to libxmmsclient++-glib1v5 in the
same upload.

These follow-up transitions for libstdc++ are not going through exactly
the normal transition procedure, because many entangled transitions are
going on at the same time, and the usual ordered transition procedure
does not scale that far. When all the C++ libraries on which this library
depends have started their transitions in unstable if required, this
library should do the same, closing this bug; the release team will deal
with binNMUs as needed.

In the case of xmms2:

* boost already started its transition with version 1.58
* the other library dependencies appear to have C APIs

so I think this transition is ready to start.

The package is likely to be NMU'd if there is no maintainer response. The
release team have declared a 2 day NMU delay[2] for packages involved
in the libstdc++ transition, in order to get unstable back to a usable
state in a finite time.

S

[1] https://wiki.debian.org/GCC5#libstdc.2B-.2B-_ABI_transition
[2] https://lists.debian.org/debian-devel-announce/2015/08/msg0.html