v3.0
Ken Murchison
murch at andrew.cmu.edu
Thu May 19 07:56:35 EDT 2016
This definitely looks like a pre-2.0 version of the library is being found.
On 05/18/2016 11:35 AM, qyb via Cyrus-devel wrote:
> I've installed libical 2.0.50, but configure still report libical >
> 2.0 checkerror
>
> # pkg-config libical --modversion
> 2.0.50
> # pkg-config libical --libs
> -L/usr/local/lib -ical -licalss -licalval -lpthread
> #pkg-config libical --cflags
> -I/usr/local/include
>
> ...
> checking for ICAL... yes
> checking whether icalproperty_get_parent is declared... yes
> checking whether icalrecur_freq_to_string is declared... yes
> checking whether icalrecur_weekday_to_string is declared... yes
> checking for icalparameter_new_iana in -lical... yes
> checking for icalparameter_new_schedulestatus in -lical... yes
> checking for icalparameter_new_managedid in -lical... no
> checking for icalproperty_new_tzuntil in -lical... no
> checking for icaltimezone_set_builtin_tzdata in -lical... no
> configure: WARNING: Your version of libical can not support timezones
> by reference. Consider upgrading to libical >= 1.0.1
> checking for icalcomponent_new_vavailability in -lical... no
> configure: WARNING: Your version of libical can not support
> availability. Consider upgrading to libical >= 1.0.1
> checking for icalcomponent_new_vvoter in -lical... no
> configure: WARNING: Your version of libical can not support consensus
> scheduling. Consider upgrading to libical >= 2.0
> checking for icalrecurrencetype_rscale_is_supported in -lical... no
> configure: WARNING: Your version of libical can not support
> non-gregorian recurrences. Consider upgrading to libical >= 2.0
> ...
>
> Checking libical.so install location, I noticed that it located at
> /usr/local/lib/x86_64-linux-gnu.
> But in config.log, gcc link library as 'gcc -o conftest -g -O2
> /tmp/x.c -lical -lpcre -lpcreposix -lz -lxml2 -L/usr/local/lib
> -lical -licalss -licalvcal -lpthread'
> If i run
> # gcc ... -L/usr/local/lib/x86_64-linux-gnu ...
> gcc will link withour error.
>
> On Wed, May 18, 2016 at 10:40 PM, qyb <qiuyingbo at gmail.com
> <mailto:qiuyingbo at gmail.com>> 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'
>
> 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/e9172670/attachment-0001.html>
More information about the Cyrus-devel
mailing list