I started to upgrade one Gentoo machine yesterday and found it was doing nothing for a few hours. It was stuck upgrading app-emulation/spice-0.14.0-r2. The upgrade was apparently caught in a never-ending loop while executing /usr/lib64/gstreamer-1.0/gst-plugin-scanner — I haven't noted down the whole command line but it happens shortly after or even during the package "prepare" phase. * I had to (and could) Ctrl+C to interrupt the system upgrade; * The machine was still responsive. I have since resumed the upgrade skipping "app-emulation/spice" and I cannot be 100% sure just yet but I'm pretty confident if "spice" had been scheduled to compile *after* all gstreamer plugins were upgraded, the issue would not have happened. Also I remember I ran into that issue some time ago, maybe again with that very package but certainly not that version. I might have waited till the system was upgraded then upgraded spice again. So my suggestion here is to have portage defer *any package that makes use of gst-plugin-scanner* after all gstreamer plugins have been upgraded.
The command line that loops forever is the following: /usr/lib64/gstreamer-1.0/gst-plugin-scanner -l /usr/bin/gst-inspect-1.0 It occurs during the "prepare" phase with the following output: checking for the appsrc GStreamer element... I have tried upgrading spice again to be sure, it loops again, as expected. There remains indeed gstreamer plugins to upgrade and some of them are left for the very end of the upgrade. Guess spice would have to be delayed right till the end, I don't know yet.
Yay! My suspicion was 100% correct (allow me some pride). Later during the upgrade, spice-gtk also caused the same issue. So I interrupted the system upgrade again, restarted with "emerge --resume --skipfirst" and waited. This time all remaining gst-plugin-* were to upgrade at the beginning (go figure...) So I waited till *all* gst-plugin-* packages were up-to-date and ran emerge -1 spice spice-gtk and the latter upgrade went 100% fine! So my deduction was correct, just that now spice-gtk also must follow the same rule: have portage defer app-emulation/spice and net-misc/spice-gtk upgrade *after* all gst-plugin-* packages. [Another way would be to have that gst-plugin-scanner crap fixed so as to at least crash or return an error if GST plugins are not to the expected version but that's my personal ranting, no obligation to take it into account whatsoever.]
There isn't really much we can do here from the virtualization team side. The gst-plugin-scanner issue has hit multiple packages.
(In reply to Matthias Maier from comment #3) > There isn't really much we can do here from the virtualization team side. > The gst-plugin-scanner issue has hit multiple packages. You can't do anything from the virtualization team side, I agree. But you might do something to the dependency chain like I suggested, right? (I might do that too, you'd argue, which I'd also agree.)
