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" <[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 >
