DSPAM 3.4 Preview Release 1 has been released. I took the opportunity to fix a few ebuild issues during the version bump; diff to be attached below.
Created attachment 53019 [details, diff] Ebuild diff from 3.4_rc2 to 3.4_p1 Version bump from 3.4 RC2 to 3.4 PR1. Also, issues from the following bugs have been addressed: http://bugs.gentoo.org/show_bug.cgi?id=81345 http://bugs.gentoo.org/show_bug.cgi?id=78727 Namely: sqlite3 support was added net-mail was changed to mail-filter in the einfo obsolete (and commented) configure options were removed along with adding more descriptive comments regarding others dspam_stats was made 4755 so dspam-web will work notification messages are copied I didn't change the multiple-DB testing, but feel free if you find it necessary.
Hi, Cool!! I've added this to CVS. I've always wondered why dspam_web did not work . :) Ciao ST Lim
Created attachment 53150 [details] mail-filter/dspam/files/dspam.cron New dspam.cron fixing some old problems with config files location and SQL scripts path.
Created attachment 53154 [details] mail-filter/dspam/dspam-3.4_pre1.ebuild I know, I know... it looks like I am never satisfied with the DSPAM ebuild. But even the new one posted here (the _p1) has problems. Allow me quickly to summarize some issues: - The new DSPAM has the possibility to use DSPAM as an deamon. The ebuild does not build and does not install the deamon. - The DSPAM documentation does mention the preference extensions to be only available for MySQL and PostgreSQL (for now). The old ebuild and the new one still do enable the preference extensions in Oracle (it does not hurt however). - The Oracle part has a line in the ebuild with the text "--with-oracle-version=MAJOR". This is going to fail on every client who has the Oracle USE flag enabled because "--with-oracle-version=MAJOR" is not an valid option or command (but it is a valid ./configure command) - The old and the new ebuild mess up the CONFIG_PROTECT_MASK variable and every configuration in the HOMEDIR and DATADIR is OVERWRITTEN with the ebuild. This is wrong and should be changed to NOT overwrite the HOMEDIR and DATADIR. - The old and the new ebuild fail to create a empty system.log in the LOGDIR. Normaly DSPAM does log into /var/log but if you have an system.log in your HOMEDIR, then DSPAM will use that. Which does blow /etc/mail/dspam up for nothing (I have LVM2 on my system and / is only 100MB. After using the ebuild my / was all the time full. I never realized that DSPAM did produce that system.log in /etc/mail/dspam. Moving it out to /var/log/dspam.log and adding a symlink to /etc/mail/dspam/dpsam.log solves this issue). - The old and the new ebuild do mess up the currently installed dspam.conf. New entries from the source of DSPAM are never installed on the system if the user already has a DSPAM installation. - The new ebuild does take care of SQLite 3 but does not install the purge script for SQLite (if only sqlite3 is in the USE flags) I have attached the ebuild I am using to build DSPAM since 3.4 beta. Currently I am runing pre1 of DSPAM in deamon (Client/Server) mode with Postfix. The attached ebuild does build the deamon for DSPAM and installs a Gentoo init.d script for using the deamon. I would have attached earlier my new ebuild into bugs.gentoo.org, but my old entry was sitting there for weeks and it seamed to me that nobody cared about it anymore or nobody was using DSPAM with Gentoo. Anyway... today I got a notification about the new ebuild and took the time now to add my new revision of the ebuild into bugs.gentoo.org. Much of the database setup is now more simplified and does not prompt you serval times for your password. What I don't have enabled in this ebuild is the possibility to use/install/configure the database on a remote system. For now the DSPAM database needs to be on the same system as the DSPAM installation. I can easy add that feature, since I did the same with SQLgrey and have the code already handy. I hope nobody is mad at me for posting such a big message here? cheers SteveB
Created attachment 53155 [details] mail-filter/dspam/files/dspam.rc
Looks like my comments are not welcome. The various errors in the dspam ebuild are still in portage and are even in the 3.4.0 ebuild.
Your comments are certainly welcome - I personally appreciate all developments in this package. You might want to file a separate bug though, especially for changes of that magnitude. When a bug has unrelated (to the original matter) material, it tends to be overlooked - especially after the bug is marked resolved and fixed. If you file a new bug I'm sure it'd get more attention.