Appimage v1.0.0 did not work

[yahbluez]

Is there an existing issue for this?

• I have searched the existing issues

Problem description

This Appimage:

https://github.com/FreeCAD/FreeCAD/releases/download/1.0.0/FreeCAD_1.0.0-conda-Linux-x86_64-py311.AppImage

has only a size of 649 MB compared to ~ 800 MB a working one has.

It crashed every time with this message:
"execv error: No such file or directory"

Full version info

Freecad 1.0.0-conda Linux x86_64 Appimage

Subproject(s) affected?

None

Anything else?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[tarman3]

FreeCAD 1.0.0.39109 (Git) Conda AppImage, Arch Linux (KDE/plasma/xcb)

OS: Arch Linux (KDE/plasma/xcb)
Architecture: x86_64
Version: 1.0.0.39109 (Git) Conda AppImage
Build type: Release
Branch: (HEAD detached at 1.0.0)
Hash: 2fcc5317fe3aee96ca73475986a577719fc78e20
Python 3.11.9, Qt 5.15.13, Coin 4.0.3, Vtk 9.2.6, OCC 7.7.2
Locale: English/United States (en_US)
Stylesheet/Theme/QtStyle: FreeCAD Dark.qss/FreeCAD Dark/Fusion
Installed mods: lattice2 1.0.0; CurvedShapes 1.0.13; MeshRemodel 1.10.34; freecad.gears 1.3.0; fasteners 0.5.31; sheetmetal 0.5.8; Silk 0.1.5; Curves 0.6.51

[oursland]

@yahbluez Are you using AppImageLauncher, by chance?

[yahbluez]

@oursland i try on manjaro linux and did not change anything. The older version like the RC2 work, the snap version also works. Starting with the launcher or from the command line booth do not work.

[yahbluez]

@tarman3

[tarman3]

To not distract system you can try:

• boot manjaro linux from usbflash in live mode
• try to run freecad

If this work, uninstall appimagelauncher in your system.

[oursland]

Unfortunately, the AppImageLauncher must be uninstalled and the computer rebooted.

There's an issue in which AppImageLauncher does not support images using zstd compression, which is the default. This bug affects other recent AppImage releases from PrusaSlicer, Zen Browser, and others.

When the issue is resolved, the next version of AppImageLauncher may be installed and used.

[luzpaz]

Maybe we should make a new ticket and 'pin it' to the top of the repo until upstream fixes it?

[yahbluez]

@oursland thank you, so i will just wait for the applauncher update, which will happen soon on manjaro.
I use the snap version which runs nice have to dive in the new UI.
The changes in the sketcher are very very great.

[yahbluez]

Appimage is broken since several months not only for this new freecad, others like prusa moved to flatpak because of the kind of problem we see here.
This is from the latest prusaslicer update:

Reasons for moving to Flatpak
We understand that the decision may make some people angry and raise questions about why we are leaving something that "just works" (the AppImage). Why did we decide to leave AppImage in favor of Flatpak? There are multiple reasons. First of all, AppImage is not designed to bundle "everything". There are still assumptions about the target system that must hold for the AppImage to work. It is up to the developer to decide what to bundle with the application, and doing this decision requires to check and test on all the targeted Linux distributions, which kind of kills the whole purpose. Also, some libraries may be almost or completely impossible to bundle (such as glibc or webkit). The AppImage itself requires certain version of libfuse to be present on the target system, otherwise it does not start at all, and because some Linux distributions have upgraded from libfuse2 to libfuse3, this brings another problem into the equation. The need to use old glibc for compatibility reasons forces us to build on older distros (not to mention that we would like to provide both x64 and arm64 builds). To summarize this all, the amount of work required to keep our build infrastructure running is consuming resources that we would much rather spend on PrusaSlicer itself.

Flatpak is a tool that is already proven by time, and it solves the problem that we need to solve - it bypasses the dependency hell created by the existence of many Linux distributions and different versions of everything. The main idea is that the application is built against a defined runtime, which is then downloaded on the target computer and the application is run against it. The biggest complain people have about Flatpak is that it downloads too much data to run a single application (although a runtime is only downloaded once for all applications that rely on it). However, Flatpak only does what people assume the AppImage was doing - it bundles everything. This is not Flatpak's fault, it is really the price paid for the Linux freedom, which effectively makes every distribution is a separately maintained platform.

Flatpak also provides better user experience regarding desktop integration and application updates, and it is able to control permissions that the applications have through its sandboxing mechanism. Although this may not be appealing to all Linux users, we believe that these points are valuable to most.

Thank you for your understanding.

Link:
https://github.com/prusa3d/PrusaSlicer/releases/tag/version_2.9.0-alpha1

[CIKoolK]

I have read several reports of this AppImageLauncher "shortcoming", and upon the first had wondered WTF is AppImageLauncher; when I "Googled" it I wondered "WTF does it do that others find appealing?"

Could not answer that--just grant execute permission to the .AppImage file and launch the damned thing.

It has not been updated in over 4 years; if I were using it I'd not hold my breath waiting...

[yahbluez]

@CIKoolK beside of that, appimage today did no longer solve the task it was made for.
Today you can have appimage files that have unsolved dependencies a do not run on any system.
So i fully understand the step prusa did with the last RC of prusaslicer, stopped using appimage and moved over to flatpak which solves the distribution problem and reduces the workload and needed tests for publishing a new release.

[Samueru-sama]

@yahbluez your problem is that you have AppImageLauncher installed, which it does not support the static appimage runtime, the static appimage runtime fixes the common issue of libfuse2 being a dependency of the AppImage (Which is one of the "reasons" given by PrusaSlicer quote you have there for moving to flatpak) and also supports zstd compression, which allows for appimages that are smaller and launch faster as well.

The AppImage launcher dev recently pushed fixes on libappimage that fix the zstd issue, but I'm not sure how long it is going to take for appimage launcher to fix the other issues.

simply run sudo pacman -Rsn appimagelauncher EDIT: And reboot

Link: https://github.com/prusa3d/PrusaSlicer/releases/tag/version_2.9.0-alpha1

All the info in that link is misleading and I wonder where they got all of that from, some statements like saying that glibc is impossible to bundle are also weird.

probono actually came to sharun asking for help on how to handle webkitgtk and got a working appimage that bundles everything contrary to Prusa statement in 2 days using new tooling that he isn't familiar with.

prusa3d/PrusaSlicer#13653

So i fully understand the step prusa did with the last RC of prusaslicer, stopped using appimage and moved over to flatpak which solves the distribution problem

flatpak solves the distribution problem by shipping an entire container to use the app with, which yeah it is true that way it will work anywhere, but note that you can do the same with appimages with a distrobox container, the only difference I guess is that it is less user friendly this way, but this is how flatpak works.

And you can also just bundle everything in the AppImage and use no container if you want it that way, this is something I hope will be more common in the future, besides me I think only GIMP and Inkscape make their appimages bundling everything, and the GIMP appimage you can only get it their gitlab while the Inkscape appimage while it bundles everything, it still uses the old appimage runtime with the libfuse2 dependency.

[yahbluez]

@Samueru-sama thank you for the details.

To be honest, on today computer systems with GB of RAM and TB of storage i stopped caring too much about space needed. I will always chose speed over size and stability over everything.
I'm old school remembering the old time with 8 bit and 4096 byte of memory
but this is a long time ago.

I use linux since decades and we have still this packaging issues this no red line trough the wild.

The freecad v1 runs fine from snap that's ok to use it.

Appimage is sexy but i already use several ways and so i do not really care if one is broken this issue was only made to help because there was no info that this issue happens.

For me the task is solved.

[Samueru-sama]

To be honest, on today computer systems with GB of RAM and TB of storage i stopped caring too much about space needed. I will always chose speed over size and stability over everything.

Same, but you have to be aware that not everyone has GB of RAM and TB of storage, specially not in developing countries. also I personally was stuck with 4 mbit ADSL internet until 2020.

I know someone that has a crappy laptop from a developing country that was fed up with flatpak being bloated that they made their own appimage like alternative (they are also fed up with appimage lol). And for example the Chromium flatpak took +40 seconds to open on their laptop, while their solution takes 20 seconds. It is this.

The freecad v1 runs fine from snap that's ok to use it.

Be aware that snap has its own set of issues, for example it has a hard dependency to systemd so you can't use it on all linux systems, it also needs some kernel patches to have working sandbox. But yeah, if nothing else works then I guess you have to stick with what does.

[yahbluez]

@Samueru-sama this is so true. It would be more than cool if there would be a single system but instead each couple of years we get something more.

https://xkcd.com/927/

The biggest issue for snap is that it makes it harder to use /tmp

But the best of this all is how much freecad v1 evolved during the last 2 years.

[Samueru-sama]

It would be more than cool if there would be a single system but instead each couple of years we get something more.

https://xkcd.com/927/

Well appimage was the first of all the "universal" packaging formats, and it is the one that gets the closest to that goal when done right, and it also isn't anything special or extremely complicated (same with appbundle), they are all inspired from the executable directories of MacOS.

AppImage also has something that if you make a directory with the name of the AppImage + .home or .config it will automatically set that as $HOME or $XDG_CONFIG_HOME so you can store all the application files there together with the app. I use this for my work web browser.

Now that the static appimage runtime is available, the only requirement (when you bundle everything in it) from the system is a fusermount* binary in PATH and also a kernel newer than 4.0 iirc. And the fusermount binary isn't strictly needed as you can set the env variable APPIMAGE_EXTRACT_AND_RUN=1 which will make the AppImage self extract on /tmp and run, you don't even need access to namespaces something that both flatpak and snap depend on.

[probonopd]

you have AppImageLauncher installed, which it does not support the static appimage runtime

As far as I remember @TheAssassin has fixed that recently or is about t fix it shortly.
In any case, a topic for https://github.com/TheAssassin/AppImageLauncher/issues.

[TheAssassin]

We just merged AppImage/type2-runtime#88 (comment). Please rebuild the AppImage with the latest runtime once its build has finished. I'll push the changes to AppImageLauncher soon.

[oursland]

@TheAssassin If I understand correctly, you're requesting we update appimagetool and rebuild the .AppImage bundles?

[TheAssassin]

appimagetool from https://github.com/AppImage/appimagetool uses the latest version automatically, it is downloaded from the repository upon execution. Please rebuild the AppImage with this one.

I just did it myself locally and it is compatible with the latest dev version of AppImageLauncher.

[Samueru-sama]

@oursland Note that this also has to be reverted, that issue was also fixed.