[Spambayes] reporet on trying 1.0a6 on SuSE
ian at astounding.org.uk
Sun Sep 21 16:39:02 EDT 2003
On Sun, 21 Sep 2003, Ian Smith wrote:
> I'm still intent on getting it working on my system, so I'll hopefully
> have some more reports shortly.
OK. Back again.
Just in case lots of my problems were down to working from teh .zip rather
than the .tar.gz, I've started again on my quest.
SuSE 8.0, which has python 2.2
Email package installed from source
Previous problems, now trying agin
My uninstall process of the .zip based attempts has been a simple
rm /usr/bin/sb_* Maybe that was a little rash, but I don't remember any
commands starting sb_ before spambayes.
Now using spambayes-1.0a6.1.tar.gz
"setup.py install" fails as before regarding False. Fixed with "True=1"
"False=0" as before. setup.py now apparently completes happily.
"sb_filter.py -n -d .sb_hammie.db" responds "Created new database in
/home/ian/.hammiedb". Indeed it has, so it seems -n ignores teh -d. No
However, this is good, because last time it got upset with the fact teh
scripts were dos format files. Seems that problem was indeed down to
working from teh .zip.
"sb_mboxtrain.py -d .hammiedb -s ./spam -g ./ham" now apparently runs.
This is good - previously it moaned about 'False'. My (naive) deduction
is that the True/False problems I had were caused by working from teh .zip
archive despite the fact that I'm linux.
I have an email in file sb_test_mail, so I try "cat ./sb_test_mail |
sb_filter.py -d ./.hammiedb". That fails, upset about True. D'oh. Said
it was naive.
Traceback (most recent call last):
File "/usr/bin/sb_filter.py", line 187, in ?
File "/usr/bin/sb_filter.py", line 157, in main
h.usedb = True
NameError: global name 'True' is not defined
As root, I add "True=1" and "False=0" to sb_filter.py immediately before
Back as user, "cat ./sb_test_mail | sb_filter.py -d ./.hammiedb" now runs.
It is "unsure; 0.69" whether "ORDER YOUR VALIUM and XANAX HERE !!!" might
be a spam. I guess my training sample wasn't big enough.
Hurrah! I now consider myself a confirmed python hacker. Well, maybe
Try sb_server.py and connecting with lynx. That works, and lets me set
options which subsequently turn up in my settings file, but when I exit
and shutdown I get a traceback. Lynx chops it up a bit, but trying to
500 Server error
Traceback (most recent call last):
line 453, in found_terminator
line 477, in onSave
line 470, in _doSave
line 229, in store
line 233, in _write_state_key
self.db[self.statekey] = (classifier.PICKLE_VERSION,
File "/usr/lib/python2.2/shelve.py", line 77, in __setitem__
self.dict[key] = f.getvalue()
TypeError: object does not support item assignment
At this point I got in a tangle, I don't know what happened, even though I
was certain I was religiously noting everything I did, but somehow
everything stopped working. Tracebacks on everything I tried, some
related to dbmstorage.py among others. Before writing it up here,
however, I checked repeatability by wiping teh lot again and retracing my
path, and everything went as above, but at this point carried on working.
With a .spambayesrc in place I can now "cat ./sb_test_mail | sb_filter.py"
and it works.
Next, I bung in a procmail recipe to feed every email to sb_filter.py, but
I don't act on teh header it puts in, I just intend to watch what it says
manually for a bit:
So, I now think I have a useable system - I'm confident I can make
procmail do what I want with teh spambayes header, and if needs be I can
do training just with sb_mboxtrain.py (I assume - I'm assuming it adds
training, not replaces existing training). I don't trust sb_server.py
yet, becasue I vaguely blame it for teh tangle I listed above. I will try
a more elegant learning scheme, and account that as well, if it helps.
regards, Ian SMith
|\ /| no .sig
More information about the Spambayes