CP866 and 1.0.0

[David Relson]

On Tue, 29 Nov 2005 11:49:25 +0100
Matthias Andree wrote:

> David Relson <relson at osagesoftware.com> writes:
> 
> > We can leave CP866 in.  It's part of the "non-unicode" package that
> > you're about to support with further configure.ac tests.  I suggest
> > that we add an FAQ entry like:
> >
> >   Q: Why am I seeing a "can't find iconv" message while linking bogofilter?
> >
> >   A: Evidently your system doesn't support Unicode.  Try building with
> > "./configure --disable-unicode"
> 
> Well, the problem is more subtle than that.
> 
> ./configure and make work, but "make check" fails in t.encoding and
> t.rfc2047_folded. t.encoding prints "Not supported iso-8859-1 to utf-8"
> before the diff, t.rfc2047_folded prints just the diff.
> 
> Here's a trivial test program that fails on this old Solaris system
> ("iconv: Invalid argument") but works on Linux and newer Solaris systems
> (it needs to be linked with -liconv on Solaris):
> 
> /* ----------------------------------------------------------- */
> #include <iconv.h>
> #include <stdio.h>
> 
> int main(void) {
> 	iconv_t icd = iconv_open("UTF-8", "ISO-8859-1");
> 	if (icd != (iconv_t)-1) {
> 		iconv_close(icd);
> 		return 0;
> 	}
> 	perror("iconv");
> 	return 1;
> }	
> /* ----------------------------------------------------------- */
> 
> I'd rather not ship a version though that is known to break "make check"
> on some common system.
> 
> If you think this would push 1.0.0 too far out, then I'd suggest we
> branch the CVS and call the new branch BRANCH_1-0 and release 1.0.0 from
> there. 
> 
> We can then fix on the trunk and backport the fix to the 1.0 branch and
> release 1.0.1 with the fix later.
> 
> I hope to write the missing and showstopping announcement texts tonight.

The explanation is valuable and appreciated.  This sounds like a build
problem to me.  Remember the build problems we had with SunOS 4.1.1?
As I recall, it had header file problems (or something) that prevented
db4 from building .  Our "solution" was to put that OS on a "not
supported for bogofilter" list.  We _could_ do the same thing in this
case.

In this case, the problem seems to be an inadequate implementation of
iconv.   We could add the old solaris version to the "not supported"
list, but that seems excessive.   Why not have configure check for the
old solaris version and force a non-unicode build?  This would be a
pretty small change that would contribute to the quality of 1.0, would
it not?

About 10 days ago I created a Release-1_0_0 tag using the 0.96.6 code
as the baseline.  I've not yet merged recent changes into that branch
but will do so before releasing 1.0.0. 

For sure when we have the fix for solaris we can include it in 1.0.1.
As I've been saying, issues will arise and need fixing.  I have no
expectations that 1.0.0, 1.0.1, or even 1.0.2 will be long lived.  I
expect increased usage of bogofilter to generate a variety of issues
that will result in a number of 1.0.x releases.  Of course when we
release the ability to change max token length (the feature requested
by Fabrice), we'll have a candidate for 1.1.0 ...