I tried opening an appimage application.
but pureos said mime is missing = or something like that.
how can I install appimage appication with pureos?
Thank yo for the link.
I managed to get one appimage application to work yet another appimage application does not work.
is it possible that one application.appimage works but another app.appimage not working?
It is possible, I had a similar issue when I was running KDE-only PureOS.
A while back I installed a couple AppImages, ran fine. Went to run another and seemingly nothing happened (Balena Etcher). I found that it threw an error when trying to run it from the terminal. If I recall correctly, it was something about being unable to find a file – so maybe a dependency issue of some sort? I ended up giving up and just using dd.
I am now using PureOS with GNOME. Just now, I tried to install Etcher, and it works fine.
I wouldn’t think this should make a difference, but it could. As I understand it, AppImages contain all of the dependencies not commonly found in distros. With Etcher seemingly being a GTK application, it is possible that a KDE-only installation was missing something not included with the Etcher AppImage.
I am not a linux pro by any means, but from what I’ve been able to learn this seems a reasonable root-cause.
Could be worth exploring your exact error and seeing if it leads to missing dependencies.
I’m not an AppImage expert, but yes, I think it would be possible for one AppImage to work and another not work. If the developer of the AppImage builds it incorrectly, then it won’t work
when running the appimage from terminal i get
sherab@sherab-pc:~$ ./ShuffleStudy-1.4.3-x86_64.AppImage installed: X-AppImage-BuildId=97587930-4842-11a9-0af8-17c2a8c48791 image: X-AppImage-BuildId=97587930-4842-11a9-0af8-17c2a8c48791 Segmentation fault
Hmm, that isn’t the most verbose of errors, but I’m going to take a guess at the problem. Given the
X-AppImage part, it seems to me like it might be built for the Xorg display protocol and not Wayland, which PureOS uses by default. You could try logging out, and then when logging in again, clicking the gear icon under the username/password field and choose the “Xorg” login option, then try the AppImage again.
A quick search of the interwebs reveals that a segfault with appimage files usually has to do with the appimage itself in some way.
To add to this, I just tried to run the ShuffleStudy AppImage mysef and encountered the same error. Running latest PureOS, fully updated.
I tried the same thing running Debian 10 Buster, fully updated, same error. Both with Wayland and Xorg in GNOME, and Plasma for giggles, too (all in a VM). No dice.
I’d recommend looking to the developer since it seems to be this one AppImage.
Thanks for your help
Yeah I contacted the developer who was very nice but said he doesn’t have the resources for looking into it.
And so it seems that this will remain the state of affairs with this particular appimage.
The interesting thing is that this appimage does work in Linux mint 19.
Any how thanks for your help
I tried and installed:
However, trying to launch Session (a secure zero trust chat client) AppImage on my Librem 5 doesn’t launch the desktop app. No error is shown or provided. AppImageLauncher does correctly integrate the app and I can see a desktop icon which is cool. Just doesn’t work…
Is there anything else i need to install to get those to launch on PureOS 10 Byzantium on Mobile?
The Purism instructions are just out of this world by the way, I don’t know any other vendor doing such good documentation.
Launching the same session app in Ubuntu 23.04, which uses Wayland, for windowing system, works just fine.
that appimage is build for x86_64 not arm64:
file session-desktop-linux-x86_64-1.11.0.AppImage session-desktop-linux-x86_64-1.11.0.AppImage: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.18, stripped
that"s not gonna run on the librem5.
thanks I totally missed the x86 part, now trying to figure out if they build an ARM64 version…
I wish Linux would have a subsystem that identifies and manages apps better and is more informant on failed launches, it basically often time shows nothing - that is true for Flatpak, Deb, AppImage etc., why not generate user messages “please use ARM64 version, or the version you are trying to execute is not compiled for your system etc…”
Please are trying to make it work: https://github.com/oxen-io/session-desktop/issues/1635
Nobody has been able to do it. It appears turning it into an Electron App, then installing it on ARM64 as .deb is pointed to as a promising route.
how is an executable build for an x86 application supposed to run on an arm64 processor to display that expected error. There are so many tools directly available on Linux to figure that out yourself.
by the way the releases on github show the x86_64 within the naming.
This is another strike against Electron apps on arm64 it seems.
On the face of it, you are of course correct but … this is not a new problem and there are easy solutions to this problem. The simplest would be that the target file to be executed contains an indicator of its architecture and the code that reads the target file first checks that indicator before bothering to load the file or at least before transfering control to the loaded file.