Bug#1029010: llvm-toolchain-15: autopkgtest regression

[Simon McVittie]

On Wed, 08 Mar 2023 at 03:11:57 +0200, Faidon Liambotis wrote:
> On Fri, Mar 03, 2023 at 05:46:15PM +0000, Simon McVittie wrote:
> > I don't think this is *really* a regression, because in the version in
> > bookworm, the autopkgtest didn't exercise compilation of C++ into
> > WebAssembly at all.
> 
> This statement strictly speaking is true, but applies only if you look
> at LLVM 15 in isolation. It *is* a regression, in the sense that this
> works with llvm-toolchain-14, where the WebAssembly work was first
> pushed, today, in both bookworm and sid. For example, retracing your
> steps in #1032317 with s/15/14/ does not result into a failure.

Sorry, I was confused by the binary package reorganization in the
llvm-toolchain-15 toolchain since it forked from -14, and I hadn't
realised that -14 had undergone equivalent restructuring to enable
WASM support. Yes, this is a regression since -14, even if it isn't
a regression since the -15 in bookworm.

> there is a metapackage, libc++-dev-wasm32, which Depends on the
> default implementation, which is libc++-14-dev-wasm32 right now. That
> metapackage has at least one notable reverse B-D, firefox, using it to
> build certain security/sandboxing features (RLBox[1], AIUI). That is to
> say, this feature works (w/ 14) and does very useful things today. it
> (seemingly) broke when it was ported to llvm-toolchain-15, which
> src:firefox does not depend on directly.

If I understand correctly, that doesn't *necessarily* have to be RC for
bookworm, because llvm-toolchain-15 is not (yet!) the default version
of LLVM provided by the metapackage, and is only used by Mesa? But it
would be a blocker for either moving the default forward from 14 to 15
(as has already been done in experimental), or making Firefox use the
non-default 15 toolchain like Mesa does, presumably to get some new
feature or optimization that isn't in 14?

    smcv