The buildd arm-arm-03 failed to update its chroot on Aug 2. As a result, in the period Aug 3-9 it built various packages using g++-4.9 when people were expecting it to use g++-5. So there are library packages, such as libsigc++-2.0-0v5, which are intended to handle the transition to GCC 5 but were unexpectedly built with the old compiler. The consequences are sometimes unpleasant and non-trivial to diagnose. For example, the package synfig was successfully built, but the command synfig crashes in some cases and that prevented synfigstudio from building.
I'm not going to copy the commands I used to get this list, because they're just too embarrassing, but there's a list below of the 37 source packages that were (earlier today) last built using build-essential_11 on arm-arm-03 in the period Aug 3-10. Most are probably harmless, because they don't use C++, don't use libraries, or don't have any of the critical types in their APIs, but some have been shown to be problematic. What to do, if anything? Does anyone know for sure how to detect which packages really should be rebuilt? Obviously one could do nothing for now and just check again in 6 months' time, when many of the packages will have been rebuilt anyway, but during those 6 months some developer time may have been wasted in investigating weird failures. aiccu analitza aptitude bear bwctl cableswig capstone colpack ctemplate cython dspdfviewer fractgen gdcm gnome-software libasync-interrupt-perl librsvg libshevek libsigc++-2.0 libvsqlitepp lm-sensors movit normalize-audio orthanc-webviewer osmo pcsc-tools pykcs11 python-pyeclib qtscript-opensource-src r-cran-fastcluster remctl roboptim-core signing-party staden-io-lib subversion svxlink taglib-extras usbutils