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.
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-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).
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
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
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 …).
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.
pantheon-files snapshot builds failed due to some remnants of
still being present, but that has obviously been fixed because the latest stable
builds compile just fine on fedora.
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.
switchboard settings application itself didn’t cause problems on fedora
(although it would be helpful if empty
system folders were created in
$LIBDIR/switchboard/ on install 2). I am
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
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).
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
appcenter drops support for
appstream-0.9 (and fedora 24)
appstream-0.10 now, which is only available on f25+ (but it works
fine now, even software categories).
The small apps
snap-photobooth didn’t cause any issues,
besides having some invalidly formatted translations in their
(just like any elementary package).
A note on standards compliance
For package quality reasons, the fedora packaging guidelines state that any
.appdata.xml that get installed by a package must pass
verification. While packaging all the elementary apps, I encountered many
.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
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
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.
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
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
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.
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
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.
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
The same can be said about the gtk theme. Also, the release tarballs
aren’t versioned and have the generally unhelpful name of
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
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
(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
libgsignon-glib exactly are needed for building
onlineaccounts plug, and
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
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.