Flatpak Linux binaries

[TTimo]

look into flatpak to provide Linux binaries

[illwieckz]

Is flatpak able to set q3map2 and other tools available in $PATH too?

I don't know well flatpack, but I remember that appimage (another way to distribute binaries on Linux) can't be a good candidate since it provides access to only one binary by design: the appimage can embed many binaries it can launch itself but they can't be launched from the outside (for example users would be able to run radiant and clicking the build menu will run q3map2, but user would not be able to run q3map2 alone).

So that's something to check: how flatpak handles that case ?

[jdolan]

I think it does support that, because maci went and provided a flatpack build for Quetoo, and we ship quetoo, quemap, quetoo-update, quetoo-master, etc..

https://github.com/maci0/org.quetoo.Quetoo

[magicmyth]

I've managed to get a working Flatpak manifest going. Repo is:

https://github.com/magicmyth/io.github.TTimo.GtkRadiant

It was a bit of a PITA (no svn in flatpak-builder and dealing with pangox's weird download URL was difficult to figure out) but from my very limited testing it seems to work for me. However, my experience from GtkRadiant is from a very long time ago so I don't know what to really test to stress it. I did make a basic room map and it builds and compiles without issue. The resulting package needs some optimising to remove unneeded bits from the build process but they don't do any harm except for a little extra disc space usage.

All the extra tools (e.g. q3map2) seem to work properly. See the repo's readme for further information on that.

Some notes

I had to patch a couple bits. First I changed the build process from using xml2-config to pkg-config because xml2-config will not function correctly in FDO runtimes (don't really know why but using xml2-config seems to be deprecated). As it is encouraged to use pkg-config over xml2-config these days It might be worth applying my patch to master (see the patches folder of my repo).

The other patch is a quick hack to revert part of commit ba64802. On Linux builds uintptr_t is not being defined so compiling fails there. I'm not really a C++ programmer so I'll let you guys decide what is best to do there but this patch at least gets things going on Linux right now.

Getting it on Flathub

Flathub may have some issues if you wanted to host there for a wider audience access. I had to enable network access for the build phase because the game packs are downloaded over svn during compile (took me a while to figure why that was happening because flatpak does not make it obvious it does this. Grrr). Network access for builds in flatpak is frowned upon and I don't know how Flathub would feel about it. I am quite sure they would require that at the very least the svn checkouts point to specifc commits of the game packages so the builds are repeatable and verifiable. As it is if a game pak was updated it would change the resulting build from past ones.

They might be more accepting if sandboxing was tightened up. Right now for ease of getting going the manifest grants host filesystem access (for the most part) but it could be restricted to the game user config directories like ~/.q3a with persist argument to the directory. Each supported game would need to be added and I have no idea what the other config dirs are called or where they are stored. Note that the user's can manually override such restrictions if they wanted.

[TTimo]

This looks very promising! I only gave gave this a brief look, I'll dig into it deeper soon.

[magicmyth]

I've been in contact with the Flatpak guys flatpak/flatpak-builder#133 and they are adding support for svn flatpak/flatpak-builder#135. So this will mean the manifest will reference each game pak as a source. I know the grabbing of the paks can be disabled with --no-packs switch. Will the current build system still compile support for the paks if that switch is set but the paks are present in the install/ directory or are some adjustments required?

[TTimo]

There's going to be interesting discussions regarding how flatpak can be used for GtkRadiant and how the integration with the games it supports is done.

The GtkRadiant binary has builtin code to copy game-related content into the games it supports when starting up. That support is always compiled in, --no-packs just disables downloading that content to be part of the zip we release.

I suspect when GtkRadiant is running from a flatpak, it won't be able to copy content into another game's folders (may require some special permissions, may depend if the target game is a host OS install or in a flatpak as well).

A lot of this will have to wait until I get more time to learn and experiment with the tech though. Thanks for doing the early exploration on this.

[magicmyth]

I don't see why it could not copy things into another game's folder. The filesystem limitations are only what we choose to put on it. And keep in mind user's can override/add to the filesystem with "--filesystem=~/gamefolder"

Thinking out loud, if the game paks are not required at all during build and don't need to actually be their to run ( I know that would be useless if their was none) the game packs can potentially be bundled into flatpak extensions. When installed flatpak would mount the game pak into the GtkRadiant game pak. This way user's can have a smaller download and grab only the game paks they are interested in via their software store.

[TTimo]

I wanted to practice flatpak a little so I picked up @magicmyth's original work, made a few updates, and rolled everything into a submission to flathub:

flathub/flathub#3682

[TTimo]

Doing a bit of testing on the latest, and it turns out we use a version of pango (1.40) that is too old for the flatpak gtk2 shared module, leading to this fatal error when opening a file selection dialog: Unable to load image-loading module: /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so: /usr/lib/x86_64-linux-gnu/librsvg-2.so.2: undefined symbol: pango_attr_insert_hyphens_new

[TTimo]

^ fixed, required patching pangox-compat .. no adverse effects observed .. was about to load up and build the quakelive map out of the game pak .. good enough? going to submit for final review

[TTimo]

release config is unstable, with less-than-useful crash backtraces. smells of memory trashing, does not seem related to the pango/pangox-compat hack above in early testing

[TTimo]

https://flathub.org/apps/io.github.TTimo.GtkRadiant