- Arch-general - lists.archlinux.org

Notice that flashed on wiki access today - too fast to read - was it important?
by David C Rankin 27 Apr '25

27 Apr '25

Arch Devs, On access of https://wiki.archlinux.org today, a dialog flashed to the screen immediately before the wiki main page was rendered, but the dialog flashed too quickly to read. Was it important or require any action? May have just been a wiki update note, dark mode looks a bit different? -- David C. Rankin, J.D.,P.E.

8 12

Journal log entries while installing an ISO image
by Friedrich Romstedt 23 Apr '25

23 Apr '25

Hi, Yesterday I prepared an USB stick with the recent version of the Arch Linux installation medium (Release 2025-04-01). This is about some error entries in the system journal, which I encountered during copying this ISO image over. The respective transcripts are provided inline, as well as attached in the form of plain text files. I used initially $ sudo cp <ISO> /dev/sda. After having finished that process, I spotted some error log entries in the system journal: Apr 20 15:30:25 T470p sudo[21475]: friedrich : TTY=pts/2 ; PWD=/home/friedrich/(...) ; USER=root ; COMMAND=/usr/bin/cp archlinux-2025.04.01-x86_64.iso /dev/sda Apr 20 15:30:25 T470p sudo[21475]: pam_unix(sudo:session): session opened for user root(uid=0) by friedrich(uid=1000) Apr 20 15:33:10 T470p systemd[1]: systemd-udevd.service: Watchdog timeout (limit 3min)! Apr 20 15:33:10 T470p systemd[1]: systemd-udevd.service: Killing process 359 (systemd-udevd) with signal SIGABRT. Apr 20 15:34:40 T470p systemd[1]: systemd-udevd.service: State 'stop-watchdog' timed out. Killing. Apr 20 15:34:40 T470p systemd[1]: systemd-udevd.service: Killing process 359 (systemd-udevd) with signal SIGKILL. Apr 20 15:36:10 T470p systemd[1]: systemd-udevd.service: Processes still around after SIGKILL. Ignoring. Apr 20 15:37:38 T470p kernel: sda: sda1 sda2 Apr 20 15:37:38 T470p sudo[21475]: pam_unix(sudo:session): session closed for user root Apr 20 15:37:38 T470p systemd[1]: systemd-udevd.service: Main process exited, code=killed, status=9/KILL Apr 20 15:37:38 T470p systemd[1]: systemd-udevd.service: Failed with result 'watchdog'. Apr 20 15:37:38 T470p systemd[1]: systemd-udevd.service: Consumed 4.845s CPU time, 51.6M memory peak. Apr 20 15:37:38 T470p systemd[1]: systemd-udevd.service: Scheduled restart job, restart counter is at 1. Apr 20 15:37:38 T470p systemd[1]: Starting Rule-based Manager for Device Events and Files... Apr 20 15:37:39 T470p systemd-udevd[21582]: Using default interface naming scheme 'v257'. Apr 20 15:37:39 T470p systemd[1]: Started Rule-based Manager for Device Events and Files. Apr 20 15:38:19 T470p kernel: usb 1-1: USB disconnect, device number 7 Because I had doubts about the integrity of the thus prepared USB stick, I repeated the process, this time using $ su - and # dd if=<ISO> of=/dev/sda bs=8M. Here, I encountered similar logs: Apr 20 15:38:53 T470p kernel: sda: sda1 sda2 Apr 20 15:38:53 T470p kernel: sd 0:0:0:0: [sda] Attached SCSI removable disk Apr 20 15:39:07 T470p su[21650]: (to root) friedrich on pts/2 Apr 20 15:39:07 T470p su[21650]: pam_unix(su:session): session opened for user root(uid=0) by friedrich(uid=1000) Apr 20 15:44:05 T470p systemd[1]: systemd-udevd.service: Watchdog timeout (limit 3min)! Apr 20 15:44:05 T470p systemd[1]: systemd-udevd.service: Killing process 21582 (systemd-udevd) with signal SIGABRT. Apr 20 15:45:35 T470p systemd[1]: systemd-udevd.service: State 'stop-watchdog' timed out. Killing. Apr 20 15:45:35 T470p systemd[1]: systemd-udevd.service: Killing process 21582 (systemd-udevd) with signal SIGKILL. Apr 20 15:47:05 T470p systemd[1]: systemd-udevd.service: Processes still around after SIGKILL. Ignoring. Apr 20 15:48:35 T470p systemd[1]: systemd-udevd.service: State 'final-sigterm' timed out. Killing. Apr 20 15:48:35 T470p systemd[1]: systemd-udevd.service: Killing process 21582 (systemd-udevd) with signal SIGKILL. Apr 20 15:48:56 T470p kernel: sda: sda1 sda2 Apr 20 15:48:56 T470p systemd[1]: systemd-udevd.service: Main process exited, code=killed, status=9/KILL Apr 20 15:48:56 T470p systemd[1]: systemd-udevd.service: Failed with result 'watchdog'. Apr 20 15:48:56 T470p systemd[1]: systemd-udevd.service: Consumed 1.101s CPU time, 7.4M memory peak. Apr 20 15:48:56 T470p systemd[1]: systemd-udevd.service: Scheduled restart job, restart counter is at 2. Apr 20 15:48:56 T470p systemd[1]: Starting Rule-based Manager for Device Events and Files... Apr 20 15:48:56 T470p systemd-udevd[21808]: Using default interface naming scheme 'v257'. Apr 20 15:48:56 T470p systemd[1]: Started Rule-based Manager for Device Events and Files. Apr 20 15:49:13 T470p kernel: usb 1-1: USB disconnect, device number 8 In the second run, where I kept an eye on the journal, I noticed that the error entries were logged a few minutes *before* the copying process completed. There were no errors reported by both of these directly. The pen drive is booting and working just fine. However, I felt this behaviour being worth it to be reported. Maybe someone else can make sense of it. Best, Friedrich

4 7

Building with cmake
by Pocket 21 Apr '25

21 Apr '25

I am building packages following DeveloperWiki:Building in a clean chroot When building packages that are associated with gnome I get the following error: CMake Error at wsrep-lib/CMakeLists.txt:5 (cmake_minimum_required): Compatibility with CMake < 3.5 has been removed from CMake. Update the VERSION argument <min> value. Or, use the <min>...<max> syntax to tell CMake that the project requires at least <min> but has been updated to work with policies introduced by <max> or earlier. Or, add -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to try configuring anyway. Adding export CMAKE_POLICY_VERSION_MINIMUM=3.5 doesn't correct my problem. Is there another way to get past this without adding -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to the PKGBUILD? -- Hindi madali ang maging ako

2 2

Valkey to replace Redis - Are devs updating configs in dependent packages (Nextcloud, etc..) to use valkey?
by David C Rankin 20 Apr '25

20 Apr '25

Arch devs, The latest news for "Valkey to replace Redis in the [extra] Repository" says: <quote> Users are recommended to begin transitioning their use of Redis to Valkey as soon as possible to avoid possible complications after the 14 day transition window closes. </quote> For other Arch packages that are configured to use redis (or php-legacy-redis), will the maintainers update the configs for the next release within the 14 day transition window? Or does "Users are recommended ..." mean just that, users need to try and make the replacements in all needed config files during the 14 days? I'm referring to packages like Nextcloud that Arch packages and has config files with entries for redis and php-legacy-redis. (with corresponding instructions in the Arch-wiki for Nextcloud) Also will there be corresponding php-valkey and php-legacy-valkey packages to replace the php-redis ones? The valkey docs are fairly clear, valkey is a for of redis 7.2: https://valkey.io/topics/migration/ so other than a name change and change to start valkey instead of redis, is there anything else involved for the likes of Nextcloud? I don't have enough cache to worry about migration files from redis to valkey other than stopping/disabling redis, starting valkey and then reloading with the config file(s) name changed. So if there are no caches a user needs to migrate from redis, other than the redis package changing to valkey, will all other Arch packages that use redis be updated in this 14 day period? -- David C. Rankin, J.D.,P.E.

2 1

arch-nspawn ERROR: chroot is not at version v6. Please rebuild. -- does that mean rm -rf $CHROOT?
by David C Rankin 19 Apr '25

19 Apr '25

Arch folks, My clean chroot will no longer update. Attempting update results in the error: $ arch-nspawn $CHROOT/root pacman -Syu ==> ERROR: chroot '/home/david/arch/pkg/chroot/root' is not at version v6. Please rebuild. I've checked the various devtools man pages and --help and there is nothing about rebuilding, so does this mean I need to: # rm -rf $CHROOT and start over? Or, is there actually a way to "rebuild" the chroot without wiping it all out and starting over? -- David C. Rankin, J.D.,P.E.

4 4

Postgresql 17
by IS 18 Apr '25

18 Apr '25

Does anyone know why Postgresql 17 is not yet available on Archlinux? Thanks

6 7

Are there arch based live ISO containing libreoffice?
by u34＠net9.cf 18 Apr '25

18 Apr '25

I am aware to archman, https://archman.org/ , live ISO with libreoffice included. Archman is current, last released on Dec 2024. There is also archbox, https://archbox-linux.github.io/ , last released on 2017.04.15. What other arch based live ISO, preferrably current, with libreoffice included within the ISO, are there? -- u34

2 2

[arch-dev-public] Re: The future of `reflector` [was: Spring cleanup '25]
by mpan 18 Apr '25

18 Apr '25

> On 22/03/2025 14:43, Robin Candau wrote: >> On 3/22/25 11:50 AM, Antonio Rojas wrote: >>> Time to clean up old cruft again. Please head to https:// >>> archlinux.org/devel/reports/unneeded-orphans/ and adopt packages you >>> want to keep in the repos. >>> [...] >>> I will start dropping packages to AUR in ~ 10 days. >>> [...] >>> reflector >>> [...] >> >> Re: Spring cleanup '25 [1]: Aside from being quite popular among our >> users (probably for historical reasons and because it's currently the >> only solution offered in the official repo as far as I can tell), >> `reflector` is included and used in our ISO [2]. >> As such, it should *not* be dropped in the current state of things. >> > Actually I don't think that's a good reason to keep it. If anything it > should be removed from ISO as well in my opinion. > > I don't think we should be including anything like that because then we > should consider also anything from https://wiki.archlinux.org/title/ > Mirrors#Client-side_ranking > > So let's keep it simple. Removal from the ISO may be a reasonable choice. It’s not an essential tool and, as an automatically started service, it was giving people trouble. Personally I also believe benchmarking tools, that use others’ resources, shouldn’t be run without person’s explicit need. Privacy concerns may be raised by some users too, given running the ISO unconditionally contacts a large number of network services. But I don’t see a reason to remove reflector from the repos, unless no new maintainer appears in due time.⁽¹⁾ The package is present on 58% pkgstats-ed machines:⁽²⁾ more popular than chromium, zsh, or ruby. Upon removal the only remaining options will be using Xyne’s repo or AUR. Not a huge deal for seasoned Archers, but I don’t think fresh users should be told to configure 3rd party repos or jump into AUR, if that’s not really necessary. Cheers, mpan ____ ⁽¹⁾ Due time: when reflector’s PKGBUILD needs to be updated. ⁽²⁾ Webapp at <https://pkgstats.archlinux.de/packages/reflector>

2 1

Mailing list is back
by Leonidas Spyropoulos 17 Apr '25

17 Apr '25

Hello, Some might have noticed we had some issues with arch-general ML from November last year. This was debugged and sorted today morning [1] and should have emails now send. Also the archive now contains the messages as well [2]. Thanks for dvzrv and gromit for their time today to sort this out together. [1]: https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/679 [2]: https://lists.archlinux.org/archives/list/arch-general@lists.archlinux.org/ Cheers, -- Leonidas Spyropoulos Developer & DevOps PGP: 59E43E106B247368 244740D17C7FD0EC

2 1

Change user password in KDE settings: root authorisation requested
by SET 17 Apr '25

17 Apr '25

Hello, If a user password is changed in systemsettings, root authorisation is requested willfully, with a UI text confirming that it’s mandatory even if it’s the user password being updated. No such request is made when doing that in a terminal and that's well within reach of any Arch user. It has been discussed at: https://discuss.kde.org/t/change-user-password-in-settings-root-authorisati… It seems that it might be distribution related. I am not asking for any change in Arch itself, and would like to read opinions of Arch maintainers about that. Thanks and regards.

2 4