On Thu, Nov 28, 2024 at 06:24:48PM +0100, Adrien Nader wrote:
> On Wed, Nov 27, 2024, Steve Langasek wrote:
> > Hi Adrien,
> > On Mon, Nov 25, 2024 at 05:26:49PM +0100, Adrien Nader wrote:
> > > For rust, I'm wondering if it's worth working on the packages unless
> > > there's a strong specific need (you can read the Rust section for details
> > > :) ).
> > My position on this is: random Rust crates with no libraries/applications as
> > reverse-build-dependencies (whether those are in Rust or not) should be
> > removed rather than fixed. The only question is whether it's easier to fix
> > them than to work out whether they have reverse-dependencies, since
> > `reverse-depends` doesn't handle virtual packages well at all.
> I understand why but for most people, removing a package is much more
> involved that adding triggers for instance.
Is there something specific you think we should do to simplify the removal
process?
> > Question, should we just roll back openmpi transition temporarily to unblock
> > the other stuff?
> > > I found out that C++ support has been dropped from the standard and now from
> > > the library. This isn't reflected in the packaging and packages end up failing
> > > to find "libmpi_cxx.so.40". This was the most common failure but not the only
> > > one.
> > That's pretty surprising to me and seems like a good argument that the new
> > openmpi was uploaded prematurely to plucky.
> It's difficult for me to answer that as I don't know the fallout to
> expect from temporarily rolling back a transition.
> BTW, here is the list of packages blocked in -proposed due to openmpi (and
> possibly other reaons):
> abyss ampliconnoise apbs arpack boost1.83 camitk cctools combblas
> deal.ii dolfin dune-grid dune-uggrid eckit espresso esys-particle
> examl fckit ffindex fftw3 fiat-ecmwf freefem++ garli genomicsdb gerris
> getdp gloo gloo-cuda gpaw gretl gromacs groops gyoto h5py hyphy hypre
> mathgl meep-mpi-default mfem molds mpi4py mumps murasaki music netgen
> netpipe nwchem open-coarrays opendrop opm-grid opm-simulators
> opm-upscaling p4est paraview petsc petsc4py phyml prime-phylo relion
> rmpi silo-llnl slepc slepc4py sopt starpu starpu-contrib sundials
> superlu-dist tree-puzzle vtk9
>
> Most of them are leaf or almost-leaf packages but there are a few
> annoying ones. Some have their own transitions going on although they
> seem mostly done now if I read the transition tracker correctly (even
> slepc/petsc).
>
> There aren't that many failing tests for the openmpi transition now.
> I've just made several of them pass by adjusting triggers and more
> results are coming but it'll take a few hours for britney to reflect
> that (and there's a queue for tests on ppc64el).
> For the errors not related to libmpi_cxx.so.40, I don't have much more
> insight however but I haven't investigated them at all. I estimate
> that's at most 10 packages, probably closer to 4 or 5.
Ah, that's also surprising, I would expect this number to be larger. If
it's really this few then I don't think it's worth dealing with a temporary
rollback.
Although the openmpi now in -proposed has also introduced an ABI change, so
we'll see how that goes.
> > > The transition tracker includes a permanent tracker for a number of
> > > ecosystems, including Coq. It can guide no-change rebuilds (which need to be
> > > done in the order shown by the transition tracker).
> > Well, no; there are bugs wrt the ordering the transition tracker says
> > packages should be built with, which is one of my main grievances with the
> > tracker. (The tracker expects you to complete all the builds at a given
> > "level" first even if a package at a given level has no
> > reverse-build-depends.)
> But does that make the ordering wrong? What you describe sounds like
> it's going to be merely less than optimal but not wrong.
It is sufficiently suboptimal as to be harmful.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
