Bugzilla Bug 134834

it's a graphviz bug and should already have been repared:

http://www.graphviz.org/bugs/b922.html

can someone update ebuild?

Created an attachment (id=87999) [edit]
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