Bug 1624999

Summary:	mutter from 3.30 branch breaks gala, hence Pantheon session
Product:	[Fedora] Fedora	Reporter:	Fabio Valentini <decathorpe>
Component:	mutter	Assignee:	Florian Müllner <fmuellner>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	29	CC:	fmuellner, jadahl, otaylor, walters
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-09-10 21:55:35 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Fabio Valentini 2018-09-03 20:24:48 UTC

The update to mutter 3.29.4 introduced an API bump to the mutter library (libmutter-2 to libmutter-3) because of significant API changes (without announcement on devel@, by the way). The gala window manager has not yet been adapted to work with these newer versions of mutter, and so the package is not installable on fedora 29+ right now.

So, with the beta release of fedora 29 approaching fast, I fear that I won't be able to ship an installable (much less working) Pantheon desktop at all, because of unmet package dependencies (on libmutter-2 and friends).


I see three possible ways to deal with this:

1) Point programmers more talented in GObject / Vala than me at the gala issue and hope the compilation issues can be resolved soon upstream.

2) Introduce a mutter328 compat package that I can build gala against - until upstream developers had more time to adapt to the new API.

3) Have a broken package on fedora 29, no working Pantheon session, and have broken upgrade paths for existing users (the Pantheon session will be removed at upgrade right now, I think).


As you might guess, I would prefer if it wouldn't come to option 3 (broken packages).


I reported the mutter 3.30 compatibility issues (beginning with build system, didn't even mention API changes) for gala here:

https://github.com/elementary/gala/issues/303

and for greeter here (the pantheon-greeter package in fedora doesn't yet have a mutter dependency, but will have one with the next release):

https://github.com/elementary/greeter/issues/120

Comment 1 Jonas Ådahl 2018-09-03 21:27:39 UTC

(In reply to Fabio Valentini from comment #0)

...

> 
> I see three possible ways to deal with this:
> 
> 1) Point programmers more talented in GObject / Vala than me at the gala
> issue and hope the compilation issues can be resolved soon upstream.

FWIW, the changes are not much more complex than changing the namespace of some API calls, so it should be quite straight forward.

> 
> 2) Introduce a mutter328 compat package that I can build gala against -
> until upstream developers had more time to adapt to the new API.

This is why the apiversion was introduced. Can we still introduce new packages like this in F29 though?

Comment 2 Kalev Lember 2018-09-04 08:32:57 UTC

4) Temporarily bundle older libmutter in gala, installing it in a private directory so you can be sure it's only gala using it (%{_libdir}/gala/)

Comment 3 Jonas Ådahl 2018-09-04 08:39:29 UTC

Note that it'll still need to depend on mutter being installed, for the gsettings schemas etc. FWIW, for a parallel rpm install, we probably would have to split up mutter into mutter-data and libmutterN (and always require mutter-data to be the newest version (so we get all gsettings things)).

Comment 4 Fabio Valentini 2018-09-04 09:00:17 UTC

Won't bundling mutter cause the same issues as the compat package - namely requiring mutter's data and gsettings schemas etc. to be installed anyway, possibly causing conflicts?

Comment 5 Jonas Ådahl 2018-09-04 09:08:34 UTC

(In reply to Fabio Valentini from comment #4)
> Won't bundling mutter cause the same issues as the compat package - namely
> requiring mutter's data and gsettings schemas etc. to be installed anyway,
> possibly causing conflicts?

They will need to be installed, yes. An old mutter reading the gsettings of a newer schema should not cause any issues however. You'll just need to make sure the bundled mutter uses its own locale files, libfiles and introspection files etc.

Another thing that'll be installed is the keybindings XML files, but they are used directly by gnome-control-center. Not sure what'll happen there is a version mismatch there.

Comment 6 Fabio Valentini 2018-09-04 09:23:05 UTC

> They will need to be installed, yes. An old mutter reading the gsettings of a newer schema should not cause any issues however. You'll just need to make sure the bundled mutter uses its own locale files, libfiles and introspection files etc.

That sounds horrible.

I'll start learning me some vala and starting to port gala to the new mutter version. That seems to be the more productive route, for now.

Comment 7 Fabio Valentini 2018-09-04 10:55:01 UTC

I see that mutter generates .gir files for it's libraries during build, but not .vapi and .deps files. Would it be possible to do generate them too during package builds?
I can't seem to figure out how to regenerate them "downstream", looks like I'm too stupid to use vapigen correctly.

Comment 8 Fabio Valentini 2018-09-10 12:05:47 UTC

I've now gone ahead and worked on a mutter328 compat package, based on the mutter package from the f28 branch. After doing some light testing, it appears to work as expected (both as BuildRequires and as runtime dependency for gala).

https://bugzilla.redhat.com/show_bug.cgi?id=1627084

Comment 9 Fabio Valentini 2018-09-10 21:55:35 UTC

The compat package is now built and available on f29+. Hope everything works as intended, but initial testing looks good.

Comment 10 Jonas Ådahl 2018-09-11 09:05:27 UTC

Great to here! Feel free to CC me on any bugs that might be related to parallel installation.

Comment 11 Fabio Valentini 2018-09-11 12:13:22 UTC

I'll do that. Thank you!