On 2014-11-30 18:46, John Hardin wrote:
On Sun, 30 Nov 2014, jdow wrote:
OK, would this work? Use the fact that the thing defaults to a string. I would
"guess" the value would be "perl_version".
if (( perl_version != "perl_version" ) && ( perl_version >= 5.01 ))
bad stuff
e
Work for centos 6?
On Sunday, November 30, 2014, Ted Mittelstaedt wrote:
> If you have 3.4 then:
>
> Fetch the patches with the commands:
>
> wget "http://svn.apache.org/viewvc/spamassassin/trunk/lib/Mail/
> SpamAssassin/Conf/Parser.pm?r1=1642207&r2=1642206&pathrev=
> 1642207&view=patch" -O pars
On 01/12/2014 11:10, John Hardin wrote:
It has been. It's waiting for the normal masscheck process to generate
a new rules update.
That's excellent, thanks John.
On 01/12/2014 09:48, Reindl Harald wrote:
> Am 01.12.2014 um 00:22 schrieb Noel Butler:
>
>> huh? who doesnt null out cron these days and allow for
>> in-individual-cron-file error reporting
>
> everybody who want to face warnings before the get fatal
>
> frankly every part of our applicat
On Sun, 30 Nov 2014, jdow wrote:
OK, would this work? Use the fact that the thing defaults to a string. I
would "guess" the value would be "perl_version".
if (( perl_version != "perl_version" ) && ( perl_version >= 5.01 ))
bad stuff
endif
Nope. != is also a numeric compar
On 2014-11-30 17:16, John Hardin wrote:
On Sun, 30 Nov 2014, jdow wrote:
On 2014-11-30 14:29, John Hardin wrote:
On Sun, 30 Nov 2014, jdow wrote:
> > On Sun, 30 Nov 2014, Benny Pedersen wrote:
> > > On 30. nov. 2014 22.15.12 John Hardin wrote:
> > > > >if version > 3.004001
> >
On 2014-11-30 17:12, John Hardin wrote:
On Sun, 30 Nov 2014, Bob Proulx wrote:
I am hoping this won't make you gun-shy from continuing your fine work on the
project. Please don't let this minor bump in the road discourage you from
future work. That would be a tragedy for the project and for t
On Sun, 30 Nov 2014, Reindl Harald wrote:
On Sun, 30 Nov 2014, jdow wrote:
>
> if version > 3.004001 && perl_version >= 5.01
>body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
> endif
exactly that's what i menat with "from my knowledge the 'if perl_version'
should not get touched in that
On Sun, 30 Nov 2014, jdow wrote:
On 2014-11-30 14:29, John Hardin wrote:
On Sun, 30 Nov 2014, jdow wrote:
> > On Sun, 30 Nov 2014, Benny Pedersen wrote:
> > > On 30. nov. 2014 22.15.12 John Hardin wrote:
> > > > >if version > 3.004001
> > > > if perl_version >= 5.01
On Mon, 1 Dec 2014, Noel Butler wrote:
On 01/12/2014 04:52, John Hardin wrote:
On Sun, 30 Nov 2014, Reindl Harald wrote:
Am 30.11.2014 um 05:39 schrieb John Hardin: On Sun, 30 Nov 2014, Reindl Harald
wrote: if that rule can't work in most environments and not made conditionally
it has to b
On Sun, 30 Nov 2014, Bob Proulx wrote:
I am hoping this won't make you gun-shy from continuing your fine work
on the project. Please don't let this minor bump in the road discourage
you from future work. That would be a tragedy for the project and for
the users.
Oh, it won't do that.
It's
On 2014-11-30 15:00, Benny Pedersen wrote:
On 30. nov. 2014 23.15.50 "Kevin A. McGrail" wrote:
>>> if version > 3.004001
>>>if perl_version >= 5.01
>>> body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
>>>endif
>>> endif
What do you see wrong with the use of th
On 2014-11-30 14:30, Kevin A. McGrail wrote:
On 11/30/2014 5:20 PM, jdow wrote:
Would a corrected syntax version of this work?
if version > 3.004001 && perl_version >= 5.01
body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
endif
{^_^}
The core issue is that only SA currently in trunk contains
On 2014-11-30 14:29, John Hardin wrote:
On Sun, 30 Nov 2014, jdow wrote:
On Sun, 30 Nov 2014, Benny Pedersen wrote:
> On 30. nov. 2014 22.15.12 John Hardin wrote:
> > > if version > 3.004001
> > if perl_version >= 5.01
> > body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
John Hardin wrote:
> I underestimated the reaction to having such a warning emitted. I will
> disable that rule until the perl_version catability is offically released.
I wanted to take a moment to say thank you John for working with the
community to resolve this problem. That just by itself is a
Am 01.12.2014 um 00:22 schrieb Noel Butler:
huh? who doesnt null out cron these days and allow for
in-individual-cron-file error reporting
everybody who want to face warnings before the get fatal
frankly every part of our applications designed to run also in cronjob
is supposed to not output
On 01/12/2014 04:52, John Hardin wrote:
> On Sun, 30 Nov 2014, Reindl Harald wrote:
> Am 30.11.2014 um 05:39 schrieb John Hardin: On Sun, 30 Nov 2014, Reindl
> Harald wrote: if that rule can't work in most environments and not made
> conditionally it has to be dropped at all because it has m
On 30/11/2014 21:23, Martin wrote:
> -Original Message- From: Martin Gregorie [mailto:mar...@gregorie.org]
> Sent: Sunday, November 30, 2014 11:08 AM To: users@spamassassin.apache.org
> Subject: Re: Argument "perl_version" isn't numeric On Sat, 2014-11-29 at
> 20:39 -0800, John Hard
On 30. nov. 2014 23.15.50 "Kevin A. McGrail" wrote:
>>> if version > 3.004001
>>>if perl_version >= 5.01
>>> body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
>>>endif
>>> endif
What do you see wrong with the use of the can/has solution that both
Mark and I prop
On 30. nov. 2014 23.00.54 John Hardin wrote:
>> if version > 3.004001
>>if perl_version >= 5.01
>> body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
>>endif
>> endif
>
> If this works now in spamassassin 3.3.2, problem solved, can i send bitcoins
> somewhere ? :)
Am 30.11.2014 um 23:29 schrieb John Hardin:
On Sun, 30 Nov 2014, jdow wrote:
On Sun, 30 Nov 2014, Benny Pedersen wrote:
> On 30. nov. 2014 22.15.12 John Hardin wrote:
> > > if version > 3.004001
> > if perl_version >= 5.01
> > body NON_588_COMPATIBLE_RE_SYNTAX /\w
On 11/30/2014 5:20 PM, jdow wrote:
Would a corrected syntax version of this work?
if version > 3.004001 && perl_version >= 5.01
body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
endif
{^_^}
The core issue is that only SA currently in trunk contains the code for
the if functionality on the perl
On Sun, 30 Nov 2014, Reindl Harald wrote:
additionally if you have the "if perl_version" *inside* a "if version" and
only apply it that way to SA >= 3.4.0 the warnings at least would only occur
on systems with a old perl and recent SA which is hopefully the minority
Not true, please see my d
On Sun, 30 Nov 2014, jdow wrote:
On Sun, 30 Nov 2014, Benny Pedersen wrote:
> On 30. nov. 2014 22.15.12 John Hardin wrote:
>
> > if version > 3.004001
> > if perl_version >= 5.01
> > body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
> > endif
> > endif
>
>
On Sun, 30 Nov 2014, Kevin A. McGrail wrote:
I think we have to accept from the noise on the traffic that the warning is
not considered acceptable.
Yeah.
What do you see wrong with the use of the can/has solution that both Mark and
I proposed? I think it will be trivial and should not cause
On Sun, 30 Nov 2014, jdow wrote:
On 2014-11-30 13:13, John Hardin wrote:
On Sun, 30 Nov 2014, Reindl Harald wrote:
> 5)
> make the condition to the SA version, there are already ton's of "if
> (version
> > = 3.004000)" rules and so it needs just to depend on SA bigger than
> > 3.4.0
>
On 2014-11-30 13:58, John Hardin wrote:
On Sun, 30 Nov 2014, Benny Pedersen wrote:
On 30. nov. 2014 22.15.12 John Hardin wrote:
if version > 3.004001
if perl_version >= 5.01
body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
endif
endif
If this works now in spa
On 11/30/2014 4:58 PM, John Hardin wrote:
On Sun, 30 Nov 2014, Benny Pedersen wrote:
On 30. nov. 2014 22.15.12 John Hardin wrote:
if version > 3.004001
if perl_version >= 5.01
body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
endif
endif
If this works now in spa
On Sun, 30 Nov 2014, jdow wrote:
Perhaps the rules that need the version check could be put into a separate
file that is only used with SA version 3.4.x and above. It might be possible
to get the appropriate sa_update patch for older versions through Red Hat, if
that is needed. It might not be
On Sun, 30 Nov 2014, Benny Pedersen wrote:
On 30. nov. 2014 22.15.12 John Hardin wrote:
if version > 3.004001
if perl_version >= 5.01
body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
endif
endif
If this works now in spamassassin 3.3.2, problem solved, can i send
On Sun, Nov 30, 2014 at 3:30 PM, Ted Mittelstaedt wrote:
> I guess the $64K question is, does the new rule that's version dependent
> Increase the "spam catch" Because if it does, then I don't regard it as a
> problem. Instead, I want it!
The real $64K question is: If you really want it (in yo
Am 30.11.2014 um 22:22 schrieb Reindl Harald:
Am 30.11.2014 um 22:13 schrieb John Hardin:
On Sun, 30 Nov 2014, Reindl Harald wrote:
5)
make the condition to the SA version, there are already ton's of "if
(version > = 3.004000)" rules and so it needs just to depend on SA
bigger than 3.4.0 inst
On 2014-11-30 13:13, John Hardin wrote:
On Sun, 30 Nov 2014, Reindl Harald wrote:
5)
make the condition to the SA version, there are already ton's of "if (version
> = 3.004000)" rules and so it needs just to depend on SA bigger than 3.4.0
instead of the perl check
why that would work?
well, ol
Perhaps the rules that need the version check could be put into a separate file
that is only used with SA version 3.4.x and above. It might be possible to get
the appropriate sa_update patch for older versions through Red Hat, if that is
needed. It might not be if 3.3.x does not load rule files
Am 30.11.2014 um 22:13 schrieb John Hardin:
On Sun, 30 Nov 2014, Reindl Harald wrote:
5)
make the condition to the SA version, there are already ton's of "if
(version > = 3.004000)" rules and so it needs just to depend on SA
bigger than 3.4.0 instead of the perl check
why that would work?
wel
On 30. nov. 2014 22.15.12 John Hardin wrote:
if version > 3.004001
if perl_version >= 5.01
body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
endif
endif
If this works now in spamassassin 3.3.2, problem solved, can i send
bitcoins somewhere ? :)
On Sun, 30 Nov 2014, Reindl Harald wrote:
5)
make the condition to the SA version, there are already ton's of "if (version
> = 3.004000)" rules and so it needs just to depend on SA bigger than
3.4.0 instead of the perl check
why that would work?
well, older RHEL versions as you said won't up
On Sun, 30 Nov 2014, John Hardin wrote:
if release > 3.004001
if perl_version >= 5.01
body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
endif
endif
dammit.
if version > 3.004001
if perl_version >= 5.01
body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
endif
endi
On Sun, 30 Nov 2014, Benny Pedersen wrote:
On 30. nov. 2014 20.53.19 John Hardin wrote:
Sadly that doesn't work. The else branch of a conditional still gets
partially parsed, so the perl_version type warning is still emitted even
if it is inside a conditional that evaluates to false.
Try
Am 30.11.2014 um 21:49 schrieb Dave Pooser:
On 11/30/14, 2:04 PM, "Reindl Harald" wrote:
it's *not* about a "crufty version of perl"
it's about a perl version check not existing in SpamAssassin 3.4.0
it's visible on recent perl versions
without the version checks issing the warnings they had
On 11/30/14, 2:04 PM, "Reindl Harald" wrote:
>it's *not* about a "crufty version of perl"
>
>it's about a perl version check not existing in SpamAssassin 3.4.0
>it's visible on recent perl versions
>without the version checks issing the warnings they had no problem
OK, I could have been clearer
How does the usual person not a member of the right mailing lists learn of this
patch? An hour spent Googling and vetting patches is an hour taken from my life
time. Fortunately for me I was still a member of this list. So I learned I can
just ignore the fool thing cluttering my mailbox. (I may
> * operating system / version
> * spamassassin version
> * perl version
>
> the missing pieces are:
>
> what operating system, how is perl installed, how is SA installed (how
> means: by hand, distribution packages, CPAN...)
Well both servers are running Ubuntu 14.04 and both perl and SA is
ins
On 30. nov. 2014 21.12.06 listsb-spamassas...@bitrate.net wrote:
http://dpaste.com/3XTYV0V.txt
Is trusted_networks and internal_networks correct both for ipv4 and ipv6 ?
Does it match settings in amavisd ?
Both sa and amavisd need to know ALL your own ips including all non routeble :)
On 2014-11-30 12:19, Ted Mittelstaedt wrote:
On 11/30/2014 11:17 AM, jdow wrote:
Ted, I simply do not feel well enough just now to be nice. I reiterate
my prior observation about vaguely stinky and spludgy material such as
emanates from the South end of North facing fertile male bovines.
I ha
Am 30.11.2014 um 21:30 schrieb Ted Mittelstaedt:
On 11/30/2014 12:09 PM, Reindl Harald wrote:
Am 30.11.2014 um 20:50 schrieb Ted Mittelstaedt:
When the fix to allow older SA versions to silently accept the new
rule updates is a simple TEXT modification of 2 text Perl modules, you
are overreac
On 11/30/2014 12:09 PM, Reindl Harald wrote:
Am 30.11.2014 um 20:50 schrieb Ted Mittelstaedt:
When the fix to allow older SA versions to silently accept the new
rule updates is a simple TEXT modification of 2 text Perl modules, you
are overreacting
no - i react correctly
* the problem was
John Hardin writes:
>> BTW, if I added "&& !__ISO_2022_JP_DELIM" check to __TVD_SPACE_ENCODED
>> and TVD_SPACE_RATIO_MINFP rules in .spamassassin/user_prefs, it seems to
>> prevent the false positive for me.
>
> That is probably a valid exclusion, I will add it in.
>
> Unfortunately the masscheck
On 30. nov. 2014 20.53.19 John Hardin wrote:
On Sun, 30 Nov 2014, Benny Pedersen wrote:
> Ruleupdates should have being if version before if perl_version, so this the
> test of perl was only done on svn version of sa, it have nothing to do with
> update or change dependice of perl installed
On 11/30/2014 11:17 AM, jdow wrote:
Ted, I simply do not feel well enough just now to be nice. I reiterate
my prior observation about vaguely stinky and spludgy material such as
emanates from the South end of North facing fertile male bovines.
I have enough headaches with pure distro modules.
On Mon, 1 Dec 2014, OGAWA Hirofumi wrote:
Hi,
I'm not sure if this is valid ml to report issue. If not, sorry.
It is the correct place.
Recently I noticed some Japanese emails are detected as spam, and it is
false positive actually. The cause of it seems to be TVD_SPACE_ENCODED
and TVD_SPAC
On 2014-11-30 11:58, Ted Mittelstaedt wrote:
On 11/30/2014 11:06 AM, jdow wrote:
On 2014-11-30 10:48, Ted Mittelstaedt wrote:
On 11/29/2014 8:39 PM, John Hardin wrote:
On Sun, 30 Nov 2014, Reindl Harald wrote:
Am 29.11.2014 um 23:27 schrieb John Hardin:
However, it is a *warning*, not a
hi-
a message from yahoo seems to have matched FORGED_YAHOO_RCVD, which from my
perspective, the message is not forged [see below pastebin - i hope i've not
removed anything of importance during anonymization]. i noted that dkim
authentication appears to have failed, which, while of interest f
Am 30.11.2014 um 20:50 schrieb Ted Mittelstaedt:
When the fix to allow older SA versions to silently accept the new
rule updates is a simple TEXT modification of 2 text Perl modules, you
are overreacting
no - i react correctly
* the problem was introduced with sa-update
* the problem has to b
Am 30.11.2014 um 20:58 schrieb Dave Pooser:
On 11/30/14 1:07 PM, "Paul R. Ganci" wrote:
You have to be joking if I am going to update my systems for sa-update.
It seems that this is a pretty much arrogant decision by spamassassin
development team. The problem is in sa-update. It should be fix
Hi,
I'm not sure if this is valid ml to report issue. If not, sorry.
Recently I noticed some Japanese emails are detected as spam, and it is
false positive actually. The cause of it seems to be TVD_SPACE_ENCODED
and TVD_SPACE_RATIO_MINFP.
Both of rules uses __TVD_SPACE_RATIO, and it matches Japa
On 11/30/2014 11:06 AM, jdow wrote:
On 2014-11-30 10:48, Ted Mittelstaedt wrote:
On 11/29/2014 8:39 PM, John Hardin wrote:
On Sun, 30 Nov 2014, Reindl Harald wrote:
Am 29.11.2014 um 23:27 schrieb John Hardin:
However, it is a *warning*, not a fatal error. And it's better than
the
rule ki
On 11/30/14 1:07 PM, "Paul R. Ganci" wrote:
>You have to be joking if I am going to update my systems for sa-update.
>It seems that this is a pretty much arrogant decision by spamassassin
>development team. The problem is in sa-update. It should be fixed there.
You have to be joking if you think
On Sun, 30 Nov 2014, Benny Pedersen wrote:
Ruleupdates should have being if version before if perl_version, so this the
test of perl was only done on svn version of sa, it have nothing to do with
update or change dependice of perl installed
Sadly that doesn't work. The else branch of a condit
On 11/30/2014 10:59 AM, Reindl Harald wrote:
Am 30.11.2014 um 19:44 schrieb Ted Mittelstaedt:
This issue has been discussed here:
http://askubuntu.com/questions/554537/argument-perl-version-isnt-numeric-in-numeric-ge-at-eval-534-line-1
There is a link to patches for 2 Perl modules that tu
Am 30.11.2014 um 20:40 schrieb Bertrand Caplet:
What version of SA are you running?
My SA version is 3.4.0
What version of Net::DNS do you have installed? Could it be stale?
and I'm using Net::DNS v0.81
that's a recent version
perl-Net-DNS-0.80-1.fc20.x86_64
please for future problem repo
> What version of SA are you running?
My SA version is 3.4.0
> What version of Net::DNS do you have installed? Could it be stale?
and I'm using Net::DNS v0.81
Regards
--
CHUNKZ.NET - casual fiddler and computer technician
Bertrand Caplet, Flers (FR)
Feel free to send encrypted/signed messages
K
On Sun, 30 Nov 2014, jdow wrote:
John, if you make it a warning - warn ONCE not ever blessed time the file is
run and CLEARLY state this is a warning only and is not fatal. PLEASE PLEASE
PLEASE
{o.o}
The reason it warns twice is the rule evaluation and promotion process
separates the two r
On Sun, 30 Nov 2014, Bertrand Caplet wrote:
Hey guys,
since some weeks I got strange error messages like :
Use of uninitialized value $4 in concatenation (.) or string at
/usr/share/perl5/Mail/SpamAssassin/Plugin/URIDNSBL.pm line 1043,
line 76.
What version of SA are you running?
or :
spf:
On 30. nov. 2014 20.02.27 jdow wrote:
Now, if you guys could work with RHEL, SUSE, and other major distros to make it
easy for them to upgrade spamassassin that situation might change. But SA seems
to be moderately low on the criticality lists for major distros.
I stopped using rpm based dist
Hey guys,
since some weeks I got strange error messages like :
Use of uninitialized value $4 in concatenation (.) or string at
/usr/share/perl5/Mail/SpamAssassin/Plugin/URIDNSBL.pm line 1043,
line 76.
or :
spf: lookup failed: unimplemented type TXT at
/usr/local/lib/perl/5.18.2/Net/DNS/RR.pm line
John, if you make it a warning - warn ONCE not ever blessed time the file is run
and CLEARLY state this is a warning only and is not fatal. PLEASE PLEASE PLEASE
{o.o}
On 2014-11-30 11:11, John Hardin wrote:
On Sun, 30 Nov 2014, Dave Pooser wrote:
On 11/30/14 12:34 PM, "Paul R. Ganci" wrote:
Ted, I simply do not feel well enough just now to be nice. I reiterate my prior
observation about vaguely stinky and spludgy material such as emanates from the
South end of North facing fertile male bovines.
I have enough headaches with pure distro modules. I really REALLY *R*E*A*L*L*Y*
do not
On Sun, 30 Nov 2014, Dave Pooser wrote:
On 11/30/14 12:34 PM, "Paul R. Ganci" wrote:
So just so I understand something is it expected that those of us with
RHEL 5.11 and RHEL 6.6 servers are expected to upgrade our perl versions
just for spamassassin's sa-update? The whole idea of running ser
Now now, be nice!
This issue affects ANY piece of OSS software that has multiple dependencies.
SpamAssassin has HUNDREDS of dependencies on different Perl modules.
Using your nasty logic if the author of Perl::Date or whatever
decided to make a change that broke SA than it's our tough luck, eh?
On 11/30/2014 11:50 AM, Dave Pooser wrote:
On 11/30/14 12:34 PM, "Paul R. Ganci" wrote:
So just so I understand something is it expected that those of us with
RHEL 5.11 and RHEL 6.6 servers are expected to upgrade our perl versions
just for spamassassin's sa-update? The whole idea of running s
On 2014-11-30 10:48, Ted Mittelstaedt wrote:
On 11/29/2014 8:39 PM, John Hardin wrote:
On Sun, 30 Nov 2014, Reindl Harald wrote:
Am 29.11.2014 um 23:27 schrieb John Hardin:
However, it is a *warning*, not a fatal error. And it's better than the
rule killing lint and blocking sa-update compl
Am 30.11.2014 um 19:48 schrieb Ted Mittelstaedt:
On 11/29/2014 8:39 PM, John Hardin wrote:
if that rule can't work in most environments and not made
conditionally it has to be dropped at all because it has more
drawbacks than benefits
It has already been commented out in my sandbox.
But thi
On 2014-11-30 03:08, Martin Gregorie wrote:
On Sat, 2014-11-29 at 20:39 -0800, John Hardin wrote:
But this effectively means we cannot add new features to SA conditionals
because they might do this to older installs.
Can SA set a $too_old flag to say that that the Perl version number
check fai
Am 30.11.2014 um 19:44 schrieb Ted Mittelstaedt:
This issue has been discussed here:
http://askubuntu.com/questions/554537/argument-perl-version-isnt-numeric-in-numeric-ge-at-eval-534-line-1
There is a link to patches for 2 Perl modules that turn off
the warnings. Worked for me when I applie
On Sun, 30 Nov 2014, Ted Mittelstaedt wrote:
This issue has been discussed here:
http://askubuntu.com/questions/554537/argument-perl-version-isnt-numeric-in-numeric-ge-at-eval-534-line-1
There is a link to patches for 2 Perl modules that turn off
the warnings. Worked for me when I applied tho
On Sun, 30 Nov 2014, Reindl Harald wrote:
Am 30.11.2014 um 05:39 schrieb John Hardin:
On Sun, 30 Nov 2014, Reindl Harald wrote:
> if that rule can't work in most environments and not made
> conditionally it has to be dropped at all because it has more
> drawbacks than benefits
But this e
If you have 3.4 then:
Fetch the patches with the commands:
wget
"http://svn.apache.org/viewvc/spamassassin/trunk/lib/Mail/SpamAssassin/Conf/Parser.pm?r1=1642207&r2=1642206&pathrev=1642207&view=patch";
-O parser.pm.patch
wget
"http://svn.apache.org/viewvc/spamassassin/trunk/lib/Mail/SpamAssa
On 11/30/14 12:34 PM, "Paul R. Ganci" wrote:
>So just so I understand something is it expected that those of us with
>RHEL 5.11 and RHEL 6.6 servers are expected to upgrade our perl versions
>just for spamassassin's sa-update? The whole idea of running servers
>with those versions of server softw
On 11/29/2014 8:39 PM, John Hardin wrote:
On Sun, 30 Nov 2014, Reindl Harald wrote:
Am 29.11.2014 um 23:27 schrieb John Hardin:
However, it is a *warning*, not a fatal error. And it's better than the
rule killing lint and blocking sa-update completely on an install that
uses an older perl
This issue has been discussed here:
http://askubuntu.com/questions/554537/argument-perl-version-isnt-numeric-in-numeric-ge-at-eval-534-line-1
There is a link to patches for 2 Perl modules that turn off
the warnings. Worked for me when I applied those patches.
Ted
On 11/30/2014 4:42 AM, Reindl
On 11/30/2014 04:08 AM, Martin Gregorie wrote:
On Sat, 2014-11-29 at 20:39 -0800, John Hardin wrote:
But this effectively means we cannot add new features to SA conditionals
because they might do this to older installs.
Can SA set a $too_old flag to say that that the Perl version number
check f
Hello RW,
Sunday, November 30, 2014, 5:36:57 PM, you wrote:
R> http://spamassassin.apache.org/full/3.4.x/doc/Mail_SpamAssassin_Conf.txt
Cheers,google didn't help!
https://www.google.co.uk/search?q=BAYESTC&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-GB:official&client=firefox-a&channel=sb&gfe_rd=c
On Sun, 30 Nov 2014 16:16:07 +
Niamh Holding wrote:
>
> Hello
>
> Out of curiosity what are the numbers representing?
>
> _BAYESTC_
> _BAYESTCLEARNED_
> _BAYESTCHAMMY_
> _BAYESTCSPAMMY_
http://spamassassin.apache.org/full/3.4.x/doc/Mail_SpamAssassin_Conf.txt
Hello
Out of curiosity what are the numbers representing?
_BAYESTC_
_BAYESTCLEARNED_
_BAYESTCHAMMY_
_BAYESTCSPAMMY_
--
Best regards,
Niamh mailto:ni...@fullbore.co.uk
pgpJsDJ2Je643.pgp
Description: PGP signature
Or simple make a local backport from
http://svn.apache.org/viewvc?view=revision&revision=1642207
Or use trunc sa
On 30. nov. 2014 13.04.43 "A. Schulze" wrote:
The file 72_active.cf from update_spamassasin_org contain some
lines "if perl_version >= 5.001000
I simply removed these lines/if st
Am 30.11.2014 um 05:39 schrieb John Hardin:
On Sun, 30 Nov 2014, Reindl Harald wrote:
Am 29.11.2014 um 23:27 schrieb John Hardin:
However, it is a *warning*, not a fatal error. And it's better than the
rule killing lint and blocking sa-update completely on an install that
uses an older per
Benny Pedersen:
Upgrade to sa 3.4 where this work, else wait for next rule update,
this is a work in progress thats only gives error when not using sa
3.4
At least here I *have* 3.4 but got the same warnings.
The file 72_active.cf from update_spamassasin_org contain some
lines "if perl_ve
> -Original Message-
> From: Martin Gregorie [mailto:mar...@gregorie.org]
> Sent: Sunday, November 30, 2014 11:08 AM
> To: users@spamassassin.apache.org
> Subject: Re: Argument "perl_version" isn't numeric
>
> On Sat, 2014-11-29 at 20:39 -0800, John Hardin wrote:
> > But this effective
On Sat, 2014-11-29 at 20:39 -0800, John Hardin wrote:
> But this effectively means we cannot add new features to SA conditionals
> because they might do this to older installs.
>
Can SA set a $too_old flag to say that that the Perl version number
check failed?
If so, it seems the me that, at ru
90 matches
Mail list logo
