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 __________________________________________________