Current state of Mac version?

[Commander_X]

[...]
You can see how I tried the build here:
https://github.com/HiranChaudhuri/oolit ... ld-mac.yml
[...]

From what I can tell the "Create Release" action should do. I just tested by copy/paste the lines in my VM, and the TestRelease.zip was properly gathered/created.

Where I have some doubts:
- not sure cd release; zip [...] worked. Definitely what you have in the zip file is the contents of the build/TestRelease folder.
- a quick zip -h in Mac's terminal doesn't expose the --recurse-path options, only -r. Regardless, your zip file was gathered recursively.

It could be worthwhile to grab all the lines in the action as a shell script, and invoke it instead, maybe add a logging option (e.g. | tee -a build/TestRelease.log at the end of each line) and take it from there.

[...]
The surprising bit for me was that zipping just the Oolite.app folder actually failed.
https://github.com/HiranChaudhuri/oolit ... focus=true

Maybe you can try similar commands on your VM and investigate better than I can on the emphemeral runner?

This reference I think is only accessible for people with accounts on github and logged in.

[hiran]

It could be worthwhile to grab all the lines in the action as a shell script, and invoke it instead, maybe add a logging option (e.g. | tee -a build/TestRelease.log at the end of each line) and take it from there.

Github actually grabs all output automatically for the logs. But I now extended the script with the first line:

Code: Select all

      - name: Create Release
        run: |
          #!/bin/bash -x
          mkdir -p release/TestRelease
          cp -r build/TestRelease/Oolite.app release/TestRelease
          mkdir -p release/TestRelease/Documentation
          cp Doc/AdviceForNewCommanders.doc release/TestRelease/Documentation
          cp Doc/contributors.txt release/TestRelease/Documentation
          cp Doc/GPL.TXT release/TestRelease/Documentation
          cp Doc/LICENSE.TXT release/TestRelease/Documentation
          cp Doc/OoliteReadMe.pdf release/TestRelease/Documentation
          cp Doc/OoliteRS.pdf release/TestRelease/Documentation
          mkdir -p release/TestRelease/Extras
          cp -r tools/BBC\ keys release/TestRelease/Extras
          cd release; zip --recurse-paths TestRelease.zip TestRelease

[...]
The surprising bit for me was that zipping just the Oolite.app folder actually failed.
https://github.com/HiranChaudhuri/oolit ... focus=true

Maybe you can try similar commands on your VM and investigate better than I can on the emphemeral runner?

This reference I think is only accessible for people with accounts on github and logged in.

The logs say this:

Code: Select all

Run #!/bin/bash -x
  #!/bin/bash -x
  mkdir -p release/TestRelease
  cp -r build/TestRelease/Oolite.app release/TestRelease
  mkdir -p release/TestRelease/Documentation
  cp Doc/AdviceForNewCommanders.doc release/TestRelease/Documentation
  cp Doc/contributors.txt release/TestRelease/Documentation
  cp Doc/GPL.TXT release/TestRelease/Documentation
  cp Doc/LICENSE.TXT release/TestRelease/Documentation
  cp Doc/OoliteReadMe.pdf release/TestRelease/Documentation
  cp Doc/OoliteRS.pdf release/TestRelease/Documentation
  mkdir -p release/TestRelease/Extras
  cp -r tools/BBC\ keys release/TestRelease/Extras
  cd release; zip --recurse-paths TestRelease.zip TestRelease
  shell: /bin/bash -e {0}
cp: build/TestRelease/Oolite.app/Contents/Frameworks/Sparkle.framework/Resources/fr_CA.lproj: No such file or directory
cp: build/TestRelease/Oolite.app/Contents/Frameworks/Sparkle.framework/Resources/fr.lproj/fr.lproj: No such file or directory
cp: build/TestRelease/Oolite.app/Contents/Frameworks/Sparkle.framework/Versions/A/Resources/fr_CA.lproj: No such file or directory
cp: build/TestRelease/Oolite.app/Contents/Frameworks/Sparkle.framework/Versions/A/Resources/fr.lproj/fr.lproj: No such file or directory
cp: build/TestRelease/Oolite.app/Contents/Frameworks/Sparkle.framework/Versions/Current/Resources/fr_CA.lproj: No such file or directory
cp: build/TestRelease/Oolite.app/Contents/Frameworks/Sparkle.framework/Versions/Current/Resources/fr.lproj/fr.lproj: No such file or directory
Error: Process completed with exit code 1.

It did not even get to the second mkdir command. So what could possibly go wrong when copying files?

[Commander_X]

[...] But I now extended the script with the first line:
[...]

That's not the script I was thinking of (actually I don't think that's a script at all).
The script would've been to create a (say, create_TestRelease_zip.sh) file starting with a simple #!/bin/sh or #!/bin/bash directive. Then you would've inserted all the commands/lines in your "Create Release" action into this file. And then in the "Create Release" action you only had to call create_TestRelease_zip.sh file.

I am not 100% sure it didn't get to the second mkdir. It's better to check that _in_ the environment.

When copy/pasted, "my" cp command also gave similar errors (regarding some language resource folders, it seems the French are still guilty -- heh!), but completed with an "usable" zip file.

[hiran]

[...] But I now extended the script with the first line:
[...]

That's not the script I was thinking of (actually I don't think that's a script at all).
The script would've been to create a (say, create_TestRelease_zip.sh) file starting with a simple #!/bin/sh or #!/bin/bash directive. Then you would've inserted all the commands/lines in your "Create Release" action into this file. And then in the "Create Release" action you only had to call create_TestRelease_zip.sh file.

I am not 100% sure it didn't get to the second mkdir. It's better to check that _in_ the environment.

When copy/pasted, "my" cp command also gave similar errors (regarding some language resource folders, it seems the French are still guilty -- heh!), but completed with an "usable" zip file.

Ok, you would prefer a script as file on the disk. But then we'd have to take care for something the current setup did look at:

Could you check the exit code of the cp command? It would get evident by executing

Code: Select all

#!/bin/bash
cp -r build/TestRelease/Oolite.app release/TestRelease
echo "exited with $?"

I suspect it is not zero.

edit: I am able to verify this. cp exits with 1 which indicates failure - the errors we captured so far are proof of that.
I changed the script to ignore/print that fact and now we have a release zip at https://github.com/HiranChaudhuri/oolite/releases

Again we need to verify the content. And I am somehow curious what these erroring files actually are...

[Commander_X]

[...]
Again we need to verify the content. And I am somehow curious what these erroring files actually are...

It seems the contents fits with what happened in my VM (i.e. 930/930 files in Oolite.app).

It also seems the files that raise the error are wrongly packaged by the Sparkle developer. This is what I found in the source tree for Sparkle that the Mac build for Oolite fetches:

Code: Select all

./Sparkle Test App.app/Contents/Frameworks/Sparkle.framework/Versions/A/Resources/fr_CA.lproj -> /Users/andym/Development/Build Products/Release (GC dual-mode; 10.5-only)/Sparkle.framework/Resources/fr.lproj
./Sparkle.framework/Versions/A/Resources/fr_CA.lproj -> /Users/andym/Development/Build Products/Release/Sparkle.framework/Resources/fr.lproj
./Sparkle.framework/Versions/A/Resources/fr.lproj/fr.lproj -> /Users/andym/Development/Build Products/Release/Sparkle.framework/Resources/fr.lproj
./With Garbage Collection/Sparkle.framework/Versions/A/Resources/fr_CA.lproj -> /Users/andym/Development/Build Products/Release (GC dual-mode; 10.5-only)/Sparkle.framework/Resources/fr.lproj

I'd guess neither me nor you have an "andym" user defined _and_ hosting the link targets.

Besides the obvious option to ask upstream for having these fixed, there is also the option to properly sanitize these links before either building or packaging. Of interest would be only these existing in Sparkle.framework folder (the others don't come during packaging).

[hiran]

[...]
Again we need to verify the content. And I am somehow curious what these erroring files actually are...

It seems the contents fits with what happened in my VM (i.e. 930/930 files in Oolite.app).

It also seems the files that raise the error are wrongly packaged by the Sparkle developer. This is what I found in the source tree for Sparkle that the Mac build for Oolite fetches:

Code: Select all

./Sparkle Test App.app/Contents/Frameworks/Sparkle.framework/Versions/A/Resources/fr_CA.lproj -> /Users/andym/Development/Build Products/Release (GC dual-mode; 10.5-only)/Sparkle.framework/Resources/fr.lproj
./Sparkle.framework/Versions/A/Resources/fr_CA.lproj -> /Users/andym/Development/Build Products/Release/Sparkle.framework/Resources/fr.lproj
./Sparkle.framework/Versions/A/Resources/fr.lproj/fr.lproj -> /Users/andym/Development/Build Products/Release/Sparkle.framework/Resources/fr.lproj
./With Garbage Collection/Sparkle.framework/Versions/A/Resources/fr_CA.lproj -> /Users/andym/Development/Build Products/Release (GC dual-mode; 10.5-only)/Sparkle.framework/Resources/fr.lproj

I'd guess neither me nor you have an "andym" user defined _and_ hosting the link targets.

Besides the obvious option to ask upstream for having these fixed, there is also the option to properly sanitize these links before either building or packaging. Of interest would be only these existing in Sparkle.framework folder (the others don't come during packaging).

Link targets - you mean to say the files in question are symlinks pointing to no valid location? That would explain the behaviour of cp.

Besides that are you able to check the content of the release? Can you install it? Can you start it? Does it crash?

[Commander_X]

[...]
Besides that are you able to check the content of the release? Can you install it? Can you start it? Does it crash?

I am not very familiar with the content of a Mac release. I noticed, though, as above, that what you've got in the "good" zip file, matches what I've got when I ran with copy'n'paste the yaml action.

Installing is as simple as unzipping a file, and unzip I could (and got the unzipped contents out of Apple's quarantine).

It also starts and crashes as before, right after showing the splash screen.

It seems that removing the volatile is the right "fix" for the js compilation. From what I could read (at least for gcc) "out of function" asm code is always compiled as volatile (regardless of having the directive set or not). It seems clang enforces the "preferred" syntax (I'd expect clang to also compile as volatile the asm code, they advertise to be quite close to gcc conventions, but be more strict on the syntax -- therefore the "meaningless" in the error message).

There might be that some of the "UTF8String" calls are not properly guarded against null values for their argument, and this hits back bad on more recent versions of macOS.

[hiran]

[...]
Besides that are you able to check the content of the release? Can you install it? Can you start it? Does it crash?

I am not very familiar with the content of a Mac release. I noticed, though, as above, that what you've got in the "good" zip file, matches what I've got when I ran with copy'n'paste the yaml action.

Installing is as simple as unzipping a file, and unzip I could (and got the unzipped contents out of Apple's quarantine).

It also starts and crashes as before, right after showing the splash screen.

That confirms the build has the same flaws as yours. We'll have to find out what exactly is missing, but if that error does not provide any better information we need developer support.

It seems that removing the volatile is the right "fix" for the js compilation. From what I could read (at least for gcc) "out of function" asm code is always compiled as volatile (regardless of having the directive set or not). It seems clang enforces the "preferred" syntax (I'd expect clang to also compile as volatile the asm code, they advertise to be quite close to gcc conventions, but be more strict on the syntax -- therefore the "meaningless" in the error message).

There might be that some of the "UTF8String" calls are not properly guarded against null values for their argument, and this hits back bad on more recent versions of macOS.

As much as I understood the 'volatile' was meaningless. That means it's presence does not change anything in the compiled output. While older compilers accepted the keyword without warning, gcc after 8.3 will fail. Removing that keyword is the only valid response to that. Although it was not meaningless on all twenty-something occurrences but just four. I removed the offending 4.

Are you familiar with debugging code? As you have the IDE, could you try to step through the Oolite startup to pinpoint where exactly and what kind of exception is thrown? Any data we get will help.

[hiran]

[...]
Besides that are you able to check the content of the release? Can you install it? Can you start it? Does it crash?

I am not very familiar with the content of a Mac release. I noticed, though, as above, that what you've got in the "good" zip file, matches what I've got when I ran with copy'n'paste the yaml action.

Installing is as simple as unzipping a file, and unzip I could (and got the unzipped contents out of Apple's quarantine).

It also starts and crashes as before, right after showing the splash screen.

That confirms the build has the same flaws as yours. We'll have to find out what exactly is missing, but if that error does not provide any better information we need developer support.

Meanwhile we have another evidence that the build is broken. Cholmondely perceived the exact same in [https://bb.oolite.space/viewtopic.php?p=282141#p282141]this and following posts[/url].

As he found more information in the Oollite logfile I now suspect that the joystick handling code is the culprit.
Why should it be bad now if it had worked for so many years?

The most likely reason is it part of the 'deprecation warnings/errors' that we ignored to obtain a build at all. Could we take back that setting and look at deprecations and more valid solutions?

[Cholmondely]

Latest 1.91 nightly is available for all platforms: https://github.com/OoliteProject/nightlies/releases

[Cholmondely]

Latest 1.91 nightly is available for all platforms: https://github.com/OoliteProject/nightlies/releases

But then good news. Great to see that Macs are staying in the fold.

Whom should we thank for the Mac Nightly?

And what should we AppleMac users look for?

Reference:
Trunk 1.91 (Changes by end March 2023: Cut and paste from GitHub: don't understand most of this)

0b1ff49 AnotherCommander Mon Aug 24 14:40:36 2020 +0200 Updated changelog to reflect the changes in customsounds.plist.
860b9d8 AnotherCommander Mon Aug 24 12:47:10 2020 +0200 Adding extra laser sounds and associated configuration. Thanks @phkb.

21bcc59 AnotherCommander Sun Aug 30 14:28:12 2020 +0200 Bump master version to 1.91.
b1af0d2 AnotherCommander Sun Aug 30 12:49:07 2020 +0200 Switch README.md to see the 1.90 d/l counters.

c4df27a KonstantinosSykas Tue Sep 1 15:50:50 2020 +0300 Linux: Fix compiler warning
bd4a0c4 dybal Fri Aug 21 12:23:37 2020 -0300 Adds weaponInfo to EquipmentInfo script object

4d0f37e KonstantinosSykas Wed Sep 9 17:23:58 2020 +0300 Changed default target to 'help', updating the relevant instructions to be more helpful. Minimized the 'debug' and 'deps-debug' targets priority when 'all' or 'deps-all' target is selected.

19cc4f8 KonstantinosSykas Fri Oct 2 12:25:59 2020 +0300 Removed a color constant not being used fixing a relevant compiler warning.

6b45ec2 AnotherCommander Sat Oct 10 14:18:54 2020 +0200 Fixed exception where nil would be passed as an object for a weapon sound dictionary key when said weapon's extra info dictionary was not defined in equipment.plist.

49d9e1a AnotherCommander Tue Oct 27 08:04:57 2020 +0100 Added Bertrand to list of contributors.
d3f5d40 Bertrand Coconnier Tue Oct 27 07:59:08 2020 +0100 Fixed an error reported by gcc on Fedora about format-security (#373)

15a7f10 KonstantinosSykas Sat Nov 14 18:14:56 2020 +0200 Linux (#315): Added libnsl.so.1 in the bundled libs to eliminate the error thrown by Fedora (as of version 28) not delivering libnsl in the default installation.

e4d06c7 Konstantinos Sykas Sun Nov 15 21:54:25 2020 +0200 Add game paused message in Game Options when in flight.

1074e37 AnotherCommander Sun Nov 22 14:30:26 2020 +0100 Implemented atmosphere desnity for planets. Range is from 0.0 to 1.0, default 0.75. The relevant properties are air_density for planetinfo.plist and airDensity for the JS planet entity.

a3fbbe7 AnotherCommander Tue Dec 1 17:19:44 2020 +0100 Changed atmosphere desnity rendering to something that looks more similar to what we had before its initial implementation, at the same time widening the atmosphere densities envelope that can be represented in the 0.0 ... 1.0 range.

f0a01c7 AnotherCommander Sun Feb 7 21:12:55 2021 +0100 Windows and Linux builds: Physical and available system memory are now reported in the log header.

a5b7d71 AnotherCommander Wed Feb 10 21:35:27 2021 +0100 Pretty pic on the front page.

74c532c AnotherCommander Sat Feb 20 19:12:29 2021 +0100 Added tsoj to contributors list.
e00be33 tsoj Sat Feb 20 18:32:02 2021 +0100 Adding "setShipInfoForKey" (#380) plus useful information to README for compiling on Linux

31939ba tsoj Mon Feb 22 16:16:33 2021 +0100 Add update all option to OXP manager (#381)

c8bddc2 phkb Sat Jul 24 02:46:47 2021 +1000 Fix for correct context when adding weapons to player ship

ca776c1 AnotherCommander Tue Jan 11 15:08:58 2022 +0200 Generate builds only for commits to the master branch.
cdde5b5 AnotherCommander Tue Jan 11 14:41:23 2022 +0200 Revert previous commit.
d6bdb02 AnotherCommander Tue Jan 11 14:07:04 2022 +0200 Ensure that nightly releases are generated only for commits to the master branch.
3ebe2b2 AnotherCommander Tue Jan 11 13:04:29 2022 +0200 Fix build status badge on title page
7d5076b AnotherCommander Tue Jan 11 12:41:50 2022 +0200 Added hiran to contributors list.
c9fea52 AnotherCommander Tue Jan 11 11:47:51 2022 +0200 Skip filesystem structure check
7596d9c HiranChaudhuri Mon Jan 10 21:59:30 2022 +0100 Add windows build workflow
c00417d HiranChaudhuri Thu Dec 30 22:46:39 2021 +0100 Update oolite.desktop (#396)

[another_commander]

Whom should we thank for the Mac Nightly?

Getafix.

And what should we AppleMac users look for?

You need to expand the Assets section below the nightly blurb and select the Mac binary:

[Cholmondely]

Whom should we thank for the Mac Nightly?

Getafix.

And what should we AppleMac users look for?

You need to expand the Assets section below the nightly blurb and select the Mac binary:

Already done, and already downloaded - thanks. Sorry, my question was too brief. I wanted to know if there were any changes/problems to look for on the AppleMac version (hence the list of changes).

So far, I've seen Tsoj's general update button (not tried it out yet) as well as not noticing any sort of new screen around start up.

[Cody]

Damn it - Dark Reader won't install on Pale Moon. <sobs>

[Cholmondely]

Just to say, Oolite 1.91 keeps on crashing with the AppleMac.

I have some 15 crash reports from the Apple Mac itself - together with the relevant latest logs. Each seems to be too long to post here - and, as a dumb pilot, I lack the knowledge to fillet them and extract the relevant items.

Crashes have occurred on priming equipment, changing view, arriving at the witchpoint beacon, docking with a Rock Hermit, etc.

What should I do with them?