Need AlmaLinux tutorial for manylinux_2_28 wheels

[abitrolly]

Description

When trying to build OpenDHT over the last week (which started with #1139) I discovered that.

1. dnf should be used instead of apt (which runs on ubuntu-latest) to install dependencies
2. EPEL repo should be enabled for certain packages
3. Other packages also require certain module to be enabled

#1154 contains all the details.

And after finally installing all the dependencies my build is still failing, because the version of asio-devel lib is too old. AlmaLinux ships with 1.10.8 and I need it to be 1.12+ (savoirfairelinux/opendht#488)

Now I am a looking at how to backport 1.12+ to AlmaLinux for building a Python wheel to try.

Build log

https://github.com/abitrolly/opendht/runs/6962066571?check_suite_focus=true

CI config

https://github.com/abitrolly/opendht/actions/runs/2527210411/workflow

[henryiii]

almalinux:8 is a rebuild of RHEL (Red Hat Enterprise Linux) 8, just like centos:8 was and rockylinux, etc. is. You use it just like you'd use the next version of manylinux2014. You can use yum, it's still provided, but dnf (which stands for "dandified yum") is the newer/recommended way to do things by Red Hat. Basically pretend manylinux_2_24 follows manylinux2014 and forget manylinux_2_24 ever existed, and you should be fine. EPEL has always been needed for older manylinux's as well if you actually needed those packages (many projects don't).

I'd think this might be a more general, non-specific to manylinux_2_28 bit of advice on things like installing packages, enabling EPEL, etc, with just a mention of the dnf recommendation for manylinux_2_28+, and we could simply drop mentions of manylinux_2_24 as it sounds like it's being discontinued (depending on what happens there). Maybe in the FAQ?

[abitrolly]

The amount of info with examples that needs to be followed looks more like a tutorial.

[henryiii]

That depends dramatically on what you are building. And that's why we have an examples page listing known projects. You could add your project with a description like "Example of manylinux_2_28 build that adds EPEL and custom build of asio". There is not a one-size-fits-all configuration; many users won't need EPEL, very few will need to rebuild asio, but might need other repos or additions. Or custom builds of dependencies. Etc. I think we can provide a few hints and lots of links to projects that are working, like we do now (but with a few more hints, like dnf being faster & how to enable EPEL).

[abitrolly]

I believe this OpenDHT + asio hits the worst case scenario. It uses external to Python build system for building the main lib that is wrapped. The lib has a dependency that is not found by dnf by default. Not found after enabling EPEL, not found after enabling powertools where it is located, and only becomes visible when you enable mariadb-devel module. And after all of that I build the dependency from source, because packaged version is too old.

Now I have this pathetic situation where the build fails, because the wheel is broken and can not be repaired.

# auditwheel repair --lib-sdir . __asio/opendht-2.4.5-cp36-cp36m-linux_x86_64.whl
INFO:auditwheel.main_repair:Repairing opendht-2.4.5-cp36-cp36m-linux_x86_64.whl
Traceback (most recent call last):
...
ValueError: Cannot repair wheel, because required library "libopendht.so.2" could not be located
# ls -la libopendht.so.2
lrwxrwxrwx. 1 root root 19 Jun 20 09:45 libopendht.so.2 -> libopendht.so.2.4.5

[abitrolly]

Problem with the list of packaged projects is that there is no entrypoint and no explanations. A bunch of files that just works may be good for troubleshooting a project that doesn't work, but that implies you already understand the big picture and details.

[abitrolly]

Took me 8 days to create this wheel savoirfairelinux/opendht@master...abitrolly:cibuildwheels.log

[henryiii]

Great! (not the 8 day part, but the wheel being made part!)

apt-get -y install $(grep "^[^#]" dependencies.txt)a

Besides the a, this likely won't work since Debian uses -dev for libraries, not -devel, even if they happen to all have the same names.

name: opendht-wheels-linux

If you add "linux" to the artifact name, you'll need another download step if you add another OS. GitHub Actions elegantly merges artifacts as it goes if they have the same name.

[abitrolly]

Fixed the comment. Thanks. Originally the idea was to have requirements.txt equivalent, with OS selectors etc. But then $(grep "^[^#]" dependencies.txt) won't be enough to filter out lines for different OS. If Debian dependencies are needed, they could be placed into dependencies-debian.txt then.

The uptodate PR is here savoirfairelinux/opendht#619. I saved the branch comparison above with the full of of the process in case the PR needs to be smashed.

[abitrolly]

If you add "linux" to the artifact name, you'll need another download step if you add another OS. GitHub Actions elegantly merges artifacts as it goes if they have the same name.

It is possible to download everything in one step https://github.com/actions/download-artifact#download-all-artifacts

[henryiii]

It is possible to download everything in one step

Yes, but then it's not together in one place for easy upload, it's now in nested folders. If you combine it all in a single artifact you can even extract it into the expected folder for the pypi action, reducing configuration there too. I've worked long and hard to make this as simple and easy as possible with minimal friction, both for teaching/training and for the 40 or so projects I help maintain.

[henryiii]

Have you tried publishing this yet, like to TestPyPI? Looks like you forgot to unpack it to dist/*, so the PyPI upload action won't be able to find it.

[abitrolly]

Have you tried publishing this yet, like to TestPyPI? Looks like you forgot to unpack it to dist/*, so the PyPI upload action won't be able to find it.

No, haven't got time. Trying to understand how to make "release on tag" working with "inter workflow gating" for fschulze/sqlalchemy_schemadisplay#30 So first I need to compare contexts and then still do TestPyPI upload without affecting the PR. Which means I need to configure action through fork specific env variable, and I am not sure actions support env variables as a way to configure them. Specifically if it is possible for https://github.com/pypa/gh-action-pypi-publish action. Too many things to test.

[abitrolly]

Asked how to test wheels in forks here #1164