fidzu : gentoo

Happy New Year 2026! Once again, a lot has happened in Gentoo over the past months. New developers, more binary packages, GnuPG alternatives support, Gentoo for WSL, improved Rust bootstrap, better NGINX packaging, … As always here we're going to revisit all the exciting news from our favourite Linux distribution.

Gentoo in numbers

Gentoo currently consists of 31663 ebuilds for 19174 different packages. For amd64 (x86-64), there are 89 GBytes of binary packages available on the mirrors. Gentoo each week builds 154 distinct installation stages for different processor architectures and system configurations, with an overwhelming part of these fully up-to-date.

The number of commits to the main ::gentoo repository has remained at an overall high level in 2025, with a slight decrease from 123942 to 112927. The number of commits by external contributors was 9396, now across 377 unique external authors.

GURU, our user-curated repository with a trusted user model, as entry point for potential developers, has shown a decrease in activity. We have had 5813 commits in 2025, compared to 7517 in 2024. The number of contributors to GURU has increased, from 241 in 2024 to 264 in 2025. Please join us there and help packaging the latest and greatest software. That's the ideal preparation for becoming a Gentoo developer!

Activity has slowed down somewhat on the Gentoo bugtracker bugs.gentoo.org, where we've had 20763 bug reports created in 2025, compared to 26123 in 2024. The number of resolved bugs shows the same trend, with 22395 in 2025 compared to 25946 in 2024. The current values are closer to those of 2023 - but clearly this year we fixed more than we broke!

New developers

In 2025 we have gained four new Gentoo developers. They are in chronological order:

1. Jay Faulkner (jayf): Jay joined us in March from Washington, USA. In Gentoo and open source in general, he's very much involved with OpenStack; further, he's a a big sports fan, mainly ice hockey and NASCAR racing, and already long time Gentoo enthusiast.

2. Michael Mair-Keimberger (mm1ke): Michael joined us finally in June from Austria, after already amassing over 9000 commits beforehand. Michael works as Network Security Engineer for a big System House in Austria and likes to go jogging regulary and hike the mountains on weekends. In Gentoo, he's active in quality control and cleanup.

3. Alexander Puck Neuwirth (apn-pucky): Alexander, a physics postdoc, joined us in July from Italy. At the intersection of Computer Science, Linux, and high-energy physics, he already uses Gentoo to manage his code and sees it as a great development environment. Beyond sci-physics, he's also interested in continuous integration and RISC-V.

4. Jaco Kroon (jkroon): Jaco signed up as developer in October from South Africa. He is a system administrator who works for a company that runs and hosts multiple Gentoo installations, and has been around in Gentoo since 2003! Among our packages, Asterisk is one example of his interests.

Featured changes and news

Let's now look at the major improvements and news of 2025 in Gentoo.

Distribution-wide Initiatives

• Goodbye Github, welcome Codeberg: Mostly because of the continuous attempts to force Copilot usage for our repositories, Gentoo currently considers and plans the migration of our repository mirrors and pull request contributions to Codeberg. Codeberg is a site based on Forgejo, maintained by a non-profit organization, and located in Berlin, Germany. Gentoo continues to host its own primary git, bugs, etc infrastructure and has no plans to change that.

• EAPI 9: The wording for EAPI 9, a new version of the specifications for our ebuilds, has been finalized and approved, and support in Portage is complete. New features in EAPI 9 include pipestatus for better error handling, an edo function for printing a command and executing it, a cleaner environment for the build processes, and the possibility of declaring a default EAPI for the profile directory tree.

• Event presence: At FOSDEM 2025 in Brussels, Gentoo has been present once more with a stand, this year together with Flatcar Container Linux (which is based on Gentoo). Naturally we had mugs, stickers, t-shirts, and of course the famous self-compiled buttons… Further, we have been present at FrOSCon 2025 in Sankt Augustin with workshops Gentoo installation and configuration and Writing your own ebuilds. Last but not least, the toolchain team has represented Gentoo at the GNU Tools Cauldron 2025 in Porto.

• SPI migration: The migration of our financial structure to Software in the Public Interest (SPI) is continuing slowly but steadily, with expense payments following the moving intake. If you are donating to Gentoo, and especially if you are a recurrent donor, please change your payments to be directed to SPI; see also our donation web page.

• Online workshops: Our German support, Gentoo e.V., is grateful to the speakers and participants of four online workshops in 2025 in German and English, on topics as varied as EAPI 9 or GnuPG and LibrePGP. We are looking forward to more exciting events in 2026.

Architectures

• RISC-V bootable QCOW2: Same as for amd64 and arm64, also for RISC-V we now have ready-made bootable disk images in QCOW2 format available for download on our mirrors in a console and a cloud-init variant. The disk images use the rv64gc instruction set and the lp64d ABI, and can be booted via the standard RISC-V UEFI support.

• Gentoo for WSL: We now publish weekly Gentoo images for Windows Subsystem for Linux (WSL), based on the amd64 stages, see our mirrors. While these images are not present in the Microsoft store yet, that's something we intend to fix soon.

• hppa and sparc destabilized: Since we do not have hardware readily available anymore and these architectures mostly fill a retrocomputing niche, stable keywords have been dropped for both hppa (PA-RISC) and sparc. The architectures will remain supported with testing keywords.

• musl with locales: Localization support via the package sys-apps/musl-locales has been added by default to the Gentoo stages based on the lightweight musl C library.

Packages

• GPG alternatives: Given the unfortunate fracturing of the GnuPG / OpenPGP / LibrePGP ecosystem due to competing standards, we now provide an alternatives mechanism to choose the system gpg provider and ease compatibility testing. At the moment, the original, unmodified GnuPG, the FreePG fork/patchset as also used in many other Linux distributions (Fedora, Debian, Arch, …), and the re-implementation Sequoia-PGP with Chameleon are available. In practice, implementation details vary between the providers, and while GnuPG and FreePG are fully supported, you may still encounter difficulties when selecting Sequoia-PGP/Chameleon.

• zlib-ng support: We have introduced initial support for using zlib-ng and minizip-ng in compatibility mode in place of the reference zlib libraries.

• System-wide jobserver: We have created steve, an implementation of a token-accounting system-wide jobserver, and introduced experimental global jobserver support in Portage. Thanks to that, it is now possible to globally control the concurrently running build job count, correctly accounting for parallel emerge jobs, make and ninja jobs, and other clients supporting the jobserver protocol.

• NGINX rework: The packaging of the NGINX web server and reverse proxy in Gentoo has undergone a major improvement, including also the splitting off of several third-party modules into separate packages.

• C++ based Rust bootstrap: We have added a bootstrap path for Rust from C++ using Mutabah's Rust compiler mrustc, which alleviates the need for pre-built binaries and makes it significantly easier to support more configurations.

• Ada and D bootstrap: Similarly, Ada and D support in gcc now have clean bootstrap paths, which makes enabling these in the compiler as easy as switching the useflags on gcc and running emerge.

• FlexiBLAS: Gentoo has adopted the new FlexiBLAS wrapper library as the primary way of switching implementations of the BLAS numerical algorithm library at runtime. This automatically also provides ABI stability for linking programs and bundles the specific treatment of different BLAS variants in one place.

• Python: In the meantime the default Python version in Gentoo has reached Python 3.13. Additionally we have also Python 3.14 available stable - fully up to date with upstream.

• KDE upgrades: As of end of 2025, in Gentoo stable we have KDE Gear 25.08.3, KDE Frameworks 6.20.0, and KDE Plasma 6.5.4. As always, Gentoo testing follows the newest upstream releases (and using the KDE overlay you can even install from git sources).

Physical and Software Infrastructure

• Additional build server: A second dedicated build server, hosted at Hetzner Germany, has been added to speed up the generation of installation stages, iso and qcow2 images, and binary packages.

• Documentation: Documentation work has made constant progress on wiki.gentoo.org. The Gentoo Handbook had some particularly useful updates, and the documentation received lots of improvements and additions from the many active volunteers. There are currently 9,647 pages on the wiki, and there have been 766,731 edits since the project started. Please help Gentoo by contributing to documentation!

Finances of the Gentoo Foundation

• Income: The Gentoo Foundation took in $12,066 in fiscal year 2025 (ending 2025/06/30); the dominant part (over 80%) consists of individual cash donations from the community. On the SPI side, we received $8,471 in the same period as fiscal year 2025; also here, this is all from small individual cash donations.
• Expenses: Our expenses in 2025 were, program services (e.g. hosting costs) $8,332, management & general (accounting) $1,724, fundraising $905, and non-operating (depreciation expenses) $10,075.
• Balance: We have $104,831 in the bank as of July 1, 2025 (which is when our fiscal year 2026 starts for accounting purposes). The Gentoo Foundation FY2025 financial statement is available on the Gentoo Wiki.
• Transition to SPI: The Foundation encourages donors to ensure their ongoing contributions are going to SPI - more than 40 donors had not responded to requests to move the recurring donations by the end of the year. Expenses will be moved to the SPI structure as ongoing income permits.

Thank you!

As every year, we would like to thank all Gentoo developers and all who have submitted contributions for their relentless everyday Gentoo work. If you are interested and would like to help, please join us to make Gentoo even better! As a volunteer project, Gentoo could not exist without its community.

05 Jan 2026 6:00am GMT

Once again it's FOSDEM time! Join us at Université Libre de Bruxelles, Campus du Solbosch, in Brussels, Belgium. The upcoming FOSDEM 2026 will be held on January 31st and February 1st 2026. If you visit FOSDEM, make sure to come by at our Gentoo stand (exact location still to be announced), for the newest Gentoo news and Gentoo swag. Also, this year there will be a talk about the official Gentoo binary packages in the Distributions devroom. Visit our Gentoo wiki page on FOSDEM 2026 to see who's coming and for more practical information.

26 Dec 2025 6:00am GMT

A common problem with running Gentoo builds is concurrency. Many packages include extensive build steps that are either fully serial, or cannot fully utilize the available CPU threads throughout. This problem becomes less pronounced when running building multiple packages in parallel, but then we are risking overscheduling for packages that do take advantage of parallel builds.

Fortunately, there are a few tools at our disposal that can improve the situation. Most recently, they were joined by two experimental system-wide jobservers: guildmaster and steve. In this post, I'd like to provide the background on them, and discuss the problems they are facing.

The job multiplication problem

You can use the MAKEOPTS variable to specify a number of parallel jobs to run:

MAKEOPTS="-j12"

This is used not only by GNU make, but it is also recognized by a plethora of eclasses and ebuilds, and converted into appropriate options for various builders, test runners and other tools that can benefit from concurrency. So far, that's good news; whenever we can, we're going to run 12 jobs and utilize all the CPU threads.

The problems start when we're running multiple builds in parallel. This could be either due to running emerge --jobs, or simply needing to start another emerge process. The latter happens to me quite often, as I am testing multiple packages simultaneously.

For example, if we end up building four packages simultaneously, and all of them support -j, we may end up spawning 48 jobs. The issue isn't just saturating the CPU; imagine you're running 48 memory-hungry C++ compilers simultaneously!

Load-average scheduling to the rescue

One possible workaround is to use the --load-average option, e.g.:

MAKEOPTS="-j12 -l13"

This causes tools supporting the option not to start new jobs if the current load exceeds 13, which roughly approximates 13 processes running simultaneously. However, the option isn't universally supported, and the exact behavior differs from tool to tool. For example, CTest doesn't start any jobs when the load is exceeded, effectively stopping test execution, whereas GNU make and Ninja throttle themselves down to one job.

Of course, this is a rough approximation. While GNU make attempts to establish the current load from /proc/loadavg, most tools just use the one-minute average from getloadavg(), suffering from some lag. It is entirely possible to end up with interspersed periods of overscheduling while the load is still ramping up, followed by periods of underscheduling before it decreases again. Still, it is better than nothing, and can become especially useful for providing background load for other tasks: a build process that can utilize the idle CPU threads, and back down when other builds need them.

The nested Makefile problem and GNU Make jobserver

Nested Makefiles are processed by calling make recursively, and therefore face a similar problem: if you run multiple make processes in parallel, and they run multiple jobs simultaneously, you end up overscheduling. To avoid this, GNU make introduces a jobserver. It ensures that the specified job number is respected across multiple make invocations.

At the time of writing, GNU make supports three kinds of the jobserver protocol:

1. The legacy Unix pipe-based protocol that relied on passing file descriptors to child processes.
2. The modern Unix protocol using a named pipe.
3. The Windows protocol using a shared semaphore.

All these variants follow roughly the same design principles, and are peer-to-peer protocols for using shared state rather than true servers in the network sense. The jobserver's role is mostly limited to initializing the state and seeding it with an appropriate number of job tokens. Afterwards, clients are responsible for acquiring a token whenever they are about to start a job, and returning it once the job finishes. The availability of job tokens therefore limits the total number of processes started.

The flexibility of modern protocols permitted more tools to support them. Notably, the Ninja build system recently started supporting the protocol, therefore permitting proper parallelism in complex build systems combining Makefiles and Ninja. The jobserver protocol is also supported by Cargo and various Rust tools, GCC and LLVM, where it can be used to limit the number of parallel LTO jobs.

A system-wide jobserver

With a growing number of tools becoming capable of parallel processing, and at the same time gaining support for the GNU make jobserver protocol, it starts being an interesting solution to the overscheduling problem. If we could run one jobserver shared across all build processes, we could control the total number of jobs running simultaneously, and therefore have all the simultaneously running builds dynamically adjust one to another!

In fact, this is not a new idea. A bug requesting jobserver integration has been filed for Portage back in 2019. NixOS jobserver effort dates back at least to 2021, though it has not been merged yet. Guildmaster and steve joined the effort very recently.

There are two primary problems with using a system-wide jobserver: token release reliability, and the "implicit slot" problem.

The token release problem

The first problem is more important. As noted before, the jobserver protocol relies entirely on clients releasing the job tokens they acquired, and the documentation explicitly emphasizes that they must be returned even in error conditions. Unfortunately, this is not always possible: if the client gets killed, it cannot run any cleanup code and therefore return the tokens! For scoped jobservers like GNU make's this usually isn't that much of a problem, since make normally terminates upon a child being killed. However, a system jobserver could easily be left with no job tokens in the queue this way!

This problem cannot really be solved within the strict bounds of the jobserver protocol. After all, it is just a named pipe, and there are limits to how much you can monitor what's happening to the pipe buffer. Fortunately, there is a way around that: you can implement a proper server for the jobserver protocol using FUSE, and provide it in place of the named pipe. Good news is, most of the tools don't actually check the file type, and these that do can easily be patched.

The current draft of NixOS jobserver provides a regular file with special behavior via FUSE, whereas guildmaster and steve both provide a character device via its CUSE API. NixOS jobserver and guildmaster both return unreleased tokens once the process closes the jobserver file, whereas steve returns them once the process acquiring them exits. This way, they can guarantee that a process that either can't release its tokens (e.g. because it's been killed), or one that doesn't because of implementation issue (e.g. Cargo), doesn't end up effectively locking other builds. It also means we can provide live information on which processes are holding the tokens, or even implement additional features such as limiting token provision based on the system load, or setting per-process limits.

The implicit slot problem

The second problem is related to the implicit assumption that a jobserver is inherited from a parent GNU make process that already acquired a token to spawn the subprocess. Since the make subprocess doesn't really do any work itself, it can "use" the token to spawn another job instead. Therefore, every GNU make process running under a jobserver has one implicit slot that runs jobs without consuming any tokens. If the jobserver is running externally and no job tokens were acquired while running the top make process, it ends up running an extra process without a job token: so steve -j12 permits 12 jobs, plus one extra job for every package being built.

Fortunately, the solution is rather simple: one needs to implement token acquisition at Portage level. Portage acquires a new token prior to starting a build job, and releases it once the job finishes. In fact, this solves two problems: it accounts for the implicit slot in builders implementing the jobserver protocol, and it limits the total number of jobs run for parallel builds.

However, this is a double-edged sword. On one hand, it limits the risk of overscheduling when running parallel build jobs. On the other, it means that a new emerge job may not be able to start immediately, but instead wait for other jobs to free up job tokens first, negatively affecting interactivity.

A semi-related issue is that acquiring a single token doesn't properly account for processes that are parallel themselves but do not implement the jobserver protocol, such as pytest-xdist runs. It may be possible to handle these better by acquiring multiple tokens prior to running them (or possibly while running them), but in the former case one needs to be careful to acquire them atomically, and not end up with the equivalent of lock contention: two processes acquiring part of the tokens they require, and waiting forever for more.

The implicit slot problem also causes issues in other clients. For example, nasm-rs writes an extra token to the jobserver pipe to avoid special-casing the implicit slot. However, this violates the protocol and breaks clients with per-process tokens. Steve carries a special workaround for that package.

Summary

A growing number of tools is capable of some degree of concurrency: from builders traditionally being able to start multiple parallel jobs, to multithreaded compilers. While they provide some degree of control over how many jobs to start, avoiding overscheduling while running multiple builds in parallel is non-trivial. Some builders can use load average to partially mitigate the issue, but that's far from a perfect solution.

Jobservers are our best bet right now. Originally designed to handle job scheduling for recursive GNU make invocations, they are being extended to control other parallel processes throughout the build, and can be further extended to control the job numbers across different builds, and even across different build containers.

While NixOS seems to have dropped the ball, Gentoo is now finally actively pursuing global jobserver support. Guildmaster and steve both prove that the server-side implementation is possible, and integration is just around the corner. At this point, it's not clear whether a jobserver-enabled systems are going to become the default in the future, but certainly it's an interesting experiment to carry.

30 Nov 2025 7:34pm GMT