<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <br>
    <div class="moz-cite-prefix">On 05/18/2016 10:40 AM, qyb via
      Cyrus-devel wrote:<br>
    </div>
    <blockquote
cite="mid:CACxcJcQ5kK+YuijmOLZvhAK8YjVUnRxgs_Vupfu+S86RyPnQ7A@mail.gmail.com"
      type="cite">
      <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>
        </div>
      </div>
    </blockquote>
    <br>
    As stated earlier, the DKIM check has been removed and will not be
    present in beta3.<br>
    <br>
    <br>
    <blockquote
cite="mid:CACxcJcQ5kK+YuijmOLZvhAK8YjVUnRxgs_Vupfu+S86RyPnQ7A@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div><br>
        </div>
        <div>Maybe we should commit the patch to OpenDKIM upstream first<br>
        </div>
      </div>
      <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">cyrus-devel@lists.andrew.cmu.edu</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 class="h5"><br>
                <br>
                -----Original Message-----<br>
                From: Anatoli [mailto:<a moz-do-not-send="true"
                  href="mailto:me@anatoli.ws">me@anatoli.ws</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">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 class="im HOEnZb"><br>
              -----Original Message-----<br>
              From: Cyrus-devel<br>
              [mailto:<a moz-do-not-send="true"
                href="mailto:cyrus-devel-bounces%2Bme">cyrus-devel-bounces+me</a>=<a
                moz-do-not-send="true"
                href="mailto:anatoli.ws@lists.andrew.cmu.edu"><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 class="im HOEnZb">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">cyrus-devel@lists.andrew.cmu.edu</a><br>
              Subject: Re: v3.0<br>
              <br>
            </span>
            <div class="HOEnZb">
              <div class="h5">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>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University
</pre>
  </body>
</html>