Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 671252 - app-emulation/spice-0.14.0-r2 waits forever running gst-plugin-scanner if some gst plugins remain to be upgraded
Summary: app-emulation/spice-0.14.0-r2 waits forever running gst-plugin-scanner if som...
Status: RESOLVED CANTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Virtualization Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-11-16 09:48 UTC by Vince C.
Modified: 2020-06-12 21:39 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vince C. 2018-11-16 09:48:45 UTC
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.
Comment 1 Vince C. 2018-11-16 10:11:18 UTC
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.
Comment 2 Vince C. 2018-11-16 11:06:30 UTC
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.]
Comment 3 Matthias Maier gentoo-dev 2020-03-14 20:52:31 UTC
There isn't really much we can do here from the virtualization team side. The gst-plugin-scanner issue has hit multiple packages.
Comment 4 Vince C. 2020-06-12 21:39:53 UTC
(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.)