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