Mir running on Fedora

[alan_g]

Last week we released Mir 0.28 and this week we settled down to tidy up a few bugs fixes and feature requests that didn’t make the release. I’ve started collecting these for a Mir 0.28.1 release to come in the next few weeks.

The most interesting of these comes from conversations at the Ubuntu Rally: there were several requests from community members around getting Mir working (or even building!) on other distributions.

As a result we’ve spent a some time building Mir on Fedora (we had to start somewhere and this was convenient). There are some rough edges to smooth out, but I’m confident that we can incorporate these updates into 0.28.1.

[tsimonq2]

Out of curiosity, would that happen to be the LXQt desktop?

[alan_g]

Yes, that was the default on the cover CD I used to install.

[alan_g]

With the latest release of Mir it is possible to checkout and build and run Mir on Fedora. You’ll first need some development tools and packages installed:

$ sudo dnf install bzr cmake gcc-c++ boost-devel mesa-libEGL-devel \
mesa-libGLES-devel glm-devel protobuf-lite-devel protobuf-compiler \
capnproto-devel capnproto glog-devel gflags-devel systemd-devel \
glib2-devel wayland-devel mesa-libgbm-devel libepoxy-devel nettle-devel \
libinput-devel libxml++-devel libuuid-devel libxkbcommon-devel \
freetype-devel lttng-ust-devel libatomic qterminal qt5-qtwayland \
python3-pillow libevdev-devel umockdev-devel gtest-devel gmock-devel

With these installed you can checkout Mir:

$ bzr branch lp:mir/0.28

And then build it:

$ mkdir mir/build
$ cd  mir/build
$ cmake ..
$ make -j4

You can then start it on your desktop (as shown in the initial post):

$ bin/miral-app

[lkundrak]

Hello Alan.

in case you’d be willing to maintain this as a proper part of Fedora package collection and need help packaging it and getting in it, then drop me a line – I’m willing to help.

Lubo

[alan_g]

Hi Lubo,

I (and the rest of the Mir team) would be delighted to have Mir packaged for Fedora and we’re willing to do some work towards that end. However, my knowledge of the Fedora packaging tools and processes is non-existent. That doesn’t make me the ideal person to maintain the packaging.

What would be involved? Is it a matter of carrying some configuration files in tree (as we already do for Debian)? Clearly we’d also need to set up some CI to detect problems.

Thanks,
Alan

[lkundrak]

Well the process is somewhat different from Debian (I’d tend to say, simpler). In general:

• You write the package SPEC file (of course)
• You need a Fedora account. When you become a packager you’ll also need to set a SSH key for it and set up Kerberos to do the builds
• You submit the SPEC file for review in Bugzilla (indicating that it’s your first package and you can’t import it yet)
• Someone picks it up for review
• You need to find a sponsor. That is a person who can allow you to import and build the package after you convince him you’re familiar with package maintenance. Sponsor will also likely watch your actions for a while and will be happy to help you if you need anything
• When you have a sponsor and the reviewer is happy enough with the package, you import it
• The rest is pretty much self-service – you import the package to Git, trigger a build in the build system and perhaps submit it as an update for a released Fedora release

The details are rather extensively documented here: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers

I’d be glad to assist you with any of the above.

An alternative is to set up a COPR. For that a source package and an unsponsored Fedora account is sufficient. A COPR was basically modelled after Ubuntu’s PPA. It’s completely self-service and good for packages of more experimental nature than in the distribution. A good way to get started.

COPR’s hosted here: https://copr.fedorainfracloud.org/

[lkundrak]

Here’s what a rather typical review ticket looks like: https://bugzilla.redhat.com/show_bug.cgi?id=1505237
(The forum doesn’t let me include three links in a single posting)

[greyback]

There’s a bunch of Mir specific distro patches in Ubuntu’s Mesa. Do we need to try getting those patches into Fedora too, or will Mir function without?
-G

[alan_g]

There’s a bunch of Mir specific distro patches in Ubuntu’s Mesa. Do we need to try getting those patches into Fedora too, or will Mir function without?
-G

There are three ways a Mir client can render:

• Using Wayland - this works (within the limits of Mir’s Wayland support)
• S/W rendering using libmirclient - this works
• EGL rendering using libmirclient - this doesn’t work without the mesa patches

The example shown above is running on unpatched Fedora 26 and uses Qt’s Wayland backend to render qterminal on Mir.

One of the changes in Mir 0.28.1 was to make building the “Mir EGL” examples optional (and default it to “off” unless the mesa patches are detected).

[alan_g]

An alternative is to set up a COPR. For that a source package and an unsponsored Fedora account is sufficient. A COPR was basically modelled after Ubuntu’s PPA. It’s completely self-service and good for packages of more experimental nature than in the distribution. A good way to get started.

COPR’s hosted here: https://copr.fedorainfracloud.org/

A Fedora COPR sounds like a good starting point. I’ll look into it further tomorrow.

BTW I see some prior art: https://copr.fedorainfracloud.org/coprs/ngompa/Mir/

[raof]

I’m not sure that either we, or Fedora, want us to carry the .spec files in the Mir source tree - the Debian packaging is somewhat special, due to our (ambitions of) continuous-release-into-Ubuntu workflow.

We should definitely test that Mir can build on Fedora, but I think that would be adequately solved by adding a Fedora target to Travis and running the commands you’ve listed here.

We’d only want to carry the .spec file in source control if we were planning to have a autobuilt mir-devel COPR, like our devel PPA. Which could be useful, but might be a stretch goal?

I don’t think we want to maintain packaging for all the various distros people might want to use Mir on, and I don’t think the various distros would want us to maintain packaging for it, either.

[Conan_Kudo]

I’m not sure that either we, or Fedora, want us to carry the .spec files in the Mir source tree - the Debian packaging is somewhat special, due to our (ambitions of) continuous-release-into-Ubuntu workflow.

I don’t think anyone would really have a problem with that. Plenty of projects are done that way. That said, official Fedora packages wouldn’t be released this way. There would be a spec in Fedora’s Dist-Git for that. If you’re working with the packager or one of you is a co-maintainer of the Fedora package, you could more-or-less do the same thing.

We’d only want to carry the .spec file in source control if we were planning to have a autobuilt mir-devel COPR, like our devel PPA. Which could be useful, but might be a stretch goal?

Plenty of desktop environment developers (Cinnamon, MATE, etc.) use Fedora, so it would probably be helpful for them. It wouldn’t be difficult, since COPR supports GitHub integration (Git checkouts, webhooks, badges, etc.).

[alan_g]

I’m not sure that either we, or Fedora, want us to carry the .spec files in the Mir source tree - the Debian packaging is somewhat special, due to our (ambitions of) continuous-release-into-Ubuntu workflow.

We should definitely test that Mir can build on Fedora, but I think that would be adequately solved by adding a Fedora target to Travis and running the commands you’ve listed here.

We’d only want to carry the .spec file in source control if we were planning to have a autobuilt mir-devel COPR, like our devel PPA. Which could be useful, but might be a stretch goal?

I don’t think we want to maintain packaging for all the various distros people might want to use Mir on, and I don’t think the various distros would want us to maintain packaging for it, either.

I’ve been discussing the way forward with @Conan_Kudo (owner of https://copr.fedorainfracloud.org/coprs/ngompa/Mir/).

@Conan_Kudo and I will work together to get Mir packaged and submitted to Fedora proper. @Conan_Kudo will deal with the packaging side and I’ll deal with any Mir issues.

The Fedora packaging will be maintained outside the Mir source tree (as something like https://github.com/MirServer/mir-fedora-packaging). This will facilitate making the latest release of Mir available as a COPR in the same way the release PPA makes it available on Ubuntu.

[alan_g]

I’ve been checking Mir trunk builds across Fedora 26, 27 and rawhide in preparation for a 0.28.2 release. Mir seems to work fine across all three versions of Fedora but there’s a problem running the test suite on rawhide that appears to be a bug in the gmock package.

@Conan_Kudo has submitted the Mir package for review to be included in Fedora.

There are x86_64 builds of Mir 0.28.1 for Fedora 26 & 27 on his COPR. This is not official nor supported, but testing on a Fedora 27 VM it seems to be working fine. Vis:

$ sudo dnf copr enable ngompa/Mir
$ sudo dnf install mir-demos
$ miral-desktop