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

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

Scheduled maintenance for gitlab.archlinux.org
by gromit 09 Jul '25

09 Jul '25

Hello everyone, our hosting provider Hetzner has just informed us that there will be a scheduled downtime window on the 9th July 2025 starting on 10:00 GMT+2 until 14:00 GMT+2 [to replace the mainboard of our Gitlab server][0]. During this time period the service will be offline for up to 40 minutes + however long it takes us to fix potentially resulting issues with the booloader, network configuration and so on. This will effect the following services/components of our distribution ecosystem: - Packaging: No packages can be updated during the downtime (as the source repositories for it will be offline) - Project Maintainers: The other projects (pacman, aurweb, buildbtw, signstar, mirrors repo etc.) will be unavailable - Bugtracker: No bugs can be reported during this timeframe - Static sites as served via Gitlab Pages (Arch Linux WKD, project pages etc.) will not be available We can not really circumvent the downtime and think it's an acceptable timeframe to not warrant any further action from us as a team. Let us know if you have any questions or additions to the above! Cheers, Christian for the DevOps Team [0]: https://docs.hetzner.com/robot/dedicated-server/general-information/mainboa…

1 1

Re: What is "Arch Linux Modernity" these days? (cvlc12)
by Cédric Clavel 22 Jun '25

22 Jun '25

Hi, I'd like to chip in about modernity, and draw attention to https://gitlab.archlinux.org/archlinux/ideas/-/issues/13 It's still not really possible to perform a clean installation using UKIs straight out of the box, at least not by following the installation guide. Using UKIs will most likely require using pacman hooks from AUR or added manually. I think it should be a lot more straightforward to set that up in a 'modern' OS. Using 'kernel-install' would probably streamline things a lot, and choosing between UKIs and traditional linux/initrds is as simple as setting this in `/etc/kernel/install.conf` Happy to hear your thoughts, have a good day Le dimanche 22 juin 2025 à 08:09 +0000, arch-dev-public-request(a)lists.archlinux.org a écrit : > Send Arch-dev-public mailing list submissions to > arch-dev-public(a)lists.archlinux.org > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > arch-dev-public-request(a)lists.archlinux.org > > You can reach the person managing the list at > arch-dev-public-owner(a)lists.archlinux.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Arch-dev-public digest..." > Today's Topics: > > 1. What is "Arch Linux Modernity" these days? (Andrei Korshikov) > 2. Re: What is "Arch Linux Modernity" these days? (Andrei > Korshikov) > _______________________________________________ > Arch-dev-public mailing list -- arch-dev-public(a)lists.archlinux.org > To unsubscribe send an email to > arch-dev-public-leave(a)lists.archlinux.org

1 0

What is "Arch Linux Modernity" these days?
by Andrei Korshikov 21 Jun '25

21 Jun '25

Hi, folks. I don't like the second paragraph of [1]. All that stuff (systemd, udev, …) was modern 10+ years ago, but nowadays they all are kind of mainstream. So, could you say what you think about modernity? My very personal opinion [2]—that second paragraph should be just deleted. But I hope you will point me out. --- Andrej Koršikov [1]: https://wiki.archlinux.org/title/Arch_Linux#Modernity [2]: https://wiki.archlinux.org/index.php?diff=838344

2 2

RFC - Manual changes for Plasma 6.4.0
by Tomaz Canabrava 20 Jun '25

20 Jun '25

Plasma 6.4.0 will need manual intervention if you are on X11 On Plasma 6.4 the wayland session will be the only one installed when the users does not manually specify kwin-x11. With the recent split of kwin into kwin-wayland and kwin-x11, users running the old X11 session needs to manually install plasma-x11-session, or they will not be able to login. Currently pacman is not able to figure out your personal setup, and it wouldn't be ok to install plasma-x11-session and kwin-x11 for every one using Plasma. tldr: Install plasma-x11-session if you are still using x11

2 2

News draft: linux-firmware >= 20250613.12fe085f-5 upgrade requires manual intervention
by Jan Alexander Steffens (heftig) 19 Jun '25

19 Jun '25

Hi all, The linux-firmware package in core-testing has been through some churn as of late, as I've been trying to split the firmware properly and ran into several issues in the process. I apologize for the mess. Unfortunately, we're not done. This time it's a Pacman limitation involving symlinks and multiple packages that I don't remember how to handle properly. The best solution I see is instructing a manual intervention. Is this how we handled this situation in the past? Does anybody have a better idea? Draft: --- With `20250613.12fe085f-5`, we split our firmware into several vendor-focused packages. `linux-firmware` is now an empty package depending on our default set of firmware. Unfortunately, this coincided with upstream reorganizing the symlink layout of the NVIDIA firmware, resulting in a situation that Pacman cannot handle. When attempting to upgrade from `20250508.788aadc8-2` or earlier, you will see the following errors: linux-firmware-nvidia: /usr/lib/firmware/nvidia/ad103 exists in filesystem linux-firmware-nvidia: /usr/lib/firmware/nvidia/ad104 exists in filesystem linux-firmware-nvidia: /usr/lib/firmware/nvidia/ad106 exists in filesystem linux-firmware-nvidia: /usr/lib/firmware/nvidia/ad107 exists in filesystem To progress with the system upgrade, first remove `linux-firmware`, then reinstall it as part of the upgrade: # pacman -Rdd linux-firmware # pacman -Syu linux-firmware --- Greetings, Jan

1 0

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