Hello.

The upload of uncertainties 3.2.3-1 in 2025-05-05 has accidentally
broken several packages, lmfit-py and pymatgen at least.

Because the breakage only happens in unstable, the plan to keep trixie
free of breakage was to not allow uncertainties to propagate to testing.

But yesterday I realized that RC Bug #1107280 in pymatgen ("tries internet
access during build") can't be fixed as far as there is an uncertainties
version which makes the package to FTBFS, as it happens now.

(Not to mention the additional problems in form of trixie-ignore tags
that would involve such strategy).

So: Should we try the route of reverting uncertainties to version 3.2.2 ?

If yes, question for Colin: Can you care about reverting uncertainties?

[ Cc to Colin and also to Drew, who asked about this just a few days ago ].

Thanks.

Thanks.

Hi,

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.

Note that, if you upload a revert to unstable that's basically identical to
the version in testing, there's no need to ask for pre-approval, as there
would be no difference anyway. You might need to ask for an unblock, though.

Thanks!

Ivo

reopen 1107456
thanks

Ivo De Decker wrote:

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.

Hi,


Correct.
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.

Thanks a lot for your reply.

El 8/6/25 a las 15:18, Paul Gevers escribió:

Good question. This is from commit [17b1c270] of src:lmfit-py by Picca Frédéric-Emmanuel
(which I'm adding to Cc).

   * d/t/control: Added architecture !armel !armhf !i386
     The upstream do not provides support for these architectures.

I would guess that at some point some of those tests started to fail,
we probably asked upstream, and they probably told us "I don't care about 32-bit".

So based on the currently available information I don't really know if the tests
just fail or it's that the package is actually broken on 32-bit.
of change to the package would help in cases like this one?

(Maybe we should invent a new control field to express "This is arch:all but only
supported on such and such").

Thanks.

El 8/6/25 a las 15:18, Paul Gevers escribió:

Maybe switching to Arch:any or providing an explicit list of build architectures?

Thanks.

Hi,
We already have that more or less:
Depends: does-not-exist [not-supported-arch1 not-supported-arch2]

But please only do this if the package is broken, not if we don't know
of if it actually works but "we don't really want to support it".

Paul

Santiago Vila <sanvila@debian.org> writes:

Yes exactly. I requested support for the upstrezm in order to fix the
test suit on 32bit arch and they told me thaht there is no support for
32bit arch.

When I did this change the autopkgtest was failing on arch32.

This is why I decided to  remove these archivectures from the
autopkgtests

Cheers

Fred

close 1107456
thanks

I see that Paul added hints for pymatgen and lmfit-py and they migrated to testing
a few days ago (thanks!). Before that, I also uploaded uncertainties with
suitable Breaks. (Well, they are probably not required anymore, but now I
know what to do in similar cases).

Now uncertainties page says "not blocked: has successful autopkgtest"
so it will not need manual intervention anymore.

Closing this bug therefore.

Thanks a lot.