[Dovecot] 1.0.rc25 released
http://dovecot.org/releases/dovecot-1.0.rc25.tar.gz http://dovecot.org/releases/dovecot-1.0.rc25.tar.gz.sig
Instead of having "Should v1.0 be released already" discussion, how about having "What's still missing from wiki.dovecot.org and how could it be improved" discussion? And what should the wiki exported to doc/ directory in the tarball look like?
* If time moves backwards, Dovecot kills itself instead of giving
random problems.
+ Added --with-headers configure option to install .h files.
Binary package builders could use this to create some dovecot-dev
package to make compiling plugins easier.
- PLAIN authentication: Don't crash dovecot-auth with invalid input.
- IMAP APPEND: Don't crash if saving fails
- IMAP LIST: If prefix.INBOX has children and we're listing under
prefix.%, don't drop the prefix.
- mbox: Broken X-UID headers still weren't handled correctly.
- mail-log plugin: Fixed deleted/undeleted logging.Timo Sirainen said the following on 1/3/2007 14:03:
And what should the wiki exported to doc/ directory in the tarball look like?
I think that the tarball should contain a "link" to wiki documentation.
This would avoid the obsolescence of the data and limit the updates to one single place.
Ciao, luigi
-- / +--[Luigi Rosa]-- \
Great warriors? Wars not make one great. --Yoda, The Return of The Jedi
On Thu, 2007-03-01 at 14:08 +0100, Luigi Rosa wrote:
Timo Sirainen said the following on 1/3/2007 14:03:
And what should the wiki exported to doc/ directory in the tarball look like?
I think that the tarball should contain a "link" to wiki documentation.
It already does contain doc/USE-WIKI-INSTEAD file.
This would avoid the obsolescence of the data and limit the updates to one single place.
But the problem is that wiki might be down or there might be some network connectivity problems. It's pretty annoying when you can't get to the documentation.
All the updates would still go through Wiki. I'd just run some script before the tarball creation to fetch the latest changes. And I already monitor all the changes in the Wiki so there shouldn't be any surprises that accidentally go into the tarball. :)
Luigi Rosa wrote:
Timo Sirainen said the following on 1/3/2007 14:03:
And what should the wiki exported to doc/ directory in the tarball look like?
I think that the tarball should contain a "link" to wiki documentation.
This would avoid the obsolescence of the data and limit the updates to one single place.
On the other hand, sometimes having some readme files on the server you're working on is preferable to having to look for things on the web (you can do more than manual copy and paste). Plus, if a snapshot of the wiki is included with the distribution, you lessen the chance of having documentation that doesn't apply to the version a particular server is running; obsolescence of the data isn't necessarily bad, if it matches the obsolescence of the software.
Ciao, luigi
Luigi Rosa wrote:
Timo Sirainen said the following on 1/3/2007 14:03:
And what should the wiki exported to doc/ directory in the tarball look like?
I think that the tarball should contain a "link" to wiki documentation.
I might suggest handling it like Exim does -- the main dovecot.tar.gz is the code only, and there's a second download of dovecot-docs.tar.gz; this way you can release updated/fixed documentation (and indeed maintain it separately) from the running codeball.
See this dir for example: http://mirrors.fourbatons.com/exim/ftp/exim/exim4/
In Exim's case there are several doc tarballs, depending on the style you want. Personally I never download any of them, having no need of the docs on my server.
-te
-- Troy Engel | Systems Engineer Fluid, Inc | http://www.fluid.com
Troy Engel schrieb:
Luigi Rosa wrote:
Timo Sirainen said the following on 1/3/2007 14:03:
And what should the wiki exported to doc/ directory in the tarball look like?
I think that the tarball should contain a "link" to wiki documentation.
I might suggest handling it like Exim does -- the main dovecot.tar.gz is the code only, and there's a second download of dovecot-docs.tar.gz; this way you can release updated/fixed documentation (and indeed maintain it separately) from the running codeball.
Maintaining it separately is what already happens, but separate downloads confuse end users even if they are skilled admins, because it makes the whole dovecot story inconcise and inconvenient.
A tarball should be self-contained, code and docs that don't require X11 stuff, period.
Plus, documentation must match code, which isn't necessarily the case for separate doc tarballs (special formats can be kept separate, but basic docs in a common/standard format should remain in the code tarball) - nobody stops Timo from releasing X.Y.1 with one line in the NEWS file "+ fixed several documentation inaccuracies" or thereabouts.
On 1 mars 07, at 14:03, Timo Sirainen wrote:
"What's still missing from wiki.dovecot.org and how could it be improved" discussion? And what should the wiki exported to doc/ directory in the tarball look like?
In TWiki, there is a "publish" plugin that create an offline version
of a TWiki Web. I don't know Moinmoin, but there might be a similar
solution : http://moinmoin.wikiwikiweb.de/FormatterMarket
I like the idea of the single PDF, it's easy to use for a sysadmin
and search is better than in multiple HTML files.
Charles
On Thu, Mar 01, 2007 at 02:48:08PM +0100, Charles Bueche wrote:
I like the idea of the single PDF, it's easy to use for a sysadmin
and search is better than in multiple HTML files.
Except that most sysadmins won't have a PDF reader installed on their IMAP server...? I'd prefer textual, man, or html format over pdf.
GeertOn Thu, 2007-03-01 at 15:06 +0100, Geert Hendrickx wrote:
Except that most sysadmins won't have a PDF reader installed on their IMAP server...? I'd prefer textual, man, or html format over pdf.
pdf2txt? HTML would be great. Both HTML and PDF could be generated by an intermediate format like docbook by the way.
ciao
Luca
On Thu, 2007-03-01 at 15:10 +0100, Luca Corti wrote:
pdf2txt? HTML would be great. Both HTML and PDF could be generated by an intermediate format like docbook by the way.
MoinMoin contains a script to dump the whole wiki into html:
MoinMoin/script/moin.py export dump --target-dir=/some/where
I was trying to change that to get it to dump to plain text but that didn't work, I can try again and talk to the Moin developers if you want that.
johannes
On Thu, 2007-03-01 at 15:14 +0100, Johannes Berg wrote:
On Thu, 2007-03-01 at 15:10 +0100, Luca Corti wrote:
pdf2txt? HTML would be great. Both HTML and PDF could be generated by an intermediate format like docbook by the way.
MoinMoin contains a script to dump the whole wiki into html:
MoinMoin/script/moin.py export dump --target-dir=/some/where
I was trying to change that to get it to dump to plain text but that didn't work, I can try again and talk to the Moin developers if you want that.
I think the documentation should be in plaintext. At least I don't like reading HTML docs myself unless they're really in the web (lynx kind of sucks).
You previously suggested some text formatter in MoinMoin. I was going to try that, but if there exists a simple "export dump" command to do everything that would be even better. :)
On Thu, 2007-03-01 at 16:22 +0200, Timo Sirainen wrote:
I think the documentation should be in plaintext.
Agreed.
You previously suggested some text formatter in MoinMoin. I was going to try that, but if there exists a simple "export dump" command to do everything that would be even better. :)
Yeah, I just tried hacking the "export dump" to make plaintext but that didn't work, might need some more tricks. I'll ask the (other) moin developers [just got commit access a few days ago]
johannes
On Thu, Mar 01, 2007 at 03:24:50PM +0100, Johannes Berg wrote:
On Thu, 2007-03-01 at 16:22 +0200, Timo Sirainen wrote:
I think the documentation should be in plaintext.
Agreed.
I second it.
You previously suggested some text formatter in MoinMoin. I was going to try that, but if there exists a simple "export dump" command to do everything that would be even better. :)
Yeah, I just tried hacking the "export dump" to make plaintext but that didn't work, might need some more tricks. I'll ask the (other) moin developers [just got commit access a few days ago]
johannes
--
Steven F. Siirila Office: Lind Hall, Room 130B Internet Services E-mail: sfs@umn.edu Office of Information Technology Voice: (612) 626-0244 University of Minnesota Fax: (612) 626-7593
Johannes Berg wrote:
On Thu, 2007-03-01 at 16:22 +0200, Timo Sirainen wrote:
I think the documentation should be in plaintext.
Agreed.
Glad to see I'm not the only person here who likes to be able to read the docs with "more".
I'm not averse to the idea of one of the "structured text" variants, but mostly because the good ones are designed to look like plain text documentation.
-- Curtis Maloney cmaloney@cardgate.net
Curtis Maloney schrieb:
Johannes Berg wrote:
On Thu, 2007-03-01 at 16:22 +0200, Timo Sirainen wrote:
I think the documentation should be in plaintext.
Agreed.
Glad to see I'm not the only person here who likes to be able to read the docs with "more".
I'm not averse to the idea of one of the "structured text" variants, but mostly because the good ones are designed to look like plain text documentation.
Basically, considerable parts of the documentation use MoinMoin markup, so they're sort of readable with more cat and less dog, - euh: more, cat, dog, or less - but it depends on how well the parties changing the respective documents have kept in mind someone might want to read raw format rather than HTML that MoinMoin formatted.
And so I suggested to feed the stuff through MoinMoin for HTML export and then using one of the numerous HTML-to-plain-text converters -- this will normalize plain text formatting.
Matthias
Matthias Andree wrote:
Curtis Maloney schrieb:
I'm not averse to the idea of one of the "structured text" variants, but mostly because the good ones are designed to look like plain text documentation.
Basically, considerable parts of the documentation use MoinMoin markup, so they're sort of readable with more cat and less dog, - euh: more, cat, dog, or less - but it depends on how well the parties changing the respective documents have kept in mind someone might want to read raw format rather than HTML that MoinMoin formatted.
And so I suggested to feed the stuff through MoinMoin for HTML export and then using one of the numerous HTML-to-plain-text converters -- this will normalize plain text formatting.
Well, that makes sense to me. Though I have a mild aversion to auto-conversion of auto-converted text, mostly likely from idles times filled with re-translating text for the humorous results :)
-- C
Timo Sirainen schrieb:
On Thu, 2007-03-01 at 15:14 +0100, Johannes Berg wrote:
On Thu, 2007-03-01 at 15:10 +0100, Luca Corti wrote:
pdf2txt? HTML would be great. Both HTML and PDF could be generated by an intermediate format like docbook by the way. MoinMoin contains a script to dump the whole wiki into html:
MoinMoin/script/moin.py export dump --target-dir=/some/where
I was trying to change that to get it to dump to plain text but that didn't work, I can try again and talk to the Moin developers if you want that.
I think the documentation should be in plaintext. At least I don't like reading HTML docs myself unless they're really in the web (lynx kind of sucks).
There is more than half a dozen HTML-to-text converters I know of off-hand: lynx, links, elinks, w3m, one htmltotext tool whose name I forgot (check freshmeat.net), dillo.
Oh, and I just remembered HTMLDOC.org of which there's a FrOSS version, which can convert HTML to PDF or PS and generates quite handsome results if used properly. If HTML contains sufficient markup, perhaps that's even a better way than the route via docbook and XSL-FO.
Luca Corti schrieb:
On Thu, 2007-03-01 at 15:06 +0100, Geert Hendrickx wrote:
Except that most sysadmins won't have a PDF reader installed on their IMAP server...? I'd prefer textual, man, or html format over pdf.
pdf2txt? HTML would be great. Both HTML and PDF could be generated by an intermediate format like docbook by the way.
Except that the situation for docbook-to-PDF conversion isn't very bright.
I know of only one affordable tool that allows production-quality PDFs from docbook, which is commercial, albeit with a free-to-use-for-open-source and a free-for-personal-use license, namely RenderX.com's XEP, with the only string includes-a-comment attached.
DSSSL style sheets and surrounding tool-chain are underpowered IMO and the XSL stuff generates FO (Formatting Objects), for which there is no decent FrOSS converter. FOP and PassiveTeX are outdated and don't even handle minimal FO compliance, xmlroff is far from being usable and that's about as much as I'm aware of.
If anyone has any corrections to make, I'll be *very happy* to be wrong and corrected by somebody else here.
Best regards Matthias Andree
FOP was recently (January 2007) updated to version 0.93 and is much more usable now.
Láďa-----Original Message----- From: dovecot-bounces@dovecot.org [mailto:dovecot-bounces@dovecot.org] On Behalf Of Matthias Andree Sent: Thursday, March 01, 2007 3:23 PM To: luca@leenoox.net Cc: Dovecot Mailing List Subject: Re: [Dovecot] 1.0.rc25 released
DSSSL style sheets and surrounding tool-chain are underpowered IMO and the XSL stuff generates FO (Formatting Objects), for which there is no decent FrOSS converter. FOP and PassiveTeX are outdated and don't even handle minimal FO compliance, xmlroff is far from being usable and that's about as much as I'm aware of.
If anyone has any corrections to make, I'll be *very happy* to be wrong and corrected by somebody else here.
Best regards Matthias Andree
On 1 mars 07, at 15:06, Geert Hendrickx wrote:
On Thu, Mar 01, 2007 at 02:48:08PM +0100, Charles Bueche wrote:
I like the idea of the single PDF, it's easy to use for a sysadmin and search is better than in multiple HTML files.
Except that most sysadmins won't have a PDF reader installed on
their IMAP server...? I'd prefer textual, man, or html format over pdf.
It depends on how you work. Usually, I read the doc on my laptop (I
even keep it for future reference) and have some ssh sessions open
where I install/configure my stuff. For recent software packages, the
tendancy is to have the doc as wiki anyway. IMHO, it's much more
readable than a 80 Kb README or INSTALL.
Anyway, this is going OT.
Charles
I am getting a ton of these with 1.0rc25, functionality does not
appear to be impaired:
Mar 1 13:48:18 tempest dovecot: IMAP(arrigo): file mbox-sync-
rewrite.c: line 408 (mbox_sync_read_and_move): assertion failed:
(need_space == (uoff_t)-mails[idx].space)
Mar 1 13:48:18 tempest dovecot: child 15294 (imap) returned error
OpenBSD 3.0 and OpenBSD 3.7
Arrigo
On Thu, 2007-03-01 at 14:49 +0100, Arrigo Triulzi wrote:
I am getting a ton of these with 1.0rc25, functionality does not
appear to be impaired:Mar 1 13:48:18 tempest dovecot: IMAP(arrigo): file mbox-sync- rewrite.c: line 408 (mbox_sync_read_and_move): assertion failed:
(need_space == (uoff_t)-mails[idx].space) Mar 1 13:48:18 tempest dovecot: child 15294 (imap) returned error
rc25 was supposed to fix all of those.. Any idea how to reproduce it? See http://wiki.dovecot.org/MboxProblems
Timo Sirainen wrote:
On Thu, 2007-03-01 at 14:49 +0100, Arrigo Triulzi wrote:
I am getting a ton of these with 1.0rc25, functionality does not
appear to be impaired:Mar 1 13:48:18 tempest dovecot: IMAP(arrigo): file mbox-sync- rewrite.c: line 408 (mbox_sync_read_and_move): assertion failed:
(need_space == (uoff_t)-mails[idx].space) Mar 1 13:48:18 tempest dovecot: child 15294 (imap) returned errorrc25 was supposed to fix all of those.. Any idea how to reproduce it? See http://wiki.dovecot.org/MboxProblems
I'm getting them as well.
I have a manual technique to fix it that Timo sent me, but I'm seeing new instances of this cropping up on previously working boxes out of the blue. I'm not sure what to make of that
Timo Sirainen schrieb:
http://dovecot.org/releases/dovecot-1.0.rc25.tar.gz http://dovecot.org/releases/dovecot-1.0.rc25.tar.gz.sig
Instead of having "Should v1.0 be released already" discussion, how about having "What's still missing from wiki.dovecot.org and how could it be improved" discussion? And what should the wiki exported to doc/ directory in the tarball look like?
- If time moves backwards, Dovecot kills itself instead of giving random problems.
- Added --with-headers configure option to install .h files. Binary package builders could use this to create some dovecot-dev package to make compiling plugins easier.
Could you rename this to --enable-header-install or something like that before you call it 1.0?
autoconf convention is (and I see no reason why Dovecot would need to deviate, it's probably your being unaware of this convention):
--with-foo use package foo in the build (say, SSL)
--enable-bar enable feature bar in the build (say, headers, special-use features, compile-time options).
Thank you.
Matthias
On Thu, 2007-03-01 at 15:04 +0100, Matthias Andree wrote:
- Added --with-headers configure option to install .h files. Binary package builders could use this to create some dovecot-dev package to make compiling plugins easier.
Could you rename this to --enable-header-install or something like that before you call it 1.0?
Changed.
Timo Sirainen schrieb:
http://dovecot.org/releases/dovecot-1.0.rc25.tar.gz http://dovecot.org/releases/dovecot-1.0.rc25.tar.gz.sig
Instead of having "Should v1.0 be released already" discussion, how about having "What's still missing from wiki.dovecot.org and how could it be improved" discussion? And what should the wiki exported to doc/ directory in the tarball look like?
- If time moves backwards, Dovecot kills itself instead of giving random problems.
- Added --with-headers configure option to install .h files. Binary package builders could use this to create some dovecot-dev package to make compiling plugins easier.
- PLAIN authentication: Don't crash dovecot-auth with invalid input.
- IMAP APPEND: Don't crash if saving fails
- IMAP LIST: If prefix.INBOX has children and we're listing under prefix.%, don't drop the prefix.
- mbox: Broken X-UID headers still weren't handled correctly.
- mail-log plugin: Fixed deleted/undeleted logging.
Hi Timo , for my first tests
ignore=Trash with qouta in sql with lda seems still be broken in rc 1.0.25
as well as the trash plugin with lda and sql
-- Mit freundlichen Gruessen Best Regards
Robert Schetterer
https://www.schetterer.org Munich/Bavaria/Germany
Hello Timo!
I've a problem with automake:
aclocal
automake -a
noinst_HEADERS: variable headers' is used but headers' is undefined
Worked well with 1.0rc24.
Version is: automake (GNU automake) 1.7.8 aclocal (GNU automake) 1.7.8
Any ideas?
Thnx.
Ciao, Gerhard
Gerhard Wiesinger schrieb:
Hello Timo!
I've a problem with automake: aclocal automake -a noinst_HEADERS: variable
headers' is used butheaders' is undefinedWorked well with 1.0rc24.
Version is: automake (GNU automake) 1.7.8 aclocal (GNU automake) 1.7.8
Can't reproduce here with CVS (branch_1_0) - which is the same except some ChangeLog changes - and automake 1.7.9.
Why are you using aclocal/automake at all if you're using a tarball?
On Fri, 2007-03-02 at 07:49 +0100, Gerhard Wiesinger wrote:
Hello Timo!
I've a problem with automake: aclocal automake -a noinst_HEADERS: variable
headers' is used butheaders' is undefinedWorked well with 1.0rc24.
Version is: automake (GNU automake) 1.7.8 aclocal (GNU automake) 1.7.8
Any ideas?
I think this should fix it: http://dovecot.org/list/dovecot-cvs/2007-March/007935.html
Hello!
Ok, has been fixed with 1.0rc26. Thnx Timo.
Ciao, Gerhard
On Fri, 2 Mar 2007, Gerhard Wiesinger wrote:
Hello Timo!
I've a problem with automake: aclocal automake -a noinst_HEADERS: variable
headers' is used butheaders' is undefinedWorked well with 1.0rc24.
Version is: automake (GNU automake) 1.7.8 aclocal (GNU automake) 1.7.8
Any ideas?
Thnx.
Ciao, Gerhard
participants (16)
-
Arrigo Triulzi
-
Charles Bueche
-
Curtis Maloney
-
Geert Hendrickx
-
Gerhard Wiesinger
-
Jay Chandler
-
Johannes Berg
-
Justin McAleer
-
Luca Corti
-
Luigi Rosa
-
Láďa
-
Matthias Andree
-
Robert Schetterer
-
Steven F Siirila
-
Timo Sirainen
-
Troy Engel