Making an AppImage or Flatpak

[vpelss]

I am making an AppImage or Flatpak for easy distribution.

The only problem is that the code places temp files in the same path as the code which will not allow AppImage to work, but I 'might. be able to get Flatpak to work.

AppImage creates a read only tmp directory to run the program.
See:
/tmp/.mount_Space_PFfcwi/usr/bin/snis_launcher: 317: cannot create snis_client_log.txt: Read-only file system

If temp files (and snisb) could be written to maybe ~, then I could package this up and open it to a wider audience.

[smcameron]

Have you tried using environment variable SNIS_ASSET_DIR to make assets be read from someplace else?

See the FILES section of man page for snis_client, for example:

FILES
       $XDG_DATA_HOME/space-nerds-in-space  is a directory used to store vari‐
       ous user defaults.  If $XDG_DATA_HOME is not set, $HOME/.local/share is
       assumed. Old versions of snis_client would use ~/.space-nerds-in-space.
       See   https://specifications.freedesktop.org/basedir-spec/basedir-spec-
       latest.html

       $XDG_DATA_HOME/space-nerds-in-space/default_ship_name.txt   This   file
       preserves the ship name field between runs so that you do not  have  to
       re-type it each time in the login screen.

       $XDG_DATA_HOME/space-nerds-in-space/role_defaults.txt  This  file  pre‐
       serves the selected roles between runs so that you do not have to  fill
       in the checkboxes each time in the login screen.

       $XDG_DATA_HOME/space-nerds-in-space/snis_ui_position_offsets.txt   This
       file preserves positions of UI elements if  the  user  moves  them  and
       saves them.

       $SNIS_ASSET_DIR/sounds/*.ogg, various audio files used by the game.

       $SNIS_ASSET_DIR/models/*.stl, various 3D models used by the game.

       $SNIS_ASSET_DIR/solarsystems/*/assets.txt, per-solarsystem art assets.

       $SNIS_ASSET_DIR/replacement_assets.txt  This file allows replacement of
       standard assets with other assets. The line of the  file  contains  two
       filenames,  separated  by any combination of spaces and tabs. The first
       filename is the original  asset  file  name,  e.g.,  "./share/snis/mod‐
       els/cruiser.stl",  and  the  second  file name is the replacement asset
       file. e.g., "./share/snis/models/my_fancy_model.obj".  Comments  begin‐
       ning  with '#' and blank lines are permitted.  Currently this asset re‐
       placement system only works for textures, ship models and sounds.  Note
       the  replacement  models should be similarly scaled and oriented as the
       original models. Normally the orientation should be such that the posi‐
       tive  X axis if forward and the positive Y axis is up.  Some models may
       deviate from this (e.g.  snis3006.obj) and have some  compensation  ap‐
       plied  via ship_types.txt.  Replacement models should have the same de‐
       viation in orientation.  Note: likely this system  does  not  yet  work
       well when SNIS_ASSET_DIR has a value that deviates from
...

[smcameron]

read only tmp directory

SNIS does need to write to disk for some things, mainly the little "database" it uses to keep track of a ship's state when jumping from one "solar system" (snis_server process) to another.

[smcameron]

/tmp/.mount_Space_PFfcwi/usr/bin/snis_launcher: 317: cannot create snis_client_log.txt: Read-only file system

Hmm, yeah SNIS_ASSET_DIR won't help with that.

TBH, if you can't compile the game yourself, you probably won't like it anyway, so not too keen on binary distributions anyway, just lets the horde of whiners in.

[smcameron]

Just committed:

a1b6cab Make snis_launcher put log files where you want them

Try this:

export SNIS_LOG_DIR=/tmp/snis_log_dir
mkdir $SNIS_LOG_DIR
snis_launcher

I would not be too surprised if there are other files that it tries to write though.

[vpelss]

Thank you very much.
Bingo. The following did the trick.

export SNIS_LOG_DIR=/tmp/snis_log_dir
mkdir $SNIS_LOG_DIR

I have been testing making an AppImage using WSL on windows. Now over to linux to give it a full test. WSL is not working with sound.

I am not sure it would be accurate to say that those who can't compile it would not appreciate it.
I think this is an amazing achievement. The only free 3d space bridge that I know of, and seems very functional.
I like the vector graphic art style.
Very ambitious.
Well done!

I am not hopeful on building a flatpak as I believe that all dependencies have to seamlessly download and compile also. And there seem to be a few dependencies.

If I get a AppImage build working with github actions, I will let you know.

[smcameron]

Alright, cool.

[smcameron]

One more small update to this:

40f2d62 snis_launcher: guard against non-existent or unwritable SNIS_LOG_DIR

[vpelss]

Thanks. With all the dependencies I have had a time to make an appimage. I have a build and instructions: https://github.com/vpelss/Space-Nerds-In-Space-Appimage/releases/tag/Newest I had to build on a newer ubuntu, so mileage may vary on different distros. I tested on Zorn distro, as that is all I had handy. I have asked an unreliable friend to test on one of their linux distros. So I will see how it fairs there. It might be more stable to try and build in a flatpak. Although I foresee a lot of hiccups. We will see :) Thanks again!

…

On Wed, Dec 18, 2024 at 7:20 PM smcameron ***@***.***> wrote: One more small update to this: 40f2d62 <40f2d62> snis_launcher: guard against non-existent or unwritable SNIS_LOG_DIR — Reply to this email directly, view it on GitHub <#362 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACMU44L3IWBJPNINLFYHN2D2GIGMVAVCNFSM6AAAAABT3DJUYGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNRRGE2TAMQ> . You are receiving this because you authored the thread.Message ID: <smcameron/space-nerds-in-space/repo-discussions/362/comments/11611502@ github.com>

[smcameron]

Thanks. Mentioned it here https://old.reddit.com/r/SNIS/comments/1hjxbw0/snis_appimage/ and here https://www.patreon.com/posts/space-nerds-in-118468188

[vpelss]

Tested successfully on:

q4OS
mint cinnamon
mint xfce
MiniOS

I am still trying a flatpack (off and on), but there are many hurdles. Flatpak insists that flatpak-builder is the only way to build packages from source. So for example, opus, the code in the makefile will not work as inside flatpak-builder, it won't let the make environment download anything from the internet. So for each dependency I have to try and find a flatpak friendly code base, and figure out a way to build it in flatpak builder. I believe flatpak is doing all this so they can validate the code in the flatpak, but it is a slog IMO.

[smcameron]

Alright, let me work on the opus situation. You can build without it (and without voice chat functionality,) which is completely fine if you're playing locally, as is meant to be the case ... the voice chat was added during covid lockdown to try to enable over the internet play, but I don't know if anyone's really ever used it in anger, or how well it really works. I've done some minimal testing and it seems to work reasonably well with two users, one in Ohio and one (me) in Virginia, and the snis_server in New York, but I can't really say I've stress tested the voice functionality.

To turn off the voice chat functionality, at the top of the Makefile, change "WITHVOICECHAT=yes" to "WITHVOICECHAT=no" (or to anything but yes). I think that will also prevent it from trying to download opus, as it should no longer be a dependency.

[smcameron]

Does this patch help? It should allow you to pre-download opus to whatever location, then build via, e.g.:

make PREFETCHED_OPUS=../../opus-1.3.1.tar.gz

so it won't try to use wget to fetch it from mozilla.org.

It also occurs to me that the "make update-assets" target runs util/snis_update_assets.sh which makes extensive use of wget to fetch loads of art assets from my digital ocean server. You'll have to find a way around that too, I imagine. (Actually, you don't have to update the assets, the default assets should work, they just don't necessarily look very good.)

[smcameron]

Oops, I forgot to upload the patch in my last comment, here it is:
allow-compiling-opus-without-downloading.patch.txt

[vpelss]

Sorry, I wasn't asking for any changes yet. I have forked your SNIS so I can modify makefile to test. I guess I should have stated that.

Depending on other hurdles, flatpak may or maynot fly.

Thanks though!
If I can take out opus, that is one less thing to worry about.
But I do like the voice chat idea though.

I imagine one of the reason bridge sims have low usage is that it is really hard to get a crew together and even harder to get them together at the same time.

IF you find that the AppImage works in most cases you can copy my yaml file and build it yourself on your github. That way there is more trust for people downloading it.

[vpelss]

I am starting to hate flatpak more than I did before :)
I 'think' flatpak-builder is seeing the following comment in glew.h
# include <GL/glu.h>
as
#include <GL/glu.h>
giving me compilation errors.

I had some really odd flatpak errors with a trailing space in a yaml file a few months back.

To test and fix this I will have to probably have to fork the glew-cmake version I am using and remove those lines.

[smcameron]

Are you sure that's a comment?

#      include <whatever.h>

is, so far as I know, valid C, and it means the same as

#include <whatever.h>

Only the '#' has to be in the first column. You can indent ifdefs this way:

 # ifdef A
 #     ifdef B
 /*   do something */
 #     endif
 # endif

From the GNU C Preprocessor https://debrouxl.github.io/gcc4ti/cpp.html

Except for expansion of predefined macros, all these operations are triggered with preprocessing directives. Preprocessing directives are lines in your program that start with #. Whitespace is allowed before and after the #. The # is followed by an identifier, the directive name.

Hmm, according to that, the '#' doesn't even need to be in the first column.

If you're talking about this:

 1201 #ifndef GLEW_NO_GLU
 1202 /* this is where we can safely include GLU */
 1203 #  if defined(__APPLE__) && defined(__MACH__)
 1204 #    include <OpenGL/glu.h>
 1205 #  else
 1206 #    include <GL/glu.h>
 1207 #  endif
 1208 #endif

Yeah, those definitely aren't comments.

[vpelss]

You are 100% correct.
What I don't know about C is vast.

So the current road block I am working on is when I compile with flatpak, I get:

/app/include/GL/glew.h:1215:14: fatal error: GL/glu.h: No such file or directory
 1215 | #    include <GL/glu.h>

I see in the makefile for glew.h that:

#ifndef GLEW_NO_GLU
/* this is where we can safely include GLU */
#  if defined(__APPLE__) && defined(__MACH__)
#    include <OpenGL/glu.h>
#  else
#    include <GL/glu.h>
#  endif
#endif

As far as I can see
the cmake file states:

option(USE_GLU "Use GLU" OFF)
...
if(NOT USE_GLU)
	list(APPEND DEFINITIONS -DGLEW_NO_GLU)

so I don't think it should be looking for GL/glu.h

I am not sure how it is triggering.

In a log from a plain and successful build of snis, I get:

object_files/joystick_config.o object_files/snis_xwindows_hacks.o object_files/png_utils.o -lSDL2 -Lssgl -lssglclient -ldl -lm -lpng16 -lz -lGLEW -lGL -lX11 -lGLU -lportaudio -lasound -lm -lpthread -lvorbisfile  -L. -lopus -lX11
  LINK bin/snis_client

My question is where is -lGLU coming from, and is this the cause? I can't seem to find where it is being added.

[smcameron]

Hmm, I'm not a big fan of CMake as there's too much black magic, but you might try this black magic I found:

target_compile_definitions(your_target PRIVATE GLEW_NO_GLU)

edit: actually no, you want it undefined, hmm... Oh wait no you do want it defined! Too many double negatives, heh.

[vpelss]

It's all black magic!

The -lGLU is coming from your make file in a normal build. Not cmake.

Could that be causing a search for GL/glu.h ?

If so, where is it being generated from?

I will continue my search another day.
I am out of juice.

[smcameron]

Added this to https://spacenerdsinspace.com

• 11a1d86 Add links to vpelss flatpak and appimage

[vpelss]

I have never submitted any flatpaks to flathub.com

I detest the bureaucracy.

That being said:

1. Do you want SNIS to show up there?

2. Did you want to submit it (so it's under your control), or can I submit?

[smcameron]

Here's the part where I confess I don't know a damn thing about flatpaks, lol. This was your idea, you can do whatever you think is best.

[smcameron]

Ok, watched a few youtube videos, read a bit. Let me think about it some. I am kind of thinking that perhaps it would be best if it were under my control, since, if there are bug reports and whatnot, I'd likely be on the receiving end of those, so it might be a good idea if I knew something about what was going on, and while I've been working on SNIS for a decade or so, and am unlikely to abandon it, you may not wish to commit to maintaining and updating some package for years and years and years and may want to wander off and work on other stuff instead at some point, which is 100% understandable (and probably predictable), so I don't want to rope you into such a commitment.

So let me do some research and think about it some.

[smcameron]

it would be best if it were under my control

but I am realizing I don't know shit about flatpak, so, "best" may not be attainable, heh.

I think I'm back to "do whatever you think is best" on the flatpak issue.

[vpelss]

It is daunting. There is 'good' documentation. But it assumes you know everything about flatpak's supporting infrastructure and you have done it all before :)

I usually work with bubble gum and duct tape, so I just know the bare minimum.

I will 'try' my first flathub submission (flatpak's app directory) with snis.

I will need to rename all my org.flathub.snis to io.github.vpelss.snis_flatpak

We will also need a version number you are happy with, following normal conventions. No rush. This will take some time!
https://en.wikipedia.org/wiki/Software_versioning

If you change your mind later, just copy all my stuff and change io.github.vpelss.snis_flatpak to io.github.scameron.snis and submit.

[smcameron]

Yeah, up to now, I have not really tagged or versioned anything, I always develop on a branch, and the idea has been any commit at all that you care to pick on master should be working (to enable git bisect to work, and because my method of "releasing" it has always just been to tell people to "git clone" it if they want it, and "git pull" to get updates). I won't say that there are zero commits on master that are broken, but it's not far from zero. The closest thing I currently have to a version is the "v 0.1" plus git commit hash that you see if you go on COMMS and type "/about".

But yeah, I gathered that I'd need to do some kind of a versioned release for flatpak.

[smcameron]

A few commits related to version numbers:

b5ef127 snis: bump version number to 1.0.0
e13c9d9 snis_server: make --version flag be more like snis_client and snis_multiverse
621a819 snis_multiverse: add --version flag
1690404 snis_client: make --version flag exit program
8c69d5e snis_version.h: fix broken ifdef guard

Also, I made a release: https://github.com/smcameron/space-nerds-in-space/releases/tag/v1.0.0

[vpelss]

FYI

I no longer rely on a modified copy of your Makefile.

I was unaware that the following would clobber internal values. I am assuming I am doing that correctly. Well it works.
make WITHVOICECHAT=no -e LUALIBS=-llua

So now there should be less package build issues on my side when you do Makefile updates.

I spent a day, trying to hunt down an elusive bug on updating to flatpak runtime from org.freedesktop.Platform 23.08 to 24.08
LUA compiles and links as it did before, but when I run snis_client it states it can't find the library...
I still am not sure how to correct it, so back to 23.08.

[vpelss]

Can you confirm that you want me to create a flatpak of SNIS in this thread.

Flathub team want to see it in github writing.

I will link them to this thread.

[smcameron]

Sure. I confirm that I have no problem with vpelss creating a flatpak of space-nerds-in-space.

-- steve

[smcameron]

Hey, I came across this ... https://discourse.flathub.org/t/manifest-multiple-sources-in-one-module/8908 and noticed this ...

Well, your second repository contains mostly data files (icon, desktop

file, metainfo). Normally, these data files should be part of the main repo, as these files are relevant on Linux no matter how the app is distributed and therefore should be managed upstream together with the app. Well, I'm not familiar with exactly what we're talking about, but things like "icon, desktop file, metainfo", seem alright. I'm not sure where they would go, and am largely unfamiliar with how they are "relevant on Linux no matter ... ", but that's likely just my own ignorance. There's always the Contrib directory, if that would help. https://github.com/smcameron/space-nerds-in-space/tree/master/Contrib

…

-- steve

On Fri, Feb 14, 2025 at 3:25 PM Vince Pelss ***@***.***> wrote: Can you confirm that you want me to create a flatpak of SNIS in this thread. Flathub team want to see it in github writing. I will link them to this thread. — Reply to this email directly, view it on GitHub <#362 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAF22B6PZGTLKPRF5DBGAL2PZGNNAVCNFSM6AAAAABT3DJUYGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEMRQGUZDIOI> . You are receiving this because you commented.Message ID: <smcameron/space-nerds-in-space/repo-discussions/362/comments/12205249@ github.com>

[smcameron]

Also, as for "desktop file" maybe I already have one: https://github.com/smcameron/space-nerds-in-space/blob/master/snis.desktop

…

-- steve On Sat, Feb 15, 2025 at 12:01 AM Stephen Cameron ***@***.***> wrote:

Hey, I came across this ... https://discourse.flathub.org/t/manifest-multiple-sources-in-one-module/8908 and noticed this ... > Well, your second repository contains mostly data files (icon, desktop file, metainfo). Normally, these data files should be part of the main repo, as these files are relevant on Linux no matter how the app is distributed and therefore should be managed upstream together with the app. Well, I'm not familiar with exactly what we're talking about, but things like "icon, desktop file, metainfo", seem alright. I'm not sure where they would go, and am largely unfamiliar with how they are "relevant on Linux no matter ... ", but that's likely just my own ignorance. There's always the Contrib directory, if that would help. https://github.com/smcameron/space-nerds-in-space/tree/master/Contrib -- steve On Fri, Feb 14, 2025 at 3:25 PM Vince Pelss ***@***.***> wrote: > Can you confirm that you want me to create a flatpak of SNIS in this > thread. > > Flathub team want to see it in github writing. > > I will link them to this thread. > > — > Reply to this email directly, view it on GitHub > <#362 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAAF22B6PZGTLKPRF5DBGAL2PZGNNAVCNFSM6AAAAABT3DJUYGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEMRQGUZDIOI> > . > You are receiving this because you commented.Message ID: > <smcameron/space-nerds-in-space/repo-discussions/362/comments/12205249@ > github.com> >

[smcameron]

Though I noticed that my snis.desktop file uses the utilities-system-monitor icon, which seems pretty bogus.

…

-- steve On Sat, Feb 15, 2025 at 12:07 AM Stephen Cameron ***@***.***> wrote:

Also, as for "desktop file" maybe I already have one: https://github.com/smcameron/space-nerds-in-space/blob/master/snis.desktop -- steve On Sat, Feb 15, 2025 at 12:01 AM Stephen Cameron < ***@***.***> wrote: > Hey, I came across this ... > > > https://discourse.flathub.org/t/manifest-multiple-sources-in-one-module/8908 > > and noticed this ... > > > Well, your second repository contains mostly data files (icon, desktop > file, metainfo). Normally, these data files should be part of the main > repo, as these files are relevant on Linux no matter how the app is > distributed and therefore should be managed upstream together with the app. > > Well, I'm not familiar with exactly what we're talking about, but things > like "icon, desktop file, metainfo", seem alright. I'm not sure where they > would go, and am largely unfamiliar with how they are "relevant on Linux no > matter ... ", but that's likely just my own ignorance. > > There's always the Contrib directory, if that would help. > https://github.com/smcameron/space-nerds-in-space/tree/master/Contrib > > -- steve > > > On Fri, Feb 14, 2025 at 3:25 PM Vince Pelss ***@***.***> > wrote: > >> Can you confirm that you want me to create a flatpak of SNIS in this >> thread. >> >> Flathub team want to see it in github writing. >> >> I will link them to this thread. >> >> — >> Reply to this email directly, view it on GitHub >> <#362 (comment)>, >> or unsubscribe >> <https://github.com/notifications/unsubscribe-auth/AAAF22B6PZGTLKPRF5DBGAL2PZGNNAVCNFSM6AAAAABT3DJUYGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEMRQGUZDIOI> >> . >> You are receiving this because you commented.Message ID: >> <smcameron/space-nerds-in-space/repo-discussions/362/comments/12205249@ >> github.com> >> >

[vpelss]

We could put them on your site.

If you do, they are here.
https://github.com/vpelss/snis_flatpak
Meta,desktop, and icon are all that are required.

If they need to be changed then you need to update, or I send changes.

Maybe wait and see what they come back with?
If we change now, I need to update the flatpak manifest, and it is working now.

Currently everything is working. It has been for a while. They just seem very focused on what I would consider the small stuff.
Lagging spaces, having 3 flatpak modules vs 1, using shared modules listed on flathub vs building a module from source etc. Very cosmetic stuff.

Someone stated that I could also put icons and desktop in my flathub git pull submission. That surprises me, and I am confident that they only approve that in rare cases.

I think there is less bureaucracy in government....

[smcameron]

Eh, I can kind of see where they are coming from. They have a way of doing things, and if they let everyone sort of do their own thing their own way all the time, then it becomes the case that it's hard to find good examples to go by, easy to accidentally follow bad examples, hard to debug because everybody's doing different things, etc. A foolish consistency may be the hobgoblin of little minds, but not all consistency is foolish.

I'll let you drive on this how you see fit, but if it's standard practice to do things a certain way, and we're doing them some other way for no real reason other than the convenience of not changing it from what we already have now, well... that's not ideal. But I'll leave it to you.

[smcameron]

Since both flatpak and appimages now exist, I suppose we can close this discussion.

• https://flathub.org/apps/io.github.smcameron.space-nerds-in-space
• https://www.appimagehub.com/p/2261862

Feel free to re-open if need be.