Wednesday, July 5, 2017

Keep trying to connect spicy to turbo. The second window does not open. I reproduced with master, so it's not my changes. I also have the problem connecting from my Linux machines, e.g. shuttle and muse. The same symptom appears. So the problem is on Turbo.

I guess I must have broken something when I tried to reboot f25-turbo in virgl mode. I had saved the configuration and restored it, but maybe there is some magic that libvirt does behind my back when I restore a guest.

Manually checked:

• The graphics / monitors configuration
• The configuration of the NVIDIA card. Probably OK, since I see the output on the screen.

There is a message stating that it is connecting to the port, so I guess this is not a firewall issue this time:

port 0x7fca76054a60 com.redhat.stream.0: opened

I don't remember seeing this message before, but I guess it was just lost in the stream?

Uri sent me a copy of his logs. He does have messages indicating that a display-2:1 channel is opened:

(remote-viewer:29461): GSpice-DEBUG: channel-display-gst.c:297 GStreamer pipeline: appsrc name=src is-live=true format=time max-bytes=0 block=true caps=video/x-vp8 ! vp8dec ! videoconvert ! appsink name=sink caps=video/x-raw,format=BGRx sync=false drop=false
(remote-viewer:29461): GSpice-DEBUG: channel-display-gst.c:297 GStreamer pipeline: appsrc name=src is-live=true format=time max-bytes=0 block=true  ! h264parse ! avdec_h264 ! videoconvert ! appsink name=sink caps=video/x-raw,format=BGRx sync=false drop=false
(remote-viewer:29461): GSpice-DEBUG: spice-channel.c:137 display-2:0: spice_channel_constructed
(remote-viewer:29461): GSpice-DEBUG: spice-channel.c:137 cursor-4:0: spice_channel_constructed
(remote-viewer:29461): GSpice-DEBUG: channel-display-gst.c:297 GStreamer pipeline: appsrc name=src is-live=true format=time max-bytes=0 block=true caps=image/jpeg ! jpegdec ! videoconvert ! appsink name=sink caps=video/x-raw,format=BGRx sync=false drop=false
(remote-viewer:29461): GSpice-DEBUG: channel-display-gst.c:297 GStreamer pipeline: appsrc name=src is-live=true format=time max-bytes=0 block=true caps=video/x-vp8 ! vp8dec ! videoconvert ! appsink name=sink caps=video/x-raw,format=BGRx sync=false drop=false
(remote-viewer:29461): GSpice-DEBUG: channel-display-gst.c:297 GStreamer pipeline: appsrc name=src is-live=true format=time max-bytes=0 block=true  ! h264parse ! avdec_h264 ! videoconvert ! appsink name=sink caps=video/x-raw,format=BGRx sync=false drop=false
(remote-viewer:29461): GSpice-DEBUG: spice-channel.c:137 display-2:1: spice_channel_constructed
(remote-viewer:29461): GSpice-DEBUG: spice-channel.c:137 inputs-3:0: spice_channel_constructed
(remote-viewer:29461): GSpice-DEBUG: spice-gtk-session.c:200 inputs-3:0: client_modifiers:0x2, guest_modifiers:0x0

I don't have the same thing on my side.

Finally figured out the problem was that something restored the original libspice-server.so.1 behind my back:

ddd@turbo[nvidia] spice> md5sum /usr/lib64/libspice-server.*
86a48403264c7b91e5b284e2d9e77f58  /usr/lib64/libspice-server.la
ce3e95ec9a8fecd5cd11d76d03833d7a  /usr/lib64/libspice-server.so
453165b9830d75d5fe8c4036139a4b7c  /usr/lib64/libspice-server.so.1
ce3e95ec9a8fecd5cd11d76d03833d7a  /usr/lib64/libspice-server.so.1.12.1
453165b9830d75d5fe8c4036139a4b7c  /usr/lib64/libspice-server.so.1.12.1.orig

The md5sum shows that it is pointing to the 1.12.1.orig instead of the one I built, 1.12.1. Fixing the link makes spicy work again. Once I explained on the mailing list, it looks like this is a known issue that dnf automatically "fixes" things for you. Great!

My quick and dirty recorder-build of spicy now works as well as the original. There is no problem as long as I use the recorder logging mechanism. Logging through glib is more tricky, because of all the filtering that happens at this level.