Re: Minutes of meeting from 2015-04-08

Oh dang, I forgot about DST changing here. Just popping in now and finding the minutes from the meeting I missed by an hour :( I've been adding to Cassandane tests for a bit more confidence in putting together a 2.5.1 release, and have possibly found a bug (one of the new tests fails against the

Re: Minutes April 13th

We plan to switch to compiling with --std=c99 and targetting all new code work to c99 best practices. First we need to make sure existing code compiles with c99. I came in on the tail end of this part of the conversation. Yesterday afternoon I spent about half an hour doing a first pass

howto: set up a cyrus development environment

Hi, These instructions are mostly for Conrad, but they might be useful to the greater list. We should also clean these up and format them on the wiki. They are based on debian 8.0, cause that's what I was setting up as I wrote it. Other Linux distros will probably be similar in the broad ideas

Re: howto: set up a cyrus development environment

However, when running the tests with ./testrunner.pl -f pretty -j 8, I get 1 failure and 182 errors in 252 tests. That seems odd. I see no specific error messages in syslog or elsewhere, so I'm thinking I must be missing something. Have any of you experienced this ? Is that against the cyrus

Re: howto: set up a cyrus development environment

Will raise a maniphest task for the bug, but in the meantime you can get Raised and resolved :) On Mon, May 4, 2015, at 03:42 PM, ellie timoney wrote: Another missing dependency, this time a cyrus one: sudo apt-get install uuid-dev and then rebuild cyrus from scratch. The problem

Re: howto: set up a cyrus development environment

of Master.sighup_recycling) ellie On Mon, May 4, 2015, at 01:15 PM, ellie timoney wrote: This one: 4 Perl exception: child process (binary /home/ellie/build/cassandane/utils/annotator.pl pid [pid]) exited with code 255 ... is a head scratcher. I'm digging deeper into it at the moment

Re: howto: set up a cyrus development environment

conr...@conradk.com +33 6 23 82 42 79 On Sat, May 2, 2015, at 10:17 AM, ellie timoney wrote: However, when running the tests with ./testrunner.pl -f pretty -j 8, I get 1 failure and 182 errors in 252 tests. That seems odd. I see no specific error messages in syslog or elsewhere, so

Release notes

Hi, So, Cyrus 2.5 releases have been taking me way too long. 2.5.1 was mostly delayed by learning the process and gaining access to things (unsurprising for my first release). 2.5.2 is being held up by writing release notes -- and chasing up user-level descriptions of what our changes are

Re: Minutes 11 May

This looks very similar to the same problem I was having (though mine was a new account being forced into its initial password change -- but the same error on trying to submit the password change), so it's interesting to hear that it's not just me. I had some discussion with Dave (dave64 on irc)

Re: Cyrus Documentation tools

My experience as a user of projects documented with Doxygen is that their documentation is usually incredibly rich and generally unhelpful. I don't know whether it's a failure of the documentation writer or one of the documentation software (or some combination thereof, or etc), but in my

Re: #documentation_reviewers

What happens if you go to https://git.cyrus.foundation/project/profile/10/ and click Join Project from the menu on the right? On Fri, May 15, 2015, at 11:42 AM, Chris Davies wrote: Does anyone know how I join #documentation_reviewers on phabricator? I tried to give myself permission but got:

Re: Fwd: [PATCH] make autocreate_quota:0 work as documented

Hi Donald, I'm currently maintaining the 2.5 series.  Your patch looks okay at a glance, it just had the misfortune of being sent through the day after I'd gone on leave for a few weeks. But I'm back now, and hope to look this over more closely and get it merged sometime this week.  Thanks for

Re: Fwd: [PATCH] make autocreate_quota:0 work as documented

Hi Donald, I've made a few cleanups and merged your patch.  It will be included in the next release. Thanks! Ellie On Mon, Jun 22, 2015, at 02:40 PM, ellie timoney wrote: Hi Donald, I'm currently maintaining the 2.5 series.  Your patch looks okay at a glance, it just had the misfortune

Re: Can't locate loadable Perl module when running cyradm

haven't had to change any permissions on /var/run/saslauthd On Fri, May 22, 2015, at 10:05 AM, ellie timoney wrote: Sorry for late response, I've been away from the office and therefore away from my dev machine. I installed saslpasswd2 with: sudo apt-get install sasl2-bin Yep I

Re: SEGFAULT in reconstruct (2.5.5)

Hi Marty, When using ‘reconstruct’ to upgrade the database formats from 2.4.17-caldav-b10 - 2.5.5, ‘reconstruct' core dumps (Solaris 10, Sun Studio C Compiler). Looking at the code, it seems that if there is an error with ‘mailbox_reconstruct’ and the error isn’t IMAP_IOERROR, a ‘NULL’ is

Re: SEGFAULT in reconstruct (2.5.5)

Hi Marty, ‘dav_reconstruct’ command in the ‘doc/install-upgrade.html’ file…. Would probably be a good idea to also mention this on the https://docs.cyrus.foundation/imap/release-notes/2.5/x/2.5.0.html page, since that mentions database upgrades, but doesn’t mention anything in the

Re: Compiling Cyrus with Sun Studio on Solaris

Hi Marty, I’m finally getting around to building the newer versions of Cyrus for our Solaris platform, and the Sun Studio compiler is complaining about lib/imapopts.c lib/imapopts.c is generated by tools/config2header, so syntactic changes will need to be handled there. The 3.0.0 b1 compile

Re: autoreconf: 'configure.ac' or 'configure.in' is required

On Mon, Aug 3, 2015, at 05:16 PM, Chris Davies wrote: Running through this[1] guide on a clean machine, i'm getting: *autoreconf: 'configure.ac' or 'configure.in' is required* whenever I run autoreconf -vi, step 3 of the Install and configure Cassandane section. Has something been removed or

Re: Today's pop quiz: replication

Another quick reply, in case it wasn't clear from my last, that it sounds like your understanding of the purpose of sync_client and sync_server are neatly reversed: Do we have multiple sync_clients because a new one is spawned by a master for each change (and then the process finishes), or is

Re: Recent security fixes

On Thu, Oct 22, 2015, at 07:22 AM, Florian Weimer wrote: > On 10/19/2015 06:38 AM, ellie timoney wrote: > > > On Mon, Oct 5, 2015, at 08:09 PM, Florian Weimer wrote: > >> Hi, > >> > >> Martin Prpic pointed out that you apparently fixed a security issue: &

Re: Recent security fixes

Hi Florian, Sorry about the late reply. Comments inline. On Mon, Oct 5, 2015, at 08:09 PM, Florian Weimer wrote: > Hi, > > Martin Prpic pointed out that you apparently fixed a security issue: > > > > This is great, thanks. I think this

Re: autocreate.sieve doesn't work correct. temporary files

for sending through these reports! :) Cheers, ellie On Fri, Oct 9, 2015, at 08:41 AM, ellie timoney wrote: >> First I guest we need NOT here (?) > > Doh! > >> And second creating are failing with follow logs (yes I use 'root' >> user for testing) >> >>

Re: autocreate.sieve doesn't work correct. temporary files

error Oct  7 > 16:54:10 imapsync cyrus/imap[4062]: autocreate_sieve: User root, > default sieve script creation failed No one files/folders are > creating. > > On Tue, Oct 6, 2015 at 3:51 AM, ellie timoney > <el...@fastmail.com> wrote: >> __ >> Hi Artyom, >>

Re: segfault in ctl_mboxlist -d with 2.5.4

Hi Chris, Thanks for reporting this. I've raised it as https://git.cyrus.foundation/T207 and will look at it today. Cheers, ellie On Thu, Jul 9, 2015, at 01:06 AM, Chris Stromsoe wrote: I'm seeing a segfault running ctl_mboxlist -d with 2.5.4. mailboxes.db format is twoskip. All

Re: Slow unit tests

I've noticed a bit of a creep in the cunit tests - they've gone from taking a few seconds to taking significantly longer. The big climb recently was for verifying timeout behaviour in lib/lock_flock.c (new module). It's on master rather than my own branch to get eyeballs on it, but at this

updating README

Found myself reading the README -- whoops, it's very stale. Jeroen's noticed this too, there's a task in phabricator that's just sat there since its creation.  I've just triaged it to High: https://git.cyrus.foundation/T8 Jeroen writes: The current README in rI reads about 2.4, and versions

Re: Another non-standard search/sort field :)

Hi Vladislav, Thanks for the patch. I'll try to get it merged this week. ellie On Sat, Sep 12, 2015, at 10:06 AM, Bron Gondwana wrote: > On Fri, Sep 11, 2015, at 23:19, Vladislav Bogdanov wrote: > > 11.09.2015 14:49, Bron Gondwana wrote: > > > On Fri, Sep 11, 2015, at 20:00, Vladislav Bogdanov

Re: Another non-standard search/sort field :)

integer?) > > Bron. > > On Tue, Sep 15, 2015, at 11:32, ellie timoney wrote: > > This patch contains code from libspamc.c (SpamAssassin?) > > > > > +/* Stolen from libspamc.c, and I'm not sure about license compatibility > > > */ > &

Re: Patch RFC: Broken compilation with Sun CC, missing include statement

This is now in git on the cyrus-imapd-2.5 and master branches. :) On Fri, Sep 18, 2015, at 10:31 AM, ellie timoney wrote: > Hi Jens, > > > After several hours of debugging, we traced it back to a missing include > > statement in times.c (strings.h missing). This resu

Re: Patch RFC: Fix broken builds with Sun CC

Hi Jens, This is not as simple as just removing the casts from lib/imapopts.c -- it's a generated file. Note the comments at the top: > /* auto-generated by config2header 1.17 */ > > /* DO NOT EDIT */ > > /* THIS FILE AUTOMATICALLY GENERATED BY config2header 1.17 */ config2header lives in

Re: Patch RFC: Broken compilation with Sun CC, missing include statement

Hi Jens, > After several hours of debugging, we traced it back to a missing include > statement in times.c (strings.h missing). This resulted in the Sun CC strings.h (plural), or string.h (singular)? Your email says strings.h but your patch adds string.h. On Linux (which most of us use),

Re: [2.4 pull request] idle / idled fixes backport to 2.4

Hi Thomas, These are now on the cyrus-imapd-2.4 git branch. Thanks for back porting them :) ellie On Fri, Sep 25, 2015, at 10:23 PM, Thomas Jarosch wrote: > The following changes since commit > e302cae2f208741c98fa73e6663963c9343ed744: > > mailbox: fix lock management over rename

Re: [PATCH master] idled: Add missing signals_poll() call

On Tue, Sep 29, 2015, at 06:34 PM, Thomas Jarosch wrote: > On Tuesday, 29. September 2015 08:35:34 ellie timoney wrote: > > On Mon, Sep 28, 2015, at 11:28 PM, Thomas Jarosch wrote: > > > On Monday, 28. September 2015 11:56:51 ellie timoney wrote: > > > > Hi Thomas

Re: [PATCH master] idled: Add missing signals_poll() call

On Mon, Sep 28, 2015, at 11:28 PM, Thomas Jarosch wrote: > On Monday, 28. September 2015 11:56:51 ellie timoney wrote: > > Hi Thomas, > > > > This is now on master. Thanks for the patch! :) > > > > ellie > > thanks Ellie. Will the 2.5 backport I sen

Re: 2.4.17 --> 2.5.3

Hi Patrick, > Second, where is this coming from? > >Sep 19 05:44:54 toad cyrus/master[22860]: setrlimit: Unable to set > file descriptors limit to -1: Operation not permitted This one is interesting. Resource limits have a "current" and a "maximum" value. Processes with suitable

Re: 2.4.17 --> 2.5.3

o longer log an error about it at every startup. I'm cherry picking this fix onto the 2.5 branch, so it will be in 2.5.7, whenever that comes about (no ETA yet). On Mon, Sep 21, 2015, at 11:27 AM, ellie timoney wrote: > Hi Patrick, > > > Second, where is this coming from? > > &

Re: Debian patches that really belong to upstream

Hi Ondřej, Thanks for sending these upstream. A bunch of these I can just apply, and will do so today. I'll email again when they're on master. Once they're on master I'll revisit them for inclusion on 2.5 and maybe 2.4. A few them warrant further discussion, which follows. Cheers, ellie >

another cassandane heads up - run 'make' again

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. :)

Re: Query re. 'private' vs. 'shared' annotations...

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

cyrusimap.org: website build script is now in git

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: origin

cyrus-imapd-3.0 branch created

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

Re: Cyrus Meeting April 3

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

Re: imapd(?) of 3.0.2 not working here [was: Re: Had problems upgrading to 3.0?]

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 > >

Cyrus release process - switching to odd-even release cycle

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

Re: 3.0.2: segfault in cyrdump

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

Re: 3.0.2: segfault in cyrdump

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

Re: 3.0.2: segfault in cyrdump

/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> >

Re: [PATCH v4] imapd.c: imapoptions: implement idle timeout

n 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 version. It might save some support effort if th

Re: testsuite run for 2.4.19 [WAS: [PATCH v4] imapd.c: imapoptions: implement idle timeout]

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

Re: imap[xxx]: IOERROR: reading message: unexpected end of file

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.

Re: [PATCH v4] imapd.c: imapoptions: implement idle timeout

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

Re: Cyrus Meeting Notes [9th October]

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

Cyrus meeting minutes for 2018-01-15

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

Re: Xapian partition definition when using archiving?

> 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 >

please let me know if you see "release" weirdness on cyrus-imapd github

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

Re: use valgrind / Re: SIGSEGV in cyrus-imapd 3.0.7 mupdate

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 STARTTLS

Re: backup replication: sync_try_imap

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 have

Re: SIGSEGV in cyrus-imapd 3.0.7 mupdate

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

Re: use valgrind / Re: SIGSEGV in cyrus-imapd 3.0.7 mupdate

ams) { + 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 wrote

Re: use valgrind / Re: SIGSEGV in cyrus-imapd 3.0.7 mupdate

> 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

Re: use valgrind / Re: SIGSEGV in cyrus-imapd 3.0.7 mupdate

n'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 > dh_params after it frees it, that would at least preve

Notice: removal of JMAP support from stable Cyrus IMAPd 3.0.x series

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

Notice: removal of JMAP support from stable Cyrus IMAPd 3.0.x series

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

Re: shared xDAV resources

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

Re: www.cyrusimap.org down?!

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. > > > >

Re: Extended LIST RETURN (CHILDREN SUBSCRIBED)

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:

Re: db5 / PANIC errors under 2.5.12?

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

Re: backup replication: sync_try_imap

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

Cyrus IMAPd version 3.1.6

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:

Re: Fixing stale entries in 'mailboxes.db'...

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

Re: https://imapwiki.org/ImapTest/ServerStatus update for Cyrus Imap 3.0

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

Re: https://imapwiki.org/ImapTest/ServerStatus update for Cyrus Imap 3.0

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

Re: Notes 29 July

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

Re: time for cyrus-imap v3.2?

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

Re: time for cyrus-imap v3.2?

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

Re: Error building cyrus-imapd-3.1.8

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

Re: The master janitor goes crazy / Re: Debugging Deadlocks

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

Re: The master janitor goes crazy / Re: Debugging Deadlocks

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 str

Re: yearly release cycle

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

Cyrus IMAPd version 3.1.9

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:

Cyrus IMAPd version 3.1.8

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:

Re: The master janitor goes crazy / Re: Debugging Deadlocks

rocesses (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 when I killed a cassandane run off > > prematurely.

Re: Status of ftp server?

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

Re: Error building cyrus-imapd-3.1.8

egards, > 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 > > Hi Davi

Re: feature freeze on master until Feb 3

;. 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 start of &

feature freeze on master until Feb 3

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

Re: guide to migrating to virtdomains: userid

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 >

Re: yearly release cycle

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 through an

Re: The master janitor goes crazy / Re: Debugging Deadlocks

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 interested to know i

Re: IMAP NOTIFY (RFC 5465) ?

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 > >

Re: meeting minutes, 2020-08-31

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

Re: standardizing logging

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

Cyrus IMAPd version 3.3.0

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:

Re: new features with no documentation

s for the explanation. What happens is that at least Cal/CardDAV > >> compile and work well without libchardet (at least under normal > >> circumstances) and, as it was not marked as required, I thought it's an > >> optional lib and here is the question of why to use it. > >> >

Re: configure: wslay v1.1.1 required but the latest one is 1.1.0

l/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 been online > >>

Re: new features with no documentation

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

Re: run-time dependencies

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

Re: configure: wslay v1.1.1 required but the latest one is 1.1.0

pd 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, origin/master, ori

objectstore: don't build unless asked for

At present, our master branch unconditionally builds in the object storage functionality (using the objectstore_dummy implementation). There's a few ways this isn't great: * it has an undocumented dependency on lib/sqldb, but doesn't try to link it in, so the build fails unless you

Re: My cassandane tests break. Yours too?

Works nicely for me now, cheers! On Sat, Dec 5, 2015, at 10:02 PM, Bron Gondwana via Cyrus-devel wrote: > On Sat, Dec 5, 2015, at 21:30, Bron Gondwana via Cyrus-devel wrote: > > So it smells like the notifyd isn't dying correctly when it finishes > > running, and is instead continuing to run the

  1   2   >