Le samedi 17 avril 2010 à 00:46 +0200, Stevan Bajić a écrit :
> On Fri, 16 Apr 2010 21:38:06 +0200
> Julien Valroff <jul...@kirya.net> wrote:
>
> > You can check the current source packages at
> > http://packages.kirya.net/debian/pool/main/d/dspam/dspam_3.9.0
> > +git20100416-1.debian.tar.gz
> >
> Okay. Quickly looking over the scripts (not 100% understanding how
> things are glued together) I have the following feedback:
>
> cron scripts for purging use additional tools that are not referenced
> by the Debian DSPAM package:
> * awk
> * grep
> * umask
> * rm
All of them are 'base' package, which are required and automatically
installed on all Debian systems (Essential: yes - Priority: required),
hence packages do not need to depend on them.
> IMHO it would be easier for you guys to use the script in the contrib
> directory as it does all the magic needed for maintenance (purging
> tokens, purging user logs, purging system logs, etc) in just one
> script.
You are 100% right. I will have a look at it, but might need help to
correclty integrate this script to Debian.
I just have to check the current status of the GNU AGPL v3 license in
Debian, as even though it was agreed it was considered as DFSG free some
time ago [0], I also remember there were some people against this
decision, and it is not included in the copyright DEP5, nor in the
common licenses.
For my own knowledge, would you please explain why you have chosen this
license for this script?
> DSPAM build system btw needs sed in order to work. I have not seen any
> dependency to sed.
Same as above.
> libdspam7-drv-mysql.cron.daily could use some additional code to avoid
> problems if the user has added two identical entries for certain MySQL
> values. So just adding " | head -n 1" after awk should do the trick.
> The same applies to libdspam7-drv-sqlite3.cron.daily.
Thanks, I have fixed that in both scripts as a temporary workaround to
dspam_maintenance.
> libdspam7-drv-pgsql.cron.daily is missing. Should I code one for you?
I do not think it is necessary if the packages all use the
dspam_maintenance script for all the backends, do you confirm it will
replace all the existing scripts?
I haven't yet tested dspam_maintenance.sh, but I think the best is to
include it in the main dspam package (with the hash driver). However, I
see there's a command line option to purge all backends, what happens if
one fails (ie. I use the MySQL driver, what will happen when it comes to
the pgsql purge?).
Also, the sql purge files are included in the respective packages, can I
specify several DSPAM_PURGE_SCRIPT_DIR?
> All of the scripts don't have code to run dspam_logrotate to purge the
> user log and the system log. IMHO that should be included into the
> purging scripts. Or a separate cron file could be created that just
> does log maintenance.
This would also be fixed if switching to dspam_mainenance, right?
> README.source has a typo in it. The second title should be "b." and
> not "b-". Or am I missing something?
>
Fixed.
> Is the dspam package not missing a dependency to syslog? Is that
> already installed by default on Debian?
Yes, the package is "important".
> File "rules" has old and not used option: --enable-signature-headers
Fixed.
> If you want to automate the creation of the splitted config files then
> you could use something like this:
> ----------------------
> for foo in ExtLookup=extlookup SQLite=sqlite MySQL=mysql
> PostgreSQL=pgsql;
> do
> sed -n -e "/^# \-\- ${foo%=*} \-\-[\t ]*$/,/^# \-\- [^-]\{1,99
> \}\-\-[\t ]*$/p" src/dspam.conf.in > debian/config/${foo#*=}.conf;
> sed -i -e '$d' debian/config/${foo#*=}.conf;
> done;
> ----------------------
Great, that would indeed be perfect!
However, it does only seem to work for the ExtLookup options (and also
include the # -- Profiles -- line)
Would you please explain this script as I am unfortunately not able to
fix it!
> I would say that the Debian DSPAM package is in good shape. I don't
> see anything significantly wrong with it.
That's what I thought, but you have already noticed a lot of things
which need to be improved/fixed, and this is very important.
I think I will work on these improvements ASAP, test the packages myself
in a virtual environment, then upload to my personal repo to get a
slightly larger board of testers, then request the package to be
uploaded to the official archive, targeted to the experimental
distribution (this will allow more people test the packages, and after
some time, I will be glad to upload it to the unstable distribution so
that it can hopefully be part of the next stable version).
This will however (I think) have to wait until 3.9.1 is released.
> btw: You can delete "006_clean-manpages.diff" as I have now updated
> the man pages based on the stuff you had in that diff file (with a
> slightly modified libdspam.3).
Great, thanks!
I cannot reach the git repo for now, will check this once SF is online
again.
[0] http://lists.debian.org/debian-legal/2008/11/msg00097.html
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Dspam-devel mailing list
Dspam-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspam-devel
