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/ [email protected] [email protected]
signature.asc
Description: PGP signature
-- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
