To ease debugging this trivial patch allows to find what was compiled in in the local version of libvirt, this doesn't work for remote access but that's probably sufficient. With the patch I get on my machine: paphio:~/libvirt/tools -> ./virsh --version Virsh command line tool of libvirt 0.8.4 See web site at http://libvirt.org/ Compiled with support for: Hypervisors: Xen QEmu/KVM UML OpenVZ LXC ESX PHYP Test Networking: Remote Daemon Network Bridging Netcf Nwfilter Storage: Dir Disk Filesystem SCSI Multipath iSCSI LVM Miscellaneous: SELinux Secrets Debug Readline paphio:~/libvirt/tools -> instead of just "0.8.4"

On 10/28/2010 07:13 AM, Daniel P. Berrange wrote: > On Thu, Oct 28, 2010 at 03:00:45PM +0200, Daniel Veillard wrote: >> To ease debugging this trivial patch allows to find what was compiled >> in in the local version of libvirt, this doesn't work for remote access >> but that's probably sufficient. With the patch I get on my machine: >> >> paphio:~/libvirt/tools -> ./virsh --version >> Virsh command line tool of libvirt 0.8.4 >> See web site at http://libvirt.org/ >> >> Compiled with support for: >> Hypervisors: Xen QEmu/KVM UML OpenVZ LXC ESX PHYP Test >> Networking: Remote Daemon Network Bridging Netcf Nwfilter >> Storage: Dir Disk Filesystem SCSI Multipath iSCSI LVM >> Miscellaneous: SELinux Secrets Debug Readline >> paphio:~/libvirt/tools -> >> >> instead of just "0.8.4" > > Hmm, if any script is running the current 'virsh --version' command > to get the version number then this will break their usage. I think > we should require a different and/or extra flag to print the > extended data. --version is not a great place since this isn't > really version information. > We already have: $ virsh version Compiled against library: libvir 0.8.2 Using library: libvir 0.8.2 Using API: QEMU 0.8.2 Running hypervisor: QEMU 0.12.5 Can we just beef that up, and leave 'virsh --version' as the short information?

Compiled with support for: Hypervisors: Xen QEmu/KVM UML OpenVZ LXC ESX PHYP Test Networking: Remote Daemon Network Bridging Netcf Nwfilter Storage: Dir Disk Filesystem SCSI Multipath iSCSI LVM Miscellaneous: SELinux Secrets Debug Readline

[adding bug-gnulib] On 10/28/2010 01:25 PM, Daniel Veillard wrote: >>> case 'v': >>> - /* FIXME - list a copyright blurb, as in GNU programs? */ >>> - puts(VERSION); >>> + vshShowVersion(ctl); >>> exit(EXIT_SUCCESS); >> >> Pre-existing bug - we don't detect write failure to stdout to exit with >> non-zero status. Unchanged by your patch. > > Not sure it's really a problem, but okay I will look. The gnulib module closeout can automatically take care of this, but it is currently licensed as GPL. Jim, Bruno, are you okay with relicensing closeout and close-stream as LGPLv2+?

Hi Eric, > >>> case 'v': > >>> - /* FIXME - list a copyright blurb, as in GNU programs? */ > >>> - puts(VERSION); > >>> + vshShowVersion(ctl); > >>> exit(EXIT_SUCCESS); > > The gnulib module closeout can automatically take care of this, but it > is currently licensed as GPL. Jim, Bruno, are you okay with relicensing > closeout and close-stream as LGPLv2+? In gnulib we have a rule of thumb which says that anything that calls exit() or xmalloc() is likely to end up only in executables, not in libraries, and code in executables can just as well be relicensed under GPL instead of LGPL.

In the libiconv and gettext packages, for example, the executables are all under GPL, although other parts of the package are under LGPL. Have you (and the management and lawyers behind libvirt) considered this approach for libvirt? I ask because 'closeout' may be only the beginning. Then comes 'xalloc', 'quotearg', and 'avltree-list', and at the end these high-value modules could be used by proprietary programs (assuming appropriate LGPL compliant packaging). We need a borderline between what can go LGPL and what needs to stay GPL, and the rule of thumb mentioned above is a good guiding line.