Hi all, I'm testing v3.0.0 beta2. Here goes the feedback, this time for the build process.
1. --disable-squat option in configure has no effect. Please see attached a patch (configure.ac.patch). 2. Without icu-dev package make fails with: unicode/ucal.h No such file or directory It somehow depends on libical, i.e. it looks like icu-dev should be installed before building libical. In any case it should be detected in configure to avoid build errors. 3. With --enable-backup make fails with: /usr/bin/ld: backup/.libs/libcyrus_backup.a(lcb_append.o): undefined reference to symbol 'SHA1_Update@@OPENSSL_1.0.0' //usr/lib64/libcrypto.so: error adding symbols: DSO missing from command line Problem: missing -lcrypto for libcyrus_backup.a /usr/bin/ld: imap/.libs/libcyrus_imap.so: undefined reference to symbol 'cyrusdb_fetch' lib/.libs/libcyrus.so: error adding symbols: DSO missing from command line Problem: missing lib/libcyrus.la for cyr_backup. Please see attached a patch for both errors (Makefile.am.patch). With these fixes build completes without errors. Then I got this new warning: configure: WARNING: Your version of OpenDKIM can not support iSchedule. Consider upgrading to OpenDKIM >= 2.7.0 I don't have DKIM on the box where Cyrus runs, in 2.5.7 there was no warning about DKIM. Haven't investigated the details yet. DKIM is part of the iSchedule draft, but is it required? And should it be OpenDKIM only or any other DKIM package works too? And then there is an old warning (also happens in 2.5.7): configure: WARNING: Parts of com_err distribuion were found, but not compile_et. configure: WARNING: Will build com_err from included sources. What should be installed/changed to avoid it? Or maybe the warning itself should be converted to a notice as compile_et is shipped with cyrus-imap and everything works as expected? Regards, Anatoli -----Original Message----- From: Anatoli [mailto:m...@anatoli.ws] Sent: Tuesday, April 19, 2016 03:39 To: cyrus-devel@lists.andrew.cmu.edu Subject: RE: v3.0 Hi Ellie, Thanks for the link! This is the information I was looking for. Great, there's a new beta! I'll test it these days and if it behaves reasonably well, I'll try to deploy it in a small production environment where the users are OK being beta-testers. I'll post here any issues found. With respect to the specialuse flags issue, it's not possible to set these flags from cyradm in the latest release (2.5.7). I'll check if it's fixed in the 3.0 beta. I have a feature suggestion with respect to these flags. I suppose that most of the deployments use these flags on some folders from the autocreate_inbox_folders list. So, instead of writing scripts that set these flags somehow, what if it would be possible to specify the specialuse flag for each autocreate folder as an optional param (with some (invalid for folder names) char (e.g. ':') as the delimiter)? Something like this: autocreate_inbox_folders: Sent:Sent|Trash:trash|Drafts:DRAFTS|Spam:Junk|OtherFolder1|OtherFolder2 The format would be defines as: folder[:<specialuse_flag>][|folder[:<specialuse_flag>]]... and <specialuse_flag> would be one of the options from the RFC6154 (section 2), interpreted case-insensitively. So when the user logs in for the first time, he/she has all the folders created with the necessary flags. IMO, a significant simplification of the mbox creation process. I haven't analyzed the code for this feature yet, but it should be quite simple to implement. Just parse the optional params, check if the value is in a predefined array and after creation of the folder, set the requested flag. Every flag could be validated for uniqueness or it may be left up to the Cyrus administrator to decide and specify the correct values (I would prefer the later, the RFC explicitly says it's up to each server implementation (section 3)). Regards, Anatoli -----Original Message----- From: Cyrus-devel [mailto:cyrus-devel-bounces+me=anatoli...@lists.andrew.cmu.edu] On Behalf Of ellie timoney via Cyrus-devel Sent: Sunday, April 17, 2016 22:37 To: cyrus-devel@lists.andrew.cmu.edu Subject: Re: v3.0 Hi Anatoli, > I'm quite interested in this release and I'd > like to help with testing, simple problems investigation and fixing, and > similar tasks, That would be greatly appreciated :) > but at least some insight to the current state of the > master is needed for that, i.e. how close it is to an RC, new > functionality expected to work, functionality/configuration changes > compared to v2.5.7, known limitations, etc. Have you looked at the 3.0.0-beta2 that was released last week? Its release notes compare it against the 2.5 series: http://cyrusimap.org/imap/release-notes/3.0/x/3.0.0-beta2.html > I see the T232 by Ellie has 4 issues that are apparently stopping this > release. Are they the only remaining issues for production-ready state? These are just the very narrow intersection of a) what I'm aware of, that has b) been logged at all, and c) is logged in phabricator where I can mark it as blocking (rather than in bugzilla, the mailing list, private email, etc). > The roadmap > (https://cyrusimap.org/overview/cyrus_roadmap.html#cyrus-roadmap) says > nothing about v3.0 and looks a little outdated. This page looks like a direct import of the page from the old website. I'm not sure quite how old it is, but given it's referencing "2.6" as future, that suggests that it's over a year old... > I'm personally interested in resolving the "specialuse flags not working > from cyradm" (T199, 198, 191, 121; looks like still pending) issue Are these still issues? Or are they stale tasks that have been fixed but not closed? We've had a number of cyradm metadata patches contributed by a few different people over the last year, so it seems probable that at least some are fixed but the assignees don't know. > Also I made a raw chroot patch for 2.5.7, > I'd like to polish and submit it for review and inclusion in v3.0. That'd be great! > Should I write to someone in particular to discuss the subject? Everyone working on Cyrus 3.0 is active on this list, so this is probably the best place for it. You're also welcome to join our conference calls, they happen at 11am UTC most Mondays on Google Hangouts. Probably the easiest way to join is to come into #cyrus on Freenode IRC at the meeting time and ask for the hangouts link, because it changes occasionally. Cheers, ellie On Sat, Apr 16, 2016, at 04:41 AM, Anatoli via Cyrus-devel wrote: > Hi folks, > > Sorry for bothering you again with subj, I haven't received any answer to > the previous mails about it. I'm quite interested in this release and I'd > like to help with testing, simple problems investigation and fixing, and > similar tasks, but at least some insight to the current state of the > master is needed for that, i.e. how close it is to an RC, new > functionality expected to work, functionality/configuration changes > compared to v2.5.7, known limitations, etc. > > I see the T232 by Ellie has 4 issues that are apparently stopping this > release. Are they the only remaining issues for production-ready state? > The roadmap > (https://cyrusimap.org/overview/cyrus_roadmap.html#cyrus-roadmap) says > nothing about v3.0 and looks a little outdated. > > I'm personally interested in resolving the "specialuse flags not working > from cyradm" (T199, 198, 191, 121; looks like still pending) issue and in > XAPPLEPUSHSERVICE feature, but I know there are a lot of other > improvements and new libraries support (like LibiCal2.0) that are worth > the effort releasing it ASAP. Also I made a raw chroot patch for 2.5.7, > I'd like to polish and submit it for review and inclusion in v3.0. > > Should I write to someone in particular to discuss the subject? > > Regards, > Anatoli > >
Makefile.am.patch
Description: Binary data
configure.ac.patch
Description: Binary data
