Mumble snapshot Linux packaging

[mkrautz]

We'd like to provide snapshot packages for Linux.

Ideally, we'd provide repos -- or if the distro provides a repo hosting service, we would potentially use that.

Ideally, the packaging would be as close as possible to downstream. It would be great if we could work with existing maintainers. Perhaps we would create repos in the mumble-voip organization here on GitHub, and collaborate with the maintainers on the packaging.

If not, we might be required to fork the current maintainers's packaging and maintain them ourselves.

Another possibility is for us to do binary packages for a single distro, i.e. Ubuntu LTS or Debian Stable -- and ensure those binary packages run on modern Debian/Ubuntu/Fedora/RHEL/CentOS. That would require us to be careful to link against libraries where the sonames match, and dlopen() the rest in a way that work across distros.

[mkrautz]

/cc @crknadle @fedpop

[hacst]

I'm not to fond of us having to maintain tons of distro packages ourselves. Given our experiences in the past I'm also not a fan of normal packaging for the client either. It is very possible we won't get around that though in which case we might want to look into something like openSUSE's open build service next to the Ubuntu PPAs we are feeding. If we can cooperate with the distro packagers so they can maintain the configurations for that inside our project everyone wins.

Ideally I would like to be able to use the same distribution model we use for Windows and OSX on Linux too. Meaning we control our toolchain and (the most important) dependencies. Not having control over the compiler, Qt and OpenSSL has been and is pretty painful. Imho this approach would also provide the best user experience if we can make it work. It's definitely worth figuring out what is already in that space (e.g. Linus Thorvald linked https://github.com/probonopd/appimagekit a while ago which they are using for subsurface now) and if it can be turned into a maintainable and usable solution.

[mkrautz]

Did you see our chat on IRC?

Distro maintainers seemed optimistic

Though I agree, there are benefits to doing it ourselves.

[hacst]

Saw it in the backlog. Finding a way to not duplicate work and improve accessibility of up-to-date binaries for all platforms is definitely in our interest. Doing so by closer cooperation with downstream maintainers on packaging would be a big step up from how it worked in the past.

Unfortunately the packaging models pretty much all Linux distributions adhere to comes with some serious drawbacks for applications like ours :( No matter how well we can cooperate on packaging it still means we'll have to support the oldest compiler and dependencies on anything we target. Past experience shows this means #ifdef, barely tested code-paths, held back features, bugs and user confusion. And in the end there will always be another distribution/version we don't support (yet). It's just a very unfortunate state of affairs.

[fedpop]

I think maintainers will need to do most of the work if they want to provide the snapshots in their ecosystem. I know I would use Fedora copr and there are ways to integrate that into CI and stuff.

I think the way chrome/jetbrains/etc provides binary dumps for /opt with all the libraries bundled into the same directory would probably be the most universal way for mumble itself to provides snapshots. Just provide a tarball, rpm and deb that basically all do the same thing: dump the binaries and libs into a directory.

[crknadle]

First, the idea of using one of Debian's package repos for snapshots probably won't work. Debian for a few years was working towards making PPAs similar to Ubuntu, however the PPA idea has been re-purposed into "bikesheds" instead -- which would be a place that only DDs or DMs could upload to. The idea of these "bikesheds" would be to allow large transitions, such as say a KDE4 -> KDE5 transition that would normally have a lot of packages that wouldn't migrate all at once, causing dependency issues. The main issue concerning DDs is the lack of package quality in many PPAs, thus requiring ftp-master checking and package signing using Debian's normal repository keys, thus only DDs and DMs can upload anything.

In terms of Debian's code / VCS repositories, that's currently in flux because there's a migration away from Alioth going on, and getting commit access normally requires a DD sponsor to send a GPG-signed message making the permission request.

When it comes to Debian, the issue of which libraries/compilers/etc to use is handled by using an build environment for each of the distributions (Unstable, Testing, Stable, Oldstable) which can be created on-the-fly. This is how I release mumble and other software in my own repository, for instance. I mostly do this with cowbuilder, which uses pbuilder. I also sometimes use sbuild which seems to be the current favorite among DDs I discussed build issues with at DebConf15. Automated buildds could be set up but that isn't a requirement. Packages for i386 can be built natively on amd64. Other architectures can be built on non-native hardware but would be slower to do as it is done with qemu.

The only compiler difference from normal is that Wheezy requires using g++-4.6 due to issues with zeroc-ice, otherwise the build will fail. This ends up being a small difference that needs to be carried in the debian/rules file. Wheezy will be supported via a separate LTS team until May 2018.

I think it would help if we discuss the intended /workflow/ of the Snapshots, preferably with some kind of graphical diagram... because with words alone I think there's some confusion here that a diagram might help with.

[crknadle]

I spent some time in the last couple of days doing the Debian packaging for snapshot 1.3.0~938 so I have some initial comments. 1.3.0 snapshots right now look like they contain documentation for Speex, Celt, and Opus and at least some of this appears to be non-redistributable as some of the files are "all rights reserved". The Lintian package checker throws the following errors:

E: mumble source: license-problem-non-free-RFC speex/doc/draft-herlein-avt-rtp-speex-00.txt
E: mumble source: license-problem-non-free-RFC-BCP78 speex/doc/draft-herlein-speex-rtp-profile$
E: mumble source: license-problem-non-free-RFC-BCP78 speex/doc/draft-herlein-speex-rtp-profile$
E: mumble source: license-problem-non-free-RFC-BCP78 speex/doc/draft-ietf-avt-rtp-speex-00.txt
E: mumble source: license-problem-non-free-RFC-BCP78 speex/doc/draft-ietf-avt-rtp-speex-01-tmp$
E: mumble source: license-problem-non-free-RFC-BCP78 speex/doc/draft-ietf-avt-rtp-speex-05-tmp$
P: mumble source: license-problem-gfdl-non-official-text speex/doc/manual.lyx invariant part i$
P: mumble source: license-problem-gfdl-non-official-text 3rdparty/speexdsp-src/doc/manual.lyx $
E: mumble source: license-problem-non-free-RFC-BCP78 celt-0.11.0-src/doc/ietf/draft-valin-celt$
E: mumble source: license-problem-non-free-RFC-BCP78 celt-0.7.0-src/doc/ietf/draft-valin-celt-$

It's probably best if these documentation files are removed by the Mumble project (for comparison the mumble 1.2 tarballs do not contain these), otherwise downstream Linux distributions will typically need to repack a modified tarball to remove these files. (At minimum such a tarball would not be releasable to Debian. If you've seen Debian packages with a "-dfsg" in the version number, that denotes having to repack the tarball to remove files to fit the Debian Free Software Guidelines.)

I've had a look at the Ubuntu-PPA package for guidance on dependencies for building the 1.3 snapshot Debian package. Lintian also throws an error for a dependency on qt5-default:

E: mumble source: build-depends-on-metapackage build-depends: qt5-default
N: 
N:    Packages must not build-depend on metapackages.
N:    
N:    Metapackages such as xorg, xorg-dev, x-window-system,
N:    x-window-system-dev and x-window-system-core exist only for the benefit
N:    of users and should not be used in package build dependencies.
N:    
N:    Refer to https://wiki.debian.org/Lintian/Tags/depends-on-metapackage for
N:    details.
N:    
N:    Severity: important, Certainty: certain
N:    
N:    Check: fields, Type: binary, udeb, source

Without a dependency on qt5-default the build fails due to the build defaulting to qmake v4 which doesn't get installed into the build chroot. I'm assuming I'll be able to find a solution for this, so I'm not too worried about it at the moment.

The current package in Debian has some files in debian/ updated compared to the Ubuntu-PPA; the 'rules' have been switched to using the more automatic 'dh' build helper, the 'copyright' has been converted to a machine-readable copyright-1.0 format (which now looks like it'll need updates for the 1.3 snapshots), and the 'compat' and 'control' uses debhelper 9.

I'm told that -dbg packages are now build automatically by debhelper 9, and if that's so then I should be able to remove the call to dh_strip as well as the entire 'mumble-dbg' package definition in the debian/control file -- that seems to be the direction this is going in other Debian packages. (I just found out about this, but there had been talk in Debian about doing it for a while.)

[crknadle]

Found a solution for depending on qt5-default: instead depend on qtbase5-dev, and add this to debian/rules:

# qtchooser will try to use qmake from qt4 even if it's not installed
export QT_SELECT=qt5

[crknadle]

Something else to consider: systemd. (And OpenRC. upstart is on its way out.)

Most (but not all) of the Linux distributions are switching to systemd. it's still important to have init scripts as well for non-Linux systems like FreeBSD (including Debian kFreeBSD), and this is where there's a bit of a clash. systemd doesn't have a native facility to disable a service based on the contents of a shell variable, so disabling murmur/mumble-server in /etc/default/mumble-server is a bit of an issue:

https://wiki.ubuntu.com/SystemdForUpstartUsers#A.2BAC8-etc.2BAC8-default_files_which_enable.2BAC8-disable_jobs

What's confusing for murmur admins is that if a systemd service file is shipped it would need to exist side-by-side with the init script, and the service file would take precedence if-and-only-if systemd is the local init system. It means that what's necessary to do to enable/disable murmur differs depending upon whether systemd was in use. :-( For the time being I've avoided this by not shipping a service file, but this isn't really the right answer.

For reference, I believe this is the service file I was last testing:

[Unit]
Description=Mumble VoIP server
ConditionPathExists=/etc/mumble-server.ini
Documentation=man:murmurd(1) file:///usr/share/doc/mumble-server/README
Documentation=http://wiki.mumble.info/wiki/Running_Murmur
Wants=network-online.target
After=network-online.target local-fs.target remote-fs.target

[Service]
Type=forking
PIDFile=/var/run/mumble-server/mumble-server.pid
ExecStart=/usr/sbin/murmurd -ini /etc/mumble-server.ini
ExecStartPre=/usr/bin/install -o mumble-server -g adm -d /var/run/mumble-server
Restart=on-abnormal

[Install]
WantedBy=multi-user.target

Furthermore there's a bug with murmur when starting it with systemd or upstart where murmur gets started but doesn't listen on any ports unless a manual setting of "host=::" or "host=0.0.0.0" is used in the .ini file. See #1629 and #1904.

[crknadle]

Also Linux related: the SSL initialization issue #1876

[probonopd]

Please see https://bintray.com/probono/AppImages/Mumble/_latestVersion#files for an experimental AppImage. Just download, make it executable, and run. No installation, no root, no system libs touched.

Should run on 2014ish and later distributions, but some fine-tuning might be needed. https://github.com/probonopd/AppImages/blob/master/recipes/meta/Mumble.yml

Let me know how it goes.

[mkrautz]

Very impressed by the brevity of the Mumble recipe. And very nice that you can source an AppImage from a PPA.

We'd probably want to build it on our own infrastructure and not rely on the PPA builds from Launchpad... Very eager to look into creating a Mumble AppImage that can be downloaded from https://www.mumble.info.

[probonopd]

Yes, that's absolutely doable. I used #1 from below but there are the other options as well:

1. Convert existing binary packages. This option might be the easiest if you already have up-to-date packages in place, ideally a ppa for trusty or earlier or a debian repository for oldstable. In this case, you can write a small .yml file and in many cases are done with the package to AppImage conversion. See examples OR
2. Bundle your Travis CI builds as AppImages. This option might be the easiest if you already have continuous builds on Travis CI in place. In this case, you can write a small scriptfile and in many cases are done with the AppImage generation. See examples OR
3. Run linuxdeployqt on your Qt application. This option might be the easiest if you have a Qt-based application. In this case, you are probably already using windeployqt and macdeployqt and now can use linuxdeployqt in the same fashion with the -appimage argument and in many cases are done with the AppImage generation See example OR
4. Manually create an AppDir and turn it into an AppImage. Start out withthe example below, then check the examples on bundling certain applications or type of applications as AppImages from thttps://github.com/probonopd/AppImageKit/wiki/

You will find more information at https://github.com/probonopd/AppImageKit/wiki, but the examples linked above should get you started. Let me know if you need further help.

[probonopd]

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

[crknadle]

I've uploaded mumble 1.3.0~2868~g44b9004+dfsg-1 to Debian experimental. The tarball needed repacking to remove draft IETF documents from the Git submodules for CELT, Opus, Speex that have a restrictive license ... thankfully there's an automated way to do that.

[Krzmbrzl]

We are now using AppImages for snapshots on Linux available at dl.mumble.info