Have a good break!

I'll begin working on an incremental patch to update the libSieve API. It'll
be much easier to get that working as a small patch than as yet another
version of this big monster thing we've been kicking around :-)

So... yeah, for others who might begin testing this out, version a9 allows
conditional compilation. Don't even bother trying to compile with libSieve!

Aaron


Ilja Booij <[EMAIL PROTECTED]> said:

> Hi,
> 
> I'll be away on holiday from December 26th to January 4th. I'll add 
> Aaron's LMTP & Sieve patch to CVS after that.
> 
> I'll be offline until January 5th, so I want to wish everybody here a 
> Happy New Year, I'll see (well, actually: e-mail) you in 2004!
> 
> Ilja
> 
> On 23 Dec 2003, at 20:58, Aaron Stone wrote:
> 
> > Weird. I had just upgraded Galeon and managed to have a version 
> > mismatch
> > somewhere deep in Gnome causing it to lock up. So I used lynx...
> >
> > I'll upload again in a few minutes.
> >
> > Aaron
> >
> >
> > Ilja Booij <[EMAIL PROTECTED]> said:
> >
> >> Hi,
> >>
> >> I think something went wrong with the upload. The file has a name with
> >> the whole path attached: /home/aaron/dbmail/lmtpd-sorting-a9.tar.gz 
> >> and
> >> does not seem to be ok. gzip -d says "not in gzip format".
> >>
> >> Ilja
> >> On Dec 23, 2003, at 12:25 AM, Aaron Stone wrote:
> >>
> >>> Ok, a9 posted.
> >>>
> >>> "Aaron Stone" <[EMAIL PROTECTED]> said:
> >>>
> >>>> Nope nothing stupid on your end, just mine. The new Makefile.am
> >>>> requires
> >>>> some changes to acinclude.m4 to define the *ALIB variables.
> >>>>
> >>>> I'll post a9 ASAP with the directories and other cleanups.
> >>>>
> >>>> Sorry, a8 doesn't build without libSieve, but a9 will!
> >>>>
> >>>> Aaron
> >>>>
> >>>>
> >>>> Ilja Booij <[EMAIL PROTECTED]> said:
> >>>>
> >>>>> Hi All, especially Aaron,
> >>>>>
> >>>>> I have trouble compiling the code with the a8 patch. Mainly 
> >>>>> because I
> >>>>> cant seem to get libSieve to compile.. But also because it's, for
> >>>>> now,
> >>>>> impossible to compile without the libSieve headers. The new
> >>>>> Makefile.am
> >>>>> does not really solve this problem, because it does not work..
> >>>>> * It uses subdirectories for storing the sorting code. Which files
> >>>>> should go in to those directories?
> >>>>> * It uses @SORTALIB@ and @AUTHALIB@, but they are not mentioned
> >>>>> anywhere in the other autotools files. Should there be something
> >>>>> included in acinclude.m4?
> >>>>>
> >>>>> Aaron, could you correct this (or am I doing something extremely
> >>>>> stupid?)
> >>>>>
> >>>>> Ilja
> >>>>>
> >>>>> On Dec 22, 2003, at 10:26 AM, Aaron Stone wrote:
> >>>>>
> >>>>>> Cool, glad that insert_messages() abstacts the physmessage stuff. 
> >>>>>> I
> >>>>>> kinda got
> >>>>>> that from a quick read, but no time this weekend to read into it
> >>>>>> that
> >>>>>> much.
> >>>>>>
> >>>>>> The db_copymsg() changes will be included in a9... although if 
> >>>>>> you'd
> >>>>>> like, I
> >>>>>> can send a separate patch to the list if you want to include it
> >>>>>> sooner.
> >>>>>>
> >>>>>> I was actually quite disappointed with the state of the Sieve
> >>>>>> interface; I
> >>>>>> thought I had it a lot farther along than it actually is :-\
> >>>>>> Anyways,
> >>>>>> I wrote
> >>>>>> it for libSieve-2.2.0pre1 and this week I'm going to have pre4 
> >>>>>> which
> >>>>>> has a lot
> >>>>>> of things changed and really a lot of things fixed.
> >>>>>>
> >>>>>> For now, just getting the LMTP daemon, the unified delivery layer
> >>>>>> and
> >>>>>> the
> >>>>>> sort/ directories set up should take enough of everyone's time, 
> >>>>>> and
> >>>>>> are not
> >>>>>> even affected by the broken Sieve situation -- just don't
> >>>>>> ./configure
> >>>>>> --with-sieve. Once the framework is in CVS, I'll focus on the 
> >>>>>> Sieve
> >>>>>> issues.
> >>>>>>
> >>>>>> Aaron
> >>>>>>
> >>>>>>
> >>>>>> Ilja Booij <[EMAIL PROTECTED]> said:
> >>>>>>
> >>>>>>> Hi,
> >>>>>>> On Dec 20, 2003, at 6:33 AM, Aaron Stone wrote:
> >>>>>>>
> >>>>>>>> Just following up to my own message here, I went ahead and tried
> >>>>>>>> out
> >>>>>>>> the
> >>>>>>>> directories thing in my own source tree, and it works like a
> >>>>>>>> charm.
> >>>>>>>> I'm going
> >>>>>>>> to do some more hacking on the lmtp/sorting/sieve patch set and
> >>>>>>>> get
> >>>>>>>> version a9
> >>>>>>>> up onto the SourceForge project this weekend, or maybe Monday
> >>>>>>>> afternoon.
> >>>>>>> I'll just start testing with the a8 patch. And when you're 
> >>>>>>> finished
> >>>>>>> with the a9 version (and everything works :) ), we'll use that 
> >>>>>>> one.
> >>>>>>>>
> >>>>>>>> Oh, Ilja, I noticed that you changed the return type of
> >>>>>>>> db_copymsg()
> >>>>>>>> again. I
> >>>>>>>> gave you a polite time about it, then later a hard time about
> >>>>>>>> it...
> >>>>>>>> so
> >>>>>>>> now
> >>>>>>>> I'll spare no mercy! db_copymsg() really really must give back
> >>>>>>>> the id
> >>>>>>>> number
> >>>>>>>> of the new message that it has created! I patched it to add the
> >>>>>>>> fourth
> >>>>>>>> arg:
> >>>>>>>>
> >>>>>>>> int db_copymsg(u64_t msg_idnr, u64_t mailbox_to,
> >>>>>>>>                u64_t user_idnr, u64_t *newmsg_idnr);
> >>>>>>>>
> >>>>>>>> Lemme know if that works right, or if I have to fiddle with
> >>>>>>>> physmessage or
> >>>>>>>> something crazy like that... I'm not sure yet if I understand 
> >>>>>>>> how
> >>>>>>>> to
> >>>>>>>> use the
> >>>>>>>> physmessage layer. Uh, actually, I'm just ignoring it and
> >>>>>>>> pretending
> >>>>>>>> that the
> >>>>>>>> higher level functions like db_insert_message() take care of
> >>>>>>>> physmessage for
> >>>>>>>> me. Is that the case or do I need to rewrite to support
> >>>>>>>> physmessage
> >>>>>>>> directly?
> >>>>>>> You're completely right. I thought I changed it to return the
> >>>>>>> message_idnr as a call-by-reference parameter. But I didn't..
> >>>>>>>
> >>>>>>> You're correct that functions like db_insert_message() will take
> >>>>>>> care
> >>>>>>> of the physmessage table. No worries about that.
> >>>>>>>
> >>>>>>> Ilja
> >>>>>>> --
> >>>>>>> IC&S
> >>>>>>> Stadhouderslaan 57
> >>>>>>> 3583 JD Utrecht
> >>>>>>> telnr. 030-6355730
> >>>>>>> faxnr. 030-6355731
> >>>>>>>
> >>>>>>> PGP-key:
> >>>>>>> http://www.ic-s.nl/keys/ilja.txt
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Dbmail-dev mailing list
> >>>>>>> [email protected]
> >>>>>>> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> -- 
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Dbmail-dev mailing list
> >>>>>> [email protected]
> >>>>>> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> >>>>>>
> >>>>> --
> >>>>> IC&S
> >>>>> Stadhouderslaan 57
> >>>>> 3583 JD Utrecht
> >>>>> telnr. 030-6355730
> >>>>> faxnr. 030-6355731
> >>>>>
> >>>>> PGP-key:
> >>>>> http://www.ic-s.nl/keys/ilja.txt
> >>>>>
> >>>>> _______________________________________________
> >>>>> Dbmail-dev mailing list
> >>>>> [email protected]
> >>>>> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> -- 
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Dbmail-dev mailing list
> >>>> [email protected]
> >>>> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> >>>>
> >>>
> >>>
> >>>
> >>> -- 
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Dbmail-dev mailing list
> >>> [email protected]
> >>> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> >>>
> >> --
> >> IC&S
> >> Stadhouderslaan 57
> >> 3583 JD Utrecht
> >> telnr. 030-6355730
> >> faxnr. 030-6355731
> >>
> >> PGP-key:
> >> http://www.ic-s.nl/keys/ilja.txt
> >>
> >> _______________________________________________
> >> Dbmail-dev mailing list
> >> [email protected]
> >> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> >>
> >
> >
> >
> > -- 
> >
> >
> >
> > _______________________________________________
> > Dbmail-dev mailing list
> > [email protected]
> > http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> >
> --
> IC&S
> Stadhouderslaan 57
> 3583 JD Utrecht
> telnr. 030-6355730
> faxnr. 030-6355731
> 
> PGP-key:
> http://www.ic-s.nl/keys/ilja.txt
> 
> _______________________________________________
> Dbmail-dev mailing list
> [email protected]
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> 



-- 



Reply via email to