Support for manylinux_2_24 and manylinux_2_28

[mxmlnkn]

Hello, I noticed that it only supports up to manylinux2014. Will there be support for newer manylinux base images?

[niess]

Hello @mxmlnkn,

thank you for pointing this out. I added the 2_24 and 2_28 Manylinux tags. Beware that these two new tags take an extra leading underscore as opposed to older tags. That is, the full syntax for new tags is -l manylinux_2_24 (instead of -l manylinux1 for example) when building an app.

I only briefly tried the new AppImages. Please, let me know if you see issues.

[mxmlnkn]

Thank you for adding those images so fast!

I tried my build script for ratarmount with manylinux_2_28 and it works now :)

When trying to build my script inside the manylinux_2_24 container, weirdly enough yum seems to be missing. This isn't your issue, I'm just mentioning it. The compiler in manylinux_2_24 is too old for me anyway.

When starting my successfully built AppImage based on manylinux_2_28, I'm getting:

/bin/bash: /tmp/.mount_ratarmMgIam8/usr/lib/libtinfo.so.6: no version information available (required by /bin/bash)

It seems to be a warning because my program itself runs fine but it is noise I wouldn't want my users to see and I don't get this with the manylinux2014 issue. I'm not sure whether it is an issue with the manylinux container or the base AppImage though.

[niess]

Thank you for reporting this issue.

I don't see your libtinfo warning when running the Python AppImage. Would you know what command triggers this?

Nevertheless, I also have issues with manylinux_2_28. In my case (Debian 10+) the command line does not work properly. E.g. I cannot erase/correct when typing a Python command. In addition, the curses package does not work properly (initscr fails with a no TERM error). However, when running directly from the Docker image it does work.

A difference between manylinux_2_28 and others is that it uses libtinfo.so.6, instead of libtinfo.so.5 for others.

[mxmlnkn]

I don't know which command triggers it. I might have to bisect my linked build script somehow to find the reason.

I'm not sure whether this applies: https://stackoverflow.com/a/72464818 . Answers seem to range from reinstalling ncurses from another source (conda-forge) or replacing libtinfo installed by conda with the system-provided one.

Because of connection to curses, the libtinfo warning seems very related to your observed command line issues.

[niess]

@mxmlnkn ,

thanks for the link. Indeed, it seems to be a compatibility issue between the packaged libtinfo, in the AppImage, and the local shell (also using libtinfo apparently, but expecting a different ABI in this case).

If you don't use curses, as a temporary patch, you could try to delete libtinfo.so.6 from the AppImage. In my case, it solved the command line issues. Indeed, my local system actually uses libtinfo.so.5.