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