Bug#799649: stk: ABI transition needed for libstdc++ v5

[Sebastian Ramacher]

Control: tags -1 + pending

Hi

On 2015-09-21 09:54:28, Felipe Sateler wrote:
> On 21 September 2015 at 05:21, Simon McVittie <smcv at debian.org> wrote:
> > Source: stk
> > Version: 4.4.4-5
> > Severity: serious
> > Justification: ABI break since stable when rebuilt
> > Tags: sid stretch
> > User: debian-gcc at lists.debian.org
> > Usertags: libstdc++-cxx11
> >
> > 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 stk, there's a lot of std::string use in include/,
> > so a transition does appear to be needed. The transition normally
> > consists of renaming the affected library packages, replacing the
> > c2a suffix from a similar previous transition with a v5 suffix
> > (libstk0v5). The SONAME should not be changed when doing this.
> >
> > If an upgrade to a new upstream SONAME is already planned, and that
> > SONAME has never been available in Debian compiled with g++-4, then an
> > alternative way to carry out the transition would be to bump the
> > SONAME. However, the libstdc++ transition has been going on for nearly
> > 2 months already, and anything that makes it take longer is bad for Debian,
> > so introducing new upstream code is not recommended at this stage.
> >
> > 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.
> >
> > Looking at the build-dependencies of stk, rtaudio and rtmidi have
> > already had their renames, so I believe stk is now ready to be renamed.
> >
> > The package might 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.
> 
> Please go ahead. I do not know when I will have time to look at this,
> so do not wait on me.

I've uploaded 4.4.4-6 with renamed packages. I saw that there is a new upstream
release in git, but I didn't want to deal with the lintian errors this new
release generates.

Cheers
-- 
Sebastian Ramacher
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20150921/21bbeb12/attachment-0001.sig>