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

p11-kit pulled from testing
by Jan Alexander Steffens (heftig) 16 Jan '26

16 Jan '26

I've removed p11-kit 0.26.0-1 from testing as it causes Firefox to distrust all the system CAs, failing to connect. This concerns the following packages: - libp11-kit - p11-kit - p11-kit-docs - lib32-p11-kit Please downgrade these packages to the last release (0.25.10-2) if you've upgraded already.

1 0

Bumpbuddy: New dashboard and features
by Robin Candau 15 Jan '26

15 Jan '26

Hi everyone, Last summer, we introduced bumpbuddy [1], a daemon watching for new upstream releases for our packages. Bumpbuddy offers a centralized and automated way for tracking and reporting new upstream release for our Package Maintainers; also providing a public place (in the form of GitLab issues [2]) for anyone to discuss the state of a pending package update, allowing for more transparency in the process. Since the initial introduction published a few months ago, bumpbuddy got a fair amount of new features & releases, so we thought it might be a good time for a follow-up! ## Dashboard Bumpbuddy's data are now publicly exposed and reported on a dedicated web dashboard [3]. This dashboard allows anyone to visualize and search through the state of monitored packages. Here are the list of the reported parameters: - Package: The package name. - Local version: The current version of the package in our GitLab package repositories. - Upstream version: The latest upstream version for the package reported by bumpbuddy. - Up to date: "Up to date" status of the package. - ✅ = Up to date - ❌ = Out of date - ⚠️ = Bumpbuddy is not able to determine the latest upstream release (due to nvchecker failures) - Issues: Link to the GitLab issue reporting the "out of date" status of a package and / or repeated nvchecker failures. - Last check: Time and date of the last check for the package. ## Report of repeated nvchecker failures As mentioned in the dashboard paragraph, bumpbuddy now also reports repeated nvchecker failures (after a specific threshold) through GitLab issues [4]. This allows to keep track and investigate eventual faulty nvchecker configurations preventing bumpbuddy to properly detect new upstream releases. Once the issue is fixed (and if not done already); such issues are automatically closed by bumpbuddy itself at the next run [5]. ## New dedicated issue labels To allow for more fine grained classification of the opened GitLab issues, the `scope::out-of-date` label was replaced by `package::out-of-date`, so that the reported upstream release can be further classified (e.g. with `scope::security` or `scope::bug`). Following the same pattern, issues for repeated nvchecker failures are labelled with `package::nvchecker` and `scope::bug`. ## General improvements and fixes Various improvements and fixes have been added, including: - Error handling for API calls, avoiding unexpected duplicate issues. - Continious update of the API data, to ensure up to date data for consumers. - Improvements of the pkgbases to GitLab path names conversion (so that e.g. the `bonnie++` pkgbase is correctly converted to `bonnieplusplus` in the GitLab path name). - Update opened GitLab issues on local package version changes (and not only on upstream version changes). - Deletion of the automated comment when updating an opened issue (as it globally ended up as extra "noise"). ## Work in progress We have some work in progress regarding our future goals, most notably: - pkgctl: Automatically close 'out-of-date' issue when releasing a new package version [6], allowing for an instant closing of 'out-of-date' issues when the matching (or a newer) version is being pushed (as compared to today where issues are only closed at the next bumpbuddy run), and generally reducing the extra "noise" cause by the multiple notifications when an issue is being closed by bumpbuddy. - archweb: import bumpbuddy data [7], getting closer to our future goal of replacing the current "Flag Package Out-of-Date" manual button by automated bumpbuddy reports. Further work regarding additional future goals will follow! Huge thanks to klausenbusk, anthraxx and jelle for their amazing work on those new features, improvements and ongoing efforts! [1] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o… [2] https://gitlab.archlinux.org/archlinux/packaging/packages/python-fastapi/-/… [3] https://bumpbuddy.archlinux.org/ [4] https://gitlab.archlinux.org/archlinux/packaging/packages/schroot/-/issues/1 [5] https://gitlab.archlinux.org/archlinux/packaging/packages/schroot/-/issues/… [6] https://gitlab.archlinux.org/archlinux/devtools/-/merge_requests/338 [7] https://github.com/archlinux/archweb/pull/598 -- Regards, Robin Candau / Antiz

1 0

new unstable repositories
by Christian Hesse 06 Jan '26

06 Jan '26

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 19

Adding the Mediation Team as Code of Conduct body for staff
by gromit 03 Jan '26

03 Jan '26

Hello everyone, I wanted to bring some attention to [this merge request][0], in order to gather feedback on the contained proposal and to follow the established process for making changes to the code of conduct. The underlying motivation for this request has been that I always felt that we as mediators were elected make sure that everyone keeps enjoying to contribute their free time to the Arch Linux projects and finds themselves in a welcoming and fun environment if they decide to do so. In order to get achieve this we started to take two types of actions: - Reactive: As specified in the [RFC!0009] the mediation team can be queried to settle disputes and newly establish previously lost trust between two parties that clashed over personal or other matters. - Proactive: Whenever people act in a manner that is detrimental to the atmosphere in the project or not constructive to a specific discussion we tried to intervene in order to have everyone be nice to each other again and to allow everyone to focus on the actual issues being discussed. Reflecting on some of the instances where we tried to proactively moderate a discussion we realized in the team that we don't have much options beyond a "hey please don't do that" and for example can't formally warn people if their conduct stays unchanged. This is unless there is a failed mediation (see the RFC for details on that) which in itself is an involved process and requires some other party to request mediation, which is not sensible for all kinds of situations. The resulting proposal therefore is that we as a mediator team assist the project leader for code of conduct related topics concerning Arch Linux staff itself. The process mentioned in the beginning of this mail defines a 14-day discussion period, but given that a lot of people are currently on vacation and might not neccesarily pay attention to their email it's fair to extend this by another week to the 13th January. If you have any feedback this is very much welcome, lets discuss it on the merge request! Cheers, Christian / gromit P.S.: I wish everyone a merry christmas if you celebrate it and a few refreshing days with friends, family and hopefully lots of nice food over new year! [0]: https://gitlab.archlinux.org/archlinux/service-agreements/-/merge_requests/… [1]: https://rfc.archlinux.page/0009-mediation-program/

2 2

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

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