News

Latest 10 recent news (see index)

March 20, 2025

Not dropping RISC-V support after all (maybe)

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.

The situation now

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.

March 12, 2025

Dropping RISC-V support

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 situation

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:

• HiFive P550 that was released recently has performance similar to Raspberry Pi 4 and is unsuitable for the task; this board was originally supposed to be released several years ago as part of the SiFive and Intel collaboration (Horse Creek) but now got released with a Chinese SoC instead
• Milk-V Pioneer is a board with 64 out-of-order cores; it is the only of its kind, with the cores being supposedly similar to something like ARM Cortex-A72. This would be enough in theory, however these boards are hard to get here (especially with Sophgon having some trouble, new US sanctions, and Mouser pulling all the Milk-V products) and from the information that is available to me, it is rather unstable, receives very little support, and is ridden with various hardware problems.
• Things based on Spacemit K1 (e.g. Milk-V Jupiter) have an 8-core SoC that is technically an out-of-order design, but in practice the per-core performance is reportedly even worse than the JH7110, so it is unsuitable.
• Boards based on JH7110 (e.g. VisionFive 2, the new Framework board etc.) utilitze 4 U74 cores (same configuration as my HiFive unmatched) that are simple in-order designs and therefore are unsuitable (similar to RPi3).
• My HiFive Unmatched, which is the same situation as above.
• Other available cores are usually much worse than any of the above.

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:

• We could never actually run tests on the packages being built, because the emulator is unreliable and will result in false positive failures. Disabling stuff conditionally for RISC-V is not a viable option because they are not RISC-V issues and will always happen with emulation, so all the RISC-V packages were being built without tests.
• It is very slow, being by far the slowest builder in our fleet. It is still several times faster than e.g. the JH7110 would build things. The performance is actually rather variable; things that can parallelize really well run at a fairly reasonable speed due to being able to spawn many emulators, while things like configure scripts that are single thread and fork a lot run very slowly. Either way, overall, it is much slower than any of the other builders, despite RISC-V being until the introduction of LoongArch64 builds the only architecture with no LTO.
• Most importantly, it is unreliable. The 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).
• It burns a ton of power for how slow it is, because it fully loads a beefy x86 machine, and I’m not happy at all about that.

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.

Will RISC-V support be reintroduced?

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:

• Tier 1 for aarch64, ppc64le, and x86_64
• Tier 2 for loongarch64
• Tier 3 for ppc64 and ppc

There 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.

February 14, 2025

New images

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.

Changes

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.

December 27, 2024

Entering beta

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.

What actually changes?

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.

Changes since alpha

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.

Infrastructure situation and sponsorship

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.

Plans for 2025

During 2025, some notable things will be coming too:

• Complete system logging overhaul
• Support for mount units in service management
• Support for network mounts in service management
• Better cgroups support and progress towards removal of elogind
• Support for service-based timers
• Overhaul of service configuration files
• Switch to dbus-broker as the system and session bus provider

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.

Upcoming images

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.

December 04, 2024

New images and welcoming new committers

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.

New committers

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.

Changes

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.

Upcoming changes

This is likely the last update before entering the beta phase, for real this time.

October 27, 2024

New images

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.

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.

Upcoming changes

This is likely the last update before entering the beta phase.

July 12, 2024

Welcoming a new committer

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 :)

July 07, 2024

New images

As of 07 July 2024 new images have been published.

These are an incremental refresh with new software. They bring various minor changes.

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.

Upcoming changes

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.

April 21, 2024

New images

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.

Changes

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.

Upcoming changes

There will be at least one more refresh before beta. Beta will likely come with a world rebuild, which means zstd for all packages.

January 22, 2024

2024 image refresh

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.

Changes

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.

Upcoming changes

We will likely introduce an installer in one of the future images, likely before beta release.