Re: libstdc++ follow-up transitions
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
Reply to: