Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

1) I am trying to use DSPAM with the PostgreSQL driver (use flag postgres) but
the driver does not get installed. /usr/lib/dspam/ is absolutely empty.

2) The hash driver does not get compiled when emerging DSPAM. The hash driver
could/should be always compiled since the hash driver is not depended to any
database backend and always available in DSPAM. DSPAM supports the compilation
with multiple drivers which can be exchanged in dspam.conf.

Reproducible: Always

(In reply to comment #0)
> 2) The hash driver does not get compiled when emerging DSPAM. The hash driver
> could/should be always compiled since the hash driver is not depended to any
> database backend and always available in DSPAM.

Erm, nope. It is intentionally disabled if you select anything else, because
it's buggy. Read the ewarn in ebuild.

(In reply to comment #0)
> 1) I am trying to use DSPAM with the PostgreSQL driver (use flag postgres) but
> the driver does not get installed. /usr/lib/dspam/ is absolutely empty.

When you select only one database backend, the driver is compiled as a static
library, thus the .so file does not exist.

> 2) The hash driver does not get compiled when emerging DSPAM. The hash driver
> could/should be always compiled since the hash driver is not depended to any
> database backend and always available in DSPAM. DSPAM supports the compilation
> with multiple drivers which can be exchanged in dspam.conf.

Jakub already replied to this point.

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

(In reply to comment #1)
> (In reply to comment #0)
> > 2) The hash driver does not get compiled when emerging DSPAM. The hash driver
> > could/should be always compiled since the hash driver is not depended to any
> > database backend and always available in DSPAM.
> 
> Erm, nope. It is intentionally disabled if you select anything else, because
> it's buggy. Read the ewarn in ebuild.
> 
No! The hash driver is not buggy. You are referring to bug #179400?
The hash driver is not suited for every tokenizer and pvalue. The hash driver
is only there for Tokenizer SBPH and PValue markov. No other driver can be used
when you set the tokenizer to SBPH and PValue to markov. That's the reason the
hash driver is there.

The other backends are suited for all other tokenizers except for SBPH.

If you use the hash driver for anything else then SPBH then the driver will
only save one class in the storage engine. Either spam or ham. Depending which
one you hit first. But it will only save one class and not both.

The hash driver is +/- a one to one copy from Bill's Yerazunis CSS (CRM Sparse
Spectra) and it is heavy used in CRM114 (and in OSBF-Lua). Jonathan Zdziarski
added it to DSPAM some time ago and the only purpose is to serve as a storage
engine for CRM114's SBPH (Sparse Binary Polynomial Hashing) tokenizer. It has
it's purpose and I think you should readd it back into the DSPAM ebuild.

Using the hash driver for anything else then SBPH will lead into issues as
described in #179400

This all is described in the documentation of DSPAM (at least I think so. Maybe
I am working to long with DSPAM, CRM114, OSBF and have read this on the mailing
list or some were else. But I really think this is described in the
documentation).

Fixed in -r3. Now hash storage driver is always installed and I've added ewarns
at the beginning of pkg_postinst() about how to use it. Also, when no other
backend is installed, dspam.conf will have the following characteristics:
 - no StorageDriver selected (since hash is the only backend available, it will
be build as a static library)
 - Tokenizer sbph
 - PValue markov

Thank you very much for the info!

(In reply to comment #4)
> Fixed in -r3. Now hash storage driver is always installed and I've added ewarns
> at the beginning of pkg_postinst() about how to use it. Also, when no other
> backend is installed, dspam.conf will have the following characteristics:
>  - no StorageDriver selected (since hash is the only backend available, it will
> be build as a static library)
>  - Tokenizer sbph
>  - PValue markov
> 
> Thank you very much for the info!
> 

Markov is the killer. Using Markov with anything else then hash driver is a
show stopper.

Anyway... You made me rethink the Cron job for DSPAM. We need to rework that
beast to handle more scenarios. I have rewritten for me the script to handle
all compiled/installed drivers and added some other stuff to it (like vacuum
for DSPAM tables in PostgreSQL, compressing CSS files for the hash driver and
purging of signatures for the hash driver).

Should I post the new job here or should I open a new bug?

// SteveB

(In reply to comment #5)
> Markov is the killer. Using Markov with anything else then hash driver is a
> show stopper.

Doug had problems with hash driver and I doubt he was using markov (I suspect
he was using the default dspam.conf).


> Should I post the new job here or should I open a new bug?

Open a new bug, but don't expect me to respond faster than in a couple of weeks
because I'm on vacation. You got this reply because I have insomnia and I found
an open wireless network at my hotel. ;)