Hi Stephan and all,
Thus far we have found three packages with these bad scripts.
ibus-gtk, librsvg2, and libwmf
I will push them out tonight, or tomorrow in a mini update.
Troy
Stephan Wiesand wrote:
> Hi Troy, Frank,
>
> ok, now I see the error when installing librsvg2. I can also confirm that it doesn't have this problem on a genuine TUVEL6. This is not a complaint - after all, it's still called alpha.
>
> After some more tests, everything else still looks ok, disregarding the missing perl-sys-virt.
>
> The only other problem I found is that virt-install and virt-manager fail to autodetect SL5/6 and TUVEL6 and hence don't choose the virtio devices by default. But that's not SL-Specific, and could be due to something missing in my installation trees.
>
> NB does anyone have a short writeup how to get started with SPICE on EL6? This would be next on my list of things to test.
>
> - Stephan
>
> On Dec 27, 2010, at 23:29 , Troy Dawson wrote:
>
>> Hi Frank,
>> Thanks for pointing that out.
>> We had gone through the rpm's and made sure that none of the *files* had koji-linux-gnu in them, but we didn't check the scripts. We're tweaking the checking script right now.
>> Troy
>>
>> Frank Schluenzen wrote:
>>> Hi,
>>> I _guess_, the problem is due to an unfortunate mixture of gdk-pixbuf paths. In the first alpha-release gtk2 would expect gdk-pixbuf loaders in /etc/gtk-2.0/[i386|x86_64]-koji-linux-gnu/gdk-pixbuf.loaders. the current release uses /etc/gtk-2.0/x86_64-redhat-linux-gnu/gdk-pixbuf.loaders (makes sense), but librsvg2 still uses the koji-path:
>>> rpm -qp librsvg2-2.26.0-5.el6.x86_64.rpm --scripts
>>> /usr/bin/update-gdk-pixbuf-loaders x86_64-koji-linux-gnu || :
>>> It's just a guess, but I could imagine it confusing gtk sufficiently not to recognize svg's ...
>>> Regards, Frank.
>>> Stephan Wiesand wrote:
>>>> Hi Troy,
>>>>
>>>> On Dec 27, 2010, at 19:20 , Troy Dawson wrote:
>>>>
>>>>> Stephan Wiesand wrote:
>>>>>> I'm trying the virtualization stuff now, and it works fine, but I can't start virt-manager. When I try, a window pops up saying "Error starting Virtual Machine Manager: Couldn't recognize the image file format for file '/usr/share/virt-manager/pixmaps/virt-manager-icon.svg'".
>>>>>> And the "Details" button reveals:
>>>>>> Traceback (most recent call last):
>>>>>> File "/usr/share/virt-manager/virt-manager.py", line 413, in <module>
>>>>>> main()
>>>>>> File "/usr/share/virt-manager/virt-manager.py", line 344, in main
>>>>>> appname + "-icon.svg")
>>>>>> GError: Couldn't recognize the image file format for file '/usr/share/virt-manager/pixmaps/virt-manager-icon.svg'
>>>>>> Is this working for others? Any idea what I may be missing (some hidden dependency?) or what could be the problem?
>>>>>> Thanks,
>>>>>> Stephan
>>>>> Hi Stephan,
>>>>> I haven't had a chance to install and test this, but I came upon this article today.
>>>>>
>>>>> http://bderzhavets.wordpress.com/2010/12/23/set-up-kvm-on-scientific-linux-6-server-alpha-3/
>>>>>
>>>>> From the article it says
>>>>> "
>>>>> To be able to start virt-manager run as root to re-create the ‘gdk-pixbuf.loaders’ file :-
>>>>>
>>>>> /usr/bin/gdk-pixbuf-query-loaders-64 > /etc/gtk-2.0/x86_64-redhat-linux-gnu/gdk-pixbuf.loaders
>>>> this makes it work, thanks a lot. I figure it's probably a matter of installation order. And I seem to remember it's not the first time the gdk-pixbuf stuff is causing this kind of problem :-(
>>>>
>>>> Maybe someone should tell them that rpm now has triggers :->
>>>>
>>>> Except for this problem, virtualization works well. I successfully installed SL6 xen paravirt VMs (64- and 32-bit) on an SL5 xen host (64-bit), SL6 VMs on an SL6 KVM host (64/64), and SL5.5 VMs on an SL6 KVM host (also 64/64), using virt-install and raw LVM volumes on direct attached storage as the backend. I haven't compared the performance to Xen yet, but it works without problems.
>>>>
>>>> Thanks again,
>>>> Stephan
>>>>
>>>>> or just comment out lines 343,344 in /usr/share/virt-manager/virt-manager.py to allow virt-manager to start .
>>>>> "
>>>>> I haven't tested this, but they were getting the same errors you were getting.
>>>>>
>>>>> Troy
>>
>> --
>> __________________________________________________
>> Troy Dawson [log in to unmask] (630)840-6468
>> Fermilab ComputingDivision/SCF/FEF/SLSMS Group
>> __________________________________________________
>
--
__________________________________________________
Troy Dawson [log in to unmask] (630)840-6468
Fermilab ComputingDivision/SCF/FEF/SLSMS Group
__________________________________________________
|
