Apache SpamAssassin 3.3.0 is now available for testing. Reproducible: Always
Created attachment 216625 [details] spamassassin-3.3.0.ebuild Installed OK but failed tests.
Created attachment 216862 [details] 3.2.5-spamd.init Includes fix from Bug 173759 and Bug 243474
Created attachment 217527 [details] spamassassin-3.3.0.ebuild 2010-01-27: SpamAssassin 3.3.0 has been released, a major new release!
Created attachment 217563 [details] spamassassin_test_fail.txt Installs ok but fails tests. I added >=dev-perl/Mail-DKIM-0.37 to DEPEND after reading http://xrl.us/bgtv6c (Link to mail-archives.apache.org) but fails as per attachment.
Test Summary Report ------------------- t/sa_check_spamd.t (Wstat: 0 Tests: 7 Failed: 2) Failed tests: 3-4 t/spamc_B.t (Wstat: 0 Tests: 9 Failed: 1) Failed test: 9 t/spamc_c.t (Wstat: 0 Tests: 2 Failed: 1) Failed test: 1 t/spamc_c_stdout_closed.t (Wstat: 0 Tests: 2 Failed: 1) Failed test: 1 t/spamc_cf.t (Wstat: 0 Tests: 4 Failed: 2) Failed tests: 3-4 t/spamc_E.t (Wstat: 0 Tests: 2 Failed: 1) Failed test: 2 t/spamc_headers.t (Wstat: 0 Tests: 5 Failed: 2) Failed tests: 3-4 t/spamc_optC.t (Wstat: 0 Tests: 9 Failed: 4) Failed tests: 2, 4, 6, 8 t/spamc_optL.t (Wstat: 0 Tests: 16 Failed: 16) Failed tests: 1-16 t/spamc_x_e.t (Wstat: 0 Tests: 7 Failed: 3) Failed tests: 2-4 t/spamc_z.t (Wstat: 0 Tests: 9 Failed: 5) Failed tests: 4-5, 7-9 t/spamd.t (Wstat: 0 Tests: 14 Failed: 5) Failed tests: 5-6, 8-10 t/spamd_allow_user_rules.t (Wstat: 0 Tests: 5 Failed: 1) Failed test: 4 t/spamd_maxchildren.t (Wstat: 0 Tests: 22 Failed: 10) Failed tests: 3-7, 17-21 t/spamd_parallel.t (Wstat: 0 Tests: 20 Failed: 10) Failed tests: 2-6, 16-20 t/spamd_port.t (Wstat: 0 Tests: 4 Failed: 2) Failed tests: 3-4 t/spamd_protocol_10.t (Wstat: 0 Tests: 9 Failed: 3) Failed tests: 2-4 Parse errors: Bad plan. You planned 10 tests but ran 9. t/spamd_report.t (Wstat: 0 Tests: 6 Failed: 3) Failed tests: 3-5 t/spamd_report_ifspam.t (Wstat: 0 Tests: 10 Failed: 3) Failed tests: 3-5 t/spamd_ssl.t (Wstat: 0 Tests: 9 Failed: 5) Failed tests: 4-5, 7-9 t/spamd_ssl_accept_fail.t (Wstat: 0 Tests: 12 Failed: 5) Failed tests: 7-8, 10-12 t/spamd_ssl_tls.t (Wstat: 0 Tests: 9 Failed: 5) Failed tests: 4-5, 7-9 t/spamd_ssl_v2.t (Wstat: 0 Tests: 9 Failed: 5) Failed tests: 4-5, 7-9 t/spamd_ssl_v23.t (Wstat: 0 Tests: 9 Failed: 5) Failed tests: 4-5, 7-9 t/spamd_ssl_v3.t (Wstat: 0 Tests: 9 Failed: 5) Failed tests: 4-5, 7-9 t/spamd_stop.t (Wstat: 0 Tests: 2 Failed: 1) Failed test: 2 t/spamd_symbols.t (Wstat: 0 Tests: 3 Failed: 2) Failed tests: 2-3 t/spamd_syslog.t (Wstat: 0 Tests: 7 Failed: 5) Failed tests: 3-7 t/spamd_unix.t (Wstat: 0 Tests: 4 Failed: 2) Failed tests: 3-4 t/spamd_unix_and_tcp.t (Wstat: 0 Tests: 10 Failed: 2) Failed tests: 3, 8 t/spamd_user_rules_leak.t (Wstat: 0 Tests: 28 Failed: 6) Failed tests: 3-6, 9, 20 t/spamd_utf8.t (Wstat: 0 Tests: 3 Failed: 2) Failed tests: 2-3 t/spamd_whitelist_leak.t (Wstat: 0 Tests: 8 Failed: 3) Failed tests: 3-4, 6 Files=160, Tests=2041, 808 wallclock secs ( 1.12 usr 0.37 sys + 60.20 cusr 11.74 csys = 73.43 CPU) Result: FAIL Failed 33/160 test programs. 128/2041 subtests failed.
You have a missing dependency on >=dev-perl/NetAddr-IP-4.0 (which, incidentally is ~x86 and ~amd64 only). Also noted the following warnings during emerge (on ppc) 'DATADIR' is not a known MakeMaker parameter name. 'ENABLE_SSL' is not a known MakeMaker parameter name. 'PERL_BIN' is not a known MakeMaker parameter name. 'SYSCONFDIR' is not a known MakeMaker parameter name. Other than that, installed and running fine on ppc (with MailScanner, so spamd not started or tested)
Created attachment 217663 [details] spamassassin-3.3.0.ebuild Thanks, this should be better, still can not figure out how to get it to pass test :(
I'm new to ebuilds, but is this really the way this dependency should be handled? amd64? ( dev-perl/NetAddr-IP ) x86? ( dev-perl/NetAddr-IP ) If I understand the mechanisms correctly, this means that attempting to emerge spamassassin on the other arches supported in your ebuild will not even look for this required dependency, and will thus fail to install unless NetAddr-IP has previously been emerged manually. I'd have thought it much more logical to include it as a dependency regardless of arch. NetAddr-IP is going to need to have the other arches added to it anyway before the spamassassin ebuild can be approved...
(In reply to comment #8) > I'm new to ebuilds, but is this really the way this dependency should be > handled? > > amd64? ( > dev-perl/NetAddr-IP > ) > x86? ( > dev-perl/NetAddr-IP > ) > > If I understand the mechanisms correctly, this means that attempting to emerge > spamassassin on the other arches supported in your ebuild will not even look > for this required dependency, and will thus fail to install unless NetAddr-IP > has previously been emerged manually. > > I'd have thought it much more logical to include it as a dependency regardless > of arch. NetAddr-IP is going to need to have the other arches added to it > anyway before the spamassassin ebuild can be approved... > I added that for testing and so repoman would not complain. I open 2 bugs for KEYWORDREQ. I am also new to ebuilds and will have a couple of experenced developers look it over. I am just getting some of the grunt word done that I can help with. Also need to add conditional support for the plugin Mail-DKIM ; http://cpansearch.perl.org/src/JMASON/Mail-SpamAssassin-3.3.0/UPGRADE Thanks for testing etc.
(In reply to comment #9) > I added that for testing and so repoman would not complain. I open 2 bugs for > KEYWORDREQ. I am also new to ebuilds and will have a couple of experenced > developers look it over. OK, understood. > Also need to add conditional support for the plugin Mail-DKIM ; > http://cpansearch.perl.org/src/JMASON/Mail-SpamAssassin-3.3.0/UPGRADE Another aspect (I've no idea how to deal with this) is that previous versions of SA optionally used Mail::SPF::Query whereas 3.3 uses Mail::SPF instead. But you can't just install dev-perl/Mail-SPF over the top of dev-perl/Mail-SPF-Query because of a file ownership conflict.
(In reply to comment #10) > Another aspect (I've no idea how to deal with this) is that previous versions > of SA optionally used Mail::SPF::Query whereas 3.3 uses Mail::SPF instead. But > you can't just install dev-perl/Mail-SPF over the top of > dev-perl/Mail-SPF-Query because of a file ownership conflict. > Though I believe that even for (recent) previous versions of Spamassassin it was recommended to use Mail::SPF rather than Mail::SPF-Query. Would portage's auto-blocker handling not handle this? If dev-perl/Mail-SPF were to have a DEPEND !dev-perl/Mail-SPF-Query, and mail-filter/Spamassassin-3.3.0 were to depend on dev-perl/Mail-SPF, then as long as nothing else DEPENDS on dev-perl/Mail-SPF-Query then it would be automatically unmerged during the upgrade to Spamassassin-3.3.0. It just needs the dependencies set up correctly in the ebuilds.
(In reply to comment #11) > (In reply to comment #10) > > Another aspect (I've no idea how to deal with this) is that previous versions > > of SA optionally used Mail::SPF::Query whereas 3.3 uses Mail::SPF instead. But > > you can't just install dev-perl/Mail-SPF over the top of > > dev-perl/Mail-SPF-Query because of a file ownership conflict. > > > > Though I believe that even for (recent) previous versions of Spamassassin it > was recommended to use Mail::SPF rather than Mail::SPF-Query. > > Would portage's auto-blocker handling not handle this? If dev-perl/Mail-SPF > were to have a DEPEND !dev-perl/Mail-SPF-Query, and > mail-filter/Spamassassin-3.3.0 were to depend on dev-perl/Mail-SPF, then as > long as nothing else DEPENDS on dev-perl/Mail-SPF-Query then it would be > automatically unmerged during the upgrade to Spamassassin-3.3.0. It just needs > the dependencies set up correctly in the ebuilds. > Working on it, needs to be keyworded see Bug 302880
Created attachment 220885 [details] mail-filter/spamassassin/spamassassin-3.3.0.ebuild only waiting for ~ppc and ~ppc64 to keyword dev-perl/Mail-SPF
*** Bug 309601 has been marked as a duplicate of this bug. ***
Newest stable is now 3.3.1
(In reply to comment #15) > Newest stable is now 3.3.1 > I just renamed the 3.3.0 ebuild and so far so good.
dabbott: you know you can just drop the keywords in the meantime and leave a keywordreq for the arches right?
(In reply to comment #17) > dabbott: you know you can just drop the keywords in the meantime and leave a > keywordreq for the arches right? > Ok thanks, added to perl-overlay [perl-experimental] http://git.overlays.gentoo.org/gitweb/?p=proj/perl-overlay.git;a=summary
(In reply to comment #18) > (In reply to comment #17) > > dabbott: you know you can just drop the keywords in the meantime and leave a > > keywordreq for the arches right? > > > Ok thanks, added to perl-overlay [perl-experimental] > http://git.overlays.gentoo.org/gitweb/?p=proj/perl-overlay.git;a=summary > David, as discussed in irc, I committed this to the gentoo-x86 tree. Please continue your work and find me when you need fixes. :)
