original bug references bug 135917 - status closed bug 140649 - status duplicate of 135917 First off, a big thanks to everyone who has contributed to getting dspam into portage and improving the ebuilds. Good to see it's finally gettin some love! I've been using dspam for a while now. Had to manually install dspam because I had problems with the ebuilds and I didn't like the defaults. I decided to give the ebuild another shot, and still have multiple issues. Don't worry, I won't gripe without supplying a fix ;) ===================================================================== 1. The command "dspam --version" doesn't display "Configuration parameters" correctly ===================================================================== With dspam-3.6.8 Configuration parameters: /usr/share/config.site /usr/etc/config.site It should display: Configuration parameters: --prefix=/usr --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --enable-long-usernames --enable-syslog --enable-domain-scale --enable-debug --enable-verbose-debug --enable-bnr-debug --enable-preferences-extension --with-mysql-includes=/usr/include/mysql --with-mysql-libraries=/usr/lib/mysql --with-storage-driver=mysql_drv --with-dspam-home=/var/spool/dspam --sysconfdir=/etc/mail/dspam --enable-daemon --disable-ldap --disable-clamav --with-dspam-group=dspam --with-dspam-home-group=dspam --with-logdir=/var/log/dspam --build=i686-pc-linux-gnu Now, with 3.6.8-r1 it displays: Configuration parameters: '--prefix=/usr' '--host=i686-pc-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib' '--enable-long-usernames' '--enable-syslog' '--enable-domain-scale' '--enable-debug' '--enable-verbose-debug' '--enable-bnr-debug' '--enable-preferences-extension' '--with-mysql-includes=/usr/include/mysql' '--with-mysql-libraries=/usr/lib/mysql' '--with-storage-driver=mysql_drv' '--with-dspam-home=/var/spool/dspam' '--sysconfdir=/etc/mail/dspam' '--enable-daemon' '--disable-ldap' '--disable-clamav' '--with-dspam-group=dspam' '--with-dspam-home-group=dspam' '--with-logdir=/var/log/dspam' '--build=i686-pc-linux-gnu' 'build_alias=i686-pc-linux-gnu' 'host_alias=i686-pc-linux-gnu' 'CFLAGS=-march=athlon-xp -O2 -msse2 -pipe' 'CXXFLAGS=-march=athlon-xp -O2 -msse2 -pipe' Compiling manually without the patches, the configure options are displayed correctly. The problem is a cascading issue with the patches. The patches: 02_all_link-dynamically.patch 03_all_clean-warnings.patch 13_all_txt-confdir.patch modify either Makefile.am or .m4 src files, requiring the ebuild to use eautoreconf function which results in a new configure script. Looks like the variable "CONFIG_SITE" never gets set in the newly regenerated configure script. (see attached patch) Patching the eautoreconf generated configure script AFTER eautoreconf runs with the attached patch and then recompiling results in the "Configuration paramaters" to be displyed correctly, ie no single quotes. I've tested it on both x86 and amd64 and the patch is applied sucessfully. ===================================================================== 2. Patches supplied by dspam-3.6.8.ebuild ===================================================================== The more of these patches I see, the more I'm starting to worry about their goodness... Most of the patches seem fairly minor except for one: 02_all_link-dynamically.patch Originally created for dspam-3.6.2 - either the config options of "--enable-shared" and "--enabled-static" were not available with that version of dspam or the author of the patch couldn't find them. dspam-3.6.8 # ./configure --help | less ... begin snip ... --enable-shared[=PKGS] build shared libraries [default=yes] --enable-static[=PKGS] build static libraries [default=yes] ... end snip ... Using the switch "--disable-static" will cause dspam to compile dynamically linked with no patchset. Even if the "02_all_link-dynamically.patch" is omitted from the patchset and "--diable-shared --enable static" are used, it doesnt seem to build statically when comparing the binaries sizes with an unpatched compile with the same options - its not even close! So it seems that the patchset is neutering the ability to build statically. What else are the patches unintentionally doing? Then there's the 14_all_autodetct-conf.patch that restores the "Configuration parameters" as mentioned above, but it does so with the options in single quotes. That's not the original design. Another one is the 12_all_logrotate-preserve-state.patch. Nothing wrong with it, but it's not the same as the one I found on the dspam mailing list. Tne one which JZ says will be included, but isn't :( I Propose a "debian-patchset" use flag. I'm probably not the only one who doesnt want them or need them. I also suggest that a CVS ebuild be created. If one wants the latest and greatest, get the new code from the source, not from year old patches. ===================================================================== 3. default config options ===================================================================== --enable-long-usernames Propose selectable/use flag and disabled by default --enable-domain-scale Propose scales should be selectable and have use flags. Default is small scale. Seperate optional use flags for large-scale or domain-scale --enable-syslog and "LOGDIR=/var/log/dspam" syslog should be selectable/use flag. Propose disable syslog by default Personally I like the default of /var/spool/dspam/log, but we'll leave it at /var/log/dspam. --disable-static added use flag that disables static in default setup. dspam by default is --enable-shared --enable-static. ===================================================================== 4. non-default options ===================================================================== --enable-debug shouldn't enable ALL debugging options. Docs state that verbose implies debug. So if verbose is used, debug shouldn't be set. Propose options should have their own use flags: debug debug-verbose (is known to cause problems) debug-bnr sanity check to prevent both debug and verbose from being selected ===================================================================== 5. Default permissions for dspam binary ===================================================================== dspam binary /usr/bin/dspam should be install as default with perms 2510 (r-x--s--) as default. If world executable is desired,create a use (world-exec) flag for option and assign perms "--with-dspam-mode=2511" instead of chmod'ing it by default. ===================================================================== 6. Cosmetic/minor changes ===================================================================== Note: These changes are NOT in the attached patch or ebuild files. /etc/mail/dspam/ contains executable .sql files. Shouldn't they be read only? remove logrotate flag and use dspam_logrotate in dspam.cron AFAIK, suexec user and group min id's on stock gentoo system are # suexec2 -V -D AP_DOC_ROOT="/var/www" -D AP_GID_MIN=100 -D AP_HTTPD_USER="apache" -D AP_LOG_EXEC="/var/log/apache2/suexec_log" -D AP_SAFE_PATH="/usr/local/bin:/usr/bin:/bin" -D AP_SUEXEC_UMASK=077 -D AP_UID_MIN=1000 -D AP_USERDIR_SUFFIX="public_html" so GID min is 100, not 1000 like the ebuild shows. ===================================================================== I don't mean to step on anyone's toes, just trying to help make a better ebuild. :)
Created attachment 104489 [details, diff] patch for eautoreconf generated configure script to restore correct dspam --version output.
Created attachment 104490 [details] ebuild with new use flags and defaults. I've also added a selectable patch option. If you enable the debian-patchset flag, one can specify which patches to omit. The variable is defined right unther the "some FHS like structure" variables near the top of the ebuild.
Comment on attachment 104490 [details] ebuild with new use flags and defaults. The "OMIT" variable should default to OMIT= not OMIT="02"
Created attachment 104492 [details] changed OMIT="02" to OMIT= Sry bout that. Left over testing artifact.
Comment on attachment 104492 [details] changed OMIT="02" to OMIT= forgot the syslog flag.
Created attachment 104493 [details] with syslog flag
1) 3.6.8-r1 fixed dspam --version, which apparently was broken by autoconf-2.60. The fix is 14_all_autodetect-conf.patch; I am aware of the inutile quotes displayed by --version, but technically speaking, it is of no consequence. Either if configure params are quoted or not, dspam-web is able to autodetect these parameters and act upon them. 2) I don't patch configure script. The right way of fixing it is through patching the source files that generated the script. 3) 02_all_link-dynamically.patch - I think you are right on this one. Still, nothing would be gained if I'll replace with --disable-static. 4) 12_all_logrotate-preserve-state.patch is fruit of my experience. It is the right thing to do, but if you have a better solution, you are welcome to prove me wrong. 5) Inventing flags like debian-patchset is definitely wrong. One, because those patches have nothing to do with debian (although some of them were inspired from theirs) and second because it has 0 significance. Would be just another esoteric USE flag that no-one knows what signifies. 6) Since we don't have debug levels, debug USE flag must enable all debug options, even if they're redundant. What guarantees do I have it would be redundant in future versions? 7) You are way too USE flag happy. Flags are supposed to be useful. long-usernames - can't imagine a scenario with this disabled. Verdict: useless. domain-scale & large-scale vs large-domain - almost useless. The only uncovered scenario is --disable-large-scale --disable-domain-scale, but the only "advantange of such configuration would be a shorter path to the dspam user data dirs (no /local). I think is safe to say it isn't worth it. syslog - This shouldn't even be a configure option. The place of such switch is in the dspam.conf. 8) dspam shouldn't be world-executable. So you want to control who has the right to use dspam through dspam group members list? Even if you use dspam daemon, users still need to have executable permission on dspam. Yet another no. 9) --with-dspam-mode : point taken 10) logrotate is used to rotate logs in /var/log/dspam. Since apparently it is used only by debug, I guess I can drop it. 11) use dspam_logrotate in dspam.cron : agreed 12) suexec's GID_MIN=100 : at that time, GID_MIN had been 1000. Better keep this limit (you never know when they rise it again). 13) etc/mail/dspam/ contains executable .sql files : current version do not install *.sql files with executable permissions. Did I missed something? Please keep it short, it was damn hard to read this jumbo-bug.
(In reply to comment #7) > 1) 3.6.8-r1 fixed dspam --version, which apparently was broken by > autoconf-2.60. The fix is 14_all_autodetect-conf.patch; I am aware of the > inutile quotes displayed by --version, but technically speaking, it is of no > consequence. Either if configure params are quoted or not, dspam-web is able to > autodetect these parameters and act upon them. Indeed it works. Would be nice it if worked as original designed. > > 2) I don't patch configure script. The right way of fixing it is through > patching the source files that generated the script. > I thought about that. Looks like the orignal code is coming from libtool - /usr/share/libtool/libltdl/configure. I didn't want to bork anything else so patching the affected configure script seemed like a better option. > 3) 02_all_link-dynamically.patch - I think you are right on this one. Still, > nothing would be gained if I'll replace with --disable-static. Just worried about what else it might affect. Why include it if there is a configure switch already included with dspam? > > 4) 12_all_logrotate-preserve-state.patch is fruit of my experience. It is the > right thing to do, but if you have a better solution, you are welcome to prove > me wrong. No biggy. Yours seems to do the job. I'll attach the patch I found for kicks. > > 5) Inventing flags like debian-patchset is definitely wrong. One, because > those patches have nothing to do with debian (although some of them were > inspired from theirs) and second because it has 0 significance. Would be just > another esoteric USE flag that no-one knows what signifies. Some of 'em? Most of them look like they came from that debiam tarball that was attached to the other closed bug. > > 6) Since we don't have debug levels, debug USE flag must enable all debug > options, even if they're redundant. What guarantees do I have it would be > redundant in future versions? I take issue with this one. The author strongly suggests NOT to compile with verbose unless absolutely necessary. Apparently is flaky and causes problems (or maybe exposes bad code?). Looks like I'll have a dspam ebuild in my overlay forever. lol > > 7) You are way too USE flag happy. Flags are supposed to be useful. > long-usernames - can't imagine a scenario with this disabled. Verdict: > useless. lol, good one! Look at php. Seriously though, there are quite a few options with dspam -file locations, owner and group settings, etc. It would be nice to cover the basics so one can still use an ebuild via use flags instead of having to hack about. I know its unreasonable to make everything available on every ebuild in gentoo and someone has to draw the line on where to stop. > domain-scale & large-scale vs large-domain - almost useless. The only > uncovered scenario is --disable-large-scale --disable-domain-scale, but the > only "advantange of such configuration would be a shorter path to the dspam > user data dirs (no /local). I think is safe to say it isn't worth it. Good point. > syslog - This shouldn't even be a configure option. The place of such > switch is in the dspam.conf. Yeah, you're right. I brought it up because its enabled by default. Just offered up a flag to be able to toggle it since it was already included in the ebuild. > > 8) dspam shouldn't be world-executable. So you want to control who has the > right to use dspam through dspam group members list? You made my point for me. 3.6.8 and 3.6.8-r1 both install the dspam binary as world executable. make DESTDIR="${D}" install || die "make install failed" chgrp dspam "${D}/usr/bin/dspam" chmod g+xs,o+x "${D}/usr/bin/dspam" Touch a file and chmod it 500. Then issue chmod g+xs,o+x and see what you end with - world executable, r-x--s--x. mode 2511. Owner is x, group is x and setgid, and others is x. Like you said, it SHOULDN'T be world executable. It should be r-x--s--- or 2510. Again, since it was there, just made a switch to toggle it. Some like it world executable, I dont have any use for it. > Even if you use dspam daemon, users still need to have executable permission > on dspam. Yet another no. I haven't run into any instance where I users needed executable permissions. > 9) --with-dspam-mode : point taken Same point as above - should be with mode 2510, dspam default. > 10) logrotate is used to rotate logs in /var/log/dspam. Since apparently it > is used only by debug, I guess I can drop it. Those files can get HUGE if you forget to turn off debug. Better leave it on second thought. > 11) use dspam_logrotate in dspam.cron : agreed > > 12) suexec's GID_MIN=100 : at that time, GID_MIN had been 1000. Better keep > this limit (you never know when they rise it again). True > 13) etc/mail/dspam/ contains executable .sql files : current version do not > install *.sql files with executable permissions. No? I just tested it.... # ls -l /etc/mail/dspam/ total 60 -rw-r--r-- 1 root dspam 27689 Dec 21 19:45 dspam.conf -rw-r----- 1 root dspam 65 Dec 21 19:45 mysql.data -rwxr-xr-x 1 root root 1303 Dec 21 19:45 mysql_objects-4.1.sql* -rwxr-xr-x 1 root root 1266 Dec 21 19:45 mysql_objects-space.sql* -rwxr-xr-x 1 root root 1249 Dec 21 19:45 mysql_objects-speed.sql* -rwxr-xr-x 1 root root 1314 Dec 21 19:45 mysql_purge-4.1.sql* -rwxr-xr-x 1 root root 537 Dec 21 19:45 mysql_purge.sql* -rwxr-xr-x 1 root root 262 Dec 20 11:56 mysql_virtual_users.sql* drwxr-xr-x 2 root root 4096 Dec 13 15:35 txt/ They look executable to me... > Did I missed something? > Please keep it short, it was damn hard to read this jumbo-bug. > I think we covered it. Thanks for the effort and your contributions to Gentoo.
Created attachment 104551 [details, diff] dspam_logrotate patch to preserve owner, group, and permissions Found this in the dspam mailing list archive
(In reply to comment #8) > > 4) 12_all_logrotate-preserve-state.patch ... > No biggy. Yours seems to do the job. I'll attach the patch I found for kicks. Looks the same. No reason for replacing my patch. > > 5) Inventing flags like debian-patchset is definitely wrong... > > Some of 'em? Most of them look like they came from that debiam tarball that > was attached to the other closed bug. And yet they aren't exactly the same. I've added only patches that makes sense to Gentoo. I will not add a patch filtering USE flag just because you dislike some patches. Prove that a patch is wrong or shouldn't be applied in some cases and I will fix it. Till then you failed to point that. > > 6) Since we don't have debug levels, debug USE flag must enable all debug > > options, even if they're redundant. What guarantees do I have it would be > > redundant in future versions? > > I take issue with this one. The author strongly suggests NOT to compile with > verbose unless absolutely necessary. Apparently is flaky and causes problems > (or maybe exposes bad code?). Looks like I'll have a dspam ebuild in my > overlay forever. lol Overlay just for debug? Who are you, the dspam developer? I'll remove --debug-verbose if you say is flaky. > > 7) You are way too USE flag happy. Flags are supposed to be useful. ... > > syslog - This shouldn't even be a configure option. The place of such > > switch is in the dspam.conf. > > Yeah, you're right. I brought it up because its enabled by default. Just > offered up a flag to be able to toggle it since it was already included in the > ebuild. I kinda like having --enable-syslog. Does --disable-syslog fit your needs? If it does, I will add this one. > > 8) dspam shouldn't be world-executable. So you want to control who has the > > right to use dspam through dspam group members list? > Like you said, it SHOULDN'T be world executable. It should be r-x--s--- or > 2510. Again, since it was there, just made a switch to toggle it. Some like > it world executable, I dont have any use for it. As a matter of fact, I couldn't use it if postfix wouldn't be able to run dspam (it switches to user:group before running MDA). Also, users wouldn't be able to run it from their procmailrcs. The point is all users should be able to run it. > > 13) etc/mail/dspam/ contains executable .sql files : current version do not > > install *.sql files with executable permissions. > > No? I just tested it.... Probably you had dspam already installed. As you know, file permissions into protected areas aren't altered by a subsequent emerges. Test it on a system without already installed *.sql files and you'll see.
(In reply to comment #10) > > > 5) Inventing flags like debian-patchset is definitely wrong... > > > > Some of 'em? Most of them look like they came from that debiam tarball that > > was attached to the other closed bug. > > And yet they aren't exactly the same. I've added only patches that makes sense > to Gentoo. I will not add a patch filtering USE flag just because you dislike > some patches. Prove that a patch is wrong or shouldn't be applied in some cases > and I will fix it. Till then you failed to point that. I'm not lobbying for that flag any longer. Though I think we can agree that the 02_all_dynamic-link.patch can be excluded and should be replaced with --disable-static. I know you said there is no gain - outcome is the same. But why patch for something that is already an option? Should I submit a patch for --enable-syslog? I'd like to think that 14_all_autodetect-conf is temporary as well. > > > 6) Since we don't have debug levels, debug USE flag must enable all debug > > > options, even if they're redundant. What guarantees do I have it would be > > > redundant in future versions? > > > > I take issue with this one. The author strongly suggests NOT to compile with > > verbose unless absolutely necessary. Apparently is flaky and causes problems > > (or maybe exposes bad code?). Looks like I'll have a dspam ebuild in my > > overlay forever. lol > > Overlay just for debug? Who are you, the dspam developer? > I'll remove --debug-verbose if you say is flaky. lol, no dpsam developer here. I had some past issues with dspam and it was related the the verbose setting. Don't recall exactly what the problem was, but removing verbose solved the problem. > > > 7) You are way too USE flag happy. Flags are supposed to be useful. > ... > > > syslog - This shouldn't even be a configure option. The place of such > > > switch is in the dspam.conf. > > > > Yeah, you're right. I brought it up because its enabled by default. Just > > offered up a flag to be able to toggle it since it was already included in the > > ebuild. > > I kinda like having --enable-syslog. Does --disable-syslog fit your needs? If > it does, I will add this one. Not a big deal to me either way. I only added flags for defaults that existed, and for options I wished to change. I didn't want to force my settings on anyone, nor did I want the defaults already in the ebuild forced on me. I can live with or without the syslog feature. Might as well leave it. > > > 8) dspam shouldn't be world-executable. So you want to control who has the > > > right to use dspam through dspam group members list? > > Like you said, it SHOULDN'T be world executable. It should be r-x--s--- or > > 2510. Again, since it was there, just made a switch to toggle it. Some like > > it world executable, I dont have any use for it. > > As a matter of fact, I couldn't use it if postfix wouldn't be able to run dspam > (it switches to user:group before running MDA). Sure you could. You would just have to use it differently. I use dspam on two postfix systems, and I don't need it. Depends how you integrate dspam into the mail-server picture. I have a dspam transport setup in master.cf and use the mailbox_transport in main.cf to send the messages to the dspam transport. dspam delivers it to procmail on one system and to lmtp (cyrus) on the other. > Also, users wouldn't be able to run it from their procmailrcs. The point is >all users should be able to run it. This is exactly why I proposed the world-exec flag (or whatever you want to call it). There are so many combinations of MTA -> MDA/LDA/pop-imap and different stages where dspam can be inserted into the chain that different combinations need different options. dspam supplies options to facilitate integration into nearly any situation, but the ebuild doesn't. I don't expect ebuild to supply ALL of dspams permutations. Some people need world-executable, but other people do not. dspam by default is NOT world executable. Should one be forced to use world exe on a SETGID program when ones setup doesn't require it? Alternatively, Should one be forced to use dspam in default mode when one's setup needs world executable? If not a flag, how about a variable for the default mode? Then set the mode with the variable instead of hard code. DSPAMMODE=2511 .... myconf="--dspam-mode=${DSPAMMODE}, ... " or is that a gentoo ebuild no-no too? > > > 13) etc/mail/dspam/ contains executable .sql files : current version do not > > > install *.sql files with executable permissions. > > > > No? I just tested it.... > > Probably you had dspam already installed. As you know, file permissions into > protected areas aren't altered by a subsequent emerges. Test it on a system > without already installed *.sql files and you'll see. Check the timestamps. I did. Several times. And one more time. Here's the before... ls -lF /etc/mail total 20 -rw-r--r-- 1 root root 1104 Dec 22 18:07 aliases -rw-r--r-- 1 root root 12288 Dec 22 18:07 aliases.db drwxr-xr-x 3 root root 4096 Nov 23 13:36 spamassassin/ and the after: polly mythtv # ls -lF /etc/mail total 24 -rw-r--r-- 1 root root 1104 Dec 22 18:07 aliases -rw-r--r-- 1 root root 12288 Dec 22 18:07 aliases.db drwxrwx--- 3 dspam dspam 4096 Dec 22 18:11 dspam/ drwxr-xr-x 3 root root 4096 Nov 23 13:36 spamassassin/ ls -lF /etc/mail/dspam/ total 56 -rw-r----- 1 dspam dspam 27619 Dec 22 18:11 dspam.conf -rw-r----- 1 root dspam 66 Dec 22 18:11 mysql.data -rwxr-xr-x 1 root root 1303 Dec 22 18:11 mysql_objects-4.1.sql* -rwxr-xr-x 1 root root 1266 Dec 22 18:11 mysql_objects-space.sql* -rwxr-xr-x 1 root root 1249 Dec 22 18:11 mysql_objects-speed.sql* -rwxr-xr-x 1 root root 1314 Dec 22 18:11 mysql_purge-4.1.sql* -rwxr-xr-x 1 root root 537 Dec 22 18:11 mysql_purge.sql* drwxr-xr-x 2 root root 4096 Dec 22 18:11 txt/ Even txt/ and its files are executable. # ls -lF /etc/mail/dspam/txt/ total 12 -rwxr-xr-x 1 root root 2257 Dec 22 18:11 firstrun.txt* -rwxr-xr-x 1 root root 1315 Dec 22 18:11 firstspam.txt* -rwxr-xr-x 1 root root 1283 Dec 22 18:11 quarantinefull.txt*
(In reply to comment #11) > (In reply to comment #10) > > > > > 5) Inventing flags like debian-patchset is definitely wrong... > > > > > > Some of 'em? Most of them look like they came from that debiam tarball that > > > was attached to the other closed bug. > > > > And yet they aren't exactly the same. I've added only patches that makes sense > > to Gentoo. I will not add a patch filtering USE flag just because you dislike > > some patches. Prove that a patch is wrong or shouldn't be applied in some cases > > and I will fix it. Till then you failed to point that. > > I'm not lobbying for that flag any longer. Though I think we can agree that > the 02_all_dynamic-link.patch can be excluded and should be replaced with > --disable-static. I know you said there is no gain - outcome is the same. But > why patch for something that is already an option? Should I submit a patch for Hope you had a great holiday season! I did a little research on the patches. See the attachment for my comments. > > > > 6) Since we don't have debug levels, debug USE flag must enable all debug > > > > options, even if they're redundant. What guarantees do I have it would be > > > > redundant in future versions? > > > > > > I take issue with this one. The author strongly suggests NOT to compile with > > > verbose unless absolutely necessary. Apparently is flaky and causes problems > > > (or maybe exposes bad code?). Looks like I'll have a dspam ebuild in my > > > overlay forever. lol > > > > Overlay just for debug? Who are you, the dspam developer? > > I'll remove --debug-verbose if you say is flaky. > > lol, no dpsam developer here. I had some past issues with dspam and it was > related the the verbose setting. Don't recall exactly what the problem was, > but removing verbose solved the problem. Don't just take my word for it. From README: DEBUGGING SWITCHES --enable-debug Turns on support for debugging output. This option allows you to turn on debugging messages for all or some users by editing dspam.conf or setting --debug on the commandline. Enabling debug in configure only adds support for debug to be compiled in, it must still be activated using one of the options prescribed above. Debugging support itself doesn't use up very many additional resources, so it should be safe to leave enabled on non-enterprise class systems. --enable-verbose-debug Turns on extremely verbose debugging output. --enable-debug is implied. Never use this on production builds! Note: When verbose debug is compiled in, DSPAM performs many additional mathematical calculations regardless of whether or not it's been activated. You shouldn't use --enable-verbose for production builds unless you have serious issues you can't resolve.
Created attachment 104867 [details] patch.comments.txt
-r2 is now in cvs. Summary: 1) not changed - I tought about removing quotes but then I saw the CFLAGS/CXXFLAGS there. Better leave it as is (I don't really understand your problem with current variant anyway). 3) not changed. (--disable-static do nothing it can be used in makefile, check configure script for yourself) 6) --enable-verbose-debug has been removed. 8) added DSPAMPERMS variable in ebuild 9) modified as suggested. 11) modified as suggested. 13) fixed.
