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

systemd v258 pre-releases
by Christian Hesse 17 Sep '25

17 Sep '25

Hello everybody, the systemd development team has pushed the first pre-release for the upcoming v258 release. It is a massive feature release, with a huge amount of new functionality and goodies. Please see the NEWS [0] for details. As announced in the PKGBUILD [1] I have prepared packages and pushed them to my personal testing repository. Have a look at this if you ware brave and want to have a first look. The comes with an updated mkinitcpio package, cherry-picking systemd-related changes. We should merge these before v258 release. Happy testing! [0] https://github.com/systemd/systemd/blob/v258-rc1/NEWS [1] https://gitlab.archlinux.org/archlinux/packaging/packages/systemd/-/blob/ma… [2] https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/merge_reques… -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

1 4

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

Removing port 222 for git on gitlab.archlinux.org
by Kristian Klausen 09 Aug '25

09 Aug '25

Hi all, the git migration happened more than two years ago[1] and as part of that the SSH port for git was changed from port 222 to the default SSH port 22[2]. A port redirect was added at the time to avoid disrupting existing local git repositories using the old port. Time has now come to removing said port redirect, which will happen one week from now. So if you have local git repositories using the old port, please change them to use the standard SSH port. See below for an example. $ git remote -v origin ssh://git@gitlab.archlinux.org:222/archlinux/infrastructure.git (fetch) origin ssh://git@gitlab.archlinux.org:222/archlinux/infrastructure.git (push) $ git remote set-url origin git@gitlab.archlinux.org:archlinux/infrastructure.git $ git remote -v origin git@gitlab.archlinux.org:archlinux/infrastructure.git (fetch) origin git@gitlab.archlinux.org:archlinux/infrastructure.git (push) [1] https://archlinux.org/news/git-migration-completed/ [2] https://gitlab.archlinux.org/archlinux/infrastructure/-/commit/bc1e7f777283… Cheers, Kristian Klausen DevOps

1 1

glibc 2.42 in testing - moving to stable repos affected
by Frederik Schwan 29 Jul '25

29 Jul '25

I'm about to push glibc 2.42 to testing. Do not move packages linked against 2.42 to extra or core until glibc itself moves around Thursday/Friday. Otherwise the package will probably break. Best regards, Frederik

1 0

Arch Linux devblog
by David Runge 24 Jul '25

24 Jul '25

Hi all, during and since last Arch Summit some of us have been discussing a dedicated blog focused on Arch Linux development topics. This blog is now live at https://devblog.archlinux.page and is also available through the Arch Planet feed aggregator [1]. The devblog is meant for all Arch Linux staff to highlight work on Arch Linux projects. Topics may include (but are not limited to) - providing an overview of recent/current/future developments (e.g. contextualizing our existing tech stack with new tools) - explaining more intricate or complex topics of our projects to a wider audience (e.g. the use of tools with code examples, etc.) Here, the audience may range from Arch Linux staff to anyone interested in the technical developments of the distribution. While this blog is probably a good place to highlight new work, it may also serve as an avenue to reduce our tribal knowledge a bit and give in-depth insights. As a side effect of producing technical posts generally increasing the knowledge about our projects, we also hope to attract new contributors. If you are interested in writing something, head on over to the repository for the blog [2] and open a merge request. In case you are interested in helping review posts, please reach out to the current developers of the project [3]. Happy writing! Best, David [1]: https://archlinux.org/planet/ [2]: https://gitlab.archlinux.org/archlinux/devblog [3]: https://gitlab.archlinux.org/archlinux/devblog/-/project_members -- https://sleepmap.de

1 0

Licensing changes in package sources (implementing RFC40 and RFC52)
by Sven-Hendrik Haase 23 Jul '25

23 Jul '25

Hey all, With [RFC40][0] and [RFC52][1] merged, we're now going full steam to make sure the changes outlined in those RFCs are soon implemented. If you are a packager and only care about how this concerns you without the nitty gritty details, here's what you need to know in short: 1. PKGBUILDs and auxiliary files (e.g. config files, etc.) that Arch Linux contributors provided will be licensed under 0BSD. Full current list [here][3]. 2. Licensing information will be documented in a `REUSE.toml` file per repository and will be maintained by package maintainers going forward. 3. We will generate a `REUSE.toml` (using `pkgctl license setup`) for most packages. 4. You may have to make changes to your packages (details below)! 5. When moving package source repositories from the AUR, either contact past contributors and ask for consent to license under 0BSD, or rewrite the package sources. The changes introduced in [RFC40][0] and [RFC52][1] have a general impact on packaging work. To clearly document which licenses apply to which files, we are introducing REUSE [2], which provides a structured configuration file format (`REUSE.toml`) for mapping files to concrete licenses. In the near future, we will add these files to package source repos in an automated fashion using `pkgctl license setup`. While doing so, we will exclude some packages added after 2024-11-01, see [this issue][4] for further details. In some cases (around 750 out of 12462 repos), packager maintainers will need to manually perform some changes, as adding a `REUSE.toml` will not work out of the box. There will be a todo list on Arch web for those packages where manual action is required. The most common reasons for this are: 1. The package's license isn't specified in an SPDX conforming fashion (e.g. `GPL2` instead of `GPL-2.0-or-later`). There are open MRs on GitLab to make some packages SPDX conforming [5]. We will go through these and we'll try to merge all of these. 2. Multiple license identifiers are specified in the PKGBUILD and SRCINFO files and patch files are present in the package source repository. In this case, we can't automatically pick a suitable upstream license. By default, all files in package source repos must be licensed under 0BSD. 0BSD is very permissive and files licensed under its terms can be contributed upstream under their desired license. For some files, 0BSD might not be suitable, and contributors need to choose a different license depending on the situation. Here are some common cases: - Included files originating from contributors that have not agreed to the 0BSD license. If the files are available under a FOSS license, mark the files under that particular license in the `REUSE.toml`. If no license is provided, the files need to be rewritten or removed. - Patches taken from upstream and committed to the repository need to be annotated with the correct upstream license. `pkgctl license` will be available from devtools v1.4.0 onwards. After this release, you will encounter a warning when running `pkgctl release` if your package source repository isn't compliant. If there are any open questions with existing packages and the new reuse setup, reach out over the mailing list or in the packaging channel. Cheers, Rafael and Sven [0]: https://rfc.archlinux.page/0040-license-package-sources/ [1]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/52 [2]: https://reuse.software/ [3]: https://gitlab.archlinux.org/archlinux/devtools/-/blob/b8c475b3f402809fc65b… [4]: https://gitlab.archlinux.org/archlinux/packaging/licensing-package-sources/… [5]: https://gitlab.archlinux.org/search?scope=merge_requests&search=spdx&state=…

1 0

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

Orphaning phosh
by Jelle van der Waa 06 Jul '25

06 Jul '25

Hi All, Lately I have noticed I haven't gotten around to updating phosh to the latest version. As this is a returning issue and I don't use phosh anymore as GNOME is good enough for tablets I decided to orphan it. Maintenance should be fairly trivial, the only issue is that it requires a revert on top of wlroots and of course needs to catch up to wlroots from time to time. [1] Upstream is very friendly and nice. [2] The packages in question which are now orphan: * phoc * phosh * phosh-mobile-settings * libgmobile * feedbackd If no one picks it up I will drop the packages to the AUR in one month so someone there can maintain it. [1] https://gitlab.archlinux.org/archlinux/packaging/packages/wlroots0.19/-/blo… [2] https://phosh.mobi/

1 0

First step for non-x86_64 contributions
by Levente Polyak 03 Jul '25

03 Jul '25

# First step for non-x86_64 contributions Hey everyone, I'd like to share my view on the first step for targeting non-x86_64 architectures in our packages. While our official infrastructure for non-x86 support isn't ready yet and will still take some time to materialize, I'd very much like to avoid siting on our hands until that day comes. There's already a ton of community interest and effort around non-x86_64. There's plenty of low hanging fruits and clean patches that are easy to review, well contained, and good groundwork. So instead of waiting for the perfect day before starting, I'd like to open the door to small, clear, and non intrusive contributions under tightly scoped rules. We should rather slowly and carefully build up compatibility now, than scramble once infra, hardware and tooling catches up. I propose the following guidelines as a first step towards implementing [RFC0032](https://rfc.archlinux.page/0032-arch-linux-ports/). ## Guidelines ### Protecting x86_64 We do not want to compromise on our primary platform. Clearly do not break or remove x86_64 behavior, functionality or features. Incompatible features or dependencies must be proposed in a way that preserves the functionality of our primary platform. ### Non-intrusive Small, focused changes that are easy to understand at a glance and can be reasoned about even without building and running it on different architectures. ### No downstream wizardry Complex, opaque, or heavy software patching is out of scope. Carrying around massive software patches downstream isn't feasible at this stage, save that for later and work together with upstream instead. ### Merge-request indicator All secondary architecture related merge-requests must be flagged with the new `pkg::ports` GitLab label. It'll help separate them from the usual requests and allow interested packagers and contributors to filter on them globally, to help out others. ### Manageable load Contributors must stick to small merge-request batches max 10 open MRs per person. All proposals must be sent manually, no fire-and-forget scripts. Collaboration is expected. If questions come up, we expect thoughtful responses from people who precisely know the changes they're submitting. ## Out of scope ### arch array No changes to `arch=()` arrays. ### non-x86_64 issues No issues or bug reports for non-x86_64. If something's broken with the `PKGBUILD`, you'll need to sort it out and send a merge-request. Don't file bugs in the tracker for other architectures. --- This approach allows us to slowly build up compatibility and make good progress without burning out our packagers and bug-wranglers or flooding our GitLab with changes and bug reports we can't handle. We can stretch out the work by allowing confined changes and avoid to stack it all for later. It gives us room to prepare without needing full build infrastructure, provide active support or require special hardware in place today. I think this really hits the right balance, tight enough to avoid burnout, open enough to make progress and welcoming enough to motivate and start harvesting work from our community. Cheers, Levente

9 13