Tested both x64 and x86 in Windows 11 Sandbox. All good, seems to be packed fine, run fine, download OXPs fine. Good stuff.
Thanks a_c.
So, does that mean we now have functional replacements for all the 1.90 release binaries/zips? Is the replacement process as simple as removing the old ones and uploading the new ones?
Edit: actually, we'd need to recreate the MD5SUM file, wouldn't we?
So, does that mean we now have functional replacements for all the 1.90 release binaries/zips? Is the replacement process as simple as removing the old ones and uploading the new ones?
Note that after updating the new deployment build to Test Release using the Windows updater utility for v1.90, the resulting executable is back to failing at downloading expansions. This is because it gets reverted to the "old" test release exe which still contains the wrong expansion index download location.
These updaters don't function correctly. They install the Test Release version of the executable in the Oolite root install folder and just make a copy of the deployment oolite.exe named oolite.exe.dpl inside the oolite.app folder.
What they should do is: The TR executable should go directly to oolite.app and there should be a backup of the original deployment exe named oolite.exe.dpl in the same folder. No executable should be placed in the root Oolite folder.
Additionally, there is no installation of the Basic-debug OXP at all. This must be included.
The file installers/win32/DeploymentToTestReleaseUpdater.nsi contains instructions on how to set up the files before running the updater generation script:
# When running this updater, the following folder structure must
# exist directly below the updater's folder:
# OoliteRootFolder
# |
# --AddOns
# | |
# | --Basic-debug.oxp
# |--oolite.app
#
# Basic-debug.oxp should contain the Debug OXP files, while
# oolite.app should contain only the Test Release executable.
# The updater will pack everything it finds below the folder
# named OoliteRootFolder, so it is important that the folder
# structure be maintained.
You should then be able to generate the updater by just running: makensis /DOOVERSION=<Maj.Min> /DOOLITEDEPLOYMENTSIZE=<bytes> /DOOBITNESS=[32|64] DeploymentToTestReleaseUpdater.nsi
where OOVERSION is 1.90 in this case, OOLITEDEPLOYMENTSIZE is the size of the deployment executable to be patched in bytes (use file properties to get that from Windows) and bitness is either 32 or 64 depending on which flavor of the updater is being generated.
OK, fixed, I think! I blame post-op meds and lack of sleep. Definitely not that I was rushing and not reading things carefully. I mean, who does that, really?
Now we're talking. These two work perfectly. I even tried updating the original (now bad) x64 1.90 depoyment installer and it updated it successfully to the new and correct 1.90 test release. So even if someone has downloaded 1.90 in the past they can now just run the 1.7MB updater to test release and it will work.
So, I now have, on my local machine, a replacement file for everything in the 1.90 release assets folder, including an updated MD5SUM file and oolite-source-1.90.tar.bz2 file (with the tweaked URL updated). Are we comfortable with me replacing the existing files with these updated ones, and then adding something like this to the description at the top:
24 June, 2025 Note: The original 1.90 release referenced a now defunct web URL for downloading OXP's. Due to ongoing build issues, we are unable to rebuild all the 1.90 binaries for all platforms with a correct URL in place. Instead, we have adjusted the binaries to the correct URL, so all of these downloads should work out of the box, with no further steps required to download OXP's.
Are there any additional steps we need to perform?
This is with the understanding that there are two entries (Source code (zip) and Source code (tar.gz)) that I can't update directly.
Personally, I think it would be better to have all these updated, even with the discrepancy noted with those source code downloads, and deal with any questions on the BB, given the confusion the existing fix (editing text files, running command line processes etc) creates for some users.
Are we comfortable with me replacing the existing files with these updated ones, and then adding something like this to the description at the top:
24 June, 2025 Note: The original 1.90 release referenced a now defunct web URL for downloading OXP's. Due to ongoing build issues, we are unable to rebuild all the 1.90 binaries for all platforms with a correct URL in place. Instead, we have adjusted the binaries to the correct URL, so all of these downloads should work out of the box, with no further steps required to download OXP's.
Normally I would not feel comfortable with replacing files in an already existing release. Under normal circumstances this can lead to support hell, where people might be reporting bugs related to the "old" version while those handling the reports would have no way to distinguish the old from the new version. Typically this would be mitigated by making a new 1.90 release, something like 1.90.1 and it still may be worth considering this path. However, it is clear that the situation we are faced with here is anything but normal. I don't think I've ever seen anything similar anywhere so I can totally understand if some rules or best practices have to be bent.
In any case I think that the part of the notice about ongoing build issues should be removed - no need to justify anything to anyone in my opinion. Just say that the binaries have been adjusted to the correct URL and that's it.
Are there any additional steps we need to perform?
This is with the understanding that there are two entries (Source code (zip) and Source code (tar.gz)) that I can't update directly.
Personally, I think it would be better to have all these updated, even with the discrepancy noted with those source code downloads, and deal with any questions on the BB, given the confusion the existing fix (editing text files, running command line processes etc.) creates for some users.
I would not worry about the auto generated zip files at all. I mean, even now they are unusable for anyone trying to build from source because they do not contain the submodule files required for the build.
As a final comment I believe that any effort spent on making a new release at this point in time, 5 years after 1.90, would be better channeled towards a 1.92 launch. We are very close to getting Linux going on all distros again and the website needs some prep work for a new version. The code is stable enough for a new release even today, therefore putting effort into that would probably be more productive in the long run. All this is said with the hope that someone else takes over the coordination of a new release - we need to train more people for this and here is a very good opportunity.
We are live! All binaries for 1.90 should now work out of the box when downloading OXP's. I've tested the download links from the oolite.space website and everything appears to have linked up successfully!
We are live! All binaries for 1.90 should now work out of the box when downloading OXP's. I've tested the download links from the oolite.space website and everything appears to have linked up successfully!
Thanks to input from mcarans I've further tweaked Linux-deps. New version here.
Syncronised with upstream and re-did the actions script to not build windows version and use distro package of doxygen to save a job. Pulled in additions to oolite-binary-resources.
New changes to static libraries included with linux-deps:
Moved libesound.so.1 to libesound.so.1.alsa, made a symlink named libesound.so.1 pointing to libespeak.so.1.pulseaudio. Most modern distros have pipewire with pulseaudio compatibility, and not all have the pipewire-alsa package installed. This seems a better default now. Unfortunately the symlink gets dereferenced somewhere between source and installation. I feel that the copied file at 231648 bytes to make things clearer is no real shame.
Removed libopenal.so.1 as it doesn't seem to function standalone. On distros that don't already have it (e.g. minimal installation of lubuntu25.04) you'll need to install it : apt install libopenal1
