Mumble: Provide AppImage snapshots

Created on 29 Jan 2017  路  10Comments  路  Source: mumble-voip/mumble

Providing snapshots in AppImage format would have, among others, these advantages:

  • Works for most Linux distributions (including Ubuntu, Fedora, openSUSE, CentOS, elementaryOS, Linux Mint, and others)
  • One app = one file = super simple for users: just download one AppImage file, make it executable, and run
  • No unpacking or installation necessary
  • No root needed
  • No system libraries changed
  • Just one format for all major distributions
  • Works out of the box, no installation of runtimes needed
  • Optional(!) desktop integration with appimaged
  • Binary delta updates, e.g., for continuous builds (only download the binary diff) using AppImageUpdate
  • Can GPG2-sign your AppImages (inside the file)
  • Works on Live ISOs

Here is an overview of projects that are already distributing upstream-provided, official AppImages.

Here is an __experimental Mumble snapshot AppImage__ produced using the ingredients from the precise mumble/snapshot ppa:
https://bintray.com/probono/AppImages/Mumble#files
If you want to give it a try, just download the latest AppImage file, make it executable, and run.

This is the file that was used to control the ppa-to-AppImage conversion:
https://github.com/probonopd/AppImages/blob/master/recipes/meta/Mumble.yml

Do you think this would be useful?
I'd be happy to help producing an official Mumble AppImage.

feature-request release-management

Most helpful comment

All 10 comments

Hi @probonopd,

I'd like to have AppImages for Mumble (and Murmur, in fact). Which is why I've also contributed small fixes here an there to the project when I've had time. But I'm not a big fan of using distro packages because it makes our release engineering process harder -- we don't control dependencies and can't easily patch things, the distro can introduce subtle breakges in security patches and bugfixes without us knowing, etc. etc.

Let me back up a bit.

All of our binary packages are produced with build environments from mumble-releng, for example:
https://github.com/mumble-voip/mumble-releng/tree/master/buildenv/1.3.x/osx

We build everything from source. That way, there is no distro that can introduce breakages behind our back in bugfix/security releases. And it allows us to have reasonably good response in case of vulnerabilities in dependencies: we can rebuild all build environments for all OSes, and release a fixed binary release.

Where I'd like to get to is to be able to have a Linux buildenv for Mumble and Murmur which we can generate AppImages from. That's my end goal.

We're pretty much there for Murmur, where we have a build environment, "centos-ermine", which uses CentOS 5 and builds a dynamic Murmur which can be run through appimagetool to generate an AppImage. (This is mainly what I've contributed patches to AppImage for, for now...).

I mean, I'm not necessarily opposed to having an official AppImage for Mumble based on the Precise PPA, but from my testing, it sadly doesn't work to well.
I've tried to run it on Ubuntu 16.10, and I can't start it:

$ ./Mumble-1.3.0.glibc2.15-x86_64.AppImage 
/bin/bash: /tmp/.mount_ccpPHH/lib/x86_64-linux-gnu/libtinfo.so.5: no version information available (required by /bin/bash)
Unable to load library icui18n "Cannot load library icui18n: (libicui18n.so.48: cannot open shared object file: No such file or directory)" 
<W>2017-01-29 03:13:24.354 PulseAudio: Connection failure: Connection refused
W: [pulseaudio] main.c: Couldn't canonicalize binary path, cannot self execute.
^C

Seems like an incompatibility between Pulse in precise and Pulse in Yakkety, perhaps? Maybe the socket path changed, or it's dynamically looked up? I don't know...

Where I'd like to get to is to be able to have a Linux buildenv for Mumble and Murmur which we can generate AppImages from. That's my end goal.

I see, very reasonable. CentOS 6 might be good choices for doing this (haven't tried to compile AppImageKit on 5 yet).

As for the issue above, I wonder whether bundling libicui18n.so.48 would fix the PulseAudio: Connection failure: Connection refused...

Does the PPA recipe have anything akin to the excluded library list at https://github.com/probonopd/linuxdeployqt/blob/master/shared/shared.cpp#L244 ?

Perhaps it'd help to always use the distro's libpulse... It has kept the same soname, at least on Ubuntu, since very early on. (It's the same on Ubuntu 9.04...)

BTW, @probonopd, should we use Type 1 or Type 2 App Images? Is apprun for Type 2 stable/secure?

@mkrautz Type 2 are the newer ones, I do recommend them at this point.

@mkrautz I'd love to see this implemented until the end of the year. I'm willing to contribute. Please make a list of TODOs that we can work on.

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

Done in #3703.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

TalkLounge picture TalkLounge  路  4Comments

rkachach picture rkachach  路  3Comments

TerryGeng picture TerryGeng  路  3Comments

ghost picture ghost  路  4Comments

Elusivehawk picture Elusivehawk  路  5Comments