Package: release.debian.org
Severity: normal
User: release.debian....@packages.debian.org
Usertags: binnmu

nmu tumiki-fighters_0.2.dfsg1-9 . ANY . unstable . -m "Rebuild against 
libgphobos76 from gcc-9."
nmu a7xpg_0.11.dfsg1-10 . ANY . unstable . -m "Rebuild against libgphobos76 
from gcc-9."
nmu ii-esu_1.0a.dfsg1-8 . ANY . unstable . -m "Rebuild against libgphobos76 
from gcc-9."
nmu mu-cade_0.11.dfsg1-12 . ANY . unstable . -m "Rebuild against libgphobos76 
from gcc-9."
nmu tatan_1.0.dfsg1-8 . ANY . unstable . -m "Rebuild against libgphobos76 from 
gcc-9."
nmu titanion_0.3.dfsg1-7 . ANY . unstable . -m "Rebuild against libgphobos76 
from gcc-9."
nmu torus-trooper_0.22.dfsg1-12 . ANY . unstable . -m "Rebuild against 
libgphobos76 from gcc-9."
nmu val-and-rick_0.1a.dfsg1-6 . ANY . unstable . -m "Rebuild against 
libgphobos76 from gcc-9."

Quoting doko from #950747 for a similar issue in projectl:

> this is a won't fix.  It will be addressed when GCC 10 becomes the default
> compiler (and libgphobos changes the soname).  There is now a binNMU for 
> projectl.

So let's binNMU tumiki-fighters as a temporary measure to mitigate #956829,
and while we are at it, rebuild all remaining rdepends of libgphobos76 that
were last built before GCC 9 was made the default.


Andreas

Reply via email to