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

RFC Final Comment Period: "buildbtw build service"
by Rafael Epplée 03 Feb '26

03 Feb '26

An RFC has now entered Final Comment Period. In 14 days, discussion will end and the proposal will either be accepted, rejected or withdrawn: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/63 Please visit the above link for discussion. Summary: """ This RFC proposes a first vertical slice of a build service to streamline rebuilding packages with many reverse dependencies. It tackles problems like repetitive manual work, blocking staging repositories, missed reverse dependencies and lack of shared context, like build logs. Goals include automating rebuilds and build ordering, enabling unattended builds, and providing isolated repos for parallel work. Builds run in secure virtual machines via a GitLab executor, organized into namespaces with histories and automatic dependency graphs. Interaction happens through CLI (pkgctl) and a web UI with SSO. """

1 1

First step for non-x86_64 contributions
by Levente Polyak 27 Jan '26

27 Jan '26

# First step for non-x86_64 contributions Hey everyone, I'd like to share my view on the first step for targeting non-x86_64 architectures in our packages. While our official infrastructure for non-x86 support isn't ready yet and will still take some time to materialize, I'd very much like to avoid siting on our hands until that day comes. There's already a ton of community interest and effort around non-x86_64. There's plenty of low hanging fruits and clean patches that are easy to review, well contained, and good groundwork. So instead of waiting for the perfect day before starting, I'd like to open the door to small, clear, and non intrusive contributions under tightly scoped rules. We should rather slowly and carefully build up compatibility now, than scramble once infra, hardware and tooling catches up. I propose the following guidelines as a first step towards implementing [RFC0032](https://rfc.archlinux.page/0032-arch-linux-ports/). ## Guidelines ### Protecting x86_64 We do not want to compromise on our primary platform. Clearly do not break or remove x86_64 behavior, functionality or features. Incompatible features or dependencies must be proposed in a way that preserves the functionality of our primary platform. ### Non-intrusive Small, focused changes that are easy to understand at a glance and can be reasoned about even without building and running it on different architectures. ### No downstream wizardry Complex, opaque, or heavy software patching is out of scope. Carrying around massive software patches downstream isn't feasible at this stage, save that for later and work together with upstream instead. ### Merge-request indicator All secondary architecture related merge-requests must be flagged with the new `pkg::ports` GitLab label. It'll help separate them from the usual requests and allow interested packagers and contributors to filter on them globally, to help out others. ### Manageable load Contributors must stick to small merge-request batches max 10 open MRs per person. All proposals must be sent manually, no fire-and-forget scripts. Collaboration is expected. If questions come up, we expect thoughtful responses from people who precisely know the changes they're submitting. ## Out of scope ### arch array No changes to `arch=()` arrays. ### non-x86_64 issues No issues or bug reports for non-x86_64. If something's broken with the `PKGBUILD`, you'll need to sort it out and send a merge-request. Don't file bugs in the tracker for other architectures. --- This approach allows us to slowly build up compatibility and make good progress without burning out our packagers and bug-wranglers or flooding our GitLab with changes and bug reports we can't handle. We can stretch out the work by allowing confined changes and avoid to stack it all for later. It gives us room to prepare without needing full build infrastructure, provide active support or require special hardware in place today. I think this really hits the right balance, tight enough to avoid burnout, open enough to make progress and welcoming enough to motivate and start harvesting work from our community. Cheers, Levente

9 14

Adding Christian Heusel as new main signing key holder
by David Runge 25 Jan '26

25 Jan '26

Hey all, for a while now we are short one active main signing key [1]. Traditionally, we have selected new main signing key holders from the list of developers. During Arch Linux summit 2025 we have been discussing this topic and brought forth the idea of selecting main signing key holders generally from the larger group of active staff instead. After a short discussion on the arch-dev mailing list, we received generally positive responses. As such, we are adding Christian Heusel as new main signing key holder [2] and Robin Candau as his revoker. His certificate has the OpenPGP fingerprint `99B6618472A3B3B814185BAED7D3D823B88BDB9B` and will be added to the archlinux-keyring. Best, David [1]: https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/issues/269 [2]: https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/issues/313 -- https://sleepmap.de

1 0

FOSDEM 2026 Dinner
by Robin Candau 24 Jan '26

24 Jan '26

Hi everyone, As usual, a few members of the Arch Linux team will be present at FOSDEM [1] this year. Since a few years now, we have held an "Arch dinner" during the FOSDEM weekend. It has been a great and well received event that we'd like to held again this year! 🙂 It will be held Saturday, January 31 at 20:00. The dinner is sponsored by Arch Linux and should cover a drink and a main course. We will cap the attendees to 20 people. Priority for members of the Arch staff. Any free spots after this can be taken by anyone interested. Please, send an email *offlist* to me [2] and Rafael [3] if you want to attend. The community users requesting spots will get a heads up the week before FOSDEM to give all staff a chance to reply. Please ask me if you have any questions. 🙂 [1] https://fosdem.org/2026/ [2] antiz(a)archlinux.org [3] raffomania(a)archlinux.org -- Regards, Robin Candau / Antiz

1 1

Arch Linux at FOSDEM 2026
by Robin Candau 22 Jan '26

22 Jan '26

Hi everyone, Members of the Arch Linux staff have historically always attended FOSDEM and this year is no different! A few of our staff members will be present at FOSDEM 2026. As always, we will try to settle down somewhere in the cantina so people can meet us (and also get some goodies 🤫). As last year, we will also hold an Arch Linux user meetup / BoF [1]! This BoF session will give a status update on the distribution, adjacent projects and future plans. There will be a short presentation followed by a Q&A session with Arch Linux distribution maintainers and project developers. Some of our staff members are also giving talks: - Rafael Epplée (raffomania): Federated Bookmark Sharing [2] - Robin Candau (Antiz): Relying on more transparent & trustworthy sources for Arch Linux packages [3] Finally, there's a "Reproducible Builds" meetup / BoF [4] to which some of us will participate or attend to as well. We wish everyone a good FOSDEM and we're looking forward to meet some of you there! 🤗 [1] https://fosdem.org/2026/schedule/event/LMBYTE-arch-linux-meetup-bof/ [2] https://fosdem.org/2026/schedule/event/YAMEDX-federated_bookmark_sharing/ [3] https://fosdem.org/2026/schedule/event/FFWA7E-transparent-sources-for-arch-… [4] https://fosdem.org/2026/schedule/event/8ETZS3-reproducible_builds_meetup/ -- Regards, Robin Candau / Antiz

1 0

Please finish the package license todo-list
by Jelle van der Waa 20 Jan '26

20 Jan '26

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/

2 1

Changes in pacman-mirrorlist package regarding HTTP mirrors
by pitastrudl 17 Jan '26

17 Jan '26

Hi all, A week ago or so [1] a change in the pacman-mirrorlist package was merged, where we removed listings of HTTP based mirror URLs so only HTTPS based mirrors remain in the newly released pacman-mirrorlist package. To further clarify, this does not translate to making HTTP based mirrors unsupported, they are still available on the mirrorlist[2] endpoint that is used by other mirrorlist fetching tools like reflector. Best regards, Arun Mirrorlist team [1]https://gitlab.archlinux.org/archlinux/packaging/packages/pacman-mirrorli… [2]https://archlinux.org/mirrorlist/

2 1

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