+1 shift report

[Simon Chopin]

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