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
