CI experiment: Build on latest Debian

[geofft]

Mostly just want to see what the symbol validation failures are....

[indygreg]

The problem with this is the glibc version will be too new and binaries won't run an older Linux distros.

We currently use Debian 8 Jessie as our base image / glibc for x86-64 and Debian 9 for aarch64 and cross-compiled arches.

Debian 8 is running glibc 2.17, which is ancient. Debian 9 is running glibc 2.24. Per https://github.com/pypa/manylinux manylinux2014 is glibc 2.17. So upgrading to Debian 9 would drop manylinux2014 ABI compatibility and would make manylinux_2_24 the minimum supported platform tag.

IMO I think enough time has passed that we should switch to Debian 9.

(It would be awesome if uv could record metrics for the glibc version seen in the wild. This would really help make data based decisions about when it is safe to drop ABI compatibility.)

[geofft]

Yea, I'm working on that, this is not for review yet ;)

[geofft]

Still not ready for review, but the last commit is the beginning of a tool to decrease the symbol version requirements where safe (a lot of symbols gained a new symbol version when glibc consolidated libdl, libm, etc. into libc). It is not yet wired into the build. With a manual (non-standalone) build of CPython from source, I am down to about 30 too-new symbols with that, of which ~half ought to be weakly linked (there's an example of how to do that with memfd_create) and ~half require staring at glibc to see exactly what they did with the ABI and how to manually bypass it (there's an example of how to do that with __libc_start_main).