+1 maintenance report

Fri Feb 18 17:14:46 UTC 2022

I was on +1 maintenance this week.

It's been a long time (years) since I last did this. I'm not sure I had
a good feel for what would be useful to work on, so rather than spending
time changing my mind constantly I just focused on what I saw
regardless.

There seem to be a lot of delays waiting on amd64 dep8 tests. Near the
start of the week there were 6705 tests in the queue. At the end of the
week there are 4643. But still the queueing time is generally over a
week. It would be nice if I could see what entries in the queue were
submitted manually by others. This doesn't seem to be presented at
https://autopkgtest.ubuntu.com/running. Christian thought this
information was available in the associated json output, but I haven't
looked into this.

On the topic of delays, I feel like I've only just gotten into a lot of
this. Because of the lag between taking some action and seeing the
result, I ended up with many pending items at any given time, because
most of the time all other items would be waiting on something before I
could proceed further with them. So I'd look for something else. So, as
I am writing up my week, I am finding many loose ends that I did not
resolve because I had started them but then previously blocked items
needed attention again.

In general I'd have liked to have seen more coordination with others on
what is going on. Sometimes I might spend an hour tracking something
down, coming to a conclusion about what action is necessary to take, and
then finding that somebody had already figured this out, done it and the
appropriate rebuild or dep8 retry was in progress or in a queue
somewhere. This is frustrating. I'd prefer to spend my efforts on
something nobody else is looking at. But there isn't any clear process
to determine what that is.

Tooling

At one point I hit what I think is a bug in autopkgtest 5.19. I
typically use it with the lxd runner against ubuntu-daily:jammy. This
doesn't include deb-src lines, so I added these with
--add-apt-source='deb-src http://archive.ubuntu.com/ubuntu jammy main
universe restricted multiverse'. But then --apt-pocket=proposed
--apt-upgrade didn't seem to work. I had tests failing locally because
of an older version of libtiff5 being in the lxd image apt indexes
resulting in a 404. Removing the --add-apt-source line fixed it (I
didn't need apt sources for the particular situation I was in). However
I haven't managed to get a good reproducer for this as the lxd image got
updated while I was debugging. My best guess is that the use of hacking
apt's config in the call to "apt-get update" as part of --add-apt-source
was causing apt to later consider the Packages file current, when it
wasn't. Getting to the bottom of this was taking too long so I left it
without being able to file a bug. Hopefully this note might help someone
else in the future though.

I found a common use case was that I'd know the binary or source package
names for extra things in proposed to retry failing dep8 tests against.
But looking up all the versions, converting to source package names and
URL-encoding manually was tedious. retry-autopkgtest-regressions in
ubuntu-archive-tools didn't seem suitable for this, and nor could I find
anything in ubuntu-helpers, so I knocked something up for this use case:
https://git.launchpad.net/~ubuntu-server/+git/ubuntu-helpers/tree/rbasak/autopkgtest-urls
I just give it the source or binary package names I want, and it looks
up the details from a chdist and outputs the retry URLs.

When working with update_output.txt, I already have a tool to run a
"apt-get -s install" inside a chdist to help understand *why* some
migration would result in some package becoming uninstallable. I needed
to do this for a different architecture so I added a `--arch` option to
this existing script:
https://git.launchpad.net/~ubuntu-server/+git/ubuntu-helpers/tree/rbasak/chdist-if-migrated

cmark-gfm

I spent an hour tracking down cmark-gfm migration failure to eg.
libghc-cmark-gfm-dev from [[src:haskell-cmark-gfm.]] This looked like it
needed a no change rebuild to pick up the new soname. But that was
already done by Utkarsh on 31 Jan. Just as I got this far, it (and
cmark-gfm) migrated.

usemod-wiki

usemod-wiki is a dep8 blocker for the perl migration. This needed a
retry as if "perl libc6 libfdgi-perl libhtml-parser-perl" from the
proposed pocket are all available. It looks like this passed but
something else has moved now.

freecad

vtk9 was being held up by an autopkgtest failure that looked like one of
the Python patterns had previously Andreas identified. I found it
already fixed upstream, uploaded a cherry-pick, and generally poked dep8
throughout the week as needed.

libdancer2-plugin-passphrase-perl

This looked like it was holding up libdigest-bcrypt-perl and the Perl
transition. This turned out to be an upstream issue already known to
Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004699.
Debian is holding libdancer2-plugin-passphrase-perl out of testing for
this reason. It might be easiest for us to do similar to allow
libdigest-bcrypt-perl through. However libdigest-bcrypt-perl 1.209-3 to
1.212-1 is also failing due to its own dep8 regression. I didn't look
into this further.

facter and boost

facter needed retriggering with additional packages to free up cpp-hocon
and leatherman to help unblock boost.

tenacity and gnocchi

It looks like gnocchi needs updating to support the version of
python3-tenacity now in proposed. I tried a couple of simple patches
locally, but that wasn't enough. I didn't end up going any deeper.

wacom

I dug into this and concluded that wacom needed libc6 and libinput
migrating at the same time. I didn't need to do anything further. When
libc6 migrated, wacom went with it.

cyrus-imapd

This was failing dep8 on ppc64el due to needing perl from proposed. I
retried witha perl trigger. It looks like doko tried the same thing a
day later. Anyway, it was insufficient. I have not looked further.

pandas

This was failing due a false test assumption interacting with an
implementation change inside a dependency. I found and uploaded the fix.
I think this worked but amd64 dep8 tests against my upload are still
pending.

strace

I have a note saying I retried a dep8 failure against
strace/5.16-0ubuntu3. I'm not sure what that means as I can't find any
dep8 records for it now.

libboost-regex1.74.0-icu67

I spent a while tracking down the details of this.

The following packages all seemed to be stuck on
libboost-regex1.74.0-icu67

libaqsis1
libdart6
libdiagnostic-aggregator1d
libgnuradio-wavelet3.9.4
libost-info2.2
libost-info2.3
libost-io2.2
libost-io2.3
libost-mol2.2
libost-mol2.3
prusa-slicer

The corresponding source packages are:

aqsis
dart
gnuradio
openstructure
ros-diagnostics
slic3r-prusa

It looked like doko had already uploaded no-change rebuilds of
everything else, but these were stuck for various reasons.

aqsis FTBFS
dart now libdart6.12, libdart6 NBS
gnuradio looks like it's entangled with its own transition
openstructure needs rebuild? I checked with doko and he uploaded a rebuild
ros-diagnostics FTBFS
slic3r-prusa FTBFS

I didn't get any further with these.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20220218/6bd8cb39/attachment.sig>