spice issueshttps://gitlab.freedesktop.org/groups/spice/-/issues2019-04-04T09:12:06Zhttps://gitlab.freedesktop.org/spice/spice-gtk/-/issues/94windows 10 and QXL dod driver2019-04-04T09:12:06Zv4nRutt3nwindows 10 and QXL dod driverQEMU KVM Host
* RHEL 7.6
* Libvirtd 4.5.0
* virt-manager 1.5.0
* virt-viewer 5.0-11.el7
VM:
* Windows 10 with spice client tools
* QXL dod graphics driver version 18
When starting out troubleshooting this I thought it might be Windows...QEMU KVM Host
* RHEL 7.6
* Libvirtd 4.5.0
* virt-manager 1.5.0
* virt-viewer 5.0-11.el7
VM:
* Windows 10 with spice client tools
* QXL dod graphics driver version 18
When starting out troubleshooting this I thought it might be Windows or even in this case Excel related. But this issue seems to be related to the way the QXL driver is handeling rendering (maybe of fonts?). To confirm my hypotheses I changed the VM to use VGA instead of QXL and that worked correctly, changing it back to QXL showed me the following below.
When using viert-viewer below happens in e.g. Excel.
Using virt-viewer:
![virt-viewer](/uploads/6525bc66cd10a3d0a03f9df9018d7df7/virt-viewer.png)
Leaving the document open through virt-viewer, closing the session and opening the same desktop with the excel document still open shows everything as it should:
Using RDP to windows 10 VM with still the QXL divers used.
![rdp](/uploads/0018f9bb319404cd1c4850fbcea889a7/rdp.png)
As you can see the first character is missing. This is the XML for the host:
[windows10.xml](/uploads/619830988ef2f1fee5365ba349c100ca/windows10.xml)
And some spice debug output when working in the Excel document.
[spice-debug.txt](/uploads/61f46b670e49cd1486eff1b84e632630/spice-debug.txt)
Please let me know if you need more infohttps://gitlab.freedesktop.org/spice/spice-protocol/-/issues/5Missing structures2019-05-31T15:29:21ZGeoffrey McRaeMissing structuresThese headers are missing several critical structures, specifically:
* SpicePoint16
* SpiceMsgMainInit
* SpiceChannelID
* SpiceMsgMainChannelsList
* SpiceMsgPing
* SpiceMsgPong
* SpiceMsgSetAck
* SpiceMsgcAckSync
* SpiceMsgNotify
* Spic...These headers are missing several critical structures, specifically:
* SpicePoint16
* SpiceMsgMainInit
* SpiceChannelID
* SpiceMsgMainChannelsList
* SpiceMsgPing
* SpiceMsgPong
* SpiceMsgSetAck
* SpiceMsgcAckSync
* SpiceMsgNotify
* SpiceMsgInputsInit
* SpiceMsgInputsKeyModifiers
* SpiceMsgcInputsKeyModifiers
* SpiceMsgcKeyDown
* SpiceMsgcKeyUp
* SpiceMsgcMousePosition
* SpiceMsgcMouseMotion
* SpiceMsgcMousePress
* SpiceMsgcMouseReleasehttps://gitlab.freedesktop.org/spice/spice/-/issues/30Incorrect macro used in `test_capability`2020-02-29T10:37:53ZGeoffrey McRaeIncorrect macro used in `test_capability`It seems that the method `test_capability` @ server/red-channel.h#L78 is used both for testing the VD_AGENT capabilities AND the auth capabilities in @ server/reds.c#L2355. This is technically incorrect and could cause issues in the futu...It seems that the method `test_capability` @ server/red-channel.h#L78 is used both for testing the VD_AGENT capabilities AND the auth capabilities in @ server/reds.c#L2355. This is technically incorrect and could cause issues in the future.
I suggest a new set of macros be added to protocol.h for set/clear/test specifically for the common_caps.https://gitlab.freedesktop.org/spice/spice-gtk/-/issues/88Build fails on macos 10.14.32019-06-03T11:08:52ZJ WBuild fails on macos 10.14.3Building v0.36 source fails when compiling `vncdisplaykeymap.c` on macos 10.14.3 -- can be fixed by adding `-ObjC` to `CFLAGS` in `configure.ac`.
Reference: https://www.mail-archive.com/spice-devel@lists.freedesktop.org/msg40085.html
E...Building v0.36 source fails when compiling `vncdisplaykeymap.c` on macos 10.14.3 -- can be fixed by adding `-ObjC` to `CFLAGS` in `configure.ac`.
Reference: https://www.mail-archive.com/spice-devel@lists.freedesktop.org/msg40085.html
Error observed:
```
In file included from vncdisplaykeymap.c:95:
In file included from /usr/local/Cellar/gtk+3/3.24.5/include/gtk-3.0/gdk/gdkquartz.h:23:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/AppKit.framework/Headers/AppKit.h:10:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:8:
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSObjCRuntime.h:512:1: error: expected identifier or '('
@class NSString, Protocol;
^
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSObjCRuntime.h:514:9: error: unknown type name 'NSString'; did you mean 'GString'?
typedef NSString * NSExceptionName NS_EXTENSIBLE_STRING_ENUM;
^
/usr/local/Cellar/glib/2.58.3/include/glib-2.0/glib/gstring.h:39:33: note: 'GString' declared here
typedef struct _GString GString;
^
```
Patch applied (extra changes to `spice-deps.m4` added so I could run `autoreconf` with `autoconf` >= 2.63):
```
diff --git a/configure.ac b/configure.ac
index 2f63422..8e90314 100644
--- a/configure.ac
+++ b/configure.ac
@@ -63,6 +63,7 @@ AC_MSG_CHECKING([for native macOS])
case "$host_os" in
*darwin*)
os_mac=yes
+ CFLAGS="${CFLAGS} -ObjC"
;;
*)
os_mac=no
diff --git a/subprojects/spice-common/m4/spice-deps.m4 b/subprojects/spice-common/m4/spice-deps.m4
index 0281625..d6348b5 100644
--- a/subprojects/spice-common/m4/spice-deps.m4
+++ b/subprojects/spice-common/m4/spice-deps.m4
@@ -1,11 +1,3 @@
-# For autoconf < 2.63
-m4_ifndef([AS_VAR_APPEND],
- AC_DEFUN([AS_VAR_APPEND], $1=$$1$2))
-m4_ifndef([AS_VAR_COPY],
- [m4_define([AS_VAR_COPY],
- [AS_LITERAL_IF([$1[]$2], [$1=$$2], [eval $1=\$$2])])])
-
-
# SPICE_WARNING(warning)
# SPICE_PRINT_MESSAGES
# ----------------------
```https://gitlab.freedesktop.org/spice/spice/-/issues/29WebDAV clients can easily DoS spice server by transferring huge files2019-09-24T13:19:27ZAndreas KinzlerWebDAV clients can easily DoS spice server by transferring huge filesI am using qemu with spice 0.14.1 in a server that also uses SPICE WebDAV file transfers. We found that memory usage of qemu is exploding when you transfer large files. A colleague transfered a 4 GB file (from his machine to the VM) and ...I am using qemu with spice 0.14.1 in a server that also uses SPICE WebDAV file transfers. We found that memory usage of qemu is exploding when you transfer large files. A colleague transfered a 4 GB file (from his machine to the VM) and we immediately got an out-of-memory kernel message and process kill.
* qemu 2.10.2
* remote viewer 7.0
* phodav (webdav daemon + remote viewer embedded server): 2.2
* vdagent from this tree https://gitlab.freedesktop.org/spice/win32/vd_agent/commit/348f7ed0cd355451408b5206f8fa423d406bc440
* VM + client OS: Windows 10 1607 x64https://gitlab.freedesktop.org/spice/spice-gtk/-/issues/85do zero-copy in gstreamer for decoding2019-11-19T08:29:56ZBugzilla Migration Userdo zero-copy in gstreamer for decoding## Submitted by Victor Toso
Assigned to **Spice Bug List**
**[Link to original bug (#100097)](https://bugs.freedesktop.org/show_bug.cgi?id=100097)**
## Description
Created attachment 130109
massif on mjpeg stream
I did a quick te...## Submitted by Victor Toso
Assigned to **Spice Bug List**
**[Link to original bug (#100097)](https://bugs.freedesktop.org/show_bug.cgi?id=100097)**
## Description
Created attachment 130109
massif on mjpeg stream
I did a quick test doing streaming with mjpeg and vp8 to compare the memory usage in the client. In this test I played a ~2 min video in the guest in maximized window.
With mjpeg we have a peak of 34.13 MB which is somewhat fine.
With vp8 we got a peak of 205.6 MB, mostly around gstreamer code.
For now, I can see two ways to improve the code:
1-) Having some memory pool in spice-channel to avoid malloc for each new message. In the code itself we already have a FIXME for that, saying:
> /* FIXME: do not allow others to take ref on in, and use realloc here?
> * this would avoid malloc/free on each message?
2-) Doing zero-copy with gstreamer, like we do in server for encoding.
Attaching massif data for future reference
**Attachment 130109**, "massif on mjpeg stream":
[massif-stream-mjpeg.out](/uploads/e574c19150c67c8a15208a42668f5f0e/massif-stream-mjpeg.out)https://gitlab.freedesktop.org/spice/spice-gtk/-/issues/83Mouse cursor invisible in virt-manager on Wayland2019-02-22T11:03:34ZPeter HuttererMouse cursor invisible in virt-manager on WaylandOnce clicking into the spice-gtk widget in virt-manager, the mouse cursor becomes invisible on the whole window (not just the VM itself) - this includes the virt-manager main window if it's open. Clicking on something that triggers a new...Once clicking into the spice-gtk widget in virt-manager, the mouse cursor becomes invisible on the whole window (not just the VM itself) - this includes the virt-manager main window if it's open. Clicking on something that triggers a new cursor shape like the window bar for dragging restores the cursor.
## Reproducible:
- Wayland GNOME session (Fedora 29)
- create a new VM with just PXE boot
- click into the guest once it is started
- mouse cursor is now gone and doesn't reappear until something else sets the cursor shape
Note: it doesn't matter that the VM doesn't get past the initial boot screen
This only happens on Wayland, not Xorg.
## Symptoms
Just a list of the more confusing behaviours so they're all summed up:
- the cursor isn't visible on any of the window decoration, menu bar or even in the virt-manager main window
- the cursor isn't captured by the window
- after clicking into the window, "Press Control_L ..." shows up in the title bar. the pointer works outside the window, on the icon bar and the menu bar, but **not** on the window decoration to move the window (window close button works)
- the "Press Control_L ..." never disappears, even if I click outside the window and do other stuff
- Ctrl_L+Alt removes the titlebar label but does not make the cursor reappear. The cursor now works on the window decoration to move the window too.
## Analysis:
The issue is the GDK seat grab spice-gtk uses.
`do_pointer_grab()` issues a `gdk_seat_grab()` with the blank cursor. This immediately triggers a `grab_broken` call that is ignored, see commit 951c21d01712cd309239a94fb883e0fda1bf6a42. It also triggers a `leave_event` with `GDK_CROSSING_GRAB` which is effectively ignored because `mouse_grab_active` is true by then.
Up to here it seems mostly ok, although I think the grab-broken check should check for `implicit` being set.
When leaving the VM window `leave_event()` has `crossing->window == the grab window`. The `crossing->mode` is `GDK_MODE_NORMAL` and `mouse_grab_active` is still true. And nothing happens, we're still grabbed.
I don't see a single `gdk_seat_ungrab()` anywhere (which would restore the cursor handling).
The Ctrl+Alt combination calls `try_mouse_ungrab()` which removes the GTK grab but not the GDK seat grab.
A quick check shows that adding a `gdk_seat_ungrab()` in the leave event makes it work as expected, at the cost of the grab.
## Problem sources:
- the expectation seems to be that a grab cannot interact with anything else. Under X, *nothing* reacts once the grab is there. Under Wayland it still highlights the buttons, allows for the menus.
- under X, `try_mouse_ungrab()` is sufficient to remove the grab correctly, Wayland requires the additional `gdk_seat_ungrab()`.
cc @carlosg, because this could very well be in GTK territoriy.https://gitlab.freedesktop.org/spice/linux/vd_agent/-/issues/12Log spam for every new user session on bare metal or non-spice VMs2020-05-20T09:34:29ZWill ThompsonLog spam for every new user session on bare metal or non-spice VMsMy Endless OS (a Debian derivative) and my Fedora systems both show output like the following for every new user session:
```
Jan 16 16:06:03 gelf spice-vdagent[5804]: Cannot access vdagent virtio channel /dev/virtio-ports/com.redhat.sp...My Endless OS (a Debian derivative) and my Fedora systems both show output like the following for every new user session:
```
Jan 16 16:06:03 gelf spice-vdagent[5804]: Cannot access vdagent virtio channel /dev/virtio-ports/com.redhat.spice.0
Jan 16 16:06:03 gelf gnome-session[5525]: gnome-session-binary[5525]: WARNING: App 'spice-vdagent.desktop' exited with code 1
```
On both distros, spice-vdagent is installed by default. (I can only speak for Endless, but presumably Fedora's rationale is the same: this improves the out-of-the-box experience in a VM.)
It is sad that most systems will get one LOG_ERR level message, and one WARNING, for every new user session. Can this be made to fail more gracefully in the case where spice-vdagent is simply not needed?https://gitlab.freedesktop.org/spice/spice-common/-/issues/2test-marshallers fails on s390x2019-01-17T08:50:06ZMarc-André Lureautest-marshallers fails on s390x```
-------
3/11 spice-common / test_marshallers FAIL 1.39 s (killed by signal 6 SIGABRT)
--- command ---
/builddir/build/BUILD/spice-gtk-0.36/s390x-redhat-linux-gnu/subprojects/spice-common/tests/test_marshallers
--- stderr...```
-------
3/11 spice-common / test_marshallers FAIL 1.39 s (killed by signal 6 SIGABRT)
--- command ---
/builddir/build/BUILD/spice-gtk-0.36/s390x-redhat-linux-gnu/subprojects/spice-common/tests/test_marshallers
--- stderr ---
**
Spice:ERROR:../subprojects/spice-common/tests/test-marshallers.c:116:main: 'memcmp(data, expected_data, len) == 0' should be TRUE
```https://gitlab.freedesktop.org/spice/spice-gtk/-/issues/81Weird warning under Windows2019-01-11T19:22:24ZFrediano ZiglioWeird warning under WindowsTrying to execute remote-viewer on Windows I'm getting this warning:
(remote-viewer.exe:124): GSpice-WARNING **: 17:43:35.610: Could not create org.gnome.SessionManager dbus proxy: Unknown or unsupported transport ôunixö for address ôun...Trying to execute remote-viewer on Windows I'm getting this warning:
(remote-viewer.exe:124): GSpice-WARNING **: 17:43:35.610: Could not create org.gnome.SessionManager dbus proxy: Unknown or unsupported transport ôunixö for address ôunix:path=/run/user/25800/busö
nothing to worry but I don't think DBus on Windows is expected.v0.36https://gitlab.freedesktop.org/spice/usbredir/-/issues/9SOL_TCP and TCP_KEEPIDLE undefined on macOS2019-01-29T10:30:19ZJ WSOL_TCP and TCP_KEEPIDLE undefined on macOSBuilding usbredir on macOS 10.14.2 fails with:
```
usbredirserver.c:376:39: error: use of undeclared identifier 'SOL_TCP'
if (setsockopt(client_fd, SOL_TCP, TCP_KEEPIDLE, &optval, optlen) == -1) {
...Building usbredir on macOS 10.14.2 fails with:
```
usbredirserver.c:376:39: error: use of undeclared identifier 'SOL_TCP'
if (setsockopt(client_fd, SOL_TCP, TCP_KEEPIDLE, &optval, optlen) == -1) {
^
usbredirserver.c:376:48: error: use of undeclared identifier 'TCP_KEEPIDLE'
if (setsockopt(client_fd, SOL_TCP, TCP_KEEPIDLE, &optval, optlen) == -1) {
^
usbredirserver.c:383:39: error: use of undeclared identifier 'SOL_TCP'
if (setsockopt(client_fd, SOL_TCP, TCP_KEEPINTVL, &optval, optlen) == -1) {
^
usbredirserver.c:390:39: error: use of undeclared identifier 'SOL_TCP'
if (setsockopt(client_fd, SOL_TCP, TCP_KEEPCNT, &optval, optlen) == -1) {
^
4 errors generated.
```
Following link suggests replacing SOL_TCP --> IPPROTO_TCP and TCP_KEEPIDLE --> TCP_KEEPALIVE:
https://stackoverflow.com/questions/15860127/how-to-configure-tcp-keepalive-under-mac-os-xhttps://gitlab.freedesktop.org/spice/win32/spice-nsis/-/issues/8clipboard ownership copy-and-paste problems2018-12-02T09:40:58ZJames Harveyclipboard ownership copy-and-paste problemsOops, sorry! Somehow wound up here, and after posting the issue realized it should have been on win32/vd_agent. See [win32/vd_agent issue 6 - clipboard ownership copy-and-paste problems](https://gitlab.freedesktop.org/spice/win32/vd_ag...Oops, sorry! Somehow wound up here, and after posting the issue realized it should have been on win32/vd_agent. See [win32/vd_agent issue 6 - clipboard ownership copy-and-paste problems](https://gitlab.freedesktop.org/spice/win32/vd_agent/issues/6)https://gitlab.freedesktop.org/spice/spice-gtk/-/issues/79When I use win32,the calling convention in glib and libusb is different2018-11-29T10:32:38ZZhuXiWhen I use win32,the calling convention in glib and libusb is differentWhen I compile spicy with mingw32:
In the libusb,the calling convention is pascal(stdcall):
```
#define API_EXPORTED LIBUSB_CALL DEFAULT_VISIBILITY
#if defined(_WIN32) || defined(__CYGWIN__) || defined(_WIN32_WCE)
#define LIBUSB_CALL WI...When I compile spicy with mingw32:
In the libusb,the calling convention is pascal(stdcall):
```
#define API_EXPORTED LIBUSB_CALL DEFAULT_VISIBILITY
#if defined(_WIN32) || defined(__CYGWIN__) || defined(_WIN32_WCE)
#define LIBUSB_CALL WINAPI
#else
#define LIBUSB_CALL
#endif
#define WINAPI FAR PASCAL
#define PASCAL _pascal
```
But in the glib,the calling is cdecl:
```
// glib: gmem.h
typedef void (*GDestroyNotify) (gpointer data);
#define g_clear_pointer(pp, destroy) \
G_STMT_START { \
G_STATIC_ASSERT (sizeof *(pp) == sizeof (gpointer)); \
/* Only one access, please */ \
gpointer *_pp = (gpointer *) (pp); \
gpointer _p; \
/* This assignment is needed to avoid a gcc warning */ \
GDestroyNotify _destroy = (GDestroyNotify) (destroy); \
\
_p = *_pp; \
if (_p) \
{ \
*_pp = NULL; \
_destroy (_p); \
} \
} G_STMT_END
```
```
// spice-client: channel-usbredir.c
g_clear_pointer(&priv->device, libusb_unref_device);
```
so the stack is brokenv0.36https://gitlab.freedesktop.org/spice/win32/usbdk/-/issues/1Crash when I tried to enable usb-redirect option via virt-viewer2019-12-13T14:01:19ZTaylorSwiftRedCrash when I tried to enable usb-redirect option via virt-viewerEnviroment:
1. ovirt3.5
1. VM: win10 x86 professional
1. virt-viewer version:7.0(latest)
1. UsbDk_1.0.19_x86.msi
1. ovirt-guest-tools version: 3.5 or 4.2 or 3.6
1. guest machine:win7
It is hard to track the log when I am testing it in w...Enviroment:
1. ovirt3.5
1. VM: win10 x86 professional
1. virt-viewer version:7.0(latest)
1. UsbDk_1.0.19_x86.msi
1. ovirt-guest-tools version: 3.5 or 4.2 or 3.6
1. guest machine:win7
It is hard to track the log when I am testing it in win7,And I donnot how to check the log.Once I try to enable usb-redirect ,I will be force to quit the console.https://gitlab.freedesktop.org/spice/spice/-/issues/27Generate at least 2048bit RSA keys for testsuite2018-12-07T12:42:41ZSalvatore BonaccorsoGenerate at least 2048bit RSA keys for testsuiteHi
This issue/request is triggered by the downstream bug in Debian as https://bugs.debian.org/910634 .
With `/etc/ssl/openssl.cnf` containing
```
[system_default_sect]
MinProtocol = TLSv1.2
CipherString = DEFAULT@SECLEVEL=2
```
the `t...Hi
This issue/request is triggered by the downstream bug in Debian as https://bugs.debian.org/910634 .
With `/etc/ssl/openssl.cnf` containing
```
[system_default_sect]
MinProtocol = TLSv1.2
CipherString = DEFAULT@SECLEVEL=2
```
the `test-leaks` testscase will fail:
```
FAIL: test-leaks
================
/server/server leaks:
(./test-leaks:29600): Spice-WARNING **: 12:13:21.692: reds.c:2860:reds_init_ssl: Could not load certificates from /<<PKGBUILDDIR>>/server/tests/pki/server-cert.pem
FAIL test-leaks (exit status: 133)
```
See the detailed analysis from Bernhard Übelacker in https://bugs.debian.org/910634#12
Regards,
Salvatorehttps://gitlab.freedesktop.org/spice/spice-gtk/-/issues/78When will cairo's OpenGLES character be used?2019-01-05T08:42:28ZyueyihuaWhen will cairo's OpenGLES character be used?@all, When I Play 1080P Video, I found my client rendered picture too slow. I see cairo can support OpenGLES, when will this can be used?@all, When I Play 1080P Video, I found my client rendered picture too slow. I see cairo can support OpenGLES, when will this can be used?https://gitlab.freedesktop.org/spice/spice/-/issues/24spice compile failed on 32bit system2018-12-04T11:05:36ZSandyspice compile failed on 32bit systemDetail please check below link:
https://github.com/freedesktop/spice/pull/1Detail please check below link:
https://github.com/freedesktop/spice/pull/1https://gitlab.freedesktop.org/spice/spice-html5/-/issues/3How to use behind NAT?2019-06-03T08:07:00ZStephanHow to use behind NAT?Hi there
I'm trying to setup the spice-html5 client so that I can access a vm from basically anywhere however I do have some issues to access it from outside my home lan.
At home I have a server that also runs the VMs.
I did download ...Hi there
I'm trying to setup the spice-html5 client so that I can access a vm from basically anywhere however I do have some issues to access it from outside my home lan.
At home I have a server that also runs the VMs.
I did download the spice-html5 source and put it onto my webserver (nginx).
I did start webproxify with webproxify 5959 localhost:5900
When I fire up a DE on the server, open browser and then open spice.html, enter localhost and 5959 I can access it.
However, when I'm outside from home, I can access the spice.html as well but I can't connect to webproxify.
I'm even unsure what host I have to enter when accessing from outside. Do I need to:
- localhost?
- 127.0.0.1
- 10.0.0.10 (lan ip)
- xx.xx.xx.xx (wan ip)
- home.domain.tld (domain that points to my home lan)?
Also, which ports do I need to open - if any?
- 5959 (because webproxify listens to it?)
- 5900 (because that's the port of the spice vm?)
Is there a good guide on how to actually use the spice-html5 client from outside the NATed LAN?https://gitlab.freedesktop.org/spice/spice-common/-/issues/1test_quic test fails on BigEndian machines2018-09-10T10:46:08ZLaurent Bigonvilletest_quic test fails on BigEndian machinesHi,
It seems that test_quic fails on BigEndian machines:
```
FAIL: test_quic
===============
** (process:756): WARNING **: 07:28:10.657: bad magic
**
ERROR:test-quic.c:152:quic_decode_to_pixbuf: assertion failed: (status == QUIC_OK)...Hi,
It seems that test_quic fails on BigEndian machines:
```
FAIL: test_quic
===============
** (process:756): WARNING **: 07:28:10.657: bad magic
**
ERROR:test-quic.c:152:quic_decode_to_pixbuf: assertion failed: (status == QUIC_OK)
FAIL test_quic (exit status: 134)
```
https://buildd.debian.org/status/package.php?p=spice-gtk&suite=unstablehttps://gitlab.freedesktop.org/spice/spice-gtk/-/issues/77build-sys: meson: don't mix spice-client-glib and spice-client-gtk dependencies2019-01-02T13:43:42ZMarc-André Lureaubuild-sys: meson: don't mix spice-client-glib and spice-client-gtk dependenciesThe new meson build uses a single spice_gtk_deps with all the dependencies for both spice-client-gtk and spice-client-glib. In order to accidentally create unnecessary dependencies on client-gtk-related libraries, the build-sys should us...The new meson build uses a single spice_gtk_deps with all the dependencies for both spice-client-gtk and spice-client-glib. In order to accidentally create unnecessary dependencies on client-gtk-related libraries, the build-sys should use different set of dependencies for the libraries.v0.36Marc-André LureauMarc-André Lureau