- Arch-general - lists.archlinux.org

Fwd: News draft: dovecot >= 2.4 requires manual intervention
by David C Rankin 31 Oct '25

31 Oct '25

Thank you Thore, Preserving 2.3, while maintained, to provide replication functionality is much appreciated. Smart move. Draft of announcement seems fine. (posted to arch-general as no reply capability to arch-dev-public) -------- Forwarded Message -------- Subject: News draft: dovecot >= 2.4 requires manual intervention Date: Wed, 29 Oct 2025 19:54:34 +0100 From: Thore Bödecker <foxxx0(a)archlinux.org> To: arch-dev-public(a)lists.archlinux.org Hi folks, the upstream dovecot 2.4 branch comes with handful of breaking changes, mostly concerning configuration semantics and syntax. For this, upstream provides a migration guide [1]. We've kept dovecot 2.4.1 in [testing] for quite some time and it received a decent number of signoffs. There was already a bit of chatter on arch-general regarding the availability of a dovecot 2.4 package in [extra]. While slightly unintentional, I've built and pushed todays upstream release version 2.4.2 to [extra]. However, there is a feature disparity: the 2.4 branch no longer supports replication. My own setup relies on that particular feature and I've grown quite fond of it, so I'm a bit sad to see it going away. As per upstreams EOL announcement [2], the 2.3 branch is supposedly going to receive critical secrity fixes, which I considered "maintained enough" to warrant packaging it separately until upstream fully drops it. The following packages are now available in [extra]: - dovecot23 - pigeonhole23 - dovecot23-fts-elastic - dovecot23-fts-xapian Where applicable, they are configured with the necessary conflicts/provides. The most recent dovecot-2.4.2-3 build also contains the following dovecot.install notice: > ==> Dovecot 2.4 is incompatible with older configurations and requires manual intervention. > ==> Refer to 'https://doc.dovecot.org/latest/installation/upgrade/2.3-to-2.4.html' for upgrading instructions. > ==> Alternatively, there is a dovecot23 (and pigeonhole23) package available. Given the fact that any dovecot 2.4 binary *will not* start with a <= 2.3 configuration file, it seems reasonable for us to publish an announcement to make users aware of this situation while also informing them about the alternate 2.3 packages we provide. News draft below. ----8<---- # dovecot >= 2.4 requires manual intervention The dovecot 2.4 release branch has made breaking changes which result in it being incompatible with any <= 2.3 configuration file. Thus, the dovecot service will no longer be able to start until the configuration file was migrated, requiring manual intervention. For guidance on the 2.3-to-2.4 migration, please refer to the following upstream documentation: [Upgrading Dovecot CE from 2.3 to 2.4](https://doc.dovecot.org/latest/installation/upgrade/2.3-to-2.4.html) Furthermore, the dovecot 2.4 branch no longer supports their replication feature, it was removed. For users relying on the replication feature or who are unable to perform the 2.4 migration right now, we provide alternative packages available in [extra]: - dovecot23 - pigeonhole23 - dovecot23-fts-elastic - dovecot23-fts-xapian The dovecot 2.3 release branch is going to [receive critical security fixes](https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/threa… from upstream until stated otherwise. ---->8---- [1] https://doc.dovecot.org/latest/installation/upgrade/2.3-to-2.4.html [2] https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/thread/3P45L… Cheers -- Thore "foxxx0" Bödecker GPG ID: 0xEB763B4E9DB887A6 GPG FP: 051E AD6A 6155 389D 69DA 02E5 EB76 3B4E 9DB8 87A6 -- David C. Rankin, J.D.,P.E.

1 0

[arch-general] System terribly slow
by riveravaldez 27 Oct '25

27 Oct '25

Hi, I'm looking for some advice trying to pinpoint why or where my system has becoming almost unusable slow. Searching the web I've found some hints but nothing precise enough. Maybe it's a failing HDD, but I'm first posting what I have until now in the hope someone can give some advice. Superficial symptoms are a general slowness. I'm using just IceWM and `startx` to initialize the GUI, and even logging into my account previous to that takes almost a minute to get done. Then any application I launch takes minutes to just start (from IceWM to firefox, from qtox to pcmanfm or geany, etc.). Even navigate the folders tree with pcmanfm takes 10 or more seconds just to show any folder content... Hope some of this helps: $ sudo journalctl -b -exp3 -- Journal begins at Thu 2021-12-02 23:59:31 -03, ends at Fri 2021-12-03 19:50:29 -03. -- dic 03 00:48:43 arch kernel: sd 0:0:0:0: [sda] Asking for cache data failed dic 03 00:48:43 arch kernel: sd 0:0:0:0: [sda] Assuming drive cache: write through dic 03 00:50:39 arch libvirtd[592]: cannot open directory '/home/dell/Software/VMs/TrisquelMini8': No existe el fichero o el directorio dic 03 00:50:39 arch libvirtd[592]: error interno: Falló al iniciar automáticamente el grupo de almacenamiento 'TrisquelMini8': cannot open directory '/home/dell/Softwar> dic 03 00:50:41 arch libvirtd[592]: No se encontró 'dmidecode' en ruta: No existe el fichero o el directorio dic 03 00:50:57 arch libvirtd[592]: No se encontró 'dmidecode' en ruta: No existe el fichero o el directorio dic 03 00:56:40 arch systemd[1]: Failed to start Disk Manager. Subject: A start job for unit udisks2.service has failed Defined-By: systemd Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel A start job for unit udisks2.service has finished with a failure. The job identifier is 1072 and the job result is failed. $ systemctl --state=failed UNIT LOAD ACTIVE SUB DESCRIPTION 0 loaded units listed. $ systemd-analyze Startup finished in 11.038s (kernel) + 1min 31.352s (userspace) = 1min 42.391s graphical.target reached after 1min 31.352s in userspace $ systemd-analyze blame 37.946s polkit.service 29.248s dev-sda1.device 28.827s systemd-tmpfiles-clean.service 24.692s udisks2.service 15.936s systemd-journal-flush.service 14.228s systemd-hwdb-update.service 13.930s ldconfig.service 13.502s upower.service 12.881s ufw.service 8.830s user(a)1000.service 7.556s systemd-tmpfiles-setup-dev.service 7.280s avahi-daemon.service 7.275s bluetooth.service 7.262s iwd.service 6.067s systemd-logind.service 6.058s systemd-machined.service 5.825s systemd-tmpfiles-setup.service 5.123s systemd-sysusers.service 4.569s systemd-udevd.service 4.511s systemd-resolved.service 4.281s systemd-networkd.service 3.724s systemd-journal-catalog-update.service 3.415s systemd-fsck@dev-disk-by\x2duuid-1d72b82c\x2d9c58\x2d4f57\x2d97a3\x2de29ff35a5632.service 2.959s systemd-modules-load.service 2.557s lm_sensors.service 2.503s systemd-random-seed.service 2.389s systemd-backlight@backlight:acpi_video0.service 1.983s dev-disk-by\x2duuid-84c91978\x2da09c\x2d4087\x2db60d\x2d86730d142f63.swap 1.967s systemd-backlight@leds:dell::kbd_backlight.service 1.563s systemd-timesyncd.service 1.457s systemd-update-utmp.service 1.287s systemd-udev-trigger.service 1.278s systemd-rfkill.service 1.219s alsa-restore.service 1.164s systemd-sysctl.service (...) $ systemctl status polkit.service ● polkit.service - Authorization Manager Loaded: loaded (/usr/lib/systemd/system/polkit.service; static) Active: active (running) since Fri 2021-12-03 00:50:28 -03; 19h ago Docs: man:polkit(8) Main PID: 613 (polkitd) Tasks: 12 (limit: 6993) Memory: 18.9M CPU: 1.032s CGroup: /system.slice/polkit.service └─613 /usr/lib/polkit-1/polkitd --no-debug dic 03 00:49:50 arch systemd[1]: Starting Authorization Manager... dic 03 00:50:05 arch polkitd[613]: Started polkitd version 0.120 dic 03 00:50:26 arch polkitd[613]: Loading rules from directory /etc/polkit-1/rules.d dic 03 00:50:26 arch polkitd[613]: Loading rules from directory /usr/share/polkit-1/rules.d dic 03 00:50:28 arch polkitd[613]: Finished loading, compiling and executing 6 rules dic 03 00:50:28 arch systemd[1]: Started Authorization Manager. dic 03 00:50:28 arch polkitd[613]: Acquired the name org.freedesktop.PolicyKit1 on the system bus $ systemctl status dev-sda1.device ● dev-sda1.device - Hitachi_HTS545025B9A300 ROOT Follows: unit currently follows state of sys-devices-pci0000:00-0000:00:1f.2-ata1-host0-target0:0:0-0:0:0:0-block-sda-sda1.device Loaded: loaded Active: active (plugged) since Fri 2021-12-03 00:49:12 -03; 19h ago Device: /sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda1 Notice: journal has been rotated since unit was started, output may be incomplete. $ systemctl status systemd-tmpfiles-clean.service ○ systemd-tmpfiles-clean.service - Cleanup of Temporary Directories Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-clean.service; static) Active: inactive (dead) since Fri 2021-12-03 01:03:52 -03; 19h ago TriggeredBy: ● systemd-tmpfiles-clean.timer Docs: man:tmpfiles.d(5) man:systemd-tmpfiles(8) Process: 1473 ExecStart=systemd-tmpfiles --clean (code=exited, status=0/SUCCESS) Main PID: 1473 (code=exited, status=0/SUCCESS) CPU: 185ms dic 03 01:03:23 arch systemd[1]: Starting Cleanup of Temporary Directories... dic 03 01:03:52 arch systemd[1]: systemd-tmpfiles-clean.service: Deactivated successfully. dic 03 01:03:52 arch systemd[1]: Finished Cleanup of Temporary Directories. $ systemctl status udisks2.service ● udisks2.service - Disk Manager Loaded: loaded (/usr/lib/systemd/system/udisks2.service; disabled; vendor preset: disabled) Active: active (running) since Fri 2021-12-03 00:59:51 -03; 19h ago Docs: man:udisks(8) Main PID: 1129 (udisksd) Tasks: 5 (limit: 6993) Memory: 3.2M CPU: 23.045s CGroup: /system.slice/udisks2.service └─1129 /usr/lib/udisks2/udisksd dic 03 00:59:26 arch systemd[1]: Starting Disk Manager... dic 03 00:59:26 arch udisksd[1129]: udisks daemon version 2.9.4 starting dic 03 00:59:51 arch systemd[1]: Started Disk Manager. dic 03 00:59:54 arch udisksd[1129]: Acquired the name org.freedesktop.UDisks2 on the system message bus $ systemctl status systemd-journal-flush.service ● systemd-journal-flush.service - Flush Journal to Persistent Storage Loaded: loaded (/usr/lib/systemd/system/systemd-journal-flush.service; static) Active: active (exited) since Fri 2021-12-03 00:48:59 -03; 19h ago Docs: man:systemd-journald.service(8) man:journald.conf(5) Process: 283 ExecStart=journalctl --flush (code=exited, status=0/SUCCESS) Main PID: 283 (code=exited, status=0/SUCCESS) CPU: 15ms dic 03 00:48:43 arch systemd[1]: Starting Flush Journal to Persistent Storage... dic 03 00:48:59 arch systemd[1]: Finished Flush Journal to Persistent Storage. $ systemctl status systemd-hwdb-update.service ● systemd-hwdb-update.service - Rebuild Hardware Database Loaded: loaded (/usr/lib/systemd/system/systemd-hwdb-update.service; static) Active: active (exited) since Fri 2021-12-03 00:48:57 -03; 19h ago Docs: man:hwdb(7) man:systemd-hwdb(8) Process: 279 ExecStart=systemd-hwdb update (code=exited, status=0/SUCCESS) Main PID: 279 (code=exited, status=0/SUCCESS) CPU: 1.746s dic 03 00:48:57 arch systemd[1]: Finished Rebuild Hardware Database. $ journalctl -b -u systemd-journald.service -- Journal begins at Thu 2021-12-02 23:59:31 -03, ends at Fri 2021-12-03 20:49:18 -03. -- dic 03 00:48:43 arch systemd-journald[271]: Journal started dic 03 00:48:43 arch systemd-journald[271]: Runtime Journal (/run/log/journal/431f639f382e4bad8a43628868f2fc6c) is 8.0M, max 292.4M, 284.4M free. dic 03 00:48:44 arch systemd-journald[271]: Time spent on flushing to /var/log/journal/431f639f382e4bad8a43628868f2fc6c is 7.561088s for 798 entries. dic 03 00:48:44 arch systemd-journald[271]: System Journal (/var/log/journal/431f639f382e4bad8a43628868f2fc6c) is 16.0M, max 2.4G, 2.4G free. $ journalctl -b -u systemd-fsck@dev-disk-by\\x2duuid-1d72b82c\\x2d9c58\\x2d4f57\\x2d97a3\\x2de29ff35a5632.service -- Journal begins at Thu 2021-12-02 23:59:31 -03, ends at Fri 2021-12-03 20:52:36 -03. -- dic 03 00:49:18 arch systemd[1]: Starting File System Check on /dev/disk/by-uuid/1d72b82c-9c58-4f57-97a3-e29ff35a5632... dic 03 00:49:21 arch systemd-fsck[485]: HOME: limpio, 208781/13107200 ficheros, 37165716/52398592 bloques dic 03 00:49:21 arch systemd[1]: Finished File System Check on /dev/disk/by-uuid/1d72b82c-9c58-4f57-97a3-e29ff35a5632. $ journalctl --verify PASS: /var/log/journal/431f639f382e4bad8a43628868f2fc6c/user-1000.journal 3b84d8: Data object's entry array not sorted File corruption detected at /var/log/journal/431f639f382e4bad8a43628868f2fc6c/system.journal:915878 (of 16777216 bytes, 56%). FAIL: /var/log/journal/431f639f382e4bad8a43628868f2fc6c/system.journal (Mensaje erróneo) $ journalctl --disk-usage Archived and active journals take up 24.0M in the file system. Maybe it's pertinent to mention that I've just cleaned up /var/log/journal to rule out storage issues. Any help will be most welcome. Thanks a lot in advance.

6 8

Btrfs
by Pocket 26 Oct '25

26 Oct '25

I am currently in process of moving fomr ext4 filesystem to btrfs. I have the following on a raspberry pi server The fdisk -l /dev/mmcblk0 /dev/mmcblk0p1 2048 1050623 1048576 512M c W95 FAT32 (LBA) /dev/mmcblk0p2 1050624 58327039 57276416 27.3G 83 Linux /dev/mmcblk0p3 58327040 62521343 4194304 2G 82 Linux swap / Solaris partition 1 is vfat partition 2 is btrfs This will go on a SSD nvme drive after the test phase is complete. It is currently booting and functioning is good. BTRFS top level: Container subvolume Home subvolume Root subvolume Snapshot DNS-2025-10-23 PiHole-2025-10-26 Snapshot volumes are from Container DNS-2025-10-23 has base and bind installed PiHole-2025-10-26 has base and pi hole installed I mount DNS-2025-10-23 to /var/lib/machines/DNS and I mount PiHole-2025-10-26 /var/lib/machines/PiHole They are mounted in /etc/fstab and I start them on boot machinectl enable DNS machinectl enable PiHole I dedup them by mounting the top level to /mnt and running duperemove -r -d /mnt I am planning to change the layout so it would be like this Root subvolume Home subvolume DNS subvolume PiHole subvolume then dedup? Also what are the issues when updating (pacman -Syu) on each subvolume then dedup. Is there anything I need to watch out for? -- Hindi madali ang maging ako

1 0

Fwd: Remove GTK2 from the official repositories
by David C Rankin 26 Oct '25

26 Oct '25

Directed to general since not allowed to post to dev: I still use Gtk2, and if it isn't a burden and isn't failing to build, I would like to see it kept. I use hexchat, nitrogen and parcellite along with xdialog. Yes we can always to to AUR, but an official package is always preferrable. (just a reqsponse to the request for opinions) -------- Forwarded Message -------- Subject: Remove GTK2 from the official repositories Date: Fri, 24 Oct 2025 00:12:39 +0200 From: Balló György <bgyorgy(a)archlinux.org> To: arch-dev-public(a)lists.archlinux.org Hi all, I think we've reached the point when we can remove the very old GTK2 package from the official repositories. I recently dropped the GTK2 version of LXDE, and there are only a few applications left that still depend on GTK2: - alltray - amsynth - bless - calf - eq10q - gimp-nufraw - gkrellm - gpsim - gtk2fontsel - gtk-chtheme - hexchat - hexter - leafpad - mono-tools - nitrogen - nspluginwrapper - osdlyrics - parcellite - pidgin - sbxkb - trayer - xboard - xdialog - xlockmore Most of these have no active development a long time ago. If no one has objections, I'll drop these packages to AUR in the next days if it's not possible to build them without GTK2. Any opinion? -- György Balló Package Maintainer -- David C. Rankin, J.D.,P.E.

6 7

systemd-networkd relies on all mountable mountpoints?
by Bjoern Franke 25 Oct '25

25 Oct '25

Hi, after an uptime of ~200 days I rebootet my NUC which had issues bringing up systemd-networkd afterwards. systemd-networkd.service: Failed to set up mount namespacing: /home: No such device Excerpt from fstab: UUID="7f313178-70b4-4a93-8e86-9c3d19e2f2b3" /mnt xfs noauto,noatime 0 0 /mnt/home /home none bind,x-systemd.automount 0 0 /mnt is mounted after unlocking it manually as it is on a luks device. Months before that setup had no issues, so does systemd try now to create namespace for all mountpoints even when the devices don't exist? Regards Bjoern

1 0

btrfs send/receive between same UUID filesystems
by Alipour Alipour 25 Oct '25

25 Oct '25

Does having the same UUID for btrfs filesystem on local and remote machines cause problems when using btrfs send/receive between them (piped through SSH)?

2 1

clipit vs parcellite - Was: "Fwd: Remove GTK2 from the official repositories"
by Ralf Mardorf 24 Oct '25

24 Oct '25

On Fri, 2025-10-24 at 12:32 +0200, Robin Candau wrote: > If anything, gtk2 and related packages can still be maintained in the > AUR, but the point is we are not willing to put efforts into > officially maintaining such deprecated packages anymore. > > Please bear with us and thank you for your understanding :) It is understandable. Btw. I'm testing if clipit can replace parcellite. • root@archlinux /usr/bin # mv -i parcellite parcellite.ori && ln -s clipit parcellite Temporarily, just to see how far one could go. • rocketmouse@archlinux ~ $ grep parc .config/openbox/autostart (sleep 1 && parcellite -n) & Not really and this doesn't change when it's "correctly" startet via clipit -n. There are seemingly no options for the window position. Some windows appear at the cursor position, the menu appears at the upper right corner, but not after pushing <Ctrl><Alt>P, it appears after first pushing <Ctrl><Alt>P followed by pushing <Ctrl><Alt>F. • rocketmouse@archlinux ~ $ cat ~/.config/parcellite/parcelliterc [rc] RCVersion=1 use_copy=true use_primary=false synchronize=false save_history=true history_pos=true history_x=1000 history_y=800 history_limit=25 data_size=0 item_size=5 automatic_paste=false auto_key=false auto_mouse=true key_input=false restore_empty=true rc_edit=false type_search=false case_search=false ignore_whiteonly=false trim_wspace_begend=false trim_newline=false hyperlinks_only=false confirm_clear=true disable_clear=false save_history_Lineno=true current_on_top=true single_line=true reverse_history=false item_length=50 persistent_history=false persistent_separate=false persistent_on_top=false persistent_delim=\\n nonprint_disp=false ellipsize=2 multi_user=true on_unity=false icon_name=parcellite menu_key=<Ctrl><Alt>P history_key=<Ctrl><Alt>H phistory_key=<Ctrl><Alt>X actions_key=<Ctrl><Alt>A • rocketmouse@archlinux ~ $ cat ~/.config/clipit/clipitrc [rc] use_copy=true use_primary=false synchronize=false automatic_paste=false show_indexes=false save_uris=true use_rmb_menu=false save_history=false history_limit=25 history_timeout_seconds=30 history_timeout=false items_menu=20 statics_show=true statics_items=10 hyperlinks_only=false confirm_clear=false single_line=true reverse_history=false item_length=50 ellipsize=2 history_key=<Ctrl><Alt>H actions_key=<Ctrl><Alt>A menu_key=<Ctrl><Alt>P search_key=<Ctrl><Alt>F offline_key=<Ctrl><Alt>O offline_mode=false exclude_windows= Let's see if I can get used to it. Hm? Maybe copying quotes from the Evolution MUA works better with clipit.

1 1

[arch-dev-public] Re: Remove GTK2 from the official repositories
by mpan 24 Oct '25

24 Oct '25

> I think we've reached the point when we can remove the very old GTK2 > package from the official repositories. I recently dropped the GTK2 > version of LXDE, and there are only a few applications left that still > depend on GTK2: > (… pkglist …) > Most of these have no active development a long time ago. If no one has > objections, I'll drop these packages to AUR in the next days if it's > not possible to build them without GTK2. Hello, thanks for building the list. NOTE: steam-native-runtime is missing from the list! Shifting away from GTK2 is a good idea. And any package package that doesn’t build due to gtk2 dependency and is not in active development, should IMO be removed. But other than that I also believe due care is needed and there is no haste. Unless of course gtk2 itself starts to be a serious burden or is at risk of becoming orphaned. Many of the packages listed are not niche. To name a few that instantly caught my eye: pidgin, leafpad, hexchat, gimp-nufraw. To limit subjective perspective’s effect on my opinion, I checked with pkgstats.[tab:1] So this isn’t just a distortion from my singular vantage point. While some projects are either dead (hexchat) or dormant/stalled (leafpad, gimp-nufraw), others are active (pidgin). Being in the first group is not making a package obsolete either, even if users should think about searching for alternatives. If all these packages are moved to AUR, what happens with the now unneeded gtk2 package? Cheers, mpan [tab:1] pkgstats results. [WARNING: statistical data ahead! Values have to be interpreted with proper understanding of their meaning, context, and influences!] Package Popularity [%] -------------------------------- steam-native-runti 12.84 calf 12.04 hexchat 5.30 pidgin 5.30 nitrogen 5.01 bless 3.79 leafpad 3.51 gimp-nufraw 2.65 mono-tools 2.12 gtk-chtheme 2.10 amsynth 2.05 xboard 1.82 eq10q 1.79 gtk2fontsel 1.73 gkrellm 1.62 parcellite 1.57 hexter 1.28 xdialog 1.18 trayer 1.00 xlockmore 0.92 osdlyrics 0.71 alltray 0.55 nspluginwrapper 0.50 gpsim 0.46 sbxkb 0.30

1 0

Any particular reason the gtk2 build was dropped from libfm-gtk2 (int included both gtk2 and gtk3)
by David C Rankin 22 Oct '25

22 Oct '25

All, The latest update to libfm-gtk2 renames it libfm-gtk3 but make is conflict with existing libfm-gtk2. https://gitlab.archlinux.org/archlinux/packaging/packages/libfm/-/commits/m… The libfm-gtk2 package included both gtk2 and gtk3 file manager builds. Now we are left with only gtk3. It was quite convenient for old apps that use the gtk2 functionality. Why did the gtk2 build get dropped? It was working quite nicely with the gtk3 filemanager files, posed no conflict and no additional work. Yes, it's old, but so are a lot of things that work quite well. If there weren't build failures, what was the reason behind the change? -- David C. Rankin, J.D.,P.E.

2 2

Btrfs and nspawn
by Pocket 28 Sep '25

28 Sep '25

I have a system that uses btrfs for the root filesystem. I created a subvolume root which becomes the root filesystem on boot up, ie it bootds to the root subvolume. I now want to add some "containers" to that machine, for example DNS. When set up with bind and started with machinectl provides DNS for the network. Is it possible to use a snapshot for the root subvolume for nspawn containers? I have seen that one can use the --template option but it appears to be a newly created container every time. Thsat won't work as I would lose the bind setup. I need something that is not volatile in which I can install bind an configure it without having to do that every time the container is shutdown and the restarted. Also if I can use the root subvolume as a template will the subsequent containers be updated when I use pacman -Syu to update the root subvolume? -- Hindi madali ang maging ako

2 2