March 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

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

Ruby 3.4.2
by Andreas 'Segaja' Schleifer 28 Apr '25

28 Apr '25

Hello, we have started today to update Ruby in Arch Linux to version 3.4.2 and for this we block staging from today on until it is completed. The progress can be watched on [0]. If you want to help in the rebuild effort please contact me on IRC or Matrix to coordinate. Best regards Segaja [0] https://archlinux.org/todo/draft-ruby-34-rebuild/

1 2

News draft: Valkey to replace Redis in the [extra] Repository
by Frederik Schwan 18 Apr '25

18 Apr '25

Hi everyone, As you might have heard by now redis got a new license and *some* forks were created [1]. Valkey as one of them is developed by the Linux Foundation, and adopted by Fedora already [2]. So we think it's a good step to follow that path and replace redis by valkey. ------ # Valkey to replace Redis in the [extra] Repository valkey, a modern in-memory data store, will soon be replacing redis in the [extra] repository. This change is due to Redis modifying its license from BSD-3-Clause to RSALv2 and SSPLv1 on March 20th, 2024[1]. Arch Linux Package Maintainers intend to support the availability of the redis package for roughly 90 days from the day of this post, to enable a smooth transition to valkey. After the 90 transition period has ended, the redis package will be moved to the AUR. Also, from this point forward, the redis package will not receive any additional updates and should be considered deprecated until it is removed. Users are recommended to begin transitioning their use of redis to valkey as soon as possible to avoid possible complications after the 90 day transition window closes. [0] https://github.com/redis/redis/commit/0b34396924eca4edc524469886dc5be6c77ec… ------ Best regards, Andrew and Frederik [1] https://redis.io/blog/redis-adopts-dual-source-available-licensing/ [2] https://www.linuxfoundation.org/press/linux-foundation-launches-open-source…

2 3

Official Arch Linux image for WSL
by Robin Candau 17 Apr '25

17 Apr '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

12 32

Spring cleanup '25
by Antonio Rojas 02 Apr '25

02 Apr '25

Time to clean up old cruft again. Please head to https://archlinux.org/devel/reports/unneeded-orphans/ and adopt packages you want to keep in the repos. For reference, a current list of packages is attached (but this may vary if packages are adopted/disowned). If you adopt a package from the list, make sure to check its dependencies and also adopt them in case they are orphan. This is also a good time to check your out-of-date packages and disown the ones you no longer have interest in/time to maintain, so they can find a maintainer in the official repos or otherwise in AUR. Keeping packages out of date and/or with unfixed issues for months/years is not ideal and can be detrimental to the overall quality of our distro in the long run. I will start dropping packages to AUR in ~ 10 days. ack acpilight arc-solid-gtk-theme arduino-builder aspell-da b43-fwcutter caja-actions echoping flterm fusesoc gauche gmrun gpgit gradle7 hitch hq kakoune-lsp lastpass-cli libutp libxml++2.6-docs log4cpp lxsplit mailgraph med-openmpi megatools molecule-plugins netcf obconf ophcrack perl-app-borgrestore perl-config-simple perl-cpanplus-dist-arch perl-data-messagepack perl-dir-self perl-statistics-descriptive physlock pinta psiconv python-clint python-glfw python-migen python-nptyping python-olm python-pyswip python-sounddevice reflector rhino-javadoc rp-pppoe ruby-cairo sc scim-chewing sipcalc smokeping snap-sync spampd swaks sx t-prot taskd tenshi tree-sitter-bash tree-sitter-python ttf-joypixels vbam-sdl vbam-wx web-ext wldash xautolock xcftools xplc

13 12

Heads up: cmake 4 may cause build failures
by Antonio Rojas 27 Mar '25

27 Mar '25

cmake 4 (currently in testing) removes support for cmake_minimum_required values below 3.5. This may cause build failures especially for unmaintained or poorly maintained upstream projects. Those can be fixed by increasing the cmake_minimum_required value in CMakeLists.txt. Note that this will change the default value of some policies so may cause some behavior change. Also, OLD vaue for some deprecated policies is no longer supported. If whatever the policy's OLD behavior does is still needed, it will need to be set in some other way. Check the specific policy's documentation for more info.

1 0

Re: Spring cleanup '25
by Chih-Hsuan Yen 22 Mar '25

22 Mar '25

Antonio Rojas <arojas(a)archlinux.org> 於 2025年3月22日週六下午6:50寫道： > > Time to clean up old cruft again. Please head to https://archlinux.org/devel/reports/unneeded-orphans/ and adopt packages you want to keep in the repos. For reference, a current list of packages is attached (but this may vary if packages are adopted/disowned). If you adopt a package from the list, make sure to check its dependencies and also adopt them in case they are orphan. > > This is also a good time to check your out-of-date packages and disown the ones you no longer have interest in/time to maintain, so they can find a maintainer in the official repos or otherwise in AUR. Keeping packages out of date and/or with unfixed issues for months/years is not ideal and can be detrimental to the overall quality of our distro in the long run. > > I will start dropping packages to AUR in ~ 10 days. > > ack > acpilight > arc-solid-gtk-theme > arduino-builder > aspell-da > b43-fwcutter > caja-actions > echoping > flterm > fusesoc > gauche > gmrun > gpgit > gradle7 > hitch > hq > kakoune-lsp > lastpass-cli > libutp > libxml++2.6-docs > log4cpp > lxsplit > mailgraph > med-openmpi > megatools > molecule-plugins > netcf > obconf > ophcrack > perl-app-borgrestore > perl-config-simple > perl-cpanplus-dist-arch > perl-data-messagepack > perl-dir-self > perl-statistics-descriptive > physlock > pinta > psiconv > python-clint > python-glfw > python-migen > python-nptyping > python-olm > python-pyswip > python-sounddevice > reflector > rhino-javadoc > rp-pppoe > ruby-cairo > sc > scim-chewing > sipcalc > smokeping > snap-sync > spampd > swaks > sx > t-prot > taskd > tenshi > tree-sitter-bash > tree-sitter-python > ttf-joypixels > vbam-sdl > vbam-wx > web-ext > wldash > xautolock > xcftools > xplc > > > > Thank you for organizing the event. I orphaned some packages that I'm not going to maintain anymore, and some of them become unneeded-orphans. * libkscreen5 * libqt5xdg * lxqt-build-tools-qt5 * python-django-fake-model * python-pynamodb * python-sshpubkeys Best, Chih-Hsuan Yen (yan12125)

1 0

Final Comment Period: RFC40 amendment
by Morten Linderud 19 Mar '25

19 Mar '25

Yo, We don't have an amendment process for RFCs, but we need to fix up a small part of RFC40 for the REUSE RFC and remove the custom 0BSD license text. I'm putting the amendmend up for a final comment period for any issues or feedback. https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/49 The intention is to extend the RFC process with a proper amendment procedure at a later point. -- Morten Linderud PGP: 9C02FF419FECBE16

1 0

RFC Final Comment Period: Upstream package sources
by David Runge 19 Mar '25

19 Mar '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/46 Please visit the above link for discussion. Summary: Improve the security of Arch Linux distribution packages by relying on transparent and, if possible, cryptographically verifiable upstream sources by default. Provide guidelines and best practices for distribution package maintainers in a document covering various source types and technologies for digital signatures. Communicate the common goal of transparent and secure package delivery for package maintainers as well as upstream project maintainers.

1 0