I try to build 3.0.0-beta2 on my Ubuntu 14.04 mechine. I've apt-get install libopendkim-dev, (2.9.1-1) configure report 'WARNING: Your version of OpenDKIM can not support iSchedule. Consider patching OpenDKIM with contrib/dkim_canon_ischedule.patch'
Maybe we should commit the patch to OpenDKIM upstream first On Mon, May 9, 2016 at 2:57 PM, Anatoli via Cyrus-devel < cyrus-devel@lists.andrew.cmu.edu> wrote: > 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 > > > > >
