Page 1 of 2
Proof: Oolite Linux 1.91 unresponsive
Posted: Tue Jul 11, 2023 8:17 pm
by 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
Re: Proof: Oolite Linux 1.91 unresponsive
Posted: Tue Jul 11, 2023 9:13 pm
by Switeck
hiran wrote: ↑Tue Jul 11, 2023 8:17 pm
I'm pretty sure that last link is broken.
Re: Proof: Oolite Linux 1.91 unresponsive
Posted: Tue Jul 11, 2023 9:32 pm
by hiran
Switeck wrote: ↑Tue Jul 11, 2023 9:13 pm
hiran wrote: ↑Tue Jul 11, 2023 8:17 pm
I'm pretty sure that last link is broken.
Fixed...
Re: Proof: Oolite Linux 1.91 unresponsive
Posted: Wed Jul 12, 2023 1:27 pm
by Stormrider
hiran wrote: ↑Tue Jul 11, 2023 8:17 pm
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.
Re: Proof: Oolite Linux 1.91 unresponsive
Posted: Wed Jul 12, 2023 2:12 pm
by hiran
Stormrider wrote: ↑Wed Jul 12, 2023 1:27 pm
hiran wrote: ↑Tue Jul 11, 2023 8:17 pm
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?
Re: Proof: Oolite Linux 1.91 unresponsive
Posted: Wed Jul 12, 2023 3:55 pm
by Stormrider
hiran wrote: ↑Wed Jul 12, 2023 2:12 pm
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.
Re: Proof: Oolite Linux 1.91 unresponsive
Posted: Wed Jul 12, 2023 4:54 pm
by hiran
Stormrider wrote: ↑Wed Jul 12, 2023 3:55 pm
hiran wrote: ↑Wed Jul 12, 2023 2:12 pm
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.
Re: Proof: Oolite Linux 1.91 unresponsive
Posted: Wed Jul 12, 2023 8:28 pm
by 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
displays the notification, and also closes the script run.
I didn't try with the double wrapper solution in the PR.
Re: Proof: Oolite Linux 1.91 unresponsive
Posted: Wed Jul 12, 2023 8:51 pm
by hiran
Commander_X wrote: ↑Wed Jul 12, 2023 8:28 pm
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.
Commander_X wrote: ↑Wed Jul 12, 2023 8:28 pm
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
Commander_X wrote: ↑Wed Jul 12, 2023 8:28 pm
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?
Commander_X wrote: ↑Wed Jul 12, 2023 8:28 pm
By inserting a
Code: Select all
LD_LIBRARY_PATH= notify-send "Bang!"
just after the
then statement in the
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'?
Re: Proof: Oolite Linux 1.91 unresponsive
Posted: Wed Jul 12, 2023 9:14 pm
by Commander_X
hiran wrote: ↑Wed Jul 12, 2023 8:51 pm
[...]
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".
Re: Proof: Oolite Linux 1.91 unresponsive
Posted: Wed Jul 12, 2023 9:56 pm
by hiran
Commander_X wrote: ↑Wed Jul 12, 2023 9:14 pm
hiran wrote: ↑Wed Jul 12, 2023 8:51 pm
[...]
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?
Commander_X wrote: ↑Wed Jul 12, 2023 9:14 pm
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).
Commander_X wrote: ↑Wed Jul 12, 2023 9:14 pm
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.
Re: Proof: Oolite Linux 1.91 unresponsive
Posted: Thu Jul 13, 2023 5:02 am
by hiran
hiran wrote: ↑Wed Jul 12, 2023 4:54 pm
Stormrider wrote: ↑Wed Jul 12, 2023 3:55 pm
hiran wrote: ↑Wed Jul 12, 2023 2:12 pm
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?
Re: Proof: Oolite Linux 1.91 unresponsive
Posted: Fri Dec 22, 2023 11:17 am
by Cas Tell
Stormrider wrote: ↑Wed Jul 12, 2023 1:27 pm
hiran wrote: ↑Tue Jul 11, 2023 8:17 pm
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:
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.
Re: Proof: Oolite Linux 1.91 unresponsive
Posted: Fri Dec 22, 2023 12:52 pm
by 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
or
apt tells me that this version is not available (maybe Kali specific).
Re: Proof: Oolite Linux 1.91 unresponsive
Posted: Fri Dec 22, 2023 1:30 pm
by hiran
Cas Tell wrote: ↑Fri Dec 22, 2023 11:17 am
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:
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.