Use Flatpak for Linux build and distribution

[magicmyth]

I've forked and updated the old Flathub flatpak builder manifest: https://github.com/magicmyth/org.quetoo.Quetoo/tree/latest

Don't know if this would resolve the issue for #534 but I tested it on Ubuntu 16.04 and 18.04 and so far it appears to work fine. I'll try to test some other distros when I get the chance but would appreciate anyone testing on their favourite distro.

I've done limited testing which includes LAN games and joining online (but no one was online).

I'm curious if you (Quetoo dev) guys know why the manifest fell into disrepair? All I have done is update the used commits for Quetoo, Quetoo-data, ObjectivelyMVC, and Objectively and all worked fine.

I'm happy to keep the manifest up-to-date for while. Might delay a week or two if a build issue creeps in that needs a bit of debugging. I'm interested in using it as a test case for Flatpak as I have also made a manifest for GtkRadiant.

[SpineyPete]

We don't (officially) support flatpak.

Unless we can find someone who can keep it consistently up-to-date in the long term, we'd rather avoid having to maintain multiple channels of distribution. It reflects poorly on the project when things break without explanation. We've already had a number of complaints pop up about flatpak builds not working. Those were uploaded by a contributor which seemed to pop up and then disappear for long periods. Needless to say, this just creates frustration for all parties involved.

Currently none of the main developers is interested in supporting and maintaining flatpak. This might change in the future, but at the moment Quetoo is in beta and sweeping/breaking changes are to be expected.

That said, you should talk to @jdolan if you feel like contributing. :) You can always drop by on Discord -- https://discord.gg/qMtbnMm

[SpineyPete]

I'm curious if you (Quetoo dev) guys know why the manifest fell into disrepair?

Simple answer is that we don't know, because the dev team simply has not looked into this at all. The flatpak was uploaded by a one-time contributor and we only became aware of it once things started breaking and people started complaining.

[magicmyth]

That all makes sense. I didn't expect to find it on Flathub when I did as Flathub is intended only for stable applications. And I'm surprised someone made the manifest and didn't mention it to the upstream devs.

If you were to support it I would recommend using it as the only official distribution channel as it makes running across distros simpler. It also allows for easy switching between dev and stable builds for user's as different branches can be hosted in a ostree repo.

Technically keeping the manifest up-to-date is very easy (just change the commits) but of course in practice that can be a bit more challenging as the project evolves through its earlier stages. As I said, I'm happy to update it from time to time and attempt resolve build changes. Because Quetoo does have a good build system already I don't see this really being an issue. Anything that affects the Flatpak build would almost surely affect Linux distros in general anyway.

As I mentioned my main interest is to give a good user case for flatpak's own development as GtkRadiant's picture among the various ID Tech engine based games as a multiple project development tool demonstrates how some apps will need a way to work with other apps in a sandboxed world.

One thing that might be worth taking though is the appstream file. Pretty much all package systems are making use of appstream now for their software stores and its recommended that the upstream projects maintain them. I'm not saying pull it in now (though feel free to do so) but keep it in mind for the future.

I may see if I can host "releases" on Github but I don't know if that technically flies as the release of the content is technically just a manifest. We'll see. If there is some hosting available I am happy to provide regular flatpak builds for Quetoo that can simply be downloaded or ideally a ostree repo for smaller download update.

I'll try and stop by the discord channel and have a chat.

Thanks SpineyPete

[jdolan]

Hi @magicmyth, thanks for spending some time on this. I do think Flatpak is a great option for Linux builds, tho it doesn't help us with Windows or macOS. I know that GtkRadiant is without reliable packaging for Linux at the moment, so I understand your motivation in proving out a Flatpak solution for it -- and needing a game to validate your approach with. Thanks for choosing Quetoo for that :)

I think we could consider Flatpak for our Linux distributions as long as it would play well with our updater. If people can install via Flatpak, but then still receive incremental updates via quetoo-update, I'd say it's viable for when we reach stable state.

[magicmyth]

It should technically be possible to have a separate data directory that quetoo-update could write to. You could have it write to /opt/games/quetoo (system wide) or $XDG_DATA_HOME/quetoo (user) and the flatpak runtime could mount those directories however it would be a bit redundant because flatpak repos (via ostree) do incremental updates anyway and take care of permission configuration.

BTW with a bit of extra fuss I could get flatpaked GtkRadiant setup to develop flatpaked Quetoo maps. As right now there is no way for one flatpak app to see another's data directory (as the library of flatpaks is masked by the sandbox) you need to create a bind mount. E.g:

mount --bind /var/lib/flatpak/app/org.quetoo.Quetoo /opt/games/quetoo

Then GtkRadiant can be configured to use /opt/games/quetoo as a the data directory. Allowing it to directly call binaries within org.quetoo.Quetoo is currently not possible though (at least as separate apps) but a developer can at least call flatpak run --command=quemap org.quetoo.Quetoo ~/.quetoo/my_level.map

I'm going to be pinging the flatpak folks about having some way to allow apps to request access to other apps (e.g access args --can-call=org.quetoo.Quetoo). I wanted to be able to point them to a user case first. This will show we have multiple ID Tech based games being able to work with multiple level editors.

[jdolan]

There's more to Quetoo updates than data -- in fact, the vast majority of our incremental updates are related to executables. Our continuous integration server publishes successful builds to an Amazon S3 bucket, which our updater in turn downloads from.

But at any rate, if you can run quetoo-update successfully from within the Flatpak sandbox, then it'll probably be just fine.

[magicmyth]

Ostree is incremental with everything in the package. It does static delta updates. Thus only the difference, whether it is a binary, png or txt, is sent. So if you updated the engine only which resulted in a single changed binary, when a user next ran a software update only the new binary (in principal) would be downloaded. If a single map was changed, then only the map data would be downloaded. Though my knowledge of ostree is still very flaky so at the moment take this with a pinch of salt ;)

You won't be able to deliver the binary within the flatpak environment because that would potentially break within the environment (it would be the same as the binary working on Ubuntu but not Gentoo). Well I suppose you you could technically build within a flatpak SDK environment and extract the built binary into your bucket and download that within the flatpak (org.quetoo.Quetoo) but that really does not make sense with flatpak as the point is to use a ostree repo, hosted over http to deliver deltas of the updated package. I know others have also hosted flatpak repositories on Amazon S3 but I've not tried that yet.

[jdolan]

I'm closing this out as there's been no activity here for quite some time.

[Calinou]

For reference, here's an updated manifest for the current Quetoo Git (as of writing): https://github.com/Calinou/org.quetoo.Quetoo

I also updated it to use the FreeDesktop 20.08 runtime. Everything seems to be working as intended so far.

You can build it locally by cloning that repository then running the following command in the repository:

flatpak-builder builddir --ccache --force-clean --user --install org.quetoo.Quetoo.json

[jdolan]

Thanks @Calinou. I've come around to this idea, and I actually think we should absorb this build as our default Linux distribution. We could build a Flatpak bundle right from ci.quetoo.org, and have all Linux distros covered. Seems worthwhile to me.

Would you be interested in actually merging this into the main Quetoo repo and setting it up on Jenkins, or would you prefer to hand it off to me?

[Calinou]

Would you be interested in actually merging this into the main Quetoo repo and setting it up on Jenkins, or would you prefer to hand it off to me?

I don't have experience with Jenkins, so I'd prefer handing it off to you.

[jdolan]

Got it. Not a problem. @magicmyth I know it's been a while since there was movement on this ticket, but would you still be interested in pushing this forward?

[magicmyth]

Wow been a while! :)

@jdolan So what are your thoughts on how you would want the flatpak to behave?

As you mentioned before about quetoo-update would you prefer not to have the flatpak build everything but instead just the engine and then when the flatpak is run it would trigger quetoo-update to download the game data? That way flathub would distribute the engine binaries only? The downside of that is the data files would be downloaded to the user's directory (under $HOME/.var/app/org.quetoo.Quetoo) which on a shared system would not be so efficient.

Or would you have it do what the manifest is currently doing and have the game data bundled in the whole flatpak? Any map/content changes would require an update to the flatpak manifest which would be pushed to flathub and then the user's software manager (flatpak update) would take care of the rest. I imagine that would cause a bit of a delay on getting the latest content to Linux users. How long I simply don't have any experience to advise with.

An alternative is to use your builds directly and have the flatpak use those as sources as that seems to be what Xonotic is doing as looking at its manifest it just downloads the release zip and stuffs everything in the right place within the flatpak sandbox.

As for Jenkins I don't have any experience besides the casual curious read in the past but I would be interested in giving it a stab. I take it one can test it out locally as I see your scripts use docker for Jenkins? Could you give me a few commands on how to build with Jenkins CI and from there I could probably start working out how to have it do a flatpak build test?

I am quite busy in real life atm but I'm willing to give it a stab. Might be a few weeks though.

[jdolan]

So part of why I think this is a better fit for us now than it was a couple years ago is:

1. We've shifted to git-flow and we are aiming to merge develop into master approximately once per month, meaning that incremental updates to users will flow at about that frequency, rather than potentially weekly or daily.
2. Because of this, we are also able to now provide full snapshots with each monthly release, rather than only "shell" snapshots that do not include game data and require the user to run quetoo-update.
3. In fact, quetoo-update is actually gone. The game itself checks for updates by comparing text files fetched from AWS, and launches the Java-based installer directly if an update is available and the user elects to take it.

So with all of these changes in mind, I think Flatpak is well aligned to deliver Quetoo to Linux users. I would propose that the Flatpak formula fetches game data and includes it in each bundle. These can be updated (automatically?) after each successful master build on http://ci.quetoo.org. If we include the Flatpak formula right in our repo, this will effectively just replace what currently resides in our linux build scripts folder. If we can publish the Flatpak package ourselves, then this would work great.

The only major change to the game itself would be to detect if we are running a Flatpak build, and instruct the user to update via Flatpak, rather than launching the Java-based installer to self-update.

Let me know if you think this all sounds feasible. If it does, I'll look into getting the Flatpak dev tools installed on ci.quetoo.org (or, more likely, the Debian build slave) so that we can give this a whirl.

[Calinou]

The only major change to the game itself would be to detect if we are running a Flatpak build, and instruct the user to update via Flatpak, rather than launching the Java-based installer to self-update.

There are two ways to do this:

• Add a compile-time switch to change the update instructions.
• Detect at run-time if a file at the /.flatpak-info path exists (this is an absolute path). If it exists, change the update instructions to mention Flatpak.

[jdolan]

Over the weekend, I provisioned a new Debian 10 build slave that is up to the task of building flatpak images. I also merged the flatpak build formula from @Calinou 's fork into the quetoo repo. I attempted to follow the instructions in the README, and the flathub dependencies installed fine. But I ran into an issue at the very end of the actual build:

/opt/jenkins/workspace/Quetoo-Linux-x86_64-develop/flatpak $] flatpak-builder \
   --force-clean \
   --repo=.. \
   build ./org.quetoo.Quetoo.json 

...
Processing application org.quetoo.Quetoo
Saving icon /app/share/app-info/icons/flatpak/64x64/org.quetoo.Quetoo.png
Saving icon /app/share/app-info/icons/flatpak/128x128/org.quetoo.Quetoo.png
Saving AppStream /app/share/app-info/xmls/org.quetoo.Quetoo.xml.gz
Done!
Committing stage cleanup to cache
Finishing app
Exporting share/applications/org.quetoo.Quetoo.desktop
Exporting share/icons/hicolor/128x128/apps/org.quetoo.Quetoo.png
Exporting share/icons/hicolor/20x20/apps/org.quetoo.Quetoo.png
Exporting share/icons/hicolor/256x256/apps/org.quetoo.Quetoo.png
Exporting share/icons/hicolor/48x48/apps/org.quetoo.Quetoo.png
Exporting share/icons/hicolor/40x40/apps/org.quetoo.Quetoo.png
Exporting share/icons/hicolor/32x32/apps/org.quetoo.Quetoo.png
Exporting share/icons/hicolor/64x64/apps/org.quetoo.Quetoo.png
Exporting share/icons/hicolor/16x16/apps/org.quetoo.Quetoo.png
Exporting share/icons/hicolor/24x24/apps/org.quetoo.Quetoo.png
Please review the exported files and the metadata
Committing stage finish to cache
Exporting org.quetoo.Quetoo to repo
error: opendir(objects): No such file or directory
Export failed: Child process exited with code 1

Everything appeared to build just fine. It was just this final packaging step that failed. Is this just a path issue? Should I not be running the flatpak build from within the working copy?

[Calinou]

@jdolan I've never seen that issue before, not sure what could be causing it :slightly_frowning_face:

[jdolan]

@Calinou What is quetoo-repo in your README? Is that meant to be a working copy of Quetoo, or a working copy of this Flatpak build?

I just moved the .flatpak-build from /path/too/quetoo/flatpak folder to a path outside of my Quetoo working copy and ran the build again, and I think it succeeded?

admin@ip-172-31-33-173:~/Coding/quetoo-flatpak$ flatpak-builder build /opt/jenkins/workspace/Quetoo-Linux-x86_64-develop/flatpak/org.quetoo.Quetoo.json
Downloading sources
Fetching full git repo https://github.com/libcheck/check.git
Fetching git repo https://github.com/jdolan/Objectively.git, ref refs/heads/master
remote: Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
Fetching git repo https://github.com/jdolan/ObjectivelyMVC.git, ref refs/heads/master
remote: Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
Fetching git repo https://github.com/jdolan/quetoo.git, ref refs/heads/master
remote: Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
Fetching git repo https://github.com/jdolan/quetoo-data.git, ref refs/heads/master
remote: Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
Starting build of org.quetoo.Quetoo
Cache hit for metadata, skipping build
Cache hit for Check, skipping build
Cache hit for Objectively, skipping build
Cache hit for ObjectivelyMVC, skipping build
Cache hit for Physfs, skipping build
Cache hit for Quetoo, skipping build
Cache hit for Quetoo-Data, skipping build
Cache hit for cleanup, skipping
Cache hit for finish, skipping
Everything cached, checking out from cache
Pruning cache

I see what looks like a complete game under build/files. So could you please clarify what these next lines in your instructions should be?

flatpak --user remote-add --no-gpg-verify --if-not-exists quetoo-repo quetoo-repo
flatpak --user install quetoo-repo org.quetoo.Quetoo
flatpak run org.quetoo.Quetoo

From what I gather from the flatpak docs, this would add a "local remote" so that I can then install the bundle from that remote, and then run it? Without a Linux box to test this on myself, what is the best way to package up the bundle and publish it on Quetoo.org or something, so that you or @kaadmy can test it? :)

[jdolan]

Nevermind, I did some reading..

So the question is: should we distribute via flathub, via our own repo, or via single-file bundles?

[jdolan]

Good god. Apparently we were accepted to Flathub years ago: https://github.com/flathub/org.quetoo.Quetoo

So.. I should fork your fork, @Calinou, and open a PR all the way to upstream, right?

[Calinou]

So.. I should fork your fork, @Calinou, and open a PR all the way to upstream, right?

You can do that, but remember that to be published on Flathub, we need to designate commits as "releases". Since Quetoo follows a rolling release model, we could do this once a month or so. (We don't have to use Git tags, but we can.)

[jdolan]

Yup, totally makes sense. We are merging to master once a month or so. So the additional work will be to update flathub with those hashes. That’s fine.

So I didn’t need to install flatpak on the build slave at all. We won’t even be running these builds 😂

[jdolan]

Okay, I've emailed admins@flathub.org to request that the org.quetoo.Quetoo repo be unarchived. I've also forked that repo, and merged your updates into my fork. Once we're able to push upstream again, we can manage pull requests through my fork.

Thank you @Calinou and @magicmyth for all of your work on this!

[jdolan]

This build is now available via Flathub. Can someone on Linux give it a whirl and report back if it works? We still need to sort out Flathub detection so that the updater is not launched, but.. the game should be playable right now.

[jdolan]

@Calinou You were saying that I can literally

fopen("/.flatpak-info", "r");

To determine if we are running a Flatpak build or not?

[Calinou]

@Calinou You were saying that I can literally

fopen("/.flatpak-info", "r");

To determine if we are running a Flatpak build or not?

Yes, that should work.

[magicmyth]

@jdolan

Thank you @Calinou and @magicmyth for all of your work on this!

Not sure how much I did but thanks anyway :slightly_smiling_face:

I've fired up Discover and installed it on my laptop. Normally I use the command line but I wanted the more normal experience. It installed suprissingly fast (probably down to the flathub servers which will help keep the load of you guys). On launching it did mention there was an update available so I clicked "No". I created a game just fine and it performed about as well as I expected on my laptop. I couldn't get any servers to join thougth as all list "Invalid response from [IP_ADDRESS]". Been a while since I tried a game so I don't know if thats typical?

To compare I ran the update script from the normal install I had already lying around which itself ran fine but I could not game the game to launch. First it needed libjpeg62 so I installed that from the repository but it then just failed to launch with:

quetoo: r_mesh_draw.c:513: R_InitMeshProgram: Assertion `r_mesh_program.shell' failed.
Sys_Signal: Received signal 6
...
/lib/x86_64-linux-gnu/libc.so.6(+0x46210) [0x7f464a7f5210]
...
bin/quetoo(main+0xd4) [0x561559e3d734]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3) [0x7f464a7d60b3]
bin/quetoo(+0xa89a) [0x561559e3d89a]Sys_Signal: Received signal 6
AL lib: (EE) alc_cleanup: 1 device not closed

I'm not actually making a bug report here just thought it goes to show how Flatpak helps avoid such problems now.

FYI It can help with debuging if you jump into the container from the command line:

flatpak run --command=sh org.quetoo.Quetoo

All the usual BASH commands work there (e.g ls -a /). If you cat /.flatpak-info you can see it contains all kinds of potentially useful information but if you wanted to go whole hog you can actually detect a flatpak update is available and have Quetoo trigger the flatpak update. I think just detecting .flatpak-info and changing the update statement is enough really. Triggering flatpak self update would just be a flexing muscle level up! :grin:

BTW for those on Windows wishing to help test. You can download POP OS and run it in a VM (e.g Virtualbox) and you will be able to use it to install Quetoo straight from its software store. You could use Ubuntu but you will need to install flatpak and the built in software store does not show flatpak out of the box but installing Gnome Software will show it.

Thanks for doing this. It will make the game even more accessable to people on Linux distros.

[jdolan]

well as I expected on my laptop. I couldn't get any servers to join thougth as all list "Invalid response from [IP_ADDRESS]". Been a while since I tried a game so I don't know if thats typical?

All of the dedicated servers right now are running stale builds. I need to add some logic to prompt server operators to take updates, but also I think the folks running them (they are not my servers) have sort of moved on from the project. So this is expected, for the time being.

To compare I ran the update script from the normal install I had already lying around which itself ran fine but I could not game the game to launch. First it needed libjpeg62 so I installed that from the repository but it then just failed to launch with:

quetoo: r_mesh_draw.c:513: R_InitMeshProgram: Assertion `r_mesh_program.shell' failed.
Sys_Signal: Received signal 6
...
/lib/x86_64-linux-gnu/libc.so.6(+0x46210) [0x7f464a7f5210]
...
bin/quetoo(main+0xd4) [0x561559e3d734]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3) [0x7f464a7d60b3]
bin/quetoo(+0xa89a) [0x561559e3d89a]Sys_Signal: Received signal 6
AL lib: (EE) alc_cleanup: 1 device not closed

This is a good catch. @Paril made some changes to the mesh / shell effect quite recently, and we might be missing a shader here in our Makefile.am or something. Altho, in that case, I'm not sure how the Flatpak build works...

I'm not actually making a bug report here just thought it goes to show how Flatpak helps avoid such problems now.

FYI It can help with debuging if you jump into the container from the command line:

flatpak run --command=sh org.quetoo.Quetoo

All the usual BASH commands work there (e.g ls -a /). If you cat /.flatpak-info you can see it contains all kinds of potentially useful information but if you wanted to go whole hog you can actually detect a flatpak update is available and have Quetoo trigger the flatpak update. I think just detecting .flatpak-info and changing the update statement is enough really. Triggering flatpak self update would just be a flexing muscle level up! 😁

This is good to know!

BTW for those on Windows wishing to help test. You can download POP OS and run it in a VM (e.g Virtualbox) and you will be able to use it to install Quetoo straight from its software store. You could use Ubuntu but you will need to install flatpak and the built in software store does not show flatpak out of the box but installing Gnome Software will show it.

Thanks for doing this. It will make the game even more accessable to people on Linux distros.

Happy to get this working. I agree, this is by far the best move for Linux users we could make. I'm relieved to never have to think about Linux dependencies again. We'll keep the Linux build from http://ci.quetoo.org around in case it does work for anyone, and they prefer it. And it's also good for us to know that the Linux build itself is compiling. But Flatpak will be our preferred installation and update method for Linux going forward.

Once I add the logic for detecting Flatpak and avoiding launching the installer from within the game, I'll update the website accordingly, and direct users to Flathub.

[magicmyth]

We'll keep the Linux build from http://ci.quetoo.org around in case it does work for anyone

I think it totally makes sense to have a build outside of Flatpak keep going as it will help catch bugs that might get hidden in a flatpak environment causing issues down the line. Plus from time to time you'll want to update the runtime and being able to make sure it builds in general (even if just one distro like Debian) will likely mean you never have any issues switching to newer runtimes.

[jdolan]

The game will now detect Flatpak builds and prompt the user to update that way, instead of launching the installer (which is actually not present on Flatpak builds). The Downloads page has also been updated with a call-to-action link that takes Linux users to our Flathub page. We did it! Closing this one out...

[jdolan]

I should mention, the Flathub detection bits won't work until our next merge / snapshot release.