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> 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> 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 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] >> Sent: Tuesday, April 19, 2016 03:39 >> To: 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=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 >> 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 >> > >> > >> > >
