Arch Linux User Repository

guygma: yes, but the problem two level depth in cyrus-imapd dependency tree. cyrus-imapd PKGBUILD is fine.

Ok, I will try that... but shouldn’t these things be dependencies defined in the PKGBUILD? I was not at all thinking a set of packages was missing.

guygma: pacman -S perl-module-install

See https://aur.archlinux.org/packages/perl-pod-pom/ This is a depenency of perl-pod-pom-view-restructured.

This is breaking for me due to a perl error:

Can't locate inc/Module/Install.pm in @INC (you may need to install the inc::Module::Install module) (@INC contains: /usr/lib/perl5/5.30/site_perl /usr/share/perl5/site_perl /usr/lib/perl5/5.30/vendor_perl /usr/share/perl5/vendor_perl /usr/lib/perl5/5.30/core_perl /usr/share/perl5/core_perl) at Makefile.PL line 2. BEGIN failed--compilation aborted at Makefile.PL line 2. ==> ERROR: A failure occurred in build().

Can anyone make sense of this and/or are others experiencing it? It is not a path resolution issue

I just updated the package to fix all the issues you reported. I'll have to look into upstreaming some of those patches sometime, but for now at least everything should work again. I tried fixing the compatibility issues with Sphinx 2 but that turned out to trickier than I first thought, so for the time being we'll indeed need to build with Sphinx 1. While old versions of the python-sphinx package might work for that purpose, I also turned 1.8.5-1 into the AUR package python-sphinx1 which can be updated should other updates break Sphinx 1.

In April the start of the summer semester kinda messed up my organisation, hence the long wait. Sorry about that! If there are any other issues left, let me know and I should be able to get them resolved much faster now.

Edit: TheGoliath, I noticed I didn't address your comment about the missing perl-module-install. I couldn't reproduce that issue in this package, but I know perl-pod-pom has an issue like that which the maintainer has yet to fix. Might you be referring to that package rather than this one?

To build it now two things need to be done:

1. Apply patch from this commit:

   https://github.com/cyrusimap/cyrus-imapd/pull/2750/commits/ad4d5fb85e1480158ee32c9b0d3d0baeac2c324a

2. run makepkg in venv with sphinx-1.8.5 installed: python -m venv /tmp/venv; source /tmp/venv/bin/activate; pip install sphinx==1.8.5; makepkg;

Filed an issue upstream, TheGoliath: https://github.com/cyrusimap/cyrus-imapd/issues/2749

I just updated this package to Cyrus 3.0.9 and will push that update in a moment. Since Cyrus 3.0 is a major new version to begin with, I also used the opportunity to make some major changes to this package as well, mostly in order to adhere to certain conventions or as a matter of housekeeping. In doing so I have tried to bring the package back into a good shape after that long-time lack of maintenance, but if there’s something you are unhappy with or if you have further suggestions for improvement, please let me know. Since the changes are so unusually extensive, here’s a rundown of them, how they impact the upgrade procedure (if so) and some reasoning behind them.

• The most important bit first: Please stop Cyrus before upgrading – there are changes in both this package and Cyrus itself that could otherwise prevent a clean upgrade.
• Please also read through the upgrade guide before performing the upgrade.
• Before 3.0, the Cyrus documentation suggested using /var/imap and /var/spool/imap as the config directory and location for partitions, respectively. In 3.0, most materials, including the example config files, point to /var/lib/cyrus and /var/spool/cyrus instead. Therefore, I have changed the default paths in this package as well, however there is no automatic migration, so if you want to migrate to the new directories you will have to do so manually. Of course you can keep using the previous directories as well if you want.
• Previously, the cyrus user was assigned a random non-system uid (>=1000). Now, it uses a fixed uid and gid of 70, which has been assigned to it for a long time. The id is updated automatically, however you will have to adjust the permissions of paths owned by that user manually, including the previously mentioned /var/imap and /var/spool/imap.
• The systemd unit has been renamed from cyrus-master.service to cyrus-imapd.service, to make the name more predictable and consistent with other services. cyrus-imapd.service is also the name used by every other distribution I could find, and is even referred to in Cyrus’s own documentation. However this change means that you will have to re-enable the service if it was enabled before.

Additionally, the following changes have also been made, but usually these should not impact the upgrade procedure:

• The /etc/conf.d/cyrus-master configuration file has been removed. It wasn’t even being used before, and I believe most people won’t need to adjust the command-line parameters anyway. If you still need to do so, you can create a drop-in file for the systemd unit.
• I’ve completely overhauled the build configuration. In the process, I’ve decided to enable a number of features which weren’t enabled by default. This means that the package has now more dependencies than before, however many of them are likely to be installed on a (mail) server anyway – for example, sqlite, postgresql-libs and mariadb-libs are also needed for postfix and opendkim, among others, while libnghttp2, krb5 and libldap are directly or indirectly required by the ubiquitous curl package. I tried to make a sensible selection, but I’m open to suggestions. I decided against splitting individual components out, but I’m also open to discussing this decision as well.
• Speaking of split packages, there is now one containing the Cyrus documentation, which was completely overhauled in 3.0.
• The package no longer conflicts with imap-server and pop3-server. I believe all files which could warrant such a conflict (particularly imapd and pop3d) currently reside in Cyrus’s own libexec directory, but let me know if I overlooked something.
• !makeflags has been removed from options. I tried building with multiple simultaneous jobs and couldn’t find any problems. Again, let me know if I was mistaken.
• The install file has been rewritten from scratch. User creation is now handled by systemd-sysusers. The state directories are no longer initialised automatically – this should now be done manually by running mkimap as cyrus:mail (invoke it as sudo runuser -u cyrus -g mail mkimap /etc/cyrus/imapd.conf, for example). They are also no longer set to update synchronously on ext[234] file systems, since this was only ever meant for systems using ext2 which is so ancient that I’m not going to explicitly support it. The configuration files are no longer chowned to cyrus and made read-only to everyone else, as is normally the case for such configuration files.
• Perl files are now installed into vendor_perl rather than site_perl, as per Perl package guidelines.