some of the wheel builds are failing

[ctb]

e.g. over in #2077, job "Build wheels for ubuntu-18.04-s390x", we're getting what looks like a crates.io update problem that is preventing a

specific jobs:

• ubuntu-18.04-aarch64
• ubuntu-18.04-ppc64le
• ubuntu-18.04-s390x

The only error I can see in the logs is:

         Updating crates.io index
    error: subprocess-exited-with-error

[ctb]

Dug into this a bit more over in #2082.

At the top of the build, where the wheel build is running .ci/install_cargo.sh, I am seeing:

      + sh -c 'source .ci/install_cargo.sh'
  head: error reading ‘/proc/self/exe’: Bad file descriptor
  head: failed to close ‘/proc/self/exe’: Bad file descriptor
  rustup: unknown platform bitness
  sh: line 358: [: : integer expression expected

which looks a bit like the problem reported here,

rust-lang/rustup#2700

For the moment, I'm inclined to let this go as "beyond my ken" and we'll revisit when we approach a release that requires wheels.

[luizirber]

#2087 postpones the issue by spliting the CI building job. Still need to figure out the underlying issue, which seems to be connected to rust-lang/cargo#8719

[luizirber]

Note: s390x is a niche arch, but aarch64 is useful (many ARM CPUs nowadays, from raspberry pi to AWS graviton) and ppc64le has users too (cz biohub used to have a large powerpc machine, if I recall correctly).

They all seem to have the same issue (which is due to using qemu+docker for emulating these archs during wheel building), so once one is fixed the other will be too, but I would personally really like to keep at least aarch64 working =]

[luizirber]

weirdly enough... once sparse registry is stable, we might avoid the problem (because it won't need libgit2 anymore)

[ctb]

this, uh, has magically fixed itself.