Is RPMfusion on strike? [SOLVED -- at least for me]

[Matthew Saltzman]

On Tue, 2009-08-25 at 06:17 +0500, gilpel at altern.org wrote: 
> > Hi gilpel;
> >
> > On Tue, 2009-08-25 at 02:04 +0500, gilpel at altern.org wrote:
> >> > On Mon, 2009-08-24 at 09:36 +0500, gilpel at altern.org wrote:
> >
> >> > Again, any messages in dmesg or /var/log/messages
> >> > or /var/log/Xorg.0.log?
> >>
> >> Yes this one, in dmesg:
> >>
> >> NVRM: API mismatch: the client has version 185.18.31 but this kernel
> >> module has version 185.18.14
> >>
> >> If I boot with kernel 2.6.29.6-217.2.3.fc11.x86_64 and I
> >> uninstall/install
> >> kmod-nvidia, I still get version 185.18.14.
> >>
> > and for
> > kernel.x86_64                   2.6.29.6-217.2.7.fc11                  s
> > kernel.x86_64                   2.6.29.6-217.2.8.fc11
> >
> > kmod-nvidia version 185.18.14 is what you are supposed to get.
> 
> Then, why do I have:
> 
> locate "185.18.31"
> /usr/lib64/nvidia/libGL.so.185.18.31
> /usr/lib64/nvidia/libGLcore.so.185.18.31
> /usr/lib64/nvidia/libXvMCNVIDIA.so.185.18.31
> /usr/lib64/nvidia/libcuda.so.185.18.31
> /usr/lib64/nvidia/libnvidia-cfg.so.185.18.31
> /usr/lib64/nvidia/libnvidia-tls.so.185.18.31
> /usr/lib64/nvidia/libvdpau.so.185.18.31
> /usr/lib64/nvidia/libvdpau_nvidia.so.185.18.31
> /usr/lib64/nvidia/libvdpau_trace.so.185.18.31
> /usr/lib64/nvidia/tls/libnvidia-tls.so.185.18.31
> /usr/lib64/xorg/modules/extensions/nvidia/libglx.so.185.18.31

What's the result of 'rpm -qf /usr/lib64/nvidia/*'?

> 
> I never enabled rpmfusion-nonfree-updates-testing , but somebody suggested
> that I install kernel-headers and *kernel-devel* for akmod. Is this
> possibly the reason?

Doubtful.

> 
> >> If I boot with kernel 2.6.29.6-217.2.9.fc11.x86_64 and I
> >> uninstall/install
> >> kmod-nvidia, will I get version 185.18.31 ?
> >
> > Where did you get kernel 2.6.29.6-217.2.9.fc11.x86_64?
> 
> Nowhere, it's a typo. I did a uname -r and replaced the 3 by a 9 instead
> of an 8.
> 
> > Why not stick with kernel-2.6.29.6-217.2.8.fc11 ?
> 
> It certainly is my intention.

Once the modules are built for a particular kernel, they stay around for
that kernel until removed.  Once you get everything synchronized again,
everything should Just Work.

> 
> 
-- 
                Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs