On 02/07/2017 06:51 PM, Stephan Bosch wrote:
> Newer versions of Pigeonhole may use a different version of the compiled
> binary format. So, for some upgrades it may be necessary to recompile.
> Anyway, for now you should be helped by just manually recompiling.
Manually recompiling fixed it. We h
I'm getting lots of errors like this (possibly on every message delivery):
imap2 dovecot: lmtp(rlaa...@wiktel.com): Error: OU02K+gQmFhUAwAAVtfydQ
: sieve: binary save: failed to create temporary file:
open(/var/lib/dovecot/sieve/junk-mail.svbin.ima
p2.852.) failed: Permission denied (euid=500(vmai
On 04/12/2016 04:05 PM, Timo Sirainen wrote:
I added it today:
https://github.com/dovecot/core/commit/03af8e5325a7b4fec36414ac35949457bc426c0b
Cool. And thanks for the awesome software!
--
Richard
We've completed our migration to Dovecot (yay!), so this isn't critical
for me any more. But this change might still be a useful addition to
Dovecot. It doesn't create any non-standard behavior (like my patch for
non-atom flags).
On 03/07/2016 11:16 PM, Richard Laager wrote:
O
While non-standard, the IMAP server we are replacing returns non-system
flags as strings instead of atoms.
Prior to this change, imapc would abort processing on the first message
with a string flag.
---
src/lib-storage/index/imapc/imapc-mailbox.c | 3 ++-
1 file changed, 2 insertions(+), 1 deleti
On 03/04/2016 08:52 AM, Timo Sirainen wrote:
> On 04 Mar 2016, at 07:47, Richard Laager wrote:
>> Is there any way to disable the header hashing in dsync?
...
> Does the attached patch happen to work? Compiles, but untested for now.
It works with one more change on top of your patch:
Is there any way to disable the header hashing in dsync?
I'm doing a one-time migration to Dovecot using imapc. The FETCHes for
Date & Message-ID take a non-trivial amount of time and it's not clear
to me if they have a function for a one-time migration.
--
Richard
I'm using Evolution and Dovecot (on the localhost) and receiving these
errors trying to move a message into the IMAP folder:
C00095 APPEND INBOX (\Answered \Seen NotJunk "Junk" "NotJunk"
"receipt-handled") {1022}
C00095 BAD Error in IMAP command APPEND: Flags list contains non-atoms.
Is this a D
On Tue, 2008-01-01 at 19:52 +0200, Timo Sirainen wrote:
> I'd want two things from BTS related to this:
>
> 1) It needs to be bidirectional: anyone on this mailing list must be
> able to reply to the mail from BTS and the reply must be added to BTS.
> What BTSes support this?
The only thing I can
On Sun, 2007-12-30 at 07:41 +0200, Timo Sirainen wrote:
> Most replies to that mail ignored the 3) part, which is
> the main reason there's no issue tracker yet.
Regarding your three issues:
1. Yes, they all suck in different ways. You have to pick one with the
least suck for you. ;)
2. If you
On Sun, 2007-12-16 at 21:52 +0100, Marcus Rueckert wrote:
> On 2007-12-16 22:43:18 +0200, Timo Sirainen wrote:
> > a) GNU Free Documentation License
> >
> > b) Creative Commons (Attribution-Share Alike?)
> >
> > It could also be dual-licensed to both to maximize the distribution
> > possibilities
On Sat, 2007-10-13 at 09:25 +0100, Daniel W wrote:
> Is it also true that to read a single message
> in a 800MB mbox, you need to load 800MB of data into memory which is
> then searched for that message?
Of course not! That's what an index is for.
Richard
signature.asc
Description: This is a
On Thu, 2007-07-05 at 17:43 +0300, Timo Sirainen wrote:
> On Wed, 2007-07-04 at 16:50 +0200, Steffen Kaiser wrote:
> > drwxrws--- 5 31045 30005 4096 2007-07-04 15:53 ./
> > drwxrwsr-x 2 31045 30005 4096 2007-06-21 12:19 cur/
>
> The setuid-group bit hides group-x bit. The only thing I can think of
On Sun, 2007-06-03 at 13:48 -0400, Dave McGuire wrote:
>That's not to say that simply adding one dependency on glib would
> cause a huge problem...but it indicates the adoption of a mindset,
> and it's a slippery slope.
The same applies to duplicating code in the interest of avoiding
depen
On Sun, 2007-06-03 at 18:48 +0300, Timo Sirainen wrote:
> I've used GLib before. The biggest problem I see with it is that it
> doesn't support memory pools. That's why I duplicated most of its useful
> functionality originally instead of just using it directly. So I think
> it's much better to fix
On Sat, 2007-05-19 at 22:31 +0300, Timo Sirainen wrote:
> On Sat, 2007-05-19 at 14:05 -0500, Richard Laager wrote:
> > On Sat, 2007-05-19 at 20:32 +0300, Timo Sirainen wrote:
> > > SVN is centralized, Mercurial is distributed. Distributed version
> > > control systems
On Sat, 2007-05-19 at 20:32 +0300, Timo Sirainen wrote:
> SVN is centralized, Mercurial is distributed. Distributed version
> control systems allow a lot of nice things.
Also curious here... Why Mercurial vs. TLA (I think that's what they're
calling arch now?), Darcs, Monotone, or Git?
Richard
On Wed, 2007-04-18 at 07:17 -0400, Charles Marcus wrote:
> Well, there is room for argument here... I would call a 'minor' version
> going from 1.0 to 1.0.1. For these increments, I totally agree.
That's a change in the micro version.
http://en.wikipedia.org/wiki/Software_versioning#Numeric
Rich
On Tue, 2007-04-17 at 21:46 +0300, Timo Sirainen wrote:
> I'm planning on keeping v1.1 almost completely compatible with v1.0.
> There could be some minor configuration file changes, but for most
> people v1.0's dovecot.conf should work with v1.1.
Please, this needs to be "Everyone's v1.0 dovecot.
19 matches
Mail list logo
