Requesting AppImage for Supertuxkart

[kskarthik]

Appimage helps packing apps which can run on all major Linux distributions. It's based on concept of one app = one file

Although you are providing a static binary, If supertuxkart can be packed along with all its dependencies inside an appimage, users can simply download give permission & run the file. Appimage also supports Delta updates

Popular apps like subsurface, scribus, krita also adopted this method to distribute their apps. It's easy to pack apps using AppImage. No extra knowledge required. It's easy for you since you have a static binary.

Project repo: https://github.com/probonopd/AppImagekit

The developer @probonopd is happy to help you packing your app :)

[qwertychouskie]

Why is this closed?

[qwertychouskie]

?

[probonopd]

@kskarthik that's a question for you

[qwertychouskie]

I just made an AppImage using https://sourceforge.net/projects/supertuxkart/files/SuperTuxKart/0.9.2/supertuxkart-0.9.2-linux.tar.xz/download, here is the file: https://jacobspctuneup.tk/SuperTuxKart

[qwertychouskie]

Hmm, the download seemed corrupted, just fixed it.

[qwertychouskie]

Oops, made a mistake, new version uploading...

[qwertychouskie]

OK, new version uploaded, same link.

[kskarthik]

Thanks for adopting appimage 😃

[probonopd]

I wouldn't call it "adopted" yet until it appears on the homepage and the official SourceForge download pages :-)

[qwertychouskie]

Also, the AppDir use to make it is here: https://jacobspctuneup.tk/SuperTuxKart.AppDir.7z
Could someone check and make sure I didn't do anything dumb? Also, tests of the AppImage on older systems, e.g. Ubuntu 14.04 and LM 17 would be appreciated.

[probonopd]

Have you ever tried to send a Pull Request to the upstream project @qwertychouskie?

[qwertychouskie]

@probonopd #2353 (comment)

[Vistaus]

I would also like to request an AppImage. My SSD is only 16 GB and I have no other internal storage, so I'd like to run SuperTuxKart from external storage and for that I need an AppImage (can't run Snaps/Flatpaks/etc. from external storage).

[probonopd]

@hiker @Benau would you be interested in a PR that packages the Travis CI build as an AppImage and uploads it to GitHub Releases?

[qwertychouskie]

Maybe not GitHub Releases on daily builds, but AppImages for daily builds uploaded to e.g. transfer.sh would be quite nice.

[probonopd]

Please reopen.

Work has started at
https://travis-ci.com/probonopd/stk-code/builds/94927432

I noticed the huge build matrix (16 different builds), using a lot of Travis CI capacity. Are we sure we need all those builds?

[probonopd]

AppImage built. However, it seems to be looking for its resources in paths other than what we get from make install:

[error  ] FileManager: Could not file 'supertuxkart.git' in any standard location (esp. ../data).
[error  ] FileManager: Last location checked '/usr/share/supertuxkart/data/'.
[fatal  ] FileManager: Set $SUPERTUXKART_DATADIR to point to the data directory.

Assume I have /some/random/mountpoint/AppDir/usr/bin/supertuxkart and /some/random/mountpoint/AppDir/usr/share/supertuxkart/data. Wouldn't that be a "standard location" that should be recognized?

[probonopd]

Looks like SuperTuxKart is searching for its resources in locations relative to the user's current working directory (cwd) rather than relative to the main binary. Could this be changed?

me@host:~/Downloads$ sudo strace ./SuperTuxKart-a3f72b7-x86_64.AppImage 2>&1 | grep data
access("data/supertuxkart.git", F_OK)   = -1 ENOENT (No such file or directory)
access("../data/supertuxkart.git", F_OK) = -1 ENOENT (No such file or directory)
access("../../data/supertuxkart.git", F_OK) = -1 ENOENT (No such file or directory)
access("./data/supertuxkart.git", F_OK) = -1 ENOENT (No such file or directory)
access("./../../../data/supertuxkart.git", F_OK) = -1 ENOENT (No such file or directory)
access("./../data/supertuxkart.git", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/share/supertuxkart/data/supertuxkart.git", F_OK) = -1 ENOENT (No such file or directory)
write(1, "\33[1;31m[error  ] FileManager: Co"..., 295[error  ] FileManager: Could not file 'supertuxkart.git'in any standard location (esp. ../data).
[error  ] FileManager: Last location checked '/usr/share/supertuxkart/data/'.
[fatal  ] FileManager: Set $SUPERTUXKART_DATADIR to point to the data directory.

[probonopd]

Even when working around this, I get:

me@host:~/Downloads/squashfs-root$ cd usr/

me@host:~/Downloads/squashfs-root/usr$ ln -s usr/share/supertuxkart/data/ .

me@host:~/Downloads/squashfs-root/usr$ ../AppRun 

[verbose  ] main: Error messages and other text output will be logged to /home/me/.config/supertuxkart/0.10-git/stdout.log.
[info   ] [FileManager]: Data files will be fetched from: '../data/'
[info   ] [FileManager]: User directory is '/home/me/.config/supertuxkart/0.10-git/'.
[info   ] [FileManager]: Addons files will be stored in '/home/me/.local/share/supertuxkart/addons/'.
[info   ] [FileManager]: Screenshots will be stored in '/home/me/.local/share/supertuxkart/screenshots/'.
[info   ] [FileManager]: User-defined grand prix will be stored in '/home/me/.local/share/supertuxkart/grandprix/'.
[info   ] [FileManager]: Asset 0 will be loaded from '../data/challenges/'.
[info   ] [FileManager]: Asset 1 will be loaded from '../data/gfx/'.
[info   ] [FileManager]: Asset 2 will be loaded from '../data/grandprix/'.
[info   ] [FileManager]: Asset 3 will be loaded from '../data/gui/icons/'.
[info   ] [FileManager]: Asset 4 will be loaded from '../data/gui/screens/'.
[info   ] [FileManager]: Asset 5 will be loaded from '../data/gui/dialogs/'.
[warn   ] [FileManager]: Directory 'library' not found, aborting.
[warn   ] [FileManager]: Directory 'models' not found, aborting.
[warn   ] [FileManager]: Directory 'music' not found, aborting.
[info   ] [FileManager]: Asset 9 will be loaded from '../data/replay/'.
[warn   ] [FileManager]: Directory 'tracks' not found, aborting.
[warn   ] [FileManager]: Directory 'sfx' not found, aborting.
[info   ] [FileManager]: Asset 12 will be loaded from '../data/shaders/'.
[info   ] [FileManager]: Asset 13 will be loaded from '../data/skins/'.
[warn   ] [FileManager]: Directory 'textures' not found, aborting.
[info   ] [FileManager]: Asset 15 will be loaded from '../data/ttf/'.
[info   ] [FileManager]: Asset 16 will be loaded from '../data/po/'.
[fatal  ] [FileManager]: Not all assets found - aborting.

[probonopd]

We don't seem to have those directories in the AppImage:

me@host:~/Downloads/squashfs-root$ find . | grep library
me@host:~/Downloads/squashfs-root$ find . | grep models
me@host:~/Downloads/squashfs-root$ find . | grep music

Where should they get installed, and how?

[probonopd]

https://github.com/supertuxkart/stk-code/tree/master/data contains much data, but not library, models, music, tracks, sfx, and textures. Where are they?

[probonopd]

Turns out one needs a svn (sic!) repo as well. Haven't seen those in years ;-)

[qwertychouskie]

Turns out one needs a svn (sic!) repo as well. Haven't seen those in years ;-)

Yeah, Git isn't well suited to large binary files (also GitHub has a repo size limit).

[hiker]

Sorry, didn't have time to look at this earlier. I admit I am not that familiar with the build process, so a few questions:

1. where are you uploading the binaries to? Are there limits to the size and download quota there?
2. Do you include all assets? Sometimes on git assets are tied to a certain code version, so we can't necessarily expect the users to have the right assets.
3. How is the build process controller? Will there an automatic one at a certain time of the day? Or each build process? Note that we atm are still working in a somewhat 'agile' environment ... meaning sometimes we have stuff on master that's not fully tested (we are going to change this soon).

TBH, I am not that much of a fan of daily releases, in particular because of 3) above, so I am not even sure if we would want to list daily builds on a web page (there is a certain security aspect - what if someone hacks an account of any user with write permission to github, pushes a commit with a trojan/virus, which then gets automatically built and pushed and published as official stk daily build :( Admittedly paranoid, and it could happen if someone just pushes a binary directly to SF, too - but at least that's only two or three admins who can push a binary to SF).

@deveee, @auriamg, @Benau, @Alayan-stk-2 - any other comments re appimage vs a static build?

Thanks!
Joerg

[probonopd]

where are you uploading the binaries to?

GitHub Releases. Currently to my cloned repo, but if you merge this then they would get uploaded to https://github.com/supertuxkart/stk-code/releases.

Are there limits to the size and download quota there?

According to https://help.github.com/articles/distributing-large-binaries/,

We don't limit the total size of your binary release files, nor the bandwidth used to deliver them. However, each individual file must be under 2 GB in size.

Do you include all assets?

Yes. The AppImage philosophy is centered around "one game = one file" simplicity and this mandates all resources to be bundled.

How is the build process controller?

https://github.com/supertuxkart/stk-code/blob/master/.travis.yml controls the builds (it does that already today!).

Will there an automatic one at a certain time of the day? Or each build process?

Like today, at every git commit a build will be triggered. You can decide whether you want to upload all builds or only tagged releases.

Note that we atm are still working in a somewhat 'agile' environment ... meaning sometimes we have stuff on master that's not fully tested (we are going to change this soon).

The suggested upload strategy is the following:

• For tagged releases, the AppImage will be attached to the tagged release source code on GitHub Releases. Those will not get deleted when a new version comes along
• For other builds, there will be one "continuous" build on GitHub Releases; it will be replaced by the newer continuous build if one comes along
• For pull requests, nothing will be uploaded to GitHub Releases; those will be uploaded to a temporary URL on transfer.io instead, where they are kept for 14 days

If you need something else, we can also customize the upload strategy.

I think that AppImage is a great way to test the continuous builds, since

• You are already building those builds anyway - so making an AppImage is can be seen as a nice "side effect"
• Being able to download the build artifacts of every build (include PRs) may help to increase testing velocity
• Thanks to AppImageUpdate binary delta updates, users can go from build to build by just downloading the (few) megabytes that have actually changed (think "diff for games") (example video)