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 elementary-stable COPR repository, more than half are already available in the official stable fedora repositories (25 and rawhide) right now, and some are still trickling down through f25-updates-testing.

elementary-stable

As my packages passed through the fedora infrastructure and into the official repositories, I started to remove the (now officially available) packages from the 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).

elementary-nightly

A recent change to the fedora build system (pkg-config -> pkgconf transition) resulted in most of my packages failing to build on rawhide.

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

elementary apps

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 /usr/share/icons/hicolor/. Some projects (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 rpmgrill fails to verify the affected packages due to the icon referenced by an included .desktop file 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.xml files 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 appstream standard as it is implemented right now).

As a side note, wingpanel‘s .desktop file references an icon named wingpanel, which I could find no trace of in either wingpanel or 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 appstream and appstream-glib (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 behavior.

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.

Upstream Issues

The CMake modules shared by some elementary software (cmake-elementary) are 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).

Additionally, some bugs were reported for projects not yet including a LICENSE or COPYING file (cerbere: LP:1658290, screenshot-tool: LP:1654258).

A previously unrecognized issue with pantheon-photos surfaced after submitting the package for f25-updates-testing - it installed its video thumbnailer binary to /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.

As 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 0.11.3.

One issue that is obvious to anyone testing the Pantheon session on fedora is that 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 (LP:1658305).

Window Manager Screen- erm … Snapshots

Some components of the Pantheon desktop session - namely gala and pantheon-session-settings - did not provide / don’t provide stable releases (yet).

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 target.

The upstream 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.

Elementary Artwork

The official elementary artwork also has some outstanding issues, some of which I had to work around for the time being.

As 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 4.0.2.

Wallpapers

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.

GTK Theme

An already existing package of the GTK theme (which was then called egtk) was 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 egtk 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 elementary-themes (née egtk).

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 tracked upstream and are being tackled.

CMake and autotools issues

Various possible build issues were uncovered for granite, gala and plank.

The 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 (LP:1653272).

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 (LP:1654405).

Additionally, the fedora package linters uncovered another possible issue with the gala and plank build scripts. Both packages include binaries that are built with PIE and 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 CFLAGS/LDFLAGS not getting passed to some compilation steps properly. I reported this issue both for gala (LP:1660751) and plank (LP:1660753).

Remaining Packages / Issues

Right now, the following elementary projects are still missing proper fedora packages.

  • capnet-assist
  • elementary-dpms-helper
  • gsignond and libgsignon-glib
  • pantheon-agent-polkit
  • pantheon-greeter
  • switchboard-plug-*

capnet-assist

Well, I just did not get around to packaging this yet.

elementary-dpms-helper

This DPMS helper script is still only available via an obscure bzr branch, though splitting it out into a proper project is finally being worked on - the issue is tracked at LP:1639935.

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: LP:1639890, “Security & Privacy” plug: LP:1639891).

gsignond and libgsignon-glib

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 still block switchboard-plug-onlineaccounts (and the dependent pantheon-mail) from being built at all on fedora. This issue is tracked at LP:1639938.

pantheon-agent-polkit

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 (LP:1660677).

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 (LP:1660681).

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).

pantheon-greeter

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 Raleway font is not yet packaged for fedora, so that is something that I have yet to do.

switchboard-plug-*

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/bin that 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.

TL;DR:

All elementary apps (except Pantheon Mail, it’s blocked by gsignond 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 updates-testing) and rawhide.

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.

Acknowledgements

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.