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
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
from upstream until stated otherwise.
We want to provide an update on the recent service outages affecting our infrastructure. The Arch Linux Project is currently experiencing an ongoing denial of service attack that primarily impacts our main webpage, the Arch User Repository (AUR), and the Forums.
We are aware of the problems that this creates for our end users and will continue to actively work with our hosting provider to mitigate the attack. We are also evaluating DDoS protection providers while carefully considering factors including cost, security, and ethical standards.
To improve the communication around this issue we will provide regular updates on …
Starting with 7.4.1-2, the following Zabbix system user accounts (previously shipped by their related packages) will no longer be used. Instead, all Zabbix components will now rely on a shared zabbix user account (as originally intended by upstream and done by other distributions):
- zabbix-server
- zabbix-proxy
- zabbix-agent (also used by the
zabbix-agent2 package)
- zabbix-web-service
This shared zabbix user account is provided by the newly introduced zabbix-common split package, which is now a dependency for all relevant zabbix-* packages.
The switch to the new user account is handled automatically for the corresponding …
With 20250613.12fe085f-5, we split our firmware into several vendor-focused packages. linux-firmware is now an empty package depending on our default set of firmware.
Unfortunately, this coincided with upstream reorganizing the symlink layout of the NVIDIA firmware, resulting in a situation that Pacman cannot handle. When attempting to upgrade from 20250508.788aadc8-2 or earlier, you will see the following errors:
linux-firmware-nvidia: /usr/lib/firmware/nvidia/ad103 exists in filesystem linux-firmware-nvidia: /usr/lib/firmware/nvidia/ad104 exists in filesystem linux-firmware-nvidia: /usr/lib/firmware/nvidia/ad106 exists in filesystem linux-firmware-nvidia: /usr/lib/firmware/nvidia/ad107 exists in filesystem
To progress with the system upgrade, first remove linux-firmware, then reinstall it as part of the upgrade:
…
On Plasma 6.4 the wayland session will be the only one installed when the users does not manually specify kwin-x11.
With the recent split of kwin into kwin-wayland and kwin-x11, users running the old X11 session needs to manually install plasma-x11-session, or they will not be able to login. Currently pacman is not able to figure out your personal setup, and it wouldn't be ok to install plasma-x11-session and kwin-x11 for every one using Plasma.
tldr: Install plasma-x11-session if you are still using x11
