Bug 35423 – spamassassin 2.61 released, bump needed

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Rajiv Aaron Manglani (RETIRED) 2003-12-09 01:14:30 UTC]

From:   Justin Mason <[e-mail]>
Subject: [SA-Announce] SpamAssassin 2.61 released!
Date: December 9, 2003 2:06:05 AM EST
To:   [e-mail]
Cc:   [e-mail], [e-mail]

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 <[e-mail]>
     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.

[Comment 1 Hanno Böck 2003-12-10 05:10:41 UTC]

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.

[Comment 2 Nick Hadaway 2003-12-10 07:31:20 UTC]

I second that thought.  Also change the name to spamassassin?  Mail-SpamAssassin is kinda kludgy.

[Comment 3 Grant Goodyear (RETIRED) 2003-12-10 08:39:06 UTC]

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.

[Comment 4 Hanno Böck 2003-12-15 03:15:49 UTC]

No reply from the perl-people.
To the [e-mail]: 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.

[Comment 5 Malte S. Stretz 2003-12-15 05:20:23 UTC]

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).

[Comment 6 Steffen Weber 2003-12-17 10:51:17 UTC]

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?

[Comment 7 Richard 2003-12-17 19:51:32 UTC]

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

[Comment 8 Robert Coie (RETIRED) 2003-12-19 16:11:56 UTC]

2.61 in portage.