v3.0

Ken Murchison murch at andrew.cmu.edu
Wed May 11 14:43:32 EDT 2016



On 05/09/2016 02:57 AM, Anatoli via Cyrus-devel 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).

Patch applied.


> 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.

A check for ICU4C has been added to configure.ac


> 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.

I'm not seeing this problem compiling on my machine.  I wonder why?


> 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?

I have commented out the check for DKIM since its not needed for 
anything that sites will deploy any time soon.


> 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:me at anatoli.ws]
> Sent: Tuesday, April 19, 2016 03:39
> To: cyrus-devel at 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.ws at lists.andrew.cmu.edu] On Behalf Of
> ellie timoney via Cyrus-devel
> Sent: Sunday, April 17, 2016 22:37
> To: cyrus-devel at 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
>>
>>

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University



More information about the Cyrus-devel mailing list