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 applied those patches.
unacceptable workaround
frankly doing so may get you fired because you risk to break other
packages from the operating system with unknown side-affects and
recommend such actions should start with a big warning
* Fedora 20 is one of the most recent OS environments
* SpamAssassin 3.4.0 is the recent upstream version
* Perl 5.18.4 is recent (Fri Oct 03 2014)
"if perl_version >= 5.010000" must not throw warning with perl 5.18.x
nobody right in has mind is patching perl-modules installed with the OS
package-managment in case of recent SA installed with the
package-managment to work around broken rules on a production server
the issue was introduced with SA rule-updates and has to be fixed there
> 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
> 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.
unacceptable workaround
frankly doing so may get you fired because you risk to break other
packages from the operating system with unknown side-affects and
recommend such actions should start with a big warning
* Fedora 20 is one of the most recent OS environments
* SpamAssassin 3.4.0 is the recent upstream version
* Perl 5.18.4 is recent (Fri Oct 03 2014)
"if perl_version >= 5.010000" must not throw warning with perl 5.18.x
nobody right in has mind is patching perl-modules installed with the OS
package-managment in case of recent SA installed with the
package-managment to work around broken rules on a production server
the issue was introduced with SA rule-updates and has to be fixed there
> 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