Linux/AppImage: Manually download the runtime to fix build error

[guihkx]

This manually downloads the old AppImage runtime (now marked as obsolete), to prevent appimage-builder v1.1.0 from failing to make the AppImage.

The download URL appimage-builder v1.1.0 uses for the AppImage runtime is hardcoded into the tool, and unfortunately it's been recently removed, so this is merely a workaround, until hopefully a future appimage-builder release fixes this.

See: AppImageCrafters/appimage-builder#375

[guihkx]

Sorry for the force push, I had to fix a grammar mistake in the commit message.

Also, this isn't supposed to be a permanent fix: It's meant just to unblock the CI/CD workflow for now.

I'll work on replacing the current tool that makes the AppImage, because it's way outdated.

[DevilXD]

Hello,

Hmm, I see. Yeah, this came up during conversation in #730. Apparently https://github.com/AppImage/AppImageTool is the new repository for the builder, but I'm not sure if that's true or not - might be worth checking it out.

Thank you for the fix =)

[guihkx]

Apparently https://github.com/AppImage/AppImageTool is the new repository for the builder, but I'm not sure if that's true or not - might be worth checking it out.

Yeah, I'll definitely check that out.

What saddens me about this, is that this was a deliberate disruption by AppImage devs to, apparently, force us into using their new runtime.

Anyway, I'll evaluate how difficult it will be to switch to their new shiny thing, but if such deliberate breakage ever happens again, feel free to completely remove the AppImage package from your repo and CI, no questions asked.

[Samueru-sama]

What saddens me about this, is that this was a deliberate disruption by AppImage devs to, apparently, force us into using their new runtime.

If you read the rationale here you will see this was done so that you can choose between the old and new runtime, you are not forced to update.

Anyway, I'll evaluate how difficult it will be to switch to their new shiny thing, but if such deliberate breakage ever happens again, feel free to completely remove the AppImage package from your repo and CI, no questions asked.

Might wanna hurry in doing it because the appimage doesn't work at all in ubuntu 20.04, which was one of the few last distros that shipped fuse2 by default.

log

./Twitch.Drops.Miner-x86_64.AppImage

** (process:10544): WARNING **: 04:29:12.593: Failed to load shared library 'libgdk-3.so.0' referenced by the typelib: /tmp/samuel/.mount_TwitchOCxtst/usr/lib/x86_64-linux-gnu/libgdk-3.so.0: undefined symbol: wl_proxy_marshal_flags
Traceback (most recent call last):
  File "/tmp/samuel/.mount_TwitchOCxtst/usr/src/main.py", line 25, in <module>
    from twitch import Twitch
  File "/tmp/samuel/.mount_TwitchOCxtst/usr/src/twitch.py", line 19, in <module>
    from gui import GUIManager
  File "/tmp/samuel/.mount_TwitchOCxtst/usr/src/gui.py", line 21, in <module>
    import pystray
  File "/tmp/samuel/.mount_TwitchOCxtst/usr/lib/python3.10/site-packages/pystray/__init__.py", line 64, in <module>
    Icon = backend().Icon
  File "/tmp/samuel/.mount_TwitchOCxtst/usr/lib/python3.10/site-packages/pystray/__init__.py", line 56, in backend
    return candidate()
  File "/tmp/samuel/.mount_TwitchOCxtst/usr/lib/python3.10/site-packages/pystray/__init__.py", line 28, in appindicator
    from . import _appindicator as backend; return backend
  File "/tmp/samuel/.mount_TwitchOCxtst/usr/lib/python3.10/site-packages/pystray/_appindicator.py", line 21, in <module>
    from gi.repository import Gtk
  File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1006, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 674, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 571, in module_from_spec
  File "/tmp/samuel/.mount_TwitchOCxtst/usr/lib/python3.10/site-packages/gi/importer.py", line 146, in create_module
    importlib.import_module('gi.repository.' + dep.split("-")[0])
  File "/tmp/samuel/.mount_TwitchOCxtst/usr/lib/python3.10/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1050, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1006, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 674, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 571, in module_from_spec
  File "/tmp/samuel/.mount_TwitchOCxtst/usr/lib/python3.10/site-packages/gi/importer.py", line 147, in create_module
    dynamic_module = load_overrides(introspection_module)
  File "/tmp/samuel/.mount_TwitchOCxtst/usr/lib/python3.10/site-packages/gi/overrides/__init__.py", line 112, in load_overrides
    override_mod = importlib.import_module(override_package_name)
  File "/tmp/samuel/.mount_TwitchOCxtst/usr/lib/python3.10/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "/tmp/samuel/.mount_TwitchOCxtst/usr/lib/python3.10/site-packages/gi/overrides/Gdk.py", line 90, in <module>
    Color = override(Color)
  File "/tmp/samuel/.mount_TwitchOCxtst/usr/lib/python3.10/site-packages/gi/overrides/__init__.py", line 189, in override
    assert g_type != TYPE_NONE
AssertionError

---

/usr/lib/x86_64-linux-gnu/libgdk-3.so.0 is present so I don't know what this mess is about.

---

Also why is the appimage released in a zip file? the documentation for years has very explicitly said that this cannot be done

This just shows that this the right way of making people aware of changes, nobody reads anything...

[DevilXD]

Also why is the appimage released in a zip file?

This entire project is released in a zip file, regardless of the underlying form of the executable. This includes not only the executable itself, but also any additional files released together with it. Right now, it's just the manual.txt file, but this system was chosen to allow any other files to be included in the future, if it'd ever be needed.

[Samueru-sama]

Also why is the appimage released in a zip file?

This entire project is released in a zip file, regardless of the underlying form of the executable. This includes not only the executable itself, but also any additional files released together with it. Right now, it's just the manual.txt file, but this system was chosen to allow any other files to be included in the future, if it'd ever be needed.

Yeah that's still wrong. The AppImage is also lacking .zsync info, so people have to manually come to the repo to update it every time.

something like the manual should be given when the user runs --help or similar, and if that's already done and you just want to make sure people read the manual, a better solution is to check on first launch and see if the user has zenity, kdialog, etc and display contents of the file on screen:

then make a lockfile in XDG_CACHE_HOME or similar so the message is only shown once.

All of this is a few lines on shell in the AppRun, you don't even have to put that code in the application itself.

But anyways just my 2 cents, thanks for the response.

[guihkx]

If you read the rationale here you will see this was done so that you can choose between the old and new runtime, you are not forced to update.

That's literally the response I linked in my post... The deliberate renaming of runtime binaries literally broke how appimage-builder works: That's not giving us a choice.

Giving us a choice would be: "Hey, we will keep the old runtime name with the name it has had forever, but if you want to switch to the new runtime, just prefix it with a new-". What was done was the opposite of that...

And no one cares if that's the "best solution", what I want is a reliable packaging tool that doesn't cause my CI to break out of nowhere...

the appimage doesn't work at all in ubuntu 20.04

That was a deliberate and conscious choice made a year ago: #423

Besides, 20.04 is EOL now, so even today I wouldn't personally support it anyway.

why is the appimage released in a zip file? that's still wrong

There's nothing wrong about it, though. A single distribution guideline was ignored because it doesn't fit the app's distribution model. I would only consider it 'wrong' if the resulting AppImage didn't work, which is not the case.

This just shows that this the right way of making people aware of changes, nobody reads anything...

Yeah, and it's also a great way of making developers turn away from AppImages forever. So call me crazy, but that doesn't seem like a good strategy when your end goal is to make developers, you know, use your packaging format...

[ivan-hc]

@guihkx libfuse2 has been discontinued since 2019, and many distros have removed it from the default installation. It's therefore a matter of convenience and security.

The change was intended as a warning to developers, "Hey, the tool you're using is obsolete. Try using the latest appimagetool if you want your AppImage to work on Fedora and Ubuntu out of the box and rely on more up-to-date and secure libraries."

It was certainly a harsh warning, but what choice did they have?

I tried to suggest replacing appimagetool in their releases, but it wasn't technically possible, according to them.

The fact is, now you know about the problem with libfuse2, and how to avoid it: use the latest appimagetool... which, among other things, can easily generate AppImage packages that support delta updates:

UPINFO="gh-releases-zsync|DevilXD|TwitchDropsMiner|latest|*x86_64.AppImage.zsync"
ARCH=x86_64 ./appimagetool -u "$UPINFO" ./*.AppDir

...assuming you distribute the AppImage as a standalone package, not in a zip archive.

[Samueru-sama]

That's literally the response I linked in my post... The deliberate renaming of runtime binaries literally broke how appimage-builder works: That's not giving us a choice.

No, you said "apparently, force us into using their new runtime" when that is bullshit, you are not being forced, you can still use the old link.

Giving us a choice would be: "Hey, we will keep the old runtime name with the name it has had forever, but if you want to switch to the new runtime, just prefix it with a new-". What was done was the opposite of that...

Alright where would that message be given? by appimagetool? Any message in the CI that doesn't cause it to fail is likely to just never be read.

A better solution would have been to update the old dynamic runtime to give the message to all users that it is deprecated (similar to how flatpak works with EOL runtimes) and they then go and open issues about it. but this would have meant that the runtime itself had to be updated and replaced in place. which sounds like being forced...

And also it is an unnecessary over complication to add version checking on the appimage runtime, which means it needs to connect to the internet.

That was a deliberate and conscious choice made a year ago: #423

yeah and still make no sense to ship an appimage that requires libfuse2 when the last distro that had this installed by default was dropped deliberately.

AppImage is meant to be download and run, having to install a dependency is anything but that.

Yeah, and it's also a great way of making developers turn away from AppImages forever.

If you are going to keep making broken appimages nothing of value is lost lol

[Samueru-sama]

I tried to suggest replacing appimagetool in their releases, but it wasn't technically possible, according to them.

That would have forced the new appimagetool onto people, which is a no no here 😆

[guihkx]

I think we're going in circles with the arguments, so the discussion about whether this breakage was intentional or not is pointless (even though the main developer said so himself).

A better solution would have been to update the old dynamic runtime to give the message to all users that it is deprecated (similar to how flatpak works with EOL runtimes) and they then go and open issues about it. but this would have meant that the runtime itself had to be updated and replaced in place. which sounds like being forced...

Um, no? Because AppImage runtimes are misleadingly tagged as 'continuous', they would just need to release an update to the old runtime with the warning included, and eventually all AppImages using that old runtime would pick it up. After all, not all of us have an infinite amount of time to keep up with AppImage changes.

And also it is an unnecessary over complication to add version checking

Gotcha, so what you're saying is that the ideal solution was to shift the complication to downstream developers, even though it was not a problem created by them.

AppImage is meant to be download and run, having to install a dependency is anything but that.

That is, once again, a self-dunk. Since the very beginning, AppImage has depended on libfuse2, and while attempting to improve upon that situation is valid, deliberately breaking projects that have not adapted to it yet, is definitely not.

If you are going to keep making broken appimages nothing of value is lost lol

The AppImage currently being made here should run just fine on any distro that has at least glibc 2.35 (and libfuse2, but that's hardly our fault). As far as I'm concerned, that's completely acceptable given the current app requirements.

But I guess we could do what some people seem to think is good packaging: Bundle all kinds of crap with the AppImage (including the glibc), making it so bloated that you immediately lose 500 MB of RAM just by running it... lol

[Samueru-sama]

So sad you cannot acknowledge that you said bullshit of being forced to adopt something when that was never the case.

After all, not all of us have an infinite amount of time to keep up with AppImage changes.

You haven't had time in 3 years???

and libfuse2, but that's hardly our fault

It is now after you decided to keep using the old runtime after being made aware of it.

But I guess we could do what some people seem to think is good packaging: Bundle all kinds of crap with the AppImage (including the glibc), making it so bloated that you immediately lose 500 MB of RAM just by running it... lol

That's going to be the practice in the future, and believe it or not if done right the final appimage is actually smaller than what usually gets done right now.

Don't believe me? check CPU-X.

Their old appimage that depended on the host glibc used to be +30 MiB. Now it is 26 MiB and truly works everywhere, musl distros and ubuntu 14.04 included.

So yeah, time update on a lot of stuff my man.

[guihkx]

So sad you cannot acknowledge that you said bullshit of being forced to adopt something when that was never the case.

Then you try to make an AppImage using appimage-builder 1.1.0 (which is still a recommended tool on appimage.org, by the way), without this workaround I had to find myself.

You haven't had time in 3 years???

No no, I've had it. It's just that I didn't think I would have to unbreak things (as opposed to upgrade), while I was using a runtime literally named continuous. Silly me for expecting words to have meaning. But then again, in your universe that word could have a different meaning, so that's my fault.

Now it is 26 MiB and truly works everywhere, musl distros and ubuntu 14.04 included

Yippee, now the 6 users of these distros can feel relieved! lol

@DevilXD I'm sorry for contributing to the spam here. I won't be posting here again, but feel free to lock this if you want, as this is resolved.

[DevilXD]

I mean, this PR is closed and I normally try to limit off-topic discussion, but this felt on-topic enough for me to just let it be.

In my opinion, the "why no update in 3 years" argument isn't really valid here, because that's barking up the wrong tree. This project uses appimage-builder, a completely different tool, which is still the recommended builder as @guihkx pointed out, and indeed, it hasn't had an update released in 3 years. That's the one that refused to move on, and it has nothing to do with this project being outdated. Intentionally breaking the builder because of "the great new and upgraded lib" is out now and available, doesn't really feel like a valid argument to me, regardless of the 4 MiB of space saved and greater compatibility, none of which have even been requested for this project. If anyone wanted greater compatibility, they'd do the research themselves and upgrade in-time accordingly, using a different builder (assuming one like that even exists). You just ended up pissing off many developers for seemingly no good reason, maybe besides the security of it all.

Anyway, it's over for now. I guess we're waiting for the appimage-builder maintainer to release the new update, which apparently fixes everything. @guihkx, when the time comes, please make a PR for it, if you can.