This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

I have been working on this on and off, but haven't committed anything yet.  If you want to commit an update then please feel free.

Note that upstream has requested that 3.0 go into F26 if at all possible, which is fine with me.

The Cyrus team is proud to announce the immediate availability of a new
version of Cyrus IMAP: 3.0.1

This is a bug fix release for the 3.0 series.

Download URLs:

    http://www.cyrusimap.org/releases/cyrus-imapd-3.0.1.tar.gz
    http://www.cyrusimap.org/releases/cyrus-imapd-3.0.1.tar.gz.sig

    ftp://ftp.cyrusimap.org/cyrus-imapd/cyrus-imapd-3.0.1.tar.gz
    ftp://ftp.cyrusimap.org/cyrus-imapd/cyrus-imapd-3.0.1.tar.gz.sig

Been working with packaging the git snapshot plus cassandane, since 3.0.0 wouldn't build with the system xapian.

cyrus-imapd-3.0.1-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-051e4e14b8

cyrus-imapd-3.0.1-1.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-051e4e14b8

The package has two problems I've noted.

It conflicts with files from "dump"

It does not contain the "deliver" binary although it does have the man pages for some reason. That's a critical part of my install...wondered why I wasn't getting any email.

Ouch, I thought I had cleaned up all of the conflicts.  I will check again.  3.0 now doesn't support installing many of its binaries to a private directory as in previous versions.

I will see where deliver went.

This update will not be pushed to F26 in any case, though upstream still does want me to get 3.0 out to F26 in any case.  Sadly it's so late but this is when my free time fell.

Thanks for the testing.

OK, hmm, cyrus-imapd-utils has /usr/sbin/deliver.  I'm guessing that the split between the utils and main packages are kind of messed up since upstream moved a number of things around.

In addition to the conflict on /usr/sbin/restore, there is also a conflict on /usr/sbin/quota.  Upstream has expressed a desire to have everything renamed with a "cyr_" prefix so that's what I'll do.

cyrus-imapd-3.0.1-7.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-0adf281d8c

cyrus-imapd-3.0.1-7.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-0adf281d8c

I haven't run it yet but while I've been modifying all the configuration files I noticed a few things.

These configuration files move everything around. The package installation script should probably move these directories from the old version to the new version. Or leave them in the old place. For example /var/spool/cyrus/mail is the new location but /var/spool/imap was the old location.

The other thing is the right under the comment in imapd.conf that "KEEP THESE IN SYNC WITH cyrus.conf" the sockets are placed into /run. But the locations in cyrus.conf are NOT the same.

Also in imapd.conf.rpmnew (which I think is from this new cyrus package) the end of the file is missing the Fedora crypto policy stuff. And it has the tls_cert_file, tls_key_file, tls_ca_file config lines that were deprecated a few versions ago.

And rpm -ql cyrus-imap shows that it includes the /var/spool/imap directory. But I think it should be the /var/spool/cyrus directory instead?

You're going to need to add a tmpfiles.d for systemd startup, maybe like this:

cat /etc/tmpfiles.d/cyrus-imapd.conf
#Type Path         Mode UID   GID   Age Argument
d     /run/cyrus   -    cyrus mail
d     /run/cyrus/proc   -    cyrus mail
d     /run/cyrus/lock   -    cyrus mail
d     /run/cyrus/socket -    cyrus mail

Except in the /usr/lib/tmpfiles.d of course.

And I had an issue with /var/run/cyrus/socket and /usr/sbin/deliver and SELinux rules.

The old SELinux type was cyrus_var_lib_t and in the new directory location they inherit cyrus_var_run_t

I think the type is fine but the selinux rules need to allow the deliver binary to write to cyrus_var_run_t files. Or make a new type for the cyrus socket files.

Also for upgrading I found that you're supposed to run "reconstruct -V max" to rebuild all the Cyrus database files to the newest aka "max" database versions. Maybe that should be added to the postinstall script, after moving the spool files to the new directory.

OK, the stream of comments in this ticket is kind of overwhelming.  To take things in a random order:

Not sure why the tempfiles.d thing has never been required before, but I'll have a look.

Selinux issues can't be handled by this package, and will need to be reported against the selinux-policy package instead.

I don't believe it is reasonable to run a full reconstruct in %post; that would run on every package update.  I can't guarantee that it's save, or reasonable to run in the context of when a package upgrade might be run.  That's more of a release notes thing instead.

I think that the stock config needs some modification to get closer to what the previous Fedora defaults were.  I don't think moving things wholesale to /var/spool/cyrus makes sense.  Sadly the history of this package is so complicated that the end result is going to be a mismash of sources for the defaults.

Sorry about the comment stream. I was making them as I was going along with the package upgrade and test.

The tmpfiles.d thing is needed because /run doesn't have the directories with the right permissions since it gets wiped on every reboot. I believe the old cyrus-imapd package created those directories in /var/lib

If the config files in the package went back to how they were in the last version, then tmpfiles.d and SELinux changes would not be needed. But I do sort of like putting the socket files and tracking databases into /run.

Proposed as a Freeze Exception for 26-final by Fedora user tibbs using the blocker tracking app because:

 I completely understand if you deny this but I figured I'd ask anyway.

Upstream requested that I get a new version of the Cyrus IMAP server into Fedora.  I've put a lot of effort into the package over the past month or so but actually getting the update pushed to F26 kept being held up.  I had an update in the pipe, but it hit the 3 day period while I was out of town and I didn't get to push it until this morning.

At this point, if the 3.0.1 update goes out as a zero day, then what ships in F26 GA will be incompatible with the zero day update.  And I've already submitted a release note mentioning the update as well.  I don't think this package will be on any media so it shouldn't be absolutely critical but it might help to avoid confusion.

Yes, of course I missed the deadline to push the most recent update because I was away for a bit.  At this point leaving 2.5.whatever in F26 GA and pushing a 0-day update is IMHO worse then having the current updates-testing 3.0.1 package and pushing an update soon after GA.  But either way it would be better to get version 3 pushed.  It's also in the release notes.

Discussed at 2017-06-29 freeze exception review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2017-06-29/f26-blocker-review.2017-06-29-16.00.html . Accepted as a freeze exception: cyrus is in the 'mail-server' group, which we think is on the Server DVD, and we agree it'd be better not to ship a version on the DVD which is incompatible with a post-release update. Please do double check the update is in good shape and will not cause any dependency issues, though; please make sure it does not depend on any *other* update still in updates-testing.

cyrus-imapd-3.0.1-7.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.

Since this bug was autoclosed but was also used for some other issues which really should have been in separate tickets, I'll just note that I've pushed an update to testing which updates to 3.0.2 and which should also fix the other issues pointed out here.  It includes a rework of the default config files to match the directories actually used (which is partially a problem I need to report upstream, since they don't actually follow their "keep these in sync" comment).  It also contains a tempfiles.d config file; I decided against trying to move those things back to /var/lib/imap because keeping the hot/throwaway databases in RAM really does make a lot of sense and that's really where sockets and such should go anyway.  And keeping with /var/lib/imap makes sense to avoid even more issues with selinux (though really anything other than a trivial installation would mount some space under /srv for that instead).