12:27 p.m.
Hi,
I am trying to update the port for libvirt to 0.9.2, but am receiving a new
compiling error, that I have not seen yet.
console.c:280: warning: declaration of 'devname' shadows a global declaration
[-Wshadow]
/usr/include/stdlib.h:264: warning: shadowed declaration is here [-Wshadow]
CC virsh-virsh.o
CCLD virsh
GEN virt-xml-validate
GEN virt-pki-validate
gmake[3]: Leaving directory
`/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.2/tools'
gmake[2]: Leaving directory
`/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.2/tools'
Making all in docs
gmake[2]: Entering directory
`/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.2/docs'
GEN libvirt-api.xml
./apibuild.py: not found
gmake[2]: *** [libvirt-api.xml] Error 127
gmake[2]: Leaving directory
`/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.2/docs'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.2'
gmake: *** [all] Error 2
*** Error code 1
Stop in /home/jhelfman/ports/devel/libvirt.
Any thoughts?
Thanks,
Jason
--
Jason Helfman
System Administrator
experts-exchange.com
http://www.experts-exchange.com/M_4830110.html
E4AD 7CF1 1396 27F6 79DD 4342 5E92 AD66 8C8C FBA5
12:45 p.m.
On 06/07/2011 09:27 PM, Jason Helfman wrote:
Hi,
I am trying to update the port for libvirt to 0.9.2, but am receiving a new
compiling error, that I have not seen yet.
Is this a VPATH build?
`/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.2/docs'
GEN libvirt-api.xml
./apibuild.py: not found
What does 'gmake V=1' show for the full command being attempted here?
Any thoughts?
Possibly a missing make dependency, or a VPATH problem. I'll try to
find some time to look into it tomorrow (it's late for me tonight).
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
3:08 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Tue, Jun 07, 2011 at 09:45:41PM -0600, Eric Blake thus spake:
On 06/07/2011 09:27 PM, Jason Helfman wrote:
> Hi,
>
> I am trying to update the port for libvirt to 0.9.2, but am receiving a new
> compiling error, that I have not seen yet.
Is this a VPATH build?
> `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.2/docs'
> GEN libvirt-api.xml
> ./apibuild.py: not found
What does 'gmake V=1' show for the full command being attempted here?
> Any thoughts?
Possibly a missing make dependency, or a VPATH problem. I'll try to
find some time to look into it tomorrow (it's late for me tonight).
I found the issue in building was an absolute path for apibuild.py for
python, that is incorrect on FreeBSD.
Here is a patch:
- --- ./docs/apibuild.py.orig 2011-06-07 21:31:43.000000000 -0700
+++ ./docs/apibuild.py 2011-06-07 21:31:55.000000000 -0700
@@ -1,4 +1,4 @@
- -#!/usr/bin/python -u
+#!/usr/bin/env python
#
# This is the API builder, it parses the C sources and build the
# API formal description in XML.
- --
Jason Helfman
System Administrator
experts-exchange.com
http://www.experts-exchange.com/M_4830110.html
E4AD 7CF1 1396 27F6 79DD 4342 5E92 AD66 8C8C FBA5
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (FreeBSD)
iF4EAREIAAYFAk3vEcIACgkQXpKtZoyM+6UTDgD+M0FhJEjiE79Q8H2mODWYWwlO
IUJYUqK7Wc4RwKki5LAA/AqgFeYD+JzPvQ3fOSEb0h4RmCKENYKEdppO22F9DOF3
=oNes
-----END PGP SIGNATURE-----
6:23 p.m.
On Tue, Jun 07, 2011 at 11:08:02PM -0700, Jason Helfman wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Tue, Jun 07, 2011 at 09:45:41PM -0600, Eric Blake thus spake:
>On 06/07/2011 09:27 PM, Jason Helfman wrote:
>> Hi,
>>
>> I am trying to update the port for libvirt to 0.9.2, but am receiving a new
>> compiling error, that I have not seen yet.
>
>Is this a VPATH build?
>
>> `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.2/docs'
>> GEN libvirt-api.xml
>> ./apibuild.py: not found
>
>What does 'gmake V=1' show for the full command being attempted here?
>
>> Any thoughts?
>
>Possibly a missing make dependency, or a VPATH problem. I'll try to
>find some time to look into it tomorrow (it's late for me tonight).
>
I found the issue in building was an absolute path for apibuild.py for
python, that is incorrect on FreeBSD.
okay, where is it on FreeBSD ?
Here is a patch:
- --- ./docs/apibuild.py.orig 2011-06-07 21:31:43.000000000 -0700
+++ ./docs/apibuild.py 2011-06-07 21:31:55.000000000 -0700
@@ -1,4 +1,4 @@
- -#!/usr/bin/python -u
+#!/usr/bin/env python
I have seens people complaining loudly because env was used like this
for example:
http://forums.westhost.com/showthread.php?9984-usr-bin-env-python-doesn-t...
another way would be to launch python directly giving the path to the
python script, this is likely to solve the issue there.
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
11:44 p.m.
On Tue, Jun 07, 2011 at 11:08:02PM -0700, Jason Helfman wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Tue, Jun 07, 2011 at 09:45:41PM -0600, Eric Blake thus spake:
> >On 06/07/2011 09:27 PM, Jason Helfman wrote:
> >> Hi,
> >>
> >> I am trying to update the port for libvirt to 0.9.2, but am receiving
> a new
> >> compiling error, that I have not seen yet.
> >
> >Is this a VPATH build?
> >
> >> `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.2/docs'
> >> GEN libvirt-api.xml
> >> ./apibuild.py: not found
> >
> >What does 'gmake V=1' show for the full command being attempted here?
> >
> >> Any thoughts?
> >
> >Possibly a missing make dependency, or a VPATH problem. I'll try to
> >find some time to look into it tomorrow (it's late for me tonight).
> >
>
> I found the issue in building was an absolute path for apibuild.py for
> python, that is incorrect on FreeBSD.
okay, where is it on FreeBSD ?
/usr/local/bin
> Here is a patch:
>
> - --- ./docs/apibuild.py.orig 2011-06-07 21:31:43.000000000 -0700
> +++ ./docs/apibuild.py 2011-06-07 21:31:55.000000000 -0700
> @@ -1,4 +1,4 @@
> - -#!/usr/bin/python -u
> +#!/usr/bin/env python
I have seens people complaining loudly because env was used like this
for example:
http://forums.westhost.com/showthread.php?9984-usr-bin-env-python-doesn-t...
I would argue that using /usr/bin/env is the correct way to handle this
and users that this breaks for haven't properly configured their
environment path for their binaries. Non-standard paths should be put in a
path so /usr/bin/env will work. /usr/bin and /usr/local/bin are very
standard, in my humble opinion.
another way would be to launch python directly giving the path to the
python script, this is likely to solve the issue there.
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
-Jason
9:55 p.m.
On Wed, Jun 08, 2011 at 07:44:43AM -0700, Jason Helfman wrote:
> On Tue, Jun 07, 2011 at 11:08:02PM -0700, Jason Helfman wrote:
>> I found the issue in building was an absolute path for apibuild.py for
>> python, that is incorrect on FreeBSD.
>
> okay, where is it on FreeBSD ?
/usr/local/bin
>> Here is a patch:
>>
>> - --- ./docs/apibuild.py.orig 2011-06-07 21:31:43.000000000 -0700
>> +++ ./docs/apibuild.py 2011-06-07 21:31:55.000000000 -0700
>> @@ -1,4 +1,4 @@
>> - -#!/usr/bin/python -u
>> +#!/usr/bin/env python
>
> I have seens people complaining loudly because env was used like this
> for example:
>
> http://forums.westhost.com/showthread.php?9984-usr-bin-env-python-doesn-t...
I would argue that using /usr/bin/env is the correct way to handle this
and users that this breaks for haven't properly configured their
environment path for their binaries. Non-standard paths should be put in a
path so /usr/bin/env will work. /usr/bin and /usr/local/bin are very
standard, in my humble opinion.
yes, I was doing the same, and people complained, left and right :-\
> another way would be to launch python directly giving the path
to the
> python script, this is likely to solve the issue there.
That IMHO avoids the problem completely and I doubt anybody would
complain we should even be able to detect at configure and take specific
paths if people want to use a non-system python binary by extending
paphio:~/libvirt -> ./configure --help | grep python
--with-python Build python bindings [default=yes]
to take a path
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
10:12 p.m.
On Thu, Jun 09, 2011 at 20:55:01 +0800, Daniel Veillard wrote:
> > another way would be to launch python directly giving the
path to the
> > python script, this is likely to solve the issue there.
That IMHO avoids the problem completely and I doubt anybody would
complain
I agree, and we already use that in one place in python/Makefile.am:
$(PYTHON) $(srcdir)/$(GENERATE) $(PYTHON)
we should even be able to detect at configure and take specific
paths if people want to use a non-system python binary by extending
paphio:~/libvirt -> ./configure --help | grep python
--with-python Build python bindings [default=yes]
to take a path
No extension needed, it already supports that (although it's not advertised
anywhere). One can use the following forms
--with-python
--with-python=/usr/local
--with-python=/usr/local/bin/python
PYTHON=/usr/local/bin/python --with-python
Jirka
2:04 a.m.
On Thu, Jun 09, 2011 at 03:12:42PM +0200, Jiri Denemark thus spake:
On Thu, Jun 09, 2011 at 20:55:01 +0800, Daniel Veillard wrote:
> > > another way would be to launch python directly giving the path to the
> > > python script, this is likely to solve the issue there.
>
> That IMHO avoids the problem completely and I doubt anybody would
> complain
I agree, and we already use that in one place in python/Makefile.am:
$(PYTHON) $(srcdir)/$(GENERATE) $(PYTHON)
> we should even be able to detect at configure and take specific
> paths if people want to use a non-system python binary by extending
>
> paphio:~/libvirt -> ./configure --help | grep python
> --with-python Build python bindings [default=yes]
>
> to take a path
No extension needed, it already supports that (although it's not advertised
anywhere). One can use the following forms
--with-python
--with-python=/usr/local
--with-python=/usr/local/bin/python
PYTHON=/usr/local/bin/python --with-python
Jirka
Sounds good to me. How would the python script in question support this?
Thanks,
Jason
--
Jason Helfman
System Administrator
experts-exchange.com
http://www.experts-exchange.com/M_4830110.html
E4AD 7CF1 1396 27F6 79DD 4342 5E92 AD66 8C8C FBA5
5:18 a.m.
On Thu, Jun 09, 2011 at 10:04:22AM -0700, Jason Helfman wrote:
On Thu, Jun 09, 2011 at 03:12:42PM +0200, Jiri Denemark thus spake:
>On Thu, Jun 09, 2011 at 20:55:01 +0800, Daniel Veillard wrote:
>>> > another way would be to launch python directly giving the path to
the
>>> > python script, this is likely to solve the issue there.
>>
>> That IMHO avoids the problem completely and I doubt anybody would
>>complain
>
>I agree, and we already use that in one place in python/Makefile.am:
>
> $(PYTHON) $(srcdir)/$(GENERATE) $(PYTHON)
>
>>we should even be able to detect at configure and take specific
>>paths if people want to use a non-system python binary by extending
>>
>>paphio:~/libvirt -> ./configure --help | grep python
>> --with-python Build python bindings [default=yes]
>>
>> to take a path
>
>No extension needed, it already supports that (although it's not advertised
>anywhere). One can use the following forms
>
> --with-python
> --with-python=/usr/local
> --with-python=/usr/local/bin/python
> PYTHON=/usr/local/bin/python --with-python
>
>Jirka
>
Sounds good to me. How would the python script in question support this?
(1) Rename the original script so it is called 'foo.in' (for each
original script called 'foo')
(2) At the top of 'foo.in' place the following two lines:
#!@PYTHON@
# @configure_input@
(3) In configure.ac, you have to make two changes:
(a) in AC_CONFIG_FILES, add an entry for 'foo'
(b) add a new line AC_SUBST([PYTHON]) after the current
line AC_SUBST([PYTHON_INCLUDES])
(4) Run 'autoconf'.
./configure will then generate 'foo' from 'foo.in', replacing all
@...@ sequences, so for example the first line above would be replaced
with #!/usr/local/bin/python.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
7:25 a.m.
On 06/12/2011 02:18 PM, Richard W.M. Jones wrote:
>>>>> another way would be to launch python directly
giving the path to the
>>>>> python script, this is likely to solve the issue there.
>>>
>>> That IMHO avoids the problem completely and I doubt anybody would
>>> complain
>>
>> I agree, and we already use that in one place in python/Makefile.am:
>>
>> $(PYTHON) $(srcdir)/$(GENERATE) $(PYTHON)
>
> Sounds good to me. How would the python script in question support this?
(1) Rename the original script so it is called 'foo.in' (for each
original script called 'foo')
(2) At the top of 'foo.in' place the following two lines:
#!@PYTHON@
# @configure_input@
Using $(PYTHON) in appropriate Makefile.am is sufficient if the script
will only ever be invoked by a Makefile generated at configure time.
But if the script must be installed, then yes, the script.in approach is
the way to go.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
1:29 a.m.
Hi,
On Thu, Jun 09, 2011 at 08:55:01PM +0800, Daniel Veillard thus spake:
On Wed, Jun 08, 2011 at 07:44:43AM -0700, Jason Helfman wrote:
> > On Tue, Jun 07, 2011 at 11:08:02PM -0700, Jason Helfman wrote:
> >> I found the issue in building was an absolute path for apibuild.py for
> >> python, that is incorrect on FreeBSD.
> >
> > okay, where is it on FreeBSD ?
>
> /usr/local/bin
>
> >> Here is a patch:
> >>
> >> - --- ./docs/apibuild.py.orig 2011-06-07 21:31:43.000000000 -0700
> >> +++ ./docs/apibuild.py 2011-06-07 21:31:55.000000000 -0700
> >> @@ -1,4 +1,4 @@
> >> - -#!/usr/bin/python -u
> >> +#!/usr/bin/env python
> >
> > I have seens people complaining loudly because env was used like this
> > for example:
> >
> > http://forums.westhost.com/showthread.php?9984-usr-bin-env-python-doesn-t...
>
> I would argue that using /usr/bin/env is the correct way to handle this
> and users that this breaks for haven't properly configured their
> environment path for their binaries. Non-standard paths should be put in a
> path so /usr/bin/env will work. /usr/bin and /usr/local/bin are very
> standard, in my humble opinion.
>
yes, I was doing the same, and people complained, left and right :-\
> > another way would be to launch python directly giving the path to the
> > python script, this is likely to solve the issue there.
That IMHO avoids the problem completely and I doubt anybody would
complain we should even be able to detect at configure and take specific
paths if people want to use a non-system python binary by extending
paphio:~/libvirt -> ./configure --help | grep python
--with-python Build python bindings [default=yes]
to take a path
Daniel
I was wondering if this issue was addressed in the upcoming release?
Thanks!
Jason
--
Jason Helfman
System Administrator
experts-exchange.com
http://www.experts-exchange.com/M_4830110.html
E4AD 7CF1 1396 27F6 79DD 4342 5E92 AD66 8C8C FBA5
1:53 a.m.
On 06/27/2011 10:29 AM, Jason Helfman wrote:
>> > another way would be to launch python directly giving
the path to
>> the
>> > python script, this is likely to solve the issue there.
>
> That IMHO avoids the problem completely and I doubt anybody would
> complain we should even be able to detect at configure and take specific
> paths if people want to use a non-system python binary by extending
>
> paphio:~/libvirt -> ./configure --help | grep python
> --with-python Build python bindings [default=yes]
>
> to take a path
>
> Daniel
>
I was wondering if this issue was addressed in the upcoming release?
I'm not sure that I've seen patches go in yet, but they are still fair
game to include if RC1 doesn't meet your needs as this is a real bug
fix. I'm also hoping to clean up configure to work on systems where
python headers are not installed (my earlier attempt stalled at
https://www.redhat.com/archives/libvir-list/2011-May/msg01223.html).
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
4:08 p.m.
On Mon, Jun 27, 2011 at 09:29:34AM -0700, Jason Helfman wrote:
Hi,
On Thu, Jun 09, 2011 at 08:55:01PM +0800, Daniel Veillard thus spake:
>On Wed, Jun 08, 2011 at 07:44:43AM -0700, Jason Helfman wrote:
>>> On Tue, Jun 07, 2011 at 11:08:02PM -0700, Jason Helfman wrote:
>>>> I found the issue in building was an absolute path for apibuild.py for
>>>> python, that is incorrect on FreeBSD.
>>>
>>> okay, where is it on FreeBSD ?
>>
>>/usr/local/bin
>>
>>>> Here is a patch:
>>>>
>>>> - --- ./docs/apibuild.py.orig 2011-06-07 21:31:43.000000000 -0700
>>>> +++ ./docs/apibuild.py 2011-06-07 21:31:55.000000000 -0700
>>>> @@ -1,4 +1,4 @@
>>>> - -#!/usr/bin/python -u
>>>> +#!/usr/bin/env python
>>>
>>> I have seens people complaining loudly because env was used like this
>>> for example:
>>>
>>>
http://forums.westhost.com/showthread.php?9984-usr-bin-env-python-doesn-t...
>>
>>I would argue that using /usr/bin/env is the correct way to handle this
>>and users that this breaks for haven't properly configured their
>>environment path for their binaries. Non-standard paths should be put in a
>>path so /usr/bin/env will work. /usr/bin and /usr/local/bin are very
>>standard, in my humble opinion.
>>
>
> yes, I was doing the same, and people complained, left and right :-\
>
>>> another way would be to launch python directly giving the path to the
>>> python script, this is likely to solve the issue there.
>
> That IMHO avoids the problem completely and I doubt anybody would
>complain we should even be able to detect at configure and take specific
>paths if people want to use a non-system python binary by extending
>
>paphio:~/libvirt -> ./configure --help | grep python
> --with-python Build python bindings [default=yes]
>
>to take a path
>
>Daniel
>
I was wondering if this issue was addressed in the upcoming release?
Oops, no but it should be as simple as the following patch, we should
be able to get this fixed in time !
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
11:57 p.m.
On 07/01/2011 01:08 AM, Daniel Veillard wrote:
>>>> another way would be to launch python directly
giving the path to the
>>>> python script, this is likely to solve the issue there.
>>
> I was wondering if this issue was addressed in the upcoming
release?
Oops, no but it should be as simple as the following patch, we should
be able to get this fixed in time !
diff --git a/docs/Makefile.am b/docs/Makefile.am
index 689fe32..050ebe1 100644
--- a/docs/Makefile.am
+++ b/docs/Makefile.am
@@ -181,7 +181,7 @@ $(python_generated_files): $(srcdir)/apibuild.py \
$(srcdir)/../include/libvirt/*.h \
$(srcdir)/../src/libvirt.c \
$(srcdir)/../src/util/virterror.c
- $(AM_V_GEN)srcdir=$(srcdir) $(srcdir)/apibuild.py
+ $(AM_V_GEN)srcdir=$(srcdir) $(PYTHON) $(srcdir)/apibuild.py
check-local: all
ACK.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
12:44 a.m.
On Fri, Jul 01, 2011 at 08:57:35AM -0600, Eric Blake wrote:
On 07/01/2011 01:08 AM, Daniel Veillard wrote:
>>>>> another way would be to launch python directly giving the path to
the
>>>>> python script, this is likely to solve the issue there.
>>>
>> I was wondering if this issue was addressed in the upcoming release?
>
> Oops, no but it should be as simple as the following patch, we should
> be able to get this fixed in time !
>
> diff --git a/docs/Makefile.am b/docs/Makefile.am
> index 689fe32..050ebe1 100644
> --- a/docs/Makefile.am
> +++ b/docs/Makefile.am
> @@ -181,7 +181,7 @@ $(python_generated_files): $(srcdir)/apibuild.py \
> $(srcdir)/../include/libvirt/*.h \
> $(srcdir)/../src/libvirt.c \
> $(srcdir)/../src/util/virterror.c
> - $(AM_V_GEN)srcdir=$(srcdir) $(srcdir)/apibuild.py
> + $(AM_V_GEN)srcdir=$(srcdir) $(PYTHON) $(srcdir)/apibuild.py
>
> check-local: all
>
ACK.
Thanks ! pushed :-)
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
5:58 a.m.
On Fri, Jul 01, 2011 at 08:57:35AM -0600, Eric Blake thus spake:
On 07/01/2011 01:08 AM, Daniel Veillard wrote:
>>>>> another way would be to launch python directly giving the path to
the
>>>>> python script, this is likely to solve the issue there.
>>>
>> I was wondering if this issue was addressed in the upcoming release?
>
> Oops, no but it should be as simple as the following patch, we should
> be able to get this fixed in time !
>
> diff --git a/docs/Makefile.am b/docs/Makefile.am
> index 689fe32..050ebe1 100644
> --- a/docs/Makefile.am
> +++ b/docs/Makefile.am
> @@ -181,7 +181,7 @@ $(python_generated_files): $(srcdir)/apibuild.py \
> $(srcdir)/../include/libvirt/*.h \
> $(srcdir)/../src/libvirt.c \
> $(srcdir)/../src/util/virterror.c
> - $(AM_V_GEN)srcdir=$(srcdir) $(srcdir)/apibuild.py
> + $(AM_V_GEN)srcdir=$(srcdir) $(PYTHON) $(srcdir)/apibuild.py
>
> check-local: all
>
ACK.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
I applied this patch (cleanly), and it still breaks:
gmake[3]: Leaving directory
`/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.3/tools'
gmake[2]: Leaving directory
`/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.3/tools'
Making all in docs
gmake[2]: Entering directory
`/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.3/docs'
GEN libvirt-api.xml
./apibuild.py: not found
gmake[2]: *** [libvirt-api.xml] Error 127
gmake[2]: Leaving directory
`/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.3/docs'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory
`/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.3'
gmake: *** [all] Error 2
*** Error code 1
From the top of the file:
#!/usr/bin/python -u
From Makefile.am after patch:
$(python_generated_files): $(srcdir)/apibuild.py \
$(srcdir)/../include/libvirt/*.h \
$(srcdir)/../src/libvirt.c \
$(srcdir)/../src/util/virterror.c
$(AM_V_GEN)srcdir=$(srcdir) $(PYTHON) $(srcdir)/apibuild.py
-jgh
--
Jason Helfman
System Administrator
experts-exchange.com
http://www.experts-exchange.com/M_4830110.html
E4AD 7CF1 1396 27F6 79DD 4342 5E92 AD66 8C8C FBA5
6:07 a.m.
On 07/01/2011 02:58 PM, Jason Helfman wrote:
I applied this patch (cleanly), and it still breaks:
gmake[3]: Leaving directory
`/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.3/tools'
gmake[2]: Leaving directory
`/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.3/tools'
Making all in docs
gmake[2]: Entering directory
`/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.3/docs'
GEN libvirt-api.xml
./apibuild.py: not found
Can you please run 'make V=1 SHELL="sh -vx"' so we can get a better
picture of what make tried to do here?
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
6:15 a.m.
On Fri, Jul 01, 2011 at 03:07:06PM -0600, Eric Blake thus spake:
On 07/01/2011 02:58 PM, Jason Helfman wrote:
>
> I applied this patch (cleanly), and it still breaks:
> gmake[3]: Leaving directory
> `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.3/tools'
> gmake[2]: Leaving directory
> `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.3/tools'
> Making all in docs
> gmake[2]: Entering directory
> `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.3/docs'
> GEN libvirt-api.xml
> ./apibuild.py: not found
Can you please run 'make V=1 SHELL="sh -vx"' so we can get a better
picture of what make tried to do here?
Done. Here is the log of the run:
http://jgh.devio.us/files/libvirt.log.gz
Thanks!
Jason
--
Jason Helfman
System Administrator
experts-exchange.com
http://www.experts-exchange.com/M_4830110.html
E4AD 7CF1 1396 27F6 79DD 4342 5E92 AD66 8C8C FBA5
7:21 a.m.
On 07/01/2011 03:15 PM, Jason Helfman wrote:
On Fri, Jul 01, 2011 at 03:07:06PM -0600, Eric Blake thus spake:
> On 07/01/2011 02:58 PM, Jason Helfman wrote:
>>
>> I applied this patch (cleanly), and it still breaks:
>> gmake[3]: Leaving directory
>> `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.3/tools'
>> gmake[2]: Leaving directory
>> `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.3/tools'
>> Making all in docs
>> gmake[2]: Entering directory
>> `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.3/docs'
>> GEN libvirt-api.xml
>> ./apibuild.py: not found
>
> Can you please run 'make V=1 SHELL="sh -vx"' so we can get a
better
> picture of what make tried to do here?
>
Done. Here is the log of the run:
http://jgh.devio.us/files/libvirt.log.gz
Thanks (I was only interested in the tail of that, so you were wise to
post the file to a website rather than spamming the list with the entire
file)
gmake[2]: Entering directory
`/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.3/docs'
srcdir=. ./apibuild.py
+ srcdir=. ./apibuild.py
./apibuild.py: not found
gmake[2]: *** [libvirt-api.xml] Error 127
This looks like your Makefile was not regenerated after your Makefile.am
change; there's no evidence that make expanded $(PYTHON) anywhere. Did
you just patch the release-candidate tarball, or are you working from
libvirt.git? I still think the latest libvirt.git has fixed things, so
if you are just working from tarballs, either we will have an RC3 for
you to test, or you'll have to figure out how to regenerate things yourself.
Do you have automake and autoconf installed? If so, 'autoreconf -v'
before your next make should fix things.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
7:30 a.m.
On Fri, Jul 01, 2011 at 04:21:54PM -0600, Eric Blake thus spake:
On 07/01/2011 03:15 PM, Jason Helfman wrote:
> On Fri, Jul 01, 2011 at 03:07:06PM -0600, Eric Blake thus spake:
>> On 07/01/2011 02:58 PM, Jason Helfman wrote:
>>>
>>> I applied this patch (cleanly), and it still breaks:
>>> gmake[3]: Leaving directory
>>> `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.3/tools'
>>> gmake[2]: Leaving directory
>>> `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.3/tools'
>>> Making all in docs
>>> gmake[2]: Entering directory
>>> `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.3/docs'
>>> GEN libvirt-api.xml
>>> ./apibuild.py: not found
>>
>> Can you please run 'make V=1 SHELL="sh -vx"' so we can get a
better
>> picture of what make tried to do here?
>>
> Done. Here is the log of the run:
> http://jgh.devio.us/files/libvirt.log.gz
Thanks (I was only interested in the tail of that, so you were wise to
post the file to a website rather than spamming the list with the entire
file)
gmake[2]: Entering directory
`/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.3/docs'
srcdir=. ./apibuild.py
+ srcdir=. ./apibuild.py
./apibuild.py: not found
gmake[2]: *** [libvirt-api.xml] Error 127
This looks like your Makefile was not regenerated after your Makefile.am
change; there's no evidence that make expanded $(PYTHON) anywhere. Did
you just patch the release-candidate tarball, or are you working from
libvirt.git? I still think the latest libvirt.git has fixed things, so
if you are just working from tarballs, either we will have an RC3 for
you to test, or you'll have to figure out how to regenerate things yourself.
Do you have automake and autoconf installed? If so, 'autoreconf -v'
before your next make should fix things.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
Ok, this worked. I was using the downloaded rc3 tarball, and I added the
patches in the build process, as FreeBSD ports patch prior to the build. I
added in to use autotools and ran a clean build, and it worked with no
issue.
USE_AUTOTOOLS= automake autoconf
Thanks!
Jason
--
Jason Helfman
System Administrator
experts-exchange.com
http://www.experts-exchange.com/M_4830110.html
E4AD 7CF1 1396 27F6 79DD 4342 5E92 AD66 8C8C FBA5
5026
days inactive
5049
days old
19 comments
5 participants
participants (5)
-
Daniel Veillard -
Eric Blake -
Jason Helfman -
Jiri Denemark -
Richard W.M. Jones