http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5761
------- Additional Comments From [EMAIL PROTECTED] 2008-01-01 00:36 ------- Created an attachment (id=4225) --> (http://issues.apache.org/SpamAssassin/attachment.cgi?id=4225&action=view) Patch against 3.2 branch to try out to see if solves problem Guess what, it looks like a bug in the tests after all! Here is a patch to try out. Apply the patch, set SPAMD_HOST to 10.0.0.200, but _do not_ start up a separate spamd instance yourself. So just apply this patch, set SPAMD_HOST and try your make test. This isn't a final fix, but if it works for you it means we know what is going on. The problem is that SPAMD_HOST was intended for an external spamd running on another machine, such as you would have to have under Windows where spamd doesn't run. However, if not running under Windows, when SPAMD_HOST is set the spam[cd]*.t tests run their instances of spamd set to accept conections from SPAMD_HOST and then run spamc connecting to SPAMD_HOST. That doesn't really make sense and should be changed. The strange thing is that as a result if you set SPAMD_HOST to an ip address of the local machine and don't start up another spamd, everything is almost right for running the spamc/spamd tests using the ip address $SPAMD_HOST instead of 127.0.0.1. There were just two things missing from that scenario, spamd was started without the -i option, and one place in one test (t/spamd_protocol_10.t) had a hardcoded 127.0.0.1 in it. This patch changes those two lines and allows SPAMD_HOST to indicate a local ip address other than 127.0.0.1 for the tests to use. If this works I'll think a bit about a more correct fix. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
