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.