June 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

Taking a break soon
by Orhun Parmaksiz 27 Jun '24

27 Jun '24

Hey! I will be taking a break from computers between the dates 29-06-2024 and 26-07-2024. During this period I won't have access to the internet so I will be pretty much unreachable. But if there is something hella urgent drop me a call on my cell - I might or might not call back. Let me know if there is anything (in the following days) and feel free to bump my packages. P.S. everything is fine, just need some time to reset :) Have a nice summer everyone!

2 1

glib2-devel split from glib2
by Jan Alexander Steffens (heftig) 12 Jun '24

12 Jun '24

Hi, Thanks to Fabian, as of 2.80.3-1, the development utilities requiring additional dependencies (*python*, *python-packaging*, *libelf*) have been split from *glib2* into *glib2-devel* with proper depends. You may need to add *glib2-devel* to the makedepends of your packages to get them to build again. At the same time, consider removing *python* or *python-packaging* from the makedepends if they were only added to run gdbus-codegen, glib-genmarshal or glib-mkenums. Greetings, Jan

1 0

pre-releases (for systemd & co) in core-testing
by Christian Hesse 08 Jun '24

08 Jun '24

Hello everybody, I used to push later pre-releases for essential core packages (for example systemd and util-linux) to core-testing. The idea was to have some extra testing even before building the final packages. For some time this worked quite well... Lately this broke, though. Our current tooling (pkgctl from devtools) builds packages (at least core ones) in core-testing. We then moved a package that was built with util-linux 2.40rc2. It's dynamic linking was ok, but it required the symbol MOUNT_2_40 from libmount.so, still breaking. We had to move the util-linux pre-release packages to core to solve this. Of course this had not been detected before, because packages in testing were ok in that combination. So wondering how to solve this, and have some extra testing anyway. The more people testing pre-release packages the better... Having said that - I have set up a custom repository for now with systemd 256rc2. To test that add these lines to your pacman.conf: [testing] Server = https://pkgbuild.com/~eworm/$repo/$arch/ Feedback welcome! -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

4 7

Adding Emil Velikov as maintainer of libudev0-shim
by Morten Linderud 06 Jun '24

06 Jun '24

Yo, `libudev0-shim` is a udev compat shim that some of our packages, most notably stream, and a few other downstreams utilize. It was written 8 years ago by Dave Reisner and has seen no development since then, but Valve/Steam has sent a couple of changes to this project. I originally asked on IRC if anyone wanted to maintain this, but after no response Emil replied on a PR that he would gladly take over maintainership of this project. Emil has been around for a few years on bugreports and misc patches to upstream projects, and generally is a nice guy. I can't see anyone objecting to this so I've asked devops to add them to the Github repository. This emailserves as a headsup that Emil is now the maintainer of the project. https://github.com/archlinux/libudev0-shim -- Morten Linderud PGP: 9C02FF419FECBE16

1 0