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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
