- Arch-general - lists.archlinux.org

systemd-coredump[1815]: [🡕] Process 808 (named) of user 40 dumped core.
by David C Rankin 26 Feb '26

26 Feb '26

Arch devs, Not sure if this is worth a bug report to Arch? Upstream?, but for the first time in 24 years named core dumped on me (bind 9.20.18-1). The journal entry is: Feb 12 02:54:22 valkyrie named[808]: timed out resolving '240.78.147.in-addr.arpa/NS/IN': 66.76.175.100#53 Feb 12 02:54:23 valkyrie named[808]: timed out resolving '240.78.147.in-addr.arpa/NS/IN': 208.180.42.100#53 Feb 12 02:54:24 valkyrie named[808]: timed out resolving '240.78.147.in-addr.arpa/NS/IN': 8.8.4.4#53 Feb 12 02:54:24 valkyrie named[808]: network unreachable resolving '240.78.147.in-addr.arpa/NS/IN': 2001:500:f0::63#53 Feb 12 02:54:25 valkyrie named[808]: host unreachable resolving '119.240.78.147.in-addr.arpa/PTR/IN': 147.78.247.25#53 Feb 12 02:54:25 valkyrie named[808]: named: src/unix/udp.c:292: uv__udp_recvmsg: Assertion `handle->recv_cb != NULL' failed. Feb 12 02:54:25 valkyrie systemd-coredump[1815]: [🡕] Process 808 (named) of user 40 dumped core. Stack trace of thread 849: #0 0x00007fbcbc53da2c n/a (libc.so.6 + 0x98a2c) #1 0x00007fbcbc4e31a0 raise (libc.so.6 + 0x3e1a0) #2 0x00007fbcbc4ca5fe abort (libc.so.6 + 0x255fe) #3 0x00007fbcbc4cb697 n/a (libc.so.6 + 0x26697) #4 0x00007fbcbc4db0b2 __assert_fail (libc.so.6 + 0x360b2) #5 0x00007fbcbcdc7246 n/a (libuv.so.1 + 0xa246) #6 0x00007fbcbcdd1985 n/a (libuv.so.1 + 0x14985) #7 0x00007fbcbcde7ad4 n/a (libuv.so.1 + 0x2aad4) #8 0x00007fbcbcdd2b12 uv_run (libuv.so.1 + 0x15b12) #9 0x00007fbcbd278700 n/a (libisc-9.20.18.so + 0x4b700) #10 0x00007fbcbd28aef0 n/a (libisc-9.20.18.so + 0x5def0) #11 0x00007fbcbc53b97a n/a (libc.so.6 + 0x9697a) #12 0x00007fbcbc5bf2bc n/a (libc.so.6 + 0x11a2bc) ... I've run bind since 2002, and on Arch since 2009 and never in all that time had it crash. The whois on 147.78.247.25 is also rather interesting, a rent-a-server shop with US and Japanese corporate registration info. Given the uniqueness of this crash, there probably should be a report, but I'm not sure if it should go to Arch or ISC (or both with the gitlab bug just tracking upstream) What say the Arch folks? Bug needed? If so, start with Arch, ISC or both? (or maybe freedesktop? but that didn't seem like it was involved other than catching the crash) -- David C. Rankin, J.D.,P.E.

2 1

pacman -Syu listing as a column?
by StyxSailor 25 Feb '26

25 Feb '26

Hi, apologies for the very basic question, but I've relatively recently switched to Arch and am trying to improve my practices, in this case by actually reading what packages will be updated before just leisurely pressing `Y' (what are your habits?). However, when running `pacman -Syu', there is a long line of packages listed rather than in a column, which makes it hard to read. Is it possible to get the listing in a column to make it easier to read before updating? Cheers, Styx

6 6

Help needed
by t+linux＠elaboris.de 19 Feb '26

19 Feb '26

Dear Linux Experts, my name is Tanja Schaaf and I live in Frankfurt. My husband, Markus Schaaf (mschaaf), was sometimes posting emails to Archlinux-Group, but I think in the last few years he was not so active any more. Unfortunately, he passed away last year in November and I stuck with my zero knowledge about Linux - I hope somebody can help me. I apologize already for my missing knowledge, asking stupid questions and being confused. All computers in our home are running (or not) on Linux Manjaro. My major problem is laptop from Markus - I have a password, but the laptop is locked and I do not know how to unlock it. I get the message: "You are in emergency mode. After logging in, type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, or "exit" to continue bootup." It doesn't matter what I do, I get the next message: "Cannot open access to console, the root account is locked. see sulogin(8( man page for more details. Press enter to continue." After that the system is asking for password and after typing the pw it jumps back to: "You are in emergency mode..." and so on and so on.... I think, it is not needed to write how down I am, especially for the reason that all important info is on his laptop - like PgGP key for his importand emails, which I cannot open now as the key is missing. Would somebody have time to help me? Regards Tanja

5 5

The NVIDIA 590 driver notice
by Mark E. Mallett 17 Feb '26

17 Feb '26

Hi, There was a notice on arch-announce and on archlinux.org/news ( https://archlinux.org/news/nvidia-590-driver-drops-pascal-support-main-pack… ) that confuses me. "With the update to driver version 590, the NVIDIA driver no longer supports Pascal (GTX 10xx) GPUs or older" etc. I don't really know if that applies to me, given the brand/model labels and all. (some detail about my hardware is offered at the end of this message.) And even if it does, the notice is (to my dull mind) unclear. It says: Updating the NVIDIA packages on systems with Pascal, Maxwell, or older cards will fail to load the driver, which may result in a broken graphical environment. That would be bad and makes me hesitent to experiment. Part of what confuses me is this: Users with GTX 10xx series and older cards must switch to the legacy proprietary branch to maintain support I'm using the proprietary nvidia driver already, so what does that statement mean to me? (I'm not running nouveau or other) So I have questions - the one above ("does this mean me?") - the one about already using the proprietary driver - can I simply not upgrade the nvidia driver, keep using the installed one? - If the system breaks, what is my recourse? - Is "Install nvidia-580xx-dkms from the AUR" (as it says) appropriate for me? I know this sounds like a lot of foggy nonunderstanding, and I guess that's because that's what it is. The relevant system has a very old NVIDIA card. I haven't seen any reactions to this, maybe I'm the only one left ;) Possibly relevant stuff from hwinfo: 22: PCI 100.0: 0300 VGA compatible controller (VGA) [Created at pci.395] Unique ID: VCu0.4tATP2A+FnB Parent ID: 8otl.w6ofvOouCK2 SysFS ID: /devices/pci0000:00/0000:00:04.0/0000:01:00.0 SysFS BusID: 0000:01:00.0 Hardware Class: graphics card Model: "nVidia GM206 [GeForce GTX 960]" Vendor: pci 0x10de "nVidia Corporation" Device: pci 0x1401 "GM206 [GeForce GTX 960]" SubVendor: pci 0x1462 "Micro-Star International Co., Ltd. [MSI]" SubDevice: pci 0x3201 Revision: 0xa1 Driver: "nvidia" Driver Modules: "nvidia" Memory Range: 0xfd000000-0xfdffffff (rw,non-prefetchable) Memory Range: 0xd0000000-0xdfffffff (ro,non-prefetchable) Memory Range: 0xce000000-0xcfffffff (ro,non-prefetchable) I/O Ports: 0xcc00-0xcc7f (rw) Memory Range: 0x000c0000-0x000dffff (rw,non-prefetchable,disabled) IRQ: 27 (1392224 events) Module Alias: "pci:v000010DEd00001401sv00001462sd00003201bc03sc00i00" Driver Info #0: Driver Status: nouveau is not active Driver Activation Cmd: "modprobe nouveau" Driver Info #1: Driver Status: nvidia_drm is active Driver Activation Cmd: "modprobe nvidia_drm" Driver Info #2: Driver Status: nvidia is active Driver Activation Cmd: "modprobe nvidia" Config Status: cfg=new, avail=yes, need=no, active=unknown Attached to: #20 (PCI bridge) Thanks for any attention. -mm- (long time no write)

10 15

Update orphan package mill
by Gonsolo 11 Feb '26

11 Feb '26

Hi! Mill in Arch is nearly three years old: https://archlinux.org/packages/extra/any/mill/ https://github.com/com-lihaoyi/mill/releases/tag/0.11.0 I have a MR for updating it: https://gitlab.archlinux.org/archlinux/packaging/packages/mill/-/merge_requ… But since it is orphaned it can't be updated. It also can't be moved to AUR. Is there really no way forward? Thanks -- Andreas

3 2

Re: KDE plasma login stalls with Wayland
by SET 10 Feb '26

10 Feb '26

Le jeudi 5 février 2026 20:00:28 heure normale d’Europe centrale sprungles.me a écrit : > If you are needing to get the maintainer, I figured out the culprit is the ddcutil package. It is reported here also: https://gitlab.archlinux.org/archlinux/packaging/packages/ddcutil/-/issues? show=eyJpaWQiOiI1IiwiZnVsbF9wYXRoIjoiYXJjaGxpbnV4L3BhY2thZ2luZy9wYWNrYWdlcy9kZGN1dGlsIiwiaWQiOjIyMzQ2NX0%3D Thank you for your reply.

1 1

Re: glibc 2.43 in testing - moving to stable repos affected
by Genes Lists 10 Feb '26

10 Feb '26

On Tue, 2026-02-10 at 11:45 +0100, Frederik Schwan wrote: > I've pushed glibc 2.43 to testing. Do not move packages linked > against 2.43 to extra or core until glibc itself moves around > Thursday/Friday. > Otherwise the package will probably break. > > Best regards, > Frederik Hi Frederik I wonder if the compile error below might be related to this update since it seems to have just started happening. May not be related of course. Either way, it would be great if someone can suggest a fix for this build error? test machine is updated using testing repos. i.e. binutils 2.46-1 gcc 15.2.1+r604+g0b99615a8aef-1 glibc 2.43+r5+g856c426a7534-1 python 3.14.2-2 Building libcamera gets macro conflicts between the definitions from glibc vs python. This could be happening because libcamera compiles with -std=c++17. What I see is that: /usr/include/features.h (glibc) vs /usr/include/python3.14/pyconfig.h (python) and features.h defines _POSIX_C_SOURCE values of - 200809L varies depending on _XOPEN_SOURCE - 202405L if _GNU_SOURCE is set On other hand, pyconfig.h fixes the value to 2008: /* Define to activate features from IEEE Stds 1003.1-2008 */ #define _POSIX_C_SOURCE 200809L which "suggests" that this is the value libcamera should also use maybe? Building libcamera started having these errors (similar ones for _XOPEN_SOURCE as well): /usr/include/python3.14/pyconfig.h:2007:9: error: ‘_POSIX_C_SOURCE’ redefined [-Werror] 2007 | #define _POSIX_C_SOURCE 200809L /usr/include/features.h:319:10: note: this is the location of the previous definition 319 | # define _POSIX_C_SOURCE 202405L Happens with both the current version (0.7.0) as well as git head of libcamera. thank you for any guidance gene

1 0

Marginal trusted pacman developer
by Ralf Mardorf 09 Feb '26

09 Feb '26

Hi, I know that pacman-static is not an official repository, but it's about the signature of a staff member, https://archlinux.org/people/support-staff/ . Is it an accident or on purpose? I temporarily commented out pacman-static in pacman.conf and uninstalled the pacman-static package. Regards, Ralf PS: $ sudo pacman -Syu error: pacman-static: signature from "Morgan Adamiec <morganamilo(a)archlinux.org>" is marginal trust :: Synchronizing package databases... core is up to date extra is up to date multilib is up to date proaudio is up to date chaotic-aur is up to date pacman-static 544.0 B 7.70 KiB/s 00:00 [...] 100% error: pacman-static: signature from "Morgan Adamiec <morganamilo(a)archlinux.org>" is marginal trust error: failed to synchronize all databases (invalid or corrupted database (PGP signature)) [2026-02-06T18:27:57+0100] [ALPM] upgraded archlinux-keyring (20260202-1 -> 20260206-1) [2026-02-06T18:27:58+0100] [ALPM-SCRIPTLET] ==> Appending keys from archlinux.gpg... [2026-02-06T18:27:59+0100] [ALPM-SCRIPTLET] ==> Disabling revoked keys in keyring... [2026-02-06T18:27:59+0100] [ALPM-SCRIPTLET] -> Disabled 1 key. [2026-02-06T18:27:59+0100] [ALPM-SCRIPTLET] ==> Updating trust database... [2026-02-06T18:28:00+0100] [ALPM-SCRIPTLET] gpg: marginals needed: 3 completes needed: 1 trust model: pgp [2026-02-06T18:28:00+0100] [ALPM-SCRIPTLET] gpg: depth: 0 valid: 1 signed: 10 trust: 0-, 0q, 0n, 0m, 0f, 1u [2026-02-06T18:28:00+0100] [ALPM-SCRIPTLET] gpg: depth: 1 valid: 10 signed: 85 trust: 1-, 0q, 0n, 9m, 0f, 0u [2026-02-06T18:28:00+0100] [ALPM-SCRIPTLET] gpg: depth: 2 valid: 72 signed: 26 trust: 72-, 0q, 0n, 0m, 0f, 0u [2026-02-06T18:28:00+0100] [ALPM-SCRIPTLET] gpg: next trustdb check due at 2026-03-13

2 2

Arch Wiki SSL Error
by starquake 09 Feb '26

09 Feb '26

Hello, It seems the Arch Wiki is down. https://wiki.archlinux.org/ in Firefox gives me a SSL_ERROR_INTERNAL_ERROR_ALERT. Thought it would be a good idea to report. Have a nice day! starquake

3 2

make pacman-pkg: where to ask for help about cross-compiling
by SET 08 Feb '26

08 Feb '26

Hello, The actual problem may concern - this forum - the archlinuxarm forum - the kernel help channels. It is about building kernel packages with 'make pacman-pkg' using a cross- compiler on an x86_64 host. All packages are generated for aarch64. For arm, only the 'linux-upstream' package is created successfully. The next package generation fails, linux-upstream-headers. Using these environment variables: export ARCH=arm export CROSS_COMPILE=arm-none-eabi- If help can be expected here, I'll further post the stderr messages, so as to shorten this post. Thank you for any input.

2 4