appimagetool has old URL, does not check runtime size nor HTTP status code

[eugenialoli]

Due to a bug on freecad on ubuntu/mint systems, we have to extract its appimage, cd to its squashfs_root folder that created, remove its /usr/lib/libstdc++ library, and then recreate the appimage using the appimagetool. However, that didn't work, while in the past, that worked, and it was the way to make it work on ubuntu systems. Now we get this:

./FreeCAD-x86_64.AppImage
bash: ./FreeCAD-x86_64.AppImage: cannot execute binary file: Exec format error

[probonopd]

@eugenialoli please provide the complete script with all the steps so that we can replicate this by copy and paste. Thanks!

[eugenialoli]

This is the script/steps I used (using the latest freecad appimage, downloaded from their site): FreeCAD/FreeCAD-Bundle#102 (comment)

[probonopd]

Where to download FreeCAD_weekly-builds-28765-Linux-Conda_glibc2.12-x86_64.AppImage from?

[eugenialoli]

I just said above that I used the latest freecad appimage, not the specific version mentioned in the script that I linked above. The problem happens with the latest appimage, but the rest of the script/steps is the same. You can get the latest appimage from the main freecad download site. Freecad is the premiere cad app for linux.

[probonopd]

cat /etc/os-release | head -n 1
# PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"

cd /tmp
wget https://github.com/FreeCAD/FreeCAD/releases/download/0.21.2/FreeCAD-0.21.2-Linux-x86_64.AppImage
chmod +x ./FreeCAD-0.21.2-Linux-x86_64.AppImage
./FreeCAD-0.21.2-Linux-x86_64.AppImage
# Works, no further modification necessary

# But anyway, let's proceed...
( cd squashfs-root ; mv ./usr/lib/libstdc++.so.6 ./usr/lib/libstdc++.so.6.removed ; cd .. )

wget https://github.com/AppImage/appimagetool/releases/download/continuous/appimagetool-x86_64.AppImage
chmod +x appimagetool-x86_64.AppImage
./appimagetool-x86_64.AppImage squashfs-root
# Downloading runtime file from https://github.com/AppImage/type2-runtime/releases/download/continuous/runtime-x86_64
Downloaded runtime binary of size 9
# The above is the error

./FreeCAD-x86_64.AppImage
# -bash: ./FreeCAD-x86_64.AppImage: cannot execute binary file: Exec format error

The issue is that https://github.com/AppImage/type2-runtime/releases/download/continuous/runtime-x86_64 currently gives error 404 and that appimagetool doesn't check for this yet.

Reference:

• Runtime download step does not truly validate downloaded file - 404 "Not Found" deemed success #57

[probonopd]

Here is an explanation of the bug:

• This version of appimagetool does not come with the runtime bundled; instead it tries to download it when needed
• The name of the runtime has changed but appimagetool still has the old name
• This version of appimagetool does not check the status code of the download, nor e.g., the size of the runtime

We clearly need to improve this.

Temporary workaround:

wget https://github.com/AppImage/type2-runtime/releases/download/continuous/runtime-fuse3-x86_64
./appimagetool-x86_64.AppImage squashfs-root --runtime-file=runtime-fuse3-x86_64

[probonopd]

@TheAssassin please let us re-consider to bundle all runtimes inside the AppImage for appimagetool. The advantages will be:

• We can change the name of the type2-runtime repository without breaking appimagetool each time
• We can change the name of the type2-runtime files without breaking appimagetool each time (the reason for this ticket)
• Things are way more robust

This whole on-demand downloading of the runtime creates way more complexity and unnecessary potential error cases than we would like to have.

[TheAssassin]

No. Just no. No. I'm tired of having the same discussion every week. It makes no sense at all. It just causes a variety of other issues and introduces a dependency hell I'm glad I could get rid of.

The name of the runtime has changed but appimagetool still has the old name

That was your idea. Maybe we should change that. Even if that means I need to revert changes in a few other places which also depend on the correct file name.

Things are way more robust

No. Also, you can't just claim that without providing any kind of argument or evidence. We've experienced the exact opposite in the past.

[probonopd]

@eugenialoli the name of the runtime file has changed again, so you need to download the latest appimagetool again.

Something I'd like to improve in the future by

• Consider to bundle the runtime #61