Mailing List Archive

Argument "perl_version" isn't numeric
Hello

Anyone else seen this in v3.4.0?

sa-learn --dump magic
Argument "perl_version" isn't numeric in numeric ge (>=) at (eval 530) line 2.
Argument "perl_version" isn't numeric in numeric ge (>=) at (eval 1023) line 2.
0.000 0 3 0 non-token data: bayes db version
0.000 0 916480 0 non-token data: nspam
0.000 0 641170 0 non-token data: nham
0.000 0 176425 0 non-token data: ntokens
0.000 0 1415097712 0 non-token data: oldest atime
0.000 0 1417254571 0 non-token data: newest atime
0.000 0 1417250274 0 non-token data: last journal sync atime
0.000 0 1417231548 0 non-token data: last expiry atime
0.000 0 0 0 non-token data: last expire atime delta
0.000 0 0 0 non-token data: last expire reduction count

--
Best regards,
Niamh mailto:niamh@fullbore.co.uk
Re: Argument "perl_version" isn't numeric [ In reply to ]
On Sat, Nov 29, 2014 at 5:25 AM, Niamh Holding <niamh@fullbore.co.uk> wrote:
>
> Hello
>
> Anyone else seen this in v3.4.0?
>
> sa-learn --dump magic
> Argument "perl_version" isn't numeric in numeric ge (>=) at (eval 530) line 2.
> Argument "perl_version" isn't numeric in numeric ge (>=) at (eval 1023) line 2.

Last night's 3.003002 update spit out this:
Argument "perl_version" isn't numeric in numeric ge (>=) at (eval 490) line 1.
Argument "perl_version" isn't numeric in numeric ge (>=) at (eval
1000) line 1.

-Jim P.
Re: Argument "perl_version" isn't numeric [ In reply to ]
Am 29.11.2014 um 11:39 schrieb Jim Popovitch:
> On Sat, Nov 29, 2014 at 5:25 AM, Niamh Holding <niamh@fullbore.co.uk> wrote:
>>
>> Hello
>>
>> Anyone else seen this in v3.4.0?
>>
>> sa-learn --dump magic
>> Argument "perl_version" isn't numeric in numeric ge (>=) at (eval 530) line 2.
>> Argument "perl_version" isn't numeric in numeric ge (>=) at (eval 1023) line 2.
>
> Last night's 3.003002 update spit out this:
> Argument "perl_version" isn't numeric in numeric ge (>=) at (eval 490) line 1.
> Argument "perl_version" isn't numeric in numeric ge (>=) at (eval
> 1000) line 1.

the same here with perl-5.18.4-291.fc20.x86_64

Argument "perl_version" isn't numeric in numeric ge (>=) at (eval 652)
line 1.
Argument "perl_version" isn't numeric in numeric ge (>=) at (eval 1145)
line 1.
29-Nov-2014 05:25:31: SpamAssassin: Update processed successfully
RE: Argument "perl_version" isn't numeric [ In reply to ]
-----Original Message-----
From: Martin [mailto:marti@ntlworld.com]
Sent: Saturday, November 29, 2014 10:58 AM
To: 'Niamh Holding'
Subject: RE: Argument "perl_version" isn't numeric

> -----Original Message-----
> From: Niamh Holding [mailto:niamh@fullbore.co.uk]
> Sent: Saturday, November 29, 2014 10:26 AM
> To: users@spamassassin.apache.org
> Subject: Argument "perl_version" isn't numeric
>
>
> Hello
>
> Anyone else seen this in v3.4.0?
>
> sa-learn --dump magic
> Argument "perl_version" isn't numeric in numeric ge (>=) at (eval 530)
> line 2.
> Argument "perl_version" isn't numeric in numeric ge (>=) at (eval
> 1023) line 2.
> 0.000 0 3 0 non-token data: bayes
> db version
> 0.000 0 916480 0 non-token data: nspam
> 0.000 0 641170 0 non-token data: nham
> 0.000 0 176425 0 non-token data: ntokens
> 0.000 0 1415097712 0 non-token data: oldest atime
> 0.000 0 1417254571 0 non-token data: newest atime
> 0.000 0 1417250274 0 non-token data: last
> journal sync atime
> 0.000 0 1417231548 0 non-token data: last
> expiry atime
> 0.000 0 0 0 non-token data: last
> expire atime delta
> 0.000 0 0 0 non-token data: last
> expire reduction count
>
> --
> Best regards,
> Niamh mailto:niamh@fullbore.co.uk

Since cron ran sa-update last night, I get these errors running sa-compile,
sa-learn and spamassassin --lint, which showed it happening after reading
72_active.cf.

I had just re-installed spamassassin thinking something was broken my end,
glad it's not just me.

Martin
RE: Argument "perl_version" isn't numeric [ In reply to ]
I seem to have found the problems in 72active.cf

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

And

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

I have hashed them out and all seems fine now
Re: Argument "perl_version" isn't numeric [ In reply to ]
On Sat, 2014-11-29 at 10:25 +0000, Niamh Holding wrote:
> Hello
>
> Anyone else seen this in v3.4.0?
>
Yes, but with 3.3.2, not 3.4.0.

Last night was the first time I've ever seen it. It was displayed by the
sa_update cron job.


Martin
RE: Argument "perl_version" isn't numeric [ In reply to ]
There were changes made but I had a feeling they might not be backwards compatible. Will look at changing that to a has/can function but leave the new perl version code for future use.
Regards,
KAM

On November 29, 2014 6:32:15 AM EST, Martin <marti@ntlworld.com> wrote:
>
>I seem to have found the problems in 72active.cf
>
>if perl_version >= 5.010000
> meta PDS_FROM_2_EMAILS __PDS_FROM_2_EMAILS && !__VIA_ML &&
>!__VIA_RESIGNER
>endif
>
>And
>
>if perl_version >= 5.010000
> header __PDS_FROM_2_EMAILS From =~
>/^\W+([\w+.-]+\@[\w.-]+\.\w\w++)(?:[^\n\w<]{0,80})?<(?!\1)[^\n\s]*\@/i
>endif
>
>I have hashed them out and all seems fine now
Re: Argument "perl_version" isn't numeric [ In reply to ]
Am 29.11.2014 um 15:11 schrieb Kevin A. McGrail:
> There were changes made but I had a feeling they might not be backwards
> compatible. Will look at changing that to a has/can function but leave
> the new perl version code for future use.

that hapens also with a recent perl-5.18 while the old rule did not have
a problem on such setups but now the "if perl_version >= 5.010000" seems
to not work as expected on old as well as recent environments

> On November 29, 2014 6:32:15 AM EST, Martin <marti@ntlworld.com> wrote:
>
>
> I seem to have found the problems in72active.cf <http://72active.cf>
>
> if perl_version >= 5.010000
> meta PDS_FROM_2_EMAILS __PDS_FROM_2_EMAILS && !__VIA_ML &&
> !__VIA_RESIGNER
> endif
>
> And
>
> if perl_version >= 5.010000
> header __PDS_FROM_2_EMAILS From =~
> /^\W+([\w+.-]+\@[\w.-]+\.\w\w++)(?:[^\n\w<]{0,80})?<(?!\1)[^\n\s]*\@/i
> endif
>
> I have hashed them out and all seems fine now
Re: Argument "perl_version" isn't numeric [ In reply to ]
On Sat, 2014-11-29 at 15:24 +0100, Reindl Harald wrote:
>
> Am 29.11.2014 um 15:11 schrieb Kevin A. McGrail:
> > There were changes made but I had a feeling they might not be backwards
> > compatible. Will look at changing that to a has/can function but leave
> > the new perl version code for future use.
>
> that hapens also with a recent perl-5.18 while the old rule did not have
> a problem on such setups but now the "if perl_version >= 5.010000" seems
> to not work as expected on old as well as recent environments
>
And 5.16.3 too

....yeah, I know I need an upgrade but I just can't get a round tuit.



Martin
Re: Argument "perl_version" isn't numeric [ In reply to ]
It is a Spamassassin code change to try and limit rules that require a specific version of perl.
Regards,
KAM

On November 29, 2014 9:53:16 AM EST, Martin Gregorie <martin@gregorie.org> wrote:
>On Sat, 2014-11-29 at 15:24 +0100, Reindl Harald wrote:
>>
>> Am 29.11.2014 um 15:11 schrieb Kevin A. McGrail:
>> > There were changes made but I had a feeling they might not be
>backwards
>> > compatible. Will look at changing that to a has/can function but
>leave
>> > the new perl version code for future use.
>>
>> that hapens also with a recent perl-5.18 while the old rule did not
>have
>> a problem on such setups but now the "if perl_version >= 5.010000"
>seems
>> to not work as expected on old as well as recent environments
>>
>And 5.16.3 too
>
>....yeah, I know I need an upgrade but I just can't get a round tuit.
>
>
>
>Martin
Re: Argument "perl_version" isn't numeric [ In reply to ]
On Sat, 29 Nov 2014, Niamh Holding wrote:

> Anyone else seen this in v3.4.0?
>
> sa-learn --dump magic
> Argument "perl_version" isn't numeric in numeric ge (>=) at (eval 530) line 2.
> Argument "perl_version" isn't numeric in numeric ge (>=) at (eval 1023) line 2.

Please see https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7107
and https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7108

This is just a warning.

Unfortunately this can't be hidden from the parser using
if version > 3.004000
as the parser will still try to parse stuff inside the false branch of a
conditions.

I underestimated the reaction to having such a warning emitted. I will
disable that rule until the perl_version catability is offically released.

--
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
-----------------------------------------------------------------------
"Bother," said Pooh as he struggled with /etc/sendmail.cf, "it never
does quite what I want. I wish Christopher Robin was here."
-- Peter da Silva in a.s.r
-----------------------------------------------------------------------
26 days until Christmas
Re: Argument "perl_version" isn't numeric [ In reply to ]
Hello John,

Saturday, November 29, 2014, 6:21:01 PM, you wrote:

JH> This is just a warning.

I guessed given that the bayes lesrning carried on after.

--
Best regards,
Niamh mailto:niamh@fullbore.co.uk
Re: Argument "perl_version" isn't numeric [ In reply to ]
On 29. nov. 2014 17.14.44 "Kevin A. McGrail" <KMcGrail@PCCC.com> wrote:

> It is a Spamassassin code change to try and limit rules that require a
> specific version of perl.
> Regards,

Upgraded here to latest trunk version of sa, there is it working as
designed, but on older 3.4.1, 3.4.0, 3.3.2 it fails
Re: Argument "perl_version" isn't numeric [ In reply to ]
On Sat, 29 Nov 2014, Benny Pedersen wrote:

> On 29. nov. 2014 17.14.44 "Kevin A. McGrail" <KMcGrail@PCCC.com> wrote:
>
>> It is a Spamassassin code change to try and limit rules that require a
>> specific version of perl.
>
> Upgraded here to latest trunk version of sa, there is it working as designed,
> but on older 3.4.1, 3.4.0, 3.3.2 it fails

Of course it fails, they don't recognize "perl_version" in a conditional.
If that construct is ever used to protect rules that use more-recent perl
syntax, we will have to accept that older SA will behave this way.

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.

--
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
-----------------------------------------------------------------------
"Bother," said Pooh as he struggled with /etc/sendmail.cf, "it never
does quite what I want. I wish Christopher Robin was here."
-- Peter da Silva in a.s.r
-----------------------------------------------------------------------
26 days until Christmas
Re: Argument "perl_version" isn't numeric [ In reply to ]
Am 29.11.2014 um 23:27 schrieb John Hardin:
> On Sat, 29 Nov 2014, Benny Pedersen wrote:
>
>> On 29. nov. 2014 17.14.44 "Kevin A. McGrail" <KMcGrail@PCCC.com> wrote:
>>
>>> It is a Spamassassin code change to try and limit rules that require a
>>> specific version of perl.
>>
>> Upgraded here to latest trunk version of sa, there is it working as
>> designed, but on older 3.4.1, 3.4.0, 3.3.2 it fails
>
> Of course it fails, they don't recognize "perl_version" in a
> conditional. If that construct is ever used to protect rules that use
> more-recent perl syntax, we will have to accept that older SA will
> behave this way.
>
> 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

don't get me wrong but this *warning* triggers cron mails and spits
messages in case of every SA related command - that's unacceptable and
in fact worser than without that check

before *only* outdated perl versions where affected, now it hits also
recent Fedora setups working before without any warning and with that
rule included

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
Re: Argument "perl_version" isn't numeric [ In reply to ]
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
>
> don't get me wrong but this *warning* triggers cron mails and spits messages
> in case of every SA related command - that's unacceptable and in fact worser
> than without that check
>
> before *only* outdated perl versions where affected, now it hits also recent
> Fedora setups working before without any warning and with that rule included

As I said, I underestimated the reaction to doing that.

> 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 this effectively means we cannot add new features to SA conditionals
because they might do this to older installs.

--
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
-----------------------------------------------------------------------
"Bother," said Pooh as he struggled with /etc/sendmail.cf, "it never
does quite what I want. I wish Christopher Robin was here."
-- Peter da Silva in a.s.r
-----------------------------------------------------------------------
26 days until Christmas
Re: Argument "perl_version" isn't numeric [ In reply to ]
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 runtime, it would be reasonable to
exclude new version-dependent features if either the $too_old flag is
set or the version number is lower than the feature needs. It would also
be reasonable for sa_update to report the exclusion since that serves to
remind the sysadmin to upgrade.


Martin
RE: Argument "perl_version" isn't numeric [ In reply to ]
> -----Original Message-----
> From: Martin Gregorie [mailto:martin@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 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 runtime, it would be
> reasonable to exclude new version-dependent features if
> either the $too_old flag is set or the version number is
> lower than the feature needs. It would also be reasonable for
> sa_update to report the exclusion since that serves to remind
> the sysadmin to upgrade.
>
>
> Martin
>

Personally I don’t want any warning messages unless something has failed.

Yesterday and again this morning I was getting warning emails every 5 minutes from cron jobs, which is really annoying.

Will the file available via sa-update be the commented out one from tonight? Or do I need to turn sa-update off for a while?

Martin
Re: Argument "perl_version" isn't numeric [ In reply to ]
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 perl
>>
>> don't get me wrong but this *warning* triggers cron mails and spits
>> messages in case of every SA related command - that's unacceptable and
>> in fact worser than without that check
>>
>> before *only* outdated perl versions where affected, now it hits also
>> recent Fedora setups working before without any warning and with that
>> rule included
>
> As I said, I underestimated the reaction to doing that.
>
>> 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 this effectively means we cannot add new features to SA conditionals
> because they might do this to older installs

which new features?
which newer perl?

spamassassin-3.4.0-7.fc20.x86_64
perl-5.18.4-291.fc20.x86_64

that "fix" for older versions is just broken and leads to warnings on a
recent SA with a recent perl while as first people with outdated setups
complained all was fine here
Re: Argument "perl_version" isn't numeric [ In reply to ]
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 failed?
>
> If so, it seems the me that, at runtime, it would be reasonable to
> exclude new version-dependent features if either the $too_old flag is
> set or the version number is lower than the feature needs. It would also
> be reasonable for sa_update to report the exclusion since that serves to
> remind the sysadmin to upgrade.
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 software is for stability. I have no
intention of running any other version of perl then what comes with the
OS. As such I do not expect to get any warnings period. Spamassassin or
sa-update putting out warnings as a public service is crazy.

--
Paul (ganci@nurdog.com)
Re: Argument "perl_version" isn't numeric [ In reply to ]
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 Harald wrote:
>
> 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 perl
>>>
>>> don't get me wrong but this *warning* triggers cron mails and spits
>>> messages in case of every SA related command - that's unacceptable and
>>> in fact worser than without that check
>>>
>>> before *only* outdated perl versions where affected, now it hits also
>>> recent Fedora setups working before without any warning and with that
>>> rule included
>>
>> As I said, I underestimated the reaction to doing that.
>>
>>> 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 this effectively means we cannot add new features to SA conditionals
>> because they might do this to older installs
>
> which new features?
> which newer perl?
>
> spamassassin-3.4.0-7.fc20.x86_64
> perl-5.18.4-291.fc20.x86_64
>
> that "fix" for older versions is just broken and leads to warnings on a
> recent SA with a recent perl while as first people with outdated setups
> complained all was fine here
>
Re: Argument "perl_version" isn't numeric [ In reply to ]
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
>>
>> don't get me wrong but this *warning* triggers cron mails and spits
>> messages in case of every SA related command - that's unacceptable and
>> in fact worser than without that check
>>
>> before *only* outdated perl versions where affected, now it hits also
>> recent Fedora setups working before without any warning and with that
>> rule included
>
> As I said, I underestimated the reaction to doing that.
>
>> 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 this effectively means we cannot add new features to SA conditionals
> because they might do this to older installs.
>

No, just release patches to the older versions to Conf.pm and Parser.pm

These are not COMPILED modules so it is easy to patch them.

The people who even notice the warnings are going to be competent enough
to run patch, and for the people who are running SpamAssassin who aren't
competent enough to be able to do that, I doubt they will be noticing
log entries.

Ted
Re: Argument "perl_version" isn't numeric [ In reply to ]
On 11/30/14 12:34 PM, "Paul R. Ganci" <ganci@nurdog.com> 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 software is for stability.

Yep. And the whole point of running SpamAssassin with sa-update is for
flexibility and agility. The two goals are necessarily in conflict. So...
Looks like you have a few options:
1) Don't run SA on RHEL
2) Run SA on RHEL but turn off sa-update and sacrifice automated reaction
to new spam in the interest of keeping your system static
3) Run SA on RHEL but upgrade perl and SpamAssassin using
third-party-packages or update from source
4) Run SA on RHEL with system perl and system SpamAssassin, run sa-update
with output redirected to /dev/null, and write your own monitoring script
to tell you if sa-update broke spamd
5) Run SA in some kind of container or VM so you can optimize for
spamassassin without tainting the purity of your RHEL install
--
Dave Pooser
Cat-Herder-in-Chief, Pooserville.com
"...Life is not a journey to the grave with the intention of arriving
safely in one pretty and well-preserved piece, but to slide across the
finish line broadside, thoroughly used up, worn out, leaking oil, and
shouting GERONIMO!!!" -- Bill McKenna
Re: Argument "perl_version" isn't numeric [ In reply to ]
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 effectively means we cannot add new features to SA conditionals
>> because they might do this to older installs
>
> which new features?

The perl version check in a conditional.

Trunk SA supports doing that now. But if actually *using* that feature,
even once it's officially released, results in unacceptable warnings in
older SA installs, then at what point can the new feature *actually be
used*?

--
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
-----------------------------------------------------------------------
15 days until Bill of Rights day
Re: Argument "perl_version" isn't numeric [ In reply to ]
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 those patches.
>
> Ted

Yes, distro maintainers applying the patch that implements perl_version
support is another way to address this problem. It's dirt simple and
should be compatible back a long ways.

--
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
-----------------------------------------------------------------------
15 days until Bill of Rights day

1 2 3 4 5 6  View All