Hi, > > > It turns out that current src:uwsgi-plugin-python has unsatisfiable > > > dependencies on uwsgi-abi-fd03c85edfee33327ac760f246543e10 [0]. > > > > > > Filing as serious because this bug causes migration stalls in sid for > > > piuparts testing of reverse dependencies [1]. > > > > I was afraid this was going to happen. > > > > Convicing the release team to let 2.0.29 into testing may take too > > much time, so the easier course of action is to revert to 2.0.28. > > > > Jonas, do you prefer I try again with the release team or I prepare > > 2.0.29-2+really2.0.28-9+1 ? > > I read #1104206 earlier today, thanks to this bugreport, and if that is > what you are implying as your previous attempt with the release team > then yes, I think is relevant to try again, because if I understand it > correctly, then #1104206 seems to mix multiple issues . specifically it > seems to me that reverting back to older release does not fix the > (related but different from what the bugreport is tracking) issue of > uwsgi package failing to track API reliably: Rebuilding packages without > touching source is still reasonable (or was, by the time the source > package was uploaded), in my opinion.
I understand that 2.0.29 was too late and too big for the soft freeze (only small, targeted fixes). And it is the upload of 2.0.29 that created the need for binNMUs. That's why I think that to be compliant we need to revert, or work out an exception with the release team. > But if you think it is relevant to discuss that API issue further, then > let's do that at #1104206 instead of here. Or merge the bugreports: > Seems easier to track this as the same issue (but thanks for being > cautious and reporting separately, Mathias!). For this ABI tracking issue, I've filled #1104672. Thanks, Alex
