This class is used to implement the so-called oVirt 'foreign menu'
which is a menu populated with ISO images available on the
oVirt instance that the user can dynamically insert into the
virtual machine he is currently viewing.
This silences an automake 1.14 warning:
src/Makefile.am:35: warning: source file 'view/autoDrawer.c' is in a
subdirectory,
src/Makefile.am:35: but option 'subdir-objects' is disabled
automake: warning: possible forward-incompatibility.
automake: At least a source file is in a subdirectory, but the
'subdir-objects'
automake: automake option hasn't been enabled. For now, the
corresponding output
automake: object file(s) will be placed in the top-level directory.
However,
automake: this behaviour will change in future Automake versions: they
will
automake: unconditionally cause object files to be placed in the same
subdirectory
automake: of the corresponding sources.
automake: You are advised to start using 'subdir-objects' option
throughout your
automake: project, to avoid future incompatibilities.
The Windows MSI product version is restricted to a 3 component
version number, whose fields are a max value of 255.255.65536
Since the main virt-viewer version takes up 3 components already,
we have the munge the micro version together with the first
component of the release version. eg we have
$VERSION[0].$VERSION[1].($VERSION[2] << 8 + $RELEASE[0])
This causes problems for RHEL which needs to have 2-component
release versions to deal with z-stream builds. eg a RHEL
version might be virt-viewer-0.5.6-2.el6_4.3 and we've
no easy way of adding the final '.3' to the Windows product
version.
If we reduce the primary virt-viewer version to just 2 components,
then we can leave the 3rd component for exclusive use by the RPM
release number. eg so we'd make product version up using
$VERSION[0].$VERSION[1].($RELEASE[0] << 8 + $RELEASE[1])
In course of normal development, we'd increase the $VERSION[0]
for each release. ie next release is 1.0, then 2.0, then 3.0.
This means we retain the ability to put out "stable" branch
releases for any historical version by doing 1.1, 1.2 instead
of having to re-add a 3rd component.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
When using the --with-buildid configure paramater, the build id which is
substituted in the MSI wxs file is automatically prepended by a '-', but
the build id which is used in the C files does not get this '-'
automatically.
Currently, the linux and mingw spec files prepend a '-' on their own to the
--with-buildid argument, but this causes the MSI installer to show 2 '-'
during installation: "Please wait while Windows configures VirtViewer
0.6.0--1"
This commit always prepends a '-' to the buildid strings, and removes the
'-' from the spec files. This is to ensure the separator between version
number and buildid is not forgotten, which could give a confusing version
number.
remomte-viewer installs a file to $datadir/share/mime to register a
mime-type for its .vv files. However, after installing this file,
update-mime-database must be run in order to update the shared mime
database. This commit (inspired by what Nautilus/planner are doing) adds
what is needed for that.
If the mime type is not correctly registered, gvfs-info console.vv will not
return the correct mime type, and xdg-open console.vv will fail to start
remote-viewer, and will fall back to running gedit as the .vv file is a
text file.
https://bugzilla.redhat.com/show_bug.cgi?id=1044209
virt-viewer currenty builds with gtk+ 2.0 by default. Nowadays, gtk+ 2.0 is
legacy, and this default is inconsistent with spice-gtk which defaults to
gtk+ 3.0. This commit switches the default to gtk+ 3.0
Windows Installer expects version of form major.minor.build in order to
perform updates.
Following Daniel Berrange suggestion, compute a ProductVersion
compatible with this scheme by shifting virt-viewer "micro" release
number and adding the extra "buildid".
For some VMs, setting host subject on SpiceSession is needed to
be able to connect to it using SPICE/SSL. Until recently, this
was not exposed in oVirt REST API/libgovirt. Since
oVirt 3.2/libgovirt 0.1.0, the host subject is available, this
patch makes use of it.
This should fix connection to oVirt VMs that were migrated to a
different host than the one they were started on.
They don't need to be wrapped inside if HAVE_XXX blocks in Makefile.am
as when XXX is not available, XXX_CFLAGS and XXX_LIBS will expand to
the empty string, and thus we can carry them unconditionally in
our app_CFLAGS/app_LDFLAGS variables.
The browser plugin code has been effectively unmaintained since
the day it was merged. There has always been a caveat that the
code has not been properly audited to ensure it is secure, and
being unmaintained doesn't give a warm secure feeling. These
days there are better solutions for the browser which are pure
HTML5 code, noVNC and SPICE-HTML5.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
In order to build the MSI, you will need msitools:
http://ftp.gnome.org/pub/GNOME/sources/msitools/
The MANUFACTURER environment variable is mandatory and should be set
to the manufacturer/author of the MSI build.
Add a configure argument to append build version details, similar to
what Daniel Berrange proposed in the "use finer package version in
mingw-virt-viewer" thread on the ML.
This installer will provide with the tools and configuration needed to
debug virt-viewer & remote-viewer. It will install itself by default in
virt-viewer directory.
The check that at least one of spice-gtk and gtk-vnc is present
uses a wrong variable name to check for spice-gtk presence, which
causes the check to think it's never present. This would make
gtk-vnc presence mandatory. This commit fixes the name of the
spice-gtk variable ($have_gtk_spice -> $have_spice_gtk).
Currently, if user wants to reconnect to a domain he can use
'-r' cmd line argument. This makes virt-viewer listen to
domain events. However, if connection to libvirtd breaks
somehow, we will receive no longer any event. Hence we must
reconnect to the libvirt.
Some distros (a 4-letters) don't have icotool.
Let's ship the .ico in the tarball.
The build will fail if icoutil is not installed when
building from git or when the .ico is absent. The error
should be explicit.
Builds are failing with an obscure error message
make[3]: Entering directory `/var/lib/builder/source-root/virt-viewer/build/icons'
GEN virt-viewer.ico
/bin/sh: -c: command not found
make[3]: *** [virt-viewer.ico] Error 127
This is because configure.ac does not enforce that icotool
is present on Win32.
* configure.ac: Mandate windres & icotool on Win32
This makefile is just fantastic, it forces you into good practices,
support various build targets (my windows builddir ignore the right
files etc..)
The more I use it, the more I like it.
We require libvirt >= 0.9.7 to get virDomainOpenGraphics
We require spice-gtk >= 0.11 to get the fix for dealing with
authentication over an SSH tunnel
We requires spice-protocol >= 0.10.1 to get a constant
required by USB redirection
When running ./autogen.sh on a pristine git checkout, I got:
libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
You should add the contents of '/usr/share/aclocal/intltool.m4' to 'aclocal.m4'.
