Oops, hit ENTER before finishing the description.  Here it is:

Two of the tests fail because of 
my local configuration.  Firstly, I don't have Razor installed.  This test should be skipped in 
that instance:

t/razor.............    Not found: spam =  Listed in Razor 

t/razor.............FAILED test 1                                            
        Failed 1/2 tests, 50.00% okay

Secondly, in my 
/etc/mail/spamassassin/local.cf, I have turned off spam_level_stars.  Testing should not 
fail as a result of my local changes!

t/spamd.............ok 11/13    Not found: stars =  X-Spam-
Level: ********** 
t/spamd.............FAILED test 12                                           
        Failed 1/13 tests, 92.31% okay

*** This bug has been marked as a duplicate of 68 ***

Subject: Re: [SAdev]  "make test" fails because of local rules

Actually, the part about razor not being tested if razor not installed is a new 
bug, but I'll fix it right now, so won't bother reopening.

I won't reopen the bug (yet) either, but I don't yet see any evidence that the razor test has been 
fixed.

Err... This bug is fixed.

But what remains unresolved is that make test fails with razor not installed.

I'm preparing a patch right now.

Created attachment 68 [details]
This is a patch! -- New sub in SATest: skip_all_patterns($skip_message)

Reassigning to Craig

Great, thanks for the patch.  In CVS now (and will make it into 2.20!)

Duncan says this bug has been fixed (and the razor test part of it has, now, thanks very much) but 
with the latest CVS I am still getting:

t/spamd.............ok 11/13    Not found: stars =  X-
Spam-Level: ********** 
t/spamd.............FAILED test 12                                           
        Failed 1/13 tests, 92.31% 
okay

Note that I'm NOT talking about a user_prefs file here, I'm talking about having 
globally disabled spam_level_stars in /etc/mail/spamassassin/local.cf.

Subject: Re:  "make test" fails if Razor is not installed

Well, if you want to fix that you have 3 options:

1. Ignore the failed test.  You know why it's failing, you know it's not a 
problem.
2. Temporarily move/rename/disable your local.cf while doing the make test.
3. Submit a patch which makes the testing stuff bypass local config file 
changes.

I thought this was all fixed in bug 68.

Oh well.

Assigning to list...

Craig suggested:
> 3. Submit a patch which makes the testing stuff bypass
> local config file changes.

A few remarks:

After some investigation it's apparent that the spamassassin tests skip the
local.cf by getting the "-c ../rules" argument from t/SATest.pm sa_t_init().
Similarly, t/rule_tests.t passes rules_filename to Mail::Spamassassin->new;
t/spamd.t fails because spamd doesn't have an equivalent way to override the
rules file location.

Unfortunately "spamd -c" is already taken.  It'd be really nice if both spamd
and spamassassin used the same option for this.  As "spamassassin -C" is not yet
taken, I'd suggest adding -C to both spamassassin and spamd as equivalent to the
exisiting "spamassassin -c", and deprecate "spamassassin -c".

However, that still leaves the question of the right way to write the test. 
Should t/spamd.t pass "-C ../rules -L" to sdrun()?  Or should t/SATest.pm be
modified to put a "-C ../rules" into a variable via sa_t_init(), and then use
that variable in start_spamd()?

Created attachment 152 [details]
Implement spamassassin -C config / spamd -C config

I've attached patch #152 which adds the -C option to both spamassassin and spamd.

I went with changing sa_t_init() for the tests.

Created attachment 154 [details]
Update previous patch for spamd long options change

Made some minor changes to adjust for the new spamd longopts code, plus I changed the 
Pod::Usage call to verbose=0 and added a direction to the manpage for more details.  I think 
changing SATest was the right way to go, given that each spamd_xxx.t file is going to want to do 
it, and any test which wants something else will have its own -C flag appended, which will override 
the default -C anyway.

*** Bug 264 has been marked as a duplicate of this bug. ***