A lot of people have been commenting on this over time so I figured I would put together a little post summarizing my thoughts on the matter and everything else.
The post is going to be quite large. Every section can be read more or less separately, but they are all connected to each other.
Chimera is a small project. It exists primarily to serve its community and not any external entity.
Making sure the maintenance cost is as low as possible is crucial. Chimera and its tooling are designed to automate away most of the boring stuff and make sure the packager’s job is pleasant and not bothersome. In a way, we aim to empower every user to be a packager. The barrier of entry is meant to be very low.
Some things that implies (I will try really hard to make this reasonable to follow, unfortunately the years have left their mark and I might be taking some assumptions for granted, so please bear with me; this also applies in the later sections):
cbuild is extended to mitigate them. Feedback is
taken into account.cbuild. One tool does everything, in a streamlined way.
Managing the repository, the build environment, the repo generation
and signing, even parts of the VCS handling and common maintenance tasks.
No external helper stuff.cbuild and not much else.cbuild is a developer tool, not a user tool. But every
user can be a developer.A common workflow setting up everything from scratch would look like so:
$ # set up environment with your cports fork
$ git clone https://github.com/my-user/cports
$ cd cports
$ # prepare a signing key
$ ./cbuild keygen
$ # prepare a build environment
$ ./cbuild bootstrap
$ # write your template here; then build it
$ ./cbuild pkg user/my-cool-program
$ # make a branch for submission
$ git checkout -b my-cool-program
$ # automatically makes a commit with the correct message and all files included
$ ./cbuild commit user/my-cool-program
$ # push and publish PR with the link
$ git push origin my-cool-program
An update would be done like this:
$ ./cbuild bump-pkgver user/my-program 4.20.69
$ ./cbuild prepare-upgrade user/my-program
$ ./cbuild pkg user/my-program
$ ./cbuild commit user/my-program
$ git push
The tooling provides common utilities for keeping your local repository clean, e.g. pruning packages and so on; it provides maintenance tools for bumping versions and revisions, checking dependency graphs, checking for new versions via update-check (which for most things distributed e.g. via common git forges requires no extra effort or specialized code), checking if your local repository can be unstaged against the remote one (verifying if you really rebuilt everything that needs it), updating sha256 checksums in templates. It even supports custom template-specific actions, such as building bootstrap tarballs for compilers. It supports aliases for less typing.
Checking for if a package has an update:
$ ./cbuild update-check main/firefox
main/firefox: 157.0 -> 157.0.1
It supports fun things when it comes to packaging bulk batches. For instance, it integrates git:
$ # build everything changed in your local commits
$ ./cbuild bulk-pkg git:origin/master..HEAD
$ # build a specific commit
$ ./cbuild bulk-pkg git:commithash
$ # build a range of commits but skipping stuff that has "test" in commit message
$ ./cbuild bulk-pkg git:from..to+!test
It supports common stuff, like
$ # build everything you have in your local repo that has a newer cports version
$ ./cbuild bulk-pkg status:outdated
There is a lot more that I could mention. I also wanted to talk about how we got here, how we started, and how our infra works.
I started using Linux in 2006/7 and soon ended up on Debian as my long-term operating system. Around the same time I started to seriously get into programming and the intersection of that ended up being packaging for Debian. Debian has a large bunch of tooling to deal with packaging and particularly the community-driven approach really appealed to me so I maintained a bunch of packages for a while. That lasted for some time until I drifted away towards other things and eventually settled on FreeBSD.
During that time I didn’t do any work for the FreeBSD project itself but I did experiment with various things that were adjacent, none of them going anywhere in the end, but I did gain a lot of helpful experience on the way.
In 2016 I started messing around with Void Linux (particularly as I had to use Linux on work computers) and around 2018 I ended up using the ppc64le (POWER) platform for my workstation, which FreeBSD did not support at all at the time. I was already familiar with Void and decided to start a ppc64le port, which I maintained downstream until 2023 and gradually it expanded to support the big endian ppc64 as well as the classic PowerPC. Doing the downstream work led to me becoming an upstream Void maintainer as well and I took care of the compiler toolchains among other things for several years and became interested in improving the build tooling.
In 2021 I started the Chimera Linux project, which gradually got better and more usable, and that led to me shifting entirely to that, deprecating the POWER port of Void and resigning from the Void team in 2023.
When I started using Void in 2016, it mainly caught my attention as a system with a fairly low barrier of entry that did not get in my way, while still being “normal” enough to act as a regular Linux system. Initially I found the way e.g. runit worked in there interesting and in many ways fresh over classic distros particularly in the pre-systemd era, while I found the post-systemd era rather unfun and daunting in general.
This was also why I ended up picking Void for the ppc64le port, as it felt small scope and approachable enough to give me a chance to reasonably maintain it by myself, while also having a compact and easily reachable community that wasn’t aligned with any particular commercial entity.
When I started the ppc64le port, I was already marginally familiar with the build tooling of Void but only really properly picked it up for the port.
For someone coming from most other Unix-like systems, xbps-src is really nice.
In Void, all the packaging of the distro, along with the build tools, exists
in a singular Git repository (void-packages). In a way, this mirrors the
ports systems as they exist on the BSDs. However, the ports systems are based
around Makefiles and you interact with ports individually using make (with
various external ports management tools existing to simplify that, working
on top of that).
In Void, software is packaged using “templates”. Every piece of software
consists of a template containing metadata fields (you know, package name,
version, dependencies, source URLs, etc.) plus (optionally) functions that
define the logic of how a template is built, along with extra files that are
necessary for the build (not always) and patches (not always). The tooling
for building templates (xbps-src itself) also exists in this tree.
Unlike most other systems, when you build a package, the build process does
not run in the system you are running the build on. Instead, xbps-src
constructs a small container (using Linux namespaces) that represents a
minimized Void system, puts stuff in it according to the template metadata
(build dependencies and whatnot) and then runs the build. At the end, you
get a local repository of xbps packages that you can install from.
The general workflow looks like this:
$ git clone https://github.com/void-linux/void-packages
$ cd void-packages
$ # create the build container
$ ./xbps-src binary-bootstrap
...
$ # build the thing you want
$ ./xbps-src pkg some-program
...
The templates are similar to e.g. PKGBUILD format of Arch Linux or
APKBUILD format of Alpine, but those do not use the containerized
approach (at least not always).
The xbps-src system is a collection of Bash scripts, and technically
the templates are also just Bash scripts, but with a set of expectations
so they in general do not utilize the full extent of the syntax and features.
When working as a packager, you basically just create a new directory in the
srcpkgs, put your template in it along with other stuff, build it, and
then you have a repo you can install it from. If you wish to submit it
upstream, you create a branch, commit it, and create a pull request.
Someone will take a look at it, and if it gets merged, the central build
infrastructure picks it up and shortly it becomes available in the central
repository.
The system neatly decouples build dependencies and runtime dependencies, with runtime dependencies typically scanned automatically from ELF files and their metadata as well as other file types, so the template specifies whatever it needs in the build environment but the runtime dependency list is largely automatic.
The system supports “build styles” so you can e.g. declare that a template uses the GNU Autotools, or Meson, or Cargo, or whatever, and it takes care of most of the groundwork, allowing for templates that are often declarative without any build logic, lowering that barrier of entry.
It also supports cross-compiling really well, letting you cross-build most of the repository to any other architecture. That’s neat, but often sloppy, and cross-built packages end up with subtle brokenness that native packages would not have, due to build systems subtly not passing certain checks and so on. You also can’t run unit tests for projects when cross compiling them, in most cases.
The system also has a really handy update-check mechanism which will scrape
upstream URLs and find version infos in them, then present you with any updates
that may have happened since the last template version update. The project has
a nightly job which generates a summary once per day, letting packagers stay
on top of things.
The build infrastructure of Void consists of several computers (each handling
a different architecture port) that are plugged as workers into the central
orchestrator, using the Buildbot software. It will
receive updates from the Git repository (void-packages), collect a batch
from the changes, figure out the correct order, and use xbps-src to build
the packages.
It will also sign the packages with the right keys. This is a separate step
that xbps-src does not handle (the output is unsigned). Eventually, things
make it in the upstream repository and get mirrored.
The way the Buildbot is managed I can’t tell you much because I never saw
much into it. The admins have an infrastructure that is based on Ansible,
Terraform, and a bunch of other pieces that are put together in ways unfamiliar
to me. Additionally, xbps-src does not do the batch sorting for you, so
other pieces of the process have to do it. Things outside the void-packages
repository itself are relatively opaque.
When I maintained the POWER port, I had my own set of scripts to keep things going and did not reuse any of the Void infrastructure at all. This was likewise opaque and purpose-built for my port.
In early summer of 2021, I started Chimera. The initial push for me was that I wanted to experiment with a different userland setup, as well as have a more personal project to work on without having to deal with others’ efforts and pre-existing work, but also I wanted to try out my own take on the build system.
There were some initial points I was unhappy with in xbps-src while
maintaining the POWER port.
xbps-src and employ various caching tricks
to make things manageable.xtools repository, including extra lints and so on. This is not
mandatory or anyhow verified however.sed calls and similar rather than
using proper patches (which leaves in calls that eventually no longer do
anything due to upstreams changing), patches are applied very fuzzily which
occasionally results in subtly mispatched things, and so on.musl targets and so on. It does run them in
pull request CI, but I do not see this as enough. Often the check runs of
templates are poorly maintained and broken.x86_64 and
i686, resulting in the other-arch ports being notably lower quality.There are others but these were my main gripes.
Chimera started with its build system. Many experiments were done. Initially,
cbuild was a ground-up rewrite of xbps-src, using Python. In cbuild,
the templates are also Python scripts, but through low-level bits that Python
allows, don’t always look as such. It came with a very minimal set of initial
packages that was basically a basic Void-like chroot, using xbps as its
package manager. Thus cports was born.
There were two initial goals:
bwrap). The
cbuild system runs outside the sandbox (in your host environment) while
any calls to the build system of the project being built are sandboxed.cports on any Linux system with the basic dependencies.xbps-src can do, but better.Chimera started with the ppc64le target only, being developed on a POWER
workstation. Over time, as things cleared up more, more targets were added,
along with additional goals and other changes.
Over the next months, the core packaging started to become more defined,
settling on the userland tooling and other things, as well as transitioning
from xbps to apk. The original idea was to use pkg from FreeBSD, but
this proved to not be ready for our style of use at the time, and upstream
suggested that we’re best off using something else.
Fundamentally, using cbuild in the basic sense feels similar to xbps-src.
The big difference is that cbuild signs everything, not needing a separate
step, and no unsigned packages are allowed. Therefore, initial setup looks
more like
$ # generate your signing key
$ ./cbuild keygen
$ # bring up the container
$ ./cbuild bootstrap
$ # package whatever you want
$ ./cbuild pkg main/firefox
We didn’t stay on xbps for very long. Soon, the switch happened to apk.
Using apk brought over various benefits.
xbps which is driven by ad-hoc logic, apk has a real dependency
solver. This means way fewer surprising behaviors and way fewer workarounds
and less effort needed from packagers to make sure that users’ systems do
not break in surprising ways.apk. In xbps,
dependencies are driven purely by name, and shared library providers and
requires have separate metadata fields. These will get checked and xbps
will not permit things to proceed if unmatched, but dependencies are done
by name. When a package is being built, the system will consult this massive
central file (common/shlibs) matching SONAMEs to package names to generate
dependencies on top of the shlib metadata. This results in poor UX (you
cannot match the shlib providers etc. in the same way as names when e.g.
installing) and is inflexible as it’s limited to shared libraries. In apk,
virtual packages are used instead, so you e.g. provide so:libfoo.so.1=1
as a virtual package name. You can then search by this name, install by
this name, etc. and it can be used for other types as well, e.g. cmd:foo
(apk add cmd:i-know-command-name-but-not-package-name) and others.
That also means more things can participate in the staging system on the
build system side. And no central mappings, as the build system can easily
query things from the repository.xbps, apk has real support for triggers. Triggers in xbps-src
are emulated with package scripts. As an example, consider e.g. updating
fonts cache. The fontconfig package has a trigger (which is a script) and
metadata to run the cache update when /usr/share/fonts is modified in any
way. Then when something modifies the directory, the trigger will run at the
end of the transaction, after all filesystem changes are done. In xbps,
you can only have scripts that run before or after a package changes and
are owned by the package; xbps-src emulates triggers by checking if the
package contains a directory that would drive the trigger and if it does,
insert a call in its package script; that means if several packages change
the fonts, each of them contains a cache update script, which will run
several times (and not at the end). This means things become quite slow
for large triggers and the transaction breaks atomicity (because the shell
script run in the middle of the transaction, rather than at the end, needs
all prior things committed to the final filesystem location).There were others, but these are notable.
Building the infrastructure was interesting. We ended up using Buildbot again, after some deliberation and original intent to build a new orchestrator from scratch. There is an important distinction in our buildbot, however.
I wasn’t happy with the opaqueness of Void’s infrastructure, and with the way
it does so much work beyond xbps-src. I declared an entire new rule that goes:
What the packager runs exactly matches what the remote build machine runs.
The build steps of Chimera’s infrastructure go approximately like this:
cports has
happened. It does not matter what change.cports has changed. It does not tell them what.cports. It does not matter what
has changed../cbuild bootstrap-update).
This updates the core packages of the container to match the repository../cbuild bulk-print-ver status:unbuilt. This generates
a list of all packages along with their versions that are present in cports,
can be built, and are not already built in the repository. This step is
separate only for the purpose of presenting it to packagers in the Buildbot
UI, so that you can have a separate view for each package being built and
so on. This list is correctly sorted. Each entry is saved in a Buildbot
variable, again for the purpose of presentation mainly.so:libfoo.so.2
while the original provider was so:libfoo.so.1) and there is still any
package depending on the old name, the unstage will fail. That ensures that
all reverse dependencies are always rebuilt as necessary before publishing.
On successful unstage, the staging area is merged into the repository.Steps 4, 5, 6 can be condensed together into a single cbuild command:
$ ./cbuild bulk-pkg status:unbuilt
The main tricky part with batch builds like that is correct sorting. Imagine having packages A and B in the bulk that you want to build. There is a package C, which A depends on, and which depends on B. Since that makes B in the dependency tree of A (through A->C->B), B needs to be built first. You do not know this by knowing only A and B, since C is not in the batch.
Since cbuild is very fast and can parse the entire collection very quickly
without caching, it can consider all the intermediates and do a proper sorted
graph trivially. It can also simply parse every template to consider whether
it’s buildable, and match it against the repo state. Therefore, on every build,
it can always do that from scratch and the orchestrator has to do nothing,
with each step being largely independent of the other.
The build fleet doesn’t do anything else. There is other auxiliary infra, such as our IRC commit bot (which announces changes driven by a webhook) and our nightly update-check equivalent to Void, letting packagers stay on top of things.
In general, everything that any piece of our infrastructure does can be easily done locally.
Our fleet is self-hosted. The orchestrator and most builders run on Chimera host systems, but they don’t have to. Currently these are:
x86_64 machine, which is a 16-core EPYC root server at Netcup,
running Chimera.aarch64 machine, which is an 80-core Ampere Altra, running Chimera,
owned by me.ppc64le machine, which is an 18-core/72-thread POWER9, running Chimera,
owned by me.loongarch64 machine, which is a Loongson 3A6000 4-core/8-thread,
likewise running Chimera, owned by me.riscv64 machine, which is a Milk-V Pioneer 64-core machine kindly
provided to us by Zach van Rijn of Adélie Linux, running Fedora.The builders do not publicly face the Internet, the orchestrator does, on its own machine. The primary repository is also on its own separate machine. Each architecture has its own signing key.
All of this may possibly even be a bit too long and too much to take in. Therefore, I will end it here and hope that I have not forgotten anything. I hope this was interesting to read and I didn’t bore you to death, and that it wasn’t unnecessarily difficult to follow.
As always, you can ask anything on our IRC.
Unless circumstances change, we are planning to retire support for the big-endian 32-bit PowerPC and 64-bit POWER platforms. Read below for when and why and how you can potentially change this.
Note that this is not about ppc64le, which is not affected by this.
We’ve been supporting these platforms in Chimera since a while back, with ppc64 being suppported in repos since the middle of 2023 and 32-bit ppc a while later.
We brought up the platform support to give people interested in the platform a base to bring the platform towards greater usability and fix the long-standing bugs that plague it. This has not happened, and so far things have been getting very slowly worse instead.
Occasionally users come in looking to test it and often expect a fully working platform but generally quickly lose interest when faced with various issues and in the end nothing gets fixed.
For instance, it has not been possible to run a working GPU either platform for several years, due to unfixed regressions in Mesa, requiring use of the old Amber branch to get these working (which most people opt for and which also ends up counter-productive for fixing things upstream).
Likewise, there has not been an up to date web browser, and things are looking to regress further e.g. with WebKit having adopted Skia for rendering (WebKit was the sole web engine left where rendering didn’t have broken colors).
We don’t have a dedicated maintainer for the platform and so far I (q66) have been working on keeping things at least building but I don’t have the resources or motivation or real interest in keeping this going.
Our build infrastructure for this is also lacking, with both platforms being built on a single virtual machine hosted at OSUOSL. The performance is for most part acceptable but e.g. we’re frequently running out of disk space as the repos grow as the machine is barely capable of hosting two sets of repos.
I have some POWER9 hardware that could be set up as a build machine to fix this but I’m not sure if this is worth running if I’m going to be the only person giving this attention, so for now this is not going to happen.
Therefore, in order to lighten my workload I plan to retire the repositories and builders by July 2026.
In the meantime, if someone steps up and is willing to dedicate time and resources to maintaining things well, actually using it, and fixing the issues that make it unusable for most people, I am willing to retract this decision and set up a better builder, but only if it actually seems like there is a future for the platform in the distro.
If not, the repositories will be removed after the middle of the year, along with packaging only relevant for these platforms (such as mesa-amber).
The 20251220 set of images is now published.
This is an incremental refresh.
This set has been overdue for a while so it mainly comes as an update with new versions.
This set is based on kernel 6.18 and comes with latest versions of desktop environments and most other software.
Newly, the live images will not automatically import LVMs and ZFS pools, as that was found to be unintuitive and sometimes system-breaking (with ZFS-on-root setups).
Additionally, the images now come with an experimental TUI
installer. It can be invoked as chimera-installer from the
command line.
The installer supports the following:
It does not support the following:
You are expected to partition, format, and mount your filesystem layout beforehand and then point the installer to the mounted root. This is by design and will remain that way, however a separate tool for simplified disk setup may be provided later on.
However, it does validate your mounted filesystem tree for baseline
correctness, performs detection of system-specific things (like ESP)
and automatically generates crypttab for encrypted setups (this is
rudimentary so if you use keyfiles or other advanced things you need
to tweak it afterwards).
The next set will come early next year with some more major changes.
The 20250420 set of images is now published.
This is an incremental refresh with some major changes.
There are some major changes in how the images are set up.
One is that EFI/BIOS images now use the Limine bootloader for the
image itself, instead of GRUB. This does not affect what bootloader
is used for the installed system (that is the user’s choice) but
it’s the first step towards moving GRUB to the user repository
eventually.
The PowerPC/POWER images still use GRUB. For installed systems,
the recommended choice is systemd-boot on EFI and GRUB elsewhere,
Limine does not yet have distro integration.
The x86 images newly use MBR for best compatibility with all hardware.
Architecture support has been expanded. On top of the existing archs from before (AArch64, PowerPC, POWER LE/BE, RISC-V, x86_64) we now ship images for the LoongArch64 architecture.
The AArch64 image list has been expanded, with Rock64 and QuartzPro64 being added.
Various fixes have been made; notably, issues with cross-device links
and local installs with separate /boot should be gone, and apk
will no longer segfault when network connection is unavailable.
Everything has been updated and the images come with kernel 6.14, GNOME 48, Plasma 6.3.4, and a variety of updated software.
For the next image set we plan to provide images for mobile phones and generally more mobile packaging.
Additionally, the ARMv7 architecture will be introduced to the builders and then to release images.
Device SD images will automatically grow their root partition and filesystem on first boot from next time but this has not yet been deployed.
Additionally, Limine will get distro integration and will become a convenient option for installation.
As circumstances have changed, we are not dropping RISC-V repos for the time being. Instead, newly rebuilt repositories are introduced, built on hardware, with tests.
This support is provisional for now, with the new builder still being evaluated to see how it holds up in the long term.
Shortly after announcing the drop, we were offered remote access to a Milk-V Pioneer machine by Zach van Rijn of Adélie Linux. This machine was originally intended for another purpose which never ended up materializing.
I proceeded to do a full world rebuild on this machine, after some environment setup to allow our infra bits to run. This world rebuild is now finished, and makes up the new repository.
For most part, it was relatively stable during the build (we had to build our own kernel to prevent the draft RVV 0.7 in the CPU from interfering, and there were two crashes but it was also under total continuous load the whole time).
The performance is fairly acceptable, though nowhere near my original idea of being similar to Cortex-A72; the cores are more comparable to Cortex-A55 in practical performance, especially since we have to disable vectors. As there is still 64 of them, most of the large projects build fairly fast (anything written in Rust builds very slowly, however).
By now, the original repositories have been replaced, and the new
machine is plugged into the infrastructure. Do keep this in mind when
upgrading existing installations, and use the --available flag with
apk (every package in your system will be reinstalled).
Either way, we will continue to monitor the builds and see how the new machine holds up. If it works well, it will stay; if significant issues arise, we might end up dropping the architecture after all, at least until something significantly better is available.
The current repository is in the same tier as the LoongArch64 repo. The specifics are very similar - i.e. no LTO, tests on and enforced. The overall coverage is also fairly equivalent.
UPDATE March 20 2025: The architecture is not being dropped for now after all. See the newer article for details.
The next set of images will drop RISC-V support. The builder is currently still going but within the next few days it will stop, and the repositories will stay in place but frozen.
Nothing will change in packaging (the build profile will remain, template support where present will remain, cross-toolchains will remain) but there will be no more updates to the repo for the foreseeable future.
The initial plumbing for RISC-V was added in the distro in July 2021
and repos later in the year, i.e. it has been there almost from the
start. During all this time, the builds have been supported by doing
so on an x86_64 machine with qemu-user binfmt emulation coupled with
transparent cbuild support for this.
The reason for doing it this way was that there wasn’t any hardware we could use for performance reasons; I had obtained a SiFive HiFive Unmatched board in October 2021 and this proved to be useless for builds as the performance of this board is similar to Raspberry Pi 3. Other boards came later, but none of them improved on that front significantly enough.
This was expected to be a temporary state that would resolve itself within 2-3 year time; it is Q1 2025, and the options are the following:
The promising option (Milk-V Oasis with 16 SiFive P670 cores) that was first announced in 2023 ultimately ended up being canned due to issues the SoC vendor has, and nobody has ever seen a single production chip, let alone a board. As far as I can tell, no other options are coming up.
It is unsustainable to stick with the current situation with the emulator. Doing so has numerous problems:
qemu emulator likes to hang
during various workloads, with the emulator going into sleep state and
remaining there forever. When that happens, the builds have to be
manually canceled and restarted (it is not deterministic). This used
to be worse before before some fixes, but even with latest version of
the emulator it still happens, particularly during Go builds (since
we rebuild every Go program upon toolchain updates for secfixes,
any such rebuild can require many manual cancelations and restarts).At this point, to have a relatively sustainable base, we’d need a board that is at least as powerful as Raspberry Pi 5. This would still make the slowest builder in the fleet, but it would likely be faster than the current emulation arrangement while also being more reliable.
However, the industry does not seem to be interested in producing such machines and for most part focuses on embedded (low-end) as well as things entirely irrelevant to a distro (AI/NPU etc.) that do not help at all; at this point I don’t think we can wait any longer, especially as no remedy has been announced.
We have no such problem with the other architectures; obviously x86 and ARM are at this point mainstream and this does not surprise anyone, but even the likes of LoongArch have perfectly acceptable hardware (not the fastest, but also not a bottleneck) that performs reliably.
If acceptable build hardware is released and is reasonably available to us, the architecture will be reintroduced.
If that happens, the repositories will be rebuilt from scratch, as if a new architecture, with a process similar to how it was recently done with LoongArch64. It will be a tier-2 architecture with enforced tests and without LTO just like LoongArch64.
However, whether or when that will happen is currently a big unknown due to such hardware not existing and nothing being even announced.
Nothing will change in the other architecture support. The new tier list will be:
aarch64, ppc64le, and x86_64loongarch64ppc64 and ppcThere is also some chance of ARMv7 and ARMv6 32-bit repositories being introduced in the next few months’ timeframe, as we may be moving to an oversized Ampere Altra machine for all ARM builds (right now AArch64 is served by a Hetzner Cloud VM and can’t take any more load). This is yet not set in stone, however.
The 20250214 set of images is now published.
This took longer than originally expected but there have been major changes that warranted waiting a bit longer for it.
The images come with a fresh version of apk-tools. This version
finally supports several features that we began using, particularly
variable expansion and being able to migrate most of its files into
a system-wide /usr location.
That means you finally have a way to properly change your mirror of choice without having to mess with the repository definitions. The process of doing that is in the relevant documentation section.
The repository definitions have been updated to use the new v3-style index naming, though backwards compatibility is also provided.
Kernel 6.13 is used in the new images. That means updated hardware support and other things.
Both the GNOME and Plasma images (the latter is still experimental) come with the latest versions of their respective desktop environments.
Various fixes have been made to allow the live system to work better and more seamlessly on more machines.
Additionally, 32-bit PowerPC images are now a standard release architecture and included in the batch. We have some plans to also introduce support for the LoongArch64 ISA, which may join them next time.
Due to all of these changes as well as updates in the infrastructure, this new set is the recommended baseline for installation. Older images have an out of date package manager and installation scripts, which may be problematic with the current layout.
Today we have updated apk-tools to an rc tag. With this,
the project is now entering beta phase, after around a year
and a half.
In general, this does not actually mean much, as the project is rolling release and updates will simply keep coming. It is more of an acknowledgement of current status, though new images will be released in the coming days.
At the point of entering alpha, the cports tree had roughly
1000 templates, most of them in main. There was a single
large desktop (GNOME) and a single major web browser (Firefox)
and an assortment of other software.
At this point, the tree contains ~2800 templates, i.e. almost 3x more. We have all major desktop environments, all major browsers, and overall much larger collection of both small and large programs.
The repo was also at ~6000 commits at the time, by 11 authors; now it’s almost 20000 commits, by over 100 authors.
Significant under-the-hood improvements have been made in service
management, our build infrastructure, the cbuild build system
which is now significantly more powerful and has much better UX,
global switch to the mimalloc allocator, stateless /var and
progress towards stateless /etc, improvements in core userland,
introduction of libdinitctl, introduction of sd-tools,
and a lot more.
Currently, we support 5 architectures (aarch64, ppc64le, ppc64,
riscv64, x86_64), 3 being tier-1 (aarch64, ppc64le, x86_64).
This list will likely remain stable in 2025. The infrastructure is self-funded and we control all of it. Besides the unsatisfactory RISC-V situation, all of the machines are sufficient.
It would be nice to introduce CI for more architectures during next year, particularly AArch64.
Chimera is a FOSS project and therefore does not and will not take donations, and is driven by its community. However, for the past half a year, I (q66) have been working on the project through my employment at Igalia, thanks to a contract with Rubicon Communications, LLC (aka Netgate). This collaboration will continue during 2025 and is a significant help and a boost for the project’s progress, as it lets me dedicate much more time.
Therefore, huge thanks to Netgate for giving me this opportunity.
During 2025, some notable things will be coming too:
And likely much more than that. On the infrastructure side, we plan to automate more things, and introduce better build hardware for the RISC-V architecture if possible, as right now it is a major bottleneck.
A new image set will be released before end of the year to match
this announcement. They will come with various fixes and a new
version of apk-tools.
As of 04 December 2024 new images have been published.
While there weren’t originally supposed to be any more images before reaching the beta phase, a new apk feature proved to be necessary.
Other than that, it’s an incremental refresh with software updates.
We have two new committers, Jami Kettunen (deathmist) and Isaac Freund (ifreund). Both have been a part of our community for a long time and are active contributors; congratulations :)
Unfortunately, another of our contributors, nekopsykose, has left the project recently. We thank her for being a part of the community and all of the work over the years and wish her the best.
The apk-tools package manager has been updated again, ahead
of implementing a new kernel backup system. New static binaries,
new OCI images, and other things have also been updated to use
this new version of apk.
That means this image set is now the minimum that can be used
to perform new installations, unless you update apk-tools
in the live environment beforehand.
Various software has been updated. Linux kernel 6.12 is now the default, most notably.
The ISOs now have a bootable partition in the protective MBR. That means compatibility with certain x86 BIOS machines should be better.
This is likely the last update before entering the beta phase, for real this time.
As of 27 October 2024 new images have been published.
These are an incremental refresh with new software, as well as new image types. They bring various minor changes.
The most notable change is a major update of apk-tools. From
now on, we will start requiring changes that were made to it,
so using older images to install is no longer supported.
Experimentally, KDE Plasma ISO images are now available alongside the GNOME images. The GNOME images are based on GNOME 47, while the KDE images use Plasma 6.2.
Additionally, the ISO images now use EROFS for its root file system instead of SquashFS. This brings increased compatibility and increased performance while in the live environment, in exchange for a minor increase in image size.
Last but not least, the “force console” GRUB options are now gone
in the graphical ISOs, but the functionality is not. Adding nogui
to kernel command line in GRUB’s editor will achieve the same.
This is likely the last update before entering the beta phase.
Since @triallax has been doing a bunch of excellent work
in addition to being a great community member, we have decided
to grow the cports committers list a bit.
Additionally, @nekopsykose is now a project owner, so it’s
no longer just @q66.
Congrats to both :)
As of 07 July 2024 new images have been published.
These are an incremental refresh with new software. They bring various minor changes.
The biggest visible change is that core and minimal
rootfs tarballs are no longer distributed; you are expected
to use either the full or bootstrap tarballs. Any regular
installation is expected to use the base-full metapackage
at very least (unwanted components can be removed by masking
them in the apk world file).
The images are still based on GNOME 46 and kernel 6.6, but with all latest updates pulled in.
Otherwise, the images represent 3 months of software updates
in cports, which are reflected here.
Before the beta release, there will be at least one more image refresh. The beta release is expected most likely during the fall this year.
As of 21 April 2024 new images have been published.
These are mainly an incremental refresh. They bring a variety of
package updates and minor quality of life improvements, and
most importantly updated apk-tools.
The graphical images are based on GNOME 46 and Linux kernel 6.6, alongside a variety of up to date software, such as the LLVM 18 toolchain.
The apk package manager in this set fully supports the zstd
compression. The distribution will start rolling out packages
compressed with zstd in the coming days (no world rebuild will
happen yet but newly built packages will be compressed with it).
The installer scripts had minor changes done in them, some of them
user-visible. Notably, chimera-chroot will now alter the prompt
to be less confusing, and it makes bind-mounted pseudo-filesystems
properly unmountable.
The ISOs are newly based on GRUB 2.12. If this causes any regressions, please report them. All the ISO images were tested on their respective architectures without any issues found.
The MNT Reform images have been dropped. The packaging of the bootloader was unsatisfactory (done from binary builds) and there haven’t been any opportunities to figure out a proper source build. Additionally, the vendor now seems to be favoring newer SOMs by default. If you are interested in maintaining support for this or any other hardware, please reach out to us on one of the official channels.
There will be at least one more refresh before beta. Beta will likely
come with a world rebuild, which means zstd for all packages.
The images have been refreshed yet again.
Most importantly these bring the 6.6 LTS kernel, an upgrade from the 6.1 series (except Raspberry Pi images, which have their own kernel) alongside minor user experience improvements.
We have upgraded the LTS kernel series from 6.1 to 6.6. Meanwhile, the installable “stable” kernel is now at 6.7.x.
Raspberry Pi images had their firmware updated, so wireless networking and Bluetooth should work equally well on 3, 4, and 5.
The apk package manager got a fix which likely resolves the issue when some directories were very rarely created with 000 permissions. This is not yet verified however, as the issue was not reproducible and therefore it is not possible to verify it.
Minor user experience improvements include support for fstab LABEL=
and the likes for swap devices, support for timedated/localed/hostnamed
D-Bus services (mainly benefits GNOME) thanks to the openrc-settingsd
project from Gentoo/postmarketOS, various package updates, more atomic
apk transactions thanks to deployment of sysusers.d and tmpfiles.d,
chimerautils fixes (e.g. stdbuf command now works properly), the
lsinitramfs and unmkinitramfs commands have been fixed, the cryptsetup
initramfs scripts have their module copying fixed, Python 3.12, and a
ton of other things.
We will likely introduce an installer in one of the future images, likely before beta release.
A new set of images has been released once again.
This is once again a refresh without any major functionality changes outside of new software; but it does bring important changes to apk-tools as well as out of the box support for Raspberry Pi 5. It comes with GNOME 45 and kernel 6.1.
As far as live-specific changes go, the strange GRUB message about “booting in blind mode” should now be gone. This was always harmless but was causing confusion in some users.
Additionally, the version of apk-tools available in these images comes with full support for xattr metadata. That means we will stop using post-install scripts for this in repo packages and instead migrate to this. That means you should always install from at least this version of the images from now on - older images may not work correctly for installations.
Raspberry Pi 5 is now supported in the Raspberry Pi images. The support has been present in cports since October and you could always generate your own image with chimera-live, but now there is no need to as the available images will work.
Outside of that, a lot of software has been updated, which affects the live image as well. Most notably, this means using GNOME 45 now.
This is a transitional set. The next set of images will probably come in relatively near future; this will bring some more major changes, for instance the Linux 6.6 kernel (which will become the new LTS) as well as quite possibly an installer and support for zstd in packages instead of zlib/deflate.
A new set of images has been released once again.
This is mostly a refresh. The previous images still work fine for installation. These new images bring updated software, and a few other functional changes.
dinit-chimera core service set has been overhauled.swclock service will synchronize time
to at least a specific timestamp.Today marks the day when the project enters the alpha phase. This has some implications, though it is not a release per se, considering Chimera is a rolling distribution; let’s take a look at what it means for potential users and contributors.
Simply put, having entered the alpha phase means that the project is somewhat more ready to deal with users and potential repository expansion. A great deal of work has been done in all areas since the last update, and the distribution is now a lot more stable, with better infrastructure, and so on.
Of course, since it’s a mere alpha, it does not mean the system is considered stable per se. There may still be large-scale changes eventually (hopefully for the better) but early adopters may now consider actually daily-driving the system, and we are ready for the repositories to grow.
This phase is expected to last about a year. Obviously, it is not possible to create a distribution from scratch and immediately mark it stable. The current biggest things in the way are:
During the next year, it is planned that those things (and others) will be addressed and the project will move towards beta.
In summary, the current state of the project means it’s daily-driveable and can be gradually updated without significant manual fixups, but there may still be bugs, missing documentation, and some things may still change at conceptual level.
The distribution finally has proper infrastructure now. This means:
Thanks to all this, there is now streamlined workflow for adding new packages and updating existing ones, making it a significantly lesser effort.
There has been a huge amount of changes since. A summary of these includes:
main
and contrib, with more than 22000 total packages.This list is not exhaustive.
This update comes with a new set of images. The main improvement is
streamlined installation thanks to new chimera-install-scripts package.
As of today, a new set of images has been released. This is following the complete world rebuild that has been going on the last few days.
The new images are therefore generated from these new packages, and are the last images that are released before the alpha release.
The world rebuild has been successful and mostly uneventful on all architectures. There aren’t any or many updated versions, as that will happen after this.
However, it is very important that the rebuild has happened for the alpha release that will come soon after this.
A lot of the work since the last update has been on cleanups and overall quality. Overall, a summary:
util-linux to shadow.console-setup to uses non-XKB keymaps by default,
removing base system dependency on Perl.locate, whereis, script, logger, cal,
and others) and many others have been written from scratch.chimerautils tools
replace its various functionality.eudev to systemd-udev.efibootmgr hook for automatic EFISTUB
boot entries.agetty handling, with support for config files
to specify various parameters such as baud rate.-fno-semantic-interposition.apk package manager will not mess up early permissions anymore,
simplifying binary bootstrapping.This is not an exhaustive list.
The new images are mostly an incremental refresh, to allow for cleaner installations that do not update thousands of packages. There have been some notable improvements too, however:
chimera-live-bootstrap and chimera-live-chroot
to simplify installations.console= anymore.
If the kernel is configured to output to serial in any way, the
respective agetty service will be configured, if it exists.networkmanager by default.Up next is updating our packages to their latest versions, as a lot of stuff in the repository is by now fairly out of date. Various minor improvements will be done while doing this, and issues reported with the new images will be addressed.
The alpha release should then come a few weeks from now, definitely during March.
The release will mark the next stage of the project, where adventurous people will be able to pick it up as their daily driver, and expansion of the package set can begin.
It has been a while without an update post, so perhaps it’s time to refresh things a little.
No news does not mean progress hasn’t been happening; there has been
a continuous stream of commits in cports as well as other parts of
the project, so I will do my best to summarize it as well as provide
an updated overview of what’s going to happen.
FOSDEM 2023 is happening once again with an in-person format, as usual in Brussels, on the first weekend of February, which is the 4th and 5th this time. I will be giving a talk about Chimera, this time in the BSD devroom (huge thanks to the organizers for letting me have a slot, despite this project being a Linux system).
I will give a general overview of the project, our progress since last FOSDEM, as well as what’s planned for the future, and perhaps more, in the form of a full length talk (we have a 50 minute slot). The devroom changes into the LLVM devroom right afterwards, which is fitting considering we are also using the LLVM toolchain.
The previous post was at the beginning of November, which is two and a half months ago. Since then, there has been a lot of updates in the project. Here are the main highlights, in chronological order.
dinit-chimera has received a complete
overhaul. Besides being more fine-grained, it also provides a cleaned
up targets system, better thought-out configuration, and better
integration.fakeroot in the host system.base-devel and base-devel-static. These
provide a way for users to declare that they want development
packages to be automatically installed alongside runtime packages.
This allows users to choose whether they wish to save space not
installing development files (default) or whether they want the
convenience of having development files for everything (similarly
to e.g. Arch Linux).This list is not exhaustive, but includes most major things.
The documentation for the project has undergone significant expansion, now containing detailed installation instructions including how to deal with things like disk encryption and root oN ZFS, and various configuration tasks.
The FAQ is now a part of the handbook and has been expanded as well.
We still have plans to release an alpha as soon as possible. This will be the point where the distro is ready for early adopters. The following needs finishing:
Since these are still pretty significant tasks, it will take some time to get them done. Therefore, the alpha will not come out before the FOSDEM talk. Right now, the idea is to make it coincide with one of the beta releases of FreeBSD 13.2, to get a chance to rebase the userland. That means mid February to early March most likely.
There will be a new set of ISO images before the alpha comes out, to give people a chance to test and expose various issues. Another set will then be made for the alpha release.
The alpha cycle is planned for 6 months to 1 year. Once it is over and the project is ready to be declared beta quality, another world rebuild will be done.
I am hoping there will be no more significant delays. Right now, it is very near, with only a small number of tasks remaining to do. Those tasks however cover a lot of ground, so they take time.
It is November, and so far without a release. While progress is happening and there is pretty much constant flow of improvements, the idea was to get something out faster, and that has unfortunately not happened yet.
So instead here is a rough plan for the near future, with an alpha release at the end (hopefully).
But first, about the progress. The packaging work is not quite finished yet, and there are several things being worked on at the same time:
dinit-chimera suite is currently receiving
a variety of improvements.A bunch of work has been done since the last update on October 12:
linux-firmware) packaging
was carefully cleaned up and split into many individual packages.
Chimera’s elaborate policy packages system allows for simple
management.extlinux.conf generator for U-Boot-based devices has
been implemented, so that all devices can use a single boot menu
system._FORTIFY_SOURCE has been
added and is now in use by default for better hardening.-Wl,-z,relro
and -Wl,-z,now by default (without explicit flags) along with
-Wl,--as-needed on top of FORTIFY.--hash-style=both to --hash-style=gnu.dinit-userservd project got an initial release.dinit-chimera) now support system-enabled
services, for both system and user. That means packaging can
install implicit service links and users do not have to enable
them manually. This applies to a select set of services such
as the D-Bus system and session buses, udevd and elogind.
The links are in dedicated packages with no hard dependencies,
so they are fully optional (but still implicit for most users).console-setup
from the Debian project.cbuild cleanups, and so on.Now for the roadmap.
Right now, Chimera is not meant to be daily driven by most people. One thing is missing software, but also updates are not guaranteed to be safe and it takes a lot of knowing what one is doing to safely use the system.
This should change with the first alpha release, which is planned for the end of 2022 or beginning of 2023.
With the alpha release, new guarantees will be introduced. Notably,
package versioning will become more stable, with no more arbitrary
changes without incrementing revision numbers. That means it will
no longer be necessary to always use the --latest flag when
updating.
Initial, rudimentary documentation will be available with the alpha release, covering things like installation, basic package management, service management and so on.
To reach the alpha release, there are several tasks left to do, tagged
with the right milestone in the cports issue tracker.
The alpha release will not be suitable for general audience. It will be an early adopter release, for careful daily driving and testing. The amount of available software will grow during this period, and bugs will be fixed. It is expected that users will package software they need to use the system.
Sometime during this cycle, additional architecture support may be
introduced (notably for big-endian ppc64 and maybe 32-bit ppc).
An automatic package build infrastructure should function during
this period and will be set up before the alpha phase begins.
Once the OS stabilizes further, the alpha cycle will be declared finished, and all packages will be rebuilt from scratch for every supported architecture. Users will be expected to carefully upgrade their systems (this will be announced ahead of time). The beta phase will begin, suitable for less adventurous users.
The current estimate for beta phase is sometime in 2023 (summer or fall). Another cycle will begin. This is expected to take at least until mid 2024, when the distro will be declared stable. This will come with another world rebuild, most likely.
Unfortunately, one of the main blockers for alpha is outside of
the project’s control. It’s apk-tools, which hasn’t had much
work done on it lately in the upstream, due to the maintainer
not having time. That means issues and pull requests also go
unaddressed, and there is nothing the project can do about it.
While currently most of the issues are minor and can be worked
around, it is blocking several features and improvements in
cbuild, such as getting rid of host requirement for fakeroot,
and cleanup of build dependency handling.
If the situation does not improve before the alpha release is
near, Chimera will continue to rely on a Git snapshot of apk-tools
during the alpha phase. The situation is supposedly temporary,
and the idea is to keep the amount of downstream patching to
a minimum. The project would definitely prefer not having to
fork the package manager, so as long as there is nothing truly
major, the preferred strategy is to wait and see, at least until
beta is near.
In addition to packaging work scheduled for before alpha, it will
be necessary to launch automated build infrastructure. This needs
work on Chimera’s own primary server (which currently does not have
its own public IP) as well as various improvements in cbuild.
The build infrastructure is absolutely necessary, as the current
manual workflow takes too much effort with the growing number
of supported architectures.
Other issues can be tracked here.
Hopefully this clears things up a little. There will be at least one new set of testable images before the alpha phase is reached. Soon there will also be initial work on the Chimera handbook, which will serve as the primary source of documentation.