i posted on spamassassin maillist about FH_DATE_PAST_20XX exists in 3.2.1 even after doing sa-update :/ bug numbers is https://issues.apache.org/SpamAssassin/show_bug.cgi?id=4179 https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5397 https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5509 https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5511 https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5571 https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5665 https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5680 how do it gets resolved ? Reproducible: Always Expected Results: to see latest stable spamassassin IS stable in gentoo > since 3.2.1 is still stable in gentoo portage would make sense to > update rules on this for that bug ? Since, and 3.2.5 was released in June of 2008, and it's currently January of 2010, wouldn't it make sense for gentoo to either: 1) abandon the package and remove it from portage -or- 2) update the stable branch to the current version that has been our stable release for over a year and a half? 3.2.1 was released in June of 2007, and that's the latest stable for gentoo? Really? There's some pretty nasty bugs in that release (ie: 4179,5397,5509, 55115571,5680,5665) It is a great disservice to the gentoo user community for them to incorporate a tool that *needs* to be updated in a timely fashion into a process with a really slow release cycle. Since 3.2.1 is already broken, (even its sa-update is somewhat broken by the "non-redundant mirrored-by" bug), I don't think that updating one rule is going to help the gentoo users very much.
for a STABLEREQ for mail-filter/spamassassin-3.2.5 it needs no outstanding bugs, I found one bug # 288161
Just turn a bug like this into a STABLEREQ then next time because that is basically the request :) Add arches once bug 288161 is resolved (unless there are any other showstoppers) Keywords: spamassassin-3.2.1-r2: alpha amd64 hppa ia64 ppc ppc64 sparc x86 Keywords: spamassassin-3.2.5-r2: ~alpha ~amd64 ~hppa ~ia64 ~ppc ~ppc64 ~sparc ~x86
Arches, please test and mark mail-filter/spamassassin-3.2.5-r2 stable.
ppc stable
Yet another sandbox vs me issue... :-( It passes the testsuite on x86 as long as i have FEATURES="test collision--protect -sandbox" With the sandbox enabled, i hit http://bugs.gentoo.org/show_bug.cgi?id=294576 It has something to do with relative paths within t/SATest.pm on line 84 and 85! If i move them around, i can pass different tests manually within the sandbox! But they have to be different (once a ./path works, while on another test it fails with it and needs to be /the/full/path or just path without anything leading) for at least 3 different tests! :-/ But i don't think its a regression, as the current stable ebuild (3.2.1-r2) contains #SRC_TEST="do". ;-)
stable x86 nonetheless, thanks Andreas.
stable on ppc64
alpha/ia64/sparc stable
FYI, it's working stable on hppa (production MX, checks some hundred mails a day with spikes of thousands/day), but I hadn't tested for bug #288161
Stable for HPPA.
Should we proceed even with bug 288161 ? (if yes, please drop the blocker)
Maybe tests should be restricted until they work with sandbox enabled (bug 294576)
(In reply to comment #12) > Maybe tests should be restricted until they work with sandbox enabled (bug > 294576) > SRC_TEST="skip" should work
amd64 stable
