virt* source

[John Summerfield]

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(a)coco.merseine.nu  Z1aaaaaaa(a)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:-)

[Dustin Henning]

	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(a)redhat.com [mailto:[e-mail]] 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(a)coco.merseine.nu  Z1aaaaaaa(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-xen

[John Summerfield]

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(a)coco.merseine.nu  Z1aaaaaaa(a)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]

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]

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(a)coco.merseine.nu  Z1aaaaaaa(a)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]

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

[John Summerfield]

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(a)coco.merseine.nu  Z1aaaaaaa(a)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]

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

[John Summerfield]

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(a)coco.merseine.nu  Z1aaaaaaa(a)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]

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]

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:
>  
>    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(a)coco.merseine.nu  Z1aaaaaaa(a)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]

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

[Daniel P. Berrange]

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.  [phone] -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|