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

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

Introducing bumpbuddy
by Robin Candau 07 Aug '25

07 Aug '25

Hi everyone, We are very happy to announce the addition of a new member to the "buddy" family: bumpbuddy! [1] Initially introduced to Arch staff during last year's Arch Summit as the "nvchecker-poc" [2], bumpbuddy is now (a)live and ready to assist our package maintainers and users in monitoring new upstream releases for our packages. ## What is bumpbuddy? Bumpbuddy is a daemon watching for new upstream releases for our packages. It automatically opens GitLab issues for out of date packages [3], keep them updated if needed (e.g. if a newer upstream release supersedes the initially reported one) [4] and closes them once the matching version has been pushed [5]. It intends to fill the gaps in current methods for new upstream release tracking and reporting by proposing a centralized and automated solution. ## Benefits for package maintainers Bumpbuddy takes advantage of the `.nvchecker.toml` file from GitLab's packages repo to perform automated tracking of new upstream releases. Therefore, Package Maintainers won't need to rely on manual `pkgctl version check` runs or "homemade" solutions to track new upstream releases for their packages anymore. The reporting of new upstream releases being done via GitLab issues offers a (public) place to discuss and collaborate around eventual problems or blocking points preventing a new release from being packaged [6]. Assignment to those "out of date" issues is opt-in and can be enabled by reacting with the "package" emoji from bugbuddy's user settings [7]. Note that such issues are automatically opened as "confirmed", so bug-wranglers will not get assigned. ## Benefits for users Thanks to bumpbuddy automated tracking and reporting, our package maintainers should now be aware of new upstream releases without requiring users to manually flag packages out of date via the dedicated button on Archweb (which we actually intend to get rid of at some point, more on that in the next chapter). Another benefit for users is that, as opposed to the current "flag out of date" feature, GitLab issues offer a public place to look for (or ask for) the state of a pending update. This should hopefully allow for more transparency towards users wondering why a specific update is taking some time to be packaged. ## Current specifications and future work Bumpbuddy currently runs every 3 hours, which means that it may take up to 3 hours for new releases to be reported and for the associated GitLab issue to be automatically close once the matching version has been pushed. It's also worth reminding that the version tracking is based on the `.nvchecker.toml` configuration file of packages repo, meaning that an erroneous configuration file may result in erroneous version reporting and that packages that miss a configuration file will not be monitored. Here are a few mid / long term goals we have for bumpbuddy: - Provide a web overview for reports [9]. - Provide an API endpoint for `pkgctl version check` (to produce faster results). - Manage "out of date" status for packages on Archweb and get rid of the "flag out of date" button; which is manual (and therefore error prone), may be used wrongly/abusively (e.g. to report bugs or send some spam), is highly dependent on packages popularity and lacks transparency (as it doesn't provide a public place to discuss eventual blocking points). - Open merge requests rather than (or in addition of) GitLab issues, including the result of `pkgctl version upgrade` (regarding our future goal to adopt a gitops workflow for packaging). - And more... [10]. ## Conclusion This is the first iteration of bumpbuddy and things are still at a fairly early stage, so bear with us and don't hesitate to open issues [10] to submit bug reports or suggesting improvements. I would like to thank everyone who helped us improving bumpbuddy so far by opening issues, sharing opinions and opening merge requests. I would also like to give a special thank to Segaja, mh4ckt3mh4ckt1c4s and yan12125, who have been (beta) testing bumpbuddy for the past few months, as well as a huge thanks to klausenbusk & gromit for their amazing work and precious help on that project! [1] https://gitlab.archlinux.org/archlinux/bumpbuddy [2] https://pkgbuild.com/~antiz/presentations/Nvchecker_PoC/ [3] https://gitlab.archlinux.org/archlinux/packaging/packages/timeshift/-/issue… [4] https://gitlab.archlinux.org/archlinux/packaging/packages/timeshift/-/issue… [5] https://gitlab.archlinux.org/archlinux/packaging/packages/timeshift/-/issue… [6] https://gitlab.archlinux.org/archlinux/packaging/packages/timeshift/-/issue… [7] https://gitlab.archlinux.org/archlinux/bugbuddy/-/issues/1 [8] https://archlinux.org/packages/extra/x86_64/timeshift/flag/ [9] https://gitlab.archlinux.org/archlinux/bumpbuddy/-/issues/10 [10] https://gitlab.archlinux.org/archlinux/bumpbuddy/-/issues/ -- Regards, Robin Candau / Antiz

3 3