Bug#954774: mozjs68: FTBFS on armel: rust/cargo using armv7-unknown-linux-gnueabi, should be armv5te-unknown-linux-gnueabi

[Simon McVittie]

Source: mozjs68
Version: 68.5.0-2
Severity: serious
Tags: ftbfs
Justification: will break gjs and gnome-shell which previously worked
X-Debbugs-Cc: debian-gtk-gnome at lists.debian.org
Control: block 954422 by -1

mozjs68 FTBFS on armel:
> checking for cargo... /usr/bin/cargo
> checking rustc version... 1.40.0
> checking cargo version... 1.39.0
> checking for rust target triplet... 
> DEBUG: Creating `/tmp/conftest5opOdA.rs` with content:
> DEBUG: | pub extern fn hello() { println!("Hello world"); }
> DEBUG: Executing: `/usr/bin/rustc --crate-type staticlib --target=armv7-unknown-linux-gnueabi -o /tmp/conftestpb2Eua.rlib /tmp/conftest5opOdA.rs`
> DEBUG: The command returned non-zero exit status 1.
> DEBUG: Its error output was:
> DEBUG: | error[E0463]: can't find crate for `std`
> DEBUG: |   |
> DEBUG: |   = note: the `armv7-unknown-linux-gnueabi` target may not be installed

>From the cargo and rustc buildd logs, it looks as though it should be
using --target=armv5te-unknown-linux-gnueabi instead. I'm not sure where
this build system gets its idea of what the most appropriate target is.
cargo has https://sources.debian.org/src/cargo/0.40.0-3/debian/bin/cargo/
and https://sources.debian.org/src/rustc/1.40.0+dfsg1-5/debian/architecture.mk/
(/usr/share/rustc/architecture.mk) which know how to map GNU tuples to
rustc targets - we should probably be using at least architecture.mk, and
possibly also the cargo wrapper.

It isn't clear whether firefox-esr would have had this problem or not,
because it's BD-uninstallable in stable and unstable for orthogonal
reasons (it B-D on nodejs which isn't available on armel).

This is not technically a regression, because mozjs68 is a new package,
but it'll be a regression for gjs (when we get gjs to build successfully
on buildds at all, which I'm making progress on).

This needs to be resolved, one way or another, before the GNOME 3.36
transition can go through. It can either be resolved by making mozjs68
build successfully on armel, or by removing gjs, gnome-shell and all their
reverse-dependencies from armel, like we had to do for s390x in buster.

    smcv