March 2026 - Arch-general - lists.archlinux.org

Bring ARM into the fold?
by Christer Solskogen 20 Apr '26

20 Apr '26

Is it time to bring Arch Linux ARM into the fold of Arch Linux? The GNU toolchain of ALARM is now very behind, and the developers are dead silent about why. There little to no response on pull requests on the github page, and while it seems like there is activity on their PKGBUILDs repo, it almost seems to me that it is some kind of automatic jobs being run. Their forum is broken and has been broken for quite some time as well. -- chs

14 27

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

30 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 5

Re: nut UPS shutdown issue after nut upgrade 2.8.2 -> 2.8.4
by David C Rankin 29 Mar '26

29 Mar '26

On 3/28/26 8:07 AM, Łukasz Michalski wrote: > > On 3/28/26 2:20 AM, David C Rankin wrote: >> Mar 27 19:07:55 valkyrie nut-driver@valkyrie_ups[830]: You may want to >> set 'pollonly' flag on CPS devices > > I would try this. > >> Mar 27 19:08:49 valkyrie nut-server[940]: Data for UPS [valkyrie_ups] >> is stale - check driver >> Mar 27 19:08:49 valkyrie upsd[940]: Data for UPS [valkyrie_ups] is >> stale - check driver >> Mar 27 19:08:52 valkyrie nut-monitor[954]: Poll UPS >> [valkyrie_ups@localhost] failed - Data stale > > Because of this. > > Regards, > Łukasz Thank you Lukasz, I'm a bit confused where it goes? It's an option to usbhid-ups according to man upbhid-ups(8), but where in the config setup does it go? The Arch wiki (https://wiki.archlinux.org/title/Network_UPS_Tools#CyberPower_UPS_keeps_dis…) talks about creating an override.conf, but it is unclear whether that goes with nut-driver@.service.d or nut-driver@valkyrie_ups.service.d? The systemd targets and service files are a bit of a spiderweb: /etc/systemd/system/nut-driver.target.wants └── nut-driver@valkyrie_ups.service -> /usr/lib/systemd/system/nut-driver@.service /etc/systemd/system/nut-driver@.service.d └── nut-driver-enumerator-generated-checksum.conf /etc/systemd/system/nut-driver@valkyrie_ups.service.d ├── nut-driver-enumerator-generated-checksum.conf ├── nut-driver-enumerator-generated-devicename.conf ├── nut-driver-enumerator-generated-doclink.conf └── nut-driver-enumerator-generated.conf /etc/systemd/system/nut.target.wants ├── nut-driver-enumerator.service -> /usr/lib/systemd/system/nut-driver-enumerator.service ├── nut-driver.target -> /usr/lib/systemd/system/nut-driver.target ├── nut-monitor.service -> /usr/lib/systemd/system/nut-monitor.service └── nut-server.service -> /usr/lib/systemd/system/nut-server.service All this just to start NUT? The wiki says nut-driver@.service, but then follows with the name nut-driver(a)cyberpower.service to create override.conf and it's unclear what the inserted @cyberpower is referring to (presumably that's the UPS name, e.g. valkyrie_ups for me), but then which unit directory gets modified, the one without @name or the one with @name? This commanded shutdown occurred again at 10:39 this morning. The driver claimed a power failure and then lost communication (there was no power failure, the other six UPS were fine, no events) So this looks like a single disconnect event, or perhaps a self-test and then communications are lost? Picking up from the driver restart yesterday, the journal shows the following: Mar 27 19:49:18 valkyrie nut-driver@valkyrie_ups[2775]: Network UPS Tools upsdrvctl - UPS driver controller 2.8.4 release Mar 27 19:49:18 valkyrie nut-driver@valkyrie_ups[2793]: Network UPS Tools 2.8.4 release - Generic HID driver 0.67 Mar 27 19:49:18 valkyrie nut-driver@valkyrie_ups[2793]: USB communication driver (libusb 1.0) 0.50 Mar 27 19:49:18 valkyrie nut-driver@valkyrie_ups[2793]: Using subdriver: CyberPower HID 0.84 Mar 27 19:49:18 valkyrie nut-driver@valkyrie_ups[2793]: Defaulting 'pollfreq' to 12 for CPS devices Mar 27 19:49:18 valkyrie nut-driver@valkyrie_ups[2793]: You may want to set 'pollonly' flag on CPS devices Mar 27 19:49:18 valkyrie nut-driver@valkyrie_ups[2793]: Listening on socket /var/lib/nut/usbhid-ups-valkyrie_ups Mar 27 19:49:19 valkyrie nut-server[2351]: Connected to UPS [valkyrie_ups]: usbhid-ups-valkyrie_ups Mar 27 19:49:19 valkyrie upsd[2351]: Connected to UPS [valkyrie_ups]: usbhid-ups-valkyrie_ups Mar 27 19:49:19 valkyrie nut-monitor[2703]: Communications with UPS valkyrie_ups@localhost established Mar 27 19:49:19 valkyrie nut-monitor[2703]: UPS valkyrie_ups@localhost: has at least one unclassified status token: [WAIT] Mar 27 19:49:24 valkyrie nut-monitor[2703]: UPS valkyrie_ups@localhost has no unclassified status tokens anymore Mar 28 10:39:59 valkyrie nut-monitor[2703]: UPS valkyrie_ups@localhost on battery Mar 28 10:39:59 valkyrie usbhid-ups[2797]: nut_libusb_get_interrupt: No such device (it may have been disconnected) Mar 28 10:40:18 valkyrie nut-server[2351]: Data for UPS [valkyrie_ups] is stale - check driver Mar 28 10:40:18 valkyrie upsd[2351]: Data for UPS [valkyrie_ups] is stale - check driver Mar 28 10:40:19 valkyrie nut-monitor[2703]: Poll UPS [valkyrie_ups@localhost] failed - Data stale Mar 28 10:40:19 valkyrie nut-monitor[2703]: Communications with UPS valkyrie_ups@localhost lost Mar 28 10:40:24 valkyrie nut-monitor[2703]: Poll UPS [valkyrie_ups@localhost] failed - Data stale Mar 28 10:40:29 valkyrie nut-monitor[2703]: Poll UPS [valkyrie_ups@localhost] failed - Data stale Mar 28 10:40:34 valkyrie nut-monitor[2703]: Poll UPS [valkyrie_ups@localhost] failed - Data stale Mar 28 10:40:34 valkyrie nut-monitor[2703]: Executing automatic power-fail shutdown Mar 28 10:40:34 valkyrie upsd[2351]: Client david@::1 set FSD on UPS [valkyrie_ups] Mar 28 10:40:34 valkyrie nut-server[2351]: Client david@::1 set FSD on UPS [valkyrie_ups] Mar 28 10:40:34 valkyrie nut-monitor[2703]: Auto logout and shutdown proceeding Mar 28 10:40:39 valkyrie systemd[1]: nut-monitor.service: Deactivated successfully. Mar 28 10:40:39 valkyrie systemd[1]: nut-monitor.service: Consumed 9.434s CPU time over 14h 54min 9.506s wall clock time, 4.2M memory peak. Mar 28 10:40:39 valkyrie nut-server[2351]: mainloop: Interrupted system call Mar 28 10:40:39 valkyrie nut-server[2351]: Signal 15: exiting Mar 28 10:40:39 valkyrie upsd[2351]: mainloop: Interrupted system call Mar 28 10:40:39 valkyrie upsd[2351]: Signal 15: exiting Mar 28 10:40:39 valkyrie systemd[1]: nut-server.service: Deactivated successfully. Mar 28 10:40:39 valkyrie systemd[1]: nut-server.service: Consumed 4.229s CPU time over 15h 1min 9.271s wall clock time, 4.4M memory peak. Mar 28 10:40:39 valkyrie nut-driver@valkyrie_ups[17695]: Network UPS Tools upsdrvctl - UPS driver controller 2.8.4 release Mar 28 10:40:44 valkyrie nut-driver@valkyrie_ups[17695]: Stopping /run/nut/usbhid-ups-valkyrie_ups.pid failed, retrying harder: Success Mar 28 10:40:44 valkyrie systemd[1]: nut-driver@valkyrie_ups.service: Main process exited, code=killed, status=9/KILL Mar 28 10:40:45 valkyrie systemd[1]: nut-driver@valkyrie_ups.service: Failed with result 'signal'. Mar 28 10:40:45 valkyrie systemd[1]: nut-driver@valkyrie_ups.service: Consumed 11.833s CPU time over 14h 51min 27.223s wall clock time, 4.1M memory peak. The salient part starts with a spurious on-battery message and then the connection with the UPS fails. I'm beginning to wonder if the "on-battery" may not just be the daily self-test of the UPS, but then why does it stop communicating with nut-monitor? It ran for 5+ years with NUT 2.7 version and never had a disconnect issue, not one. Really strange. On restart after the shutdown this morning, the driver came up and connected just fine, so I'm not sure what to make of the issue. I'll mess with this a little more to see if I can get it to be stable, if not I'm just going to swap another APC 1500W UPS in and see if NUT will work with it, if not I'll just go with apcupsd. Thank you for your help! -- David C. Rankin, J.D.,P.E.

2 2

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