Re: [Dspam-user] DSPAM 3.9.0 BETA 4
Original-Nachricht > Datum: Wed, 11 Nov 2009 08:17:06 + > Von: Paul Cockings > An: Steve > CC: dspam-user@lists.sourceforge.net > Betreff: Re: [Dspam-user] DSPAM 3.9.0 BETA 4 > Steve wrote: > > > > Has any one of you ever setup another Anti-Spam system in the same range > as DSPAM that was way, way easier to setup as DSPAM? What product was/is > that? > > > > > I started with SA, and found it too complex for me at the time > Then I moved to MailScanner, as pretty website, I even brought the > book! I tired running with mailscanner, but didn't find my way - I > really don't understand it and to make simple things happen seem complex. > > Users should be using bayes plugins for outlook, sysadmins should be > installing Dspam. Dspam isn't complex, we just need to improve > documentation, how-tos, examples etc > Okay then. I am terribly bad at writing in English. But since most of us are native English speakers... they should go and start writing documentation and how-to's. Why do we have just a bunch of commits for 3.9.0 targeting the documentation? We should have more. A very easy to follow step by step instruction should be bundled with the DSPAM documentation. Who is going to take that task? // Steve -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Dspam-user mailing list Dspam-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspam-user
Re: [Dspam-user] DSPAM 3.9.0 BETA 4
Original-Nachricht > Datum: Wed, 11 Nov 2009 06:29:25 +0100 > Von: "Imposit.com - Webmaster" > An: dspam-user@lists.sourceforge.net > Betreff: Re: [Dspam-user] DSPAM 3.9.0 BETA 4 > Hi Steve, > Hallo Martin, > I dont think is too complicated either, but the access to understand dspam > is. > Everything with statistics is for non mathematical persons not easy to understand. If one wants to understand the techniques behind DSPAM then read this PDF here -> http://www-stat.stanford.edu/~tibs/ElemStatLearn/ <- and this here -> http://www.cs.princeton.edu/courses/archive/fall07/cos126/assignments/markov.html <- and this here -> http://www.amsta.leeds.ac.uk/~charles/statlog/ <- and and and... I could point out a bunch of other resources one could read to understand how machine learning works. DSPAM does nothing fancy. It uses those principles to process and learn. > About the idea to split conf files: > The easierst way would and should be making markers to import the conf > file > like @import /path; > Thanks to Hugo Monteiro something like that is already implemented in DSPAM 3.9.0 series. The configure switch is called "--enable-split-configuration" if I am not wrong. > So every user can deside if it make sense or not, how to split and where > any > why and how often > If they want they can make 20 configs :-) > > Personally I would love to see only 5 lines in the config: the DB > connection. > Rest of it should be in a table (okokok I know, maybe I love dbs to > much :-) > You know that the whole DSPAM admin team hates SQL and databases. We strongly believe in NoSQL. No! I am joking :) > Original-Nachricht > > Datum: Tue, 10 Nov 2009 17:19:36 +0100 > > Von: "Imposit.com - Webmaster" > > An: dspam-user@lists.sourceforge.net > > Betreff: Re: [Dspam-user] DSPAM 3.9.0 BETA 4 > > > Shure ist not so hard to configure, > > If you know Dspam. > > > > Its normal for us who knows how and what to do with dspam (more or less > > :-) > > to say its not hard to configure. > > We forgot how hard the first time was :-) > > > > But I see there no way out. Dspam is a Product for Hosters not enduser. > > Its > > their normal job getting into complex Applications, adapt them and use > > them. > > > > If you want to make it easier thers a simple solution: > > First Restrukture the Documentation or make two of it. > > Means One is a Step by Step first install, second the inside all about > > Dpsam > > Documentation. > > > > This will help at first steps. They have to learn it more inside anyway > > and > > this I not nessesary a bad thing. > > > Any one is welcome to write that documentation. As it turns out I am to > deep > involved into DSPAM to see the real problems a beginner might have with > DSPAM. So I am not the best person doing that task. > > > > I think its absolutely the wrong investing now time into make it easier > > instead of bringing dspam into his next generation. > > How many daemons you know where the setup is easy? > > Did you ever setup and apache host (ther are compileoptions a user take > > days > > to understand what they man and even years to know when they need them > and > > not even to think about the configuration)... > > > I would say that DSPAM is not harder then SpamAssassin, CRM114, OSBF-Lua, > Bogofilter, etc... > > Why is all this complain about how complex it is to setup DSPAM? I really > don't get it. Internet -> MTA -> DSPAM -> Inject back into MTA -> Deliver > > The whole DSPAM part is really not that hard. A hand full settings inside > dspam.conf and one is done with the setup. The integration inside the MTA > or > the gluing together with the MTA is the hard part. But I really, really > don't see DSPAM configuration such a ultra - giga - big issue. Am I so > wrong? > > Has any one of you ever setup another Anti-Spam system in the same range > as > DSPAM that was way, way easier to setup as DSPAM? What product was/is > that? > > > > No dpsam is design to be an enterpriselevel system not an enduser > desktop > > filter. The question is not to make a setup easier. > > The question is how to make it easier to understand dspam and its > > strukture > > - here the apache website documentation is a good way to go . > > > > BTW I want to say again that it would be really nessesary getting rid of > > saved files into the Filesystem and replace it with a database driven > > system > > (even when it means that hash no long
Re: [Dspam-user] DSPAM 3.9.0 BETA 4
Imposit.com - Webmaster wrote: > Hi Steve, > I dont think is too complicated either, but the access to understand dspam > is. > > About the idea to split conf files: > The easierst way would and should be making markers to import the conf file > like @import /path; > So every user can deside if it make sense or not, how to split and where any > why and how often > If they want they can make 20 configs :-) > > DSPAM already allows configuration file splitting. Please check the compile time option --enable-split-configuration. That will allow you to just: Include /etc/dspam/dspam.d/ and populate that directory with the files you wish. Regards, Hugo Monteiro. -- ci.fct.unl.pt:~# cat .signature Hugo Monteiro Email: hugo.monte...@fct.unl.pt Telefone : +351 212948300 Ext.15307 Web : http://hmonteiro.net Centro de Informática Faculdade de Ciências e Tecnologia da Universidade Nova de Lisboa Quinta da Torre 2829-516 Caparica Portugal Telefone: +351 212948596 Fax: +351 212948548 www.ci.fct.unl.pt ap...@fct.unl.pt ci.fct.unl.pt:~# _ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Dspam-user mailing list Dspam-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspam-user
Re: [Dspam-user] DSPAM 3.9.0 BETA 4
Steve wrote: > > Has any one of you ever setup another Anti-Spam system in the same range as > DSPAM that was way, way easier to setup as DSPAM? What product was/is that? > > I started with SA, and found it too complex for me at the time Then I moved to MailScanner, as pretty website, I even brought the book! I tired running with mailscanner, but didn't find my way - I really don't understand it and to make simple things happen seem complex. Users should be using bayes plugins for outlook, sysadmins should be installing Dspam. Dspam isn't complex, we just need to improve documentation, how-tos, examples etc -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Dspam-user mailing list Dspam-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspam-user
Re: [Dspam-user] DSPAM 3.9.0 BETA 4
Hi Steve, I dont think is too complicated either, but the access to understand dspam is. About the idea to split conf files: The easierst way would and should be making markers to import the conf file like @import /path; So every user can deside if it make sense or not, how to split and where any why and how often If they want they can make 20 configs :-) Personally I would love to see only 5 lines in the config: the DB connection. Rest of it should be in a table (okokok I know, maybe I love dbs to much :-) Original-Nachricht > Datum: Tue, 10 Nov 2009 17:19:36 +0100 > Von: "Imposit.com - Webmaster" > An: dspam-user@lists.sourceforge.net > Betreff: Re: [Dspam-user] DSPAM 3.9.0 BETA 4 > Shure ist not so hard to configure, > If you know Dspam. > > Its normal for us who knows how and what to do with dspam (more or less > :-) > to say its not hard to configure. > We forgot how hard the first time was :-) > > But I see there no way out. Dspam is a Product for Hosters not enduser. > Its > their normal job getting into complex Applications, adapt them and use > them. > > If you want to make it easier thers a simple solution: > First Restrukture the Documentation or make two of it. > Means One is a Step by Step first install, second the inside all about > Dpsam > Documentation. > > This will help at first steps. They have to learn it more inside anyway > and > this I not nessesary a bad thing. > Any one is welcome to write that documentation. As it turns out I am to deep involved into DSPAM to see the real problems a beginner might have with DSPAM. So I am not the best person doing that task. > I think its absolutely the wrong investing now time into make it easier > instead of bringing dspam into his next generation. > How many daemons you know where the setup is easy? > Did you ever setup and apache host (ther are compileoptions a user take > days > to understand what they man and even years to know when they need them and > not even to think about the configuration)... > I would say that DSPAM is not harder then SpamAssassin, CRM114, OSBF-Lua, Bogofilter, etc... Why is all this complain about how complex it is to setup DSPAM? I really don't get it. Internet -> MTA -> DSPAM -> Inject back into MTA -> Deliver The whole DSPAM part is really not that hard. A hand full settings inside dspam.conf and one is done with the setup. The integration inside the MTA or the gluing together with the MTA is the hard part. But I really, really don't see DSPAM configuration such a ultra - giga - big issue. Am I so wrong? Has any one of you ever setup another Anti-Spam system in the same range as DSPAM that was way, way easier to setup as DSPAM? What product was/is that? > No dpsam is design to be an enterpriselevel system not an enduser desktop > filter. The question is not to make a setup easier. > The question is how to make it easier to understand dspam and its > strukture > - here the apache website documentation is a good way to go . > > BTW I want to say again that it would be really nessesary getting rid of > saved files into the Filesystem and replace it with a database driven > system > (even when it means that hash no longer works). > It will make things simplier - many permission issue will be solved that > way. Even Problems to scale the system and many other things > Right! I would like to do that. A lot of things needs then to be changed in user land. All the small and easy bash tools reading directly from the filesystem would need to be enhanced or DSPAM needs to deliver an interface that one can hook into to get the needed data. > > > > > -Ursprüngliche Nachricht- > Von: Steve [mailto:stev...@gmx.net] > Gesendet: Dienstag, 10. November 2009 16:24 > An: dspam-user@lists.sourceforge.net > Betreff: Re: [Dspam-user] DSPAM 3.9.0 BETA 4 > > > Original-Nachricht > > Datum: Tue, 10 Nov 2009 13:44:03 +0100 > > Von: Tom Hendrikx > > An: Steve > > CC: dspam-user@lists.sourceforge.net > > Betreff: Re: [Dspam-user] DSPAM 3.9.0 BETA 4 > > > Steve wrote: > > > > >> If you would introduce something like Dovecots macro processing of > > >> usernames and domains into Dspam, you can obsolete > > >> --enable-homedir, --enable-long-usernames, --enable-domain-scale, > > >> --enable-large-scale, --with-dspam-home and maybe more from > > >> configure, *and* gain more flexibility for power setups. Ah, > > >> simplicity > > >> > > > @simplicity: That would be more complicated then two simple options > > > (either domain- or large scale). > > > > You would remove 5 configure
Re: [Dspam-user] DSPAM 3.9.0 BETA 4
Original-Nachricht > Datum: Tue, 10 Nov 2009 17:19:36 +0100 > Von: "Imposit.com - Webmaster" > An: dspam-user@lists.sourceforge.net > Betreff: Re: [Dspam-user] DSPAM 3.9.0 BETA 4 > Shure ist not so hard to configure, > If you know Dspam. > > Its normal for us who knows how and what to do with dspam (more or less > :-) > to say its not hard to configure. > We forgot how hard the first time was :-) > > But I see there no way out. Dspam is a Product for Hosters not enduser. > Its > their normal job getting into complex Applications, adapt them and use > them. > > If you want to make it easier thers a simple solution: > First Restrukture the Documentation or make two of it. > Means One is a Step by Step first install, second the inside all about > Dpsam > Documentation. > > This will help at first steps. They have to learn it more inside anyway > and > this I not nessesary a bad thing. > Any one is welcome to write that documentation. As it turns out I am to deep involved into DSPAM to see the real problems a beginner might have with DSPAM. So I am not the best person doing that task. > I think its absolutely the wrong investing now time into make it easier > instead of bringing dspam into his next generation. > How many daemons you know where the setup is easy? > Did you ever setup and apache host (ther are compileoptions a user take > days > to understand what they man and even years to know when they need them and > not even to think about the configuration)... > I would say that DSPAM is not harder then SpamAssassin, CRM114, OSBF-Lua, Bogofilter, etc... Why is all this complain about how complex it is to setup DSPAM? I really don't get it. Internet -> MTA -> DSPAM -> Inject back into MTA -> Deliver The whole DSPAM part is really not that hard. A hand full settings inside dspam.conf and one is done with the setup. The integration inside the MTA or the gluing together with the MTA is the hard part. But I really, really don't see DSPAM configuration such a ultra - giga - big issue. Am I so wrong? Has any one of you ever setup another Anti-Spam system in the same range as DSPAM that was way, way easier to setup as DSPAM? What product was/is that? > No dpsam is design to be an enterpriselevel system not an enduser desktop > filter. The question is not to make a setup easier. > The question is how to make it easier to understand dspam and its > strukture > - here the apache website documentation is a good way to go . > > BTW I want to say again that it would be really nessesary getting rid of > saved files into the Filesystem and replace it with a database driven > system > (even when it means that hash no longer works). > It will make things simplier - many permission issue will be solved that > way. Even Problems to scale the system and many other things > Right! I would like to do that. A lot of things needs then to be changed in user land. All the small and easy bash tools reading directly from the filesystem would need to be enhanced or DSPAM needs to deliver an interface that one can hook into to get the needed data. > > > > > -Ursprüngliche Nachricht- > Von: Steve [mailto:stev...@gmx.net] > Gesendet: Dienstag, 10. November 2009 16:24 > An: dspam-user@lists.sourceforge.net > Betreff: Re: [Dspam-user] DSPAM 3.9.0 BETA 4 > > > Original-Nachricht > > Datum: Tue, 10 Nov 2009 13:44:03 +0100 > > Von: Tom Hendrikx > > An: Steve > > CC: dspam-user@lists.sourceforge.net > > Betreff: Re: [Dspam-user] DSPAM 3.9.0 BETA 4 > > > Steve wrote: > > > > >> If you would introduce something like Dovecots macro processing of > > >> usernames and domains into Dspam, you can obsolete > > >> --enable-homedir, --enable-long-usernames, --enable-domain-scale, > > >> --enable-large-scale, --with-dspam-home and maybe more from > > >> configure, *and* gain more flexibility for power setups. Ah, > > >> simplicity > > >> > > > @simplicity: That would be more complicated then two simple options > > > (either domain- or large scale). > > > > You would remove 5 configure switches that no first-timer understands > > for something that can (and probably should) be handled more elegantly > > in a configuration file, where changes to directory paths are applied to > > configuration items named like "user_homedir": a name that reflects a > > directory path. And *that* is simple and understandable to anyone. > > > You write as if I was the one making up that decision to implement stuff > that way. It's not me. I am just the
Re: [Dspam-user] DSPAM 3.9.0 BETA 4
Shure ist not so hard to configure, If you know Dspam. Its normal for us who knows how and what to do with dspam (more or less :-) to say its not hard to configure. We forgot how hard the first time was :-) But I see there no way out. Dspam is a Product for Hosters not enduser. Its their normal job getting into complex Applications, adapt them and use them. If you want to make it easier thers a simple solution: First Restrukture the Documentation or make two of it. Means One is a Step by Step first install, second the inside all about Dpsam Documentation. This will help at first steps. They have to learn it more inside anyway and this I not nessesary a bad thing. I think its absolutely the wrong investing now time into make it easier instead of bringing dspam into his next generation. How many daemons you know where the setup is easy? Did you ever setup and apache host (ther are compileoptions a user take days to understand what they man and even years to know when they need them and not even to think about the configuration)... No dpsam is design to be an enterpriselevel system not an enduser desktop filter. The question is not to make a setup easier. The question is how to make it easier to understand dspam and its strukture - here the apache website documentation is a good way to go . BTW I want to say again that it would be really nessesary getting rid of saved files into the Filesystem and replace it with a database driven system (even when it means that hash no longer works). It will make things simplier - many permission issue will be solved that way. Even Problems to scale the system and many other things -Ursprüngliche Nachricht- Von: Steve [mailto:stev...@gmx.net] Gesendet: Dienstag, 10. November 2009 16:24 An: dspam-user@lists.sourceforge.net Betreff: Re: [Dspam-user] DSPAM 3.9.0 BETA 4 Original-Nachricht > Datum: Tue, 10 Nov 2009 13:44:03 +0100 > Von: Tom Hendrikx > An: Steve > CC: dspam-user@lists.sourceforge.net > Betreff: Re: [Dspam-user] DSPAM 3.9.0 BETA 4 > Steve wrote: > > >> If you would introduce something like Dovecots macro processing of > >> usernames and domains into Dspam, you can obsolete > >> --enable-homedir, --enable-long-usernames, --enable-domain-scale, > >> --enable-large-scale, --with-dspam-home and maybe more from > >> configure, *and* gain more flexibility for power setups. Ah, > >> simplicity > >> > > @simplicity: That would be more complicated then two simple options > > (either domain- or large scale). > > You would remove 5 configure switches that no first-timer understands > for something that can (and probably should) be handled more elegantly > in a configuration file, where changes to directory paths are applied to > configuration items named like "user_homedir": a name that reflects a > directory path. And *that* is simple and understandable to anyone. > You write as if I was the one making up that decision to implement stuff that way. It's not me. I am just the poor DSPAM user working the last months almost exclusively on developing and fixing issues in DSPAM. The good think to have this as compile option is that you can overstep the reading of dspam.conf in some situations and using what the user has set on compile time. This saves time. Having everything configurable inside dspam.conf would definitely be a great option but does not necessarily makes things less complex. In some areas it makes things more complex. One of such things is the Web-UI where you would need to ensue read access to dspam.conf for the tools and if some one is running the Web UI in a chroot then things get more complicated. Using variables would be cool. But I am sure that most users would not fiddle around with default setups. When looking at what Dovecot allows then I am sure that most users would just use: %u - username %n - user part in u...@domain, same as %u if there's no domain %d - domain part in u...@domain, empty if there's no domain %h - home directory I personally would like to have more then just that. I would like to have the offset functionality as well. That would allow me to implement large scale by just using %h/%1u/%2.1u/%u and domain scale by just using %h/%d/%u. However... one would need to tweak that since DSPAM does not follow strict <1st char>/<2nd char>/ for large scale. If the user name has a "." on the 2nd character then the directory might look like this for user d.u...@domain.tld: /var/spool/dspam/data/d/d.u...@domain.tld/. This basically breaks the assumption that every user can be reached 3 levels down the data root if one is using large scale. >From my viewpoint this is a bug in DSPAM. But probably John has never thought about that a dot has a special meaning on some file systems and that /var/spool/dspam
Re: [Dspam-user] DSPAM 3.9.0 BETA 4
Original-Nachricht > Datum: Tue, 10 Nov 2009 13:44:03 +0100 > Von: Tom Hendrikx > An: Steve > CC: dspam-user@lists.sourceforge.net > Betreff: Re: [Dspam-user] DSPAM 3.9.0 BETA 4 > Steve wrote: > > >> If you would introduce something like Dovecots macro processing of > >> usernames and domains into Dspam, you can obsolete > >> --enable-homedir, --enable-long-usernames, --enable-domain-scale, > >> --enable-large-scale, --with-dspam-home and maybe more from > >> configure, *and* gain more flexibility for power setups. Ah, > >> simplicity > >> > > @simplicity: That would be more complicated then two simple options > > (either domain- or large scale). > > You would remove 5 configure switches that no first-timer understands > for something that can (and probably should) be handled more elegantly > in a configuration file, where changes to directory paths are applied to > configuration items named like "user_homedir": a name that reflects a > directory path. And *that* is simple and understandable to anyone. > You write as if I was the one making up that decision to implement stuff that way. It's not me. I am just the poor DSPAM user working the last months almost exclusively on developing and fixing issues in DSPAM. The good think to have this as compile option is that you can overstep the reading of dspam.conf in some situations and using what the user has set on compile time. This saves time. Having everything configurable inside dspam.conf would definitely be a great option but does not necessarily makes things less complex. In some areas it makes things more complex. One of such things is the Web-UI where you would need to ensue read access to dspam.conf for the tools and if some one is running the Web UI in a chroot then things get more complicated. Using variables would be cool. But I am sure that most users would not fiddle around with default setups. When looking at what Dovecot allows then I am sure that most users would just use: %u - username %n - user part in u...@domain, same as %u if there's no domain %d - domain part in u...@domain, empty if there's no domain %h - home directory I personally would like to have more then just that. I would like to have the offset functionality as well. That would allow me to implement large scale by just using %h/%1u/%2.1u/%u and domain scale by just using %h/%d/%u. However... one would need to tweak that since DSPAM does not follow strict <1st char>/<2nd char>/ for large scale. If the user name has a "." on the 2nd character then the directory might look like this for user d.u...@domain.tld: /var/spool/dspam/data/d/d.u...@domain.tld/. This basically breaks the assumption that every user can be reached 3 levels down the data root if one is using large scale. >From my viewpoint this is a bug in DSPAM. But probably John has never thought >about that a dot has a special meaning on some file systems and that >/var/spool/dspam/data/d/./d.u...@domain.tld is equal to >/var/spool/data/d/d.u...@domain.tld > > It's all written in the doc. > > > > > > > > Then he has not read the documentation. > > > > > > > > And DSPAM preferences are like that. If you read the documentation > > then you will see where you need to change them in order to have > > proper working preferences for a user. It's simple once you have read > > the documentation and not just read but understood. > > > Again, I do not think a new user needs to spend 2 days of documentation > reading before he can get a test setup running. > He does not! If one just installs DSPAM and does not fiddle around then he can have DSPAM up and running in no time. 1) Install DSPAM - apt-get install dspam dspam-webfrontend - emerge dspam dspam-web - rpm -Uvh dspam - etc 2) Configure storage backend inside dspam.conf (for this example I use MySQL) - edit/change: MySQLServer, MySQLUser, MySQLPass, MySQLDb, StorageDriver 3) Configure the delivery and server/client stuff inside dspam.conf: - edit/change: DeliveryHost 127.0.0.1 - edit/change: DeliveryPort 10026 - edit/change: DeliveryIdent localhost - edit/change: DeliveryProto SMTP - edit/change: ServerDomainSocketPath "/var/run/dspam/dspam.sock" - edit/change: ClientHost "/var/run/dspam/dspam.sock" - edit/change: ClientIdent "@dspam_localhost" 4) Import the database schema into MySQL - mysqladmin --user=root -p create dspam - mysql --user=root -p > GRANT SELECT, INSERT, UPDATE, DELETE ON dspam.* TO 'dspam_admin'@'localhost' IDENTIFIED BY 'dspam_admin_password'; > GRANT SELECT, INSERT, UPDATE, DELETE ON dspam.* TO
Re: [Dspam-user] DSPAM 3.9.0 BETA 4
Steve wrote: >> If you would introduce something like Dovecots macro processing of >> usernames and domains into Dspam, you can obsolete >> --enable-homedir, --enable-long-usernames, --enable-domain-scale, >> --enable-large-scale, --with-dspam-home and maybe more from >> configure, *and* gain more flexibility for power setups. Ah, >> simplicity >> > @simplicity: That would be more complicated then two simple options > (either domain- or large scale). You would remove 5 configure switches that no first-timer understands for something that can (and probably should) be handled more elegantly in a configuration file, where changes to directory paths are applied to configuration items named like "user_homedir": a name that reflects a directory path. And *that* is simple and understandable to anyone. > It's all written in the doc. > > > > Then he has not read the documentation. > > > > And DSPAM preferences are like that. If you read the documentation > then you will see where you need to change them in order to have > proper working preferences for a user. It's simple once you have read > the documentation and not just read but understood. > Again, I do not think a new user needs to spend 2 days of documentation reading before he can get a test setup running. > DSPAM is very powerful and the problem is that DSPAM is not hiding > things from the user. And the second problem is that some users not > understanding much of DSPAM internals are not using the tools that > make their life easier but go ahead and fiddle around with changing > dspam.conf and directly adding/removing/modifying entries in the > database instead of using the tools that abstract the complexity for > them (for example dspam_admin). > This is a nice one: they don't understand the internals, yet dive into it and fiddle in all the wrong locations. Are there too many locations, too much documentation explaining too much stuff and not pointing to the right tools, or too stupid users? I never saw dspam_admin before bash autocompletion told me of it's existance. Maybe it was in the docs somewhere, but I think I missed it. The keyword here is: make it more straightforward. Don't write more docs to explain stuff that is simply 'too hard', but make the process simpler and document in 2 parts: the straightforward way and the stuff with all the background info. Most people who don't run a resource-short server don't care which tokenizer is used, as long as it yields them a 99% success rate. >> When I compare the time that I needed to first-time setup Postfix >> for 1 domain and 2 mailboxes (i.e. a test setup) to Dspam with same >> setup: yes, Postfix is easy. I'm not talking about systems with >> gazillion domains/users here, minimal setup should be easier, this >> makes adoption and testing of Dspam much better. ISP-sized setups >> always need special attention so the admin should should give it >> the time and work it needs. It's their work and they know it. >> > DSPAM is not really much harder then Postfix. Installing DSPAM and > configuring it to process mail and tag the mails is easy. Gluing it > together with Postfix is another issue. Can you tell me what was/is > so hard in installing and configuring DSPAM? > This was more than 2 years ago, but I remember at least that I got scared on all the configure switches I didn't understand (or gentoo use flags for that matter), and then getting swamped in the documentation which is accurate, technical and far too much for a newbie. After getting the feeling that I read up on all the things I did not understand, most of the information from the first half of the reading session was already gone. 2 days had passed and I didn't install a thing yet. After that I just installed and started to get a setup running without understanding if I even started in the right direction. I succeeded in the end, but simply said: it is too f***ing hard for a newbie :) > Bring on the ideas and solutions how to make DSPAM easier. If we can agree on thinking up on this concept: getting new users started easily, combining code changes that make configuration/setup more straightforward, and documentation that helps first-timers setting things up in say two hours, then bring on the wiki account. The domain-/large-scale stuff vs. path macro processing would be a nice starter. -- Tom -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Dspam-user mailing list Dspam-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspam-user
Re: [Dspam-user] DSPAM 3.9.0 BETA 4
Original-Nachricht > Datum: Tue, 10 Nov 2009 09:54:50 +0100 > Von: Tom Hendrikx > An: Steve > CC: dspam-user@lists.sourceforge.net, ds...@cytringan.co.uk > Betreff: Re: [Dspam-user] DSPAM 3.9.0 BETA 4 > Steve wrote: > > Original-Nachricht > >> Datum: Tue, 10 Nov 2009 00:43:05 +0100 Von: Tom Hendrikx > >> An: Steve , > >> dspam-user@lists.sourceforge.net Betreff: Re: [Dspam-user] DSPAM > >> 3.9.0 BETA 4 > > > >> Steve wrote: > >> > >>> You miss one point: Everyone and his dog think they can package > >>> the product better. Let's look for example at Debian: They break > >>> up the configuration in peaces and have one part in dspam.conf > >>> while having another part some where external. > >>> > >>> And now just think about how many different distros are there and > >>> other OS that do the same. And now try to bring one universal > >>> tool helping to configure all those DSPAM installations. Good > >>> look doing that! > >> Don't get me wrong, I'm not trying to advocate for a 'universal > >> tool'. If we can install all the relevant stuff in relevant > >> locations (based on FHS or any other sane standard), > >> > > FHS only applies to certain OS. Linux for example. But what about all > > the different *BSD brands? And what about all the different > > incarnations of Solaris/Open Solaris? etc... It's not easy to be > > multi platform. > > 'Sane locations' are available on every OS, just like they are used > right now. That is why configure has things like --prefix > or--sysconfdir: so that the OS, the vendor/distro or the admin can setup > things they like. And the Makefile can (should!) use this information to > it's own advantage. This is off-topic since most of this is already in > place and working fine, or easy to fix. > > >> For instance: the choice for large-scale, domain-scale or none of > >> them. It is not clear what the choice means for your setup: does it > >> affect the default config, or does it also affect the way Dspam > >> works internally? Why does Dspam have this option, and Postfix for > >> example doesn't? Or to turn it the other way: why needs Dspam such > >> a thing and Postfix or Dovecot do not? > >> > > Dovecot has something like that. And Postfix as well. They use it in > > different areas of the product. And all this because of speed and > > other limitations/influences of the underlaying file system. You have > > to think global. Can you imagine 1 million email addresses managed by > > DSPAM? And all of those 1 million emails saved under > > /var/spool/dspam/data/x. Flat. No hierarchy at all. Can you > > imagine how horribly slow lookups in this directory will be? That's > > the reason for the large-scale and/or domain-scale. They both try to > > mitigate that issue by splitting the directory either on the first > > two letters of the email (large scale) or by splitting on domain > > level (domain scale). And don't think that DSPAM is the only one > > doing that. Squid is doing the same with their cache directory. > > Postfix is doing it in the queue. Dovecot is doing it when storing > > the mails in mbox or maildir (see mail_location and the various > > options to tweak how to organize your mail store). > > > > If you would introduce something like Dovecots macro processing of > usernames and domains into Dspam, you can obsolete --enable-homedir, > --enable-long-usernames, --enable-domain-scale, --enable-large-scale, > --with-dspam-home and maybe more from configure, *and* gain more > flexibility for power setups. Ah, simplicity > @simplicity: That would be more complicated then two simple options (either domain- or large scale). @flexibility: Definitely. That would be more flexible. > Another example from yesterdays mail thread: preferences extension. You > can setup default preferences in dspam.conf and database, user > preferences in database and homedir config file, change stuff in the > webUI or via the dspam_admin utility (in which of the mentioned places > does such a change end up, or is there a 5th or even 6th location?). And > in which order are values in all these locations applied? > It's all written in the doc. 1) If preference extensions are enabled then they are first evaluated. 1.1) First by user UID 1.2) Second by default UID (0) 2) Then dspam.conf is evaluated For the web-UI the default.prefs are used to set defaults in the UI if preference extensi
Re: [Dspam-user] DSPAM 3.9.0 BETA 4
Tom Hendrikx wrote: >> @Paul Cockings: I think I'm in the same seat as you: an administrator >> but not a coder. As you can see I don't expect any of this in beta5 or >> 3.9.0 release, I just merely want to point out the places where I think >> Dspam could gain a lot in means of acceptation. >> >> > > And here I forgot to mention that besides all of the talking, I see > Dspam improving already a lot. So keep up the good work, and a big > thanks to everyone that is already contributing! > > Thanks for your input, its all noted and i'll add to the grand list of things to look at. For better installs in the short term, I'm intending to make several 'how-to' on the wiki (there is one started for FreeBSD). This would be a good place to start expanding the documentation into why/which option is for what and when to use. The admins have decided that the basic install docs should remain in the tarball, but any extended docs should be added to the wiki. Everyone is invited to make a how-to, edit an existing one, make comments or tell us about your Dpsam installation. If you want write access to the wiki, just drop me a email. A point worth noting to everyone out there - you don't need to be a coder to add to the project! In fact I think its really healthy to have a mix of user/devels/admin/etc Remember to take a look at the Dspam website (dspam.sf.net) and wiki which is full of resources to help you out (http://sourceforge.net/apps/mediawiki/dspam/index.php?title=Main_Page) Regards to all, Paul -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Dspam-user mailing list Dspam-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspam-user
Re: [Dspam-user] DSPAM 3.9.0 BETA 4
> @Paul Cockings: I think I'm in the same seat as you: an administrator > but not a coder. As you can see I don't expect any of this in beta5 or > 3.9.0 release, I just merely want to point out the places where I think > Dspam could gain a lot in means of acceptation. > And here I forgot to mention that besides all of the talking, I see Dspam improving already a lot. So keep up the good work, and a big thanks to everyone that is already contributing! -- Regards, Tom -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Dspam-user mailing list Dspam-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspam-user
Re: [Dspam-user] DSPAM 3.9.0 BETA 4
Steve wrote: > Original-Nachricht >> Datum: Tue, 10 Nov 2009 00:43:05 +0100 Von: Tom Hendrikx >> An: Steve , >> dspam-user@lists.sourceforge.net Betreff: Re: [Dspam-user] DSPAM >> 3.9.0 BETA 4 > >> Steve wrote: >> >>> You miss one point: Everyone and his dog think they can package >>> the product better. Let's look for example at Debian: They break >>> up the configuration in peaces and have one part in dspam.conf >>> while having another part some where external. >>> >>> And now just think about how many different distros are there and >>> other OS that do the same. And now try to bring one universal >>> tool helping to configure all those DSPAM installations. Good >>> look doing that! >> Don't get me wrong, I'm not trying to advocate for a 'universal >> tool'. If we can install all the relevant stuff in relevant >> locations (based on FHS or any other sane standard), >> > FHS only applies to certain OS. Linux for example. But what about all > the different *BSD brands? And what about all the different > incarnations of Solaris/Open Solaris? etc... It's not easy to be > multi platform. 'Sane locations' are available on every OS, just like they are used right now. That is why configure has things like --prefix or--sysconfdir: so that the OS, the vendor/distro or the admin can setup things they like. And the Makefile can (should!) use this information to it's own advantage. This is off-topic since most of this is already in place and working fine, or easy to fix. >> For instance: the choice for large-scale, domain-scale or none of >> them. It is not clear what the choice means for your setup: does it >> affect the default config, or does it also affect the way Dspam >> works internally? Why does Dspam have this option, and Postfix for >> example doesn't? Or to turn it the other way: why needs Dspam such >> a thing and Postfix or Dovecot do not? >> > Dovecot has something like that. And Postfix as well. They use it in > different areas of the product. And all this because of speed and > other limitations/influences of the underlaying file system. You have > to think global. Can you imagine 1 million email addresses managed by > DSPAM? And all of those 1 million emails saved under > /var/spool/dspam/data/x. Flat. No hierarchy at all. Can you > imagine how horribly slow lookups in this directory will be? That's > the reason for the large-scale and/or domain-scale. They both try to > mitigate that issue by splitting the directory either on the first > two letters of the email (large scale) or by splitting on domain > level (domain scale). And don't think that DSPAM is the only one > doing that. Squid is doing the same with their cache directory. > Postfix is doing it in the queue. Dovecot is doing it when storing > the mails in mbox or maildir (see mail_location and the various > options to tweak how to organize your mail store). > If you would introduce something like Dovecots macro processing of usernames and domains into Dspam, you can obsolete --enable-homedir, --enable-long-usernames, --enable-domain-scale, --enable-large-scale, --with-dspam-home and maybe more from configure, *and* gain more flexibility for power setups. Ah, simplicity Another example from yesterdays mail thread: preferences extension. You can setup default preferences in dspam.conf and database, user preferences in database and homedir config file, change stuff in the webUI or via the dspam_admin utility (in which of the mentioned places does such a change end up, or is there a 5th or even 6th location?). And in which order are values in all these locations applied? When you ask someone to 'change the preference setting', I can understand that he cannot see his change applied when he even doesn't know in which location to update them, and where to check for the result. A good brainstorm could result in something that is a lot more easier to understand and administer (from sysadmin view), to use (from user view) and to debug (from developer or supporter view). I think things like this should be thought of again, and maybe see an overhaul for Dspam 4.0 (yes I'm optimistic:>). You could see this as feature bloat (and that needs to die). This is not the fault of today's developers, but thinking about it could be put on the todo-list. I'd be happy to add my thoughts. > >> I just want to show an example (the answer is in the README), there >> are so much things that you cannot gripe without reading all the >> docs again and again. Postfix is quite easy to setup: default >> install and 30 minutes with a howto suffice for a simple
Re: [Dspam-user] DSPAM 3.9.0 BETA 4
Tom Hendrikx wrote: > Steve wrote: > > > > Maybe it would make a nice point on the todo-list to look into a way to > make sure that new users can get a new install up and running without > too much hassle, even without a configuration utility or strong guidance > /lots of work from their distro. > Hi Tom, This is a subject I personally want to lead with Dspam (along with many others). I started to use Dspam a few years ago, I had a bit of experience with *nix boxes ie I could compile a kernel, install software and read man pages but it took me weeks to get Dspam running and even then I wasn't confident of the options i'd chosen! As a Dspam admin (but not a coder) I have a passion to fix this, but all resources have been focused on sorting the code base out and releasing 3.9.0. Once we have this new release (and I promise the community that many of us are working really hard to make this happen) then we'll start looking at the docs, options and installation process for Dspam. I want a good solid base (3.9.0) to work from first. Kind regards, Paul -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Dspam-user mailing list Dspam-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspam-user
Re: [Dspam-user] DSPAM 3.9.0 BETA 4
Original-Nachricht > Datum: Tue, 10 Nov 2009 00:43:05 +0100 > Von: Tom Hendrikx > An: Steve , dspam-user@lists.sourceforge.net > Betreff: Re: [Dspam-user] DSPAM 3.9.0 BETA 4 > Steve wrote: > > > You miss one point: Everyone and his dog think they can package the > > product better. Let's look for example at Debian: They break up the > > configuration in peaces and have one part in dspam.conf while having > > another part some where external. > > > > And now just think about how many different distros are there and > > other OS that do the same. And now try to bring one universal tool > > helping to configure all those DSPAM installations. Good look doing > > that! > > Don't get me wrong, I'm not trying to advocate for a 'universal tool'. > If we can install all the relevant stuff in relevant locations (based on > FHS or any other sane standard), > FHS only applies to certain OS. Linux for example. But what about all the different *BSD brands? And what about all the different incarnations of Solaris/Open Solaris? etc... It's not easy to be multi platform. > we can also ship a tool that can work > with this setup. Distros can customize by using --prefix and the likes, > and the DSPAM build scripts can deal with it. > > If Debian or anybody else decides that they know better than upstream, > then that is their way of working. I'm sure they'll find a way to make > good use of a configuration tool we ship, or just remove it from their > package. > > > > > At the time when I wrote that configure part for the Ebuild, every > > one in the Gentoo community was crying out loud how hard it is to > > configure DSPAM. I could not hear any more those complains so I did > > not wanted to repeat the same and again the same message/instructions > > on the Gentoo forum. That was one of the reasons I rewrote the > > Ebuild. > > Dspam *is* hard to configure, also after using the script in the ebuild: > there are lots of other options that might need some fiddling before you > have dspam running in a way fit for you, your users and your hardware. > > For instance: the choice for large-scale, domain-scale or none of them. > It is not clear what the choice means for your setup: does it affect the > default config, or does it also affect the way Dspam works internally? > Why does Dspam have this option, and Postfix for example doesn't? Or to > turn it the other way: why needs Dspam such a thing and Postfix or > Dovecot do not? > Dovecot has something like that. And Postfix as well. They use it in different areas of the product. And all this because of speed and other limitations/influences of the underlaying file system. You have to think global. Can you imagine 1 million email addresses managed by DSPAM? And all of those 1 million emails saved under /var/spool/dspam/data/x. Flat. No hierarchy at all. Can you imagine how horribly slow lookups in this directory will be? That's the reason for the large-scale and/or domain-scale. They both try to mitigate that issue by splitting the directory either on the first two letters of the email (large scale) or by splitting on domain level (domain scale). And don't think that DSPAM is the only one doing that. Squid is doing the same with their cache directory. Postfix is doing it in the queue. Dovecot is doing it when storing the mails in mbox or maildir (see mail_location and the various options to tweak how to organize your mail store). > I just want to show an example (the answer is in the README), there are > so much things that you cannot gripe without reading all the docs again > and again. Postfix is quite easy to setup: default install and 30 > minutes with a howto suffice for a simple test setup, and it does stuff > like domain-/large-scale in the config file, so you can fiddle with it > easily, *after* having your initial setup up and running. With Dspam you > get lost in the knobs and dials that have all kinds of functions that > are far from obvious, even before can type 'make && make install' ;) > You want to tell me that Postfix is obvious? No way! Some one never having anything done with messaging will have his hard time to configure a properly working Postfix. And the same goes for DSPAM. Without reading and understanding what you read it's hard. No mater at what you look. > Maybe it would make a nice point on the todo-list to look into a way to > make sure that new users can get a new install up and running without > too much hassle, even without a configuration utility or strong guidance > /lots of work from their distro. > I would love if that would be possible. But I am afraid that you can't much a
Re: [Dspam-user] DSPAM 3.9.0 BETA 4
Steve wrote: > You miss one point: Everyone and his dog think they can package the > product better. Let's look for example at Debian: They break up the > configuration in peaces and have one part in dspam.conf while having > another part some where external. > > And now just think about how many different distros are there and > other OS that do the same. And now try to bring one universal tool > helping to configure all those DSPAM installations. Good look doing > that! Don't get me wrong, I'm not trying to advocate for a 'universal tool'. If we can install all the relevant stuff in relevant locations (based on FHS or any other sane standard), we can also ship a tool that can work with this setup. Distros can customize by using --prefix and the likes, and the DSPAM build scripts can deal with it. If Debian or anybody else decides that they know better than upstream, then that is their way of working. I'm sure they'll find a way to make good use of a configuration tool we ship, or just remove it from their package. > > At the time when I wrote that configure part for the Ebuild, every > one in the Gentoo community was crying out loud how hard it is to > configure DSPAM. I could not hear any more those complains so I did > not wanted to repeat the same and again the same message/instructions > on the Gentoo forum. That was one of the reasons I rewrote the > Ebuild. Dspam *is* hard to configure, also after using the script in the ebuild: there are lots of other options that might need some fiddling before you have dspam running in a way fit for you, your users and your hardware. For instance: the choice for large-scale, domain-scale or none of them. It is not clear what the choice means for your setup: does it affect the default config, or does it also affect the way Dspam works internally? Why does Dspam have this option, and Postfix for example doesn't? Or to turn it the other way: why needs Dspam such a thing and Postfix or Dovecot do not? I just want to show an example (the answer is in the README), there are so much things that you cannot gripe without reading all the docs again and again. Postfix is quite easy to setup: default install and 30 minutes with a howto suffice for a simple test setup, and it does stuff like domain-/large-scale in the config file, so you can fiddle with it easily, *after* having your initial setup up and running. With Dspam you get lost in the knobs and dials that have all kinds of functions that are far from obvious, even before can type 'make && make install' ;) Maybe it would make a nice point on the todo-list to look into a way to make sure that new users can get a new install up and running without too much hassle, even without a configuration utility or strong guidance /lots of work from their distro. > > I do that often. You should see my nginx Ebuild. It's the same here. > The original Ebuild is just plain wrong. But hey... I am to bored to > fight with people in the b.g.o about obvious things. I use the Ebuild > for me and I know that is right (I specifically asked the original > author about configure options and his response confirmed me that the > current Ebuild for nginx is not 100% correct). Today I would probably > to the same with the DSPAM Ebuild. I would rewrite it and NOT submit > it to b.g.o. > > Don't get me wrong. I love Gentoo but some things are just not the > way it should be. You could now ask yourself who the hell I am to > complain about Gentoo and say what is right and what is wrong? You > are right. > I ran into some of these issues also, but maybe I'm not so harsh about it as you are (yet). Still I love Gentoo as a platform. -- Regards, Tom signature.asc Description: OpenPGP digital signature -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Dspam-user mailing list Dspam-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspam-user
Re: [Dspam-user] DSPAM 3.9.0 BETA 4
Original-Nachricht
> Datum: Mon, 09 Nov 2009 22:48:30 +0100
> Von: Tom Hendrikx
> An: Steve
> CC: dspam-user@lists.sourceforge.net
> Betreff: Re: [Dspam-user] DSPAM 3.9.0 BETA 4
> Steve wrote:
> >>>> 'My ebuild' is based upon the one in a sf bug [1] which is
> >>>> obviously based on he work on portage, which again is yours. IMHO
> >>>> the ebuild is far too complicated to maintain properly,
> >>>>
> >>> It's not that complicated. The whole pre-install configuration is
> >>> pretty logical. The post-install configuration is storage dependent
> >>> but the flow of the script is logical.
> >>>
> >> I've written some ebuilds and my share of shell scripts, and I disagree
> >> with you :)
> >>
> > Good! I like when people disagree. :)
> > So where and why do you disagree? What can we do better? What can we rip
> out? What can we replace? How can we minimize the code without breaking
> it?
>
> As I mentioned, I think we should rip out all the stuff that tries to do
> the configuration. This holds for both the sed stuff during install, as
> for the post-install script. IMHO we should ship an external utility
> that does all this, and let the ebuild ship the stock configuration file.
>
> The "USE flag to configure options" logic should ideally be the only
> fancy code block in an ebuild. All the rest should ideally be resolved
> 'upstream', f.i. in dspams 'make install'. Since we're upstream,
> submitting a patch upstream is trivial (writing it is something else).
> This would f.i. mean to install helper sql scripts.
>
You miss one point: Everyone and his dog think they can package the product
better. Let's look for example at Debian: They break up the configuration in
peaces and have one part in dspam.conf while having another part some where
external.
And now just think about how many different distros are there and other OS that
do the same. And now try to bring one universal tool helping to configure all
those DSPAM installations. Good look doing that!
It's not easy. Believe it or not.
At the time when I wrote that configure part for the Ebuild, every one in the
Gentoo community was crying out loud how hard it is to configure DSPAM. I could
not hear any more those complains so I did not wanted to repeat the same and
again the same message/instructions on the Gentoo forum. That was one of the
reasons I rewrote the Ebuild.
I do that often. You should see my nginx Ebuild. It's the same here. The
original Ebuild is just plain wrong. But hey... I am to bored to fight with
people in the b.g.o about obvious things. I use the Ebuild for me and I know
that is right (I specifically asked the original author about configure options
and his response confirmed me that the current Ebuild for nginx is not 100%
correct). Today I would probably to the same with the DSPAM Ebuild. I would
rewrite it and NOT submit it to b.g.o.
Don't get me wrong. I love Gentoo but some things are just not the way it
should be. You could now ask yourself who the hell I am to complain about
Gentoo and say what is right and what is wrong? You are right. But let me
illustrate one example:
Install a system and wait some weeks. Then go ahead and just reinstall all the
same packages with exactly the same version and revision as you did weeks ago
(after doing first a emerge --sync). And now tell me that you will never ever
see a configuration option changed after you reinstalled whole world. I can
tell you right now that you will see changes. And this is absolutely a "no go".
This should never ever happen. New configuration should automatically lead to a
new revision. But not in Gentoo land. They change things all the time without
bumping a revision. How the hell is one supposed to to quality assurance in
such an environment?
And this is just one example. I could go on and post you many, many more.
> >> I'm no good with C or dialog,
> >>
> > Dialog is ultra easy. If you know Shell programming then dialog should
> not be an issue for you.
> >
> > A simple dialog for choosing the storage backend:
> >
> > dialog --backtitle "DSPAM storage backend" --radiolist "Select DSPAM
> storage backend to use:" 10 40 4 $(dsbc=0;for dsb in $(dspam --version|sed -n
> "s:,: :g;s:.*\-\with\-storage\-driver=\([^']*\)'.*:\1:gp");do let
> dsbc+=1;echo -ne ${dsbc} ${dsb} $([ ${dsbc} -eq 1 ] && echo "on" || echo
> "off")"
> ";done)
> > --
> >
> Looks easy enough, I'll give it a go :)
>
> >>>> Maybe we can take the gentoo-specifi
Re: [Dspam-user] DSPAM 3.9.0 BETA 4
Steve wrote:
'My ebuild' is based upon the one in a sf bug [1] which is
obviously based on he work on portage, which again is yours. IMHO
the ebuild is far too complicated to maintain properly,
>>> It's not that complicated. The whole pre-install configuration is
>>> pretty logical. The post-install configuration is storage dependent
>>> but the flow of the script is logical.
>>>
>> I've written some ebuilds and my share of shell scripts, and I disagree
>> with you :)
>>
> Good! I like when people disagree. :)
> So where and why do you disagree? What can we do better? What can we rip out?
> What can we replace? How can we minimize the code without breaking it?
As I mentioned, I think we should rip out all the stuff that tries to do
the configuration. This holds for both the sed stuff during install, as
for the post-install script. IMHO we should ship an external utility
that does all this, and let the ebuild ship the stock configuration file.
The "USE flag to configure options" logic should ideally be the only
fancy code block in an ebuild. All the rest should ideally be resolved
'upstream', f.i. in dspams 'make install'. Since we're upstream,
submitting a patch upstream is trivial (writing it is something else).
This would f.i. mean to install helper sql scripts.
>> I'm no good with C or dialog,
>>
> Dialog is ultra easy. If you know Shell programming then dialog should not be
> an issue for you.
>
> A simple dialog for choosing the storage backend:
>
> dialog --backtitle "DSPAM storage backend" --radiolist "Select DSPAM storage
> backend to use:" 10 40 4 $(dsbc=0;for dsb in $(dspam --version|sed -n "s:,:
> :g;s:.*\-\with\-storage\-driver=\([^']*\)'.*:\1:gp");do let dsbc+=1;echo -ne
> ${dsbc} ${dsb} $([ ${dsbc} -eq 1 ] && echo "on" || echo "off")" ";done)
> --
>
Looks easy enough, I'll give it a go :)
Maybe we can take the gentoo-specific talk off-list and try to get
something out that we can propose to gentoo devs for portage
inclusion. It would be nice to have beta4 as ~arch or ~arch-masked
in portage.
>>> Alin Năstac is probably loaded with work. Maybe if we move to RC then
>>> he could include a Ebuild? I think if you would post an Ebuild in
>>> g.b.o then he would add it to Portage? Should I do it?
>>>
>> It seems that your connections are better than mine, so go ahead.
>> As said, I'll send you some more ebuild-related stuff off-list.
>>
> Okay. I am going to post the next BETA/RC release in b.g.o and push it to CVS.
>
Great :)
--
Regards,
Tom
signature.asc
Description: OpenPGP digital signature
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july___
Dspam-user mailing list
Dspam-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspam-user
Re: [Dspam-user] DSPAM 3.9.0 BETA 4
Original-Nachricht
> Datum: Mon, 09 Nov 2009 21:31:02 +0100
> Von: Tom Hendrikx
> An: Steve
> CC: dspam-user@lists.sourceforge.net
> Betreff: Re: [Dspam-user] DSPAM 3.9.0 BETA 4
> Steve wrote:
> >
> >>> insinto "${DSPAM_CONFDIR}" newins
> >>> src/tools.pgsql_drv/pgsql_objects.sql pgsql_objects.sql && +
> >>> newins src/tools.pgsql_drv/purge-pe.sql pgsql_pe-purge.sql &&
> >>>
> >> This file is dead in the beta4 and git source.
> >>
> > Nope. It's right that is not packaged in BETA4 but it's wrong
> > regarding GIT. The file is there and will be again included in newer
> > versions.
> >
> Hm, I missed git then. I'll change the ebuild:)
>
> >> 'My ebuild' is based upon the one in a sf bug [1] which is
> >> obviously based on he work on portage, which again is yours. IMHO
> >> the ebuild is far too complicated to maintain properly,
> >>
> > It's not that complicated. The whole pre-install configuration is
> > pretty logical. The post-install configuration is storage dependent
> > but the flow of the script is logical.
> >
> I've written some ebuilds and my share of shell scripts, and I disagree
> with you :)
>
Good! I like when people disagree. :)
So where and why do you disagree? What can we do better? What can we rip out?
What can we replace? How can we minimize the code without breaking it?
> But I think this is more matter of taste, and ultimately a
> decision of the person maintaining it. And if we need someone to
> maintain it in portage, make it as easy as possible to him (or her).
>
> >> IMHO the auto-configure stuff (emerge --config and various sed
> >> stuff during src_install()) should be removed from the ebuild. It
> >> would be a lot more useful when it is pulled out of the ebuild and
> >> into a separate script, that can be distributed with dspam
> >> (dspam-setup?). In stead of relying on USE flags as input for which
> >> backends to support, the script could be adapted during 'make',
> >> based on configure options.
> >>
> > I wanted to make one that uses GNU dialog to ask some questions and
> > then based on the responses do the whole setup/installation. But so
> > far I had not time to do that. But I think that something like that
> > could be beneficial to all DSPAM users. Unfortunately not much people
> > invest time in helping driving DSPAM ahead. There are many places
> > users could help beside developing on the core of DSPAM. I wounder
> > why no one is doing small but important things like that?
> >
>
> I'm no good with C or dialog,
>
Dialog is ultra easy. If you know Shell programming then dialog should not be
an issue for you.
A simple dialog for choosing the storage backend:
dialog --backtitle "DSPAM storage backend" --radiolist "Select DSPAM storage
backend to use:" 10 40 4 $(dsbc=0;for dsb in $(dspam --version|sed -n "s:,:
:g;s:.*\-\with\-storage\-driver=\([^']*\)'.*:\1:gp");do let dsbc+=1;echo -ne
${dsbc} ${dsb} $([ ${dsbc} -eq 1 ] && echo "on" || echo "off")" ";done)
--
> but I can give it a try in shell, similar
> to the ebuild. I have your script as a guide.
>
> >> Maybe we can take the gentoo-specific talk off-list and try to get
> >> something out that we can propose to gentoo devs for portage
> >> inclusion. It would be nice to have beta4 as ~arch or ~arch-masked
> >> in portage.
> >>
> > Alin Năstac is probably loaded with work. Maybe if we move to RC then
> > he could include a Ebuild? I think if you would post an Ebuild in
> > g.b.o then he would add it to Portage? Should I do it?
> >
> It seems that your connections are better than mine, so go ahead.
> As said, I'll send you some more ebuild-related stuff off-list.
>
Okay. I am going to post the next BETA/RC release in b.g.o and push it to CVS.
> --
> Regards,
> Tom
>
Steve
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
Dspam-user mailing list
Dspam-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspam-user
Re: [Dspam-user] DSPAM 3.9.0 BETA 4
Steve wrote:
>
>>> insinto "${DSPAM_CONFDIR}" newins
>>> src/tools.pgsql_drv/pgsql_objects.sql pgsql_objects.sql && +
>>> newins src/tools.pgsql_drv/purge-pe.sql pgsql_pe-purge.sql &&
>>>
>> This file is dead in the beta4 and git source.
>>
> Nope. It's right that is not packaged in BETA4 but it's wrong
> regarding GIT. The file is there and will be again included in newer
> versions.
>
Hm, I missed git then. I'll change the ebuild:)
>> 'My ebuild' is based upon the one in a sf bug [1] which is
>> obviously based on he work on portage, which again is yours. IMHO
>> the ebuild is far too complicated to maintain properly,
>>
> It's not that complicated. The whole pre-install configuration is
> pretty logical. The post-install configuration is storage dependent
> but the flow of the script is logical.
>
I've written some ebuilds and my share of shell scripts, and I disagree
with you :) But I think this is more matter of taste, and ultimately a
decision of the person maintaining it. And if we need someone to
maintain it in portage, make it as easy as possible to him (or her).
>> IMHO the auto-configure stuff (emerge --config and various sed
>> stuff during src_install()) should be removed from the ebuild. It
>> would be a lot more useful when it is pulled out of the ebuild and
>> into a separate script, that can be distributed with dspam
>> (dspam-setup?). In stead of relying on USE flags as input for which
>> backends to support, the script could be adapted during 'make',
>> based on configure options.
>>
> I wanted to make one that uses GNU dialog to ask some questions and
> then based on the responses do the whole setup/installation. But so
> far I had not time to do that. But I think that something like that
> could be beneficial to all DSPAM users. Unfortunately not much people
> invest time in helping driving DSPAM ahead. There are many places
> users could help beside developing on the core of DSPAM. I wounder
> why no one is doing small but important things like that?
>
I'm no good with C or dialog, but I can give it a try in shell, similar
to the ebuild. I have your script as a guide.
>> Maybe we can take the gentoo-specific talk off-list and try to get
>> something out that we can propose to gentoo devs for portage
>> inclusion. It would be nice to have beta4 as ~arch or ~arch-masked
>> in portage.
>>
> Alin Năstac is probably loaded with work. Maybe if we move to RC then
> he could include a Ebuild? I think if you would post an Ebuild in
> g.b.o then he would add it to Portage? Should I do it?
>
It seems that your connections are better than mine, so go ahead.
As said, I'll send you some more ebuild-related stuff off-list.
--
Regards,
Tom
signature.asc
Description: OpenPGP digital signature
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july___
Dspam-user mailing list
Dspam-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspam-user
Re: [Dspam-user] DSPAM 3.9.0 BETA 4
Original-Nachricht
> Datum: Mon, 09 Nov 2009 20:33:11 +0100
> Von: Tom Hendrikx
> An: Steve
> CC: dspam-user@lists.sourceforge.net
> Betreff: Re: [Dspam-user] DSPAM 3.9.0 BETA 4
> Steve wrote:
> > Hallo Tom,
> >
> hi! :)
>
Hello,
> > I did a quick diff against my 3.9.0 Ebuild and this is the result
> > (keep in mind that my Ebuild is downloading from GIT):
> >
> There is also a git ebuild in the overlay (dspam-.ebuild), but its
> content is exactly the same as the beta4 one, except for the parts where
> source is retrieved (tarball vs git repo).
>
> >
> > -COMMON_DEPEND="clamav? ( app-antivirus/clamav ) -
> > ldap? ( net-nds/openldap ) +COMMON_DEPEND="clamav? (
> > >=app-antivirus/clamav-0.90.2 ) + ldap? (
> > >=net-nds/openldap-2.2 )
> >
> The mentioned versions are since long no more available on gentoo.
>
Yes. That's right. But you never know who has what version active and it's
really not needed to have a >= 2.3 dependency just because Gentoo does not
anymore have the older Ebuilds in Portage.
> > pkg_setup() {
> > + # Delete these lines some time after -r6 removal
> > + if has_version "<=mail-filter/dspam-3.8.0-r6" &&
> >
> >
> See the comment, 3.8.0-r6 is dead for ages.
>
Right. But see again my comment above.
> > + # due to parallel build failures
> > + filter-flags -j[0-9]*
> >
> This is a workaround for an already fixed bug
> (http://sourceforge.net/tracker/?func=detail&aid=2811139&group_id=250683&atid=1126467)
>
Correct.
> > +src_compile() { + emake -j1 CC="$(tc-getCC)" || die "emake
> > failed" +} +
> >
> This seems a double for above bugfix...
>
Yes. That one is fixed.
> > insinto "${DSPAM_CONFDIR}"
> > newins src/tools.pgsql_drv/pgsql_objects.sql pgsql_objects.sql &&
> > + newins src/tools.pgsql_drv/purge-pe.sql pgsql_pe-purge.sql &&
> >
> This file is dead in the beta4 and git source.
>
Nope. It's right that is not packaged in BETA4 but it's wrong regarding GIT.
The file is there and will be again included in newer versions.
> > +pkg_preinst() {
> > + # Delete these lines some time after -r6 removal
> > + if has_version "<=mail-filter/dspam-3.8.0-r6" ; then
> >
> >
> Again, see the comment.
>
> > The whole configure part needs to be changed (from my view point).
> > When I did the configure part for the stock Gentoo Ebuild (yes. I
> > have written it) then I used "[[" for most if statements. That is
> > fine but breaks on ulibc and should not be used. It's not needed.
> >
> True, consider all of [[ stuff changed.
>
Thanks.
> > The second issue is the external lookup. While you are right that
> > LDAP queries could be substituted with external lookup, it is wrong
> > to have a dependency to OpenLDAP for external lookup. The external
> > lookup module could be used WITHOUT openldap. In fact I have changed
> > the make file to search for OpenLDAP and activate LDAP functionality
> > in external lookup if it finds OpenLDAP.
> >
> 'My ebuild' is based upon the one in a sf bug [1] which is obviously
> based on he work on portage, which again is yours. IMHO the ebuild is
> far too complicated to maintain properly,
>
It's not that complicated. The whole pre-install configuration is pretty
logical. The post-install configuration is storage dependent but the flow of
the script is logical.
> so I just made sure that the
> ebuild from the bug worked for the tarballs. You're right about the ldap
> stuff, also changed that. Consider most of the other (uncommented)
> changes also applied.
>
> [1]:http://sourceforge.net/tracker/index.php?func=detail&aid=2802205&group_id=250683&atid=1126467
>
> IMHO the auto-configure stuff (emerge --config and various sed stuff
> during src_install()) should be removed from the ebuild. It would be a
> lot more useful when it is pulled out of the ebuild and into a separate
> script, that can be distributed with dspam (dspam-setup?). In stead of
> relying on USE flags as input for which backends to support, the script
> could be adapted during 'make', based on configure options.
>
I wanted to make one that uses GNU dialog to ask some questions and then based
on the responses do the whole setup/installation. But so far I had not time to
do that. But I think that something like that could be beneficial to all DSPAM
users. Unfortunately not much people inves
Re: [Dspam-user] DSPAM 3.9.0 BETA 4
Steve wrote:
> Hallo Tom,
>
hi! :)
> I did a quick diff against my 3.9.0 Ebuild and this is the result
> (keep in mind that my Ebuild is downloading from GIT):
>
There is also a git ebuild in the overlay (dspam-.ebuild), but its
content is exactly the same as the beta4 one, except for the parts where
source is retrieved (tarball vs git repo).
>
> -COMMON_DEPEND="clamav? ( app-antivirus/clamav ) -
> ldap? ( net-nds/openldap ) +COMMON_DEPEND="clamav? (
> >=app-antivirus/clamav-0.90.2 ) + ldap? (
> >=net-nds/openldap-2.2 )
>
The mentioned versions are since long no more available on gentoo.
> pkg_setup() {
> + # Delete these lines some time after -r6 removal
> + if has_version "<=mail-filter/dspam-3.8.0-r6" &&
>
>
See the comment, 3.8.0-r6 is dead for ages.
> + # due to parallel build failures
> + filter-flags -j[0-9]*
>
This is a workaround for an already fixed bug
(http://sourceforge.net/tracker/?func=detail&aid=2811139&group_id=250683&atid=1126467)
> +src_compile() { + emake -j1 CC="$(tc-getCC)" || die "emake
> failed" +} +
>
This seems a double for above bugfix...
> insinto "${DSPAM_CONFDIR}"
> newins src/tools.pgsql_drv/pgsql_objects.sql pgsql_objects.sql &&
> + newins src/tools.pgsql_drv/purge-pe.sql pgsql_pe-purge.sql &&
>
This file is dead in the beta4 and git source.
> +pkg_preinst() {
> + # Delete these lines some time after -r6 removal
> + if has_version "<=mail-filter/dspam-3.8.0-r6" ; then
>
>
Again, see the comment.
> The whole configure part needs to be changed (from my view point).
> When I did the configure part for the stock Gentoo Ebuild (yes. I
> have written it) then I used "[[" for most if statements. That is
> fine but breaks on ulibc and should not be used. It's not needed.
>
True, consider all of [[ stuff changed.
> The second issue is the external lookup. While you are right that
> LDAP queries could be substituted with external lookup, it is wrong
> to have a dependency to OpenLDAP for external lookup. The external
> lookup module could be used WITHOUT openldap. In fact I have changed
> the make file to search for OpenLDAP and activate LDAP functionality
> in external lookup if it finds OpenLDAP.
>
'My ebuild' is based upon the one in a sf bug [1] which is obviously
based on he work on portage, which again is yours. IMHO the ebuild is
far too complicated to maintain properly, so I just made sure that the
ebuild from the bug worked for the tarballs. You're right about the ldap
stuff, also changed that. Consider most of the other (uncommented)
changes also applied.
[1]:http://sourceforge.net/tracker/index.php?func=detail&aid=2802205&group_id=250683&atid=1126467
IMHO the auto-configure stuff (emerge --config and various sed stuff
during src_install()) should be removed from the ebuild. It would be a
lot more useful when it is pulled out of the ebuild and into a separate
script, that can be distributed with dspam (dspam-setup?). In stead of
relying on USE flags as input for which backends to support, the script
could be adapted during 'make', based on configure options.
Maybe we can take the gentoo-specific talk off-list and try to get
something out that we can propose to gentoo devs for portage inclusion.
It would be nice to have beta4 as ~arch or ~arch-masked in portage.
--
Regards,
Tom
signature.asc
Description: OpenPGP digital signature
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july___
Dspam-user mailing list
Dspam-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspam-user
Re: [Dspam-user] DSPAM 3.9.0 BETA 4
Original-Nachricht
> Datum: Sun, 08 Nov 2009 00:00:22 +0100
> Von: Tom Hendrikx
> An: dspam-user@lists.sourceforge.net
> Betreff: Re: [Dspam-user] DSPAM 3.9.0 BETA 4
Hallo Tom,
> On 02/11/09 00:04, Stevan Bajić wrote:
> > The DSPAM team is happy to announce another beta release! DSPAM 3.9.0
> BETA 4.
> >
> > We would appreciate if packagers/ports maintainers could package this
> release ...
> >
> > The DSPAM Team
> >
>
> I have updated the ebuild in my gentoo overlay to BETA 4. Also the git
> (live) ebuild has been updated to work again. I've been doing some
> testing on amd64 (compile only) and x86 (compile and run). Any feedback
> is welcome of course.
>
> The ebuilds are available at:
> https://svn.whyscream.net/whyscream-overlay/testing/mail-filter/dspam/
>
I did a quick diff against my 3.9.0 Ebuild and this is the result (keep in mind
that my Ebuild is downloading from GIT):
theia ~ # diff -Naur dspam-3.9.0_beta4.ebuild
/mnt/gentoo.overlay/mail-filter/dspam/dspam-3.9.0.ebuild
--- dspam-3.9.0_beta4.ebuild2009-11-07 16:28:20.0 +0100
+++ /mnt/gentoo.overlay/mail-filter/dspam/dspam-3.9.0.ebuild2009-11-02
22:28:21.756567529 +0100
@@ -3,27 +3,25 @@
# $Header: Exp $
EAPI="2"
+EGIT_PROJECT="dspam"
+EGIT_REPO_URI="git://dspam.git.sourceforge.net/gitroot/dspam/dspam"
+EGIT_BRANCH="master"
WANT_AUTOCONF="latest"
WANT_AUTOMAKE="latest"
-inherit eutils autotools multilib flag-o-matic versionator
-
-MY_PV="`echo $(replace_version_separator 3 '-')| tr [:lower:] [:upper:]`"
-MY_P="${PN}-${MY_PV}"
-SRC_URI="mirror://sourceforge/dspam/${MY_P}.tar.gz"
-S="${WORKDIR}/${MY_P}"
+inherit eutils autotools multilib flag-o-matic git
DESCRIPTION="A statistical-algorithmic hybrid anti-spam filter"
HOMEPAGE="http://dspam.nuclearelephant.com/";
LICENSE="GPL-2"
SLOT="0"
KEYWORDS="~alpha amd64 ~ppc sparc x86"
-IUSE="clamav daemon ldap mysql postgres sqlite syslog \
+IUSE="clamav daemon external-lookup ldap mysql postgres sqlite syslog \
large-domain virtual-users user-homedirs \
debug debug-bnr debug-verbose"
-COMMON_DEPEND="clamav? ( app-antivirus/clamav )
- ldap? ( net-nds/openldap )
+COMMON_DEPEND="clamav? ( >=app-antivirus/clamav-0.90.2 )
+ ldap? ( >=net-nds/openldap-2.2 )
mysql? ( virtual/mysql )
sqlite? ( =dev-db/sqlite-3* )"
DEPEND="${COMMON_DEPEND}
@@ -40,19 +38,41 @@
DSPAM_MODE=2511
pkg_setup() {
+ # Delete these lines some time after -r6 removal
+ if has_version "<=mail-filter/dspam-3.8.0-r6" &&
+ built_with_use "<=mail-filter/dspam-3.8.0-r6" sqlite &&
+ grep -q "^StorageDriver.*libsqlite_drv.so"
"${ROOT}${DSPAM_CONFDIR}"/dspam.conf; then
+ eerror "Sqlite2 support has been removed. Please
upgrade your database to sqlite3"
+ eerror "and select libsqlite3_drv.so in dspam.conf
before proceeding with update."
+ die "sqlite-2 no longer supported"
+ fi
+
local egid euid
# Need a UID and GID >= 1000, for being able to use suexec in apache
for euid in $(seq 1000 5000 ) ; do
- [[ -z $(egetent passwd ${euid}) ]] && break
+ [ -z "$(egetent passwd ${euid})" ] && break
done
for egid in $(seq 1000 5000 ) ; do
- [[ -z $(egetent group ${egid}) ]] && break
+ [ -z "$(egetent group ${egid})" ] && break
done
enewgroup dspam ${egid}
enewuser dspam ${euid} -1 "${DSPAM_HOMEDIR}" dspam,mail
}
+src_prepare() {
+ AT_M4DIR="${S}/m4"
+ eautoreconf
+
+ # Fix SQLite3 driver
+ # epatch "${FILESDIR}"/${P}-sqlite3_driver_fixes.patch
+}
+
+src_unpack() {
+ git_src_unpack
+ cd "${S}"
+}
+
src_configure() {
local myconf=""
@@ -75,6 +95,7 @@
fi
local STORAGE="hash_drv"
+
# select storage driver
if use sqlite ; then
STORAGE="${STORAGE},sqlite3_drv"
@@ -89,6 +110,17 @@
myconf="${myconf} --with-pgsql-includes=/usr/include/postgresql"
myconf="${myconf} --with-pgsql-libraries=/usr/$(get_libdir)"
fi
+ if [ "${STORAGE:0:1}" == "," ] ; then
+ STORAGE="${STORAGE:1}"
+ fi
+
+ if use debug ; then
+ append-flags -g2 -ggdb
+
Re: [Dspam-user] DSPAM 3.9.0 BETA 4
On 02/11/09 00:04, Stevan Bajić wrote: > The DSPAM team is happy to announce another beta release! DSPAM 3.9.0 BETA 4. > > We would appreciate if packagers/ports maintainers could package this release > ... > > The DSPAM Team > I have updated the ebuild in my gentoo overlay to BETA 4. Also the git (live) ebuild has been updated to work again. I've been doing some testing on amd64 (compile only) and x86 (compile and run). Any feedback is welcome of course. The ebuilds are available at: https://svn.whyscream.net/whyscream-overlay/testing/mail-filter/dspam/ -- Regards, Tom signature.asc Description: OpenPGP digital signature -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Dspam-user mailing list Dspam-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspam-user
Re: [Dspam-user] DSPAM 3.9.0 BETA 4
Le lundi 02 novembre 2009 à 00:04 +0100, Stevan Bajić a écrit : > The DSPAM team is happy to announce another beta release! DSPAM 3.9.0 > BETA 4. > > The source tarball can be downloaded from the downloads section at > Sourceforge [1]. > > If you are running any of the older BETA or ALPHA releases then you > can just upgrade to BETA 4. There are no compatibility issues compared > to older ALPHA or older BETA releases. Users using 3.8.0 or older can > upgrade to BETA 4 by following the steps mentioned in the UPGRADING > file. > > A detailed changelog is available inside the tarball. Most changes are > bug fixes, stability enhancements or enhancements to the > documentation. New in BETA 4 is "osb" for PValue. Should you use OSB > as tokenizer then you can switch your current PValue to "osb" without > loosing any tokens or scarifying compatibility. "osb" for PValue > introduces weighted probability values for the OSB tokenizer and > should speedup learning and increase accuracy. Give it a try and let > us know how well or bad "osb" for PValue performed on your setup. > > We would appreciate if packagers/ports maintainers could package this > release so as many people as possible can try this release on their > systems without too much effort. If you made a package of this > release, then please email us a link to your webspace so that we can > compile a list of operating systems with packages available on our > website. The unofficial packages for Debian Lenny (both amd64 and i386) are now available from my personal repository: http://packages.kirya.net Cheers, Julien -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Dspam-user mailing list Dspam-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspam-user
