<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
This definitely looks like a pre-2.0 version of the library is being
found.<br>
<br>
<br>
<div class="moz-cite-prefix">On 05/18/2016 11:35 AM, qyb via
Cyrus-devel wrote:<br>
</div>
<blockquote
cite="mid:CACxcJcQaBmS8zvkQu=V9RvvogdshkTqUXBDXtV=Nmmf4RpAsCA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>I've installed libical 2.0.50, but configure
still report libical > 2.0 checkerror<br>
<br>
</div>
# pkg-config libical --modversion<br>
2.0.50<br>
</div>
# pkg-config libical --libs<br>
</div>
-L/usr/local/lib -ical -licalss -licalval -lpthread<br>
</div>
#pkg-config libical --cflags<br>
</div>
-I/usr/local/include<br>
<br>
...<br>
checking for ICAL... yes<br>
checking whether icalproperty_get_parent is declared... yes<br>
checking whether icalrecur_freq_to_string is declared... yes<br>
checking whether icalrecur_weekday_to_string is declared...
yes<br>
checking for icalparameter_new_iana in -lical... yes<br>
checking for icalparameter_new_schedulestatus in -lical...
yes<br>
checking for icalparameter_new_managedid in -lical... no<br>
checking for icalproperty_new_tzuntil in -lical... no<br>
checking for icaltimezone_set_builtin_tzdata in -lical... no<br>
configure: WARNING: Your version of libical can not support
timezones by reference. Consider upgrading to libical >=
1.0.1<br>
checking for icalcomponent_new_vavailability in -lical... no<br>
configure: WARNING: Your version of libical can not support
availability. Consider upgrading to libical >= 1.0.1<br>
checking for icalcomponent_new_vvoter in -lical... no<br>
configure: WARNING: Your version of libical can not support
consensus scheduling. Consider upgrading to libical >=
2.0<br>
checking for icalrecurrencetype_rscale_is_supported in
-lical... no<br>
configure: WARNING: Your version of libical can not support
non-gregorian recurrences. Consider upgrading to libical
>= 2.0<br>
...<br>
<br>
</div>
Checking libical.so install location, I noticed that it
located at /usr/local/lib/x86_64-linux-gnu.<br>
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'<br>
</div>
If i run <br>
# gcc ... -L/usr/local/lib/x86_64-linux-gnu ... <br>
gcc will link withour error.<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, May 18, 2016 at 10:40 PM, qyb <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:qiuyingbo@gmail.com" target="_blank">qiuyingbo@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<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="HOEnZb">
<div class="h5">
<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
moz-do-not-send="true"
href="mailto:cyrus-devel@lists.andrew.cmu.edu"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:cyrus-devel@lists.andrew.cmu.edu">cyrus-devel@lists.andrew.cmu.edu</a></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 '<a class="moz-txt-link-abbreviated" href="mailto:SHA1_Update@@OPENSSL_1.0.0">SHA1_Update@@OPENSSL_1.0.0</a>'<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 moz-do-not-send="true"
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><br>
<br>
-----Original Message-----<br>
From: Anatoli [mailto:<a
moz-do-not-send="true"
href="mailto:me@anatoli.ws" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:me@anatoli.ws">me@anatoli.ws</a></a>]<br>
Sent: Tuesday, April 19, 2016 03:39<br>
To: <a moz-do-not-send="true"
href="mailto:cyrus-devel@lists.andrew.cmu.edu"
target="_blank">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><br>
-----Original Message-----<br>
From: Cyrus-devel<br>
[mailto:<a moz-do-not-send="true"
href="mailto:cyrus-devel-bounces%2Bme"
target="_blank">cyrus-devel-bounces+me</a>=<a
moz-do-not-send="true"
href="mailto:anatoli.ws@lists.andrew.cmu.edu"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:anatoli.ws@lists.andrew.cmu.edu">anatoli.ws@lists.andrew.cmu.edu</a></a>]
On Behalf Of<br>
</span><span>ellie timoney via Cyrus-devel<br>
Sent: Sunday, April 17, 2016 22:37<br>
To: <a moz-do-not-send="true"
href="mailto:cyrus-devel@lists.andrew.cmu.edu"
target="_blank">cyrus-devel@lists.andrew.cmu.edu</a><br>
Subject: Re: v3.0<br>
<br>
</span>
<div>
<div>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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University
</pre>
</body>
</html>