Re: Re: possible mass bug filing: spamassassin 3
Hello there, I was wondering too, why there is no SA3 in sarge yet. A friend of mine asked to write a couple words about this new version from a system administrator view. When I was using 2.6x series, the main tool to mark spam was bayes database, and some others tests would help to identify spam. But the main one was Bayes. In v3, the situation is pretty different. For me, the change from 2.6x to 3.xx was a huge leap forward. It is pretty hard to explain how much better v3 is. The main thing to identify spam now is surbl (www.surbl.org). Shortly, pretty much all of spam contains some url's to some spam sites. All these websites/ip's are being tracked in surbl database. Since the most of the spam is some random words/junk and a spam url, it is a VERY efficient way to fight spam. Please, please, please include spamassassin3 in sarge. One can live with spamassassin 2.xx, but when you taste the difference... It does make sysadmins life so much much much easier. If it is not possible, is there any chance to get surbl tests in 2.xx series?
Re: possible mass bug filing: spamassassin 3
Hi, * Ramunas Vabolis ([EMAIL PROTECTED]) [041116 09:15]: I was wondering too, why there is no SA3 in sarge yet. A friend of mine asked to write a couple words about this new version from a system administrator view. Given that SA3 is a major change, and we had massive memory issues with the previous upload, the transfer to sarge is a bit delayed. I expect that SA3 will go in one of these days, and it is _definitly_ on my direct watch list. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: possible mass bug filing: spamassassin 3
On Tue, Nov 16, 2004 at 10:54:44AM +0100, Andreas Barth wrote: Given that SA3 is a major change, and we had massive memory issues with the previous upload, the transfer to sarge is a bit delayed. I expect that SA3 will go in one of these days, and it is _definitly_ on my direct watch list. FWIW, we've run SA3 here (with a couple thousand users) in a woody backport for almost a week now, with no problems. This is of course not to say there is no bugs... :-) /* Steinar */ -- Homepage: http://www.sesse.net/
Re: possible mass bug filing: spamassassin 3
* Steinar H. Gunderson ([EMAIL PROTECTED]) [041116 12:30]: On Tue, Nov 16, 2004 at 10:54:44AM +0100, Andreas Barth wrote: Given that SA3 is a major change, and we had massive memory issues with the previous upload, the transfer to sarge is a bit delayed. I expect that SA3 will go in one of these days, and it is _definitly_ on my direct watch list. FWIW, we've run SA3 here (with a couple thousand users) in a woody backport for almost a week now, with no problems. This is of course not to say there is no bugs... :-) This is definitly one of the good news, and together with the other good news I was almost convinced to let SA3 through. However, I'm not too sure if bug 279981 needs to be solved prior to SA3 going to sarge, and I would like some feedback from the maintainer. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: possible mass bug filing: spamassassin 3
On Tue, 16 Nov 2004, Andreas Barth wrote: * Steinar H. Gunderson ([EMAIL PROTECTED]) [041116 12:30]: On Tue, Nov 16, 2004 at 10:54:44AM +0100, Andreas Barth wrote: Given that SA3 is a major change, and we had massive memory issues with the previous upload, the transfer to sarge is a bit delayed. I expect that SA3 will go in one of these days, and it is _definitly_ on my direct watch list. FWIW, we've run SA3 here (with a couple thousand users) in a woody backport for almost a week now, with no problems. This is of course not to say there is no bugs... :-) This is definitly one of the good news, and together with the other good news I was almost convinced to let SA3 through. However, I'm not too sure if bug 279981 needs to be solved prior to SA3 going to sarge, and I would like some feedback from the maintainer. IMHO it only *has* to be fixed in sarge if it affects upgrades from 2.20, which is in stable. Otherwise, documentation on NEWS.Debian should be enough. Of course, if there is a safe way to automate this, it would be best. But one would have to make spamassassin itself detect that the database is of an older version, and do the cleanup. Anything else is a partial fix that is actually worse than documenting things properly on NEWS.Debian. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: possible mass bug filing: spamassassin 3
* Henrique de Moraes Holschuh ([EMAIL PROTECTED]) [041116 14:55]: On Tue, 16 Nov 2004, Andreas Barth wrote: * Steinar H. Gunderson ([EMAIL PROTECTED]) [041116 12:30]: On Tue, Nov 16, 2004 at 10:54:44AM +0100, Andreas Barth wrote: Given that SA3 is a major change, and we had massive memory issues with the previous upload, the transfer to sarge is a bit delayed. I expect that SA3 will go in one of these days, and it is _definitly_ on my direct watch list. FWIW, we've run SA3 here (with a couple thousand users) in a woody backport for almost a week now, with no problems. This is of course not to say there is no bugs... :-) This is definitly one of the good news, and together with the other good news I was almost convinced to let SA3 through. However, I'm not too sure if bug 279981 needs to be solved prior to SA3 going to sarge, and I would like some feedback from the maintainer. IMHO it only *has* to be fixed in sarge if it affects upgrades from 2.20, which is in stable. Otherwise, documentation on NEWS.Debian should be enough. I agree with you that fixing is only required if this might be a problem for upgrades from woody. As this bug report is quite young, I think the best thing really is to give the maintainer enough time to take a look at it, and decide whether this needs to be fixed first (and if, how) or not. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: possible mass bug filing: spamassassin 3
On Tue, Nov 16, 2004 at 03:01:03PM +0100, Andreas Barth wrote: IMHO it only *has* to be fixed in sarge if it affects upgrades from 2.20, which is in stable. Otherwise, documentation on NEWS.Debian should be enough. It doesn't affect upgrades from 2.20 which have no Bayes at all. The only solution is documenting the issue. I agree with you that fixing is only required if this might be a problem for upgrades from woody. As this bug report is quite young, I think the best thing really is to give the maintainer enough time to take a look at it, and decide whether this needs to be fixed first (and if, how) or not. I don't recommend 3.0.1 go into sarge. 3.0.2 will be released shortly, and that fixes a few more bugs that should make it mature enough. This bug, specifically, can only be solved by documentation as there is no reliable way for spamassassin to find every bayesian database; furthermore, it may be a violation of policy (? havent checked recently) or at least considered harmful for a maintainer script to change stuff in /home where most Bayes databases lie. Spamassassin tries to overcome this but automatically rebuilding while processing if necessary; however, this can be problematic as multiple processes try to access the same database while it's being synced, causing them to wait (often for a while). (IIRC) -- Duncan Findlay signature.asc Description: Digital signature
Re: possible mass bug filing: spamassassin 3
* Duncan Findlay ([EMAIL PROTECTED]) [041116 16:50]: On Tue, Nov 16, 2004 at 03:01:03PM +0100, Andreas Barth wrote: I agree with you that fixing is only required if this might be a problem for upgrades from woody. As this bug report is quite young, I think the best thing really is to give the maintainer enough time to take a look at it, and decide whether this needs to be fixed first (and if, how) or not. I don't recommend 3.0.1 go into sarge. 3.0.2 will be released shortly, and that fixes a few more bugs that should make it mature enough. I understand this as that I should keep my block hint, and once 3.0.2 has survived 10 days in unstable, it will automatically go in? This bug, specifically [...] I trust you as maintainer that you do the right thing. I just saw this bug on skimming through the bug list, and wanted to know your opinion on it. Thanks for your explanation. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: possible mass bug filing: spamassassin 3
On Wed, 06 Oct 2004 15:56:25 -0500, Manoj Srivastava [EMAIL PROTECTED] said: Under your scheme, Sarge would be bereft of all the packages that build on SA that have not changed, at the cost of something that has shown all evidence of being flakey and not ready for prime time yet. Well, dialing down max children to 2 allows my machine to keep load averages within sane limits, and still not build up a significant backlog (-m 10 was doing that). I have not had any further problems with SA3, so far. manoj -- Real Users find the one combination of bizarre input values that shuts down the system for days. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: possible mass bug filing: spamassassin 3
On Sun, Oct 10, 2004 at 04:46:10AM +0200, Sven Mueller wrote: The only official interfaces SpamAssassin ever provided (to the best of my knowledge) are: 1) calling spamassassin directly (as a commandline tool) 2) calling the spamc client (again, as a commandline tool) 3) accessing spamd over its defined interface (which is used by spamc) [...] And given the fact that the SA3 API has been published more than 7 month ago (more like 8: 2004-02-18 was the last date on which the API was changed in an incompatible way), each tool had more than enough time to adjust to this. I don't follow your logic here. First, you say that using SA via the Perl modules are not supported; then, you say that the SA Perl APIs were frozen and officially published seven months ago? /* Steinar */ -- Homepage: http://www.sesse.net/
Re: possible mass bug filing: spamassassin 3
* Sven Mueller | Tollef Fog Heen [u] wrote on 07/10/2004 09:52: | * Duncan Findlay | Umm... I'd like to see that | 7122 root 15 0 660m 332m 4692 D 0.0 43.8 8:18.64 spamd | 7123 nobody15 0 287m 257m 4692 D 0.0 34.0 0:17.01 spamd | | Furthermore, you should use the -m option to limit the number of | | children to something sane, like 5 or so. | This is per child, as I wrote. | | Do you have any additional rulesets like those SARE rules installed? No. | If so, how many/what total size? I have ~10 custom body matching rules. If that makes SA explode, something is seriously broken. :) -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: possible mass bug filing: spamassassin 3
On Sun, Oct 10, 2004 at 12:23:26PM +0200, Steinar H. Gunderson wrote: I don't follow your logic here. First, you say that using SA via the Perl modules are not supported; then, you say that the SA Perl APIs were frozen and officially published seven months ago? Oh, and checking on spamassassin.apache.org: Flexible: SpamAssassin encapsulates its logic in a well-designed, abstract API so it can be integrated anywhere in the email stream. The Mail::SpamAssassin classes can be used on a wide variety of email systems including procmail, sendmail, Postfix, qmail, and many others. Or, http://spamassassin.apache.org/full/3.0.x/dist/doc/Mail_SpamAssassin.html: Mail::SpamAssassin is a module to identify spam using several methods [...]. If you wish to use a command-line filter tool, try the spamassassin or the spamd/spamc tools provided. This does not look like an internal unsupported interface to me. /* Steinar */ -- Homepage: http://www.sesse.net/
Re: possible mass bug filing: spamassassin 3
* Sven Mueller
| Tollef Fog Heen [u] wrote on 07/10/2004 10:00:
|
| * Sven Mueller | Well, perl modules don't have an SO name.
| : [EMAIL PROTECTED] /usr/lib apt-cache show libvideo-capture-v4l-perl|
| grep ^Depends
| Depends: perlapi-5.8.3, perl (= 5.8.3-2), libc6 (= 2.3.2.ds1-4)
| Seems like perl provides an API that the module depends on, no?
|
| perlapi seems to be some sort of a pseudo package.
It's a virtual package.
| But anyway: What does a package version have to do with SO names?
(I assume you meant package name, if not please explain a bit further
what you mean)
For packages including APIs, the package name should include the API
version number. For shared objects (libraries), that's the soname.
Perl modules don't really have a similar concept, but that's just
tradition and there's no reason why they couldn't.
| | And actually, the library part of SA isn't intended to be the most
| | often used one.
| If it is provided, it must work.
|
| So if someone provides a huge program which consists of various
| specially crafted dynamic libraries (whose APIs are documented but not
| really intended for use outside of this specific program), these
| libraries may not change in a way which changes those APIs?
Yes, or rather it must bump the soname when changing those APIs.
Also, if they're not intended for general use, they shouldn't be put
in /usr/share/perl5 but in a private module directory. (Similarly,
not /usr/lib for private libraries, but a /usr/lib/$packagename/ or
something like that.)
| Sure seems strange to me.
| The only official interfaces SpamAssassin ever provided (to the best
| of my knowledge) are:
| 1) calling spamassassin directly (as a commandline tool)
| 2) calling the spamc client (again, as a commandline tool)
| 3) accessing spamd over its defined interface (which is used by spamc)
From the front page of spamassassin.org:
: Flexible: SpamAssassin encapsulates its logic in a well-designed,
: abstract API so it can be integrated anywhere in the email
: stream. The Mail::SpamAssassin classes can be used on a wide variety
: of email systems including procmail, sendmail, Postfix, qmail, and
: many others.
| If it is changed in an incompatible fashion, it must bump soname.
| Or make SA into a library proper, with
| libmail-spamassassin-perl being the module part and spamassassin
| depending on that.
|
| Well, in that case, libmail-spamassassin-perl would be the size of the
| current spamassassin package, and the new spamassassin package (which
| depends on the libmail-spamassassin-perl package) is about 2k in size,
| description and packaging overhead included. Sorry, that doesn't make
| much sense.
: [EMAIL PROTECTED] ~ for f in $(dpkg -L spamassassin | grep -v perl \
|grep -v man3 ); do [ -f $f ] echo $f; done | xargs du -shc |
tail -1
1,1Mtotalt
SA currently ships nearly 600k of rules.
| You'd still have to bump soname, but only for the library part.
|
| Go learn perl, than come back.
(Apology about writing mail after discussion with boss accepted. :)
| Perl Modules might have version numbers, but they certainly don't
| have SO names. BTW: Give a descend definition of what you refer to
| as soname, and I might apologize and say that you are right.
soname is here used a bit loosely meaning «ABI/API version»; this is
technically not correct (as you point out), but it's shorter than
writing «ABI/API version» all over the place.
(And, given that perl modules can be normal shared objects, they
certainly _can_ have sonames proper, but I agree that's not the norm.)
| This is _not_ hard to get right, and there is really no exuse not get
| it right.
|
| The only way to get it right (in your sense of the word) would be to
| rename the Perl Mail::SpamAssassin module (along with its sub-modules)
| to Mail::SpamAssassin3. However, this would make some programs break
| which are otherwise able to cope with v3 Mail:SpamAssasin quite well.
They can try to import Mail::SpamAssassin3 first, if that fails, try
Mail::SpamAssassin. A nice thing with this is you actually know what
API you use.
| spampd for example has a total of 10 lines which differentiate between
| versions v being 2.7, 2.7 = v 3.0 and v = 3.0 _and_ do what's
| needed to work with either of the three possible categories of
| SpamAssassin versions. If SpamAssasin v3 would be renamed to
| Mail::SpamAssassin3, the changes would be more like 120 lines.
BEGIN {
eval {
require Mail::SpamAssassin3;
import Mail::SpamAssassin3 qw(foo bar baz);
}
if ($@) {
require Mail::SpamAssassin;
import Mail::SpamAssassin qw(foo bar baz);
}
}
Doesn't look like 120 lines to me.
| And given the fact that the SA3 API has been published more than 7
| month ago (more like 8: 2004-02-18 was the last date on which the API
| was changed in an incompatible way), each tool had more than enough
| time to adjust to this. Note: The outside API
Re: possible mass bug filing: spamassassin 3
On Sun, Oct 10, 2004 at 10:43:14AM +0900, Clemens Schwaighofer wrote: Furthermore, we should all know that Anti-Spam, Anti-Virus is a CPU memory hog. It needs tons of memory and fastest cpu ... always. I'm using now bogofilter and razor, without CPU and memory problems at all. So your always should probably be parsed sometimes. -- Francesco P. Lovergine
Re: possible mass bug filing: spamassassin 3
Tollef Fog Heen [u] wrote on 10/10/2004 13:01:
* Sven Mueller
From the front page of spamassassin.org:
: Flexible: SpamAssassin encapsulates its logic in a well-designed,
: abstract API so it can be integrated anywhere in the email
: stream. The Mail::SpamAssassin classes can be used on a wide variety
: of email systems including procmail, sendmail, Postfix, qmail, and
: many others.
You are right. This has changed since I last checked (two years ago or
so, not sure when). I should have re-checked this before posting.
| [splitting SA into libmail-spamassassin-perl and spamassassin]
|
| Well, in that case, libmail-spamassassin-perl would be the size of the
| current spamassassin package, and the new spamassassin package (which
| depends on the libmail-spamassassin-perl package) is about 2k in size,
| description and packaging overhead included. Sorry, that doesn't make
| much sense.
: [EMAIL PROTECTED] ~ for f in $(dpkg -L spamassassin | grep -v perl \
|grep -v man3 ); do [ -f $f ] echo $f; done | xargs du -shc |
tail -1
1,1Mtotalt
SA currently ships nearly 600k of rules.
I don't understand what you are trying to say. If you yre trying to
say that libmail-spamassassin-perl wouldn't include the rules, but
spamassassin would, I would like to propose splitting into 3 packages:
libmail-spamassassin-perl, libmail-spamassassin-perl-rules and
spamassassin, so that Programs relying on libmail-spamassassin-perl can
also depend upon the rules package without depening on the spamassassin
package. Also note that we actually already have 2 packages:
spamassassin and spamc.
But what I meant to say is that it doesn't make much sense to split the
spamassasin package into several packages: neither the perl modules nor
spamassassin itself would be useful without the rules. So you would need
to include the rules in the modules-package (or a third package, upon
which the lib package would probably depend). After you did that, the
spamassassin executable doesn't add much to that package (29k to be
precise).
As a side note: SA3 ships with 452k of rules if you count
/etc/spamassassin/local.cf and 448k if not:
mail2:/tmp# dpkg -L spamassassin| grep -E 'etc|usr/share/spamassassin' |
grep .cf| xargs du -hc| tail -1
452Ktotal
mail2:/tmp# dpkg -L spamassassin| grep -E 'usr/share/spamassassin' |
grep .cf| xargs du -hc| tail -1
448Ktotal
You didn't exclude all man pages and you didn't exclude start scripts
and configuration ;-)
soname is here used a bit loosely meaning «ABI/API version»; this is
technically not correct (as you point out), but it's shorter than
writing «ABI/API version» all over the place.
OK.
(And, given that perl modules can be normal shared objects, they
certainly _can_ have sonames proper, but I agree that's not the norm.)
In a way, yes. But this is only true for binary modules.
They can try to import Mail::SpamAssassin3 first, if that fails, try
Mail::SpamAssassin. A nice thing with this is you actually know what
API you use.
Yes.
| spampd for example has a total of 10 lines which differentiate between
| versions v being 2.7, 2.7 = v 3.0 and v = 3.0 _and_ do what's
| needed to work with either of the three possible categories of
| SpamAssassin versions. If SpamAssasin v3 would be renamed to
| Mail::SpamAssassin3, the changes would be more like 120 lines.
BEGIN {
eval {
require Mail::SpamAssassin3;
import Mail::SpamAssassin3 qw(foo bar baz);
}
if ($@) {
require Mail::SpamAssassin;
import Mail::SpamAssassin qw(foo bar baz);
}
}
Doesn't look like 120 lines to me.
Problem is that SA doesn't work well with that sort of namespace
mangling. At least most programs which I looked at using SA modules use
it in a object oriented way (if you can call it that). So they have a
multitude of lines referring to Mail::SpamAssassin.
| [SA3 API published half a year ago]
This is orthagonal to the discussion -- how much and when the API
changed doesn't mean it shouldn't be done right.
Well, yes.
This is Debian. We don't break stuff arbitrarily.
I.e. We try not to break stuff arbitrarily. ;-)
Problem with SA3 is that by renaming Mail::SpamAssassin to
Mail::SpamAssassin3 for SA3 makes it difficult for many programs to
adjust. Especially because this introduces a new modulename which isn't
used on any other platform, causing it to be a debian-only change to the
programs. Not renaming it breaks some programs, which had months to
adjust to the new API (upstream) with that adjustment being a pretty
small change. Also, the adjustment needs to be made in upstream versions
anyway.
I certainly don't want to see SA3 enter the testing/stable archive as
spamassassin/Mail::SpamAssassin before each and every program which
uses it can cope with the change or conflicts version =3 [1] or is
removed from the archive.
However, I would like to see SA3 enter the testing/stable archive as
spamassassin as soon as any program
Re: possible mass bug filing: spamassassin 3
Tollef Fog Heen [u] wrote on 07/10/2004 09:52: * Duncan Findlay | Umm... I'd like to see that 7122 root 15 0 660m 332m 4692 D 0.0 43.8 8:18.64 spamd 7123 nobody15 0 287m 257m 4692 D 0.0 34.0 0:17.01 spamd | Furthermore, you should use the -m option to limit the number of | children to something sane, like 5 or so. This is per child, as I wrote. Do you have any additional rulesets like those SARE rules installed? If so, how many/what total size? SA3 really explodes in size when more rules are given. Without additional rulesets, i.e. just with the rules SA 3.0 ships with, I have about 20M of memory usage by spampd (spamassassin based SMTP/LMTP proxy). With an additional 460k of rules (some SARE, some others), this shoots up to 40M. With 5M of additional rules, it consumes like 170M of memory. So I would guess that you use additional rulesets totalling about 10-15M in size. Am I right? If so, try removing the biggest rulesets installed, probably something like SARE BigEvil or the like. cu, sven
Re: possible mass bug filing: spamassassin 3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/07/2004 01:43 AM, Tollef Fog Heen wrote: * martin f krafft | What do you think? API changed generally means you bump soname. Why not for SA as well. Also, SA3 is useless, as it eats about half a gig of RAM on my system. Per child. at office SA2 eats 89MB per daemon, and it opens a new daemon for each damn mail ... becaue spamd can't handle multile connections, but SA3 can, so under the line SA3 is more efficient. Furthermore, we should all know that Anti-Spam, Anti-Virus is a CPU memory hog. It needs tons of memory and fastest cpu ... always. lg, clemens -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBaJOyjBz/yQjBxz8RAl9AAKDWKEdE3jTwFeyl8aw1ka9Xqxg5awCdHHPJ gbGMGc2yL+2nbEZdDf/1eUI= =drOc -END PGP SIGNATURE-
Re: possible mass bug filing: spamassassin 3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/08/2004 07:25 PM, Tollef Fog Heen wrote: * Duncan Findlay | A lot of that is shared, but not reported as such by top/ps due to | changes in how the kernel reports shared memory. The kernel only | reports memory that is used in shared libraries, I believe. More | memory is shared between spamd and it's children. My system ran out of swap, with 768MB memory and half a gig of swap. Problems went away when I downgraded to SA2. If SA uses more than 100 MB shared memory, I'd say something is seriously wrong anyhow. please read the SA3 man page. it doesn't open spamd on demand, but it runs them permanently, but each can have (default) 200 conenctions. therefore you can set the how many daemons max flag to 2 or so, because then you can handle 400 parallel connections. should be enought for home ... lg, clemens -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBaJR2jBz/yQjBxz8RAumjAKC7mZ0gt+npU72LWNSKtUxv7MdP7wCfS3sE aunhCS6QGdC7FnwXb64aAlc= =h245 -END PGP SIGNATURE-
Re: possible mass bug filing: spamassassin 3
Tollef Fog Heen [u] wrote on 07/10/2004 10:00: * Sven Mueller | Well, perl modules don't have an SO name. : [EMAIL PROTECTED] /usr/lib apt-cache show libvideo-capture-v4l-perl| grep ^Depends Depends: perlapi-5.8.3, perl (= 5.8.3-2), libc6 (= 2.3.2.ds1-4) Seems like perl provides an API that the module depends on, no? perlapi seems to be some sort of a pseudo package. But anyway: What does a package version have to do with SO names? | And actually, the library part of SA isn't intended to be the most | often used one. If it is provided, it must work. So if someone provides a huge program which consists of various specially crafted dynamic libraries (whose APIs are documented but not really intended for use outside of this specific program), these libraries may not change in a way which changes those APIs? Sure seems strange to me. The only official interfaces SpamAssassin ever provided (to the best of my knowledge) are: 1) calling spamassassin directly (as a commandline tool) 2) calling the spamc client (again, as a commandline tool) 3) accessing spamd over its defined interface (which is used by spamc) If it is changed in an incompatible fashion, it must bump soname. Or make SA into a library proper, with libmail-spamassassin-perl being the module part and spamassassin depending on that. Well, in that case, libmail-spamassassin-perl would be the size of the current spamassassin package, and the new spamassassin package (which depends on the libmail-spamassassin-perl package) is about 2k in size, description and packaging overhead included. Sorry, that doesn't make much sense. You'd still have to bump soname, but only for the library part. Go learn perl, than come back. Perl Modules might have version numbers, but they certainly don't have SO names. BTW: Give a descend definition of what you refer to as soname, and I might apologize and say that you are right. But for now we either have different ideas of what a soname is or you don't have much knowledge about perl (heck, I don't know perl well, but I know enough to be certain that perl modules don't have anything I would call a soname). This is _not_ hard to get right, and there is really no exuse not get it right. The only way to get it right (in your sense of the word) would be to rename the Perl Mail::SpamAssassin module (along with its sub-modules) to Mail::SpamAssassin3. However, this would make some programs break which are otherwise able to cope with v3 Mail:SpamAssasin quite well. spampd for example has a total of 10 lines which differentiate between versions v being 2.7, 2.7 = v 3.0 and v = 3.0 _and_ do what's needed to work with either of the three possible categories of SpamAssassin versions. If SpamAssasin v3 would be renamed to Mail::SpamAssassin3, the changes would be more like 120 lines. And given the fact that the SA3 API has been published more than 7 month ago (more like 8: 2004-02-18 was the last date on which the API was changed in an incompatible way), each tool had more than enough time to adjust to this. Note: The outside API (i.e. the API to _use_ SpamAssassin as opposed to the inside API used to enhance SpamAssassin by plugins) only had pretty minor changes. Regards, Sven
Re: possible mass bug filing: spamassassin 3
Sven Mueller [u] wrote on 10/10/2004 04:46: Go learn perl, than come back. Sheesh, I shouldn't write mail after prolonged discussions with my boss... I apologize for the rudeness of that comment. Even though it was meant somewhat jokingly, I realize it probably was too harsh. Sorry. cu, sven
Re: possible mass bug filing: spamassassin 3
On Wed, Oct 06, 2004 at 07:37:42PM +0200, martin f krafft wrote: Now it's running at -m5 (the suggested value) and I have not had problems since. Of course, now I only get half the throughput, and my queue has not emptied for a whole day because SA is unable to keep up. I had -m2 and each child canibalized up 20M of VM in just a few minutes. With 128M that makes difference. I'm now quite happily using razor with only very few false positives and a very high success rate in filtering spam. -- Francesco P. Lovergine
Re: possible mass bug filing: spamassassin 3
* Emilio Jesús Gallego Arias | For me sa work well: That doesn't help me. | Can you give some steps to reproduce such memory comsuption. Yeah, receive the mail/spam I get and you'll see it within twenty minutes. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: possible mass bug filing: spamassassin 3
* Duncan Findlay | A lot of that is shared, but not reported as such by top/ps due to | changes in how the kernel reports shared memory. The kernel only | reports memory that is used in shared libraries, I believe. More | memory is shared between spamd and it's children. My system ran out of swap, with 768MB memory and half a gig of swap. Problems went away when I downgraded to SA2. If SA uses more than 100 MB shared memory, I'd say something is seriously wrong anyhow. | Other than that I don't know what to say. It doesn't seem like it | should take up that much memory... | | FWIW, I can't really reproduce that. I can reproduce it within twenty minutes of starting SA3. I run SA smtp-time and I get enough mail that I'm not sure I'm going to start tracking down where the problem is. (Given that I don't know perl and SA well enough.) -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: possible mass bug filing: spamassassin 3
On Fri, Oct 08, 2004 at 12:24:18PM +0200, Tollef Fog Heen wrote: | Can you give some steps to reproduce such memory comsuption. Yeah, receive the mail/spam I get and you'll see it within twenty minutes. Unless you're offering to provide relevant samples of the messages in question, that response is quite worthless from a troubleshooting perspective.
Re: possible mass bug filing: spamassassin 3
On Fri, Oct 08, 2004 at 12:24:18PM +0200, Tollef Fog Heen wrote: * Emilio Jesús Gallego Arias | For me sa work well: That doesn't help me. | Can you give some steps to reproduce such memory comsuption. Yeah, receive the mail/spam I get and you'll see it within twenty minutes. Do you limit the size of the messages you sacn? -- Duncan Findlay signature.asc Description: Digital signature
Re: possible mass bug filing: spamassassin 3
also sprach Greg Norris [EMAIL PROTECTED] [2004.10.08.1601 +0200]: Unless you're offering to provide relevant samples of the messages in question, that response is quite worthless from a troubleshooting perspective. Yes, please forward your spam to debian-devel so that we can all feel it. Not. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: possible mass bug filing: spamassassin 3
* Duncan Findlay | On Fri, Oct 08, 2004 at 12:24:18PM +0200, Tollef Fog Heen wrote: | * Emilio Jesús Gallego Arias | | | For me sa work well: | | That doesn't help me. | | | Can you give some steps to reproduce such memory comsuption. | | Yeah, receive the mail/spam I get and you'll see it within twenty | minutes. | | Do you limit the size of the messages you sacn? I can't see any such option in the shipped SA configuration, no, but I tend not to receive very large mail either. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: possible mass bug filing: spamassassin 3
On Fri, Oct 08, 2004 at 04:10:14PM +0200, martin f krafft wrote: also sprach Greg Norris [EMAIL PROTECTED] [2004.10.08.1601 +0200]: Unless you're offering to provide relevant samples of the messages in question, that response is quite worthless from a troubleshooting perspective. Yes, please forward your spam to debian-devel so that we can all feel it. Not. Exactly where did I say please send it to the list?
Re: possible mass bug filing: spamassassin 3
Tollef Fog Heen [EMAIL PROTECTED] writes: * Duncan Findlay | On Fri, Oct 08, 2004 at 12:24:18PM +0200, Tollef Fog Heen wrote: | * Emilio Jess Gallego Arias | | | For me sa work well: | | That doesn't help me. | | | Can you give some steps to reproduce such memory comsuption. | | Yeah, receive the mail/spam I get and you'll see it within twenty | minutes. | | Do you limit the size of the messages you sacn? I can't see any such option in the shipped SA configuration, no, but I tend not to receive very large mail either. spamc -s, if you use spamc. I use Exim4 with the Exiscan ACL patch, and have an exim rule that accepts mail 80k before the scans for spam. Rotty -- Andreas Rottmann | [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://yi.org/rotty | GnuPG Key: http://yi.org/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 To iterate is human; to recurse, divine.
Re: possible mass bug filing: spamassassin 3
* Duncan Findlay | On Wed, Oct 06, 2004 at 06:43:47PM +0200, Tollef Fog Heen wrote: | * martin f krafft | | | What do you think? | | API changed generally means you bump soname. Why not for SA as well. | | Also, SA3 is useless, as it eats about half a gig of RAM on my | system. Per child. | | Umm... I'd like to see that 7122 root 15 0 660m 332m 4692 D 0.0 43.8 8:18.64 spamd 7123 nobody15 0 287m 257m 4692 D 0.0 34.0 0:17.01 spamd | Furthermore, you should use the -m option to limit the number of | children to something sane, like 5 or so. This is per child, as I wrote. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: possible mass bug filing: spamassassin 3
* Sven Mueller | Well, perl modules don't have an SO name. : [EMAIL PROTECTED] /usr/lib apt-cache show libvideo-capture-v4l-perl| grep ^Depends Depends: perlapi-5.8.3, perl (= 5.8.3-2), libc6 (= 2.3.2.ds1-4) Seems like perl provides an API that the module depends on, no? | And actually, the library part of SA isn't intended to be the most | often used one. If it is provided, it must work. If it is changed in an incompatible fashion, it must bump soname. Or make SA into a library proper, with libmail-spamassassin-perl being the module part and spamassassin depending on that. You'd still have to bump soname, but only for the library part. This is _not_ hard to get right, and there is really no exuse not get it right. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: possible mass bug filing: spamassassin 3
On Wed, Oct 06, 2004 at 06:03:18PM -0400, Duncan Findlay wrote: (And my home server is a AMD K6-II 450, with 192MB RAM, not bad for my own amount of daily mail) Perhaps you simply need to tune the -m option. Spamassassin has switched to a preforking model (similar to apache) rather than a spawning option, so the number specified by -m should be decreased. To '-m 1' ? Even that will be too much for SA3 to fit in 192MB of RAM; and the throughput will be *bad*... Even if SA3 has better ways to stop spam, that doesn't mean SA2 suddenly stopped doing what it does. It's a trade-off people have to make; either they buy bigger, larger, better servers to manage the incoming spam, or they cope with more SPAM. Is it that hard to understand? -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
Re: possible mass bug filing: spamassassin 3
Duncan Findlay wrote, Wednesday, October 06, 2004 11:03 PM On Wed, Oct 06, 2004 at 10:51:46PM +0200, Jose Carlos Garcia Sogo wrote: [...] And, BTW, since version 2.64 we have: - Rules backported from 3.0.0 So though SA3 can make other things better (bayesian and so), SA2 is not so obsolete, and basically *works* in machines in which SA3 won't. I'm not really sure what you mean by rules backported from 3.0.0. Unfortunately, rules are fairly linked to releases. The above was a /direct/ quote from the 2.64-1 changelog: spamassassin (2.64-1) unstable; urgency=high * New upstream release - Rules backported from 3.0.0 - Problem on long headers fixed - Performance improvements * [SECURITY] Fixes a potential DoS attack, hence the urgency=high. -- Jesus Climent [EMAIL PROTECTED] Thu, 5 Aug 2004 08:50:17 +0300 Regards, Adam
Re: possible mass bug filing: spamassassin 3
On Wed, Oct 06, 2004 at 06:29:38PM +0200, Steinar H. Gunderson wrote: Eh. spamassassin has had a long-standing, well-known API, and suddenly changes it. It is _SA_ which broke this, not the other applications. SA has had a long-standing, well-known API in the many packages which went to experimental, during the development and testing process of the new 3.0 series. Amavisd-new introduced the necessary changes in their code to comply with the 3.x API back in february (IIRC, check on the changelog). The process has been going on for several months, and if your application deppends on SA to work, you should have been tracking SA development, at least API wise. And you say suddenly? -- Jesus Climent info:www.pumuki.org Unix SysAdm|Linux User #66350|Debian Developer|2.4.27|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 Sometimes, the only way to catch and uncatchable woman is to offer her a wedding ring. --Senior Ed Bloom (Big Fish)
Re: possible mass bug filing: spamassassin 3
On Wed, Oct 06, 2004 at 08:46:04PM +0200, Jeroen van Wolffelaar wrote: Well, I'm not at all convinced this is so good. Didn't the RMs say something about 'no major new upstream releases', in order to be able to ship sarge this year? 2.64-1 is in testing. since sa3 has RCs, it will not get into sarge, at least not until the problems are solved. In addition to the enormous amount of reports of sa3 taken down systems, or causing mail loss, by people who I regard as pretty clueful[1], I think it's pretty obvious it would be a very bad move to let sa3 into sarge. sa3 is IMNSHO a sarge+1, aka etch project. And I have been running it ever since beta1 in a 512GB PII-350 and my mail has been going thru without much problems (right now, version=3.0.0-pre4). data 11713 0.0 0.1 20392 716 ?SAug05 0:05 ./spamd --socketpath=/home/data/sa/spamd.sock -L -d -m 5 J -- Jesus Climent info:www.pumuki.org Unix SysAdm|Linux User #66350|Debian Developer|2.4.27|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 Tell me, Mr. Anderson, what good is a phone call when you are unable to speak? --Agent Smith (The Matrix)
Re: possible mass bug filing: spamassassin 3
On Thu, Oct 07, 2004 at 11:08:55AM +0200, Jesus Climent wrote: And I have been running it ever since beta1 in a 512GB PII-350 and my mail has ^ That might explain why you haven't been seeing any problems ;-) /* Steinar */ -- Homepage: http://www.sesse.net/
Re: possible mass bug filing: spamassassin 3
also sprach Steinar H. Gunderson [EMAIL PROTECTED] [2004.10.07.1252 +0200]: And I have been running it ever since beta1 in a 512GB PII-350 and my mail has That might explain why you haven't been seeing any problems ;-) I didn't think the x86 architecture can handle 512 Gb of RAM. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: possible mass bug filing: spamassassin 3
On Thu, Oct 07, 2004 at 09:37:19AM +0100, Adam D. Barratt wrote: I'm not really sure what you mean by rules backported from 3.0.0. Unfortunately, rules are fairly linked to releases. The above was a /direct/ quote from the 2.64-1 changelog: spamassassin (2.64-1) unstable; urgency=high * New upstream release - Rules backported from 3.0.0 - Problem on long headers fixed - Performance improvements * [SECURITY] Fixes a potential DoS attack, hence the urgency=high. -- Jesus Climent [EMAIL PROTECTED] Thu, 5 Aug 2004 08:50:17 +0300 And this is a /direct/ quote from the upstream SpamAssassin Changes file: rules backported from 3.0.0 tree r22197 | striker | 2004-06-27 12:59:51 + (Sun, 27 Jun 2004) | 5 lines J -- Jesus Climent info:www.pumuki.org Unix SysAdm|Linux User #66350|Debian Developer|2.4.27|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 That's thirty minutes away. I'll be there in ten. --Wolf (Pulp Fiction)
Re: possible mass bug filing: spamassassin 3
On Thu, Oct 07, 2004 at 12:52:15PM +0200, Steinar H. Gunderson wrote: On Thu, Oct 07, 2004 at 11:08:55AM +0200, Jesus Climent wrote: And I have been running it ever since beta1 in a 512GB PII-350 ^ That might explain why you haven't been seeing any problems ;-) s/GB/MB/ -- Jesus Climent info:www.pumuki.org Unix SysAdm|Linux User #66350|Debian Developer|2.4.27|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 Problem? I haven't got a problem. I've got fucking problems. Plural. --Ted the Bellhop (Four Rooms)
Re: possible mass bug filing: spamassassin 3
On Wed, Oct 06, 2004 at 04:11:26PM +0200, Marco d'Itri wrote: Sorry, but the basic problem I'm speaking about has nothing to do with volatile - but just that requiring substancially more memory might be a bad idea. We still have inn1 and inn2 parallel (and I'm a happy user of inn1), for similar reasons. But the problem still stands: spamassassin 2.x should not be used anymore because it's obsolete. People should either work to reduce the memory usage of 3.x or switch to a different filtering program. That's silly. Maybe 2.x is obsolete but it catches about 90% of my spam. Which still leaves 20 or so per day in my inbox. But I'd be very pissed if upgrading my PII-233 with 128MB of RAM installs a program which just can't run on that machine. Greetings Torsten signature.asc Description: Digital signature
Re: possible mass bug filing: spamassassin 3
On Thu, Oct 07, 2004 at 04:17:23PM +0200, Torsten Landschoff wrote: That's silly. Maybe 2.x is obsolete but it catches about 90% of my spam. Which still leaves 20 or so per day in my inbox. But I'd be very pissed if upgrading my PII-233 with 128MB of RAM installs a program which just can't run on that machine. Just for your information SA3 was almost unusable on my P4 1.4Ghz with 128MB. It's not a dedicated box, but it's adequate for my workstation use with wmaker. -- Francesco P. Lovergine
Re: possible mass bug filing: spamassassin 3
El jue, 07-10-2004 a las 09:52 +0200, Tollef Fog Heen escribi: * Duncan Findlay | On Wed, Oct 06, 2004 at 06:43:47PM +0200, Tollef Fog Heen wrote: | * martin f krafft | | | What do you think? | | API changed generally means you bump soname. Why not for SA as well. | | Also, SA3 is useless, as it eats about half a gig of RAM on my | system. Per child. | | Umm... I'd like to see that 7122 root 15 0 660m 332m 4692 D 0.0 43.8 8:18.64 spamd 7123 nobody15 0 287m 257m 4692 D 0.0 34.0 0:17.01 spamd | Furthermore, you should use the -m option to limit the number of | children to something sane, like 5 or so. This is per child, as I wrote. For me sa work well: ii spamassassin 3.0.0-1Perl-based spam filter using text analysis [EMAIL PROTECTED]:~$ ps axum | grep spam 0:00 /usr/sbin/spamd --port 7830 --local --daemonize emilio5160 0.2 5.0 28352 25972 ? -13:00 0:38 spamd child emilio5161 0.0 5.1 28872 26408 ? -13:00 0:04 spamd child emilio5162 0.0 5.0 28612 26252 ? -13:00 0:04 spamd child emilio5163 0.0 5.0 28344 25924 ? -13:00 0:03 spamd child emilio5164 0.0 5.0 28744 26308 ? -13:00 0:04 spamd child emilio5810 0.0 0.1 2184 768 pts/0-16:39 0:00 grep spam Can you give some steps to reproduce such memory comsuption. Regards, Emilio
Re: possible mass bug filing: spamassassin 3
On Thu, Oct 07, 2004 at 01:24:57PM +0200, Jesus Climent wrote: On Thu, Oct 07, 2004 at 09:37:19AM +0100, Adam D. Barratt wrote: I'm not really sure what you mean by rules backported from 3.0.0. Unfortunately, rules are fairly linked to releases. The above was a /direct/ quote from the 2.64-1 changelog: Sorry, I missed that. Only a few rules were actually backported, according to SVN. -- Duncan Findlay signature.asc Description: Digital signature
Re: possible mass bug filing: spamassassin 3
On Thu, Oct 07, 2004 at 09:52:40AM +0200, Tollef Fog Heen wrote: * Duncan Findlay | On Wed, Oct 06, 2004 at 06:43:47PM +0200, Tollef Fog Heen wrote: | * martin f krafft | | | What do you think? | | API changed generally means you bump soname. Why not for SA as well. | | Also, SA3 is useless, as it eats about half a gig of RAM on my | system. Per child. | | Umm... I'd like to see that 7122 root 15 0 660m 332m 4692 D 0.0 43.8 8:18.64 spamd 7123 nobody15 0 287m 257m 4692 D 0.0 34.0 0:17.01 spamd | Furthermore, you should use the -m option to limit the number of | children to something sane, like 5 or so. This is per child, as I wrote. A lot of that is shared, but not reported as such by top/ps due to changes in how the kernel reports shared memory. The kernel only reports memory that is used in shared libraries, I believe. More memory is shared between spamd and it's children. Other than that I don't know what to say. It doesn't seem like it should take up that much memory... FWIW, I can't really reproduce that. root 1525 0.0 1.2 27192 6696 ?-Oct05 0:00 /usr/sbin/spamd --create-prefs --max-children 5 --helper-home-dir -s local0 -d --pidfile=/var/run/spamd.pid root 1584 0.0 4.9 32944 25660 ? -Oct05 1:20 spamd child root 1585 0.0 5.0 34008 26168 ? -Oct05 1:25 spamd child root 1586 0.0 5.2 35172 26844 ? -Oct05 1:23 spamd child root 1587 0.0 4.9 32072 25332 ? -Oct05 1:46 spamd child root 1588 0.0 6.5 42180 33852 ? -Oct05 1:49 spamd child -- Duncan Findlay signature.asc Description: Digital signature
possible mass bug filing: spamassassin 3
Hi folks, Spamassassin 3 is finally in unstable. Thanks to Duncan (and possibly others involved)! If you'd be so kind as to refer to #274993, I think we have a problem. A number of packages (see the bug report) depend on spamassassin, but some are not going to work with version 3, which changed the API considerably. The example here is spamass-milter, which simply does not work. The submitter of the bug report suggests to add a conflict to spamassassin. To me, this is coming at it from the wrong angle. I my well understand this all wrong, but if SA conflicts with spamass-milter, which is in testing, it is not going to be able to trickle into sarge until a new spamass-milter has been uploaded and has trickled to sarge first. Instead, I propose that the packages depending on spamassassin should be removed from sarge unless it is known that they work with spamassassin 3. Then, new versions are uploaded which do either of the following: a. conflict with spamassassin (= 3) (I am not sure if it is better to depend on spamassassin ( 3) instead) b. provide a new version that can interface with spamassassin 3. I really think spamassassin 3 should make it into Sarge, if at all possible, and not be held up by depending packages which aren't up to speed. What do you think? -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: possible mass bug filing: spamassassin 3
On Wed, Oct 06, 2004 at 11:52:04AM +0200, martin f krafft wrote: If you'd be so kind as to refer to #274993, I think we have a problem. A number of packages (see the bug report) depend on spamassassin, but some are not going to work with version 3, which changed the API considerably. The example here is spamass-milter, which simply does not work. IMHO the easiest solution is to introduce a spamassassin2 package which conflicts with the spamassassin package, and to have spamass-milter and friends depend on spamassassin2. Actually fixing the programs to use the 3.0 API can then happen as a subsequent step - and if it doesn't happen by release time, we still have spamassassin 3 in stable... Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯
Re: possible mass bug filing: spamassassin 3
On Wed, 06 Oct 2004, martin f krafft wrote: b. provide a new version that can interface with spamassassin 3. Just for the record, current amavisd-new can talk to spamassassin 3, even if not perfectly (chroots needs some... tweaking). As for the bugs, go ahead. spamassassin 2 is pretty much useless, and anything that depends/recommends spamassassin and cannot keep up with it really needs to be booted off the archive (if it cannot be fixed fast enough). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: possible mass bug filing: spamassassin 3
On Wed, Oct 06, 2004 at 11:52:04AM +0200, martin f krafft wrote: Hi folks, Spamassassin 3 is finally in unstable. Thanks to Duncan (and possibly others involved)! Just for record, I and a few other people removed spamassassin 3 on my workstation due to performace problems. It is really a memory and cpu hog. I doubt it is usable as is on any box without a good deal of horsepower and memory. I would add at least a big warning in its NEWS file about this, until its problems will be not solved. -- Francesco P. Lovergine
Re: possible mass bug filing: spamassassin 3
also sprach Francesco P. Lovergine [EMAIL PROTECTED] [2004.10.06.1418 +0200]: Just for record, I and a few other people removed spamassassin 3 on my workstation due to performace problems. It is really a memory and cpu hog. I have to confirm. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: possible mass bug filing: spamassassin 3
* Francesco P. Lovergine ([EMAIL PROTECTED]) [041006 14:20]: On Wed, Oct 06, 2004 at 11:52:04AM +0200, martin f krafft wrote: Spamassassin 3 is finally in unstable. Thanks to Duncan (and possibly others involved)! Just for record, I and a few other people removed spamassassin 3 on my workstation due to performace problems. It is really a memory and cpu hog. I doubt it is usable as is on any box without a good deal of horsepower and memory. I would add at least a big warning in its NEWS file about this, until its problems will be not solved. If this is not solved, we really should consider to re-introduce spamassassin 2 as spamassassin, and the version 3 as spamassassin3. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: possible mass bug filing: spamassassin 3
On Wed, Oct 06, 2004 at 02:32:09PM +0200, Andreas Barth wrote: If this is not solved, we really should consider to re-introduce spamassassin 2 as spamassassin, and the version 3 as spamassassin3. Or we should not consider it. In such case 2.64 will become obsolete even faster than 2.20 did in woody, since it is obsoleted by 3.x. Having 2.64 which is only worth having for the bayessian methods is brainless since we have other bayesian tools for the trick, some of them considered even more efficient: bogofilter, dspam, crm114,... J -- Jesus Climent info:www.pumuki.org Unix SysAdm|Linux User #66350|Debian Developer|2.4.27|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 I don't wanna hear old sad bastard music Barry, I just want something I can ignore. --Rob (High Fidelity)
Re: possible mass bug filing: spamassassin 3
On Wed, Oct 06, 2004 at 02:40:47PM +0200, Jesus Climent wrote: On Wed, Oct 06, 2004 at 02:32:09PM +0200, Andreas Barth wrote: If this is not solved, we really should consider to re-introduce spamassassin 2 as spamassassin, and the version 3 as spamassassin3. Or we should not consider it. In such case 2.64 will become obsolete even faster than 2.20 did in woody, since it is obsoleted by 3.x. Having 2.64 which is only worth having for the bayessian methods is brainless since we have other bayesian tools for the trick, some of them considered even more efficient: bogofilter, dspam, crm114,... Unfortunately, it is also used as the only anti-spam plugin in other software, such as amavis AFAIK. As pointed before anyway, releasing those kind of tools and thinking of having them frozen for a couple of years is a non-sense, plain and clear. The volatile archive is having more and more sense. -- Francesco P. Lovergine
Re: possible mass bug filing: spamassassin 3
* Francesco P. Lovergine ([EMAIL PROTECTED]) [041006 15:05]: On Wed, Oct 06, 2004 at 02:40:47PM +0200, Jesus Climent wrote: On Wed, Oct 06, 2004 at 02:32:09PM +0200, Andreas Barth wrote: Just for record, I and a few other people removed spamassassin 3 on my workstation due to performace problems. It is really a memory and cpu hog. I doubt it is usable as is on any box without a good deal of horsepower and memory. I would add at least a big warning in its NEWS file about this, until its problems will be not solved. If this is not solved, we really should consider to re-introduce spamassassin 2 as spamassassin, and the version 3 as spamassassin3. Unfortunately, it is also used as the only anti-spam plugin in other software, such as amavis AFAIK. As pointed before anyway, releasing those kind of tools and thinking of having them frozen for a couple of years is a non-sense, plain and clear. The volatile archive is having more and more sense. Sorry, but the basic problem I'm speaking about has nothing to do with volatile - but just that requiring substancially more memory might be a bad idea. We still have inn1 and inn2 parallel (and I'm a happy user of inn1), for similar reasons. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: possible mass bug filing: spamassassin 3
On Oct 06, Andreas Barth [EMAIL PROTECTED] wrote: Sorry, but the basic problem I'm speaking about has nothing to do with volatile - but just that requiring substancially more memory might be a bad idea. We still have inn1 and inn2 parallel (and I'm a happy user of inn1), for similar reasons. But the problem still stands: spamassassin 2.x should not be used anymore because it's obsolete. People should either work to reduce the memory usage of 3.x or switch to a different filtering program. -- ciao, | Marco | [8385 ac29DiCFF88Ek] signature.asc Description: Digital signature
Re: possible mass bug filing: spamassassin 3
On Wed, Oct 06, 2004 at 11:52:04AM +0200, martin f krafft wrote: If you'd be so kind as to refer to #274993, I think we have a problem. A number of packages (see the bug report) depend on spamassassin, but some are not going to work with version 3, which changed the API considerably. The example here is spamass-milter, which simply does not work. The submitter of the bug report suggests to add a conflict to spamassassin. To me, this is coming at it from the wrong angle. I my well understand this all wrong, but if SA conflicts with spamass-milter, which is in testing, it is not going to be able to trickle into sarge until a new spamass-milter has been uploaded and has trickled to sarge first. Instead, I propose that the packages depending on spamassassin should be removed from sarge unless it is known that they work with spamassassin 3. This is backwards. The conflicts must be added in spamassassin in order that we don't forget to remove said other packages from sarge if necessary. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: possible mass bug filing: spamassassin 3
also sprach Colin Watson [EMAIL PROTECTED] [2004.10.06.1616 +0200]: This is backwards. The conflicts must be added in spamassassin in order that we don't forget to remove said other packages from sarge if necessary. That prevents SA from entering Sarge. I say: remove all the others from Sarge unless or until they comply with SA 3. I fail to see yours and Adrian's rationale for why spamassassin should collide with a software, when the software in fact collides with spamassassin. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: possible mass bug filing: spamassassin 3
Scripsit Colin Watson [EMAIL PROTECTED] This is backwards. The conflicts must be added in spamassassin in order that we don't forget to remove said other packages from sarge if necessary. Won't work, at least not by itself. Since we expect the other packages to sooner or later be updated to work with spamassassin3, a conflict from spamassassin would need to be a versioned one. But how is the spamassassin maintainer to know which future version of the client package will work with spamassassin3? The only fully watertight solution would be to have spamassassin 3 declare Conflicts: client-package-1 (= $currentversion1), client-package-2 (= $currentversion2), ... client-package-N (= $currentversionN) and arrange for *each* *future* version of the client packages to declare Conflicts: spamassassin (= 3.0) until they have been fixed. (But release-manager intervention would still be needed for SA3 to proceed to testing before all current clients have been fixed). -- Henning Makholm The compile-time type checker for this language has proved to be a valuable filter which traps a significant proportion of programming errors.
Re: possible mass bug filing: spamassassin 3
On Wed, Oct 06, 2004 at 04:33:37PM +0200, martin f krafft wrote: I say: remove all the others from Sarge unless or until they comply with SA 3. OK, so you want to remove exim4 from sarge, thus breaking installation altogether? I fail to see yours and Adrian's rationale for why spamassassin should collide with a software, when the software in fact collides with spamassassin. Eh. spamassassin has had a long-standing, well-known API, and suddenly changes it. It is _SA_ which broke this, not the other applications. /* Steinar */ -- Homepage: http://www.sesse.net/
Re: possible mass bug filing: spamassassin 3
* martin f krafft | What do you think? API changed generally means you bump soname. Why not for SA as well. Also, SA3 is useless, as it eats about half a gig of RAM on my system. Per child. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: possible mass bug filing: spamassassin 3
Tollef Fog Heen wrote: * martin f krafft | What do you think? API changed generally means you bump soname. Why not for SA as well. Also, SA3 is useless, as it eats about half a gig of RAM on my system. Per child. After running for a little while, PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 2024 adamm 15 0 176m 42m 36m S 2.0 4.2 0:37.11 mozilla-thunder 2109 adamm 15 0 80764 28m 29m S 0.0 2.8 0:05.19 firefox-bin 1271 root 5 -10 156m 24m 146m S 0.3 2.5 0:58.67 XFree86 2925 root 25 0 25320 22m 4836 S 0.0 2.2 0:10.05 spamd 2929 root 25 0 25324 22m 4836 S 0.0 2.2 0:09.14 spamd 2926 root 24 0 25320 22m 4836 S 0.0 2.2 0:09.15 spamd 2927 root 24 0 25320 22m 4836 S 0.0 2.2 0:09.15 spamd 2928 root 24 0 25320 22m 4836 S 0.0 2.2 0:09.15 spamd 2924 root 25 0 24040 21m 4836 S 0.0 2.1 0:00.48 spamd I wouldn't say it uses half a gig of ram. Something else is going on.. - Adam -- Building your applications one byte at a time http://www.galacticasoftware.com
Re: possible mass bug filing: spamassassin 3
also sprach Adam Majer [EMAIL PROTECTED] [2004.10.06.1934 +0200]: After running for a little while, [...] I wouldn't say it uses half a gig of ram. Something else is going on.. I had -m10 passed to spamd for 2.64. When I upgraded, I left that in place. I almost hosed a server that went up to load 30 immediately. It took me 40 minutes to get a shell, another 30 to halt postfix and unload SA. Now it's running at -m5 (the suggested value) and I have not had problems since. Of course, now I only get half the throughput, and my queue has not emptied for a whole day because SA is unable to keep up. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: possible mass bug filing: spamassassin 3
On Wed, 06 Oct 2004, martin f krafft wrote: also sprach Adam Majer [EMAIL PROTECTED] [2004.10.06.1934 +0200]: After running for a little while, [...] I wouldn't say it uses half a gig of ram. Something else is going on.. I had -m10 passed to spamd for 2.64. When I upgraded, I left that in place. I almost hosed a server that went up to load 30 immediately. It took me 40 minutes to get a shell, another 30 to halt postfix and unload SA. How much network latency do you have? If -m10 is helping you, you must be waiting on TCP/IP requests like crazy. Now it's running at -m5 (the suggested value) and I have not had problems since. Of course, now I only get half the throughput, and my queue has not emptied for a whole day because SA is unable to keep up. Fishy, fishy... find out why it is taking so much time to process your messages that -m10 would help. Disable non-local checks for a while, check your DNS cache (you have one on each of your MTA and SA boxes, don't you?)... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: possible mass bug filing: spamassassin 3
On Wed, 06 Oct 2004, Tollef Fog Heen wrote: Also, SA3 is useless, as it eats about half a gig of RAM on my system. Per child. This is a ridiculous big RSS. What are you telling SA to do? Load 20MB of AWL and 20MB of Bayes data into memory? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: possible mass bug filing: spamassassin 3
martin f krafft wrote: also sprach Adam Majer [EMAIL PROTECTED] [2004.10.06.1934 +0200]: After running for a little while, [...] I wouldn't say it uses half a gig of ram. Something else is going on.. I had -m10 passed to spamd for 2.64. When I upgraded, I left that in place. I almost hosed a server that went up to load 30 immediately. It took me 40 minutes to get a shell, another 30 to halt postfix and unload SA. Now it's running at -m5 (the suggested value) and I have not had problems since. Of course, now I only get half the throughput, and my queue has not emptied for a whole day because SA is unable to keep up. Spamassassin 2.63 used less ram, PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 14615 spamd 16 15 23204 11M 4708 S N 0.0 2.3 0:24 spamd so that would be about 40% of what spamassassin 3.0 seems to be using at the start and about 1/4 of what 3.0 used in my little run below. 3.0 is also seems slower than 2.63 probably because new/better tests were added.. I've also run spamassassin (spamassassin --mbox mbox obox), where mbox is about 850 messages. It took spamassassin, real2m45.994s user2m34.211s sys 0m1.949s It also used a max of 40MB during the run. This means that spamassassin 3.0 scans at a rate of about 5 message per second on Athlon 2000+. Max thoughput for the day should be at about 400k messages, but probably 100k should be a better target. Concurrency is not going to help you unless CPU is idle. In my case, -m 2 would use 100% CPU (not using razor). - Adam PS. 3.0 seems *much* better at detecting obfuscated spam. Where 2.63 gave an email 0.5, the new version gives it 7.3. Spam beware! :) On the other hand, this is a type of spam arms race. Running spamassassin will become more expensive as it improves. -- Building your applications one byte at a time http://www.galacticasoftware.com
Re: possible mass bug filing: spamassassin 3
On Wed, Oct 06, 2004 at 11:52:04AM +0200, martin f krafft wrote: Hi folks, Spamassassin 3 is finally in unstable. Thanks to Duncan (and possibly others involved)! Well, I'm not at all convinced this is so good. Didn't the RMs say something about 'no major new upstream releases', in order to be able to ship sarge this year? In addition to the enormous amount of reports of sa3 taken down systems, or causing mail loss, by people who I regard as pretty clueful[1], I think it's pretty obvious it would be a very bad move to let sa3 into sarge. sa3 is IMNSHO a sarge+1, aka etch project. --Jeroen [1] Tollef Fog Heen and Manoj Srivastava come to mind -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: possible mass bug filing: spamassassin 3
also sprach Henrique de Moraes Holschuh [EMAIL PROTECTED] [2004.10.06.2023 +0200]: How much network latency do you have? If -m10 is helping you, you must be waiting on TCP/IP requests like crazy. I am not sure. A normal run via spamd takes about 3 seconds per message. At peak times, the server sees about 40 messages in that interval. Fishy, fishy... find out why it is taking so much time to process your messages that -m10 would help. Disable non-local checks for a while, check your DNS cache (you have one on each of your MTA and SA boxes, don't you?)... Yes, I run dnscache on all boxes. MTA and SA are on the same box. I only have one box with SA 3.0 so far. Considering that RBL checks are almost not cacheable by nature, I can fully understand. One pass through spamd causes maybe 20 DNS requests... I think 3 seconds to have them all answered is not bad. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: possible mass bug filing: spamassassin 3
Steinar H. Gunderson [u] wrote on 06/10/2004 18:29: On Wed, Oct 06, 2004 at 04:33:37PM +0200, martin f krafft wrote: I say: remove all the others from Sarge unless or until they comply with SA 3. OK, so you want to remove exim4 from sarge, thus breaking installation altogether? ??? Since when does exim4 use SA by default? AFAIK, you have to specifically configure it to use it. Right? If so, there should be no reason to remove it or for it to conflict with SA3. Eh. spamassassin has had a long-standing, well-known API, and suddenly changes it. It is _SA_ which broke this, not the other applications. If a program is a front-end for SA and only works if SA is installed, then it should keep up with any changes SA is doing to its API. SA3 has long before been in beta testing AFAIK, so it should've been quite easy for those maintainers to fix their programs. And SA3 API isn't _that_ much different from SA2.6 API for the most used interfaces. I had to change as much as 3 lines in SpamPD 2.12 to make it work with SA3, though upstream did a cleaner job by supporting SA 2.7, SA 3.0 and SA 3.0 in one script as of SpamPD 2.2(0). cu, sven
Re: possible mass bug filing: spamassassin 3
On Wed, 06 Oct 2004, martin f krafft wrote: also sprach Colin Watson [EMAIL PROTECTED] [2004.10.06.1616 +0200]: This is backwards. The conflicts must be added in spamassassin in order that we don't forget to remove said other packages from sarge if necessary. That prevents SA from entering Sarge. Which is basically what should happen until those packages are fixed, since SA (=3) makes those packages unuseable. An easier solution is to provide both the older API information and the newer API information in the response for now, since there's no reason to break compatibility like has been done. The major change that I'm aware of is the nonsensical change of 'hits' to 'score'[1] in the output. Just provide both 'hits' and 'score' and this particular problem will go away. [This was the major issue facing spamass-milter, which is fixed in -7 by checking for the other if it can't find the first.] Don Armstrong 1: I'll grant that score is more logical than hit, but I really don't see the point... -- I'd sign up in a hot second for any cellular company whose motto was: We're less horrible than a root canal with a cold chisel. -- Cory Doctorow http://www.donarmstrong.com http://rzlab.ucr.edu
Re: possible mass bug filing: spamassassin 3
also sprach Don Armstrong [EMAIL PROTECTED] [2004.10.06. +0200]: The major change that I'm aware of is the nonsensical change of 'hits' to 'score'[1] in the output. Just provide both 'hits' and 'score' and this particular problem will go away. [This was the major issue facing spamass-milter, which is fixed in -7 by checking for the other if it can't find the first.] I would have to check closely, which is out of the question right now... but I guess this could be even done in the configuration. 1: I'll grant that score is more logical than hit, but I really don't see the point... It's their perfect right in some ways. And incredibly silly in others. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: possible mass bug filing: spamassassin 3
* martin f krafft ([EMAIL PROTECTED]) [041006 16:35]: also sprach Colin Watson [EMAIL PROTECTED] [2004.10.06.1616 +0200]: This is backwards. The conflicts must be added in spamassassin in order that we don't forget to remove said other packages from sarge if necessary. That prevents SA from entering Sarge. That's a feature. I say: remove all the others from Sarge unless or until they comply with SA 3. I guess spamassassin3 won't be added to sarge. Can you remember the upload of the latest kde to unstable, and the explicit NO from the release masters? Can you remember that already before that it was said no new upstream versions? Spamassassin 3 is a new upstream version - so, no spamassassin 3 in sarge. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: possible mass bug filing: spamassassin 3
On Wed, Oct 06, 2004 at 10:01:12PM +0200, Sven Mueller wrote: ??? Since when does exim4 use SA by default? AFAIK, you have to specifically configure it to use it. Right? If so, there should be no reason to remove it or for it to conflict with SA3. Well, if I dist-upgrade my mail server so a new spamassassin comes in, my mail setup breaks. Now, that is clearly broken, and an RC bug on some package. If a program is a front-end for SA and only works if SA is installed, then it should keep up with any changes SA is doing to its API. Wrong. SA should not change its API in an incompatible fashion without also bumping its soname (ie. the package name in this case), like any other library. And SA3 API isn't _that_ much different from SA2.6 API for the most used interfaces. In that case, it should provide a backwards-compatible interface. /* Steinar */ -- Homepage: http://www.sesse.net/
Re: possible mass bug filing: spamassassin 3
also sprach Andreas Barth [EMAIL PROTECTED] [2004.10.06.2234 +0200]: I guess spamassassin3 won't be added to sarge. Can you remember the upload of the latest kde to unstable, and the explicit NO from the release masters? Can you remember that already before that it was said no new upstream versions? Spamassassin 3 is a new upstream version - so, no spamassassin 3 in sarge. Fair enough. But what if we provide spamassassin3 in addititon to spamassassin (2.64) ? SA3 is where it's at (within SA, there's other/better stuff). Development of SA2 will stop, or has already. No matter whether security.d.o or volatile.d.o, it would be favourable to be able to push improvements to SA3 rather than replace SA2 with SA3 through these channels. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: possible mass bug filing: spamassassin 3
* martin f krafft ([EMAIL PROTECTED]) [041006 22:40]: also sprach Andreas Barth [EMAIL PROTECTED] [2004.10.06.2234 +0200]: I guess spamassassin3 won't be added to sarge. Can you remember the upload of the latest kde to unstable, and the explicit NO from the release masters? Can you remember that already before that it was said no new upstream versions? Spamassassin 3 is a new upstream version - so, no spamassassin 3 in sarge. Fair enough. But what if we provide spamassassin3 in addititon to spamassassin (2.64) ? That can be done of course - as well as we have exim4 in addition to exim, or inn2 in addition to inn. But in this case, reverting the latest upload of spamassassin might be a good idea. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: possible mass bug filing: spamassassin 3
El mi, 06-10-2004 a las 08:03 -0300, Henrique de Moraes Holschuh escribi: On Wed, 06 Oct 2004, martin f krafft wrote: b. provide a new version that can interface with spamassassin 3. Just for the record, current amavisd-new can talk to spamassassin 3, even if not perfectly (chroots needs some... tweaking). As for the bugs, go ahead. spamassassin 2 is pretty much useless, and anything that depends/recommends spamassassin and cannot keep up with it really needs to be booted off the archive (if it cannot be fixed fast enough). But the problem is that spamassassin 2 works in usual people MX systems (which usually is your older desktop) while SA3 has a big problem in that machines, making it unusable. And, BTW, since version 2.64 we have: - Rules backported from 3.0.0 So though SA3 can make other things better (bayesian and so), SA2 is not so obsolete, and basically *works* in machines in which SA3 won't. (And my home server is a AMD K6-II 450, with 192MB RAM, not bad for my own amount of daily mail) Cheers, -- Jose Carlos Garcia Sogo [EMAIL PROTECTED] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: possible mass bug filing: spamassassin 3
also sprach Andreas Barth [EMAIL PROTECTED] [2004.10.06.2244 +0200]: That can be done of course - as well as we have exim4 in addition to exim, or inn2 in addition to inn. But in this case, reverting the latest upload of spamassassin might be a good idea. I can't wait for Duncan to join in and give us his view. I would vote for the spamassassin3 approach. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: possible mass bug filing: spamassassin 3
On Oct 06, Steinar H. Gunderson [EMAIL PROTECTED] wrote: Well, if I dist-upgrade my mail server so a new spamassassin comes in, my mail setup breaks. Now, that is clearly broken, and an RC bug on some package. We are talking about unstable. -- ciao, | Marco | [8393 idbw1qdMcWarw] signature.asc Description: Digital signature
Re: possible mass bug filing: spamassassin 3
Steinar H. Gunderson [u] wrote on 06/10/2004 22:37: On Wed, Oct 06, 2004 at 09:10:39PM +0200, Sven Mueller wrote: ??? Since when does exim4 use SA by default? AFAIK, you have to specifically configure it to use it. Right? If so, there should be no reason to remove it or for it to conflict with SA3. Well, if I dist-upgrade my mail server so a new spamassassin comes in, my mail setup breaks. Now, that is clearly broken, and an RC bug on some package. If it were happening in stable, I am 100% with you. It it is with regards to testing, well, I'm between 30% and 70% with you. More on 60% currently with the release pending any month now ;-) With regards to unstable, I'm more like 10% with you on this matter. If it is possible for a maintainer to avoid such breakages, he should 100% do that. But with spamassassin, I don't really see how the maintainer should do that. Many frontends work with the new spamassassin with no change at all, and those would certainly like to benefit from SA3 without needing to change their packages. Many other frontends break. But how should the SA maintainer know which frontends break and which don't? He would only want to Conflict with those that break, leaving the others alone. If a program is a front-end for SA and only works if SA is installed, then it should keep up with any changes SA is doing to its API. Wrong. SA should not change its API in an incompatible fashion without also bumping its soname (ie. the package name in this case), like any other library. Well, perl modules don't have an SO name. And actually, the library part of SA isn't intended to be the most often used one. More specifically, the spamassassin has always stated that though they try to keep the API, it is not guaranteed to be compatible from one revision (sic!) to another. The only part that was guaranteed to maintain their interfaces for at least major 1 version (obsoleting but still supporting in 3.x what was supported in 2.x) where the executables spamassassin, sa-learn, spamc, spamd. And SA3 API isn't _that_ much different from SA2.6 API for the most used interfaces. In that case, it should provide a backwards-compatible interface. Well, they could probably do that for many parts (the most often used ones, actually), but I doubt that it is possible for all parts. cu, sven
Re: possible mass bug filing: spamassassin 3
On Wed, 6 Oct 2004 16:33:37 +0200, martin f krafft [EMAIL PROTECTED] said: also sprach Colin Watson [EMAIL PROTECTED] [2004.10.06.1616 +0200]: This is backwards. The conflicts must be added in spamassassin in order that we don't forget to remove said other packages from sarge if necessary. That prevents SA from entering Sarge. Which is a good thing, neh? A brand new version ought to kick around in Sid until the rough edges are knocked off. I say: remove all the others from Sarge unless or until they comply with SA 3. No, this is backwards, Currently, in Sarge, we have a bunch of packages working together -- using SA2 interfaces. So people have SA, and all the other things that make use of the API. Under your scheme, Sarge would be bereft of all the packages that build on SA that have not changed, at the cost of something that has shown all evidence of being flakey and not ready for prime time yet. manoj -- When marriage is outlawed, only outlaws will have inlaws. Jef Poskanzer ([EMAIL PROTECTED]) Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: possible mass bug filing: spamassassin 3
also sprach Manoj Srivastava [EMAIL PROTECTED] [2004.10.06.2256 +0200]: Under your scheme, Sarge would be bereft of all the packages that build on SA that have not changed, at the cost of something that has shown all evidence of being flakey and not ready for prime time yet. My scheme was devised before I really felt the wrath of the SA3 gods. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: possible mass bug filing: spamassassin 3
* Marco d'Itri ([EMAIL PROTECTED]) [041006 23:05]: On Oct 06, Steinar H. Gunderson [EMAIL PROTECTED] wrote: Well, if I dist-upgrade my mail server so a new spamassassin comes in, my mail setup breaks. Now, that is clearly broken, and an RC bug on some package. We are talking about unstable. We are talking about a package aimed for next stable. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: possible mass bug filing: spamassassin 3
On Wed, Oct 06, 2004 at 10:51:46PM +0200, Jose Carlos Garcia Sogo wrote: But the problem is that spamassassin 2 works in usual people MX systems (which usually is your older desktop) while SA3 has a big problem in that machines, making it unusable. And, BTW, since version 2.64 we have: - Rules backported from 3.0.0 So though SA3 can make other things better (bayesian and so), SA2 is not so obsolete, and basically *works* in machines in which SA3 won't. I'm not really sure what you mean by rules backported from 3.0.0. Unfortunately, rules are fairly linked to releases. (And my home server is a AMD K6-II 450, with 192MB RAM, not bad for my own amount of daily mail) Perhaps you simply need to tune the -m option. Spamassassin has switched to a preforking model (similar to apache) rather than a spawning option, so the number specified by -m should be decreased. -- Duncan Findlay signature.asc Description: Digital signature
Re: possible mass bug filing: spamassassin 3
On Wed, Oct 06, 2004 at 10:37:04PM +0200, Steinar H. Gunderson wrote: On Wed, Oct 06, 2004 at 10:01:12PM +0200, Sven Mueller wrote: ??? Since when does exim4 use SA by default? AFAIK, you have to specifically configure it to use it. Right? If so, there should be no reason to remove it or for it to conflict with SA3. Well, if I dist-upgrade my mail server so a new spamassassin comes in, my mail setup breaks. Now, that is clearly broken, and an RC bug on some package. I'm not really sure why or how your mail server breaks when a new spamassassin comes in. If you're talking about exiscan-acl included with exim4-daemon-heavy, it works fine with SpamAssassin 3. Otherwise, it must be a local modification, which I can't speak to unless I see it. If a program is a front-end for SA and only works if SA is installed, then it should keep up with any changes SA is doing to its API. Wrong. SA should not change its API in an incompatible fashion without also bumping its soname (ie. the package name in this case), like any other library. As far as I know, few programs depend on the Mail::SpamAssassin modules. Most choose to use the scripts instead. And SA3 API isn't _that_ much different from SA2.6 API for the most used interfaces. Actually, virtually any program using SpamAssassin through the modules will need to be changed. Most simply use the scripts, or spamc/spamd or the SPAMD protocol directly. (These are all fine.) In that case, it should provide a backwards-compatible interface. This was contemplated, but deemed to be difficult and ugly. -- Duncan Findlay signature.asc Description: Digital signature
Re: possible mass bug filing: spamassassin 3
On Wed, Oct 06, 2004 at 01:22:02PM -0700, Don Armstrong wrote: The major change that I'm aware of is the nonsensical change of 'hits' to 'score'[1] in the output. Just provide both 'hits' and 'score' and this particular problem will go away. [This was the major issue facing spamass-milter, which is fixed in -7 by checking for the other if it can't find the first.] In configuration, both 'hits' and 'score' are accepted as of right now (and this is likely to remain for a while). I don't think we were aware of much that actually parses output and searches for these strings (which are configurable anyways, AFAIK). Don Armstrong 1: I'll grant that score is more logical than hit, but I really don't see the point... The point is that we want SpamAssassin to be more user friendly, and the opportunity for making such changes is really limited to major releases. -- Duncan Findlay signature.asc Description: Digital signature
Re: possible mass bug filing: spamassassin 3
On Wed, Oct 06, 2004 at 06:43:47PM +0200, Tollef Fog Heen wrote: * martin f krafft | What do you think? API changed generally means you bump soname. Why not for SA as well. Also, SA3 is useless, as it eats about half a gig of RAM on my system. Per child. Umm... I'd like to see that Most of the time people misinterpret how much memory is using. The majority of it is shared memory, but is not reported as such by top (etc) since that only reports memory used by shared libraries. I suspect the actual memory used is a lot less than that. Furthermore, you should use the -m option to limit the number of children to something sane, like 5 or so. -- Duncan Findlay signature.asc Description: Digital signature
Re: possible mass bug filing: spamassassin 3
On Wed, Oct 06, 2004 at 11:52:04AM +0200, martin f krafft wrote: I really think spamassassin 3 should make it into Sarge, if at all possible, and not be held up by depending packages which aren't up to speed. I'm currently inclined to leave 2.64 in sarge (as has been my intention ever since uploading 3.0.0). While it would be nice to get spamassassin 3.0.0 in to sarge, it's too late and we'd probably need to wait until 3.0.1 anyways (3.0.0 seems to have a couple of issues that are fixed in .1). After reading the discussion, the only other option I'd consider at this moment would be putting a spamassassin3 package in sarge. Unfortunately, I don't really feel this would be particularly useful, for the same reasons spamassassin 2.64 won't be useful. SpamAssassin really needs to be kept more up to date than that. While SpamAssassin 3 will have more staying power than 2.64, it'll still go out of date well before sarge+1's release. I don't feel that people will bother upgrading from spamassassin to spamassassin3 (3.0.0) when 3.2.x is around. (I may be overestimating the speed at which spamassassin releases, but then again, woody has 2.20, which is so incredibly obsolete right now, I wonder if it does more harm than good.) The truth is a large portion of stable users rely on spamassassin backports. Packaging spamassassin3 right now is probably not all that useful. -- Duncan Findlay signature.asc Description: Digital signature
