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