Arch Linux

In the recent blog post on the work funded by Sovereign Tech Fund (STF), we provided an overview of the "File Hierarchy for the Verification of OS Artifacts" (VOA) and the voa project as its reference implementation. VOA is a generic framework for verifying any kind of distribution artifacts (i.e. files) using arbitrary signature verification technologies. The voa CLI ⌨️ The voa project offers the voa(1) command line interface (CLI) which makes use of the voa(5) configuration file format for technology backends. It is recommended to read the respective man pages to get …

In 2024 the Sovereign Tech Fund (STF) started funding work on the ALPM project, which provides a Rust-based framework for Arch Linux Package Management. Refer to the project's FAQ and mission statement to learn more about the relation to the tooling currently in use on Arch Linux. The funding has now concluded, but over the time of 15 months allowed us to create various tools and integrations that we will highlight in the following sections. We have worked on six milestones with focus on various aspects of the package management ecosystem, ranging from formalizing, parsing and writing of …

Did you know you can have newlines in pathnames? The design is very human and this absolutely doesn't have any unforeseen consequences! Also a friendly reminder that you can store anything on a nameserver if you try hard enough.

Originally posted by me on donotsta.re (2025-12-23)

2025 was a crazy simulation. A lot of glitches, plot twists and fun stuff™.

Same as last year, this is a summary of what I’ve been up to throughout the year. See also the recap/retrospection published by my friends (antiz, jvoisin, orhun).

• Uploaded 467 packages to Arch Linux
  • Most of them being reproducible, meaning I provably didn’t abuse my position of compiling the binaries
  • 35 of them are signal-desktop
  • 29 of them are metasploit
• Made 53 uploads to Debian
  • All of them being related to my work in the debian-rust team, that I’ve been a part of since 2018
  • …

Peter Jung via arch-announce wrote:

With the update to driver version 590, the NVIDIA driver no longer supports Pascal (GTX 10xx) GPUs or older. We will replace the 'nvidia' package with 'nvidia-open', 'nvidia-dkms' with 'nvidia-open-dkms', and 'nvidia-lts' with 'nvidia-lts-open'. Impact: Updating the NVIDIA packages on systems with Pascal, Maxwell, or older cards will fail to load the driver, which may result in a broken graphical environment. Intervention required for Pascal/older users: Users with GTX 10xx series and older cards must switch to the legacy proprietary branch to maintain support:

• Uninstall the official 'nvidia', 'nvidia-lts', or 'nvidia-dkms' packages.
• Install 'nvidia-580xx-dkms' from the AUR

Users with Turing (20xx and GTX 1650 series) and newer GPUs will automatically transition to the open kernel modules on upgrade and require no manual intervention.

https://archlinux.org/news/nvidia-590-d … l-modules/

With the update to driver version 590, the NVIDIA driver no longer supports Pascal (GTX 10xx) GPUs or older. We will replace the nvidia package with nvidia-open, nvidia-dkms with nvidia-open-dkms, and nvidia-lts with nvidia-lts-open. Impact: Updating the NVIDIA packages on systems with Pascal, Maxwell, or older cards will fail to load the driver, which may result in a broken graphical environment. Intervention required for Pascal/older users: Users with GTX 10xx series and older cards must switch to the legacy proprietary branch to maintain support:

• Uninstall the official nvidia, nvidia-lts, or nvidia-dkms packages.
• Install nvidia-580xx-dkms from the AUR

Users with Turing (20xx and GTX 1650 series) and newer GPUs will automatically transition to the open kernel modules on upgrade and require no manual intervention.

The following packages may require manual intervention due to the upgrade from 9.0 to 10.0:

• aspnet-runtime
• aspnet-targeting-pack
• dotnet-runtime
• dotnet-sdk
• dotnet-source-built-artifacts
• dotnet-targeting-pack

pacman may display the following error failed to prepare transaction (could not satisfy dependencies) for the affected packages. If you are affected by this and require the 9.0 packages, the following commands will update e.g. aspnet-runtime to aspnet-runtime-9.0: pacman -Syu aspnet-runtime-9.0 pacman -Rs aspnet-runtime

Over the course of 2025, every single major cloud provider has failed. In June, Google Cloud had issues taking down Cloud Storage for many users. In late October, Amazon Web Services had a massive outage in their main hub, us-east-1, affecting many services as well as some people’s beds. A little over a week later Microsoft Azure had a [widespread outage][Azure outage] that managed to significantly disrupt train service in the Netherlands, and probably also things that matter. Now last week, Cloudflare takes down large swaths of the internet in a way that causes non-tech people to learn Cloudflare exists. And every single time, people share that one XKCD comic.

After Gandi was bought up and started taking extortion level prices for their domains I’ve been looking for an excuse to migrate registrar. Last week I decided to bite the bullet and move to Porkbun as I have another domain renewal coming up. However after setting up an account and paying for the transfer for 4 domains, I realized their DNS services are provided by Cloudflare! I personally do not use Cloudflare, and stay far away from all of their products for various reasons.

If you've ever tried to publish a package on PyPI, you might have encountered a quite interesting error message: error: Failed to publish [..] to https://upload.pypi.org/legacy/ Caused by: Upload failed with status code 400 Bad Request. Server says: 400 The name [..] is too similar to an existing project. See https://pypi.org/help/#project-name for more information. Sadly it's not very clear what "too similar" means in this context. Also there's no way to check if your name is acceptable before actually trying to upload the package. Luckily, PyPI warehouse is open source, so let's just check how the validation is implemented.

I think 2025 was a good year (for me, it would be hard to say it was that great in general). Well, it still is because as I'm writing this, it's 12th November. I wanted to wait for the end of the year before starting to draft this post, but well - I'm in the right mood, and it makes more sense to act instead of holding back (this is probably a foreshadowing).

The waydroid package prior to version 1.5.4-2 (including aur/waydroid) creates Python byte-code files (.pyc) at runtime which were untracked by pacman. This issue has been fixed in 1.5.4-3, where byte-compiling these files is now done during the packaging process. As a result, the upgrade may conflict with the unowned files created in previous versions. If you encounter errors like the following during the update:

error: failed to commit transaction (conflicting files) waydroid: /usr/lib/waydroid/tools/__pycache__/__init__.cpython-313.pyc exists in filesystem waydroid: /usr/lib/waydroid/tools/actions/__pycache__/__init__.cpython-313.pyc exists in filesystem waydroid: /usr/lib/waydroid/tools/actions/__pycache__/app_manager.cpython-313.pyc exists in filesystem

You can safely overwrite these files by running the following command: pacman -Syu --overwrite /usr/lib/waydroid/tools/\*__pycache__/\*

The dovecot 2.4 release branch has made breaking changes which result in it being incompatible with any <= 2.3 configuration file. Thus, the dovecot service will no longer be able to start until the configuration file was migrated, requiring manual intervention. For guidance on the 2.3-to-2.4 migration, please refer to the following upstream documentation: Upgrading Dovecot CE from 2.3 to 2.4 Furthermore, the dovecot 2.4 branch no longer supports their replication feature, it was removed. For users relying on the replication feature or who are unable to perform the 2.4 migration right now, we provide alternative packages available in [extra]:

• dovecot23
• pigeonhole23
• dovecot23-fts-elastic
• dovecot23-fts-xapian

The dovecot 2.3 release branch is going to receive critical security fixes from upstream until stated otherwise.

I said when I made the announcement that there wasn’t any drama, and there still isn’t.

I've been meaning to write this post for some time now, well I've been meaning to write several posts for some time now so I thought - let's write one post that is especially hard to follow, that's even better right? What finally pushed me to write was yesterday's (as I'm writing this) pastagang birthday party. If you don't know what pastagang is, then this post is not about pastagang ...but you should get the idea by the end anyway (or just read pastagang.cc), this post will be quite chaotic. It's something different this time, a little bit more personal. I had quite a lot of "breakthroughs" this year and want to share this. Maybe, but just maybe you will find this relatable. I'm not an influencer. I am the only planned target audience for this post. If you are not me, add "maybe" to every "should" you read. Some of the things may not apply to you. You may even think this whole post is just plain wrong, and I'm fine with that. You are getting an almost unedited look at my stream of thoughts, and if you think that this post is a mess - thank goodness, this means you are not in my head but an actual human being, wheeeew.

rebuilderd v0.25.0 was recently released, this version has improved in-toto support for cryptographic attestations that this blog post briefly outlines. 😺 As a quick recap, rebuilderd is an automatic build scheduler that emerged in 2019/2020 from the Reproducible Builds project doing the following:

1. Track binary packages available in a Linux distribution
2. Attempt to compile the official binary packages from their (alleged) source code
3. Check if the package we compiled is bit-for-bit identical
   1. If so, mark it GOOD, issue an attestation
   2. In every other case, mark it BAD, generate a diffoscope

…

https://archlinux.org/news/recent-services-outages/

We want to provide an update on the recent service outages affecting our infrastructure. The Arch Linux Project is currently experiencing an ongoing denial of service attack that primarily impacts our main webpage, the Arch User Repository (AUR), and the Forums. We are aware of the problems that this creates for our end users and will continue to actively work with our hosting provider to mitigate the attack. We are also evaluating DDoS protection providers while carefully considering factors including cost, security, and ethical standards. To improve the communication around this issue we will provide regular updates on our service …

Since GNOME 48, users can now preserve their battery health directly from GNOME Settings. Currently, this feature only works on laptops that support both start and end charge thresholds, such as ThinkPads. Ideally, we’d like to support every laptop with any form of charge threshold control but that isn't …

Starting with 7.4.1-2, the following Zabbix system user accounts (previously shipped by their related packages) will no longer be used. Instead, all Zabbix components will now rely on a shared zabbix user account (as originally intended by upstream and done by other distributions):

• zabbix-server
• zabbix-proxy
• zabbix-agent (also used by the zabbix-agent2 package)
• zabbix-web-service

This shared zabbix user account is provided by the newly introduced zabbix-common split package, which is now a dependency for all relevant zabbix-* packages. The switch to the new user account is handled automatically for the corresponding main configuration files and systemd service units. However, manual intervention may be required if you created custom files or configurations referencing to and / or being owned by the above deprecated users accounts, for example:

• PSK files used for encrypted communication
• Custom scripts for metrics collections or report generations
• sudoers rules for metrics requiring elevated privileges to be collected
• ...

Those should therefore be updated to refer to and / or be owned by the new zabbix user account, otherwise some services or user parameters may fail to work properly, or not at all. Once migrated, you may remove the obsolete user accounts from your system.

In Arch Linux, as part of RFC40, we have recently decided to license all Arch Linux package sources as 0BSD. Our package sources didn't have any license previously. RFC40 only specified that we do want to license our package sources but it didn't specify how to ensure this. As such, in RFC52 we decided we want to use REUSE to achieve that. NOTE: It might be a bit confusing that our PKGBUILD files also have a license field. However, this field specifies the upstream license, i.e. the license of the software that we package. It does not specify …

In October 2024 a team of dedicated developers has started work on the ALPM project. Since then it has been focusing on writing new documentation on many aspects of Arch Linux Package Management that were not thoroughly documented in the past. This article provides an overview of the specifications written by this project and attempts to contextualize them for the reader. The existing stack 📚 With its bash based makepkg tool for package creation, the libalpm C library for interfacing with system state and the central pacman package management tool, the pacman project has defined the …

With 20250613.12fe085f-5, we split our firmware into several vendor-focused packages. linux-firmware is now an empty package depending on our default set of firmware. Unfortunately, this coincided with upstream reorganizing the symlink layout of the NVIDIA firmware, resulting in a situation that Pacman cannot handle. When attempting to upgrade from 20250508.788aadc8-2 or earlier, you will see the following errors: linux-firmware-nvidia: /usr/lib/firmware/nvidia/ad103 exists in filesystem linux-firmware-nvidia: /usr/lib/firmware/nvidia/ad104 exists in filesystem linux-firmware-nvidia: /usr/lib/firmware/nvidia/ad106 exists in filesystem linux-firmware-nvidia: /usr/lib/firmware/nvidia/ad107 exists in filesystem To progress with the system upgrade, first remove linux-firmware, then reinstall it as part of the upgrade: # pacman -Rdd linux-firmware # pacman -Syu linux-firmware

On Plasma 6.4 the wayland session will be the only one installed when the users does not manually specify kwin-x11. With the recent split of kwin into kwin-wayland and kwin-x11, users running the old X11 session needs to manually install plasma-x11-session, or they will not be able to login. Currently pacman is not able to figure out your personal setup, and it wouldn't be ok to install plasma-x11-session and kwin-x11 for every one using Plasma. tldr: Install plasma-x11-session if you are still using x11