Hi, On 08-06-2025 14:26, Santiago Vila wrote:
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?
Correct.
(i.e. Would those Breaks help the migration?)
Partially. The Breaks help for two things, you're asking about one of them:1) [original purpose] they prevent our users from upgrading uncertainties without upgrading lmfit-py and/or pymatgen [1]. This is wanted if the autopkgtest regressions catch a real breakage (and not merely a test problem). 2) they tell the migration software that the tests for src:uncertainties need to be done with all three package from unstable. This is your question, and for that the answer is yes. However, if it's *only* a test breakage, some maintainers find this a too weak argument to add the Breaks.
As I understand you, src:lmfit-py and src:pymatgen can migrate without src:uncertainties. That means that once they're in testing, the next retry should pass and no longer block src:uncertainties.
However, src:lmfit-py doesn't run any tests on 32 bits architectures (the binary is arch:all, but the tests don't support 32 bit) so src:lmfi-py can't migrate without an unblock, or without a change to the package. Now the question is, if the tests are skipped on 32 bit architecture, does that mean that the package is broken on those architectures? If the tests are only disabled because the tests are broken on those architectures, but the package works anyways, than that's the reason why src:lmfit-py would need an unblock.
Paul[1] partial upgrades. While officially not supported, we're getting much better at it, particularly because autopkgtests catch so many of the issues.
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature