search for: njr

http://dovecot.org/test/ I've still lots of mails in my INBOX and in this list that I should be looking into.. But here's a release that fixes at least some things. Maybe I'll make another one tomorrow.. Most importantly keyword code was changed a lot. It's now faster and less buggy. The keywords are also finally written into mbox, and keyword changes in the mbox are picked up.

...so far. Almost everyone uses mbox format, and most users primarily use SquirrelMail; I use Apple Mail and Thunderbird, as well as accessing the mailboxes locally with Mutt, and have not noted any visible problems. There have been several of these messages: dovecot: Feb 21 11:40:06 Error: IMAP(njr): mbox sync: UID inserted in the middle of mailbox /usr/home/njriley/mail/lists/trac (5308 > 1151) dovecot: Feb 21 22:57:13 Error: IMAP(njr): mbox sync: UID inserted in the middle of mailbox /usr/home/njriley/mail/lists/trac (6458 > 1151) dovecot: Feb 22 08:37:03 Error: IMAP(njr): mbox sync...

http://dovecot.org/test/ Fixes: - Crashes in non-x86 64bit systems - Bugs in cache file header caching (you probably should delete all dovecot.index.cache files to be sure the bug won't haunt you in future) - FETCH ENVELOPE patch by Chris Wakelin (I'll try to figure out what to do with the list patch later) Known bugs left: - Thunderbird + maildir: moving lots of messages from

http://dovecot.org/test/ Now checks that field alignmentations are in indexes as they're expected. test78 crashed if it was wrong, earlier versions ignored the problem (and crashed with 64bit systems). Now if it's wrong, it prints error to log file and recreates the index. That means you probably should delete all dovecot.index files to avoid tons of errors in log files. Only mbox users

..."I've nothing against OO, I do have something against C++. Its a dogs dinner. Anyone who's (tried) to read Stroustrups book on C++ like I had the misfortune of doing knows that the man is very intelligent but has about as much clarity of thought as Timothy Leary on a bad day." -- NJR in comp.os.linux.development.apps

In my experience, with the gcc compiler, cross-compiling is highly reliable. If your code runs on one processor, then it will run on all. Linking and such might be an issue, which you will discover immediately when the first person tries to run what you've built on their system. It still would be great to run these tests on all four. Actually, you should be able to test 32-bit