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
