> 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.
> > # openmpi transition
>
> > Openmpi has been blocking a large number of migrations (not surprising
> > considering how many packages depend on it).
>
> This includes blocking boost, which in turn blocks exiv2 NBS removal, which
> has prevented us from having any successful image builds for two community
> flavors (edubuntu, ubuntustudio) since plucky opened.
>
> 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.
NB: petsc has a few new versions in unstable that may be worth
checking
> > 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.
> > Autopkgtest will try to install the test deps with "all proposed" but somehow
> > that doesn't seem effective. Not sure why because I thought that would be
> > enough but in practice it's additional triggers which make the tests succeed.
>
> Do you know that retry-autopkgtest-regressions with no arguments will
> synthesize an autopkgtest retry request that consolidates all triggers that
> it finds failures for in update_excuses? e.g.:
>
> $ retry-autopkgtest-regressions |grep package=mpi4py
> https://autopkgtest.ubuntu.com/request.cgi?release=plucky&arch=s390x&package=mpi4py&trigger=mpi4py%2F4.0.1-3ubuntu1&trigger=openmpi%2F5.0.5-6&trigger=python3-defaults%2F3.12.7-1
> [...]
> $
>
> > # Rust
>
> > Rust does things slightly differently than Coq but the result is the same.
> > Very often, tests need to use rust packages from proposed. They don't need
> > all-proposed but instead something that would be "all-rust-proposed".
>
> Is there a common failure pattern when using all-proposed?
I wasn't aware that retry-autopkgtest-regressions did that and I had
unfortunately assumed it didn't!
For rust packages, that behavior is somewhat wider than only adding the
rust-* packages but only a minor difference overall.
The idea of "all-rust-proposed" was not about a failure but rather being
able to track down which packages were effectively involved in tests
passing later on.
If only doing it for rust- packages is 99% as effective but without
pulling all proposed, that seemed interesting to me. However, the
retry-autopkgtest-regressions that you outlined above is just as good
and there's probably no reason to spend time adding complexity trying to
shrink the new triggers for rust packages.
> > # Packages without issues but not transitioning
>
> > There are a number of packages that are not moving, yet there is no reason
> > for them to be stuck according to update_excuses.html. There is some more
> > data in update_output.txt but it's not directly usable: at best it will
> > give hints
> >
> > I found that apt can help (and didn't yet manage to use dose in the proper
> > way). Rought steps are:
> > - open update_output.txt,
> > - pick the sources packages from a "trying" line,
> > - also pick the binaries in the following line,
> > - use chdist to apt list binary packages in -proposed (and only -proposed) for
> > the source package,
> > - use chdist to apt list binary packages _not_ in -proposed for the binaries
> > listed by britney
> > - use chdist in a full environment to apt install both set of binaries
> > at once (the ones reported by britney and the ones reported by apt using
> > only -proposed)
>
> Have you seen update-output-helper in lp:ubuntu-archive-tools? It tries to
> automate the process of going from a failed line in update_output to a
> chdist environment you can use to see why apt says the newly-uninstallable
> packages are uninstallable.
>
> $ update-output-helper -u
> [...]
> $ update-output-helper libgit2
> [...]
> $ chdist -d "/home/vorlon/.cache/brapt" apt u-a-h --dry-run install librust-bat-dev
> [...]
> NOTE: This is only a simulation!
> apt needs root privileges for real execution.
> Keep also in mind that locking is deactivated,
> so don't depend on the relevance to the real current situation!
> Reading package lists... Done
> Building dependency tree... Done
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
>
> The following packages have unmet dependencies:
> librust-libgit2-sys-dev : Depends: libgit2-dev (< 1.8~~) but 1.8.4+ds-1ubuntu1 is to be installed
> E: Unable to correct problems, you have held broken packages.
> $
>
> etc.
>
> Badly underdocumented. (Documentation at top of script, not in --help)
> Commandline should be improved. (need for -d option should be removed,
> should only need a chdist name.)
I had seen it but that's it. Actually I had seen someone not on my
timezeone say you had told them about it, but I didn't know more about it
and I didn't understand the script at first, then forgot a bit about it
(well, until writing my report, and then forgot again :) ).
BTW, I actually looked for a --help message both back then and again
just now. :P
I think what I wrote is actually very close to update-output-helper. It
was different initially but it ended up being very similar.
There's probably an advantage to my script which is being stateless: it
doesn't need to change configuration files. It's also slightly more
automated and pulls the list of conflicting packages automatically. I
haven't compared the results however!
> > ## Snapd
>
> > I re-triggered tests for a snapd SRU across several releases. The backers
> > of the SRU were asking for people to retry the failing tests through a
> > launchpad bug. Considering that the tests required several retries, that
> > felt very inefficient and long for them. I guess IRC and providing retry
> > links would have been more efficient but it still requires involving
> > several people which will lead to latency and frustration. Except by
> > broadening retry rights, I'm not sure how to really fix that however.
>
> we should in general be broadening the rights to retry failed autopkgtests
> to include "anyone who might have a legitimate need for them". Does not
> need to be package uploaders. You (or they) should be able to talk to the
> Ubuntu Release Management Team about this.
Somehow I can't find the corresponding bug again but I'll make sure to
redirect people that way next time.
--
Adrien
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
