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

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

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

Archive repos snapshot changes
by Kristian Klausen 09 Nov '25

09 Nov '25

Hi all, We (DevOps) want to reduce [the I/O stress][1] on the archive server (archive.archlinux.org) by reducing the numbers of inodes (currently 55 millions). Most of these inodes (52,6 millions) originates from the daily snapshot (64k inodes) of the repositories. Going forward only the database files and the "sources" directory will be included in the snapshot (~120 inodes + ~2400 inodes for "sources") and all HTTP requests for package files will be redirected to the relevant package at https://archive.archlinux.org/packages/. E.g. https://archive.archlinux.org/repos/2025/11/02/core/os/x86_64/linux-6.17.6.… -> https://archive.archlinux.org/packages/l/linux/linux-6.17.6.arch1-1-x86_64.… Package files from existing snapshots will be removed at a later date. The "sources" directory will be removed at a later date, when a proper replacement is in place. If no concerns are raised before 2025-11-21 EOD, we will move forward with the changes. [1] All inodes must be traveresed for backup and hardlinking Cheers, Kristian Klausen DevOps

1 0

Dropping qt5-webengine
by Antonio Rojas 08 Nov '25

08 Nov '25

Hi, Qt5 is EOL since May. In particular, qt5-webengine's Chromium ships with unfixed vulnerabilities. Its code is bitrotting, which also makes it a costly package to maintain due to the frequent API changes in its dependencies (I had to give up on system ffpmeg and switch to its ancient bundled version, and currently doesn't build against ICU 78). I therefore think it's wise to drop it from our repos. Its remaining reverse dependencies are: csoundqt - can be built without it by disabling remote debugging support, MR at [1] fcitx-libpinyin - archived upstream for over a year globalprotect-openconnect - very out of date, a new version switching to wbkitgtk and rust is available in testing. kchmviewer - dead upstream (no activity in 4 years) qmc2 - dead upstream (no activity in 1.5 years) wiznote - dead upstream (no activity in 4 years) openshot - the only case of a (semi-)maintained application still unported to Qt6 - there was an attempt 3 years ago [2] aborted due to some drama and no signs of new efforts since then, porting is non-trivial. If there are no objections (that include an offer to pick up maintenance of the package), I will drop it and all its unported reverse dependencies in a few days. [1] https://gitlab.archlinux.org/archlinux/packaging/packages/csoundqt/-/merge_… [2] https://github.com/OpenShot/openshot-qt/pull/4836

3 3

GitLab unavailable at the moment
by Jelle van der Waa 05 Nov '25

05 Nov '25

Hi All, GitLab is experiencing some high load due to unknown reasons, devops is investigating. Expect issues when updating packages so maybe postpone them if you can. Greetings, Jelle

2 1

News Draft: waydroid >= 1.5.4-3 update may require manual intervention
by George Hu 05 Nov '25

05 Nov '25

The `waydroid` package prior to version `1.5.4-2` (including `aur/waydroid`) creates byte-compiled Python 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 overwrite 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 remove the conflicting files by running the following command before upgrading: ```sh find /usr/lib/waydroid/tools/ -type d -name __pycache__ -exec sudo rm -rf '{}' + ``` -- Best Regards, George Hu / Integral

4 5