AppImage: increase compatibility & add tests #17
Conversation
git-developer
force-pushed
the
appimage
branch
from
133879f
to
a07389f
Compare
|
Wow, the compatibility issues are a mess. Thanks a lot for digging into this and making such a detailed writeup. I am not sure about providing builds for Focal if it looks like Jammy builds should be equally compatible, but I suppose we might as well, since the distro is EOL in half a year anyway. I am still planning to look into Flatpak at an unknown future date, hopefully it will:
|
|
Thanks for looking at this so quickly!
Could you give some details about that one?
I think it doesn't hurt to create an AppImage for Focal now and drop it in 04/2025 (EOL is 2032). Maybe it helps someone. |
return sets the return code, finishes the function and continues executing. exit sets the return code and exits the script. #!/bin/bash
crashonerror() {
return 1
}
crashonerror
echo 'all good'This script returns 'all good' and RC is 0 - because return code of the last exec was from echo. I just noticed you're doing it in another place too.
Yeah that's what I meant but worded it ambiguously, won't hurt and you already tested it. |
|
Regarding exit vs. return: I start scripts with |
|
Oh, i forgot that you put -e there. |
This PR aims to improve the compatibility of created AppImages.
Current Problems
The current AppImages are based on Ubuntu LTS releases Jammy and Noble. They crash on some environments, at least:
The commented environment requires an AppImage build based on Ubuntu Lunar while Lunar is EOL.
Causes
The crashes have different causes:
The AppImage documentation explains some concepts which are important for compatibility, e.g.:
The current AppImages are not based on these concepts.
Solutions
Library exclusions have been revisited.
According to the first concept ("Build on old systems"), additional AppImages are built for popular Debian-based distributions:
The build contains a test job that runs sc-controller with the existing
check-dependencyargument. A build success now means that a) all required dependencies are part of the AppImage and b) the libraries are compatible to the host systems (at least to the extent ofcheck-dependency). The test job runs in a Docker container for several popular linux distributions:Implementation notes
/lib64directory in Ubuntu Noble.AppImageBuilder.ymlbecause no apt packagepython3-vdfexists for these distributions. When they run EOL, these extra files can be deleted.amd64arch only (I didn't figure out how to run them onarm64).Known issues
There's an open compatibility issue concerning the AppImages for newer AppImages (primarily Ubuntu Noble & Debian Trixie). They cause a segmentation fault on most distributions. The test job knows about this issue and does not fail. Here is the summary of some manual and CI tests:
The segmentation fault occurs in
ld-linux-x86-64.so.2(part of glibc) loaded by thepython3process. The kernel reports