Timo Sirainen wrote:
Maybe this one works? :)
It started...
Didn't work very well, though - got tons of these
imap(teg): Sep 03 11:40:33 Panic: file ostream-file.c: line 183 (update_buffer): assertion failed: (size <= fstream->tail)
when trying to open a folder. Reverting to 0.99.10.9 solved it.
-- Trond Eivind Glomsrød Senior Software Engineer Scali - www.scali.com High Performance Clustering
On 3.9.2004, at 12:43, Trond Eivind Glomsrød wrote:
Didn't work very well, though - got tons of these
imap(teg): Sep 03 11:40:33 Panic: file ostream-file.c: line 183 (update_buffer): assertion failed: (size <= fstream->tail)
when trying to open a folder. Reverting to 0.99.10.9 solved it.
Oh. I noticed it too and fixed it in rc3, but looks like I missed one place. Well, fixed in rc4.
Timo Sirainen wrote:
On 3.9.2004, at 12:43, Trond Eivind Glomsrød wrote:
Didn't work very well, though - got tons of these
imap(teg): Sep 03 11:40:33 Panic: file ostream-file.c: line 183 (update_buffer): assertion failed: (size <= fstream->tail)
when trying to open a folder. Reverting to 0.99.10.9 solved it.
Oh. I noticed it too and fixed it in rc3, but looks like I missed one place. Well, fixed in rc4
RC4 has been working for more than an hour here now, for me and without my office being swarmed by others.
-- Trond Eivind Glomsrød Senior Software Engineer Scali - www.scali.com High Performance Clustering
Timo Sirainen
Maybe this one works? :)
Hum... applications must not #include
On 3.9.2004, at 13:23, Matthias Andree wrote:
Timo Sirainen tss@iki.fi writes:
Maybe this one works? :)
Hum... applications must not #include
(read on below the log): .. Given that this check isn't even used, I'm suggesting this patch:
Right. Wonder why I ever added it.
Timo Sirainen tss@iki.fi writes:
On 3.9.2004, at 13:23, Matthias Andree wrote:
Timo Sirainen tss@iki.fi writes:
Maybe this one works? :)
Hum... applications must not #include
(read on below the log): .. Given that this check isn't even used, I'm suggesting this patch: Right. Wonder why I ever added it.
Oh hum and while you're at it, could you change the early configure.in line so it reads:
AM_INIT_AUTOMAKE(dovecot, 0.99.11, dovecot@dovecot.org)
So autoconf can list the proper bug reporting address in case of trouble.
Thanks,
-- Matthias Andree
Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)
On 3.9.2004, at 14:41, Matthias Andree wrote:
Oh hum and while you're at it, could you change the early configure.in line so it reads:
AM_INIT_AUTOMAKE(dovecot, 0.99.11, dovecot@dovecot.org)
So autoconf can list the proper bug reporting address in case of trouble.
After that it doesn't write PACKAGE and VERSION macros into config.h. When would it use it anyway? Or does that work only with newer automakes than 1.4?
Timo Sirainen tss@iki.fi writes:
On 3.9.2004, at 14:41, Matthias Andree wrote:
Oh hum and while you're at it, could you change the early configure.in line so it reads:
AM_INIT_AUTOMAKE(dovecot, 0.99.11, dovecot@dovecot.org)
So autoconf can list the proper bug reporting address in case of trouble.
After that it doesn't write PACKAGE and VERSION macros into config.h. When would it use it anyway? Or does that work only with newer automakes than 1.4?
Make that AC_INIT with the arguments and use AM_INIT_AUTOMAKE without arguments.
automake 1.4 is obsolete. I have mailed a tarball containing updated acinclude.m4, Makefile.am and configure.in off-list.
-- Matthias Andree
Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)
participants (3)
-
Matthias Andree
-
Timo Sirainen
-
Trond Eivind Glomsrød