Update: I’ve now built a mutter328 compat package for fedora 29 and rawhide, and – pending some testing – it will be a good short- to mid-term solution for the mutter 3.30 compatibility issue.

However, this will not be a long-term solution. So, upstream developers are probably still happy about contributions to help make gala compatible with the latest versions of mutter (since that will benefit future versions of elementaryOS too). Development has been started in this git branch.

The beta release of fedora 29 is approaching fast (September 18, according to the Schedule), but right now, it’s impossible to install and run a Pantheon session on fedora 29 and rawhide - due to incompatibilities with the new version of mutter, which will be released tomorrow as part of the GNOME 3.30 stable release.

The problem

During the development of mutter 3.30, substantial changes were made to internal code (to allow for performance improvements, and to work on dropping X server requirements). These and other changes resulted in changed library APIs, and resulted in bumping the library version from libmutter-2 to libmutter-3.

This initially resulted in broken builds of gala in fedora CI and broken elementary-nightly builds of gala git master and greeter git master - which I reported at the time with an issue for gala and for greeter.

When an API version bumps like these happened in the past, they did not require too much work to adapt gala to newer versions of libmutter. However, according to upstream developers, “countless changes are required to catch up with the API changes” in mutter 3.30. So, it will take time to adapt gala (and by extension, greeter, which borrows some of the window manager code from gala) to the new library versions.

So, if nothing changes, gala, and by extension, elementary’s Pantheon session, won’t be available on fedora 29 at all.

Possible solutions

I recently opened a bug report about the mutter compatibility issue on RedHat Bugzilla, seeing two ways to resolve the issue - either to help port gala to the new mutter API, or to create a compatibility package of mutter 3.28 for gala to be built and linked against, until it is adapted to the new version. The mutter maintainers pointed out a third option - to bundle an older, compatible version of mutter in the gala package for now.

1. Porting gala to mutter 3.30 / libmutter-3

Adapting gala to support the new version of mutter is obviously the best way forward, since the most people can benefit from it. However, as mentioned above, this will take some time and possibly won’t happen in time for the release of fedora 29.

Also, I am not familiar enough with the Vala language, the gala code-base, and the GObject system in general to do the heavy lifting myself, and upstream developers are (rightly) focused on stability improvements for the upcoming release of elementaryOS 5.0 “Juno”.

If somebody versed in Vala wants to step up and help with porting gala to libmutter-3, upstream developers have started working on it in this git branch.

2. Introducing a mutter328 compatibility package in fedora

A short-term solution for fixing gala would be to package the last stable version of mutter from the gnome-3-28 branch separately from the latest version, providing compatibility with dependencies that didn’t already have time to adapt to the changed APIs.

This solution would come with the additional cost of maintaining another - quite complicated - package (mutter328). Additionally, the mutter package in fedora would have to be adjusted to split off data files into a version-independent sub-package.

3. Bundling mutter 3.28 in the gala package

Another possibility would be to bundle a stable version of mutter from the gnome-3-28 branch in gala itself, making a compat package obsolete. For all intents and purposes, the result is roughly equivalent, since no other packages in fedora seem to link against mutter itself.

However, both creating a compatibility package and bundling an older release would require patching the mutter sources and build system to use differently named libraries, locale files, settings files, and data files, and I don’t think I’m up for this task (at least not alone). Also, this would be easier if mutter had already been ported to use meson, but the build system is still autotools-based.

How to help

Basically, I’m stuck. I can’t port gala to the new mutter APIs myself, and I don’t know how to patch the mutter build system to the extent that would be required for either creating a compat package or bundling the libraries within the gala package. So, any help is appreciated - and I think gala upstream would also greatly appreciate any help with porting gala to the latest version of mutter.

Upstream work

The gala upstream developers have started working on the basics of mutter 3.30 support in a git branch. However, only build system adjustments have been done - and no API adaptations yet. There also seem to be some build errors unrelated to the mutter changes, which might be caused by faulty GObject bindings for Gio and Json on fedora 29 and later.

Downstream (fedora) work

The package repository for gala on fedora is probably the best starting point for any necessary downstream work (be it preparation for using a mutter328 compat package or bundling an older version of mutter in gala itself). Since a fedora account is necessary to send me pull requests, I’m also happy about plain patches.

The fedora packaging of mutter could be used as a starting point for the compat package (or as a guide for building a bundled version).