Create StargateDAW

[L3337]

I do have a question about the verification; You mention testing on the oldest supported version of Ubuntu, does that currently mean 14.04? I expect that these images probably work on 18.04, or definitely 20.04, but likely do not fully work on 16.04 or earlier.

If working on 14.04 is a hard requirement to be listed, we can close the pull request, as that will not be easily possible.

[probonopd]

I mean the oldest currently supported version of Ubuntu at any given time. This is so that users who are using any of the currently supported versions of Ubuntu (and their derivatives) and hoefully similarly old other distributions will be able to use your application.

18.04 LTS (Bionic Beaver) is supported until Apr 2023.

20.04 LTS (Focal Fossa) is supported until Apr 2025.

So until Apr 2023 it is fair to assume that your users are running no newer distribution than 18.04 LTS (Bionic Beaver).

How did you end up thinking 14.04 was still a requirement? It is out of standard support since a long time. I don't think many users are still running it.

[probonopd]

Oops. StargateDAW-23.01.3-linux-x86_64.AppImage.tar.gz doesn't work. We need an AppImage file, not an .AppImage.tar.gz file.

[L3337]

How did you end up thinking 14.04 was still a requirement? It is out of standard support since a long time. I don't think many users are still running it.

Apparently I misread the requirements, where ever it was I read them. Standard support vs. End of Life, as listed on the Canonical wiki

Oops. StargateDAW-23.01.3-linux-x86_64.AppImage.tar.gz doesn't work. We need an AppImage file, not an .AppImage.tar.gz file.

Ah, I guess that is why CI/CD is failing? Of course it would be trivial to change it, but tar.gz solves a real problem: It allows setting the execute bit without the user having to do it themselves, helpful for the user experience of less advanced users. Most/all distros will not give the user a hint that they need to do so after trying to double click a freshly downloaded appimage (some are extra obtuse by requiring a right-click -> Execute even if the executable bit is set).

If you guys are not open to allowing tar.gz archives of AppImages, I'll start uploading as a plain AppImage, I'm just hesitant to throw away a solution to a real problem (but of course, any user getting deep into using AppImages is going to have to learn sooner or later, I get it).

[probonopd]

If you guys are not open to allowing tar.gz archives of AppImages, I'll start uploading as a plain AppImage, I'm just hesitant to throw away a solution to a real problem (but of course, any user getting deep into using AppImages is going to have to learn sooner or later, I get it).

Please see https://github.com/AppImage/AppImageKit/wiki/Creating-AppImages/cc2441518975caca23e9ce2dba6f08a22c678d1e#common-mistake.

Thanks for considering!

[L3337]

Fair enough. Latest release has been uploaded as a non-tar.gz'd AppImage

[probonopd]

Variable FILES is empty. is likely a bug in our test script, not related to this PR specifically. We need to find the root cause.

[L3337]

Now knowing that 18.04 is the actual requirement, I created an 18.04 test VM, and unfortunately this happened:

  File "/tmp/.mount_StargappQbyb/opt/python3.10/lib/python3.10/site-packages/sgui/sgqt.py", line 57, in <module>
    from PyQt6 import QtGui, QtWidgets, QtCore
ImportError: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /tmp/.mount_StargappQbyb/opt/python3.10/lib/python3.10/site-packages/PyQt6/Qt6/lib/libQt6Core.so.6)

Those Qt6 binaries come from pip. Usually all binaries in pip are built with ManyLinux, which is based on some ancient CentOS version from like 2014, I'm not sure why Qt6 is being built with a slightly more recent glibc than what's in 18.04, it may have something to do with the available graphics APIs.

This is probably problematic for any AppImage that uses PyQt6, because building Qt6 and PyQt6 is an absolutely daunting task that I doubt many will do. I would expect nearly 100% of PyQt6 AppImages are getting their Qt6 binaries from the same source as I am.

Currently I build all of my C code and some of my C dependencies in Debian 10 (glibc 2.28), with some C dependencies coming from Debian repos and Python dependencies coming from pip. I could easily switch the build container to Ubuntu 18.04 (glibc 2.27), but if some/all of the pip binaries are being built with glibc 2.28, that is going to be a massive undertaking to build and package all of those myself.

If you are able/willing to grant an exception (I already know it works on 20.04, that has been well tested), then that would be awesome, since 18.04 goes out of support in a few months. If not, we can close this PR for now (or leave it open), it does not make sense to spend a significant amount of time reworking the build process at this point.

[probonopd]

Yes, I understand. Let's leave it open, and revisit in April, when the test will be upgraded to a newer Ubuntu LTS then.

[L3337]

Bump. I have rebased the AppImage to Debian 11 since we last spoke, but the images still work and are compatible with Ubuntu 20.04, which uses the same glibc version.