Re: [virt-tools-list] how do virt-viewer show the usb device name

[Daniel P. Berrange]

On Mon, Dec 11, 2017 at 05:08:12PM +0800, 嬴政 wrote:
> Hi,
>I am in the trouble.
>virt-viewer6.0.msi  can show the usb device info
>compile the virt-viewer6.0 with souce code by myself, it can not show usb 
> device info right. just " Usb Device " "Usb Device"
>I found the code that have no the win32 "spice_usbutil_get_sysfs_attribute"
>so , I'm curious about what code you're using， such as  which version 
> spice-gtk？

The MSI for version 6.0  was built using Fedora 26 mingw toolchain. So
check the version(s) of the various mingw32-x RPMs in Fedora 26
repos to see what we used.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] virt-manager running on python3

[Daniel P. Berrange]

On Thu, Dec 07, 2017 at 09:00:30AM -0700, Charles Arnold wrote:
> There has been some recent work done for python3 support in virt-manager.
> Are there plans to move virt-manager entirely to python3?
> There is more work that could be done for this conversion if we want to 
> completely
> move virt-manager to run on python3 and I would be happy to contribute to that
> effort if there is interest. 
> In making these changes do we need to keep python2 compatibility?

Python3 is clearly the future, but I think its probably wise to keep dual
py2/3 support for a little while longer, if only to make backports to
current enterprise distros easier.  Definitely contribute patches to port
more stuff to dual py2/3 code if you have the time.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [virt-bootstrap] [PATCH 1/3] utils: Add is_installed function

[Daniel P. Berrange]

On Tue, Nov 21, 2017 at 11:37:37AM +0100, Cedric Bosdonnat wrote:
> On Wed, 2017-11-01 at 00:19 +, Radostin Stoyanov wrote:
> > Add utility function to check whether an executable is available in
> > the PATH env variable.
> > ---
> >  src/virtBootstrap/utils.py | 10 ++
> >  1 file changed, 10 insertions(+)
> > 
> > diff --git a/src/virtBootstrap/utils.py b/src/virtBootstrap/utils.py
> > index 84d1629..2bd7873 100644
> > --- a/src/virtBootstrap/utils.py
> > +++ b/src/virtBootstrap/utils.py
> > @@ -32,6 +32,7 @@ import subprocess
> >  import sys
> >  import tempfile
> >  import logging
> > +from distutils.spawn import find_executable
> >  
> 
> What annoys me with this approach is that it will add a runtime dependency
> on distutils. as virtBootstrap is not meant to run on a non-linux platform
> couldn't we just call the 'which' tool to do the job?

The 'find_executable' method is pretty trivial. Just split $PATH on
the value of os.pathsep, and then just check each component to see
if it contains the file. Trivial to implement locally without any
fuss, and better than spawning external tools for something so simple


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Status of virt-viewer headerbar conversion ?

[Daniel P. Berrange]

On Fri, Nov 17, 2017 at 01:44:13PM -0200, Eduardo Lima (Etrunko) wrote:
> On 17/11/17 11:45, Daniel P. Berrange wrote:
> > A while ago now we had patches going through review that switched over to
> > use Gtk HeaderBar concept. I was wondering what the status of that is, as
> > I think it would be a nice step forward for virt-viewer UI.
> >
> 
> As far as I remember, the idea was to support both client and server
> side decorations. It would be required to do something like
> GtkAboutDialog does to detect if it should display the HeaderBar or not.
> 
> My opinion is that it would require too much work to keep two different
> versions of the UI, and basically I did not went down that path, and
> kept that branch dormant for a while until the subject was raised once
> again.

So looking at the Sagar's patch the largest portion of the patch diff
is converting all the menubar signal handlers into GAction callbacks.
What's interesting is that this is actually completely tangential to
the GtkHeaderbar work. By which I mean you can use GAction callbacks
with menubars too.

If the code to convert over to GAction was done separately from the
conversion to use GtkHeaderbar, this would have been much more obvious.

Bearing this in mind, I think it is not too hard to preserve the use of
the menubar for when CSD isn't available. The only real burden is in
the .ui file which would keep the original menubar definition, but
conect action names instead, and something to choose which to show
at startup.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

[virt-tools-list] Status of virt-viewer headerbar conversion ?

[Daniel P. Berrange]

A while ago now we had patches going through review that switched over to
use Gtk HeaderBar concept. I was wondering what the status of that is, as
I think it would be a nice step forward for virt-viewer UI.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] virt-viewer 6.0 download problems

[Daniel P. Berrange]

On Thu, Nov 02, 2017 at 02:50:08PM +, Daniel P. Berrange wrote:
> On Tue, Oct 31, 2017 at 05:48:10PM +0100, Eduardo Lima (Etrunko) wrote:
> > On 31/10/17 17:32, Wow Zaza wrote:
> > > Thank you for the replies. I was able to download using Firefox. I tried
> > > using Chrome, Edge, and Internet Explorer. None of them worked. Although
> > > my problem is solved, could it be a compilation issue on your end? Only
> > > one of the major browser is able to download this file; I am sure a lot
> > > of people trying to download are having issues.
> > 
> > 
> > I don't think it has anything to do with how the package is build, but
> > maybe an issue with the web server not setting the correct mime-type? I
> > am just shooting in the dark here, not sure how this should work.
> 
> It looks like this is a problem in pagure.io setup. It is not serving any
> Content-Type header at all for .msi files.

Reported at  https://pagure.io/pagure/issue/2736


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] virt-viewer 6.0 download problems

[Daniel P. Berrange]

On Tue, Oct 31, 2017 at 05:48:10PM +0100, Eduardo Lima (Etrunko) wrote:
> On 31/10/17 17:32, Wow Zaza wrote:
> > Thank you for the replies. I was able to download using Firefox. I tried
> > using Chrome, Edge, and Internet Explorer. None of them worked. Although
> > my problem is solved, could it be a compilation issue on your end? Only
> > one of the major browser is able to download this file; I am sure a lot
> > of people trying to download are having issues.
> 
> 
> I don't think it has anything to do with how the package is build, but
> maybe an issue with the web server not setting the correct mime-type? I
> am just shooting in the dark here, not sure how this should work.

It looks like this is a problem in pagure.io setup. It is not serving any
Content-Type header at all for .msi files.

They've also set "X-Content-Type-Options: nosniff" header which disables
automatic mime-type sniffing by the browser

Different browseres honour nosniff in different ways, hence the difference
between firefox & chrome, the latter appears stricter.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] virt-viewer 6.0 download problems

[Daniel P. Berrange]

On Mon, Oct 30, 2017 at 08:27:46PM +, Wow Zaza wrote:
> I want to bring to your attention that the virt-viewer 6.0 (x86 and x64)
> download aren't currently accessible via the download link. When you
> click on the download link, all you see is gibberish. Can you please
> look into it?

It works just fine when I try it.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [virt-viewer] doc: Adjust reference to spice-gtk man page

[Daniel P. Berrange]

On Fri, Sep 22, 2017 at 11:10:10AM +0200, Christophe Fergeau wrote:
> On Thu, Sep 21, 2017 at 05:56:21PM +0200, Pavel Grunt wrote:
> > 
> >  Yup, that was also my feeling when finding the doc-only spice-gtk
> >  package :)
> > 
> >I agree, is it in Fedora? el7 has just spice-gtk3 rpm
> >Pavel
> 
> Yes, Fedora which still has
> %files
> %doc AUTHORS
> %doc COPYING
> %doc README
> %doc NEWS
> %{_mandir}/man1/spice-client.1*
> 
> In el7, these files have been moved to the spice-gtk package.
> Imo, at least COPYING would fit better in spice-glib as this is the
> lower-level package, and I prefer to have the license installed
> on all systems using one of the packages generated from spice-gtk source
> rpm.

Yes for Fedora packaging compliance it in fact must be in spice-glib, or
in every sub-RPM - having it in spice-gtk which never gets pulled in by
any deps is non-compliant packaging.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [virt-viewer] doc: Adjust reference to spice-gtk man page

[Daniel P. Berrange]

On Thu, Sep 21, 2017 at 10:16:56AM +0200, Christophe Fergeau wrote:
> The man page spice-gtk ships is named "spice-client", not "spice-gtk"
> 
> Signed-off-by: Christophe Fergeau <cferg...@redhat.com>
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1477966
> ---
>  man/virt-viewer.pod | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/man/virt-viewer.pod b/man/virt-viewer.pod
> index 8463eb4..9ea5fb8 100644
> --- a/man/virt-viewer.pod
> +++ b/man/virt-viewer.pod
> @@ -223,6 +223,6 @@ to the extent permitted by law.
>  
>  =head1 SEE ALSO
>  
> -C<virsh(1)>, C<virt-manager(1)>, C<spice-gtk(1)>, the project website 
> C<http://virt-manager.org>
> +C<virsh(1)>, C<virt-manager(1)>, C<spice-client(1)>, the project website 
> C<http://virt-manager.org>

I was wondering what man page this is until I found it was in the
spice-gtk RPM, not spice-gtk3.  The spice-gtk RPM seems entirely
pointless to me - it used to contain the GTK2 build but thats now
gone - can we just put the man page in spice-gtk3 RPM and kill
the spice-gtk RPM entirely

Anyway

Reviewed-by: Daniel P. Berrange <berra...@redhat.com>

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Time for a new virt-viewer release ?

[Daniel P. Berrange]

On Mon, Jul 10, 2017 at 10:34:27AM -0400, Marc-André Lureau wrote:
> Hi
> 
> - Original Message -
> > On 07/07/17 09:15, Daniel P. Berrange wrote:
> > > Our last release was in Nov last year and there's a bunch of accumulated
> > > patches. It would also be desirable to include the fix for libvirt on
> > > Windows which should make virt-viewer work properly again.
> > > 
> > 
> > ACK with it, at least from my side, there is nothing left pending.
> 
> If you do a Windows build, please wait for spice-gtk release. I think
> we can make it this week, as soon as fedora 26 is out might be the
> earliest.

Is it ok to make a release now, and if so, which spice-gtk / mingw-spice-gtk
versions should I make sure I have ?  Is F26 updates sufficient now ?


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH 2/2] remote-viewer: remove --spice-controller

[Daniel P. Berrange]

On Fri, Jul 28, 2017 at 08:43:45PM +0200, marcandre.lur...@redhat.com wrote:
> From: Marc-André Lureau 
> 
> spice controller interface is being removed from spice-gtk.

Is this fallout from napi browser plugins being killed by firefox/chrome/etc ?

Since i was planning on doing a release real soon, should we perhaps just
add a deprecation message on startup right now, and then once I've done
the release we merge this removal, so users have a little warning. Or has
the code already been killed by spice-gtk ?


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH virt-viewer] Don't set LC_ALL=C during build as that breaks python apps

[Daniel P. Berrange]

On Thu, Jul 27, 2017 at 04:00:53PM +0100, Richard W.M. Jones wrote:
> On Tue, Jul 25, 2017 at 01:48:41PM +0100, Daniel P. Berrange wrote:
> > Setting LC_ALL=C breaks python apps doing I/O on UTF-8 source
> > files. In particular this broke glib-mkenums
> > 
> > Traceback (most recent call last):
> >   File "/usr/bin/glib-mkenums", line 669, in 
> > process_file(fname)
> >   File "/usr/bin/glib-mkenums", line 406, in process_file
> > line = curfile.readline()
> >   File "/usr/lib64/python3.6/encodings/ascii.py", line 26, in decode
> > return codecs.ascii_decode(input, self.errors)[0]
> > UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 
> > 849: ordinal not in range(128)
> > 
> > Signed-off-by: Daniel P. Berrange <berra...@redhat.com>
> > ---
> > 
> > Pushed to fix rawhide build
> > 
> >  maint.mk | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/maint.mk b/maint.mk
> > index 79104d0..2e70cae 100644
> > --- a/maint.mk
> > +++ b/maint.mk
> > @@ -117,8 +117,8 @@ news-check-lines-spec ?= 1,10
> >  news-check-regexp ?= '^\*.* $(VERSION_REGEXP) \($(today)\)'
> >  
> >  # Prevent programs like 'sort' from considering distinct strings to be 
> > equal.
> > -# Doing it here saves us from having to set LC_ALL elsewhere in this file.
> > -export LC_ALL = C
> > +# Doing it here saves us from having to set LC_COLLATE elsewhere in this 
> > file.
> > +export LC_COLLATE = C
> 
> I don't know what the answer is, but two observations:
> 
> (1) We had the same problem in libguestfs and this was our fix:
> 
> https://github.com/libguestfs/libguestfs/commit/f861c138550a0c99247a6955aa2c594f380867f4

Hmm, unsetting LC_ALL means the output of the script is potentially affected
by differing sort ordering of the user's locale, which is why i kept setting
LC_COLLATE.


It seems that a better approach would be to use C.UTF-8, and then fallback
to en_US.UTF-8 on systems which lack it, since en_US is still pretty close
to C in its semantics, while supporting UTF-8 everywhere. eg change maint.mk
to be

 export LC_ALL = $(shell LC_ALL=C.utf-8 locale -ck charmap 2>/dev/null | \
 grep -i UTF-8 1>/dev/null 2>&1 && \
 echo "C.UTF-8"  || echo "en_US.UTF-8")
 

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH virt-viewer] Don't set LC_ALL=C during build as that breaks python apps

[Daniel P. Berrange]

On Tue, Jul 25, 2017 at 07:58:52AM -0500, Eric Blake wrote:
> On 07/25/2017 07:48 AM, Daniel P. Berrange wrote:
> > Setting LC_ALL=C breaks python apps doing I/O on UTF-8 source
> > files. In particular this broke glib-mkenums
> > 
> > Traceback (most recent call last):
> >   File "/usr/bin/glib-mkenums", line 669, in 
> > process_file(fname)
> >   File "/usr/bin/glib-mkenums", line 406, in process_file
> > line = curfile.readline()
> >   File "/usr/lib64/python3.6/encodings/ascii.py", line 26, in decode
> > return codecs.ascii_decode(input, self.errors)[0]
> > UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 
> > 849: ordinal not in range(128)
> 
> Eww. Are we sure that's not a bug in python?  LC_ALL=C is supposed to be
> 8-bit clean (every byte is a character, you can never get an encoding
> error), and a superset of 7-bit ascii.  The failure makes is sound like
> python is incorrectly treating LC_ALL=C as requesting only 7-bit ascii
> instead of full 8-bit cleanness.

IIUC, whether its 8-bit clean or not is not the problem - even if it is
8-bit clean, it will not enable UTF-8 support so python defaults to the
ascii charset, instead of utf-8 causing the failures seen above.

> > +++ b/maint.mk
> > @@ -117,8 +117,8 @@ news-check-lines-spec ?= 1,10
> >  news-check-regexp ?= '^\*.* $(VERSION_REGEXP) \($(today)\)'
> >  
> >  # Prevent programs like 'sort' from considering distinct strings to be 
> > equal.
> > -# Doing it here saves us from having to set LC_ALL elsewhere in this file.
> > -export LC_ALL = C
> > +# Doing it here saves us from having to set LC_COLLATE elsewhere in this 
> > file.
> > +export LC_COLLATE = C
> 
> This makes the build non-deterministic on platforms that have exported
> LC_ALL.

NB it is already non-deterministic because 'maint.mk' is only ever used
if you run 'make' from the top-level. So if youre in a sub-dir and run
make you never see this setting and thus everything "works" (that made
debugging this a total nightmare).


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

[virt-tools-list] [PATCH virt-viewer] Don't set LC_ALL=C during build as that breaks python apps

[Daniel P. Berrange]

Setting LC_ALL=C breaks python apps doing I/O on UTF-8 source
files. In particular this broke glib-mkenums

Traceback (most recent call last):
  File "/usr/bin/glib-mkenums", line 669, in 
process_file(fname)
  File "/usr/bin/glib-mkenums", line 406, in process_file
line = curfile.readline()
  File "/usr/lib64/python3.6/encodings/ascii.py", line 26, in decode
return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 849: 
ordinal not in range(128)

Signed-off-by: Daniel P. Berrange <berra...@redhat.com>
---

Pushed to fix rawhide build

 maint.mk | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/maint.mk b/maint.mk
index 79104d0..2e70cae 100644
--- a/maint.mk
+++ b/maint.mk
@@ -117,8 +117,8 @@ news-check-lines-spec ?= 1,10
 news-check-regexp ?= '^\*.* $(VERSION_REGEXP) \($(today)\)'
 
 # Prevent programs like 'sort' from considering distinct strings to be equal.
-# Doing it here saves us from having to set LC_ALL elsewhere in this file.
-export LC_ALL = C
+# Doing it here saves us from having to set LC_COLLATE elsewhere in this file.
+export LC_COLLATE = C
 
 ## --- ##
 ## Sanity checks.  ##
-- 
2.13.3

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

[virt-tools-list] [PATCH virt-what v2] Update to detect QEMU via 'TCGTCGTCGTCG' CPUID

[Daniel P. Berrange]

QEMU >= 2.10 will start reporting the string "TCGTCGTCGTCG"
for CPUID queries when running under TCG only (KVM signature
is unchanged)

Signed-off-by: Daniel P. Berrange <berra...@redhat.com>
---

Changed in v2:

 - Rebase to git master

 virt-what.in | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/virt-what.in b/virt-what.in
index 5cf2136..5f9edd7 100644
--- a/virt-what.in
+++ b/virt-what.in
@@ -275,6 +275,9 @@ fi
 if ! "$skip_qemu_kvm"; then
 if [ "$cpuid" = "KVMKVMKVM" ]; then
 echo kvm
+elif [ "$cpuid" = "TCGTCGTCGTCG" ]; then
+echo qemu
+skip_lkvm=true
 elif echo "$dmi" | grep -q 'Product Name: KVM'; then
 echo kvm
 skip_lkvm=true
@@ -297,10 +300,10 @@ if ! "$skip_qemu_kvm"; then
 echo kvm
 skip_lkvm=true
 else
-# XXX This is known to fail for qemu with the explicit -cpu
+# This is known to fail for qemu with the explicit -cpu
 # option, since /proc/cpuinfo will not contain the QEMU
-# string.  The long term fix for this would be to export
-# another CPUID leaf for non-accelerated qemu.
+# string. QEMU 2.10 added a new CPUID leaf, so this
+# problem only triggered for older QEMU
 if grep -q 'QEMU' "${root}/proc/cpuinfo"; then
 echo qemu
 fi
-- 
2.13.0

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

[virt-tools-list] [PATCH virt-what] Update to detect QEMU via 'TCGTCGTCGTCG' CPUID

[Daniel P. Berrange]

QEMU >= 2.10 will start reporting the string "TCGTCGTCGTCG"
for CPUID queries when running under TCG only (KVM signature
is unchanged)

Signed-off-by: Daniel P. Berrange <berra...@redhat.com>
---
 virt-what.in | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/virt-what.in b/virt-what.in
index 1a373ed..4770d46 100644
--- a/virt-what.in
+++ b/virt-what.in
@@ -272,6 +272,9 @@ fi
 if ! "$skip_qemu_kvm"; then
 if [ "$cpuid" = "KVMKVMKVM" ]; then
 echo kvm
+elif [ "$cpuid" = "TCGTCGTCGTCG" ]; then
+echo qemu
+skip_lkvm=true
 elif echo "$dmi" | grep -q 'Product Name: KVM'; then
 echo kvm
 skip_lkvm=true
@@ -289,10 +292,10 @@ if ! "$skip_qemu_kvm"; then
 skip_lkvm=true
 fi
 else
-# XXX This is known to fail for qemu with the explicit -cpu
+# This is known to fail for qemu with the explicit -cpu
 # option, since /proc/cpuinfo will not contain the QEMU
-# string.  The long term fix for this would be to export
-# another CPUID leaf for non-accelerated qemu.
+# string. QEMU 2.10 added a new CPUID leaf, so this
+# problem only triggered for older QEMU
 if grep -q 'QEMU' "${root}/proc/cpuinfo"; then
 echo qemu
 fi
-- 
2.13.0

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Time for a new virt-viewer release ?

[Daniel P. Berrange]

On Mon, Jul 10, 2017 at 10:34:27AM -0400, Marc-André Lureau wrote:
> Hi
> 
> - Original Message -
> > On 07/07/17 09:15, Daniel P. Berrange wrote:
> > > Our last release was in Nov last year and there's a bunch of accumulated
> > > patches. It would also be desirable to include the fix for libvirt on
> > > Windows which should make virt-viewer work properly again.
> > > 
> > 
> > ACK with it, at least from my side, there is nothing left pending.
> 
> If you do a Windows build, please wait for spice-gtk release. I think we
> can make it this week, as soon as fedora 26 is out might be the earliest.

I would intend to do builds at same time as the release, using F26 repos.
I can wait for you to get new spice-gtk into F26 though - as long as it
is in updates-testing at least, I can pull it in for build.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Time for a new virt-viewer release ?

[Daniel P. Berrange]

On Fri, Jul 07, 2017 at 01:15:40PM +0100, Daniel P. Berrange wrote:
> Our last release was in Nov last year and there's a bunch of accumulated
> patches. It would also be desirable to include the fix for libvirt on
> Windows which should make virt-viewer work properly again.

Oh I meant to say, I would intend to use Fedora 26 for building the MSI
installers


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

[virt-tools-list] Time for a new virt-viewer release ?

[Daniel P. Berrange]

Our last release was in Nov last year and there's a bunch of accumulated
patches. It would also be desirable to include the fix for libvirt on
Windows which should make virt-viewer work properly again.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] virt-what patch to support Logical Domains (LDoms) on Linux SPARC

[Daniel P. Berrange]

On Thu, May 25, 2017 at 09:26:51AM +0100, Darren Kenny wrote:
> Hi,
> 
> I've not seen any comments on this patch, is there anything
> that I need to do/change?

I'm copying Richard Jones on the patch, since he maintains virt-what
and must have not seen the mail yet.

> Darren Kenny wrote:
> > Hi,
> > 
> > I have a patch to add support for Logical Domains (LDoms) virtualization
> > on SPARC chipsets running Oracle Linux for SPARC.
> > 
> > At the moment Oracle Linux for SPARC is the only variant that support
> > LDoms, but it is hoped will change in the future.
> > 
> > The virt-what tool seems to be a very useful way to identify the running
> > virtualization technology, and for anyone that requires it, we would
> > like to be able to also identify most of the various LDoms domain types
> > that can be done in a script.
> > 
> > Attached is the patch that provides this support, outputting one or more
> > of the strings:
> > 
> > ldoms
> > ldoms-control
> > ldoms-root
> > ldoms-io
> > 
> > I would like to get this applied upstream to the virt-what sources if
> > that is at all possible.
> > 
> > Thanks,
> > 
> > Darren.
> > 
> > PS - Please respond off-list to me, since I'm not currently subscribed.
> 
> ___
> virt-tools-list mailing list
> virt-tools-list@redhat.com
> https://www.redhat.com/mailman/listinfo/virt-tools-list

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH virt-viewer v2] virt-viewer: Ensure to not close during migration

[Daniel P. Berrange]

On Thu, May 18, 2017 at 11:59:18AM +0200, Pavel Grunt wrote:
> Take a look at the shutdown event detail before killing
> the connection. Otherwise it breaks the SPICE seamless migration
> feature.
> 
> Regression since commit a62827d28c6b69e90102e4c1c8043cbddad8929a
> 
> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1442929
> Signed-off-by: Pavel Grunt 
> ---
>  src/virt-viewer.c | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/src/virt-viewer.c b/src/virt-viewer.c
> index 3b96534..5c321db 100644
> --- a/src/virt-viewer.c
> +++ b/src/virt-viewer.c
> @@ -52,6 +52,10 @@
>  #include "virt-viewer-auth.h"
>  #include "virt-viewer-util.h"
>  
> +#ifdef HAVE_SPICE_GTK
> +#include "virt-viewer-session-spice.h"
> +#endif
> +
>  struct _VirtViewerPrivate {
>  char *uri;
>  virConnectPtr conn;
> @@ -737,6 +741,13 @@ virt_viewer_domain_event(virConnectPtr conn 
> G_GNUC_UNUSED,
>  switch (event) {
>  case VIR_DOMAIN_EVENT_STOPPED:
>  session = virt_viewer_app_get_session(app);
> +#ifdef HAVE_SPICE_GTK
> +/* do not disconnect due to migration */
> +if (detail == VIR_DOMAIN_EVENT_STOPPED_MIGRATED &&
> +VIRT_VIEWER_IS_SESSION_SPICE(session)) {
> +break;
> +}
> +#endif
>  if (session != NULL)
>  virt_viewer_session_close(session);
>  break;

ACK

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH virt-viewer] virt-viewer: Ensure to not close during migration

[Daniel P. Berrange]

On Thu, May 18, 2017 at 11:30:04AM +0200, Pavel Grunt wrote:
> Take a look at the shutdown event detail before killing
> the connection.
> 
> Regression since commit a62827d28c6b69e90102e4c1c8043cbddad8929a
> 
> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1442929
> Signed-off-by: Pavel Grunt 
> ---
>  src/virt-viewer.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/src/virt-viewer.c b/src/virt-viewer.c
> index 3b96534..4a4570f 100644
> --- a/src/virt-viewer.c
> +++ b/src/virt-viewer.c
> @@ -721,7 +721,7 @@ static int
>  virt_viewer_domain_event(virConnectPtr conn G_GNUC_UNUSED,
>   virDomainPtr dom,
>   int event,
> - int detail G_GNUC_UNUSED,
> + int detail,
>   void *opaque)
>  {
>  VirtViewer *self = opaque;
> @@ -736,6 +736,10 @@ virt_viewer_domain_event(virConnectPtr conn 
> G_GNUC_UNUSED,
>  
>  switch (event) {
>  case VIR_DOMAIN_EVENT_STOPPED:
> +/* do not disconnect due to migration */
> +if (detail == VIR_DOMAIN_EVENT_STOPPED_MIGRATED) {
> +break;
> +}

Only SPICE does seemless migration, so this surely needs to be conditional,

NB, we rely on the domain events to exit promptly when using SSH tunnelling,
because the SSH tunnel does not go away when the remote VNC/SPICE closes
the connection. So we can't just rely on VNC conenction terminating to make
us exit.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] what is virt-viewer intended to be ?

[Daniel P. Berrange]

On Thu, May 11, 2017 at 03:03:12PM +0200, Lentes, Bernd wrote:
> Hi,
> 
> sorry for asking a simple question, but i'm confused. What is virt-viewer
> intended to be ?
> To connect directly to virtual machine consoles, e.g. with VNC ?
> Or connect to libvirtd which runs e.g. on a remote linux host ?
> Or both ?

Both. the 'virt-viewer' binary connects to libvirtd (local or remote) and
looks up the VNC / SPICE console address for the guest, and then connects
to that.  The 'remote-viewer' binary connects directly to the VNC or SPICE
address you give it, avoiding libvirtd.

> 
> If i'm able to connect to libvirtd on a remote host, what can i do ? I
> think the functionality of virt-viewer is limited compared to virt-manager.
> This page (https://libvirt.org/windows.html) gaves me the impression
> that i can connect with virt-viewer to a libvirtd on a remote host.

Yes, it will work

> I tried to connect to a libvirtd on a linux host host using virt-viewer
> and the following in the adress bar: qemu+tcp://192.168.100.10 and
L> qemu+tcp://192.168.100.1016509, but didn't succeed.
> The port 16509 on the linux host is opened in the firewall and libvirtd
> is listening on it.

The URIs are malformed - you're missing the path component. eg

  qemu+tcp://192.168.100.10/system

FYI, you can test using 'virsh -c URI' - if virsh succeeds, virt-viewer
would too.


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [virt-viewer] spec: Use https:// for Source/URL fields

[Daniel P. Berrange]

On Tue, May 09, 2017 at 05:47:59PM +0200, Christophe Fergeau wrote:
> The mingw-virt-viewer.spec/virt-viewer.spec file are currently using a
> mix of http and ftp for their URLs. ftp://virt-manager.org has never
> existed. This commit switches to use https:// everywhere.
> 
> Signed-off-by: Christophe Fergeau <cferg...@redhat.com>
> ---
>  mingw-virt-viewer.spec.in | 4 ++--
>  virt-viewer.spec.in   | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)

Reviewed-by: Daniel P. Berrange <berra...@redhat.com>


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] virt-manager language

[Daniel P. Berrange]

On Tue, May 09, 2017 at 05:42:39PM +0200, jean-philippe constantin wrote:
> Hello,
> My Debian Jessie OS is in french and virt-manager also. Is it possible to
> install the english version on a french OS ?

There is no separate installation required. You just need to set an
environment variable when starting virt-manager e.g.

 $ LANG=en_US virt-manager

or equivalently use LANG=C

the same env variable should work for any translated application

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Easier container creation

[Daniel P. Berrange]

On Mon, Apr 24, 2017 at 09:15:43AM -0500, Eric Blake wrote:
> On 04/22/2017 11:39 AM, Stoyanov, Radostin wrote:
> 
> > 
> > I would like to ask for feedback on the UI which is shown in the attached 
> > screen recording.
> 
> Please don't EVER do that again.  Attaching a 5M screen recording to a
> mailing list multiplies your 5M by the list subscription count,
> resulting in a HUGE load on the mailserver. Instead, post a URL to your
> recording, hosted on some other web site, so that only interested
> parties need download it.

To be fair, the mailing list should have rejected the email before it
hit the list. It seems we had mistakenly configured the size limit
value, thinking it was bytes, where as it should have been KB. So we
had the limit set at ~256 MB instead of 256 KB.  I've put the size
limit back down to 300 KB now, which matches libvirt list limits

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH virt-viewer] configure: Check for all libvirt dependencies

[Daniel P. Berrange]

On Mon, Apr 24, 2017 at 10:09:24AM +0200, Christophe Fergeau wrote:
> On Mon, Apr 24, 2017 at 09:42:43AM +0200, Pavel Grunt wrote:
> > Build with libvirt only when libvirt-glib is present
> 
> There is already such a check right after the part you modified:
> 
> AS_IF([test "x$with_libvirt" != "xno" && test "x$with_libvirt" != "xyes"],
>   [PKG_CHECK_EXISTS([libvirt >= $LIBVIRT_REQUIRED],
> [with_libvirt=yes], [with_libvirt=no])])
> 
> AS_IF([test "x$with_libvirt" = "xyes"],
>   [PKG_CHECK_MODULES(LIBVIRT, [libvirt >= $LIBVIRT_REQUIRED] 
> [libvirt-glib-1.0 >= $LIBVIRT_GLIB_REQUI
>   [AC_DEFINE([HAVE_LIBVIRT], 1, [Have libvirt?])]
> )
> AM_CONDITIONAL([HAVE_LIBVIRT], [test "x$with_libvirt" = "xyes"])
> 
> The check you modified is when we autodetect libvirt presence rather than
> having an explicit --with[out]-libvirt.
> In such a situation, we expect libvirt support to be silently enabled/disabled
> depending on what is installed. This fails when libvirt is detected, but
> libvirt-glib is missing/too old. In this situation, without your change,
> configure would error out when we expect it to just disable libvirt support.
> Your patch should fix this case, and disable libvirt support in this 
> situation.
> 
> If my understanding is correct,
> Acked-by: Christophe Fergeau 
> with a more detailed commit log.

NACK, to this. It is crazy to have us calling pkg-config twice for the same
modules. It should be possible to rewrite this to remove the duplicated check
entirely 


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] virt-bootstrap proposal

[Daniel P. Berrange]

On Wed, Mar 15, 2017 at 07:24:13PM -0400, Cole Robinson wrote:
> Sorry for the delayed response. Just looked now.
> 
> On 03/09/2017 05:09 AM, Cedric Bosdonnat wrote:
> > Hi all,
> > 
> > Those following libvirt's mailing already saw a similar thread started 
> > there.
> > I have worked on a virt-bootstrap tool to make it easy to instanciate
> > container root file system out of docker images (and possible other 
> > sources).
> > 
> > You'll see a wrap up blog post explaining the workflow here:
> > 
> > http://bosdonnat.fr/system-container-images.html
> > 
> > Daniel suggested to have the virt-bootstrap code (or whatever the final name
> > could be) along with virt-install and virt-manager.
> 
> Besides being written in python and being virt related this doesn't have much
> overlap with virt-manager.git code. All current command line tools are largely
> concerned with manipulating/generating libvirt XML, and looks like
> virt-bootstrap won't ever do that? So for example it will have a completely
> orthogonal test suite. That's my initial impression anyways

Oh, I didn't look at the code, but I thought it was doing all the XML generation
too. ie populate the chroot and configure the libvirt guest in the same manner
that virt-install would do, and would hence benefit from sharing code.

> Right now the tool is basically just a wrapper around skopeo; besides handling
> virt-builder images, what else do you foresee the tool handling? Different
> formats, example command line arguments, etc. Just trying to get a sense of
> how much bigger the tool will get.

I'd expect it to be able to do bootstrapping of yum / dpkg into chroots at
some point.


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [virt-manager PATCH v3] domain: add support to rename domain with nvram vars file

[Daniel P. Berrange]

On Wed, Mar 08, 2017 at 09:59:57AM +0100, Pavel Hrdina wrote:
> Libvirt storage API doesn't support renaming storage volumes so
> we need to copy the nvram file and remove the old one.

We really ought to add a virStorageVolRename API - I'm surprised we did
not already have it :-) At least file an RFE so we track it.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH virt-viewer 1/2] virt-viewer: Allow more precise VM selection

[Daniel P. Berrange]

On Thu, Mar 02, 2017 at 08:40:23AM -0600, Jonathon Jongsma wrote:
> On Thu, 2017-03-02 at 10:36 +0100, Christophe de Dinechin wrote:
> > > 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 then by its name.
> > > > 
> > > > Introduce new command line options to cover this situation:
> > > >  "--domain-name" to connect to the VM by its name
> > > >  "--id" to connect to the VM by its id
> > > >  "--uuid" to connect to the VM by its uuid
> > > > The options are mutually exclusive
> > > > 
> > > > Resolves: rhbz#1399077
> > > > ---
> > > >  man/virt-viewer.pod | 14 
> > > >  src/virt-viewer.c   | 97
> > > > +++--
> > > >  2 files changed, 101 insertions(+), 10 deletions(-)
> > > > 
> > > > diff --git a/man/virt-viewer.pod b/man/virt-viewer.pod
> > > > index 9abf03c..30af8db 100644
> > > > --- a/man/virt-viewer.pod
> > > > +++ b/man/virt-viewer.pod
> > > > @@ -122,6 +122,20 @@ kiosk-quit option to "on-disconnect" value,
> > > > virt-viewer will quit
> > > >  instead. Please note that --reconnect takes precedence over this
> > > >  option, and will attempt to do a reconnection before it quits.
> > > >  
> > > > +=item --id, --uuid, --domain-name
> > > > +
> > > > +Connect to the virtual machine by its id, uuid or name. These
> > > > options
> > > > +are mutual exclusive. For example the following command may
> > > > sometimes
> > > > +connect to a virtual machine with the id 2 or with the name 2
> > > > (depending
> > > > +on the number of running machines):
> > > > +
> > > > +virt-viewer 2
> > > > +
> > > > +To always connect to the virtual machine with the name "2" use
> > > > the
> > > > +"--domain-name" option:
> > > > +
> > > > +virt-viewer --domain-name 2
> > > > +
> > > >  =back
> > > >  
> > > >  =head1 CONFIGURATION
> > > > diff --git a/src/virt-viewer.c b/src/virt-viewer.c
> > > > index 1f99552..6bc9b6d 100644
> > > > --- a/src/virt-viewer.c
> > > > +++ b/src/virt-viewer.c
> > > > @@ -82,6 +82,46 @@ static gboolean opt_attach = FALSE;
> > > >  static gboolean opt_waitvm = FALSE;
> > > >  static gboolean opt_reconnect = FALSE;
> > > >  
> > > > +typedef enum {
> > > > +DOMAIN_SELECTION_NONE,
> > > > +DOMAIN_SELECTION_NAME,
> > > > +DOMAIN_SELECTION_ID,
> > > > +DOMAIN_SELECTION_UUID,
> > > > +} DomainSelection;
> > > > +
> > > > +static const gchar* domain_selection_to_opt[] = {
> > > > +[DOMAIN_SELECTION_NONE] = NULL,
> > > > +[DOMAIN_SELECTION_NAME] = "--domain-name",
> > > > +[DOMAIN_SELECTION_ID] = "--id",
> > > > +[DOMAIN_SELECTION_UUID] = "--uuid",
> > > > +};
> > > > +
> > > > +static DomainSelection domain_selection_type =
> > > > DOMAIN_SELECTION_NONE;
> > > > +
> > > > +static gboolean
> > > > +opt_domain_selection_cb(const gchar *option_name,
> > > > +const gchar *value G_GNUC_UNUSED,
> > > > +gpointer data G_GNUC_UNUSED,
> > > > +GError **error)
> > > > +{
> > > > +guint i;
> > > > +if (domain_selection_type != DOMAIN_SELECTION_NONE) {
> > > > +g_set_error(error, G_OPTION_ERROR,
> > > > G_OPTION_ERROR_FAILED,
> > > > +"selection type has been already set");
> > > > +return FALSE;
> > > > +}
> > > > +
> > > > +for (i = DOMAIN_SELECTION_NAME; i <=
> > > > G_N_ELEMENTS(domain_selection_to_opt); i++) {
> > > > +if (g_strcmp0(option_name, domain_selection_to_opt[i])
> > > > == 0)
> > > > {
> > > > +domain_selection_type = i;
> > > > +return TRUE;
> > > > +}
> > > > +}
> > > > +
> > > > +g_assert_not_reached();
> > > > +return FALSE;
> > > > +}
> > > > +
> > > >  static void
> > > >  virt_viewer_add_option_entries(VirtViewerApp *self,
> > > > GOptionContext
> > > > *context, GOptionGroup *group)
> > > >  {
> > > > @@ -96,6 +136,12 @@ virt_viewer_add_option_entries(VirtViewerApp
> > > > *self, GOptionContext *context, GOp
> > > >    N_("Wait for domain to start"), NULL },
> > > >  { "reconnect", 'r', 0, G_OPTION_ARG_NONE,
> > > > _reconnect,
> > > >    N_("Reconnect to domain upon restart"), NULL },
> > > > +{ "domain-name", '\0', G_OPTION_FLAG_NO_ARG,
> > > > G_OPTION_ARG_CALLBACK, opt_domain_selection_cb,
> > > > +  N_("Select the virtual machine only by its name"),
> > > > NULL },
> > > > +{ "id", '\0', G_OPTION_FLAG_NO_ARG,
> > > > G_OPTION_ARG_CALLBACK,
> > > > opt_domain_selection_cb,
> > > > +  N_("Select the virtual machine only by its id"), NULL
> > > > },
> > > > +{ "uuid", '\0', G_OPTION_FLAG_NO_ARG,
> > > > G_OPTION_ARG_CALLBACK,
> > > > 

Re: [virt-tools-list] [PATCH virt-viewer 1/2] virt-viewer: Allow more precise VM selection

[Daniel P. Berrange]

On Fri, Feb 24, 2017 at 03:57:23PM +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 then by its name.
> 
> Introduce new command line options to cover this situation:
>  "--domain-name" to connect to the VM by its name
>  "--id" to connect to the VM by its id
>  "--uuid" to connect to the VM by its uuid
> The options are mutually exclusive
> 
> Resolves: rhbz#1399077
> ---
>  man/virt-viewer.pod | 14 
>  src/virt-viewer.c   | 97 
> +++--
>  2 files changed, 101 insertions(+), 10 deletions(-)
> 
> diff --git a/man/virt-viewer.pod b/man/virt-viewer.pod
> index 9abf03c..30af8db 100644
> --- a/man/virt-viewer.pod
> +++ b/man/virt-viewer.pod
> @@ -122,6 +122,20 @@ kiosk-quit option to "on-disconnect" value, virt-viewer 
> will quit
>  instead. Please note that --reconnect takes precedence over this
>  option, and will attempt to do a reconnection before it quits.
>  
> +=item --id, --uuid, --domain-name
> +
> +Connect to the virtual machine by its id, uuid or name. These options
> +are mutual exclusive. For example the following command may sometimes
> +connect to a virtual machine with the id 2 or with the name 2 (depending
> +on the number of running machines):
> +
> +virt-viewer 2
> +
> +To always connect to the virtual machine with the name "2" use the
> +"--domain-name" option:
> +
> +virt-viewer --domain-name 2
> +
>  =back
>  
>  =head1 CONFIGURATION
> diff --git a/src/virt-viewer.c b/src/virt-viewer.c
> index 1f99552..6bc9b6d 100644
> --- a/src/virt-viewer.c
> +++ b/src/virt-viewer.c
> @@ -82,6 +82,46 @@ static gboolean opt_attach = FALSE;
>  static gboolean opt_waitvm = FALSE;
>  static gboolean opt_reconnect = FALSE;
> 
> +typedef enum {
> +DOMAIN_SELECTION_NONE,
> +DOMAIN_SELECTION_NAME,
> +DOMAIN_SELECTION_ID,
> +DOMAIN_SELECTION_UUID,
> +} DomainSelection;


> +switch (domain_selection_type) {
> +default: /* DOMAIN_SELECTION_NONE */
> +case DOMAIN_SELECTION_ID:
> +id = strtol(priv->domkey, , 10);
> +if (id >= 0 && end && !*end) {
> +dom = virDomainLookupByID(priv->conn, id);
> +}
> +if (domain_selection_type != DOMAIN_SELECTION_NONE) {
> +break;
> +}
> +/* fallthrough */
> +case DOMAIN_SELECTION_UUID:
> +if (!dom && virt_viewer_parse_uuid(priv->domkey, uuid) == 0) {
> +dom = virDomainLookupByUUID(priv->conn, uuid);
> +}
> +if (domain_selection_type != DOMAIN_SELECTION_NONE) {
> +break;
> +}
> +/* fallthrough */
> +case DOMAIN_SELECTION_NAME:
> +if (!dom) {
> +dom = virDomainLookupByName(priv->conn, priv->domkey);
> +}
>  }
> +
>  return dom;
>  }

IMHO using a switch here isn't really helping particularly with the
tricks to allow fallthrough, except when you don't want to allow
fallthrough.

I think this can be made nicer with a different approach that uses
the enum as a bitfield. eg psuedo code...

   int selection = 0;

   if (--domain is set) {
 selection |= DOMAIN_SELECTION_DOMAIN;
   } else if (--uuid is set) {
 selection |= DOMAIN_SELECTION_UUID;
   } else if (--id is set) {
 selection |= DOMAIN_SELECTION_ID;
   }

   if (!selection) {
 selection = DOMAIN_SELECTION_DOMAIN |
 DOMAIN_SELECTION_UUID |
 DOMAIN_SELECTION_ID;
   }


   if (selection & DOMAIN_ID) {
   dom = ...lookup by id...
   if (dom)
 selection = 0;
   }
   if (selection & DOMAIN_UUID) {
   dom = ...lookup by uuid...
   if (dom)
 selection = 0;
   }
   if (selection & DOMAIN_NAME) {
   dom = ...lookup by name...
   if (dom)
 selection = 0;
   }

This also avoids the issue with the switch potentially generating
fallthrough warnings under gcc7.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH virt-viewer 00/10] Make dialogs use GtkHeaderBar

[Daniel P. Berrange]

On Wed, Feb 22, 2017 at 11:15:22AM +, Daniel P. Berrange wrote:
> On Thu, Feb 16, 2017 at 10:57:52PM +0000, Daniel P. Berrange wrote:
> > On Thu, Feb 16, 2017 at 11:05:13AM -0200, Eduardo Lima (Etrunko) wrote:
> > > On 16/02/17 10:06, Pavel Grunt wrote:
> > > > Hi,
> > > > 
> > > > On Thu, 2017-02-09 at 17:22 -0200, Eduardo Lima (Etrunko) wrote:
> > > >> This whole series is the result of the initial idea of having the
> > > >> new
> > > >> iso-dialog to use this widget. Having it done only for the iso-
> > > >> dialog
> > > >> would not make much sense, so I went on and ported all other
> > > >> dialogs.
> > > >> The widget requires Gtk version 3.12, which should not be a problem
> > > >> for
> > > >> any recent distro.
> > > >>
> > > >> Using GtkHeaderBar makes dialogs look cleaner and more 'modern',
> > > >> also
> > > >> follow the style used by GNOME applications. In the near future,
> > > >> virt-viewer main window could also make use of it, as we recently
> > > >> saw in
> > > >> a series sent to this mailing list.
> > > > 
> > > > so are we going for the GNOME style for all desktop envs ? In my
> > > > opinion it does not look nice in Windows and Xfce - simply does not
> > > > fit it in. iirc it was mentioned that there is a way to have both the
> > > > classic and the GNOME look in the discussion about Sagar's patches few
> > > > weeks ago..
> > > 
> > > I have no idea of what it looks like in Windows, but it indeed looks
> > > good in Linux environments. I tested in both GNOME and Enlightenment,
> > > not sure about other DEs out there. As far as I remember, the discussion
> > > on that other series was about the classic menu versus the buttons on
> > > the header bar.
> > 
> > Please post some screenshots showing the before & after state of this
> > on GNOME, Linux non-GNOME and Windows, so we can accurately evaluate
> > what the change is.
> 
> So I've just done some tests on TWM and Windows against
> 
> https://github.com/etrunko/virt-viewer/tree/headerbar
> 
> The results are here:
> 
>   https://berrange.fedorapeople.org/virt-viewer-gtk-headerbar/win32/
>   https://berrange.fedorapeople.org/virt-viewer-gtk-headerbar/twm/
> 
> On Win32 the key things are
> 
>  - The about & prefs dialog use the Win32 native style header
>  - The connect dialog & main window use the GNOME headerbar style

BTW, this is running under Windows 2008r2

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH virt-viewer 00/10] Make dialogs use GtkHeaderBar

[Daniel P. Berrange]

On Thu, Feb 16, 2017 at 10:57:52PM +, Daniel P. Berrange wrote:
> On Thu, Feb 16, 2017 at 11:05:13AM -0200, Eduardo Lima (Etrunko) wrote:
> > On 16/02/17 10:06, Pavel Grunt wrote:
> > > Hi,
> > > 
> > > On Thu, 2017-02-09 at 17:22 -0200, Eduardo Lima (Etrunko) wrote:
> > >> This whole series is the result of the initial idea of having the
> > >> new
> > >> iso-dialog to use this widget. Having it done only for the iso-
> > >> dialog
> > >> would not make much sense, so I went on and ported all other
> > >> dialogs.
> > >> The widget requires Gtk version 3.12, which should not be a problem
> > >> for
> > >> any recent distro.
> > >>
> > >> Using GtkHeaderBar makes dialogs look cleaner and more 'modern',
> > >> also
> > >> follow the style used by GNOME applications. In the near future,
> > >> virt-viewer main window could also make use of it, as we recently
> > >> saw in
> > >> a series sent to this mailing list.
> > > 
> > > so are we going for the GNOME style for all desktop envs ? In my
> > > opinion it does not look nice in Windows and Xfce - simply does not
> > > fit it in. iirc it was mentioned that there is a way to have both the
> > > classic and the GNOME look in the discussion about Sagar's patches few
> > > weeks ago..
> > 
> > I have no idea of what it looks like in Windows, but it indeed looks
> > good in Linux environments. I tested in both GNOME and Enlightenment,
> > not sure about other DEs out there. As far as I remember, the discussion
> > on that other series was about the classic menu versus the buttons on
> > the header bar.
> 
> Please post some screenshots showing the before & after state of this
> on GNOME, Linux non-GNOME and Windows, so we can accurately evaluate
> what the change is.

So I've just done some tests on TWM and Windows against

https://github.com/etrunko/virt-viewer/tree/headerbar

The results are here:

  https://berrange.fedorapeople.org/virt-viewer-gtk-headerbar/win32/
  https://berrange.fedorapeople.org/virt-viewer-gtk-headerbar/twm/

On Win32 the key things are

 - The about & prefs dialog use the Win32 native style header
 - The connect dialog & main window use the GNOME headerbar style


On TWM the key things are

 - The about & prefs dialog use the TWM native style header
 - The connect dialog & main window use the TWM native style header
   *and* the GNOME headerbar style at the same time.


Some things...

GTK is smart with the About dialog - it is obviously dynamically
choosing whether to use a header bar or not and avoids it on both
TWM & Windows, but uses it on GNOME.

I'm not seriously expecting anyone to run with TWM. I picked it
simply as an example of a "dumb" window manager that won't understand
hints required to turn off headers when client side decorations are
used

I'm open to being convinced that this is a complete non-issue, if
all commonly used modern window managers support client side
decorations. I suspect this is probably the case, but it'd be good
to validate this with demos across all the common desktop envs on
Linux (GNOME, KDE, XFCE, Mate, Cinnamon, etc), so we know what to
expect for users.

This does still leave a question of themeing under non-GNOME. eg
running under say KDE, virt-viewer would previously have a KDE
theme header bar, whereas it now (might) have a GNOME style theme.
Again we can possibly declare this is a non-issue as it just requires
someone to write some GTK CSS to make it fit with KDE theme, and people
may well have already dealt with this since there's other GNOME apps
using headerbars already.

The Windows behaviour is a bigger question mark to me. We see GTK
being smart with the About dialog and not using header bar, keeping
the native Win32 style. I think the GNOME headerbar on the main
window looks totally out of place on Win32. If you look at other
apps like Firefox which try to use a headerbar-like approach, they
keep the Win32 style, but seemlessly blend it into their headerbar

https://berrange.fedorapeople.org/virt-viewer-gtk-headerbar/ff-win32.png

So I'm inclined to say we should *not* use headerbar for Win32
unless there's a way to make it blend wit the win32 theme - having
it use the default GTK/GNOME style just looks wrong IMHO.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH virt-viewer 00/10] Make dialogs use GtkHeaderBar

[Daniel P. Berrange]

On Fri, Feb 17, 2017 at 03:49:47PM -0200, Eduardo Lima (Etrunko) wrote:
> On 16/02/17 20:57, Daniel P. Berrange wrote:
> > On Thu, Feb 16, 2017 at 11:05:13AM -0200, Eduardo Lima (Etrunko) wrote:
> >> On 16/02/17 10:06, Pavel Grunt wrote:
> >>> Hi,
> >>>
> >>> On Thu, 2017-02-09 at 17:22 -0200, Eduardo Lima (Etrunko) wrote:
> >>>> This whole series is the result of the initial idea of having the
> >>>> new
> >>>> iso-dialog to use this widget. Having it done only for the iso-
> >>>> dialog
> >>>> would not make much sense, so I went on and ported all other
> >>>> dialogs.
> >>>> The widget requires Gtk version 3.12, which should not be a problem
> >>>> for
> >>>> any recent distro.
> >>>>
> >>>> Using GtkHeaderBar makes dialogs look cleaner and more 'modern',
> >>>> also
> >>>> follow the style used by GNOME applications. In the near future,
> >>>> virt-viewer main window could also make use of it, as we recently
> >>>> saw in
> >>>> a series sent to this mailing list.
> >>>
> >>> so are we going for the GNOME style for all desktop envs ? In my
> >>> opinion it does not look nice in Windows and Xfce - simply does not
> >>> fit it in. iirc it was mentioned that there is a way to have both the
> >>> classic and the GNOME look in the discussion about Sagar's patches few
> >>> weeks ago..
> >>
> >> I have no idea of what it looks like in Windows, but it indeed looks
> >> good in Linux environments. I tested in both GNOME and Enlightenment,
> >> not sure about other DEs out there. As far as I remember, the discussion
> >> on that other series was about the classic menu versus the buttons on
> >> the header bar.
> > 
> > Please post some screenshots showing the before & after state of this
> > on GNOME, Linux non-GNOME and Windows, so we can accurately evaluate
> > what the change is.
> 
> Okay, I have uploaded the screenshots of the dialogs to the following url:
> 
> http://imgur.com/a/WHt8R
> 
> I ran both before-series and after-series in GNOME and Enlightenment,
> all dialogs look exactly the same, except for the about dialog. By the
> way, I realized I should not mess with the About dialog, it does its own
> magic automatically. That one patch should be dropped.

I'm surprised it looks the same in GNOME + Enlightenment - I guess
Enlightenment must be supporting the same magic GNOME does to allow
GTK to do client side window decorations, without then adding its
own title bar too.  The dual titlebars is my main concern as I think
we saw that in the previous proposal for this kind of change.

I'd particularly like to see what happens in Windows with this change.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH virt-viewer 00/10] Make dialogs use GtkHeaderBar

[Daniel P. Berrange]

On Thu, Feb 16, 2017 at 11:05:13AM -0200, Eduardo Lima (Etrunko) wrote:
> On 16/02/17 10:06, Pavel Grunt wrote:
> > Hi,
> > 
> > On Thu, 2017-02-09 at 17:22 -0200, Eduardo Lima (Etrunko) wrote:
> >> This whole series is the result of the initial idea of having the
> >> new
> >> iso-dialog to use this widget. Having it done only for the iso-
> >> dialog
> >> would not make much sense, so I went on and ported all other
> >> dialogs.
> >> The widget requires Gtk version 3.12, which should not be a problem
> >> for
> >> any recent distro.
> >>
> >> Using GtkHeaderBar makes dialogs look cleaner and more 'modern',
> >> also
> >> follow the style used by GNOME applications. In the near future,
> >> virt-viewer main window could also make use of it, as we recently
> >> saw in
> >> a series sent to this mailing list.
> > 
> > so are we going for the GNOME style for all desktop envs ? In my
> > opinion it does not look nice in Windows and Xfce - simply does not
> > fit it in. iirc it was mentioned that there is a way to have both the
> > classic and the GNOME look in the discussion about Sagar's patches few
> > weeks ago..
> 
> I have no idea of what it looks like in Windows, but it indeed looks
> good in Linux environments. I tested in both GNOME and Enlightenment,
> not sure about other DEs out there. As far as I remember, the discussion
> on that other series was about the classic menu versus the buttons on
> the header bar.

Please post some screenshots showing the before & after state of this
on GNOME, Linux non-GNOME and Windows, so we can accurately evaluate
what the change is.

Also, I tried to apply this series to test it myself, but it fails to
apply to git master for some reason

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

[virt-tools-list] virt-viewer moved GIT repository

[Daniel P. Berrange]

Fedora hosted is being shutdown real soon now. I've previously moved the
downloads over to pagure.io, and have now moved the git repository too.

If you have a checkout, you'll need to replace your "origin" remote.

  git remote rm origin

then one or these as appropriate:

  git remote add origin ssh://g...@pagure.io/virt-viewer.git  (committers)
  git remote add origin https://pagure.io/virt-viewer.git(read-only)

finally

  git branch -u origin/master master

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH] virt-viewer: Avoid waiting if --attach is needed

[Daniel P. Berrange]

On Thu, Jan 12, 2017 at 05:58:02PM +0200, Snir Sheriber wrote:
> Avoid waiting for domain to start if only direct libvirt connection
> can be established (i.e remote connection is disabled) and --attach
> was not set
> 
> Resolves: rhbz#1386630
> ---
>  src/virt-viewer.c | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/src/virt-viewer.c b/src/virt-viewer.c
> index 3a3b64d..7a03100 100644
> --- a/src/virt-viewer.c
> +++ b/src/virt-viewer.c
> @@ -846,6 +846,21 @@ virt_viewer_initial_connect(VirtViewerApp *app, GError 
> **error)
>  }
>  
>  if (info.state == VIR_DOMAIN_SHUTOFF) {
> +/* If attach is disabled check whether remote connection can be 
> established */
> +if(!virt_viewer_app_get_attach(app)) {
> +char *type,*xmldesc;
> +
> +xmldesc = virDomainGetXMLDesc(dom, 0);
> +type = virt_viewer_extract_xpath_string(xmldesc, 
> "string(/domain/devices/graphics/listen/@type)");
> +if(g_strcmp0(type,"none") == 0) {
> +g_set_error_literal(, VIRT_VIEWER_ERROR, 
> VIRT_VIEWER_ERROR_FAILED,
> +_("Display can only be attached 
> through libvirt with --attach"));
> +free(xmldesc);
> +goto cleanup;
> +}
> +free(xmldesc);
> +}
> +
>  virt_viewer_app_show_status(app, _("Waiting for guest domain to 
> start"));
>  goto wait;
>  }

This is wrong. The guest XML may change at the time it starts, so doing
this premature check on the inactive XML may lead us to incorrectly
report an error


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH 0/5] Give a modern look to virt-virewer

[Daniel P. Berrange]

On Sat, Dec 17, 2016 at 05:50:07PM +0100, Fabiano Fidêncio wrote:
> From: Fabiano Fidêncio 
> 
> So, this patch series has been waiting for a long time to be upstreamed
> and during this week there was some conversations on #spice about getting
> it reviewed (even though I had already mentioned a few times it's been
> blocked by the changes not yet merged in the foreign-menu, which will
> become an item instead under preferences instead of the menu it is
> nowadays).
> 
> Now I've taken the bullet and rebased the series on top of a branch[0]
> which contains the latest work (in progress) done in the foreign menu.
> Or also cloneed directly from my github[1].
> 
> For those who will be testing and reviewing, please, apply thos patches
> on top of [0].
> 
> I was able to do some tests using RHEVM and foreign-menu icon
> "showability" works as expected.
> 
> An important note here is that while I'm the person sending the patches
> the person who ended up writing the most part of the code is Sagar
> Ghuge, so, big thanks to him!
> 
> I've done a few rounds of reviews privately with Sagar and IMO the
> patches, if not in the best shape, are quite okay.
> 
> Hopefully we will be able to see it merged soon :-)

IMHO the result needs more work for non-GNOME desktop environments.

If I run it on non-GNOME, then I get the window manager's title bar
followed by the virt-viewer titlebar, duplicating the min/max/close
buttons and the window title.  This wastes screen real estate and
looks pretty ugly, so I think we need to do better than that for
non-GNOME. ie, keep the original menu bar as-is for non-GNOME
desktops, and don't display the new fat header bar.


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH 4/5] window: Replace toolbar with headerbar (fullscreen)

[Daniel P. Berrange]

On Sat, Dec 17, 2016 at 05:50:11PM +0100, Fabiano Fidêncio wrote:
> From: Sagar Ghuge 
> 
> In order to give a modern look to {virt,remote}-viewer let's replace the
> old toolbar for a headerbar (it's the widget shown when the app is
> fullscreen).
> 
> The items in the headerbar are exactly the same ones present in the old
> toolbar.

The old toolbar was only as wide as was needed to display the buttons
and was centered.

The new headerbar covers the entire screen  width with 90% empty space
which is quite ugly and not user friendly as it obscures a good portion
of the guest display too.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

[virt-tools-list] ANNOUNCE: virt-viewer 5.0 release

[Daniel P. Berrange]

I am happy to announce a new bugfix release of virt-viewer, version 5.0:

  http://virt-manager.org/download/sources/virt-viewer/virt-viewer-5.0.tar.gz

This release also includes semi-experimental MSI installers for the
Win32 (x86) and Win64 (x64) platforms:

  http://virt-manager.org/download/sources/virt-viewer/virt-viewer-x86-5.0.msi
  http://virt-manager.org/download/sources/virt-viewer/virt-viewer-x64-5.0.msi

All are signed with key DAF3 A6FD B26B 6291 2D0E  8E3F BE86 EBB4 1510 4FDF  
(4096R)

  
http://virt-manager.org/download/sources/virt-viewer/virt-viewer-5.0.tar.gz.asc
  
http://virt-manager.org/download/sources/virt-viewer/virt-viewer-x86-5.0.msi.asc
  
http://virt-manager.org/download/sources/virt-viewer/virt-viewer-x64-5.0.msi.asc

All historical releases are available from:

  http://virt-manager.org/download/

Changes in this release include:

  - Don't retry authentication when credentials
are provided via vvfile
  - Fix display of guest name in title for VNC
  - Fix detection of domain stop when tunnelling
over SSH
  - Fix problem resizing with GTK client side
decorations
  - Fix leak on file transfer
  - Only include native spec file in dist to fix
rpmbuild -ta
  - Check min required spice-glib version
  - Display errors to user if failing to open UNIX socket
  - Simplify file transfer UI to only display overall
progress, rather than full list of files
  - Show list of files which failed to transfer

Thanks to everyone who contributed towards this release

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] RFC: time for a 5.0 release ?

[Daniel P. Berrange]

On Thu, Nov 24, 2016 at 02:11:59PM +0100, Pavel Grunt wrote:
> On Thu, 2016-11-24 at 12:59 +0000, Daniel P. Berrange wrote:
> > On Thu, Nov 24, 2016 at 12:17:23PM +0000, Daniel P. Berrange wrote:
> > > On Mon, Oct 10, 2016 at 04:05:32PM +0100, Daniel P. Berrange
> > > wrote:
> > > > On Mon, Oct 10, 2016 at 04:26:29PM +0200, Fabiano Fidêncio
> > > > wrote:
> > > > > On Mon, Oct 10, 2016 at 2:38 PM, Daniel P. Berrange <berrange@
> > > > > redhat.com> wrote:
> > > > > > The 4.0 release was in June, and there have not been very
> > > > > > many changes
> > > > > > since then, but there are a couple of significant ones
> > > > > > 
> > > > > >  - Fix resizing of windows when using CSDs (relevant for
> > > > > > Wayland)
> > > > > >  - Fix virt-viewer not exiting on broken connection to guest
> > > > > > 
> > > > > > If we do a new release we can also pull in the nasty Win32
> > > > > > redraw
> > > > > > bug that plagued 4.0. Of course we could do a new MSI build
> > > > > > v4.1
> > > > > > as an alternative.
> > > > > 
> > > > > I'm completely in favor of a new release.
> > > > > 
> > > > > Pavel was looking forward for a libusb* release at some point,
> > > > > so we
> > > > > could enable USB Redirection support in the Windows builds.
> > > > > 
> > > > > *: libusb released the -rc6 on October 1st. Would worth to
> > > > > talk to
> > > > > them and see what are their plan before running our release.
> > > > 
> > > > I want to do the Windows build against Fedora 25, so given the
> > > > current
> > > > GTK bug pointed out, we'll have to wait a little anyways. So
> > > > lets look
> > > > again in a week or two and hopefully we'll have fixed gtk +
> > > > libusb.
> > > 
> > > So can you confirm everything is ready todo a new virt-viewer
> > > release
> > > on current Fedora 25 with updates applied. ie as the libusb stuff
> > > ready
> > > and is the GTK bug fixed ?
> > 
> > F25 has glib 2.50.1 which has the bug fix we need for win32.
> > 
> > The mingw32-libusbx version is 1.0.21 and I'm unclear if that is the
> > version Fabiano/Pavel want for USB redirection in windows ?
> 
> It is, also is needed:
> mingw*-spice-gtk3-0.33-3 - it contains some usb related fixes

Ok, I'll pull that from updates-testing and do a formal release and
windows build then.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] RFC: time for a 5.0 release ?

[Daniel P. Berrange]

On Thu, Nov 24, 2016 at 12:17:23PM +, Daniel P. Berrange wrote:
> On Mon, Oct 10, 2016 at 04:05:32PM +0100, Daniel P. Berrange wrote:
> > On Mon, Oct 10, 2016 at 04:26:29PM +0200, Fabiano Fidêncio wrote:
> > > On Mon, Oct 10, 2016 at 2:38 PM, Daniel P. Berrange <berra...@redhat.com> 
> > > wrote:
> > > > The 4.0 release was in June, and there have not been very many changes
> > > > since then, but there are a couple of significant ones
> > > >
> > > >  - Fix resizing of windows when using CSDs (relevant for Wayland)
> > > >  - Fix virt-viewer not exiting on broken connection to guest
> > > >
> > > > If we do a new release we can also pull in the nasty Win32 redraw
> > > > bug that plagued 4.0. Of course we could do a new MSI build v4.1
> > > > as an alternative.
> > > 
> > > I'm completely in favor of a new release.
> > > 
> > > Pavel was looking forward for a libusb* release at some point, so we
> > > could enable USB Redirection support in the Windows builds.
> > > 
> > > *: libusb released the -rc6 on October 1st. Would worth to talk to
> > > them and see what are their plan before running our release.
> > 
> > I want to do the Windows build against Fedora 25, so given the current
> > GTK bug pointed out, we'll have to wait a little anyways. So lets look
> > again in a week or two and hopefully we'll have fixed gtk + libusb.
> 
> So can you confirm everything is ready todo a new virt-viewer release
> on current Fedora 25 with updates applied. ie as the libusb stuff ready
> and is the GTK bug fixed ?

F25 has glib 2.50.1 which has the bug fix we need for win32.

The mingw32-libusbx version is 1.0.21 and I'm unclear if that is the
version Fabiano/Pavel want for USB redirection in windows ?

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] RFC: time for a 5.0 release ?

[Daniel P. Berrange]

On Mon, Oct 10, 2016 at 04:05:32PM +0100, Daniel P. Berrange wrote:
> On Mon, Oct 10, 2016 at 04:26:29PM +0200, Fabiano Fidêncio wrote:
> > On Mon, Oct 10, 2016 at 2:38 PM, Daniel P. Berrange <berra...@redhat.com> 
> > wrote:
> > > The 4.0 release was in June, and there have not been very many changes
> > > since then, but there are a couple of significant ones
> > >
> > >  - Fix resizing of windows when using CSDs (relevant for Wayland)
> > >  - Fix virt-viewer not exiting on broken connection to guest
> > >
> > > If we do a new release we can also pull in the nasty Win32 redraw
> > > bug that plagued 4.0. Of course we could do a new MSI build v4.1
> > > as an alternative.
> > 
> > I'm completely in favor of a new release.
> > 
> > Pavel was looking forward for a libusb* release at some point, so we
> > could enable USB Redirection support in the Windows builds.
> > 
> > *: libusb released the -rc6 on October 1st. Would worth to talk to
> > them and see what are their plan before running our release.
> 
> I want to do the Windows build against Fedora 25, so given the current
> GTK bug pointed out, we'll have to wait a little anyways. So lets look
> again in a week or two and hopefully we'll have fixed gtk + libusb.

So can you confirm everything is ready todo a new virt-viewer release
on current Fedora 25 with updates applied. ie as the libusb stuff ready
and is the GTK bug fixed ?


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH virt-viewer v4 1/2] Simplify file transfer dialog UI

[Daniel P. Berrange]

On Mon, Oct 24, 2016 at 04:04:21PM -0500, Jonathon Jongsma wrote:
> When transferring a large number of files, the file transfer dialog was
> unusable because the window size would be larger than the client
> desktop. To solve this, remove the list of individual files (and the
> ability to cancel each file transfer independantly) and only display
> a single overall progress bar that shows the status of all ongoing
> transfers.
> 
> This also allows us to remove the delayed unref of the task since we
> don't need to show the task information about each individual transfer
> task until the window is closed. Removes TaskFinishedData type.
> 
> This patch requires new API from spice-gtk to calculate the overall
> progress:
>  spice_file_transfer_task_get_total_bytes()
>  spice_file_transfer_task_get_transferred_bytes()
> ---
>  configure.ac   |   2 +-
>  src/Makefile.am|   1 +
>  .../ui/virt-viewer-file-transfer-dialog.ui |  87 ++

This also breaks the build because you didn't list the newly translatable
file:

--- ../po/POTFILES.in
+++ ../po/POTFILES.in
@@ -6,6 +6,7 @@
 src/resources/ui/remote-viewer-connect.ui
 src/resources/ui/virt-viewer-about.ui
 src/resources/ui/virt-viewer-auth.ui
+src/resources/ui/virt-viewer-file-transfer-dialog.ui
 src/resources/ui/virt-viewer-guest-details.ui
 src/resources/ui/virt-viewer-preferences.ui
 src/resources/ui/virt-viewer-vm-connection.ui
maint.mk: you have changed the set of files with translatable diagnostics;
 apply the above patch
../maint.mk:1063: recipe for target 'sc_po_check' failed
make: *** [sc_po_check] Error 1
make: *** Waiting for unfinished jobs
Build step 'Execute shell' marked build as failure


Please ensure to always runs "make syntax-check" before pushing any
changes.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH virt-viewer] !fixup Simplify file transfer dialog UI

[Daniel P. Berrange]

On Thu, Oct 27, 2016 at 02:33:08PM -0500, Jonathon Jongsma wrote:
> ---
> Includes fixes from Pavel and Fabiano's reviews
> 
>  src/resources/ui/virt-viewer-file-transfer-dialog.ui | 12 +++-
>  src/virt-viewer-file-transfer-dialog.c   |  6 +++---
>  2 files changed, 10 insertions(+), 8 deletions(-)
> 

> diff --git a/src/virt-viewer-file-transfer-dialog.c 
> b/src/virt-viewer-file-transfer-dialog.c
> index 3339ba4..cd1b4aa 100644
> --- a/src/virt-viewer-file-transfer-dialog.c
> +++ b/src/virt-viewer-file-transfer-dialog.c
> @@ -58,7 +58,7 @@ 
> virt_viewer_file_transfer_dialog_class_init(VirtViewerFileTransferDialogClass 
> *k
>  GtkWidgetClass *widget_class = GTK_WIDGET_CLASS(klass);
>  
>  gtk_widget_class_set_template_from_resource(widget_class,
> -
> "/org/virt-manager/virt-viewer/ui/virt-viewer-file-transfer-dialog.ui");
> +VIRT_VIEWER_RESOURCE_PREFIX 
> "/ui/virt-viewer-file-transfer-dialog.ui");


This appears to have broken the build

../../src/virt-viewer-file-transfer-dialog.c: In function 
'virt_viewer_file_transfer_dialog_class_init':
../../src/virt-viewer-file-transfer-dialog.c:62:49: error: 
'VIRT_VIEWER_RESOURCE_PREFIX' undeclared (first use in this function)
 VIRT_VIEWER_RESOURCE_PREFIX 
"/ui/virt-viewer-file-transfer-dialog.ui");
 ^~~
../../src/virt-viewer-file-transfer-dialog.c:62:49: note: each undeclared 
identifier is reported only once for each function it appears in
../../src/virt-viewer-file-transfer-dialog.c:62:77: error: expected ')' before 
string constant
 VIRT_VIEWER_RESOURCE_PREFIX 
"/ui/virt-viewer-file-transfer-dialog.ui");
 
^
make[3]: *** [Makefile:930: 
libvirt_viewer_la-virt-viewer-file-transfer-dialog.lo] Error 1



Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] RFC: time for a 5.0 release ?

[Daniel P. Berrange]

On Mon, Oct 10, 2016 at 04:26:29PM +0200, Fabiano Fidêncio wrote:
> On Mon, Oct 10, 2016 at 2:38 PM, Daniel P. Berrange <berra...@redhat.com> 
> wrote:
> > The 4.0 release was in June, and there have not been very many changes
> > since then, but there are a couple of significant ones
> >
> >  - Fix resizing of windows when using CSDs (relevant for Wayland)
> >  - Fix virt-viewer not exiting on broken connection to guest
> >
> > If we do a new release we can also pull in the nasty Win32 redraw
> > bug that plagued 4.0. Of course we could do a new MSI build v4.1
> > as an alternative.
> 
> I'm completely in favor of a new release.
> 
> Pavel was looking forward for a libusb* release at some point, so we
> could enable USB Redirection support in the Windows builds.
> 
> *: libusb released the -rc6 on October 1st. Would worth to talk to
> them and see what are their plan before running our release.

I want to do the Windows build against Fedora 25, so given the current
GTK bug pointed out, we'll have to wait a little anyways. So lets look
again in a week or two and hopefully we'll have fixed gtk + libusb.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

[virt-tools-list] RFC: time for a 5.0 release ?

[Daniel P. Berrange]

The 4.0 release was in June, and there have not been very many changes
since then, but there are a couple of significant ones

 - Fix resizing of windows when using CSDs (relevant for Wayland)
 - Fix virt-viewer not exiting on broken connection to guest

If we do a new release we can also pull in the nasty Win32 redraw
bug that plagued 4.0. Of course we could do a new MSI build v4.1
as an alternative.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Plugins for virt-manager

[Daniel P. Berrange]

On Fri, Sep 16, 2016 at 10:56:37AM -0500, David Ashley wrote:
> Does virt-manager support plugins? I have looked through the source code and
> can not find any supporting mechanism for this functionality. I have an idea
> for extending virt-manager but it would involve functionality that would
> only be useful for some users. I would hate to impose the overhead for this
> new functionality for all users so I think it should be implemented as a
> plugin.
> 
> I can add the plugin code to virt-manager once an architecture has been
> established. Obviously a lot of input would be needed to get this right.
> Would others be interested in contributing (ideas, code, testing, etc.) to
> this? Or is this even the correct way to add new functionality to
> virt-manager? is there a better way?
> 
> Discussion anyone?

The natural approach to plugins for any GTK app these days is to integrate
with libpeas. It would not relaly be all that much work. The harder thing
is deciding what kind of API gaurantees to provide plugin authors. eg will
changes in virt-manager break plugins on every release :-)


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH virt-viewer] Disable CSD to avoid rendering issues

[Daniel P. Berrange]

On Wed, Aug 10, 2016 at 08:35:49AM +0200, Fabiano Fidêncio wrote:
> Pavel,
> 
> On Tue, Aug 9, 2016 at 5:29 PM, Pavel Grunt <pgr...@redhat.com> wrote:
> > On Tue, 2016-08-09 at 15:57 +0100, Daniel P. Berrange wrote:
> >> On Tue, Aug 09, 2016 at 04:40:02PM +0200, Pavel Grunt wrote:
> >> >
> >> > On Tue, 2016-08-09 at 15:12 +0100, Daniel P. Berrange wrote:
> >> > >
> >> > > On Tue, Aug 09, 2016 at 04:09:15PM +0200, Pavel Grunt wrote:
> >> > > >
> >> > > >
> >> > > > Due to recent changes in gtk+ the content of window is not rendered
> >> > > > properly in Windows 10 when the client side decorations are used.
> >> > > >
> >> > > > It is possible to disable the client side decorations using
> >> > > > the GTK_CSD="0" environment variable.
> >> > > >
> >> > > > Keep them disabled to avoid issues.
> >> > > >
> >> > > > Related:
> >> > > > https://bugzilla.redhat.com/show_bug.cgi?id=1352216
> >> > >
> >> > > Can you provide the actual GTK bug report for this issue.
> >> >
> >> > I am working on reproducer for the issue. Apparently only remote-viewer 
> >> > has
> >> > problems.
> >> > >
> >> > >
> >> > > >
> >> > > >
> >> > > > ---
> >> > > > I know it is not a solution. virt-viewer should learn to work 
> >> > > > properly
> >> > > > with
> >> > > > CSD
> >> > > > ---
> >> > > >  src/virt-viewer-util.c | 2 ++
> >> > > >  1 file changed, 2 insertions(+)
> >> > > >
> >> > > > diff --git a/src/virt-viewer-util.c b/src/virt-viewer-util.c
> >> > > > index 0491f73..1b0335d 100644
> >> > > > --- a/src/virt-viewer-util.c
> >> > > > +++ b/src/virt-viewer-util.c
> >> > > > @@ -295,6 +295,8 @@ void virt_viewer_util_init(const char *appname)
> >> > > >  }
> >> > > >  }
> >> > > >  #endif
> >> > > > +/* FIXME: avoid rendering issues with csd - used by default in
> >> > > > Win10*/
> >> > > > +g_setenv("GTK_CSD", "0", TRUE);
> >> > >
> >> > > At the version least you should make this hidden behind G_OS_WIN32,
> >> > > even better if you can make it only happen on Win10 at runtime.
> >> >
> >> > I wanted to keep it for every OS so it is harder to forget about fixing 
> >> > it.
> >>
> >> Nope that'll break virt-viewer when run under Wayland, since AFAIK, the
> >> Wayland compositors all request CSD
> >
> > GTK_CSD is ignored under Wayland/when cannot be used. But I can of course 
> > move
> > it up to the G_OS_WIN32 to make it more clear.
> 
> I also prefer inside a G_OS_WIN32 ifdef.
> Another thing is that this solution is a temporary hack. So, I'd like
> to suggest to apply it only in the 4.0-maint branch.

It is bad practice to apply a fix only to a maint branch, as that opens
the possibility of forgetting to fix it in master, which means users
would see a regression on the next release. Fixes should always go into
master first, and then stable branches, even if we intend to do a better
fix in master at some point in the future.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH virt-viewer] Disable CSD to avoid rendering issues

[Daniel P. Berrange]

On Tue, Aug 09, 2016 at 04:40:02PM +0200, Pavel Grunt wrote:
> On Tue, 2016-08-09 at 15:12 +0100, Daniel P. Berrange wrote:
> > On Tue, Aug 09, 2016 at 04:09:15PM +0200, Pavel Grunt wrote:
> > > 
> > > Due to recent changes in gtk+ the content of window is not rendered
> > > properly in Windows 10 when the client side decorations are used.
> > > 
> > > It is possible to disable the client side decorations using
> > > the GTK_CSD="0" environment variable.
> > > 
> > > Keep them disabled to avoid issues.
> > > 
> > > Related:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1352216
> > 
> > Can you provide the actual GTK bug report for this issue.
> 
> I am working on reproducer for the issue. Apparently only remote-viewer has
> problems.
> > 
> > > 
> > > ---
> > > I know it is not a solution. virt-viewer should learn to work properly 
> > > with
> > > CSD
> > > ---
> > >  src/virt-viewer-util.c | 2 ++
> > >  1 file changed, 2 insertions(+)
> > > 
> > > diff --git a/src/virt-viewer-util.c b/src/virt-viewer-util.c
> > > index 0491f73..1b0335d 100644
> > > --- a/src/virt-viewer-util.c
> > > +++ b/src/virt-viewer-util.c
> > > @@ -295,6 +295,8 @@ void virt_viewer_util_init(const char *appname)
> > >  }
> > >  }
> > >  #endif
> > > +/* FIXME: avoid rendering issues with csd - used by default in 
> > > Win10*/
> > > +g_setenv("GTK_CSD", "0", TRUE);
> > 
> > At the version least you should make this hidden behind G_OS_WIN32,
> > even better if you can make it only happen on Win10 at runtime.
> 
> I wanted to keep it for every OS so it is harder to forget about fixing it.

Nope that'll break virt-viewer when run under Wayland, since AFAIK, the
Wayland compositors all request CSD

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH virt-viewer] Disable CSD to avoid rendering issues

[Daniel P. Berrange]

On Tue, Aug 09, 2016 at 04:09:15PM +0200, Pavel Grunt wrote:
> Due to recent changes in gtk+ the content of window is not rendered
> properly in Windows 10 when the client side decorations are used.
>
> It is possible to disable the client side decorations using
> the GTK_CSD="0" environment variable.
> 
> Keep them disabled to avoid issues.
> 
> Related:
> https://bugzilla.redhat.com/show_bug.cgi?id=1352216

Can you provide the actual GTK bug report for this issue.

> ---
> I know it is not a solution. virt-viewer should learn to work properly with 
> CSD
> ---
>  src/virt-viewer-util.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/src/virt-viewer-util.c b/src/virt-viewer-util.c
> index 0491f73..1b0335d 100644
> --- a/src/virt-viewer-util.c
> +++ b/src/virt-viewer-util.c
> @@ -295,6 +295,8 @@ void virt_viewer_util_init(const char *appname)
>  }
>  }
>  #endif
> +/* FIXME: avoid rendering issues with csd - used by default in Win10*/
> +g_setenv("GTK_CSD", "0", TRUE);

At the version least you should make this hidden behind G_OS_WIN32,
even better if you can make it only happen on Win10 at runtime.


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH glib] Fix check for libvirt optional functions

[Daniel P. Berrange]

On Thu, Jul 28, 2016 at 02:36:54PM +0200, Christophe Fergeau wrote:
> On Thu, Jul 28, 2016 at 01:30:12PM +0100, Daniel P. Berrange wrote:
> > The checks for virDomainOpenGraphicsFD and
> > virNetworkGetDHCPLeases in configure are simply trying
> > to compile and link a test program. This was assuming
> > that libvirt was installed in /usr/lib & /usr/include,
> > which is not always the case. Using a pkg-config version
> > check avoids needing to compile and thus avoids the
> > bad assumptions about install locations.
> > 
> > Signed-off-by: Daniel P. Berrange <berra...@redhat.com>
> > ---
> > 
> > Pushed as a broken build fix
> > 
> >  configure.ac | 18 --
> >  1 file changed, 12 insertions(+), 6 deletions(-)
> > 
> > diff --git a/configure.ac b/configure.ac
> > index f71e5cf..b2848f2 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -92,13 +92,19 @@ LIBVIRT_GLIB_COMPILE_WARNINGS
> >  
> >  PKG_CHECK_MODULES(LIBVIRT, libvirt >= $LIBVIRT_REQUIRED)
> >  # virDomainOpenGraphicsFD was introduced in libvirt 1.2.8
> > -AC_CHECK_LIB([virt],
> > - [virDomainOpenGraphicsFD],
> > - [AC_DEFINE([HAVE_VIR_DOMAIN_OPEN_GRAPHICS_FD], 1, [Have 
> > virDomainOpenGraphicsFD?])])
> > +AC_MSG_CHECKING([for virDomainOpenGraphicsFD])
> > +PKG_CHECK_EXISTS(libvirt >= 21.2.8,
> 
> s/21/1

Sigh, mistakenly commited my debug hack


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH glib] Avoid unused variable in DHCP lease finalize method

[Daniel P. Berrange]

On Thu, Jul 28, 2016 at 01:30:27PM +0100, Daniel P. Berrange wrote:
> If the network DHCP lease support is not detected, the build
> will generate a warning / error:
> 
> libvirt-gobject-network-dhcp-lease.c: In function 
> 'gvir_network_dhcp_lease_finalize':
> libvirt-gobject-network-dhcp-lease.c:99:27: error: unused variable 'lease' 
> [-Werror=unused-variable]
>  GVirNetworkDHCPLease *lease = GVIR_NETWORK_DHCP_LEASE(object);
>^
> cc1: all warnings being treated as errors
> 
> Signed-off-by: Daniel P. Berrange <berra...@redhat.com>
> ---
> 
> Pushed as a broken build fix
> 
>  libvirt-gobject/libvirt-gobject-network-dhcp-lease.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)

Sorry wrong list and it got through before I successfully Ctrl-C'd it.


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

[virt-tools-list] [PATCH glib] Avoid unused variable in DHCP lease finalize method

[Daniel P. Berrange]

If the network DHCP lease support is not detected, the build
will generate a warning / error:

libvirt-gobject-network-dhcp-lease.c: In function 
'gvir_network_dhcp_lease_finalize':
libvirt-gobject-network-dhcp-lease.c:99:27: error: unused variable 'lease' 
[-Werror=unused-variable]
 GVirNetworkDHCPLease *lease = GVIR_NETWORK_DHCP_LEASE(object);
   ^
cc1: all warnings being treated as errors

Signed-off-by: Daniel P. Berrange <berra...@redhat.com>
---

Pushed as a broken build fix

 libvirt-gobject/libvirt-gobject-network-dhcp-lease.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/libvirt-gobject/libvirt-gobject-network-dhcp-lease.c 
b/libvirt-gobject/libvirt-gobject-network-dhcp-lease.c
index 7d1c979..200778d 100644
--- a/libvirt-gobject/libvirt-gobject-network-dhcp-lease.c
+++ b/libvirt-gobject/libvirt-gobject-network-dhcp-lease.c
@@ -96,12 +96,10 @@ static void gvir_network_dhcp_lease_set_property(GObject 
*object,
 
 static void gvir_network_dhcp_lease_finalize(GObject *object)
 {
-GVirNetworkDHCPLease *lease = GVIR_NETWORK_DHCP_LEASE(object);
 #ifdef HAVE_VIR_NETWORK_GET_DHCP_LEASES
+GVirNetworkDHCPLease *lease = GVIR_NETWORK_DHCP_LEASE(object);
 GVirNetworkDHCPLeasePrivate *priv = lease->priv;
-#endif /* HAVE_VIR_NETWORK_GET_DHCP_LEASES */
 
-#ifdef HAVE_VIR_NETWORK_GET_DHCP_LEASES
 virNetworkDHCPLeaseFree(priv->handle);
 #endif /* HAVE_VIR_NETWORK_GET_DHCP_LEASES */
 
-- 
2.7.4

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

[virt-tools-list] [PATCH glib] Fix check for libvirt optional functions

[Daniel P. Berrange]

The checks for virDomainOpenGraphicsFD and
virNetworkGetDHCPLeases in configure are simply trying
to compile and link a test program. This was assuming
that libvirt was installed in /usr/lib & /usr/include,
which is not always the case. Using a pkg-config version
check avoids needing to compile and thus avoids the
bad assumptions about install locations.

Signed-off-by: Daniel P. Berrange <berra...@redhat.com>
---

Pushed as a broken build fix

 configure.ac | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/configure.ac b/configure.ac
index f71e5cf..b2848f2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -92,13 +92,19 @@ LIBVIRT_GLIB_COMPILE_WARNINGS
 
 PKG_CHECK_MODULES(LIBVIRT, libvirt >= $LIBVIRT_REQUIRED)
 # virDomainOpenGraphicsFD was introduced in libvirt 1.2.8
-AC_CHECK_LIB([virt],
- [virDomainOpenGraphicsFD],
- [AC_DEFINE([HAVE_VIR_DOMAIN_OPEN_GRAPHICS_FD], 1, [Have 
virDomainOpenGraphicsFD?])])
+AC_MSG_CHECKING([for virDomainOpenGraphicsFD])
+PKG_CHECK_EXISTS(libvirt >= 21.2.8,
+ [
+  AC_DEFINE([HAVE_VIR_DOMAIN_OPEN_GRAPHICS_FD], 1, [Have 
virDomainOpenGraphicsFD?])
+  AC_MSG_RESULT([yes])
+],[AC_MSG_RESULT([no])])
 # virNetworkGetDHCPLeases was introduced in libvirt 1.2.6
-AC_CHECK_LIB([virt],
- [virNetworkGetDHCPLeases],
- [AC_DEFINE([HAVE_VIR_NETWORK_GET_DHCP_LEASES], 1, [Have 
virNetworkGetDHCPLeases?])])
+AC_MSG_CHECKING([for virNetworkGetDHCPLeases])
+PKG_CHECK_EXISTS(libvirt >= 21.2.6,
+ [
+  AC_DEFINE([HAVE_VIR_NETWORK_GET_DHCP_LEASES], 1, [Have 
virNetworkGetDHCPLeases?])
+  AC_MSG_RESULT([yes])
+],[AC_MSG_RESULT([no])])
 enable_tests=no
 PKG_CHECK_MODULES(GLIB2, glib-2.0 >= $GLIB2_TEST_REQUIRED,
   [enable_tests=yes],
-- 
2.7.4

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [Libvirt-ci] Build failed in Jenkins: virt-manager-test » libvirt-centos-7 #1474

[Daniel P. Berrange]

This latest virt-manager failure looks genuine:

On Thu, Jul 28, 2016 at 09:12:18AM +, c...@centos.org wrote:
> --- tests/cli-test-xml/compare/virt-install-kvm-f14-url.xml
> +++ Generated Output
> @@ -50,7 +50,7 @@
>
>
>  
> -
> +
>  
>
>  
> @@ -109,7 +109,7 @@
>
>
>  
> -
> +
>  
>
>  

Looks like there's two separate issues here

 - The test case is assuming usb tablet, but in fact pulling data
   from libosinfo. Fedora 23 records support for virtio1.0-input
   devices, so this seems to have tripped up the test assumptions

 - It looks like the code is just blindly copying the device
   name from libosinfo, into the guest XML, but this is not valid
   since there's not a 1-1 match between dev names in libosinfo
   and device model names in libvirt.

eg, a name virtio1.0-input in libosinfo maps to 
in libvirt.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

[virt-tools-list] [c...@centos.org: [Libvirt-ci] Build failed in Jenkins: virt-manager-test » libvirt-fedora-23 #1440]

[Daniel P. Berrange]

It appears that quite a few tests in virt-manager are currently
failing. I'm unclear if this is due to genuine libvirt regressions,
or the tests were relying on undefined behaviour which has now
changed in libvirt

- Forwarded message from c...@centos.org -

> Date: Tue, 19 Jul 2016 15:52:37 + (GMT+00:00)
> From: c...@centos.org
> To: shaj...@redhat.com, libvirt...@redhat.com
> Subject: [Libvirt-ci] Build failed in Jenkins: virt-manager-test » 
> libvirt-fedora-23 #1440
> 
> See 
> 
> 
> --
> Started by upstream project "virt-manager-test" build number 1440
> originally caused by:
>  Started by upstream project "virt-manager-build" build number 1370
>  originally caused by:
>   Started by upstream project "libvirt-python-build" build number 1123
>   originally caused by:
>Started by upstream project "libvirt-daemon-build" build number 1543
>originally caused by:
> Started by an SCM change
> Started by an SCM change
>  Started by upstream project "virt-viewer-build" build number 1148
>  originally caused by:
>   Started by upstream project "libvirt-daemon-build" build number 1543
> [EnvInject] - Loading node environment variables.
> Building remotely on libvirt-fedora-23 (libvirt) in workspace 
> 
> [libvirt-fedora-23] $ /bin/sh -xe /tmp/hudson515687075386881451.sh
> + ./setup.py test
> running test
> s.F.F...F.ssssssF.s...Fss..s..
> ==
> FAIL: testCLI0229virt_xml_edit_simple_metadata (tests.clitest.CLITests)
> --
> Traceback (most recent call last):
>   File 
> "
>  line 1013, in 
> return lambda s: cmdtemplate(s, cmd)
>   File 
> "
>  line 1012, in cmdtemplate
> _cmdobj.run(self)
>   File 
> "
>  line 270, in run
> tests.fail(err)
> AssertionError: ./virt-xml  --connect 
> __virtinst_test__test:///
>  test-for-virtxml --edit --print-diff --define --metadata 
> name=foo-my-new-name,uuid=12345678-12F4-1234-1234-123456789AFA,description="hey
>  this is my
> new
> very,very=new desc\'",title="This is my,funky=new title" 
> Conversion outputs did not match.
> --- tests/cli-test-xml/compare/virt-xml-edit-simple-metadata.xml
> +++ Generated Output
> @@ -8,7 +8,7 @@
>  +  hey this is my
>  +new
>  +very,very=new desc'
> -   409600
> +   4194304
> 204800
> 
>  @@
> 
> 
> ==
> FAIL: testCLI0231virt_xml_edit_simple_memory (tests.clitest.CLITests)
> --
> Traceback (most recent call last):
>   File 
> "
>  line 1013, in 
> return lambda s: cmdtemplate(s, cmd)
>   File 
> "
>  line 1012, in cmdtemplate
> _cmdobj.run(self)
>   File 
> "
>  line 270, in run
> tests.fail(err)
> AssertionError: ./virt-xml  --connect 
> __virtinst_test__test:///
>  test-for-virtxml --edit --print-diff --define --memory 
> 500,maxmemory=1000,hugepages=off
> Conversion outputs did not match.
> --- tests/cli-test-xml/compare/virt-xml-edit-simple-memory.xml
> +++ Generated Output
> @@ -1,7 +1,7 @@
> 12345678-12f4-1234-1234-123456789012
> Test VM for virtxml cli tests
> 
> --  409600
> +-  4194304
>  -  204800
>  +  1024000
>  +  512000
> 
> 
> ==
> FAIL: testCLI0235virt_xml_edit_simple_blkiotune (tests.clitest.CLITests)
> --
> Traceback (most recent call last):
>   File 
> 

Re: [virt-tools-list] [virt-viewer v1] Take reference to monitor the file transfer task

[Daniel P. Berrange]

On Tue, Jul 12, 2016 at 02:22:54PM +0200, Fabiano Fidêncio wrote:
> On Tue, Jul 12, 2016 at 2:19 PM, Victor Toso  wrote:
> > Documentation states that:
> >  "Client applications may take a reference on the @task object and use
> >  it to monitor the status of the file transfer task."
> >
> > We have been monitoring SpiceFileTransferTask without reference it but
> > since the introduction of file transfer dialog we also unref it after
> > task is finished (on task_finished_remove) leading to critical
> > warnings when task original reference has been freed already.
> >
> > Signed-off-by: Victor Toso 
> > ---
> >  src/virt-viewer-session-spice.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/src/virt-viewer-session-spice.c 
> > b/src/virt-viewer-session-spice.c
> > index 731f074..fdbfd5d 100644
> > --- a/src/virt-viewer-session-spice.c
> > +++ b/src/virt-viewer-session-spice.c
> > @@ -943,7 +943,7 @@ on_new_file_transfer(SpiceMainChannel *channel 
> > G_GNUC_UNUSED,
> >  {
> >  VirtViewerSessionSpice *self = VIRT_VIEWER_SESSION_SPICE(user_data);
> >  
> > virt_viewer_file_transfer_dialog_add_task(self->priv->file_transfer_dialog,
> > -  task);
> > +  g_object_ref(task));
> >  }
> >
> >  static void
> 
> Acked-by: Fabiano Fidêncio 

Should be added to v4.0-maint branch too


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

[virt-tools-list] [PATCH] virt-viewer: ensure we close when seeing domain stop event

[Daniel P. Berrange]

Normally virt-viewer relies on the VNC/SPICE widget seeing
an EOF on its underlying connection to detect when the
session is closed.

When tunnelling to a remote guest over SSH though, this
EOF can be delayed for a very long time, leaving a dead
session open.

This can be seen with

   virt-viewer -c qemu+ssh://remotehost/system guestname

when on the remote shell run

   virsh destroy guestname

and notice that virt-viewer does not see the shutdown
immediately.

When we get a domain stopped event we know the session
should be dead, so forceably close it, if not already
closed.

Signed-off-by: Daniel P. Berrange <berra...@redhat.com>
---
 src/virt-viewer.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/virt-viewer.c b/src/virt-viewer.c
index 173b0d3..4dfe8df 100644
--- a/src/virt-viewer.c
+++ b/src/virt-viewer.c
@@ -664,6 +664,7 @@ virt_viewer_domain_event(virConnectPtr conn G_GNUC_UNUSED,
 {
 VirtViewer *self = opaque;
 VirtViewerApp *app = VIRT_VIEWER_APP(self);
+VirtViewerSession *sess;
 GError *error = NULL;
 
 g_debug("Got domain event %d %d", event, detail);
@@ -673,7 +674,9 @@ virt_viewer_domain_event(virConnectPtr conn G_GNUC_UNUSED,
 
 switch (event) {
 case VIR_DOMAIN_EVENT_STOPPED:
-//virt_viewer_deactivate(self);
+sess = virt_viewer_app_get_session(app);
+if (sess != NULL)
+virt_viewer_session_close(sess);
 break;
 
 case VIR_DOMAIN_EVENT_STARTED:
-- 
2.7.4

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

[virt-tools-list] [PATCH] virt-viewer: fix display of guest name in title for vnc

[Daniel P. Berrange]

The following commit broke the display of the guest name in
the title for VNC displays:

  commit 61a1bc4dcbb056755fe96c5945f84c1312041059
  Author: Pavel Grunt <pgr...@redhat.com>
  Date:   Wed Apr 15 13:50:35 2015 +0200

session-vnc: Set window for display to avoid gtk-vnc v0.3.8 crash

The VNC display widget of gtk-vnc v0.3.8 needs a window at the moment

The problem is that this causes the window to be associated
with the display before the guest name is available. Thus
when ensure_window_for_display() runs, the window is already
configured and so it never invokes the logic to set the title.

The fix is to unconditionally update the title in the
ensure_window_for_display() method, even if the window already
exists.

Signed-off-by: Daniel P. Berrange <berra...@redhat.com>
---
 src/virt-viewer-app.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/virt-viewer-app.c b/src/virt-viewer-app.c
index f983db2..e8412ac 100644
--- a/src/virt-viewer-app.c
+++ b/src/virt-viewer-app.c
@@ -898,7 +898,6 @@ ensure_window_for_display(VirtViewerApp *self, 
VirtViewerDisplay *display)
 if (l && virt_viewer_window_get_display(VIRT_VIEWER_WINDOW(l->data)) 
== NULL) {
 win = VIRT_VIEWER_WINDOW(l->data);
 g_debug("Found a window without a display, reusing for display 
#%d", nth);
-virt_viewer_app_set_window_subtitle(self, win, nth);
 if (self->priv->fullscreen && !self->priv->kiosk)
 app_window_try_fullscreen(self, win, nth);
 } else {
@@ -907,6 +906,7 @@ ensure_window_for_display(VirtViewerApp *self, 
VirtViewerDisplay *display)
 
 virt_viewer_window_set_display(win, display);
 }
+virt_viewer_app_set_window_subtitle(self, win, nth);
 
 return win;
 }
-- 
2.7.4

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

[virt-tools-list] ANNOUNCE: virt-viewer 4.0 release

[Daniel P. Berrange]

I am happy to announce a new bugfix release of virt-viewer, version 4.0:

  http://virt-manager.org/download/sources/virt-viewer/virt-viewer-4.0.tar.gz

This release also includes semi-experimental MSI installers for the
Win32 (x86) and Win64 (x64) platforms:

  http://virt-manager.org/download/sources/virt-viewer/virt-viewer-x86-4.0.msi
  http://virt-manager.org/download/sources/virt-viewer/virt-viewer-x64-4.0.msi

All are signed with key DAF3 A6FD B26B 6291 2D0E  8E3F BE86 EBB4 1510 4FDF  
(4096R)

  
http://virt-manager.org/download/sources/virt-viewer/virt-viewer-4.0.tar.gz.asc
  
http://virt-manager.org/download/sources/virt-viewer/virt-viewer-x86-4.0.msi.asc
  
http://virt-manager.org/download/sources/virt-viewer/virt-viewer-x64-4.0.msi.asc

All historical releases are available from:

  http://virt-manager.org/download/

Changes in this release include:

  - Drop support for gtk2 builds
  - Require spice-gtk >= 0.31
  - Require glib2 >= 2.38
  - Require gtk3 >= 3.10
  - Require libvirt-glib >= 0.1.8
  - Increase minimum window size fo 320x200 instead of 50x50
  - Remove use of GSLice
  - Don't show usbredir button if not connected yet
  - Only compute monitor mapping in full screen
  - Don't ignore usb-filter in spiec vv-file
  - Port to use GtkApplication API
  - Don't leave window open after connection failure
  - Validate symbols from max glib/gdk versions
  - Don't use GtkStock
  - Don't use gtk_widget-modify_{fg,bg} APIs
  - Drop use of built-in eventloop in favour of libvirt-glib
  - Don't open X display while parsing command line
  - Fix window title
  - Use GResource for building ui files into binary
  - Fix crash with invalid spice monitor mapping
  - Add dialog to show file transfer progress and allow
cancelling
  - Remove unused nsis installer support
  - Include adwaita icon theme in msi builds
  - Add more menu mnemonics
  - Fix support for windows consoles to allow I/O redirection
  - Add support for ovirt sso-token in vv-file
  - Fix crash with zooming window while not connected
  - Remove custom auto drawer widget with GtkRevealer
  - Add appdata file for gnome software
  - Misc other bug fixes
  - Refresh translations

Thanks to everyone who contributed patches towards this release

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH virt-viewer] package: Add appdata metadata for Gnome Software

[Daniel P. Berrange]

On Mon, Jun 27, 2016 at 05:20:54PM +0200, Lukáš Venhoda wrote:
> Adds metadata to be used with Gnome Software.
> Includes name, summary, description and three screenshots of remote-viewer.
> ---
>  data/Makefile.am  |  9 +++--
>  data/remote-viewer.appdata.xml.in | 29 +
>  po/POTFILES.in|  1 +
>  virt-viewer.spec.in   |  1 +
>  4 files changed, 38 insertions(+), 2 deletions(-)
>  create mode 100644 data/remote-viewer.appdata.xml.in

ACK


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

[virt-tools-list] Plan for virt-viewer release this week

[Daniel P. Berrange]

Hi Folks,

It is time we did another virt-viewer release, since alot of code has
built-in. I'm suggesting we aim todo one on this coming Thursday 30th.

At least we'll want the appdata patches added. Let me know if there's
any other patch series pending we might want..

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH virt-viewer 2/2 v2] package: Add appdata metadata for Gnome Software

[Daniel P. Berrange]

On Fri, Jun 24, 2016 at 03:13:41PM +0100, Daniel P. Berrange wrote:
> On Fri, Jun 24, 2016 at 04:12:55PM +0200, Lukas Venhoda wrote:
> > Hi
> > 
> > On Fri, Jun 24, 2016 at 11:57 AM, Daniel P. Berrange <berra...@redhat.com>
> > wrote:
> > 
> > > If we're going todo this, then we should host the screenshots on the
> > > actual project website, ie virt-manager.org, not spice-space.org.
> > > Also we must ensure we use a URL path we will be willing to keep
> > > stable indefinitely.
> > >
> > > eg something like this
> > >
> > >   http://virt-manager.org/appdata/en_US/screenshots/virt-viewer.png
> > >
> > >
> > Who should I contact about this?
> 
> Me :-)

I've created four perma-links now

https://virt-manager.org/appdata/en_US/virt-viewer/general.png
https://virt-manager.org/appdata/en_US/virt-viewer/connection.png
https://virt-manager.org/appdata/en_US/virt-viewer/usbredir.png
https://virt-manager.org/appdata/en_US/virt-viewer/shared_folder.png

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH virt-viewer 2/2 v2] package: Add appdata metadata for Gnome Software

[Daniel P. Berrange]

On Fri, Jun 24, 2016 at 04:12:55PM +0200, Lukas Venhoda wrote:
> Hi
> 
> On Fri, Jun 24, 2016 at 11:57 AM, Daniel P. Berrange <berra...@redhat.com>
> wrote:
> 
> > If we're going todo this, then we should host the screenshots on the
> > actual project website, ie virt-manager.org, not spice-space.org.
> > Also we must ensure we use a URL path we will be willing to keep
> > stable indefinitely.
> >
> > eg something like this
> >
> >   http://virt-manager.org/appdata/en_US/screenshots/virt-viewer.png
> >
> >
> Who should I contact about this?

Me :-)

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH 1/2] package: Add Provides remote-viewer

[Daniel P. Berrange]

On Thu, Jun 23, 2016 at 04:53:08PM +0200, Lukáš Venhoda wrote:
> Enables usage of dnf install remote-viewer and dnf remove remote-viewer
> for the virt-viewer package
> ---
>  virt-viewer.spec.in | 2 ++
>  1 file changed, 2 insertions(+)

NACK this is totally pointless. The use of virtual provides in RPM is
to facilitate upgrades where renaming is done. It is absolutely not
there to provide arbitrary aliases for every command that happens to
be part of the installed package.


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH virt-viewer 2/2 v2] package: Add appdata metadata for Gnome Software

[Daniel P. Berrange]

On Fri, Jun 24, 2016 at 11:45:13AM +0200, Lukáš Venhoda wrote:
> Adds metadata to be used with Gnome Software.
> Includes name, summary, description and three screenshots of remote-viewer.
> ---
> Changes since v1:
>  - typo
>  - removed line from commit log
>  - fixed website url
> ---
>  data/Makefile.am  |  9 +++--
>  data/remote-viewer.appdata.xml.in | 28 
>  po/POTFILES.in|  1 +
>  virt-viewer.spec.in   |  1 +
>  4 files changed, 37 insertions(+), 2 deletions(-)
>  create mode 100644 data/remote-viewer.appdata.xml.in
> 
> diff --git a/data/Makefile.am b/data/Makefile.am
> index 821c171..55718d9 100644
> --- a/data/Makefile.am
> +++ b/data/Makefile.am
> @@ -76,6 +76,11 @@ mimedir = $(datadir)/mime/packages
>  mime_DATA = virt-viewer-mime.xml
>  @INTLTOOL_XML_RULE@
> 
> +appdatadir   = $(datadir)/appdata
> +APPDATAFILES = remote-viewer.appdata.xml.in
> +appdata_DATA = $(APPDATAFILES:.xml.in=.xml)
> +@INTLTOOL_XML_RULE@
> +
>  install-data-hook:
>  if ENABLE_UPDATE_MIMEDB
>   @if $(AM_V_P); then set -x; else echo "  INSTALL  
> update-mime-database"; fi; \
> @@ -88,8 +93,8 @@ if ENABLE_UPDATE_MIMEDB
>   $(UPDATE_MIME_DATABASE) "$(DESTDIR)$(datadir)/mime";
>  endif
> 
> -CLEANFILES += $(mime_DATA) $(desktop_DATA)
> -EXTRA_DIST += $(MIMEFILES) $(DESKTOPFILES)
> +CLEANFILES += $(mime_DATA) $(desktop_DATA) $(appdata_DATA)
> +EXTRA_DIST += $(MIMEFILES) $(DESKTOPFILES) $(APPDATAFILES)
> 
>  endif
> 
> diff --git a/data/remote-viewer.appdata.xml.in 
> b/data/remote-viewer.appdata.xml.in
> new file mode 100644
> index 000..1fa9d31
> --- /dev/null
> +++ b/data/remote-viewer.appdata.xml.in
> @@ -0,0 +1,28 @@
> +
> +
> + remote-viewer.desktop
> + CC0-1.0
> + GPL-2.0+
> + <_name>Remote Viewer
> + <_summary>Remotely access virtual machines
> + 
> +  <_p>
> +Remote Viewer provides a graphical viewer for the guest OS
> +display. At this time it supports guest OS using the VNC
> +or SPICE protocols. Further protocols may be supported in
> +the future as user demand dictates. The viewer can connect
> +directly to both local and remotely hosted guest OS, optionally
> +using SSL/TLS encryption.
> +  
> + 
> + 
> +   type="default">http://www.spice-space.org/static/images/remote_viewer_youtube.png
> +  
> http://www.spice-space.org/static/images/remote_viewer_usbredir.png
> +  
> http://www.spice-space.org/static/images/remote_viewer_shared_folder.png
> + 
> + 
> +  virt-viewer
> + 
> + https://virt-manager.org/
> + virt-tools-list_at_redhat.com
> +

If we're going todo this, then we should host the screenshots on the
actual project website, ie virt-manager.org, not spice-space.org.
Also we must ensure we use a URL path we will be willing to keep
stable indefinitely.

eg something like this

  http://virt-manager.org/appdata/en_US/screenshots/virt-viewer.png


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH] [RFC] Drop zooming operations

[Daniel P. Berrange]

On Mon, Jun 13, 2016 at 09:55:50AM +0200, Fabiano Fidêncio wrote:
> Zooming operations have been a big source of bugs since they were
> introduced. My suggestion is that we drop the zooming operations before
> start merging Sagar's work[0], which I would like to have in for Fedora
> 25.

If we drop functionality based on whether it is a source of bugs, then
the first place to start would be to drop spice.

IOW, I honestly don't see this as an even remotely compelling reason
to drop the zoom functionality.

I also don't think it materially affects our ability to accept Sagar's
work, so I think that's not relevant.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH virt-install] virtinst: Add --transient flag.

[Daniel P. Berrange]

On Thu, Jun 02, 2016 at 12:20:32PM +0200, Pavel Hrdina wrote:
> On Thu, Jun 02, 2016 at 11:02:27AM +0100, Richard W.M. Jones wrote:
> > On Thu, Jun 02, 2016 at 11:00:16AM +0200, Pavel Hrdina wrote:
> > > We should forbid to use --transient with all other types of install
> > > methods because it doesn't make any sense and it doesn't work.
> > > Unfortunately we need to add a check "if options.transient and
> > > (options.pxe or options.cdrom or ), we cannot simply check for
> > > --import or --boot because --boot can be combined with any other
> > > install method.
> > 
> > I'm not sure I understand.  Surely a --pxe install (for example) could
> > involve a boot, and so --transient could be appropriate?
> > 
> > What other options are in the list elided above?
> 
> The thing is that virt-install has 2 phases while installing and each phase 
> has
> its own XML.  The first phase is the install phase where install XML is used.
> After the installation is completed virt-install destroys the guest, replace 
> the
> domain XML with boot XML and starts it again.
> 
> If you set that the domain is transient, the domain disappears after the first
> phase is completed.  Which leads to two different solutions:

> 1. allow --transient only with --import or --boot but not with other install
> options, because they redefine the domain XML
> 
> 2. update the code so also all other install option would be able to destroy 
> the
> guest and start it again only as transient.  Currently it doesn't work.  If 
> you
> use --noautoconsole or kill the virt-install during first phase there is no
> process that will start the guest again and if you let the virt-install to 
> start
> the guest again it will fail with error message that the domain cannot be 
> found.

IMHO it is valid to want to install a guest, but *not* start it after
installation is complete. IOW, --transient is semantically valid even
with --install IMHO - it just means you would not start it after intsall
completes.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH 2/3] Remove nsis installer

[Daniel P. Berrange]

On Tue, Apr 26, 2016 at 04:43:53PM +0200, Fabiano Fidêncio wrote:
> On Tue, Apr 26, 2016 at 4:34 PM, Daniel P. Berrange <berra...@redhat.com> 
> wrote:
> > On Tue, Apr 26, 2016 at 04:29:07PM +0200, Christophe Fergeau wrote:
> >> On Tue, Apr 26, 2016 at 04:16:41PM +0200, Fabiano Fidêncio wrote:
> >> > The only reason for us to keep maintaining the nsis installer was the
> >> > activex plugin (spicex), which requires those nsis based installers.
> >> > As the next release of RHEV/oVirt won't use the activex plugin (spicex)
> >> > let's completely remove the nsis installer from our tree and focus on
> >> > only maintain the msi installer.
> >>
> >> Given that oVirt 4.0 is not released yet, might make sense to hold that
> >> for a bit? Maybe some last minute issue will prevent that removal.
> >
> > Does anyone know what the newest version of virt-viewer is that oVirt
> > has been shipping ?  It could be valid to say that if they want NSIS
> > they should stick on the v2.0-maint of v3.0-maint branches instead
> > of updating to the virt-viewer 4.0 release .
> 
> 2.0 with a bunch of patch on top, considering the client is the same
> one used for RHEVM.

IMHO, since they've not even upgraded to 3.0 release version, I think
we're fine to drop nsis in the virt-viewer-4.0 version, without waiting
for the next oVirt release.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH 2/3] Remove nsis installer

[Daniel P. Berrange]

On Tue, Apr 26, 2016 at 04:29:07PM +0200, Christophe Fergeau wrote:
> On Tue, Apr 26, 2016 at 04:16:41PM +0200, Fabiano Fidêncio wrote:
> > The only reason for us to keep maintaining the nsis installer was the
> > activex plugin (spicex), which requires those nsis based installers.
> > As the next release of RHEV/oVirt won't use the activex plugin (spicex)
> > let's completely remove the nsis installer from our tree and focus on
> > only maintain the msi installer.
> 
> Given that oVirt 4.0 is not released yet, might make sense to hold that
> for a bit? Maybe some last minute issue will prevent that removal.

Does anyone know what the newest version of virt-viewer is that oVirt
has been shipping ?  It could be valid to say that if they want NSIS
they should stick on the v2.0-maint of v3.0-maint branches instead
of updating to the virt-viewer 4.0 release .


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Official Mac port of Virt-Manager

[Daniel P. Berrange]

Regards,
Daniel

On Mon, Mar 21, 2016 at 06:57:30PM -0400, Programmingkid wrote:
> I was wondering if someone made it so that Virt-Manager could run under Mac 
> OS X, and he or she sent in the patches to you, would you accept them and add 
> them to Virt-Manager's official repository? 

AFAIK, there's been no work to port it to OS-X. Virt-manager is written in
python, and libvirt clients build for OS-X, so in theory it is possible, but
in practice I've no idea what dragons might lurk there. I imagine it would
be easier than a Win32 port, but that's not saying much...

I've copied the virt-manager mailing list since that's a better place for
this kind of question

> I also would like to say Virt-Manager seems like a great program. Good job on 
> making it. 

FWIW, I haven't done any work on virt-manager for a good 5 years now, Cole
Robinson leads the development, so while I'm happy to receive compliments
for creating it, Cole and other recent community contributors deserve most
of the credit

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [virt-viewer] Don't include libvirt.h in virt-viewer-auth.h

[Daniel P. Berrange]

On Wed, Mar 09, 2016 at 05:12:19PM +0100, Fabiano Fidêncio wrote:
> On Wed, Mar 9, 2016 at 5:02 PM, Christophe Fergeau  
> wrote:
> > virt-viewer-auth.h does not use any libvirt types, so the #include is
> > not needed, and virt-viewer-auth.h is used while building remote-viewer,
> > which do not use libvirt compilation flags. This caused failures on
> > a freshly installed box without libvirt headers.
> > ---
> >  src/virt-viewer-auth.h | 4 
> >  1 file changed, 4 deletions(-)
> >
> > diff --git a/src/virt-viewer-auth.h b/src/virt-viewer-auth.h
> > index 85e3bbc..cdabd00 100644
> > --- a/src/virt-viewer-auth.h
> > +++ b/src/virt-viewer-auth.h
> > @@ -25,10 +25,6 @@
> >
> >  #include "config.h"
> >
> > -#ifdef HAVE_LIBVIRT
> > -#include 
> > -#endif
> > -
> >  #include "virt-viewer-session.h"
> >  #include "virt-viewer-util.h"
> >
> > --
> > 2.5.0
> >
> > ___
> > virt-tools-list mailing list
> > virt-tools-list@redhat.com
> > https://www.redhat.com/mailman/listinfo/virt-tools-list
> 
> Acked-by: Fabiano Fidêncio 
> 
> Btw, do you know some automated way to check for not needed includes? ;-)

The typical approach is to just try deleting includes until the build
fails. The results of this still need to be vetted though, because a
header file my be not-needed on one OS, but needed on a different OS
depending on how they've structured their system header files :-( So
it is best to be wary of removing headers unless its obvious they are
clearly not-needed to a human eye.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [virt-viewer 0/3] Bring back libvirt-glib dependency

[Daniel P. Berrange]

On Tue, Feb 23, 2016 at 03:32:04PM +0100, Fabiano Fidêncio wrote:
> A long time ago we used to depend on libvirt-glib for the glib event
> loop integration. On commit 296f91c it got dropped in favor of
> keeping everything into virt-viewer tree because libvirt-glib was not
> mature enough. Well, that's not the case anymore, so let's bring
> the dependency back.

BTW, we should also consider using libvirt-gobject and libvirt-gconfig
for accessing VMs & looking at their config, instead of using libvirt
and parsing XML directly.


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [virt-viewer v2 3/3] util: allow loading an in-tree ui file

[Daniel P. Berrange]

On Thu, Feb 25, 2016 at 02:03:40PM +0100, Fabiano Fidêncio wrote:
> This commits allows to load ui files without the need to install
> virt-viewer. It helps a lot developers testing changes in the ui files
> and also avoid abortions like [0] when running remote-viewer from the
> source tree and without having any previous installation.
> 
> [0]:
> fidenci@cat ~/src/upstream/virt-viewer $ ./src/remote-viewer
> 
> (remote-viewer:29951): virt-viewer-ERROR **: failed to find UI
> description file
> Trace/breakpoint trap (core dumped)
> 
> Signed-off-by: Fabiano Fidêncio 
> ---
>  src/Makefile.am|  2 +-
>  src/virt-viewer-util.c | 35 +++
>  2 files changed, 32 insertions(+), 5 deletions(-)
> 
> diff --git a/src/Makefile.am b/src/Makefile.am
> index 171a141..ac7177d 100644
> --- a/src/Makefile.am
> +++ b/src/Makefile.am
> @@ -187,7 +187,7 @@ if OS_WIN32
>  remote_viewer_LDFLAGS += -Wl,--subsystem,windows
>  endif
>  
> -AM_CPPFLAGS = -DPACKAGE_DATADIR=\""$(pkgdatadir)"\"
> +AM_CPPFLAGS = -DPACKAGE_DATADIR=\""$(pkgdatadir)"\" 
> -DSOURCE_DIR=\""$(abs_srcdir)"\"

Embedding the source build directory inside binaries is generally
bad practice IMHO.

> +static gboolean
> +virt_viewer_util_try_to_load_ui_from_non_system_data_dirs(GtkBuilder 
> *builder,
> +  const gchar *name,
> +  GError **error)
> +{
> +gboolean ret;
> +gchar *path;
> +
> +/*
> + * Firstly, try to load the ui file from the $srcdir.
> + * It allows developers to test changes done in the ui file without
> + * installing virt-viewer.
> + */
> +path = g_build_filename(SOURCE_DIR, name, NULL);

Just create a relative path here eg

 g_build_filename(".", "src", name, NULL);

> +ret = virt_viewer_util_add_to_builder_from_file(builder, path, error);
>  g_free(path);
>  
> +if (!ret) {
> +/*
> + * And only then try to load the ui file from the $pkgdatadir.
> + */
> +path = g_build_filename(PACKAGE_DATADIR, "ui", name, NULL),
> +ret = virt_viewer_util_add_to_builder_from_file(builder, path, 
> error);
> +g_free(path);
> +}
> +
>  return ret;

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [c...@centos.org: Build failed in Jenkins: virt-viewer-build » libvirt-centos-6 #712]

[Daniel P. Berrange]

On Mon, Feb 15, 2016 at 05:57:01PM +0100, Fabiano Fidêncio wrote:
> Daniel.
> 
> On Mon, Feb 15, 2016 at 5:09 PM, Daniel P. Berrange <berra...@redhat.com> 
> wrote:
> > Some recent patches appear to have broken the build...
> 
> Pavel already posted a patch that will be pushed soon.
> It seems like the right time for applying the pending patch that drops
> Gtk2 support. What do you think?

I've not personally reviewed the latest posting - as long as the issues
raised with the posting are address, its fine.

When those patches for dropping Gtk2 merge, we'll have to kill off this
centos6 job and just do centos7

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

[virt-tools-list] [c...@centos.org: Build failed in Jenkins: virt-viewer-build » libvirt-centos-6 #712]

[Daniel P. Berrange]

Some recent patches appear to have broken the build...

- Forwarded message from c...@centos.org -

> Date: Mon, 15 Feb 2016 13:25:50 + (GMT+00:00)
> From: c...@centos.org
> To: shaj...@redhat.com, berra...@redhat.com
> Subject: Build failed in Jenkins: virt-viewer-build » libvirt-centos-6 #712
> 
> See 
> 
> 
> Changes:
> 
> [pgrunt] app: Compute monitor mapping only in fullscreen
> 
> [pgrunt] display: Use common code to get preferred size
> 
> [pgrunt] display: Remove zoom property
> 
> --
> [...truncated 191 lines...]
> config.status: creating data/Makefile
> config.status: creating data/adwaita-icons-needed.wxi
> config.status: creating data/virt-viewer.wxs
> config.status: creating data/virt-viewer.nsis
> config.status: creating data/virt-viewer-debug.nsis
> config.status: creating icons/Makefile
> config.status: creating icons/16x16/Makefile
> config.status: creating icons/22x22/Makefile
> config.status: creating icons/24x24/Makefile
> config.status: creating icons/32x32/Makefile
> config.status: creating icons/48x48/Makefile
> config.status: creating icons/256x256/Makefile
> config.status: creating man/Makefile
> config.status: creating mingw-virt-viewer.spec
> config.status: creating po/Makefile.in
> config.status: creating src/Makefile
> config.status: creating src/virt-viewer.rc
> config.status: creating virt-viewer.spec
> config.status: creating config.h
> config.status: linking ../GNUmakefile to GNUmakefile
> config.status: executing depfiles commands
> config.status: executing libtool commands
> config.status: executing default-1 commands
> config.status: executing po/stamp-it commands
> configure: 
> configure: Configuration summary
> configure: =
> configure: 
> configure:  Features:
> configure: 
> configure:   Gtk: 2.0
> configure: 
> configure:  Libraries:
> configure: 
> configure:GLIB2: -pthread -I/usr/include/glib-2.0 
> -I/usr/lib64/glib-2.0/include   -pthread -Wl,--export-dynamic -lgthread-2.0 
> -lgmodule-2.0 -lrt -lglib-2.0  
> configure: 
> configure:  GTK: -pthread -I/usr/include/gtk-2.0 
> -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo 
> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 
> -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 
> -I/usr/include/freetype2 -I/usr/include/libpng12   -pthread -lgtk-x11-2.0 
> -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 
> -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 
> -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0  
> configure: 
> configure:  GTK_VNC: -pthread -I/usr/include/gtk-vnc-1.0 
> -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 
> -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 
> -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 
> -I/usr/include/freetype2 -I/usr/include/libpng12   -pthread -lgtk-vnc-1.0 
> -lgtk-x11-2.0 -lgnutls -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 
> -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig 
> -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0  
> configure: 
> configure:SPICE_GTK:  
> configure: 
> configure:  LIBXML2: -I/usr/include/libxml2   -lxml2  
> configure: 
> configure:  LIBVIRT:   -lvirt -ldl  
> configure: 
> configure:OVIRT:  
> configure: 
> 
> Now type 'make' to compile virt-viewer.
> + make syntax-check
> GFDL_version
> 0.38 GFDL_version
> TAB_in_indentation
> 0.26 TAB_in_indentation
> Wundef_boolean
> 0.35 Wundef_boolean
> avoid_attribute_unused_in_header
> 0.41 avoid_attribute_unused_in_header
> avoid_if_before_free
> 0.57 avoid_if_before_free
> cast_of_argument_to_free
> 0.19 cast_of_argument_to_free
> cast_of_x_alloc_return_value
> 0.16 cast_of_x_alloc_return_value
> changelog
> 0.20 changelog
> const_long_option
> 0.17 const_long_option
> copyright_check
> 0.51 copyright_check
> copyright_format
> 0.42 copyright_format
> error_message_period
> 0.15 error_message_period
> error_message_warn_fatal
> 0.25 error_message_warn_fatal
> m4_quote_check
> 0.21 m4_quote_check
> makefile_TAB_only_indentation
> 0.18 makefile_TAB_only_indentation
> makefile_at_at_check
> 0.13 makefile_at_at_check
> po_check
> 1.64 po_check
> preprocessor_indentation
> maint.mk: skipping test sc_preprocessor_indentation: cppi not installed
> 0.09 preprocessor_indentation
> prohibit_HAVE_MBRTOWC
> 0.15 prohibit_HAVE_MBRTOWC
> prohibit_always-defined_macros
> 0.03 prohibit_always-defined_macros
> prohibit_argmatch_without_use
> 0.22 prohibit_argmatch_without_use
> prohibit_assert_without_use
> 0.33 prohibit_assert_without_use
> prohibit_backup_files
> 0.37 prohibit_backup_files
> prohibit_c_ctype_without_use
> 0.40 prohibit_c_ctype_without_use
> prohibit_canonicalize_without_use
> 

[virt-tools-list] ANNOUNCE: virt-viewer 3.1 release

[Daniel P. Berrange]

I am happy to announce a new bugfix release of virt-viewer, version 3.1:

  http://virt-manager.org/download/sources/virt-viewer/virt-viewer-3.1.tar.gz

This release also includes semi-experimental MSI installers for the
Win32 (x86) and Win64 (x64) platforms:

  http://virt-manager.org/download/sources/virt-viewer/virt-viewer-x86-3.1.msi
  http://virt-manager.org/download/sources/virt-viewer/virt-viewer-x64-3.1.msi

All are signed with key DAF3 A6FD B26B 6291 2D0E  8E3F BE86 EBB4 1510 4FDF  
(4096R)

  
http://virt-manager.org/download/sources/virt-viewer/virt-viewer-3.1.tar.gz.asc
  
http://virt-manager.org/download/sources/virt-viewer/virt-viewer-x86-3.1.msi.asc
  
http://virt-manager.org/download/sources/virt-viewer/virt-viewer-x64-3.1.msi.asc

All historical releases are available from:

  http://virt-manager.org/download/

Changes in this release include:

  - Refresh translations

Thanks to everyone who contributed patches towards this release

NOTE: again the 3.x branch is the *last* release series to support GTK-2.
>From 4.0 onwards it is going to be GTK-3 only.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH 7/7] Make GApplication port compatible with older glib

[Daniel P. Berrange]

On Fri, Dec 11, 2015 at 02:40:36PM -0200, Eduardo Lima (Etrunko) wrote:
> Signed-off-by: Eduardo Lima (Etrunko) 
> ---
>  configure.ac   |  2 +-
>  src/remote-viewer.c|  9 +
>  src/virt-glib-compat.c | 29 +
>  src/virt-viewer-app.c  | 15 +++
>  src/virt-viewer-app.h  |  8 
>  src/virt-viewer.c  |  9 +
>  6 files changed, 71 insertions(+), 1 deletion(-)

[snip]

You've added an awful lot of back compat code here to deal with
this. I can't help thinking a better approach is to just not
use the g_application_add_main_option_entries() method in the
first place instead of adding piles of copy+pasted code.

Reading the description of that method does not make it sound
like it is a critical feature we absolutely need to have.

[quote]
This function is new in GLib 2.40. Before then, the only real
choice was to send all of the commandline arguments (options
and all) to the primary instance for handling. GApplication
ignored them completely on the local side. Calling this function
"opts in" to the new behaviour, and in particular, means that
unrecognised options will be treated as errors.
[/quote]


IMHO we could just do as that suggested, and send the options
to the primary instance for handling instead of parsing them
locally. Or alternatively just carry on using the GOptionContext
for parsing CLI args locally, and only use GApplication for the
non-CLI arg handling parts


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] ANNOUNCE: virt-viewer 3.0 release

[Daniel P. Berrange]

On Mon, Dec 07, 2015 at 08:56:34PM -0500, Hajime Taira wrote:
> Don't worry about it. I am translating po file related new pot file on Zanata 
> now.
> Could you refresh the translations before next minor release?

I'll do a 3.1 release with updated translations only in a week or so,
to allow a little time for more translations.


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] ANNOUNCE: virt-viewer 3.0 release

[Daniel P. Berrange]

Hmm, I screwed up and didn't refresh the translations :-(

Daniel

On Sun, Dec 06, 2015 at 08:57:32PM -0500, Hajime Taira wrote:
> Hi Daniel,
> 
> Congrats. virt-viewer 3.0 release.
> 
> I have a question. Where do you merge po file from? Zatana or Transifex?
> POT-Creation-Date is "2015-02-23 11:36+" in of each po file on git. This 
> is Too old.
> 
> POT-Creation-Date: 2015-02-23 11:36+
> https://git.fedorahosted.org/cgit/virt-viewer.git/tree/po/ja.po
> https://git.fedorahosted.org/cgit/virt-viewer.git/tree/po/fr.po
> 
> I recognize that Zanata is currently translation space.
> https://fedora.zanata.org/project/view/virt-viewer
> 
> Best regards,
> 
> Hajime Taira <hta...@redhat.com>
> RHEL Solution Architect
> Services and Pre-Sales
> Red Hat K.K.
> 
> Ebisu Neonato 8F, 4-1-18, Ebisu,
> Shibuya-ku, Tokyo, Japan 150-0013
> 
> - 元のメッセージ -
> 差出人: "Daniel P. Berrange" <berra...@redhat.com>
> 宛先: virt-tools-list@redhat.com
> 送信済み: 2015年12月4日, 金曜日 午前 1:35:04
> 件名: [virt-tools-list] ANNOUNCE: virt-viewer 3.0 release
> 
> I am happy to announce a new release of virt-viewer, version 3.0:
> 
>   http://virt-manager.org/download/sources/virt-viewer/virt-viewer-3.0.tar.gz
> 
> This release also includes semi-experimental MSI installers for the
> Win32 (x86) and Win64 (x64) platforms:
> 
>   http://virt-manager.org/download/sources/virt-viewer/virt-viewer-x86-3.0.msi
>   http://virt-manager.org/download/sources/virt-viewer/virt-viewer-x64-3.0.msi
> 
> All are signed with key DAF3 A6FD B26B 6291 2D0E  8E3F BE86 EBB4 1510 4FDF  
> (4096R)
> 
>   
> http://virt-manager.org/download/sources/virt-viewer/virt-viewer-3.0.tar.gz.asc
>   
> http://virt-manager.org/download/sources/virt-viewer/virt-viewer-x86-3.0.msi.asc
>   
> http://virt-manager.org/download/sources/virt-viewer/virt-viewer-x64-3.0.msi.asc
> 
> All historical releases are available from:
> 
>   http://virt-manager.org/download/
> 
> Changes in this release include:
> 
>   - Last release to support GTK2 for Linux. The next
> 4.0 release will be GTK3 only.
>   - Don't add URI scheme / path info to oVirt URIs
>   - Require spice-gtk >= 0.30
>   - Enable webdav folder sharing with spice
>   - Add preferences UI dialog
>   - Take --direct into account when checking if guest is
> reachable
>   - Take SPICE proxy into account when connecting to oVirt
> instances
>   - Fail gracefully when hostname is not returned by
> oVirt
>   - Don't show empty foreign menu on secondary displays
>   - Avoid accidentally trying to connect to port 0 when
> oVirt doesn't specify a port number
>   - Correctly update geometry when enabling/disabling
> display heads
>   - Avoid accidentally creating extra monitors when using
> configuration file monitor mapping
>   - Exit normally when cancelling connect dialog
>   - Don't wait for a guest that we know will never show up
>   - Fix crash when using --reconnect with SPICE
>   - Avoid zooming out if it would decrease window size
> below minimum required for top menu display
>   - Fix crash when disabling last enabled display
>   - Honour changes in display position from guest
>   - Don't show error dialog twice for unknown graphics type
>   - Allow to cancel oVirt auth without error
>   - Set sensitivity of display menu based on whether it is
> usable or not
>   - Set sensitivity of tool bar buttons based on whether they
> are usable or not
>   - Set guest name reported by VNC
>   - Fix crash when using gtk-vnc 0.3.8
>   - Fix alt-tab behaviour in choose VM dialog
>   - Don't allow missing display in monitor mapping config
>   - Add --with-osid flag to configure to allow specifying
> the operating system build target. The values should
> be based on libosinfo OS short IDs.
>   - Ensure windows installer places menu icon for all users
> not just admin. Requires manual uninstall of previous
> windows version
>   - Require address in remote viewer connect dialog
>   - Automatically retry VNC connection after auth failure
>   - Drop GTK2 support for Windows builds
>   - Enable keepalives on libvirt connection
>   - Allow resize of window to arbitrary size
>   - Fix thread safety handling event callbacks
>   - Avoid deprecation warnings with newer glib
>   - Pulled in multiple fixes for event loop from libvirt-glib
>   - Fix misc bugs reported by coverity
>   - Fix binary ID in MSI installer
>   - Stop polling libvirt after reconnecting to libvirt
> 
> Thanks to everyone who contributed patches towards this release
> 
> NOTE: again this is the *last* release to support GTK-2. From here
> onw

Re: [virt-tools-list] [PATCH 3/4] Port to GtkApplication API's

[Daniel P. Berrange]

On Thu, Dec 03, 2015 at 12:17:41PM -0200, Eduardo Lima (Etrunko) wrote:
> On 12/02/2015 09:09 AM, Christophe Fergeau wrote:
> > Hey,
> > 
> > On Fri, Nov 27, 2015 at 05:24:00PM -0200, Eduardo Lima (Etrunko) wrote:
> >> Most of this patch consists in code being shuffled around to fit the
> >> expected flow while using the new APIs. I tried my best to make this
> >> patch the less intrusive as possible. Main changes are:
> >>
> >> - VirtViewerApp is now a subclass of GtkApplication
> >>
> >>   Also, some mainloop calls were replaced, as follows:
> >>* gtk_main() -> g_application_run()
> >>* gtk_quit() -> g_application_quit()
> >>
> >> - Unified command line option handling:
> >>   The logic has moved from the main functions and split in three, the
> >>   common options, and specific ones for each application. With this, the
> >>   main functions were highly simplified, and now basically responsible
> >>   for instantiating the App object and running the main loop.
> >>
> >> - All Window objects must be associated with the Application, and with
> >>   this, there is no need to emit our own 'window-added' signal, it will
> >>   be done by GtkApplication by the time gtk_application_add_window() is
> >>   called. The 'window-removed' signal has also been removed, as it was
> >>   not being used anyway.
> > 
> > GApplication was added in glib 2.28, but some of the API you are using (
> > g_application_add_option_group ) was added as recently as glib 2.40.
> > configure.ac needs to be updated to reflect this, or some alternatives
> > need to be considered if the glib 2.40 is too new (el7.0 had a too old
> > glib, el7.1 is fine, fedora 21 and newer are fine too).
> 
> Ok, I will update configure.ac too

No, we have to avoid anything from 2.40 - the newest glib we can use
based on major distro support is going to be 2.38, as I don't think
it is reasonable to drop support for current SLES.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH 3/4] Port to GtkApplication API's

[Daniel P. Berrange]

On Wed, Dec 02, 2015 at 06:25:12PM -0700, Jim Fehlig wrote:
> On 12/02/2015 04:15 AM, Daniel P. Berrange wrote:
> > Yep, we need to agree which min platform we're targetting. It is nice
> > to see RHEL7 rebasing GTK, as that makes life easier. We should not
> > only consider RHEL though. It would be desirable if someone can provide
> > a list of GTK versions in current SLES,
> 
> SLES11: glib 2.22, gtk 2.18.9
> SLES12: glib 2.38, gtk 3.10.9
> 
> SLES11 builds for newer virt-viewer are already disabled.

Debian Jessie has glib 2.42, gtk 3.14.5

Ubuntu LTS 14.04 has glib 2.40.0, gtk 3.10.8

RHEL-7.1 has glib 2.40.0, gtk 3.8.8

The lowest common denominator across these major distros is

  glib 2.38
  gtk  3.8.8

So I think that is what virt-viewer should be sticking to as minimum
versions.

For glib we should make sure we set  GLIB_VERSION_MIN_REQUIRED and
GLIB_VERSION_MAX_ALLOWED to match the min version, so that we don't
accidentally introduce use of newer functions.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

[virt-tools-list] ANNOUNCE: virt-viewer 3.0 release

[Daniel P. Berrange]

I am happy to announce a new release of virt-viewer, version 3.0:

  http://virt-manager.org/download/sources/virt-viewer/virt-viewer-3.0.tar.gz

This release also includes semi-experimental MSI installers for the
Win32 (x86) and Win64 (x64) platforms:

  http://virt-manager.org/download/sources/virt-viewer/virt-viewer-x86-3.0.msi
  http://virt-manager.org/download/sources/virt-viewer/virt-viewer-x64-3.0.msi

All are signed with key DAF3 A6FD B26B 6291 2D0E  8E3F BE86 EBB4 1510 4FDF  
(4096R)

  
http://virt-manager.org/download/sources/virt-viewer/virt-viewer-3.0.tar.gz.asc
  
http://virt-manager.org/download/sources/virt-viewer/virt-viewer-x86-3.0.msi.asc
  
http://virt-manager.org/download/sources/virt-viewer/virt-viewer-x64-3.0.msi.asc

All historical releases are available from:

  http://virt-manager.org/download/

Changes in this release include:

  - Last release to support GTK2 for Linux. The next
4.0 release will be GTK3 only.
  - Don't add URI scheme / path info to oVirt URIs
  - Require spice-gtk >= 0.30
  - Enable webdav folder sharing with spice
  - Add preferences UI dialog
  - Take --direct into account when checking if guest is
reachable
  - Take SPICE proxy into account when connecting to oVirt
instances
  - Fail gracefully when hostname is not returned by
oVirt
  - Don't show empty foreign menu on secondary displays
  - Avoid accidentally trying to connect to port 0 when
oVirt doesn't specify a port number
  - Correctly update geometry when enabling/disabling
display heads
  - Avoid accidentally creating extra monitors when using
configuration file monitor mapping
  - Exit normally when cancelling connect dialog
  - Don't wait for a guest that we know will never show up
  - Fix crash when using --reconnect with SPICE
  - Avoid zooming out if it would decrease window size
below minimum required for top menu display
  - Fix crash when disabling last enabled display
  - Honour changes in display position from guest
  - Don't show error dialog twice for unknown graphics type
  - Allow to cancel oVirt auth without error
  - Set sensitivity of display menu based on whether it is
usable or not
  - Set sensitivity of tool bar buttons based on whether they
are usable or not
  - Set guest name reported by VNC
  - Fix crash when using gtk-vnc 0.3.8
  - Fix alt-tab behaviour in choose VM dialog
  - Don't allow missing display in monitor mapping config
  - Add --with-osid flag to configure to allow specifying
the operating system build target. The values should
be based on libosinfo OS short IDs.
  - Ensure windows installer places menu icon for all users
not just admin. Requires manual uninstall of previous
windows version
  - Require address in remote viewer connect dialog
  - Automatically retry VNC connection after auth failure
  - Drop GTK2 support for Windows builds
  - Enable keepalives on libvirt connection
  - Allow resize of window to arbitrary size
  - Fix thread safety handling event callbacks
  - Avoid deprecation warnings with newer glib
  - Pulled in multiple fixes for event loop from libvirt-glib
  - Fix misc bugs reported by coverity
  - Fix binary ID in MSI installer
  - Stop polling libvirt after reconnecting to libvirt

Thanks to everyone who contributed patches towards this release

NOTE: again this is the *last* release to support GTK-2. From here
onwards it is going to be GTK-3 only.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH 2/2] autobuild: gtk2 has been dropped for windows

[Daniel P. Berrange]

On Tue, Dec 01, 2015 at 09:40:04PM +0100, Fabiano Fidêncio wrote:
> On Mon, Nov 30, 2015 at 4:39 PM, Christophe Fergeau  
> wrote:
> > ACK
> 
> I didn't push this one because it's a bit critical IMHO and I will
> explain why :-)
> A few months ago I dropped gtk2 support from the Windows builds in
> order to avoid maintenance of a code that is not being used as, for
> Windows builds, we have been using gtk3 since 2.0.
> The only problem with the gtk3 approach is that Windows XP support has
> been dropped (I found it out after posting this patch, while debugging
> a non-related crash). So, if we go for a gtk3 build we automatically
> are dropping Windows XP support as well.
> 
> So, I'd like to hear from everyone (also including Daniel) if I should
> revert those patches removing gtk2 support for windows and with that
> have a last release with Windows XP support or if we are okay dropping
> Windows XP support.

If anyone is mad enough to still use ancient outdated unsupported
Windows XP, they should be just fine using an ancient outdated
unsupported virt-viewer version too. IOW I don't care about dropping
support for XP.


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH 3/4] Port to GtkApplication API's

[Daniel P. Berrange]

On Wed, Dec 02, 2015 at 12:09:56PM +0100, Christophe Fergeau wrote:
> Hey,
> 
> On Fri, Nov 27, 2015 at 05:24:00PM -0200, Eduardo Lima (Etrunko) wrote:
> > Most of this patch consists in code being shuffled around to fit the
> > expected flow while using the new APIs. I tried my best to make this
> > patch the less intrusive as possible. Main changes are:
> > 
> > - VirtViewerApp is now a subclass of GtkApplication
> > 
> >   Also, some mainloop calls were replaced, as follows:
> >* gtk_main() -> g_application_run()
> >* gtk_quit() -> g_application_quit()
> > 
> > - Unified command line option handling:
> >   The logic has moved from the main functions and split in three, the
> >   common options, and specific ones for each application. With this, the
> >   main functions were highly simplified, and now basically responsible
> >   for instantiating the App object and running the main loop.
> > 
> > - All Window objects must be associated with the Application, and with
> >   this, there is no need to emit our own 'window-added' signal, it will
> >   be done by GtkApplication by the time gtk_application_add_window() is
> >   called. The 'window-removed' signal has also been removed, as it was
> >   not being used anyway.
> 
> GApplication was added in glib 2.28, but some of the API you are using (
> g_application_add_option_group ) was added as recently as glib 2.40.
> configure.ac needs to be updated to reflect this, or some alternatives
> need to be considered if the glib 2.40 is too new (el7.0 had a too old
> glib, el7.1 is fine, fedora 21 and newer are fine too).

Yep, we need to agree which min platform we're targetting. It is nice
to see RHEL7 rebasing GTK, as that makes life easier. We should not
only consider RHEL though. It would be desirable if someone can provide
a list of GTK versions in current SLES, Ubuntu LTS, Debian and RHEL7
updates, and we can thus make sure we don't pick something that excludes
a major distro's current long term release (I'm assuming all the non-LTS
distros will be just fine since they track current state of art).

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

[virt-tools-list] [virt-viewer] plan for 3.0 release and dropping GTK2 support

[Daniel P. Berrange]

We made the last release (v2.0) way back in Jan this year. There are plenty
of patches accumulated in GIT since then, so we're way overdue for making
a new release.

Thus I'd suggest that we plan to make a v3.0 release in 1 week time on
Wed Dec 2nd.  With that in mind any pending patches should be reviewed
and merged in the next few days.

Furthermore, I suggest that we officially declare 3.0 release to be
the *LAST* main line release to support GTK2 and GTK3 in parallel.
ie the relase 4.0 should be GTK3 only.

If we need to do further fixes for GTK2, we can create a v2.0-maint
branch and have minor point releases (2.1, 2.2, etc) for that purpose,
but the bulk of new development be GTK3 focused.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH v2 0/6] [virt-viewer] Some cosmetic fixes

[Daniel P. Berrange]

On Wed, Nov 04, 2015 at 12:32:41PM -0200, Eduardo Lima (Etrunko) wrote:
> Resend of my cleanup series, please take a look. In this new version,
> I have found what was causing the errors running autogen.sh and updated
> git.mk from upstream.

This series broke the build on older RHEL because the m4/ directory
no longer exists in a clean checkout. The solution is to mkdir -p m4
in autogen.sh.

It also fails 'make syntax-check' on all platforms - please ensure
'make sytnax-check' passes before pushing any code to git master.

I've pushed changes to fix both these build problems.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] virt-viewer dependency on newer spice-gtk

[Daniel P. Berrange]

On Tue, Oct 13, 2015 at 10:23:22AM -0500, Jonathon Jongsma wrote:
> On Mon, 2015-10-12 at 17:51 +0100, Daniel P. Berrange wrote:
> > On Mon, Oct 12, 2015 at 11:46:05AM -0500, Jonathon Jongsma wrote:
> > > On Mon, 2015-10-12 at 14:54 +0100, Daniel P. Berrange wrote:
> > > > On Mon, Oct 12, 2015 at 08:50:12AM -0500, Jonathon Jongsma wrote:
> > > > > On Mon, 2015-10-12 at 10:26 +0100, Daniel P. Berrange wrote:
> > > > > > On Fri, Oct 09, 2015 at 04:15:13PM -0500, Jonathon Jongsma wrote:
> > > > > > > Unfortunately, there was no single-header include for the GTK+ 
> > > > > > > library
> > > > > > > until just recently (spice-client-gtk.h), so this requires 
> > > > > > > bumping the
> > > > > > > spice-gtk version requirement to a unreleased git version.
> > > > > > 
> > > > > > IIUC this is going to prevent virt-viewer being built against 
> > > > > > existing
> > > > > > released of spice. I think this is a rather unpleasant API break for
> > > > > > SPICE to force on client programs.
> > > > > > 
> > > > > > I would really expect there to be several releases where SPICE 
> > > > > > provided
> > > > > > the new single-header that apps could use, while *also* allowing 
> > > > > > apps
> > > > > > to continue to include the more specific headers. ie, give apps some
> > > > > > grace time to switch over to the new style. Can you try and re-visit
> > > > > > this in SPICE first.
> > > > > 
> > > > > Actually, the only changes I have pushed to spice are those that:
> > > > > 
> > > > > - add this new spice-client-gtk.h master header
> > > > > - produce a compiler #warning when including one of the sub-headers
> > > > > 
> > > > > So, at the moment, it is still possible to build virt-viewer against
> > > > > both released and unreleased (git master) spice-gtk. In the latter 
> > > > > case,
> > > > > we'll just get compile warnings. This patch adds a dependency on git
> > > > > master to try to avoid those warnings. But we can delay this patch and
> > > > > simply live with the warnings for a little while if that's what people
> > > > > prefer.
> > > > 
> > > > My general desire is that virt-viewer *always* be capable of building
> > > > against the most recent Fedora stable branch, because when I build
> > > > release binaries (eg for Win32) I don't want to be using unreleased
> > > > code or Fedora rawhide. I want to use a known good stable Fedora release
> > > > Mingw toolchain.
> > > 
> > > This dependency obviously only applies to virt-viewer in git master. Are
> > > you suggesting that virt-viewer from git should always be buildable
> > > against the version of spice-gtk in fedora? Or are you talking about
> > > virt-viewer releases? As I said, I can probably delay this patch for a
> > > while if that's what people prefer, but at the moment I'm not sure I
> > > totally understand what you're requesting.
> > 
> > What is currently in virt-viewer GIT master will become the next
> > release of virt-viewer. We don't want the next virt-viewer release
> > to be blocked on a Fedora release. Thus virt-viewer GIT master must
> > always build on most recent Fedora release.
> 
> Hmm, to me that seems overly restrictive for virt-viewer development. I
> have not followed this policy for the current development cycle and
> nobody has complained so far. Until quite recently virt-viewer did
> depend on spice-gtk from git. But Christophe packaged and built the new
> spice-gtk 0.30 very soon after it was released, and I believe it is now
> already available for fedora 22-24.

Just because no one complained doesn't make it right. When it comes to
doing the next release, if it doesn't compile on current stable
Fedora there will not be a new release created until it is fixed.
IMHO it really isn't a very onerous requirement to expect things to
build on a current released distro.


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH virt-viewer v2] Adapt to spice-gtk single-header include policy

[Daniel P. Berrange]

On Fri, Oct 09, 2015 at 04:15:13PM -0500, Jonathon Jongsma wrote:
> Unfortunately, there was no single-header include for the GTK+ library
> until just recently (spice-client-gtk.h), so this requires bumping the
> spice-gtk version requirement to a unreleased git version.

IIUC this is going to prevent virt-viewer being built against existing
released of spice. I think this is a rather unpleasant API break for
SPICE to force on client programs.

I would really expect there to be several releases where SPICE provided
the new single-header that apps could use, while *also* allowing apps
to continue to include the more specific headers. ie, give apps some
grace time to switch over to the new style. Can you try and re-visit
this in SPICE first.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH virt-viewer v2] Adapt to spice-gtk single-header include policy

[Daniel P. Berrange]

On Mon, Oct 12, 2015 at 08:50:12AM -0500, Jonathon Jongsma wrote:
> On Mon, 2015-10-12 at 10:26 +0100, Daniel P. Berrange wrote:
> > On Fri, Oct 09, 2015 at 04:15:13PM -0500, Jonathon Jongsma wrote:
> > > Unfortunately, there was no single-header include for the GTK+ library
> > > until just recently (spice-client-gtk.h), so this requires bumping the
> > > spice-gtk version requirement to a unreleased git version.
> > 
> > IIUC this is going to prevent virt-viewer being built against existing
> > released of spice. I think this is a rather unpleasant API break for
> > SPICE to force on client programs.
> > 
> > I would really expect there to be several releases where SPICE provided
> > the new single-header that apps could use, while *also* allowing apps
> > to continue to include the more specific headers. ie, give apps some
> > grace time to switch over to the new style. Can you try and re-visit
> > this in SPICE first.
> 
> Actually, the only changes I have pushed to spice are those that:
> 
> - add this new spice-client-gtk.h master header
> - produce a compiler #warning when including one of the sub-headers
> 
> So, at the moment, it is still possible to build virt-viewer against
> both released and unreleased (git master) spice-gtk. In the latter case,
> we'll just get compile warnings. This patch adds a dependency on git
> master to try to avoid those warnings. But we can delay this patch and
> simply live with the warnings for a little while if that's what people
> prefer.

My general desire is that virt-viewer *always* be capable of building
against the most recent Fedora stable branch, because when I build
release binaries (eg for Win32) I don't want to be using unreleased
code or Fedora rawhide. I want to use a known good stable Fedora release
Mingw toolchain.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH virt-viewer v2] Adapt to spice-gtk single-header include policy

[Daniel P. Berrange]

On Mon, Oct 12, 2015 at 11:46:05AM -0500, Jonathon Jongsma wrote:
> On Mon, 2015-10-12 at 14:54 +0100, Daniel P. Berrange wrote:
> > On Mon, Oct 12, 2015 at 08:50:12AM -0500, Jonathon Jongsma wrote:
> > > On Mon, 2015-10-12 at 10:26 +0100, Daniel P. Berrange wrote:
> > > > On Fri, Oct 09, 2015 at 04:15:13PM -0500, Jonathon Jongsma wrote:
> > > > > Unfortunately, there was no single-header include for the GTK+ library
> > > > > until just recently (spice-client-gtk.h), so this requires bumping the
> > > > > spice-gtk version requirement to a unreleased git version.
> > > > 
> > > > IIUC this is going to prevent virt-viewer being built against existing
> > > > released of spice. I think this is a rather unpleasant API break for
> > > > SPICE to force on client programs.
> > > > 
> > > > I would really expect there to be several releases where SPICE provided
> > > > the new single-header that apps could use, while *also* allowing apps
> > > > to continue to include the more specific headers. ie, give apps some
> > > > grace time to switch over to the new style. Can you try and re-visit
> > > > this in SPICE first.
> > > 
> > > Actually, the only changes I have pushed to spice are those that:
> > > 
> > > - add this new spice-client-gtk.h master header
> > > - produce a compiler #warning when including one of the sub-headers
> > > 
> > > So, at the moment, it is still possible to build virt-viewer against
> > > both released and unreleased (git master) spice-gtk. In the latter case,
> > > we'll just get compile warnings. This patch adds a dependency on git
> > > master to try to avoid those warnings. But we can delay this patch and
> > > simply live with the warnings for a little while if that's what people
> > > prefer.
> > 
> > My general desire is that virt-viewer *always* be capable of building
> > against the most recent Fedora stable branch, because when I build
> > release binaries (eg for Win32) I don't want to be using unreleased
> > code or Fedora rawhide. I want to use a known good stable Fedora release
> > Mingw toolchain.
> 
> This dependency obviously only applies to virt-viewer in git master. Are
> you suggesting that virt-viewer from git should always be buildable
> against the version of spice-gtk in fedora? Or are you talking about
> virt-viewer releases? As I said, I can probably delay this patch for a
> while if that's what people prefer, but at the moment I'm not sure I
> totally understand what you're requesting.

What is currently in virt-viewer GIT master will become the next
release of virt-viewer. We don't want the next virt-viewer release
to be blocked on a Fedora release. Thus virt-viewer GIT master must
always build on most recent Fedora release.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Start encrypted Image with virt-manager

[Daniel P. Berrange]

On Wed, Sep 09, 2015 at 11:14:27AM +0200, Matthias Peter Walther wrote:
> Hello,
> 
> I subscribed today, because I googled my problem and couldn't find a
> solution. Maybe you know how to do this:
> 
> I encrypted an image of mine with the option: -o encryption

Please don't do that, encryption support in QCow2 is going to be deleted
in QEMU real soon as it is broken by design

https://www.berrange.com/posts/2015/03/17/qemu-qcow2-built-in-encryption-just-say-no-deprecated-now-to-be-deleted-soon/

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Start encrypted Image with virt-manager

[Daniel P. Berrange]

On Wed, Sep 09, 2015 at 11:33:29AM +0200, Matthias Walther wrote:
> Dear Daniel,
> 
> thanks for your quick reply. What's the alternative? 
> 
> I thought maybe using standard encryption within the virtual machine
> might be slow. What's the best practice?

LUKS / dm-crypt is the only viable option right now - either set it up
on your host and unlock it before starting the guest, or run it inside
your guest. If you make sure the guest is configured with a host-model
CPU, then the guest CPU will have the 'aes' flag available and performance
should be pretty decent for guest filesystem encryption.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

[virt-tools-list] [PATCH virt-manager 0/2] Fix support for virtual port profiles

[Daniel P. Berrange]

The previously added support for virtual port profiles was
incomplete and also undocumented

Daniel P. Berrange (2):
  virtinst: support virtual port parameters for non-802.1Qbg NICs
  virt-install: document virtual port profile parameters

 man/virt-install.pod   | 85 ++
 .../compare/virt-install-many-devices.xml  |  8 ++
 tests/clitest.py   |  1 +
 virtinst/cli.py|  6 ++
 virtinst/deviceinterface.py|  2 +
 5 files changed, 102 insertions(+)

-- 
2.4.3

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

[virt-tools-list] [PATCH virt-manager 2/2] virt-install: document virtual port profile parameters

[Daniel P. Berrange]

Signed-off-by: Daniel P. Berrange berra...@redhat.com
---
 man/virt-install.pod | 85 
 1 file changed, 85 insertions(+)

diff --git a/man/virt-install.pod b/man/virt-install.pod
index fd0b0ad..b2fb019 100644
--- a/man/virt-install.pod
+++ b/man/virt-install.pod
@@ -780,6 +780,91 @@ Controlling firewall and network filtering in libvirt. 
Value can be any nwfilter
 defined by the Cvirsh 'nwfilter' subcommands. Available filters can be listed
 by running 'virsh nwfilter-list', e.g.: 'clean-traffic', 'no-mac-spoofing', ...
 
+=item Bvirtualport_type
+
+The type of virtual port profile, one the following values
+
+=over 4
+
+=item C802.Qbg
+
+The following additional parameters are accepted
+
+=over 4
+
+=item Bvirtualport_managerid
+
+
+The VSI Manager ID identifies the database containing the VSI type
+and instance definitions. This is an integer value and the value
+0 is reserved.
+
+=item Bvirtualport_typeid
+
+The VSI Type ID identifies a VSI type characterizing the network
+access. VSI types are typically managed by network administrator.
+This is an integer value.
+
+=item Bvirtualport_typeidversion
+
+The VSI Type Version allows multiple versions of a VSI Type. This
+is an integer value.
+
+=item Bvirtualport_instanceid
+
+The VSI Instance ID Identifier is generated when a VSI instance
+(i.e. a virtual interface of a virtual machine) is created. This
+is a globally unique identifier.
+
+=back
+
+=item C802.Qbh
+
+The following additional parameters are accepted
+
+=over 4
+
+=item Bvirtualport_profileid
+
+The profile ID contains the name of the port profile that is to
+be applied to this interface. This name is resolved by the port
+profile database into the network parameters from the port profile,
+and those network parameters will be applied to this interface.
+
+=back
+
+=item Copenvswitch
+
+The following additional parameters are accepted
+
+=over 4
+
+=item Bvirtualport_profileid
+
+The OpenVSwitch port profile for the interface
+
+=item Bvirtualport_interfaceid
+
+A UUID to uniquely identify the interface. If omitted one will
+be generated automatically
+
+=back
+
+=item Cmidonet
+
+The following additional parameters are accepted
+
+=over 4
+
+=item Bvirtualport_interfaceid
+
+A UUID identifying the port in the network to which the interface
+will be bound
+
+=back
+
+=back
+
 =back
 
 Use --network=? to see a list of all available sub options. Complete details 
at Lhttp://libvirt.org/formatdomain.html#elementsNICS
-- 
2.4.3

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

[virt-tools-list] [PATCH virt-manager 1/2] virtinst: support virtual port parameters for non-802.1Qbg NICs

[Daniel P. Berrange]

Previous commit added support for virtual port profiles
on NICs, but only defined the attributes needed by the
802.1Qbg NIC type.

  commit 34e2ca8389ddf1c764109c4e5c74f8fd5bf0e604
  Author: Cole Robinson crobi...@redhat.com
  Date:   Fri Jan 31 16:51:02 2014 -0500

cli: --network: Wire up virtualport options

This commit adds the profileid and interfaceid parameters
needed by 801.Qbh, openvswitch and midonet

Signed-off-by: Daniel P. Berrange berra...@redhat.com
---
 tests/cli-test-xml/compare/virt-install-many-devices.xml | 8 
 tests/clitest.py | 1 +
 virtinst/cli.py  | 6 ++
 virtinst/deviceinterface.py  | 2 ++
 4 files changed, 17 insertions(+)

diff --git a/tests/cli-test-xml/compare/virt-install-many-devices.xml 
b/tests/cli-test-xml/compare/virt-install-many-devices.xml
index cf77888..1cb4b3f 100644
--- a/tests/cli-test-xml/compare/virt-install-many-devices.xml
+++ b/tests/cli-test-xml/compare/virt-install-many-devices.xml
@@ -168,6 +168,14 @@
   model type=virtio/
   driver name=qemu queues=3/
 /interface
+interface type=bridge
+  source bridge=ovsbr/
+  mac address=00:11:22:33:44:55/
+  model type=virtio/
+  virtualport type=openvswitch
+parameters profileid=demo 
interfaceid=09b11c53-8b5c-4eeb-8f00-d84eaa0aaa3b/
+  /virtualport
+/interface
 interface type=direct
   source dev=eth5 mode=vepa/
   mac address=00:11:22:33:44:55/
diff --git a/tests/clitest.py b/tests/clitest.py
index ccd15bc..2c87804 100644
--- a/tests/clitest.py
+++ b/tests/clitest.py
@@ -460,6 +460,7 @@ c.add_compare( \
 \
 --network user,mac=12:34:56:78:11:22,portgroup=foo \
 --network bridge=foobar,model=virtio,driver_name=qemu,driver_queues=3 \
+--network 
bridge=ovsbr,virtualport_type=openvswitch,virtualport_profileid=demo,virtualport_interfaceid=09b11c53-8b5c-4eeb-8f00-d84eaa0aaa3b
 \
 --network 
type=direct,source=eth5,source_mode=vepa,target=mytap12,virtualport_type=802.1Qbg,virtualport_managerid=12,virtualport_typeid=1193046,virtualport_typeidversion=1,virtualport_instanceid=09b11c53-8b5c-4eeb-8f00-d84eaa0aaa3b,boot_order=1
 \
 \
 --graphics sdl \
diff --git a/virtinst/cli.py b/virtinst/cli.py
index 22123d8..f5ed1c2 100644
--- a/virtinst/cli.py
+++ b/virtinst/cli.py
@@ -1761,12 +1761,18 @@ class ParserNetwork(VirtCLIParser):
 self.set_param(driver_queues, driver_queues)
 
 self.set_param(virtualport.type, virtualport_type)
+
+# For vepa
 self.set_param(virtualport.managerid, virtualport_managerid)
 self.set_param(virtualport.typeid, virtualport_typeid)
 self.set_param(virtualport.typeidversion,
 virtualport_typeidversion)
 self.set_param(virtualport.instanceid, virtualport_instanceid)
 
+# For openvswitch
+self.set_param(virtualport.profileid, virtualport_profileid)
+self.set_param(virtualport.interfaceid, virtualport_interfaceid)
+
 def _parse(self, optsobj, inst):
 if optsobj.fullopts == none:
 return
diff --git a/virtinst/deviceinterface.py b/virtinst/deviceinterface.py
index cabd656..78143a9 100644
--- a/virtinst/deviceinterface.py
+++ b/virtinst/deviceinterface.py
@@ -60,6 +60,8 @@ class VirtualPort(XMLBuilder):
 typeid = XMLProperty(./parameters/@typeid, is_int=True)
 typeidversion = XMLProperty(./parameters/@typeidversion, is_int=True)
 instanceid = XMLProperty(./parameters/@instanceid)
+profileid = XMLProperty(./parameters/@profileid)
+interfaceid = XMLProperty(./parameters/@interfaceid)
 
 
 class VirtualNetworkInterface(VirtualDevice):
-- 
2.4.3

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH virt-manager 1/2] virtinst: support virtual port parameters for non-802.1Qbg NICs

[Daniel P. Berrange]

On Fri, Aug 28, 2015 at 12:26:30PM +0100, Daniel P. Berrange wrote:
 diff --git a/virtinst/cli.py b/virtinst/cli.py
 index 22123d8..f5ed1c2 100644
 --- a/virtinst/cli.py
 +++ b/virtinst/cli.py
 @@ -1761,12 +1761,18 @@ class ParserNetwork(VirtCLIParser):
  self.set_param(driver_queues, driver_queues)
  
  self.set_param(virtualport.type, virtualport_type)
 +
 +# For vepa
  self.set_param(virtualport.managerid, virtualport_managerid)
  self.set_param(virtualport.typeid, virtualport_typeid)
  self.set_param(virtualport.typeidversion,
  virtualport_typeidversion)
  self.set_param(virtualport.instanceid, virtualport_instanceid)
  
 +# For openvswitch
 +self.set_param(virtualport.profileid, virtualport_profileid)
 +self.set_param(virtualport.interfaceid, virtualport_interfaceid)

FYI I tweaked the comment here to mention midonet  distinguish qbg vs qbh vepa
modes before I pushed to git.


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] How to make virt-manager targets the correct qemu emulators

[Daniel P. Berrange]

On Thu, Jun 25, 2015 at 01:34:32AM +, Gabriel Laupre wrote:
 Hello,
 
 I have an old version of qemu installed under the path /usr/bin/. I am
 using a Centos 7 machine.
 I just got the last qemu code and made some modifications, recompiled it
 and I have my qemu emulators under /usr/local/bin.
 
 When I launch the virt-manager, it seems that it targets the old one under
 /usr/bin/ and I want to change that the virt-manager will use my new one
 under /usr/local/bin.
 
 Where can I specify this information?

virt-manager relies on libvirt to tell it which emulator to use by
default. Libvirt search $PATH for emulators. So you need to make
sure your /usr/local/bin appears before /usr/bin in the $PATH seen
by libvirtd.


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list