Provide AppImages - Githubissues

TheAssassin commented 7 years ago

Currently there's an AppImage build script for murmur. I'd love to see such a script for the client, too, especially for snapshots of the development versions, but also for the stable ones.

I love Mumble, and I'd like to just download new versions and check them out without having to go through the hassle of adding a PPA. Download, make executable, run -- that sounds like the right way. It can be done with the server (using those "static binaries"), so why not offer that for the client, too?

EDIT (from @Krzmbrzl): As per #6463, AppImages would also be nice for the server

mkrautz commented 7 years ago

Haven't gotten there yet. :-)

probonopd commented 6 years ago

What is the status and/or level of interest in this? Is there anything I could help with?

mkrautz commented 6 years ago

There is a lot of interest, still... At least from me. I want to see it happen. :) But I'm sad I haven't had the time to tackle it. :(

It's just that I want to fit it into our build system here. We build Windows/macOS/Linux from the same sources with the same patches. Ideally, the client AppImage would be handled the same way. Obviously, I can't expect you guys to fiddle with our brittle .build scripts, so I guess that's on me.

However, while I'd ideally like the client to use the same deps as the other platforms, all the "other" work could of course be done independently of that.

Some general "Mumble" points:

Mumble supports positional audio plugins. On Windows, they're installed into Program Files/Mumble/Pugins, on macOS they live in the app bundle. The obvious way would be to put them into the app bundle, but that's not very transparent to the user. Ideally, the app would be distributed as an .AppImage without a tarball at all, so I'm not totally sure what to do here.

Mumble also has an overlay feature. It's implemented a shared library you can LD_PRELOAD into your game. (In the future, we might inject it automatically, or use other means, e.g. Vulkan validation layers, which is what Steam uses for its Vulkan overlay on Windows and Linux). Anyway: since this library needs to be LD_PRELOADED, it needs to live on the filesystem. Right now, there is also a shell script users can use, as a wrapper, to launch games through. It's called mumble-overlay. You use it like mumble-overlay glxgears to launch an overlay-enabled glxgears. I suppose the overlay library could like in the .AppImage, and we could do some kind of runtime detection to find the .AppImages mountpoint, and use the library from there. Is this a problem that has already been solved? Also, it'd make sense to ship both an i386 and an x86_64 variant at the same time, to allow the overlay to inject into games of both architectures.

Some AppImage questions:

For GUI apps, it is my impression that many libs are not included in the .AppImage itself. Would things such as glib, pulseaudio, etc. etc. be bundled, or would the AppImage rely on the system? Obviously, both methods would probably work in practice. If I were to build a Mumble .AppImage, I would probably stuff as many deps in there as possible, and not rely on the system. That's what our Murmur AppImage does. The reason it does it, is because it's how our current "static" builds work via Magic Ermine.

TheAssassin commented 6 years ago

I am not sure what the problem about the positional audio plugins is. User specified ones should go in their home directories, standard ones provided by the Mumble project can just be put into the AppImage. At least that's what most projects do with their, let's say, auxiliary data.

The overlay is pretty buggy on Linux anyway in my experience (sorry, just my experience -- it doesn't want to work with quite a share of games (e.g., any game that uses SDL 2 won't show the overlay, which is at least half of them)), so I wouldn't mind if that feature wasn't available from the AppImage at first. It could be implemented by using a custom AppRun inside the AppImage (maybe implemented as a shell script) which calls said script when a specific flag is passed or so. You're probably over-engineering this a bit. And the architecture issue could be dealt with that way easily, too, by having that script detect the target binary's architecture and LD_PRELOADing the right library.

In general, our tools bundle all libraries except for so-called "basic" ones, which involve glibc, libstdc++, etc. and a few ones which used to be conflicting on some systems. They are managed in a blacklist called excludelist. This list is maintained with great care, so you can rely on it. There's so many AppImages working with different sound systems etc., and they all work fine, and bundle or don't bundle libraries based on this list. Of course, one has to test the AppImages on different systems (different combinations of desktop environments, sound systems etc.), but that's a necessity for all methods of distribution.

The tool you want to try for the client is linuxdeployqt, a kind-of-automagic tool that takes care of bundling Qt plugins and also all general libraries (by passing a flag called -bundle-non-qt-libs). It is used by many Qt and non Qt based projects, and people like it for being quite easy to use. You should be able to write some script based on the example Travis CI script that works for your build system.

Fun fact: I am already building Mumble AppImages on Travis CI using linuxdeployqt that work fine for me and @probonopd. Check out my fork: https://github.com/TheAssassin/mumble/blob/master/.travis.yml and https://github.com/TheAssassin/mumble/blob/master/scripts/travis-ci/build_appimage.bash It wasn't really hard to write that script, and it works great so far. Feel free to copy and adapt it.

If you should be working on this once, feel free to leave me a message on IRC as well. I'm there very regularly, and can probably help sort out some quirks or fix some of the common anti patterns.

By the way, AppImage have their own update mechanism which works with little infrastructure effort (you just need some HTTP server somewhere, and upload a file). See https://github.com/AppImage/AppImageUpdate. AppImageUpdate can be used as a C++ library (it's written in C++11), and there's efforts to make a Qt user interface, but you could write your own interface as well (that's what e.g., Subsurface plan to do, greetings @dirkhh). I could imagine that you could write some Linux specific interface that blends with the existing update check.

probonopd commented 6 years ago

I suppose the overlay library could like in the .AppImage, and we could do some kind of runtime detection to find the .AppImages mountpoint, and use the library from there. Is this a problem that has already been solved?

$APPDIR in the environment will give you the mountpoint, and $APPIMAGE will give you the path to the AppImage file. You can use them,e.g., in your custom AppRun script.

mkrautz commented 6 years ago

I am not sure what the problem about the positional audio plugins is. User specified ones should go in their home directories, standard ones provided by the Mumble project can just be put into the AppImage. At least that's what most projects do with their, let's say, auxiliary data.

Agreed. My thinking was just that the plugins being opqauely stored in the AppImage could confuse people. But that line of thinking requires that users actually go look for the plugins on the filesystem, which is probably quite unlikely. Furthermore, it could be argued that an .AppImage is no more opaque than a macOS .app bundle.

Actually, support for opening .AppImages directly in file managers/extractors would be neat. Would be cool to be able to explore them without too much effort.

TheAssassin commented 6 years ago

Well, "support in file managers" to us means that one can double click run it, which works already today (after making them executable, of course, but we're working on removing that step or replacing it with a Windows UAC like security dialog).

But certain archive managers should be able to read AppImages, at least type 1 ones, as they're valid ISO files. (However, please don't take that as an argument for using the deprecated type 1, type 2 is so much better.)

Type 2 AppImages support self-extraction, call with --appimage-extract. We further plan to add a function to appimagetool to extract both type 1 and type 2 AppImages, by the way.

Krzmbrzl commented 3 years ago

The AppImage we are currently building is broken. Thus we would appreciate if someone (with AppImage experience) could look into this as we currently don't have the capacities to fix it.

TheAssassin commented 3 years ago

@Krzmbrzl link please.

Krzmbrzl commented 3 years ago

The AppImage is always built as part of our CI job on Azure Pipelines. It can be found as a published "artifact" on the respective CI build overview. The latest build can be found at https://dev.azure.com/Mumble-VoIP/Mumble/_build/results?buildId=3200&view=results

trymeouteh commented 2 years ago

Would like to see an AppImage for Mumble.

Windows users have the ability to download the installers for Mumble client install the client offline and backup the EXE installers. Mumble makes for a good communication app and service over mesh networks and having the ability to backup the client and server is essential if the internet goes down to deploy Mumble.

codecnotsupported commented 1 year ago

The AppImage is always built as part of our CI job on Azure Pipelines. It can be found as a published "artifact" on the respective CI build overview. The latest build can be found at https://dev.azure.com/Mumble-VoIP/Mumble/_build/results?buildId=3200&view=results

I don't see any appimage artifacts.

Krzmbrzl commented 1 year ago

Yeah, we no longer build the AppImage as it was broken and nobody has had the tine yet to look into fixing it.

mumble-voip / mumble

Provide AppImages #4659