Some remarks about pygraphviz 0.34
Cyril Brulebois
here are some items:
- some scripts are +x, some others are not, I guess that you might want
to chmod a+x them all;
- django example isn't listed in Examples.txt, and I guess that some
explanations might be needed, since out-of-the-box, it fails with the
following:
,---
| kibi@cherry:/tmp/examples$ ./django_simple.py
| Traceback (most recent call last):
| File "./django_simple.py", line 19, in ?
| from django.http import HttpResponse
| ImportError: No module named django.http
`---
I might discover what's missing by myself, but documenting a needed
module to all users would be better, I guess. ;-)
Besides that, all other samples are performing the right thing.
I'll be adding the egg info in the package, as I did for the 0.33 upload
of python-networkx, and then ask for a sponsor. Everything should be
fine afterwards. I'm also setting the Debian Python Module Team (DPMT)
as comaintainers, in case I'm unavailable for a while, so that other
python packagers can take care of it if I'm short of time.
As for 2.12, upstream now ships their libs under /usr/lib and no longer
under /usr/lib/graphviz. So the pkg-config outputs changed from:
-I/usr/include/graphviz -L/usr/lib/graphviz
to:
-I/usr/include/graphviz
However, your current use of pkg-config seems to assume that there's
also a -L parameter, see:
,---
| cd . && python2.4 setup.py build_ext
| Traceback (most recent call last):
| File "setup.py", line 58, in ?
| includes,libs=output.split()
| ValueError: need more than 1 value to unpack
| make: *** [python-build-stamp-2.4] Error 1
`---
That's not (yet) a problem since I'm not yet using 2.12, and I might not
use the pkg-config method for now, since it adds a (maybe unnecessary)
build dependency, and since it looks like the old method could work.
Cheers,
--
Cyril Brulebois
Aric Hagberg
> here are some items:
> - some scripts are +x, some others are not, I guess that you might want
> to chmod a+x them all;
> - django example isn't listed in Examples.txt, and I guess that some
> explanations might be needed, since out-of-the-box, it fails with the
> following:
> ,---
> | kibi@cherry:/tmp/examples$ ./django_simple.py
> | Traceback (most recent call last):
> | File "./django_simple.py", line 19, in ?
> | from django.http import HttpResponse
> | ImportError: No module named django.http
> `---
I changed the permissions and put in some code to indicate
that this example is meant to run with the Django web framework.
>
> Besides that, all other samples are performing the right thing.
>
> I'll be adding the egg info in the package, as I did for the 0.33 upload
> of python-networkx, and then ask for a sponsor. Everything should be
> fine afterwards. I'm also setting the Debian Python Module Team (DPMT)
> as comaintainers, in case I'm unavailable for a while, so that other
> python packagers can take care of it if I'm short of time.
>
> As for 2.12, upstream now ships their libs under /usr/lib and no longer
> under /usr/lib/graphviz. So the pkg-config outputs changed from:
> -I/usr/include/graphviz -L/usr/lib/graphviz
>
> to:
> -I/usr/include/graphviz
>
> However, your current use of pkg-config seems to assume that there's
> also a -L parameter, see:
> ,---
Thanks for that report. I will clean up the pkg-config handling
and that is a good place to start.
> That's not (yet) a problem since I'm not yet using 2.12, and I might not
> use the pkg-config method for now, since it adds a (maybe unnecessary)
> build dependency, and since it looks like the old method could work.
Aric
Cyril Brulebois
> Thanks for that report. I will clean up the pkg-config handling
> and that is a good place to start.
Hi Aric,
is there any progress on this? It would be cool to see this problem
solved so that I'm able to upload a fixed python-pygraphviz, linking
with the latest graphviz package, which replaced the old one
(unfortunately, due to the former packaging methods, one cannot have
both versions installed in parallel; I've fixed this, but that only
applies to current and newer packages).
If you want me to test some patches, even not commited in your svn
repository, they are of course welcome (I might be wrong but I didn't
see any change when I last checked some days ago).
Cheers,
--
Cyril Brulebois
Aric Hagberg
I opened a ticket for this so you can see when it gets fixed.
Hopefully soon - thanks for reminding me.
https://networkx.lanl.gov/ticket/110
Aric
Cyril Brulebois
> I opened a ticket for this so you can see when it gets fixed.
> Hopefully soon - thanks for reminding me.
> https://networkx.lanl.gov/ticket/110
> Aric
Hi back,
I backported r605 so as to patch setup.py and have a correct behaviour
with graphviz 2.12, but it sounds to me that setup.cfg imposes the
rpath. I guess an appropriate option exists to disable it (currently,
I'm patching setup.cfg, deleting the section), but maybe it could be
possible to detect the need for an rpath automatically? Just suggesting,
it is not at all a blocker IMHO.
Cheers,
--
Cyril Brulebois
Aric Hagberg
On Tue, Jul 10, 2007 at 10:41:34PM +0200, Cyril Brulebois wrote:
> I backported r605 so as to patch setup.py and have a correct behaviour
> with graphviz 2.12, but it sounds to me that setup.cfg imposes the
> rpath. I guess an appropriate option exists to disable it (currently,
> I'm patching setup.cfg, deleting the section), but maybe it could be
> possible to detect the need for an rpath automatically? Just suggesting,
> it is not at all a blocker IMHO.
Is the right thing to just remove that section?
I did that and I added auto-detection for the runtime libraries in
https://networkx.lanl.gov/changeset/621
Let me know if that doesn't fix this problem.
Aric
Cyril Brulebois
> Is the right thing to just remove that section?
I'm not that used to setuptools, but I feel that just using
"runtime_library_dirs=library_dirs" should be sufficient, the eventual
-R parameter should be used there.
> I did that and I added auto-detection for the runtime libraries in
> https://networkx.lanl.gov/changeset/621
> Let me know if that doesn't fix this problem.
I've just tried with r621 and everything's fine. I'll have a look at
graphviz 2.8 if I find time, but I believe the needed rpath will be
added automatically.
I also noted an "FTBFS" (Fails To Build From Source) on alpha, I don't
know yet whether the problem resides in pygraphviz or in the packages on
which pygraphviz build-depends. I'll keep you posted [in another thread]
if needed, once I've analyzed the build log.
Thanks for the quick fix.
Cheers,
--
Cyril Brulebois
Cyril Brulebois
> I also noted an "FTBFS" (Fails To Build From Source) on alpha, I don't
> know yet whether the problem resides in pygraphviz or in the packages
> on which pygraphviz build-depends.
That was a problem in the libc-dev package on a particular build daemon,
nothing to worry about from your point of view. ;-)
Bye,
--
Cyril