For some time now, I have been working to make the pantheon session and elementary apps available on fedora. At the moment the packages are available in two COPR repositories (elementary-stable and elementary-nightly), but a future inclusion into the offficial fedora package repository is on my todo-list.

However, I encountered some problems (some less serious, some real showstoppers, and some are only really really annoying) during this package effort.

Enter: kentauros

To lower the maintenance burden for packaging (stable and nightly snapshots!) of packages in general, I wrote a small tool that automates most of the process (you can find that on github, too: kentauros on github).

So far so good - as long as nothing breaks because of upstream changes, nightly builds require no manual actions from my side and are fully automated. For new builds of stable releases, all I have to do is to change 2 values in a configuration file (update version string and source URL) and run my tool.

Initial progress with apps

I started with packaging granite (the elementary widget additions to standard GTK+3), because it is required by almost all elementary apps and by some programs which are part of the shell. Building granite packages was simple enough (it’s also a fairly small package).

I continued with some of the simpler elementary apps, like pantheon-terminal and pantheon-calculator, which build just fine on a modern fedora system - with the minor hiccup that I had to manually add “-fPIC” to the compiler flags for pantheon-terminal (otherwise the binary didn’t link successfully on x86_64).

Building the scratch text editor was problematic at first (early snapshots of what would become the stable release for loki), but the latest stable releases build fine and without problems (not counting still using the security nightmarish webkitgtk3).

The audience video player was probably the least problematic piece of software to package (except maybe granite), everything just works as it should (using cmake and pkgconfig for dependency tracking makes packaging really fast).

Continuing with the noise music player, I ran into the first serious problems. Older snapshots of the code still depended on the outdated sqlheavy library for database functionality - which doesn’t even build on fedora 22+ or something (which is what I tested at the time). During the development for loki, the database backend switched to using libgda, which is readily available on modern distros, so my packaging effort could continue - only to discover that the last.fm integration needed pantheon-online-accounts integration (that horror story is expanded below, because it deserves its own chapter). In the end, I just didn’t build the last.fm plugin for noise.

Early source snapshots of the maya-calendar package didn’t compile correctly on fedora, but that error has been patched upstream long since and now stable releases build just fine (althouth the latest commits in bzr trunk break the build again …).

Packaging the contractor sharing service was quite simple, it’s just a shame not even all elementary apps make use of it. As a side note, it would be really nice if contractor created an empty /usr/share/contractor/ directory on install, where other packages can put their .contract files without having to own the directory themselves 1.

Early pantheon-files snapshot builds failed due to some remnants of marlin still being present, but that has obviously been fixed because the latest stable builds compile just fine on fedora.

The shotwell fork pantheon-photos proved a bit difficult at first, but as soon as the port to CMake and the “fork” was complete (and the two packages installable in parallel), the package built just fine.

The switchboard settings application itself didn’t cause problems on fedora (although it would be helpful if empty hardware, network, personal and system folders were created in $LIBDIR/switchboard/ on install 2). I am patching the about plug to display information for fedora and not for elementaryOS. Most other switchboard plugs compile and work fine as far as I can tell, but the locale plug seems to display wrong information and the mouse-touchpad plug needs a patch for recent GNOME versions (because it hardcodes old gsettings paths). Whether the parental-controls plug actually works, I have no idea - nobody has complained yet, though (also, it installs its .service files to the wrong location on non-ubuntu systems). The power plug requires a specific gsettings key to be present at runtime and crashes without it - just like the security-privacy plug: The missing key is org.pantheon.dpms, which is provided by an obscure bzr branch hidden somewhere on launchpad (see the obscure software section below).

Getting appcenter to configure and compile successfully proved a more difficult task … the first issue I encountered was that it was complaining about missing cmake modules (every other elementary package bundles those itself). Digging those up took some time (see remarks on discoverability of software below). After that finally worked, there was a curious bug where the software categories in the application itself were empty in fedora 24. With the latest release, appcenter drops support for appstream-0.9 (and fedora 24) and requires appstream-0.10 now, which is only available on f25+ (but it works fine now, even software categories).

The small apps screenshot-tool and snap-photobooth didn’t cause any issues, besides having some invalidly formatted translations in their .desktop files (just like any elementary package).

A note on standards compliance

For package quality reasons, the fedora packaging guidelines state that any .desktop and .appdata.xml that get installed by a package must pass verification. While packaging all the elementary apps, I encountered many invalid .desktop and appdata files - which I reported bugs for, and corrected invalid translations on launchpad manually.

Also, I reported bugs and / or contributed patches to the verification tools to correctly recognise Pantheon as a valid desktop environment. desktop-file-utils had a new stable release in the meantime, adding some new recognised desktop environments, but my bug reports (at freedesktop.org and with the fedora package) have been completely ignored so far 3.

As a result, I am just shipping a patched version of desktop-file-utils in the COPR repositories.

Compared to that, my report and pull request for libappstream-glib have been honored quite fast and the change was even incorporated in a new stable release only a few days later.

So, at the moment, all stable packages ship valid .desktop and appdata files (nightly snapshots sometimes have “pre-release” notes in appdata files and don’t validate correctly, so validation results are ignored for nightly builds).

Packaging session components

It took me quite some time to get a working Pantheon session up and running - having to overcome some hurdles along the way.

Packaging the latest plank dock wasn’t difficult, since the package had already been in the official fedora repositories previously. I only find it curious that it still installs *.la files in 2016.

The gala window manager (which uses libmutter) is only available via a bzr snapshot (no stable release has been made yet), and it is proving to be a temperamental piece of software. It only compiles correctly against mutter from the GNOME 3.20 series (which is available on fedora 24), but doesn’t work with the latest stable mutter from GNOME 3.22 (yet). As a result of this, the Pantheon desktop session does only work on fedora 24 right now.

The pantheon top panel, wingpanel, is split into a main package and some indicators, which are written from scratch (which fixes an issue I had with wingpanel in earlier versions, because it indirectly relied on an ubuntu-ified GTK+3 install on the host system). Aside from looking horrible (with any theme other than elementary on GTK+ == 3.18), it compiles and works fine. And since the slingshot launcher was converted to a wingpanel indicator for loki, it also works fine.

I almost overlooked packaging pantheon-agent-polkit (because it is, I think, the newest addition to the pantheon package family) - but it did not raise any issues and polkit works fine in a Pantheon session once installed.

The cerbere session watchdog didn’t cause any problems during packaging.

The configuration files for the actual Pantheon session were difficult to find (hidden somewhere on launchpad), and some did hardcode ubuntu- or debian-specific paths - instead of constantly patching the ubuntu-specific configuration files, I decided to fork the session settings and maintain them seperately for fedora (pantheon-session-settings on github). I also added a -overrides subpackage to the pantheon-session-settings package for users who want to override elementary’s (and GNOME’s) session settings with the elementary default settings.

The lightdm frontend pantheon-greeter doesn’t compile correctly on fedora - the error message looks like it might be a build system issue, but nobody could / would /wanted to help me with that, since it builds fine on elementaryOS / ubuntu.

Artwork packaging

I could only find the current official elementary wallpapers in a github repository, which I snapshot for package builds, since I couldn’t find recent release tarballs.

The icon theme is provided by a nice tarball, but no install script is provided - so files have to be copied explicitly in the .spec file.

The same can be said about the gtk theme. Also, the release tarballs aren’t versioned and have the generally unhelpful name of elementary.tar.xz.

Hide and Seek on launchpad

As mentioned above, I could only find some pieces of software needed for apps or the session after digging around in launchpad for a while.

The elementary CMake modules are hidden somewhere in an obscure bzr repository (honestly, it does have junk as part of its URL, I’m not kidding: cmake-modules at junk). These are needed for building appcenter (and will possibly be needed for other packages, too, when the bundled modules are removed in favor of the modules in this package).

The small elementary-dpms-helper (whatever that is) is also hidden in an obscure bzr branch, but is quietly required for two switchboard plugs at runtime (or they crash!). It can be found in another one of the junk repositories (elementary-dpms-helper at junk).

The configuration files for the pantheon session were also a bit hard to find - and I ended up forking those for fedora, anyway (pantheon-xsession-settings somewhere on launchpad became pantheon-session-settings on github for fedora).

The gsignond and libgsignon-glib Saga

For some reason I cannot think of myself, elementary decided to not use the upstream GLib bindings for signon, but the - somehow neglected-looking - GLib ports thereof for implementing their online accounts integration.

But, for me, the most confusing part was: which gsignond and libgsignon-glib exactly are needed for building pantheon-online-accounts, the switchboard onlineaccounts plug, and pantheon-mail?

I tried to build against the most recent upstream release (which didn’t work), against a git snapshot of the upstream repository (which didn’t work) and a snapshot of the bzr mirror on launchpad (which also didn’t work). After asking around on the elementary slack, I found out that there is a “fork” of gsignond somewhere on launchpad (…). After checking out the sources at the exact revision that is used for the elementary-daily PPA, I find that they don’t compile on fedora.

So, the current status is: it just doesn’t work right now. Which means that online accounts integration isn’t available in switchboard and pantheon in general (which means: no pantheon-mail, just use geary if you really want it that badly).

TL;DR: General Brokenness

Even if all of the above might sound a bit negative, most of the elementary apps and most parts of the pantheon session work fine on fedora - it’s just that some of the critical bits still cause big problems.

Those aside, I want to make some remarks about general portability and / or brokenness on non-ubuntu systems.

  • The elementary GTK theme is useless on any modern distribution (it just isn’t compatible with any GTK+ version > 3.18, even though 3.22 has been declared “stable” for the coming 3-5 years or something).
  • Some elementary apps require a very recent vala release to compile (vala-0.34), which has been released alongside the recent GNOME 3.22.
  • Gala doesn’t work with the latest stable release of GNOME (it just doesn’t), so the pantheon session is currently unavailable on fedora 25.

In my opinion, those issues arise (at least in part) from of the franken-GNOME that ubuntu ships (and elementary updating single libraries doesn’t help either) - building elementary apps against a coherent set of gnome libraries (that have been released and tested together) just isn’t possible:

The newest vala version is required (which was released with GNOME 3.22, but the GTK theme doesn’t even work with a GTK version as new as 3.20).

That is, in my opinion, the biggest problem when trying to provide a coherent elementary / Pantheon Desktop experience on a distribution that isn’t elementary / ubuntu - no linux distribution in its / their right mind would ship anything remotely resembling the package mess elementary has to / does rely on for their system.

  1. This “issue” has been fixed promptly and a fix is now in bzr trunk. ↩

  2. This “issue” has been fixed promptly and a fix is now in bzr trunk ↩

  3. “Pantheon” is now a recognised DE in git master Bug Report on freedesktop.org ↩