December 2025 - Arch-dev-public - lists.archlinux.org

News draft: NVIDIA 590 driver drops Pascal support; main packages switch to Open Kernel Modules
by Peter Jung 18 Dec '25

18 Dec '25

Hey all, Below you can find the news draft for the changes in the new 590 Driver. You can also find an explanation in this commit: https://gitlab.archlinux.org/archlinux/packaging/packages/nvidia-utils/-/co… 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. Best regards, Peter

1 0

systemd v259 pre-releases
by Christian Hesse 18 Dec '25

18 Dec '25

Hello everybody, the systemd development team has pushed the first pre-release for the upcoming v259 release. Please see the NEWS [0] for details. As announced in the PKGBUILD [1] I have prepared packages and pushed them to my personal testing repository. Have a look at this if you are brave and want to have a first look. Happy testing! [0] https://github.com/systemd/systemd/blob/v259-rc1/NEWS [1] https://gitlab.archlinux.org/archlinux/packaging/packages/systemd/-/blob/ma… -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

1 3

The Arch Linux WSL image is now reproducible
by Robin Candau 17 Dec '25

17 Dec '25

Hi everyone, Allow me to share a great milestone we've been able to recently reach: Our WSL image [0] is now bit-for-bit reproducible [1]! Here is a quick sum up of the issue we faced and the fixes we applied for them: ----- ## Installing packages from an archived repo snapshot To ensure that the same exact versions / releases of packages get installed in the image across builds, we defined an archived snapshot of our repositories (via our "Arch Linux Archive" service [2][3]) as the source to download packages during build. The date for the daily archived repo snapshot is based against the version of the built image (which is date based). The same date is also used as the `SOURCE_DATE_EPOCH` (SDE) timestamp (see below points for SDE usage). ## Normalize filesystem `mtimes` with SDE With SDE set in our build script, we normalized `mtimes` of the rootFS against it as a post-build operation to avoid non-deterministic timestamps on that front: ``` find "$BUILDDIR" -exec touch --no-dereference --date="@$SOURCE_DATE_EPOCH" {} + ``` ## Get rid of Pacman logs during build (timestamps recording) Pacman records each operation with the associated timestamp in its logfile (/var/log/pacman.log). Since we don't particularly need Pacman logs to be recorded during the image build, we redirected them to `/dev/null/`: ``` pacman \ [...] --logfile /dev/null \ [...] ``` ## Normalize packages' installation date in Pacman's local package DB Pacman records packages' installation date, resulting in non-deterministic timestamps recording in the metadata included in the local package database. Fortunately, Jelle van der Waa recently brought support in Pacman for honoring SDE on that front [4]. With the related commit being merged in our latest pacman package release, simply exporting SDE in our build script was enough to normalize packages' installation date in Pacman's local package database. ## Delete Pacman keyring Pacman OpenPGP keys (generated with `pacman-key`) implies non-deterministic data in the local Pacman keyring. Fortunately, WSL has a built-in "oobe" (Out Of the Box Experience) mechanism [5] that allows to automatically run a script at the first boot of the image. We therefore took advantage of this mechanism to completely delete the Pacman's keyring as a post-build operation and automatically recreate it at the first boot of the image via the "oobe" script (by running `pacman-key --init && pacman-key --populate archlinux` from it). ## Normalize tar's `mtimes` and ordering Our rootFS for the WSL image is archived with `tar`, to which we added a few options to normalize `mtimes` (against SDE) as well as ordering, in order to avoid non-determinism on that front: ``` tar \ [...] --mtime="@$SOURCE_DATE_EPOCH" \ --clamp-mtime \ --sort=name \ [...] ``` ## Delete tar's `atimes` / `ctimes` Finally, we got rid of tar's `atimes` / `ctimes` to avoid non-deterministic timestamps in the archive's metadata: ``` tar \ [...] --pax-option=delete=atime,delete=ctime \ [...] ``` ----- For more details, you can take a look at the related merge requests, respectively to test the image reproducibility from a dedicated GitLab CI stage [6] and to actually make the image reproducible (including all the above fixes) [7]. At the moment, the result of the dedicated CI stage verifying the image reproducibility is non-blocking for releasing, but we intend to make it mandatory soon (given that we achieved to maintain a full reproducibility until then). The additional good news is that, since it's built in a similar way, most of those fixes should also apply to our Docker image [8] as well ; with the exception of the Pacman keyring related issue which will need to be dealt with differently, somehow... (since, as far as I know, OCI images doesn't have any built-in / straightforward mechanism to run a script or commands automatically at first boot, like the WSL "oobe" mechanism). This represents a meaningful achievement regarding our global "reproducible builds" related efforts and is encouraging for future related work on our other releng images! [0] https://gitlab.archlinux.org/archlinux/archlinux-wsl [1] https://reproducible-builds.org/ [2] https://archive.archlinux.org [3] https://wiki.archlinux.org/title/Arch_Linux_Archive [4] https://gitlab.archlinux.org/pacman/pacman/-/commit/f4bdb77470528019aaba4d8… [5] https://learn.microsoft.com/en-us/windows/wsl/build-custom-distro#add-the-w… [6] https://gitlab.archlinux.org/archlinux/archlinux-wsl/-/merge_requests/74 [7] https://gitlab.archlinux.org/archlinux/archlinux-wsl/-/merge_requests/76 [8] https://gitlab.archlinux.org/archlinux/archlinux-docker -- Regards, Robin Candau / Antiz

1 0

Please finish the package license todo-list
by Jelle van der Waa 15 Dec '25

15 Dec '25

Hi all, The Python rebuild is off to a bit of a rocky start with ~ 100 packages which fail `pkgctl license check`. Please help complete this todo so we can keep rebuilding. [1] https://archlinux.org/todo/make-packages-license-compliant/

1 0

GitLab behind Anubis
by Kristian Klausen 14 Dec '25

14 Dec '25

Hi all, To deflect yet another scraping attack against our GitLab instance, it has been hastily put behind Anubis. This may have broken stuff. Please reach out if notice anything that does not work, either by replying to this email or #archlinux-devops on IRC. Cheers, Kristian Klausen DevOps

1 0

Python 3.14 rebuild starting
by Jelle van der Waa 13 Dec '25

13 Dec '25

Hi all! Let's start the Python 3.14 rebuild as Christmas present for our users! This effectively means [staging] will be blocked for a longer period of time before everything is rebuild. I'll start after the hdf5 rebuild has been moved and will first bootstrap the build tooling (setuptools, flit, pytest, etc.). When that's done a todolist will be opened for all Python packages. Do note that there will be cycles which need to be broken up by building packages without tests first. Greetings, Jelle

1 0

Fwd: Looking for feedback on CONFIG_MODULE_HASHES for Linux
by Robin Candau 10 Dec '25

10 Dec '25

Hi everyone, As discussed during this year's Arch summit, Thomas is seeking help / support from projects that could benefit from his patch set which aims to enable reproducible kernel packages for Linux distributions (see the forwarded mail below). As far as I can tell, this is something we would be interested in. I think it would be nice if we could "officially" claim our interest as "Arch Linux" to hopefully provide some assistance to Thomas for his incoming discussion with upstream. Does any of the kernel packages maintainers on our side wants to jump in (or anyone else interested with some kernel knowledge, I guess)? -------- Forwarded Message -------- Subject: Looking for feedback on CONFIG_MODULE_HASHES for Linux Date: Thu, 13 Nov 2025 21:10:58 +0100 From: Thomas Weißschuh via rb-general <rb-general(a)lists.reproducible-builds.org> Reply-To: General discussions about reproducible builds <rb-general(a)lists.reproducible-builds.org> To: rb-general(a)lists.reproducible-builds.org CC: Thomas Weißschuh <thomas(a)t-8ch.de> Hi everyone, I am the author of the CONFIG_MODULE_HASHES patchset [0] for the Linux kernel which aims to enable reproducible kernel packages for Linux distributions. My goal is to reignite development and continue with the upstream process. To have a better base to argue with I'd like to get some confirmation that distributions have looked at the patches and do intent to adapt this scheme when it is available in the mainline kernel. That should help me get some leverage with the upstream maintainers. The current form of the patches can be found at [1], they are only slightly adapted from the previous submission to LKML. Remaining open topics before the next submission are proper IMA support and stripping of modules. Future changes may introduce more hash algorithms and performance improvements, but these should not be relvant for now. So if you are packaging Linux for your distribution, have looked at my patches and are eager to use them, please let me know. My plan is to talk with the upstream maintainers at the upcoming Linux Plumbers Conference on 11th of December. Thanks, Thomas [0] https://lore.kernel.org/lkml/20250429-module-hashes-v3-0-00e9258def9e@weiss… [1] https://git.kernel.org/pub/scm/linux/kernel/git/thomas.weissschuh/linux.git…

2 1

News draft: .NET packages may require manual intervention
by George Rawlinson 09 Dec '25

09 Dec '25

The following packages may require manual intervention due to the update 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: ```sh pacman -Syu aspnet-runtime-9.0 pacman -Rs aspnet-runtime ```

1 0

new unstable repositories
by Christian Hesse 07 Dec '25

07 Dec '25

Hello everybody, for some time I used to push rc release for some packages (namely systemd & util-linux) to core-testing. This broke once, when a package was built against that rc release and thus did depend on new symbols, then finally was moved before the package it was built against. After that I pushed all the rc releases to a public personal repository, anybody interested could test from there. But I think the audience was a lot smaller, and last systemd release revealed some unexpected regressions *after* final release. That situation is not any better, especially when rc releases in Arch were a major factor in finding regressions early. At Arch Summit 2025 we had a chat about that situation and discussed several ideas. In the end we came up with one reasonable solution: We should introduce new repositories [core-unstable] and [extra-unstable] for this kind of testing. People would still have to enable these repositories, but I guess chances are higher than for my personal repository. I guess we have three places that need to be touched: * create repositories on servers (-> DevOps) * dbscripts * devtools Anything more? Feedback is welcome, same for other ideas - this is not set in stone and I am open for anything that works for me/us. Thanks! -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

7 17