Oolite Bulletins

hiran wrote: ↑Thu May 09, 2024 11:45 am

hiran wrote: ↑Sun May 05, 2024 10:16 am

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?

• 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.

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

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

MrFlibble wrote: ↑Tue Jun 11, 2024 6:58 pm

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.)

MrFlibble wrote: ↑Tue Jun 11, 2024 6:58 pm

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.

MrFlibble wrote: ↑Tue Jun 11, 2024 6:58 pm

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.

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

MrFlibble wrote: ↑Tue Jun 11, 2024 6:58 pm

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

hiran wrote: ↑Tue Jun 11, 2024 8:05 pm

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.

hiran wrote: ↑Tue Jun 11, 2024 8:05 pm

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

MrFlibble wrote: ↑Tue Jun 11, 2024 8:23 pm

hiran wrote: ↑Tue Jun 11, 2024 8:05 pm

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.

hiran wrote: ↑Tue Jun 11, 2024 8:05 pm

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 wrote: ↑Tue Jun 11, 2024 8:37 pm

MrFlibble wrote: ↑Tue Jun 11, 2024 8:23 pm

hiran wrote: ↑Tue Jun 11, 2024 8:05 pm

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.

hiran wrote: ↑Tue Jun 11, 2024 8:05 pm

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.

MrFlibble wrote: ↑Tue Jun 11, 2024 8:42 pm

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.

hiran wrote: ↑Wed Jun 12, 2024 2:39 pm

MrFlibble wrote: ↑Tue Jun 11, 2024 8:42 pm

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 wrote: ↑Wed Jun 12, 2024 2:45 pm

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

hiran wrote: ↑Wed Jun 12, 2024 6:43 pm

MrFlibble wrote: ↑Wed Jun 12, 2024 2:45 pm

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'.

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

#!/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

MrFlibble wrote: ↑Wed Jun 12, 2024 9:33 pm

hiran wrote: ↑Wed Jun 12, 2024 6:43 pm

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)

MrFlibble wrote: ↑Wed Jun 12, 2024 9:33 pm

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

MrFlibble wrote: ↑Wed Jun 12, 2024 9:33 pm

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.

MrFlibble wrote: ↑Wed Jun 12, 2024 9:33 pm

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