Bug#1107456: closed by Ivo De Decker <ivodd@debian.org> (Re: Bug#1107456: Acknowledgement (pre-unblock: uncertainties/3.2.3+really3.2.2-1))
reopen 1107456
thanks
Ivo De Decker wrote:
I'm going to close this bug, as there isn't really a question for the release
team here. Feel free to reopen it (or file a new one) if you need something
from the release team.
You are right and I apologize for my lack of clarity.
The question *would* have been: Would we have the support from the RT
to solve the uncertainties sudoku by uploading a revert?
However, after I sent the bug I realized this is not a good solution,
as we can still fix everything which is currently broken and
reduce the difference between testing and unstable.
The new plan will be as follows:
(CC to involved parties for their information)
I've uploaded fixed versions of lmfit-py and pymatgen. They
are compatible with both old and new uncertainties, but their
old autopkgtests are the reason why uncertainties can't migrate
to testing right now:
https://qa.debian.org/excuses.php?package=uncertainties
Because this is a chicken-and-egg problem, I will ask
(in a few days) for both lmfit-py and pymatgen to be
unblocked, and after they migrate to testing,
the autopkgtests for uncertainties will finally pass
and it can migrate to testing without help.
And there is indeed a question related to all this: If we
make a new upload of uncertainties which just adds a breaks
against old lmfit-py and old pymatgen, would that really
tell the testing migration machinery that they should not run
the old autopkgtests of lmfit-py and pymatgen with
the new uncertainties?
(i.e. Would those Breaks help the migration?)
(I think that was the original plan from Colin, which I now
believe it's the best path to follow)
Thanks.
Reply to: