From: Justin Mason <jm@jmason.org> Subject: [SA-Announce] SpamAssassin 2.61 released! Date: December 9, 2003 2:06:05 AM EST To: SpamAssassin-announce@lists.sourceforge.net Cc: SpamAssassin-devel@lists.sourceforge.net, SpamAssassin-talk@lists.sourceforge.net Downloading ----------- Pick it up from: http://SpamAssassin.org/released/Mail-SpamAssassin-2.61.tar.gz http://SpamAssassin.org/released/Mail-SpamAssassin-2.61.tar.bz2 http://SpamAssassin.org/released/Mail-SpamAssassin-2.61.zip md5sum: 6521ad3e6ed5a2eba35476c43c1697b7 Mail-SpamAssassin-2.61.tar.gz 25a87ca67c1550360e1378c816301b53 Mail-SpamAssassin-2.61.tar.bz2 8ab5e24ddb64f8a7d9d0299a72b3ea0b Mail-SpamAssassin-2.61.zip sha1sum: da8f10c1c7eb91f2fced05366f4d792bcb6255ec Mail-SpamAssassin-2.61.tar.gz bf161bc92f33bdad298daefc279e2b85efa34f7d Mail-SpamAssassin-2.61.tar.bz2 050cd37240b34b7d0f1bf31df7cb46fb0ad50678 Mail-SpamAssassin-2.61.zip Or on CPAN shortly, once the mirrors update. The release files also have a .asc accompanying them. The file serves as an external GPG signature for the given release file. The signing key is available via the wwwkeys.pgp.net keyserver, as well as http://www.spamassassin.org/released/GPG-SIGNING-KEY The key information is: pub 1024D/265FA05B 2003-06-09 SpamAssassin Signing Key <release@spamassassin.org> Key fingerprint =3D 26C9 00A4 6DD4 0CD5 AD24 F6D7 DEE0 1987 265F A05B Summary of major changes since 2.60 ----------------------------------- - Dramatically reduced memory usage of Bayes expiry. - avoid false positives on Outlook 2003 messages, mails from Mac, Palm, and localized versions of Eudora, several AOL MUAs, and newer versions of The Bat! - new set of French translations from Michel Bouissou - updated to reflect new Dynablock DNSBL location - avoids a possible hole that was giving AWL bonuses to spammer forgeries on some networks - miscellaneous bug fixes --j.
As there is an update, I suggest moving dev-perl/Mail-SpamAssassin to net-mail/spamassassin I don't know why spamassassin is in dev-perl, it is not a tool nor a library for perl-devs, it's an applucation written in perl. But I don't think we sort applications by their programming language, but by their usage.
I second that thought. Also change the name to spamassassin? Mail-SpamAssassin is kinda kludgy.
For what it's worth, it used to be in net-mail, and it was called spamassassin. Spamassassin turns out to be a special case, because it is both an application and a set of perl modules, so a case could be made for either.
No reply from the perl-people. To the perl@gentoo.org: Is it okay for you if I takeover maintainership of spamassassin? To all: is it okay to move spamassassin from dev-perl/Mail-SpamAssassin to net-mail/spamassassin? If there are no replys, I'll do the changes in a few days and commit an updated spamassassin.
Hanno: I also offered to maintain the SpamAssassin ebuild, in PM to rac and mcummings. No reply till now, maybe they're on vacation :) I'm one of the SA developers, so I more or less know whats going on in that stuff and am very keen to get updates of the packages out quickly if needed. But if you'd have an eye on the stuff it'd be ok, too. About moving to net-mail: That's IMO not a so good idea at the moment. SA actually offers a bunch of perl libs which are used by AMaViS and spamass-milter (and probably others). So dev-perl is where at least the libs belong to. What I thought about was splitting up the package into dev-perl/Mail-SpamAssassin (the libs) net-mail/spamassassin (spamassassin, sa-learn, spamc) net-mail/spamassassin-daemon (spamd) net-mail/spamassassin-tools (some tools from aren't yet distributed) The latter three would depend on the first one of course. Splitting off the clients and daemon etc. would make it possible to have a more fine-grained check for dependencies. And to put the stuff where it logically belongs to. This (and the move at all) should not happen for 2.61 though as 2.61 is just a bug fix release for 2.60 and one doesn't want to change logics for bug fixes :) Whatever is decided (splitting or moving or whatever) should not happen before 2.70 (the next feature release).
I don't think that my opinion actually matters, but could you please put this bugfix release into portage and the decide upon the future place of SpamAssassin in Portage and make this change with 2.70 or whatever becomes the next major release?
Hey, I know most people on here will have done this themselves (if they wanted to), but for the others... I just mod'd the 2.60-r2 ebuild to work for the 2.70-CVS release. One weird thing is ExtUtils::MakeMaker complains about wanting 6.11 or higher, even though it's already 6.20. Thankfully it's only a warning. http://ruled.net/files/gentoo/Mail-SpamAssassin-2.70.ebuild
2.61 in portage.
