Hi all, Ken, the 2 errors that don't happen to you only happen to me when compiling with --enable-backup. I've tested the beta2 tarball as well as the current git, both errors still happen to me on 2 different machines. Without the --enable-backup option these errors don't occur.
Ellie, I'll send the config.log and the resulting make output to you and Ken directly. I can confirm that the latest master from the dev git has the patch for --disable-squat correctly working and the ICU checking in configure is present now too, but maybe it should be converted from a warning to an error when with --enable-http? DKIM warning doesn't appearing anymore. It would be great to solve the "Parts of com_err distribuion were found, but not compile_et" warning too. I'm also getting: checking for BIO_accept in -lcrypto... yes checking for crypt... no checking for crypt in -lcrypt... yes Warning (mostly harmless): No library found for -lcrypto (same for -lssl) I found another issue with the dependencies: the build requires yacc/lex when building sieve, though in the Release Notes there is the following text: Replaced the et (error table) libary with a version that doesn't require lex or yacc. Remove the lex/yacc checking from Configure. I guess the lex/yacc checking should be placed in the configure again, inside the enable-sieve block. Regards, Anatoli -----Original Message----- From: Ken Murchison [mailto:mu...@andrew.cmu.edu] Sent: Wednesday, May 11, 2016 15:44 To: Anatoli; cyrus-devel@lists.andrew.cmu.edu Subject: Re: v3.0 On 05/09/2016 02:57 AM, Anatoli via Cyrus-devel 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). Patch applied. > 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. A check for ICU4C has been added to configure.ac > 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. I'm not seeing this problem compiling on my machine. I wonder why? > 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? I have commented out the check for DKIM since its not needed for anything that sites will deploy any time soon. > 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 >> >> -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University
