> I have a series of patches under the thread "[ 895107 ] Delivery status in > pipe and getopt support in main" in the patch tracker... Sometimes I've > uploaded files that SourceForge pukes on when other people try to download > them. Very odd; methinks SourceForge is a little finicky in places. > Thanks will try and look at that thread.
> > The libSieve in CVS is not current with my working tree. I've was cleaning > up > the API and the data structures and writing documentation for all of it a > few > months ago, but got really busy with school and DBMail and so I only got > around to uploading the documentation :-\ You mind sendming me a tarball offline? Or sending me a place I can get your current working tree? Thx. I understand about getting busy.... > > Aaron > > > "Leif Jackson" <[EMAIL PROTECTED]> said: > >> 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 >> > > > > -- > > > > _______________________________________________ > Dbmail-dev mailing list > Dbmail-dev@dbmail.org > http://twister.fastxs.net/mailman/listinfo/dbmail-dev >
