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

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

Dropping orphan Python packages
by Jelle van der Waa 02 Oct '24

02 Oct '24

Hi all, It's autumn and Python 3.13 is soon to be released, to not rebuild unrequired packages I propose to drop these orphan unrequired packages Sunday 6 October. If anyone wants to pick an orphan up please reply to this email. python-sphinx-typlog-theme python-requests-hawk python-pyvcd python-olm python-biopython python-flask-httpauth python-fxa python-ipyxact python-listparser Greetings, Jelle

1 0

RFC Final Comment Period: Mirror definition - Proposal for new mirror administration routines and mirror requirements
by pitastrudl 01 Oct '24

01 Oct '24

An RFC has now entered its Final Comment Period. In 14 days, discussion will end and the proposal will either be accepted, rejected or withdrawn: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/29 Please visit the above link for discussion. Summary: Before this proposal, all tasks surrounding mirrors were manual and in free-text form. This RFC therefore outlines the definitions and guidelines surrounding both becoming but also maintaining and decommissioning a mirrors in a new format using TOML and GitLab.

1 0