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

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