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

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

16 May '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);}

3 3

Re: pre-releases (for systemd & co) in core-testing
by Christian Hesse 15 May '24

15 May '24

Randy DuCharme <radio.ad5gb(a)gmail.com> on Wed, 2024/05/15 05:06: > Suggestion (s). This is open source real life comes first, always. > > People that volunteer to help are genuinely real but being ignored wins > ZERO.... even if they have 27 years of C C++ No idea what you want to tell me... Really. Please try again if this is a serious suggestion related to the topic. -- 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);}

1 0

Mesa pulled from testing
by Jan Alexander Steffens (heftig) 08 May '24

08 May '24

I've removed Mesa 1:24.0.7-1 from testing as the radeonsi driver crashes immediately, somewhere deep in LLVM. This concerns the following packages: • libva-mesa-driver • mesa • mesa-vdpau • opencl-clover-mesa • opencl-rusticl-mesa • vulkan-intel • vulkan-mesa-layers • vulkan-nouveau • vulkan-radeon • vulkan-swrast • vulkan-virtio • lib32-libva-mesa-driver • lib32-mesa • lib32-mesa-vdpau • lib32-opencl-clover-mesa • lib32-opencl-rusticl-mesa • lib32-vulkan-intel • lib32-vulkan-mesa-layers • lib32-vulkan-nouveau • lib32-vulkan-radeon • lib32-vulkan-swrast • lib32-vulkan-virtio

1 0

Ruby 3.2.4
by Andreas 'Segaja' Schleifer 08 May '24

08 May '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 0

Orphaning some packages
by Chih-Hsuan Yen 04 May '24

04 May '24

Hi all, I'm going to orphan some packages that I no longer need or depend on, so that I can better focus on my other packages. Here is the package list: * fcitx-chewing * nextcloud-client * python-nbdime * python-nbval * python-openpyxl * python-pg8000 * python-prctl * python-scramp * python-sure * python-testing.postgresql (may be dropped - depends on python-nose, no upstream commits since 2017) * scim-chewing * web-ext Please adopt packages you need, thanks! Best Regards, Chih-Hsuan Yen (yan12125)

1 0

time64 ABI fix coming to upstream glibc
by Florian Weimer 02 May '24

02 May '24

The <utmp.h> and <utmp.h> headers had a bug that the on-disk structures defined there could change size on some targets when _TIME_BITS was set to 64. This is obviously wrong because the files are not going to magically change their layout because the application accessing them was built in a specific way. We're going to fix this in glibc upstream on the stable release branches, going all the way back to glibc 3.34 (the first release with this kind of time64 support). After the fix, the _TIME_BITS definition will no longer impact struct layout. Usually, that means epoch fields are 32-bits wide, to match co-installable architectures. To extend the usable life-time of these interfaces somewhat, glibc 2.40 changes epoch fields to unsigned types in these structures. This change is specific to the upcoming glibc 2.40 release, I do not plan to backport it. Thanks, Florian

1 0