Hi folks, I had my +1 shift last week. On the first couple of days I st started looking into the very old items on the excuses page to see if I could move the needle a bit on them (see the mescc-tools paragraph further down, spoiler alert: no joy).
After that, I focused my attention on the clusters identified by the `find-proposed-cluster` script. Only 3 clusters popped up: * libgnatcoll-db is blocked behind gcc-13 * rust-reqwest: see below * r-cran-effectsize: picked up by Miriam And finally, once those were handled, I looked into some FTBFSes. I had the pleasure of being shadowed for part of the week by Ravi Kant Sharma, and by Miriam EspaƱa Acebal for the remainder. ## Handover for next shift Urgent: * giada (rtaudio6 transition) Nice to have: * mescc-tools ## mescc-tools (LP: #2072472) > tools for binary bootstrapping mescc-tools has been stuck in -proposed for more than one cycle, due to a FTBFS on ppc64el. Looking at the logs, its tests fail due to a SIGILL. The same package and version doesn't fail on Debian. I didn't want to spend too long on this, and it proved surprisingly difficult to use the usual set of debug tools, since mescc-tools is essentially a bare-bones assembler that doesn't seem to bother with things such as symbols or debug info (which makes sense). The net result is no technical progress but at least I created a bug. Next step could be a binary diff of the problematic test binary on Debian and Ubuntu to see if/where it differs. ## rust-reqwest (LP: #2071789) > Higher level HTTP client library - Rust source code This crate was holding up a few other Rust packages due to tests regressing on ppc64el and amd64, while the migration-reference/0 tests were inconclusive due to the Rust dependency graph being what it is. It was a really fun investigation, involving talking to both IS and the Ubuntu Release Management team, discovering that some cargo-culted patterns I learned before weren't actually working as I thought (I know, right?!), learning about proxies and their interaction with custom DNS config (it's not great), and a genuine technical mystery. The high-level overview is that the rust-reqwest tests have *always* been failing on our infrastructure due to our proxy, and that actually makes sense. That's not bad per se, because you can't regress failing tests. The mystery here is that a few weeks ago, the tests actually *passed* once on the aforementioned architectures, despite it being impossible according to everything I know and learned. That created a new baseline, so when the miracle didn't reproduce, our CI thought there was a regression. A possible solution would have been to hint the tests to reset the baseline, but I actually opted to fix the upstream test suite to better handle the proxy in the first place. Many thanks to both the upstream author for pointing out that my initial patch was grossly overengineered, and jbicha for pushing the fix to Debian. ## hypercorn vs node-mermaid (LP: #2069202) > Markdownish syntax for generating flowcharts I spent some time trying out the latest version of node-mermaid in Debian to see if we could bring it back in Ubuntu, but even there it's FTBFS for reasons unrelated to its original removal. Out of my depth, I ended up just pinging the Debian maintainer to see if they could publish their Salsa branch in the archive as it presumably solves the issue (I couldn't try it out due to missing pristine-tar branch) ## giada (LP: #2072342) > Hardcore Loop Machine giada is involved in the rtaudio6 transition, but its NCR failed to build, so I went about to port its code to the new librtaudio APIs, which changed fairly drastically how error handling is done. Sadly, once that was fixed, other errors cropped up that were related to the new JUCE version. I managed to fix the linking issue, but ran out of time to fix the latest error, which might be related to PIE? Hopefully the next shift can pick it up. Cheers, Simon -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel