OoliteStarter

[phkb]

Please have a look at OoliteStarter v0.1.31-furbelow.2

@arquaebus @phkb: Have you had a chance looking at that new release? Are the issues you brought up covered, or is there further work necesary?

Sorry, just started a new job, so haven't had time. Should be able to have a look early next week.

[MrFlibble]

Binary attempts were done first, but I'll show the 'other way' first as it actually seems to work quite easily:

Install Java SDK 17, I got it using the x86 dmg installer from this page https://www.oracle.com/uk/java/technolo ... jdk17-mac . The Arm version is there if using Apple silicon.

(Looks like java 17 is effectively obsolete after September. Do you know if it'll work with a more recent version? If so, we should edit this and recommend the newest version that will play nice.)

Get the generic tar.gz version from your releases page. Double click it to extract. A new folder will appear. Navigate into that folder. then either:

• Best way: Make sure terminal is on your dock. Drag run.sh onto Terminal, hit return in Terminal.
• Fluffiest way: Right click (or ctrl-click) the file run.sh, select Open-with, other application, enable 'all Applications', navigate to Applications/Utilities and select 'Terminal', if you set 'always' then double clicking any file with a .sh extension will invoke terminal and run it.
• Another fluffy way. Navigate into 'dist' folder, right click the 'jar' file, and select open with JavaLauncher. It'll grumble that the app might be infested with malware, but you can overrule that.

I'll remind myself how to make a terminal launch 'properly fluffy' when I get time. I think there's a trivial way to make an app bundle directory with an icon and all. That may still end up with the java icon when handing off to java.

Ready to run versions:-

Testing the package on MacOS Ventura (13.6.7), Intel. I expect it to fail, as github is using Arm. I fell on the same spike with the other thing. Might be worth making that apparent on releases.

First attempt is with the gelsemium.2.pkg. The package manager whinges this:-

cannot be opened because it is from an unknown developer. macOS cannot verify that this app is free from malware.

I see you've commented that out in the build.yml. Have you not got valid keys to sign it? No biggie, as the user can just get the pkg from the zip...

The app from the zip fails thus:

You can't open the application "OoliteStarter" because this application in not supported on this Mac.

The info on that one shows it as "Apple silicon", ergo it's doomed to fail on intel.

I've had a nose at the build.yml and readme.md. I've grabbed Java 17 JDK and built it successfully on x86_64. I grabbed the source and dist and did a bit of renaming to botch it together. It moans about the png file not being icns format, so it's going to use the default. Looks ok though. Guess I need to install OoLite-dev mac x86_64 to see if it really-really works, though my 'Mac' is not a mac, and might not have the graphical oomph

There are some positive gruntings around the interwebs on how to do universal2 with jpackage. These two links may be helpful if you wanted to try it.
https://stackoverflow.com/questions/717 ... undled-jre
leads to these two:
https://github.com/ChristopherBruno78/universal_jre
https://incenp.org/notes/2023/universal ... macos.html

It may be kinder to make two flavours for macOS, x86_64 and arm_64 since the universal binary might weigh in at 300 megs!

Another horrible alternative is to make it x86_64 only, and use Rosetta to interpret it on arm. Not worth doing IMHO.

Seems a heck of a penalty, 150megs to get a nice icon, vs. ~10megs to just run it from .jar. Is there no way to embed a nice icon in a .jar?

[hiran]

Binary attempts were done first, but I'll show the 'other way' first as it actually seems to work quite easily:

Install Java SDK 17, I got it using the x86 dmg installer from this page https://www.oracle.com/uk/java/technolo ... jdk17-mac . The Arm version is there if using Apple silicon.

(Looks like java 17 is effectively obsolete after September. Do you know if it'll work with a more recent version? If so, we should edit this and recommend the newest version that will play nice.)

The documentation say OoliteStarter needs JDK 17+, so it should run smoothly on a newer version, e.g. 21.
According to my data OpenJDK 17 would enjoy support for at least one more year. See
- https://www.oracle.com/java/technologie ... admap.html
- https://access.redhat.com/articles/1299013

Nevertheless I just checked and upgraded the dependencies so new versions directly build on OpenJDK 21.

Get the generic tar.gz version from your releases page. Double click it to extract. A new folder will appear. Navigate into that folder. then either:

• Best way: Make sure terminal is on your dock. Drag run.sh onto Terminal, hit return in Terminal.
• Fluffiest way: Right click (or ctrl-click) the file run.sh, select Open-with, other application, enable 'all Applications', navigate to Applications/Utilities and select 'Terminal', if you set 'always' then double clicking any file with a .sh extension will invoke terminal and run it.
• Another fluffy way. Navigate into 'dist' folder, right click the 'jar' file, and select open with JavaLauncher. It'll grumble that the app might be infested with malware, but you can overrule that.

I'll remind myself how to make a terminal launch 'properly fluffy' when I get time. I think there's a trivial way to make an app bundle directory with an icon and all. That may still end up with the java icon when handing off to java.

So no surprises here. That is good.

Ready to run versions:-

Testing the package on MacOS Ventura (13.6.7), Intel. I expect it to fail, as github is using Arm. I fell on the same spike with the other thing. Might be worth making that apparent on releases.

What? Really? Indeed I never checked!
Here's an excerpt from the logs:

Code: Select all

Current runner version: '2.317.0'
Operating System
  macOS
  14.5
  23F79
Runner Image
  Image: macos-14-arm64
  Version: 20240603.1
  Included Software: https://github.com/actions/runner-images/blob/macos-14-arm64/20240603.1/images/macos/macos-14-arm64-Readme.md
  Image Release: https://github.com/actions/runner-images/releases/tag/macos-14-arm64%2F20240603.1

Oh no! And I teased poor Cholmondely...

While I don't know how to trigger an Intel 64 bit MacOS runner I will try to at least indicate something in the filename. What a bummer...
https://docs.github.com/en/actions/usin ... ed-runners

I've had a nose at the build.yml and readme.md. I've grabbed Java 17 JDK and built it successfully on x86_64. I grabbed the source and dist and did a bit of renaming to botch it together. It moans about the png file not being icns format, so it's going to use the default. Looks ok though. Guess I need to install OoLite-dev mac x86_64 to see if it really-really works, though my 'Mac' is not a mac, and might not have the graphical oomph

Wow, you got very far. So it all boils down to finding an Intel Runner in Github.


There are some positive gruntings around the interwebs on how to do universal2 with jpackage. These two links may be helpful if you wanted to try it.
https://stackoverflow.com/questions/717 ... undled-jre
leads to these two:
https://github.com/ChristopherBruno78/universal_jre
https://incenp.org/notes/2023/universal ... macos.html

It may be kinder to make two flavours for macOS, x86_64 and arm_64 since the universal binary might weigh in at 300 megs!

Another horrible alternative is to make it x86_64 only, and use Rosetta to interpret it on arm. Not worth doing IMHO.

Seems a heck of a penalty, 150megs to get a nice icon, vs. ~10megs to just run it from .jar. Is there no way to embed a nice icon in a .jar?
[/quote]
Sounds good for me. Although I am not sure how to package that well without having the right runner. But if you can find out your input is definitely welcome.
And actually we are facing the same issue with the precompiled debug console.

[MrFlibble]

Wow, you got very far. So it all boils down to finding an Intel Runner in Github.
...
Sounds good for me. Although I am not sure how to package that well without having the right runner. But if you can find out your input is definitely welcome.

I don't think there is one. Going the universal2 route may be do-able if using the universal2 version of java. If so, then building on Arm64 won't be a problem.

Else I can do a local build for you to manually upload to github release. It's a workaround. If it's only done on required releases, it's not a big bother.

And actually we are facing the same issue with the precompiled debug console.

Yup. You can see I've stopped building it on my one for now. I found it's not quite working when I tested it, hence the delay. I'm trying to fix it on my x86_64 (with a bit of help from Cag!) before I worry about making binaries for MacOS. Same possible workaround, I may have to do that as a local build for intel Mac.

[hiran]

Wow, you got very far. So it all boils down to finding an Intel Runner in Github.
...
Sounds good for me. Although I am not sure how to package that well without having the right runner. But if you can find out your input is definitely welcome.

I don't think there is one. Going the universal2 route may be do-able if using the universal2 version of java. If so, then building on Arm64 won't be a problem.

Else I can do a local build for you to manually upload to github release. It's a workaround. If it's only done on required releases, it's not a big bother.

And actually we are facing the same issue with the precompiled debug console.

Yup. You can see I've stopped building it on my one for now. I found it's not quite working when I tested it, hence the delay. I'm trying to fix it on my x86_64 (with a bit of help from Cag!) before I worry about making binaries for MacOS. Same possible workaround, I may have to do that as a local build for intel Mac.

Hmmm, building manually? I'd go mad with something like that.
But if you have the equipment, you could actually install the Github Runner software and use it as self-hosted runner. That would relieve you from building manually despite it would build on your computer.

Edit: Now I am thinking about the Oolite releases themselves. I never checked the MacOS architecture. That could be part of our problems. After all we try to link to precompiled shared libraries. Oh man...

[MrFlibble]

Wow, you got very far. So it all boils down to finding an Intel Runner in Github.
...
Sounds good for me. Although I am not sure how to package that well without having the right runner. But if you can find out your input is definitely welcome.

I don't think there is one. Going the universal2 route may be do-able if using the universal2 version of java. If so, then building on Arm64 won't be a problem.

Else I can do a local build for you to manually upload to github release. It's a workaround. If it's only done on required releases, it's not a big bother.

And actually we are facing the same issue with the precompiled debug console.

Yup. You can see I've stopped building it on my one for now. I found it's not quite working when I tested it, hence the delay. I'm trying to fix it on my x86_64 (with a bit of help from Cag!) before I worry about making binaries for MacOS. Same possible workaround, I may have to do that as a local build for intel Mac.

Hmmm, building manually? I'd go mad with something like that.
But if you have the equipment, you could actually install the Github Runner software and use it as self-hosted runner. That would relieve you from building manually despite it would build on your computer.

If I can boil the build process down to a script, it'll be no bother as all I'd have to do is boot it (remotely if I want), then launch the build script. Almost at that now. If that script (like builder on the other thing) can live in-tree, then others can roll their own variants by running a single script, or someone else can take over if I get shot down by pirates. Using my 'Mac' as a runner is probably not an option for a number of reasons.

[arquebus]

Very weird things happening in gelsemium.4 regarding updated OXPs

I'm seeing multiple versions of the same OXP in my Installed list, but it's not clear in the UI whether they're all installed at the same time, or only the most recent. To be sure, I uninstall the older versions, which takes out ALL of the versions.

The bottom description section always says "install this as an update" regardless of the OXP's status (not installed, installed) except when it's the only version in the installed list (which happens if you uninstall the older one, which knocks all of them out, and then you re-install the one from the left side, which will always be the most recent).

[arquebus]

An additional glitch:

Right side, filter to Updatable

List contains OXPs that the description below says have newer versions.

Newer versions do not appear anywhere on the left screen. It is unclear how to update.

Galactic Registry (for example) is updatable from 5.8 to 5.9.1. Doesn't appear in left list. So I uninstall from the right to see if I can simply reinstall with the newer version... and it still doesn't show up on the left list. But then if I remove the filter (show all), there it is, updated.

So basically the interface does not explain how to update an OXP, but ends up updating the OXP anyway when you uninstall it. Which means that the uninstall arrow is actually an update arrow when you're filtered by updatable. Or something. Unclear.

[arquebus]

I renew my plea to at least have an option to automatically do all of this stuff in the background, with a summary notification of what was done.

[hiran]

Can I replay the situation? After all I had not touched the OXP managing stuff for a few versions.

Regarding background updates: they are offered but with a screen to approve the activity before magick happens.

[hiran]

If I can boil the build process down to a script, it'll be no bother as all I'd have to do is boot it (remotely if I want), then launch the build script. Almost at that now. If that script (like builder on the other thing) can live in-tree, then others can roll their own variants by running a single script, or someone else can take over if I get shot down by pirates. Using my 'Mac' as a runner is probably not an option for a number of reasons.

Ok, your build results will be welcome.
I'm not sure what privileges you need to add artifacts to releases but am sure someone from the OoliteProject administration can grant the access.

[MrFlibble]

If I can boil the build process down to a script, it'll be no bother as all I'd have to do is boot it (remotely if I want), then launch the build script. Almost at that now. If that script (like builder on the other thing) can live in-tree, then others can roll their own variants by running a single script, or someone else can take over if I get shot down by pirates. Using my 'Mac' as a runner is probably not an option for a number of reasons.

Ok, your build results will be welcome.
I'm not sure what privileges you need to add artifacts to releases but am sure someone from the OoliteProject administration can grant the access.

Files can be added to a release by editing the release. Below the text and files will appear "Attach binaries by dropping them here or selecting them. " so, for now, if there's a particular version you want e.g. Cholly to try out just let me know. I'll roll it on-demand to a temp file host and post the link here. Doing so will lead me rapidly towards automation of the task. Old versions in x86_64 form can get lost once a better method is sorted, and/or development calms down.

Is there a 'current stable' of choice for me to do?

[hiran]

Is there a 'current stable' of choice for me to do?

This is the currently stable one:
https://github.com/OoliteProject/Oolite ... ag/v0.1.31

I think if you stick to the builds on the master branch it would be fully sufficient. Experimental versions all have a branch name, as currently 'gelsemium'.

[MrFlibble]

Is there a 'current stable' of choice for me to do?

This is the currently stable one:
https://github.com/OoliteProject/Oolite ... ag/v0.1.31

I think if you stick to the builds on the master branch it would be fully sufficient. Experimental versions all have a branch name, as currently 'gelsemium'.

Cool. I cheated, 'cos I skipped the Maven headache by re-using the jar from the generic dist. I've managed to knock together a build script that does it all with little editing. Should be able to repeat this by just changing the version number.

Here's the app, simply zipped.
OoliteStarter-0.1.31-MacOS-x86_64.zip
(56.96 MB)

And here, wrapped up in an installer.
OoliteStarter-0.1.31-x86_64.pkg
(56.67 MB)

These uploads will self-destruct on July 12th at about 22:22.

Edit: I had failed to get maven build working due to

Code: Select all

src/test/java/oolite/starter/OoliteTest.java:        command.add("/usr/bin/ls");

/bin and /sbin were traditionally the home of stuff needed to boot the system and effect simple repairs before even mounting /usr (which might have been an NFS share).
It's ONLY at the more standard /bin/ls on the Mac. Most Linuxes these days assume a largely flat filesystem, with a symlink /usr/bin to /bin so 'ls' appears in both places.
IMHO, /bin/ls is a more robust choice. I've patched around it in my MacOs-x86_64 build script with sed, and can now build from scratch in one hit.
All I need to do is edit the version number. Output files in $HOME/starter/build/target. I've pasted the build script below in case I have a nasty run in with the 'goids.

Code: Select all

#!/bin/bash

distVER=0.1.31
arch=x86_64

#Builder for Mac.
distURL=https://codeload.github.com/OoliteProject/OoliteStarter/zip/refs/tags/v$distVER
builddir=$HOME/starter/build

kaput(){ echo "$1" ; exit 2 ; }

[ "x$distVER" = "x" ] && kaput "Version is nonsense"
#jpackage won't accept the first digit of version being zero.
# so we patch it here.
MacVER=$(echo "$distVER" | sed 's@^0\.@1.@')

mkdir -p "$builddir" && cd "$builddir" || kaput "Can't make build dir $builddir"

getTar(){
	curl -L -o dist-${distVER}.zip $distURL
	unzip -qq dist-${distVER}.zip
	ls -al
}

doMaven(){
	#PATCH FOR MAC.
	#BSD sed insists on a suffix for backup when using -i to edit inline.
	sed -i flibble 's@/usr/bin/ls@/bin/ls@' \
 	 OoliteStarter-$distVER/src/test/java/oolite/starter/OoliteTest.java
	export PATH="$PATH:$HOME/maven/bin"
	cd OoliteStarter-$distVER || kaput "failed to cd to source" 
	mvn versions:set "-DnewVersion=$distVER"
	mvn -B package -e --file pom.xml
	cd -
}

doBuild(){
echo "$distVER"
jpackage \
 --type app-image \
 --app-version $MacVER \
 --copyright Copyright \
 --description "OoliteStarter $distVER" \
 --name "OoliteStarter" --dest target/appimage \
 --temp target/oolite-starter-tmp --vendor "OoliteProject" --verbose \
 --icon OoliteStarter-$distVER/src/main/resources/oolite_logo.png \
 --input OoliteStarter-$distVER/target/dist \
 --main-jar OoliteStarter-$distVER.jar \
 --main-class oolite.starter.MainFrame --mac-package-name "OoliteStarter" \
 --resource-dir OoliteStarter-$distVER/src/jpackage/resources-mac \
 --vendor OoliteProject
}

doApp(){
 jpackage \
  --type pkg \
  --verbose \
  --app-version $MacVER \
  --app-image target/appimage/OoliteStarter.app \
  --name "OoliteStarter" \
  --icon OoliteStarter-$distVER//src/main/resources/oolite_logo.png \
  --dest target \
  --resource-dir OoliteStarter-$distVER/src/jpackage/resources-mac \
  --vendor OoliteProject
}

makeZipDist(){
 cd target/appimage
 zip -qr ../OoliteStarter-${distVER}-MacOS-$arch.zip  *
 cd - ; cd target
 mv OoliteStarter-${MacVER}.pkg OoliteStarter-${distVER}-$arch.pkg
}

getTar
doMaven
doBuild
doApp
makeZipDist

[hiran]

This is the currently stable one:
https://github.com/OoliteProject/Oolite ... ag/v0.1.31

I think if you stick to the builds on the master branch it would be fully sufficient. Experimental versions all have a branch name, as currently 'gelsemium'.

Cool. I cheated, 'cos I skipped the Maven headache by re-using the jar from the generic dist. I've managed to knock together a build script that does it all with little editing. Should be able to repeat this by just changing the version number.

Here's the app, simply zipped.
OoliteStarter-0.1.31-MacOS-x86_64.zip (56.96 MB)
And here, wrapped up in an installer.
OoliteStarter-0.1.31-x86_64.pkg (56.67 MB)

Thank you! I cannot check the content, but I added them to the stable release.

These uploads will self-destruct on July 12th at about 22:22.

Ummmm - I hope I understand the scope right...

Edit: I had failed to get maven build working due to

Code: Select all

src/test/java/oolite/starter/OoliteTest.java:        command.add("/usr/bin/ls");

/bin and /sbin were traditionally the home of stuff needed to boot the system and effect simple repairs before even mounting /usr (which might have been an NFS share).
It's ONLY at the more standard /bin/ls on the Mac. Most Linuxes these days assume a largely flat filesystem, with a symlink /usr/bin to /bin so 'ls' appears in both places.
IMHO, /bin/ls is a more robust choice. I've patched around it in my MacOs-x86_64 build script with sed, and can now build from scratch in one hit.

Ok, that unit test is no good choice. I just checked, and on Ubuntu ls is in the path I gave. But you are right, /bin is a symlink to /usr/bin so I can follow your suggestion.

All I need to do is edit the version number. Output files in $HOME/starter/build/target. I've pasted the build script below in case I have a nasty run in with the 'goids.

Code: Select all

#!/bin/bash

distVER=0.1.31
arch=x86_64

#Builder for Mac.
distURL=https://codeload.github.com/OoliteProject/OoliteStarter/zip/refs/tags/v$distVER
builddir=$HOME/starter/build

kaput(){ echo "$1" ; exit 2 ; }

[ "x$distVER" = "x" ] && kaput "Version is nonsense"
#jpackage won't accept the first digit of version being zero.
# so we patch it here.
MacVER=$(echo "$distVER" | sed 's@^0\.@1.@')

mkdir -p "$builddir" && cd "$builddir" || kaput "Can't make build dir $builddir"

getTar(){
	curl -L -o dist-${distVER}.zip $distURL
	unzip -qq dist-${distVER}.zip
	ls -al
}

doMaven(){
	#PATCH FOR MAC.
	#BSD sed insists on a suffix for backup when using -i to edit inline.
	sed -i flibble 's@/usr/bin/ls@/bin/ls@' \
 	 OoliteStarter-$distVER/src/test/java/oolite/starter/OoliteTest.java
	export PATH="$PATH:$HOME/maven/bin"
	cd OoliteStarter-$distVER || kaput "failed to cd to source" 
	mvn versions:set "-DnewVersion=$distVER"
	mvn -B package -e --file pom.xml
	cd -
}

doBuild(){
echo "$distVER"
jpackage \
 --type app-image \
 --app-version $MacVER \
 --copyright Copyright \
 --description "OoliteStarter $distVER" \
 --name "OoliteStarter" --dest target/appimage \
 --temp target/oolite-starter-tmp --vendor "OoliteProject" --verbose \
 --icon OoliteStarter-$distVER/src/main/resources/oolite_logo.png \
 --input OoliteStarter-$distVER/target/dist \
 --main-jar OoliteStarter-$distVER.jar \
 --main-class oolite.starter.MainFrame --mac-package-name "OoliteStarter" \
 --resource-dir OoliteStarter-$distVER/src/jpackage/resources-mac \
 --vendor OoliteProject
}

doApp(){
 jpackage \
  --type pkg \
  --verbose \
  --app-version $MacVER \
  --app-image target/appimage/OoliteStarter.app \
  --name "OoliteStarter" \
  --icon OoliteStarter-$distVER//src/main/resources/oolite_logo.png \
  --dest target \
  --resource-dir OoliteStarter-$distVER/src/jpackage/resources-mac \
  --vendor OoliteProject
}

makeZipDist(){
 cd target/appimage
 zip -qr ../OoliteStarter-${distVER}-MacOS-$arch.zip  *
 cd - ; cd target
 mv OoliteStarter-${MacVER}.pkg OoliteStarter-${distVER}-$arch.pkg
}

getTar
doMaven
doBuild
doApp
makeZipDist

Let's add that to the project. Just give it a meaningful name, add comments inside what it intends to do and stuff it besides pom.xml. I'm happy to accept a pull request.
Obviously I will never run that script, so maintenance is on you.