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