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

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

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

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