Oolite Bulletins

I think adding this somewhere in the flatpak build process should make things work

sharpenedblade wrote: ↑Fri Jan 09, 2026 6:19 am

I think adding this somewhere in the flatpak build process should make things work

Code: Select all

sed -i 's/Exec=oolite/Exec=run_oolite.sh/' installers/FreeDesktop/oolite.desktop

Thanks for checking. I will check the desktop file.

sharpenedblade wrote: ↑Fri Jan 09, 2026 6:19 am

I think adding this somewhere in the flatpak build process should make things work

Code: Select all

sed -i 's/Exec=oolite/Exec=run_oolite.sh/' installers/FreeDesktop/oolite.desktop

Please can you try the version here by uninstalling any existing Oolite flatpak, manually deleting any Oolite .desktop file that remains in ~/.local/share/applications/ and then installing.

I see run --branch=master --arch=x86_64 --command=run_oolite.sh space.oolite.Oolite in the desktop file that gets created when I install from the flatpak.

The latest release is working now.

sharpenedblade wrote: ↑Sat Jan 10, 2026 1:42 am

The latest release is working now.

Thanks. I have made a PR: https://github.com/OoliteProject/oolite/pull/537

PR merged.

After merging the modern Windows build PR the flatpak was created but not included in the final pre-release. @mcarans, could you please take a look at this?

The release job doesn't depend on the build-flatpak job. The new Windows build is now faster, and so I think the release job is starting and attempting to download the flatpak artifact before it's been built and uploaded. Previously it just luckily happened to be available because the build-flatpak job had finished first.

Excellent observation, thanks. It is now building again and let's see in a few minutes how it goes...

... and it worked. Nice!

The FlatHub release required some changes which I implemented, but the last exchange with FlatHub's reviewer doesn't sound positive: https://github.com/flathub/flathub/pull/7759

The reviewer observed the x86_64 requirement and asked "why?"

I said "The game only builds on x86_64 not on aarch64. It is not possible to get it to work on ARM whether on Windows or Linux. The JavaScript library used by the game to support expansions cannot be rebuilt for ARM."

The reviewer said: "it's 2026"

I replied: "The JavaScript library is an old Mozilla engine that precedes the existence of modern ARM based architectures. It still requires Python 2 to get some of it to build. We would like to upgrade it, but it is a huge project to do it and ensure that hundreds of existing expansions still work with no guarantee that it's even possible.

I've only been working on the game since mid last year in my spare time. I wanted to get the Linux build working again as it had ceased working several years ago and bring the major GNUStep Objective-C dependency up to date, switching from gcc to Clang to support modern Objective-C and replacing espeak with espeak-ng etc. The only working build was Windows, but even that was using an old version of gcc and very old libraries that needed to be updated too. Since we're talking about a volunteer project not a commercial game, resources are very limited. In future, I'd also like to upgrade SDL from 1.2 to 3 to allow new features.

The game was originally written on Mac but stopped working when the Mac architecture changed in 2020. Supporting Mac again is something we would also like to do in future.

We hope that with more visibility for the game more people will contribute to it and so aid in achieving these goals.

Is it a requirement for FlatHub that ARM is supported?"

I haven't heard anything since.

As long as the PR remains open there is hope.

Fwiw, I have been following the progress of your PR and in my opinion the reviewer is being a bit obnoxious for no reason at all. Once the test build has succeeded and been confirmed as functional, there is really no point in continuing to nit-pick on things like ARM support. I have not read anywhere that ARM support is a flathub requirement either but it could be that I am missing something as well, my Linux and flathub ken is very restricted. Haven't seen any similar reviewer comments on other flathub applications either.

another_commander wrote: ↑Sat Feb 14, 2026 8:57 am

As long as the PR remains open there is hope.

Fwiw, I have been following the progress of your PR and in my opinion the reviewer is being a bit obnoxious for no reason at all. Once the test build has succeeded and been confirmed as functional, there is really no point in continuing to nit-pick on things like ARM support. I have not read anywhere that ARM support is a flathub requirement either but it could be that I am missing something as well, my Linux and flathub ken is very restricted. Haven't seen any similar reviewer comments on other flathub applications either.

They continue to give feedback so I suppose all is not lost. The latest is "there is no licence file in the root of the repo. Do you have it?" They are certainly thorough.

I have copied https://github.com/OoliteProject/oolite ... license.md to the root of the 1.92-maintenance branch. There is a doc/LICENSE.txt already. The only relevant mentions I could see are in tools/mkmanifest.sh and tools/mktarballs. The former I changed to mention LICENSE.md instead of LICENSE.txt. Is mktarballs used anywhere or is it old? I think it would be better not to have multiple copies of the licence, so want to delete doc/LICENSE.txt if possible.

Are you ok to put license.md in the root of the master branch, reference it in mkmanifest.sh and similarly delete the doc/LICENSE.txt in that branch? I would also change the readthedocs to use the root one in due course deleting https://github.com/OoliteProject/oolite ... license.md.

Feel free to do what you think is necessary to sort out the license issue in both 1.92-maintenance and master.

As for the mktarballs file, mo idea what it was used for or when it was last used.

Bot

another_commander wrote: ↑Sun Feb 15, 2026 10:27 am

As for the mktarballs file, mo idea what it was used for or when it was last used.

It's mentioned in Doc/PORTING.TXT which was last changed in 2012.

The text in mktarballs indicates it uses Autopackage .
It's like a (not very succesfull) very early predecessor of flatpak/appimage .

another_commander wrote: ↑Sun Feb 15, 2026 10:27 am

Feel free to do what you think is necessary to sort out the license issue in both 1.92-maintenance and master.

As for the mktarballs file, mo idea what it was used for or when it was last used.

I made a PR for master with changes: https://github.com/OoliteProject/oolite/pull/551