Closed Dounial closed 8 months ago
Isn't that going against the very own principle of appimages? One executable for all.
I know the current AppImage in the releases is outdated and probably not built the right way (worked on my machine)
The only proper solution I am willing to accept is an update of the GH actions workflow
Leaving open for discussion
I wanted to add; it wasn't able to run it in my case due to this error:
I also have the same error as @Dounial (/tmp/.mount_SamRews34nNe/usr/bin/samrewritten: symbol lookup error: /lib64/libgio-2.0.so.0: undefined symbol: g_module_open_full
). Currently the AppImage isn't distro-agnostic, the solution is to fix that, not make lots of differing builds.
No, the solution is to fix the bug. You're welcome to contribute, and as I pinned in the issues tab, I am unfortunately not active on this project anymore for the time being. It would be amazing to see pull requests from the users!
EDIT: OOps, massive misread from my part! You're absolutely right @ChildishGiant ! As I keep repeating, the build chain is whack and needs to be redone :)
I am currently running Fedora and could not find a working AppImage for my distro - after reading the documentation I saw that I have to create the AppImage on my own, I don't think every Linux user is able to do so or some get confused by it (not saying it's hard or people are dumb, just wanted to point out that different new AppImages for every distro would be more user-friendly overall). The one which is provided for Ubuntu does (obviously) not work on Fedora, that's why I'm recommending AppImage-releases for different distros.
In case if someone wonders; this is a custom built AppImage created from me, I'm unsure if it works for other Fedora-users too but here it is: https://files.catbox.moe/uwb85l.AppImage