Provide more insight into ```auditwheel repair``` failures?

[dralley]

One of my packages won't build because of "too recent versioned symbols", however, it won't tell me which one:

https://github.com/dralley/createrepo_c/runs/447946439?check_suite_focus=true#step:7:321

There are some commands to provide that information -- is there any chance that the CI could expose that information somehow, if the repair fails?

https://github.com/pypa/auditwheel/issues/159

[RalfG]

I can update entrypoint.sh to run auditwheel show "$whl" if auditwheel repair failed.

I ran this locally with your package and got the following output:

+ auditwheel show /github/workspace/wheelhouse/createrepo_c-0.15.7-cp36-cp36m-linux_x86_64.whl

createrepo_c-0.15.7-cp36-cp36m-linux_x86_64.whl is consistent with the
following platform tag: "linux_x86_64".

The wheel references external versioned symbols in these system-
provided shared libraries: libz.so.1 with versions {'ZLIB_1.2.2.3',
'ZLIB_1.2.3.5', 'ZLIB_1.2.3.3'}, liblzma.so.5 with versions
{'XZ_5.1.2alpha', 'XZ_5.0'}, libxml2.so.2 with versions
{'LIBXML2_2.4.30'}, libcrypto.so.10 with versions {'OPENSSL_1.0.1_EC',
'libcrypto.so.10'}, libc.so.6 with versions {'GLIBC_2.12',
'GLIBC_2.3', 'GLIBC_2.7', 'GLIBC_2.14', 'GLIBC_2.15', 'GLIBC_PRIVATE',
'GLIBC_2.3.3', 'GLIBC_2.3.4', 'GLIBC_2.3.2', 'GLIBC_2.17',
'GLIBC_2.11', 'GLIBC_2.2.5', 'GLIBC_2.4', 'GLIBC_2.8', 'GLIBC_2.16'},
libattr.so.1 with versions {'ATTR_1.0'}, libdl.so.2 with versions
{'GLIBC_2.2.5'}, libpthread.so.0 with versions {'GLIBC_2.2.5',
'GLIBC_2.3.3', 'GLIBC_2.3.2'}, libm.so.6 with versions
{'GLIBC_2.2.5'}, libgssapi_krb5.so.2 with versions
libnss3.so with versions {'NSS_3.12.6', 'NSS_3.21', 'NSS_3.11.1',
'NSS_3.10', 'NSS_3.3', 'NSS_3.5', 'NSS_3.34', 'NSS_3.14.3',
'NSS_3.12.5', 'NSS_3.15', 'NSS_3.6', 'NSS_3.11.2', 'NSS_3.9.2',
'NSS_3.9', 'NSS_3.22', 'NSS_3.13', 'NSS_3.2', 'NSS_3.7', 'NSS_3.12',
'NSS_3.8', 'NSS_3.3.1', 'NSS_3.14', 'NSS_3.9.3', 'NSS_3.19.1',
'NSS_3.11', 'NSS_3.12.1', 'NSS_3.4'}, libssl3.so with versions
{'NSS_3.2', 'NSS_3.4', 'NSS_3.14', 'NSS_3.11.4'}, libfreebl3.so with
versions {'NSSRAWHASH_3.12.3'}, libnssutil3.so with versions
{'NSSUTIL_3.21', 'NSSUTIL_3.15', 'NSSUTIL_3.14', 'NSSUTIL_3.12',
'NSSUTIL_3.13', 'NSSUTIL_3.39', 'NSSUTIL_3.38', 'NSSUTIL_3.24',
'NSSUTIL_3.12.5', 'NSSUTIL_3.17.1', 'NSSUTIL_3.31', 'NSSUTIL_3.12.3'},
libacl.so.1 with versions {'ACL_1.0'}, libpopt.so.0 with versions
{'LIBPOPT_0'}, librt.so.1 with versions {'GLIBC_2.2.5'},
libresolv.so.2 with versions {'GLIBC_2.2.5'}, libssl.so.10 with
versions {'libssl.so.10'}, libk5crypto.so.3 with versions
{'k5crypto_3_MIT'}, libkrb5support.so.0 with versions
{'krb5support_0_MIT'}, libkrb5.so.3 with versions {'krb5_3_MIT'},
libkeyutils.so.1 with versions {'KEYUTILS_0.3', 'KEYUTILS_1.0',
'KEYUTILS_1.5'}, libgcc_s.so.1 with versions {'GCC_3.3.1', 'GCC_3.0'},
libelf.so.1 with versions {'ELFUTILS_1.0'}

This constrains the platform tag to "linux_x86_64". In order to
achieve a more compatible tag, you would need to recompile a new wheel
from source on a system with earlier versions of these libraries, such
as a recent manylinux image.

To make testing this a bit easier, you can easily build and run the container locally with the Dockerfile and entrypoint.sh.

[RalfG]

You can run it on Actions with v0.2.1-manylinux2014_x86_64

[nick-youngblut]

I'm having a hard time finding the versions available for each manylinux option. For instance, which versions are available for manylinux_2_31_x86_64? Is v0.2.1-manylinux_2_31_x86_64 available? What about v0.3.1-manylinux_2_31_x86_64?

It appears that can't just use 0.5.0:

Error: Unable to resolve action `RalfG/python-wheels-manylinux-build@v0.5.0-manylinux_2_31_x86_64`, unable to find version `v0.5.0-manylinux_2_31_x86_64`

Also not working:

Error: Unable to resolve action `RalfG/python-wheels-manylinux-build@v0.5.0-manylinux_x86_64`, unable to find version `v0.5.0-manylinux_x86_64`

[nick-youngblut]

The reason why I'm trying to figure out which manylinux_*_x86_64 to use:

This constrains the platform tag to "manylinux_2_31_x86_64". In order
to achieve a more compatible tag, you would need to recompile a new
wheel from source on a system with earlier versions of these
libraries, such as a recent manylinux image.