October 2025 - Arch-dev-public - lists.archlinux.org

First step for non-x86_64 contributions
by Levente Polyak 27 Jan '26

27 Jan '26

# First step for non-x86_64 contributions Hey everyone, I'd like to share my view on the first step for targeting non-x86_64 architectures in our packages. While our official infrastructure for non-x86 support isn't ready yet and will still take some time to materialize, I'd very much like to avoid siting on our hands until that day comes. There's already a ton of community interest and effort around non-x86_64. There's plenty of low hanging fruits and clean patches that are easy to review, well contained, and good groundwork. So instead of waiting for the perfect day before starting, I'd like to open the door to small, clear, and non intrusive contributions under tightly scoped rules. We should rather slowly and carefully build up compatibility now, than scramble once infra, hardware and tooling catches up. I propose the following guidelines as a first step towards implementing [RFC0032](https://rfc.archlinux.page/0032-arch-linux-ports/). ## Guidelines ### Protecting x86_64 We do not want to compromise on our primary platform. Clearly do not break or remove x86_64 behavior, functionality or features. Incompatible features or dependencies must be proposed in a way that preserves the functionality of our primary platform. ### Non-intrusive Small, focused changes that are easy to understand at a glance and can be reasoned about even without building and running it on different architectures. ### No downstream wizardry Complex, opaque, or heavy software patching is out of scope. Carrying around massive software patches downstream isn't feasible at this stage, save that for later and work together with upstream instead. ### Merge-request indicator All secondary architecture related merge-requests must be flagged with the new `pkg::ports` GitLab label. It'll help separate them from the usual requests and allow interested packagers and contributors to filter on them globally, to help out others. ### Manageable load Contributors must stick to small merge-request batches max 10 open MRs per person. All proposals must be sent manually, no fire-and-forget scripts. Collaboration is expected. If questions come up, we expect thoughtful responses from people who precisely know the changes they're submitting. ## Out of scope ### arch array No changes to `arch=()` arrays. ### non-x86_64 issues No issues or bug reports for non-x86_64. If something's broken with the `PKGBUILD`, you'll need to sort it out and send a merge-request. Don't file bugs in the tracker for other architectures. --- This approach allows us to slowly build up compatibility and make good progress without burning out our packagers and bug-wranglers or flooding our GitLab with changes and bug reports we can't handle. We can stretch out the work by allowing confined changes and avoid to stack it all for later. It gives us room to prepare without needing full build infrastructure, provide active support or require special hardware in place today. I think this really hits the right balance, tight enough to avoid burnout, open enough to make progress and welcoming enough to motivate and start harvesting work from our community. Cheers, Levente

9 14

News draft: dovecot >= 2.4 requires manual intervention
by Thore Bödecker 29 Oct '25

29 Oct '25

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

1 0

Remove GTK2 from the official repositories
by Balló György 26 Oct '25

26 Oct '25

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

2 2

New CDN based mirror now available: fastly.mirror.pkgbuild.com
by gromit 20 Oct '25

20 Oct '25

Hello everyone, we [have now setup][0][1] an additional option for a worldwide mirror: https://fastly.mirror.pkgbuild.com With the caching done by the Fastly CDN, the bandwidth speeds and time to first byte should be quite good all around the globe, especially as more and more people start using the service. Thanks a lot to Fastly for sponsoring us with free access to their services! This new mirror can be seen as an orthogonal approach to the already existing, also DevOps administered geomirrors, which will not be replaced by the CDN based mirror. Please check it out and [let us know][2] if you find any problems with it! Kind regards, Antiz, Pitastrudl and gromit [0]: https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/1031 [1]: https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/639 [2]: https://gitlab.archlinux.org/archlinux/infrastructure/-/issues

1 0

GHC 9.6.6 enters [extra-testing]
by Felix Yan 13 Oct '25

13 Oct '25

Hi all, The GHC 9.6.x updates have now entered [extra-testing]. This time, four packages have been retired, so please remove them manually if you have them installed: - haskell-configfile - haskell-monad-gen - haskell-monad-journal - haskell-success Again a special thanks to @Vekhir for helping me in preparing many batches of updates, including this one. Please let me know if you encounter any issues. Otherwise, the batch will be moved to [extra] in a few days. -- Regards, Felix Yan

1 0

New filesystem in core-testing with fully locked accounts
by David Runge 12 Oct '25

12 Oct '25

Hi all, please note, that filesystem 2025.10.12 in core-testing now features fully locked user accounts [1] based on the ongoing related TODO [2]. In case you run into any issues with those user accounts because of this, please report them as ticket on the package. Best, David [1]: https://gitlab.archlinux.org/archlinux/packaging/packages/filesystem/-/comm… [2]: https://archlinux.org/todo/change-sysusers-to-fully-locked-system-accounts/

1 0

HEADS UP: Qt 6.10 in [extra-testing]
by Antonio Rojas 07 Oct '25

07 Oct '25

This is a reminder that anything compiled against 6.10 will automatically depend on it, so it will have to stay in testing until Qt itself moves.

1 0