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.
> # 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.
> 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.)
> 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?
> # 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.)
> ## 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.
Cheers,
--
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
