github build woes

[MrFlibble]

I've just updated the linux static libraries bundle on my fork, which as far as I can see is otherwise much the same as the 'proper' master. I confess I've simplified the doxygen bit in actions, using the one in ubuntu rather than grabbing ti and building. Seems adequate, builds faster.

The build today failed at the doxygen step and build-linux. The first because github have deprecated actions/upload-file@v3, which was called in by actions/upload-pages-artifact@v2.. so I tweaked the one character required to fix that in the build-all.yml.

Code: Select all

-actions/upload-pages-artifact@v2
+actions/upload-pages-artifact@v3

That fixed the doxygen build.

However, something else seems to have changed in a breaking way. At build-linux (pkg-posix), we see:

Code: Select all

/usr/bin/ld: deps/Linux-deps/x86_64/lib_linker/libSDL.so: undefined reference to `pthread_sigmask@GLIBC_2.32'
/usr/bin/ld: deps/Linux-deps/x86_64/lib_linker/libSDL.so: undefined reference to `stat@GLIBC_2.33'
collect2: error: ld returned 1 exit status
make[5]: *** [/usr/share/GNUstep/Makefiles/Instance/objc.make:79: obj.spk/oolite] Error 1
make[4]: *** [/usr/share/GNUstep/Makefiles/Instance/objc.make:64: internal-objc_program-all_] Error 2
make[3]: *** [/usr/share/GNUstep/Makefiles/Master/rules.make:297: oolite.all.objc-program.variables] Error 2
make[2]: *** [/usr/share/GNUstep/Makefiles/Master/objc.make:36: internal-all] Error 2
make[2]: Leaving directory '/home/runner/work/oolite/oolite/oolite'
make[1]: *** [Makefile:142: deps-release-deployment] Error 2
make[1]: Leaving directory '/home/runner/work/oolite/oolite/oolite'
+ make_rc=2
+ '[' 2 -ne 0 ']'
+ exit 2
make: *** [Makefile:215: pkg-posix] Error 2
Error: Process completed with exit code 2.

Of course that's not the whole log, but I see only warns and notes above.

Anyone "in the know" got a minute to have a proper look please?

https://github.com/OoMrFlibble/oolite/a ... 38628#logs


Problem solved-ish. I commented it out in the lib_linker script, as it wouldn't have been there/done anyway.

Perhaps lib_linker needs updating/reconsidering? Maybe we could use that as a good place to grab all the static bundle of libs? That might help if building on an even older platform with a view to making a flatpak or appimage.

[MrFlibble]

GitHub:

We will soon start the deprecation process for Ubuntu 20.04. While the image is being deprecated, you may experience longer queue times during peak usage hours. Deprecation will begin on 2025-02-01 and the image will be fully unsupported by 2025-04-01.

Which basically means we'll have to either build elsewhere, or accept that backwards compatibility with systems which will still be supported for a few years, will break.

I suppose some horrible workarounds involving a chroot or proot installed older OS (if actions supports that) could be employed to preserve backwards compatibility.

[hiran]

GitHub:

We will soon start the deprecation process for Ubuntu 20.04. While the image is being deprecated, you may experience longer queue times during peak usage hours. Deprecation will begin on 2025-02-01 and the image will be fully unsupported by 2025-04-01.

Which basically means we'll have to either build elsewhere, or accept that backwards compatibility with systems which will still be supported for a few years, will break.

I suppose some horrible workarounds involving a chroot or proot installed older OS (if actions supports that) could be employed to preserve backwards compatibility.

Not sure about the meaning for the community .

For me Oolite does not have to be backward compatible. I have decent hardware with an up to date OS. But Oolite won't run. It never did on Ubuntu 24 LTS.

So my OS is not compatible, I cannot fix it but at the same time it is ok. It could just mean that anorher platform is gone.

[Cholmondely]

Backwards compatibility

For me Oolite does not have to be backward compatible. I have decent hardware with an up-to-date OS. But Oolite won't run. It never did on Ubuntu 24 LTS.

So my OS is not compatible, I cannot fix it but at the same time it is OK. It could just mean that another platform is gone.

It certainly used to matter.

Having spent hours poring over the old threads, one constant theme which comes up time and time again is that many people were using old computers/old versions of operating systems.

Even now, I use a 5 year old AppleMac and stubbornly refuse to update my OS (my updating experiences are miserable. Miserable.). But there are similar statements from Wildeblood (mChat archive: Wildeblood • Mon Feb 17, 2025 10:26 am) and Cody said something similar to me a month or so ago.

I'm willing to accept that it might be different for you Linux types. You all seem to be computer whizz-kids who prang your prams at the drop of a hat (I gaze at Mr Flibble's declarations in a mix of befuddlement, bedazzlement, bewilderment and bemusement).

[Wildeblood]

I gaze at Mr Flibble's declarations in a mix of befuddlement, bedazzlement, bewilderment and bemusement.

It's the begonement that will really get you; when you start sensing begonement, it's time to worry. As ever, a clear statement of the problem would help: what do you seek to make compatible with what?

Should the leading edge version of Oolite be compatible with:-
The most OS versions possible?
The most popular OS on new computers being bought today?
The most common OS globally?

Should the most recent, presumably most feature-rich, version seek to satisfy that desire, or is it sufficient that a version does?

[MrFlibble]

Should the leading edge version of Oolite be compatible with:-

Within the Linux scope of that, I'm aiming for broadest compatibility. Linux is a broad bazaar of platforms and 'current' versions.

Stable (1.90) would ideally in the package managers of major distros, if of course they can be encouraged into finding devs to take it on. For most distros there would be little work to do. The same could be done going forward if we nailed down a 1.92.

Those who want bleeding edge are more likely to make a little extra effort. For example, those with Gentoo are unlikely to have problems building from source, or even making an ebuild file to simplify the task for others.

The majority of those for whom it does not work, are unlikely to bother joining the forums to let us know.

The current state of play on the github 1.90 version binaries: It will work nicely on a very small range of distros. The 1.91 when built by github actions will soon only work on the latest Ubuntu and some contemporaries, leaving the rest behind, even if they are still 'current'. Not so funny when the majority are likely to be among "the rest", using for instance LinuxMint 21.3, which is supported for a few years yet, or the previous version of Ubuntu. The reason for this limitation is largely that nobody has checked the bundled libraries for a while, and github keeps changing the 'current' ubuntu build platform on Actions, so it'll only work where the hosting system is a close relative of the build system. Also of note, the github "Actions" system tends to phase-out build systems long before they diminish in the field as client systems.

We could:

• provide source and instructions (least friendly) We do this.
  [*}a universal installer built on the oldest platform one can muter with bundled libraries (medium friendly) We sort of do this.
  [*}build per platform installers/packages (best)

We don't do this at all, though we might be able to trivially do it for contemporaries of the build host.
The middle option, the universal installer, could equally be an AppImage built on the oldest platform available for broadest compatibility.

For the 'universal' binary of the newer on Github, my fork has refreshed bundled libraries to make it function on a broader range of distros. I just sat down with a couple of VMs and picked the fluff off the Linux dependencies. Building on an older platform would be even more universal. If it is built on the latest platform, no amount of bundled libraries will help. In a couple of months, github actions will force that to be, unless we use an external build host (A small VM could do that, and I can provide if needs must).

Only building a version which will only work on the latest version of the most popular platform might make some sense for e.g. Windows, but it's never likely to be the right way ahead on Linux.

Wow! Has anybody got a ladder? This horse is higher than I'd anticipated.

[hiran]

Well you cannot blame Github for just providing the latest version for each operating system. After all they provide it free of charge.

If you want other (older) operating systems noone stops you to setup and maintain that infrastructure.

The fact that noone is doing it - not even those asking for it - tells me it is not worth the effort.
But besides all that the Oolite project is not even capable of making use of the free offering.

Just a side note: my computer is 8 years old, running the latest Ubuntu Desktop. Why should I keep sitting on some old OS if the new one comes for free?
Compare that to a five years old Mac.

So my suggestion:
Build Oolite on the free plan of Github.
Ubuntu latest is 24. There is also Ubuntu 22. Make them as shiny as possible.

If efforts allow setup alternative systems to provide builds for other Linux distributions. Or finally package as Flatpak, Appimage or Snap. There are choices but I do not see movement in any direction.

[MrFlibble]

Well you cannot blame Github for just providing the latest version for each operating system. After all they provide it free of charge.

Github do things for free. I appreciate it. Mercifully, they also keep more than one version alive. Unfortunately they obsolete platforms before they are retired (unless I suppose, you're willing to pay).

If you want other (older) operating systems noone stops you to setup and maintain that infrastructure.

I'd consider setting up a VM to do it. If we wanted to go Appimage, that would be a desirable way ahead as building on a recent platform rather limits the range of compatibility.

One point which I hope doesn't go unnoticed... those for whom it does not work at first attempt, are unlikely to bother sticking around to say so.

Is 1.90 still working on newer distros? I've not tried it for yonks.

The fact that noone is doing it - not even those asking for it - tells me it is not worth the effort.

I'm not sure exactly what you mean by that. A lot of folk who want a thing, and ask for it in the forums or github issues, are not themselves necessarily clued-up or tooled-up enough to achieve it.

But besides all that the Oolite project is not even capable of making use of the free offering.

It is though isn't it? Please clarify.

Just a side note: my computer is 8 years old, running the latest Ubuntu Desktop. Why should I keep sitting on some old OS if the new one comes for free?
Compare that to a five years old Mac.

I get the Mac reference.

I don't feel it's that simple.

Most of mine are older I'm not an average user by any means, but why would I upgrade my (non rolling version) free OS when I don't need to? I update it. It's still supported, gets sec updates, and is stable. Oolite was working fine on it (still is for me!). There's no practical reason beyond having more recent versions of certain software like LibreOffice, which would help me decide to upgrade if/when it mattered to me.

Anything new that I set up, be it metal or VM, is always the latest of whichever distro I need to use, rolling distros where appropriate.

But I have a few existing setups using earlier, still-supported distros, which are not (currently) worth the faff of upgrade. My very portable and stable netbook would be a right pain to dist-upgrade, so I'll put it off as long as sensible, and may even retire it in a year or so. My current laptop of choice has quite a lot going on which would need re-doing if I go to the newer distro, so I have cause to hang back.Of course, I'd migrate upward before the OS devs stop putting out sec updates.

I'd like to see Oolite working, out of the box, for as many casual Linux users, on as many distros as possible.

So my suggestion:
Build Oolite on the free plan of Github.
Ubuntu latest is 24. There is also Ubuntu 22. Make them as shiny as possible.

That seems the most obvious route, at least for now.

Simply building on the oldest version (available on github for free) and bundling the appropriate libs, allows it to work on both current/previous Ubuntus and other vaguely contemporary platforms. I see no extra 'shine' if it breaks for existing users, or precludes some potential new ones without good cause.

Of course, with the current setup, when github force dist-upgrade, Oolite can switch it up one level, and tell people they must upgrade, build from source, or lose out. I suggest though that instead of setting 'ubuntu-current' or whatever wildcard, and getting nasty surprises when github switch things, the project continues to specify a particular version OS for build. That makes it easier to peg the static libraries, and grants wider potential audience.

My fork only involves changes to the Linux static library bundle, and already works on a lot of platforms where the upstream will not. I'll have to redo that when the build host changes. I do not mind.

If we get the static bundle right, and build on oldest available (freely of course!), the installer version should work without having to add [m]any packages on most potential (current) target systems.

If efforts allow setup alternative systems to provide builds for other Linux distributions. Or finally package as Flatpak, Appimage or Snap. There are choices but I do not see movement in any direction.

I'm trying to move a bit in that direction

Re: Appimage. The recommendation is to build using the oldest platform sensibly available, to allow compatibility from that point on. The goal being broadest compatibility, not only across distros, but also versions. An off-github build host would become a must. It might not be worth the effort, but its hard to gague potential uptake, when we don't know how many have already 'walked on by' for things not working on their distro of choice.

There are always some folk such as us who would gladly build from source if no other option existed. For my stable laptop, it looks like that's what I'll be doing in a couple of months.

It'd be nice to have an idea of the size of our current Linux user-base.

[hiran]

I don't know why Oolite - compiled on Ubuntu 20 or 22 does not run on 24. Only guessing it's related to gnustep.

Even more irritating is the fact that Oolite compiled on 24 does not run on 24.

There is nothing limiting us to only one build that runs everywhere. Yes, favorable.
But still we can run the build system for every Ubuntu flavor they offer.

[MrFlibble]

I don't know why Oolite - compiled on Ubuntu 20 or 22 does not run on 24. Only guessing it's related to gnustep.

Either you've misunderstood, or I fumbled what I said... It is forward compatible.

The libraries that were bundled were all obsolete or absent. That's why folks had to install gnustep-base even though a (wrong) version was bundled. It would only run on the same version as it was built on, and why seemingly random packages needed to be installed depending on distro/desktop.

If the right libs are bundled, it will work on newer distros than that on which it was built with few or no extra packages required. Tha advantage of bundling the right libs extends to it working on other contemporary platforms.

Even more irritating is the fact that Oolite compiled on 24 does not run on 24.

It does. However, even with all the libraries bundled it still cannot work on 22. Builds are not backwards compatible. That's the problem I'm trying to point out. When GH turn off 20.04, only 22 and up will be supported by the resulting binaries.

20.04 ends standard support in April, so I withdraw that github are entirely premature. It does have extended security updates until 2030 however, so could arguably serve as a base way down the line.

Switching to 22.04 is no hardship. It has two years of shelf-life left. I'd got my versions "out by one" due the the difference between Mint and Ubu versions. That horse just got a little closer to the ground.

There is nothing limiting us to only one build that runs everywhere. Yes, favorable.
But still we can run the build system for every Ubuntu flavor they offer.

If we use the oldest they offer, then we'll be getting the most coverage for our efforts, and only need to build one, as it's forward compatible.

My fork is an attempt to sort out the library bundle. I'll do a branch for 22 ahead of the April switch. The only other real change I've got on mine is using the doxygen provided by ubu rather than building it from scratch every time. It was failing, so I made it 'stable', (and simpler).

To cover the most systems would require a build system outside github. Shouldn't be too much of a pain to do that for the rare stable versions, and maybe a few major milestones of dev. Even if it's just hand-rolled and uploaded it'd not be a major effort.

[MrFlibble]

But still we can run the build system for every Ubuntu flavor they offer.

I just registered that bit in a different way.

If the user-base is (or might become) large enough, I suppose we 'could' do deb packages per github actions supported Ubu, maybe even a PPA.

The "one-binary installer to fit all" is still worth having, as not all Linux boxen are Ubu based, and it's a chance to get those users aboard a step short of having to build from source.

I've sometimes mentally switched off my experience of installing Oolite, to mindfully walk the path of a naive user. There are many pinch-points, crossroads, and cul-de-sacs where fear, uncertainty, and/or doubt might deter Joe Sixpack. My goal is to help fix those up, to get more budding commanders finding their space legs.