>
> For some reason, newer versions of gcc (e.g. 7.1.1 in fedora 26) print
> a warning about format truncation even when using snprintf:
>
> CC usbredirparser.lo
> ../../usbredirparser/usbredirparser.c: In function ‘usbredirparser_do_read’:
> ../../usbredirparser/usbredirparser.c:270:33:
On Thu, Jul 13, 2017 at 5:33 AM, Victor Toso wrote:
> From: Victor Toso
>
> This patch fixes the avdec_h264 element not being present on
> gstvideo_has_codec() which get all decoder elements from GstRegistry
> and filter them on our GstCaps in order to get the ones for given
> codec.
>
> The issu
Hi
On Thu, Jul 13, 2017 at 2:51 PM Pavel Grunt wrote:
>
> On Thu, 2017-07-13 at 14:33 +0200, Victor Toso wrote:
> > From: Victor Toso
> >
> > This patch fixes the avdec_h264 element not being present on
> > gstvideo_has_codec() which get all decoder elements from GstRegistry
> > and filter them
For some reason, newer versions of gcc (e.g. 7.1.1 in fedora 26) print
a warning about format truncation even when using snprintf:
CC usbredirparser.lo
../../usbredirparser/usbredirparser.c: In function ‘usbredirparser_do_read’:
../../usbredirparser/usbredirparser.c:270:33: error: ‘%s’ di
>
> >
> > On Fri, 2017-07-28 at 12:44 +0100, Frediano Ziglio wrote:
> > > Recent GitLab CI jobs are failing to run valgrind checks
> > > (like https://gitlab.com/spice/spice/-/jobs/25220999).
> > >
> > > This as recent distro changes cause valgrind not to find some
> > > symbols required to dete
>
> - Original Message -
> > >
> > > Hi
> > >
> > > - Original Message -
> > >
> > > > If you are worried about more effort for PRs considering the solution
> > > > 2 could be an option. If patchew is able to create an "item" (actually
> > > > I think they call them just "series
On Fri, 2017-07-28 at 09:15 +0200, Christophe de Dinechin wrote:
> >
> > How you really mean "git submodules".. Eh, what's the point? Sounds
> > very wrong and useless to me, it will be constantly outdated..
> > Write a script instead?
>
> What I really mean is something like this: https://gitlab
>
> On Fri, 2017-07-28 at 12:44 +0100, Frediano Ziglio wrote:
> > Recent GitLab CI jobs are failing to run valgrind checks
> > (like https://gitlab.com/spice/spice/-/jobs/25220999).
> >
> > This as recent distro changes cause valgrind not to find some
> > symbols required to detect some GLib supp
On Fri, Jul 28, 2017 at 12:44:57PM +0100, Frediano Ziglio wrote:
> Recent GitLab CI jobs are failing to run valgrind checks
> (like https://gitlab.com/spice/spice/-/jobs/25220999).
>
> This as recent distro changes cause valgrind not to find some
> symbols required to detect some GLib suppression
On Fri, 2017-07-28 at 12:44 +0100, Frediano Ziglio wrote:
> Recent GitLab CI jobs are failing to run valgrind checks
> (like https://gitlab.com/spice/spice/-/jobs/25220999).
>
> This as recent distro changes cause valgrind not to find some
> symbols required to detect some GLib suppression errors.
Recent GitLab CI jobs are failing to run valgrind checks
(like https://gitlab.com/spice/spice/-/jobs/25220999).
This as recent distro changes cause valgrind not to find some
symbols required to detect some GLib suppression errors.
Adding debugging information for GLib solve the problem.
Signed-o
- Original Message -
> >
> > Hi
> >
> > - Original Message -
> >
> > > If you are worried about more effort for PRs considering the solution
> > > 2 could be an option. If patchew is able to create an "item" (actually
> > > I think they call them just "series") and you are able
>
> Hi
>
> - Original Message -
>
> > If you are worried about more effort for PRs considering the solution
> > 2 could be an option. If patchew is able to create an "item" (actually
> > I think they call them just "series") and you are able to see the
> > merge status and change it if n
Hi
- Original Message -
> If you are worried about more effort for PRs considering the solution
> 2 could be an option. If patchew is able to create an "item" (actually
> I think they call them just "series") and you are able to see the
> merge status and change it if needed you hardly wi
> > On 28 Jul 2017, at 10:23, Frediano Ziglio < fzig...@redhat.com > wrote:
>
> > > > On 27 Jul 2017, at 17:08, Frediano Ziglio < fzig...@redhat.com > wrote:
> > >
> >
>
> > > > Try to sum up the initial problem was patches/series tracking
> > >
> >
>
> > > > So far there are 3 proposal
On Fri, 28 Jul 2017 09:15:46 +0200
Christophe de Dinechin wrote:
> > On 27 Jul 2017, at 17:07, Marc-André Lureau
> > wrote:
> >
> > - Create top-level repository with all others repositories as
> > submodules (if we use 'spice-server', that one would be called
> > 'spice') *
> >
> > Isn't thi
Hi
- Original Message -
> From: Christophe de Dinechin
>
> By default, subdmodules will be checked out in detached state.
> This means that you may lose some work in progress.
Lose is a bit strong here.
If you have uncommitted changes, submodule update will fail.
If it's committed, it
Hi,
On Fri, 2017-07-28 at 09:15 +0200, Christophe de Dinechin wrote:
> > On 27 Jul 2017, at 17:07, Marc-André Lureau
> > wrote:
> >
> > Hi
> >
> > - Original Message -
> > > > I think we should rather find a consensus on the mailing list rather
> > > > than
> > > > avoiding the discussi
On Fri, Jul 28, 2017 at 09:56:24AM +0100, Frediano Ziglio wrote:
> Signed-off-by: Frediano Ziglio
> ---
> README | 3 +++
> 1 file changed, 3 insertions(+)
>
> Changes since v1:
> - remove CELT (obsoleted);
> - use 1.0 version for Opus.
>
> diff --git a/README b/README
> index cb64b74d..293c858
From: Christophe de Dinechin
By default, subdmodules will be checked out in detached state.
This means that you may lose some work in progress.
Using the --merge option will also ensure that if there
are conflicts between your current submodule and the
version referenced by the parent, you get a
> On 28 Jul 2017, at 10:23, Frediano Ziglio wrote:
>
>>>
>>> On 27 Jul 2017, at 17:08, Frediano Ziglio wrote:
>>>
>>> Try to sum up the initial problem was patches/series tracking
>>>
>>> So far there are 3 proposal
>>> 1) PR/MR (GitLab/GitHub style)
>>> 2) patchew
>>> 3a) shared git reposit
Signed-off-by: Frediano Ziglio
---
README | 3 +++
1 file changed, 3 insertions(+)
Changes since v1:
- remove CELT (obsoleted);
- use 1.0 version for Opus.
diff --git a/README b/README
index cb64b74d..293c8588 100644
--- a/README
+++ b/README
@@ -38,6 +38,9 @@ functionality
Cyrus-SASL
> On 28 Jul 2017, at 10:17, Christophe Fergeau wrote:
>
> On Fri, Jul 28, 2017 at 09:30:18AM +0200, Christophe de Dinechin wrote:
>>>
For example, a lot of the streaming work requires a branched-off
spice-protocol.
I was also wondering about protocol updates being ea
On Thu, Jul 27, 2017 at 01:51:52PM -0500, Jonathon Jongsma wrote:
> On Thu, 2017-07-27 at 14:25 +0100, Frediano Ziglio wrote:
> > Maybe other dependencies should be reviewed too.
> > Like SASL not mandatory or GE Gui (what is it?), OpenGL, Xorg.
>
>
> Mmm, it looks like that was supposed to be "C
Acked-by: Christophe Fergeau series, some comments
in patch 6/6
On Fri, Jul 28, 2017 at 07:48:18AM +0100, Frediano Ziglio wrote:
> Signed-off-by: Frediano Ziglio
> ---
> README | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/README b/README
> index 45fbe89c..0fd6f071
On Fri, Jul 28, 2017 at 07:48:23AM +0100, Frediano Ziglio wrote:
> Signed-off-by: Frediano Ziglio
> ---
> README | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/README b/README
> index cb64b74d..65e0231b 100644
> --- a/README
> +++ b/README
> @@ -38,6 +38,10 @@ functionality
>
>
On Thu, Jul 27, 2017 at 05:14:53PM +0200, Christophe de Dinechin wrote:
> - Should I make ‘recorder’ an independent module like spice-protocol?
> But if so, how do I sync it with the code using it?
You can make it a shared library that modules needing its functionality
are going to link with. This
>
> > On 27 Jul 2017, at 17:08, Frediano Ziglio wrote:
> >
> > Try to sum up the initial problem was patches/series tracking
> >
> > So far there are 3 proposal
> > 1) PR/MR (GitLab/GitHub style)
> > 2) patchew
> > 3a) shared git repository
> > 3b) links to external git repositories
> >
> > 1)
On Fri, Jul 28, 2017 at 09:30:18AM +0200, Christophe de Dinechin wrote:
> >
> >>
> >> For example, a lot of the streaming work requires a branched-off
> >> spice-protocol.
> >>
> >> I was also wondering about protocol updates being easier to do in a
> >> consistent way if spice-protocol was “ab
> On 27 Jul 2017, at 17:08, Frediano Ziglio wrote:
>
> Try to sum up the initial problem was patches/series tracking
>
> So far there are 3 proposal
> 1) PR/MR (GitLab/GitHub style)
> 2) patchew
> 3a) shared git repository
> 3b) links to external git repositories
>
> 1) PR surely can trace the
> On 27 Jul 2017, at 15:53, Christophe Fergeau wrote:
>
> On Thu, Jul 27, 2017 at 03:00:27PM +0200, Christophe de Dinechin wrote:
>> No, that’s not correct (at least for me). The review itself can happen over
>> mail,
>> what I find inefficient is:
>>
>> a) to get the list of things to review,
> On 27 Jul 2017, at 17:35, Frediano Ziglio wrote:
>
>>
>>
>>> On 27 Jul 2017, at 17:00, Victor Toso wrote:
>>>
>>> Hi,
>>>
>>> On Thu, Jul 27, 2017 at 04:28:59PM +0200, Christophe de Dinechin wrote:
> On 27 Jul 2017, at 16:04, Christophe Fergeau wrote:
>
> On Thu, Jul 2
>
> On Sat, Jul 22, 2017 at 04:25:59AM -0400, Frediano Ziglio wrote:
> > >
> > > 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 my compiler (gcc 7.1.1)
> > > is unable to know 'evol' value at compile-time. Since the rem
> On 27 Jul 2017, at 17:06, Christophe Fergeau wrote:
>
> On Thu, Jul 27, 2017 at 04:28:59PM +0200, Christophe de Dinechin wrote:
>>
>>> On 27 Jul 2017, at 16:04, Christophe Fergeau wrote:
>>>
>>> On Thu, Jul 27, 2017 at 03:29:11PM +0200, Christophe de Dinechin wrote:
> On 27 Jul 20
> On 27 Jul 2017, at 17:07, Marc-André Lureau
> wrote:
>
> Hi
>
> - Original Message -
>>> I think we should rather find a consensus on the mailing list rather than
>>> avoiding the discussion.
>>
>> “Avoiding the discussion" sounds like a cheap and unjustified shot. Please
>> discuss
35 matches
Mail list logo
