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.
