As usual my feeling about doing +1 maintenance is that I'm not able to be helpful. I'd be happy to take specific work items ("fix this build" or "figure out this test failure") but I'm just flailing around trying to find something to do. Most threads I pull on seem to be things that either someone has already worked on and it's waiting on a build or test in a queue somewhere, or resolve to a pattern that I'd have expected automation to have handled weeks ago. See my discussions with Julian in #ubuntu-release earlier for example, although a huge thanks to Julian for helping me in realtime there on things I did find.
My usual frustration still exists - most of the people working on this seem to be doing so silently, so I have trouble getting context, duplicating others' work, and so forth. Bryce pointed out that perhaps the +1 maintenance handovers need to focus more on what is outstanding rather than what work individuals did, as more of a handover of the status of the archive than a work log. I'm not sure I really grok the status of the archive, but here are my observations in case it helps others: * The dep8 queues seemed to be big earlier in the week (I never actually looked at the figures) but currently the numbers don't seem too bad for armhf * Nearly everything I looked at seemed to be stuck somehow on time_t on armhf. Usually this is because there is stuff left in the transition - things depend on the non-t64 binary when there is now a t64 binary, pulling both into a dependency tree so they conflict. * I didn't find that many failures that weren't caused by this, but those that were seemed to be actual failures that need fixing such as test or build failures due to the time_t change. But these were in the minority of issues (and are probably holding them up) yet I don't know of a good way to identify them into a list of tasks to work on. And here's my work log: * Started with looking at why libdbi-perl is not migrating with the first dep8 failure - auto-multiple-choice. This needs auto-multiple-choice-common -> ghostscript -> libgtk-3-0t64 -> libcups2 but it should be using libcups2t64, causing a conflict. It looked like gtk+3.0 needed a rebuild then. I found that Simon Chopin had uploaded this about an hour previous to me looking into it, so this should be fixed soon and I can look again at what's blocking it next. * The next dep8 failure for libdbi-perl is cod-tools. This one seems to install OK with chdist and -t noble-proposed, which isn't exactly what the autopkgtest in Launchpad is doing. I wondered about how to set up an equivalent pin for chdist to test, but then it occurred to me to look at the autopkgtest queue, and I see that Steve has already queued a retest for cod-tools against (amongst others) libdbi-perl so I guess it's more efficient to move on for now. * eekboek seems similar as does libanyevent-dbi-perl. These also have retries already queued. I guess I should look beyond libdbi-perl. * glewlwyd: dep-wait on rebuild for gnutls soname change on armhf * Candidate for removal? Seems to be a leaf package * Julian confirmed for me in #ubuntu-release - thanks! But this follows a pattern so I think Julian has a much larger list for archive admins to remove. * iddawc * Interestingly glewlwyd depends on it * Synced Debian time_t fix * courier-authlib * This depended on the old libgdbm6 instead of libgdbm6t64, causing courier to FTBFS which I think will eventually block the gdbm transition even though update_excuses didn't list it yet (because it focuses on autopkgtests first). * I found this surprising. This package hadn't had an upload, sync or build since Lunar. Shouldn't someone have already uploaded no change rebuilds for everything depending on the old soname binaries from a simple check of Depends? Anyway, I asked on #ubuntu-release and Julian very quickly knocked that up. Thank you! I think there were a number of other threads I chased up that didn't lead to anything actionable that I didn't note down. I had many interrupts this week so didn't manage to get more done - sorry. I really feel though that 90% of the time I did spend was wasted, and this is something we need to fix. Many thanks to Julian for the realtime discussions and help. This gave me confidence in pushing the (few) specific things I did; otherwise I wasn't sure if I was missing something. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel