Gitea: A brand spankin’ new SCM

I’ve long complained about how painful Gitlab has been since it was brought in, and fought the “necessary evil” battle in my head repeatedly, and then, sure enough, another change was required that would have required redoing a bunch of configuration work I’d put into it, so, instead of resolving the outage by continuing to polish the turd, I’ve decided to replace the product altogether with a fresh install of Gitea.

Gitea seems nice so far, it seems to solve most of my pain points with Gitlab, though it has a few of its own, but they’re much easier pains to live with.

It seems a lot more receptive to theming too:

So, I guess now I have to go make a bunch of maintenance and link updates :/

Public Request for Feedback

Today I’m opening up a channel for feedback from anybody who might be reading this to see what people think about some filesystem adaptations that I am considering making.

During the building of a linux system, many of the created shared objects and other files get copied around to end up where they’re supposed to be after they’re compiled, and some things can be in multiple places; so I think it would be a much cleaner arrangement to set up some symlinks for things that can be in multiple places, so that there is only one real place that any of those things be.

For example, a symlink at /bin that points to /usr/bin. And a symlink at /lib that points to /usr/lib, /lib32 -> /usr/lib32, /lib64 -> /usr/lib64.

The full list I’m considering is:

  • /bin -> /usr/bin
  • /lib -> /usr/lib
  • /lib32 -> /usr/lib32
  • /lib64 -> /usr/lib64
  • /sbin -> /usr/sbin

I don’t think this would violate the FHS, or the LSB, both of which are goals of this project.

Let me know! You can use the SURRO Linux mailing list at:

Or, if you’d prefer to be more direct or private, I can be emailed at

Progress Update

I felt like the container stuff was getting in the way, so I pulled all that out for Variant D and intend to reintroduce that layer when I have a functional system being generated.

Source Code is at:

At this point a functional CHROOT is compiled and I’m in the process of bootstrapping the rex call to a second stage rex execution from inside the context of the chroot.

One of the reasons Rex is really good at this is that it allows you to create a different environment for different scripts, and change the executing user and other factors that allow you to turn otherwise manual processes across several environments and contexts into just one that’s configured.

Kudos to the LFS project for the progress so far, as creating the toolchains for the chroot would have been much harder to learn if I hadn’t studied and borrowed chunks of their book’s process. Also special thanks to DJ Lucas from that project, whose patient guidance and training early on was invaluable to just getting to this point. I have frequently through this process run into obstacles and remembered conversations with him, that ended up helping to solve those obstacles.

From here it looks like I’m kind of on my own, as I had to change how some things are done, particularly the order in which components are made available on the chroot system in order to make rex able to even be executed. So, this is crossing a bit of a landmark of sorts into what seems to me to be uncharted (or at least undocumented) territory.

Fortunately, the D-Variant got this project almost to the M3 milestone, so, it’s almost out of the “endlessly f*cking with gcc and glibc build scripts” phase. I’m pretty excited about that part, because it’s the least interesting and least fun thing I can imagine being done on a linux system. I want to work on the package pipelines.

Things are moving rapidly now, but, I don’t want to promise on a timeline. It feels like 2-6 months for a bootable demo.

I’ve lost and regained my desire to work on this project several times since it started.

Quiet, Rapid New Progress

Late in the week last week, the barrier to a cross toolchain with glibc finally became unkinked after so long a time of looking at it that I don’t even want to go back and check to see when it first came up.

Since then, I’ve been able to rapidly progress through the steps of generating a sysroot from raw sources and have been building out the rest of the system.

There is unfortunately nothing to download by way of bootable isos yet, but, I expect there will be by this time next year, and some time before then I will be releasing the project for generation of a full system for those builders out there who might be interested.


The GPG Key ID for Chris Punches (phanes/bagira on irc) is:


It has been brought to my attention that someone on the Libera network is impersonating me on Libera.Chat using the nick phanes.

If there is any doubt about the authenticity of someone claiming to be me, the above credentials can verify my identity.

Advent Rex

Up until this point I’ve been building the prototype tool called Examplar while establishing requirements with the Foster build. For those of you just joining, Foster is the set of scripts and data that will generate the ISO or container for SURRO Linux.

I am pleased to announce that the Examplar name is now officially retired and will now be called Rex. It has been polished up, and can do some really neat things for large scale automation.

It’s source can be downloaded at the following URLs:

The primary repository is on our personal gitlab and the github repo is a downstream mirror so that we can get github users filing issues on its built-in tracker.

There are significant changes that needed to be made to get this tool from where it was when this project started to a usable product for this use case, so, it’s good to finally get it out of the way; I will now shift to just using it hopefully for the Foster builds I keep talking about so much while I knock out any bugs that come up from the issue tracker.

Really glad to get this piece in place, finally.

It is requested of anyone reading who can, to please review the code for potential improvements, file issues for potential problems (it is an alpha even though it’s 4th gen at this point), and let me know. Issues are filed on the github mirror for the time being.


Mailing List Changes

After some consideration, I’ve decided to make some changes to the mailing list details for SURRO Linux.

While it’s not yet being used very much, I felt that using the term “greybeards” could potentially be excluding women from participating.

That, and, it turns out, as I learn more about how to facilitate an open source project, not all contributors contribute. I’ve been going about this all wrong — we should be trying to maximize the number of contributors to get that occasional pull request instead of trying to form a team of people who will do things regularly.

So, I’m disbanding the concept of a “greybeard” contributor and any associated roles, and now we just have “contributors” and “non-contributors”. If you don’t contribute, you’re a “non-contributor”.

The new mailing list is at:

Contributors and non-contributors are welcome to sign up and help out.


Official Gitlab Relocated

If you’re one of the reviewers, you’ve probably noticed that the is throwing an error. That’s because it is now a CNAME record pointing to

It was inevitable — the SURRO Industries name, while well intended, doesn’t reflect well from a branding perspective, and this really should be under the SILO GROUP name.

So, moving forward, source code repositories for all SILO GROUP owned projects not on github will exist at

Significant Updates: A working Cross-Compiler

I’m excited to announce some significant progress on this effort since my last post.

After a couple years of frustration trying to figure out a way to design this process in a way that does not involve how LFS does it, which is problematic in so many ways between poor documentation in the binutils/gcc/etc docs, and the arduously inflexible documentation from the LFS project, I’ve decided to go a different way and test this out in a prototype called “Foster-B”.

Intended to be a place where I can hack away without destroying my existing codebase with experimentation, I opted instead to litter the internet with various repositories of experimental sessions, in this case called Foster-B where I wanted to see if I could “outsource” the responsibility for maintaining the cross-compiler pieces to another entity without compromising SURRO’s “not based on another distro” requirement, like BUILDROOT would do.

At this point Foster-B has a working cross-compiler inside the container residing at /opt/crosstools.

The cross-compiler provider is the crosstool-ng project. It’s pretty clumsy but I got it working. And this should bring us up to the point in the process where LFS would be in about their chapter 6 using a method that is actually designed to be automated without potentially gutting the user’s host system.

This one part required a rather large investment of time and it’s not even done yet. I still have some cleanup to do, and I still need to use the cross-compiler to compile a chroot, which is actually a much easier task.

I think we’re through the “hump”, though, and I’m excited about days to come when I can be in that chroot building out the SURRO Linux proper.