On 18/08/15 09:06, Philip Rinn wrote: > thanks for taking care of the transition to the g++-5 ABI! > Could you be a little more verbose? Should I do something to make the > transition > happen (and if, how and when)?
Sorry, I incorrectly assumed that gstreamermm-1.0 was a pkg-gnome package, and so you would probably have seen enough of these bugs already to be almost as tired of them as I am :-) The context is that gstreamermm-1.0 has std::string in its ABI, and g++-5 has switched its default ABI to C++11 mode, which changes the representation of std::string; so building gstreamermm-1.0 with g++-5 changes its ABI, even though there were no source code changes. As a result, someone needs to rename the binary package to add the "v5" suffix, similar to what I did for gtkmm3.0 <https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;att=1;filename=gtkmm3.0_3.16.0-2.diff;bug=795916>, and fix any packaging that is broken by that change (for instance symbols files, shlibs, or any mentions of the library package name in debian/rules). In principle you can upload that change to unstable as soon as all your C++ build-dependencies have had their renames, or been confirmed to not need a rename. In your case I think that just means waiting for glibmm2.4, which has already happened. However, to be able to test your change, ideally you should be able to rebuild and test reverse-dependencies; or if you can't actually *test* them because not enough packages have been binNMU'd for you to be able to get a working system, the next best thing is to be able to *rebuild* some reverse-dependencies successfully. I've been using a local instance of sbuild, with a local apt repository containing transitioned and locally-rebuilt packages. To be able to rebuild subtitleeditor successfully, you'll probably need to wait for atkmm, pangomm and gtkmm3.0 (each of which I just uploaded) to get out of the NEW queue; so it's probably best to wait for those to hit unstable before doing anything. However, you could prepare the changes in your git repository if you want to be helpful. If you do that, it would be great if you could send a patch to this bug, so that it's obvious how to NMU if you aren't available to upload it at the appropriate time. It isn't currently clear whether you should close this bug in the upload or not: the initial recommendation was to leave the bug open and reassign it to release.debian.org as a transition tracker, but jcristau seems to have switched to just closing the bug in the usual way in his most recent round of NMUs, so I'm not sure what's going on there. S
