Lots has happened since the last update.
Chiefly, Ikey has started up the blsforme project (Rust), which is a continuation and upgrade on the Clear Boot Manager project (C), for which he is now considering Solus the upstream. This will improve on its CBM predecessor in key areas, and will be able to replace CBM in Solus. It will also be used by moss to handle kernels and initramfs images in a sane manner in Serpent OS.
In parallel to that, Ikey bootstrapped the lichen Serpent OS TUI installer project. If you want to see the current progress, check out this YT video.
After tarkah returned from a well-deserved vacation, he took on the task of productising the graphical widgets and components that will comprise the basic building blocks for the underlying lichen TUI installer logic. Some of you may be aware that tarkah is a contributor to the iced Rust GUI toolkit, which is also being used to develop the COSMIC Desktop Environment. Tarkah recentely noted that the patterns he's setting up for the lichen TUI are pretty much the same as the ones in iced.
For the first iteration of the lichen Serpent OS TUI installer, Ikey will make it support exactly one configuration: GPT partitions, ext4 FS, bare iron install (no LVM or LUKS just yet, no other FS supported). It will also be using blsforme to manage the installed kernel(s). Having a deliberately locked-down target for MVP means that, once it is working, it should be easier to begin adding new FSes and LVM+LUKS support step by step in the future.
Reilly has contributed a bunch of Rust PRs that chiefly center around making moss and boulder builds reproducible. These will help with software supply chain security long into the future.
Joey has contributed his first Rust PR, which centers around enabling programmatic bumps of the (source)release field of stone.yaml recipes. In addition, Joey recently landed his first Solus stack upgrade built and pushed with autobuild (GNOME 46.2). His slightly incredulous summary was simply: "using autobuild feels like magic"
Gavin has -- apart from working on autobuild (as outlined in the last post) -- started up a new e2mf project, the goal of which is to be able to create an amalgam of Solus package.yml recipes, eopkg pspec.xml manifests and actual parsing of binary artefacts in exploded .eopkgs (which can also be done at the very end of the install phase in the Solus ypkg build process).
This work of Gavin's will potentially enable Solus to begin using current Serpent infrastructure (assuming Serpent does a bit of work to support it) or, alternatively, give Solus more insight into rebuild scenarios with no extra infrastructure requirements. I am pretty excited to see how this project will pan out, as it might prove useful in terms of giving Solus users a way to introspect these additional binary manifests with moss, and thus giving them a reason to begin getting acquainted with moss as part of a better, more streamlined Solus packaging process.
Fabio put up a couple of PRs for usysconf-rs that have sort of stalled, and we need to get this going again. The idea is to be able to use the same core logic for moss triggers in Serpent and triggers in Solus, as yet another way to "bridge the gap" and continually bring the Solus and Serpent projects closer to each other, thus making the Solus migration to Serpent tooling sort of incremental, rather than having to change everything in one fell swoop.
In parallel to all of the above, I was tapped by Solus to help with planning out and executing the move from their py2-based eopkg to their new py3-based eopkg port and the upcoming /usr merge "epoch bump" of the Solus repository. These tasks are each (in their own ways) hard prerequisites for Solus to be able to begin the migration to Serpent tooling.
The planning is mostly complete and the process is being tracked in a new room in the Serpent matrix space, which was created at Ikey's behest. This means we now have a place dedicated to discussing how to bridge the gap from both ends, rather than scatter these discussion around the more Solus operations-related channels like we did before.
The goal with this is not only to help Solus move off its increasing creaky underpinnings, but also to help inform the development direction in Serpent that will lead to the quickest productisation of tools, to the benefit of both Serpent OS itself, and to Solus as a downstream consumer/early adopter of the Serpent tooling.
In addition to that work, I have also tested and merged a few PRs and fiddled a bit with the Serpent infrastructure.
Stay tuned for more updates.
