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

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