Hi Stephan,
If you're compiling PCRE from sources, the segfaults are a known issue.
You would need the debian patch: apt-get source libpcre3-dev && cat
pcre3-8.38/debian/patches/pcreposix.patch.
Regards,
Anatoli
*From:* Stephan Lauffer
*Sent:* Friday, August 04, 2017 04:27
*To:* Cyr
her things) to run Sieve rules on already received emails
(lack of this feature IMO is the only disadvantage of Sieve vs
client-side rules). Do you have any status for this work? Any plans on
implementing that particular RFC?
Regards,
Anatoli
*From:* Bron Gondwana
*Sent:* Monday, May 29, 2017 15
Bron, Ken,
I've just created a new issue for this:
https://github.com/cyrusimap/cyrus-imapd/issues/2373, so it's not lost
in the mails archive.
Please let us know if the community can sponsor the development.
Thanks,
Anatoli
*From:* Anatoli
*Sent:* Monday, April 09, 2018 00:40
*To:* Cyrus
radio buttons for access type (read|write)), so
its owner could share his/her calendars/contacts directly from the
existing GUI.
Please let me know if I can provide additional details.
Thanks,
Anatoli
*From:* Ken Murchison
*Sent:* Friday, May 25, 2018 10:29
*To:* Cyrus Devel
ues.
Remote addressbooks are not supported in Thunderbird, so I use
/CardBook/ add-on and it works well with shared addressbooks, no issues
detected. /Evolution/ supports CardDAV natively and also works well with
shared addressbooks.
Regards,
Anatoli
*From:* Ken Murchison
*Sent:* Saturday, Apri
f the app (the URL
finally resets to the user principals folder
(/dav/principals/user/t...@domain.com/) as iOS is pointed to it by Cyrus).
In the attached file goes the telemetry for the rest of the communication.
Thanks,
Anatoli
-- t...@domain.com Sun Mar 25 06:05:36 2018
<152196
Hi All!
Robert, is your work on read-only cyrusdb locks somehow related to the
global lock feature (https://github.com/cyrusimap/cyrus-imapd/issues/1763)?
Regards,
Anatoli
*From:* Robert Stepanek
*Sent:* Monday, November 26, 2018 18:40
*To:* Cyrus Devel
*Subject:* Notes - Nov 26 2018
Got it, thanks for the explanation!
*From:* Robert Stepanek
*Sent:* Tuesday, November 27, 2018 10:05
*To:* Cyrus Devel
*Subject:* Re: Notes - Nov 26 2018
Hi Anatoli,
no, what I am working is rather the opposite: the current implementation
uses exclusive locks on mailboxes where it could do
://tools.ietf.org/html/rfc7231#section-6.5.4
On 2/12/19 07:13, Johan Hattne wrote:
> Hi Anatoli;
>
> Thanks for your reply; I’ll be focusing on the MKCOL for now:
>
> I don’t know about permission to overwrite quite yet, but from looking at the
> source it seems the break (
major
release. Also, some flexible dates could be defined, e.g. to publish a
major release every 6-12 months.
Regards,
Anatoli
On 13/12/19 11:59, Ricardo Signes wrote:
> Hey, remember last month when I asked about releasing Cyrus v3.2
> <https://lists.andrew.cmu.edu/pipermail/cyrus-devel/
the request. At the same time, the freebusy URL
returns the scheduling info correctly for any user on the system.
What could be wrong now?
Thanks,
Anatoli
On 15/4/20 09:31, Ken Murchison wrote:
>
> On 4/14/20 10:22 PM, Anatoli wrote:
>> Hi All,
>>
>> I'm experimenti
le" (below goes an example exchange).
Is this rfc supported? If yes, why may it not work as expected? I'm
testing it now with v3.0.5 as this is what I have at one deployment. I
can update it if there were relevant changes in later versions.
Thanks,
Anatoli
[1]
https://www.cyrusimap.org/dev/imap/d
he path of the mailbox differs
from the path of the lookup? It looks like the XXX comment implies
exactly this.
And then I'm not sure iSchedule also requires special permissions for
the lookup, like freebusy URL service.
Could you please give your feedback on all this?
Regards,
Anatoli
On 15/4/
Дилян,
Is there any IMAP NOTIFY capable client? Have you investigated it further?
And AFAIK notifyd is for another purpose (incomplete in the opensource
version, but used for things like push notifications which are under
NDAs from Apple).
Regards,
Anatoli
On 4/3/20 10:39, Дилян Палаузов wrote
for those who need freebusy scheduling support? The change
itself is rather small.
Regards,
Anatoli
On 21/4/20 07:20, Anatoli wrote:
> Ken,
>
> I was checking imap/http_caldav_sched.c. There are these lines:
>
> 921 /* XXX - BROKEN WITH DOMAIN SPLI
->avail_out) {
159 buf_ensure(>zbuf, 256 * 1024);
160 }
If I understand it correctly, deflatePending in this case is only used
to get the needed buffer size and we could replace it with a hardcoded
buffer size (like in my example of 256K).
Thanks,
Anatoli
ed in any way at this moment and there are no plans to make it work,
so to remove the confusion and simplify the code.
Regards,
Anatoli
[1]: https://github.com/cyrusimap/cyrus-imapd/pull/3095
[2]: https://github.com/cyrusimap/cyrus-imapd/issues/1765
On 19/6/20 02:09, Anatoli wrote:
> Ellie,
>
> Than
Hi Ken,
Is there anything preventing the merge of your change in the PR?
I thought it would be included in 3.2.2.
Regards,
Anatoli
On 3/6/20 17:47, Ken Murchison wrote:
> This is my latest proposed fix:
> https://github.com/cyrusimap/cyrus-imapd/pull/3061
>
>
> On 6/2/20 7
FYI, the wslay developer just released the 1.1.1 version with the commit
in question so the dependency is ok now.
More details here: https://github.com/cyrusimap/cyrus-imapd/issues/3070
On 5/6/20 05:11, Anatoli wrote:
> Ellie,
>
> You're right, I haven't checked well the dates!
&g
page and
reformat a bit the tables. If you consider it appropriate, I could
prepare a patch too.
Regards,
Anatoli
On 5/6/20 05:45, Anatoli wrote:
>> Thanks for the explanation. What happens is that at least Cal/CardDAV
>> compile and work well without libchardet (at least under normal
Ellie,
Thanks for the explanation!
I'll try to prepare a PR for the compiling page these days.
Regards,
Anatoli
On 19/6/20 00:29, ellie timoney wrote:
> I think transfig is the package that provides fig2dev? I think that's an
> artifact from the old days, and is only used for gene
Thanks,
Anatoli
Cyrus developers,
What is the purpose/benefit of zeroskip?
What is the purpose of chardet and cld2 in cyrus-imapd?
Should any be considered in production environments running 3.2 branch?
Thanks,
Anatoli
executables invoked
by some component of cyrus-imapd, then I guess all of them would be
required during runtime.
If some of them are only used for building the executables or linked as
static libs, then they should not be needed during runtime, I guess, but
I'm not sure if there are any.
Thanks,
Anatoli
the opportunity and as 3.2 got its own branch, any
chance to close issues/1765 (remove SNMP) [2] by merging pull/2100 [3]?
This would open the road to work on chroot & other security
improvements.
And it would be nice to finally decide/proceed on issues/1731 [4], what
Дилян has mentioned (PCRE).
R
Ellie,
You're right, I haven't checked well the dates!
I just asked the author of Wslay if he could tag a new release. Hope we get an
answer soon.
Regards,
Anatoli
On 4/6/20 21:10, ellie timoney wrote:
> The commit was authored in 2015, but the pull request was only merged to
> wslay
s see it and take appropriate
action. I suppose there are not that many installations with 3.2 yet so
if the warning is included with 3.2.2 it would be an appropriate time.
Regards,
Anatoli
On 4/6/20 21:58, ellie timoney wrote:
> On Thu, Jun 4, 2020, at 12:52 PM, Anatoli wrote:
>>> ch
er functionality like CalDAV
itself, then definitely it would be included. But at this moment the
Compiling page doesn't provide these details and here we are.
On 5/6/20 05:30, Anatoli wrote:
> Ellie,
>
>> libchardet is already listed on the compiling page as being used by
>> the
red (and if they are not used yet, maybe
they shouldn't be mentioned there at all?). This could help porters and
maintainers to make more educated decisions on how to package Cyrus.
Thanks,
Anatoli
[1] https://www.cyrusimap.org/imap/developer/compiling.html
On 3/6/20 19:01, Ken Murchison wrote:
>
hecks for !zstrm->avail_out as it's
possible that there would be not enough buffer for deflate() to complete
in one call.
Regards,
Anatoli
[1] https://www.zlib.net/manual.html
On 2/6/20 17:36, Ken Murchison wrote:
> Hi Anatoli,
>
> Thanks for the report. I'm not sure tha
a mention of a 1.1.1-DEV version. Not sure if
cyrus-imapd httpd requires something from it or if it was just a typo and 1.1.0
is ok.
For the later case below is a patch.
Regards,
Anatoli
diff --git a/configure.ac b/configure.ac
index dc0e0fff2..30e925c60 100644
--- a/configure.ac
+++ b
like the v3.0 has implemented a number of interesting
features, it would be great to see the release soon! : )
Regards,
Anatoli
From: Cyrus-devel
[mailto:cyrus-devel-bounces+me=anatoli...@lists.andrew.cmu.edu] On Behalf Of
ellie timoney via Cyrus-devel
Sent: Friday, April 08, 2016 02:44
Hi Bron,
It would be great! Also it'll help a lot to have a roadmap with ETAs for
each stage with a feature set defined. We're very interested in v3.0 and at
this time we have no idea about its present and future.
Regards,
Anatoli
-Original Message-
From: Cyrus-devel
[mailto:cyrus-devel
(and others) think about the proposed (in my
previous mail) specialuse integration into autocreate_inbox_folders? I could
try to implement it if the core devs consider it a useful feature.
Regards,
Anatoli
-Original Message-
From: Leena Heino [mailto:leena.he...@uta.fi]
Sent: Thursday, April 21
ice 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 informat
Ellie,
I see the fixes in master, great!
I'll respond about the backup compile error in private to keep this thread
on-topic.
Regards,
Anatoli
From: Cyrus-devel
[mailto:cyrus-devel-bounces+me=anatoli...@lists.andrew.cmu.edu] On Behalf Of
ellie timoney via Cyrus-devel
Sent
ex 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
T
Should I write to someone in particular to discuss the subject?
Regards,
Anatoli
ECIAL-USE)
...
* LIST (\HasNoChildren \Archive) "/" folder
...
The flag is still set.
The T199 actually mentions exactly this behavior. Why do you think that this
is not a bug? How is it supposed the specialuse flag should be set from
cyradm? OR, what does the specialuse property from getmd mean if
,
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 interes
already stored mails? I
find lack of this feature as the only (but notable) downside to Sieve vs
local rules.
Regards,
Anatoli
*From:* Ken Murchison Via Cyrus-devel
*Sent:* Monday, February 06, 2017 19:34
*To:* Cyrus-devel
*Subject:* Cyrus Sieve futures
All,
I'm in the process of rewriting the
James, I didn't know about this RFC, but I just read it and that's
exactly what is needed!
Ken, +1 for imapsieve :)
*From:* James Cassell Via Cyrus-devel
*Sent:* Wednesday, February 08, 2017 13:15
*To:* Cyrus Devel
*Subject:* Re: Cyrus Sieve futures
On Tue, Feb 7, 2017, at 02:36 AM, Anatoli
e: Cyrus Sieve futures
Actually, that's pretty much already done, the separation. Sieve, more
than any other part of the Cyrus code, is very decoupled. It used to be
a separate CVS repository once upon a time.
Bron.
On Tue, 7 Feb 2017, at 18:36, Anatoli via Cyrus-devel wrote:
Hi Ken,
I
Re: Cyrus Sieve futures
I'm pretty sure there's no IO handling inside the sieve bytecode
processing, though it makes callbacks to perform the actual actions -
so the impure bits are very clearly defined.
On Wed, 8 Feb 2017, at 13:05, Anatoli via Cyrus-devel wrote:
Bron, do you mean Sieve is
o be
able to contribute it during the Q1/17. Once this change is implemented
(which in itself wouldn't change almost any functionality, so it would
be easy to test and deploy), the chroot functionality would be some 15
lines of code.
Merry Christmas and Happy New Year!
Anatoli
*From:* Bron Gondwana Via C
Hi All,
> NEXT WEEK:
> * read through issues for anything that should be a 3.2 release
blocker and we'll discuss the tasks at the next meeting.
Bron, please consider issues #1765/#2100 (a chroot implementation
blocker) and #1763 (efficient backup blocker).
Thanks,
Anatoli
*From:
Ellie, Ken, thanks for the clarifications! Ellie, I hope you recover soon!
Best regards,
Anatoli
*From:* Ellie Timoney
*Sent:* Monday, July 29, 2019 20:28
*To:* Cyrus Devel
*Subject:* Re: Notes 29 July
On Mon, Jul 29, 2019, at 11:10 PM, Anatoli via Cyrus-devel wrote:
There are a lot
in the near
future? 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.
Regards,
Anatoli
*From:* Bron Gondwana
*Sent:* Monday, July 29, 2019 08:36
*To:* Cyrus Devel
*Subject:* Notes 29 July
Present
ld be reviewed and
merged too?
Regards,
Anatoli
On 5/11/19 09:25, Bron Gondwana wrote:
> I've tagged those 4 issues for 3.2.
>
> We're going to try to work out what work is necessary for 3.2 to be
> done, so knowing that these are important is valuable.
>
> Cheers,
>
> Br
would have to be done to
guarantee it (i.e. to make it like Cyrus was shutdown normally)?
Regards,
Anatoli
On 7/11/19 19:56, Bron Gondwana wrote:
> On Thu, Nov 7, 2019, at 15:46, Anatoli via Cyrus-devel wrote:
>> Bron,
>>
>> Thanks for your detailed reply and the work
ccur (I suppose this is where the mail data and
all sorts of databases are written). Once they are identified they could
be tweaked a bit for better concurrency and lockability and then we
could analyze how to wrap them with a global lock/barrier.
Regards,
Anatoli
On 12/11/19 06:20, Bron Gondwan
ou decide with Ellie
on possible directions.
Thanks!
Anatoli
On 5/11/19 18:20, Bron Gondwana wrote:
> On Wed, Nov 6, 2019, at 03:44, Anatoli via Cyrus-devel wrote:
>> Hi All!
>>
>> Bron, for deployments I manage these issues are also important:
>
> First of all - thanks for w
ync/write logic to be able to
provide a working solution. But once the write operations are
encapsulated in separate functions and there's a list of all of them, I
could implement the efficient global locking and the backup tool that
would leverage it.
Regards,
Anatoli
On 13/11/19 02:25, Bron Gondwana
53 matches
Mail list logo
