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

Docker Open Source Community Program renewed for 2025
by Levente Polyak 13 May '25

13 May '25

Hi all, I've prolonged our Docker Open Source Community Program for another year for 2025. We've also received the approval and confirmation of the application. One of the benefits is, that this allows for our images to have relaxed pull limits. This is a yearly renewal. The next renewal will be popping up around March 2026. https://hub.docker.com/repository/docker/archlinux/archlinux Cheers, Levente

1 0

On dropping Redis
by Bert Peters 13 May '25

13 May '25

Hi all, A while ago we as a distro decided to stop supporting Redis, due to their licence change [1], and move to Valkey. Through a combined effort, we removed all direct dependencies on redis, replacing them with vault and patching until that worked. The announcement was posted, and a deadline was set. This may or may not have caused Redis to reconsider their license change, and have announced another relicencing, this time to the AGPL [2] [3]. With that change, I personally believe there is no longer a reason to remove redis from [extra], and keep it in the repos as-is. Redis is almost but not quite compatible with Valkey, so dropping it without good cause would be a disservice to our community. Now, I don't want to make light of the harm that Redis inc initially wrought on the open source community with their license change, or waste the work that was done to make everything work with Valkey. Pushback like this is what caused the license change. As such, I propose we continue to use Valkey as the implementation for all purposes that don't strictly require Redis, and maintain Redis simply as a package for our commynity's convenience. That way, should the licensing change again in the future, we do not have a similar amount of work ahead of us. This seems to me the Arch way: pragmatic and user central. Now I know that this is not a universally shared opinion, so please consider this email an invitation for discussion on what we should be doing here. Cheers, Bert [1]: https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o… [2]: https://antirez.com/news/151 [3]: https://redis.io/blog/agplv3/

8 10

RFC: Introducing a process for sponsorships
by gromit 06 May '25

06 May '25

Hello everyone, A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/55 Please visit the above link for discussion. Summary: This RFC introduces a process which gives sponsorships a clear point of contact, introduces fitting measures of transparency and specifies a set of guidelines for such engagements with external entities.

1 0

Sunsetting epapirus-icon-theme
by Felix Yan 05 May '25

05 May '25

Hi, As per upstream suggested in the release note [1], epapirus-icon-theme is no longer provided in [extra] now. Users are suggested to use Papirus / Papirus-Dark from now on. [1] https://github.com/PapirusDevelopmentTeam/papirus-icon-theme/releases/tag/2… -- Regards, Felix Yan

1 0

RFC: Establish default build flags for Fortran
by Jakub Klinkovský 04 May '25

04 May '25

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

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

Orphaning buildbot, AWS-related and several other packages
by Chih-Hsuan Yen 23 Apr '25

23 Apr '25

Hi all, I'm getting busier with work and life, so I would like to focus on packages I still use. Here is the list of packages I orphaned earlier today. Packages include buildbot, AWS-related packages and other packages that are no longer used by my remaining packages. Some of them require extra care. For example, python-aiobotocore is tightly coupled with specific botocore/boto3/aws-cli versions and should be updated together. Feel free to reach me for more details if needed, thank you. aws-cli buildbot flatbuffers python-aiobotocore python-aioitertools python-autobahn python-aws-sam-translator python-aws-xray-sdk python-awscrt python-boto3 python-botocore python-cfn-lint python-croniter python-evalidate python-flask-cors python-hvac python-joserfc python-jschema-to-python python-jsondiff python-jsonpath-ng python-jsonschema-path python-junit-xml python-jwcrypto python-klein python-moto python-openapi-schema-validator python-openapi-spec-validator python-py-partiql-parser python-pyhcl python-pypugjs python-pytest-env python-pytrie python-s3transfer python-sarif-om python-snappy python-sphinx-jinja python-treq python-tubes python-txaio python-txrequests python-ubjson python-unidiff Best Regards, Chih-Hsuan Yen (yan12125)

2 1

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

Packaging repositories are now automatically archived upon inactivity
by Jelle van der Waa 17 Apr '25

17 Apr '25

Hi everyone, Thanks to Levente reviewing, fixing and deploying a new gluebuddy. Packaging repositories which have no activity for the last 30 days are now automatically archived, making it clearer to users that this package is not available in our repositories when browsing/searching GitLab. If a package repository was archived which you still want to work on, please reach out to the devops team to unarchive it. Due to GitLab permissions issues we cannot allow packagers via pkgctl to unarchive a repository. Greetings, Jelle

1 1