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. > > # 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
