New Linux AppImage and source builds to test

[MrFlibble]

[...]
Here is a download link if you want to test: https://www.filemail.com/d/rqboegjegmaysyy. If you do, please let me know what version of Linux you use.

Sigh (expected):

Code: Select all

$ ./Oolite_1.91.0.7781-251216-47a0cfb-x86_64.AppImage 
./Oolite_1.91.0.7781-251216-47a0cfb-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by ./Oolite_1.91.0.7781-251216-47a0cfb-x86_64.AppImage)

This is on Slackware 15.0 (glibc still 2.33)

There's a reason I'm using "me own" build

I expect it's down to the age of the distro. The AppImage was built in GitHub Actions on Ubuntu 22.04LTS (April 21, 2022). Slackware 15 was released before (February 2, 2022). I could try to build the AppImage in GH Actions on 20.04LTS but may run into issues. I'd be interested to know how many are using pre Ubuntu 22.04LTS distros.

Quickly trying this one out on LinuxMint 21.3 (based on Ubuntu 22).

On loading an existing save-game it doesn't find my existing OXPs. Presumably a few other bits have moved around too. Should these changes have a large memo on the release page?

[cbr]

Quickly trying this one out on LinuxMint 21.3 (based on Ubuntu 22).

On loading an existing save-game it doesn't find my existing OXPs. Presumably a few other bits have moved around too. Should these changes have a large memo on the release page?

Ditto

[SiriusCG]

You must be logged in to GitHub, then those items become download links.

Here is a download link if you want to test: https://www.filemail.com/d/rqboegjegmaysyy. If you do, please let me know what version of Linux you use.

Thanks for the alternate download link. I'll be testing on 64-bit Lubuntu 24.04 LTS using Nvidia 580 drivers on a GTX 1070 card (if that info is useful to you)

[mcarans]

On loading an existing save-game it doesn't find my existing OXPs. Presumably a few other bits have moved around too. Should these changes have a large memo on the release page?

When I add an OXP to the AppImage version, it stores it under my home folder in:

Code: Select all

/home/mcarans/GNUstep/Library/ApplicationSupport/Oolite/ManagedAddOns/

It looks for saved games in:

Code: Select all

/home/mcarans/oolite-saves/

The defaults file is:

Code: Select all

/home/mcarans/GNUstep/Defaults/OoliteDefaults.plist

Please can you tell me where your existing OXPs and other files are stored.

[mcarans]

[...]
Here is a download link if you want to test: https://www.filemail.com/d/rqboegjegmaysyy. If you do, please let me know what version of Linux you use.

Sigh (expected):

Code: Select all

$ ./Oolite_1.91.0.7781-251216-47a0cfb-x86_64.AppImage 
./Oolite_1.91.0.7781-251216-47a0cfb-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by ./Oolite_1.91.0.7781-251216-47a0cfb-x86_64.AppImage)

This is on Slackware 15.0 (glibc still 2.33)

There's a reason I'm using "me own" build

I experimented with building an AppImage on Ubuntu 20.04, but ran into issues with building libobcj2, so won't proceed further. 20.04 is much older than your distro so you probably wouldn't run into the same issue building libobjc2 on Slackware:
https://github.com/mcarans/oolite/actio ... 8463667983

For future reference, this is the branch where I did the experiments: https://github.com/mcarans/oolite/tree/ ... buntu20.04

AI suggested using Slackware Current, the rolling release version of Slackware. A possibly better idea is to unpack the AppImage by calling it with --appimage-extract, then build glibc 2.34 locally on your machine and copy it into the extracted AppDir under /usr/lib.

[Lone_Wolf]

Some bad news :

The commit https://github.com/OoliteProject/oolite ... de6a62679b that merges the PR breaks build on Arch Linux with gcc .

Code: Select all

Compiling file src/Core/Entities/OOParticleSystem.m ...
src/Core/Entities/OOParticleSystem.m: In function ‘-[OOParticleSystem initWithPosition:velocity:count:minSpeed:maxSpeed:duration:baseColor:]’:
src/Core/Entities/OOParticleSystem.m:70:17: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode
   70 |                 for (unsigned i = 0; i < count; i++)
      |                 ^~~
src/Core/Entities/OOParticleSystem.m:70:17: note: use option ‘-std=c99’, ‘-std=gnu99’, ‘-std=c11’ or ‘-std=gnu11’ to compile your code
src/Core/Entities/OOParticleSystem.m: In function ‘-[OOSmallFragmentBurstEntity initFragmentBurstFrom:velocity:size:]’:
src/Core/Entities/OOParticleSystem.m:281:17: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode
  281 |                 for (unsigned i = 0; i < count; i++)
      |                 ^~~
src/Core/Entities/OOParticleSystem.m: In function ‘-[OOBigFragmentBurstEntity initFragmentBurstFrom:velocity:size:]’:
src/Core/Entities/OOParticleSystem.m:337:17: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode
  337 |                 for (unsigned i = 0; i < count; i++)
      |                 ^~~

src/Core/Entities/OOParticleSystem.m hasn't been changed in 9 years, so something else must have changed .
The commit https://github.com/OoliteProject/oolite ... 19b7835ee1 just before that one builds fine.
gcc and gnustep on my system haven't been changed in weeks.

I expect something in ac4541d increased the used standard but have no idea what.

[another_commander]

Fix just committed. Please build from source now.

[Lone_Wolf]

Build succeeds now, thanks.

I did notice espeak-ng is now used so I have been able to remove the last downstream patch to force espeak-ng and will upload new version of my aur oolite-git package .


P.S.
only change to upstream sourcecode left in that package now is the deletion of 2 files in 2 folders that interfere with libpng system library on arch .

[mcarans]

Build succeeds now, thanks.

I did notice espeak-ng is now used so I have been able to remove the last downstream patch to force espeak-ng and will upload new version of my aur oolite-git package .


P.S.
only change to upstream sourcecode left in that package now is the deletion of 2 files in 2 folders that interfere with libpng system library on arch .

Great news that it works!

[cbr]

Please can you tell me where your existing OXPs and other files are stored.

Added an oxz and it created the directory path you showed.

But i was looking for the Addons dir ( which i thought would automatically be found in oolite-trunk ),
Ok with 'x' it was created in .oolite.

In stead of this hidden dir would it be possible to change this to Library/ApplicationSupport/Oolite next to the managed ones?
Why hid it when we want to edit? currently solution 'linked' ...

[mcarans]

Please can you tell me where your existing OXPs and other files are stored.

Added an oxz and it created the directory path you showed.

But i was looking for the Addons dir ( which i thought would automatically be found in oolite-trunk ),
Ok with 'x' it was created in .oolite.

In stead of this hidden dir would it be possible to change this to Library/ApplicationSupport/Oolite next to the managed ones?
Why hid it when we want to edit? currently solution 'linked' ...

I'm confused. This README.txt for Linux from 8 years ago says:

"Folders that get created during execution
=========================================
Note: Please note that the folders described in this paragraph are not
removed when you uninstall Oolite. They are considered as user folders
(e.g. AddOns, screenshots, savegames with player's in-game status, game
settings, etc.) since they contain files generated with the Commander's own
pain and blood. You will have to manually remove them, if you believe that
you do not need them and that you will not need them even if you reinstall
Oolite in the future.

When you run Oolite for the first time a ~/GNUstep/ (~ stands for your home
folder path) folder will be created into your home folder. The GNUstep
backend needs this.

If you decide to use the "Manage Expansion Packs" functionality the
~/GNUstep/Library/ApplicationSupport/Oolite/ManagedAddOns/ folder will be
created to store the AddOns that you install from within the game itself.
This is the only folder (from the folders described in this section) that
the uninstaller will remove in case it finds it empty.

A ~/.Oolite/Logs/ folder is created to store the application Logs folder.
When Oolite is installed as a system-wide application, the .Oolite folder
may also be used to store OXPs visible only by the specific user
(~/.Oolite/AddOns.); see the "Adding AddOns" section below for more details.

A ~/.Oolite/.oolite-run file is also created at first run and its existence
supresses the display of this README.

A ~/oolite-saves/ folder is created when you save your game status as a
Commander.

Finally a ~/oolite-saves/snapshots/ folder is created when you grab an
in-game screenshot (* key) for the first time. "

I don't think any of these folders has been changed by the new build or AppImage, but please correct me if I am mistaken. We can consider changing them in future though.

[phkb]

I think the issue is that there should be two places Oolite looks for AddOns: in the "ManagedAddOns" folder (with the path as you've specified), and in the "AddOns" folder, which on Linux I assume is in the User folder? When you go into the Expansion Manager in Oolite, and download an expansion, then go to the "List Installed Expansion Packs", select the expansion and then use the "x" key, it should extract it to the "AddOns" folder with an ".off" extension. You can then go and manually change it to ".oxp" in that folder to have it expanded and editable.

[cbr]

For the trunk version i use :
/GNUstep/Applications/Oolite-trunk/AddOns

For stable
/GNUstep/Applications/Oolite/AddOns

The Appimage oolite does not have an install dir like above therefore i suggested one in the same dir as managedaddons

[mcarans]

For the trunk version i use :
/GNUstep/Applications/Oolite-trunk/AddOns

For stable
/GNUstep/Applications/Oolite/AddOns

The Appimage oolite does not have an install dir like above therefore i suggested one in the same dir as managedaddons

I see what you mean. Yes this can be changed and your suggested folder makes sense.

[mcarans]

Build succeeds now, thanks.

I did notice espeak-ng is now used so I have been able to remove the last downstream patch to force espeak-ng and will upload new version of my aur oolite-git package .


P.S.
only change to upstream sourcecode left in that package now is the deletion of 2 files in 2 folders that interfere with libpng system library on arch .

I think you can probably just make a PR to delete those 2 files in https://github.com/OoliteProject/oolite ... pendencies as that was in any case what MrFlibble planned to do to fix the legacy build. That repo gets checked out as a submodule to deps/Linux-deps. I'm not sure why you have it separately as oolite-linux-dependencies in your build, but it will presumably get deleted from there too if you change https://github.com/OoliteProject/oolite ... pendencies.

Pacman is essentially a cli-frontend for libalpm.so and all systemwide installations on archlinux are maintained through libalpm .
Other package managers like flatpak, pip, conda, kde discover , gnome sw centre, steam etc either communicate with libalpm or stick to user installs (probably 99% do the latter on archlinux)

Pacman/libalpm are forbidden to touch user folders. This means anything under $HOME and /usr/local .

So as long as configure/make/make install or modern equivalent only touches /usr/local its fine.
If installing deps is needed, it should be done manually through a pacman command listed in documentation.

Just wanted to check something as I think I may have misunderstood what you said. I have removed sudo for installing packages on Arch, but AI says "On Arch Linux, yes—you typically need sudo to install packages system-wide using pacman, because it modifies system directories like /usr and /etc." You definitely need it to build from source on Ubuntu and Fedora as various system packages must be installed (like clang, SDL etc.). The reason it works in GitHub Actions without it is because containers by default run as root.

I was thinking of adding a root check like this:

Code: Select all

if [ -z "${SUDO_CMD+set}" ]; then
    if [ "$(id -u)" -eq 0 ]; then
        echo "Running as root - no need for sudo"
        SUDO_CMD = ""
    else
        echo "Not running as root - will sudo when needed"
        SUDO_CMD = "sudo"
    fi
fi

The script would then use sudo if not root and not use sudo if root. If really needed, a user could override by explicitly setting SUDO_CMD to either "" or "sudo" before running the script. Would that work on Arch?