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

RFC: buildbtw build service
by Rafael Epplée 23 Sep '25

23 Sep '25

Hey all, A new RFC (request for comment) has been opened here: 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 repos, 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. - Cheers, Rafael

1 0

systemd v258 pre-releases
by Christian Hesse 17 Sep '25

17 Sep '25

Hello everybody, the systemd development team has pushed the first pre-release for the upcoming v258 release. It is a massive feature release, with a huge amount of new functionality and goodies. 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 ware brave and want to have a first look. The comes with an updated mkinitcpio package, cherry-picking systemd-related changes. We should merge these before v258 release. Happy testing! [0] https://github.com/systemd/systemd/blob/v258-rc1/NEWS [1] https://gitlab.archlinux.org/archlinux/packaging/packages/systemd/-/blob/ma… [2] https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/merge_reques… -- 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 4

Update on Valve sponsored work in July 2025
by Rafael Epplée 08 Sep '25

08 Sep '25

Hi all, here is a quick progress report on Valve sponsored work in July 2025. ## Signstar Based on feedback from reviewers, we have added further research and data to [RFC 0059] which provides information on specific costs and technological differences between discussed options. Due to reviewer concerns with regards to colocation hosting feasibility and costs we have pivoted to support the YubiHSM 2 as default backend for the proposed solution. The existing NetHSM integration will remain for as long as possible to potentially be re-evaluated in the future. The code coverage setup has been split so that unit tests and integration tests each have their own report. In an additional step, we have also added coverage reporting for use-cases in which tests have to switch users. Logging to systemd journal with rich metadata has been added, in case journald is available in the given environment. An issue with doctests coverage being broken for multi-member projects has been investigated (see [cargo-llvm-cov#440]). A large part of the NetHSM handling backend has been merged and released, which allows to synchronize a NetHSM backend with a Signstar configuration file ([signstar!249]). To support further backends in the future, work on making the Signstar configuration file format less dependent on the existing set of crates related to the NetHSM has been started ([signstar!292]). A sample signer [yubihsm-pgp] with mock YubiHSM has been implemented. The PoC exercises all major features we would need (creating new ed25519 asymmetric key; creating new wrapping key, backed by 3 out of 5 Shamir’s Secret Sharing and key export/import; creating new OpenPGP certificate using HSM key; signing given data file using that certificate; verifying that file with SOP implementations). YubiHSM additionally has support for [key attestation], sadly, due to RustCrypto version drift it doesn't work when mixed with rPGP. Additionally, investigated internal YubiHSM audit log for operations, which stores all operations executed on the HSM. The log can be cryptographically verified that it has not been tampered with. [YubiHSM logs] ## wkd-exporter Added code coverage, based on the existing code from signstar. Generated code quality file for Gitlab so that each merge request has a nice presentation of what would change. Contributed `[metadata]` attributes to `just` [just#2794] and used that to track CI job package dependencies [wkd-exporter#16]. ### Hours billed for Signstar David (85h), Wiktor (124h) ## Buildbtw We've received lots of feedback from PoC testers which as lead to lots of improvements and a treasure trove of new issues we'll be able to reference while building towards the next milestone: the first "production" release. Our plan is to take all learnings from the PoC and use them to build a small, but polished foundation which will provide build services to all staff members (and eventually also drive-by gitlab contributors). The PoC will continue running for a while (consider joining the testing instance if you haven't done so!), and we've continued working on it. We drastically improved the scheduler's memory usage and performance, fixed lots of papercuts in the CLI and web UI, and fixed bugs, a major one of them in the graph calculation algorithm. We also merged the first contributions from gromit. Thank you, gromit! The impulses for these changes came from onboarding sessions for the PoC testing instance. Thanks to everyone who participated so far! For the new production milestone, we've created plans based on our experience with the PoC: an overhauled data structure for improved performance, a deployment concept and release strategy, OIDC authentication, an improved JSON API for scheduling builds, and a new module structure for the code. Last but not least, we started writing an RFC covering major workflows and requirements for the production system we're envisioning. ### Hours billed for buildbtw Rafael (79h), Sven (39.5h), Levente (0h) ## Package Source Licensing Implemented [pkgctl license](https://gitlab.archlinux.org/archlinux/devtools/-/merge_requests/3… and worked through many packages with bad licenses. Created a [todo to make all packages license compliant](https://archlinux.org/todo/make-packages-license-compliant/). ### Hours billed for Package Source Licensing Rafael (4h), Sven (81h) ## Meeting Notes Meeting notes are available for staff in the [internal-notes] repository. [internal-notes]: https://gitlab.archlinux.org/archlinux/internal-notes/-/tree/main/valve [RFC 0059]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/59 [cargo-llvm-cov#440]: https://github.com/taiki-e/cargo-llvm-cov/issues/440 [yubihsm-pgp]: https://gitlab.archlinux.org/wiktor/yubihsm-pgp [key attestation]: https://docs.yubico.com/hardware/yubihsm-2/hsm-2-user-guide/hsm2-core-conce… [just#2794]: https://github.com/casey/just/pull/2794 [signstar!249]: https://gitlab.archlinux.org/archlinux/signstar/-/merge_requests/249 [signstar!292]: https://gitlab.archlinux.org/archlinux/signstar/-/merge_requests/292 [wkd-exporter#16]: https://gitlab.archlinux.org/archlinux/wkd-exporter/-/merge_requests/16/dif… [YubiHSM logs]: https://docs.yubico.com/hardware/yubihsm-2/hsm-2-user-guide/hsm2-core-conce…

1 0

glib2 removed from core-testing
by Jan Alexander Steffens (heftig) 06 Sep '25

06 Sep '25

glib2 2.86.0-1 was removed from core-testing as it prevented gnome-shell from launching. Please downgrade any updated installs back to core/glib2 2.84.4-2. lib32-glib2 was removed as well.

1 0

New way to support Arch Linux: GitHub Sponsors
by Levente Polyak 05 Sep '25

05 Sep '25

Hey everyone, We've got a new way for you to support Arch Linux and help us pay our bills: GitHub Sponsors! https://github.com/sponsors/archlinux/ All funds go to our existing fiscal host at SPI, just like with PayPal or credit card donations: https://www.spi-inc.org/projects/archlinux/ Your support means the world to us, not just financially but also by being an active part of our community. We're super grateful and send love to our community 🫶. Let's keep this distro rolling together. 🚀

1 0

Standardize on running autoreconf in prepare()
by Jelle van der Waa 01 Sep '25

01 Sep '25

Hi All, After all the recent RISC-V news I went ahead and checked out the existing effort to get Arch Linux supported on RISC-V. Felix maintains an overlay of PKGBUILDs which require customization to be be able to build on RISC-V. A lot of these PKGBUILD's patch autotools projects to run `autoreconf -fiv` in prepare(), this re-generates `configure` to understand RISC-V. Since these patches are simple enough and I don't see them harming Arch Linux, I would argue that we want these patches applied in our packages. Re-generating configure should not break, and if it does we should not accept the patch and get a bug filled upstream. Re-creating configure and thus not using the provided `configure` could arguably also be a good thing regarding supply chain security. And this also should help with other architecture ports. As a follow up we can discuss providing our own "/usr/share/config.site" and then ./configure --prefix=/usr would automatically configure localstatedir, libexecdir, etc. [1] https://github.com/felixonmars/archriscv-packages [2] https://github.com/felixonmars/archriscv-packages/blob/master/libafterimage…

8 8

namcap 3.6.0 released
by Jelle van der Waa 24 Aug '25

24 Aug '25

Hi, Seen a long hiatus, finally a new namcap release has entered [extra-testing] Release notes: - Allow rules to be disabled by default - Allow namcap-devel to be run from any directory - Support '+' in license expressions - New unreproducible sphinx cache file rule - New dbus services improperly installed in /etc rule - Introduce typechecking using mypy and extend ruff linting rules - Don't crash on missing description, only throw error lint - Remove python-six from tests - Fix safeguards against false positives for QML dependency check - Limit shadow stack check to x86_64 binaries - Change from getopt to argparse Please report issues on GitLab [1] Thanks! Jelle [1] https://gitlab.archlinux.org/pacman/namcap/-/issues/

1 0

RFC Final Comment Period: "Automated digital signing of OS artifacts"
by David Runge 19 Aug '25

19 Aug '25

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/59 Please visit the above link for discussion. Summary: """ Introduce a centralized, hardware backed solution for the digital signing of OS artifacts. Gradually replace the need for manual signing of artifacts throughout the distribution. The stepwise plan in this document will eventually lead to changes for the following existing roles within Arch Linux staff: - _Package maintainers_ will no longer sign packages using their individual OpenPGP private key. - The amount of OpenPGP certificates for _main signing key holders_ to care for will be drastically reduced. - The _DevOps team_ will have to monitor and administrate additional physical machines. New groups of people within Arch Linux staff will - collectively take care of the administrative credentials for the described system as _holders of shares of a shared secret_, - provide software upgrades for components of the system as _developers of Signstar_ - and create releases for a central, image-based OS as _developers of Signstar OS_. For details refer to the section **changes for users and staff**. """

1 0

PKGBUILD SPDX License array RFC status
by Jelle van der Waa 18 Aug '25

18 Aug '25

Hi All, Some time ago we decided to adopt SPDX license identifiers in the license array of PKGBUILD's. Without having progress reports its hard to know what the current status is, so I made a little script with some borrowed logic from namcap. [1] This uses expac to extract the licenses array from the local package sync db (/var/lib/pacman/sync). The unknown / invalid entries are emitted on stderr and stdout contains JSON data to be consumed by whatever tool you might suit you :-) A test run on my machine gave the following output, in summary: [2] * invalid: 62 * unknown: 4743 I hope having an easy script to collect statistics will move the conversion process forward. But do note that the original RFC does not yet tackle the `custom` license question. [3] [1] https://github.com/jelly/Dotfiles/blob/master/bin/arch-spdx-statistics [2] https://gist.githubusercontent.com/jelly/c5b790c3b1223f91362d956d50401e93/r… [3] https://rfc.archlinux.page/0016-spdx-license-identifiers/#unresolved-questi…

2 2

Removing port 222 for git on gitlab.archlinux.org
by Kristian Klausen 09 Aug '25

09 Aug '25

Hi all, the git migration happened more than two years ago[1] and as part of that the SSH port for git was changed from port 222 to the default SSH port 22[2]. A port redirect was added at the time to avoid disrupting existing local git repositories using the old port. Time has now come to removing said port redirect, which will happen one week from now. So if you have local git repositories using the old port, please change them to use the standard SSH port. See below for an example. $ git remote -v origin ssh://git@gitlab.archlinux.org:222/archlinux/infrastructure.git (fetch) origin ssh://git@gitlab.archlinux.org:222/archlinux/infrastructure.git (push) $ git remote set-url origin git@gitlab.archlinux.org:archlinux/infrastructure.git $ git remote -v origin git@gitlab.archlinux.org:archlinux/infrastructure.git (fetch) origin git@gitlab.archlinux.org:archlinux/infrastructure.git (push) [1] https://archlinux.org/news/git-migration-completed/ [2] https://gitlab.archlinux.org/archlinux/infrastructure/-/commit/bc1e7f777283… Cheers, Kristian Klausen DevOps

1 1