Packages (2)

Pinned Comments

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.

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.

Latest Comments

Small update: I finally figured out how to make the documentation build with Sphinx 2, so the dependency on Sphinx 1 is now gone and there is no longer any need for that virtualenv hack either. I’m sorry that I could’t get it done any earlier.

guygma: Thanks for the submission. It’s not my way of doing things (I’d rather do it the way it is now or come up with a patch to make it work with Sphinx 2) but I’ll pin a link to it for those who prefer your solution (I don’t want to pin the PKGBUILD itself because that’d push the upgrade note down by a lot). My primary reason for this is that with your solution, the use of pip will result in lots of downloads during the build phase, and this means that if you’re building packages in a clean environment like a chroot (as you have done yourself), those dependencies can’t be cached and will have to be re-downloaded for every package build that needs them. The way it is now, you might have to install “over 200MB” (according to zork, haven’t checked myself) of python2-sphinx dependencies in whatever your build environment is, however those only need to be downloaded once and can then be re-used for every build that needs them. Using pip, on the other hand, these dependencies will have to be re-downloaded on every build, e.g. (presumably) for the next version or (especially important for me) when implementing and testing changes to the packaging process.

Edit: While I won’t be incorporating this change, I do see that it makes the build process more tedious and I’ll give patching for version 2 another try when I find some time for it next week.

Also, on a different note, if you’re here for JMAP support, I’m afraid you’ll have to be a little more patient, since experimental JMAP support was removed in version 3.0.6 and is now planned to have its full release in a later version. Alternatively, if you can’t stand the wait, you could try an unstable version (3.1.x) or the latest code from the master branch. Right now the --enable-jmap option is simply ignored (as you’ll see in build output: configure: WARNING: unrecognized options: --enable-jmap).

OK, so I have updated the PKGBUILD and managed to build in a clean chroot with all of the options enabled (including xapian). I have included the PKGBUILD below in the hopes it makes it easy for the maintainer to update it if they see fit. Also, those who take care to read it may input the edits themselves on their local copy if they had trouble with the previous version as I did.

I believe I have incorporated the suggestions made by all the recent comments in this thread.

EDIT: I can also confirm that --enable-jmap builds properly, which is fantastic as JMAP functionality was the main reason I am moving from Dovecot to Cyrus.

Yes, it should, but sometimes dependencies get overlooked. As you can see, both I and another user already noted the missing dependency in the comment section of perl-pod-pom back in march, however the maintainer still hasn’t taken action.

On another note, please make sure you have a basic understanding of how installing packages from AUR works. Since you seemingly weren’t aware of the issue with perl-pod-pom and thought it was a problem with this package, I’m suspecting you are using some AUR helper to install these packages. However, it is pretty dangerous to use those tools without an understanding of what exactly they are doing, since the packages on the AUR are created by other users and there is no guarantee they won’t do malicious things to your system. The AUR wiki article should be a good starting point for learning more. If you do know all that already, though, I guess you’ll be safe; I’m just trying to be helpful :)

Edit: Well, looks like someone was faster than me. I shouldn’t try to work on too many things at the same time I guess ^^

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?