Mailing List Archive

1 2 3 4 5 6  View All
Re: Argument "perl_version" isn't numeric [ In reply to ]
On 2014-11-30 15:00, Benny Pedersen wrote:
> On 30. nov. 2014 23.15.50 "Kevin A. McGrail" <KMcGrail@PCCC.com> wrote:
>
>> >>> if version > 3.004001
>> >>> if perl_version >= 5.010000
>> >>> 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 proposed? I think it will be trivial and should not cause
>> any errors for older SA's.
>
> Why does the above not work aswell ?
>

The "if perl_version...." line must be at least partially parsed so that the
endif parsing works.

{^_^}
Re: Argument "perl_version" isn't numeric [ In reply to ]
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 just embarrassing as all hell to publicly step on my sword in this
manner.

--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Men by their constitutions are naturally divided in to two parties:
1. Those who fear and distrust the people and wish to draw all
powers from them into the hands of the higher classes. 2. Those who
identify themselves with the people, have confidence in them,
cherish and consider them as the most honest and safe, although not
the most wise, depository of the public interests.
-- Thomas Jefferson
-----------------------------------------------------------------------
15 days until Bill of Rights day
Re: Argument "perl_version" isn't numeric [ In reply to ]
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 <jhardin@impsec.org> wrote:
>> > > > > > if version > 3.004001
>> > > > > if perl_version >= 5.010000
>> > > > > 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 ? :)
>> > >
>> > > It "works" in 3.3.2 *IF* you accept the warning about
>> > > perl_version being non-numeric that this entire thread is about.
>> > > The non-5.8.8-compatible RE is skipped, because the perl_version
>> > > conditional fails to false on the type warning and doesn't
>> > > include the rule.
>> >
>> > Would a corrected syntax version of this work?
>> >
>> > if version > 3.004001 && perl_version >= 5.010000
>> > body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
>> > endif
>>
>> Yes. That *does* work.
>>
>> Thank you! I think you just solved it.
>
> Here is another idea that might be helpful if....
>
> if ((ref( perl_version ) == SCALAR ) && (perl_version >= 5.010000))
> body yatta yatta
> endif

The SA if() conditional only supports a very limited subset of the perl
syntax, otherwise the perl_version change wouldn't have been needed in the
first place, we could just check $] or $^V directly.

So, that doesn't work:

Nov 30 17:14:09.267 [18334] warn: config: error in if - ( ( "ref" (
"fnord_var" ) == "SCALAR" ) && ( "fnord_var" >= 5.010000 ) ) : syntax
error at (eval 2556) line 1, near ""ref" ( "


--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Men by their constitutions are naturally divided in to two parties:
1. Those who fear and distrust the people and wish to draw all
powers from them into the hands of the higher classes. 2. Those who
identify themselves with the people, have confidence in them,
cherish and consider them as the most honest and safe, although not
the most wise, depository of the public interests.
-- Thomas Jefferson
-----------------------------------------------------------------------
15 days until Bill of Rights day
Re: Argument "perl_version" isn't numeric [ In reply to ]
On Sun, 30 Nov 2014, Reindl Harald wrote:

>> On Sun, 30 Nov 2014, jdow wrote:
>> >
>> > if version > 3.004001 && perl_version >= 5.010000
>> > 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 case at all"

I was assuming you were referring to the version that everyone had been
discussing up to the point jdow made her suggestion, namely:

if version > 3.004001
if perl_version >= 5.01000
body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
endif
endif

Apologies if you were not, you didn't make that clear.

--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Men by their constitutions are naturally divided in to two parties:
1. Those who fear and distrust the people and wish to draw all
powers from them into the hands of the higher classes. 2. Those who
identify themselves with the people, have confidence in them,
cherish and consider them as the most honest and safe, although not
the most wise, depository of the public interests.
-- Thomas Jefferson
-----------------------------------------------------------------------
15 days until Bill of Rights day
Re: Argument "perl_version" isn't numeric [ In reply to ]
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 the users.
>
> Oh, it won't do that.
>
> It's just embarrassing as all hell to publicly step on my sword in this manner.

Stepped in a "richard", you did. (Read Terry Pratchett's "Dodger" if you must to
get the term's meaning and origin.)

{^_-} Joanne
Re: Argument "perl_version" isn't numeric [ In reply to ]
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 <jhardin@impsec.org> wrote:
>>> > > > > > if version > 3.004001
>>> > > > > if perl_version >= 5.010000
>>> > > > > 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 ? :)
>>> > > > > It "works" in 3.3.2 *IF* you accept the warning about > >
>>> perl_version being non-numeric that this entire thread is about. > > The
>>> non-5.8.8-compatible RE is skipped, because the perl_version > >
>>> conditional fails to false on the type warning and doesn't > > include the
>>> rule.
>>> > > Would a corrected syntax version of this work?
>>> > > if version > 3.004001 && perl_version >= 5.010000
>>> > body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
>>> > endif
>>>
>>> Yes. That *does* work.
>>>
>>> Thank you! I think you just solved it.
>>
>> Here is another idea that might be helpful if....
>>
>> if ((ref( perl_version ) == SCALAR ) && (perl_version >= 5.010000))
>> body yatta yatta
>> endif
>
> The SA if() conditional only supports a very limited subset of the perl syntax,
> otherwise the perl_version change wouldn't have been needed in the first place,
> we could just check $] or $^V directly.
>
> So, that doesn't work:
>
> Nov 30 17:14:09.267 [18334] warn: config: error in if - ( ( "ref" ( "fnord_var"
> ) == "SCALAR" ) && ( "fnord_var" >= 5.010000 ) ) : syntax error at (eval 2556)
> line 1, near ""ref" ( "

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.010000 ))
bad stuff
endif

{^_^}
Re: Argument "perl_version" isn't numeric [ In reply to ]
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.010000 ))
> bad stuff
> endif

Nope. != is also a numeric comparison so you gain no ground. And "ne"
isn't included in the perl subset that SA conditionals use.

--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
...intellectuals have no interest in what _creates_ wealth, and
what _inhibits_ the creation of wealth. They are very concerned
about the _distribution_ of it, but they act as if wealth just
exists somehow. It's like manna from heaven, it's only a
question of how we split it up. -- Thomas Sowell
-----------------------------------------------------------------------
15 days until Bill of Rights day
Re: Argument "perl_version" isn't numeric [ In reply to ]
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.010000 ))
>> bad stuff
>> endif
>
> Nope. != is also a numeric comparison so you gain no ground. And "ne" isn't
> included in the perl subset that SA conditionals use.

Well, I tried. I guess after being a bit trying I figured giving a good try was
called for. Whining is no fun. Finding solutions is.

{^_^}
Re: Argument "perl_version" isn't numeric [ In reply to ]
Hello Ted,

Sunday, November 30, 2014, 7:50:49 PM, you wrote:

TM> assuming
TM> your package maintainers are following the new releases of SA

There's an assumption!

CentOS 6

spamassassin.x86_64 3.3.1-3.el6 base

CentOS 7

spamassassin-3.3.2-18.el7.x86_64.rpm

--
Best regards,
Niamh mailto:niamh@fullbore.co.uk
Re: Argument "perl_version" isn't numeric [ In reply to ]
On 1. dec. 2014 02.06.51 jdow <jdow@earthlink.net> wrote:

> The "if perl_version...." line must be at least partially parsed so that the
> endif parsing works.

Design faults, is spamassassin really that bad ?
Re: Argument "perl_version" isn't numeric [ In reply to ]
Am 01.12.2014 um 10:25 schrieb Benny Pedersen:
> On 1. dec. 2014 02.06.51 jdow <jdow@earthlink.net> wrote:
>
>> The "if perl_version...." line must be at least partially parsed so
>> that the
>> endif parsing works.
>
> Design faults, is spamassassin really that bad ?

don't start the same as on the dovecot list here followed by innocent
playing thread strip quting after get the deserved response!

https://www.mail-archive.com/dovecot@dovecot.org/msg55174.html
http://www.dovecot.org/list/dovecot/2013-November/093465.html
RE: Argument "perl_version" isn't numeric [ In reply to ]
I haven’t read all this thread, since it went ballistic Sunday, too much to
read but there seems to be a misconception this is an sa-update problem from
what I have read. This is not the case the if perl_version causes problems
in sa-learn and spamassassin too.

What dose seem strange is that spamassassin --lint picks up the version
correctly "Perl 5.012004" so perl_version is doing something wrong if the
version can be picked up numerically elsewhere, surely in the next release
of spamassassin this can be changed and it can play nicely with older
versions of perl.
Re: Argument "perl_version" isn't numeric [ In reply to ]
On 11/30/2014 11:29 PM, John Hardin wrote:

>> Would a corrected syntax version of this work?
>>
>> if version > 3.004001 && perl_version >= 5.010000
>> body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
>> endif
>
> Yes. That *does* work.
>
> Thank you! I think you just solved it.


Define work...

-----------
if version > 3.004001 && perl_version >= 5.010000
body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
endif

# spamassassin --lint
Dec 1 15:03:50.365 [28224] warn: Argument "perl_version" isn't numeric
in numeric ge (>=) at (eval 2520) line 2.
----------

-----------
if version > 3.004001
if perl_version >= 5.010000
body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
endif
endif

# spamassassin --lint
Dec 1 15:04:29.115 [28226] warn: Argument "perl_version" isn't numeric
in numeric ge (>=) at (eval 2521) line 2.
-----------

(SA 3.3.1 / perl 5.8.8)


But I was thinking another solution to the problem;

Since there already are quite a few changes to 3.4(+) (quite a few
checking for version >= 3.004000 in the rulesets)

How difficult would it be to split 3.4.1(+) rulesets from pre-3.4.1
rulesets? Older SA/sa-update would then fetch rulesets without the
new checks, and new sa-update would benefit from the new checks...


just my $.02

--
Bernt 'Burnie' Pettersen /// DoD#2345
<E-mail:burnie@dod.no> /// <URL:http://burnie.sh/>
- Creative brains need creative workhours! -
Re: Argument "perl_version" isn't numeric [ In reply to ]
On 12/1/2014 9:21 AM, Burnie wrote:
> On 11/30/2014 11:29 PM, John Hardin wrote:
>
>>> Would a corrected syntax version of this work?
>>>
>>> if version > 3.004001 && perl_version >= 5.010000
>>> body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
>>> endif
>>
>> Yes. That *does* work.
>>
>> Thank you! I think you just solved it.
>
>
> Define work...
OK, looks like we need to add a single has/can function for perl
5.010000 for this issue since we can't pass a parameter or use
perl_version without hitting errors. It's not scalable but will solve
the immediate issue.

> But I was thinking another solution to the problem;
>
> Since there already are quite a few changes to 3.4(+) (quite a few
> checking for version >= 3.004000 in the rulesets)
>
> How difficult would it be to split 3.4.1(+) rulesets from pre-3.4.1
> rulesets? Older SA/sa-update would then fetch rulesets without the
> new checks, and new sa-update would benefit from the new checks...
That's a decent amount of work AND a dangerous path to tread because
only 3.4.X is supported by the project currently so if we invested a lot
of time on that path, it would lead to dropping 3.3.X support. But it's
a good thought because it is a solution no one else mentioned.

Regards,
KAM
Re: Argument "perl_version" isn't numeric [ In reply to ]
On 12/1/2014 10:11 AM, Kevin A. McGrail wrote:
> On 12/1/2014 9:21 AM, Burnie wrote:
>> On 11/30/2014 11:29 PM, John Hardin wrote:
>>
>>>> Would a corrected syntax version of this work?
>>>>
>>>> if version > 3.004001 && perl_version >= 5.010000
>>>> body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
>>>> endif
>>>
>>> Yes. That *does* work.
>>>
>>> Thank you! I think you just solved it.
>>
>>
>> Define work...
> OK, looks like we need to add a single has/can function for perl
> 5.010000 for this issue since we can't pass a parameter or use
> perl_version without hitting errors. It's not scalable but will solve
> the immediate issue.
>
>> But I was thinking another solution to the problem;
>>
>> Since there already are quite a few changes to 3.4(+) (quite a few
>> checking for version >= 3.004000 in the rulesets)
>>
>> How difficult would it be to split 3.4.1(+) rulesets from pre-3.4.1
>> rulesets? Older SA/sa-update would then fetch rulesets without the
>> new checks, and new sa-update would benefit from the new checks...
> That's a decent amount of work AND a dangerous path to tread because
> only 3.4.X is supported by the project currently so if we invested a
> lot of time on that path, it would lead to dropping 3.3.X support. But
> it's a good thought because it is a solution no one else mentioned.
>
> Regards,
> KAM
This module may be of some help as well:
Re: Argument "perl_version" isn't numeric [ In reply to ]
On 12/1/2014 10:24 AM, Joe Quinn wrote:
> On 12/1/2014 10:11 AM, Kevin A. McGrail wrote:
>> On 12/1/2014 9:21 AM, Burnie wrote:
>>> On 11/30/2014 11:29 PM, John Hardin wrote:
>>>
>>>>> Would a corrected syntax version of this work?
>>>>>
>>>>> if version > 3.004001 && perl_version >= 5.010000
>>>>> body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
>>>>> endif
>>>>
>>>> Yes. That *does* work.
>>>>
>>>> Thank you! I think you just solved it.
>>>
>>>
>>> Define work...
>> OK, looks like we need to add a single has/can function for perl
>> 5.010000 for this issue since we can't pass a parameter or use
>> perl_version without hitting errors. It's not scalable but will solve
>> the immediate issue.
>>
>>> But I was thinking another solution to the problem;
>>>
>>> Since there already are quite a few changes to 3.4(+) (quite a few
>>> checking for version >= 3.004000 in the rulesets)
>>>
>>> How difficult would it be to split 3.4.1(+) rulesets from pre-3.4.1
>>> rulesets? Older SA/sa-update would then fetch rulesets without the
>>> new checks, and new sa-update would benefit from the new checks...
>> That's a decent amount of work AND a dangerous path to tread because
>> only 3.4.X is supported by the project currently so if we invested a
>> lot of time on that path, it would lead to dropping 3.3.X support.
>> But it's a good thought because it is a solution no one else mentioned.
>>
>> Regards,
>> KAM
> This module may be of some help as well:
http://search.cpan.org/~bdfoy/Perl-Version/lib/Perl/Version.pm

(Sorry for fat-fingering ctrl+enter)
Re: Argument "perl_version" isn't numeric [ In reply to ]
On 12/1/2014 10:25 AM, Joe Quinn wrote:
> http://search.cpan.org/~bdfoy/Perl-Version/lib/Perl/Version.pm
Not really because we want to make the check in a config file delivered
by SA-UPDATE without any changes to SA that will ripple to older SA
installations. And I don't think we have an issue identifying the
version of perl. We have an issue writing a config file logic that can
identify the version of perl that works with SA trunk and doesn't throw
a warn in older versions of SA.

regards,
KAM
Re: Argument "perl_version" isn't numeric [ In reply to ]
On Mon, 1 Dec 2014, Burnie wrote:

> On 11/30/2014 11:29 PM, John Hardin wrote:
>
>> > Would a corrected syntax version of this work?
>> >
>> > if version > 3.004001 && perl_version >= 5.010000
>> > body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
>> > endif
>>
>> Yes. That *does* work.
>>
>> Thank you! I think you just solved it.
>
>
> Define work...
>
> -----------
> if version > 3.004001 && perl_version >= 5.010000
> body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
> endif
>
> # spamassassin --lint
> Dec 1 15:03:50.365 [28224] warn: Argument "perl_version" isn't numeric in
> numeric ge (>=) at (eval 2520) line 2.

Dammit. I ran it (against trunk) here (with a different pseudo-var name,
and using version > 9) and did *not* get a type warning!

if version > 1 && fnord_should_be_skipped >= 5.010000
body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
endif

gives:

Dec 1 09:08:36.622 [22970] warn: Argument "fnord_should_be_skipped" isn't
numeric in numeric ge (>=) at (eval 2555) line 1.
Dec 1 09:08:37.481 [22970] dbg: message: main message type: text/plain


if version > 4 && fnord_should_be_skipped >= 5.010000
body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
endif

gives:

Dec 1 09:09:49.486 [22988] dbg: message: main message type: text/plain


> But I was thinking another solution to the problem;
>
> Since there already are quite a few changes to 3.4(+) (quite a few
> checking for version >= 3.004000 in the rulesets)
>
> How difficult would it be to split 3.4.1(+) rulesets from pre-3.4.1
> rulesets? Older SA/sa-update would then fetch rulesets without the
> new checks, and new sa-update would benefit from the new checks...

That may need to be what happens.

--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
There is no better measure of the unthinking contempt of the
environmentalist movement for civilization than their call to
turn off the lights and sit in the dark. -- Sultan Knish
-----------------------------------------------------------------------
14 days until Bill of Rights day
Re: Argument "perl_version" isn't numeric [ In reply to ]
On Mon, 1 Dec 2014, Kevin A. McGrail wrote:

> On 12/1/2014 9:21 AM, Burnie wrote:
>> On 11/30/2014 11:29 PM, John Hardin wrote:
>>
>> > > Would a corrected syntax version of this work?
>> > >
>> > > if version > 3.004001 && perl_version >= 5.010000
>> > > body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
>> > > endif
>> >
>> > Yes. That *does* work.
>> >
>> > Thank you! I think you just solved it.
>>
>>
>> Define work...
>
> OK, looks like we need to add a single has/can function for perl 5.010000 for
> this issue since we can't pass a parameter or use perl_version without
> hitting errors. It's not scalable but will solve the immediate issue.
>
>> But I was thinking another solution to the problem;
>>
>> Since there already are quite a few changes to 3.4(+) (quite a few
>> checking for version >= 3.004000 in the rulesets)
>>
>> How difficult would it be to split 3.4.1(+) rulesets from pre-3.4.1
>> rulesets? Older SA/sa-update would then fetch rulesets without the
>> new checks, and new sa-update would benefit from the new checks...
>
> That's a decent amount of work AND a dangerous path to tread because only
> 3.4.X is supported by the project currently so if we invested a lot of time
> on that path, it would lead to dropping 3.3.X support. But it's a good
> thought because it is a solution no one else mentioned.

Before we go that route, I have not tested whether a require_version at
the beginning of a separate rules file will bypass this issue.

--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
There is no better measure of the unthinking contempt of the
environmentalist movement for civilization than their call to
turn off the lights and sit in the dark. -- Sultan Knish
-----------------------------------------------------------------------
14 days until Bill of Rights day
Re: Argument "perl_version" isn't numeric [ In reply to ]
John Hardin wrote:
> Burnie wrote:
> >John Hardin wrote:
> >> jdow wrote:
> >>> Would a corrected syntax version of this work?
> >>> > if version > 3.004001 && perl_version >= 5.010000
> >>> body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
> >>> endif
> >>
> >> Yes. That *does* work.
> >>
> >> Thank you! I think you just solved it.
> >
> >Define work...
> >
> >if version > 3.004001 && perl_version >= 5.010000
> > body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
> >endif
> >
> ># spamassassin --lint
> >Dec 1 15:03:50.365 [28224] warn: Argument "perl_version" isn't numeric in
> >numeric ge (>=) at (eval 2520) line 2.
>
> Dammit. I ran it (against trunk) here (with a different pseudo-var name, and
> using version > 9) and did *not* get a type warning!

First, thank you for the fix in the latest updates. I no longer saw
any warnings from cron with last nights release cycle.

Regarding this syntax I just ran a test here with exactly that
syntax in Debian Wheezy Stable.

$ spamassassin --version
SpamAssassin version 3.3.2
running on Perl version 5.14.2

if version > 3.004001 && perl_version >= 5.010000
meta PDS_FROM_2_EMAILS __PDS_FROM_2_EMAILS && !__VIA_ML && !__VIA_RESIGNER
endif

if version > 3.004001 && perl_version >= 5.010000
header __PDS_FROM_2_EMAILS From =~ /^\W+([\w+.-]+\@[\w.-]+\.\w\w++)(?:[^\n\w<]{0,80})?<(?!\1)[^\n\s]*\@/i
endif

This produced no lint warnings with the above combination. I am
missing why it is causing problems in Burnie's configuration. Is
3.3.1 really that different here from 3.3.2 which is silent?

Bob
Re: Argument "perl_version" isn't numeric [ In reply to ]
On Mon, 1 Dec 2014, John Hardin wrote:
> On Mon, 1 Dec 2014, Kevin A. McGrail wrote:
>> On 12/1/2014 9:21 AM, Burnie wrote:
>>
>> > But I was thinking another solution to the problem;
>> >
>> > Since there already are quite a few changes to 3.4(+) (quite a few
>> > checking for version >= 3.004000 in the rulesets)
>> >
>> > How difficult would it be to split 3.4.1(+) rulesets from pre-3.4.1
>> > rulesets? Older SA/sa-update would then fetch rulesets without the
>> > new checks, and new sa-update would benefit from the new checks...
>>
>> That's a decent amount of work AND a dangerous path to tread because only
>> 3.4.X is supported by the project currently so if we invested a lot of
>> time on that path, it would lead to dropping 3.3.X support. But it's a
>> good thought because it is a solution no one else mentioned.
>
> Before we go that route, I have not tested whether a require_version at the
> beginning of a separate rules file will bypass this issue.

Ugh, that's actually worse:

Dec 1 10:57:50.092 [23879] warn: config: configuration file "/home/jhardin/develop/spamassassin/testing/require_version.cf" requires version 5.003000 of SpamAssassin, but this is code version 3.004001. Maybe you need to use the -C switch, or remove the old config files? Skipping this file at lib/Mail/SpamAssassin/Conf/Parser.pm line 406.
Dec 1 10:57:50.092 [23879] info: config: configuration file "/home/jhardin/develop/spamassassin/testing/require_version.cf" requires version 5.003000 of SpamAssassin, but this is code version 3.004001. Maybe you need to use the -C switch, or remove the old config files? Skipping this file
Dec 1 10:57:50.092 [23879] warn: Argument "fnord_should_be_skipped" isn't numeric in numeric ge (>=) at (eval 2526) line 1.

It emits *more* warnings, and *doesn't* actually skip parsing the
conditional in that file. :(

I suppose the only option is can(Mail::SpamAssassin::Conf::perl_min_version_5010000) after all.

That's *so* ugly.

--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
We have to realize that people who run the government can and do
change. Our society and laws must assume that bad people -
criminals even - will run the government, at least part of the
time. -- John Gilmore
-----------------------------------------------------------------------
14 days until Bill of Rights day
Re: Argument "perl_version" isn't numeric [ In reply to ]
On Mon, 1 Dec 2014, Bob Proulx wrote:

> John Hardin wrote:
>> Burnie wrote:
>>> John Hardin wrote:
>>>> jdow wrote:
>>>>> Would a corrected syntax version of this work?
>>>>>> if version > 3.004001 && perl_version >= 5.010000
>>>>> body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
>>>>> endif
>>>>
>>>> Yes. That *does* work.
>>>>
>>>> Thank you! I think you just solved it.
>>>
>>> Define work...
>>>
>>> if version > 3.004001 && perl_version >= 5.010000
>>> body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
>>> endif
>>>
>>> # spamassassin --lint
>>> Dec 1 15:03:50.365 [28224] warn: Argument "perl_version" isn't numeric in
>>> numeric ge (>=) at (eval 2520) line 2.
>>
>> Dammit. I ran it (against trunk) here (with a different pseudo-var name, and
>> using version > 9) and did *not* get a type warning!
>
> Regarding this syntax I just ran a test here with exactly that
> syntax in Debian Wheezy Stable.
>
> $ spamassassin --version
> SpamAssassin version 3.3.2
> running on Perl version 5.14.2
>
> if version > 3.004001 && perl_version >= 5.010000
> meta PDS_FROM_2_EMAILS __PDS_FROM_2_EMAILS && !__VIA_ML && !__VIA_RESIGNER
> endif
>
> if version > 3.004001 && perl_version >= 5.010000
> header __PDS_FROM_2_EMAILS From =~ /^\W+([\w+.-]+\@[\w.-]+\.\w\w++)(?:[^\n\w<]{0,80})?<(?!\1)[^\n\s]*\@/i
> endif
>
> This produced no lint warnings with the above combination. I am
> missing why it is causing problems in Burnie's configuration. Is
> 3.3.1 really that different here from 3.3.2 which is silent?

I did a quick troll through the SVN history but nothing leapt out at me.
However, I'm not that familiar with the parser.

I can confirm 3.2.5 *does* generate a lint warning with that syntax (an
old VM I have).

Could somebody else running 3.3.1 confirm Burnie's results?

--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
...the good of having the government prohibited from doing harm
far outweighs the harm of having it obstructed from doing good.
-- Mike@mike-istan
-----------------------------------------------------------------------
14 days until Bill of Rights day
Re: Argument "perl_version" isn't numeric [ In reply to ]
On 12/01/2014 08:50 PM, John Hardin wrote:
> On Mon, 1 Dec 2014, Bob Proulx wrote:
>
>> $ spamassassin --version
>> SpamAssassin version 3.3.2
>> running on Perl version 5.14.2
>>
>> if version > 3.004001 && perl_version >= 5.010000
>> meta PDS_FROM_2_EMAILS __PDS_FROM_2_EMAILS && !__VIA_ML &&
>> !__VIA_RESIGNER
>> endif
>>
>> if version > 3.004001 && perl_version >= 5.010000
>> header __PDS_FROM_2_EMAILS From =~
>> /^\W+([\w+.-]+\@[\w.-]+\.\w\w++)(?:[^\n\w<]{0,80})?<(?!\1)[^\n\s]*\@/i
>> endif
>>
>> This produced no lint warnings with the above combination. I am
>> missing why it is causing problems in Burnie's configuration. Is
>> 3.3.1 really that different here from 3.3.2 which is silent?
>
> I did a quick troll through the SVN history but nothing leapt out at me.
> However, I'm not that familiar with the parser.
>
> I can confirm 3.2.5 *does* generate a lint warning with that syntax (an
> old VM I have).
>
> Could somebody else running 3.3.1 confirm Burnie's results?


A "preliminary" test here - on Perl 5.8.8 - gives the same warning in
3.3.1, 3.3.2 and 3.4.0. So it might have to do with the Perl version.


# (cd Mail-SpamAssassin-3.3.1 && ./spamassassin --lint)
Dec 1 21:15:12.602 [21690] warn: Argument "perl_version" isn't numeric
in numeric ge (>=) at (eval 313) line 2.

# (cd Mail-SpamAssassin-3.3.2 && ./spamassassin --lint)
Dec 1 21:15:20.617 [21696] warn: Argument "perl_version" isn't numeric
in numeric ge (>=) at (eval 313) line 2.

# (cd Mail-SpamAssassin-3.4.0 && ./spamassassin --lint)
Dec 1 21:15:30.946 [21706] warn: Argument "perl_version" isn't numeric
in numeric ge (>=) at (eval 314) line 2.



--
Bernt 'Burnie' Pettersen /// DoD#2345
<E-mail:burnie@dod.no> /// <URL:http://burnie.sh/>
- Creative brains need creative workhours! -
Re: Argument "perl_version" isn't numeric [ In reply to ]
On Mon, 1 Dec 2014, John Hardin wrote:

> On Mon, 1 Dec 2014, Bob Proulx wrote:
>
>> John Hardin wrote:
>>> Burnie wrote:
>>>> John Hardin wrote:
>>>>> jdow wrote:
>>>>>> Would a corrected syntax version of this work?
>>>>>>> if version > 3.004001 && perl_version >= 5.010000
>>>>>> body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
>>>>>> endif
>>>>>
>>>>> Yes. That *does* work.
>>>>>
>>>>> Thank you! I think you just solved it.
>>>>
>>>> Define work...
>>>>
>>>> if version > 3.004001 && perl_version >= 5.010000
>>>> body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
>>>> endif
>>>>
>>>> # spamassassin --lint
>>>> Dec 1 15:03:50.365 [28224] warn: Argument "perl_version" isn't numeric
>>>> in
>>>> numeric ge (>=) at (eval 2520) line 2.
>>>
>>> Dammit. I ran it (against trunk) here (with a different pseudo-var name,
>>> and
>>> using version > 9) and did *not* get a type warning!
>>
>> Regarding this syntax I just ran a test here with exactly that
>> syntax in Debian Wheezy Stable.
>>
>> $ spamassassin --version
>> SpamAssassin version 3.3.2
>> running on Perl version 5.14.2
>>
>> if version > 3.004001 && perl_version >= 5.010000
>> meta PDS_FROM_2_EMAILS __PDS_FROM_2_EMAILS && !__VIA_ML &&
>> !__VIA_RESIGNER
>> endif
>>
>> if version > 3.004001 && perl_version >= 5.010000
>> header __PDS_FROM_2_EMAILS From =~
>> /^\W+([\w+.-]+\@[\w.-]+\.\w\w++)(?:[^\n\w<]{0,80})?<(?!\1)[^\n\s]*\@/i
>> endif
>>
>> This produced no lint warnings with the above combination. I am
>> missing why it is causing problems in Burnie's configuration. Is
>> 3.3.1 really that different here from 3.3.2 which is silent?
>
> I did a quick troll through the SVN history but nothing leapt out at me.
> However, I'm not that familiar with the parser.
>
> I can confirm 3.2.5 *does* generate a lint warning with that syntax (an old
> VM I have).
>
> Could somebody else running 3.3.1 confirm Burnie's results?

# spamassassin --version
SpamAssassin version 3.3.1
running on Perl version 5.10.0


if version > 3.004001 && perl_version >= 5.010000
body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
endif

is silent (no errors, no warnings in a --lint)

if version > 3.004001
if perl_version >= 5.010000
body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
endif
endif

throws a warning on --lint
Dec 1 16:44:30.000 [29399] warn: Argument "perl_version" isn't numeric in numeric ge (>=) at (eval 2681) line 1.

So it looks like it's perl version dependent.


--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Re: Argument "perl_version" isn't numeric [ In reply to ]
On 2014-12-01 12:18, Burnie wrote:
> On 12/01/2014 08:50 PM, John Hardin wrote:
>> On Mon, 1 Dec 2014, Bob Proulx wrote:
>>
>>> $ spamassassin --version
>>> SpamAssassin version 3.3.2
>>> running on Perl version 5.14.2
>>>
>>> if version > 3.004001 && perl_version >= 5.010000
>>> meta PDS_FROM_2_EMAILS __PDS_FROM_2_EMAILS && !__VIA_ML &&
>>> !__VIA_RESIGNER
>>> endif
>>>
>>> if version > 3.004001 && perl_version >= 5.010000
>>> header __PDS_FROM_2_EMAILS From =~
>>> /^\W+([\w+.-]+\@[\w.-]+\.\w\w++)(?:[^\n\w<]{0,80})?<(?!\1)[^\n\s]*\@/i
>>> endif
>>>
>>> This produced no lint warnings with the above combination. I am
>>> missing why it is causing problems in Burnie's configuration. Is
>>> 3.3.1 really that different here from 3.3.2 which is silent?
>>
>> I did a quick troll through the SVN history but nothing leapt out at me.
>> However, I'm not that familiar with the parser.
>>
>> I can confirm 3.2.5 *does* generate a lint warning with that syntax (an
>> old VM I have).
>>
>> Could somebody else running 3.3.1 confirm Burnie's results?
>
>
> A "preliminary" test here - on Perl 5.8.8 - gives the same warning in
> 3.3.1, 3.3.2 and 3.4.0. So it might have to do with the Perl version.
>
>
> # (cd Mail-SpamAssassin-3.3.1 && ./spamassassin --lint)
> Dec 1 21:15:12.602 [21690] warn: Argument "perl_version" isn't numeric in
> numeric ge (>=) at (eval 313) line 2.
>
> # (cd Mail-SpamAssassin-3.3.2 && ./spamassassin --lint)
> Dec 1 21:15:20.617 [21696] warn: Argument "perl_version" isn't numeric in
> numeric ge (>=) at (eval 313) line 2.
>
> # (cd Mail-SpamAssassin-3.4.0 && ./spamassassin --lint)
> Dec 1 21:15:30.946 [21706] warn: Argument "perl_version" isn't numeric in
> numeric ge (>=) at (eval 314) line 2.

I just added the following to my user-prefs file:
if version > 3.004001 && perl_version >= 5.010000
meta PDS_FROM_2_EMAILS __PDS_FROM_2_EMAILS && !__VIA_ML &&
!__VIA_RESIGNER
endif

No error here SL6.6, perl 5.10.1 and SA 3.3.1.

{^_^}

1 2 3 4 5 6  View All