[users] spamassassin-3.3.1-1 Dependency Issue

Post by Clayton Keller
spamassassin-3.3.1-1.el5.rf.i386 from rpmforge has depsolving problems
--> Missing Dependency: perl(Razor2) >= 2.61 is needed by package spamassassin-3.3.1-1.el5.rf.i386 (rpmforge)
Error: Missing Dependency: perl(Razor2) >= 2.61 is needed by package spamassassin-3.3.1-1.el5.rf.i386 (rpmforge)

Clayton,

Thanks for the report! This is a known issue; the fix is already in place, and you should see a spamassassin-3.3.1-2 package in the repo that fixes the problem no later than tomorrow.

-steve

--
If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v
http://five.sentenc.es

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.repoforge.org/pipermail/users/attachments/20100322/bdeb69ab/attachment.bin

Clayton Keller

2010-03-22 16:20:12 UTC

Post by Clayton Keller
spamassassin-3.3.1-1.el5.rf.i386 from rpmforge has depsolving problems
--> Missing Dependency: perl(Razor2)>= 2.61 is needed by package spamassassin-3.3.1-1.el5.rf.i386 (rpmforge)
Error: Missing Dependency: perl(Razor2)>= 2.61 is needed by package spamassassin-3.3.1-1.el5.rf.i386 (rpmforge)

Clayton,
Thanks for the report! This is a known issue; the fix is already in place, and you should see a spamassassin-3.3.1-2 package in the repo that fixes the problem no later than tomorrow.
-steve

Steve,

Thank you for the info.

I had one other thought. I believe amavisd-new 2.6.2 or later is now a
requirement for SpamAssassin 3.3.x.

Taken from the SpamAssassin release announcement
(http://svn.apache.org/repos/asf/spamassassin/branches/3.3/build/announcements/3.3.0.txt):

...
- versions of amavisd-new between 2.5.2 and 2.6.1 (inclusive) are
incompatible with SpamAssassin 3.3; please upgrade amavisd to 2.6.2 or
later, or apply a workaround
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6257
...

I'm not sure if you need to take that into consideration with this build
as well but thought I'd pass it along.

Clay

Clayton Keller

2010-03-25 20:51:20 UTC

Post by Clayton Keller
I have attempted to upgrade the SpamAssassin package this morning and
spamassassin-3.3.1-1.el5.rf.i386 from rpmforge has depsolving problems
--> Missing Dependency: perl(Razor2)>= 2.61 is needed by package
spamassassin-3.3.1-1.el5.rf.i386 (rpmforge)
Error: Missing Dependency: perl(Razor2)>= 2.61 is needed by package
spamassassin-3.3.1-1.el5.rf.i386 (rpmforge)

Clayton,
Thanks for the report! This is a known issue; the fix is already in
place, and you should see a spamassassin-3.3.1-2 package in the repo
that fixes the problem no later than tomorrow.
-steve

Steve,
Thank you for the info.
I had one other thought. I believe amavisd-new 2.6.2 or later is now a
requirement for SpamAssassin 3.3.x.
Taken from the SpamAssassin release announcement
...
- versions of amavisd-new between 2.5.2 and 2.6.1 (inclusive) are
incompatible with SpamAssassin 3.3; please upgrade amavisd to 2.6.2 or
later, or apply a workaround
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6257
...
I'm not sure if you need to take that into consideration with this build
as well but thought I'd pass it along.
Clay

I have found another oddity with the build, the newly added requirement
for perl-Mail-SPF is now conflicting with a python-pyspf package that is
being used by pypolicyd-spf from http://www.openspf.org/Software for our
frontline SPF checking.

---
Transaction Check Error:
file /usr/bin/spfquery from install of
perl-Mail-SPF-2.006-1.el5.rf.noarch conflicts with file from package
python-pyspf-2.0.4-2.el5.noarch
---

With previous releases we added the following to our local.cf file:

do_not_use_mail_spf 1

This allows it to fallback to the Mail::SPF::Query rather than Mail::SPF
for the lookups. Which we have installed.

It was also my uderstanding that the SPF plugin in SpamAssassin would
use any exisitng SPF headers which were already present to help prevent
additonal DNS queries, which the openspf software should be creating for us.

I wanted to again pose the question regarding the requirement of the
package as I am unable to install at the present time because of the
conflict. Is this requirement for Mail::SPF really needed to be included
at this time? I am no means authority on this just providing feedback
with our current implementation.

Clayton Keller

2010-03-25 21:06:19 UTC

Clayton,
Thanks for the report! This is a known issue; the fix is already in
place, and you should see a spamassassin-3.3.1-2 package in the repo
that fixes the problem no later than tomorrow.
-steve

Steve,
Thank you for the info.
I had one other thought. I believe amavisd-new 2.6.2 or later is now a
requirement for SpamAssassin 3.3.x.
Taken from the SpamAssassin release announcement
...
- versions of amavisd-new between 2.5.2 and 2.6.1 (inclusive) are
incompatible with SpamAssassin 3.3; please upgrade amavisd to 2.6.2 or
later, or apply a workaround
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6257
...
I'm not sure if you need to take that into consideration with this build
as well but thought I'd pass it along.
Clay

I have found another oddity with the build, the newly added requirement
for perl-Mail-SPF is now conflicting with a python-pyspf package that is
being used by pypolicyd-spf from http://www.openspf.org/Software for our
frontline SPF checking.
---
file /usr/bin/spfquery from install of
perl-Mail-SPF-2.006-1.el5.rf.noarch conflicts with file from package
python-pyspf-2.0.4-2.el5.noarch
---
do_not_use_mail_spf 1
This allows it to fallback to the Mail::SPF::Query rather than Mail::SPF
for the lookups. Which we have installed.
It was also my uderstanding that the SPF plugin in SpamAssassin would
use any exisitng SPF headers which were already present to help prevent
additonal DNS queries, which the openspf software should be creating for us.
I wanted to again pose the question regarding the requirement of the
package as I am unable to install at the present time because of the
conflict. Is this requirement for Mail::SPF really needed to be included
at this time? I am no means authority on this just providing feedback
with our current implementation.

Apologies for replying to my own message so quickly, but I am posing a
simialr question to the SpamAssassin users mailing list for more
clarification on the package requirements regarding Mail::SPF.

Dag Wieers

2010-03-25 21:39:50 UTC

Clayton,
Thanks for the report! This is a known issue; the fix is already in
place, and you should see a spamassassin-3.3.1-2 package in the repo
that fixes the problem no later than tomorrow.
-steve

Steve,
Thank you for the info.
I had one other thought. I believe amavisd-new 2.6.2 or later is now a
requirement for SpamAssassin 3.3.x.
Taken from the SpamAssassin release announcement
...
- versions of amavisd-new between 2.5.2 and 2.6.1 (inclusive) are
incompatible with SpamAssassin 3.3; please upgrade amavisd to 2.6.2 or
later, or apply a workaround
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6257
...
I'm not sure if you need to take that into consideration with this build
as well but thought I'd pass it along.
Clay

I have found another oddity with the build, the newly added requirement
for perl-Mail-SPF is now conflicting with a python-pyspf package that is
being used by pypolicyd-spf from http://www.openspf.org/Software for our
frontline SPF checking.
---
file /usr/bin/spfquery from install of
perl-Mail-SPF-2.006-1.el5.rf.noarch conflicts with file from package
python-pyspf-2.0.4-2.el5.noarch
---
do_not_use_mail_spf 1
This allows it to fallback to the Mail::SPF::Query rather than Mail::SPF
for the lookups. Which we have installed.
It was also my uderstanding that the SPF plugin in SpamAssassin would
use any exisitng SPF headers which were already present to help prevent
additonal DNS queries, which the openspf software should be creating for us.
I wanted to again pose the question regarding the requirement of the
package as I am unable to install at the present time because of the
conflict. Is this requirement for Mail::SPF really needed to be included
at this time? I am no means authority on this just providing feedback
with our current implementation.

Apologies for replying to my own message so quickly, but I am posing a
simialr question to the SpamAssassin users mailing list for more
clarification on the package requirements regarding Mail::SPF.

It is not a strict requirement, but because there is no such thing as
"optional" components with RPM, if we don't add it, most people will
simply not enable it.

I can see that due to path conflicts that could pose a problem, on the
other hand no 2 packages should provide the same binary anyhow and both
projects should find a solution to this.

--
-- dag wieers, dag at wieers.com, http://dag.wieers.com/ --
[Any errors in spelling, tact or fact are transmission errors]

Clayton Keller

2010-03-26 19:48:25 UTC

Post by Clayton Keller
I have attempted to upgrade the SpamAssassin package this

morning > > > and

Post by Clayton Keller
spamassassin-3.3.1-1.el5.rf.i386 from rpmforge has

depsolving > > > problems

Post by Clayton Keller
--> Missing Dependency: perl(Razor2)>= 2.61 is needed by package
spamassassin-3.3.1-1.el5.rf.i386 (rpmforge)
Error: Missing Dependency: perl(Razor2)>= 2.61 is needed by

package

Post by Clayton Keller
spamassassin-3.3.1-1.el5.rf.i386 (rpmforge)

Post by Clayton Keller
Clayton,

Thanks for the report! This is a known issue; the fix is

already in

Post by Steve Huff
place, and you should see a spamassassin-3.3.1-2 package in the repo
that fixes the problem no later than tomorrow.

Post by Steve Huff
-steve
Steve,

Thank you for the info.
I had one other thought. I believe amavisd-new 2.6.2 or later is

now a

Post by Clayton Keller
requirement for SpamAssassin 3.3.x.

Post by Steve Huff
Taken from the SpamAssassin release announcement

- versions of amavisd-new between 2.5.2 and 2.6.1 (inclusive) are
incompatible with SpamAssassin 3.3; please upgrade amavisd to 2.6.2 or
later, or apply a workaround
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6257
...

Post by Steve Huff
I'm not sure if you need to take that into consideration with

this build

Post by Clayton Keller
as well but thought I'd pass it along.

Post by Steve Huff
Clay

I have found another oddity with the build, the newly added requirement
for perl-Mail-SPF is now conflicting with a python-pyspf package that is
being used by pypolicyd-spf from http://www.openspf.org/Software for our
frontline SPF checking.
---
file /usr/bin/spfquery from install of
perl-Mail-SPF-2.006-1.el5.rf.noarch conflicts with file from package
python-pyspf-2.0.4-2.el5.noarch
---
do_not_use_mail_spf 1
This allows it to fallback to the Mail::SPF::Query rather than Mail::SPF
for the lookups. Which we have installed.
It was also my uderstanding that the SPF plugin in SpamAssassin would
use any exisitng SPF headers which were already present to help prevent
additonal DNS queries, which the openspf software should be creating for us.
I wanted to again pose the question regarding the requirement of the
package as I am unable to install at the present time because of the
conflict. Is this requirement for Mail::SPF really needed to be included
at this time? I am no means authority on this just providing feedback
with our current implementation.

Apologies for replying to my own message so quickly, but I am posing a
simialr question to the SpamAssassin users mailing list for more
clarification on the package requirements regarding Mail::SPF.

It is not a strict requirement, but because there is no such thing as
"optional" components with RPM, if we don't add it, most people will
simply not enable it.
I can see that due to path conflicts that could pose a problem, on the
other hand no 2 packages should provide the same binary anyhow and both
projects should find a solution to this.

I wanted to post an update on my issue. After conversing with the pyspf
maintainer I've decided to manually modify the code in pyspf to allow
both to coexist.

Clayton Keller

2010-03-26 19:48:25 UTC

Post by Clayton Keller
I have attempted to upgrade the SpamAssassin package this

morning > > > and

Post by Clayton Keller
spamassassin-3.3.1-1.el5.rf.i386 from rpmforge has

depsolving > > > problems

Post by Clayton Keller
--> Missing Dependency: perl(Razor2)>= 2.61 is needed by package
spamassassin-3.3.1-1.el5.rf.i386 (rpmforge)
Error: Missing Dependency: perl(Razor2)>= 2.61 is needed by

package

Post by Clayton Keller
spamassassin-3.3.1-1.el5.rf.i386 (rpmforge)

Post by Clayton Keller
Clayton,

Thanks for the report! This is a known issue; the fix is

already in

Post by Steve Huff
place, and you should see a spamassassin-3.3.1-2 package in the repo
that fixes the problem no later than tomorrow.

Post by Steve Huff
-steve
Steve,

Thank you for the info.
I had one other thought. I believe amavisd-new 2.6.2 or later is

now a

Post by Clayton Keller
requirement for SpamAssassin 3.3.x.

Post by Steve Huff
Taken from the SpamAssassin release announcement

Post by Steve Huff
I'm not sure if you need to take that into consideration with

this build

Post by Clayton Keller
as well but thought I'd pass it along.

Post by Steve Huff
Clay

I have found another oddity with the build, the newly added requirement
for perl-Mail-SPF is now conflicting with a python-pyspf package that is
being used by pypolicyd-spf from http://www.openspf.org/Software for our
frontline SPF checking.
---
file /usr/bin/spfquery from install of
perl-Mail-SPF-2.006-1.el5.rf.noarch conflicts with file from package
python-pyspf-2.0.4-2.el5.noarch
---
do_not_use_mail_spf 1
This allows it to fallback to the Mail::SPF::Query rather than Mail::SPF
for the lookups. Which we have installed.
It was also my uderstanding that the SPF plugin in SpamAssassin would
use any exisitng SPF headers which were already present to help prevent
additonal DNS queries, which the openspf software should be creating for us.
I wanted to again pose the question regarding the requirement of the
package as I am unable to install at the present time because of the
conflict. Is this requirement for Mail::SPF really needed to be included
at this time? I am no means authority on this just providing feedback
with our current implementation.

Apologies for replying to my own message so quickly, but I am posing a
simialr question to the SpamAssassin users mailing list for more
clarification on the package requirements regarding Mail::SPF.

It is not a strict requirement, but because there is no such thing as
"optional" components with RPM, if we don't add it, most people will
simply not enable it.
I can see that due to path conflicts that could pose a problem, on the
other hand no 2 packages should provide the same binary anyhow and both
projects should find a solution to this.

I wanted to post an update on my issue. After conversing with the pyspf
maintainer I've decided to manually modify the code in pyspf to allow
both to coexist.

Clayton Keller

2010-03-26 19:48:25 UTC

Post by Clayton Keller
I have attempted to upgrade the SpamAssassin package this

morning > > > and

Post by Clayton Keller
spamassassin-3.3.1-1.el5.rf.i386 from rpmforge has

depsolving > > > problems

Post by Clayton Keller
--> Missing Dependency: perl(Razor2)>= 2.61 is needed by package
spamassassin-3.3.1-1.el5.rf.i386 (rpmforge)
Error: Missing Dependency: perl(Razor2)>= 2.61 is needed by

package

Post by Clayton Keller
spamassassin-3.3.1-1.el5.rf.i386 (rpmforge)

Post by Clayton Keller
Clayton,

Thanks for the report! This is a known issue; the fix is

already in

Post by Steve Huff
place, and you should see a spamassassin-3.3.1-2 package in the repo
that fixes the problem no later than tomorrow.

Post by Steve Huff
-steve
Steve,

Thank you for the info.
I had one other thought. I believe amavisd-new 2.6.2 or later is

now a

Post by Clayton Keller
requirement for SpamAssassin 3.3.x.

Post by Steve Huff
Taken from the SpamAssassin release announcement

Post by Steve Huff
I'm not sure if you need to take that into consideration with

this build

Post by Clayton Keller
as well but thought I'd pass it along.

Post by Steve Huff
Clay

I have found another oddity with the build, the newly added requirement
for perl-Mail-SPF is now conflicting with a python-pyspf package that is
being used by pypolicyd-spf from http://www.openspf.org/Software for our
frontline SPF checking.
---
file /usr/bin/spfquery from install of
perl-Mail-SPF-2.006-1.el5.rf.noarch conflicts with file from package
python-pyspf-2.0.4-2.el5.noarch
---
do_not_use_mail_spf 1
This allows it to fallback to the Mail::SPF::Query rather than Mail::SPF
for the lookups. Which we have installed.
It was also my uderstanding that the SPF plugin in SpamAssassin would
use any exisitng SPF headers which were already present to help prevent
additonal DNS queries, which the openspf software should be creating for us.
I wanted to again pose the question regarding the requirement of the
package as I am unable to install at the present time because of the
conflict. Is this requirement for Mail::SPF really needed to be included
at this time? I am no means authority on this just providing feedback
with our current implementation.

Apologies for replying to my own message so quickly, but I am posing a
simialr question to the SpamAssassin users mailing list for more
clarification on the package requirements regarding Mail::SPF.

It is not a strict requirement, but because there is no such thing as
"optional" components with RPM, if we don't add it, most people will
simply not enable it.
I can see that due to path conflicts that could pose a problem, on the
other hand no 2 packages should provide the same binary anyhow and both
projects should find a solution to this.

I wanted to post an update on my issue. After conversing with the pyspf
maintainer I've decided to manually modify the code in pyspf to allow
both to coexist.

Clayton Keller

2010-03-26 19:48:25 UTC

Post by Clayton Keller
I have attempted to upgrade the SpamAssassin package this

morning > > > and

Post by Clayton Keller
spamassassin-3.3.1-1.el5.rf.i386 from rpmforge has

depsolving > > > problems

Post by Clayton Keller
--> Missing Dependency: perl(Razor2)>= 2.61 is needed by package
spamassassin-3.3.1-1.el5.rf.i386 (rpmforge)
Error: Missing Dependency: perl(Razor2)>= 2.61 is needed by

package

Post by Clayton Keller
spamassassin-3.3.1-1.el5.rf.i386 (rpmforge)

Post by Clayton Keller
Clayton,

Thanks for the report! This is a known issue; the fix is

already in

Post by Steve Huff
place, and you should see a spamassassin-3.3.1-2 package in the repo
that fixes the problem no later than tomorrow.

Post by Steve Huff
-steve
Steve,

Thank you for the info.
I had one other thought. I believe amavisd-new 2.6.2 or later is

now a

Post by Clayton Keller
requirement for SpamAssassin 3.3.x.

Post by Steve Huff
Taken from the SpamAssassin release announcement

Post by Steve Huff
I'm not sure if you need to take that into consideration with

this build

Post by Clayton Keller
as well but thought I'd pass it along.

Post by Steve Huff
Clay

I have found another oddity with the build, the newly added requirement
for perl-Mail-SPF is now conflicting with a python-pyspf package that is
being used by pypolicyd-spf from http://www.openspf.org/Software for our
frontline SPF checking.
---
file /usr/bin/spfquery from install of
perl-Mail-SPF-2.006-1.el5.rf.noarch conflicts with file from package
python-pyspf-2.0.4-2.el5.noarch
---
do_not_use_mail_spf 1
This allows it to fallback to the Mail::SPF::Query rather than Mail::SPF
for the lookups. Which we have installed.
It was also my uderstanding that the SPF plugin in SpamAssassin would
use any exisitng SPF headers which were already present to help prevent
additonal DNS queries, which the openspf software should be creating for us.
I wanted to again pose the question regarding the requirement of the
package as I am unable to install at the present time because of the
conflict. Is this requirement for Mail::SPF really needed to be included
at this time? I am no means authority on this just providing feedback
with our current implementation.

Apologies for replying to my own message so quickly, but I am posing a
simialr question to the SpamAssassin users mailing list for more
clarification on the package requirements regarding Mail::SPF.

It is not a strict requirement, but because there is no such thing as
"optional" components with RPM, if we don't add it, most people will
simply not enable it.
I can see that due to path conflicts that could pose a problem, on the
other hand no 2 packages should provide the same binary anyhow and both
projects should find a solution to this.

I wanted to post an update on my issue. After conversing with the pyspf
maintainer I've decided to manually modify the code in pyspf to allow
both to coexist.

Clayton Keller

2010-03-26 19:48:25 UTC

Post by Clayton Keller
I have attempted to upgrade the SpamAssassin package this

morning > > > and

Post by Clayton Keller
spamassassin-3.3.1-1.el5.rf.i386 from rpmforge has

depsolving > > > problems

Post by Clayton Keller
--> Missing Dependency: perl(Razor2)>= 2.61 is needed by package
spamassassin-3.3.1-1.el5.rf.i386 (rpmforge)
Error: Missing Dependency: perl(Razor2)>= 2.61 is needed by

package

Post by Clayton Keller
spamassassin-3.3.1-1.el5.rf.i386 (rpmforge)

Post by Clayton Keller
Clayton,

Thanks for the report! This is a known issue; the fix is

already in

Post by Steve Huff
place, and you should see a spamassassin-3.3.1-2 package in the repo
that fixes the problem no later than tomorrow.

Post by Steve Huff
-steve
Steve,

Thank you for the info.
I had one other thought. I believe amavisd-new 2.6.2 or later is

now a

Post by Clayton Keller
requirement for SpamAssassin 3.3.x.

Post by Steve Huff
Taken from the SpamAssassin release announcement

Post by Steve Huff
I'm not sure if you need to take that into consideration with

this build

Post by Clayton Keller
as well but thought I'd pass it along.

Post by Steve Huff
Clay

I have found another oddity with the build, the newly added requirement
for perl-Mail-SPF is now conflicting with a python-pyspf package that is
being used by pypolicyd-spf from http://www.openspf.org/Software for our
frontline SPF checking.
---
file /usr/bin/spfquery from install of
perl-Mail-SPF-2.006-1.el5.rf.noarch conflicts with file from package
python-pyspf-2.0.4-2.el5.noarch
---
do_not_use_mail_spf 1
This allows it to fallback to the Mail::SPF::Query rather than Mail::SPF
for the lookups. Which we have installed.
It was also my uderstanding that the SPF plugin in SpamAssassin would
use any exisitng SPF headers which were already present to help prevent
additonal DNS queries, which the openspf software should be creating for us.
I wanted to again pose the question regarding the requirement of the
package as I am unable to install at the present time because of the
conflict. Is this requirement for Mail::SPF really needed to be included
at this time? I am no means authority on this just providing feedback
with our current implementation.

Apologies for replying to my own message so quickly, but I am posing a
simialr question to the SpamAssassin users mailing list for more
clarification on the package requirements regarding Mail::SPF.

It is not a strict requirement, but because there is no such thing as
"optional" components with RPM, if we don't add it, most people will
simply not enable it.
I can see that due to path conflicts that could pose a problem, on the
other hand no 2 packages should provide the same binary anyhow and both
projects should find a solution to this.

I wanted to post an update on my issue. After conversing with the pyspf
maintainer I've decided to manually modify the code in pyspf to allow
both to coexist.

Dag Wieers

2010-03-25 21:39:50 UTC

Clayton,
Thanks for the report! This is a known issue; the fix is already in
place, and you should see a spamassassin-3.3.1-2 package in the repo
that fixes the problem no later than tomorrow.
-steve

Steve,
Thank you for the info.
I had one other thought. I believe amavisd-new 2.6.2 or later is now a
requirement for SpamAssassin 3.3.x.
Taken from the SpamAssassin release announcement
...
- versions of amavisd-new between 2.5.2 and 2.6.1 (inclusive) are
incompatible with SpamAssassin 3.3; please upgrade amavisd to 2.6.2 or
later, or apply a workaround
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6257
...
I'm not sure if you need to take that into consideration with this build
as well but thought I'd pass it along.
Clay

I have found another oddity with the build, the newly added requirement
for perl-Mail-SPF is now conflicting with a python-pyspf package that is
being used by pypolicyd-spf from http://www.openspf.org/Software for our
frontline SPF checking.
---
file /usr/bin/spfquery from install of
perl-Mail-SPF-2.006-1.el5.rf.noarch conflicts with file from package
python-pyspf-2.0.4-2.el5.noarch
---
do_not_use_mail_spf 1
This allows it to fallback to the Mail::SPF::Query rather than Mail::SPF
for the lookups. Which we have installed.
It was also my uderstanding that the SPF plugin in SpamAssassin would
use any exisitng SPF headers which were already present to help prevent
additonal DNS queries, which the openspf software should be creating for us.
I wanted to again pose the question regarding the requirement of the
package as I am unable to install at the present time because of the
conflict. Is this requirement for Mail::SPF really needed to be included
at this time? I am no means authority on this just providing feedback
with our current implementation.

Apologies for replying to my own message so quickly, but I am posing a
simialr question to the SpamAssassin users mailing list for more
clarification on the package requirements regarding Mail::SPF.

--
-- dag wieers, dag at wieers.com, http://dag.wieers.com/ --
[Any errors in spelling, tact or fact are transmission errors]

Dag Wieers

2010-03-25 21:39:50 UTC

Clayton,
Thanks for the report! This is a known issue; the fix is already in
place, and you should see a spamassassin-3.3.1-2 package in the repo
that fixes the problem no later than tomorrow.
-steve

Steve,
Thank you for the info.
I had one other thought. I believe amavisd-new 2.6.2 or later is now a
requirement for SpamAssassin 3.3.x.
Taken from the SpamAssassin release announcement
...
- versions of amavisd-new between 2.5.2 and 2.6.1 (inclusive) are
incompatible with SpamAssassin 3.3; please upgrade amavisd to 2.6.2 or
later, or apply a workaround
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6257
...
I'm not sure if you need to take that into consideration with this build
as well but thought I'd pass it along.
Clay

I have found another oddity with the build, the newly added requirement
for perl-Mail-SPF is now conflicting with a python-pyspf package that is
being used by pypolicyd-spf from http://www.openspf.org/Software for our
frontline SPF checking.
---
file /usr/bin/spfquery from install of
perl-Mail-SPF-2.006-1.el5.rf.noarch conflicts with file from package
python-pyspf-2.0.4-2.el5.noarch
---
do_not_use_mail_spf 1
This allows it to fallback to the Mail::SPF::Query rather than Mail::SPF
for the lookups. Which we have installed.
It was also my uderstanding that the SPF plugin in SpamAssassin would
use any exisitng SPF headers which were already present to help prevent
additonal DNS queries, which the openspf software should be creating for us.
I wanted to again pose the question regarding the requirement of the
package as I am unable to install at the present time because of the
conflict. Is this requirement for Mail::SPF really needed to be included
at this time? I am no means authority on this just providing feedback
with our current implementation.

Apologies for replying to my own message so quickly, but I am posing a
simialr question to the SpamAssassin users mailing list for more
clarification on the package requirements regarding Mail::SPF.

--
-- dag wieers, dag at wieers.com, http://dag.wieers.com/ --
[Any errors in spelling, tact or fact are transmission errors]

Dag Wieers

2010-03-25 21:39:50 UTC

Clayton,
Thanks for the report! This is a known issue; the fix is already in
place, and you should see a spamassassin-3.3.1-2 package in the repo
that fixes the problem no later than tomorrow.
-steve

Steve,
Thank you for the info.
I had one other thought. I believe amavisd-new 2.6.2 or later is now a
requirement for SpamAssassin 3.3.x.
Taken from the SpamAssassin release announcement
...
- versions of amavisd-new between 2.5.2 and 2.6.1 (inclusive) are
incompatible with SpamAssassin 3.3; please upgrade amavisd to 2.6.2 or
later, or apply a workaround
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6257
...
I'm not sure if you need to take that into consideration with this build
as well but thought I'd pass it along.
Clay

I have found another oddity with the build, the newly added requirement
for perl-Mail-SPF is now conflicting with a python-pyspf package that is
being used by pypolicyd-spf from http://www.openspf.org/Software for our
frontline SPF checking.
---
file /usr/bin/spfquery from install of
perl-Mail-SPF-2.006-1.el5.rf.noarch conflicts with file from package
python-pyspf-2.0.4-2.el5.noarch
---
do_not_use_mail_spf 1
This allows it to fallback to the Mail::SPF::Query rather than Mail::SPF
for the lookups. Which we have installed.
It was also my uderstanding that the SPF plugin in SpamAssassin would
use any exisitng SPF headers which were already present to help prevent
additonal DNS queries, which the openspf software should be creating for us.
I wanted to again pose the question regarding the requirement of the
package as I am unable to install at the present time because of the
conflict. Is this requirement for Mail::SPF really needed to be included
at this time? I am no means authority on this just providing feedback
with our current implementation.

Apologies for replying to my own message so quickly, but I am posing a
simialr question to the SpamAssassin users mailing list for more
clarification on the package requirements regarding Mail::SPF.

--
-- dag wieers, dag at wieers.com, http://dag.wieers.com/ --
[Any errors in spelling, tact or fact are transmission errors]

Dag Wieers

2010-03-25 21:39:50 UTC

Clayton,
Thanks for the report! This is a known issue; the fix is already in
place, and you should see a spamassassin-3.3.1-2 package in the repo
that fixes the problem no later than tomorrow.
-steve

Steve,
Thank you for the info.
I had one other thought. I believe amavisd-new 2.6.2 or later is now a
requirement for SpamAssassin 3.3.x.
Taken from the SpamAssassin release announcement
...
- versions of amavisd-new between 2.5.2 and 2.6.1 (inclusive) are
incompatible with SpamAssassin 3.3; please upgrade amavisd to 2.6.2 or
later, or apply a workaround
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6257
...
I'm not sure if you need to take that into consideration with this build
as well but thought I'd pass it along.
Clay

I have found another oddity with the build, the newly added requirement
for perl-Mail-SPF is now conflicting with a python-pyspf package that is
being used by pypolicyd-spf from http://www.openspf.org/Software for our
frontline SPF checking.
---
file /usr/bin/spfquery from install of
perl-Mail-SPF-2.006-1.el5.rf.noarch conflicts with file from package
python-pyspf-2.0.4-2.el5.noarch
---
do_not_use_mail_spf 1
This allows it to fallback to the Mail::SPF::Query rather than Mail::SPF
for the lookups. Which we have installed.
It was also my uderstanding that the SPF plugin in SpamAssassin would
use any exisitng SPF headers which were already present to help prevent
additonal DNS queries, which the openspf software should be creating for us.
I wanted to again pose the question regarding the requirement of the
package as I am unable to install at the present time because of the
conflict. Is this requirement for Mail::SPF really needed to be included
at this time? I am no means authority on this just providing feedback
with our current implementation.

Apologies for replying to my own message so quickly, but I am posing a
simialr question to the SpamAssassin users mailing list for more
clarification on the package requirements regarding Mail::SPF.

--
-- dag wieers, dag at wieers.com, http://dag.wieers.com/ --
[Any errors in spelling, tact or fact are transmission errors]

Clayton Keller

2010-03-25 21:06:19 UTC

Clayton,
Thanks for the report! This is a known issue; the fix is already in
place, and you should see a spamassassin-3.3.1-2 package in the repo
that fixes the problem no later than tomorrow.
-steve

Steve,
Thank you for the info.
I had one other thought. I believe amavisd-new 2.6.2 or later is now a
requirement for SpamAssassin 3.3.x.
Taken from the SpamAssassin release announcement
...
- versions of amavisd-new between 2.5.2 and 2.6.1 (inclusive) are
incompatible with SpamAssassin 3.3; please upgrade amavisd to 2.6.2 or
later, or apply a workaround
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6257
...
I'm not sure if you need to take that into consideration with this build
as well but thought I'd pass it along.
Clay

I have found another oddity with the build, the newly added requirement
for perl-Mail-SPF is now conflicting with a python-pyspf package that is
being used by pypolicyd-spf from http://www.openspf.org/Software for our
frontline SPF checking.
---
file /usr/bin/spfquery from install of
perl-Mail-SPF-2.006-1.el5.rf.noarch conflicts with file from package
python-pyspf-2.0.4-2.el5.noarch
---
do_not_use_mail_spf 1
This allows it to fallback to the Mail::SPF::Query rather than Mail::SPF
for the lookups. Which we have installed.
It was also my uderstanding that the SPF plugin in SpamAssassin would
use any exisitng SPF headers which were already present to help prevent
additonal DNS queries, which the openspf software should be creating for us.
I wanted to again pose the question regarding the requirement of the
package as I am unable to install at the present time because of the
conflict. Is this requirement for Mail::SPF really needed to be included
at this time? I am no means authority on this just providing feedback
with our current implementation.

Apologies for replying to my own message so quickly, but I am posing a
simialr question to the SpamAssassin users mailing list for more
clarification on the package requirements regarding Mail::SPF.

Clayton Keller

2010-03-25 21:06:19 UTC

Clayton,
Thanks for the report! This is a known issue; the fix is already in
place, and you should see a spamassassin-3.3.1-2 package in the repo
that fixes the problem no later than tomorrow.
-steve

Steve,
Thank you for the info.
I had one other thought. I believe amavisd-new 2.6.2 or later is now a
requirement for SpamAssassin 3.3.x.
Taken from the SpamAssassin release announcement
...
- versions of amavisd-new between 2.5.2 and 2.6.1 (inclusive) are
incompatible with SpamAssassin 3.3; please upgrade amavisd to 2.6.2 or
later, or apply a workaround
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6257
...
I'm not sure if you need to take that into consideration with this build
as well but thought I'd pass it along.
Clay

I have found another oddity with the build, the newly added requirement
for perl-Mail-SPF is now conflicting with a python-pyspf package that is
being used by pypolicyd-spf from http://www.openspf.org/Software for our
frontline SPF checking.
---
file /usr/bin/spfquery from install of
perl-Mail-SPF-2.006-1.el5.rf.noarch conflicts with file from package
python-pyspf-2.0.4-2.el5.noarch
---
do_not_use_mail_spf 1
This allows it to fallback to the Mail::SPF::Query rather than Mail::SPF
for the lookups. Which we have installed.
It was also my uderstanding that the SPF plugin in SpamAssassin would
use any exisitng SPF headers which were already present to help prevent
additonal DNS queries, which the openspf software should be creating for us.
I wanted to again pose the question regarding the requirement of the
package as I am unable to install at the present time because of the
conflict. Is this requirement for Mail::SPF really needed to be included
at this time? I am no means authority on this just providing feedback
with our current implementation.

Apologies for replying to my own message so quickly, but I am posing a
simialr question to the SpamAssassin users mailing list for more
clarification on the package requirements regarding Mail::SPF.

Clayton Keller

2010-03-25 21:06:19 UTC

Clayton,
Thanks for the report! This is a known issue; the fix is already in
place, and you should see a spamassassin-3.3.1-2 package in the repo
that fixes the problem no later than tomorrow.
-steve

Steve,
Thank you for the info.
I had one other thought. I believe amavisd-new 2.6.2 or later is now a
requirement for SpamAssassin 3.3.x.
Taken from the SpamAssassin release announcement
...
- versions of amavisd-new between 2.5.2 and 2.6.1 (inclusive) are
incompatible with SpamAssassin 3.3; please upgrade amavisd to 2.6.2 or
later, or apply a workaround
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6257
...
I'm not sure if you need to take that into consideration with this build
as well but thought I'd pass it along.
Clay

I have found another oddity with the build, the newly added requirement
for perl-Mail-SPF is now conflicting with a python-pyspf package that is
being used by pypolicyd-spf from http://www.openspf.org/Software for our
frontline SPF checking.
---
file /usr/bin/spfquery from install of
perl-Mail-SPF-2.006-1.el5.rf.noarch conflicts with file from package
python-pyspf-2.0.4-2.el5.noarch
---
do_not_use_mail_spf 1
This allows it to fallback to the Mail::SPF::Query rather than Mail::SPF
for the lookups. Which we have installed.
It was also my uderstanding that the SPF plugin in SpamAssassin would
use any exisitng SPF headers which were already present to help prevent
additonal DNS queries, which the openspf software should be creating for us.
I wanted to again pose the question regarding the requirement of the
package as I am unable to install at the present time because of the
conflict. Is this requirement for Mail::SPF really needed to be included
at this time? I am no means authority on this just providing feedback
with our current implementation.

Apologies for replying to my own message so quickly, but I am posing a
simialr question to the SpamAssassin users mailing list for more
clarification on the package requirements regarding Mail::SPF.

Clayton Keller

2010-03-25 21:06:19 UTC

Clayton,
Thanks for the report! This is a known issue; the fix is already in
place, and you should see a spamassassin-3.3.1-2 package in the repo
that fixes the problem no later than tomorrow.
-steve

Steve,
Thank you for the info.
I had one other thought. I believe amavisd-new 2.6.2 or later is now a
requirement for SpamAssassin 3.3.x.
Taken from the SpamAssassin release announcement
...
- versions of amavisd-new between 2.5.2 and 2.6.1 (inclusive) are
incompatible with SpamAssassin 3.3; please upgrade amavisd to 2.6.2 or
later, or apply a workaround
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6257
...
I'm not sure if you need to take that into consideration with this build
as well but thought I'd pass it along.
Clay

I have found another oddity with the build, the newly added requirement
for perl-Mail-SPF is now conflicting with a python-pyspf package that is
being used by pypolicyd-spf from http://www.openspf.org/Software for our
frontline SPF checking.
---
file /usr/bin/spfquery from install of
perl-Mail-SPF-2.006-1.el5.rf.noarch conflicts with file from package
python-pyspf-2.0.4-2.el5.noarch
---
do_not_use_mail_spf 1
This allows it to fallback to the Mail::SPF::Query rather than Mail::SPF
for the lookups. Which we have installed.
It was also my uderstanding that the SPF plugin in SpamAssassin would
use any exisitng SPF headers which were already present to help prevent
additonal DNS queries, which the openspf software should be creating for us.
I wanted to again pose the question regarding the requirement of the
package as I am unable to install at the present time because of the
conflict. Is this requirement for Mail::SPF really needed to be included
at this time? I am no means authority on this just providing feedback
with our current implementation.

Apologies for replying to my own message so quickly, but I am posing a
simialr question to the SpamAssassin users mailing list for more
clarification on the package requirements regarding Mail::SPF.

Clayton Keller

2010-03-25 20:51:20 UTC

Clayton,
Thanks for the report! This is a known issue; the fix is already in
place, and you should see a spamassassin-3.3.1-2 package in the repo
that fixes the problem no later than tomorrow.
-steve

Steve,
Thank you for the info.
I had one other thought. I believe amavisd-new 2.6.2 or later is now a
requirement for SpamAssassin 3.3.x.
Taken from the SpamAssassin release announcement
...
- versions of amavisd-new between 2.5.2 and 2.6.1 (inclusive) are
incompatible with SpamAssassin 3.3; please upgrade amavisd to 2.6.2 or
later, or apply a workaround
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6257
...
I'm not sure if you need to take that into consideration with this build
as well but thought I'd pass it along.
Clay

Clayton Keller

2010-03-25 20:51:20 UTC

Clayton,
Thanks for the report! This is a known issue; the fix is already in
place, and you should see a spamassassin-3.3.1-2 package in the repo
that fixes the problem no later than tomorrow.
-steve

Steve,
Thank you for the info.
I had one other thought. I believe amavisd-new 2.6.2 or later is now a
requirement for SpamAssassin 3.3.x.
Taken from the SpamAssassin release announcement
...
- versions of amavisd-new between 2.5.2 and 2.6.1 (inclusive) are
incompatible with SpamAssassin 3.3; please upgrade amavisd to 2.6.2 or
later, or apply a workaround
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6257
...
I'm not sure if you need to take that into consideration with this build
as well but thought I'd pass it along.
Clay

Clayton Keller

2010-03-25 20:51:20 UTC

Clayton,
Thanks for the report! This is a known issue; the fix is already in
place, and you should see a spamassassin-3.3.1-2 package in the repo
that fixes the problem no later than tomorrow.
-steve

Steve,
Thank you for the info.
I had one other thought. I believe amavisd-new 2.6.2 or later is now a
requirement for SpamAssassin 3.3.x.
Taken from the SpamAssassin release announcement
...
- versions of amavisd-new between 2.5.2 and 2.6.1 (inclusive) are
incompatible with SpamAssassin 3.3; please upgrade amavisd to 2.6.2 or
later, or apply a workaround
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6257
...
I'm not sure if you need to take that into consideration with this build
as well but thought I'd pass it along.
Clay

Clayton Keller

2010-03-25 20:51:20 UTC

Clayton,
Thanks for the report! This is a known issue; the fix is already in
place, and you should see a spamassassin-3.3.1-2 package in the repo
that fixes the problem no later than tomorrow.
-steve

Steve,
Thank you for the info.
I had one other thought. I believe amavisd-new 2.6.2 or later is now a
requirement for SpamAssassin 3.3.x.
Taken from the SpamAssassin release announcement
...
- versions of amavisd-new between 2.5.2 and 2.6.1 (inclusive) are
incompatible with SpamAssassin 3.3; please upgrade amavisd to 2.6.2 or
later, or apply a workaround
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6257
...
I'm not sure if you need to take that into consideration with this build
as well but thought I'd pass it along.
Clay

Clayton Keller

2010-03-22 16:20:12 UTC

Post by Clayton Keller
spamassassin-3.3.1-1.el5.rf.i386 from rpmforge has depsolving problems
--> Missing Dependency: perl(Razor2)>= 2.61 is needed by package spamassassin-3.3.1-1.el5.rf.i386 (rpmforge)
Error: Missing Dependency: perl(Razor2)>= 2.61 is needed by package spamassassin-3.3.1-1.el5.rf.i386 (rpmforge)

Clayton,
Thanks for the report! This is a known issue; the fix is already in place, and you should see a spamassassin-3.3.1-2 package in the repo that fixes the problem no later than tomorrow.
-steve

Clayton Keller

2010-03-22 16:20:12 UTC

Post by Clayton Keller
spamassassin-3.3.1-1.el5.rf.i386 from rpmforge has depsolving problems
--> Missing Dependency: perl(Razor2)>= 2.61 is needed by package spamassassin-3.3.1-1.el5.rf.i386 (rpmforge)
Error: Missing Dependency: perl(Razor2)>= 2.61 is needed by package spamassassin-3.3.1-1.el5.rf.i386 (rpmforge)

Clayton,
Thanks for the report! This is a known issue; the fix is already in place, and you should see a spamassassin-3.3.1-2 package in the repo that fixes the problem no later than tomorrow.
-steve

Clayton Keller

2010-03-22 16:20:12 UTC

Post by Clayton Keller
spamassassin-3.3.1-1.el5.rf.i386 from rpmforge has depsolving problems
--> Missing Dependency: perl(Razor2)>= 2.61 is needed by package spamassassin-3.3.1-1.el5.rf.i386 (rpmforge)
Error: Missing Dependency: perl(Razor2)>= 2.61 is needed by package spamassassin-3.3.1-1.el5.rf.i386 (rpmforge)

Clayton,
Thanks for the report! This is a known issue; the fix is already in place, and you should see a spamassassin-3.3.1-2 package in the repo that fixes the problem no later than tomorrow.
-steve

Clayton Keller

2010-03-22 16:20:12 UTC

Post by Clayton Keller
spamassassin-3.3.1-1.el5.rf.i386 from rpmforge has depsolving problems
--> Missing Dependency: perl(Razor2)>= 2.61 is needed by package spamassassin-3.3.1-1.el5.rf.i386 (rpmforge)
Error: Missing Dependency: perl(Razor2)>= 2.61 is needed by package spamassassin-3.3.1-1.el5.rf.i386 (rpmforge)

Clayton,
Thanks for the report! This is a known issue; the fix is already in place, and you should see a spamassassin-3.3.1-2 package in the repo that fixes the problem no later than tomorrow.
-steve

Clayton Keller

2010-03-22 15:26:20 UTC

Steve Huff

2010-03-22 15:29:27 UTC

Clayton Keller

2010-03-22 15:26:20 UTC

Steve Huff

2010-03-22 15:29:27 UTC

Clayton Keller

2010-03-22 15:26:20 UTC

Steve Huff

2010-03-22 15:29:27 UTC

Clayton Keller

2010-03-22 15:26:20 UTC

Steve Huff

2010-03-22 15:29:27 UTC