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.
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 :-\ 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 > --
