>
> We never change 'evol' value, and this is currently causing issues with
> gcc 7.1.1: quic.c is checking at compile-time that 'evol' is 1, 3 or 5.
> This is a constant, so a static check should be good, but the compiler (gcc
> 7.1.1) is unable to know 'evol' value at compile-time. Since the rem
On Tue, Aug 01, 2017 at 09:24:42AM -0400, Frediano Ziglio wrote:
> >
> > On Tue, Aug 01, 2017 at 07:51:37AM -0400, Frediano Ziglio wrote:
> > > About the "consistently use Reviewed-by" this is already been proved
> > > to be not possible in our team. We use patchwork but we can't say we
> > > use
We never change its value, so we basically have 2 constants for the
same thing, DEFwmimax and wmimax. This commit removes the latter.
Signed-off-by: Christophe Fergeau
---
common/quic.c | 3 ---
common/quic_rgb_tmpl.c | 24
common/quic_tmpl.c | 24 +
This helps to make quic_rgb_tmpl.c and quic_tmpl.c more consistent.
Signed-off-by: Christophe Fergeau
---
common/quic_rgb_tmpl.c | 8
common/quic_tmpl.c | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/common/quic_rgb_tmpl.c b/common/quic_rgb_tmpl.c
index 15d14
We never change its value, so we basically have 2 constants for the
same thing, DEFwminext and wminext. This commit removes the latter
Signed-off-by: Christophe Fergeau
---
common/quic.c | 7 ++-
common/quic_rgb_tmpl.c | 16
common/quic_tmpl.c | 16
We never change 'evol' value, and this is currently causing issues with
gcc 7.1.1: quic.c is checking at compile-time that 'evol' is 1, 3 or 5.
This is a constant, so a static check should be good, but the compiler (gcc
7.1.1) is unable to know 'evol' value at compile-time. Since the removal
of spi
Signed-off-by: Christophe Fergeau
---
common/quic_rgb_tmpl.c | 28
common/quic_tmpl.c | 88 +-
2 files changed, 58 insertions(+), 58 deletions(-)
diff --git a/common/quic_rgb_tmpl.c b/common/quic_rgb_tmpl.c
index f3d07a5..15d14
DEFevol is known at compile-time, so we can use SPICE_VERIFY to check
its value.
Signed-off-by: Christophe Fergeau
---
common/quic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/quic.c b/common/quic.c
index 049a5cd..8567368 100644
--- a/common/quic.c
+++ b/common/qu
- Original Message -
> From: Victor Toso
>
> spice_vmc_input_stream_co_data() is called with the payload of
> message ($data) and this buffer size ($size).
>
> The client of this demux reads each parameter using
> spice_vmc_input_stream_read_all_async() by passing the size of the
> mes
- Original Message -
> From: Victor Toso
>
> The channel can be reset after disabling the shared-folder. If we had
> pending read, we should cancel it using the GCancellable for the
> demuxing code on vmcstream.c (c->cancellable) and per client operation
> (client->cancellable) which is
>
> On Tue, Aug 01, 2017 at 07:51:37AM -0400, Frediano Ziglio wrote:
> > About the "consistently use Reviewed-by" this is already been proved
> > to be not possible in our team. We use patchwork but we can't say we
> > use consistently these replies, lot of the times they came in different
> > for
From: Victor Toso
The channel can be reset after disabling the shared-folder. If we had
pending read, we should cancel it using the GCancellable for the
demuxing code on vmcstream.c (c->cancellable) and per client operation
(client->cancellable) which is done on client_remove_unref() called by
g_
From: Victor Toso
spice_vmc_input_stream_co_data() is called with the payload of
message ($data) and this buffer size ($size).
The client of this demux reads each parameter using
spice_vmc_input_stream_read_all_async() by passing the size of the
message that it wants which is stored in self->cou
Hi,
On Tue, Aug 01, 2017 at 08:00:11AM -0400, Frediano Ziglio wrote:
> >
> > Hi,
> >
> > On Tue, Aug 01, 2017 at 06:31:16AM -0400, Frediano Ziglio wrote:
> > > > Subject: [Spice-devel] [spice-gtk v1] Bump glib 2.36 -> 2.46
> > >
> > > I would add "requirement" to the subject.
> >
> > "build-sy
On Tue, Aug 01, 2017 at 12:43:36PM +0200, Victor Toso wrote:
> Hi,
>
> On Tue, Aug 01, 2017 at 06:31:16AM -0400, Frediano Ziglio wrote:
> > > Subject: [Spice-devel] [spice-gtk v1] Bump glib 2.36 -> 2.46
> >
> > I would add "requirement" to the subject.
>
> "build-sys: bump glib 2.36 -> 2.46" wor
On Tue, Aug 01, 2017 at 07:51:37AM -0400, Frediano Ziglio wrote:
> About the "consistently use Reviewed-by" this is already been proved
> to be not possible in our team. We use patchwork but we can't say we
> use consistently these replies, lot of the times they came in different
> format.
I'm nev
>
> Hi,
>
> On Tue, Aug 01, 2017 at 06:31:16AM -0400, Frediano Ziglio wrote:
> > > Subject: [Spice-devel] [spice-gtk v1] Bump glib 2.36 -> 2.46
> >
> > I would add "requirement" to the subject.
>
> "build-sys: bump glib 2.36 -> 2.46" works as well?
>
Maybe is just me, just that seems you are
>
> Hey,
>
> On Thu, Jul 27, 2017 at 11:08:06AM -0400, Frediano Ziglio wrote:
> > Try to sum up the initial problem was patches/series tracking
> >
> > 2) similar to patchwork with additional feature but missing
> >the state tracking part. Maybe would be not hard to add;
> >
> > Maybe would
Hi,
On Tue, Aug 01, 2017 at 06:31:16AM -0400, Frediano Ziglio wrote:
> > Subject: [Spice-devel] [spice-gtk v1] Bump glib 2.36 -> 2.46
>
> I would add "requirement" to the subject.
"build-sys: bump glib 2.36 -> 2.46" works as well?
>
> >
> > From: Victor Toso
> >
> > At the moment:
> > - Fed
> Subject: [Spice-devel] [spice-gtk v1] Bump glib 2.36 -> 2.46
I would add "requirement" to the subject.
>
> From: Victor Toso
>
> At the moment:
> - Fedora 26 has 2.52
> - Fedora 25 has 2.50
> - Fedora 24 has 2.48
> - CentOS 7 has 2.46
> - Debian 9 has 2.50
>
What about RHEL ? Do we support
Hi,
On Tue, Aug 01, 2017 at 11:16:27AM +0100, marcandre.lur...@redhat.com wrote:
> From: Marc-André Lureau
>
> The spice-controller was a small library to let NPAPI browser plugins
> communicate with the spice client. Due to usage of vala, the library
> could not promise ABI stability, and was a
>
> On Mon, Jul 31, 2017 at 09:57:41AM +0200, Christophe de Dinechin wrote:
> > > What is a difference between a personal branch and a branch at the
> > > offical repo?
> >
> > Visibility. Having an implicit way to share not just the diffs (the way
> > patches do)
> > but the actual branch. There
Hi
- Original Message -
> From: Victor Toso
>
> At the moment:
> - Fedora 26 has 2.52
> - Fedora 25 has 2.50
> - Fedora 24 has 2.48
> - CentOS 7 has 2.46
> - Debian 9 has 2.50
>
> Signed-off-by: Victor Toso
Not a big deal, but probably ok too.
so ack
> ---
> configure.ac | 4
From: Marc-André Lureau
The spice-controller was a small library to let NPAPI browser plugins
communicate with the spice client. Due to usage of vala, the library
could not promise ABI stability, and was also considerer a pretty
poor implementation.
Furthermore, major browser vendors began to ph
From: Victor Toso
At the moment:
- Fedora 26 has 2.52
- Fedora 25 has 2.50
- Fedora 24 has 2.48
- CentOS 7 has 2.46
- Debian 9 has 2.50
Signed-off-by: Victor Toso
---
configure.ac | 4 ++--
src/spice-pulse.c | 20
tests/uri.c | 5 -
3 files changed, 2 inse
25 matches
Mail list logo
