riotdocker-base: bump to 2022.04 (Jammy Jellyfish)

[kaspar030]

Trying to just bump. (/me crossing fingers)

[kaspar030]

@chrysn I think we need a newer c2rust build (based on jammy):

#12 53.26 The following packages have unmet dependencies:
#12 53.36  c2rust : Depends: libllvm10 (>= 1:9~svn298832-1~) but it is not installable
#12 53.36 E: Unable to correct problems, you have held broken packages.

Maybe tag it differently so the old one stays until this PR is merged?

[chrysn]

IIUC it should suffice if I build c2rust-built on the current branch (with the right riotdocker); I'll publish it as :jammy (probably tomorrow morning after this has run through) and then this branch can switch over to :jammy (and maybe we should stick with Ubuntu version names rather than :latest anyway).

[chrysn]

Hm, it's not tha trivial due to OpenSSL version mismatches, investigating tomorrow.

[chrysn]

I don't see a trivial route for fixing this right now -- C2Rust depends on OpenSSL 1.x (which is also the default libssl-dev in Debian even now), but Ubuntu switched to OpenSSL 3 while Debian still has that only marked as "experimental".

I'm running some tests with selectively updated C2Rust dependencies, maybe that gets us somewhere; in parallel, I'm looking into whether we can unpin the C2Rust version altogether (looks like they're preparing a new major release, so I'm careful there to just update master).

[chrysn]

The new upstream release of c2rust looks like the most promising route; I hoped to let it mature a bit more, but it appears to solve the issue of not accepting the new OpenSSL version (judging by other openssl-sys dependent packages building on jammy).

Looks right now like it'll need one or two bug fixes, and a riot-sys update to get the generalized workarounds where they depended on properties of the old version, but generally that update would simplify things a lot anyway, as it allows building c2rust without downloading an ancient nightly.

[benpicco]

Is there a chance we can then also use #116?
I'd really like to use a more up to date picolibc, but I don't want to maintain it myself.

[chrysn]

The Rust situation is largely resolved with RIOT-OS/RIOT#18048 that pulls in a riot-sys with support for the latest C2Rust.

I do have working builds locally with a branch of C2Rust (mainly branches that upstream is about to merge, plus a change to be able to tell which C2Rust version we're actually using). If you want to press this fast, I can get these ship-shape, but I'd prefer to wait for their release (immunant/c2rust#388), as that'd allow simplifying things further (cargo install c2rust --version 0.1.6 rather than building from git).

[kaspar030]

I don't think there's any rush. No need to press this.

[kaspar030]

https://github.com/immunant/c2rust/releases/tag/v0.16.0 :)

[chrysn]

Other than on the Rust side, how far along is this? (Options for the C2Rust update are to do it in here, or to do it on a separate update still on focal, as using the new C2Rust version is now also a blocker for RIOT-OS/RIOT#18056)

[edit:] Never mind, started it on focal as it's cleaner that way anyway; see #195

[chrysn]

If you rebase that onto master after #195 is in, you can switch the riotbuild/Dockerfile COPY --from chrysn/c2rust-built:for-riot to chrysn/c2rust-built:jammy that is being uploaded (which takes a while given it's based on a local build of riotdocker-base).

(The more I think of it, the more I want to get rid of the docker tag switcharoo, and just start doing a cargo install c2rust directly in riotbuild, now that that's possible)

[kaspar030]

Other than on the Rust side, how far along is this?

let's see. :)

[chrysn]

I can't make it a suggestion from the GitHub GUI as it's outside the range, but seeing that LLVM version is parameterized, s/libclang-dev/libclang-${LLVM_VERSION}-dev/ and s/llvm-dev/llvm-${LLVM_VERSION}-dev/ in the 'Installing C2Rust (build) dependencies' section should enhance version cohesion.

[kaspar030]

I've bumped numpy to 1.22.4. It's marked as emlearn dependency, and emlearn specifies ">=1.14.0". Where is this used? @aabadie do you know?

[benpicco]

Where is this used?

https://github.com/RIOT-OS/RIOT/tree/master/tests/pkg_emlearn

[chrysn]

This is making RIOT-OS/RIOT#18565 harder than it needs to be.

Is there anything left that's keeping us from continuing with this? Let's ask one expert:

bors try

[kaspar030]

hm, it seems like this passed.

[chrysn]

Not ACKing yet because there's a fixup left in this (and we don't have CI checks that prevent merging them). I think this is good for a squash and then prime time. (We're still well on time to have this for 2022.10).

[kaspar030]

IMO we should maybe merge this on a tuesday morning with a bunch of motivated sprinters ready to fix the fallout.

[chrysn]

Or a Monday afternoon (like, in 8 hours), so that if there is breakage, CI would have gathered failure reports from a few runs that the sprinters can work on.

[benpicco]

bors try

[bors]

try

Build succeeded:

• Build and Test

[kaspar030]

so, should we do it? (needs an ACK)

btw, the actions already do a "try".

[kaspar030]

bors merge

[bors]

Build succeeded:

• Build and Test

[miri64]

Seems like with this update libasan is now missing from the Docker container. All release tests for native failed tonight: https://github.com/RIOT-OS/RIOT/actions/runs/3163069653/jobs/5150275711