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

RFC: Automated digital signing of OS artifacts
by David Runge 17 Jun '25

17 Jun '25

A new RFC (request for comment) has been opened here: 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 in a colocation. 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

Update on Valve sponsored work in May 2025
by Rafael Epplée 17 Jun '25

17 Jun '25

Hi all, here is a quick progress report on Valve sponsored work in May 2025. ## Weeklies - [2025-05-13] - [2025-05-20] - [2025-05-27] ## Signstar This month we have been focusing on getting the RFC for automated signing of OS artifacts ready (we apologize in advance - it is not going to be a short one). We estimate to publish it this month (June). In the Signstar project we have improved the way we run integration tests, by implementing a custom target runner, that allows us to seamlessly run some tests in containerized environments (see [signstar!237]). We've updated our cryptography libraries (rpgp 0.16 includes support for Post Quantum Cryptography) and started work on gathering code coverage for tests. Further work has gone into adding a module for NetHSM syncing and state handling to the signstar-config crate (see [signstar!165]/[signstar!249]). ### Hours billed for Signstar April: David (35h), Wiktor (91h) ## Buildbtw We're focused on getting builds running in VMs inside gitlab pipelines. Besides that, we want to release parts of the PoC that can already be useful to other Arch Linux projects. - We've implemented background running of virtual machines in vmexec to support our custom gitlab runner executor which runs in multiple discrete steps, requiring virtual machines to stay running between each of them ([vmexec-background]). - We've improved vmexec's robustness, and fixed more bugs ([vmexec-pty], [vmexec-exit-codes], [vmexec-stderr]). - We've decided to license the buildbtw source code under GPL. - We're planning to release a standalone tool for keeping a local copy of all of Arch Linux' package source repositories and automatically fetching any changes. This can be used by projects such as bumpbuddy or ALPM. - We've started polishing up the CLI, web UI and documentation in preparation for a first PoC user test. We'd like to invite everyone who's interested to participate in our weekly coordination meetings. Tuesdays at 17:00 UTC (19:00 CEST), we meet on the Arch Linux Mumble server to discuss the current state of the project, groom gitlab issues, discuss technical questions and plan the week ahead. You're welcome to join and listen, or to contribute your expertise. If you'd like to participate through other means, we've also made an effort to clean up our issue tracker. Please browse the issues and pitch in if something feels unclear, or information is missing. You can follow along our day-to-day progress on the proof-of-concept milestone ([poc-milestone]) and the standalone tool milestone ([tool-milestone]). ### Hours billed for buildbtw and package source licensing May: Rafael (53h), Sven (81h), Levente (0h) ## Package Source Licensing - After some last fine-tuning, Morten has merged the RFC40 amendment (thanks!) ([rfc40]) - We've prepared a draft mail with packager guidelines for arch-dev-public ([licensing-adp-mail]) - We've created a plan for licensing new contributions since our last batch of licensing notification mails. Once RFC52 is merged and we've added REUSE.toml files to all repositories where all contributors have been notified, we'll send out a second batch of licensing notifications for new contributors. After a second 4 month waiting period, we'll add REUSE.toml files to the rest of the repositories. [2025-05-13]: https://md.archlinux.org/wmTzaT1IQlGp3S3WuDJgiA# [2025-05-20]: https://md.archlinux.org/s2yfyaFJTVavU1nMI2h6XQ# [2025-05-27]: https://md.archlinux.org/JDxTHJ4-Sw60bnDNPTWZXg# [vmexec-background]: https://gitlab.archlinux.org/archlinux/vmexec/-/merge_requests/5 [poc-milestone]: https://gitlab.archlinux.org/archlinux/buildbtw/-/milestones/11#tab-issues [signstar!165]: https://gitlab.archlinux.org/archlinux/signstar/-/merge_requests/165 [signstar!237]: https://gitlab.archlinux.org/archlinux/signstar/-/merge_requests/237 [signstar!249]: https://gitlab.archlinux.org/archlinux/signstar/-/merge_requests/249 [tool-milestone]: https://gitlab.archlinux.org/archlinux/buildbtw/-/milestones/17#tab-issues [vmexec-pty]: https://gitlab.archlinux.org/archlinux/vmexec/-/merge_requests/1 [vmexec-exit-codes]: https://gitlab.archlinux.org/archlinux/vmexec/-/merge_requests/7 [vmexec-stderr]: https://gitlab.archlinux.org/archlinux/vmexec/-/merge_requests/6 [rfc40]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/49 [licensing-adp-mail]: https://md.archlinux.org/PYvbvENaTni5Skf67V1Jgg#

1 0

Zig packaging guidelines
by kpcyrd 17 Jun '25

17 Jun '25

hello, I've just changed minisign from C to Zig since this is now supported by upstream (it was quite the journey though). I noticed we don't have any packaging guideline for Zig yet so I would like to propose adding one. The example based on my notes is quite straight-forward: ``` depends=( glibc ) makedepends=( zig ) build() { cd "${pkgname}-${pkgver}" zig build --verbose -Dcpu=baseline -Doptimize=ReleaseSmall } package() { cd "${pkgname}-${pkgver}" install -Dm755 -t "${pkgdir}/usr/bin" zig-out/bin/example } ``` Common gotchas were: - The `zig build` command is essentially fully silent if no interactive terminal is attached, `--verbose` helped but it's still very little info - Without `-Dcpu=baseline` the compiler is going to probe the build server cpu, which both causes problems with Reproducible Builds, but more importantly can also make the binary crash with `Illegal instruction` errors, since the default binaries aren't really distributable Looking at the ncdu PKGBUILD shows there's some room for improvement: ``` build() { cd "${pkgname}-${pkgver}" DESTDIR="build" zig build \ --summary all \ --global-cache-dir ../zig-global-cache \ --prefix /usr \ --search-prefix /usr \ --release=safe \ -Dtarget=native-linux.6.1-gnu.2.38 \ -Dcpu=baseline \ -Dpie=true } check() { cd "${pkgname}-${pkgver}" zig build test \ --summary all \ --global-cache-dir ../zig-global-cache \ --prefix /usr \ --search-prefix /usr \ --release=safe \ -Dtarget=native-linux.6.1-gnu.2.38 \ -Dcpu=baseline \ -Dpie=true } ``` More input very welcome, but I'm also fine with adding a very basic one by myself and whoever has something to add can just edit the wiki. Never lose the plot, kpcyrd

5 5

Transition to the new WoW64 wine and wine-staging
by Peter Jung 14 Jun '25

14 Jun '25

We are transitioning the wine and wine-staging package to a pure wow64(1] build. This change removes the dependency on the multilib repository. The main reason for this is to align with upstream Wine development, which simplifies packaging and the dependency chain. Potential Issues: - OpenGL Performance: A known limitation of the new WoW64 mode is reduced performance for 32-bit applications that use OpenGL directly. - Breaking Changes: Existing 32-bit prefixes needs to be recreated If you are facing issues with 32 bit prefixes, please recreate these and reinstall the application. [1]: https://gitlab.winehq.org/wine/wine/-/releases/wine-9.0#wow64

2 1

RFC Final Comment Period: REUSE for package license linting
by Morten Linderud 13 Jun '25

13 Jun '25

An RFC has now entered its Final Comment Period. In 14 days, the discussion will end and the proposal will either be accepted, rejected or withdrawn: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/52 Please visit the above link for discussion. Summary: Utilize REUSE for package license linting for all package sources. -- Morten Linderud PGP: 9C02FF419FECBE16

1 0

RFC Final Comment Period: Establish default build flags for Fortran
by Jakub Klinkovský 12 Jun '25

12 Jun '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/54 Please visit the above link for discussion. Summary: This RFC establishes default build flags (`FFLAGS`, `FCFLAGS`, `DEBUG_FFLAGS`) for compiling Fortran code in Arch Linux packages, aligning them with the security hardening standards defined for C.

1 0

Adopting similar packages in extra
by Quentin Michaud 10 Jun '25

10 Jun '25

Hi all, I am interested in packaging vscodium [1] into extra but am worried that it would be seen as a duplicate of the code [2] package. This situation is unclear and not explicitly mentioned in the wiki [3]. I asked the question on Matrix/IRC and this stirred a larger debate, so artafinde suggested me to post the question here in order to have a record of the discussion and potential decisions. The (more generic) questions are the following: under which criteria do we want to accept multiple "similar" packages in official repos or replace one by another? Do we want to fix (or already have) rules or guidelines for these situations or do we want to proceed on a case-by-case basis? "similar" packages can mean different things, I see several categories: - Hard fork of a project but projects are very close / are trying to stay compatible. Examples : redis (AUR) / valkey (extra), terraform (extra) / opentofu (extra) - Soft fork of a project aiming at adding / removing functionalities using patches. Examples : vscode (extra) / vscodium (AUR), firefox (extra) / librewolf (AUR) and other Firefox forks - Rewrite of a project but aiming to achieve the exact same goals / drop-in replacement : Examples: sudo (core) / sudo-rs (extra), coreutils (core) / uutils (extra). This category is tricky because the definition of "exact same goals" is unclear, but I exclude software that implement common standards but that are vastly different in practice, such as docker / podman or openssh / dropbear. This is more relevant to the "replace one by another" part, as Ubuntu did recently with sudo [4]. As for the criteria on which to base these decisions, they are many but the most important ones that I was able to think of are: - licensing changes - user impact - compatibility / conflicts between forks / flavors of the same software I hope thinking and discussing about this will help us to set guidelines on how to handle such situations in the future and document it in the wiki. Your thoughts are welcome :) Cheers, Quentin Michaud / mh4ckt3mh4ckt1c4s [1]: https://vscodium.com/ [2]: https://archlinux.org/packages/extra/x86_64/code/ [3]: https://wiki.archlinux.org/title/Package_Maintainer_guidelines#Rules_for_pa… [4]: https://discourse.ubuntu.com/t/adopting-sudo-rs-by-default-in-ubuntu-25-10/…

5 5

Adopting similar packages in extra
by Quentin MICHAUD 09 Jun '25

09 Jun '25

1 0

Switch to a versioned packaging scheme for wlroots
by Robin Candau 31 May '25

31 May '25

Hi, Wlroots is one of the packages for which we need to keep multiple versions around to ensure compatibility with reverse dependencies. At the moment, we have a wlroots0.17 package [1] (for the few packages that still require it, most notably qtile [2]) and a "regular" wlroots package [3] that currently points to 0.18. We are evaluating bumping the wlroots package to 0.19, but that requires the introduction of a new wlroots0.18 package to preserve compatibility with reverse dependencies that are not yet compatible with 0.19 (similar to what was done with the wlroots0.17 package). This method makes new wlroots releases difficult to triage as we have to release both the wlroots package bump and the new wlroots0.18 package at the same time (to avoid breaking changes regarding reverse dependencies) while ensuring that we defined proper "conflicts" to avoid conflicting files issues during upgrade [4] (since we can't control in which order packages will be upgraded on users' system). For instance, the new wlroots0.18 package would likely need a "conflicts" array that looks like this; in order to avoid files collision with the "regular" wlroots package until it gets updated to 0.19 on users' system, and also to avoid an unexpected conflict with the wlroots0.17 package. ``` conflicts=( "wlroots<0.19" "wlroots>=0.18" ) ``` While the above _should_ work, this is a quirky dance that will eventually get more and more complex over time (e.g. if we have to accumulate more versions of wlroots in the future). As such, I would like to switch to a versioned packaging scheme for wlroots. This means dropping the "regular" wlroots package and solely rely on versioned packages like: wlroots0.17, wlroots0.18 & wlroots0.19 (similar to e.g. gtk2, gtk3, gtk4 in a sense). Wlroots already adopted a versioned so/lib naming scheme so there is no file collision between e.g. wlroots0.18 and wlroots0.19 (meaning we won't need the above "conflicts" array dance anymore). Technically speaking, that means introducing a new wlroots0.18 package that conflicts and replaces the current "regular" wlroots package (to ensure people make the switch without file conflicting issue) and a new wlroots0.19 package. We could then drop the "regular" wlroots package from the repo and keep moving with versioned packages only in the future (e.g. wlroots0.20, wlroots0.21, and so on...). Reverse dependencies can then explicitly point to the version they need (similar to how it's done currently with wlroots0.17). I'm aware that this may be unconventional regarding how we usually do things in Arch Linux, but I think it's fair to say that current way we have to deal with new wlroots releases is confusing and causes more harm than good. I think the above suggestion is a practical and relevant solution for such specific case. I created a related task todo list [5] that I will tackle today and put to staging. I intend to leave it in staging for a week or two in order to leave some time for people to react and / or raise any concerns I may have missed about switching to a versioned packaging scheme. Thanks :) [1] https://archlinux.org/packages/extra/x86_64/wlroots0.17/ [2] https://github.com/qtile/qtile/blob/master/docs/manual/wayland.rst?plain=1#… [3] https://archlinux.org/packages/extra/x86_64/wlroots/ [4] https://gitlab.archlinux.org/archlinux/packaging/packages/wlroots0.17/-/iss… [5] https://archlinux.org/todo/switch-to-a-versioned-packaging-scheme-for-wlroo… -- Regards, Robin Candau / Antiz

2 4

Amending RFC40 to remove custom 0BSD license
by Morten Linderud 26 May '25

26 May '25

Yo, Today I noticed that the "License package sources" RFC contained an amended 0BSD license that added a two paragraph exception for patch files and other auxiliary files. The purpose of this change is to ensure the license is not covering other files in the repository that the author can't license from the upstream. See: https://rfc.archlinux.page/0040-license-package-sources/ While this is a practical problem that needs to be solved, we should not be doing that through additional text in a FSF- and OSI approved license. This essentially makes it a custom license that is not really going to detected as 0BSD from external sources, and runs against the original goal of removing legal uncertainty. As the change, and by extension the problem itself, is not mentioned in the text it came as a surprise to me that it was done. What I think is more proper is to remove these two lines from the proposed license file, and move this to a separate RFC that would cover a use of the REUSE specification, or SPDX license identifiers. This would serve the same purpose as the Debian `copyright` files, while also being standardized. I have written a proposed amendment to the text that I hope people find okay. https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/49 *Please note that any licenses already added to the repository needs to be amended.* My goal is to write up a RFC for the REUSE/SPDX part of this before the current 3 month timeline where we'll start adding licenses to ensure we don't prolong the process. If people are curious how this would look like, I annotated the `usd` package as an example. https://gitlab.archlinux.org/foxboron/usd/-/tree/morten/reuse See the spec for more details: https://reuse.software/spec-3.2/ Cheers! -- Morten Linderud PGP: 9C02FF419FECBE16

6 11