3.4.1 Key issues: sa_compile test failures and txrep.pm uninitialized issues

["Kevin A. McGrail" <km...@apache.org>]

Hello SpamAssassin Users and Developers,

I wanted to take a moment to provide my $0.02 on two in the wild issues 
with 3.4.1 that I've heard a lot about in the past few days:

The first in the wild issue has been some failures on sa_compile.t. 
These errors are confirmed as solely test errors and do not indicate an 
issue with using compiled rules in production.  You can see more about 
the issue on https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7181 and 
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7005.   If you are 
affected by this issue, an easy work around is to rename the re2c 
executable during cpan installations or make tests so that the 
sa_compile.t test is skipped.

And if you do have issues with compiled rules beyond the tests, 
commenting out the Rule2XSBody plugin in v320.pre will disable the use 
of compiled rules and the underlying deterministic finite state machine.


The second in the wild issue has been some logging of uninitialized 
errors from TxRep.com when txrep_track_messages  is enabled.  The errors 
are categorized as completely innocuous but totally annoying.  The good 
news is that we believe the logic causing the issue has been identified 
and improved.  But before I state that emphatically, I have asked Ivo, 
the author of TxRep, to review the logic changes that avert the error to 
make sure we have a good fix. You can see more about that issue at 
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7164.  In the 
meantime, an easy work around to this issue is to add 
txrep_track_messages 0 to your configuration which will disable the code 
with the bug.


In my opinion, neither of these issues warrants an escalation of a 3.4.2 
release but I wanted to let people know they are being actively worked 
on as well as give some possible workarounds.

Thanks for supporting Apache SpamAssassin!

Regards,
KAM

-- 
Kevin A. McGrail
VP & Chair, Apache SpamAssassin Project Management Committee

Re: 3.4.1 Key issues: sa_compile test failures and txrep.pm uninitialized issues

[Bill Cole <sa...@billmail.scconsult.com>]

On 6 May 2015, at 20:57, Kevin A. McGrail wrote:

> Hello SpamAssassin Users and Developers,
>
> I wanted to take a moment to provide my $0.02 on two in the wild 
> issues with 3.4.1 that I've heard a lot about in the past few days:
>
> The first in the wild issue has been some failures on sa_compile.t. 
> These errors are confirmed as solely test errors and do not indicate 
> an issue with using compiled rules in production.  You can see more 
> about the issue on 
> https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7181 and 
> https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7005.   If you are 
> affected by this issue, an easy work around is to rename the re2c 
> executable during cpan installations or make tests so that the 
> sa_compile.t test is skipped.

I would (for obvious reasons) add to that list 
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7188 which is also 
worked around by skipping the test OR by applying the patch attached to 
the bug. It appears that this bug has been around a long time and went 
unnoticed because the bulk of people using /opt/$DIR as a prefix for 
build/test are MacPorts users and MacPorts doesn't run tests by default 
or ever test as root, so the most serious risk (damaging the operational 
rule & config directories under /{etc,var}/opt/) is avoided.

As with the other sa_compile.t issue, I don't see that as any sort of 
emergency issue. The tests implemented in that file are more for 
developers than for end-users in that they answer "is rule compilation 
broken in general?" without answering "is my build able to compile 
rules?"