v3.0

[qyb]

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> 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> 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:me at anatoli.ws]
>> Sent: Tuesday, April 19, 2016 03:39
>> To: 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=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
>> 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
>> >
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20160518/8cb04dc0/attachment-0001.html>