Dolphin-Emu under openSUSE Leap 42.3

EDIT: Thanks to a tip in the comments, Qt 5.6 support is restored for now. Something broke Fedora 27, though. Once Dolphin adopts Qt 5.9-specific features, I’ll proceed as originally mentioned below.

Original post:
A day after I formally announced my game console emulator repository, the Dolphin Emulator guys decided to merge a patch that makes Qt 5.9 mandatory. That means Dolphin is no longer compatible with openSUSE Leap 42.3 which comes with Qt 5.6.

I take pride in myself for having a high-quality product, even if it’s just free video game stuff. Therefore my plan is this instead of simply disabling 42.3 and calling it a day:

I’ll pick the last commit before that patch and build that Dolphin revision. Then I’ll disable the 42.3 target and build the most recent version for the other distributions. That way the last 42.3-compatible binaries stay on the download server until I remove the 42.3 target entirely which will be either when Leap 15.1 gets released or maybe even earlier.

I don’t think the impact will be that big, though. For gaming it’s important anyway to migrate to new base OS anyway because of all the performance improvements that come with new kernel and Mesa versions but for now the 42.3 users are covered.

Advertisements

Video game emulators for Linux

What started as an effort to package Ishiiruka-Dolphin for Linux has grown into a broader project. It grew in silence but I thought it’s time I formally announce it.

My Open Build Service repository ships release versions of:

And it ships regular Git snapshots (for very active projects almost daily) of:

Everything in this repo is 100% legal. Games, firmware, or BIOS dumps are NOT included and will never be (unless someone makes a legal reimplementation of those). Some emulators are still highly experimental (such as Decaf) and don’t even work for anything but simple homebrew stuff.

It’s not always possible but I try to target the current and the last Fedora releases, the current and the last openSUSE Leap releases, as well as openSUSE Tumbleweed. I build for x86-64 only. Some of the packages would also build for CentOS, Mageia, and 32bit x86 but I decided not not enable these build targets to reduce strain on OBS servers – I’d be happy to accept tweaks and fixes, should anyone of you fork a package into your OBS home repo and build it there.

Dolphin/Ishiiruka users might also be interested in this collection of gamepad layout presets: https://gitlab.com/KAMiKAZOW/Dolphin-360-Linux.

UPDATE: Added bsnes.

Adoption of Flatpak vs Snap (2018 edition)

This is an update to my blog post from last year.

Here some facts for context, should anyone read this sometime down the road:

  • Today is 8 June 2018
  • Latest Flatpak:
    0.11.8.1, released today (0.11.8.0 was released yesterday)
    0.10.4 “Stable” released on 14 February 2018 (last old stable was 0.8.9)
  • Latest Snapd:
    2.32.9 released 21 days ago

Because Flatpak comes in two types, regular release (0.11.x) and “Stable” (=LTS, 0.10.x), the latest Stable release counts as well. With Flatpak 0.11.8’s hotfix only released 4 hours ago, it could not have passed the QA of any serious distribution, so 0.11.7 counts as latest for now.

Green means the latest version is in an official repository.
Yellow means that either the latest version is in an add-on repo or the package is in an official repository but with some problems.
Red means either not available at all or in some barely maintained (or even abandoned) add-on repository.

Flatpak Snap
Arch Linux Extra / Latest release AUR only / Latest release
Debian Latest in Stretch Outdated everywhere (even Sid)
Fedora Latest release Outdated and clashing with SELinux
Gentoo Overlay with latest release Overlay outdated
Mageia 0.10.3 Not available
openSUSE Latest in TW / Latest LTS in Leap15 Outdated / In add-on repo only
RHEL/CentOS 0.8.8 Not available
Ubuntu Latest in Bionic Latest in Bionic

Flatpak is continuing to go strong. In case of Mageia it graduated from the development Cauldron branch into a proper Mageia release, even though they forgot to package 0.10.4 and only ship 0.10.3, so while more users can no use Flatpak packages, they went from green to yellow because of that update oversight.
openSUSE’s conservative Leap releases also carry Flatpak now, not only their rolling release, so things actually improved while staying green.
Weirdly enough CentOS, while shipping Flatpak and not Snapd, does not even ship the last Old Stable release.

Positive developments for Snap have been that it graduated in Fedora from a totally broken build in a user repository to the main one. There are problems with SELinux (which is enabled by default on Fedora) but I don’t know how serious they are, so I give them the benefit of the doubt and rate it yellow instead of red.

In Arch Linux Snapd got demoted from the Community repo to AUR, however that at least carries the latest release.

In an attempt to increase the adoption rate of Snap, Canonical hired people to package Snapd for competing distributors. To a degree it seems to have paid off because Arch, Fedora, and openSUSE packages at least have some outside contributors, however only the AUR package is not outdated. Even Debian’s Snapd package is no longer the latest release. So while Snapd managed to cut the number of red cells down, the Debian packagers also dropped the ball and now they’ve lost their green table cell.

Just like last year, smaller distributions seem to gravitate more towards Flatpak than Snapd (like OpenMandriva).

So while things changed here and there, IMO Flatpak is still the way to go, especially for those software vendors that target professional users with Flatpak being supported by CentOS/RHEL, Debian, openSUSE Leap, and even the current LTS release of Ubuntu. Snap packages OTOH are only 100% supported by Ubuntu. Even other distributions that carry it do with some downsides.

Qt Web Renderers Greatly Improved in openSUSE Leap 15 and TW

With the upcoming release of Leap 15.0 and current snapshots of Tumbleweed, the rolling release variant, openSUSE users get important updates to both QtWebKit and QtWebEngine.

QtWebKit

QtWebKit was officially abandoned by Qt Company in Qt 5.6. As the name suggests, it is a port of the WebKit engine primarily developed by Apple for Safari. Until recently openSUSE shipped the abandoned version of QtWebKit, however Konstantin Tokarev maintains an independent version of QtWebKit which merges work of the old Qt port with improvements the WebKit-GTK port made, like using CMake instead of QMake. More importantly, this new QtWebKit 5.212 raises the security patchlevel to that of WebKit-GTK 2.12 and also includes some additional backports. While that is hardly state of the art and I would strongly recommend against using a QtWebKit browser to surf the web, it is a huge improvement over shipping an abandoned release.

Shoutouts to Max Lin who brought QtWebKit 5.12 to openSUSE.

There are still good reasons why QtWebKit makes sense in certain controlled environments. WebKit works with more CPU architectures and uses less memory than QtWebEngine.

I have packaged a version of the QupZilla 1.8 web browser for evaluation purposes. You can use it to find and report bugs in QtWebKit but – as I said – I would not recommend using it as daily web browser.

QtWebEngine

QtWebEngine is the official successor of QtWebKit. It is based on the Chromium codebase developed by Google for Chrome. In most cases, it is a very good choice but there is also a downside: Its releases are tied to the rest of Qt 5. This is less of a problem for Tumbleweed which usually gets the latest Qt 5 version anyway but it is a big problem for Leap which as a distribution with long-term support uses the latest LTS version of Qt 5. During the support cycle of a Qt 5 LTS version, updates ship less frequently until only the most crucial bugs are fixed. The previous LTS version, 5.6, was released in March 2016 and did not get a single bugfix release between October 2016 (v5.6.2) and September 2017 (v5.6.3) and there hasn’t been one since. While that may be fine for the rest of Qt 5.6, there have been a bunch of security fixes to the Chromium codebase that users did not get.

This changes now. Following the example of the Fedora KDE team, we now ship the latest QtWebEngine release regardless of the rest of Qt.

This means: Leap 15 has Qt 5.9 LTS and QtWebEngine 5.10.1 and will get QtWebEngine 5.11 and further future versions ASAP.

As an added bonus, we even ship additional security fixes that are not in 5.10.1. This is thanks to the work done in Fedora whose patches we could simply apply without much work on our part. Additional thanks to Fabian Vogt of openSUSE’s KDE team who helped me a lot with some scripting magic required when mixing different Qt and QtWebEngine versions.

Ishiiruka-Dolphin (GameCube/Wii Emulator) for Linux

You may have heard about Dolphin, not our file manager but the GameCube and Wii emulator of the same name. What you may not have heard of is Ishiiruka, a fork of Dolphin that prioritizes performance over emulation accuracy – and clean code if comments by an upstream Dolphin author on Reddit are to be believed.

Although Ishiiruka began as a reaction to remove the Direct3D 9 renderer in the Windows version of Dolphin (which is probably why the Linux community ignored it for the most part), it also began to tackle other performance issues such as “micro stuttering”.

Recently the Git master branch of Ishiiruka shipped compilation fixes for Linux, so I decided to dust off my old dolphin-emu.spec file and give it a try (I’m hardly an expert packager). So after some dabbling I succeeded. For now only Fedora 24, Fedora 25, and openSUSE Tumbleweed are supported. The packages are available from https://software.opensuse.org/package/ishiiruka-dolphin-unstable.

openSUSE Leap requires some workaround because it defaults to GCC 4. I plan to look into it at a later time. Once Tino creates a new Stable branch that incorporates the Linux fixes, I’ll post it under https://software.opensuse.org/package/ishiiruka-dolphin. (Quick update: It is now available on openSUSE Leap. The Stable builds as well. In addition to that, all openSUSE builds now build against shared wxWidgets 3.1 instead of statically linking the included one.)

If anyone of you is interested in Arch, Debian, Ubuntu,… packages (anything supported by OBS), I’ll gladly accept Submit Requests for PKGBUILD etc. files at https://build.opensuse.org/project/show/home:KAMiKAZOW:Emulators.

Get it from https://software.opensuse.org/package/ishiiruka-dolphin and https://software.opensuse.org/package/ishiiruka-dolphin-unstable.

Adoption of Flatpak vs Snap

A recent blog post says that KDE is still undecided on which containerized application format to support. Inspired by a post in a heated discussion on Phoronix I decided to investigate on my own how well various distributions support either format, so here’s a table with the results:

Flatpak Snap
Arch Linux Extra / Latest release Community repo /
Out-of-date
Debian Latest in Stretch Latest in Stretch
Fedora Latest release (F24 and newer) Not in main distro /
COPR outdated (no F25)
Gentoo Overlay with latest release Overlay outdated
Mageia Not available
openSUSE 0.8.0 in Tumbleweed, latest in review Failed and outdated builds in add-on repo only
Ubuntu Latest in Zesty Latest in Zesty

Given these results alone, I’m quite frankly pretty puzzled how the jury could still be out and that’s completely ignoring the centralized nature of Snap. Distributing AppImages via Steam makes more sense than Snap (Steam has the same centralized nature as Snap). Not only does every somewhat mainstream distribution ship Steam in some non-free repo, it would also allow us to distribute applications to Windows and macOS.

Even Snap’s home turf, Ubuntu, supports Flatpak since 16.10. Canonical employee Zygmunt Krynicki (zyga) was tasked to package Snap for various distributions but didn’t touch most packages since about half a year (no idea why). The COPR for Fedora does neither ship the latest Snap release nor does it support the latest Fedora version (F25). Builds in the OBS repo for openSUSE all fail, even though openSUSE also uses AppArmor, which Snap relies on for its security features instead of SELinux. The only distribution outside the Debian/Ubuntu ecosystem that adopted Snap at all in an official repository was Arch and that one does not even ship the latest release – despite Arch’s rolling release nature. Meanwhile Flatpak was adopted by every somewhat major distribution except Gentoo (and even there the 3rd party overlay is more up-to-date than Snap’s). Smaller distributions like Intel’s ClearLinux and Solus also adopted Flatpak (I encourage to read the Solus post for some great insight).

Note: I’m not a developer, so I see myself as an outsider looking in on that topic who just wanted to contribute some stats. Although my current focus is packaging (RPM), I had no closer look at either format other than distribution support for the table above. I also disabled comments in this case, just because I don’t want to fragment discussion further. Head to the original blog post if you want to comment on this topic.

Xbox pads under Fedora 24

After the release of Rocket League beta for Linux, I decided to install Steam under Fedora 24 and try it out.

The Xbox controller driver is not installed by default. Get it via

sudo dnf install kernel-modules-extra

Apparently the SteamOS variant of the xpad driver has some additions the normal kernel driver does not (yet) have.

To install it:

  1. Uninstall kernel-modules-extra (if installed; the upstream driver conflicts with the SteamOS version):
    sudo dnf -y remove kernel-modules-extra
  2. Enable negativo17’s Steam repo:
    sudo dnf config-manager --add-repo=http://negativo17.org/repos/fedora-steam.repo
  3. Install the dkms-xpad driver:
    sudo dnf -y install dkms-xpad kernel-devel
  4. Build the kernel module:
    sudo dkms install -m xpad/4.1

Not sure if I did a sudo modprobe xpad afterwards but now it works. Have fun.