>>> 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
>> 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 lo
>> 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 R
> 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 m
>>> 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-N
>> 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 R
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
>> 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/Export
>> Is there somewhere at RepoForge I could notify them about this?
>
> users mailing list:
> us...@lists.repoforge.org
> http://lists.repoforge.org/mailman/listinfo/users
Thank you. I am reporting it now
___
CentOS mailing list
CentOS@centos.org
ht
>> 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
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
>>> 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 t
>>> 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/spamassa
>>> 1.) Attacker uses apache remote exploit (or other means) to obtain
>>> your /etc/shadow file (not a remote shell, just GET the file
>>> without that fact being logged);
>>
>> I don't mean to thread-hijack, but I'm curious, if apache runs as
>> its
>> own non-root user and /etc/shadow i
>>> 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
>
> 1.) Attacker uses apache remote exploit (or other means) to obtain
> your /etc/shadow file (not a remote shell, just GET the file
> without that fact being logged);
I don't mean to thread-hijack, but I'm curious, if apache runs as its
own non-root user and /etc/shadow is root-owned and 0400,
>> 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/yu
>> 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
>> rem
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.
>>> 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
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
>> r
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.
> >>Is the only reasonable solution to schedule a "human cron" once a week
>to look
> >> at needed updates? Ouch.
> >
> > A middle-of-the-road approach is to have a machine or VM where you can
> > test things, perhaps the one you use as your own desktop or for
> > development, where
- Original Message
> From: Robert Heller
> To: CentOS mailing list
> Cc: centos@centos.org
> Sent: Wed, April 6, 2011 11:58:46 AM
> Subject: Re: [CentOS] Auto-updates -- Bad Idea?
>
> At Wed, 6 Apr 2011 11:35:47 -0700 (PDT) CentOS mailing list
>
>wrote:
>
> >
> > Hello,
> >
>
Hello,
As I've learned recently, I do not have any auto updates configured on my
system. I see some posts on the web encouraging the use of "yum-cron", but I'd
like to know what people feel about the use of automatic updates.
That is, for a server (non-desktop) system, automatic updates co
> > It does look like updates are happening, but it's not clear to me by
> > whom.
> > do_update is set to "no", but notification is by "dbus", so I assumed
> > that
> > "dbus" is notifying another process to do the actual updates. Is
> there
> > a way I
> > can track that down?
> >
> > > A
> > then the outstanding question is how to figure out why certain
> > packages are not being updated.
>
> Well, first action: did you actually check with the repo that there is a
> newer package?
Yes. I'm not sure why would you think otherwise...?
> Just because a package isn't updated
> > Do you know how to determine which repo a particular package is from? For
> > example, when I do "yum info" against clamav (which isn't receiving
>automatic
>
> > updates), it just says "Repo: installed". I don't know what repo it comes
>from.
> >
> "yum list clamav --showduplicate
> > >> >> Sorry if this is somewhat naive, but I'm a little confused as to
>what
>
> >the
> > >> >> criteria is for that which will get upgraded automatically by
> > >> yum
>and
> > > what
> > >> >> will not.
> > >> >>
> > >> >> I see in our logwatch messages from time to time t
> >> >> Sorry if this is somewhat naive, but I'm a little confused as to
> >> >> what
>the
> >> >> criteria is for that which will get upgraded automatically by yum and
> > what
> >> >> will not.
> >> >>
> >> >> I see in our logwatch messages from time to time that yum upgraded
> >> >
> > Sorry if this is somewhat naive, but I'm a little confused as to what
> > the
> > criteria is for that which will get upgraded automatically by yum and what
>will
>
> > not.
> >
> > I see in our logwatch messages from time to time that yum upgraded a
> > bunch
>of
>
> > stuff,
> >> Sorry if this is somewhat naive, but I'm a little confused as to what the
> >> criteria is for that which will get upgraded automatically by yum and
what
> >> will not.
> >>
> >> I see in our logwatch messages from time to time that yum upgraded
> >> a bunch of stuff, but I also noti
> Sorry if this is somewhat naive, but I'm a little confused as to what the
> criteria is for that which will get upgraded automatically by yum and what
>will
>
> not.
>
> I see in our logwatch messages from time to time that yum upgraded a bunch
>of
>
> stuff, but I also notice that
Hello,
Sorry if this is somewhat naive, but I'm a little confused as to what the
criteria is for that which will get upgraded automatically by yum and what will
not.
I see in our logwatch messages from time to time that yum upgraded a bunch of
stuff, but I also notice that yum will not upg
34 matches
Mail list logo
