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

glibc 2.41 in testing - moving to stable repos affected
by Frederik Schwan 30 Jan '25

30 Jan '25

I just pushed glibc 2.41 to testing. Do not move packages linked against 2.41 to extra or core until glibc itself moves around Sunday/Monday. Otherwise the package will probably break. Best regards, Frederik

1 0

Official Arch Linux image for WSL
by Robin Candau 29 Jan '25

29 Jan '25

Hi everyone, I'm writing this mail to collect thoughts and interests about providing an official Arch Linux image for WSL (Windows Subsystem for Linux) [1]. Indeed, after a quick related discussion over on IRC, I started tinkering with this and I personally would be eventually interested in proposing this "officially", if that's of interest. This proposal is inspired by the related Fedora one [2] (which was accepted and planned for Fedora 42). # Benefits An official Arch Linux image for WSL would provide an easy way for people to give Arch Linux a try directly from their Windows system, making our distro more "discoverable" and accessible. Additionally, some people may have no other choice but to use Windows in specific situations (despite not necessarily being the best choice for their needs / duties), e.g. on their company's workstation (like it's the case for me). While WSL consists of an acceptable solution to get access to a Linux environment in such situations, the lack of an official image for Arch Linux either "suggests" the use of a different distribution or "forces" people to rely on unofficial Arch Linux WSL images (which quality may vary). # Distribution / Installation WSL images can be distributed via tarballs, Appx packages, or via the Windows Store. From what we know, distributing images from the Windows Store implies agreeing to the store policies & developer agreement, and may imply additional eventual concerns related to TOS/EULA. I unfortunately don't have much details on that front currently but I think that distribution from the Windows Store should be out of scope for now. Moreover, since version 2.4.4, WSL greatly improved the way to install tarballs outside from the store by adding "click-to-install" support for tarballs using the ".wsl" extension, as well as automatic first setup script support. As such, I would personally advice for that distribution method for the time being. Indeed, downloading such an Arch Linux ".wsl" tarball and (double) clicking on it would be all that's needed to be able to use Arch Linux with WSL. Note that WSL 2.4.4 and greater are still qualified as pre-releases at the time I'm writing those lines [3], but can still be installed with a single command line from a PowerShell prompt (`wsl --update --pre-release` from a system with WSL2 installed). If anything, installing such tarballs from WSL prior to 2.4.4 can still be done "manually" via a single command line (`wsl --import <DistroName> <InstallationPath> <TarballPath>`). With a proper documentation, using Arch Linux with WSL prior to 2.4.4 would still be pretty straightforward. # Technical details WSL2 provides a single virtual machine managed by the Windows host which runs guest Linux distributions as containers. As such, the Arch Linux base container image [4] can already be used for basic WSL support. To define some default parameters and provide additional functionalities, some specific WSL configuration files can be added to it. This, for instance, allows to add `systemd` support out of the box [5], define default parameters (e.g. default user, icon for the app shortcut or terminal profile) and automatic first setup script (which can be used to create a default non-root user and perform basic system setup interactively at first run for instance) [6]. The archive just needs to be renamed from ".tar.zst" to ".wsl" to allow "click-to-install" with WSL >= 2.4.4. For those interested, I actually "built" such a ".wsl" Arch Linux tarball [7] based on our latest base container image which can be installed & uses with WSL2 (made for test purposes). Make sure to read the README [8], which contains important information such as how the tarball was generated and how to use it. # Tarball maintenance / management Given that the WSL tarball would be based on our Docker / Container image, it could eventually be maintained in the same repo [4], although I'm not sure that mixing a WSL specific image with our "Docker" images is desirable. We also have the arch-boxes repo [9] which provides multiple kind of Arch images (vagrant, qcow2, cloud...). I think a WSL image could fit well there. Alternatively, a new dedicated repo could be created. When it comes to actual maintenance / management, I think the image generation and releasing should be fairly easy to automate via a scheduled GitLab CI (as it is currently done for our Docker images for instance). The process is fairly straightforward (grab latest base Docker image / tarball, un-archive it, add a few WSL specific files, re-archive it, rename it from ".tar.zst" to ".wsl"). I guess a monthly generation / release would be more than enough. We would still need a few people to watch over and feel responsible to maintain this. I'd happily be one of them, but please feel free to express interest :) # Unresolved questions / issues From a purely technical stand point, there is one pending issue which, fortunately, can be easily worked around. But the actual root cause and proper fix are unknown yet. See the last section of the README [8] for more details. On another level, I guess the important point here is to determine if we actually want this and, if so, how? For instance, which level of support do we want to provide (if we are to do this)? Since it would be pretty close in terms of "design" and usage, I personally think we could provide a similar level of support than the Docker images & Arch boxes images. Anyway, sorry for the long read 0:) Just to clarify, the actual purpose of this mail is to collect thoughts, concerns, questions, interests (both regarding using such an "official" Arch Linux WSL image and / or helping maintaining it), ... Please, share opinions if you have some :) [1] https://learn.microsoft.com/en-us/windows/wsl/about [2] https://fedoraproject.org/wiki/Changes/FedoraWSL [3] https://github.com/microsoft/WSL/releases [4] https://gitlab.archlinux.org/archlinux/archlinux-docker [5] https://devblogs.microsoft.com/commandline/systemd-support-is-now-available… [6] https://learn.microsoft.com/en-uisns/windows/wsl/build-custom-distro#add-th… [7] https://pkgbuild.com/~antiz/WSL/ [8] https://pkgbuild.com/~antiz/WSL/README.md [9] https://gitlab.archlinux.org/archlinux/arch-boxes -- Regards, Robin Candau / Antiz

10 20

Talks from Arch contributors at FOSDEM 2025
by Morten Linderud 24 Jan '25

24 Jan '25

Yo, FOSDEM is approaching and several Arch contributors and maintainers are holding talks next weekend. I have taken the liberty to collect up all the talks in this email so other staff, and users, are aware. Some talks are Arch related, some talks less so. But still interesting topics nonetheless! # David Runge Adventures in oxidizing Arch Linux Package Management When: Saturday 18:05 - 18:45 Room: Rust Devroom - UB2.252A (Lameere) https://fosdem.org/2025/schedule/event/fosdem-2025-6259-adventures-in-oxidi… # Filipe Laíns Understanding (modern) Python packaging When: Sunday 10:00 - 10:30 Room: Python Devroom - UD2.218A https://fosdem.org/2025/schedule/event/fosdem-2025-4242-understanding-moder… # Morten Linderud Hardware backed SSH keys: ssh-tpm-agent When Saturday 15:00 - 15:30 Room: Security Devroom - UB4.132 https://fosdem.org/2025/schedule/event/fosdem-2025-5544-hardware-backed-ssh… # Orhun Parmaksız Bringing terminal aesthetics to the Web with Rust (and vice versa) When: Saturday 12:25 - 13:05 Room: Rust Devroom - UB2.252A (Lameere) https://fosdem.org/2025/schedule/event/fosdem-2025-5496-bringing-terminal-a… From Side Projects to Sustainable Open Source When: Saturday 15:05 - 15:30 Room: Community Devroom - UB5.230 https://fosdem.org/2025/schedule/event/fosdem-2025-5498-from-side-projects-… # Remi Gacogne Honey, I shrunk DNSdist When: Saturday 18:20 - 18:45 Room: DNS Devroom H.2213 https://fosdem.org/2025/schedule/event/fosdem-2025-4991-honey-i-shrunk-dnsd… -- Morten Linderud PGP: 9C02FF419FECBE16

2 1

FOSDEM 2025 Dinner
by Robin Candau 24 Jan '25

24 Jan '25

Hi everyone, 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 :) The dinner will be held Saturday, 1st of February 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 25 people. Priority for members of the Arch staff (developers, package maintainers and support staff). Any free spots after this can be taken by anyone interested. Please, send me [1] an email *offlist* if you want to attend, including Foxboron as CC [2] to increase the bus factor :P The 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 :) I also plan to announce a pub closer to the FOSDEM weekend, so anyone unable to join the dinner can still come and grab a drink with the rest of us. [1] antiz(a)archlinux.org [2] foxboron(a)archlinux.org -- Regards, Robin Candau / Antiz

1 1

tcl/tk 9 pulled out of [testing]
by Jelle van der Waa 18 Jan '25

18 Jan '25

Hi all, tcl/tk 9 was uploaded to [extra-testing] without a rebuild of the dependent packages. It has now been pulled out, so if you had it installed you'll need to manually downgrade. https://gitlab.archlinux.org/archlinux/packaging/packages/tk/-/issues/1

1 1

Arch Linux FOSDEM BOF
by Jelle van der Waa 17 Jan '25

17 Jan '25

Hi All, We managed to get a BOF (Birds Of A Feather) session at FOSDEM, at congress (CCC) we did something similar a short project update and then a Q&A session. [1] I expect the room to be small for this ~ 30-50 people as it is in building AW. Everyone from Staff is allowed to join the Q&A session on stage but note that the space might be limited and we possibly can't accommodate 6 or more people. [1] https://fosdem.org/2025/schedule/event/fosdem-2025-6706-arch-linux- meetup-bof/ Greetings, Jelle

1 0

ruby-liquid 5.6.4 pulled from testing
by Bert Peters 16 Jan '25

16 Jan '25

Hi all, Please note that I've just pulled ruby-liquid 5.6.4 from [extra- testing]. ruby-liquid 5.6.1 raises a dependency on part of the standard library to Ruby 3.4, which we do not yet support. Please downgrade ruby-liquid to the version available in [extra]. Kind regards, Bert.

1 0

News draft: Pango ≥ 1.56.0 fails in the presence of old Electron ≤ 29 apps
by Jan Alexander Steffens (heftig) 15 Jan '25

15 Jan '25

Apps using the incoming `pango 1.56.0` may fail to render text or crash if the user has also run apps based on Electron 29 or older. To immediately mitigate the issue, delete `~/.cache/fontconfig` or run `fc-cache`. However, further use of old Electron apps may cause the problem to reappear. We recommend - switching newer versions of the Electron applications that use at least Electron 30, - using Flatpak releases of the applications, or - giving the applications their own XDG cache directory by running them with `XDG_CACHE_HOME=${HOME}/.cache/appname` in the environment. ### Technical details Pango 1.56.0 depends on "font wrapper" information provided by Fontconfig 2.15.0 in order to determine whether it supports a font. Electron 29 and older are shipping a Git snapshot of Fontconfig that has the same cache version (`9`) as Fontconfig 2.15.0. but lacks the font wrapper information. The Electron version of Fontconfig fails to parse the cache files generated by our version of Fontconfig. It then regenerates them without the font wrapper information. Our Fontconfig still considers these cache files valid, but the missing font wrapper information leads to Pango failing to find any valid fonts. This issue is being tracked at [pango#1]( https://gitlab.archlinux.org/archlinux/packaging/packages/pango/-/issues/1)

3 4

Amending RFC40 to remove custom 0BSD license
by Morten Linderud 09 Jan '25

09 Jan '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 9

Issues with Libera.Chat and public access via Matrix
by David Runge 09 Jan '25

09 Jan '25

Hi all, back in October I have created channels for the buildbtw and signstar projects [1] which are meant to be publicly accessible for development and general user activities. While these work fine on the Libera.Chat side, the bridging via our private Matrix bridge causes friction: It is not possible to access the bridged rooms from Matrix without either being in the private Arch Linux staff space or being invited specifically to that room. This is due to the fact, that the official bridge has been shut down in August 2023 and eventually sunset entirely [2]. I raised this issue in the #archlinux-devops channel and after a chat with Jan the following possible scenarios materialized: - only use IRC (shut out Matrix users) - only use Matrix (shut out IRC users) - continue to invite interested people to bridged Matrix rooms manually (basically also shut out Matrix users) - switch to a different IRC network that is (still) accessible via a public Matrix bridge (e.g. oftc.net [3]) for public rooms I am not fond of the first three options as they either shut out user groups or require manual handholding of user additions, which in my mind does not scale. I'm raising this as a general note, because this is an issue when it comes to making public rooms available on Matrix beyond our own staff. For the ALPM project I have therefore chosen the path of least resistance and created #alpm on oftc.net for the time being. It would be great to find a less fragmenting solution for public rooms, so I'd be happy to get some input on this topic. Best, David [1]: https://lists.archlinux.org/archives/list/arch-projects@lists.archlinux.org… [2]: https://libera.chat/guides/matrix [3]: https://oftc.net -- https://sleepmap.de

1 0