Fedora, GNOME, Linux

Why I use Flatpak for 3rd party apps


There are more reasons why to run applications as flatpaks. Someone wants to have the latest versions as soon as possible. For me as a user of Fedora which provides up-to-date versions of apps this is not a big motivation. Someone wants to run apps more securely. Again I usually trust software provided by Fedora and Flatpak sandbox is still not as strictly enforced as it should ideally be.

But where I really prefer using Flatpak to RPM packages are 3rd party applications. I’m usually running development versions of Fedora. Pre-releases on my work machine and Rawhide on my home laptop. They have been pretty stable for me, including applications in Fedora repositories. Unfortunately it’s not the case for 3rd party applications. Their authors usually don’t follow distro development closely and although many of them bundle as much as possible to avoid problems with changing dependencies, things break.

I used to use the Spotify client as a package from Negativo17 repos. But when I upgraded to F27, something broke and it stopped working. I’m pretty sure it was fixed later on after people started reporting it, but I didn’t want to stop using Spotify for the time being and didn’t have time to debug and report the issue. So I switched to Spotify flatpak and it has worked for me ever since.

The problem I had with very early stages of pre-released Fedora and Rawhide is that dependecies of GStreamer plugins in RPMFusion were usually broken. So I ended up without system multimedia codecs. It was often the case for VLC from the same repository, too. Then I switched to VLC and GNOME MPV flatpaks. Problem solved.

The last example is Telegram. Until recently I was using the official version. It’s not even provided as an RPM package. You have to download an archive, unpack its content to your home, run the binary which creates a desktop file… not very elegant in 2018, but once you do it, it just works. Well… until it doesn’t. I upgraded to F28 and Telegram suddenly took a lot of time to start up. It hung on some font config error until it timeouted and finally started. It easily took 1 minute. So I switched to Telegram flatpak as well. Works like a charm.

So what I really appreciate about Flatpak is that the apps don’t rely on the underlying system, so if the system changes e.g. due to upgrade to a newer major version apps don’t break. As I said it’s not such a major issue for distro-provided apps, but it’s certainly an issue for 3rd apps and Flatpak solved it for me.

Fedora, GNOME, Linux

Flathub Experience: Adding an App

Flathub is a new distribution channel for Linux desktop apps. Truly distro-agnostic, unifying across abundance of Linux distributions. I was planning for a long time to add an application to Flathub and see what the experience is, especially compared to traditional distro packaging (I’m a Fedora packager). And I finally got to it this last week.


In Fedora I maintain PhotoQt, a very fast image viewer with very unorthodox UI. Its developer is very responsive and open to feedback. Already back in 2016 I suggested he provides PhotoQt as a flatpak. He did so and found making a flatpak really easy. However it was in the time before Flathub, so he had to host its own repo.

Last week I was notified about a new release of PhotoQt, so I prepared updates for Fedora and noticed that the Flatpak support became “Coming soon” again. So I was like “hey, let’s get it back and to Flathub”. I picked up the two-year-old flatpak manifest, and started rewriting it to successfully build with the latest Flatpak and meet Flathub requirements.

First I updated dependencies. You add dependencies to the manifest in a pretty elegant way, but what’s really time consuming is getting checksums of official archives. Most projects don’t offer them at all, so you have to download the archive and generate it yourself. And you have to do it with every update of that dependency. I’d love to see some repository of modules. Many apps share the same dependencies, so why to do the same work again and again with every manifest?

Need to bundle the latest LibRaw? Go to the repository and pick the module info for your manifest:

"name": "libraw",
"cmake": false,
"builddir": true,
"sources": [ { "type": "archive", "url": "https://www.libraw.org/data/LibRaw-0.18.8.tar.gz", "sha256":"56aca4fd97038923d57d2d17d90aa11d827f1f3d3f1d97e9f5a0d52ff87420e2" } ]

And on the top of such a repo you can actually build a really nice tooling. You can let the authors of apps add dependencies simply by picking them from the list and you can generate the starting manifest for them. And you could also check for dependency updates for them. LibRaw has a new version, wanna bundle it, and see how your app builds with it? And the LibRaw module section of your manifest would be replaced by the new one and a build triggered.

Of course such a repo of modules would have to be curated because one could easily sneak in a malicious module. But it would make writing manifests even easier.

Besides updating dependencies I also had to change the required runtime. Back in 2016 KDE only had a testing runtime without any versioning. Flathub now includes KDE runtime 5.10, so I used it. PhotoQt also uses “photoqt” in all file names and Flatpak/Flathub now requires it in the reverse-DNS format: org.qt.photoqt. Fortunately flatpak-builder can rename it for you, you just need to state it in the manifest:

"rename-desktop-file": "photoqt.desktop",
"rename-appdata-file": "photoqt.appdata.xml",
"rename-icon": "photoqt",

Once I was done with the manifest, I looked at the appdata file. PhotoQt has it in a pretty good shape. It was submitted by me when I packaged it for Fedora. But there were still a couple of things missing which are required by Flathub: OASR and release info. So I added it.

I proposed all the changes upstream and at this point PhotoQt was pretty much ready for submitting to Flathub. I never intended to maintain PhotoQt in Flathub myself. There should be a direct line between the app author and users, so apps should be maintained by app authors if possible. I knew that upstream was interested in adding PhotoQt to Flathub, so I contacted the upstream maintainer and asked him whether he wanted to pick it up and go through the Flathub review process himself or whether I should do it and then hand over the maintainership to him. He preferred the former.

The review was pretty quick and it only took 2 days between submitting the app and accepting it to Flathub. There were three minor issues: 1. the reviewer asked if it’s really necessary to give the app access to the whole host, 2. app-id didn’t match the app name in the manifest (case sensitivity), 3. by copy-pasting I added some spaces which broke the appdata file and of course I was too lazy to run validation before submitting it.

And that was it. Now PhotoQt is available in Flathub. I don’t remember how much time exactly it took me to get PhotoQt to Fedora, but I think it was definitely more and also the spec file is more complex than the flatpak manifest although I prefer the format of spec files to json.

Is not your favorite app available in Flathub? Just go ahead, flatpak it, and then talk to upstream, and try to hand the maintainership over to them.

Linux, Red Hat

Flatpak and Endless OS at InstallFest Prague

I spent the last weekend in Prague attending InstallFest 2017. The event is called InstallFest because many, many years ago it started as an event where students could come and get help with installations of various Linux distributions. Times of installfests are gone and this event has transitioned into an open source conference with more practical focus.

The event has moved to a new venue – Faculty of Electrical Engineering of Czech University of Technology. It’s where Red Hat recently started a new open source lab. The venue was larger than the one in previous years and hosted 3 tracks + a small booth area.

I came to talk on two things – Flatpak and Endless OS. My Flatpak talk was on Saturday and got a 55-minute slot which seemed like a lot of time, but if you want to cover all the specifics of the technology, even 55 minutes is not much. The room was pretty full and the topic apparently stirred some attention. There was even one person interested in porting Flatpak to another distribution.

My talk on Flatpak

My talk on Endless OS was the first one of the second day. I only asked for a 25-minute slot which was just enough to make a brief introduction of the system. I also brought with me both Endless devices I have in possession – Endless One and Endless Mini. There were not as many people as at my Flatpak talk, but those who came seemed pretty interested. Almost none of them had ever heard of the OS and PCs before. They asked if they’d ever be available in Europe (which I couldn’t answer because I have no idea) or if you can connect extending hardware to the PCs just like to Raspberry.

As a side note, I was positively surprised how many people wore Fedora t-shirts at the conference.

Myself with the Endless PCs


Fedora, Uncategorized

Nightly and Wayland Builds of Firefox for Flatpak

When I announced Firefox Developer Edition for Flatpak over a month ago, I also promised that we would not stop there and bring more options in the future. Now I can proudly announce that we provide two more variants of Firefox – Firefox Nightly and Firefox Nightly for Wayland.

With Nightly, you can closely follow the development of Firefox. Due to Flatpak you can easily install it and keep getting daily updates via our flatpak repo.

As a bonus, we’re also bringing a Firefox build that runs natively on Wayland. We used to provide a Copr repository, but with Flatpak it’s open to users of other distros, too. When running this version, keep in mind it’s still WIP and very experimental. Firefox seems to run just fine on Wayland at first glance, but there is still some basic functionality missing (copy-paste for example) and it’s not so stable either (it crashed the whole Wayland session for me once). But once it’s done, it will be a big improvement in security for Firefox on Linux because Wayland isolates the application on the display server level. Together with other pieces of Flatpak sandboxing, it will provide a full sandbox for the browser in the future.

When adding more Firefox variants to the repo, we first considered using branches, but you have to switch between them manually to start different variants of Firefox which we didn’t find very user friendly. In the end, we’re using one branch and multiple applications with different names in it. This way, you can install and run multiple variants in parallel.


You can find the instructions to install Firefox for Flatpak on the repository webpage. We’re also constantly improving how Firefox runs in Flatpak. If you have any Flatpak-specific problems with Firefox, please report it to our bug tracker on Github. If you hit problems that are not Flatpak-specific, please report them directly to Mozilla.

And again kudos to Jan Hořák from our team who made all this happen!

Fedora, Linux

Firefox Developer Edition for Flatpak

Our team maintains Firefox RPMs for Fedora and RHEL and a lot of people have been asking us to provide Firefox for Flatpak as well. I’m finally happy to announce Firefox Developer Edition for Flatpak.


We started with the Developer Edition because that’s something that is not easily available to Fedora users. Providing the standard Firefox wouldn’t bring a lot of benefit right now because it’s available very quickly after upstream releases via Fedora repositories. In the future, we’d like to add releases of the standard Firefox (nightly, stable, perhaps ESR).

Firefox DE for Flatpak is built on our internal build cluster and hosted on mojefedora.cz (mojefedora == myfedora in Czech) on OpenShift. It’s an unofficial build for testing purposes, not provided by Mozilla. We’d like to work with Mozilla, so that it can eventually be adopted by the Mozilla project and you can get Firefox flatpaks directly from the source.

Right now, Firefox DE is not sandboxed, it has full access to user’s home. In the near future, we’d like to start a devel branch in the flatpak repository where we will ship a sandboxed Firefox and experiment how well Firefox can handle sandboxing and what needs to be done to assure the expected user experience. A web browser is definitely the #1 candidate among desktop applications for sandboxing. If you’re interested in sandboxing Firefox on Linux via Flatpak, contact us (you’ll find Jan’s email on the website with installation instructions).

Firefox Developer Edition for Flatpak running on Fedora

We’ve tested the FDE flatpak on Fedora 25, openSUSE Tumbleweed, and Ubuntu 16.10. You need flatpak 0.6.13 or newer for the installation commands to work. The repo should work with older versions as well, but there was a change in command syntax and the commands we use don’t work in older releases than 0.6.13. Fedora 25 has the newest release (0.8.0), openSUSE Tumbleweed has a new enough release (0.6.14), just for Ubuntu you’ll need to install the newest flatpak from a PPA.


Firefox Developer Edition for Flatpak running on Ubuntu

GNOME Software in Fedora 25 also supports adding repos via .flatpakrepo files and installing apps via .flatpakref files, but it’s not reliable enough yet, so we only recommend you use the command line instructions. It’s just two commands (you only need the latter one on Fedora 25 with the newest flatpak).

There are also a couple of problems we haven’t quite figured out yet. In openSUSE and Ubuntu, the desktop file database is not refreshed after the installation, so the launcher doesn’t appear right away. You need to log out and log in to refresh it and make the launcher appear. In openSUSE Tumbleweed in KDE Plasma in a VM, I couldn’t start the app getting “no protocol specified, Error: cannot open display: :99.0”. We’re looking for hearing from you how it works on other distributions.

Although the repo is for testing purposes, we’re committed to updating it regularly until we announce otherwise on the website with the installation instructions. So you don’t have to worry that you’ll end up with a scratch build that will never get updated.

At last, I’d like to thank Vadim Rutkovsky who made the initial proof-of-concept Firefox build for Flatpak we built upon, and Jan Hořák who did most of the work on the current build and repo setup.

Fedora, GNOME, LibreOffice, Linux

Installing flatpaks gets easier in Fedora 25

A lot of users complained that installing flatpaks was too difficult. And they were right, just look at the installation instructions on the Flatpak download page at LibreOffice.org. But that was never meant to be the final user experience.


Richard Hughes integrated Flatpak support into GNOME Software and the Red Hat desktop apps team worked with him to make sure it works well with apps we’ve already packaged for Flatpak. And this is the result. As you can see installing LibreOffice for Flatpak is now a matter of a couple of clicks with GNOME Software 3.22.2 in Fedora 25:


Flatpak allows you to generate a .flatpak bundle which includes the app and all the necessary info for installation of the app and setting up its repo for future updates. You can also create a .flatpakref file which doesn’t contain the app, but all the installation info and the app is downloaded during the installation. This format is also supported by GNOME Software now. LibreOffice offers a .flatpak bundle because it’s more similar to what users are used to from Windows and macOS.

As you can see on the video, installing .flatpak bundles is a matter of downloading the file and opening it directly with GNOME Software or double-clicking it. There is one prerequisite though. You need to have a repo of the runtime the app requires enabled which I had because I had been using the GNOME runtime for other apps already. Installation of runtimes is being streamlined as well. As a runtime provider, you can ship .flatpakrepo file which includes necessary info for setting up the repo and is as easy to install as .flatpak and .flatpakref. For Fedora Workstation we’re currently considering to enable repos of most common runtimes by default, so users would not have to deal with them at all, the required runtimes would get installed automatically with the app.