I packaged the game as a flatpak

[Wildeblood]

So it looks for an AddOns dir next to the .app dir?

Yes.

[sharpenedblade]

Can pr#515 be merged soon, the last blocker for the flathub package is the appstream metadata. Once the metadata is upstream the pr can be tested according to the flathub merge process.

[another_commander]

I haven't merged it because I have no say on the Linux builds nor way to confirm the functionality of the PR. Would appreciate one of the Linux guys with access to the project on github making the decision to press the merge button, provided they are good with the contents of the PR.

[MrFlibble]

#515 looks mostly good to me.

Does the 'requires' section need 'display length', and if so, should the (presumably minimum) be as high as 768.

[sharpenedblade]

I haven't merged it because I have no say on the Linux builds nor way to confirm the functionality of the PR

#515 is just metadata for gui software apps, the actual build artifact is in #516.

Does the 'requires' section need 'display length', and if so, should the (presumably minimum) be as high as 768.

768 is what the flatpak docs say to use for desktop only apps. Flatpak doesn't strictly enforce the display length tag so desktops/laptops with smaller screens will still work. The tag actually means that it should not show up as a mobile app. https://docs.flathub.org/docs/for-app-a ... -only-apps

[MrFlibble]

I haven't merged it because I have no say on the Linux builds nor way to confirm the functionality of the PR

#515 is just metadata for gui software apps, the actual build artifact is in #516.

Does the 'requires' section need 'display length', and if so, should the (presumably minimum) be as high as 768.

768 is what the flatpak docs say to use for desktop only apps. Flatpak doesn't strictly enforce the display length tag so desktops/laptops with smaller screens will still work. The tag actually means that it should not show up as a mobile app. https://docs.flathub.org/docs/for-app-a ... -only-apps

Thanks for the clarification.

Do mobile devices need excluding? Surely a mobile device/tablet with e.g. a Bluetooth keyboard would be fine.

[sharpenedblade]

Do mobile devices need excluding? Surely a mobile device/tablet with e.g. a Bluetooth keyboard would be fine.

The examples in the flathub docs add touch support for all mobile/tablet apps. Mobile flatpak can still install "desktop" apps, they just are not in the mobile section of flathub (edit: actually it will just give you a warning about compatibility, then install it like normal), so if someone does have a keyboard and wants to install the flatpak they still can.

[MrFlibble]

Do mobile devices need excluding? Surely a mobile device/tablet with e.g. a Bluetooth keyboard would be fine.

The examples in the flathub docs add touch support for all mobile/tablet apps. Mobile flatpak can still install "desktop" apps, they just are not in the mobile section of flathub (edit: actually it will just give you a warning about compatibility, then install it like normal), so if someone does have a keyboard and wants to install the flatpak they still can.

Sweet!

[hiran]

I haven't merged it because I have no say on the Linux builds nor way to confirm the functionality of the PR. Would appreciate one of the Linux guys with access to the project on github making the decision to press the merge button, provided they are good with the contents of the PR.

Difficult to tell what it does. It adds another build job to the workflow that seems completely independend from everything that is in place already. So I'm wondering how the version calculation would be done, or how the up to date documentation goes in there.

Also there is no build artifact to be inspected.

[hiran]

I haven't merged it because I have no say on the Linux builds nor way to confirm the functionality of the PR. Would appreciate one of the Linux guys with access to the project on github making the decision to press the merge button, provided they are good with the contents of the PR.

Difficult to tell what it does. It adds another build job to the workflow that seems completely independend from everything that is in place already. So I'm wondering how the version calculation would be done, or how the up to date documentation goes in there.

Also there is no build artifact to be inspected.

So I went to the source of the PR: https://github.com/sharpenedblade/oolite and checked the Actions tab.
The branch sharpenedblade:add-flatpak-ci has never finished successfully. That would explain why there is no build artifact to look at.

I would not go for a merge at this point.

[sharpenedblade]

I made the build job depend on the common-steps job now. The flatpak does not bundle docs because the only place they can go is the flatpak install dir, which is not meant to be accessed by users. I am still working on getting the version info to show up though.

The CI was failing because the git checkout failed because the .gitmodules file used relative URLs, I pushed a commit to temporarily fix that but it needs to be reverted before merging. The CI build-flatpak job passed and uploaded an artifact, but the windows build is failing for some reason. I didn't touch anything that could affect windows so I'm not sure whats happening.

[Cholmondely]

It is a great shame that creating new versions of Oolite is such a pain in the unmentionables for both the AppleMac and Linux.

I know that other games have issues with the AppleMac. But is that also true for Linux?

And, why is Windows so easy?

[sharpenedblade]

It is a great shame that creating new versions of Oolite is such a pain in the unmentionables for both the AppleMac and Linux.

GNUstep is basically legacy technology now, and oolite doesn't even work with modern GNUstep and needs an older release to compile. Oolite also has some other legacy dependencies that are shipped as pre compiled object files which makes things weird.

I know that other games have issues with the AppleMac. But is that also true for Linux?

Most modern game engines/libraries are one click to compile for Linux. Packaging on linux is kind of a mess, but its not really a problem for games since they are usually shipped with something like steam that takes care of managing updates. By running in a flatpak (either directly or by being run by a flatpaked app store), host library versions don't even matter that much anymore. And even for games that don't compile on linux, wine is really good and runs almost every game that doesn't explicitly try to block it.

[sharpenedblade]

I rebased the flatpak onto master, it crashes at startup or soon after with this error:

Code: Select all

oolite: Uncaught exception NSInternalInconsistencyException, reason: src/Core/OOWeakSet.m:168  Assertion failed in OOWeakSet(instance), method addObject:.  Attempt to add object to OOWeakSet which does not conform to OOWeakReferenceSupport.

Sometimes the error is a segfault with this backtrace. I can reliably trigger this error by shooting at something (but shooting into empty space works fine):

Code: Select all

#0  0x00005593507d3640 in js_ReportErrorNumberVA(JSContext*, unsigned int, JSErrorFormatString const* (*)(void*, char const*, unsigned int), void*, unsigned int, int, __va_list_tag*) ()
[Current thread is 1 (Thread 0x7fbd937cee00 (LWP 2))]
(gdb) bt\

#0  0x00005593507d3640 in js_ReportErrorNumberVA(JSContext*, unsigned int, JSErrorFormatString const* (*)(void*, char const*, unsigned int), void*, unsigned int, int, __va_list_tag*) ()
#1  0x00005593507a8db9 in JS_ReportErrorNumber ()
#2  0x0000559350829bce in js::ExternalInvoke(JSContext*, js::Value const&, js::Value const&, unsigned int, js::Value*, js::Value*) ()
#3  0x00005593507b1d11 in JS_CallFunctionValue ()
#4  0x00005593506ad349 in -[OOJavaScriptEngine callJSFunction:forObject:argc:argv:result:]
    (self=<optimized out>, _cmd=<optimized out>, function=18445617886793514608, jsThis=0x7fbd2ce48288, argc=0, argv=0x0, outResult=0x7ffe60811a80) at src/Core/Scripting/OOJavaScriptEngine.m:503
#5  0x00005593506f368f in -[OOJSTimer timerFired] (self=0x55936663b2f0, _cmd=<optimized out>) at src/Core/Scripting/OOJSTimer.m:180
#6  0x00005593506fec6f in +[OOScriptTimer updateTimers] (self=<optimized out>, _cmd=<optimized out>)
    at src/Core/Scripting/OOScriptTimer.m:180
#7  0x0000559350542a8c in -[PlayerEntity update:] (self=0x559359583040, _cmd=<optimized out>, delta_t=0.016795039176940918)
    at src/Core/Entities/PlayerEntity.m:2637
#8  0x000055935079df98 in -[Universe update:] (self=<optimized out>, _cmd=<optimized out>, inDeltaT=<optimized out>)
    at src/Core/Universe.m:7227
#9  0x000055935075230c in -[GameController doPerformGameTick] (self=0x559358a339e0, _cmd=<optimized out>) at src/Core/Universe.h:838
#10 0x0000559350751431 in -[GameController performGameTick:] (self=<optimized out>, _cmd=<optimized out>, sender=<optimized out>)
    at src/Core/GameController.m:329
#11 0x00007fbd94763c39 in -[NSTimer fire] (self=0x55935b1a1c70, _cmd=<optimized out>) at NSTimer.m:326
#12 0x00007fbd9472d288 in -[NSRunLoop _limitDateForContext:] (self=0x559357d68760, _cmd=<optimized out>, context=0x559357beec70)
    at NSRunLoop.m:1041
#13 0x00007fbd9472a9b8 in -[NSRunLoop limitDateForMode:]
    (self=0x559357d68760, _cmd=0x7fbd949f9360 <_OBJC_SELECTOR_TABLE+1216>, mode=0x7fbd949fa170 <_OBJC_INSTANCE_2>) at NSRunLoop.m:1141
#14 0x00007fbd9472ab47 in -[NSRunLoop runMode:beforeDate:]
    (self=0x559357d68760, _cmd=<optimized out>, mode=0x7fbd949fa170 <_OBJC_INSTANCE_2>, date=0x559357d72a10) at NSRunLoop.m:1315
#15 0x00007fbd94728e2d in -[NSRunLoop runUntilDate:] (self=0x559357d68760, _cmd=<optimized out>, date=0x559357d72a10)
    at NSRunLoop.m:1364
#16 0x0000559350757ced in main (argc=1, argv=0x7ffe60812b38) at src/SDL/main.m:183

[Lone_Wolf]

GNUstep is basically legacy technology now, and oolite doesn't even work with modern GNUstep and needs an older release to compile.

On archlinux oolite trunk only needs minor adjustements to build and run .
This is with gnustep-base 1.31.1 , gnustep-make 2.9.3 and gcc 15.1 .

All of those were released this year.

espeak & libpng14 are the only legacy deps needed, all other deps are on recent versions provided by archlinux repos.