+1 shift report

Wed Jul 10 12:54:12 UTC 2024

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

#geoalchemy2

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.

Regards,

Miriam

[1] https://bugs.launchpad.net/ubuntu/+source/r-cran-bayestestr/+bug/2071941
[2] https://ci.debian.net/packages/r/r-cran-bayestestr/
[3] https://bugs.launchpad.net/ubuntu/+source/geoalchemy2/+bug/2024067

On Mon, Jul 8, 2024 at 10:49 AM Simon Chopin <simon.chopin at canonical.com>
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
>
> 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 at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>

-- 
[image: Canonical-20th-anniversary]

Miriam España Acebal

Software Engineer II - Ubuntu Public Cloud/Server

Email:

miriam.espana at canonical.com

Location:

Spain  (GMT+2)

canonical.com

ubuntu.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20240710/6fc69a28/attachment.html>