On 17/08/15 11:07, Matthias Klose wrote: > There is now another test rebuild [2] done > with an augmented dh_makeshlibs printing cxx11 symbols in libraries [3]. No > new > bug reports were filed yet. ... > [2] https://people.debian.org/~doko/logs/gcc5-20150813/archive-gcc-08-13-2015/ > [3] deb https://people.debian.org/~doko/tmp/gcc-5 ./
I have gone through the ~500 logs that mention CXX11 and added them to <https://titanpad.com/UtA5km2wW6>. I have not done mass-bug-filing or checked how many rdeps there were. I am not an expert on the finer points of C++ ABIs, so my attempts to partition the list into "exports C++11" and "uses C++11" might not be entirely accurate, but it's a start; if nothing else, it's useful to be able to search the titanpad for a package name to see whether another package's build-dependencies could potentially need a transition. Please leave a note on the titanpad to "claim" a block of package names before doing any mass-bug-filing, to avoid duplication. The "uses C++11" set might still need a mass-bug-filing asking their maintainers to check, but I think they're lower priority than the "exports C++11" set. If it wasn't such an intrusive upstream change, I'd say we need a release goal "C++ libraries use -fvisibility=hidden to hide all non-ABI symbols" before next time this happens, so that the non-ABI symbols just don't show up... Release team, here are some suggestions for binNMUs and other wanna-build interactions: Fixes for some earlier failures, and version skews caused by maintainer-built binaries not being discarded: # retry failed build with binNMU'd imagemagick gb pfstools_1.8.5-2.1 . amd64 # for opencv transition; maintainer upload had the old opencv nmu ffmpeg_7:2.7.2-2 . amd64 . -m "rebuild with libopencv-core2.4v5" Looking at the build-dependencies of the "bad" packages, the following transitions (mostly small ones) don't appear to be entangled with anything that hasn't already started or involve rebuilding any libraries that are thought to need transitions, so they might be a good way to reduce the problem space and make it easier to reason about larger transitions: * https://release.debian.org/transitions/html/auto-adplug.html * https://release.debian.org/transitions/html/auto-assimp.html * https://release.debian.org/transitions/html/auto-gflags.html * https://release.debian.org/transitions/html/auto-givaro.html * https://release.debian.org/transitions/html/auto-gstreamermm-1.0.html * https://release.debian.org/transitions/html/auto-libassa.html * https://release.debian.org/transitions/html/auto-libccrtp.html * https://release.debian.org/transitions/html/auto-libclaw.html * https://release.debian.org/transitions/html/auto-libhmsbeagle.html * https://release.debian.org/transitions/html/auto-libmusicbrainz3.html * https://release.debian.org/transitions/html/auto-libopkele.html * https://release.debian.org/transitions/html/auto-log4cplus.html * https://release.debian.org/transitions/html/auto-mimetic.html * https://release.debian.org/transitions/html/auto-modglue.html Fixing protobuf on mips/mipsel (<https://bugs.debian.org/796069>) would unblock a number of transitions, and the affected packages can be queued up behind a dep-wait already if I understand the process correctly: dw mixxx_1.11.0~dfsg-5 . mips mipsel . -m libprotobuf9v5 dw clementine_1.2.3+dfsg-4 . mips mipsel . -m libprotobuf9v5 dw cubemap_1.2.0-2 . mips mipsel . -m libprotobuf9v5 dw libphonenumber_6.3~svn698-4 . mips mipsel . -m libprotobuf9v5 dw osmpbf_1.3.3-5 . mips mipsel . -m libprotobuf9v5 dw pink-pony_1.4.1-1 . mips mipsel . -m libprotobuf9v5 Regards, S