Bug#1102928: mpich: mpi-defaults autopkgtest regressions on 32-bit

[Alastair McKinstry]

>
>
> (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: alastair at mckinstry.ie, im: @alastair:mckinstry.ie @amckinstry at 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