October 2024 - Arch-general - lists.archlinux.org

Periodic aged package report
by Genes Lists 11 Oct '24

11 Oct '24

Periodic check of Arch out of date packages. This considered are purely my opinion of those that are sufficiently 'relevant'. Apologies to any others. The really good news is that there really aren't many ! Big congrats for the hard work keeping Arch awesome and up to date. Note that, some are excluded when they are work in progress and/or involve a significant amount of work (provided they are not "too" old, which none are). Arch is doing an amazing job keeping our core/key packages like compiler tools, python, systemd, kernel and other vital packages very up to date. What remains are a few that are relevant enough (imho) to make the list. I am using 3 metrics of age: - Num-B The number of releases we are behind Some packages have frequent updates some do not. - Age The number of days between the arch version and the latest - New: How recent was the latest released (days ago from today) Package Arch Curr Date num-b Age New ------------------ ---------- ------ -------- ------ ------ ---- apparmor 3.1.7-5 4.0.3 08/15/24 4 195 55 biber 1:2.19-4 2.20 03/21/24 1 321 202 dkms 3.0.12-1 3.1.0 10/01/24 2 373 8 python-cryptography 42.0.8-1 43.0.1 09/03/24 2 91 36 python-setuptools 1:69.5.1-1 75.1.0 09/13/24 22 153 26 yubioath-desktop 5.1.0-3 7.1.0 09/25/24 12 1234 14 (1) (1) Now called yubico-authenticator -- Gene

5 7

Valgrind problem
by Frank 07 Oct '24

07 Oct '24

Good evening, I'm trying to debug an issue with Evolution and the Gnome guys asked me to use valgrind. However, when running this command I get an error I'm stuck with: valgrind --num-callers=30 --leak-check=no --track-origins=yes /usr/lib/evolution-calendar-factory -w ==4915== Memcheck, a memory error detector ==4915== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al. ==4915== Using Valgrind-3.23.0 and LibVEX; rerun with -h for copyright info ==4915== Command: /usr/lib/evolution-calendar-factory -w ==4915== valgrind: Fatal error at startup: a function redirection valgrind: which is mandatory for this platform-tool combination valgrind: cannot be set up. Details of the redirection are: valgrind: valgrind: A must-be-redirected function valgrind: whose name matches the pattern: strcmp valgrind: in an object with soname matching: ld-linux-x86-64.so.2 valgrind: was not found whilst processing valgrind: symbols from the object with soname: ld-linux-x86-64.so.2 valgrind: valgrind: Possible fixes: (1, short term): install glibc's debuginfo valgrind: package on this machine. (2, longer term): ask the packagers valgrind: for your Linux distribution to please in future ship a non- valgrind: stripped ld.so (or whatever the dynamic linker .so is called) valgrind: that exports the above-named function using the standard valgrind: calling conventions for this platform. The package you need valgrind: to install for fix (1) is called valgrind: valgrind: On Debian, Ubuntu: libc6-dbg valgrind: On SuSE, openSuSE, Fedora, RHEL: glibc-debuginfo valgrind: valgrind: Note that if you are debugging a 32 bit process on a valgrind: 64 bit system, you will need a corresponding 32 bit debuginfo valgrind: package (e.g. libc6-dbg:i386). valgrind: valgrind: Cannot continue -- exiting now. Sorry. THX Frank

3 4

Delayed responsiveness on resume after upgrade
by SET 07 Oct '24

07 Oct '24

Hello, I just upgraded a host and noticed a waiting of about 90s before the desktop (KDE) becomes responsive (typing to unlock the screen, the mouse cursor can be moved). This was not the case before the upgrade. This box has 3 remote shares attached via sshfs. The delay to responsiveness is near immediate if it is suspended while the remote shares are not connected. With remote shares connected on suspend: [Sat Oct 5 12:05:03 2024] OOM killer enabled. [Sat Oct 5 12:05:03 2024] Restarting tasks ... done. [Sat Oct 5 12:05:03 2024] random: crng reseeded on system resumption [Sat Oct 5 12:05:03 2024] PM: suspend exit [Sat Oct 5 12:05:03 2024] r8169 0000:06:00.0 eth0: Link is Up - 1Gbps/ Full - flow control off [Sat Oct 5 12:06:35 2024] r8169 0000:06:00.0 eth0: Link is Down [Sat Oct 5 12:06:35 2024] Generic FE-GE Realtek PHY r8169-0-600:00: attached PHY driver (mii_bus:phy_addr=r8169-0-600:00, irq=MAC) [Sat Oct 5 12:06:35 2024] r8169 0000:06:00.0 eth0: Link is Down [Sat Oct 5 12:06:39 2024] r8169 0000:06:00.0 eth0: Link is Up - 1Gbps/ Full - flow control off With remote shares disconnected on suspend: [Sat Oct 5 12:10:55 2024] OOM killer enabled. [Sat Oct 5 12:10:55 2024] Restarting tasks ... done. [Sat Oct 5 12:10:55 2024] random: crng reseeded on system resumption [Sat Oct 5 12:10:55 2024] PM: suspend exit [Sat Oct 5 12:10:55 2024] Generic FE-GE Realtek PHY r8169-0-600:00: attached PHY driver (mii_bus:phy_addr=r8169-0-600:00, irq=MAC) [Sat Oct 5 12:10:56 2024] r8169 0000:06:00.0 eth0: Link is Down [Sat Oct 5 12:10:58 2024] r8169 0000:06:00.0 eth0: Link is Up - 1Gbps/ Full - flow control off It seems that the network link remains 'up' when the remote shares are connected, then has to go down and that's where the delay lies. Afterwards, it quickly returns to the up state. 'modinfo r8169' does not expose any option at all. I wish to know if there's a simple known solution to quickly resume the host. The root cause could also lie deep in the kernel and may perhaps disappear on a future upgrade. I can live with it, it's just annoying. Thanks for any input.

2 2

Re: Future of salt in our repositories
by Genes Lists 05 Oct '24

05 Oct '24

On Sat, 2024-10-05 at 17:36 +0200, Morten Linderud wrote: > Yo, > > `salt` is a framework for server provisioning, change management and > ... > `salt` as of version `3007` does not support Python 3.12, and the > release `3008` > seems far away, ... > 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 > ... ... > 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. Replying via general. This does indeed make a lot of sense. 'onedir' sounds pretty horrible. It might worthwhile noting that salt was acquired by VMware which in turn was acquired by broadcom a couple years ago. I have no views if this is significant for its future trajectory or not. I wonder if some people might be considering migrating to Ansible or another alternative? thanks for staying on top of things and keeping us informed. gene -- Gene

1 0

Estimate for Linux 6.11 to move from testing to core?
by David C. Rankin 02 Oct '24

02 Oct '24

All, Devs, I've been watching https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/issues to try and get a handle on when to expect the 6.11 kernel. I can't read the tea-leaves very well. Does anyone involved in the process have an estimate of when we should look for the new kernel to be released? I ask because I have one production box to update and want to set aside time in case I have to troubleshoot. Though thankfully, the 6.10 -> 6.11 update looks benign from a server standpoint. Are we just waiting on the i915 shadow frame-buffer issue or one of the other audio issues? -- David C. Rankin, J.D.,P.E.

4 4

Wayland performance issues after upgrading linux and nvidia
by Edward Toroshchyn 02 Oct '24

02 Oct '24

All, Just wanted to drop a short FYI here, in case you've also encountered issues running Wayland after updating linux (6.10.10.arch1-1 -> 6.11.1.arch1-1) and nvidia (560.35.03-6 -> 560.35.03-9). For me, downgrading helped: # cd /var/cache/pacman/pkg/; pacman -U nvidia-560.35.03-3-x86_64.pkg.tar.zst linux-6.10.8.arch1-1-x86_64.pkg.tar.zst I've reported the issue here: https://gitlab.archlinux.org/archlinux/packaging/packages/nvidia/-/issues/9 Worm regards, -- Edward

1 0