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
