Hi All,
I just created an issue [1] about subj.
I can create a PR if the proposed fix is ok (I'd go without the type cast).
Regards,
Anatoli
[1] https://github.com/cyrusimap/cyrus-imapd/issues/3128
used 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
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
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
the compiling 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 leas
thing essential for a broader 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
g the issue, so the maintainers 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, Anat
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
&
e 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
cial/required (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 Mur
ibs are available, but would be willing to make that work with Cyrus is
> possible (pull requests welcome).
>
>
> On 6/3/20 5:41 PM, Anatoli wrote:
>> Hi Ken,
>>
>> Thanks for the explanation, though my question was a bit of another
>> scope. Please, let me re
; once he's been online
>>
>> On Wed, Jun 3, 2020, at 2:58 PM, Anatoli wrote:
>>> Hi Ellie,
>>>
>>>> When you configure it with your patch applied and 1.1.0 installed,
>>> does Cyrus build okay?
>>>
>>> Yes, it builds without error
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,
An
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
wslay
Thanks,
Anatoli
tpd 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, origin/HEAD, master)
> Author
has 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
gt; - }
> -
> - buf_ensure(&txn->zbuf, pending);
> - }
> + buf_ensure(&txn->zbuf, deflateBound(zstrm, len));
>
> zstrm->next_out = (Bytef *) txn->zbuf.s + txn->zbuf.len;
> zstrm->avail_out = txn->zbuf.alloc - txn-&g
kept with the checks 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 repor
if (!zstrm->avail_out) {
159 buf_ensure(&txn->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
t bug 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
Дилян,
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
the format of the 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?
Regard
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 experimen
Service unavailable" (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
ertain criteria for the features to be included in each 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
>
1#section-6.5.8
[5] https://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
> so
entire sync/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
laces where
data write operations occur (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,
Anatol
x27;s the case, what 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 detaile
lease let me know if you'd like my feedback once you 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
be they could 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.
>
&
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 of
n 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 Jul
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
*
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
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
of the two (or both) they may support. He's
currently at CalConnect in Tokyo and I'm hoping it prompts some
discussion among the membership.
On 05/26/2018 07:19 PM, Anatoli wrote:
Hi Ken,
Thanks for dedicating time to this issue.
The *current problem*: the auto-discovery mec
ns 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
*Subject:* Re: shared xDAV
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
*
nd haven't found any
issues.
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 Mu
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
<1521968736<*PROPFIND* */dav/calendars/sha
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:
would
allow (among other 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:
evel
*Subject:* 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:
B
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 A
el
*Subject:* Re: 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
most MUAs could be applied to 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
d describe the proposed
changes and others (Greg) would be able to contribute their changes too.
Again, once we all agree on them, everyone involved would provide
corresponding patches. Then we'd repeat the above steps for the actual
chroot changes.
Happy New Year!
Regards,
Anat
ther than in the master). This change
should be carefully analyzed and it's a significant effort, I hope to 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 f
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
out all of them, not allowing to continue to the make stage until all
requirements are satisfied. Please apply the fixes as you see fit.
Regards,
Anatoli
-Original Message-
From: Cyrus-devel
[mailto:cyrus-devel-bounces+me=anatoli...@lists.andrew.cmu.edu] On Behalf Of
ellie timoney
version that doesn't
require lex or yacc. Remove the lex/yacc checking from Configure.
I guess the lex/yacc checking should be placed in the configure again,
inside the enable-sieve block.
Regards,
Anatoli
-Original Message-
From: Ken Murchison [mailto:mu...@andrew.cmu.edu]
Se
elf
should be converted to a notice as compile_et is shipped with cyrus-imap and
everything works as expected?
Regards,
Anatoli
-----Original Message-
From: Anatoli [mailto:m...@anatoli.ws]
Sent: Tuesday, April 19, 2016 03:39
To: cyrus-devel@lists.andrew.cmu.edu
Subject: RE: v3.0
Hi Ellie,
Thanks
o you (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
uot; RETURN (SPECIAL-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 propert
up to each server
implementation (section 3)).
Regards,
Anatoli
-Original Message-
From: Cyrus-devel
[mailto:cyrus-devel-bounces+me=anatoli...@lists.andrew.cmu.edu] On Behalf Of
ellie timoney via Cyrus-devel
Sent: Sunday, April 17, 2016 22:37
To: cyrus-devel@lists.andrew.cmu.edu
Subject
ew and inclusion in v3.0.
Should I write to someone in particular to discuss the subject?
Regards,
Anatoli
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:c
looks 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:
and similar, not for something implemented in normal
IMAP clients, so it makes sense to disable it for production use. Am I
right?
Thanks,
Anatoli
configure.patch
Description: Binary data
62 matches
Mail list logo