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

Please finish the package license todo-list
by Jelle van der Waa 15 Dec '25

15 Dec '25

Hi all, The Python rebuild is off to a bit of a rocky start with ~ 100 packages which fail `pkgctl license check`. Please help complete this todo so we can keep rebuilding. [1] https://archlinux.org/todo/make-packages-license-compliant/

1 0

GitLab behind Anubis
by Kristian Klausen 14 Dec '25

14 Dec '25

Hi all, To deflect yet another scraping attack against our GitLab instance, it has been hastily put behind Anubis. This may have broken stuff. Please reach out if notice anything that does not work, either by replying to this email or #archlinux-devops on IRC. Cheers, Kristian Klausen DevOps

1 0

Python 3.14 rebuild starting
by Jelle van der Waa 13 Dec '25

13 Dec '25

Hi all! Let's start the Python 3.14 rebuild as Christmas present for our users! This effectively means [staging] will be blocked for a longer period of time before everything is rebuild. I'll start after the hdf5 rebuild has been moved and will first bootstrap the build tooling (setuptools, flit, pytest, etc.). When that's done a todolist will be opened for all Python packages. Do note that there will be cycles which need to be broken up by building packages without tests first. Greetings, Jelle

1 0

systemd v259 pre-releases
by Christian Hesse 10 Dec '25

10 Dec '25

Hello everybody, the systemd development team has pushed the first pre-release for the upcoming v259 release. 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 are brave and want to have a first look. Happy testing! [0] https://github.com/systemd/systemd/blob/v259-rc1/NEWS [1] https://gitlab.archlinux.org/archlinux/packaging/packages/systemd/-/blob/ma… -- 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 2

Fwd: Looking for feedback on CONFIG_MODULE_HASHES for Linux
by Robin Candau 10 Dec '25

10 Dec '25

Hi everyone, As discussed during this year's Arch summit, Thomas is seeking help / support from projects that could benefit from his patch set which aims to enable reproducible kernel packages for Linux distributions (see the forwarded mail below). As far as I can tell, this is something we would be interested in. I think it would be nice if we could "officially" claim our interest as "Arch Linux" to hopefully provide some assistance to Thomas for his incoming discussion with upstream. Does any of the kernel packages maintainers on our side wants to jump in (or anyone else interested with some kernel knowledge, I guess)? -------- Forwarded Message -------- Subject: Looking for feedback on CONFIG_MODULE_HASHES for Linux Date: Thu, 13 Nov 2025 21:10:58 +0100 From: Thomas Weißschuh via rb-general <rb-general(a)lists.reproducible-builds.org> Reply-To: General discussions about reproducible builds <rb-general(a)lists.reproducible-builds.org> To: rb-general(a)lists.reproducible-builds.org CC: Thomas Weißschuh <thomas(a)t-8ch.de> Hi everyone, I am the author of the CONFIG_MODULE_HASHES patchset [0] for the Linux kernel which aims to enable reproducible kernel packages for Linux distributions. My goal is to reignite development and continue with the upstream process. To have a better base to argue with I'd like to get some confirmation that distributions have looked at the patches and do intent to adapt this scheme when it is available in the mainline kernel. That should help me get some leverage with the upstream maintainers. The current form of the patches can be found at [1], they are only slightly adapted from the previous submission to LKML. Remaining open topics before the next submission are proper IMA support and stripping of modules. Future changes may introduce more hash algorithms and performance improvements, but these should not be relvant for now. So if you are packaging Linux for your distribution, have looked at my patches and are eager to use them, please let me know. My plan is to talk with the upstream maintainers at the upcoming Linux Plumbers Conference on 11th of December. Thanks, Thomas [0] https://lore.kernel.org/lkml/20250429-module-hashes-v3-0-00e9258def9e@weiss… [1] https://git.kernel.org/pub/scm/linux/kernel/git/thomas.weissschuh/linux.git…

2 1

News draft: .NET packages may require manual intervention
by George Rawlinson 09 Dec '25

09 Dec '25

The following packages may require manual intervention due to the update from 9.0 to 10.0: * aspnet-runtime * aspnet-targeting-pack * dotnet-runtime * dotnet-sdk * dotnet-source-built-artifacts * dotnet-targeting-pack pacman may display the following error `failed to prepare transaction (could not satisfy dependencies)` for the affected packages. If you are affected by this and require the 9.0 packages, the following commands will update e.g. aspnet-runtime to aspnet-runtime-9.0: ```sh pacman -Syu aspnet-runtime-9.0 pacman -Rs aspnet-runtime ```

1 0

new unstable repositories
by Christian Hesse 07 Dec '25

07 Dec '25

Hello everybody, for some time I used to push rc release for some packages (namely systemd & util-linux) to core-testing. This broke once, when a package was built against that rc release and thus did depend on new symbols, then finally was moved before the package it was built against. After that I pushed all the rc releases to a public personal repository, anybody interested could test from there. But I think the audience was a lot smaller, and last systemd release revealed some unexpected regressions *after* final release. That situation is not any better, especially when rc releases in Arch were a major factor in finding regressions early. At Arch Summit 2025 we had a chat about that situation and discussed several ideas. In the end we came up with one reasonable solution: We should introduce new repositories [core-unstable] and [extra-unstable] for this kind of testing. People would still have to enable these repositories, but I guess chances are higher than for my personal repository. I guess we have three places that need to be touched: * create repositories on servers (-> DevOps) * dbscripts * devtools Anything more? Feedback is welcome, same for other ideas - this is not set in stone and I am open for anything that works for me/us. Thanks! -- 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);}

7 17

Archive repos snapshot changes
by Kristian Klausen 09 Nov '25

09 Nov '25

Hi all, We (DevOps) want to reduce [the I/O stress][1] on the archive server (archive.archlinux.org) by reducing the numbers of inodes (currently 55 millions). Most of these inodes (52,6 millions) originates from the daily snapshot (64k inodes) of the repositories. Going forward only the database files and the "sources" directory will be included in the snapshot (~120 inodes + ~2400 inodes for "sources") and all HTTP requests for package files will be redirected to the relevant package at https://archive.archlinux.org/packages/. E.g. https://archive.archlinux.org/repos/2025/11/02/core/os/x86_64/linux-6.17.6.… -> https://archive.archlinux.org/packages/l/linux/linux-6.17.6.arch1-1-x86_64.… Package files from existing snapshots will be removed at a later date. The "sources" directory will be removed at a later date, when a proper replacement is in place. If no concerns are raised before 2025-11-21 EOD, we will move forward with the changes. [1] All inodes must be traveresed for backup and hardlinking Cheers, Kristian Klausen DevOps

1 0

Dropping qt5-webengine
by Antonio Rojas 08 Nov '25

08 Nov '25

Hi, Qt5 is EOL since May. In particular, qt5-webengine's Chromium ships with unfixed vulnerabilities. Its code is bitrotting, which also makes it a costly package to maintain due to the frequent API changes in its dependencies (I had to give up on system ffpmeg and switch to its ancient bundled version, and currently doesn't build against ICU 78). I therefore think it's wise to drop it from our repos. Its remaining reverse dependencies are: csoundqt - can be built without it by disabling remote debugging support, MR at [1] fcitx-libpinyin - archived upstream for over a year globalprotect-openconnect - very out of date, a new version switching to wbkitgtk and rust is available in testing. kchmviewer - dead upstream (no activity in 4 years) qmc2 - dead upstream (no activity in 1.5 years) wiznote - dead upstream (no activity in 4 years) openshot - the only case of a (semi-)maintained application still unported to Qt6 - there was an attempt 3 years ago [2] aborted due to some drama and no signs of new efforts since then, porting is non-trivial. If there are no objections (that include an offer to pick up maintenance of the package), I will drop it and all its unported reverse dependencies in a few days. [1] https://gitlab.archlinux.org/archlinux/packaging/packages/csoundqt/-/merge_… [2] https://github.com/OpenShot/openshot-qt/pull/4836

3 3

GitLab unavailable at the moment
by Jelle van der Waa 05 Nov '25

05 Nov '25

Hi All, GitLab is experiencing some high load due to unknown reasons, devops is investigating. Expect issues when updating packages so maybe postpone them if you can. Greetings, Jelle

2 1

News Draft: waydroid >= 1.5.4-3 update may require manual intervention
by George Hu 05 Nov '25

05 Nov '25

The `waydroid` package prior to version `1.5.4-2` (including `aur/waydroid`) creates byte-compiled Python files (.pyc) at runtime which were untracked by pacman. This issue has been fixed in 1.5.4-3, where byte-compiling these files is now done during the packaging process. As a result, the upgrade may overwrite the unowned files created in previous versions. If you encounter errors like the following during the update: ``` error: failed to commit transaction (conflicting files) waydroid: /usr/lib/waydroid/tools/__pycache__/__init__.cpython-313.pyc exists in filesystem waydroid: /usr/lib/waydroid/tools/actions/__pycache__/__init__.cpython-313.pyc exists in filesystem waydroid: /usr/lib/waydroid/tools/actions/__pycache__/app_manager.cpython-313.pyc exists in filesystem ``` You can safely remove the conflicting files by running the following command before upgrading: ```sh find /usr/lib/waydroid/tools/ -type d -name __pycache__ -exec sudo rm -rf '{}' + ``` -- Best Regards, George Hu / Integral

4 5

mkinitcpio v40, packaging changes and kernel-install
by Morten Linderud 04 Nov '25

04 Nov '25

Yo, I'm dropping the new `mkinitcpio` v40 release into [core-testing] right after this email. Generally the changes are not super interesting, but we got a new build system with meson for this release. This has given us the option to enable and disable the default hooks for `mkinitcpio` during building. As a result I have made two packaging decisions! # Disabled fallback image creation for new installs. Generally they are not super useful and people that need them can enable them if they would like too. This is only affects new installs as we can't change the hook files on existing installs. # Switched over to `systemd` hooks by default. This is generally a change I think we should have done a long time ago. The systemd side of our initramfs is getting a lot of changes thanks to systemd moving the needle forward, however our busybox hooks are not getting any of these improvements and have generally stalled for years. I have swapped things over on our side, and will continue to maintain the busybox hooks upstream. Further release notes can be found here: https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/releases/v40 # kernel-install Beyond this next on my todo is to see if we can move us wholesale away from the custom libalpm hooks we currently have to using `kernel-install`. This is going to make things much easier for us and users to swap between initrd and uki generators. It would also allow us to simplify our kernel installation and boot creation as we can probably automatically generate configs with hooks. I plan on writing a rough outline of my idea to arch-dev-public before doing a RFC, mostly because I haven't completely decided on how we would like to do this smoothly and people might have better ideas then me. -- Morten Linderud PGP: 9C02FF419FECBE16

1 0

News draft: dovecot >= 2.4 requires manual intervention
by Thore Bödecker 29 Oct '25

29 Oct '25

Hi folks, the upstream dovecot 2.4 branch comes with handful of breaking changes, mostly concerning configuration semantics and syntax. For this, upstream provides a migration guide [1]. We've kept dovecot 2.4.1 in [testing] for quite some time and it received a decent number of signoffs. There was already a bit of chatter on arch-general regarding the availability of a dovecot 2.4 package in [extra]. While slightly unintentional, I've built and pushed todays upstream release version 2.4.2 to [extra]. However, there is a feature disparity: the 2.4 branch no longer supports replication. My own setup relies on that particular feature and I've grown quite fond of it, so I'm a bit sad to see it going away. As per upstreams EOL announcement [2], the 2.3 branch is supposedly going to receive critical secrity fixes, which I considered "maintained enough" to warrant packaging it separately until upstream fully drops it. The following packages are now available in [extra]: - dovecot23 - pigeonhole23 - dovecot23-fts-elastic - dovecot23-fts-xapian Where applicable, they are configured with the necessary conflicts/provides. The most recent dovecot-2.4.2-3 build also contains the following dovecot.install notice: > ==> Dovecot 2.4 is incompatible with older configurations and requires manual intervention. > ==> Refer to 'https://doc.dovecot.org/latest/installation/upgrade/2.3-to-2.4.html' for upgrading instructions. > ==> Alternatively, there is a dovecot23 (and pigeonhole23) package available. Given the fact that any dovecot 2.4 binary *will not* start with a <= 2.3 configuration file, it seems reasonable for us to publish an announcement to make users aware of this situation while also informing them about the alternate 2.3 packages we provide. News draft below. ----8<---- # dovecot >= 2.4 requires manual intervention The dovecot 2.4 release branch has made breaking changes which result in it being incompatible with any <= 2.3 configuration file. Thus, the dovecot service will no longer be able to start until the configuration file was migrated, requiring manual intervention. For guidance on the 2.3-to-2.4 migration, please refer to the following upstream documentation: [Upgrading Dovecot CE from 2.3 to 2.4](https://doc.dovecot.org/latest/installation/upgrade/2.3-to-2.4.html) Furthermore, the dovecot 2.4 branch no longer supports their replication feature, it was removed. For users relying on the replication feature or who are unable to perform the 2.4 migration right now, we provide alternative packages available in [extra]: - dovecot23 - pigeonhole23 - dovecot23-fts-elastic - dovecot23-fts-xapian The dovecot 2.3 release branch is going to [receive critical security fixes](https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/threa… from upstream until stated otherwise. ---->8---- [1] https://doc.dovecot.org/latest/installation/upgrade/2.3-to-2.4.html [2] https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/thread/3P45L… Cheers -- Thore "foxxx0" Bödecker GPG ID: 0xEB763B4E9DB887A6 GPG FP: 051E AD6A 6155 389D 69DA 02E5 EB76 3B4E 9DB8 87A6

1 0

Remove GTK2 from the official repositories
by Balló György 26 Oct '25

26 Oct '25

Hi all, I think we've reached the point when we can remove the very old GTK2 package from the official repositories. I recently dropped the GTK2 version of LXDE, and there are only a few applications left that still depend on GTK2: - alltray - amsynth - bless - calf - eq10q - gimp-nufraw - gkrellm - gpsim - gtk2fontsel - gtk-chtheme - hexchat - hexter - leafpad - mono-tools - nitrogen - nspluginwrapper - osdlyrics - parcellite - pidgin - sbxkb - trayer - xboard - xdialog - xlockmore Most of these have no active development a long time ago. If no one has objections, I'll drop these packages to AUR in the next days if it's not possible to build them without GTK2. Any opinion? -- György Balló Package Maintainer

2 2

New CDN based mirror now available: fastly.mirror.pkgbuild.com
by gromit 20 Oct '25

20 Oct '25

Hello everyone, we [have now setup][0][1] an additional option for a worldwide mirror: https://fastly.mirror.pkgbuild.com With the caching done by the Fastly CDN, the bandwidth speeds and time to first byte should be quite good all around the globe, especially as more and more people start using the service. Thanks a lot to Fastly for sponsoring us with free access to their services! This new mirror can be seen as an orthogonal approach to the already existing, also DevOps administered geomirrors, which will not be replaced by the CDN based mirror. Please check it out and [let us know][2] if you find any problems with it! Kind regards, Antiz, Pitastrudl and gromit [0]: https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/1031 [1]: https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/639 [2]: https://gitlab.archlinux.org/archlinux/infrastructure/-/issues

1 0

GHC 9.6.6 enters [extra-testing]
by Felix Yan 13 Oct '25

13 Oct '25

Hi all, The GHC 9.6.x updates have now entered [extra-testing]. This time, four packages have been retired, so please remove them manually if you have them installed: - haskell-configfile - haskell-monad-gen - haskell-monad-journal - haskell-success Again a special thanks to @Vekhir for helping me in preparing many batches of updates, including this one. Please let me know if you encounter any issues. Otherwise, the batch will be moved to [extra] in a few days. -- Regards, Felix Yan

1 0

New filesystem in core-testing with fully locked accounts
by David Runge 12 Oct '25

12 Oct '25

Hi all, please note, that filesystem 2025.10.12 in core-testing now features fully locked user accounts [1] based on the ongoing related TODO [2]. In case you run into any issues with those user accounts because of this, please report them as ticket on the package. Best, David [1]: https://gitlab.archlinux.org/archlinux/packaging/packages/filesystem/-/comm… [2]: https://archlinux.org/todo/change-sysusers-to-fully-locked-system-accounts/

1 0

HEADS UP: Qt 6.10 in [extra-testing]
by Antonio Rojas 07 Oct '25

07 Oct '25

This is a reminder that anything compiled against 6.10 will automatically depend on it, so it will have to stay in testing until Qt itself moves.

1 0

arch-install-scripts v30
by Morten Linderud 27 Sep '25

27 Sep '25

Yo, I've cut a new release of arch-install-scripts ahead of next months ISO. Changes and features in the new release: * Removal of `DownloadUser` from `pacman.conf` in `pacstrap` to prevent errors where the `alpm` user does not have access to the given path. * `arch-chroot` now has a new flag, `-S`, which uses `systemd-run` under the hood. * Uses the new `X-mount.nocanonicalize=target` option from `util-linux` to mount symlinks. * `genfstab` now properly understand `zram` swap targets, and will ignore them. * `pacstrap` now respects all paths from `pacman.conf` when initializing a new chroot. * Shellcheck no longer makes complaints about the project. It's been pushed to `[testing]`. https://gitlab.archlinux.org/archlinux/arch-install-scripts/-/releases/v30 Cheers. -- Morten Linderud PGP: 9C02FF419FECBE16

1 0

ffmpeg 8.0 rebuild on hold
by Lukas Fleischer 24 Sep '25

24 Sep '25

Hi all, The ffmpeg 8.0 rebuild [1] overlaps with other pending rebuilds. Those rebuilds need to be completed and moved out of the staging repositories first. Please do not continue working on the ffmpeg rebuild until the other rebuilds are completed. We'll send an update once things are ready. Thanks! Lukas [1] https://archlinux.org/todo/ffmpeg-80-and-friends/

1 1

RFC: buildbtw build service
by Rafael Epplée 23 Sep '25

23 Sep '25

Hey all, A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/63 Please visit the above link for discussion. Summary: This RFC proposes a first vertical slice of a build service to streamline rebuilding packages with many reverse dependencies. It tackles problems like repetitive manual work, blocking staging repos, missed reverse dependencies and lack of shared context like build logs. Goals include automating rebuilds and build ordering, enabling unattended builds, and providing isolated repos for parallel work. Builds run in secure virtual machines via a GitLab executor, organized into namespaces with histories and automatic dependency graphs. Interaction happens through CLI (`pkgctl`) and a web UI with SSO. - Cheers, Rafael

1 0

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

Update on Valve sponsored work in July 2025
by Rafael Epplée 08 Sep '25

08 Sep '25

Hi all, here is a quick progress report on Valve sponsored work in July 2025. ## Signstar Based on feedback from reviewers, we have added further research and data to [RFC 0059] which provides information on specific costs and technological differences between discussed options. Due to reviewer concerns with regards to colocation hosting feasibility and costs we have pivoted to support the YubiHSM 2 as default backend for the proposed solution. The existing NetHSM integration will remain for as long as possible to potentially be re-evaluated in the future. The code coverage setup has been split so that unit tests and integration tests each have their own report. In an additional step, we have also added coverage reporting for use-cases in which tests have to switch users. Logging to systemd journal with rich metadata has been added, in case journald is available in the given environment. An issue with doctests coverage being broken for multi-member projects has been investigated (see [cargo-llvm-cov#440]). A large part of the NetHSM handling backend has been merged and released, which allows to synchronize a NetHSM backend with a Signstar configuration file ([signstar!249]). To support further backends in the future, work on making the Signstar configuration file format less dependent on the existing set of crates related to the NetHSM has been started ([signstar!292]). A sample signer [yubihsm-pgp] with mock YubiHSM has been implemented. The PoC exercises all major features we would need (creating new ed25519 asymmetric key; creating new wrapping key, backed by 3 out of 5 Shamir’s Secret Sharing and key export/import; creating new OpenPGP certificate using HSM key; signing given data file using that certificate; verifying that file with SOP implementations). YubiHSM additionally has support for [key attestation], sadly, due to RustCrypto version drift it doesn't work when mixed with rPGP. Additionally, investigated internal YubiHSM audit log for operations, which stores all operations executed on the HSM. The log can be cryptographically verified that it has not been tampered with. [YubiHSM logs] ## wkd-exporter Added code coverage, based on the existing code from signstar. Generated code quality file for Gitlab so that each merge request has a nice presentation of what would change. Contributed `[metadata]` attributes to `just` [just#2794] and used that to track CI job package dependencies [wkd-exporter#16]. ### Hours billed for Signstar David (85h), Wiktor (124h) ## Buildbtw We've received lots of feedback from PoC testers which as lead to lots of improvements and a treasure trove of new issues we'll be able to reference while building towards the next milestone: the first "production" release. Our plan is to take all learnings from the PoC and use them to build a small, but polished foundation which will provide build services to all staff members (and eventually also drive-by gitlab contributors). The PoC will continue running for a while (consider joining the testing instance if you haven't done so!), and we've continued working on it. We drastically improved the scheduler's memory usage and performance, fixed lots of papercuts in the CLI and web UI, and fixed bugs, a major one of them in the graph calculation algorithm. We also merged the first contributions from gromit. Thank you, gromit! The impulses for these changes came from onboarding sessions for the PoC testing instance. Thanks to everyone who participated so far! For the new production milestone, we've created plans based on our experience with the PoC: an overhauled data structure for improved performance, a deployment concept and release strategy, OIDC authentication, an improved JSON API for scheduling builds, and a new module structure for the code. Last but not least, we started writing an RFC covering major workflows and requirements for the production system we're envisioning. ### Hours billed for buildbtw Rafael (79h), Sven (39.5h), Levente (0h) ## Package Source Licensing Implemented [pkgctl license](https://gitlab.archlinux.org/archlinux/devtools/-/merge_requests/3… and worked through many packages with bad licenses. Created a [todo to make all packages license compliant](https://archlinux.org/todo/make-packages-license-compliant/). ### Hours billed for Package Source Licensing Rafael (4h), Sven (81h) ## Meeting Notes Meeting notes are available for staff in the [internal-notes] repository. [internal-notes]: https://gitlab.archlinux.org/archlinux/internal-notes/-/tree/main/valve [RFC 0059]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/59 [cargo-llvm-cov#440]: https://github.com/taiki-e/cargo-llvm-cov/issues/440 [yubihsm-pgp]: https://gitlab.archlinux.org/wiktor/yubihsm-pgp [key attestation]: https://docs.yubico.com/hardware/yubihsm-2/hsm-2-user-guide/hsm2-core-conce… [just#2794]: https://github.com/casey/just/pull/2794 [signstar!249]: https://gitlab.archlinux.org/archlinux/signstar/-/merge_requests/249 [signstar!292]: https://gitlab.archlinux.org/archlinux/signstar/-/merge_requests/292 [wkd-exporter#16]: https://gitlab.archlinux.org/archlinux/wkd-exporter/-/merge_requests/16/dif… [YubiHSM logs]: https://docs.yubico.com/hardware/yubihsm-2/hsm-2-user-guide/hsm2-core-conce…

1 0

glib2 removed from core-testing
by Jan Alexander Steffens (heftig) 06 Sep '25

06 Sep '25

glib2 2.86.0-1 was removed from core-testing as it prevented gnome-shell from launching. Please downgrade any updated installs back to core/glib2 2.84.4-2. lib32-glib2 was removed as well.

1 0

New way to support Arch Linux: GitHub Sponsors
by Levente Polyak 05 Sep '25

05 Sep '25

Hey everyone, We've got a new way for you to support Arch Linux and help us pay our bills: GitHub Sponsors! https://github.com/sponsors/archlinux/ All funds go to our existing fiscal host at SPI, just like with PayPal or credit card donations: https://www.spi-inc.org/projects/archlinux/ Your support means the world to us, not just financially but also by being an active part of our community. We're super grateful and send love to our community 🫶. Let's keep this distro rolling together. 🚀

1 0

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

namcap 3.6.0 released
by Jelle van der Waa 24 Aug '25

24 Aug '25

Hi, Seen a long hiatus, finally a new namcap release has entered [extra-testing] Release notes: - Allow rules to be disabled by default - Allow namcap-devel to be run from any directory - Support '+' in license expressions - New unreproducible sphinx cache file rule - New dbus services improperly installed in /etc rule - Introduce typechecking using mypy and extend ruff linting rules - Don't crash on missing description, only throw error lint - Remove python-six from tests - Fix safeguards against false positives for QML dependency check - Limit shadow stack check to x86_64 binaries - Change from getopt to argparse Please report issues on GitLab [1] Thanks! Jelle [1] https://gitlab.archlinux.org/pacman/namcap/-/issues/

1 0

RFC Final Comment Period: "Automated digital signing of OS artifacts"
by David Runge 19 Aug '25

19 Aug '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/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. 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

PKGBUILD SPDX License array RFC status
by Jelle van der Waa 18 Aug '25

18 Aug '25

Hi All, Some time ago we decided to adopt SPDX license identifiers in the license array of PKGBUILD's. Without having progress reports its hard to know what the current status is, so I made a little script with some borrowed logic from namcap. [1] This uses expac to extract the licenses array from the local package sync db (/var/lib/pacman/sync). The unknown / invalid entries are emitted on stderr and stdout contains JSON data to be consumed by whatever tool you might suit you :-) A test run on my machine gave the following output, in summary: [2] * invalid: 62 * unknown: 4743 I hope having an easy script to collect statistics will move the conversion process forward. But do note that the original RFC does not yet tackle the `custom` license question. [3] [1] https://github.com/jelly/Dotfiles/blob/master/bin/arch-spdx-statistics [2] https://gist.githubusercontent.com/jelly/c5b790c3b1223f91362d956d50401e93/r… [3] https://rfc.archlinux.page/0016-spdx-license-identifiers/#unresolved-questi…

2 2

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

Introducing bumpbuddy
by Robin Candau 07 Aug '25

07 Aug '25

Hi everyone, We are very happy to announce the addition of a new member to the "buddy" family: bumpbuddy! [1] Initially introduced to Arch staff during last year's Arch Summit as the "nvchecker-poc" [2], bumpbuddy is now (a)live and ready to assist our package maintainers and users in monitoring new upstream releases for our packages. ## What is bumpbuddy? Bumpbuddy is a daemon watching for new upstream releases for our packages. It automatically opens GitLab issues for out of date packages [3], keep them updated if needed (e.g. if a newer upstream release supersedes the initially reported one) [4] and closes them once the matching version has been pushed [5]. It intends to fill the gaps in current methods for new upstream release tracking and reporting by proposing a centralized and automated solution. ## Benefits for package maintainers Bumpbuddy takes advantage of the `.nvchecker.toml` file from GitLab's packages repo to perform automated tracking of new upstream releases. Therefore, Package Maintainers won't need to rely on manual `pkgctl version check` runs or "homemade" solutions to track new upstream releases for their packages anymore. The reporting of new upstream releases being done via GitLab issues offers a (public) place to discuss and collaborate around eventual problems or blocking points preventing a new release from being packaged [6]. Assignment to those "out of date" issues is opt-in and can be enabled by reacting with the "package" emoji from bugbuddy's user settings [7]. Note that such issues are automatically opened as "confirmed", so bug-wranglers will not get assigned. ## Benefits for users Thanks to bumpbuddy automated tracking and reporting, our package maintainers should now be aware of new upstream releases without requiring users to manually flag packages out of date via the dedicated button on Archweb (which we actually intend to get rid of at some point, more on that in the next chapter). Another benefit for users is that, as opposed to the current "flag out of date" feature, GitLab issues offer a public place to look for (or ask for) the state of a pending update. This should hopefully allow for more transparency towards users wondering why a specific update is taking some time to be packaged. ## Current specifications and future work Bumpbuddy currently runs every 3 hours, which means that it may take up to 3 hours for new releases to be reported and for the associated GitLab issue to be automatically close once the matching version has been pushed. It's also worth reminding that the version tracking is based on the `.nvchecker.toml` configuration file of packages repo, meaning that an erroneous configuration file may result in erroneous version reporting and that packages that miss a configuration file will not be monitored. Here are a few mid / long term goals we have for bumpbuddy: - Provide a web overview for reports [9]. - Provide an API endpoint for `pkgctl version check` (to produce faster results). - Manage "out of date" status for packages on Archweb and get rid of the "flag out of date" button; which is manual (and therefore error prone), may be used wrongly/abusively (e.g. to report bugs or send some spam), is highly dependent on packages popularity and lacks transparency (as it doesn't provide a public place to discuss eventual blocking points). - Open merge requests rather than (or in addition of) GitLab issues, including the result of `pkgctl version upgrade` (regarding our future goal to adopt a gitops workflow for packaging). - And more... [10]. ## Conclusion This is the first iteration of bumpbuddy and things are still at a fairly early stage, so bear with us and don't hesitate to open issues [10] to submit bug reports or suggesting improvements. I would like to thank everyone who helped us improving bumpbuddy so far by opening issues, sharing opinions and opening merge requests. I would also like to give a special thank to Segaja, mh4ckt3mh4ckt1c4s and yan12125, who have been (beta) testing bumpbuddy for the past few months, as well as a huge thanks to klausenbusk & gromit for their amazing work and precious help on that project! [1] https://gitlab.archlinux.org/archlinux/bumpbuddy [2] https://pkgbuild.com/~antiz/presentations/Nvchecker_PoC/ [3] https://gitlab.archlinux.org/archlinux/packaging/packages/timeshift/-/issue… [4] https://gitlab.archlinux.org/archlinux/packaging/packages/timeshift/-/issue… [5] https://gitlab.archlinux.org/archlinux/packaging/packages/timeshift/-/issue… [6] https://gitlab.archlinux.org/archlinux/packaging/packages/timeshift/-/issue… [7] https://gitlab.archlinux.org/archlinux/bugbuddy/-/issues/1 [8] https://archlinux.org/packages/extra/x86_64/timeshift/flag/ [9] https://gitlab.archlinux.org/archlinux/bumpbuddy/-/issues/10 [10] https://gitlab.archlinux.org/archlinux/bumpbuddy/-/issues/ -- Regards, Robin Candau / Antiz

3 3

News draft: zabbix >= 7.4.1-2 may requires manual intervention
by Robin Candau 04 Aug '25

04 Aug '25

Hi, I've been working on a significant rework of the zabbix split package [1] over the past few days, introducing a fair amount of changes and improvements. One key change consists of replacing the multiple sysusers historically created for each zabbix components with a single shared "zabbix" user: - It aligns better with the intended upstream standard and the way other distributions does this (see [2] for more details). - The previous historical approach was somewhat *hacky*, e.g. relying on unnecessarily static UID:GID for each user and running some `chown` during `package()` rather than relying on systemd sysusers.d / tmpfiles.d. That said, this change *may* require manual intervention from users. While I'm aware that Zabbix component usage on Arch Linux might be relatively low, I believe that monitoring components are critical enough to warrant a news entry about this change and the potential impact it implies. Of course, feel free to let me know if you think otherwise. News draft below. Pad available at [3]. ---------- # zabbix >= 7.4.1-2 may requires manual intervention Starting withi `7.4.1-2`, the following Zabbix system users (previously shipped by their related packages) will no longer be used. Instead, all Zabbix components will now rely on a shared `zabbix` user (as originally [intended by upstream](https://www.zabbix.com/documentation/current/en/manual/installati… and done by other distributions): - zabbix-server - zabbix-proxy - zabbix-agent *(also used by the `zabbix-agent2` package)* - zabbix-web-service This shared `zabbix` user is provided by the newly introduced `zabbix-common` *split* package, which is a now a dependency for all relevant `zabbix-*` packages. The switch to the new user is handled automatically in the corresponding `systemd` service units. However, **manual intervention may be required** if you have custom files or configurations referencing / being owned by the above deprecated users, for example: - `PSK` files used for encrypted communication - Custom scripts for metrics collections / report generations - `sudoers` rules to metrics requiring elevated privileges to be collected - ... Those should therefore be updated to refer to / be owned by the new `zabbix` user, otherwise some services may fail to start properly (if not at all). Once migrated, you may optionally remove the obsolete users and their primary groups from your system (see the [related Arch Wiki page](https://wiki.archlinux.org/title/Users_and_groups) for details). ---------- [1] https://gitlab.archlinux.org/archlinux/packaging/packages/zabbix [2] https://gitlab.archlinux.org/archlinux/packaging/packages/zabbix/-/issues/1… [3] https://md.archlinux.org/YjsLnkzRRoeMa7BP3gxYKw# -- Regards, Robin Candau / Antiz

2 4

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

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) 18 Jun '25

18 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

RFC Final Comment Period: REUSE for package license linting
by Morten Linderud 13 Jun '25

13 Jun '25

An RFC has now entered its Final Comment Period. In 14 days, the discussion will end and the proposal will either be accepted, rejected or withdrawn: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/52 Please visit the above link for discussion. Summary: Utilize REUSE for package license linting for all package sources. -- Morten Linderud PGP: 9C02FF419FECBE16

1 0

RFC Final Comment Period: Establish default build flags for Fortran
by Jakub Klinkovský 12 Jun '25

12 Jun '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/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

Adopting similar packages in extra
by Quentin Michaud 10 Jun '25

10 Jun '25

Hi all, I am interested in packaging vscodium [1] into extra but am worried that it would be seen as a duplicate of the code [2] package. This situation is unclear and not explicitly mentioned in the wiki [3]. I asked the question on Matrix/IRC and this stirred a larger debate, so artafinde suggested me to post the question here in order to have a record of the discussion and potential decisions. The (more generic) questions are the following: under which criteria do we want to accept multiple "similar" packages in official repos or replace one by another? Do we want to fix (or already have) rules or guidelines for these situations or do we want to proceed on a case-by-case basis? "similar" packages can mean different things, I see several categories: - Hard fork of a project but projects are very close / are trying to stay compatible. Examples : redis (AUR) / valkey (extra), terraform (extra) / opentofu (extra) - Soft fork of a project aiming at adding / removing functionalities using patches. Examples : vscode (extra) / vscodium (AUR), firefox (extra) / librewolf (AUR) and other Firefox forks - Rewrite of a project but aiming to achieve the exact same goals / drop-in replacement : Examples: sudo (core) / sudo-rs (extra), coreutils (core) / uutils (extra). This category is tricky because the definition of "exact same goals" is unclear, but I exclude software that implement common standards but that are vastly different in practice, such as docker / podman or openssh / dropbear. This is more relevant to the "replace one by another" part, as Ubuntu did recently with sudo [4]. As for the criteria on which to base these decisions, they are many but the most important ones that I was able to think of are: - licensing changes - user impact - compatibility / conflicts between forks / flavors of the same software I hope thinking and discussing about this will help us to set guidelines on how to handle such situations in the future and document it in the wiki. Your thoughts are welcome :) Cheers, Quentin Michaud / mh4ckt3mh4ckt1c4s [1]: https://vscodium.com/ [2]: https://archlinux.org/packages/extra/x86_64/code/ [3]: https://wiki.archlinux.org/title/Package_Maintainer_guidelines#Rules_for_pa… [4]: https://discourse.ubuntu.com/t/adopting-sudo-rs-by-default-in-ubuntu-25-10/…

5 5

Adopting similar packages in extra
by Quentin MICHAUD 09 Jun '25

09 Jun '25

1 0

Switch to a versioned packaging scheme for wlroots
by Robin Candau 31 May '25

31 May '25

Hi, Wlroots is one of the packages for which we need to keep multiple versions around to ensure compatibility with reverse dependencies. At the moment, we have a wlroots0.17 package [1] (for the few packages that still require it, most notably qtile [2]) and a "regular" wlroots package [3] that currently points to 0.18. We are evaluating bumping the wlroots package to 0.19, but that requires the introduction of a new wlroots0.18 package to preserve compatibility with reverse dependencies that are not yet compatible with 0.19 (similar to what was done with the wlroots0.17 package). This method makes new wlroots releases difficult to triage as we have to release both the wlroots package bump and the new wlroots0.18 package at the same time (to avoid breaking changes regarding reverse dependencies) while ensuring that we defined proper "conflicts" to avoid conflicting files issues during upgrade [4] (since we can't control in which order packages will be upgraded on users' system). For instance, the new wlroots0.18 package would likely need a "conflicts" array that looks like this; in order to avoid files collision with the "regular" wlroots package until it gets updated to 0.19 on users' system, and also to avoid an unexpected conflict with the wlroots0.17 package. ``` conflicts=( "wlroots<0.19" "wlroots>=0.18" ) ``` While the above _should_ work, this is a quirky dance that will eventually get more and more complex over time (e.g. if we have to accumulate more versions of wlroots in the future). As such, I would like to switch to a versioned packaging scheme for wlroots. This means dropping the "regular" wlroots package and solely rely on versioned packages like: wlroots0.17, wlroots0.18 & wlroots0.19 (similar to e.g. gtk2, gtk3, gtk4 in a sense). Wlroots already adopted a versioned so/lib naming scheme so there is no file collision between e.g. wlroots0.18 and wlroots0.19 (meaning we won't need the above "conflicts" array dance anymore). Technically speaking, that means introducing a new wlroots0.18 package that conflicts and replaces the current "regular" wlroots package (to ensure people make the switch without file conflicting issue) and a new wlroots0.19 package. We could then drop the "regular" wlroots package from the repo and keep moving with versioned packages only in the future (e.g. wlroots0.20, wlroots0.21, and so on...). Reverse dependencies can then explicitly point to the version they need (similar to how it's done currently with wlroots0.17). I'm aware that this may be unconventional regarding how we usually do things in Arch Linux, but I think it's fair to say that current way we have to deal with new wlroots releases is confusing and causes more harm than good. I think the above suggestion is a practical and relevant solution for such specific case. I created a related task todo list [5] that I will tackle today and put to staging. I intend to leave it in staging for a week or two in order to leave some time for people to react and / or raise any concerns I may have missed about switching to a versioned packaging scheme. Thanks :) [1] https://archlinux.org/packages/extra/x86_64/wlroots0.17/ [2] https://github.com/qtile/qtile/blob/master/docs/manual/wayland.rst?plain=1#… [3] https://archlinux.org/packages/extra/x86_64/wlroots/ [4] https://gitlab.archlinux.org/archlinux/packaging/packages/wlroots0.17/-/iss… [5] https://archlinux.org/todo/switch-to-a-versioned-packaging-scheme-for-wlroo… -- Regards, Robin Candau / Antiz

2 4

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

pulling mariadb-lts from extra-testing
by Christian Hesse 22 May '25

22 May '25

Hello everbody, I have just pulled mariadb-lts (11.4.6-1) from extra-testing. Several upstream bug reports indicate that there is a serious performance regression, though the exact cause it not yet known. Another release is expected really soon, possibly even in the following week. -- 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 2

IRC Channel for mirror related discussions now available
by pitastrudl 19 May '25

19 May '25

Hi all, We've created, some time ago already, a new channel on libera.chat for any Arch Linux mirror / mirrorlist related questions and chat. This is just another communication channel for all things related. It is still advised to report any issues to https://gitlab.archlinux.org/archlinux/arch-mirrors/-/issues for easier visibility and tracking of progress. Thank you for all your contributions, past and future! Channel name: #archlinux-mirrors Regards, Arun

1 0

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

GHC 9.4.8 enters [extra-testing]
by Felix Yan 03 Apr '25

03 Apr '25

Hi all, The long delayed GHC 9.4.x updates have been done and moved to [extra-testing]. Two obsolete packages were retired from the distribution. If you still have them installed, please consider removing them: - haskell-configurator - haskell-critbit Many thanks again to @Vekhir who helped me a lot for preparing this batch and many previous batches of Haskell updates. As always, please report any issues and have fun! -- Regards, Felix Yan

1 0

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

RFC Final Comment Period: Shorten default TCP keepalive time
by Jan Alexander Steffens (heftig) 11 Mar '25

11 Mar '25

An RFC has now entered its Final Comment Period. In 14 days, the discussion will end and the proposal will either be accepted, rejected or withdrawn: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/51 Please visit the above link for discussion. Summary: Set our default `net.ipv4.tcp_keepalive_time` to override the extremely conservative kernel default.

1 0

RFC: REUSE for package license linting
by Morten Linderud 11 Mar '25

11 Mar '25

A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/52 Please visit the above link for discussion. Summary: Utilize REUSE for package license linting for all package sources. -- Morten Linderud PGP: 9C02FF419FECBE16

1 0

RFC: providing an official WSL image
by Robin Candau 03 Mar '25

03 Mar '25

A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/50 Please visit the above link for discussion. Summary: Provide an official Arch Linux WSL image and define specifications for it (in terms of maintenance, distribution and support). -- Regards, Robin Candau / Antiz

1 2

Cleaning up old [community*] repos
by Sven-Hendrik Haase 01 Mar '25

01 Mar '25

Hey, The git/community-to-extra migration was almost two years ago. Back then, we left the [community] repository and friends ([community-staging], [community-testing]) in place (though empty) so that users would have an easier time migrating. They've sat there unused for a long time now and I think users have had enough time to migrate. I would like to suggest removing the empty [community] repos from repos.archlinux.org. This could break update workflows for users who haven't updated their /etc/pacman.conf in a long time but apart from that I don't expect any drawbacks. Opinions? Sven

4 5

RFC: Shorten default TCP keepalive time
by Jan Alexander Steffens (heftig) 22 Feb '25

22 Feb '25

A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/51 Please visit the above link for discussion. Summary: Set our default `net.ipv4.tcp_keepalive_time` to override the extremely conservative kernel default.

1 0

Grub package removed from [testing], please stay on grub-2:2.12-3
by Tobias Powalowski 19 Feb '25

19 Feb '25

Hi, this afternoon we bumped the grub package to the latest available git snapshot, in order to solve the latest security issues encountered and revealed by the grub devs yesterday night. After some initial testing we decided to remove it again from the [testing] repository. We need now to figure out how we can solve the security issues without breaking user's systems, eg. loopback is broken or accessing encrypted devices. We will forward the detected issues to the grub devs. If you already updated the grub package, please downgrade it to grub-2:2.12-3, that is in [core] repository. Best regards tpowa -- Tobias Powalowski Arch Linux Developer (tpowa) https://www.archlinux.org tpowa(a)archlinux.org Archboot Developer https://archboot.com St. Martin-Apotheke Herzog-Georg-Str. 25 89415 Lauingen https://www.st-martin-apo.de info(a)st-martin-apo.de

1 0

Rust packaging guidelines: Remove --all-features suggestion
by kpcyrd 19 Feb '25

19 Feb '25

hello, following up on an irc discussion on the Rust packaging guideline, I'd like to propose changing the command in section 5 from: cargo build --frozen --release --all-features to cargo build --frozen --release Enabling all non-default features is rarely what we want, they are usually off for a reason and instead features should be explicitly selected and enabled, or added to the default feature set by upstream if they are meant to be on by default. Setting --all-features in many projects (mine included) would enable the `vendored` feature that opts you out of system libraries, which is something we explicitly don't want. cheers, kpcyrd

2 1

News draft: Cleaning up old repositories
by Sven-Hendrik Haase 17 Feb '25

17 Feb '25

Hey all, in an earlier thread [0], I proposed cleaning up the unused repos from repos.archlinux.org. They've become unused and stagnant after the git migration almost two years ago. We kept them around so it wouldn't break setups of users that tried to get the repository sync databases with an outdated pacman.conf. The old repos are safe to remove. Originally I had planned to just remove them and leave it at that. However, some people mentioned that it might still confuse users who haven't updated their pacman.conf in a long time. In order to inform those users there should be a news post. [0] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o… --- # Cleaning up old repositories Around two years ago, we've merged the [community] repository into [extra] as part of the git migration. In order to not break user setups, we kept these repositories around in an unused and empty state. We're going to clean up these old repositories on *2025-03-01*. On systems where `/etc/pacman.conf` still references the old `[community]` repository, `pacman -Sy` will return an error on trying to sync repository metadata. The following deprecated repositories will be removed: `[community], `[community-testing]`, `[testing]`, `[testing-debug]`, `[staging]`, `[staging-debug]`. Please make sure to remove all use of the aforementioned repositories from your `/etc/pacman.conf`! --- Cheers, Sven

2 2

Fwd: Phasing out reiserfsprogs (EOL)
by Tobias Powalowski 06 Feb '25

06 Feb '25

Hi folks, as Giancarlo and Gromit mentioned, this is worth sharing on the public mailing list too. So here the mentioned mails from me for the public. Best regards tpowa -------- Weitergeleitete Nachricht -------- Betreff: Re: Phasing out reiserfsprogs (EOL) Datum: Thu, 6 Feb 2025 09:35:18 +0100 Von: Tobias Powalowski <tobias.powalowski(a)googlemail.com> An: staff(a)lists.archlinux.org Am 28.08.24 um 14:20 schrieb Tobias Powalowski: > Hi folks, > > reiserfs is a dead horse, I started to drop it from btrfs-progs > depends already. > > Any strong objection in removing it as depend from all packages? > > Thanks for your opinions. > > Best regards > > tpowa > Hi folks, 6.13 reached the repositories, all packages that depended on reiserfs were updated some time ago. The reiserfsprogs are now gone from the official repositories. Best regards tpowa

1 0

News draft: glibc 2.41 breaks Discord
by Frederik Schwan 04 Feb '25

04 Feb '25

Hi everyone, as discussed in the Matrix packaging channel, the upcoming glibc move from testing to stable will break audio connectivity for Discord clients. Discord has fixed the issue in their canary build and has communicated an eta for the fix in stable for 2025-02-10. As the glibc update holds off package moves from testing to stable I would like to continue releasing the toolchain and give everyone instructions on how to fix their Discord installation. ------ # Glibc 2.41 corrupting Discord installation Glibc and it's friends will move from testing to stable on approx. 2025-02-03. After installing the update, the Discord client will show a read warning that the installation is corrupt. This issue has been fixed in the Discord canary build. Until the fix hits the stable Discord release, please use the canary build or login via browser if you rely on audio connectivity. There have been no reports that (written) chat connectivity is affected. ------ Best regards, Frederik

4 5

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

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

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

Splitting the Arch Linux repo and archive server
by Kristian Klausen 27 Dec '24

27 Dec '24

Hi all, The DevOps team is working on splitting[0] the repo server and the archive server, which are currently still located on the same box (gemini.archlinux.org) This reason for splitting it is mainly due to I/O issues and to ensure separation of concerns. Please see [1] and [2] for a bit more context. We have already ordered the new repo server (AX41-NVMe[3] with an extra 1 TB NVMe SSD) and switched the rsync endpoint for the mirrors 7 months ago[2], so now the time has come to move the home of the repos from gemini to the new repo server. Christian and I are planning on taking a stab on this in a few hours, during which the access to the repos will be cut off. [1] https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/531 [2] https://lists.archlinux.org/archives/list/arch-mirrors@lists.archlinux.org/… [3] https://www.hetzner.com/dedicated-rootserver/ax41-nvme Cheers, Kristian

2 1

python-httpcore 1.0.7-1 & python-httpx 0.28.1-1 pulled from testing
by Robin Candau 27 Dec '24

27 Dec '24

Hi all, Please note that I have just pulled python-httpcore 1.0.7-1 & python-httpx 0.28.1-1 from [extra-testing]. Python-httpx >= 0.28 introduces breaking changes preventing some reverse dependencies (meaning packages depending on it) to be built correctly. This will be worked on in a proper separate ToDo task [1]. Please downgrade python-httpcore & python-httpx to the version available in [extra]. [1] https://archlinux.org/todo/python-httpx-028-rebuild/ -- Regards, Robin Candau / Antiz

1 0

Do not change architecture of packages during rebuilds
by Jelle van der Waa 22 Dec '24

22 Dec '24

Hi All, As you might have noticed, Python 3.13 is moved to [core]. Just like with the move of staging to testing we can't move a package because it changed architectures and hits a dbscripts bug. [1] Please don't do this until the bug is fixed :) [1] https://gitlab.archlinux.org/archlinux/dbscripts/-/issues/57

1 0

TensorFlow packages incompatible with Python 3.13
by Torsten Keßler 20 Dec '24

20 Dec '24

Dear all, over the last weeks, Arch Linux Package Maintainers have been working on the Python rebuild for the new minor release 3.13. All but one package, TensorFlow, where successfully updated to work with Python 3.13. TensorFlow proved to be difficult to update [0]. As a large software stack with different python modules and low level C/C++ interfaces, we can't progress without upstream. Unfortunately, a new TensorFlow release with Python 3.13 is only expected for early next year [1]. We have evaluated different options. TensorFlow and related packages could be dropped from the official repositories. But we think that this step would cause too much confusion for users. Instead, we add a warning printed during the installation of a TensorFlow package that encourages users to use TensorFlow via pip or via the official docker images: WARNING: This version of the TensorFlow package is not compatible with Python 3.13 If you want to use TensorFlow, consider installing an older version of Python and use a virtual environment or use the official Docker image, https://www.tensorflow.org/install Best, Torsten [0] https://github.com/tensorflow/tensorflow/issues/78774#issuecomment-24395683… [1] https://github.com/tensorflow/tensorflow/issues/78774#issuecomment-24981485…

3 3

Sovereign Tech Agency funding for ALPM project
by David Runge 09 Dec '24

09 Dec '24

Hi all, I am happy to announce that the [ALPM][0] (Arch Linux Package Management) project receives funding from the [Sovereign Tech Agency][1] for work on the Arch Linux packaging ecosystem. > The Sovereign Tech Agency supports the development, improvement, and > maintenance of open digital infrastructure. > Its goal is to sustainably strengthen the open source ecosystem, focusing on > security, resilience, technological diversity, and the people behind the code. The investment from the Agency's Sovereign Tech Fund provides financing for four developers to work on the ALPM project in a part time capacity over the course of 15 months. The developers are [Arne Christian Beer][2], [Heiko Schäfer][3], [Orhun Parmaksız][4] and [David Runge (myself)][5]. Work on the project has started in October 2024 and the funding continues until the end of 2025. The ALPM project provides specifications, as well as Rust libraries and tools. Its goals are robust integration for all package creation, validation and installation tasks, repository management, as well as drop-in replacements or alternatives for some facilities provided by [pacman][6]. The investment through the Sovereign Tech Fund supports multiple milestones, which are explained below. ## Formal specifications for packaging data formats The Arch Linux packaging ecosystem uses underspecified/undocumented file and metadata types, yet we need to be able to use them reliably in other contexts such as package creation, build and package repository management tooling. Therefore this milestone involves developing versioned specifications for all low-level descriptor file and implementing Rust libraries based on them. These will be based on the existing ad-hoc reference implementations in [makepkg][7] and pacman. ## Basic OpenPGP verification of artifacts Signature verification in Arch Linux package management currently hinges on a stateful GnuPG keyring. This solution is brittle and has already caused various issues related to the Arch Linux keyring in the past. To simplify signature verification - while at the same time enabling the use of a more diverse set of cryptographic technologies - a specification for the [UAPI group][8] will be written. An accompanying Rust library will be provided as a simple and stateless integration, not limited to use in Arch Linux. ## Rust library for handling of individual packages The structure of Arch Linux package files is currently not explicitly defined. This milestone focuses on providing a formal specification of what an ALPM-based package contains, how it is created and handled. A dedicated Rust library and tool will facilitate package creation, validation and installation. These new Rust libraries will also expose a C API for possible integration into the C-based libalpm library. ## Rust library for system package management This milestone revolves around the use of the previously implemented components by providing a library for package download, validation, verification, installation and state handling similar to pacman's libalpm and will handle sets of individual packages on user systems. A C-API will be provided for compatibility with libalpm-based applications. One specific concern of this milestone is modernizing the OpenPGP integration. Current package management tooling does not allow for scoping signature verifiers (e.g. OpenPGP certificates) for a specific purpose, such as "only packages" or "only repository metadata". The new system will rely on a stateless approach such as the one to be proposed as specification to the UAPI group. ## Distribution-agnostic OpenPGP stack for the verification of distribution artifacts This milestone will focus on a set of foundational libraries, based on a UAPI specification from a previous milestone. These libraries will add support for PGPKI (aka the “Web of Trust”) in the generic directory structure for OpenPGP certificates used for the verification of distribution artifacts. The libraries mentioned above will be integrated into the ALPM context to allow for example the full verification of packages and repository metadata. A Rust-based solution will be provided as a modern alternative to the current GnuPG-based approach. # The outcome(s) The ALPM project strives to build a modern, sustainable, maintainable and memory-safe framework for the Arch Linux packaging ecosystem. This framework will enable robust and predictable integration for all package related tooling and libraries. The project goals are intentionally ambitious while being constrained to a relatively short period of time. The work is organized so that real world benefits will happen early and often. Several infrastructure related projects have already reached out with a concrete interest to make use of libraries created in the first phase of the project. The work will be done in the open, on the [Arch Linux GitLab][0]. Everyone and anyone is welcome to join in and help out! My sincerest thanks go to the Sovereign Tech Agency for commissioning dedicated work on the ALPM project. Best, David [0]: https://gitlab.archlinux.org/archlinux/alpm/alpm [1]: https://www.sovereign.tech/ [2]: https://gitlab.archlinux.org/nukesor [3]: https://gitlab.archlinux.org/heiko [4]: https://gitlab.archlinux.org/orhun [5]: https://gitlab.archlinux.org/dvzrv [6]: https://wiki.archlinux.org/title/pacman [7]: https://wiki.archlinux.org/title/Makepkg [8]: https://uapi-group.org

1 0

Highlights in the devtools 1.3.0 release
by gromit 06 Dec '24

06 Dec '24

Hello everyone, as we got the feedback on the Arch Linux Summit that not everyone is aware about all the new shiny things in devtools, we wanted to give a small overview about the latest developments. Apart from this effort every release has an easily digestable changelog attached (see [0] as example for 1.3.0), so if you want to stay up to date you can also follow the releases on the Gitlab repo or check the previous release notes for additional gems! # 🚀 Highlights in the 1.3.0 release 🚀 ## ✨ The 'pkgctl issue' subcommands Now all the functionality needed to work with issues is availiable directly on the commandline via pkgctl. A regular packager workflow might look something like this: Check open issues: $ pkgctl issue list --assigned-to-me --group Check details about an issue: $ pkgctl issue view --package linux 97 $ pkgctl issue view --package linux --web 97 $ pkgctl issue view --package linux --comments 97 React to the issue: $ pkgctl issue close --package linux --edit 97 $ pkgctl issue comment --package linux 97 There are way more options and things to do, but feel free to explore on you're own! ➡ Contributed by @anthraxx in [MR!255][1] 🎉 ## 🚧 Fixes to 'offload-build' There was a major refactoring effort for offload-build, which has the very neat consequence that the --inspect argument can now be used in combination with pkgctl build's --offload so that remote builds can be debugged more easily. ➡ Contributed by @lahwaacz in [MR!234][2] 🎉 ## 📦 nvchecker related changes - For packages without an upstream one can now create a special config: $ pkgctl version setup --no-upstream This is thought to be only used with packages that do not have a canonical upstream, like metapackages. If you have trouble setting up nvchecker integration for the more complicated packages feel free to get in touch! - On release there now is a warning when a package repository does not have a '.nvchecker.toml' - We no offer a way to retrieve machine-readable output from pktctl version check: $ pkgctl version check --json * ➡ Contributed by @antiz, @segaja and @anthraxx in [MR!273][3], [MR!275][4] and [MR!286][5] 🎉 --- Apart from the big changes/improvements there are of course a lot of minor bug fixes, documentation improvements and smaller features included. Thanks for everyone that helped to discuss & improve features! 🎉 Cheers, anthraxx & gromit [0]: https://gitlab.archlinux.org/archlinux/devtools/-/releases/v1.3.0 [1]: https://gitlab.archlinux.org/archlinux/devtools/-/merge_requests/255 [2]: https://gitlab.archlinux.org/archlinux/devtools/-/merge_requests/234 [3]: https://gitlab.archlinux.org/archlinux/devtools/-/merge_requests/273 [4]: https://gitlab.archlinux.org/archlinux/devtools/-/merge_requests/275 [5]: https://gitlab.archlinux.org/archlinux/devtools/-/merge_requests/286

1 0

Python 3.13 Rebuild
by Jelle van der Waa 16 Nov '24

16 Nov '24

Hi all, Leaves are falling, weather is getting colder and my apartment needs heating so clearly it is time to rebuild 1500+ packages. If no one objects or has any other pressing rebuilds, I'd like to kick off a Python rebuild bootstrap this weekend (latest Sunday). A To Do list will be created when we have bootstrapped setuptools, pytest and friends. Greetings, Jelle

1 2

RFC: Streamline the RFC writing process
by Robin Candau 15 Nov '24

15 Nov '24

A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/43 Please visit the above link for discussion. Summary: Streamline the writing and publishing of RFCs by relying on markdown and dedicated spellcheckers and linters. -- Regards, Robin Candau / Antiz

3 4

RFC: Upstream Package Sources
by David Runge 14 Nov '24

14 Nov '24

A new RFC (request for comment) has been opened here: 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 also cryptographically verifiable upstream sources by default.

1 0

News Announcement: Licensing Package Sources
by Rafael Epplée 14 Nov '24

14 Nov '24

Hey all, after our previous email to ADP, some of you suggested a news post might be warranted in addition to the notification to ADP which we agree with. I'm happy to hear any feedback on the draft below. You can find a live version with incorporated feedback in a pad at [0]. --- Title: Providing a license for package sources Arch Linux hasn't had a license for any package sources (such as `PKGBUILD`s) in the past, which is potentially problematic. Providing a license will preempt that uncertainty. In [RFC 40](https://rfc.archlinux.page/0040-license-package-sources/) we agreed to change all package sources to be licensed under the very liberal [0BSD](https://spdx.org/licenses/0BSD.html) license. **This change will not limit what you can do with package sources.** Check out the RFC linked above for more on the rationale and prior discussion. Before we make this change, we will provide contributors with a way to voice any objections they might have. Starting on 2024-xx-xx, over the course of a week, contributors will receive a single notification email listing all their contributions. - If you receive an email and agree to this change, there is no action required from your side. - If you do not agree, please reply to the email and we'll find a solution together. If you contributed to Arch Linux packages before but didn't receive an email, please contact us at package-sources-licensing(a)archlinux.org. --- Cheers, Rafael [0]: https://md.archlinux.org/xMN1JFWIQm6qWb29aAblyQ#

1 0

Let's drop ollama-gemma2-2b and forbid GenAI models
by Sven-Hendrik Haase 14 Nov '24

14 Nov '24

Hey all, There's been some discussion about this via chat but no action has been taken. Some time ago, ollama-gemma2-2b was uploaded to [extra] which has caused some discussion for various reasons. I'm not writing this mail to address or open up the discussion for ethical or political concerns. This is about pragmatism. With the current state of things, I don't think we should have any LLMs or other GenAI models in official repos. I think it would be much more practical to offer downloaders such as huggingface-cli or ollama instead. GenAI models become out of date every other week and they tend to be rather large too. Downloaders allow users to download these models from specialized hosters at good speeds and to easily stay up to date. I don't think we're doing anyone a service by offering outdated GenAI models in the repos. This mail is explicitly NOT about other ML model types such as rnnoise. Those tend to be small and unchanging. They should stay in repos where it makes sense and if there's software that uses them (such as Mumble in this particular example). I propose this: - Drop ollama-gemma2-2b - Forbid other GenAI models from entering official repos for the time being What do you guys think? Cheers, Sven

5 5

Licensing Package Sources
by Rafael Epplée 12 Nov '24

12 Nov '24

Hey everyone, As part of the implementation of RFC 40 [0], we're about to start sending out emails to everyone who has previously contributed to any of our package sources in any capacity. We have gathered around 5000 unique emails and will space sending out over a few days to make sure we don't run into rate limits. Contributors will receive a single email listing all their contributions. Gathering the emails was done on a best-effort basis. If you have contributed to Arch before and didn't receive an email, please contact us at package-sources-licensing(a)archlinux.org. Cheers, Rafael and Sven [0] https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/40

1 0

zlib-ng
by Jelle van der Waa 11 Nov '24

11 Nov '24

Hey All, I noticed Fedora is discussing switching from zlib to zlib-ng. zlib-ng is a fork of zlib, which seems to offer ~ 40% better performance and a new API. We have about ~ 1000 packages depending on zlib, zlib-ng does offer a compat option to keep zlib API compatibility. [1] # Proposal From a discussion in #archlinux-staff. It was determined that a possible plan would be to introduce zlib-ng as package in [extra] with the modern API enabled, we can then migrate packages over that are compatible to the new API. A zlib-ng-compat package can be provided, as proposed by Fedora, that activates the zlib API compatibility mode and directly provides libz.so. This package can provide/conflict the original zlib package, and potentially be target to replace zlib all together. In short: zlib-ng would provide libz-ng.so zlib-ng-compat would provide libz.so # Packages which might be able to use zlib-ng Alpine offers a package which has 6 required packages.[2] Debian's codesearch suggests a few packages seem to mention a possible zlib-ng compatibility. [3] These notes where written down last Thursday, in the meantime, Anthraxx uploaded zlib-ng to [extra], so we can start switching packages which use the modern API over. Replacing zlib with zlib-ng-compact is something we need to discuss, I've overheard so far that some test suites fail because they check the compressed test artifact's hash which with zlib-ng can be different. [1] https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject.o… [2] https://pkgs.alpinelinux.org/package/edge/community/x86/zlib-ng [3] https://codesearch.debian.net/search?q=zlib-ng&literal=1&perpkg=1 Greetings, Jelle van der Waa & Anthraxx

3 3

Deprecating Fcitx 4.x
by Felix Yan 20 Oct '24

20 Oct '24

Hello, It appears all upstream repositories for Fcitx 4 have been archived since May. This indicates that the framework is no longer being developed or supported by upstream. I will not remove all Fcitx 4.x packages from Arch repositories now, but I encourage everyone to try out Fcitx 5.x and migrate your configuration. Fcitx upstream provides a migration guide at: https://fcitx-im.org/wiki/Upgrade_from_Fcitx_4 -- Regards, Felix Yan

1 0

Ruby 3.3.5
by Andreas 'Segaja' Schleifer 14 Oct '24

14 Oct '24

Hello, we have started today to update Ruby in Arch Linux to version 3.3.5 and for this we block staging from today on until it is completed. The progress can be watched on [0]. Best regards Segaja [0] https://archlinux.org/todo/ruby-33-rebuild/

1 3

Autumn packages cleanup
by Jelle van der Waa 14 Oct '24

14 Oct '24

Hi all, I'm going to orphan the following packages as I want to focus more time on maintaining Python. I'll orphan the following packages in [extra] in a week, please pick them up if you are interested. (Or else I should probably packages which are unrequired to the AUR). eslint_d esptool fsarchiver geckodriver hey meilisearch python-meilisearch intel-gpu-tools python-pyenchant unshield wabt bonnie++

1 0

Dropping python-spsdk and others
by David Runge 09 Oct '24

09 Oct '24

Hi all, with python-pynitrokey dropping the dependency on python-spsdk and others, I am able to drop a few packages. If you are interested in any of them, please make sure to adopt them, else I will drop the following packages to the AUR in a week from now (2024-10-16): python-spsdk python-bincopy python-argparse-addons python-python-click-command-tree python-python-click-option-group python-deepmerge python-hexdump python-libusbsio python-pylink-square python-pyocd python-cmsis-pack-manager python-sly python-pyftdi python-frozendict The python-fastjsonschema package is not used by any of the packages I maintain (but used by fusesoc, jupyter-nbformat, python-{poetry-core,validate-pyproject}) and I will orphan it. Best, David -- https://sleepmap.de

1 0

Future of salt in our repositories
by Morten Linderud 05 Oct '24

05 Oct '24

Yo, `salt` is a framework for server provisioning, change management and administrations tasks. It's based on Python and been a fairly popular framework over the years. It's been packaged in our repositories for over a decade now as it was originally written by Thomas Hatch, which was a package maintainer for many years. `salt` as of version `3007` does not support Python 3.12, and the release `3008` seems far away, which means they won't be ready for the eventual release of Python 3.13 early next year either. This is actively causing problems for the users depending on this package. https://github.com/saltstack/salt/milestone/120 Instead of aiming for compatability it seems like Salt is going for the vendor approach they call `onedir` and instead bundle *everyting*, including their own Python runtime, into a directory. This is going to be a mess to properly support for us as we would be fully reliant on salt to properly ship security updates, along with giving us a *very* hard time properly maintaing this package. https://gitlab.archlinux.org/archlinux/packaging/packages/salt/-/issues/4 I don't think the `onedir` thing belongs in our repositories and as the upstream won't be ready for Python 3.13 I don't see any other possibility but to drop package from our repositories. Salt does not provide their own pacman package for salt, so this is a headsup for anyone relying on the package for their server administration work so they can spend time figuring out how to migrate to another approach. As long as there are not any major issues I intend to drop this package ahead of our Python 3.13 release and prep work. Which might be December/Januar at it's earliest, and early summer at it's latest. I'll give a new update when the Python package maintainers start working on this. -- Morten Linderud PGP: 9C02FF419FECBE16

1 0

Re: Ruby 3.3.5
by Andreas 'Segaja' Schleifer 05 Oct '24

05 Oct '24

On 10/2/24 4:23 AM, Leandro Cunha wrote: > Some gems like Capybara seem to break in this version until the last > time I saw it. Being an important use software that I know breaks in > this version. > There seems to be more. Well there might always be a gem that needs updating, but ruby 3.3 has been released in December 2023 and so far I haven't encountered a single gem in our repos that wasn't compatible. Some we had to update to get compatible. For capybara I'm not sure what you are talking about. Their gemspec file says they are compatible with ruby > 3.3 and a simple rebuild against our extra-staging repo (which currently holds ruby 3.3.5) runs through, so at least it builds against ruby 3.3 I tried to get some tests working for this but it needs a lot of additional gems which I don't have time to dive too deep into right now, but as far as I can tell I see no issue that this is not ruby 3.3 compatible. If so you should report this upstream. Best regards Segaja

1 0

thunderbird 131.0 pulled from testing
by Leonidas Spyropoulos 02 Oct '24

02 Oct '24

Hi all, please note that I have just pulled thunderbird 131.0-1 from extra-testing. This is a release for testing purposes only and the confusion from my side came from the fact that the json file we monitor for updates has recently changed. Please downgrade to the extra version and execute thunderbird with `--allow-downgrade` parameter to downgrade your profile. thunderbird --allow-downgrade cheers -- Leonidas Spyropoulos Developer & DevOps PGP: 244740D17C7FD0EC

1 0

Dropping orphan Python packages
by Jelle van der Waa 02 Oct '24

02 Oct '24

Hi all, It's autumn and Python 3.13 is soon to be released, to not rebuild unrequired packages I propose to drop these orphan unrequired packages Sunday 6 October. If anyone wants to pick an orphan up please reply to this email. python-sphinx-typlog-theme python-requests-hawk python-pyvcd python-olm python-biopython python-flask-httpauth python-fxa python-ipyxact python-listparser Greetings, Jelle

1 0

RFC Final Comment Period: Mirror definition - Proposal for new mirror administration routines and mirror requirements
by pitastrudl 01 Oct '24

01 Oct '24

An RFC has now entered its 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/29 Please visit the above link for discussion. Summary: Before this proposal, all tasks surrounding mirrors were manual and in free-text form. This RFC therefore outlines the definitions and guidelines surrounding both becoming but also maintaining and decommissioning a mirrors in a new format using TOML and GitLab.

1 0

Arch Linux and Valve Collaboration
by Levente Polyak 27 Sep '24

27 Sep '24

We are excited to announce that Arch Linux is entering into a direct collaboration with Valve. Valve is generously providing backing for two critical projects that will have a huge impact on our distribution: a build service infrastructure and a secure signing enclave. By supporting work on a freelance basis for these topics, Valve enables us to work on them without being limited solely by the free time of our volunteers. This opportunity allows us to address some of the biggest outstanding challenges we have been facing for a while. The collaboration will speed-up the progress that would otherwise take much longer for us to achieve, and will ultimately unblock us from finally pursuing some of our planned endeavors. We are incredibly grateful for Valve to make this possible and for their explicit commitment to help and support Arch Linux. These projects will follow our usual development and consensus-building workflows. [RFCs] will be created for any wide-ranging changes. Discussions on this mailing list as well as issue, milestone and epic planning in our GitLab will provide transparency and insight into the work. We believe this collaboration will greatly benefit Arch Linux, and are looking forward to share further development on this mailing list as work progresses. [RFCs]: https://rfc.archlinux.page/

1 0

RFC Final Comment Period: License Package Sources
by Sven-Hendrik Haase 21 Sep '24

21 Sep '24

An RFC has now entered its 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/40 Please visit the above link for discussion. Summary: Our package sources currently do not have explicit licenses. This RFC proposes to license all Arch Linux package sources under the terms of the Zero-Clause BSD license.

2 3

Arch Linux in August 2024
by Levente Polyak 18 Sep '24

18 Sep '24

## Staff We would like to welcome [Quentin Michaud][0] as part of the Arch Linux Package Maintainer team. ## RFC A previously proposed [Distribution Developer Manual RFC][1] has been accepted with the intention to document how to run the distribution while leveraging GitLab's collaboration features and streamlined workflows for maintaining and evolving the resulting specifications. We have proposed an [RFC to license all Arch Linux package sources][2] under the terms of the Zero-Clause BSD license. We have proposed an [RFC to streamline the writing and publishing of RFCs][3] by relying on markdown and dedicated spellcheckers and linters. ## archinstall We have released [archinstall up to v2.8.6][4], featuring Limine configuration changes, optimized mirror listing including improved handling of speed tests, and several bug fixes. These updates also add support for Catalan translation. ## Infrastructure We have deployed Tempo as an APM (Application Performance Monitoring) within our infrastructure and connected it as a data source in Grafana. The first integration has been implemented in AURWeb, allowing us to trace individual requests and database queries for better performance insights. Furthermore we enabled the [body Sieve extension in Dovecot][5] for our staff, allowing for more advanced email filtering as well as rolled out HTTP/3 for several of our services. ## Packaging ### Ruby We have successfully rebuilt all relevant packages for Ruby 3.2.4 including collaborative effort to make packages ready for the new interpreter version. Ruby 3.2.4 is now available in the official repositories. ### Statistics In this month, we’ve successfully rolled out 4797 package updates addressing various enhancements and rebuilds, including 2354 package upgrades. Additionally, we’ve received 163 new package issues, while resolving a total of 131 issues. [0]: https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/t… [1]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/21 [2]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/40 [3]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/43 [4]: https://github.com/archlinux/archinstall/releases/tag/v2.8.6 [5]: https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/862

1 0

Arch Linux in July 2024
by Levente Polyak 18 Sep '24

18 Sep '24

## Pacman [Pacman v7.0.0][0] has been released as a major feature version. A new `DownloadUser` configuration option allows for dropping privileges when downloading files to a temporary directory. On top of this security measure, the new Landlock sandbox also prevents writing outside the restricted download directory. Additionally, `makepkg` removes `GITFLAGS` support, as it required breaking changes to git source handling. Furthermore this release addresses unstable git checksumming influenced by specific user configuration. On top, it now prevents `PKGBUILD` from overriding `BUILDENV` to avoid undesired side effects. ## ArchWeb We have released [ArchWeb 2024-07-29][1], featuring improvements in rebuilderd integration for reproducible builds status, enhanced caching for several pages, and implementation of a Django Prometheus exporter for better monitoring inside our Grafana dashboards. ## ArchISO [ArchISO v79][2] is a minor update that introduces reproducibility for the ext4 image, thanks to improvements related to `tune2fs`. ## infrastructure ArchWeb now exports Prometheus metrics via the `/metrics` endpoint, including request duration data. We are now scraping the endpoint and added visualization in our Grafana dashboards. ## SPI We have drafted a project status update highlighting our major achievements and key focus areas for the [2023 Annual SPI Report][3]. ## Packaging ### Statistics In this month, we’ve successfully rolled out 6084 package updates addressing various enhancements and rebuilds, including 2476 package upgrades. Additionally, we’ve received 200 new package issues, while resolving a total of 143 issues. [0]: https://gitlab.archlinux.org/pacman/pacman/-/releases/v7.0.0 [1]: https://github.com/archlinux/archweb/releases/tag/release_2024-07-29 [2]: https://gitlab.archlinux.org/archlinux/archiso/-/tags/v79 [3]: https://www.spi-inc.org/corporate/annual-reports/2023.pdf

1 0

Arch Linux in June 2024
by Levente Polyak 18 Sep '24

18 Sep '24

## archinstall The [archinstall v2.8.1][0] update has been released, featuring several bug fixes and improvements to partitioning and desktop profiles, along with the introduction of experimental LVM support and the addition of Finnish translation. ## ArchWeb [ArchWeb 2024-06-12][1] has been rolled out, which includes an update to Django's latest major version, Django 5.0 as well as small improvements within our Ruff configuration used as our Python linter. ## devtools We have released [devtools v1.2.1][2], which includes several small bug fixes as well as the ability in `mkarchroot` to specify a file destination inside the chroot and support for bind mounting a tmpfs with `makechrootpkg`. ## bugbuddy We have released [bugbuddy v0.3.0][3], our GitLab bot, which now automatically assigns security team members when the `scope::security` label is set for any issues or merge requests. ## Packaging ### Ruby We have completed the bootstrapping of Ruby 3.2.4 and will now begin the initial migration work toward its full release. ### Statistics In this month, we’ve successfully rolled out 4054 package updates addressing various enhancements and rebuilds, including 2259 package upgrades. Additionally, we’ve received 197 new package issues, while resolving a total of 183 issues. [0]: https://github.com/archlinux/archinstall/releases/tag/v2.8.1 [1]: https://github.com/archlinux/archweb/releases/tag/release_2024-06-12 [2]: https://gitlab.archlinux.org/archlinux/devtools/-/releases/v1.2.1 [3]: https://gitlab.archlinux.org/archlinux/bugbuddy/-/releases/v0.3.0

1 0

Arch Linux in May 2024
by Levente Polyak 18 Sep '24

18 Sep '24

## Staff We would like to welcome [Bert Peters][0] (bertptrs) as well as [Giovanni Harting][1] (anonfunc) as part of the Arch Linux Package Maintainer team. ## RFC An [RFC has been accepted][2] to introduce "Arch Linux Ports" as testbed for unofficial architectures until they are integrated in the main Arch Linux repositories. ## devtools We have released [devtools v1.2.0][3], featuring several new enhancements and improvements. This release includes distro flag changes, notably the addition of `no-omit-frame-pointer` flags and `_FORTIFY_SOURCE` level 3. A new `pkgctl version setup` command has been implemented to automatically detect and configure nvchecker. We also added `pkgctl repo clean` which allows for the removal of untracked files. `arch-nspawn` now supports Pacman `CacheServer`, and offload building fetches logs from the remote server, making debugging easier for packagers. Additionally, `pkgctl release` now ensures split package uploads are released as a single batch, fixing a race condition when releasing in parallel. ## mkinitcpio We have released [mkinitcpio v39][4], featuring various improvements and fixes. The use of global variables for retrieving cmdline parameters is now deprecated, and hook authors should update their hooks to use the getarg function. This release also adds support for ARM zImage and introduces a new `acpi_override` hook for ACPI table upgrades and overrides. Additionally, `lsinitcpio` now supports listing, analyzing, and extracting UKIs. ## AurWeb We have released [AurWeb v6.2.10][5], which includes several improvements such as adding a maximum limit for comment length. Additionally, all application dependencies have been updated, and leftover mentions of `[community]` have been replaced with `[extra]`. ## ArchISO We have released [ArchISO v78][6], which includes several improvements and bug fixes. Notable changes include fixing the check for microcode update files in initramfs images and formatting the EFI system partition as FAT32 with a reduced size of 36 MiB, down from 512 MiB. ## Infrastructure We have added GitLab packages for pacman at [pacman.archlinux.page][7], which now serves as the new homepage for our package manager. ## ArchWeb We have released [ArchWeb 2024-05-02][9], featuring minor HTML fixes and an updated bootstrap tarball extension to align with ArchISO v77's switch from gzip to zstd compression. Additionally, this release includes compatibility dependency updates for Python 3.12. ## Gluebuddy [Gluebuddy v0.6.2][8], our infrastructure automation tool, now allows external contributors to remain part of our GitLab group without being automatically offboarded. ## Packaging ### Statistics In this month, we’ve successfully rolled out 5383 package updates addressing various enhancements and rebuilds, including 2604 package upgrades. Additionally, we’ve received 285 new package issues, while resolving a total of 323 issues. [0]: https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/t… [1]:https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.or… [2]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/32 [3]: https://gitlab.archlinux.org/archlinux/devtools/-/releases/v1.2.0 [4]: https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/releases/v39 [5]: https://gitlab.archlinux.org/archlinux/aurweb/-/tags/v6.2.10 [6]: https://gitlab.archlinux.org/archlinux/archiso/-/tags/v78 [7]: https://pacman.archlinux.page/ [8]: https://gitlab.archlinux.org/archlinux/gluebuddy/-/releases/v0.6.2 [9]: https://github.com/archlinux/archweb/releases/tag/release_2024-05-11

1 0

Arch Linux in April 2024
by Levente Polyak 18 Sep '24

18 Sep '24

## Staff ### Project Leader Election Recently, we held our [Arch Linux Project Leader][0] election, and the current Project Leader, Levente "anthraxx" Polyák, was the sole nominee. As per our election rules, he has been re-elected for another term. Congratulations to Levente, and we wish him continued success in his leadership! ## RFC An [RFC has been accepted][1] to grant all Arch Linux staff members, not limited to those in packaging roles, the privilege to initiate RFCs directly, aligning with the broad range of topics these documents encompass. ## archinstall [Archinstall v2.8.0][2] has been released, bringing various fixes and improvements, including enhancements in microcode handling, partitioning, and an increase in ESP size to 1 GiB. ## ArchISO We have released [ArchISO v77][3], which adds a Memtest86+ boot entry for systemd-boot. Additionally, this version now uses mkinitcpio's microcode hook instead of external microcode images and switches the UEFI boot loader from GRUB to systemd-boot. ## ArchWeb We have released [ArchWeb 2024-04-28][4], introducing the ability for packagers to easily add notes to Todo lists via our HedgeDoc instance. Additionally, references to external microcode images have been removed, as ArchISO v77 now includes microcode within the single initramfs. ## Packaging ### Python We have successfully bootstrapped Python 3.12 and rebuilt all relevant packages including collaborative effort to make packages ready for the new interpreter version. Python 3.12.3 is now available in the official repositories. ### Statistics In this month, we’ve successfully rolled out 7186 package updates addressing various enhancements and rebuilds, including 2335 package upgrades. Additionally, we’ve received 282 new package issues, while resolving a total of 265 issues. [0]: https://wiki.archlinux.org/title/DeveloperWiki:Project_Leader [1]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/31 [2]: https://github.com/archlinux/archinstall/releases/tag/v2.8.0 [3]: https://gitlab.archlinux.org/archlinux/archiso/-/tags/v77 [4]: https://github.com/archlinux/archweb/releases/tag/release_2024-04-28

1 0

Arch Linux in March 2024
by Levente Polyak 18 Sep '24

18 Sep '24

## Staff We would like to welcome [Carl Smedstad][0] as part of the Arch Linux Package Maintainer team. Furthermore, we would like to welcome svartkanin as Support Staff for the archinstall project, assisting with issue tracking and handling of merge requests. ### Project Leader Election The 2024 [Arch Linux Project Leader][1] election process has started, with the nomination period now officially open for candidate submissions. ## RFC A previously proposed [RFC has been accepted][2] to create a dedicated role for the moderation of the AUR that supports and eventually replaces the Package Maintainers as the current moderators. An [RFC has been proposed][3] to introduce "Arch Linux Ports" as testbed for unofficial architectures until they are integrated in the main Arch Linux repositories. An [RFC has been proposed][4] to grant all Arch Linux staff members, not limited to those in packaging roles, the privilege to initiate RFCs directly, aligning with the broad range of topics these documents encompass. ## mkinitcpio [mkinitcpio v38.1 has been released][5] as a bugfix update, addressing various regressions. Additionally, the encrypt and sd-encrypt hooks now always include the hid-generic module, which is required for FIDO tokens. ## Pacman [Pacman 6.1.0][6] introduces several key features and improvements. Cache server support has been added, allowing cache servers to be tried before non-cache servers, though they won't be used for database files. The update also replaces libdepends and libprovides with autodeps, enabling automatic addition of libraries to the depends and provides arrays. Additionally, a new `verify()` function has been implemented for custom source verification, allowing for the use of verification schemes not natively supported by makepkg. Lastly, checksum support for git, mercurial, and bzr sources has been added, enabling packagers to use simple refnames in the `PKGBUILD` while ensuring the security of immutable build inputs. ## ArchWeb The ArchWeb 2024-03-05 release includes several small changes, like ISO downloads are now linked exclusively via HTTPS mirrors, improving user security in certain scenarios. Additionally, the ability to add blogs to "ArchWeb Planet" has been restricted to official Arch Linux staff only. ## archinstall We have released [archinstall v2.7.2][7], featuring several improvements and fixes, including enhancements related to Unified Kernel Images (UKIs). ## Infrastructure We have made the "Geo Mirrors" dashboard and metrics [publicly available][8]. This offers valuable insights for mirror administrators and mirror owners, allowing them to monitor performance and distribution more effectively. ## Packaging ### Spring Cleanup We successfully completed our [annual spring cleanup][9], adopting orphaned packages and removing obsolete or unmaintained ones from the official repositories. This effort led to a significant reduction of abandoned packages, keeping our repositories well-maintained and relevant. ### Statistics In this month, we’ve successfully rolled out 7777 package updates addressing various enhancements and rebuilds, including 2684 package upgrades. Additionally, we’ve received 306 new package issues, while resolving a total of 303 issues. [0]: https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/t… [1]: https://wiki.archlinux.org/title/DeveloperWiki:Project_Leader [2]: https://rfc.archlinux.page/0019-aur-moderator-role/ [3]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/32 [4]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/31 [5]: https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/releases/v38… [6]: https://gitlab.archlinux.org/pacman/pacman/-/releases/v6.1.0 [7]: https://github.com/archlinux/archinstall/releases/tag/v2.7.2 [8]: https://dashboards.archlinux.org/d/EWz2Faunz/geo-mirrors [9]: https://lists.archlinux.org/hyperkitty/list/arch-dev-public@lists.archlinux…

1 0

Arch Linux in February 2024
by Levente Polyak 18 Sep '24

18 Sep '24

## Staff We would like to welcome Vincent Dahmen (wahrwolf) as Arch Linux Support Staff with their new role as Mirror Admin. On top we would like to welcome [andreymal and codingkoopa][0] to their new role as ArchWiki Maintainers. Additionally, we would like to congratulate Christian Heusel (gromit) on his promotion to a full DevOps member. ## Testing Team In early February, we issued a [call for participation][1] about joining the [Arch Testing Team][2] which was also shared on the [Forum][3], [Mastodon][4], [Reddit][5] and IRC. The response was overwhelmingly positive, with over 60 new testing accounts created, significantly extending our capacity for more reliable package update testing! For those who haven't joined yet, there's still time! 😉 ## ArchISO For the first time in history, the official Arch ISO [does not fit in a CD][6] as it now exceeds even the largest 900 MiB capacity CDs. Those few still using the coaster form factor instead of USB flash drives will need to switch to a DVD for burning the ISO. ## devtools We released [devtools 1.1.0][7], a major update packed with bug fixes, improvements, and new workflow commands. Notable additions include the `pkgctl version` subcommand, which uses nvchecker to check and apply newer upstream versions, the `pkgctl search` subcommand to search expressions across the entire packaging group, and the `pkgctl aur` subcommand to assist in transitioning packages from official repos to the AUR. Additionally, `makechrootpkg` now allows users to drop into a debug shell for inspecting failed builds within the chroot. All packaging repo clones also come with a default excludes file to ignore common artifacts. Further changes are listed in the [changelog][7]. ## mkinitcpio The latest [mkinitcpio release v38][8] introduces key changes, including the deprecation of `--microcode` option in favor of a new microcode hook for early microcode loading. mkinitcpio now supports creating an early CPIO image, with the `microcode` hook handling the integration of early microcode into this image. ## ArchWiki To enhance readability, [the color of visited links has been updated][9] from gray to the MediaWiki default purple. In addition to [welcoming CodingKoopa and Andreymal][0] to their new roles as ArchWiki Maintainers, we are also excited to [welcome Dybdeskarphet][0], who joins as a new Translator. ## RFC An [RFC has been accepted][10] to add `-fno-omit-frame-pointer` and `-mno-omit-leaf-frame-pointer` to the default compilation flags to improve the effectiveness of profiling and debugging tools. ## Packaging ### ghc We have successfully rolled out GHC 9.2 after resolving all outstanding issues, marking another step toward the latest GHC. ### Plasma 6 Plasma 6, KDE Frameworks 6 and KDE Applications 24.02 (mostly ported to Qt6) are now available in the repositories. ### Statistics In this month, we’ve successfully rolled out 8196 package updates addressing various enhancements and rebuilds, including 2612 package upgrades. Additionally, we’ve received 168 new package issues, while resolving a total of 216 issues. [0]: https://wiki.archlinux.org/title/ArchWiki:News#2024/02/29_-_New_maintainers… [1]: https://lists.archlinux.org/hyperkitty/list/arch-general@lists.archlinux.or… [2]: https://wiki.archlinux.org/title/Arch_Testing_Team [3]: https://bbs.archlinux.org/viewtopic.php?id=293464 [4]: https://fosstodon.org/@archlinux/111907965691846810 [5]: https://www.reddit.com/r/archlinux/comments/1aniloc/join_the_arch_testing_t… [6]: https://gitlab.archlinux.org/archlinux/archiso/-/issues/144 [7]: https://gitlab.archlinux.org/archlinux/devtools/-/releases/v1.1.0 [8]: https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/releases/v38 [9]: https://wiki.archlinux.org/title/Special:Permalink/800562#Visited_links_are… [10]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/26

1 0

Enabling split debug for kernels?
by Jan Alexander Steffens (heftig) 14 Sep '24

14 Sep '24

Hi list, As of Pacman 7.0.0, we can have makepkg create debug packages for our kernels, however... Compressed modules are not scanned, meaning either we continue to use INSTALL_MOD_STRIP=1 (throwing away debuginfo for all modules), we disable compression, or we have to enhance makepkg further. For reference, without module compression, the package size of linux drops from 135 MiB to 98 MiB and its installed size rises from 135 MiB to 562 MiB. Debian has been compressing their kernel modules since last year. Instead of splitting debuginfo, they install unstripped modules into /usr/lib/debug/: https://salsa.debian.org/kernel-team/linux/-/commit/e8b64e4b4318aaaf7222f47… Fedora & RHEL do not compress kernel modules, for the same reason of incompatibility with split debuginfo: https://bugzilla.redhat.com/show_bug.cgi?id=1349651 In addition, with compression disabled, the split debuginfo step of packaging linux takes 1½ hours on our build server, which is less than optimal. From what I can tell, that time is spent in the # create any needed hardlinks loop, causing runtime to explode quadratically (amount of stripped files × amount of files in the package). When the kernel is built with module compression, it also adds support for decompressing modules with the selected compression without help from kmod. This seems to be needed in some edge cases, so reënabling compression wouldn't be as easy as adding a module compression stage to makepkg. Debian ran into problems when they missed enabling this support: https://salsa.debian.org/kernel-team/linux/-/merge_requests/980 The issue tracking split debug is at https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/issues/2 The MR to test split debug is at https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/merge_req… It would be nice to have full debuginfo available. Greetings, Jan

1 0

News draft: Manual intervention for pacman 7.0.0 and local repositories required
by gromit 13 Sep '24

13 Sep '24

Hello everyone, with the move of pacman version 7.0.0 a few changes might require manual intervention from end users, which shall be described in the following news item! If you have feedback to it feel free to reply directly! ------ # Manual intervention for pacman 7.0.0 and local repositories required With the release of [version 7.0.0][0] pacman has added support for downloading packages as a separate user with dropped privileges, which we deem a good default for our distribution. For users with local repos however this might imply that the download user does not have access to the files in question, which can be fixed by assigning the files and folder to the "alpm" group. $ chown $USER:alpm -R /path/to/local/repo This is of course only relevant after you have successfully [merged the .pacnew][1] files. Pacman also introduced [a change][2] to improve checksum stability for git repos that utilize .gitattributes files. This might require a one-time checksum change for PKGBUILDs that use git sources. [0]: https://gitlab.archlinux.org/pacman/pacman/-/blob/master/NEWS?ref_type=heads [1]: https://wiki.archlinux.org/title/Pacman/Pacnew_and_Pacsave [2]: https://gitlab.archlinux.org/pacman/pacman/-/commit/9548d6cc765b1a8dcf933e8…

2 1

Replacing mlocate with plocate
by Morten Linderud 10 Sep '24

10 Sep '24

Yo! I'm going to drop `mlocate` from the repositories and provide `plocate` as the default locate in Arch Linux. mlocate is very much an abandoned project, while plocate is a modern implementation with a faster database implementation along with io_uring support. https://plocate.sesse.net/ The question is if people feel a strong desire to keep a locate implementation in `[core]` or if we are fine with this living inside `[extra]`. Adding `plocate` to `[core]` would mean we would need to move a `liburing` to `[core]` and I don't really know if we need that. Any opinions? -- Morten Linderud PGP: 9C02FF419FECBE16

4 4

Arch Linux public upload server
by Orhun Parmaksiz 03 Sep '24

03 Sep '24

Hey all! As some of you might already know, I maintain an upload server project called `rustypaste`: https://archlinux.org/packages/extra/x86_64/rustypaste/ I’ve been using it daily for a couple of years now and have been quite happy with it. I used to provide a public instance for free use, but due to some issues with the provider, I had to shut it down: https://github.com/orhun/rustypaste/issues/326 The other day, I started wondering why Arch Linux shouldn't support a similar public service, like https://paste.ubuntu.com, but powered by rustypaste. I believe we could configure rustypaste to allow public uploads with a retention period and necessary security measures in place. I was going to bring this up with the DevOps team, but I thought it might be better to get general opinions on the matter first. 🐻 Cheers, Orhun

5 5

ell 0.68-1 pulled from testing
by Andreas Radke 28 Aug '24

28 Aug '24

I have pulled ell 0.68-1 from testing because it breaks current iwd in extra and the new iwd release has not happened yet. Please downgrade to the ell version in extra repository. -Andy

1 0

Ruby 3.2.4
by Andreas 'Segaja' Schleifer 09 Aug '24

09 Aug '24

Hello, after a lot of work and some wrong avenues we are finally ready to update Ruby in Arch Linux to version 3.2.4. For this we will block staging from tomorrow (09.05.2024) on to do the rebuild, and it might take some time to complete. At the same time we also replace the approach of providing an /etc/gemrc with the more up-to-date approach of providing an operating_system.rb for ruby to rely on. This should solve several issues currently open for the ruby and the rubygems package. We know that Ruby 3.2.4 isn’t the latest version but we decided to do this one and maybe in a couple of months update to ruby 3.3.x once we are sure it is ready. During the update we will also drop some ruby default gem packages which are not needed anymore as we will not de-vendor all ruby defaultgems in the future. There might arise some dependency issues but we will have to face them when we see them. Best regards Segaja

1 3

RFC Final Comment Period: Distribution Developer Manual
by Levente Polyak 09 Aug '24

09 Aug '24

An RFC has now entered its 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/21 Please visit the above link for discussion. Summary: This RFC proposes the migration of Arch Linux's operational distro specifications from existing ArchWiki and other sources to a dedicated GitLab developer manual repository. The intention is to document how to run the distribution while leveraging GitLab's collaboration features and streamlined workflows for maintaining and evolving the resulting specifications. This change aims to centralize and enhance the efficiency of specification management while preserving the integrity of the community-contributed contentin the Wiki. This request for comments is superseding RFC-0005 by extending its scope to handle all distro specifications coherently instead of handling a single sub section (packaging guidelines) differently to others.

1 0

RFC: License Package Sources
by Sven-Hendrik Haase 07 Aug '24

07 Aug '24

A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/40 Please visit the above link for discussion. Summary: Our package sources currently do not have explicit licenses. This RFC proposes to license all Arch Linux package sources under the terms of the Zero-Clause BSD license.

1 0

Away until 2024-08-12
by David Runge 30 Jul '24

30 Jul '24

Hi all, I'll be on holidays from tomorrow until 2024-08-12 and only sporadically read mails etc. Please feel free to bump/move packages I maintain. Have a good summer! :) Best, David -- https://sleepmap.de

1 0

Resignation
by Florian Pritz 28 Jul '24

28 Jul '24

Hi, Sadly I have no longer had the time necessary to properly handle master key holder and packager duties for a while now. I don't feel like it's fair to you guys and our users to keep this up any longer so I'm officially resigning now. Most pressing topics that come to mind for someone wanting to take over: * I hold a master key, so you'll need to find a new holder for that * perl 5.40 update * various bug reports on Gitlab for my packages * a few flagged packages Thanks for all the nice memories since "[2008-10-19 14:38] installed filesystem (2008.03-2)". While I will no longer be involved in Arch development, I'll still continue to use it and this nice, old install will also continue to live on. Hope to see you guys around :) Florian

5 4

libassuan 3.0.1-1 pulled from testing after crashing pacman
by David Runge 22 Jul '24

22 Jul '24

Hi all, please note that I have just pulled libassuan 3.0.1-1 from core-testing. In this patch-level release some major issues emerged, that break pacman: ``` pacman -Ss test pacman: /usr/lib/libassuan.so.9: version `LIBASSUAN_1.0' not found (required by /usr/lib/libgpgme.so.11) ``` Please note that if you have libassuan 3.0.1-1 installed, you may have to use an installation media or static pacman to get back to 3.0.0-1. I'm very sorry to have caused any inconvenience over this. I will contact upstream about this momentarily. Best, David -- https://sleepmap.de

1 0

Fwd: [PATCH v6] kbuild: add script and target to generate pacman package
by Jan Alexander Steffens (heftig) 16 Jul '24

16 Jul '24

Hi, recently there's been an effort to add a `pacman-pkg` target to the Linux kernel build system, which uses a PKGBUILD to build `linux-upstream` packages for Arch Linux. Since this is of interest to us, I'm forwarding the latest patch email to our list here to give you a chance to provide feedback to the author. I can see this making bisection of kernel issues (or just testing patches) much easier, especially for users. It's also quite an unusual way of calling makepkg. The email is also available at [lore.kernel.org](https://lore.kernel.org/linux-kbuild/20240716-kbuild-pacma…. Greetings, Jan PS: My apologies for sending this twice; the first email was sent with "Markdown" formatting in Evolution, which didn't quite do what I think it would. This one uses "Markdown as HTML", which should have both `text/plain` and `text/html` variants.

1 0

Fwd: [PATCH v6] kbuild: add script and target to generate pacman package
by Jan Alexander Steffens (heftig) 16 Jul '24

16 Jul '24

1 0

AUR Maintenance Saturday 13 July 12:00 UTC
by Jelle van der Waa 13 Jul '24

13 Jul '24

Hi all, We are having some performance issues with the AUR's git repository which requires some maintenance. [1] This means that the AUR will be unavailable for some time starting 12:00 UTC till it is done (hopefully 2 hours, could be more). [1] https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/599

2 1

Urgent news draft: The sshd service needs to be restarted after upgrading to openssh-9.8p1
by Robin Candau 01 Jul '24

01 Jul '24

Hi everyone, As you might have heard by now (or experienced it already), the latest openssh-9.8p1 release requires the sshd daemon to be restarted otherwise new connections cannot establish (the one used to upgrade the package remains intact though). To prevent people from eventually blocking themselves out any further, we would like to introduce a `post_upgrade` transaction for the openssh-9.8p1 package which will restart the sshd service (a MR for that is being worked on [1]), accompanied by an urgent news entry (similarly to what was done for the openssh-8.2p1 release) [2]. Given the urgent aspect of the news, it would be nice to have some quick feedback if possible. I intend to post the news as soon as openssh-9.8p1-2 is released with the `post_upgrade` transaction. --------------- News draft: # The sshd service needs to be restarted after upgrading to openssh-9.8p1 After upgrading to openssh-9.8p1, the existing SSH daemon will be unable to accept new connections. (See https://gitlab.archlinux.org/archlinux/packaging/packages/openssh/-/issues/5) When upgrading remote hosts, please make sure to restart the SSH daemon using `systemctl restart sshd` right after upgrading. If you are upgrading to openssh-9.8p1-2 or higher, this restart will happen automatically. --------------- [1] https://gitlab.archlinux.org/archlinux/packaging/packages/openssh/-/issues/… [2] https://archlinux.org/news/sshd-needs-restarting-after-upgrading-to-openssh… -- Regards, Robin Candau / Antiz

2 2

Taking a break soon
by Orhun Parmaksiz 26 Jun '24

26 Jun '24

Hey! I will be taking a break from computers between the dates 29-06-2024 and 26-07-2024. During this period I won't have access to the internet so I will be pretty much unreachable. But if there is something hella urgent drop me a call on my cell - I might or might not call back. Let me know if there is anything (in the following days) and feel free to bump my packages. P.S. everything is fine, just need some time to reset :) Have a nice summer everyone!

2 1

glib2-devel split from glib2
by Jan Alexander Steffens (heftig) 11 Jun '24

11 Jun '24

Hi, Thanks to Fabian, as of 2.80.3-1, the development utilities requiring additional dependencies (*python*, *python-packaging*, *libelf*) have been split from *glib2* into *glib2-devel* with proper depends. You may need to add *glib2-devel* to the makedepends of your packages to get them to build again. At the same time, consider removing *python* or *python-packaging* from the makedepends if they were only added to run gdbus-codegen, glib-genmarshal or glib-mkenums. Greetings, Jan

1 0

pre-releases (for systemd & co) in core-testing
by Christian Hesse 08 Jun '24

08 Jun '24

Hello everybody, I used to push later pre-releases for essential core packages (for example systemd and util-linux) to core-testing. The idea was to have some extra testing even before building the final packages. For some time this worked quite well... Lately this broke, though. Our current tooling (pkgctl from devtools) builds packages (at least core ones) in core-testing. We then moved a package that was built with util-linux 2.40rc2. It's dynamic linking was ok, but it required the symbol MOUNT_2_40 from libmount.so, still breaking. We had to move the util-linux pre-release packages to core to solve this. Of course this had not been detected before, because packages in testing were ok in that combination. So wondering how to solve this, and have some extra testing anyway. The more people testing pre-release packages the better... Having said that - I have set up a custom repository for now with systemd 256rc2. To test that add these lines to your pacman.conf: [testing] Server = https://pkgbuild.com/~eworm/$repo/$arch/ Feedback welcome! -- 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);}

4 7

Adding Emil Velikov as maintainer of libudev0-shim
by Morten Linderud 05 Jun '24

05 Jun '24

Yo, `libudev0-shim` is a udev compat shim that some of our packages, most notably stream, and a few other downstreams utilize. It was written 8 years ago by Dave Reisner and has seen no development since then, but Valve/Steam has sent a couple of changes to this project. I originally asked on IRC if anyone wanted to maintain this, but after no response Emil replied on a PR that he would gladly take over maintainership of this project. Emil has been around for a few years on bugreports and misc patches to upstream projects, and generally is a nice guy. I can't see anyone objecting to this so I've asked devops to add them to the Github repository. This emailserves as a headsup that Emil is now the maintainer of the project. https://github.com/archlinux/libudev0-shim -- Morten Linderud PGP: 9C02FF419FECBE16

1 0

Stepping down
by Maxim Baz 27 May '24

27 May '24

Hi everyone Life got busier than ever, and I find myself unable to give nearly as much attention to packaging that it deserves. As such, I believe the most respectful course of action would be for me to step down as package maintainer now, and re-apply in the future if this makes sense. There's no immediate action needed for any of my packages, I have updated them all today. But here's the list of packages where I'm the sole maintainer, it would be awesome if some of them would earn your interest to adopt them: aspell-da browserpass browserpass-chromium browserpass-firefox curlie gocryptfs goimapnotify grub-btrfs kitty libu2f-server pam-u2f python-black python-i3ipc rebuild-detector swappy ttf-joypixels wire-desktop wldash yubikey-touch-detector Best wishes Maxim Baz

6 5

Cleaning up some of my packages
by Filipe Laíns 24 May '24

24 May '24

Hi everyone, A while ago I wrote to the staff mailing list about my lack of activity. Thankfully, I think I am finally now slowly getting back up to speed with life and my open source commitments. If someone wants more details, I wrote a bigger explanation on [1] (tw: mental health). To help with this, I think I should do some cleaning up of my packages, I have disowned a bunch of them. Several of them, such as the Deepin, Budgie, and D packages, had a co-maintainer, so they should be alright. The ones that didn't are listed below. I tried to list the maintainers of the dependents to make it easier to identify. Packages with dependents: pyannotate (check dependency for python-py7zr, cc Caleb) python-dill (dependency for python-pylint, cc Caleb) python-future (dependency for a bunch of Felix's packages, and more) python-multipart (dependency for python-moto, cc Chih-Hsuan) python-py (dependency for python-pytest-forked, cc Felix) python-pypng (dependency for python-qrcode, cc Felix, Levente, Caleb) python-zc.lockfile (dependency for python-cherrypy and python-pytest-services, cc Thore and David) (check/optional dependencis for python-fastapi) python-aiomysql python-aiopg python-aiosqlite (also hard dependency for python-ypy-websocket, cc Antonio) python-asyncpg (also hard dependency for nominatim, cc Justin) python-databases D ecosystem packages without dependents: adrdox d-containers d-mir-core d-stdx-allocator gir-to-d glibd mustache-d General packages without dependents: bluefish budgie-extras dbxtool (deprecated — archived on Github, and replaced by fwupd) flterm fusesoc grub-theme-vimix log4cpp netcf pulseaudio-equalizer-ladspa python-biopython python-bitcoinlib python-edalize python-euclid3 python-ipyxact python-litevideo python-litedram python-liteeth python-liteiclink python-litejesd204b python-litepcie python-litesata python-litescope python-litesdcard python-litevideo python-litex python-litex-boards python-livereload python-kikit python-markdown2 python-migen python-occ-core python-okonomiyaki python-pybars3 python-pymeta3 python-pypubsub python-pyvcd python-simplesat python-solidpython python-sphinx-typlog-theme python-svgwrite python-watchgod thefuck This lists includes flatenned dependency trees, so if you adopt any of the packages listed as without dependents, please be keep in mind they might depend on other packages on the list. You might want to pick up those too. [1] https://ffy00.github.io/blog/03-state-of-things-2024-04/ Cheers, Filipe Laíns

1 0

Re: pre-releases (for systemd & co) in core-testing
by Christian Hesse 23 May '24

23 May '24

Genes Lists <lists(a)sapience.com> on Thu, 2024/05/23 06:27: > On Thu, 2024-05-23 at 09:16 +0200, Christian Hesse wrote: > > Christian Hesse <list(a)eworm.de> on Wed, 2024/05/15 11:08: > > > .. > > > Feedback welcome! > > > > Pushed systemd 256rc3-1 last night. All the same applies... > > Please keep testing! > > Hi Christian > > For feedback do you plan to make this visible in the package > signoffs page [1] or do you want a quick email with ack/nack? > > For now: > > mkinitcpio-39.1-1.1 - all good > systemd-256rc3-1 - all good > > gene > > [1] https://archlinux.org/packages/signoffs/ Good point! I would have to push to core-testing repository for the packages to be visible for signoffs. That's what I tend to avoid now with pre-releases. So short notice via mail or messaging is fine. Thanks! -- 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 0

Re: pre-releases (for systemd & co) in core-testing
by Christian Hesse 15 May '24

15 May '24

Randy DuCharme <radio.ad5gb(a)gmail.com> on Wed, 2024/05/15 05:06: > Suggestion (s). This is open source real life comes first, always. > > People that volunteer to help are genuinely real but being ignored wins > ZERO.... even if they have 27 years of C C++ No idea what you want to tell me... Really. Please try again if this is a serious suggestion related to the topic. -- 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 0

Mesa pulled from testing
by Jan Alexander Steffens (heftig) 08 May '24

08 May '24

I've removed Mesa 1:24.0.7-1 from testing as the radeonsi driver crashes immediately, somewhere deep in LLVM. This concerns the following packages: • libva-mesa-driver • mesa • mesa-vdpau • opencl-clover-mesa • opencl-rusticl-mesa • vulkan-intel • vulkan-mesa-layers • vulkan-nouveau • vulkan-radeon • vulkan-swrast • vulkan-virtio • lib32-libva-mesa-driver • lib32-mesa • lib32-mesa-vdpau • lib32-opencl-clover-mesa • lib32-opencl-rusticl-mesa • lib32-vulkan-intel • lib32-vulkan-mesa-layers • lib32-vulkan-nouveau • lib32-vulkan-radeon • lib32-vulkan-swrast • lib32-vulkan-virtio

1 0

Orphaning some packages
by Chih-Hsuan Yen 04 May '24

04 May '24

Hi all, I'm going to orphan some packages that I no longer need or depend on, so that I can better focus on my other packages. Here is the package list: * fcitx-chewing * nextcloud-client * python-nbdime * python-nbval * python-openpyxl * python-pg8000 * python-prctl * python-scramp * python-sure * python-testing.postgresql (may be dropped - depends on python-nose, no upstream commits since 2017) * scim-chewing * web-ext Please adopt packages you need, thanks! Best Regards, Chih-Hsuan Yen (yan12125)

1 0

time64 ABI fix coming to upstream glibc
by Florian Weimer 02 May '24

02 May '24

The <utmp.h> and <utmp.h> headers had a bug that the on-disk structures defined there could change size on some targets when _TIME_BITS was set to 64. This is obviously wrong because the files are not going to magically change their layout because the application accessing them was built in a specific way. We're going to fix this in glibc upstream on the stable release branches, going all the way back to glibc 3.34 (the first release with this kind of time64 support). After the fix, the _TIME_BITS definition will no longer impact struct layout. Usually, that means epoch fields are 32-bits wide, to match co-installable architectures. To extend the usable life-time of these interfaces somewhat, glibc 2.40 changes epoch fields to unsigned types in these structures. This change is specific to the upcoming glibc 2.40 release, I do not plan to backport it. Thanks, Florian

1 0

Archweb ToDo Notes
by Jelle van der Waa 28 Apr '24

28 Apr '24

Hi all, Archweb ToDo's now have a link called "Todo Notes" this links to an md.archlinux.org pad based on the todo slug (prefixed with archweb) to avoid conflicts. Hopefully this helps collaboration on todo's which are a bit more complicated or require additional information. So for example for: https://archlinux.org/todo/drop-python-exceptiongroup/ There is now automatically: https://md.archlinux.org/archweb-drop-python-exceptiongroup Hopefully this helps with sharing why something is not rebuild/finished in a todo with links to issues. Archweb cannot detect if soemone has written to the pad, so maybe the body should have a *note* about it :-) Greetings, Jelle

1 0

Python 3.13 specific packaging issues
by Jelle van der Waa 27 Apr '24

27 Apr '24

Hi all, We are almost ready to drop Python 3.12 in testing, hopefully tensorflow can be pursued-ed to recompile against [staging] soon. This Python release dropped the `imp` module, but the next release (3.13) which is slated for October this year will drop more Python batteries, some methods and some unittest invocations. [1] I already scanned a part of the Python packages and the mailcap and cgi deprecation will be a bit painful. (And logger.warn usage but that is easy to patch to logger.warning) I want to propose to open issues per package for Python 3.13 compatibility, it would point out what is not compatible and ideally link to an upstream issue or let the package maintainer create this issue. Once we are ready to start thinking about a Python 3.13 rebuild we can go through the list of issues with a `python-3.13` label. [2] Finding issues now will hopefully: a) convince packages we maintain to get a new release b) a happier rebuild c) find packages which are issues and should likely not be maintained in the repos There is one caveat, the changelog is draft. I am not sure if Python has a history of reverting breaking changes in an alpha release. But as far as I know these things have been deprecated for quite a while. We have a history of not opening upstream issues in our packaging repository, but I think for this scenario it would make sense and actually help us deliver Python sooner in the repos. [1] https://docs.python.org/3.13/whatsnew/3.13.html [2] https://gitlab.archlinux.org/groups/archlinux/packaging/packages/-/issues Greetings, Jelle van der Waa

4 6

RFC Final Comment Period: Arch Linux Ports
by David Runge 25 Apr '24

25 Apr '24

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/32 Please visit the above link for discussion. Summary: Introduce "Arch Linux Ports" as testbed for unofficial architectures until they are integrated in the main Arch Linux repositories. This integration is meant to provide infrastructure and community-based support for architectures until they are fully supported by the main distribution.

1 0

Python 3.12
by Jelle van der Waa 21 Apr '24

21 Apr '24

Hi all, We should get started on Python 3.12, 3.13 alpha is already getting released! To be 100% honest, I am not super looking forward to it as it's a ton of work due to our lack of automated tooling. In basics a plan would be to first tackle low hanging fruit to-do's: * https://archlinux.org/todo/pytest-runner-removal/ * https://archlinux.org/todo/imp-module-removal-in-python-312/ * https://archlinux.org/todo/use-pyprojecttoml-for-building-if-supported/ * drop unused python modules in our repo https://archlinux.org/devel/reports/unneeded-orphans/ We've finished python-bootstrap, and can bootstrap the required build packages (python-setuptools, build, etc.). And figuring out the rebuild order. (Big thanks to david, for the help here!) [1] [2] So soon we can start the rebuild which will probably take a while to complete as we have no good automated tooling yet for mass rebuilds. This rebuild will likely block [staging] for a good 2 or more weeks, so when would be a good time to schedule this? I expect two things to break our package builds in 3.12: * The removal of distutils see the snippet below, adding python-setuptools to makedepends should resolve this. For example: GISCAN ZBar-1.0.gir Traceback (most recent call last): File "/usr/bin/g-ir-scanner", line 99, in <module> from giscanner.utils import dll_dirs File "/usr/lib/gobject-introspection/giscanner/utils.py", line 385, in <module> import distutils.cygwinccompiler ModuleNotFoundError: No module named 'distutils' * The removal of the imp module, the todo list above has been open for a while, but not all packages have been fixed. * The usual failing tests, missing sources you know it :) [1] https://gitlab.archlinux.org/archlinux/python-bootstrap/-/merge_requests/3 [2] https://notes.vdwaa.nl/arch/python.html Greetings, Jelle

2 6

News draft: Arch Linux Leader Election Results
by gromit 12 Apr '24

12 Apr '24

Hello everyone, a few people have asked for the election results to be published as a News announcement. If you have any feedback regarding the draft below feel free to send it as a response or ping me on IRC. I will post the announcement at the beginning of next week. ^_^ Cheers, gromit === Recently we held our leader election, and the previous Project Leader Levente "anthraxx" Polyák ran again while no other people were nominated for the role. As per [our election rules](https://wiki.archlinux.org/title/DeveloperWiki:Project_Leader#Electi… he is re-elected for a new term. The role of of the project lead within Arch Linux is connected to [a few responsibilities](https://wiki.archlinux.org/title/DeveloperWiki:Project_Le… regarding decision making (when no consensus can be reached), handling financial matters with SPI and overall project management tasks. **Congratulations to Levente and all the best wishes for another successful term!** ===

1 0

Re: Arch Linux Rust packaging licensing problem
by Jan Alexander Steffens (heftig) 07 Apr '24

07 Apr '24

On Sat, Apr 6, 2024 at 10:42 PM Arvid Norlander <arvid(a)vorpal.se> wrote: > Hi, > > After talking to people on Arch Linux IRC channels (mpan in particular) > about this, they recommended I contact you directly about this, since it > affects many packages (so filing a bug on any specific package wasn't > really > appropriate). > > Arch only packages the final binary crates for Rust (as opposed to separate > packages for every single Rust dependency, which would rightfully drive > people crazy). As a result, you only get one single package that contains > many libraries. > > Lets take an example: ripgrep, which links to ~53 dependencies (maybe less, > not all dependencies are used on all platforms, etc). Many of these > dependencies use MIT license or similar that requires: > > > The above copyright notice and this permission notice shall be included > in > > all copies or substantial portions of the Software. > > Looking in /usr/share/licenses/ripgrep I only see the copyright notice > for ripgrep itself. This is a bit of a problem. > > Similarly, one of it's dependencies is unicode-ident which uses > "Unicode-DFS-2016" as it's license. That is missing. encoding_rs is > "(Apache-2.0 OR MIT) AND BSD-3-Clause" (which may collapse down to MIT, not > sure, I am not a lawyer). > > So I can see two problems here: > > 1. Copyright notices that need to be included for dependencies, aren't. > 2. The SPDX expression may be incorrect (missing some things from > dependencies that should be included). > > Looking at some other packages (not just ripgrep) I see similar issues > across all of those packages. > > Now, for something like rust it would be impossible to require the > maintainers to handle this by hand. So lets talk solutions. > > * There is cargo-about (already packaged in Arch, also has suspect > license/copyright info). It doesn't do quite what you want: Given a > config and a handlebar template it will generate an HTML page with all > the licenses you use. It will collapse "OR" in the license info based on > a priority list of which licenses you prefer. > > You could perhaps wrangle the handlebar template to generate a text > file instead of a HTML file, not sure. It can also output a JSON file > instead though (I have used that at my dayjob for license compliance). > > While it is a good solution, it is not a drop-in solution without > additional scripting on top (and you need to specify accepted licenses > for your project). > > * I believe Fedora has some automated tooling based on this comment by a > Fedora packager: > https://users.rust-lang.org/t/psa-check-if-your-cargo-crates-are-clean-and-… > > That is for the SPDX expression. I have not looked into the details of > their tooling. > > * Debian probably have thought about this too, they tend to be rather > careful (some may say up-tight even) about this sort of issues. It might > be worth checking out what they did. > > I'd like some automated tooling that works for AUR too, I maintain some > Rust packages there (some of which I'm also the upstream for). For that > reason, I'd be happy to stay "in the loop" on this issue as well as > possibly help (time and energy permitting, due to recently recovering from > burnout, energy tends to vary on a day to day basis), rather than treating > it as a one-off issue report. > > Is it a high priority issue? No. > Should it be solved eventually? Yes, for legal reasons. > > Best regards, > Arvid Norlander > (Arch Linux user and Rust / C++ software developer) > Hi Arvid, Thanks for bringing this issue to my attention and your detailed email about it. I'm CCïng our public development mailing list in this response so our other maintainers get informed, too. I agree that Arch needs a solution for this eventually. Unlike Fedora we do not package Rust libraries so I think we need some help from Cargo for this. Preferably from upstream, but a third-party tool would work as well. Ideally, I think there we would create a SPDX license expression from the entire crate tree and then simplify it, e.g. to turn `(MIT) AND (MPL-2.0 OR MIT) AND (MIT AND BSD-2-Clause) AND (MPL-2.0 OR BSD-3-Clause)` into `MIT AND BSD-2-Clause AND (MPL-2.0 OR BSD-3-Clause)`. Or perhaps even simpler if the tool had knowledge about which licenses are covered by others. We could call such a tool in the `package()` function to set the `license` for the package. I'm not sure how feasible this would be. Are crates required to use SPDX expressions? Greetings, Jan

1 0

News draft: Increasing the default vm.max_map_count value
by Robin Candau 05 Apr '24

05 Apr '24

MD pad available at https://md.archlinux.org/xl4oBGN9SDWRXnfvHuLhgg?both ---- # Increasing the default vm.max_map_count value As per [this proposal](https://lists.archlinux.org/archives/list/arch-dev-public@lists.a…, we decided to increase the [vm.max_map_count](https://docs.kernel.org/admin-guide/sysctl/vm.html#max-ma… value from the default `65530` to `1048576`, based on the same change that multiple distributions already did on their respective side. This change should help addressing performance, crash or start-up issues for some memory intensive applications, particularly for (but not limited to) [some Windows games](https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2057792/comment… played through Wine/Steam Proton. Overall, it goes forward a smoother user experience out of the box with no expressed concerns about potential downsides in the related proposal. This `vm.max_map_count` increase is introduced in the `2024.04.07` release of the [filesystem package](https://archlinux.org/packages/core/any/filesystem/) and will be effective right after the upgrade. Before upgrading, in case you're already providing your own value for that parameter in a `sysctl` config file, either remove it (to switch to the new default value) or make sure your config file will be read [with a higher priority](https://man7.org/linux/man-pages/man8/sysctl.8.html#SYSTEM_FILE_P… than the `/usr/lib/sysctl.d/10-arch.conf` file (to supersede the new default value). -- Regards, Robin Candau / Antiz

1 0

New supply-chain security tool: backseat-signed
by kpcyrd 03 Apr '24

03 Apr '24

Hello, I'm going to keep this short, I've been writing a lot of text recently (which is quite exhausting, on top of my dayjob and all the code I wrote today afterwards. Apologies if you're still waiting for a reply in one of the other threads). I figured out a somewhat straight-forward way to check if a given `git archive` output is cryptographically claimed to be the source input of a given binary package in either Arch Linux or Debian (or both). I believe this to be the "reproducible source tarball" thing some people have been asking about. As explained in the README, I believe reproducing autotools-generated tarballs isn't worth everybody's time and instead a distribution that claims to build from source should operate on VCS snapshots instead of tarballs with 25k lines of pre-generated shell-script. Building from VCS snapshots is already the case for a large number of Arch Linux packages (through auto-generated Github tarballs). Some packages have been actively converted to VCS snapshots by Arch Linux staff in response to the xz incident. This tool highlights the concept of "canonical sources", which is supposed to give guidance on what to code review. This is also why I think code signing by upstream is somewhat low priority, since the big distros can form consensus around "what's the source code" regardless. https://github.com/kpcyrd/backseat-signed The README shows how to verify Arch Linux and Debian build cmatrix from the same source code - they may both still apply patches (which would be considered part of the build instructions), but the specified source input is the same. This tarball can also be bit-for-bit reproduced from VCS by taking a `git archive` snapshot of the v2.0 tag in the cmatrix repository. (If somebody ever tells you programming in Rust is slower, I wrote the entirety of this codebase within a few hours of a single day) Let me know what you think. 🖤 Happy feet, kpcyrd

1 0

Re: Proposal to increase the default vm.max_map_count value
by Robin Candau 02 Apr '24

02 Apr '24

> On April 1, 2024 12:09:47 PM UTC, Robin Candau <antiz(a)archlinux.org> wrote: > > On 3/25/24 9:10 AM, Robin Candau wrote: > > Hi everyone, > > I'm writing this mail as proposal to increase the default > `vm.max_map_count` value in Arch Linux. > > > It's been a week since this proposal thread [1] was made. For now it > only received a few but all positives feedback (both from staff > members and users in a related thread on arch-general [2]). > > Do we have any more thoughts anyone wants to share? > > Also, if we are to implement this change, anyone has an opinion > about which package should provide it? So far, the following > packages have been mentioned: > - systemd (as Fedora did) > - procps-ng (as Ubuntu did) > - filesystem > > Given that the proposal goes through, I'll create the MR to the > chosen package accordingly. Also, despite this change being > impact-free (as far as we can tell), I think a related news item to > inform users about this change would be a great idea (I'll write > that as well). > > Please, share your opinion about the change itself or the best > package to provide it if you have any :) > > [1] > https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o… <https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o…> > [2] > https://lists.archlinux.org/archives/list/arch-general@lists.archlinux.org/… <https://lists.archlinux.org/archives/list/arch-general@lists.archlinux.org/…> > On 4/1/24 11:11 PM, Ehalls wrote: > I would keep it out of systemd. Do you think it is the approproate place? > > (Copying the above response I received from someone off-list, as it is staff only) Since the change consists of shipping a sysctl file and that sysctl is provided by procps-ng, I personally think procps-ng is the appropriate place. -- Regards, Robin Candau / Antiz

1 2

Proposal to increase the default vm.max_map_count value
by Robin Candau 01 Apr '24

01 Apr '24

Hi everyone, I'm writing this mail as proposal to increase the default `vm.max_map_count` [1] value in Arch Linux. The default `vm.max_map_count` 65530 value is making some Windows games crash (or even prevent them to start at all) while being played through Wine or Steam Play (Proton). Examples are (but not limited to) Star Citizen, THE FINALS, Hogwarts Legacy, DayZ or Counter-Strike 2 (see [2] for a list of bug reported to Valve for these games on that matter). In that regard, SteamOS is shipping an increased `vm.max_map_count` default value to address the above issue and numerous distributions have since then decided to implement that change on their side as well, such as Fedora [3], NixOS [4] and, more recently, Ubuntu [5]. While I'm aware that Arch is a user centric/DIY distro and everyone can set their own `vm.max_map_count` value fairly easily, shipping an increased value on our side would be a beneficial change to make in my opinion as it would result in a smoother gaming experience out of the box for our users without representing any downside/side effect (as far as I'm aware). In terms of implementation, the change basically consists of shipping the following sysctl file: ``` # Increase the number of virtual memory areas that one process may request vm.max_map_count=1048576 ``` For reference, Fedora added it to their systemd package [6], while Ubuntu handled it at the procps level [7]. I personally don't have a strong opinion on the implementation way/place. To sum up, I think this would be a reasonable and positive change to make to our distro. I'd be happy to read your thoughts (or eventual objection)! 😊 [1] https://docs.kernel.org/admin-guide/sysctl/vm.html#max-map-count [2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2057792/comments/5 [3] https://fedoraproject.org/wiki/Changes/IncreaseVmMaxMapCount [4] https://github.com/NixOS/nixpkgs/pull/238459 [5] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2057792 [6] https://src.fedoraproject.org/rpms/systemd/blob/f39/f/10-map-count.conf [7] https://git.launchpad.net/ubuntu/+source/procps/commit/?h=applied/2%254.0.4… -- Regards, Robin Candau / Antiz

3 4

Mirror hardening - complementing RFC 29
by pitastrudl 28 Mar '24

28 Mar '24

Hi, A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/35 Please visit the above link for discussion. Summary: Before this proposal, there were a lack of security definitions and measures on mirrors within the Arch Linux community. This RFC therefore outlines the requirements, definitions and guidelines surrounding not only hardening but also maintaining proper security of a mirror. Best regards, Arun

1 0

RFC Final Comment Period: Allow all staff to create RFCs
by Kristian Klausen 23 Mar '24

23 Mar '24

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/31 Please visit the above link for discussion. Summary: Grant all Arch Linux staff members, not limited to those in packaging roles, the privilege to initiate RFCs directly, aligning with the broad range of topics these documents encompass.

1 0

Arch Linux minimal container userland 100% reproducible - now what?
by kpcyrd 21 Mar '24

21 Mar '24

hello, in last week's email to the reproducible-builds email list[1] about reproducible Arch Linux I mentioned there's only one unreproducible package left in docker.io/library/archlinux. [1]: https://lists.reproducible-builds.org/pipermail/rb-general/2024-March/00329… Due to amazing work by dvzrv and Foxboron this package is now also reproducible! INFO arch_repro_status > All packages are reproducible! INFO arch_repro_status > Your system is 100.00% reproducible. To try for yourself use: podman run --rm -t archlinux sh -c 'pacman -Suy arch-repro-status --noconfirm && arch-repro-status' However: Where do we go from here? It would be cool if the OCI container image itself could also be reproduced (bit-for-bit), but I'm not sure if there's any prior work (specifically for images listed as 'official' on Docker Hub)? Specifically what I mean - given a line like this: FROM archlinux@sha256:2dbd72d1e5510e047db7f441bf9069e9c53391b87e04e5bee3f379cd03cec060 I want to reproduce the artifact(s) that are pulled in by this, with the packages our Arch Linux rebuilders have reproduced from source code. From what I understand this hash points to a json manifest that is not contained in the container image itself and was generated by the registry (should we archive them?), and this manifest then points to the sha256 of the tar containing the filesystem (I'm possibly missing an indirection here). Hopefully one of the many SBOM formats can help with this. :P I know the container image is built from these two repositories but I don't have any in-depth knowledge: - https://github.com/docker-library/official-images/blob/master/library/archl… - https://gitlab.archlinux.org/archlinux/archlinux-docker The only work towards reproducible container images I'm aware of is by Akihiro Suda: https://github.com/reproducible-containers/repro-get#are-container-images-b… I'm suspecting the current scripts used by Arch Linux would still be prone to mirror changes[2] though, meaning new package uploads would end up in our reproduced artifacts (causing mismatches) and the container image could only be reproduced for a short amount of time. [2]: https://gitlab.archlinux.org/archlinux/archlinux-docker/-/blob/98cd79111dd5… I'm also not sure if there's a missing puzzle piece with reproducible containers in regards to this manifest json that is generated by the registry. The image digest being unpredictable has also been mentioned in a cosign github issue[3]. [3]: https://github.com/sigstore/cosign/issues/2516 Input much appreciated! ## Caveats Probably worth mentioning, at the time of writing there's no consensus across multiple orgs yet, the https://reproducible.archlinux.org instance reports this status, two other rebuilders don't report the full 100% yet. $ arch-repro-status -r https://reproducible.crypto-lab.ch [...] INFO arch_repro_status > 3/118 packages are not reproducible. INFO arch_repro_status > Your system is 97.46% reproducible. $ arch-repro-status -r https://wolfpit.net/rebuild [...] INFO arch_repro_status > 3/118 packages are not reproducible. INFO arch_repro_status > Your system is 97.46% reproducible. The packages in question are part of this rebuild todo (specifically gcc-libs, glibc, ncurses): https://archlinux.org/todo/rebuild-core-with-reproducible-pacman/ Meaning there's currently some luck involved for these 3 packages, e.g. using btrfs currently increases your chances to get an exact match (after a few tries). We're obviously trying to get rid of this caveat though. --- If you appreciate this flavor of supply-chain security you may be interested in repro-env[4] that I'm currently trying to land[5] in ubuntu 24.04 LTS, but is blocked by Debian's libnettle[6]. [4]: https://github.com/kpcyrd/repro-env [5]: https://tracker.debian.org/pkg/rust-repro-env [6]: https://tracker.debian.org/pkg/nettle cheers, kpcyrd

3 2

Revising Go packaging guidelines (2024)
by kpcyrd 21 Mar '24

21 Mar '24

hello, the Arch Linux Go packaging guidelines[0] currently suggest this for building software written in Go: > export CGO_CPPFLAGS="${CPPFLAGS}" > export CGO_CFLAGS="${CFLAGS}" > export CGO_CXXFLAGS="${CXXFLAGS}" > export CGO_LDFLAGS="${LDFLAGS}" > export GOFLAGS="-buildmode=pie -trimpath -ldflags=-linkmode=external -mod=readonly -modcacherw" > > # or alternatively you can define some of these flags from the CLI options > go build \ > -trimpath \ > -buildmode=pie \ > -mod=readonly \ > -modcacherw \ > -ldflags "-linkmode external -extldflags \"${LDFLAGS}\"" \ > . [0]: https://wiki.archlinux.org/title/Go_package_guidelines There's also section "2.2.2 Supporting debug packages" which contradicts the previous section. ## Suggestion I'd like to propose changing this to something like: > prepare() { > cd ${pkgname}-${pkgver} > go mod download > } > > build() { > cd ${pkgname}-${pkgver} > go build . > } > > package() { > cd ${pkgname}-${pkgver} > install -Dm0755 -t "${pkgdir}/usr/bin/" "${pkgname}" > } Plus any extra flags (for example for debug packages to work, if any are needed at all - there's a note about this towards the end of this essay). Instead of suggesting two (three) different approaches, the packaging guidelines should endorse argv over environment variables (how to set them with environment variables can still be documented in a later section of the guideline). The reason I'm suggesting this: ## Passing flags over argv Setting these options through environment variables is for cases when `go` isn't executed directly by our PKGBUILD, but instead by some indirection like a Makefile. Makefiles are more popular in Go projects than they are in e.g. Rust projects, but presumably because for many years (10+) there was no analogous to `env!("CARGO_PKG_VERSION")` to embed a version string into the binary for --version output. Since almost exactly two years ago, in Go 1.18 released March 2022, there's now `runtime/debug.ReadBuildInfo` which gives you a reference to an embedded struct that contains a version string[1]. [1]: https://pkg.go.dev/runtime/debug#ReadBuildInfo Hopefully more Go projects are going to favor this in the future over custom build scripts and passing `-X main.Version=...` with output from `git describe --tags`. If this catches on, people might think of `go build` more like they currently think of `cargo build` and I think the Go package guideline should encourage this. Not just for Go but for software in general, using `git describe` should be considered an anti-pattern. In the way the Arch Linux build system currently works, only the checked out files are authenticated and pinned by sha256sums= and friends, but `git describe` explicitly works on unauthenticated git objects in `.git/`. I've published a writeup on how to take advantage of this on the reproducible builds list in September 2023[2]. [2]: https://lists.reproducible-builds.org/pipermail/rb-general/2023-September/0… ## Using the Go native Linker Binaries built by the Go compiler have been reproducible for a long time, however Go binaries built by Arch Linux usually aren't. This has led to some confusion, with bug reports to upstreams of Go software because it wasn't obvious that the package not being reproducible in this case isn't a problem in upstream's source code, but the way Arch Linux compiles it. Arch Linux generally prefers binaries with hardening flags enabled[3] and therefore explicitly opts into a non-default linker (Cgo), but it seems to be the unpopular choice. Cgo seems to have less support than normal Go on Linux (evidently, since Cgo has been known to have reproducible build issues for years now). Other Linux distributions seem to stick to normal Go too, Nix has Cgo off by default[4] and searching through nixpkgs for "buildGoModule" yields about 2k results, searching for "CGO_ENABLED" has 105 results, with more than half being "CGO_ENABLED=0" though. Alpine Linux only sets GOFLAGS globally[5] (which Arch Linux currently doesn't), searching for `rg -l --multiline '\tgo.*build'` in aports matches 356 files, `rg -l CGO_ENABLED=0` matches 23 files and `rg -l CGO_ENABLED=1` matches 18 files. [3]: https://github.com/jvoisin/compiler-flags-distro [4]: https://github.com/NixOS/nixpkgs/blob/b081342f1c16e4cbe4f40f139bbdda1475ea3… [5]: https://git.alpinelinux.org/abuild/tree/default.conf?h=3.12.0#n5 The global GOFLAGS as specified in Alpine Linux are: > export GOFLAGS="-buildmode=pie -modcacherw -trimpath -buildvcs=false" Which we could consider setting globally too, like we do with RUSTFLAGS. Figuring out what Debian does was somewhat challenging, their integration with the go build system is called dh-golang[6], they seem to set CGO_ENABLED=1 only when cross-compiling, with go >= 1.13 (released 2019) they seem to build with `go install -trimpath ...` and no further GOFLAGS environment variable. [6]: https://salsa.debian.org/go-team/packages/dh-golang/-/blob/debian/sid/lib/D… I understand the concern of Go possibly being more prone to ROP-style exploits when 1) built with the native linker and 2) used with e.g. a vulnerable version of libgit2, however, as of 2024, there have been barely any memory-corruption based exploits for Go software. ## Motivation - Most of our Go software is currently not reproducible due to Cgo, including core/libcap, which is the last unreproducible package in docker.io/library/archlinux - The barrier for packaging Go in Arch Linux is currently somewhat high (compared to e.g. packaging Rust), the guideline requires too much interpretation and could be improved - Quirks that are only needed for old Go projects (like 2.1.1) should be listed towards the end instead of being the first code block in the guideline --- cheers, kpcyrd

2 1

Spring cleanup '24
by gromit 20 Mar '24

20 Mar '24

Hello everyone, the amount of birds that are chirping in front of my flat make it clear that spring is coming (at least to Heidelberg). :p Therefore it is time to do our annual spring cleanup and free the repos from any leftovers. Please head to https://archlinux.org/devel/reports/unneeded-orphans/ and adopt packages that you'd like to keep in the repos. The devs among us should maybe also have a look at the (few) [orphans in [core]][0]. This is maybe also a good time to re-evaluate the current package set you maintain and disown anything that you've lost interest in so others can properly maintain it either in the repos or the AUR. Feel free to drop a message here if its anything major. I will start dropping packages on 2024-03-17, so please try to have a look at the lists in the next few days. Cheers, gromit [0]: https://archlinux.org/packages/?sort=&repo=Core&q=&maintainer=orphan

5 7

RFC Final Comment Period: Create new AUR moderator role
by Torsten Keßler 16 Mar '24

16 Mar '24

An RFC has now entered its 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/19 Please visit the above link for the discussion. Summary: Create a dedicated role for the moderation of the AUR that supports and eventually replaces the Package Maintainers as the current moderators.

1 1

pacman in testing can cause some issues for packagers
by Morten Linderud 15 Mar '24

15 Mar '24

Yo, With `pacman` in testing `[core-testing]` there might be some issues for packagers that use `makepkg --geninteg` or `updpkgsums` and submitting the source packages to build.archlinux.org. As the *sums=() array will contain an integrity check for git sources in pacman 6.1 and beyond the older pacman version on build.a.o is not going to understand this and fail the build. Just set the array to 'SKIP' as usual and it should build fine. I'm not aware of any other packager issues as of writing. -- Morten Linderud PGP: 9C02FF419FECBE16

2 2

RFC: Arch Linux Ports
by David Runge 11 Mar '24

11 Mar '24

A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/32 Please visit the above link for discussion. Summary: Introduce "Arch Linux Ports" as testbed for unofficial architectures until they are integrated in the main Arch Linux repositories. This integration is meant to provide infrastructure and community-based support for architectures until they are fully supported by the main distribution.

1 0

pacman 6.1.0 and libalpm.so.14 rebuild
by Morten Linderud 09 Mar '24

09 Mar '24

Yo, pacman 6.1.0 is now in staging and I've made a gitlab epic and a todo for the rebuild. https://archlinux.org/todo/libalpmso-rebuild/ https://gitlab.archlinux.org/groups/archlinux/packaging/packages/-/epics/2 Currently a Rust and some C stuff is failing to build. -- Morten Linderud PGP: 9C02FF419FECBE16

2 1

Future of libdepends and libprovides
by Balló György 09 Mar '24

09 Mar '24

Hi all, Since the support for libdepends and libprovides has been removed from the recently released pacman 6.1, [1] we need to do something before adopting it to Arch Linux. Many our packages rely on libdepends and libprovides, and if makepkg would not fill the soname version and architecture, those dependencies would be broken. I mentioned this one year ago, but no further discussions happened. [2] In short term, we should revert this commit [3] at distribution level to avoid breakages. In long term, we have to decide via RFC what to do with libdepends and libprovides. We could probably make a slow, manual transition to the new 'autodeps' feature in pacman, but it still does not support optional autodeps, [4] which means that would be impossible to mark any binary deps as optional. [1] https://gitlab.archlinux.org/pacman/pacman/-/releases/v6.1.0 [2] https://lists.archlinux.org/hyperkitty/list/arch-dev-public@lists.archlinux… [3] https://gitlab.archlinux.org/pacman/pacman/-/commit/354a300cd26bb1c7e655147… [4] https://gitlab.archlinux.org/pacman/pacman/-/merge_requests/58 -- György Balló Package Maintainer

2 1

RFC: Allow all staff to create RFCs
by Kristian Klausen 05 Mar '24

05 Mar '24

A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/31 Please visit the above link for discussion. Summary: Grant all Arch Linux staff members, not limited to those in packaging roles, the privilege to initiate RFCs directly, aligning with the broad range of topics these documents encompass.

1 0

Consolidating our mkinitcpio hooks
by Morten Linderud 03 Mar '24

03 Mar '24

Hi, Currently we have a lot of our mkinitcpio hooks in several packages which has never been consolidated. This makes it confusing where stuff belong and what is provided where, and I really want to consolidate everything. It would help keeping up the development of the hooks, patch everything and ultimately write a test suite for mkinitcpio. I also have long term plans on moving the default hooks from busybox to systemd, but this will happen at a later point. Initially I really want to move the hooks from `cryptsetup` and `systemd`: * encrypt and sd-encrypt from core/cryptsetup * systemd and udev from core/systemd We could maybe consider a few other hooks from [core] depending on peoples opinion? We are missing a good networking hook for systemd, and that should preferably be solved at some point. A list of possibly other relevant mkinitcpio stuff: Hook Package * btrfs btrfs-progs * dmraid dmraid * mdadm mdadm * mdadm_udev mdadm * lvm2 lvm2 * sd-lvm2 lvm2 * net mkinitcpio-nfs-utils * netconf mkinitcpio-netconf # Migration It's unclear to me how we should best move these hooks. We would need to merge them upstream into `mkinitcpio` first, then remove them from the packages. Is a news item is enough for this? Or do we want to include a couple of package constraints to ensure people are accidentally removing their hooks? What are peoples opinions? -- Morten Linderud PGP: 9C02FF419FECBE16

5 10

Announcing pacquery
by Jelle van der Waa 03 Mar '24

03 Mar '24

Hi all, One of the things I've been missing for a long time is the ability to easily query package information. Pacman -S --print-format lacks some options and more importantly does not support json output. I've had a small rust utility locally which helped a lot with getting ready for the pacman rebuild. This weekend I spend some time refining it and releasing it to the repos as pacquery. An example, finding all packages which have make/check/depends on python-tomli [jelle@natrium][~/projects/pacquery]%pacquery python-tomli | jq -r '.[].required_by | join(" ")' python-flake8-black python-ipdb python-setuptools-gettext python-setuptools python-responses python-tomli-w python-fsspec sip mdformat repod mypy autopep8 python-diff-cover python-pep621 python-versioningit python-pylint python-pdm-pep517 python-sphinx-theme-builder python-pytest-cov towncrier python-isort Note that this tool uses the syncdb's so these need to be up to date and it defaults to core,extra,multilib. Greetings, Jelle van der Waa

1 0

GHC 9.2.8 enters [extra-testing]
by Felix Yan 26 Feb '24

26 Feb '24

Hi all, The long delayed GHC 9.2.x updates have been done and moved to [extra-testing]. There are a few notable changes regarding our GHC packaging: - Codegen backend has been switched back to NCG for multiple reasons: = GHC doesn't support latest LLVM and was using llvm14 in Arch. This adds up to our maintenance burden of LLVM. (IIRC LLVM 15 support was fixed only recently.) = LLVM backend actually generates slower code. We have evaluated the changes during the past years and noticed as large as 50% slower results in some benchmarks. I also got similar information from other distribution people. = LLVM backend sometimes deadlocks on compile-time. I hit this from time to time and it's not easy to reproduce reliably. (There are similar issues that are always reproducible, but got fixed already.) All `--ghc-option=-fllvm` has been removed from PKGBUILDs during the rebuild. - Build system of GHC itself has been switched to Hadrian. - Some obsolete packages have been retired from the distribution, and will be removed once the batch enters [extra]: haskell-bytestring-show haskell-random-source haskell-brittany haskell-hls-brittany-plugin haskell-hls-tactics-plugin haskell-hls-haddock-comments-plugin A lot of thanks to @Vekhir who helped me a lot for preparing this so that it's done much earlier and smoother than I expected :) As always, please report any issues and have fun! -- Regards, Felix Yan

1 0

RFC: Distribution Developer Manual
by Levente Polyak 24 Feb '24

24 Feb '24

A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/21 Please visit the above link for discussion. Summary: This RFC proposes the migration of Arch Linux's operational distro specifications from existing ArchWiki and other sources to a dedicated GitLab Developer Manual repository. The intention is to document how to run the distribution while leveraging GitLab's collaboration features and streamlined workflows for maintaining and evolving the resulting specifications. This change aims to centralize and enhance the efficiency of specification management while preserving the integrity of the community-contributed content in the Wiki. This request for comments is superseding `RFC-0005 <https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/5>`_ by extending its scope to handle all distro specifications coherently instead of handling a single sub section (packaging guidelines) differently to others.

1 0

Arch Linux in January 2024
by Levente Polyak 14 Feb '24

14 Feb '24

## Staff We would like to welcome [Vladimir LAVALLADE (Erus Iluvatar)][0] to their new role as ArchWiki Administrator. ## Infrastructure The DevOps team has recently provisioned a new EPYC 9454P build server for Arch Linux packaging. This high-performance server is meant to streamline the packaging process, ensuring more efficient building of resource hungry package builds. ## mkinitcpio mkinitcpio [v37.2][1] and [v37.3][2] have been released. These releases include numerous bug fixes, such as patches addressing inflated initramfs sizes and resolving issues with kernel images located in non-standard locations. ## RFC An [RFC has been proposed][3] to add ``-fno-omit-frame-pointer`` and ``-mno-omit-leaf-frame-pointer`` to the default compilation flags to improve the effectiveness of profiling and debugging tools. Additionally, an [RFC has been proposed][4] to define new mirror administration routines and mirror requirements. This RFC outlines the requirements, definitions and guidelines surrounding not only becoming but also maintaining and decommissioning a mirror. ## Packaging ### Firefox The [firefox][5] and [firefox-developer-edition][6] packages have been updated to include regular debug packages. As part of this update, symbols are no longer submitted to Mozilla at the end of the build process. Instead, [Mozilla retrieves all symbols from our end][7]. This change enables local debugging of Firefox while still allowing the submission of useful crash reports to Mozilla and leveraging their profiling service. ### Statistics In this month, we've successfully rolled out 11068 package updates addressing various enhancements and rebuilds, including 2777 package upgrades. Additionally, we've received 204 new package issues, while resolving a total of 258 issues. [0]: https://wiki.archlinux.org/title/ArchWiki:News#2024/01/07_-_New_administrat… [1]: https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/releases/v37… [2]: https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/releases/v37… [3]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/26 [4]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/29/diffs [5]: https://gitlab.archlinux.org/archlinux/packaging/packages/firefox/-/commit/… [6]: https://gitlab.archlinux.org/archlinux/packaging/packages/firefox-developer… [7]: https://github.com/mozilla/symbol-scrapers/pull/41

1 0

dropping opera
by Ike Devolder 08 Feb '24

08 Feb '24

Hi, Since I have not really used opera for years, I'm finally going to drop it from the repo's. If someone wants it, feel free to adopt it. Else I will drop it to AUR in 2 weeks. --Ike

1 1

RFC Final Comment Period: Add -fno-omit-frame-pointer and -mno-omit-leaf-frame-pointer to default compilation flags
by Morten Linderud 06 Feb '24

06 Feb '24

An RFC has now entered its 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/26 Please visit the above link for the discussion. Summary: Add ``-fno-omit-frame-pointer`` and ``-mno-omit-leaf-frame-pointer`` to the default compilation flags to improve the effectiveness of profiling and debugging tools. -- Morten Linderud PGP: 9C02FF419FECBE16

1 2

Forensic tool release: archlinux-userland-fs-cmp (reproducible pre-compiled binary available)
by kpcyrd 31 Jan '24

31 Jan '24

hello, I released a tool recently that I'd like to share with this list: https://github.com/kpcyrd/archlinux-userland-fs-cmp It's supposed to be used from a rescue image (any Linux) with an Arch install mounted to e.g. /mnt. It does the following: - Open /mnt/var/lib/pacman and extract the list of (allegedly) installed packages. - Instead of trusting the `mtree` files from the mounted file system, the %NAME% and %VERSION% values from the `desc` files are used to start a download stream from archive.archlinux.org. - From the download stream it's decompressing and inspecting the content on-the-fly, since the .MTREE file is near the beginning of the package we can abort the remaining package download after the mtree has been received (saving a lot of time and traffic). - All files in /mnt that are part of a package are hashed and compared with the sha256 hashes in the MTREE files downloaded from the archive. - Finally, it's printing a report of all files that either mismatched or are not a part of any package. This can be redirected to a file using the -o flag. At no point is any file from the mounted filesystem eval'd or otherwise executed. Parsers are written in a memory safe language. Although it's integrating with pacman, the integration with archive.archlinux.org makes this Arch Linux specific, files from AUR, Manjaro or SteamOS packages are all going to be flagged for manual inspection. The authenticity of the .MTREE files is assumed through the https connection they are downloaded from (which is supposed to be sufficient for the use-case it's built for). The release page on github has a pre-compiled, statically linked binary that can trivially be reproduced from source code. The dependency tree is documented in Cargo.lock, the build environment is documented in repro-env.lock. The binary has been tested to be working correctly on a Debian bookworm installer busybox rescue shell. There's a gif in the README showing how the tool looks like in action. --- I also printed reproducible builds stickers with a new and unique design that I'm planning to hand out at FOSDEM (along with some 37c3 leftovers), if you have read this far, feel free to ask me about stickers if you see me there. The print cost geht auf mein Nacken. cheers, kpcyrd

1 0

FOSDEM 2024 Dinner
by Morten Linderud 26 Jan '24

26 Jan '24

Yo! The previous years at FOSDEM we have held a dinner with around 15-20 people. Some maintainers from Arch, and some users that wanted to join. It has been great events and with FOSDEM 2024 happening I thought it was a good idea to do it again :) The dinner will be held Saturday, 3rd of February, around 20:00. The dinner is sponsored by the 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 team (developers, packagers and support staff). Any free spots after this can be taken by anyone interested. Send me an email *offlist* if you want to attend. 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. Cheers! -- Morten Linderud PGP: 9C02FF419FECBE16

1 1

Arch Linux in December 2023
by Levente Polyak 23 Jan '24

23 Jan '24

## Staff We would like to welcome [Jakub Klinkovský (lahwaacz)][0] as part of the Arch Linux Package Maintainer team. ## User meetup During the [37th Chaos Communication Congress (37C3)][1], we hosted a user meetup. At this event, we presented our latest achievements and developments. Additionally, we held an open Q&A session to engage and connect with our community. ## dbscripts We performed a thorough cleanup of the codebase, removing all legacy SVN functionality that is no longer necessary. Furthermore, a critical locking issue was resolved, which previously allowed the same file descriptor to be reused multiple times. This correction ensures that each lock is properly maintained, addressing concurrency locking issues and preventing inconsistent states. ## Infrastructure We have rolled out [Keycloak 23][2], to utilize the latest features and fixes for our central Single Sign-On (SSO) system at [accounts.archlinux.org][3]. Additionally, we've activated the Account Console version 3, which grants us access to its custom field support, specifically designed in conjunction with the 'User Profile' feature. ## RFC We [proposed and accepted an RFC][4] to make dbus-broker our default D-Bus daemon, while still allowing the venerable dbus-daemon to be used and minimizing the disruption of existing installations. Furthermore an [RFC has been proposed][5] to add ``-fno-omit-frame-pointer`` and ``-mno-omit-leaf-frame-pointer`` to the default compilation flags to improve the effectiveness of profiling and debugging tools. [0]: https://lists.archlinux.org/hyperkitty/list/aur-general@lists.archlinux.org… [1]: https://events.ccc.de/category/37c3/ [2]: https://www.keycloak.org/2023/11/keycloak-2300-released.html [3]: https://accounts.archlinux.org [4]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/25 [5]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/26

1 0

New checks for SPDX license identifiers with namcap >= 3.5.0
by David Runge 14 Jan '24

14 Jan '24

Hi all! With RFC0016 [1] we have worked out a way to reason about SPDX license identifiers [2] in the context of PKGBUILDs and packages. Over the past months I have worked on the licenses package [3], as well as namcap [4] to create the integration for all packagers. This mail serves as a refresher and general overview of what this means for packagers. TL;DR: Namcap now emits more specific error messages and there are probably a few things in this mail that you will want to learn about! :) To be able to be more specific in the below text, I will use this mini-glossary to explain what some words refer to: * *known* licenses and exceptions - Licenses and license exceptions *known* to SPDX (i.e. they are in the lists [2][5]). * *unknown* licenses and exceptions - Licenses and license exceptions *not known* to SPDX (i.e. they are *not* in the lists [2][5]). License identifiers prefixed with "LicenseRef-" are not considered. * *common* licenses and exceptions - Licenses and license exceptions that are packaged in the context of the licenses package [3] and can be shared *commonly*. * *uncommon* licenses and exceptions - Licenses and license exceptions that are *known*, but are *not common* (i.e. they are in the lists [2][5] but not in the licenses package [3]). License identifiers prefixed with "LicenseRef-" are always considered *uncommon*. For packagers a few things change when it comes to handling license information for packages. * It is encouraged to have a look at the list of *known* license identifiers [2] and exceptions [5] to familiarize yourself with how identifiers look like. The *common* licenses can be found in /usr/share/licenses/spdx/ and the *common* license exceptions in /usr/share/licenses/spdx/exceptions/. * The `license` array in PKGBUILDs should now start to contain valid SPDX license identifiers [2][5] or custom license identifiers, that are prefixed with "LicenseRef-" (e.g. "LicenseRef-Custom-License-1.0"). To keep complex scenarios maintainable and readable, each entry in the `license` array may be interpreted as being concatenated by the `AND` license expression [6]. * We now distinguish between various versions of some identifiers (e.g. previously we were okay with simple identifiers such as "GPL3" but now we have "GPL-3.0-only" and "GPL-3.0-or-later", which are separate from one another). If you are unsure about what applies, either contact upstream or reach out over mail, IRC, Matrix to ask other packagers. * If in doubt, rather be more specific than less specific! * To aide in documenting copyright and attribution, many upstreams rely on SPDX License IDs [7], which are added as comments at the top of each source file. These often help a great deal in figuring out which specific licenses apply and help in finding out whether there are any license files missing. To help you with figuring things out, namcap gained a few more features with > 3.5.0 (although some issues had to be ironed out up until 3.5.2 and I seriously hope I didn't introduce even more bugs ;-)). Please remember that namcap does not take away the work of investigating and providing the correct license identifiers for you! * Namcap now emits errors on all *unknown* license identifiers [2] and license exceptions [5]. * Namcap now lists all *uncommon* licenses and license exceptions while providing an overview about how many license files it found for the amount of *uncommon* identifiers (each *uncommon* identifier requires a separate file). * Namcap now emits errors with suggestions on formatting issues of license expressions (e.g. `MIT and Apache-2.0` -> `MIT AND Apache-2.0`). * Namcap now emits errors on license strings that can not be parsed. * Namcap now emits errors when the license directory is a symlink to a location in another package, that is not in `depends`. * Namcap now emits errors when the license directory is a symlink to a location in another package and license files are missing for *uncommon* identifiers. * Namcap now emits warnings if it detects symlinks for the license directory or single license files to another package. This is done because it is *very* cumbersome and error-prone to detect files in other packages reliably (e.g. those could in turn be symlinks to non-existent files, etc.). It is encouraged to package license files per package! Symlinks in the same package are fine! I hope this summary was not too overwhelming and will help you to get through the licensing jungle! Please do note, that the Arch Wiki section on license identifiers in the PKGBUILD article [8] still needs to be adapted. If there are any questions, please reach out! Many thanks to everyone who worked on the RFC and helped with testing the implementation! Best, David [1] https://rfc.archlinux.page/0016-spdx-license-identifiers/ [2] https://spdx.org/licenses/ [3] https://archlinux.org/packages/core/any/licenses/ [4] https://gitlab.archlinux.org/pacman/namcap/ [5] https://spdx.org/licenses/exceptions-index.html [6] https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/ [7] https://spdx.dev/learn/handling-license-info/ [8] https://wiki.archlinux.org/title/PKGBUILD#license -- https://sleepmap.de

1 0

RFC: Mirror Definition
by Anton Hvornum 09 Jan '24

09 Jan '24

A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/29 Please visit the above link for discussion. Summary: Before this proposal, there were a lack of requirements and definition of what a mirror is within the Arch Linux community. This RFC therefore outlines the requirements, definitions and guidelines surrounding both becoming but also maintaining and decommissioning a mirror.

1 0

Making dbus-broker our default D-Bus daemon
by Jan Alexander Steffens (heftig) 05 Jan '24

05 Jan '24

The following change just entered our testing repositories: We are making dbus-broker our default implementation of D-Bus, for improved performance, reliability and integration with systemd. For the foreseeable future we will still support the use of dbus-daemon, the previous implementation. Pacman will ask you whether to install dbus-broker-units or dbus-daemon-units. We recommend picking the default. For a more detailed rationale, please see RFC 25 at https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/25.

1 0

freerdp dropped from [extra-testing]
by David Runge 02 Jan '24

02 Jan '24

Hi all! I just dropped freerdp from [extra-testing], as I moved it there erroneously. Freerdp > 3 is currently *not* compatible with most dependents. I will try to figure out whether a freerdp2 package is feasible in the coming days. Patching the dependents is of course also an option, however most upstreams seem to not have progressed sufficiently on the topic yet. Best, David -- https://sleepmap.de

1 0

RFC Final Comment Period: Make dbus-broker our default D-Bus daemon
by Jan Alexander Steffens (heftig) 16 Dec '23

16 Dec '23

An RFC has now entered its 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/25 Please visit the above link for discussion. Summary: Make dbus-broker our default D-Bus daemon, while still allowing the venerable dbus-daemon to be used and minimizing the disruption of existing installations.

1 0

RFC: Add -fno-omit-frame-pointer and -mno-omit-leaf-frame-pointer to default compilation flags
by Morten Linderud 16 Dec '23

16 Dec '23

A new RFC (request for comments) have been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/26#note_149849 Please visit the above link for discussion. Summary: Add ``-fno-omit-frame-pointer`` and ``-mno-omit-leaf-frame-pointer`` to the default compilation flags to improve the effectiveness of profiling and debugging tools. I'm sponsoring this on behalf of Daan De Meyer. -- Morten Linderud PGP: 9C02FF419FECBE16

1 0

Stepping down as Python maintainer
by Felix Yan 13 Dec '23

13 Dec '23

Hello, For the past ten years (and several days) I have been the guy maintaining Python itself and some libraries in Arch. It's been a long journey and I learned a lot from it. I was a web back-end developer back then, and I used Arch as the base OS of our company's servers and system-wide Python packages as the runtime. The server and website are still running today, but I am no longer developing Python very frequently these days. Plus, Python's type-hinting has been a headache for me for years and lowered my interest in contributing to upstream projects a lot. In the past, the large cross-minor-version Python rebuilds were done with either Evangelos' rebuilder or my own island solution. I understand Arch's striving to improve bus factor and formalizing process, so I am making room for others to try on the 3.11 and 3.12 rebuilds. As Jelle has progressed a lot now, I feel it's approaching the right time for me to step down as the Python maintainer. I will be disowning many of my no longer used Python module packages in the following days, so that they could find a better maintainer either in the Arch team, or later in the AUR if they are going to be dropped. Please also consider adopting the main python package and let me know :) -- Regards, Felix Yan

1 0

Arch Linux in November 2023
by Levente Polyak 12 Dec '23

12 Dec '23

## Arch Summit 2023 The Arch Summit took place in Hamburg, Germany, on November 4th and 5th, bringing together Arch Linux staff and invited guests. The summit provided an opportunity for the staff to connect, socialize, and delve into discussions regarding various aspects of our distro. A range of topics were explored including but not limited to infrastructure and mirror management, rebuilders for packages, signing enclave, mkinitcpio, packaging tooling improvements, and community building. Reports on these discussions will be published later. A special thanks to "adesso SE" for generously sponsoring the event, offering an excellent venue and catering support. ## Bug migration We are happy to announce that the migration from Flyspray to GitLab is complete. 🥳 Bug reports and Merge Requests for packages or Arch Linux projects can now be found on GitLab. For more details, check out the [related Arch Linux news post][0]. ## Testing Team To join the [Arch Testing Team][1], simply drop an email to `arch-testing-accounts(a)archlinux.org`. This transitions the process to a [team-based][2] approach that not only speeds up the account setup process but also provides a more collaborative environment through the GitLab service desk. If you're keen on diving into contributing to Arch Linux, joining the Arch Testing Team is a fantastic way to kickstart your involvement. 🚀 ## bugbuddy [Bugbuddy v0.2.0][3] has undergone significant updates, including the periodic refresh of maintainer and staff data from ArchWeb, ensuring the automatic reflection of package orphaning and adoption. Additionally, package maintainers can now opt-in to be assigned to unconfirmed issues for their packages. Furthermore, default labels for severity and priority have been added, and merge requests have been streamlined with automatic assignment to package maintainers. ## mkinitcpio mkinitcpio v37 has been released. Notable changes include the `consolefont` hook now using the kbd project's `setfont`, resolving past issues. Furthermore, the `autodetect` hook introduced a workaround for a race condition with `udevadm settle` and includes all possibly needed modules as an alternative fallback, preventing incomplete initramfs images and potential unbootable systems. Check out the [mkinitcpio v37 release announcement][4] for more details and additional changes. ## dbscripts Recent updates enhance atomicity by consolidating a unit of work and implementing robust error handling. Concurrency issues have been resolved by replacing outdated locking code with a modern, convenient API, and adopting less error-prone locking through flock. These changes collectively address various scenarios that previously resulted in inconsistencies between operations and had the potential to corrupt the repository state. ## alpm-types alpm-types has been released in version 0.4.0 introducing various smaller fixes and improvements. More information can be found in the [changelog][5]. ## Pacman Pacman is in the final stages of [preparing its next major release][6], version [7.0.0][7]. Additionally, collaborative efforts with an external auditor for the audit of the package manager and libalpm have been initiated. Stay tuned for more information and announcements around this exciting development in the near future. [0]: https://archlinux.org/news/bugtracker-migration-to-gitlab-completed/ [1]: https://wiki.archlinux.org/title/Arch_Testing_Team [2]: https://gitlab.archlinux.org/groups/archlinux/teams/testing/admins/-/group_… [3]: https://gitlab.archlinux.org/archlinux/bugbuddy/-/releases/v0.2.0 [4]: https://lists.archlinux.org/hyperkitty/list/arch-projects@lists.archlinux.o… [5]: https://gitlab.archlinux.org/archlinux/alpm/alpm-types/-/blob/0.4.0/CHANGEL… [6]: https://lists.archlinux.org/hyperkitty/list/pacman-dev@lists.archlinux.org/… [7]: https://gitlab.archlinux.org/pacman/pacman/-/milestones/1

1 0

phoc phosh phosh-mobile-settings dropped from [testing]
by Jelle van der Waa 11 Dec '23

11 Dec '23

Hi all, I pushed 0.34 of phosh to [testing] but it sadly does not start on my x86 tablet, so I've pulled it out of testing until that is fixed. Greetings, Jelle

1 1

Arch Linux in October 2023
by Levente Polyak 10 Dec '23

10 Dec '23

## Staff We would like to welcome [Christian Heusel (gromit)][0] to the Arch Linux DevOps team, expanding his responsibilities. ## bugbuddy The initial version of [Bugbuddy][1], our GitLab bug bot, has been introduced. This tool assigns package maintainers to confirmed GitLab issues in the packaging group. Notably, the code has undergone substantial improvement, now operating as a daemon process that can promptly respond to GitLab webhook calls. ## dbscripts The `db-remove` command has been streamlined, eliminating the need to pass an `arch` parameter by adding automatic resolution. Moreover, the `db-update` command now properly checks staged packages against staging/testing, addressing a loophole that previously caused state inconsistencies. Additionally we've enhanced the development process by parallelizing test execution, massively reducing unit testing duration. ## RFC In late 2021, an [RFC was proposed][2] to rename the `Trusted User` role to `Package Maintainer`, aligning it with the role's evolving nature within the Arch staff. The RFC, voted positively in late 2022, has now resulted in the successful renaming across various Arch resources, including the [Packaging Bylaws][3], [ArchWeb][4], [AURWeb][5], [ArchWiki][6], and the "[What can I do for Arch Linux?][7]" page. ## ArchWiki The [ArchWiki has been updated to MediaWiki 1.40][8], necessitating adjustments to the ArchLinux extension due to upstream changes in the Vector 2022 skin. This has prompted consideration of [switching to the Timeless skin][9]. Additionally, there has been a switch from PNG to SVG images in the wiki for article status templates and statistic histograms. The wiki now features the addition of [Extension:Thanks][10] and [Extension:DiscussionTools][11], offering users a streamlined way to express gratitude and heavily simplifying discussions on talk pages. ## ArchISO The ISO now provides a `/boot/grub/loopback.cfg` file which GRUB and Super GRUB2 Disk users can use to boot the ISO file without needing to manually specify the kernel, initrd and kernel command line parameters. Documentation on utilizing the `loopback.cfg` file is available both [upstream][12] and on [ArchWiki][13]. [0]: https://lists.archlinux.org/hyperkitty/list/arch-devops@lists.archlinux.org… [1]: https://gitlab.archlinux.org/archlinux/bugbuddy/ [2]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/7 [3]: https://gitlab.archlinux.org/archlinux/package-maintainer-bylaws/-/merge_re… [4]: https://github.com/archlinux/archweb/pull/478 [5]: https://gitlab.archlinux.org/archlinux/aurweb/-/merge_requests/755 [6]: https://wiki.archlinux.org/index.php?title=ArchWiki_talk:Requests&oldid=790… [7]: https://gitlab.archlinux.org/archlinux/neoasknot/-/merge_requests/84 [8]: https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/747 [9]: https://github.com/archlinux/archwiki/pull/71 [10]: https://www.mediawiki.org/wiki/Extension:Thanks [11]: https://www.mediawiki.org/wiki/Extension:DiscussionTools [12]: https://www.supergrubdisk.org/wiki/Loopback.cfg [13]: https://wiki.archlinux.org/title/Multiboot_USB_drive#Arch_Linux_monthly_rel…

1 0

RFC: Make dbus-broker our default D-Bus daemon
by Jan Alexander Steffens (heftig) 08 Dec '23

08 Dec '23

A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/25 Please visit the above link for discussion. Summary: Make dbus-broker our default D-Bus daemon, while still allowing the venerable dbus-daemon to be used and minimizing the disruption of existing installations.

1 0

Proposal: Automating release artifacts signing and deployment
by Kristian Klausen 02 Dec '23

02 Dec '23

Hi all, nl6720 has proposed[1] that DevOps create a CA for signing the iPXE and initramfs release artifacts. The goal is to be less dependent on a single person's signing key. After dialogue on IRC, we came to the conclusion, that maybe automating signing of the release artifacts (ISO included) is feasible. So the plan we came up with: 1. DevOps creates a CA with a lifetime of 10 years and stores it in their vault 2. DevOps binds a private key to the TPM on secure-runner1.archlinux.org[2] and create a CSR 3. DevOps signs the CSR with the created CA 4. DevOps creates a dedicated GitLab runner, on the mentioned server, with direct access to the TPM and restricted to specific GitLab projects 5. DevOps assigns the runner to the releng project[3] 6. The releng team set up automation for signing the release artifacts with the TPM To keep the implementation simple, the plan is to sign the ISO with `openssl cms` instead of OpenPGP. With that done, the next step would be the automatic synchronization to the mirros and archweb integration. We would like some input on the approach mentioned. If no concerns are raised, we will start implementing it. [1] https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/548 [2] Server for running pipelines for trusted Arch Linux projects [3] https://gitlab.archlinux.org/archlinux/releng/ Cheers, Kristian Klausen

1 0

News Draft: "Bugtracker migration to GitLab completed"
by gromit 01 Dec '23

01 Dec '23

Hello everyone, as we have completed the bugtracker migration it would be good to post a news item about it. Please give feedback if you have any about the draft below! Cheers, klausenbusk & gromit --- # Bugtracker migration to GitLab completed We are happy to announce that the migration of the bugtracker to GitLab is done! 🥳 This means the issue tracker and merge requests on the Gitlab package repos are now enabled. The old bugtracker will subsequently be closed down. For archiving reasons there will be a static copy so that links (for example the randomly picked [Task #56716][0]) are still stable, migrated bugs have a closing comment pointing to the new URL on GitLab. Packaging bugs are now opened on the repo hosting the corresponding packaging sources, the "Add a new Bug" Button on the package page on archlinux.org will automatically direct you to the correct place to open the issue. The workflow afterwards is mostly the same, first our [Bug Wranglers][1] will have a look at the issues and triage them and then they will be handed over to the respective [Package Maintainers][2] to fix. A list of all issues can be found [here][3]. If you do not have an account for GitLab already please write us a mail with your desired username to accountsupport(a)archlinux.org as advised in the banner! Thanks to everyone who has helped during the migration! [0]: https://bugs.archlinux.org/task/56716 [1]: https://gitlab.archlinux.org/groups/archlinux/teams/bug-wranglers/-/group_m… [2]: https://gitlab.archlinux.org/archlinux/teams/package-maintainer-team [3]: https://gitlab.archlinux.org/groups/archlinux/packaging/-/issues

1 0

Bugtracker Migration to GitLab
by Levente Polyak 25 Nov '23

25 Nov '23

## Scope Our primary goal is to migrate bugs.archlinux.org to GitLab, focusing on packaging bugs and our internal projects. In this email, we'll outline the workflow for packaging bugs and seek your assistance in testing the migration and the bug bot in the [test migration group](https://gitlab.archlinux.org/groups/flyspray-migration/packaging/pac…. Please pay attention to the relevant paragraphs and everyone is strongly encouraged to conduct testing as outlined in the testing section. ## Contribution The biggest chunk of the issue migration preparation and testing has been done by gromit, who elevated a former contribution from kevr into its current awesome state. On top, jelle has assisted in various ways to help providing the migration data and infra setup for the test migration. Additionally, I hacked together the bug bot that follows the defined workflow and labels. ## Issue Conversion Please review the converted issues to ensure there are no significant issues with packaging project assignments or issue content/metadata. You can find packaging issues at: [Packaging Issues](https://gitlab.archlinux.org/groups/flyspray-migration/packaging/pa…. Following the rollout of the issue migration, the [canonical source for packaging issues](https://gitlab.archlinux.org/groups/archlinux/packaging/packages/-/… will shift to each individual package repository. ## Workflow Our workflow will continue to rely on a team effort, similar to the bug wranglers used in Flyspray, but now within the GitLab environment. When new issues are opened, our bug wranglers will validate them, ensuring packagers receive high-quality bug reports. We'll use GitLab's status labels like "unconfirmed" and "confirmed" as well as issue assignees to streamline the process. ## Bug Bot Our bug bot, named bugbuddy, will play a crucial role in this workflow. When a new issue is opened, the bot will automatically assign the issue to all bug wranglers and set the label to "unconfirmed" for easy filtering. Once a bug wrangler confirms the issue, they will assign the "confirmed" status label. This, in turn, triggers the bug bot to automatically assign the issue to the current package maintainers. If packagers adopt or orphan packages in archweb, the bot will reassign the issues accordingly. ## Testing To ensure a smooth transition, we kindly request your assistance in testing the entire migration process and the functionality of our bug bot. Here are the steps to follow: 1. Check multiple converted issues in the [test migration group](https://gitlab.archlinux.org/groups/flyspray-migration/packaging/pac…. 2. Familiarize yourself with the workflow outlined above. 3. Open a test issue. 4. Monitor the bug bot's automatic assignment and the initial label, which should be "unconfirmed." 5. Progressively move the issue to the "confirmed" status. 6. Observe the automatic reassignment to the appropriate package maintainers. ## Labels To maintain useful fields and efficient issue filtering, we will use the following labels for issue categorization: Scope: bug, documentation, enhancement, feature, question, regression, reproducibility, security Status: unconfirmed, confirmed, in-progress, in-review, on-hold, waiting-input, waiting-upstream Resolution: cant-reproduce, completed, duplicate, invalid, not-a-bug, upstream, wont-fix Severity: 1-critical, 2-high, 3-medium, 4-low, 5-lowest Priority: 1-urgent, 2-high, 3-normal, 4-low ## Per Packager Settings For your convenience, we've implemented a feature that allows you to have more control over your assigned issues. This can be done by reacting with emojis in the bugbuddy issue tracker at [this link](https://gitlab.archlinux.org/archlinux/bugbuddy/-/issues/1). To assign yourself to unconfirmed issues related to your own packages, simply react to the control issue by using the magnifying glass emoji. This action will modify bugbuddy's behavior and ensure that you are assigned alongside the bug wranglers to unconfirmed issues within your domain. ## Rollout Timeline If no significant issues arise, we will proceed with the rollout in approximately 2 weeks. This entails disabling login on Flyspray and importing all bugs into GitLab. Subsequently, Flyspray will be replaced with static sites to preserve historical data for some time. ## User Signup The primary challenge we face currently is the account setup in Keycloak, as we have temporarily disabled signup in GitLab due to a high volume of spam. We discussed potential solutions during the Arch Summit 2023 to address the spam issue and allow users to sign up without requiring manual approval. Our DevOps team is actively working on resolving this spam issue to enable account signup for the migration. Meanwhile, the DevOps team will make every effort to promptly create the accounts. Cheers, Levente, Christian & Jelle

3 3

Winter is coming - orphan cleanups
by Jelle van der Waa 25 Nov '23

25 Nov '23

Hi all, Winter is coming and I am looking at orphans in our repos which I would propose to move to the AUR in a week if no one adopts them: - gambit-c - midori - vim-align - vim-pastie - uhttpmock - tty-proggy-clean - tcacpi-bat - archey3 - aurphan - autocutsel - cherrytree - gdlmm - gv - howl - hyena - icecast - libgsystem - libident - libnl1 - libxml++2.6-docs - livewallpaper - ollama-cuda - poppler-sharp - python-aiohttp-cors - python-cx-freeze - python-gnuplot - python-ibm-db-sa - python-magic-filter - razercfg - rhino-javadoc - sparkleshare - zsh-theme-powerlevel10k Greetings, Jelle van der Waa

1 0

bash 5.2.x status
by Tobias Powalowski 29 Oct '23

29 Oct '23

Hi, yesterday anthraxx stated this: - major breakage in potentially a lot of scripts including pacman, dbscripts, devtools and who knows what kind of packages. I tried devtools with 5.2.15 and fixed the only thing I ran into, with this MR: https://gitlab.archlinux.org/archlinux/devtools/-/merge_requests/133 shopt handling seems to have changed a bit. I would like to proceed in getting latest bash version into our distribution. Adding bash 5.2.x to staging or testing repository and start fixing eventually borken stuff. Would this ok for you guys? greetings tpowa -- Tobias Powalowski Arch Linux Developer & Package Maintainer (tpowa) https://www.archlinux.org <http://www.archlinux.org> tpowa(a)archlinux.org Archboot Developer https://bit.ly/archboot St. Martin-Apotheke Herzog-Georg-Str. 25 89415 Lauingen https://www.st-martin-apo.de info(a)st-martin-apo.de

3 5

Arch Linux in September 2023
by Levente Polyak 22 Oct '23

22 Oct '23

## Staff We would like to welcome [Fabian Bornschein (fabiscafe)][0] as part of the Arch Linux Package Maintainer team. ## Bug weekend During the 1st to 3rd of September, we conducted a [bug weekend][1] with the aim of resolving old bugs and implementing proposed solutions. This effort not only reduced the backlog but also contributed to streamlining the upcoming bug tracker migration, resulting in the resolution of approximately 200 bugs. ## devtools We've [released devtools v1.0.4][2], concentrating on bug fixes. Additionally, we implemented unique scope names for nspawn containers, enabling them to fit within a slice hierarchy for better resource management. Also, we now generate a `.SRCINFO` file in the Git repository, simplifying the retrieval of release and source metadata. ## OCI images With the exception of the official DockerHub library image, all [Arch Linux OCI images][3] are now [signed using the built-in sigstore feature][4] in podman and can be verified through cosign. ## RFC We [proposed and accepted an RFC][5] to extend our `LDFLAGS` in order to reduce the size of relocations. You can find more details about [this RFC][5] on GitLab. By making this change, we ensure to reduce the installed size of native packages. ## systemd-boot Starting from version `254.2-1`, the systemd package includes [IA32 systemd-boot EFI binaries][6]. This change allows users with IA32 UEFI systems to opt for the more straightforward [systemd-boot][7] instead of being restricted to the Grub bootloader. ## TU bylaws In September, we discussed and implemented a [change in the Trusted User Bylaws][8]. This update migrates proposed amendments to be submitted as GitLab merge requests, streamlining our workflows and aligning with modern practices applied across our distribution. [0]: https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/t… [1]: https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o… [2]: https://gitlab.archlinux.org/archlinux/devtools/-/releases/v1.0.4 [3]: https://gitlab.archlinux.org/archlinux/archlinux-docker#arch-linux-oci-imag… [4]: https://gitlab.archlinux.org/archlinux/archlinux-docker/-/merge_requests/77 [5]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/23 [6]: https://bugs.archlinux.org/task/79531 [7]: https://wiki.archlinux.org/title/systemd-boot [8]: https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/m…

1 0

dbscripts leftover packages in staging and testing
by Levente Polyak 21 Oct '23

21 Oct '23

Hi all, this is mostly a notification mail about some inconsistencies with dbscripts where under specific circumstances some leftover packages remain in staging or testing. This issue seems to exist since the last major rollout in June. There seem to be at least two different bugs involved, one in `db remove` and another one in `db move`. I've tracked down the `db remove` one, and am debugging the other issue which also affects libreoffice. I've also written an `fsck` script to detect issues inside the pacman binary repo or within the dbscripts state repo. It seems since June this lead to around 15 occurrences. If you encounter a new leftover package, please feel welcomed to send me a ping. I'm happy to try to help you, or just check if it may be a new or an existing issue. However, there isn't any actionable for packagers for the time being as leftover packages can't be manually removed via `db remove`. I'll correct the inconsistencies as soon as the bug is resolved. Hope this helps one or the other packager to get some insights into the existence of this issue. Cheers, Levente

1 1

News Draft: Incoming changes in JDK / JRE packages may require manual intervention
by Leonidas Spyropoulos 12 Oct '23

12 Oct '23

We are introducing a change in JDK/JRE packages of our distro. This is triggered from the way a JRE is build in modern versions of Java (>9). To sum it up instead of having JDK and JRE packages coexist in the same system we will be making them conflict. The JDK variant package includes the runtime environment to execute Java applications so if one needs compilation and runtime of Java they need only the JDK package in the future. If, on the other hand, they need just runtime of Java then JRE (or jre-headless) will work. This will (potentially) require a manual user action during upgrade: if users have both JDK and JRE installed the can manually install the JDK with pacman -Sy jdk-openjdk and this remove the JRE related packages. if users have both JRE and JRE-headless they will need to choose one of them and install it manually since they would conflict each other now. If they only have one of the JDK/JRE/JRE-headless pacman should resolve dependencies normally no user action is needed. The above are also valid for Java 17 and Java 11 packages as well but not for Java 1.8 since they don’t support modules. -- Leonidas Spyropoulos Developer & DevOps PGP: 59E43E106B247368

1 0

Incoming changes in JDK /JRE packages
by Leonidas Spyropoulos 09 Oct '23

09 Oct '23

Hello, We are introducing a change in JDK/JRE packages of our distro. This is triggered from the way a JRE is build in modern versions of Java (>9). To sum it up instead of having JDK and JRE packages coexist in the same system we will be making them conflict. The JDK variant package includes the runtime environment to execute Java applications so if one needs compilation and runtime of Java they need only the JDK package in the future. If, on the other hand, they need just runtime of Java then JRE (or jre-headless) will work. This will (potentially) require a manual user action during upgrade: - if users have both JDK and JRE installed the can manually install the JDK with `pacman -Sy jdk-openjdk` and this remove the JRE related packages. - if users have both JRE and JRE-headless they will need to choose one of them and install it manually since they would conflict each other now. - If they only have one of the JDK/JRE/JRE-headless pacman should resolve dependencies normally no user action is needed. The above are also valid for Java 17 and Java 11 packages as well but not for Java 1.8 since they don't support modules. Cheers, -- Leonidas Spyropoulos Developer & DevOps PGP: 59E43E106B247368

1 0

RFC Final Comment Period: Add -Wl,-z,pack-relative-relocs
by Jan Alexander Steffens (heftig) 25 Sep '23

25 Sep '23

An RFC has now entered its 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/23 Please visit the above link for discussion. Summary: Add -Wl,-z,pack-relative-relocs to our LDFLAGS in order to reduce the size of relocations.

2 1

News Draft: Default password hashing algorithm changed to yescrypt
by David Runge 20 Sep '23

20 Sep '23

Hi all, with shadow 4.14.0 I introduced some changes to default password hashing algorithms and would like to post the following on the website once the relevant packages (filesystem, pambase, shadow) move to [core]: ```markdown With shadow >= `4.14.0`, Arch Linux's default password hashing algorithm changed from `SHA512` to [yescrypt](https://www.openwall.com/yescrypt/) and [PAM](https://wiki.archlinux.org/title/PAM) honors the chosen `ENCRYPT_METHOD` in /etc/login.defs. While this should not require any direct user intervention, do note that since we now fully integrate with PAM the `YESCRYPT_COST_FACTOR` setting in `/etc/login.defs` is currently without effect, until [PAM implements reading its value](https://github.com/linux-pam/linux-pam/issues/607). If a `YESCRYPT_COST_FACTOR` higher (or lower) than the default (`5`) is needed, it can be set using the `rounds` option of the [pam_unix](https://man.archlinux.org/man/pam_unix.8) module (i.e. in /etc/pam.d/system-auth). Furthermore, additional changes in the filesystem (>= `2023.09.18`) and pambase (>= `20230918`) packages now ensure [umask](https://man.archlinux.org/man/umask.1p) being set centrally in /etc/login.defs instead of /etc/profile. ``` Best, David -- https://sleepmap.de

1 2

Bug Day
by Jelle van der Waa 17 Sep '23

17 Sep '23

Hey All, I'd like to propose that we have a bug weekend on 1-3 September to clean up our bug tracker before we fully migrate it to Gitlab. We already have less issues then before! [1] But getting the number of issues to be migrated down would be a good thing and make our users happy :-) There is a list of "easy" of fail to build from source and issues with patches. [2] [3] Most of the coordination should happen on #archlinux-bugs on libera.chat. [1] https://dashboards.archlinux.org/d/c9a9b812-a067-4534-96bf-c21ba7a0c47d/fly… [2] https://bugs.archlinux.org/index.php?string=FTBFS&project=0 [3] https://bugs.archlinux.org/index.php?string=&project=0&opened=loqs Greetings, Jelle van der Waa

2 4

News Draft: ppp >= 2.5.0-1 update may require manual intervention
by Felix Yan 14 Sep '23

14 Sep '23

As you may or may not have noticed, both `ppp` and `rp-pppoe` package used to ship a `rp-pppoe.so` and they are not 100% compatible. Back in 2021, ppp 2.4.9 starts to rename its own copy of `rp-pppoe.so` to `pppoe.so`. As of `ppp 2.5.0`, upstream decided to remove the `rp-pppoe.so` symlink and thus broke configurations with the old name. If you still have the old ppp package's `rp-pppoe.so` configured somewhere (likely in /etc/ppp/peers/), please update it to use just `pppoe.so`. Configurations with the same plugin from the `rp-pppoe` package (using full path like /usr/lib/rp-pppoe/rp-pppoe.so) are not affected. -- Regards, Felix Yan

3 3