Hi Quanah,
> Is someone able to answer as to what the process should be for accepting
> merges? I'd like to be able to move forward on cyrus-sasl development. :)
I'm not really sure, but maybe this is something we can all chat about and
figure something out. Are you able to join one of our we
Prototype with some usage examples here:
https://github.com/cyrusimap/cyrus-imapd/pull/3149
On Mon, 17 Aug 2020, at 10:06 PM, Ricardo Signes wrote:
> On our weekly call this morning, we were talking about moving toward
> standardizing the format of Cyrus logs. My interest here is in making it
The Cyrus team is pleased to announce the immediate availability of a new
version of Cyrus IMAP: 3.3.0
This is a snapshot of the master branch, and should be considered for testing
purposes and bleeding-edge features only. It is available as a git tag, which
can be found here:
https://github.c
ta window;
> >>> but now that it's in a stable release, it will remain as it is.
> >>
> >> Thanks for the explanation. What happens is that at least Cal/CardDAV
> >> compile and work well without libchardet (at least under normal
> >> circumstances
The build-time dependencies are listed on the Compiling page under the
"Developers only" heading:
https://www.cyrusimap.org/imap/developer/compiling.html#developers-only
Additionally, these dependencies are only required when building from git
sources. In our official release files (with filen
On Thu, Jun 4, 2020, at 12:52 PM, Anatoli wrote:
> > chardet is used by the JMAP module of httpd to detect the character
> set of untagged 8-bit headers.
>
> Does that mean that these libs are required? If not, what would happen
> if not included? How Cyrus would detect the charset? Or put in othe
/wslay/pull/47
> >
> >
> > On 6/3/20 1:19 AM, ellie timoney wrote:
> >> Cool, thanks for confirming that. So far it's sounding like 1.1.0 is
> >> probably adequate, but I'll wait a little bit to see if Ken has any input
> >> once he's b
ectively httpd binary includes references to wslay_event_xxx in
> its symbols table.
>
> Regards,
> Anatoli
>
> On 3/6/20 01:35, ellie timoney wrote:
> > In our "cyruslibs" package, the wslay submodule is at this commit:
> >
> > commit 4a937cd (HEAD, ori
In our "cyruslibs" package, the wslay submodule is at this commit:
commit 4a937cd (HEAD, origin/master, origin/HEAD, master)
Author: Tatsuhiro Tsujikawa
AuthorDate: Fri Jun 8 23:19:03 2018 +0900
Commit: Tatsuhiro Tsujikawa
CommitDate: Fri Jun 8 23:19:03 2018 +0900
Bump up version nu
On Fri, Apr 24, 2020, at 2:56 AM, Sébastien Michel wrote:
> Hi,
>
> Le mer. 4 mars 2020 à 14:40, Дилян Палаузов
> a écrit :
> >
> > Hello,
> >
> > is RFC 5465 (IMAP NOTIFY (https://tools.ietf.org/html/rfc5465.html)
> > supported in 3.0 as stated at
> > https://www.cyrusimap.org/imap/rfc-support.
The FTP is known to be down, and we don't expect it to come back. This is all
still hosted by CMU at the moment, even though they've pulled out of the
project.
Our real plan has been to move the cyrusimap.org domain away from the CMU
infrastructure and onto github.io (which doesn't provide FTP
I've yet to fix up the github labels, will get on that after lunch.
Travis CI knows about 3.2 and seems to be building it correctly :)
Cheers,
ellie
On Wed, Jan 15, 2020, at 10:55 AM, ellie timoney wrote:
> Hi,
>
> I plan on branching off a new cyrus-imapd-3.2 branch at the s
–y
>
> Regards,
> David.
>
>
> *From: * Cyrus-devel
>
> on behalf of ellie timoney
> *Date: * Thursday, December 5, 2019 at 4:30 PM
> *To: * "cyrus-devel@lists.andrew.cmu.edu"
> *Subject: * Re: Error building cyrus-imapd-3.1.8
>
On Wed, Jan 15, 2020, at 1:18 PM, Ricardo Signes wrote:
> *QUESTION:* Do we have an established policy for how features are deprecated
> and removed? For example, if we can make a backward incompatible change in
> Cyrus X.Y.0, how long in advance do we need to provide notice, and via what
> mean
Hi,
I plan on branching off a new cyrus-imapd-3.2 branch at the start of February
(probably on the 3rd), so I can start making beta releases in preparation for
an eventual real release in March (hopefully!).
In the meantime, if you have big, risky branches that should not be in the 3.2
release
, 2019, at 2:22 PM, ellie timoney wrote:
> I think the really useful information to collect next time this happens
> (and while the master process is still running) is:
>
> * What does lsof tell us about that ready file descriptor (in the
> example, fd 11)? I would be very inter
Thanks, invite sent! :)
On Tue, Dec 24, 2019, at 2:03 AM, Quanah Gibson-Mount wrote:
>
>
> --On Monday, December 23, 2019 11:36 AM +1100 ellie timoney
> wrote:
>
> > I tracked down Quanah's github account from a recent pull request, and
> > sent throug
I tracked down Quanah's github account from a recent pull request, and sent
through an invitation to the cyrusimap organisation.
Not sure what Howard Chu's email address or github username is? I can invite
him too once I know.
Cheers,
ellie
On Sun, Dec 22, 2019, at 12:52 AM, Ken Murchison wr
The Cyrus team is pleased to announce the immediate availability of a new
version of Cyrus IMAP: 3.1.9
This is a snapshot of the master branch, and should be considered for testing
purposes and bleeding-edge features only. It is available as a git tag, which
can be found here:
https://github.c
Hi David,
That smells like a missing dependency. Have you reviewed
https://www.cyrusimap.org/dev/imap/developer/compiling.html ?
Looking at the error, and glancing at the dependencies list, I wonder if you
need 'perl-devel'. It's listed as a developer-only dependency, but because
you're buildi
The Cyrus team is pleased to announce the immediate availability of a new
version of Cyrus IMAP: 3.1.8
This is a snapshot of the master branch, and should be considered for testing
purposes and bleeding-edge features only. It is available as a git tag, which
can be found here:
https://github.c
o (httpd and notifyd). Then I try to
> connect to that processes (gdb). This does not work, however, since
> the processes are moved to zombie status.
>
> Greetings
> Дилян
>
> On Thu, 2019-11-28 at 10:34 +1100, ellie timoney wrote:
> > Saw something similar just now
0x555ac7124a97 in child_janitor (now=...) at master/master.c:1221
#1 0x555ac712a67a in main (argc=10, argv=0x7ffdc1fe78b8)
at master/master.c:2812
Haven't dug further yet, but it looks similar to your report
On Wed, Nov 27, 2019, at 9:17 AM, ellie timoney wrote:
> Can you st
Can you strace the master process next time it's spinning at 100%? What is it
doing at that time?
On Tue, Nov 26, 2019, at 1:29 AM, Дилян Палаузов wrote:
> Hello,
>
> > I run cyrus imap 3.0.x with some private changes.
> >
> > Sometimes when stop the master process, the master process utilizes
"x RENAME old new" is now fixed such that the renamed mailbox will remain on
its original partition (on both the master and cyrus-imapd-3.0 branches),
instead of accidentally going through the choose-a-partition logic.
You still can't provide an explicit partition unless the mailbox name isn't
On Wed, Nov 6, 2019, at 10:56 AM, Bron Gondwana wrote:
> On Wed, Nov 6, 2019, at 09:24, ellie timoney wrote:
>> On Tue, Nov 5, 2019, at 4:44 PM, Bron Gondwana wrote:
>>> On Tue, Nov 5, 2019, at 12:04, Ricardo Signes wrote:
>>>> So, I think the plan was to cut a stable
On Tue, Nov 5, 2019, at 4:44 PM, Bron Gondwana wrote:
> On Tue, Nov 5, 2019, at 12:04, Ricardo Signes wrote:
>> So, I think the plan was to cut a stable Cyrus 3.2 after we had stable JMAP.
>> Is that time now? We talked about this on the Zoom call today.
>
> I think we're pretty close to it. The
On Wed, Nov 6, 2019, at 8:20 AM, Bron Gondwana wrote:
> * #1765 (Move SNMP out from master into a separate daemon) and related
>> pending PR #2100. Ellie had significant progress on this, don't know
>> what's blocking it, but this issue basically blocks any further work on
>> privilege separation l
On Mon, Jul 29, 2019, at 11:10 PM, Anatoli via Cyrus-devel wrote:
> There are a lot of issues with both 3.0, 3.1 and 3.2 tags (some even have 2.5
> tag), it's not clear which are scheduled to be closed for which release.
>
The tags for existing versions (i.e. 2.4, 2.5, 3.0, 3.1) indicate which
So,
> Robert:
> * Cyrus work:
> - some of the Xapian stuff would be good to test with older index db formats.
> - It would be good to run tests with two different binaries, one to create
> old-style data and the other one to see that things still work!
> - this would be a good general thing, b
I've updated this with the results from the scripted tests (i.e. all the 0/n
numbers, based on the src/tests/* stuff), but from my experimentation so far it
hasn't yet become apparent exactly how to test the checkpoint/recent/etc
columns and/or how to interpret the results, so I've left those co
This ("ImapTest") looks like the thing that we can run from Cassandane as
Cassandane::Cyrus::ImapTest, I haven't had it set up for a while (haven't
gotten around to it on new laptop yet...) but I think last time I looked we
passed a lot of the tests on 3.0, and some of the ones we failed looked
On Tue, Mar 19, 2019, at 8:42 AM, Karl Pielorz wrote:
>
>
> --On 18 March 2019 at 12:34:12 +0100 Sebastian Hagedorn
> wrote:
>
> >> user.kpielorz.Archive.1-OldLogs16 (null)
> >>
> >> [snip]
> >>
> >> Anyone seem similar, or know what can be done with them?
> >
> > I believe those are "to
> Would be fine if Bron, Ellie or someone at Fastmail could tell
> something about it to us :) :)
Cheeky! Thing is, at FM our production servers more or less track the
master branch, so we were running "3.0" from the moment 2.5 forked off,
and so our upgrade process only ever really needs to deal
The Cyrus team is pleased to announce the immediate availability of a
new version of Cyrus IMAP: 3.1.6
This is a snapshot of the master branch, and should be considered for
testing purposes and bleeding-edge features only. It is available as a
git tag, which can be found here:
https://github.com/cy
Hi Karl,
I'm not sure if you're aware, but we've removed support for Berkeley DB from
3.0+. It remains in the 2.5 series mainly for legacy reasons, but no-one's
specifically maintaining support for it (especially not for newer versions like
db5).
Since you've recently upgraded from 2.3 to 2.5
On Tue, Oct 9, 2018, at 10:32 PM, Carlos Velasco wrote:
> Hi,
>
> > Ellie:
> > - Released new Cyrus 2.5 version.
>
> Forgot the announcement mail?
Nope, it went to the announce and info lists, same as it always does:
http://asg.web.cmu.edu/archive/message.php?mailbox=archive.cyrus-announce&msg=2
Hi all,
ANNOTATEMORE support has been added back to the master branch, but it's
now hidden behind an imapd.conf(5) option
"annotate_enable_legacy_commands" (which defaults to off). :)
3. is the same as it always was, ANNOTATEMORE support was not
removed there.
Cheers,
ellie
Hi Philippe,
On Tue, Sep 4, 2018, at 6:49 PM, Philippe wrote:
> Hi Ellie,
>
> thanks a lot for your answer.
>
> On 04.09.2018 04:50, ellie timoney wrote:
> > From your other email, it looks like you're using the experimental
> > backup system?
> No worries, I
Hi Philippe,
>From your other email, it looks like you're using the experimental backup
>system?
Please note that this system is _experimental_ and may change (probably in
non-backward compatible ways) in the future. It's also not really under active
development at the moment. If you don't a
Hi,
I've just attached the real release files from the 3.0.7 release (from 18th of
May) to the GitHub "release" tag for it, as an experiment to see what happens:
https://github.com/cyrusimap/cyrus-imapd/releases
So far I can see that it's now listing it as the "latest release" (correct) "3
min
Hi Michael,
On Fri, Jul 13, 2018, at 6:40 PM, Michael Menge wrote:
> Hi Ellie
>
> thanks for your replies,
>
> Quoting ellie timoney :
>
> > From what I'm seeing here, it looks like mupdate calls
> > tls_init_serverengine() for each new STA
. Even if someone does
produce patches for master, they won't make it back to the 3.0 series.
Sorry to be the bearer of annoying news!
ellie
On Fri, Jul 13, 2018, at 12:57 PM, ellie timoney wrote:
> I'm still digging, but if you amend your log patch to also NULL out
&
h_params) {
+ syslog(LOG_CRIT, "dh_params will be freed %p", dh_params);
+ DH_free(dh_params);
+ dh_params = NULL;
+ syslog(LOG_CRIT, "dh_params were freed %p", dh_params);
+ }
#endif
On Fri, Jul 13, 2018, at 12:47 PM, ellie timoney
> so it seems to me that the dh_params were set once on startup but
> freed for each closed connection
Yikes :o
On Thu, Jul 12, 2018, at 7:09 PM, Michael Menge wrote:
> Hi,
>
> Дилян had suggested to add some debug outputs to imap/tls.c
>
>
>
> diff --git a/imap/tls.c b/imap/tls.c
>
Hi,
Are you confident that the backtrace in your earlier email is from the thread
that crashed?
mupdate is multithreaded, so obtaining the correct backtrace from a crash is a
bit of work (but maybe you already did this)
It's been a while since I've done any multithreaded debugging with gcc (s
Hi,
I don't see mention in that bug report which version of Cyrus they were testing
with, but it sounds like this issue, which was fixed in 2.5.11:
https://github.com/cyrusimap/cyrus-imapd/issues/11
These were the commits from that issue:
https://github.com/cyrusimap/cyrus-imapd/commit/9fd3ef12
Looks like it's back up now
On Tue, Apr 24, 2018, at 8:29 AM, Partha Susarla wrote:
>
> On Tue, Apr 24, 2018, at 7:46 AM, Fritz Elfert wrote:
> > Hi *,
> >
> > Apologies in advance if this is off topic but I gather this is the
> > safest/fastest way to reach whoever is responsible.
> >
> > Anyo
Is this thread covering the same ground as
https://github.com/cyrusimap/cyrus-imapd/pull/2307 ? I don't know DAV
well enough to tell.
On Sun, Apr 8, 2018, at 10:53 AM, Ken Murchison wrote:
> I originally wrote the code to handle public calendars in the "shared"
> namespace, but I focused on user c
Hi all :)
We've decided to remove the experimental JMAP support from the stable Cyrus
IMAPd 3.0.x series. This is a minimally-invasive change, which won't affect
other aspects of the software.
The motivation for this is the rapid evolution of the JMAP specification as it
moves toward formal s
Hi all :)
We've decided to remove the experimental JMAP support from the stable Cyrus
IMAPd 3.0.x series. This is a minimally-invasive change, which won't affect
other aspects of the software.
The motivation for this is the rapid evolution of the JMAP specification as it
moves toward formal s
Present: Ken, Robert S, Ellie, Nicola
Ken:
* still waiting to finish SASL release - need to ping people working on
remaining issues
* worked on a user ticket
* fixed some caldav things
* mostly working on IETF drafts for the working group that Bron is chairing
* reviewing Bron's fixes for the fre
> It's really the default search tier to use, and has no direct
> relationship to the "default" partition.
Yep, or at least, this is my understanding too.
> In other words, this is just another circumstance where seemingly
> obvious partition names (like default-default) get us into
> documentatio
Hi,
Michael's patch is now on all the affected branches, and will be
included in future releases. Thanks very much :)
> From me/us here... we think it must be typo, failure to not allow the
> rename here. But it would be nice to read some words of the developers
> who added this restriction
What's the conf call time for next week, now that Melbourne is in DST?
On Mon, Oct 9, 2017, at 10:20 PM, Partha Susarla wrote:
> Present: Bron, Ken, RobS, Nicola, Partha
>
> Bron:
> * Cyrus Board Meeting [With Ken] - decision yet to be taken on
> foundation
> association. Next meeting on Friday
Hi :)
We've been talking about how we manage Cyrus releases, and the
increasing gulf between the 3.0 series and the master branch --
accompanied by vague second-hand memories of the 2.4->2.5->3.0
transitions...
As of now, we're switching to an odd-even release cycle.
The 3.0.x series will contin
On Tue, Aug 8, 2017, at 06:01 PM, Stephan Lauffer wrote:
> Now I get a Floating point exception (core dumped). Did i miss another
> patch from git/master to get it fixed in 3.0.2?
Now that's curious. Nope, you haven't missed a patch, there was just
the two. I don't remember even seeing any flo
/1d44995a694417bdec738df19b6085cc3b4afb5chttps://github.com/cyrusimap/cyrus-imapd/commit/7e133301d9664305785ccd9c50b62abf9bf9b108
Cheers,
ellie
On Tue, Aug 8, 2017, at 11:18 AM, ellie timoney wrote:
> I've just reproduced this myself, core dump is in
> https://github.com/cyrusimap/cyrus-imapd/issues/2080>
&
I've just reproduced this myself, core dump is in
https://github.com/cyrusimap/cyrus-imapd/issues/2080
Looks like it affects master branch too. Looking into it now...
Cheers,
ellie
On Tue, Aug 8, 2017, at 09:08 AM, Bron Gondwana wrote:
> The strace brings it down to a pretty small block of code
Hi Stephan,
Is this fixed by Ken's patch for the libpcre dependency?
Cheers,
ellie
On Wed, Aug 2, 2017, at 05:29 PM, Stephan Lauffer wrote:
> Dear Nicola,
>
> Zitat von Nicola Nye :
> [...]
> > If this was you, and you want some help upgrading, send through some
> > more information. (There'
Awesome, thanks so much for that :)
Cheers,
ellie
On Tue, May 16, 2017, at 09:41 PM, Thomas Jarosch wrote:
> Hi ellie,
>
> the testsuite run was all good for the upcoming 2.4.19.
>
> It tested folder creation, LMTP, POP3, message create/move/delete
> and the ANNOTATEMORE extension for "Kolab f
wrote:
> Hi Ellie,
>
> On Tuesday, 09 May 2017 03:15:07 CEST ellie timoney wrote:
> > I'm looking at doing a new release of 2.4 soon -- there's been a number
> > of issues coming up lately which are already fixed in git, but aren't in
> > a released
Hi Thomas, Philipp,
On Tue, Oct 4, 2016, at 05:19 PM, Thomas Jarosch wrote:
> we also have a version of this patch for cyrus 2.4 in production now.
> If you're interested, we can upstream it, too.
Sorry for the late reply, but this would be great!
I'm looking at doing a new release of 2.4 soon -
On Wed, May 3, 2017, at 09:56 PM, Carlos Velasco wrote:
> >> My cyrus imap version is 2.5.10 and my SMTP is a postfix 3.1.4
> >>
> >> Apr 25 22:05:29 local6:err imap: imap[13453]: IOERROR: reading message:
> >> unexpected end of file
> >>
> >> Looking into imap logs I see these errors at the end.
Minutes!
Ken:
* working on more sieve stuff, another major rewrite. no longer leaking
memory, even in case of failures, cool!
* duplicate extension working
* 80% done with ihave extension (run time checking of extensions)
* jmap working group went well
Robert:
* message records rewrite: using new
Hi,
The website build script for cyrusimap.org is now managed in git. This
is in preparation for making the 3.0 docs available separately from the
2.5 and master docs.
The /root/docs directory on the web server is now a git repository, with
remotes set thus:
originhttps://github.com/cyrus
Hi,
I've created the cyrus-imapd-3.0 branch. Fixes and stuff that need to
be in 3.0.x releases should be applied or backported to here.
The master branch is now what will eventually become the 3.1 series.
Issues affecting this branch specifically should be labelled "3.1" on
github.
(There's st
I've added a set of self-tests to make sure Cassandane is able to
generate core files, and that they don't get truncated too small.
There's a new binary, utils/crash, that needs to be compiled. Running
make after your next pull will do the right thing. :)
I'm speculating a bit here, so take this with a grain of salt...
My understanding of private annotations is that that apply (/ are
visible) only to the user that added them (regardless of who else has
access to the mailbox), whereas shared annotations apply (/ are visible)
to everyone who has appr
Another data point: on my development/testing setup, the cyrus user's
shell is /bin/false. I'm not sure what the practical difference is, if
any, between this and nologin. I get no issues with this for
conventional use.
But for post-hoc debugging/examining state/etc, I often want a working
shell
Is that going to conflict with this?
https://github.com/cyrusimap/cyrus-imapd/issues/1778
On Tue, Feb 7, 2017, at 09:34 AM, Ken Murchison via Cyrus-devel wrote:
> All,
>
> I'm in the process of rewriting the Sieve parser and adding new
> extensions for what will become part of Cyrus v3.1. We cu
Hi Thomas,
Your understanding of the imap / sync relationship is backwards: it's
not that sync_server now understands imap-style commands with tags, but
rather that imapd can now act as a sync destination.
Specifically, imapd now supports SYNCAPPLY, SYNCGET and SYNCRESTART
commands, which corr
I'm 100% in favour of discarding the "exec perl" hack -- solely because
it confuses syntax highlighting something fierce :P
But I have no particular familiarity with its historical context,
so can't reliably evaluate whether it's still needed for some
obscure reason
On Fri, Jan 13, 2017, at 06:
Looks good, thanks :)
On Wed, Dec 14, 2016, at 11:23 PM, Stephan Lauffer via Cyrus-devel
wrote:
> Hi all!
>
> We are testing 2.5.10 and have segfaults with notifyd.
>
> I give it a try with my 1st guthub issue... hopefully I did it rigth: (:
>
>https://github.com/cyrusimap/cyrus-imapd/issue
Interestingly, it looks like both master and cyrus-imapd-2.5 branches
already have some sort of checking for availability of librt (look for
"LIB_RT" in configure.ac and Makefile.am) -- they're allegedly trying to
bring it in because skiplist needs fdatasync (which I guess depends or
depended upon
Hi Giles,
It sounds like we'll need to add some detection to configure.ac for
working out when to link against librt.
Do you get the same problem with the master branch? It also has the
idle timeout patch, so I'd expect the same problem -- unless master is
already linking properly with librt, in
1.1.0 support has notionally been there for months (included in 2.5.9):
https://github.com/cyrusimap/cyrus-imapd/issues/3
That said, afaik it was last tested with 1.1.0-pre5, and I don't know
what's changed in OpenSSL since then. Or maybe that file was missed
during testing somehow.
Thanks for t
I think some of the confusion comes from the fact that the setting name
-- "archive max size" -- very strongly implies (incorrectly) something
like "the largest size of message that will be archived" / "messages
larger than this will not be archived at all". It takes a fair bit of
attentive readin
This version of the patch is now on master. Thanks very much for
putting it together :)
I've opened https://github.com/cyrusimap/cyrus-imapd/issues/42 for
backporting it to 2.5 -- expecting to do it soon, but making sure it
doesn't get forgotten if I get distracted!
Cheers,
ellie
On Thu, Sep 2
blem, but I wouldn't know what to look for anyway. I am not going to
> give up capturing the packets though. At the very least I can probably
> learn more about IMAP and that is a good thing.
>
> Andy
>
> On 09/27/2016 01:07 AM, ellie timoney via Cyrus-devel wrote:
> >
On Thu, Sep 22, 2016, at 05:55 AM, Carson Gaspar via Cyrus-devel wrote:
> > If the client's connection has dropped out, no data will ever appear on
> > the socket, so select will never flag it as readable, so we will never
> > try to read from it, so we will never receive the read error even though
On Thu, Sep 22, 2016, at 01:29 AM, Philipp Gesang wrote:
> Minutes again, because IMO a fallback between different units of
> measure would be confusing.
Yeah, I was thinking the same thing. :) The updated patch looks good to
me.
So it looks like what we're getting from this is two things:
* ma
Hi Richard,
Thanks for bumping this, looks like it got forgotten about. I've put
this into the github issues tracker as
https://github.com/cyrusimap/cyrus-imapd/issues/27 so at least it won't
get forgotten again.
It looks from your patch like "internaldate" and "sentdate" are the
specific fields
On Tue, Sep 20, 2016, at 06:24 PM, Philipp Gesang wrote:
> Another reason is to preserve the old behavior by default. It
> might hit other users if the effect of the “timeout” is extended
> that way.
>
> What about the middle ground? Cyrus could default to the
> “timeout” value unless “idletimeout
On Tue, Sep 20, 2016, at 08:37 PM, Robert Mueller via Cyrus-devel wrote:
>
> > The thing is, during IDLE, we're not blocked on a read, we're blocked on
> > a select (in idle_wait()). We don't even try to read from the client
> > until the select tells us it's readable. If the client has dropped o
On Tue, Sep 20, 2016, at 01:30 PM, Robert Mueller via Cyrus-devel wrote:
> Is there a reason to have a separate idle timeout separate to the
> standard inactivity timeout?
>
> timeout: 32
> The length of the IMAP server's inactivity autologout
> timer, in minu
-- but I guess if
there's a crack there, the imapidletimeout patch will fill that too.
Any thoughts?
Cheers,
ellie
On Wed, Sep 14, 2016, at 05:11 PM, Thomas Jarosch wrote:
> Hi Ellie,
>
> On Monday, 12. September 2016 11:35:45 ellie timoney wrote:
> [clock jumps]
> > Or
On Fri, Sep 16, 2016, at 07:54 PM, Carlos Velasco wrote:
> >> I think idled ought to become_cyrus itself. It shouldn't continue
> >> running as root even if it was started as root.
> >
> > The attached patch seems to resolve this for me. Karl, does it help in
> > your case?
> >
> > It's against th
On Fri, Sep 16, 2016, at 10:59 AM, ellie timoney via Cyrus-devel wrote:
> I think idled ought to become_cyrus itself. It shouldn't continue
> running as root even if it was started as root.
The attached patch seems to resolve this for me. Karl, does it help in
your case?
It&#x
On Thu, Sep 15, 2016, at 12:09 AM, Carlos Velasco via Cyrus-devel wrote:
> > We're in the process of moving from Cyrus 2.4.17 to 2.5.7.
> >
> > So far this is going OK - but I've noticed when I stop the 2.5.7 server
> > (this is on FreeBSD so 'service imapd stop') - it leaves behind idled?
> >
> >
of "29 minutes" applies to
clients wishing to avoid being timed out by breaking/resuming idle
early, from which I take the implication that a reasonable server might
time out connections after 30 mins. But, Outlook...
Cheers,
ellie
On Thu, Sep 8, 2016, at 11:26 PM, Thomas Jarosch wrot
eers,
ellie
On Thu, Sep 8, 2016, at 07:37 PM, Philipp Gesang wrote:
> Hi,
>
> thanks for the review. There’s a v3 of the patch now in which I
> address your points.
>
> -<| Quoting ellie timoney , on Thursday, 2016-09-08
> 11:07:54 AM |>-
> > > +if (c
> +if (clock_gettime(CLOCK_MONOTONIC_COARSE, &now) == -1) {
> +syslog(LOG_ERR, "clock_gettime (%d %s): error reading clock",
> + errno, strerror(errno));
> +return false;
> +}
I'm curious about the choice of struct timespec/clock_gettime() vs
time_t/time() --
On Wed, Sep 7, 2016, at 05:00 PM, Philipp Gesang wrote:
> -<| Quoting Philipp Gesang , on Wednesday,
> 2016-09-07 08:58:15 |>-
> > -<| Quoting ellie timoney , on Wednesday, 2016-09-07
> > 11:00:17 |>-
> > > Hi Philipp,
> > >
> > > On Wed,
Hi Philipp,
On Wed, Sep 7, 2016, at 12:06 AM, Philipp Gesang via Cyrus-devel wrote:
> [...]
> --
> 2.4.11
>
Is the above indicating that the patch is against Cyrus 2.4.11? Or is
that just an unrelated signature?
If the patch is not against 2.4.11, which version is it against?
Cheers,
ellie
think the answer is "yes, we'd like to always return it, and
> correctly".
>
> LSUB is special, because it's whether there are SUBSCRIBED children,
> rather than mailbox children.
>
> Bron.
>
> On Tue, 6 Sep 2016, at 12:46, ellie timoney wro
Our handling of the \HasChildren and \HasNoChildren flags in list
responses is currently inconsistent -- though not strictly in violation
of RFC (with the exception of a known bug in 2.5).
[We pass our Cassandane List tests because they have these
inconsistencies baked into their expected result
I've just pushed up a new feature in Cassandane for marking tests as
only applying to particular version ranges. So if you're writing tests
for a new Cyrus feature, you can mark them appropriately, and Cassandane
can still run cleanly when testing versions prior to that feature's
introduction.
Th
Hi Sebastian,
I think the attached patch should restore compatibility with autoconf
version 2.63 -- are you able to confirm?
Cheers,
ellie
On Mon, Aug 8, 2016, at 10:07 AM, ellie timoney via Cyrus-devel wrote:
> Yep, it's due to the use of the 'm4_esyscmd_s' macro. I
Yep, it's due to the use of the 'm4_esyscmd_s' macro. I've seen a few
other projects achieve 2.63 compatibility just by detecting whether this
macro is available, and providing their own replacement if not. I plan
to do something like this too, hopefully before next release, but
haven't yet looke
1 - 100 of 213 matches
Mail list logo
