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

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