I've checked out the source virt*, but I cannot tell that it's newer than I have.
The changelog for virt-manager suggests not.
Mercurial doesn't set file times to those on the server, so they reflect when I checked it out rather than what's in the repo.
I planned to build from source and install to /usr/local, but this suggests my idea is impractical:
virtinst--devel/virtinst/ParaVirtGuest.py: cmd = ["/usr/bin/virsh", "console", "%s" %(self.domain.ID(),)]
Surely, the location of executable components should not be hard-coded in the source tree. I could live with it, grudgingly, if it was set at configure time.
I can't give you any good information on the source and configure options and whatnot, but assuming that there is a hardcoded executable path that doesn't match where you want to build to, wouldn't a hardlink do the trick? On the other hand, if the install path in the source you want to build is hardcoded, I guess I have no thoughts, but hopefully someone does. Dustin
-----Original Message----- From: fedora-xen-bounces@redhat.com [mailto:fedora-xen-bounces@redhat.com] On Behalf Of John Summerfield Sent: Wednesday, January 09, 2008 18:06 To: Fedora Xen Subject: [Fedora-xen] virt* source
I've checked out the source virt*, but I cannot tell that it's newer than I have.
The changelog for virt-manager suggests not.
Mercurial doesn't set file times to those on the server, so they reflect when I checked it out rather than what's in the repo.
I planned to build from source and install to /usr/local, but this suggests my idea is impractical:
virtinst--devel/virtinst/ParaVirtGuest.py: cmd = ["/usr/bin/virsh", "console", "%s" %(self.domain.ID(),)]
Surely, the location of executable components should not be hard-coded in the source tree. I could live with it, grudgingly, if it was set at configure time.
Dustin Henning wrote:
I can't give you any good information on the source and configure options and whatnot, but assuming that there is a hardcoded executable path that doesn't match where you want to build to, wouldn't a hardlink do the trick? On the other hand, if the install path in the source you want to build is hardcoded, I guess I have no thoughts, but hopefully someone does. Dustin
/usr/bin belongs to the package manager (rpm here, dpkg on debian). The hard-coded path means my self-built version would run the packaged virsh instead of the one I built.
John Summerfield wrote:
I've checked out the source virt*, but I cannot tell that it's newer than I have.
The changelog for virt-manager suggests not.
Mercurial doesn't set file times to those on the server, so they reflect when I checked it out rather than what's in the repo.
The changelog isn't updated frequently, usually only with releases. To see actual changes and the times they were made, use the 'hg log' command in the checked out repo.
I planned to build from source and install to /usr/local, but this suggests my idea is impractical:
virtinst--devel/virtinst/ParaVirtGuest.py: cmd = ["/usr/bin/virsh", "console", "%s" %(self.domain.ID(),)]
Surely, the location of executable components should not be hard-coded in the source tree. I could live with it, grudgingly, if it was set at configure time.
I don't really know the solution to that. If virt-install pulled 'virsh' from the shell path, /usr/local would take precedence. But there may be drawbacks to that which I dont know.
- Cole
Cole Robinson wrote:
John Summerfield wrote:
I've checked out the source virt*, but I cannot tell that it's newer than I have.
The changelog for virt-manager suggests not.
Mercurial doesn't set file times to those on the server, so they reflect when I checked it out rather than what's in the repo.
The changelog isn't updated frequently, usually only with releases. To see actual changes and the times they were made, use the 'hg log' command in the checked out repo.
Thanks, looks much better. Several changes I see hit problems I've seen.
I planned to build from source and install to /usr/local, but this suggests my idea is impractical:
virtinst--devel/virtinst/ParaVirtGuest.py: cmd = ["/usr/bin/virsh", "console", "%s" %(self.domain.ID(),)]
Surely, the location of executable components should not be hard-coded in the source tree. I could live with it, grudgingly, if it was set at configure time.
I don't really know the solution to that. If virt-install pulled 'virsh' from the shell path, /usr/local would take precedence. But there may be drawbacks to that which I dont know.
It should use $PATH, but does not. See my reply to Richard's. I can't test bleeding-edge without upsetting standard F8 versions.
John Summerfield wrote:
virtinst--devel/virtinst/ParaVirtGuest.py: cmd = ["/usr/bin/virsh", "console", "%s" %(self.domain.ID(),)]
Surely, the location of executable components should not be hard-coded in the source tree. I could live with it, grudgingly, if it was set at configure time.
Agreed -- this is simply a bug in virt-manager.
Rich.
Richard W.M. Jones wrote:
John Summerfield wrote:
virtinst--devel/virtinst/ParaVirtGuest.py: cmd = ["/usr/bin/virsh", "console", "%s" %(self.domain.ID(),)]
Surely, the location of executable components should not be hard-coded in the source tree. I could live with it, grudgingly, if it was set at configure time.
Agreed -- this is simply a bug in virt-manager.
There are a few other places the virt* programs have fixed ideas about where stuff must be: [summer@potoroo virt]$ find * -type f -exec grep -HE '/usr/(|s)bin' {} ; | grep -Ev '/usr/bin/(perl|python)' Binary file virt-manager--devel/.hg/store/data/src/gnome-virt-manager.in.i matches virt-manager--devel/autobuild.sh:if [ -f /usr/bin/rpmbuild ]; then virt-manager--devel/src/virt-manager.py.in: elif os.path.exists("/usr/bin/qemu"): virt-viewer--devel/autobuild.sh:if [ -f /usr/bin/rpmbuild ]; then virt-viewer--devel/virt-viewer.spec.in:BuildRequires: /usr/bin/pod2man virtinst--devel/tests/boot-paravirt-disk-file.xml: <bootloader>/usr/bin/pygrub</bootloader> virtinst--devel/tests/boot-paravirt-many-disks.xml: <bootloader>/usr/bin/pygrub</bootloader> virtinst--devel/tests/boot-paravirt-disk-drv-tap-qcow.xml: <bootloader>/usr/bin/pygrub</bootloader> virtinst--devel/tests/boot-paravirt-disk-drv-phy.xml: <bootloader>/usr/bin/pygrub</bootloader> virtinst--devel/tests/boot-paravirt-disk-drv-file.xml: <bootloader>/usr/bin/pygrub</bootloader> virtinst--devel/tests/boot-paravirt-disk-drv-tap.xml: <bootloader>/usr/bin/pygrub</bootloader> virtinst--devel/tests/capabilities-qemu.xml: <emulator>/usr/bin/qemu-system-x86_64</emulator> virtinst--devel/tests/capabilities-qemu.xml: <emulator>/usr/bin/qemu</emulator> virtinst--devel/tests/capabilities-qemu.xml: <emulator>/usr/bin/qemu-system-mips</emulator> virtinst--devel/tests/capabilities-qemu.xml: <emulator>/usr/bin/qemu-system-mipsel</emulator> virtinst--devel/tests/capabilities-qemu.xml: <emulator>/usr/bin/qemu-system-sparc</emulator> virtinst--devel/tests/capabilities-qemu.xml: <emulator>/usr/bin/qemu-system-ppc</emulator> virtinst--devel/tests/boot-paravirt-disk-block.xml: <bootloader>/usr/bin/pygrub</bootloader> virtinst--devel/autobuild.sh:if [ -f /usr/bin/rpmbuild ]; then virtinst--devel/virtinst/util.py: elif os.path.exists("/usr/bin/qemu"): virtinst--devel/virtinst/util.py: for dir in ['', '/sbin/', '/usr/sbin']: virtinst--devel/virtinst/ImageManager.py: osblob += " <bootloader>/usr/bin/pygrub</bootloader>" virtinst--devel/virtinst/ParaVirtGuest.py: cmd = ["/usr/bin/virsh", "console", "%s" %(self.domain.ID(),)] virtinst--devel/virtinst/DistroManager.py: osblob += "<bootloader>/usr/bin/pygrub</bootloader>" virtinst--devel/virtinst/DistroManager.py: osblob += "<bootloader>/usr/bin/pygrub</bootloader>" virtinst--devel/virt-install: args = ["/usr/bin/virt-viewer"] virtinst--devel/virt-install: args = ["/usr/bin/virsh"] virtinst--devel/ChangeLog: 'distro' Traceback (most recent call last): File "/usr/bin/virt- virtinst--devel/ChangeLog: install", line 647, in <module> main() File "/usr/bin/virt- virtinst--devel/ChangeLog: Move virt-install & virt-clone to /usr/bin instead of sbin since [summer@potoroo virt]$
John Summerfield wrote:
Richard W.M. Jones wrote:
John Summerfield wrote:
virtinst--devel/virtinst/ParaVirtGuest.py: cmd = ["/usr/bin/virsh", "console", "%s" %(self.domain.ID(),)]
Surely, the location of executable components should not be hard-coded in the source tree. I could live with it, grudgingly, if it was set at configure time.
Agreed -- this is simply a bug in virt-manager.
There are a few other places the virt* programs have fixed ideas about where stuff must be: [summer@potoroo virt]$ find * -type f -exec grep -HE '/usr/(|s)bin' {} ; | grep -Ev '/usr/bin/(perl|python)'
By and large these are not bugs. It would only be a bug if an installed program contains a hard-coded path, and the path is not discovered by (eg) ./configure, and there is no way around the hard-coded path at runtime, and the user could conceivably want to use a different binary.
Rich.
Richard W.M. Jones wrote:
John Summerfield wrote:
Richard W.M. Jones wrote:
John Summerfield wrote:
virtinst--devel/virtinst/ParaVirtGuest.py: cmd = ["/usr/bin/virsh", "console", "%s" %(self.domain.ID(),)]
Surely, the location of executable components should not be hard-coded in the source tree. I could live with it, grudgingly, if it was set at configure time.
Agreed -- this is simply a bug in virt-manager.
There are a few other places the virt* programs have fixed ideas about where stuff must be: [summer@potoroo virt]$ find * -type f -exec grep -HE '/usr/(|s)bin' {} ; | grep -Ev '/usr/bin/(perl|python)'
By and large these are not bugs. It would only be a bug if an installed program contains a hard-coded path, and the path is not discovered by (eg) ./configure, and there is no way around the hard-coded path at runtime, and the user could conceivably want to use a different binary.
Rich.
Thanks Rich. I am unfamiliar with the tools I need to put that statement to the test. INSTALL says to run ./configure, but there is no ./configure to run.
The website does say how to get the source with hg, and how to submit changes, but I can't see how to go from the checkout to building and installing.
Where is the documentation?
I do want to use alternative binaries (but then again I don't), but I do not wish to replace any standard part of F8.
John Summerfield wrote:
I am unfamiliar with the tools I need to put that statement to the test. INSTALL says to run ./configure, but there is no ./configure to run.
The website does say how to get the source with hg, and how to submit changes, but I can't see how to go from the checkout to building and installing.
I'm not sure which INSTALL file you're reading, but once you've got the source for virtinst--devel from hg you need to use the standard python way to build it. Try:
python setup.py --help
If this is Fedora, another, better route to go down is to build it from the .src.rpm using rpmbuild. Try the first suggestion on this page:
http://fedoranews.org/tchung/rpmbuild/
Rich.
Richard W.M. Jones wrote:
John Summerfield wrote:
Thanks Rich
I am unfamiliar with the tools I need to put that statement to the test. INSTALL says to run ./configure, but there is no ./configure to run.
The website does say how to get the source with hg, and how to submit changes, but I can't see how to go from the checkout to building and installing.
I'm not sure which INSTALL file you're reading, but once you've got the source for virtinst--devel from hg you need to use the standard python way to build it. Try:
The one checked out in the source tree, one of thse: virt-manager--devel/INSTALL virt-viewer--devel/INSTALL
python setup.py --help
That seems likely to work for one of the four. I've checked out virt-manager-web--devel but not yet looked at it.
If this is Fedora, another, better route to go down is to build it from the .src.rpm using rpmbuild. Try the first suggestion on this page:
I do not want to replace the standard F8 software, but I do want to be able to build and run the latest from the Hg repo.
You snipped my actual question and its rationale: <<Z Where is the documentation?
I do want to use alternative binaries (but then again I don't), but I do not wish to replace any standard part of F8. Z
That precludes the use of rpmbuild (unless the rpm is relocatable).
John Summerfield wrote:
Richard W.M. Jones wrote:
John Summerfield wrote:
Richard W.M. Jones wrote:
John Summerfield wrote:
virtinst--devel/virtinst/ParaVirtGuest.py: cmd = ["/usr/bin/virsh", "console", "%s" %(self.domain.ID(),)]
Surely, the location of executable components should not be hard-coded in the source tree. I could live with it, grudgingly, if it was set at configure time.
Agreed -- this is simply a bug in virt-manager.
There are a few other places the virt* programs have fixed ideas about where stuff must be: [summer@potoroo virt]$ find * -type f -exec grep -HE '/usr/(|s)bin' {} ; | grep -Ev '/usr/bin/(perl|python)'
By and large these are not bugs. It would only be a bug if an installed program contains a hard-coded path, and the path is not discovered by (eg) ./configure, and there is no way around the hard-coded path at runtime, and the user could conceivably want to use a different binary.
Rich.
Thanks Rich. I am unfamiliar with the tools I need to put that statement to the test. INSTALL says to run ./configure, but there is no ./configure to run.
The website does say how to get the source with hg, and how to submit changes, but I can't see how to go from the checkout to building and installing.
Where is the documentation?
I do want to use alternative binaries (but then again I don't), but I do not wish to replace any standard part of F8.
If you are trying to build virt-manager, run ./autogen.sh that comes with the source: this will build 'configure'. You will probably need to install a few things in order to build it like intltool and automake.
- Cole
On Fri, Jan 11, 2008 at 10:50:36PM +0900, John Summerfield wrote:
Richard W.M. Jones wrote:
John Summerfield wrote:
virtinst--devel/virtinst/ParaVirtGuest.py: cmd = ["/usr/bin/virsh", "console", "%s" %(self.domain.ID(),)]
Surely, the location of executable components should not be hard-coded in the source tree. I could live with it, grudgingly, if it was set at configure time.
Agreed -- this is simply a bug in virt-manager.
There are a few other places the virt* programs have fixed ideas about where stuff must be:
Most of these are not bugs because they are testsuites, or because these paths are being validated because other apps we call already expect the paths in those locations - so even if virt-install wished to use non-absolute paths it couldn't.
There are the only two which could potentially be fixed to use a relative path, and let the os.execvp/execlp call find the binary. Patches welcomed...
virtinst--devel/virt-install: args = ["/usr/bin/virt-viewer"] virtinst--devel/virt-install: args = ["/usr/bin/virsh"]
Dan.