154500 - "Show dependency graph" doesn't work well with webdot

Status: NEW

(Bugzilla :: Dependency Views, defect)

Description

[John Ellson]

The "Show dependency graph" feature of bugzilla has never worked well.

I'm one of the authors of graphviz and webdot (the tools bugzilla is trying to
use to generate the graphs).  I'd be pleased to assist with fixing/improving
this feature if the bugzilla developer would get in touch.

Comment 1

[Bradley Baetz (:bbaetz)]

gerv, you touched this sort of thing last, didn't you?

Currently we use the webdot server (which doesn't work, because it doesn't send
a Host header, apparently), but as soon as myk installs 'dot' localally on bmo,
then the new bugzilla versoin can use that,

Comment 2

[John Ellson]

There is a newer version of webdot (from http://www.graphviz.org/pub/graphviz/ )
that you can install from rpms on your own local RH-7.x box or SuSE-7.x box.
That way you can maintain better control of load and stability than is possible
from the AT&T installation.   AT&T are using an old version which I don't have
access to for maintenance (Lucent is no longer a part of AT&T).

The current version of webdot does send a "Host:" header in its upstream request
for the .dot file.

Comment 3

[Gervase Markham [:gerv]]

Local dot works very well. Webdot (at least, using the AT&T server) works less
well. If someone can fix webdot, that's great, but I think deprecating it in
favour of local dot is probably a better way to go.

[e-mail] - have you installed Bugzilla locally, or are you just looking
at bugzilla.mozilla.org? Have you tried local dot?

Gerv

Comment 4

[John Ellson]

I haven't yet installed Bugzilla locally.   My concern here was more for
Mozilla's Bugzilla and the fact that it was a poor showcase for graphviz tools.

I'm willing to install bugzilla locally in support of these goals.   Is there a
specific set of sources that I should be using?

(Should we take this correspondance external to Mozilla's Bugzilla?)

Comment 5

[John Ellson]

I don't see any code in bugzilla-LATEST to run the "dot" executable locally in a
pipe, or when you said "local dot" did you mean just a local webdot installation?

There are multiple levels of integration possible:
   0) remote webdot server (what you have now, but we could fix it)
   1) local webdot server
   2) /usr/bin/dot invoked in a pipe
   3) a libdotneato.a binding that extends the scripting language 
            (currently only available for tcl)

1) would be quick based on existing bugzilla code.  It would maintain
a good separation of concerns, but let you allocate and control suffiecient
hardware resources to maintain a good service for Mozilla's Bugzilla installation.
2) would probably be relatively easy and sufficient even for high traffic
bugzilla servers.  Implementing it would require some perl hacking to implement
some of the functions that webdot does now, but the pieces are available.
For example, see AT&Ts reimplementation of webdot in perl using dot in a pipe.
http://www.research.att.com/sw/tools/graphviz/extras/webdot.pl

Providing a perl binding to libdotneato.a to support 3) is something that we
(graphviz) should do, but it isn't likely to happen quickly.

Comment 6

[Bradley Baetz (:bbaetz)]

I meant 3 - look at
http://lxr.mozilla.org/mozilla/source/webtools/bugzilla/showdependencygraph.cgi#181

BMO isn't set up to use that, yet, though

One thing which would be useful is the ability for webdot to output html client
side image maps, instead of server ones which we have to translate.

Comment 7

[Gervase Markham [:gerv]]

The local dot stuff is in 2.16 (currently up to Release Candidate 2.) Check that
out, either by downloading the tarball or by looking on the web
(http://lxr.mozilla.org/mozilla/source/webtools/bugzilla). We enhanced the dot
support quite a bit - search for closed bugs with "dot" in the summary targetted
at 2.16.

Gerv

Comment 8

[John Ellson]

Re comment #6. 

The latest tcl version of webdot can edit html templates and produce client-side
maps.  Its a bit tricky to get the HTML template right so that other
hrefs aren't unnecessarily processed through webdot.

See the demos at http://www.graphviz.org/webdot/

Comment 9

[John Ellson]

Re comment #6.

I should have said, see the *tutorials* at http://www.graphviz.org/webdot/
in particular, see: http://www.graphviz.org/cgi-bin/webdot/webdot/clientmap.html

Comment 10

[John Ellson]

OK, I see this in 2.16rc2.  This else clause is really what I meant by
level 2) integration, but I agree that this is probably the right level.

if ($webdotbase =~ /^https?:/) {
    # Remote dot server
     ...
} else {
    # Local dot installation
    ...
    system("$webdotbase","-Tpng","-o","$pngfilename","$filename");
    ...
}

In order to do client-side maps I think you need to generate the html as well.

Comment 11

[John Ellson]

I just took the liberty of opening bug # 154612  for the issue of client-side maps.

Comment 12

[Bradley Baetz (:bbaetz)]

Right, we do generate the html. But we have to get graphviz to generate a server
side image map, and then proces this to convert to to a client one.

webdot can generate client side image maps, but dot can't. Or at least I
couldn't work out how to get it to do so.

Comment 13

[John Ellson]

Using -Timap (instead of -Tismap) will get you closer.

Dot from graphviz 1.8.6 contains a change to the x,y coordinate order in -Timap
output to conform to the map conventions (and dumb browsers that can't work out
if a point is inside a rectangle described by a diagonal line irrespective of
the direction of the diagonal!)

Comment 14

[Gervase Markham [:gerv]]

I am assigning all the bugs I am not working on in the immediate future to
[e-mail]. This means:

- I will be able to search for bugs assigned to me as a list of bugs I'm going
to fix (which is as it should be), and
- people won't falsely assume I might be about to fix a bug when I'm not.

Gerv

Comment 15

[Dave Miller [:justdave]]

I'll take this, I have graphviz/dot set up on one of my installations I can play
with.  I wasn't aware this bug was here or I would have pushed it a little
harder.  Where does this stand?

Comment 16

[John Ellson]

> Where does this stand ?

I took #12 as a request for dot to provide client-side image maps,
which it now does in graphviz-1.8.10. The command is:  dot -Tcmap

Comment 17

[Dave Miller [:justdave]]

OK, just to clarify here....  what we need to do is eliminate the code for
generating a client map from a server map, and just ask dot to create a client
map for us to begin with.  We also need to check the version of dot to ensure
it's a recent enough version to support -Tcmap...

justdave@sinclair [14:34 ~ 5] tcsh> dot -V
dot version 1.8.6 (Sun Dec 29 02:37:15 PST 2002)

That seems to be the magic incantation necessary. :)

and 1.8.6 is the minimum required for this, correct?

Comment 18

[John Ellson]

No, the minimum for "dot -Tcmap" support is graphviz-1.8.10.

Comment 19

[Dave Miller [:justdave]]

whoops, right, you said that.  So the version on my box is too old...  which is
interesting considering I downloaded it off the graphviz site about a month
ago...  was the redhat RPM though, maybe there wasn't an RPM for the newest version.

Comment 20

[John Ellson]

Please use the rpms and/or sources from our developer site:
   http://www.graphviz.org/pub/graphviz/

Comment 21

[Rajesh]

Hi Dave,

       I'm trying to run Graphviz locally. I know the location of dot
executable. Kindly let me know how to specifity the path on the parameters page.
The location of the dot file on my system is /usr/bin/dot. If I put this then I
get a message saying that the path that I've put does not contain a vaild
execuatble.

       Please help me out.

Regards,
Raj. 

Comment 22

[Alex Pavloff]

I've got additional problems with the dependency graphing.  It doesn't work in
my configuration (Bugzilla 2.18 on Windows), using either a local dot (graphviz
3.0, installed from the AT&T site) or a webdot.

Failure case for local dot is a broken link, with the following in the Apache
error log:

[Tue Feb 01 17:38:22 2005] [error] [client 10.0.0.12] [Tue Feb  1 17:38:22 2005]
showdependencygraph.cgi: binmode() on closed filehandle DOT at
C:/p4_ut011666_WS-ALEXP/Bugzilla/showdependencygraph.cgi line 234., referer:
http://ws-alexp:8081/show_bug.cgi?id=2
[Tue Feb 01 17:38:22 2005] [error] [client 10.0.0.12] [Tue Feb  1 17:38:22 2005]
showdependencygraph.cgi: readline() on closed filehandle DOT at
C:/p4_ut011666_WS-ALEXP/Bugzilla/showdependencygraph.cgi line 235., referer:
http://ws-alexp:8081/show_bug.cgi?id=2
[Tue Feb 01 17:38:22 2005] [error] [client 10.0.0.12] [Tue Feb  1 17:38:22 2005]
showdependencygraph.cgi: binmode() on closed filehandle DOT at
C:/p4_ut011666_WS-ALEXP/Bugzilla/showdependencygraph.cgi line 253., referer:
http://ws-alexp:8081/show_bug.cgi?id=2
[Tue Feb 01 17:38:22 2005] [error] [client 10.0.0.12] [Tue Feb  1 17:38:22 2005]
showdependencygraph.cgi: readline() on closed filehandle DOT at
C:/p4_ut011666_WS-ALEXP/Bugzilla/showdependencygraph.cgi line 254., referer:
http://ws-alexp:8081/show_bug.cgi?id=2
[Tue Feb 01 17:38:22 2005] [error] [client 10.0.0.12] [Tue Feb  1 17:38:22 2005]
showdependencygraph.cgi: Use of uninitialized value in concatenation (.) or
string at C:/p4_ut011666_WS-ALEXP/Bugzilla/showdependencygraph.cgi line 86.,
referer: http://ws-alexp:8081/show_bug.cgi?id=2

For a webdot, I get a link with the text "Dependency Graph", linking to the .map
file, and no picture.

In both cases, the .dot file is being created correctly.  Running the local dot
from the command line with the -o option to output to a file generates the
correct .png file.

Comment 23

[Max Kanat-Alexander]

This bug has not been touched by its owner in over six months, even though it is
targeted to 2.20, for which the freeze is 10 days away. Unsetting the target
milestone, on the assumption that nobody is actually working on it or has any
plans to soon.

If you are the owner, and you plan to work on the bug, please give it a real
target milestone. If you are the owner, and you do *not* plan to work on it,
please reassign it to [e-mail] or a .bugs component owner. If you are
*anybody*, and you get this comment, and *you* plan to work on the bug, please
reassign it to yourself if you have the ability.

Comment 24

[John Ellson]

I'm willing to support this in any way I can from the graphviz side, but I'm not
familiar enough with the bugzilla code base or design goals to take this by myself.

Please note that graphviz-2.2 is the currently recommended stable version of
graphviz.

Comment 25

[Dave Miller [:justdave]]

I don't have time to work on this personally, so getting it off my buglist. 
CCing some of the newer team members who might be interested in taking it on.

Comment 26

[Alex Pavloff]

For a local dot, the problem can be fixed by using a forward slashed, no spaces
path for the dotpath, like 

C:/progra~1/ATT/Graphviz/bin/dot.exe

Paths that use backslashes and spaces will validate properly in the params form,
but will fail when the system goes to call dot.

The problem is in showdepedencygraph.cgi -- $webdotbase needs to be massaged a
bit for Windows installations.

Comment 27

[timeless]

i believe that's bug 312304 (fixed)

Comment 28

[devon]

This is still a problem in Bugzilla 5.0.4.
Clicking a bug's Dependency Graph link (for one both with bugs that it Depends on and Blocks) gives an invalid URL that eventually leads to (https://about.att.com/error.html).
Any workarounds or is that it until a developer has time to mess about with it?
Thanks very much either way