Week plan:
- Explore Mesa configuration to get virgl working in guest when building from
sources
- Investigate if the bug is fixed, if not, bisect and attempt a fix
- Resume my efforts on Spice for Mac, VNC is just a bit painful
Results:
- Built Mesa from source in virgl configuration
- Bisected
> On 2 Mar 2017, at 10:37, Pavel Grunt wrote:
>
> On Thu, 2017-03-02 at 10:31 +0100, Christophe de Dinechin wrote:
>>> On 2 Mar 2017, at 09:56, Pavel Grunt wrote:
>>>
>>> Theoretically a VM name can be a valid VM id or uuid. In that case
>>> connec
> On 1 Mar 2017, at 22:36, Jonathon Jongsma wrote:
>
> On Fri, 2017-02-24 at 15:57 +0100, Pavel Grunt wrote:
>> Theoretically a VM name can be a valid VM id or uuid. In that case
>> connecting to the VMs may be problematic since virt-viewer selects
>> the VM by its id then by uuid if not found t
> On 2 Mar 2017, at 09:56, Pavel Grunt wrote:
>
> Theoretically a VM name can be a valid VM id or uuid. In that case
> connecting to the VMs may be problematic since virt-viewer selects
> the VM by its id then by uuid if not found then by its name.
>
> Introduce new command line options to cove
> On 10 Feb 2017, at 15:50, Pavel Grunt wrote:
>
> On Thu, 2017-02-09 at 18:46 +0100, Christophe de Dinechin wrote:
>> I tend to agree. I don’t see how any legitimate GError * (from
>> g_error_new or the like) would have a NULL message. So this is
>> really defe
10:40 -0600, Jonathon Jongsma wrote:
>> Out of curiosity, what was the situation where you encountered a non-
>> NULL error with a NULL error->message? It doesn't seem like this
>> should
>> be necessary.
>>
>> Jonathon
>>
>>
>>
>>
>> If the message is NULL, we should still display something like
>> “unknown error”. If we think it’s worth testing for error->message
>> != NULL, then I suggest another patch just for that, that fixes all
>> places and not just this one.
> I agree
Separate patch sent.
>> BTW, I did not fin
---
src/ovirt-foreign-menu.c | 14 +++---
src/remote-viewer.c| 22 --
src/virt-viewer-app.c | 14 +++---
src/virt-viewer-file-transfer-dialog.c | 2 +-
src/virt-viewer-file.c | 6 +++---
src/v
When running 'remote-viewer' without arguments,
and selecting a non-supported protocol, e.g. ssh://foo,
the generated error was silently swallowed by the retry loop.
This was introduced in 06b2c382468876a19600374bd59475e66d488af8.
---
src/remote-viewer.c | 3 +++
1 file changed, 3 insertions(+)
d
Thanks for the comments.
> On 9 Feb 2017, at 11:23, Pavel Grunt wrote:
>
> Hello Christophe,
>
> On Wed, 2017-02-08 at 17:48 +0100, Christophe de Dinechin wrote:
>> When running 'remote-viewer' without arguments,
>> and selecting a non-supported protocol, e
> On 8 Feb 2017, at 20:34, Eduardo Lima (Etrunko) wrote:
>
> Patch looks good, I personally also like to check for error->message
> before dereferencing it, but I don't really know what others think about it.
I had wondered about that, but I checked, and apparently, all other places that
look
When running 'remote-viewer' without arguments,
and selecting a non-supported protocol, e.g. ssh://foo,
the generated error was silently swallowed by the retry loop.
This was introduced in 06b2c382468876a19600374bd59475e66d488af8.
---
src/remote-viewer.c | 3 +++
1 file changed, 3 insertions(+)
d
12 matches
Mail list logo
