I've put the patch in CVS, because we'll need it anyway. This way, it's
also easier to debug it, because a simple cvs update will get everybody
the new code :)
The delivery chain is still buggy: When delivering messages through
LMTP, all messages get delivered twice.
Ilja
Leif Jackson wrote:
Ilja & Aaron,
I am looking for this patch. I cannot access it from sourceforge? Or do I
have to checkout from cvs differently than the default dbmail root? I
would be glad to look at this.... Also Aaron, i was working on your sieve
code but there are some issues between the current libsieve you have in
cvs and the last one posed on sourceforge, the api and the lib doesn't
match quite right or at least not to the code you have in the dbmail cvs
tree, i am really exited about this feature and would like to help.
Thanks,
Leif
Hi,
don't know why, but I just cannot find the reason why the delivery
user_idnr is added to the userids-list in the dsn twice. It does not
happen when using dbmail-smtp, only when using dbmail-lmtp.
Aaron (or anybody else), can you take a look at this? I'm completely
lost at the moment.. :(
Also, there is the problem with the read_header() function. Some testing
has revealed that it always functions the first time an instance of
dbmail-lmtp gets a message. The second time that the same instance of
the daemon gets a message, it reads the output from the MTA (postfix in
my case) very slowly. Are we forgetting to cleanup something?
Ilja
Ilja Booij wrote:
I haven't found the cause of this bug yet. There is also still a problem
with the read_header() function. It's constantly hanging on an fgets
there..
Ilja
Ilja Booij wrote:
There is no problem when sending messages through dbmail-smtp, only
when using lmtp. Strange..
looking further
Ilja
Ilja Booij wrote:
Now there's another problem with deliveries. I get every mail twice!
I'm firing up gdb as I type..
Ilja
Aaron Stone wrote:
Posted to SourceForge. A little patch to pipe.c and header.c, which
fixes a
buffer boundary issue in the newline/rfc counting, the forgotten
delivery
useridnr loop and a missing rfcsize argument to sort_and_deliver.
It's also a proper forwards patch now :-P
Aaron
"Aaron Stone" <[EMAIL PROTECTED]> said:
Excuses, excuses. See SourceForge for an updated version of the
previously
posted patch; I neglected to add the new rfcsize arguments to the
sort call,
and something else gone wrong read_header(). Valgrinding as we
speak!
Aaron
"Aaron Stone" <[EMAIL PROTECTED]> said:
Now I remember! I continued fixing a bug or two in the
2.0rc2-fixes-snap1
tree after I'd made the patches from it. But to start clean, I
took a fresh
2.0rc2, applied the patches, and then started working towards the
next set
of patches... apparently without bringing this bugfix into the new
tree :-\
I read over the rest of the diff to make sure that I didn't leave
anything
else out, and this does seem to be the only thing I missed.
Apply the attached patch, *reversed* (because I really need sleep
:-P)
Aaron
""Aaron Stone"" <[EMAIL PROTECTED]> said:
Oh, weird. I really did fix that already; I'll see if maybe I
fixed it in an
older tree by accident. Will post a patch this afternoon.
Aaron
Ilja Booij <[EMAIL PROTECTED]> said:
I've applied the patch (have not updated CVS yet).
I ran into the following problem:
When delivering a message, all message go into the mailbox of
user_idnr 0 (that is: zero).
The problem seems to be, that the user_idnrs to deliver the
messages to are kept in delivery->userids (in a list), but that
this list is never used when attempting delivery. The
delivery->userids field is not used when calling
sort_and_deliver(). In that call, only delivery->useridnr is
used, which defaults to zero.
Ilja
Aaron Stone wrote:
Here it goes... I'll also post to SourceForge.
Aaron
Ilja Booij <[EMAIL PROTECTED]> said:
HEAD is completely updated. I'm having some trouble updating
dbmail_2_0_branch, due to conflicts when applying patches. I
guess I'll wait with updating that branch. Or, like somebody
suggested a while
ago,
do the branching on release of 2.0 final (and abandon the
current
branch
for now).
Good luck finishing your project :)
Ilja
Aaron Stone wrote:
If you have CVS updated to your latest working tree I'll patch
against it
in a
few hours. This moment I have to finish up a project before
daybreak.
Aaron
Ilja Booij <[EMAIL PROTECTED]> said:
Just tried this for myself. A lot of warnings..
I guess the cleaned up statements are in the patches you'll
send me today? ;)
I agree we should keep the __attribute__ thing in the
source. It does not cost us anything, and it helps
preventing bugs. Sounds like free lunch to me! :)
Ilja
Aaron Stone wrote:
Well that was fun! I also caught three or four more of the
missing
comma
errors, and a handful of "%s, %s: ...." formats that were
missing the
__FILE__, __FUNCTION arguments.
I cleaned up all of the warnings, though we should
definitely keep
the GNU
attribute in the source to warn against format bugs in the
future.
Aaron
"Aaron Stone" <[EMAIL PROTECTED]> said:
I found the GNU extension to turn on pritnf style format
checking! In
debug.h,
make this your declaration of trace():
void trace(int level, char *formatstring, ...)
__attribute__((format(printf, 2, 3)));
Voila, tons of errors next time you make.
Aaron
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
--
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
--
--
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
