On Sat, 25 Mar 2017, Adam D. Barratt wrote:
wxwidgets3.0 was recently binNMU'd in stretch. wxpython3.0 needs to be
rebuilt to avoid a C++ ABI mismatch warning when all wxPython
applications are used.
It was binNMUed _in unstable_, a month ago. If there's an issue, why
wasn't it noticed earlier?
I wasn't aware of the fact that wxWidgets was binNMUed until someone
reported a problem, as there isn't any sort of notification. In fact, I
can't even find a bug report that requested one.
More specifically, I can only see one binNMU for wxpython3.0 having been
performed in the past, in 2015. If the packages are so tightly coupled,
shouldn't there have been far more frequent rebuilds in the past? (and
how did the combination of wxwidgets3.0 uploaded on 2016-07-29 and
wxpython3.0 uploaded on 2016-07-19 work?)
The coupling is really only related to C++ ABI changes. As long as the
C++ ABI hasn't change, there isn't any problem.
nmu wxpython3.0_3.0.2.0+dfsg-3 . ANY . stretch . -m "Rebuild due to wxWidgets C++
ABI change"
That won't work, in any case - unstable and testing have the same binary
version of the packages, so the binNMUs would have to be performed in
unstable and then migrate (as testing can't have a higher version of the
package than unstable).
My bad, I'm relatively unfamiliar with the binNMU process. So it should
be:
nmu wxpython3.0_3.0.2.0+dfsg-3 . ANY . unstable . -m "Rebuild due to wxWidgets C++
ABI change"
Does it then automatically migrate to testing, or does an unblock have to
be filed?
