Bug#797866: libtorrent: ABI transition needed for libstdc++ v5
On 21/09/15, 09:52am, Simon McVittie wrote: > On Wed, 09 Sep 2015 at 05:38:16 -0700, Jose-Luis Rivas wrote: > > The only reverse dependencies are rtorrent and it needs an upgrade as > > well since there's a newer upstream version (it's the same upstream) > > depending on the newer version of libtorrent. > > > > Do I really need to do the transition or is it safe then? > > libtorrent needs *some* transition: either the v5 rename, or the new SONAME. > > If you are prepared to deal with both libtorrent and rtorrent, including any > fallout from regressions in the new upstream version, then you can go the > new-SONAME route if you prefer. Yes, I have rtorrent ready, awaiting for libtorrent19 to pass NEW. -- ⨳ PGP 0x13EC43EEB9AC8C43 ⨳ https://ghostbar.co signature.asc Description: Digital signature
Bug#797866: libtorrent: ABI transition needed for libstdc++ v5
On Wed, 09 Sep 2015 at 05:38:16 -0700, Jose-Luis Rivas wrote: > The only reverse dependencies are rtorrent and it needs an upgrade as > well since there's a newer upstream version (it's the same upstream) > depending on the newer version of libtorrent. > > Do I really need to do the transition or is it safe then? libtorrent needs *some* transition: either the v5 rename, or the new SONAME. If you are prepared to deal with both libtorrent and rtorrent, including any fallout from regressions in the new upstream version, then you can go the new-SONAME route if you prefer. S
Bug#797866: libtorrent: ABI transition needed for libstdc++ v5
On 09/09/15 07:00, Jose-Luis Rivas wrote: > On 08/09/15, 10:24pm, Jose-Luis Rivas wrote: >> Just to be clear, if I rebuild this with the source packages from >> unstable with a new upstream version the rename is not necessary? > > Nevermind, upstream bumped soname anyway. A new upstream SONAME makes the v5 transition rename unnecessary; but if upstream have bumped SONAME, then they've broken API/ABI (or are doing it wrong), which increases the risk that reverse-dependencies of libtorrent will fail to compile or fail to work. A new upstream release that does not bump the SONAME does not have any effect on the need for a transition/rename. I suspect that the lowest-risk approach to getting this transition finished in a finite time is to do the v5 rename, then ask the release team for a separate transition slot for the new upstream SONAME. S
Bug#797866: libtorrent: ABI transition needed for libstdc++ v5
Nevermind, upstream bumped soname anyway. On 08/09/15, 10:24pm, Jose-Luis Rivas wrote: > Just to be clear, if I rebuild this with the source packages from > unstable with a new upstream version the rename is not necessary? > > On 03/09/15, 08:21am, Simon McVittie wrote: > > Source: libtorrent > > Version: 0.13.2-1 > > Severity: serious > > Justification: breaks ABI without a package rename > > Tags: sid stretch > > User: debian-...@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 libtorrent, std::string appears in functions that are > > explicitly exported, so it seems very likely that a transition is needed. > > The transition normally consists of renaming the > > affected library packages, adding a v5 suffix (libtorrent14v5). > > 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. Please avoid doing this unless the new upstream version > > is very low-risk. > > > > 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 libtorrent, the C++ libraries > > are libcppunit and libsigc++, which have both had their renames > > already; so this sub-transition is ready to start. > > > > 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. > > > > Regards, > > S > > > > [1] https://wiki.debian.org/GCC5#libstdc.2B-.2B-_ABI_transition > > [2] https://lists.debian.org/debian-devel-announce/2015/08/msg0.html > > -- > ⨳ PGP 0x13EC43EEB9AC8C43 ⨳ https://ghostbar.co -- ⨳ PGP 0x13EC43EEB9AC8C43 ⨳ https://ghostbar.co signature.asc Description: Digital signature
Bug#797866: libtorrent: ABI transition needed for libstdc++ v5
On 09/09/15, 07:30am, Simon McVittie wrote: > On 09/09/15 07:00, Jose-Luis Rivas wrote: > > On 08/09/15, 10:24pm, Jose-Luis Rivas wrote: > >> Just to be clear, if I rebuild this with the source packages from > >> unstable with a new upstream version the rename is not necessary? > > > > Nevermind, upstream bumped soname anyway. > > A new upstream SONAME makes the v5 transition rename unnecessary; but if > upstream have bumped SONAME, then they've broken API/ABI (or are doing > it wrong), which increases the risk that reverse-dependencies of > libtorrent will fail to compile or fail to work. > > A new upstream release that does not bump the SONAME does not have any > effect on the need for a transition/rename. > > I suspect that the lowest-risk approach to getting this transition > finished in a finite time is to do the v5 rename, then ask the release > team for a separate transition slot for the new upstream SONAME. > The only reverse dependencies are rtorrent and it needs an upgrade as well since there's a newer upstream version (it's the same upstream) depending on the newer version of libtorrent. Do I really need to do the transition or is it safe then? -- ⨳ PGP 0x13EC43EEB9AC8C43 ⨳ https://ghostbar.co signature.asc Description: Digital signature
Bug#797866: libtorrent: ABI transition needed for libstdc++ v5
Just to be clear, if I rebuild this with the source packages from unstable with a new upstream version the rename is not necessary? On 03/09/15, 08:21am, Simon McVittie wrote: > Source: libtorrent > Version: 0.13.2-1 > Severity: serious > Justification: breaks ABI without a package rename > Tags: sid stretch > User: debian-...@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 libtorrent, std::string appears in functions that are > explicitly exported, so it seems very likely that a transition is needed. > The transition normally consists of renaming the > affected library packages, adding a v5 suffix (libtorrent14v5). > 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. Please avoid doing this unless the new upstream version > is very low-risk. > > 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 libtorrent, the C++ libraries > are libcppunit and libsigc++, which have both had their renames > already; so this sub-transition is ready to start. > > 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. > > Regards, > S > > [1] https://wiki.debian.org/GCC5#libstdc.2B-.2B-_ABI_transition > [2] https://lists.debian.org/debian-devel-announce/2015/08/msg0.html -- ⨳ PGP 0x13EC43EEB9AC8C43 ⨳ https://ghostbar.co signature.asc Description: Digital signature
Processed: Re: Bug#797866: libtorrent: ABI transition needed for libstdc++ v5
Processing commands for cont...@bugs.debian.org: > tag 797866 confirmed Bug #797866 [src:libtorrent] libtorrent: ABI transition needed for libstdc++ v5 Added tag(s) confirmed. > quit Stopping processing here. Please contact me if you need assistance. -- 797866: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797866 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#797866: libtorrent: ABI transition needed for libstdc++ v5
Source: libtorrent Version: 0.13.2-1 Severity: serious Justification: breaks ABI without a package rename Tags: sid stretch User: debian-...@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 libtorrent, std::string appears in functions that are explicitly exported, so it seems very likely that a transition is needed. The transition normally consists of renaming the affected library packages, adding a v5 suffix (libtorrent14v5). 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. Please avoid doing this unless the new upstream version is very low-risk. 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 libtorrent, the C++ libraries are libcppunit and libsigc++, which have both had their renames already; so this sub-transition is ready to start. 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. Regards, S [1] https://wiki.debian.org/GCC5#libstdc.2B-.2B-_ABI_transition [2] https://lists.debian.org/debian-devel-announce/2015/08/msg0.html
