Hi,
Running CentOS5 with SpamAssassin v3.3.1-2.el5 installed via yum
I remember getting this error a while ago, and it was fixed, but now it's happening again:
Subroutine Net::DNS::Resolver::Base::AF_INET6 redefined at /usr/lib/perl5/5.8.8/Exporter.pm line 65. at /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/Net/DNS/Resolver/Base.pm line 65
The results I get from Google regarding this are all circa 2008. The only hints I can find seem to suggest to remove perl-IO-Socket-INET6, but trying to do so using yum (I don't want to start using another method of package management) tells me that spamassassin is a dependency and will also be removed - obviously undesirable.
Perl is up to date on the machinge. Am I the only one seeing this? What can I do to fix it?
From: email builder emailbuilder88@yahoo.com
The only hints I can find seem to suggest to remove perl-IO-Socket-INET6, but trying to do so using yum (I don't want to start using another method of package management) tells me that spamassassin is a dependency and will also be removed - obviously undesirable.
If you really want to remove it, use rpm instead. rpm -e --nodeps perl-IO-Socket-INET6 But it will annoy you at every update...
On my Zimbra server (CentOS 5.7), sa works fine. I have spamassassin-3.3.1-2.el5 and perl-IO-Socket-INET6-2.51-2.fc6 installed.
Did you disable IPV6?
JD
John, THANK YOU very much for responding --
The only hints I can find seem to suggest to remove perl-IO-Socket-INET6, but trying to do so using yum (I don't want to start using another method of package management) tells me that spamassassin is a dependency and will also be removed - obviously undesirable.
If you really want to remove it, use rpm instead. rpm -e --nodeps perl-IO-Socket-INET6 But it will annoy you at every update...
That was my fear... I'm wondering why this crept up again, since all my packages are completely up to date according to yum.
On my Zimbra server (CentOS 5.7), sa works fine. I have spamassassin-3.3.1-2.el5 and perl-IO-Socket-INET6-2.51-2.fc6 installed.
Same here. Are you running sa-update? SpamAssassin works fine for me, but sa-update is giving this error every time it runs.
Did you disable IPV6?
No - can you explain what you are implying?
On my Zimbra server (CentOS 5.7), sa works fine.
I have spamassassin-3.3.1-2.el5 and perl-IO-Socket-INET6-2.51-2.fc6 installed.
Same here. Are you running sa-update? SpamAssassin works fine for me, but sa-update is giving this error every time it runs.
Yes, it seems to run fine: Updating (Sun Jan 1 00:00:01 CET 2012)... Update available for channel updates.spamassassin.org Update was available, and was downloaded and installed successfully ...
Did you disable IPV6?
No - can you explain what you are implying?
Hum... not sure anymore why I asked... ^_^ Nevermind.
Did you install any perl libs out of rpm/yum...? BTW, 64bits here...
JD
On my Zimbra server (CentOS 5.7), sa works fine.
I have spamassassin-3.3.1-2.el5 and perl-IO-Socket-INET6-2.51-2.fc6 installed.
Same here. Are you running sa-update? SpamAssassin works fine for me, but sa-update is giving this error every time it runs.
Yes, it seems to run fine: Updating (Sun Jan 1 00:00:01 CET 2012)... Update available for channel updates.spamassassin.org Update was available, and was downloaded and installed successfully
Weird then. Wondering why I'm getting this problem.
Name : spamassassin Arch : i386 Version : 3.3.1 Release : 2.el5 Size : 3.1 M Repo : installed
Name : perl-IO-Socket-INET6 Arch : noarch Version : 2.51 Release : 2.fc6 Size : 22 k Repo : installed
Did you disable IPV6?
No - can you explain what you are implying?
Hum... not sure anymore why I asked... ^_^ Nevermind.
Did you install any perl libs out of rpm/yum...? BTW, 64bits here...
32 for me.
Thanks for your help...
On 01/04/2012 01:33 AM, email builder wrote:
John, THANK YOU very much for responding --
The only hints I can find seem to suggest to remove perl-IO-Socket-INET6, but trying to do so using yum (I don't want to start using another method of package management) tells me that spamassassin is a dependency and will also be removed - obviously undesirable.
If you really want to remove it, use rpm instead. rpm -e --nodeps perl-IO-Socket-INET6 But it will annoy you at every update...
That was my fear... I'm wondering why this crept up again, since all my packages are completely up to date according to yum.
yum only does what we tell it to do.
It is possible that you have a package installed that is not from the CentOS repos, etc.
If people add external repositories, it is very easy to get conflicts.
The only hints I can find seem to suggest to remove
perl-IO-Socket-INET6, but trying to do so using yum (I don't want to start using another method of package management) tells me that spamassassin is a dependency and will also be removed - obviously undesirable.
If you really want to remove it, use rpm instead. rpm -e --nodeps perl-IO-Socket-INET6 But it will annoy you at every update...
That was my fear... I'm wondering why this crept up again, since all my packages are completely up to date according to yum.
yum only does what we tell it to do.
I told it to update all my packages. :-)
It is possible that you have a package installed that is not from the CentOS repos, etc.
If people add external repositories, it is very easy to get conflicts.
I do have rpmforge as a repo in order to get a thing or two that CentOS does not offer. How can I diagnose if this is the problem? Here's a list of perl packages according to rpm -qa ---- are the ".rf" ones from rpmforge? I think most of those are requirements for the amavisd-new package.
perl-Net-DNS-0.63-1.el5.rf perl-URI-1.35-3 perl-libwww-perl-5.805-1.1.1 perl-Package-Constants-0.02-1.el5.rf perl-Pod-Escapes-1.04-1.2.el5.rf perl-Crypt-OpenSSL-RSA-0.26-1.el5.rf perl-NetAddr-IP-4.044-1.el5.rf perl-Socket6-0.19-3.fc6 perl-5.8.8-32.el5_7.6 perl-String-CRC32-1.4-2.fc6 perl-Digest-SHA1-2.11-1.2.1 perl-Digest-HMAC-1.01-15 perl-HTML-Tagset-3.20-1.el5.rf perl-IO-Socket-SSL-1.17-1.el5.rf perl-Compress-Zlib-1.42-1.fc6 perl-TimeDate-1.16-5.el5 perl-Convert-BinHex-1.119-2.2.el5.rf perl-Convert-TNEF-0.17-3.2.el5.rf perl-Mail-SPF-2.006-1.el5.rf perl-DBI-1.52-2.el5 perl-Digest-SHA-5.50-1.el5.rf perl-Crypt-OpenSSL-Random-0.04-1.el5.rf perl-Pod-Simple-3.16-1.el5.rf perl-Git-1.7.6.4-1.el5.rf perl-Unix-Syslog-1.1-1.el5.rf perl-Archive-Tar-1.39.1-1.el5_5.2 perl-Error-0.17016-1.el5.rf perl-Email-Date-Format-1.002-1.el5.rf perl-Mail-DKIM-0.39-1.el5.rf perl-Net-SSLeay-1.30-4.fc6 perl-IO-Zlib-1.09-1.el5.rf perl-HTML-Parser-3.59-1.el5.rf perl-IO-stringy-2.110-1.2.el5.rf perl-Archive-Zip-1.26-1.el5.rf perl-MIME-tools-5.420-2.el5.rf perl-Razor-Agent-2.84-1.el5.rf perl-DBD-MySQL-3.0007-2.el5 perl-BerkeleyDB-0.43-1.el5.rf perl-Convert-UUlib-1.34-1.el5.rf perl-Net-Server-0.99-1.el5.rf perl-Test-Pod-1.45-1.el5.rf perl-MIME-Lite-3.027-1.el5.rf perl-MailTools-2.08-1.el5.rf perl-version-0.91-1.el5.rf perl-IO-Socket-INET6-2.51-2.fc6
On 01/04/2012 10:29 PM, email builder wrote:
The only hints I can find seem to suggest to remove
perl-IO-Socket-INET6, but trying to do so using yum (I don't want to start using another method of package management) tells me that spamassassin is a dependency and will also be removed - obviously undesirable.
If you really want to remove it, use rpm instead. rpm -e --nodeps perl-IO-Socket-INET6 But it will annoy you at every update...
That was my fear... I'm wondering why this crept up again, since all my packages are completely up to date according to yum.
yum only does what we tell it to do.
I told it to update all my packages. :-)
It is possible that you have a package installed that is not from the CentOS repos, etc.
If people add external repositories, it is very easy to get conflicts.
I do have rpmforge as a repo in order to get a thing or two that CentOS does not offer. How can I diagnose if this is the problem? Here's a list of perl packages according to rpm -qa ---- are the ".rf" ones from rpmforge? I think most of those are requirements for the amavisd-new package.
.rf? is from RepoForge (ex-RPMForge).
You might need to use priorities and set RepoForge lower then SA repo. maybe you will need to downgrade few packages.
There is "Perl package problems" thread on this list from ~20 days ago. Read it for more info.
The only hints I can find seem to suggest to remove
perl-IO-Socket-INET6, but trying to do so using yum (I
don't
want to start using another method of package
management)
tells me that spamassassin is a dependency and will also
be
removed - obviously undesirable.
If you really want to remove it, use rpm instead. rpm -e --nodeps perl-IO-Socket-INET6 But it will annoy you at every update...
That was my fear... I'm wondering why this crept up again, since all my packages are completely up to date according to yum.
yum only does what we tell it to do.
I told it to update all my packages. :-)
It is possible that you have a package installed that is not from the CentOS repos, etc.
If people add external repositories, it is very easy to get conflicts.
I do have rpmforge as a repo in order to get a thing or two that CentOS does not offer. How can I diagnose if this is the problem? Here's a list of perl packages according to rpm -qa ---- are the
".rf"
ones from rpmforge? I think most of those are requirements for the amavisd-new package.
.rf? is from RepoForge (ex-RPMForge).
You might need to use priorities and set RepoForge lower then SA repo. maybe you will need to downgrade few packages.
Hmm, OK, prioritze CentOS repo over RepoForge then will yum update figure out the rest? I don't see any priority settings in my yum conf files... I'll have to read up on that.
Interestingly, I get this:
rpm -q --whatrequires perl-IO-Socket-INET6 no package requires perl-IO-Socket-INET6
However,
yum remove perl-IO-Socket-INET6
Loaded plugins: fastestmirror Setting up Remove Process Resolving Dependencies --> Running transaction check ---> Package perl-IO-Socket-INET6.noarch 0:2.51-2.fc6 set to be erased --> Processing Dependency: perl(IO::Socket::INET6) for package: spamassassin --> Running transaction check ---> Package spamassassin.i386 0:3.3.1-2.el5 set to be erased --> Processing Dependency: perl(Mail::SpamAssassin) for package: amavisd-new --> Running transaction check ---> Package amavisd-new.i386 0:2.6.6-1.el5.rf set to be erased --> Finished Dependency Resolution
Dependencies Resolved
============================================================================================== Package Arch Version Repository Size ============================================================================================== Removing: perl-IO-Socket-INET6 noarch 2.51-2.fc6 installed 22 k Removing for dependencies: amavisd-new i386 2.6.6-1.el5.rf installed 2.7 M spamassassin i386 3.3.1-2.el5 installed 3.1 M
Transaction Summary ============================================================================================== Remove 3 Package(s) Reinstall 0 Package(s) Downgrade 0 Package(s)
Is this ok [y/N]: n Exiting on user Command
There is "Perl package problems" thread on this list from ~20 days ago. Read it for more info.
OK I'll go try to find it
From: email builder emailbuilder88@yahoo.com
Hmm, OK, prioritze CentOS repo over RepoForge then will yum update figure out the rest? I don't see any priority settings in my yum conf files...
# yum list | grep priorities yum-priorities.noarch 1.1.16-16.el5.centos installed
# cat /etc/yum/pluginconf.d/priorities.conf [main] enabled = 1 check_obsoletes=1
Then add "priority=n" to the repos sections. n=1 for CentOS n=2 for repo 2 etc...
Interestingly, I get this: rpm -q --whatrequires perl-IO-Socket-INET6 no package requires perl-IO-Socket-INET6
# rpm -q --provides perl-IO-Socket-INET6 perl(IO::Socket::INET6) = 2.51 perl-IO-Socket-INET6 = 2.51-2.fc6
# rpm -q --whatrequires "perl(IO::Socket::INET6)" spamassassin-3.3.1-2.el5
JD
Hmm, OK, prioritze CentOS repo over RepoForge then will yum update
figure out the rest? I don't see any priority settings in my yum conf files...
# yum list | grep priorities yum-priorities.noarch 1.1.16-16.el5.centos installed
# cat /etc/yum/pluginconf.d/priorities.conf [main] enabled = 1 check_obsoletes=1
Then add "priority=n" to the repos sections. n=1 for CentOS n=2 for repo 2 etc...
Ah, it's a separate package. OK thanks for the info!
But before I try that, I'm wondering, shouldn't it be easy from the error message to simply understand what package is creating the problem?
It turns out it's not sa-update specifically doing this, but the restart of spamassassin itself:
/etc/init.d/spamassassin condrestart
Stopping spamd: [ OK ] Starting spamd: Subroutine Net::DNS::Resolver::Base::AF_INET6 redefined at /usr/lib/perl5/5.8.8/Exporter.pm line 65. at /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/Net/DNS/Resolver/Base.pm line 66 [ OK ]
I've ensured that my spamassassin, perl-Net-DNS and per-IO-Socket-INET6 packages are all from the CentOS repo, so is it just a crap shoot to find what is causing this? I'd expect the error message to be more helpful than that...
Recap on my versions:
perl-IO-Socket-INET6-2.51-2.fc6 perl-Net-DNS-0.59-3.el5 spamassassin-3.3.1-2.el5
Hmm, OK, prioritze CentOS repo over RepoForge then will yum update
figure out the rest? I don't see any priority settings in my yum
conf
files...
# yum list | grep priorities yum-priorities.noarch 1.1.16-16.el5.centos
installed
# cat /etc/yum/pluginconf.d/priorities.conf [main] enabled = 1 check_obsoletes=1
Then add "priority=n" to the repos sections. n=1 for CentOS n=2 for repo 2 etc...
Ah, it's a separate package. OK thanks for the info!
But before I try that, I'm wondering, shouldn't it be easy from the error message to simply understand what package is creating the problem?
It turns out it's not sa-update specifically doing this, but the restart of spamassassin itself:
/etc/init.d/spamassassin condrestart
Stopping spamd: [ OK ] Starting spamd: Subroutine Net::DNS::Resolver::Base::AF_INET6 redefined at /usr/lib/perl5/5.8.8/Exporter.pm line 65. at /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/Net/DNS/Resolver/Base.pm line 66 [ OK ]
I've ensured that my spamassassin, perl-Net-DNS and per-IO-Socket-INET6 packages are all from the CentOS repo, so is it just a crap shoot to find what is causing this? I'd expect the error message to be more helpful than that...
Recap on my versions:
perl-IO-Socket-INET6-2.51-2.fc6 perl-Net-DNS-0.59-3.el5 spamassassin-3.3.1-2.el5
In fact, it was suggested on the spamassassin list that version 0.59-3.el5 is vastly out of date and known to be buggy and, contrary to the suggestion here of ensuring I prioritize CentOS repos, I would be better served to get the newer version of per-Net-DNS from the RepoForge (extras) repository.
Other thoughts (on this or my main question in my last email above) would be greatly appreciated.
On 01/05/2012 10:17 PM, email builder wrote:
Hmm, OK, prioritze CentOS repo over RepoForge then will yum update figure out the rest? I don't see any priority settings in my yum
conf
files...
# yum list | grep priorities yum-priorities.noarch 1.1.16-16.el5.centos
installed
# cat /etc/yum/pluginconf.d/priorities.conf [main] enabled = 1 check_obsoletes=1
Then add "priority=n" to the repos sections. n=1 for CentOS n=2 for repo 2 etc...
Ah, it's a separate package. OK thanks for the info!
But before I try that, I'm wondering, shouldn't it be easy from the error message to simply understand what package is creating the problem?
It turns out it's not sa-update specifically doing this, but the restart of spamassassin itself:
/etc/init.d/spamassassin condrestart
Stopping spamd: [ OK ] Starting spamd: Subroutine Net::DNS::Resolver::Base::AF_INET6 redefined at /usr/lib/perl5/5.8.8/Exporter.pm line 65. at /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/Net/DNS/Resolver/Base.pm line 66 [ OK ]
I've ensured that my spamassassin, perl-Net-DNS and per-IO-Socket-INET6 packages are all from the CentOS repo, so is it just a crap shoot to find what is causing this? I'd expect the error message to be more helpful than that...
Recap on my versions:
perl-IO-Socket-INET6-2.51-2.fc6 perl-Net-DNS-0.59-3.el5 spamassassin-3.3.1-2.el5
In fact, it was suggested on the spamassassin list that version 0.59-3.el5 is vastly out of date and known to be buggy and, contrary to the suggestion here of ensuring I prioritize CentOS repos, I would be better served to get the newer version of per-Net-DNS from the RepoForge (extras) repository.
Other thoughts (on this or my main question in my last email above) would be greatly appreciated.
RHEL (and therefore CentOS) is designed to work with items that it uses as dependencies.
You should not upgrade any packages in the distribution unless you have verified that all the dependencies that are needed by other items that are in the distribution can use the newer things you want to bring in.
For example, I rebuilt and used a newer version of both samba and ldap on centos-4 (the version that was included in centos-5) when I wanted to upgrade all my domain controllers from CentOS-4 to CentOS-5. But when I did that, I had to verify that I either also rebuilt any items that use samba and ldap to use the new libraries.
If you know what you are doing and understand how to validate the dependency trees, check for repo closure, etc ... then upgrading items to newer versions is fine. If you do not know how to do that, then you end up with a hot pile of mess and eventually an unusable system.
Also remember that upstream does backporting to keep API/ABI compatibility:
https://access.redhat.com/security/updates/backporting/
I don't know what is causing your specific issue ... whether you are getting something newer in sa-update than is designed to work with CentOS (sa-update bypasses the normal rpm type updates and does updates from elsewhere). It should only update rules, so maybe some of the new rules require a new version of perl-Net-DNS. If that is the case, then a Red Hat bugzilla entry needs to be made.
If it will not work with the CentOS version of perl-Net-DNS and if it works with the rfx version, then obviously you would run that. If that is the case, we need to get the rhel one upgraded.
On 01/06/2012 09:36 AM, Johnny Hughes wrote:
On 01/05/2012 10:17 PM, email builder wrote:
Hmm, OK, prioritze CentOS repo over RepoForge then will yum update figure out the rest? I don't see any priority settings in my yum
conf
files...
# yum list | grep priorities yum-priorities.noarch 1.1.16-16.el5.centos
installed
# cat /etc/yum/pluginconf.d/priorities.conf [main] enabled = 1 check_obsoletes=1
Then add "priority=n" to the repos sections. n=1 for CentOS n=2 for repo 2 etc...
Ah, it's a separate package. OK thanks for the info!
But before I try that, I'm wondering, shouldn't it be easy from the error message to simply understand what package is creating the problem?
It turns out it's not sa-update specifically doing this, but the restart of spamassassin itself:
/etc/init.d/spamassassin condrestart
Stopping spamd: [ OK ] Starting spamd: Subroutine Net::DNS::Resolver::Base::AF_INET6 redefined at /usr/lib/perl5/5.8.8/Exporter.pm line 65. at /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/Net/DNS/Resolver/Base.pm line 66 [ OK ]
I've ensured that my spamassassin, perl-Net-DNS and per-IO-Socket-INET6 packages are all from the CentOS repo, so is it just a crap shoot to find what is causing this? I'd expect the error message to be more helpful than that...
Recap on my versions:
perl-IO-Socket-INET6-2.51-2.fc6 perl-Net-DNS-0.59-3.el5 spamassassin-3.3.1-2.el5
In fact, it was suggested on the spamassassin list that version 0.59-3.el5 is vastly out of date and known to be buggy and, contrary to the suggestion here of ensuring I prioritize CentOS repos, I would be better served to get the newer version of per-Net-DNS from the RepoForge (extras) repository.
Other thoughts (on this or my main question in my last email above) would be greatly appreciated.
RHEL (and therefore CentOS) is designed to work with items that it uses as dependencies.
You should not upgrade any packages in the distribution unless you have verified that all the dependencies that are needed by other items that are in the distribution can use the newer things you want to bring in.
For example, I rebuilt and used a newer version of both samba and ldap on centos-4 (the version that was included in centos-5) when I wanted to upgrade all my domain controllers from CentOS-4 to CentOS-5. But when I did that, I had to verify that I either also rebuilt any items that use samba and ldap to use the new libraries.
If you know what you are doing and understand how to validate the dependency trees, check for repo closure, etc ... then upgrading items to newer versions is fine. If you do not know how to do that, then you end up with a hot pile of mess and eventually an unusable system.
Also remember that upstream does backporting to keep API/ABI compatibility:
https://access.redhat.com/security/updates/backporting/
I don't know what is causing your specific issue ... whether you are getting something newer in sa-update than is designed to work with CentOS (sa-update bypasses the normal rpm type updates and does updates from elsewhere). It should only update rules, so maybe some of the new rules require a new version of perl-Net-DNS. If that is the case, then a Red Hat bugzilla entry needs to be made.
If it will not work with the CentOS version of perl-Net-DNS and if it works with the rfx version, then obviously you would run that. If that is the case, we need to get the rhel one upgraded.
Doing a little more research ... I am using this version of amavisd-new from EPEL (you are using a newer version from repoforge) and I do not seem to have that issue (I am x86_64 and you appear to be i386):
http://download.fedora.redhat.com/pub/epel/5/x86_64/repoview/amavisd-new.htm...
But before I try that, I'm wondering, shouldn't it be easy
from the error message to simply understand what package is creating the problem?
It turns out it's not sa-update specifically doing this, but the restart of spamassassin itself:
/etc/init.d/spamassassin condrestart
Stopping spamd: [ OK ] Starting spamd: Subroutine Net::DNS::Resolver::Base::AF_INET6 redefined
at
/usr/lib/perl5/5.8.8/Exporter.pm line 65. at
/usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/Net/DNS/Resolver/Base.pm
line 66 [ OK ]
I've ensured that my spamassassin, perl-Net-DNS and per-IO-Socket-INET6 packages are all from the CentOS repo, so is it just a crap shoot to find what is causing this? I'd expect the error message to be more helpful than that...
Recap on my versions:
perl-IO-Socket-INET6-2.51-2.fc6 perl-Net-DNS-0.59-3.el5 spamassassin-3.3.1-2.el5
In fact, it was suggested on the spamassassin list that version 0.59-3.el5 is vastly out of date and known to be buggy and, contrary to the suggestion here of ensuring I prioritize CentOS repos, I would be better served to get the newer version of per-Net-DNS from the RepoForge (extras) repository.
Other thoughts (on this or my main question in my last email above) would be greatly appreciated.
RHEL (and therefore CentOS) is designed to work with items that it uses as dependencies.
<snip>
If you know what you are doing and understand how to validate the dependency trees, check for repo closure, etc ... then upgrading items to newer versions is fine. If you do not know how to do that, then you end up with a hot pile of mess and eventually an unusable system.
I understand, and I agree. My strongest desire is to stay away from all this manual manipulation. But (see above) I *AM* using the newest spamassassin and per-Net-DNS (where the error is happening?) packages from the CentOS repo, so why in the world are they not working together?? That's the kicker. What else can I do if CentOS provides buggy packages?
I don't know what is causing your specific issue ... whether you are getting something newer in sa-update than is designed to work with CentOS (sa-update bypasses the normal rpm type updates and does updates from elsewhere). It should only update rules, so maybe some of the new rules require a new version of perl-Net-DNS. If that is the case, then a Red Hat bugzilla entry needs to be made.
See above - it's the spamassassin restart that causes the error, in the end, nothing really to do with sa-update.
If it will not work with the CentOS version of perl-Net-DNS and if it works with the rfx version, then obviously you would run that. If that is the case, we need to get the rhel one upgraded.
So maybe I *do* need to open a bug report? Where do I do that?
Le 06/01/2012 21:06, email builder wrote :
I don't know what is causing your specific issue ... whether you are getting something newer in sa-update than is designed to work with CentOS (sa-update bypasses the normal rpm type updates and does updates from elsewhere). It should only update rules, so maybe some of the new rules require a new version of perl-Net-DNS. If that is the case, then a Red Hat bugzilla entry needs to be made.
See above - it's the spamassassin restart that causes the error, in the end, nothing really to do with sa-update.
If it will not work with the CentOS version of perl-Net-DNS and if it works with the rfx version, then obviously you would run that. If that is the case, we need to get the rhel one upgraded.
So maybe I *do* need to open a bug report? Where do I do that?
can you try to disable ipv6, then reboot and see if you still get the error message?
I don't know what is causing your specific issue ... whether you
are getting something newer in sa-update than is designed to work with CentOS (sa-update bypasses the normal rpm type updates and does updates from elsewhere). It should only update rules, so maybe some of the new rules require a new version of perl-Net-DNS. If that is the case, then a Red Hat bugzilla entry needs to be made.
See above - it's the spamassassin restart that causes the error, in the end, nothing really to do with sa-update.
If it will not work with the CentOS version of perl-Net-DNS and if it works with the rfx version, then obviously you would run that. If that is the case, we need to get the rhel one upgraded.
So maybe I *do* need to open a bug report? Where do I do that?
can you try to disable ipv6, then reboot and see if you still get the error message?
Sorry, it's a production machine, I'd rather not do that. I can make small changes but a reboot-- Beside, if this is the set of packages CentOS gives me when I install something like spamassassin, it seems like they should work no matter what. But don't get me wrong, I really appreciate your suggestion.
On 01/07/2012 12:50 PM, email builder wrote:
I don't know what is causing your specific issue ... whether you are getting something newer in sa-update than is designed to work with CentOS (sa-update bypasses the normal rpm type updates and does updates from elsewhere). It should only update rules, so maybe some of the new rules require a new version of perl-Net-DNS. If that is the case, then a Red Hat bugzilla entry needs to be made.
See above - it's the spamassassin restart that causes the error, in the end, nothing really to do with sa-update.
If it will not work with the CentOS version of perl-Net-DNS and if it works with the rfx version, then obviously you would run that. If that is the case, we need to get the rhel one upgraded.
So maybe I *do* need to open a bug report? Where do I do that?
can you try to disable ipv6, then reboot and see if you still get the error message?
Sorry, it's a production machine, I'd rather not do that. I can make small changes but a reboot-- Beside, if this is the set of packages CentOS gives me when I install something like spamassassin, it seems like they should work no matter what. But don't get me wrong, I really appreciate your suggestion.
It is not the CentOS packages causing your issues. I told you already that I have spamassassin running with these packages with no problems: ================================================== [root@localhost ~]# rpm -qa | grep -i perl | sort mod_perl-2.0.4-6.el5.x86_64 perl-5.8.8-32.el5_7.6.x86_64 perl-Archive-Tar-1.39.1-1.el5_5.2.noarch perl-Archive-Zip-1.16-1.2.1.noarch perl-Authen-SASL-2.10-1.el5.1.noarch perl-BerkeleyDB-0.32-1.el5.x86_64 perl-BSD-Resource-1.28-1.fc6.1.x86_64 perl-Class-Singleton-1.4-1.el5.centos.noarch perl-Compress-Zlib-1.42-1.fc6.x86_64 perl-Convert-ASN1-0.20-1.1.noarch perl-Convert-BinHex-1.119-5.el5.noarch perl-Convert-TNEF-0.17-7.el5.noarch perl-Convert-UUlib-1.4-1.el5.x86_64 perl-DateTime-0.42-1.el5.centos.x86_64 perl-DateTime-Format-Mail-0.3001-1.el5.centos.noarch perl-DateTime-Format-W3CDTF-0.04-1.el5.centos.noarch perl-DateTime-Locale-0.35-1.el5.centos.noarch perl-DateTime-TimeZone-0.6904-1.el5.centos.noarch perl-DBD-MySQL-3.0007-2.el5.x86_64 perl-DBD-SQLite-1.14-3.el5.x86_64 perl-DBI-1.52-2.el5.x86_64 perl-Digest-HMAC-1.01-15.noarch perl-Digest-SHA1-2.11-1.2.1.x86_64 perl-File-RsyncP-0.68-1.el5.centos.x86_64 perl-GSSAPI-0.24-2.el5.x86_64 perl-HTML-Parser-3.55-1.fc6.x86_64 perl-HTML-Tagset-3.10-2.1.1.noarch perl-IO-Multiplex-1.08-5.el5.noarch perl-IO-Socket-INET6-2.51-2.fc6.noarch perl-IO-Socket-SSL-1.01-1.fc6.noarch perl-IO-stringy-2.110-5.el5.noarch perl-IO-Zlib-1.04-4.2.1.noarch perl-LDAP-0.33-3.fc6.noarch perl-libwww-perl-5.805-1.1.1.noarch perl-Mail-SPF-Query-1.999.1-3.el5.noarch perl-MailTools-1.77-1.el5.centos.noarch perl-MIME-tools-5.420-3.el5.noarch perl-NetAddr-IP-4.027-5.el5_6.x86_64 perl-Net-CIDR-Lite-0.20-2.1.el5.noarch perl-Net-DNS-0.59-3.el5.x86_64 perl-Net-IP-1.25-2.fc6.noarch perl-Net-Server-0.96-2.el5.noarch perl-Net-SSLeay-1.30-4.fc6.x86_64 perl-Params-Validate-0.89-1.el5.centos.x86_64 perl-Razor-Agent-2.85-1.el5.x86_64 perl-Socket6-0.19-3.fc6.x86_64 perl-TimeDate-1.16-5.el5.noarch perl-Time-modules-2003.1126-1.el5.centos.noarch perl-Unix-Syslog-0.100-9.el5.1.x86_64 perl-URI-1.35-3.noarch perl-XML-NamespaceSupport-1.09-1.2.1.noarch perl-XML-Parser-2.34-6.1.2.2.1.x86_64 perl-XML-RSS-1.32-1.el5.centos.noarch perl-XML-SAX-0.14-11.noarch perl-XML-Simple-2.14-4.fc6.noarch ==================================================
The issue you are having, based on the error that you posted, is that something else is already providing the subroutine "Net::DNS::Resolver::Base::AF_INET6" when it is trying to be loaded by perl module provided by CentOS (perl-Net-DNS-0.59-3.el5.i386). What we do not know is what ELSE is providing that routine.
Since I have the same 3 RPMs installed that you are quoting as the potential issue, and since I am not having the dual subroutine issue, that implies that the "SOMETHING ELSE" providing the other "Net::DNS::Resolver::Base::AF_INET6" is not any of the packages that I have installed.
So, I would say that this issue must be caused by the intermixing of perl modules from other than CentOS repositories.
Can anyone reproduce this issue without .rf. or .rfx. perl modules installed?
So maybe I *do* need to open a bug report? Where do I do that?
can you try to disable ipv6, then reboot and see if you still get the error message?
Sorry, it's a production machine, I'd rather not do that. I can make small changes but a reboot-- Beside, if this is the set of packages CentOS gives me when I install something like spamassassin, it seems like they should work no matter what. But don't get me wrong, I really appreciate your suggestion.
It is not the CentOS packages causing your issues. I told you already that I have spamassassin running with these packages with no problems:
Although I have the 32-bit packages which could be slightly different, no?
That said, I would tend to think you're correct:
The issue you are having, based on the error that you posted, is that something else is already providing the subroutine "Net::DNS::Resolver::Base::AF_INET6" when it is trying to be loaded by perl module provided by CentOS (perl-Net-DNS-0.59-3.el5.i386). What we do not know is what ELSE is providing that routine.
It seems like it shouldn't be hard to grep for who the culprit is, but what do I know - doing this didn't turn up anything I could too easily decypher:
cd /usr/lib/perl5 grep -rin 'af_inet6' *
I only got 40 lines of output from that so I could post them if needed. Grepping exactly for "sub af_inet6" gives me only one result:
5.8.8/i386-linux-thread-multi/bits/socket.ph:66: eval 'sub AF_INET6 () { &PF_INET6;}' unless defined(&AF_INET6);
Are there modules that are placed somewhere other than /usr/lib/perl5 that could have the offending code? Or is this a fruitless way to track down the problem?
On 01/08/2012 08:40 PM, email builder wrote:
So maybe I *do* need to open a bug report? Where do I do that?
can you try to disable ipv6, then reboot and see if you still get the error message?
Sorry, it's a production machine, I'd rather not do that. I can make small changes but a reboot-- Beside, if this is the set of packages CentOS gives me when I install something like spamassassin, it seems like they should work no matter what. But don't get me wrong, I really appreciate your suggestion.
It is not the CentOS packages causing your issues. I told you already that I have spamassassin running with these packages with no problems:
Although I have the 32-bit packages which could be slightly different, no?
That said, I would tend to think you're correct:
The issue you are having, based on the error that you posted, is that something else is already providing the subroutine "Net::DNS::Resolver::Base::AF_INET6" when it is trying to be loaded by perl module provided by CentOS (perl-Net-DNS-0.59-3.el5.i386). What we do not know is what ELSE is providing that routine.
It seems like it shouldn't be hard to grep for who the culprit is, but what do I know - doing this didn't turn up anything I could too easily decypher:
cd /usr/lib/perl5 grep -rin 'af_inet6' *
I only got 40 lines of output from that so I could post them if needed. Grepping exactly for "sub af_inet6" gives me only one result:
5.8.8/i386-linux-thread-multi/bits/socket.ph:66: eval 'sub AF_INET6 () { &PF_INET6;}' unless defined(&AF_INET6);
Are there modules that are placed somewhere other than /usr/lib/perl5 that could have the offending code? Or is this a fruitless way to track down the problem?
perl-NetAddr-IP-4.044-1.el5.rf <=== I think that is the problem package
I don't know if that version is required by the repoforge packages ... but base contains perl-NetAddr-IP-4.027-5.el5_6
I would see if I could replace perl-NetAddr-IP-4.044-1.el5.rf from repoforge with perl-NetAddr-IP-4.027-5.el5_6 from base.
So maybe I *do* need to open a bug report? Where do I do
that?
can you try to disable ipv6, then reboot and see if you still get the error message?
Sorry, it's a production machine, I'd rather not do that. I can make small changes but a reboot-- Beside, if this is the set of packages CentOS gives me when I install something like spamassassin, it seems like they should work no matter what. But don't get me wrong, I really appreciate your suggestion.
It is not the CentOS packages causing your issues. I told you already that I have spamassassin running with these packages with no problems:
Although I have the 32-bit packages which could be slightly different, no?
That said, I would tend to think you're correct:
The issue you are having, based on the error that you posted, is that something else is already providing the subroutine "Net::DNS::Resolver::Base::AF_INET6" when it is trying to be loaded by perl module provided by CentOS (perl-Net-DNS-0.59-3.el5.i386). What we do not know is what ELSE is providing that routine.
It seems like it shouldn't be hard to grep for who the culprit is, but what do I know - doing this didn't turn up anything I could too easily decypher:
cd /usr/lib/perl5 grep -rin 'af_inet6' *
I only got 40 lines of output from that so I could post them if needed. Grepping exactly for "sub af_inet6" gives me only one result:
5.8.8/i386-linux-thread-multi/bits/socket.ph:66: eval 'sub AF_INET6 () { &PF_INET6;}' unless defined(&AF_INET6);
Are there modules that are placed somewhere other than /usr/lib/perl5 that could have the offending code? Or is this a fruitless way to track down the problem?
perl-NetAddr-IP-4.044-1.el5.rf <=== I think that is the problem package
I don't know if that version is required by the repoforge packages ... but base contains perl-NetAddr-IP-4.027-5.el5_6
I would see if I could replace perl-NetAddr-IP-4.044-1.el5.rf from repoforge with perl-NetAddr-IP-4.027-5.el5_6 from base.
rpm -e --nodeps perl-NetAddr-IP
vi /etc/yum.repos.d/rpmforge.repo -- change all enabled = 1 to enabled = 0 temporarily (seems like yum priorities is going to be a good idea) --
yum install perl-NetAddr-IP
/etc/init.d/spamassassin condrestart Stopping spamd: [ OK ] Starting spamd: [ OK ]
That did it. Thanks a lot to Nicolas for sharing and thanks very very much to Johnny for the patient help.
Is there somewhere at RepoForge I could notify them about this?
On 01/09/2012 09:56 PM, email builder wrote:
Is there somewhere at RepoForge I could notify them about this?
users mailing list: users@lists.repoforge.org http://lists.repoforge.org/mailman/listinfo/users
Is there somewhere at RepoForge I could notify them about this?
users mailing list: users@lists.repoforge.org http://lists.repoforge.org/mailman/listinfo/users
Thank you. I am reporting it now
\
Is there somewhere at RepoForge I could notify them about this?
users mailing list: users@lists.repoforge.org http://lists.repoforge.org/mailman/listinfo/users
Thank you. I am reporting it now _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos -----------------------------------------------
Thanks for your post.
I have three e-mail servers and the error is on all three.
[root@MailIn ~]# service spamassassin restart Stopping spamd: [ OK ] Starting spamd: Subroutine Net::DNS::Resolver::Base::AF_INET6 redefined at /usr/lib/perl5/5.8.8/Exporter.pm line 65. at /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/Net/DNS/Resolver/Base.pm line 66 [ OK ]
When you report the bug would you post the bug number so we could follow it.
Thanks,
Greg Ennis
Gregory P. Ennis wrote:
I have three e-mail servers and the error is on all three.
[root@MailIn ~]# service spamassassin restart Stopping spamd: [ OK ] Starting spamd: Subroutine Net::DNS::Resolver::Base::AF_INET6 redefined at /usr/lib/perl5/5.8.8/Exporter.pm line 65. at /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/Net/DNS/Resolver/Base.pm line 66 [ OK ]
When you report the bug would you post the bug number so we could follow it.
The problem was solved for the OP when he downgraded perl-NetAddr-IP to use the stock version from centos (perl-NetAddr-IP-4.027-5.el5_6) instead of the one from repoforge. Doesn't this solve it for you?
Gregory P. Ennis wrote:
I have three e-mail servers and the error is on all three.
[root@MailIn ~]# service spamassassin restart Stopping spamd: [ OK ] Starting spamd: Subroutine Net::DNS::Resolver::Base::AF_INET6 redefined at /usr/lib/perl5/5.8.8/Exporter.pm line 65. at /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/Net/DNS/Resolver/Base.pm line 66 [ OK ]
When you report the bug would you post the bug number so we could follow it.
The problem was solved for the OP when he downgraded perl-NetAddr-IP to use the stock version from centos (perl-NetAddr-IP-4.027-5.el5_6) instead of the one from repoforge. Doesn't this solve it for you? -----------------------------------------------------------------
Thanks!!!!!
I will not be able to change things for a couple of days, but sure appreciate the information. Looks like I will need to remove spamassassin and then re-install it.
Thanks again!!!!
Greg
I have three e-mail servers and the error is on all three.
[root@MailIn ~]# service spamassassin restart Stopping spamd: [ OK ] Starting spamd: Subroutine Net::DNS::Resolver::Base::AF_INET6 redefined at
/usr/lib/perl5/5.8.8/Exporter.pm line 65.
at
/usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/Net/DNS/Resolver/Base.pm line 66
[ OK ]
When you report the bug would you post the bug number so we could follow
it.
The problem was solved for the OP when he downgraded perl-NetAddr-IP to use the stock version from centos (perl-NetAddr-IP-4.027-5.el5_6) instead of the one from repoforge. Doesn't this solve it for you?
Thanks!!!!!
I will not be able to change things for a couple of days, but sure appreciate the information. Looks like I will need to remove spamassassin and then re-install it.
Why? Just remove that package and install the one from CentOS. Spamassassin doesn't need to be touched.
Dne 10.1.2012 4:02, email builder napsal(a):
Why? Just remove that package and install the one from CentOS. Spamassassin doesn't need to be touched.
Hello, Seems to me that you are still using the mix of repos. Packages from RF work fine.
root@specs2:1280:279:/$ rpm -q spamassassin perl-IO-Socket-INET6 perl-Net-DNS perl-NetAddr-IP| sort perl-IO-Socket-INET6-2.57-2.el5.rfx perl-NetAddr-IP-4.044-1.el5.rf perl-Net-DNS-0.66-1.el5.rfx spamassassin-3.3.2-2.el5.rfx
root@specs2:1279:278:/$ sa-update -D Jan 10 15:07:53.098 [32233] dbg: logger: adding facilities: all Jan 10 15:07:53.098 [32233] dbg: logger: logging level is DBG Jan 10 15:07:53.098 [32233] dbg: generic: SpamAssassin version 3.3.2 Jan 10 15:07:53.098 [32233] dbg: generic: Perl 5.008008, PREFIX=/usr, DEF_RULES_DIR=/usr/share/spamassassin, LOCAL_RULES_DIR=/etc/mail/spamassassin, LOCAL_STATE_DIR=/var/lib/spamassassin Jan 10 15:07:53.098 [32233] dbg: config: timing enabled Jan 10 15:07:53.099 [32233] dbg: config: score set 0 chosen. Jan 10 15:07:53.104 [32233] dbg: dns: is Net::DNS::Resolver available? yes Jan 10 15:07:53.104 [32233] dbg: dns: Net::DNS version: 0.66 Jan 10 15:07:53.104 [32233] dbg: generic: sa-update version svn917659 Jan 10 15:07:53.104 [32233] dbg: generic: using update directory: /var/lib/spamassassin/3.003002 Jan 10 15:07:53.231 [32233] dbg: diag: perl platform: 5.008008 linux Jan 10 15:07:53.231 [32233] dbg: diag: [...] module installed: Digest::SHA1, version 2.13 Jan 10 15:07:53.231 [32233] dbg: diag: [...] module installed: HTML::Parser, version 3.68 Jan 10 15:07:53.231 [32233] dbg: diag: [...] module installed: Net::DNS, version 0.66 Jan 10 15:07:53.231 [32233] dbg: diag: [...] module installed: NetAddr::IP, version 4.044 Jan 10 15:07:53.231 [32233] dbg: diag: [...] module installed: Time::HiRes, version 1.9717 Jan 10 15:07:53.231 [32233] dbg: diag: [...] module installed: Archive::Tar, version 1.56 Jan 10 15:07:53.231 [32233] dbg: diag: [...] module installed: IO::Zlib, version 1.10 Jan 10 15:07:53.231 [32233] dbg: diag: [...] module installed: Digest::SHA1, version 2.13 Jan 10 15:07:53.231 [32233] dbg: diag: [...] module installed: MIME::Base64, version 3.07 Jan 10 15:07:53.231 [32233] dbg: diag: [...] module installed: DB_File, version 1.814 Jan 10 15:07:53.231 [32233] dbg: diag: [...] module installed: Net::SMTP, version 2.29 Jan 10 15:07:53.231 [32233] dbg: diag: [...] module installed: Mail::SPF, version v2.006 Jan 10 15:07:53.231 [32233] dbg: diag: [...] module installed: IP::Country::Fast, version 604.001 Jan 10 15:07:53.231 [32233] dbg: diag: [...] module installed: Razor2::Client::Agent, version 2.84 Jan 10 15:07:53.231 [32233] dbg: diag: [...] module installed: Net::Ident, version 1.23 Jan 10 15:07:53.231 [32233] dbg: diag: [...] module installed: IO::Socket::INET6, version 2.57 Jan 10 15:07:53.231 [32233] dbg: diag: [...] module installed: IO::Socket::SSL, version 1.44 Jan 10 15:07:53.231 [32233] dbg: diag: [...] module installed: Compress::Zlib, version 2.037 Jan 10 15:07:53.232 [32233] dbg: diag: [...] module installed: Mail::DKIM, version 0.39 Jan 10 15:07:53.232 [32233] dbg: diag: [...] module installed: DBI, version 1.616 Jan 10 15:07:53.232 [32233] dbg: diag: [...] module installed: Getopt::Long, version 2.35 Jan 10 15:07:53.232 [32233] dbg: diag: [...] module installed: LWP::UserAgent, version 5.835 Jan 10 15:07:53.232 [32233] dbg: diag: [...] module installed: HTTP::Date, version 5.831 Jan 10 15:07:53.232 [32233] dbg: diag: [...] module installed: Encode::Detect, version 1.01 Jan 10 15:07:53.232 [32233] dbg: gpg: Searching for 'gpg' Jan 10 15:07:53.232 [32233] dbg: util: current PATH is: /usr/kerberos/sbin:/usr/kerberos/bin:/usr/lib64/ccache/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin Jan 10 15:07:53.233 [32233] dbg: util: executable for gpg was found at /usr/bin/gpg Jan 10 15:07:53.233 [32233] dbg: gpg: found /usr/bin/gpg Jan 10 15:07:53.233 [32233] dbg: gpg: release trusted key id list: 5E541DC959CB8BAC7C78DFDC4056A61A5244EC45 26C900A46DD40CD5AD24F6D7DEE01987265FA05B 0C2B1D7175B852C64B3CDC716C55397824F434CE Jan 10 15:07:53.235 [32233] dbg: channel: attempting channel updates.spamassassin.org Jan 10 15:07:53.235 [32233] dbg: channel: update directory /var/lib/spamassassin/3.003002/updates_spamassassin_org Jan 10 15:07:53.235 [32233] dbg: channel: channel cf file /var/lib/spamassassin/3.003002/updates_spamassassin_org.cf Jan 10 15:07:53.236 [32233] dbg: channel: channel pre file /var/lib/spamassassin/3.003002/updates_spamassassin_org.pre Jan 10 15:07:53.236 [32233] dbg: channel: metadata version = 1227079 Jan 10 15:07:53.240 [32233] dbg: dns: 2.3.3.updates.spamassassin.org => 1227079, parsed as 1227079 Jan 10 15:07:53.240 [32233] dbg: channel: current version is 1227079, new version is 1227079, skipping channel Jan 10 15:07:53.240 [32233] dbg: diag: updates complete, exiting with code 1
Regards, DH
Why? Just remove that package and install the one from CentOS.
Spamassassin doesn't need to be touched.
Seems to me that you are still using the mix of repos. Packages from RF work fine.
Well, kind of. If you review this thread, you'll see that the the fix was to stop using the RepoForge package for perl-NetAddr-IP so that it wasn't mixed with CentOS packages for perl-Net-DNS and perl-IO-Socket-INET6.
Maybe your position is that you won't fix perl-NetAddr-IP because you only support it when used when all other packages are from RepoForge, but I don't think that's realistic at all - everyone running CentOS will have mostly CentOS packages - naturally. They'll pick up some others they want or need for various reasons from RepoForge, so I'd imagine you'll see mixing of packages quite often amongst people who add RepoForge to their yum systems. Therefore, I'd have thought you'd be interested to learn of an incompatibility in one of the RepoForge packages.
root@specs2:1280:279:/$ rpm -q spamassassin perl-IO-Socket-INET6 perl-Net-DNS perl-NetAddr-IP| sort perl-IO-Socket-INET6-2.57-2.el5.rfx perl-NetAddr-IP-4.044-1.el5.rf perl-Net-DNS-0.66-1.el5.rfx spamassassin-3.3.2-2.el5.rfx
Dne 11.1.2012 1:13, email builder napsal(a):
Well, kind of. If you review this thread, you'll see that the the fix was to stop using the RepoForge package for perl-NetAddr-IP so that it wasn't mixed with CentOS packages for perl-Net-DNS and perl-IO-Socket-INET6. Maybe your position is that you won't fix perl-NetAddr-IP because you only support it when used when all other packages are from RepoForge, but I don't think that's realistic at all
- everyone running CentOS will have mostly CentOS packages -
naturally. They'll pick up some others they want or need for various reasons from RepoForge, so I'd imagine you'll see mixing of packages quite often amongst people who add RepoForge to their yum systems. Therefore, I'd have thought you'd be interested to learn of an incompatibility in one of the RepoForge packages.
Well, I will definitely not fix it. Most of users does not pick up the particular packages but enables the repo entity. Basically it would be really hard to support both scenarios. I consider packages you mention as a whole email stack provided by RF. The stack includes: amavisd-new spamassassin dependent perl-* dependent file de-compressors Regards, DH
On 01/11/2012 04:42 AM, David Hrbáč wrote:
Dne 11.1.2012 1:13, email builder napsal(a):
Well, kind of. If you review this thread, you'll see that the the fix was to stop using the RepoForge package for perl-NetAddr-IP so that it wasn't mixed with CentOS packages for perl-Net-DNS and perl-IO-Socket-INET6. Maybe your position is that you won't fix perl-NetAddr-IP because you only support it when used when all other packages are from RepoForge, but I don't think that's realistic at all
- everyone running CentOS will have mostly CentOS packages -
naturally. They'll pick up some others they want or need for various reasons from RepoForge, so I'd imagine you'll see mixing of packages quite often amongst people who add RepoForge to their yum systems. Therefore, I'd have thought you'd be interested to learn of an incompatibility in one of the RepoForge packages.
Well, I will definitely not fix it. Most of users does not pick up the particular packages but enables the repo entity. Basically it would be really hard to support both scenarios. I consider packages you mention as a whole email stack provided by RF. The stack includes: amavisd-new spamassassin dependent perl-* dependent file de-compressors Regards, DH
I agree with David here ...
repoforge has moved all packages that replace CentOS base packages to their rfx (repoforge extras) repository.
If you are going to use rfx packages, you likely need to use all relevant rfx packages and not mix and match (which is what caused this problem). In this case, that would include the whole stack for spamassassin. This DOES replace base CentOS packages ... but that is the purpose of the RFX repo, so don't enable it in the first place if you don't want to replace CentOS packages. And if you DO want to replace CentOS packages, then replace them all for the things you are installing from rfx.
A different way to accomplish the same thing without replacing CentOS base packages (if your goal is to prevent replacing base packages ... which may or may not be your goal) is to first try EPEL. EPEL has a version of amavisd-new (for this particular scenario) which works properly with all the base CentOS packages. A goal of EPEL is that they can not replace packages from RHEL (so also not CentOS). But the version of amavisd-new is older in EPEL than the one in RFX. Which is best ... that is up to you.
I am not recommending one approach over the other ... which approach you take depends on your goals. Most of the time my personal goals are to stay as close to the enterprise OS as I possibly can and only replace packages if absolutely necessary, so I would likely try EPEL first and go to RFX later. But, I do not know of any packages in RFX that break things, so I think either approach can be equally "stable" on CentOS servers.
The bottom line is that you need to understand what you are trying to accomplish and adjust your strategy as necessary. You need to understand what the goals of a repository is before you enable it (does it replace base packages, do I want to try to block that aspect of the repo, etc) ... and you need to enable it correctly if you intend to use it.
For RFX (as an example)... if you enable things like yum-priorities (which will always choose base/updates from CentOS over newer packages from RFX), that is going to cause issues where some packages from RFX may not work properly with the base CentOS packages.
Adding 3rd party repos is complicated and if you do it, you need to pay close attention to what each one does and enable it properly. You can't expect 3rd party repos to support using only parts of the repo and not others (ie, yum-priorities) ... but you also can't expect CentOS to support the packages installed by the 3rd party repos that replace base packages. Therefore, YOU have to support yourself if you add them :D
Johnny Hughes wrote:
On 01/11/2012 04:42 AM, David Hrbáč wrote:
Dne 11.1.2012 1:13, email builder napsal(a):
Well, kind of. If you review this thread, you'll see that the the fix was to stop using the RepoForge package for perl-NetAddr-IP so that it wasn't mixed with CentOS packages for perl-Net-DNS and perl-IO-Socket-INET6. Maybe your position is that you won't fix perl-NetAddr-IP because you only support it when used when all other packages are from RepoForge, but I don't think that's realistic at all
- everyone running CentOS will have mostly CentOS packages -
naturally. They'll pick up some others they want or need for various reasons from RepoForge, so I'd imagine you'll see mixing of packages quite often amongst people who add RepoForge to their yum systems. Therefore, I'd have thought you'd be interested to learn of an incompatibility in one of the RepoForge packages.
Well, I will definitely not fix it. Most of users does not pick up the particular packages but enables the repo entity. Basically it would be really hard to support both scenarios. I consider packages you mention as a whole email stack provided by RF. The stack includes: amavisd-new spamassassin dependent perl-* dependent file de-compressors Regards, DH
I agree with David here ...
repoforge has moved all packages that replace CentOS base packages to their rfx (repoforge extras) repository.
the problem in this case is that perl-NetAddr-IP from repoforge should be in RFX, but it isn't. But it's really for historical reasons: perl-NetAddr-IP was only added to base in 5.7. So now that it's in base it has to move from rf to rfx, and it just hasn't done so yet. But the move from rf to rfx doesn't fundamentally change things, there's no magic solution here: in any case, if a user had the RF perl-NetAddr-IP installed prior to 5.7 (perfectly legitimate), and decides to install spamassassin today (pulling it from base since it's there, this is legit and standard practice as well), s/he will have the OP's issue. Having the package tagged RFX will simply make it easier to identify the problem.
Well, kind of. If you review this thread, you'll see that the the
fix was to stop using the RepoForge package for perl-NetAddr-IP so that it wasn't mixed with CentOS packages for perl-Net-DNS and perl-IO-Socket-INET6. Maybe your position is that you won't fix perl-NetAddr-IP because you only support it when used when all other packages are from RepoForge, but I don't think that's realistic at all
- everyone running CentOS will have mostly CentOS packages -
naturally. They'll pick up some others they want or need for various reasons from RepoForge, so I'd imagine you'll see mixing of packages quite often amongst people who add RepoForge to their yum systems. Therefore, I'd have thought you'd be interested to learn of an incompatibility in one of the RepoForge packages.
Well, I will definitely not fix it. Most of users does not pick up the particular packages but enables the repo entity. Basically it would be really hard to support both scenarios. I consider packages you mention as a whole email stack provided by RF. The stack includes: amavisd-new spamassassin dependent perl-* dependent file de-compressors Regards, DH
I agree with David here ...
repoforge has moved all packages that replace CentOS base packages to their rfx (repoforge extras) repository.
If you are going to use rfx packages, you likely need to use all relevant rfx packages and not mix and match (which is what caused this problem). In this case, that would include the whole stack for spamassassin. This DOES replace base CentOS packages ... but that is the purpose of the RFX repo, so don't enable it in the first place if you don't want to replace CentOS packages. And if you DO want to replace CentOS packages, then replace them all for the things you are installing from rfx.
A different way to accomplish the same thing without replacing CentOS base packages (if your goal is to prevent replacing base packages ... which may or may not be your goal) is to first try EPEL. EPEL has a version of amavisd-new (for this particular scenario) which works properly with all the base CentOS packages. A goal of EPEL is that they can not replace packages from RHEL (so also not CentOS). But the version of amavisd-new is older in EPEL than the one in RFX. Which is best ... that is up to you.
I am not recommending one approach over the other ... which approach you take depends on your goals. Most of the time my personal goals are to stay as close to the enterprise OS as I possibly can and only replace packages if absolutely necessary, so I would likely try EPEL first and go to RFX later. But, I do not know of any packages in RFX that break things, so I think either approach can be equally "stable" on CentOS servers.
I don't 100% understand your explanation of EPEL, but I'm definitely going to go learn about it.
The bottom line is that you need to understand what you are trying to accomplish and adjust your strategy as necessary. You need to understand what the goals of a repository is before you enable it (does it replace base packages, do I want to try to block that aspect of the repo, etc) ... and you need to enable it correctly if you intend to use it.
For RFX (as an example)... if you enable things like yum-priorities (which will always choose base/updates from CentOS over newer packages from RFX), that is going to cause issues where some packages from RFX may not work properly with the base CentOS packages.
Adding 3rd party repos is complicated and if you do it, you need to pay close attention to what each one does and enable it properly. You can't expect 3rd party repos to support using only parts of the repo and not others (ie, yum-priorities) ... but you also can't expect CentOS to support the packages installed by the 3rd party repos that replace base packages. Therefore, YOU have to support yourself if you add them :D
I understand this in principle, but I think reality ends up being a little more difficult. I think I ended up with what RepoForge packages I did because at the time I built the server, CentOS either didn't have amavisd-new at all or RepoForge's was newer and without knowing about yum-priorities, I got the RepoForge one (and a bunch of other dependencies) without really understanding the implications (I had enabled RepoForge to get a version of Postfix that wasn't horribly crippled, although at this point both RepoForge and CentOS's versions of postfix are deplorably ancient - compiling by hand may be in order).
So I could have been better educated for sure, but the way it plays out also isn't going to be straight forward in a lot of cases I think. Maybe RepoForge should make it more clear on their site what the implications of using their packages are or that users may want to use yum-priorities for a better chance of avoiding problems. I certainly would have thought twice if their site had warned me of possible problems that could happen if I was only using part of their whole "email stack".
And then there's the problem Nicolas is pointing out, which seems to be part of my problem. If such conflicting packages are supposed to be in rfx but are not..... Maybe Daniel could move it, which would definitely help my yum to stop complaining....
And then there's the problem Nicolas is pointing out, which seems
to be part of my problem. If such conflicting packages are supposed to be in rfx but are not..... Maybe Daniel could move it, which would definitely help my yum to stop complaining....
David not Daniel. My apologies missing your name.
On 01/11/2012 08:42 AM, email builder wrote:
Well, kind of. If you review this thread, you'll see that the the fix was to stop using the RepoForge package for perl-NetAddr-IP so that it wasn't mixed with CentOS packages for perl-Net-DNS and perl-IO-Socket-INET6. Maybe your position is that you won't fix perl-NetAddr-IP because you only support it when used when all other packages are from RepoForge, but I don't think that's realistic at all
- everyone running CentOS will have mostly CentOS packages -
naturally. They'll pick up some others they want or need for various reasons from RepoForge, so I'd imagine you'll see mixing of packages quite often amongst people who add RepoForge to their yum systems. Therefore, I'd have thought you'd be interested to learn of an incompatibility in one of the RepoForge packages.
Well, I will definitely not fix it. Most of users does not pick up the particular packages but enables the repo entity. Basically it would be really hard to support both scenarios. I consider packages you mention as a whole email stack provided by RF. The stack includes: amavisd-new spamassassin dependent perl-* dependent file de-compressors Regards, DH
I agree with David here ...
repoforge has moved all packages that replace CentOS base packages to their rfx (repoforge extras) repository.
If you are going to use rfx packages, you likely need to use all relevant rfx packages and not mix and match (which is what caused this problem). In this case, that would include the whole stack for spamassassin. This DOES replace base CentOS packages ... but that is the purpose of the RFX repo, so don't enable it in the first place if you don't want to replace CentOS packages. And if you DO want to replace CentOS packages, then replace them all for the things you are installing from rfx.
A different way to accomplish the same thing without replacing CentOS base packages (if your goal is to prevent replacing base packages ... which may or may not be your goal) is to first try EPEL. EPEL has a version of amavisd-new (for this particular scenario) which works properly with all the base CentOS packages. A goal of EPEL is that they can not replace packages from RHEL (so also not CentOS). But the version of amavisd-new is older in EPEL than the one in RFX. Which is best ... that is up to you.
I am not recommending one approach over the other ... which approach you take depends on your goals. Most of the time my personal goals are to stay as close to the enterprise OS as I possibly can and only replace packages if absolutely necessary, so I would likely try EPEL first and go to RFX later. But, I do not know of any packages in RFX that break things, so I think either approach can be equally "stable" on CentOS servers.
I don't 100% understand your explanation of EPEL, but I'm definitely going to go learn about it.
The bottom line is that you need to understand what you are trying to accomplish and adjust your strategy as necessary. You need to understand what the goals of a repository is before you enable it (does it replace base packages, do I want to try to block that aspect of the repo, etc) ... and you need to enable it correctly if you intend to use it.
For RFX (as an example)... if you enable things like yum-priorities (which will always choose base/updates from CentOS over newer packages from RFX), that is going to cause issues where some packages from RFX may not work properly with the base CentOS packages.
Adding 3rd party repos is complicated and if you do it, you need to pay close attention to what each one does and enable it properly. You can't expect 3rd party repos to support using only parts of the repo and not others (ie, yum-priorities) ... but you also can't expect CentOS to support the packages installed by the 3rd party repos that replace base packages. Therefore, YOU have to support yourself if you add them :D
I understand this in principle, but I think reality ends up being a little more difficult. I think I ended up with what RepoForge packages I did because at the time I built the server, CentOS either didn't have amavisd-new at all or RepoForge's was newer and without knowing about yum-priorities, I got the RepoForge one (and a bunch of other dependencies) without really understanding the implications (I had enabled RepoForge to get a version of Postfix that wasn't horribly crippled, although at this point both RepoForge and CentOS's versions of postfix are deplorably ancient - compiling by hand may be in order).
So I could have been better educated for sure, but the way it plays out also isn't going to be straight forward in a lot of cases I think. Maybe RepoForge should make it more clear on their site what the implications of using their packages are or that users may want to use yum-priorities for a better chance of avoiding problems. I certainly would have thought twice if their site had warned me of possible problems that could happen if I was only using part of their whole "email stack".
And then there's the problem Nicolas is pointing out, which seems to be part of my problem. If such conflicting packages are supposed to be in rfx but are not..... Maybe Daniel could move it, which would definitely help my yum to stop complaining.... _______________________________________________
It is now part of RFX and not part of RF. If you look here, you will see no perl-NetAddr-IP now in RF.
http://apt.sw.be/redhat/el6/en/x86_64/
(there is a repoforge and and extras dir under there)
Johnny Hughes wrote:
On 01/11/2012 08:42 AM, email builder wrote:
And then there's the problem Nicolas is pointing out, which seems to be part of my problem. If such conflicting packages are supposed to be in rfx but are not..... Maybe Daniel could move it, which would definitely help my yum to stop complaining....
It is now part of RFX and not part of RF. If you look here, you will see no perl-NetAddr-IP now in RF.
http://apt.sw.be/redhat/el6/en/x86_64/
(there is a repoforge and and extras dir under there)
it's in RFX for el6, but not for el5 which we were talking about ;-)
On 01/11/2012 09:59 AM, Nicolas Thierry-Mieg wrote:
Johnny Hughes wrote:
On 01/11/2012 08:42 AM, email builder wrote:
And then there's the problem Nicolas is pointing out, which seems to be part of my problem. If such conflicting packages are supposed to be in rfx but are not..... Maybe Daniel could move it, which would definitely help my yum to stop complaining....
It is now part of RFX and not part of RF. If you look here, you will see no perl-NetAddr-IP now in RF.
http://apt.sw.be/redhat/el6/en/x86_64/
(there is a repoforge and and extras dir under there)
it's in RFX for el6, but not for el5 which we were talking about ;-)
OK ... then it ought to move (probably) :)
Dne 11.1.2012 17:22, Johnny Hughes napsal(a):
OK ... then it ought to move (probably) :)
Se my post on repoforge users list. http://lists.repoforge.org/pipermail/users/2012-January/022634.html .... There's no one to move the package but Dag. DH
OK ... then it ought to move (probably) :)
Se my post on repoforge users list. http://lists.repoforge.org/pipermail/users/2012-January/022634.html .... There's no one to move the package but Dag.
Per your suggestion, I filed a bug report on this, although that tracker seems like a lonely place. :)
OK ... then it ought to move (probably) :)
See my post on repoforge users list. http://lists.repoforge.org/pipermail/users/2012-January/022634.html .... There's no one to move the package but Dag.
Per your suggestion, I filed a bug report on this, although that tracker seems like a lonely place. :)
FYI for the CentOS list, this issue has been resolved (perl-NetAddr-IP has been moved to the RepoForge extras repository).
Yum no longer complains that perl-NetAddr-IP has to be updated and spamassassin does not produce errors.
Thanks again
And then there's the problem Nicolas is pointing out, which seems to be part of my problem. If such conflicting packages are supposed to be in rfx but are not..... Maybe Daniel could move it, which would definitely help my yum to stop complaining....
It is now part of RFX and not part of RF. If you look here, you will see no perl-NetAddr-IP now in RF.
http://apt.sw.be/redhat/el6/en/x86_64/
(there is a repoforge and and extras dir under there)
I'm on a 32 bit machine, not sure if that makes a difference.
What I do know is this:
yum update
============================================================================================== Package Arch Version Repository Size ============================================================================================== Updating: perl-NetAddr-IP i386 4.044-1.el5.rf rpmforge 140 k
Transaction Summary ============================================================================================== Install 0 Package(s) Upgrade 1 Package(s)
Is this because I need to migrate something from rpmforge to RepoForge???
Dne 11.1.2012 17:12, email builder napsal(a):
I'm on a 32 bit machine, not sure if that makes a difference. What I do know is this:
yum update
============================================================================================== Package Arch Version Repository Size ============================================================================================== Updating: perl-NetAddr-IP i386 4.044-1.el5.rf rpmforge 140 k
Transaction Summary
Install 0 Package(s) Upgrade 1 Package(s)
Is this because I need to migrate something from rpmforge to RepoForge???
No, this is the timeline: - no perl-NetAddr-IP in Centos <5.7 - RF's perl-NetAddr-IP replaces no package in OS, so it must be in RF repo - perl-NetAddr-IP-4.027 has been introduced in Centos 5.7 - no one (Dag) moved perl-NetAddr-IP from RF to RFX - stock perl-NetAddr-IP-4.027<perl-NetAddr-IP-4.044 from RF - and here goes the yum... DH
Johnny Hughes wrote:
On 01/07/2012 12:50 PM, email builder wrote:
I don't know what is causing your specific issue ... whether you are getting something newer in sa-update than is designed to work with CentOS (sa-update bypasses the normal rpm type updates and does updates from elsewhere). It should only update rules, so maybe some of the new rules require a new version of perl-Net-DNS. If that is the case, then a Red Hat bugzilla entry needs to be made.
See above - it's the spamassassin restart that causes the error, in the end, nothing really to do with sa-update.
If it will not work with the CentOS version of perl-Net-DNS and if it works with the rfx version, then obviously you would run that. If that is the case, we need to get the rhel one upgraded.
So maybe I *do* need to open a bug report? Where do I do that?
can you try to disable ipv6, then reboot and see if you still get the error message?
Sorry, it's a production machine, I'd rather not do that. I can make small changes but a reboot-- Beside, if this is the set of packages CentOS gives me when I install something like spamassassin, it seems like they should work no matter what. But don't get me wrong, I really appreciate your suggestion.
It is not the CentOS packages causing your issues. I told you already that I have spamassassin running with these packages with no problems: ================================================== [root@localhost ~]# rpm -qa | grep -i perl | sort
<snip>
The issue you are having, based on the error that you posted, is that something else is already providing the subroutine "Net::DNS::Resolver::Base::AF_INET6" when it is trying to be loaded by perl module provided by CentOS (perl-Net-DNS-0.59-3.el5.i386). What we do not know is what ELSE is providing that routine.
Since I have the same 3 RPMs installed that you are quoting as the potential issue, and since I am not having the dual subroutine issue, that implies that the "SOMETHING ELSE" providing the other "Net::DNS::Resolver::Base::AF_INET6" is not any of the packages that I have installed.
So, I would say that this issue must be caused by the intermixing of perl modules from other than CentOS repositories.
Can anyone reproduce this issue without .rf. or .rfx. perl modules installed?
I have seen this same issue, but on a system where I am a user, so I can't experiment much. I tried to reproduce it on one of my systems and could not. The only perl package from rf[x] on the system with the issue is perl-NetAddr-IP-4.044-1.el5.rf.x86_64. Installing that on my test system does not exhibit the problem, but the test system has ipv6 disabled.
What I get on the problem system is eg: $ sa-learn --spam .0spam/cur/ Subroutine IO::Socket::INET6::AF_INET6 redefined at /usr/lib/perl5/5.8.8/Exporter.pm line 65. at /usr/lib/perl5/vendor_perl/5.8.8/IO/Socket/INET6.pm line 16 Subroutine Net::DNS::Resolver::Base::AF_INET6 redefined at /usr/lib/perl5/5.8.8/Exporter.pm line 65. at /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/Net/DNS/Resolver/Base.pm line 66 Learned tokens from 0 message(s) (2 message(s) examined)
There are many similar issues on google. It seems to be just noise though, and spamassassin still appears to function properly.
After solving my problem by downgrading perl-NetAddr-IP to the CentOS repo's version, yum is of course telling me perl-NetAddr-IP is out of date and needs to be updated (back to the buggy one in RepoForge).
So looks like yum-priorities is in order (ha! the pun!), but I have a question
Hmm, OK, prioritze CentOS repo over RepoForge then will yum update
figure out the rest? I don't see any priority settings in my yum conf files...
# yum list | grep priorities yum-priorities.noarch 1.1.16-16.el5.centos installed
# cat /etc/yum/pluginconf.d/priorities.conf [main] enabled = 1 check_obsoletes=1
Then add "priority=n" to the repos sections. n=1 for CentOS n=2 for repo 2 etc...
If I already have a bunch of packages from RepoForge, some of which might also be in the CentOS repo (some presumably with lower version numbers), what happens after installing and configuring yum-priorities?
Do those packages automatically get downgraded? Does yum complain and tell me I should downgrade? I assume upgrades would happen per usual if there are newer versions of packages in CentOS repo.
I'm slightly concerned because I have a handful of packages that got installed automatically from RepoForge when I installed amavisd-new from there, and I'd hate to break something.
Thanks for any preemptive advice!!!!
On 2012-01-10 14:13, email builder wrote: ... <snip> ...
If I already have a bunch of packages from RepoForge, some of which might also be in the CentOS repo (some presumably with lower version numbers), what happens after installing and configuring yum-priorities?
Do those packages automatically get downgraded? Does yum complain and tell me I should downgrade? I assume upgrades would happen per usual if there are newer versions of packages in CentOS repo.
I'm slightly concerned because I have a handful of packages that got installed automatically from RepoForge when I installed amavisd-new from there, and I'd hate to break something.
If the packages are _NEWER_ than those in CentOS, then no, they will not be overwritten.
You might also consider installing yum-protectbase.
You'd then have to make a conscious effort to overwrite the base packages!
Cheers, ak.
On 01/09/2012 09:59 PM, Anthony wrote:
On 2012-01-10 14:13, email builder wrote: ...
<snip> ... > If I already have a bunch of packages from RepoForge, some of which > might also be in the CentOS repo (some presumably with lower version > numbers), what happens after installing and configuring > yum-priorities? > > Do those packages automatically get downgraded? Does yum complain > and tell me I should downgrade? I assume upgrades would happen per > usual if there are newer versions of packages in CentOS repo. > > I'm slightly concerned because I have a handful of packages that got > installed automatically from RepoForge when I installed amavisd-new > from there, and I'd hate to break something. If the packages are _NEWER_ than those in CentOS, then no, they will not be overwritten.
You might also consider installing yum-protectbase.
You'd then have to make a conscious effort to overwrite the base packages!
You need to do the same thing with yum-priorities as well ... basically, yum-protectbase and yum-priorities are the same thing, with protectbase having 2 priority groups (1 and 0) with priorities has 99 priority groups (99 down to 1). I would use yum-priorities and not yum-protectbase.
In both cases, you are not going to be told about packages already installed that are newer than those in the CentOS.
You can find those RPMs though by doing this:
rpm -qa | egrep ".rf" | sort
that will tell you all repoforge rpms installed ... then do this to see which ones also have duplicates from base or updates:
yum --disablerepo=* --enablerepo=base --enablerepo=updates --showduplicates list all $(rpm -q --qf '%{name} ' $(rpm -qa | grep ".rf"))
That should work to tell you which .rf packages are also in base or updates.
Johnny Hughes wrote:
On 01/09/2012 09:59 PM, Anthony wrote:
In both cases, you are not going to be told about packages already installed that are newer than those in the CentOS.
You can find those RPMs though by doing this:
rpm -qa | egrep ".rf" | sort
that will tell you all repoforge rpms installed ... then do this to see which ones also have duplicates from base or updates:
yum --disablerepo=* --enablerepo=base --enablerepo=updates --showduplicates list all $(rpm -q --qf '%{name} ' $(rpm -qa | grep ".rf"))
That should work to tell you which .rf packages are also in base or updates.
and if you find any that are .rf (not .rfx==repoforge extras), you can report them to the repoforge mailing list or on their github, because packages that conflict with base+updates are supposed to be in rfx now, not rf.
-
Anthony -
David Hrbáč -
email builder -
Gregory P. Ennis -
John Doe -
Johnny Hughes -
Ljubomir Ljubojevic -
Nicolas Thierry-Mieg