deploySite task in github workflow failing

[MrFlibble]

Could you use a URL shortening service (like Tiny URL) to shorten it? That way, nothing else needs to be created.

Rather than adding yet another dependency I'd involve timer to test whether https://oolite.space/ is feasible.

The string oxz-index-url is looked up in the configuration (GnuStepDefaults?) file. If not found, the builtin default is used.
https://github.com/OoliteProject/oolite ... ger.m#L311

This behaviour is already documented in https://wiki.alioth.net/index.php/Apple ... revious.29

If not found.. That's the thing. For most users, it will not be found, and AFAICT Oolite will create it, with the aforementioned default, which we're aiming to patch.

I'm with you on avoiding a dependency such as tinyshortnameserviceprovider.com. The optimum way ahead is if timer would be kind enough to add a couple of alternative paths so we can test our options.

So far as I can see, we can hexedit our way around the issue in Linux and Mac builds of 1.90, the former being a tar-script, the latter being a zip archive, both having the relevant URL plain in the binary. The Mac version ideally sits as a backward compatible lump. The Linux version will ideally also get patched to include the correct libraries if it doesn't already, but that can be done without an actual rebuild. I'll have a go and see if it runs on a fresh install of something current, and if needed, install an old Ubuntu/Mint on a VM to reap the libraries required, and add them to the tarball.

The windoze version is a self-extracting installer, and may prove a tad harder to edit. Might be easier to run a re-build for that, unless anyone here knows how to re-jig such a file?

[another_commander]

The windoze version is a self-extracting installer, and may prove a tad harder to edit. Might be easier to run a re-build for that, unless anyone here knows how to re-jig such a file?

I don't think you can jig an NSIS installer. It uses CRCs for self-verifying its integrity when it runs. Even a one byte change will result in a failure to execute.

[MrFlibble]

The windoze version is a self-extracting installer, and may prove a tad harder to edit. Might be easier to run a re-build for that, unless anyone here knows how to re-jig such a file?

I don't think you can jig an NSIS installer. It uses CRCs for self-verifying its integrity when it runs. Even a one byte change will result in a failure to execute.

Thanks for confirming my fears. At least we should be able to effect a simple fix on the Mac and Linux (both 64 and 32 bit) variants.

Would a rebuild of the windows variant be backwards compatible? Could the fix be more easily achieved by re-doing the last step (constructing the installer)?

[another_commander]

Would a rebuild of the windows variant be backwards compatible? Could the fix be more easily achieved by re-doing the last step (constructing the installer)?

Yes, it is totally possible to rebuild the installer corresponding to the exact github revision used to generate the 1.90 release.

[MrFlibble]

Would a rebuild of the windows variant be backwards compatible? Could the fix be more easily achieved by re-doing the last step (constructing the installer)?

Yes, it is totally possible to rebuild the installer corresponding to the exact github revision used to generate the 1.90 release.

I'm inferring from that, that we should to be able to hex-edit a corrected URL into all versions, and re-build the installers without actually recompiling everything. This would keep 32 bit versions with backwards compatibility for Lin and Win, at least for 1.90.

The only other polishing required would be the library re-bundling (if needed), which I can do with a couple of VM's and legacy versions of Ubuntu, as were used for the 2020 build of 1.90. If my assumption above is wrong, then I can also use those to re-build (with all URLs fixed!) for Lin 32/64, compatible from 2020 to now.

I'll sanity test the hex-edit fix later today, at least for Linux and Mac, using a local URL redirect setup pending proper alias.

[MrFlibble]

I've just used a hacky little python redirect and learned three things.

This all works fine on the Mac version.

Putting a slash at the end of the URL in the oolite binary doesn't hurt anything.

Redirecting to the https variant of the site works fine.

From that, I am going to assume the ideal extra URL should be https://addons.oolite.space/api/1.0/repo/ but if it's not much extra effort, then having http://addons.oolite.space/api/1.0/index/ to fall back on if I'm wrong, might be a good idea.

EDIT: Hold that.. Just realised it's working without actually hitting the redirect. Hunting for the old config that must be getting hit. Will update when done. Managed to clobber the errant config file and tested it properly. All good.

[hiran]

EDIT: Hold that.. Just realised it's working without actually hitting the redirect. Hunting for the old config that must be getting hit. Will update when done. Managed to clobber the errant config file and tested it properly. All good.

Do I understand you managed to patch the binaries? And all that is required is to repackage them into installers to have updated URLs in the 1.90 installations?

@anyone: Who can help with these installers?

[MrFlibble]

EDIT: Hold that.. Just realised it's working without actually hitting the redirect. Hunting for the old config that must be getting hit. Will update when done. Managed to clobber the errant config file and tested it properly. All good.

Do I understand you managed to patch the binaries? And all that is required is to repackage them into installers to have updated URLs in the 1.90 installations?

@anyone: Who can help with these installers?

It's my understanding that we need timer to add a URL that fits the same number of characters. If/when that happens, the installers can be 'fixed'.

Other options would be to use a URL shortening service, or for someone to set up a redirecting web server (which I could do if needed), but both of those add an extra dependency AKA layer of flakiness.

[hiran]

EDIT: Hold that.. Just realised it's working without actually hitting the redirect. Hunting for the old config that must be getting hit. Will update when done. Managed to clobber the errant config file and tested it properly. All good.

Do I understand you managed to patch the binaries? And all that is required is to repackage them into installers to have updated URLs in the 1.90 installations?

@anyone: Who can help with these installers?

It's my understanding that we need timer to add a URL that fits the same number of characters. If/when that happens, the installers can be 'fixed'.

Other options would be to use a URL shortening service, or for someone to set up a redirecting web server (which I could do if needed), but both of those add an extra dependency AKA layer of flakiness.

He is rarely online. Too bad.

[phkb]

It's my understanding that we need timer to add a URL that fits the same number of characters. If/when that happens, the installers can be 'fixed'.

Timer has created a new, shorter URL for us to use, which I've tested and it works successfully. The URL is http://mods.oolite.space/api/1.0/overview

MrFlibble, maybe this weekend you could break out your hex-editor and see if we've got a contender?

[MrFlibble]

It's my understanding that we need timer to add a URL that fits the same number of characters. If/when that happens, the installers can be 'fixed'.

Timer has created a new, shorter URL for us to use, which I've tested and it works successfully. The URL is http://mods.oolite.space/api/1.0/overview

MrFlibble, maybe this weekend you could break out your hex-editor and see if we've got a contender?

On it!

[MrFlibble]

I've done the easy bit and patched the MacOS zips. If someone can sanity check it please, I'll crack on with the library hell of the Linux versions.

The test version (oolite-1.90-Mac-TestRelease.zip (102.06 MB) ) and The plain version (oolite-1.90.zip (101.75 MB) ) will self destruct in 15 days.

If sane, we should be able to simply drop it in to the github 1.90 downloads as a replacement. I'd suggest tweaking the text there to mention the need to twiddle the config on windoze, and perhaps more explanatory filenames, particularly for the plain mac version zip.

I also note that in the MacOS version there's a reference to http://www.oolite.org/updates/oolite-mac-appcast.xml, which of course will be dead. I'm not going to dwell on the potential consequences of that.

[MrFlibble]

More fixed versions for sanity check and re-injection:
Here's a tweaked oolite-1.90.tar.gz (13.31 MB) and oolite-source-1.90.tar.bz2 (149.09 MB) Which both look like source code, though the latter has a bunch of png files in Resources/Binary/Textures, and likely other diffs. Anyone know what's going on there? Maybe another filename chage towards sanity required.

[another_commander]

The zip is created automatically by GitHub when a release is published. It is generated whether we like it or not. The bz2 is the tarball created by us and is the one you should download if you want to build from source.

[phkb]

I've done the easy bit and patched the MacOS zips. If someone can sanity check it please

I couldn't get the plain version to run on my Mojave Hackintosh. To double check I downloaded the current 1.90 Mac version and it launched without an issue. No error, just "The application Oolite.app can't be opened".

I'm downloading the test release now and will report back with further results.