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. -- Cheers John -- spambait 1aaaaaaa@coco.merseine.nu Z1aaaaaaa@coco.merseine.nu -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.html http://support.microsoft.com/kb/555375 You cannot reply off-list:-)
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. -- Cheers John -- spambait 1aaaaaaa@coco.merseine.nu Z1aaaaaaa@coco.merseine.nu -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.html http://support.microsoft.com/kb/555375 You cannot reply off-list:-) -- Fedora-xen mailing list Fedora-xen@redhat.com https://www.redhat.com/mailman/listinfo/fedora-xen
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
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. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
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. -- Cheers John -- spambait 1aaaaaaa@coco.merseine.nu Z1aaaaaaa@coco.merseine.nu -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.html http://support.microsoft.com/kb/555375 You cannot reply off-list:-)
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]$ -- Cheers John -- spambait 1aaaaaaa@coco.merseine.nu Z1aaaaaaa@coco.merseine.nu -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.html http://support.microsoft.com/kb/555375 You cannot reply off-list:-)
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. -- Cheers John -- spambait 1aaaaaaa@coco.merseine.nu Z1aaaaaaa@coco.merseine.nu -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.html http://support.microsoft.com/kb/555375 You cannot reply off-list:-)
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. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
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. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
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. -- Cheers John -- spambait 1aaaaaaa@coco.merseine.nu Z1aaaaaaa@coco.merseine.nu -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.html http://support.microsoft.com/kb/555375 You cannot reply off-list:-)
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. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
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
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 --helpThat 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: > > http://fedoranews.org/tchung/rpmbuild/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). -- Cheers John -- spambait 1aaaaaaa@coco.merseine.nu Z1aaaaaaa@coco.merseine.nu -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.html http://support.microsoft.com/kb/555375 You cannot reply off-list:-)