July 2024 - 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

Ruby 3.2.4
by Andreas 'Segaja' Schleifer 09 Aug '24

09 Aug '24

Hello, after a lot of work and some wrong avenues we are finally ready to update Ruby in Arch Linux to version 3.2.4. For this we will block staging from tomorrow (09.05.2024) on to do the rebuild, and it might take some time to complete. At the same time we also replace the approach of providing an /etc/gemrc with the more up-to-date approach of providing an operating_system.rb for ruby to rely on. This should solve several issues currently open for the ruby and the rubygems package. We know that Ruby 3.2.4 isn’t the latest version but we decided to do this one and maybe in a couple of months update to ruby 3.3.x once we are sure it is ready. During the update we will also drop some ruby default gem packages which are not needed anymore as we will not de-vendor all ruby defaultgems in the future. There might arise some dependency issues but we will have to face them when we see them. Best regards Segaja

1 3

Away until 2024-08-12
by David Runge 30 Jul '24

30 Jul '24

Hi all, I'll be on holidays from tomorrow until 2024-08-12 and only sporadically read mails etc. Please feel free to bump/move packages I maintain. Have a good summer! :) Best, David -- https://sleepmap.de

1 0

Resignation
by Florian Pritz 28 Jul '24

28 Jul '24

Hi, Sadly I have no longer had the time necessary to properly handle master key holder and packager duties for a while now. I don't feel like it's fair to you guys and our users to keep this up any longer so I'm officially resigning now. Most pressing topics that come to mind for someone wanting to take over: * I hold a master key, so you'll need to find a new holder for that * perl 5.40 update * various bug reports on Gitlab for my packages * a few flagged packages Thanks for all the nice memories since "[2008-10-19 14:38] installed filesystem (2008.03-2)". While I will no longer be involved in Arch development, I'll still continue to use it and this nice, old install will also continue to live on. Hope to see you guys around :) Florian

5 4

libassuan 3.0.1-1 pulled from testing after crashing pacman
by David Runge 22 Jul '24

22 Jul '24

Hi all, please note that I have just pulled libassuan 3.0.1-1 from core-testing. In this patch-level release some major issues emerged, that break pacman: ``` pacman -Ss test pacman: /usr/lib/libassuan.so.9: version `LIBASSUAN_1.0' not found (required by /usr/lib/libgpgme.so.11) ``` Please note that if you have libassuan 3.0.1-1 installed, you may have to use an installation media or static pacman to get back to 3.0.0-1. I'm very sorry to have caused any inconvenience over this. I will contact upstream about this momentarily. Best, David -- https://sleepmap.de

1 0

Fwd: [PATCH v6] kbuild: add script and target to generate pacman package
by Jan Alexander Steffens (heftig) 16 Jul '24

16 Jul '24

Hi, recently there's been an effort to add a `pacman-pkg` target to the Linux kernel build system, which uses a PKGBUILD to build `linux-upstream` packages for Arch Linux. Since this is of interest to us, I'm forwarding the latest patch email to our list here to give you a chance to provide feedback to the author. I can see this making bisection of kernel issues (or just testing patches) much easier, especially for users. It's also quite an unusual way of calling makepkg. The email is also available at [lore.kernel.org](https://lore.kernel.org/linux-kbuild/20240716-kbuild-pacma…. Greetings, Jan PS: My apologies for sending this twice; the first email was sent with "Markdown" formatting in Evolution, which didn't quite do what I think it would. This one uses "Markdown as HTML", which should have both `text/plain` and `text/html` variants.

1 0

Fwd: [PATCH v6] kbuild: add script and target to generate pacman package
by Jan Alexander Steffens (heftig) 16 Jul '24

16 Jul '24

1 0

AUR Maintenance Saturday 13 July 12:00 UTC
by Jelle van der Waa 13 Jul '24

13 Jul '24

Hi all, We are having some performance issues with the AUR's git repository which requires some maintenance. [1] This means that the AUR will be unavailable for some time starting 12:00 UTC till it is done (hopefully 2 hours, could be more). [1] https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/599

2 1

Urgent news draft: The sshd service needs to be restarted after upgrading to openssh-9.8p1
by Robin Candau 01 Jul '24

01 Jul '24

Hi everyone, As you might have heard by now (or experienced it already), the latest openssh-9.8p1 release requires the sshd daemon to be restarted otherwise new connections cannot establish (the one used to upgrade the package remains intact though). To prevent people from eventually blocking themselves out any further, we would like to introduce a `post_upgrade` transaction for the openssh-9.8p1 package which will restart the sshd service (a MR for that is being worked on [1]), accompanied by an urgent news entry (similarly to what was done for the openssh-8.2p1 release) [2]. Given the urgent aspect of the news, it would be nice to have some quick feedback if possible. I intend to post the news as soon as openssh-9.8p1-2 is released with the `post_upgrade` transaction. --------------- News draft: # The sshd service needs to be restarted after upgrading to openssh-9.8p1 After upgrading to openssh-9.8p1, the existing SSH daemon will be unable to accept new connections. (See https://gitlab.archlinux.org/archlinux/packaging/packages/openssh/-/issues/5). When upgrading remote hosts, please make sure to restart the SSH daemon using `systemctl restart sshd` right after upgrading. If you are upgrading to openssh-9.8p1-2 or higher, this restart will happen automatically. --------------- [1] https://gitlab.archlinux.org/archlinux/packaging/packages/openssh/-/issues/… [2] https://archlinux.org/news/sshd-needs-restarting-after-upgrading-to-openssh… -- Regards, Robin Candau / Antiz

2 2