On Thu, 28 Jul 2011, Ross Walker wrote:
> To: CentOS mailing list
> From: Ross Walker
> Subject: Re: [CentOS] yum segfault - rpmforge problem?
>
> On Jul 26, 2011, at 2:03 PM, Keith Roberts wrote:
>
>> On Tue, 26 Jul 2011, Always Learning wrote:
>>
>>
On Jul 26, 2011, at 2:03 PM, Keith Roberts wrote:
> On Tue, 26 Jul 2011, Always Learning wrote:
>
> *snip*
>
>> Programmes that abort because of bad data are defective programmes and
>> need rectification. No good programmer ever accepts that other people's
>> data will always be valid.
>
> +1
On Tue, 26 Jul 2011, Always Learning wrote:
*snip*
> Programmes that abort because of bad data are defective programmes and
> need rectification. No good programmer ever accepts that other people's
> data will always be valid.
+1
Kind Regards,
Keith
---
On Tue, 2011-07-26 at 18:34 +0200, Leonard den Ottolander wrote:
> On Tue, 2011-07-26 at 17:22 +0100, Karanbir Singh wrote:
> > sure, but you need to take this upstream to get attention.
>
> This has happened as I mentioned earlier.
>
> > I just dont
> > see this as an important enough issue
On 07/26/2011 05:34 PM, Leonard den Ottolander wrote:
>> I just dont
>> see this as an important enough issue to fix within centos here.
>
> No such suggestion was made. We all know CentOS behaves like upstream
> and the fix will probably trickle down soon enough.
ah you see, we have a bit of room
On Tue, 26 Jul 2011, Stephen Harris wrote:
>> I dont really see that as a yum issue, the problem is bad metadata in
>> rpmforge.
>
> A segfault is a bug, even if it's only triggered by bad data :-)
I agree. It should report that the checksum is bad, and skip to the next
repo.
> (thought: could
On 07/26/2011 05:43 PM, Stephen Harris wrote:
> (thought: could bad metadata cause an exploitable segfault?)
>
if you can create something like that - make sure you report it to the
right places!
- KB
___
CentOS mailing list
CentOS@centos.org
http://li
On Tue, Jul 26, 2011 at 05:12:23PM +0100, Karanbir Singh wrote:
> On 07/26/2011 04:59 PM, Leonard den Ottolander wrote:
> > Seems an issue with yum too, seeing that it segfaults over bad data.
> > This has been reported upstream:
> > https://bugzilla.redhat.com/show_bug.cgi?id=725798
>
> I dont re
On Tue, 2011-07-26 at 17:22 +0100, Karanbir Singh wrote:
> sure, but you need to take this upstream to get attention.
This has happened as I mentioned earlier.
> I just dont
> see this as an important enough issue to fix within centos here.
No such suggestion was made. We all know CentOS behav
On Tue, 2011-07-26 at 17:12 +0100, Karanbir Singh wrote:
> I dont really see that as a yum issue, the problem is bad metadata in
> rpmforge.
A programme that crashes on bad input is what I'd call broken. Abort
yes, segfault no.
Regards,
Leonard.
--
mount -t life -o ro /dev/dna /genetic/researc
On 07/26/2011 05:19 PM, Thomas Harold wrote:
> While the problem is bad metadata, should yum really be left off the
> hook for segfaulting when it gets bad data? Shouldn't yum catch that
> error with checks, then exit gracefully with an error code?
sure, but you need to take this upstream to get a
On 7/26/2011 12:12 PM, Karanbir Singh wrote:
> On 07/26/2011 04:59 PM, Leonard den Ottolander wrote:
>> Seems an issue with yum too, seeing that it segfaults over bad data.
>> This has been reported upstream:
>> https://bugzilla.redhat.com/show_bug.cgi?id=725798
>
> I dont really see that as a yum
On 07/26/2011 04:59 PM, Leonard den Ottolander wrote:
> Seems an issue with yum too, seeing that it segfaults over bad data.
> This has been reported upstream:
> https://bugzilla.redhat.com/show_bug.cgi?id=725798
I dont really see that as a yum issue, the problem is bad metadata in
rpmforge.
- K
We have the same problem with DAG repositories.
Regards,
Mathieu.
Le 26/07/2011 17:59, Leonard den Ottolander a écrit :
> On Tue, 2011-07-26 at 16:40 +0100, Karanbir Singh wrote:
>> this is a problem with the metadata from rpmforge, a couple of guys are
>> working through the issue in #yum on irc
On Tue, 2011-07-26 at 16:40 +0100, Karanbir Singh wrote:
> this is a problem with the metadata from rpmforge, a couple of guys are
> working through the issue in #yum on irc.freenode.net, feel free to join
> them.
Seems an issue with yum too, seeing that it segfaults over bad data.
This has been
On 07/26/2011 04:33 PM, Lars Hecking wrote:
>
>> We've had the same problem. It helped to recursively delete all cached
>> files in /var/cache/yum. Just run yum update again and you shoudl be fine.
>
> This does not help here. I started from an empty /var/cache/yum directory.
> The problem is r
> We've had the same problem. It helped to recursively delete all cached
> files in /var/cache/yum. Just run yum update again and you shoudl be fine.
This does not help here. I started from an empty /var/cache/yum directory.
The problem is related to rpmforge, there is no segfault with
--disab
> 00:01
> rpmforge | 1.1 kB
> 00:00
> rpmforge/primary | 3.9 MB
> 00:20
> rpmforge: [## ]
> 471/10722Segmentation fault
>
We've had the same p
MB 00:11
dag: [###
] 891/10953Segmentation fault
Frank M. Ramaekers Jr.
-Original Message-
From: centos-boun...@centos.org [mailto:centos-boun...@centos.org] On
Behalf Of Lars Hecking
Sent: Tuesday, July 26, 2011 9:01 AM
To: centos@centos.org
Subject: [CentOS] yum segfault
[root@host ~]# yum clean all
Loaded plugins: fastestmirror, protectbase
Cleaning up Everything
Cleaning up list of fastest mirrors
[root@ost ~]# yum search libcli
Loaded plugins: fastestmirror, protectbase
Determining fastest mirrors
* base: centos-distro.cavecreek.net
* elrepo: elrepo.imt-syste
20 matches
Mail list logo
