it's a graphviz bug and should already have been repared: http://www.graphviz.org/bugs/b922.html can someone update ebuild?
Created attachment 87999 [details] Input to dot that will draw a simple UML type class file The command I use to process the attached file is: dot -Tpng -o class.png class.dot and use something like firefox or kuickshow to view the image file created in class.png. Using graphviz-2.6-r1 produces the expected image. Using graphviz-2.8 produces the same size image that's entirely black.
same here...
I've emerged the development snapshot (today 2.9.20060604.0440) by renaming the original ebuild (had to comment out the notcl patch on line 38.). The problem of this ebuild doesn't occur anymore. Haven't done any heavy testing and thus don't know if some other issues turn up. HTH, Urs
This bug exist only with png,tiff,jpg infact with svg the image are correct;
Don't understand why graphviz 2.8 has been marked stable on x86 with such a blocking [1] bug! [1] GraphViz used only to render (in PNG) dynamic graphs in a web-application.
exists upstream: http://www.graphviz.org/bugs/b922.html
I had the same problem, and the easy solution was to do LC_ALL=C emerge graphviz (My original setting of LC_ALL was en_US.utf8. In graphviz lib/common/Makefile.am contains a rule that sorts color names by using LC_COLLATE=C $(SORT) ..., but LC_COLLATE has no effect when LC_ALL is set, so the color names ended up listed in the wrong order.)
It seems that nobody cares about graphviz... so I've gone ahead and commited the LC_ALL based fix.
that is a workaround, not a fix
> that is a workaround, not a fix It's not the perfect fix, since LC_ALL=C is applied to the whole compilation, rather than just the sort command, but in what way is it not a fix at all?
a fix is something applied to the source code that fixes the root cause and then you would send it upstream a workaround is none of these things, yet the final result still works
The root issue is that the sort command does not compare the same way as strcmp() does. The fix is to do sort using a strcmp()-compatible comparison function. LC_ALL=C is the way to do this (for ASCII systems -- which last time I asked was an acceptable assumption for Gentoo). Your distinction between things that can be sent upstream and things that can't is an important one, but a different one. There are ebuilds that contain the build system in themselves, and using your meaning of "fix" it's impossible to fix /anything/ that gets broken by them. This issue is fixed.
is the `sort` in the ebuild ? no ? then LC_ALL does not belong in the ebuild if the call to `sort` in the graphviz build system needs standard ASCII sorting, then you patch the graphviz build system to use LC_ALL=C *only* when calling sort if someone told you that inserting LC_ALL into ebuilds is acceptable, they were wrong
I already acknowledged that it would have been better to use LC_ALL=C only for the sort call. You're avoiding addressing my point. (And since I doubt you will change that after this: don't feel a need to reply to this.)
i didnt avoid your point, i addressed it pretty clearly the issue here is that the makefile is broken ... thus your section about the ebuild being the build system is irrelevant this bug is not fixed until the Makefile is patched and sent upstream ... so long as LC_ALL is in the ebuild and not the Makefile, it is a workaround and the bug report stays open
fixed in cvs by changing LC_COLLATE in the makefile to LC_ALL
