- Arch-general - lists.archlinux.org

nut UPS shutdown issue after nut upgrade 2.8.2 -> 2.8.4
by Łukasz Michalski 23 Mar '26

23 Mar '26

Hi, A little warning after my 3h debugging nut debugging session: After upgrading nut from 2.8.2 to 2.8.4 /usr/lib/systemd/system-shutdown/nutshutdown script will stop working if MODE in /etc/nut/ups.conf is not set. I have a running standalone configuration with nut driver, server and monitor on single machine and I didn't set MODE in ups.conf. Due to this commit: https://github.com/jimklimov/nut/commit/cccbd8774b1f7d4c749c114e649e6924cba… in 2.8.4 without MODE system shutdown will not issue a shutdown command to UPS anymore. Regards, Łukasz

2 1

davinci-resolve no longer downloads the upstream package; was this actually an AUR rules violation?
by kleines Filmröllchen 19 Mar '26

19 Mar '26

Hello all, this issue has been on my mind for a while, but I haven’t bothered to write to the mailing list about it until now. Before Muflone took over maintainership of the davinci-resolve packages (including davinci-resolve-studio and davinci-resolve-beta), the PKGBUILD would automatically download the upstream package from Blackmagic’s website. While Resolve is proprietary, the non-Studio version (and the beta) are freely available, requiring not even a proper login with the vendor. The download link on the website (https://www.blackmagicdesign.com/products/davinciresolve ) is behind a “registration” form, but this does not create a user account and to the best external knowledge, the data entered here is never verified in any way. Therefore, previous versions of the AUR package either used a download link obtained by the maintainer after filling out the form with arbitrary data, or replayed the form submission with fixed data during prepare(), obtaining a new download link for the user. Either way, the package contents are obviously always identical (regular hashing applied). The same is true for packages retrieved through the support center (https://www.blackmagicdesign.com/support/family/davinci-resolve-and-fusion ), where in fact the Studio version (which requires a paid license) does not require the submission of a form at all. However, Muflone changed this behavior to instead require a locally-downloaded version of the upstream package in all three cases. The user reception for this was mixed, additionally caused by the issue that AUR helpers need the upstream package file located in special cache directories and not the current working directory. Personally, I am strongly opposed to this change, but Muflone has deflected criticism by pointing out that “Packages must not contain black magic or unknown/hard to understand commands as users are required to check the PKGBUILDs before installing/updating from AUR” (https://aur.archlinux.org/packages/davinci-resolve?O=60#comment-1013733 ). While I agree in spirit, I disagree in this specific case. There are multiple easy ways of obtaining the package that have been known for some time; a review of the package commit history confirms this. On the contrary, some of the changes required to make more technical aspects of the package work properly will not be easy to understand for users at times. Furthermore, a careful review of the AUR packages reveals to me that this kind of direct download is perfectly allowed, since in my opinion it doesn’t circumvent any real technical measures by the upstream provider; see elaboration above: form contents are not checked by the Blackmagic website, and sometimes skippable altogether. I’m writing to the mailing list to gain clarification on the matter: whether the manual download is actually more compliant with AUR rules than what was happening previously (before commit 7351177b553aa3983163450822bf251ec7f7ab75), and whether the previous approach was even in violation. If not, I’m not sure—if it’s possible that the AUR maintainers can urge Muflone to change it back, that would be excellent, but I don’t remember the AUR working that way. Blocking Muflone and/or orphaning the package is also not a reasonable approach, unless there is someone to step up to maintainership for the package (unfortunately not me, as I don’t use Resolve frequently enough, and often need to stay on older versions due to bugs frequently introduced in new releases). I hope I’m not overstepping any lines with this request, but as a user of the package it is very annoying when a (new) maintainer degrades the user experience for unclear/nebulous “rules compliance” and refuses to engage in discussions about it. This is also the reason I am writing here in the first place, I want to make it clear that I did of course try to discuss this on the package comment page first; over a year ago in fact. I also finally want to make it clear that this is not about piracy of the Studio version in any way shape or form; while the package download for it is still freely available from Blackmagic, it’s less important to change the PKGBUILD as the software isn’t free in the first place. Greetings, kleines Filmröllchen

1 1

grafana 12.4.0 upgrade error
by Łukasz Michalski 11 Mar '26

11 Mar '26

Hi, I've got following error when upgrading grafana from 12.3.0 to 12.4.0: error="rebuilding indexes failed for org 1 (default): rebuild index error: resource_last_import_time_query.sql: Query with 0 input arguments and 0 output destination arguments: database is locked (5) (SQLITE_BUSY); query: SELECT \"namespace\", \"group\", \"resource\", \"last_import_time\"\n FROM \"resource_last_import_time\";" I filled a bug here: https://github.com/grafana/grafana/issues/119912 Anyone has a solution for this? Thanks, Łukasz

3 3

Age verification question
by Some Guy called 10 Mar '26

10 Mar '26

Will Arch Linux add age verification to comply with Californian laws? Looking forward to your answer!

23 43

Emergency moderation enabled
by Jelle van der Waa 10 Mar '26

10 Mar '26

Hi, The mailing list is now put on emergency moderation, meaning your messages have to be approved by the moderation team before they are accepted. This has been done due to the heated "Age Verification" discussion, insults do not belong on this mailing list. The Arch Linux team is aware of the new California Law and is investigating options, note that this law goes in effect 1 January 2027. So there is currently no rush to implement or decide on a solution. Greetings, Jelle

2 1

pacman -Qdt
by arch.hias＠eilert.tech 09 Mar '26

09 Mar '26

Hello everyone, when I check for orphaned packages with pacman -Qdt, I see packages that were previously set to be installed as explicit. Then I run pacman -D --asexplicit ..., check again with pacman -Qdt, and everything is fine—no orphaned packages. After a future pacman -Syu, reboot, pacman -Qdt I see the same packages again. This affects, for example: libreoffice-still-de, bluez-utils, alsa-tools, inkscape, linux-lts, ncdu, gnuradio-companion, xfce4-whiskermenu-plugin, firefox-i18n-de, discord, chromium. Any hints on what I might be missing? Has anyone had similar experiences? Best regards hias

3 4

6.18.13 and updated mdadm (RAID1) won't boot, dropped to recovery console, LTS fine - help?
by David C Rankin 27 Feb '26

27 Feb '26

All, This is the first fail to boot I've had with Arch in years. After a relatively small update, which went fine on my test machine (no RAID/mdadm), I updated the server and was dropped to recovery console on reboot (mild panic set in looking at the "failed to find ....") The update included the 6.18.13 kernel and mdadm 4.5-1. Those were the only packages I could see that may be relevant to this issue (possibly the firmware) Prior to reboot I'd checked that all drives, etc. wer okay, no journal entries out of the ordinary, etc.. But on reboot, the boot failed and I was dropped to the recovery console. I also have LTS on this box, just for the case where an updated kernel doesn't boot, so instead of groping around half-blind in the recovery console, I rebooted and chose to boot LTS -- all fine. This is where I need help. How do I figure out what failed to cause the new 6.18.13 kernel to not boot? LTS is fine, machine is up, running and happy, just as it was on 6.18.9.arch1-2 (prior kernel). Not finding a driver and dropping to the recovery console leaves no logs, so how do I find out why the new kernel and mdadm package are failing? Should I just downgrade those packages (kernel and mdadm) and see if that works, or is there are more systematic way to approach this. I'm proficient in a lot of areas, but unfortunately diagnosing what went wrong from the recovery console isn't one of them. (I'd generally boot the install CD and chroot the system and go at it that way). Anybody able to provide any guidance on how to recover the 6.18.13 setup, or what information I need to check to see why it's failing? My only inclination is the download and burn a new install CD, chroot and try rebuilding initramfs? Curiously, the new initramfs is quite a bit smaller than LTS: -rw------- 1 root root 10250207 Feb 26 21:42 initramfs-linux-lts.img -rw------- 1 root root 9633236 Feb 26 21:43 initramfs-linux.img I always check the "Latest News" feed for any gotchas before upgrading the server, and there was nothing this time, but... Something went very wrong -- help... The list full list of packages updated were: Packages (70) adwaita-fonts-50.0-1 apparmor-4.1.6-2 bubblewrap-0.11.0-2 ca-certificates-mozilla-3.121-1 cpupower-6.19.3-1 ddrescue-1.30-2 deno-2.7.1-1 fasm-1.73.35-1 feh-3.11.3-1 firefox-148.0-1 gawk-5.4.0-1 giac-2.0.0.21-1 glslang-1:1.4.341.0-2 gpgme-2.0.1-3 gst-libav-1.28.1-1 gst-plugins-bad-1.28.1-1 gst-plugins-bad-libs-1.28.1-1 gst-plugins-base-1.28.1-1 gst-plugins-base-libs-1.28.1-1 gst-plugins-good-1.28.1-1 gstreamer-1.28.1-1 inkscape-1.4.3-4 libfyaml-0.9.5-1 libid3tag-0.16.4-1 libinih-62-2 libkeccak-1.4.3-1 libksba-1.6.8-1 libldac-2.0.2.3-3 libmaxminddb-1.13.2-1 libngtcp2-1.21.0-1 libplacebo-7.360.0-2 libreoffice-still-25.8.5-2 libxmp-4.7.0-1 linux-6.18.13.arch1-1 linux-docs-6.18.13.arch1-1 linux-firmware-20260221-1 linux-firmware-amdgpu-20260221-1 linux-firmware-atheros-20260221-1 linux-firmware-broadcom-20260221-1 linux-firmware-cirrus-20260221-1 linux-firmware-intel-20260221-1 linux-firmware-mediatek-20260221-1 linux-firmware-nvidia-20260221-1 linux-firmware-other-20260221-1 linux-firmware-radeon-20260221-1 linux-firmware-realtek-20260221-1 linux-firmware-whence-20260221-1 linux-headers-6.18.13.arch1-1 mdadm-4.5-1 mesa-1:26.0.1-1 nss-3.121-1 openmpi-5.0.10-1 parallel-20260222-1 poppler-26.02.0-2 poppler-glib-26.02.0-2 poppler-qt6-26.02.0-2 postgresql-18.3-1 postgresql-docs-18.3-1 postgresql-libs-18.3-1 python-chardet-6.0.0.post1-1 python-platformdirs-4.9.3-1 python-pypdf-6.7.3-1 python-requests-2.32.5-4 sha3sum-1.2.4-1 shaderc-2026.1-2 spandsp-0.0.6-7 spirv-tools-1:1.4.341.0-2 vim-9.2.0067-1 vim-runtime-9.2.0067-1 xkeyboard-config-2.47-1 -- David C. Rankin, J.D.,P.E.

3 4

strange message on booting the system
by Frank 27 Feb '26

27 Feb '26

Hello, I'm seeing this message when booting the system: Unable to resume from device 'dev/disk/by-partuuid/foo/bar' (259:3) offset 0, continuing boot process. After this the system starts as expected. Resuming from a hibernation image works fine, I only get this message on normal boot. I'm using systemd-boot as my boot manager. Frank

2 1

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