Wednesday 10 July 2024

Re: +1 shift report

Hi all,

First of all, a big thank you to Simon for letting me shadow him for even more time than I expected in the beginning... I learned a lot! We did a pair session for rust-reqwest in which he was brilliant at pulling the thread and finding out what was happening.

And then, yes, I took the r-cran-effectsize cluster as I had been using R in the past... a past far away :$. So, in a mixture of recklessness and confidence, I said to myself, why not? 

TL;DR: I only have suggestions on actions (skipping tests :( )

#r-cran-effectsize -> r-cran-bayestestr
This migration is pending on  r-cran-bayestestr/0.13.2-1: The problem here is that we are getting as regression some test that in previous commits were commented by upstream (so never passed because they were never run even there). I locally could pass the tests, but installing the dependencies and all the needed stuff via the Rconsole (install.packages(languageserver)), not the deb packages, so I guess is something about versioning or dependencies with rstan package (as the failing error is "rstan (local) .fun(model_code = .x1)") but, tbh, I  didn't hit the nail on the head. I left it for a more experienced packager on R or, as I suggested in [1], the short-term fix might be to comment those tests again. In Debian are falling too [2].


Again, tests that are failing when previously were skipped (but only for s390x). I updated the bug [3] with the same skipping suggestion.

That's for this time... I hope next time I can produce a more touchable outcome.



On Mon, Jul 8, 2024 at 10:49 AM Simon Chopin <> wrote:
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

* 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.


ubuntu-devel mailing list
Modify settings or unsubscribe at:


Miriam España Acebal

Software Engineer II - Ubuntu Public Cloud/Server



Spain  (GMT+2)