Ilja,
Correction I wiped my cvs out and re-checked it out and the changes are
there. I was expecting the update command to merge the changes is this
not the case with the dbmail cvs tree?
On the list.c stuff I see this with the dmalloc lib we talked about a
while back, do you knotice a state where the imapd and pop3d daemons will
not exit when given a sig term? I am having an issue with them while
debugging and I don't in the cvs from 1/12/04. Any ideas? If you want
this patch for dmalloc let me know I will be glad to send it on so you
can check with it yourself.
Thanks,
leif
p.s. Aaron I still want to help on the libsieve and sieve code, and to
anyone else if you have the framework for server side sorting and
threading I would like to help with that otherwise I may have to write it
myself :) Thanks.
> 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" <aaron@serendipity.palo-alto.ca.us> 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" <aaron@serendipity.palo-alto.ca.us> 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"" <aaron@serendipity.palo-alto.ca.us> 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 <ilja@ic-s.nl> 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 <ilja@ic-s.nl> 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 <ilja@ic-s.nl> 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" <aaron@serendipity.palo-alto.ca.us> 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
>
