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

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

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

15 Jan '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 0

FOSDEM 2026 Dinner
by Robin Candau 06 Jan '26

06 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 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