Proof: Oolite Linux 1.91 unresponsive

[hiran]

So what I labelled as Oolite Linux potentially unresponsive (stuck, crashed) is actually a completely unresponsive setup - especially for new users.

To run into this pitfall, follow these instructions:

1) Install Ubuntu Linux 22 LTS Desktop on a physical or virtual machine (VirtualBox is sufficient) - just a default installation. No artwork required.
(Hint: If you do not want to reinstall everything, at least make sure the $HOME/.Oolite directory does not exist, as it would on a freshly installed machine)
2) Download the Oolite Trunk 1.91 installer
3) Execute the installer.
4) When searching for the Oolite application, you will see an Oolite-Trunk icon. Click it.

Oolite will not appear.


I tried to cover this with PRs. Just let me know if you see issues of getting them merged:
https://github.com/OoliteProject/oolite/pull/432
https://github.com/OoliteProject/oolite ... ies/pull/2

[Switeck]

I tried to cover this with PRs. Just let me know if you see issues of getting them merged:
https://github.com/OoliteProject/oolite/pull/432
https://github.com/OoliteProject/oolite ... ies/pull/2

I'm pretty sure that last link is broken.

[hiran]

I tried to cover this with PRs. Just let me know if you see issues of getting them merged:
https://github.com/OoliteProject/oolite/pull/432
https://github.com/OoliteProject/oolite ... ies/pull/2

I'm pretty sure that last link is broken.

Fixed...

[Stormrider]

Oolite will not appear.

I can confirm this behavior on Mint 20.3. When I run the sh file in terminal I get this output:

Code: Select all

./oolite.app/oolite: error while loading shared libraries: libgnustep-base.so.1.28: cannot open shared object file: No such file or directory

When I look in home/GNUstep/Applications/Oolite/oolite.app and look at the properties of the oolite file it claims to be a shared library (application/x-sharedlib) not an executable file.

[hiran]

Oolite will not appear.

I can confirm this behavior on Mint 20.3. When I run the sh file in terminal I get this output:

Code: Select all

./oolite.app/oolite: error while loading shared libraries: libgnustep-base.so.1.28: cannot open shared object file: No such file or directory

When I look in home/GNUstep/Applications/Oolite/oolite.app and look at the properties of the oolite file it claims to be a shared library (application/x-sharedlib) not an executable file.

We have two different problems here. Currently I am ignoring the shared library problem. What I am focusing at is the consequence: the user, having started Oolite does not see anything. I believe either he should see the game or an error message.

Did you try to modify the scripts according to my PRs? Do you think it is a valid improvement?

[Stormrider]

Did you try to modify the scripts according to my PRs? Do you think it is a valid improvement?

No, sadly I am not technologically advanced enough to even get Oolite to compile successfully. I was just confirming the behavior.

[hiran]

Did you try to modify the scripts according to my PRs? Do you think it is a valid improvement?

No, sadly I am not technologically advanced enough to even get Oolite to compile successfully. I was just confirming the behavior.

Thank you for confirmation. Actually there is no need to recompile the project just to modify some scripts. But we can do it differently.

I will soon merge the pull requests, and then the project will get compiled by GitHub automatically.
If after that you can just test again and confirm the behaviour is the intended one I will be happy already.

[Commander_X]

I tested, similarly, in a VM on xubuntu 22.04 live iso.
True, no reaction while trying to start it from the GUI.
One notice/correction though, the (original) startup script doesn't remain stuck (together with its shell and cat command) when started from GUI. It seems that the "interactive" section only happens when the startup shell is in a terminal. When either starting the script from a terminal, or checking the "Run in terminal" checkbox for the GUI launch, the script remains stuck in the "Press Ctrl-C [...]" message.
By inserting a

Code: Select all

LD_LIBRARY_PATH= notify-send "Bang!"

just after the then statement in the

Code: Select all

if [ $? != 0 ]

displays the notification, and also closes the script run.
I didn't try with the double wrapper solution in the PR.

[hiran]

I tested, similarly, in a VM on xubuntu 22.04 live iso.
True, no reaction while trying to start it from the GUI.

Yes, that is the issue I'm trying to address.

One notice/correction though, the (original) startup script doesn't remain stuck (together with its shell and cat command) when started from GUI. It seems that the "interactive" section only happens when the startup shell is in a terminal.

I wonder why since nowhere in the script I see something that would distinguish whether it was started from terminal or GUI.
But I see a difference on the first run or any subsequent run. That means, once you tried running the script from GUI you would have to reset your system, otherwise the test is a subsequent one and with that invalid.

Maybe you want to verify the existence of files like $HOME/.Oolite/.oolite*-run

When either starting the script from a terminal, or checking the "Run in terminal" checkbox for the GUI launch, the script remains stuck in the "Press Ctrl-C [...]" message.

Where do you get a "Run in terminal" checkbox?

By inserting a

Code: Select all

LD_LIBRARY_PATH= notify-send "Bang!"

just after the then statement in the

Code: Select all

if [ $? != 0 ]

displays the notification, and also closes the script run.
I didn't try with the double wrapper solution in the PR.

Interesting. Yes, with such a line the notification also appears on my system. But why would the script terminate if you just added one line and the problematic 'cat' is still there? Finally, what is the script's exit code after it 'banged'?

[Commander_X]

[...]
I wonder why since nowhere in the script I see something that would distinguish whether it was started from terminal or GUI.
[...]
Where do you get a "Run in terminal" checkbox?
[...]
Interesting. Yes, with such a line the notification also appears on my system. But why would the script terminate if you just added one line and the problematic 'cat' is still there? Finally, what is the script's exit code after it 'banged'?

The shell knows when it's interactive or not. From bash manual:

Code: Select all

       An interactive shell is one started without non-option  arguments  (un‐
       less  -s  is  specified) and without the -c option whose standard input
       and error are both connected to terminals (as determined by isatty(3)),
       or  one  started  with  the -i option.  PS1 is set and $- includes i if
       bash is interactive, allowing a shell script or a startup file to  test
       this state.

About the "Run in terminal", XFCE (the main desktop in the xubuntu) has the whisker menu (I'm not using it very often). You can go to the app in the menu, right click, and you'll get the "launcher configuration" dialog you get for regular registered apps with XFCE (see here).

I'd guess the script's exit code is still "!= 0".

[hiran]

[...]
I wonder why since nowhere in the script I see something that would distinguish whether it was started from terminal or GUI.
[...]
Where do you get a "Run in terminal" checkbox?
[...]
Interesting. Yes, with such a line the notification also appears on my system. But why would the script terminate if you just added one line and the problematic 'cat' is still there? Finally, what is the script's exit code after it 'banged'?

The shell knows when it's interactive or not. From bash manual:

Code: Select all

       An interactive shell is one started without non-option  arguments  (un‐
       less  -s  is  specified) and without the -c option whose standard input
       and error are both connected to terminals (as determined by isatty(3)),
       or  one  started  with  the -i option.  PS1 is set and $- includes i if
       bash is interactive, allowing a shell script or a startup file to  test
       this state.

Ok, the shell knows whether it is interactive. But where/how does this modify the behaviour of the script? After all the script does not access PS1 or $- - or does it?

About the "Run in terminal", XFCE (the main desktop in the xubuntu) has the whisker menu (I'm not using it very often). You can go to the app in the menu, right click, and you'll get the "launcher configuration" dialog you get for regular registered apps with XFCE (see here).

Maybe that explains: I am on vanilla Ubuntu, which uses the Gnome desktop. I'm not aware of such a menu there (I do not say it doesn't exist).

I'd guess the script's exit code is still "!= 0".

While the oolite (or oolite-trunk) script tries to preserve the exit code, oolite-wrapper does not. It always exits with zero. I'm not sure what exit code would be communicated once it runs cat, which shall be terminated by pressing Ctrl-C. Does that just terminate cat and the rest of the script carries on, or does the rest of the script also terminate with an exit code !=0 ?

After all I want to remove the cat, so that problem should no longer exist in future.

[hiran]

Did you try to modify the scripts according to my PRs? Do you think it is a valid improvement?

No, sadly I am not technologically advanced enough to even get Oolite to compile successfully. I was just confirming the behavior.

Thank you for confirmation. Actually there is no need to recompile the project just to modify some scripts. But we can do it differently.

I will soon merge the pull requests, and then the project will get compiled by GitHub automatically.
If after that you can just test again and confirm the behaviour is the intended one I will be happy already.

The current build of Oolite Nightly contains my changes.
Could you just perform the test again and let me know whether the process is still stuck silently or gives feedback to the user?

[Cas Tell]

Oolite will not appear.

I can confirm this behavior on Mint 20.3. When I run the sh file in terminal I get this output:

Code: Select all

./oolite.app/oolite: error while loading shared libraries: libgnustep-base.so.1.28: cannot open shared object file: No such file or directory

When I look in home/GNUstep/Applications/Oolite/oolite.app and look at the properties of the oolite file it claims to be a shared library (application/x-sharedlib) not an executable file.

I'm getting the exact same error. I've downloaded the most recent Oolite version, 1.91.0.7579-231219-e0738b6. The error message is this:

Code: Select all

/oolite.app/oolite: error while loading shared libraries: 
libgnustep-base.so.1.28: cannot open shared object file: 
No such file or directory

Erk. It looks like Oolite died with an error. When making an error
report, please copy + paste the log above into the report.

To solve the problem I did this:

Code: Select all

apt install libgnustep-base-dev

and

Code: Select all

apt install gnustep-make-doc gobjc-multilib gobjc-13-multilib gcc-13-doc gnustep-base-doc

The latter are the recommended additional libraries of libgnustep. - Nevertheless, the problem did not disappear.

[Cas Tell]

The problem boils down to me having libgnustep v1.29 installed but Oolite wants 1.28 (1.28.1 resp.). And I cannot use

Code: Select all

apt-get install gnustep=1.28

or

Code: Select all

apt-get install gnustep=1.28.1

apt tells me that this version is not available (maybe Kali specific).

[hiran]

I'm getting the exact same error. I've downloaded the most recent Oolite version, 1.91.0.7579-231219-e0738b6. The error message is this:

Code: Select all

/oolite.app/oolite: error while loading shared libraries: 
libgnustep-base.so.1.28: cannot open shared object file: 
No such file or directory

Erk. It looks like Oolite died with an error. When making an error
report, please copy + paste the log above into the report.

To solve the problem I did this:

Code: Select all

apt install libgnustep-base-dev

and

Code: Select all

apt install gnustep-make-doc gobjc-multilib gobjc-13-multilib gcc-13-doc gnustep-base-doc

The latter are the recommended additional libraries of libgnustep. - Nevertheless, the problem did not disappear.

Your symptom is the same. But I'm afraid this thread never intended to fix the root cause (see https://bb.oolite.space/viewtopic.php?p=290000#p290000). It was intended to fix something in the reporting of the error so the user would be aware. You need to do some other action to really get it resolved.