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

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