I have been kind of busy the last few weeks - which includes having been busy getting the Pantheon DE and elementary apps running and working great on fedora!
State of my COPR repositories
Out of all the packages originally distributed via my
COPR repository, more than half are already available in the official stable
fedora repositories (25 and rawhide) right now, and some are still trickling
As my packages passed through the fedora infrastructure and into the official
repositories, I started to remove the (now officially available) packages from
elementary-stable COPR repository. This means that mostly only the
packages with outstanding (packaging) issues are left.
I updated the description text of the repository to better represent the “changed” status (well, on average) of the contained packages and to briefly describe the issues which prevent them from becoming official fedora packages (yet).
A recent change to the fedora build system (
pkg-config -> pkgconf transition)
resulted in most of my packages failing to build on
This has prompted me to start working on something which I wanted to do for some time now anyway … I have started to synchronize the packaging between the “official” fedora packages and the “nightly” builds.
This should decrease the chance for incompatibilities between the official packages and nightly builds, and should raise the quality of the nightly builds for fedora overall.
State of the fedora packages
Getting the packaging of the core elementary apps into good shape proved to be more work than I anticipated. Additionally, being kind of a perfectionist about it didn’t help.
Problems with Icons
Most elementary apps don’t ship application icons, but rely on generic icons instead (to de-duplicate icons and maintenance effort). Those should be present in every icon theme following the XDG Icon Naming Specification. In theory, this should work great.
In practice, this approach is not followed by, for example, GNOME’s apps - most
of those ship their own (“branded”) icons to
appstream implementations, fedora package linters and GNOME
Software, etc.) seem to rely on GNOME’s behavior.
This leads to some issues with packaging elementary apps for fedora:
The first issue with this approach is that fedora’s package linter
rpmgrillfails to verify the affected packages due to the icon referenced by an included
.desktopfile not existing.
The second issue stems from some icon names that are “pseudo-generic” in that they adhere to the pattern outlined in the XDG Specification, but are not mentioned in it - so they should be broken on all distros.
The third issue is that (some) packages with no associated icons don’t show up in GNOME Software, despite their
.appdata.xmlfiles being valid, as required by the fedora Packaging Guidelines.
The fourth issue is that, even if the concept of generic icons would work in fedora / GNOME Software, an inconsistent set of some generic icons and some branded icons would be shown (no consistency, as is the case in AppCenter right now - but this is an issue with the
appstreamstandard as it is implemented right now).
As a side note,
.desktop file references an icon named
wingpanel, which I could find no trace of in either
elementary’s icon theme. Since
wingpanel is not actually a user-facing
program, I don’t particularly care about this issue, but it’s worth mentioning.
I reported the apparent “missing icons” oversight upstream
on launchpad for all
affected packages. A possible solution has been discussed with the upstream
developers and between the developers of
(here), but the issue
has not been resolved yet.
I think the whole “icon handling issue” will have to be clarified in the
appstream specification itself, so all implementations can provide consistent
In the meantime, to work around the issue at hand (missing icons breaking
things) and limitations and quirks of the used
appstream implementations (on
fedora: appstream-glib, on
ubuntu: appstream), I decided to bundle
icons with most elementary apps. As this could possibly lead to file conflicts
(generic file names in generic locations provided by applications sounds like a
great idea!), I patched the apps’
.desktop files and renamed the icons to
match the respective
.desktop file names for consistency.
So, for example, the
org.pantheon.calculator.desktop file now references the
org.pantheon.calculator icon instead of
accessories-calculator. I bundled
icons for every elementary app missing one so the appearance and behaviour
is consistent between all elementary packages.
As a side effect, third-party icon themes might no longer provide “properly” named icons for elementary apps - but I can’t fix this problem for everybody.
The CMake modules shared by some elementary software (
not yet available as a stable release (requested upstream at LP:1639931), so I had to package a
bzr snapshot of those to finish the
appcenter packaging (
pantheon-greeter also needs them, but more on that package later).
A licensing issue with the upstream source code was discovered during the final package cleanups - most elementary software shipped source code with mismatched or outdated license information (reported upstream at LP:1653413, etc.), which in some cases blocked packages from entering fedora.
The legal issue blocking
pantheon-photos was resolved with a (very quick)
bugfix release (thank you!), and the package review could continue (it’s
available in f25 and rawhide now).
A previously unrecognized issue with
pantheon-photos surfaced after submitting
the package for
f25-updates-testing - it installed its video thumbnailer
/usr/share/ - which was a BIG issue, I had to pull the package
from fedora 25. After reporting this upstream
(LP:1659549), it was
fixed quickly (thank you!). I also applied the upstream patch to my package and
pushed a fixed package update.
Pantheon Session / Desktop Environment
Once all packages of apps (which were not blocked at that time) were done, I turned to finishing packaging the components of a Pantheon session.
plank was already packaged for fedora, I applied to become (and became) a
co-maintainer of the existing package. Following that I created and pushed out
the pending update to
One issue that is obvious to anyone testing the Pantheon session on fedora is
wingpanel looks broken (wrong colors of text, background and icons) with
any GTK theme other than “elementary” (which is, sadly, completely broken on
every supported fedora release).
wingpanel depends on some custom GTK
css magic (which is beyond me) that is only available in the “elementary” GTK
theme right now. I reported this issue upstream
Window Manager Screen- erm … Snapshots
Some components of the Pantheon desktop session - namely
pantheon-session-settings - did not provide / don’t provide stable releases
In the latter case I was solely responsible for that, so I cleaned up the code a
bit, added a missing
COPYING file (matching the license of the upstream code),
fixed some forgotten issues, and tagged a release that my fedora package could
gala developers could (or would) not provide a stable release for
me - either at that time or in the foreseeable future - so I had to create a
snapshot build of
gala, too. At least the
gala build tools automate the
process of generating a snapshot nicely.
The official elementary artwork also has some outstanding issues, some of which I had to work around for the time being.
elementary-icon-theme was already packaged for fedora, I applied to become
(and became) a co-maintainer of the existing package. After that, I pushed out
the update to
The official elementary wallpapers still don’t provide a stable release tarball (upstream issue LP:1639922).
Additionally, the wallpapers git repository includes artwork which is distributed under a license that is incompatible with fedora’s requirements (and elementaryOS’ too, for that matter, since they became a for-profit company). I ended up creating a “downstream” fork of the elementary wallpapers git repository, now containing only acceptably licensed wallpapers (exclusively Public Domain right now), and tagged a release which my package could target.
An already existing package of the GTK theme (which was then called
orphaned in fedora, and I took it up (only to retire the package in rawhide
(f26+) and let it die in f24 and f25). The new
elementary-theme package (which
succeeds the old one in a way) is installable in parallel with the old
package, so nothing should get broken for users of the old theme.
The upstream elementary GTK theme project provided only unversioned tarballs of
their releases (up to version
< 5.0.3), which made targeting them for
packaging hard. I reported this
issue upstream, and it has
been resolved with the
5.0.3 release of
The latest release of the elementary GTK theme (
5.0.3 at the time of writing)
still does not support GTK versions
> 3.18, but compatibility issues with
recent GTK are now
and are being tackled.
CMake and autotools issues
Various possible build issues were uncovered for
granite build scripts (CMake) seem to produce a
libgranite library which
is linked directly against some libraries that are not used directly. I reported
this possible issue upstream
The same happens for the
gala autotools build (only worse). The resulting
libgala is linked directly against more than 25 unneeded dependencies. I
reported this upstream
Additionally, the fedora package linters uncovered another possible issue with
plank build scripts. Both packages include binaries that are
RELRO support (as per the default compilation flags on
fedora), but the resulting binaries are only partially
RELRO. I suspect this
is an issue with
LDFLAGS not getting passed to some compilation steps
properly. I reported this issue both for
Remaining Packages / Issues
Right now, the following elementary projects are still missing proper fedora packages.
Well, I just did not get around to packaging this yet.
This also blocks the “Power” and “Security & Privacy”
switchboard plugs from
being submitted for inclusion in fedora, since they require this helper binary
to exist on the system. That this runtime dependency is completely undocumented
in both cases is also reported as an issue (“Power” plug:
“Security & Privacy” plug:
Last time I checked, those projects did not compile successfully on fedora. I
think upstream is working on resolving this, but right now, these build failures
switchboard-plug-onlineaccounts (and the dependent
pantheon-mail) from being built at all on fedora. This issue is tracked at
The Pantheon PolKit agent has (at least) two issues which prevent it from being submitted for review for fedora:
The autostart entry
.desktop file (which is needed to make it run in a
Pantheon session - which is kind of the whole point of this program) is not
part of the release tarball, but of the debian packaging files instead. I
reported this issue upstream
Additionally, the build scripts hard-code a directory in
/usr/lib/* as the
location of the binary, which should be installed to somewhere in
/usr/libexec/*. I also reported this issue upstream
Until those issues are resolved and the package can be submitted to fedora, authorizing with PolKit won’t work in the Pantheon session (unless you are “crazy” and use the packages from the elementary-stable COPR).
The Pantheon LightDM greeter seems to have some bugs concerning login delays (on elementaryOS and on fedora), I would like to get this problem resolved before submitting my package for review.
Another issue seems to be that locking the screen doesn’t work when using this LightDM greeter (whereas it works when using the GTK Greeter). This issue was reported on GitHub (elementary-stable-rpms Issue #9).
Additionally, some visual elements of the greeter depend on application-specific
themeing (that is only present in the elementary GTK theme right now) or assume
a particular font is installed on the system (
Raleway) - if it is not
available, some interface elements are quietly not drawn at all. The
font is not yet packaged for fedora, so that is something that I have yet to do.
The issues blocking the “Power”, “Security & Privacy” and “Online Accounts” were already mentioned above.
Some of the other plugs have blocking issues, too:
- The “About” plug needs a (rebased) patch to display correct information about the system on fedora (elementary-nightly-rpms Issue #35, but this problem also applies to the latest stable release).
- The “Date & Time” plug needs someone to test whether it works correctly on fedora.
- The “Locale” plug seems broken - I suspect the configuration of the System Language and the Keyboard Layout differ between fedora and ubuntu-based distros.
- The “Pantheon Shell / Desktop” plug has a blocking issue (it installs a binary to
/usr/binthat clearly belongs in
/usr/libexec/) - I reported this issue upstream at LP:1660688.
- The “Parental Controls” plug should confirmably work on fedora before I am comfortable with submitting it for review (for obvious reasons).
- The “Security & Privacy” plug needs someone to test whether the security-related settings really work at all on fedora before I am comfortable submitting this package as well.
- The “Sharing” plug crashes in conjunction with recent versions of GNOME, because a GSettings key that is relied upon no longer exists.
- The “User Accounts” plug needs some thorough testing (preferably in a VM), because users could lock themselves out of their own system if this plug contains errors.
All elementary apps (except Pantheon Mail, it’s blocked by
not building on fedora) are available as official packages on fedora 25 (already
stable or still in
updates-testing) and rawhide.
All components necessary for a Pantheon session (except the
PolKit Agent, which has yet unresolved issues, and the
Captive Portal Assistant, which is just not packaged yet) are available as
official packages on fedora 25 (already stable or still in
All parts of the elementary artwork (including the GTK theme, the
icon theme and official wallpapers) are now available on fedora 25
(already stable or still in
updates-testing) and rawhide. The elementary GTK
theme is still incompatible with all currently supported versions of fedora (24,
25, rawhide), but support for GTK
> 3.18 is now actively being worked on.
At the time of writing, the Pantheon LightDM greeter and some of the
switchboard plugs still have unresolved issues, though I should be able to
submit most of those without issues to fedora in the near future.
I would like to thank Neal (@Det_Conan_Kudo; my fedora packaging sensei, sponsor and reviewer of all (?) of my fedora packages so far) for the time he puts into making my packages better and available on fedora faster.
I would also like to thank the guys at @elementary for helping me resolve most issues I come across. Even tough some (but not all of them) are fedora-specific, they still provide feedback and fixes for most issues - but especially speedy fixes for critical issues! Dan (@DanielFore), Cody (~codygarver), Corentin (@tintou_noel) and Rico (~ricotz) clearly deserve to be mentioned by name. Thank you.