(presumably with some substitutions in the source code to get the
appropriate multiarch tuple for the relevant architecture) would be
enough to fix what we're now calling #1102928. I haven't verified that
but it seems plausible.
See also #1088919 and #1089694 which involve packaging changes that were
made in 4.2.x in unstable, migrated to testing successfully, but then
were lost when 4.3.x was re-uploaded from experimental into unstable.
Those packaging changes seem like they might be relevant here.
I'll check.
I will upload 4.3.x to experimental with Adrians fix. (and
debian/experimental branch)
I understand your concern about the late stage of the release cycle,
but
I also notice that mpich 4.3.x was first uploaded to unstable 2 days
before the toolchain freeze, which doesn't seem like an ideal time
to be
dropping functionality that previously existed and may have been
relied on
by dependent packages.
I think that given circumstances 4.3.* is not ready for trixie.
Do you plan to revert the upload of 4.3.x to unstable by uploading a
4.3.0+really4.2.1 version that matches what's in trixie, or is your
intention that 4.3.x will stay in unstable, without migrating, until
after the trixie release?
The problem with having packages in unstable that are not ready for
trixie is that whenever a dependent package is built on the buildds,
it will
be built against the dependency in unstable. For example, in this case,
valgrind has a RC bug fix that *is* desired in trixie, but there is no
way
to avoid valgrind being compiled against mpich 4.3.x (at least on 32-bit
architectures), so valgrind is subject to any compile-time regression
that exists in 4.3.x - in particular the disappearance of mpi-c.pc.
Depending on implementation details of the MPI ABI, it's possible that
dependent packages like valgrind might also pick up a versioned
dependency on libmpich12 (>= 4.3.0), which would prevent them from
migrating before mpich does. (I don't know whether this is something
that would genuinely happen for this particular package.)
As a result of factors like those, the release team does not like
packages being uploaded to unstable prematurely, and considers it to be
a RC bug for a package to be in unstable for 30+ days without being able
to migrate (#1103419).
smcv
(not a release team member, just a DD trying to help make the
release happen)
My perference was to leave 4.3.0. in unstable, but given the valgrind
issue, it looks like an upload 4.3.0_really4.2.1 is needed. Anyone think
differently?
Alastair
--
Alastair McKinstry,
GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
e: alast...@mckinstry.ie, im: @alastair:mckinstry.ie @amckins...@mastodon.ie
Commander Vimes didn’t like the phrase “The innocent have nothing to fear,”
believing the innocent had everything to fear, mostly from the guilty but in
the longer term
even more from those who say things like “The innocent have nothing to fear.”
- T. Pratchett, Snuff
