Yesterday we released the pre3 for SpamAssassin 3.0.0, the final version is expected to hit the shops in about a month. I'll attach an ebuild for 3.0.0-pre3; the app itself probably should not go into portage yet but I'd like some people to test the ebuild itself. For discussion: - I changed the ebuild so that spamd is installed into /usr/sbin instead of /usr/bin. I'd like to do that upstream but unfortunately is that impossible without a whole load of nasty Makefile.PL hacks. Anybody against this? - I heard some complaints about the spamassassin config lying in /etc/mail/spamassassin instead of /etc/spamassassin directly. This ebuild changed that. Advantage: New users will find the config faster, it won't be stored below a directory which is historically used by sendmail. Disadvantage: Old users will wonder why their configs wont work anymore and where the path went. This is still discussed upstream. What else has changed or should be noted: - The SA license has changed. It's now ASL-2. Website etc. has change, too. The download for the preX still go from the old server, the SRC_URI will have to be changed for the final version. - dev-perl/Storable was added as a dependency. It's actually only needed for spamd with user configs enabled but as spamd is the recommended way using SA and user configs are enabled unless you use something special like SQL-stored configs, it is needed for maybe 80% of the users. - The required Net::DNS version was set to 0.34. SA itself isn't too picky about the version but (the optional module) Mail::SPF is. Unfortunately isn't there a package for that module yet, I'll try to put one together (will be a separate bug). Anyway, the current stable version of Net::DNS is > 0.34 anyway. - dev-libs/openssl was added as a dependency if USE=ssl is enabled. I think that one was pulled in via the dev-perl/IO-Socket-SSL dependency anyway but as spamc uses it I preferred to state the dependency explicitly. - The SSL support is now a bit more deterministic: Before if no USE=ssl was given, the SSL support in spamc was enabled if the configure script detected the presence of the libs. That has changed, a missing USE=ssl now measn that spamc won't be linked against OpenSSL. - In 2.63-r1 it was introduced that qmail-spamc was always built (with some bugs), see bug 49448. I introduced a (local) USE-flag qmail for that, which sounds like it could become a global one once :) - Some other stuff I probably forgot. Reproducible: Always Steps to Reproduce:
Created attachment 36002 [details] spamassassin-3.0.0_pre3.ebuild The ebuild.
Created attachment 36003 [details] files/3.0.0-spamd.init The modified init script, now stored with a leading version number.
Created attachment 36004 [details] files/3.0.0-spamd.conf The modified /etc/conf.d file, now also stored with a leading version number.
Seems like the dependency on Storage isn't necessary for perl-5.8.2 as that module is already shipped with that version. Should the Storage dependency moved inside the big else block or is it easier to get rid of that one and just require perl-5.8.2? I don't care too much as 5.8.2 is the oldest ebuild in the tree for IMO quite some time now.
Created attachment 36232 [details] spamassassin-3.0.0_pre3-r1.ebuild Revisited the ebuild after a short chat with ciaranm and rac: - It now DEPENDs on perl-5.8.2. Makes our lives much easier. - Replaces the sed and tr with shell expansion.
The -r1 ebuild worked for me. Can we get this in the tree (masked) so folks can use it if they want? The 3.0 release is much better at detecting spam than the 2.63 version.
Apart from a minor perl hickup it is working fine here with amavisd-new-20040701. A minor fix for the ebuild though: einfo " /usr/share/doc/${P}/INSTALL.gz" should be einfo " /usr/share/doc/${PVR}/INSTALL.gz"
Created attachment 36800 [details] spamassassin-3.0.0_pre4.ebuild Bumped and updated SRC_URI.
Created attachment 36808 [details] spamassassin-3.0.0_pre4-r1.ebuild I have no clue why this one never arrived here though I submitted it yesterday. Thanks for your work Sune, but I added some more changes: * IMPORTANT: The config files are now in the default path /etc/mail/spamassassin again. After some discussion with the other devs we came to the conclusion that the upgrade path is too rocky if we move it. * Yet another einfo is printed about upgrading * /usr/share/doc/${PVR} -> /usr/share/doc/${PF} * make test is enabled again, I will probably disable it for the final (as the tests take ages) but for the prereleases, every watchful eye is welcome :) Comments, flames, cookies?
I installed and tested the 3.0.0-pre4-r1 ebuild. It worked for me.
Created attachment 37549 [details] spamassassin-3.0.0_rc1.ebuild Updated ebuild for the RC1. Changes: * Set sysconfdir fixed to /etc to make sure something like bug 48205 can't happen (I hope). * Changed datadir to be /usr/share/spamassassin/core so other possible ebuilds for rules can use the parent dir, too. * Added a version_tag in 11_gentoo.rc so any possible changes or patches applied to Gentoo's SA can be spotted in bug reports to the upstream devs easily.
Haven't had the time to dig into this one. But somewhere the ebuild tries to write outside the sandbox. All tests successful, 5 tests skipped. Files=65, Tests=1462, 841 wallclock secs (441.61 cusr + 52.71 csys = 494.32 CPU) --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/tmp/sandbox-mail-filter_-_spamassassin-3.0.0_rc1-3119.log" open_wr: /var/dcc/map --------------------------------------------------------------------------------
Will check this out, I had sandbox disabled because another ebuild had issues.
Can't reproduce it. man dcc says about that file DCC clients pick the nearest working DCC server using a small shared or memory mapped file, /var/dcc/map. It contains server names, port numbers, passwords, recent performance measures, and so forth. This file allows clients to use quick retransmission timeouts and to waste little time on servers that have temporarily stopped working or become unreachable. The utility program cdcc(8) is used to maintain this file as well as to check the health of servers. But judging from that I don't think dcc should modify it. Which version of dcc do you have installed? My wild guess is that one of the spamd tests called dcc though it shouldn't if network tests aren't enabled. Could you post the full list of tests run? Especially because on your box is one test less skipped which shouldn't happen. Hmmm... do you have Mail::SPF installed? All tests successful, 6 tests skipped. Files=65, Tests=1460, 478 wallclock secs (258.34 cusr + 60.12 csys = 318.46 CPU)
Woops manually modified mail-filter/dcc-1.2.50 (with dccifd). Tried to downgrad to dcc-1.2.28 in portage but still the same problem. Did you remember to do a rm -rf /var/tmp/portage/spamassassin-3.0.0_rc1/ ? Because during the second run you will not get this error as some of the installation has already been done. And yes I have Mail::SPF installed. Btw dcc-1.2.28.ebuild could use a loving hand.
Ah. Mail::SPF::Query triggers the bug. Investigating...
Will be fixed in rc2 (or the final release, whatever is first). The patch can be found here <http://bugzilla.spamassassin.org/show_bug.cgi?id=3690#c1>.
Created attachment 38120 [details] spamassassin-3.0.0_rc1-r2.ebuild Fresh ebuild for you :) One word in advance: If anybody wants to commit one of this ebuilds to the portage tree, please ask me first! Just because there are still things to fix up -- like for example that this tarball is fetched from my personal website. This time it's not an official RC but a pre-patch version of the next one -- actually, its the current state of the code base which contains a bunch of fixes, especially important in this case stuff in the build system. Whats new in this release, ebuild-wise: * More docu for the masses is installed. Weee... * Even more API docu with 'use doc'. * The ebuild already makes use of the future VERSION_STRING stuff. See the file PACKAGING in the codebase if you want to know whats that exactly. The short version is that it should speed up the build process a bit as some calls to Perl aren't needed anymore. Once that patch goes into the codebase that means (after 3.0.0 was released). The sandbox violation because of DCC still happens on 'make test' from time to time. Fixing the SPF test made it a bit better but I'm still investigating which test is the actual culprit.
Created attachment 39093 [details] spamassassin-3.0.0_rc3.ebuild New ebuild for RC3 (hopefully the last RC). Changes: * All which were in rc1-r2, except that its pulled from the official location again. * Additionally the spf.t test is temporarily removed -- the fix to keep it from running without net tests enabled wasn't complete. Hopefully the dcc sandbox violations are now a thing of the past, too.
Oops, accidently assigned the bug to me.
Created attachment 39289 [details] spamassassin-3.0.0_rc4.ebuild ebuild for the RC4. The only change, ebuild-wise: --- spamassassin-3.0.0_rc3.ebuild 2004-09-07 00:02:03.000000000 +0200 +++ spamassassin-3.0.0_rc4.ebuild 2004-09-10 10:48:00.713407856 +0200 @@ -134,8 +134,6 @@ # FIXME: Remove the following block in the final ebuild. if [ "${PV//[^_]/}" == _ ]; then - # spf.t was fixed after rc3 - rm t/spf.t hasq maketest $FEATURES || perl-module_src_test fi }
Created attachment 39647 [details] spamassassin-3.0.0_rc5.ebuild ebuild for RC5. The final version is scheduled for next week (if no really grave bugs crop up). Changes in the ebuild: * Also applied workaround for bug 62276.
SpamAssassin 3.0.0 final is released!!
Posted. qmail isn't (yet?) a valid USE flag, had to comment out its use for now.
i don't know if this is the correct place to add this, but you need to add Digest-SHA1 as a dependency of spamasssassin-3.0.0. I was unable to compile until I emerged that package.
Already in the depends dev-perl/Digest-SHA1
*** Bug 64966 has been marked as a duplicate of this bug. ***
3.0 release notes: http://issues.apache.org/eyebrowse/ReadMsg?listName=users@spamassassin.apache.org&msgNo=16203
In order to get SPF support I think the perl SPF module has to be added to portage.
Along with: 1 - Net::SMTP (from CPAN) 2 - Mail::SPF::Query (from CPAN) 3 - IP::Country::Fast (from CPAN) 4 - Net::Ident (from CPAN) I'll work on these tonight/tomorrow. Some of extra deps that will need to be added as well, so you'll have to give me a little time.
oops...net-smtp is part of libnet, um, one done...
It seems that the current spamassassin-3.0.0.ebuild breaks amavisd-new. Specifically, amavisd-new is hard-coded to expect all SA rules in the /usr/share/spamassassin directory. This ebuild has the setting "DATADIR=/usr/share/spamassassin/core". Unfortunately amavisd-new will run without any warnings, but when it checks an email, no rules are applied, and the email is always given a score of '0'. Changing this to "DATADIR=/usr/share/spamassassin" corrects the problem and amavisd-new will then run correctly.
amavis ebuild bugs need to be filed in a seperate bug - outside the scope of this "bug" report. In fact, unless there are objections, I'd like to close this bug out - the intention was to track the release of spamassassin 3, which is now in portage. Any bugs with spamassassin or related add ons should be filed seperately.
Re comment #32, I've written some interesting comments on the matter over at bug #64462. Please take a look.
OK, closing this one out. Please file new bugs for new, well, bugs :)
