v3.0
Ken Murchison
murch at andrew.cmu.edu
Thu May 19 07:52:57 EDT 2016
On 05/18/2016 10:40 AM, qyb via Cyrus-devel wrote:
> 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'
As stated earlier, the DKIM check has been removed and will not be
present in beta3.
>
> 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 at lists.andrew.cmu.edu
> <mailto:cyrus-devel at 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 <http://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:me at anatoli.ws <mailto:me at anatoli.ws>]
> Sent: Tuesday, April 19, 2016 03:39
> To: cyrus-devel at lists.andrew.cmu.edu
> <mailto: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
> <mailto:cyrus-devel-bounces%2Bme>=anatoli.ws at lists.andrew.cmu.edu
> <mailto: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
> <mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20160519/577d5087/attachment.html>
More information about the Cyrus-devel
mailing list