Providing snapshots in AppImage format would have, among others, these advantages:
appimagedHere 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.
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?
This issue would fix this: https://github.com/mumble-voip/mumble/issues/2865
Done in #3703.
Most helpful comment
This issue would fix this: https://github.com/mumble-voip/mumble/issues/2865