My cin appimage won't start. Ic changed to debian trixie. No way to start appimages atm.
I had the problem with appimages in the past so I decided not to use them and to use cin from the official but very outdated debian 10 repo.
At debian trixie these appimages again don't work. The reason is that this appimage stuff depends on old outdated Fuse2 libraries-> https://community.cryptomator.org/t/appimage-fails-to-run-on-ubuntu-24-04-lts/13863/5
I don't think these appimages are a good thing. Partially maybe but not as a robust deployment of code.
from source -> full pain
old repos: just horrible
the appimages: suck completely
This is very bad. MatN helped to establish AppImage because we lost our main programmer who used to create packages for several versions of multiple distros. AppImage was the only way for us to keep providing updates. I will email MatN to see if he can help with a viable solution.
Thank you very much.
Wouldn't it be possible to deploy the source code too? (Maybe I 'd stuck with it too)
These appimages are as they are and they bring dependencies.
Compiling from source sometimes can be real pain but then there's a chance to have it running. ATM there's no way (for me). I could downgrade Fuse which would cut off major filesystem functions. I think nobody wants that.
There is a package release for Defian 12 at:
https://github.com/einhander/cin-gg-packages/releases/tag/20240715
Not sure if that will work for Trixie though or if you have time to test that. Andrey updates this for recent O/S versions.
I'm following now
This is a good working solution. For me this method is best.
You just need one package (libsuil-0-0) which luckily is inside the multimedia repo of Christian Marillat
trixie has some transition packages (t64).
Installing libfuse2t64 makes the appimages working again without dependencies trouble (at least in my case).
It can be installed side by side to libfuse3-3.
After informing the Mailing List, we are now more prepared for other users to have the same problem. We updated the website news at:
And Andrey noted that libfuse2t64, being a temporary solution, most likely will not work with Debian 13 as the official release later.
Again, thank you so much for the early warning!
I must say I was wrong with appimages at my entry post. It of course isn't the appimage that's bad but the lack of output when something goes wrong and the dependency for older libfuse versions. It had just been so frustrating because I wasn't able to find a solution. Everywhere it was said you just need to make it executable and then run it.
Perhaps you can edit the last line of my entry to make it a little bit less flavoured.
The t64 files aren't temporal but transitional packages which deal with the year 2038 problem. I can't say whether they will stay at the final release as they are or not (at all).
The problem with t64 files could arise if CinGG would check for dependencies e.g. libasound2 which already has been installed with libasoundt64.
CinGG wouldn't be able to start because the name check fails.
If they dropped libfuse2t64 in the future new appimages probably would to be created with dependy for libfuse3 - just an assumption.
At the moment the problem with appimages is that they don't give any output they need the older libfuse2t64 dependency.
So for debian users the installation with dpkg is the better solution because it gives you terminal output, installs over older versions and so on.
As long someyone is able to maintain .deb release candidates.
Because not everybody is using debian (and .deb) of course your notes on handling appimages could be really helpful to some users.
You could add to the notes how to build a new appimage that previously has been extracted and modified:
$ <system architecture> <destination appimage> <source>
Example:
$ ARCH=x86_64 ./cingg.AppImage squashfs-root/
I messed up some things with my entry post.
Hopefully this post can fix that.
Oh No! something else to worry about -- the 2028 problem which I was blissfully unaware of. And then there is the analogous storage constraints problem of 2106.
Thanks for additional information. Your original post is just fine as is -- package installation of CinGG is definitely a preferred method of running CinGG, especially since you can automatically get the updates as they come out if that aspect is enabled. About the below quote, it is stated in the manual how to do this -- however if having trouble with running appimage in the first place, you would not want to make another appimage anyway!
You could add to the notes how to build a new appimage that previously has been extracted and modified/
