134834 2006-05-29 15:22 0000 graphviz 2.8 produces black pictures 2006-10-06 11:46:18 0000 1 1 1 Unclassified Gentoo Linux Ebuilds unspecified x86 Linux RESOLVED FIXED http://www.graphviz.org/bugs/b922.html P2 normal --- 1 filter.my@seznam.cz graphics@gentoo.org bill_krueger@verizon.net danmitchell@mail.utexas.edu giamma@vki.ac.be gralves@gmail.com kovacsp3@comcast.net ladanyi@tmit.bme.hu patrick.allaert@gmail.com truedfx@gentoo.org tschenturs@gmx.ch filter.my@seznam.cz 2006-05-29 15:22:09 0000 it's a graphviz bug and should already have been repared: http://www.graphviz.org/bugs/b922.html can someone update ebuild? bill_krueger@verizon.net 2006-05-31 09:57:49 0000 Created an attachment (id=87999) 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. tschenturs@gmx.ch 2006-06-04 22:56:31 0000 same here... tschenturs@gmx.ch 2006-06-05 05:20:28 0000 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 yoghi@sigmalab.net 2006-07-08 07:08:08 0000 This bug exist only with png,tiff,jpg infact with svg the image are correct; patrick.allaert@gmail.com 2006-09-14 05:05:32 0000 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. patrick.allaert@gmail.com 2006-09-14 07:25:20 0000 exists upstream: http://www.graphviz.org/bugs/b922.html gdrasny@earthlink.net 2006-09-19 10:55:16 0000 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.) chrb@gentoo.org 2006-09-21 14:05:17 0000 It seems that nobody cares about graphviz... so I've gone ahead and commited the LC_ALL based fix. vapier@gentoo.org 2006-09-21 15:28:55 0000 that is a workaround, not a fix truedfx@gentoo.org 2006-09-22 04:37:41 0000 > 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? vapier@gentoo.org 2006-09-22 10:40:02 0000 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 truedfx@gentoo.org 2006-09-22 11:10:25 0000 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. vapier@gentoo.org 2006-09-22 11:37:17 0000 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 truedfx@gentoo.org 2006-09-22 11:45:50 0000 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.) vapier@gentoo.org 2006-09-22 13:02:12 0000 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 vapier@gentoo.org 2006-10-06 11:46:18 0000 fixed in cvs by changing LC_COLLATE in the makefile to LC_ALL 87999 2006-05-31 09:57 0000 Input to dot that will draw a simple UML type class file class.dot text/plain ZGlncmFwaCBHIHsKICAgICAgICBmb250bmFtZSA9ICJCaXRzdHJlYW0gVmVyYSBTYW5zIgogICAg ICAgIGZvbnRzaXplID0gOAoKICAgICAgICBub2RlIFsKICAgICAgICAgICAgICAgIGZvbnRuYW1l ID0gIkJpdHN0cmVhbSBWZXJhIFNhbnMiCiAgICAgICAgICAgICAgICBmb250c2l6ZSA9IDgKICAg ICAgICAgICAgICAgIHNoYXBlID0gInJlY29yZCIKICAgICAgICBdCgogICAgICAgIGVkZ2UgWwog ICAgICAgICAgICAgICAgZm9udG5hbWUgPSAiQml0c3RyZWFtIFZlcmEgU2FucyIKICAgICAgICAg ICAgICAgIGZvbnRzaXplID0gOAogICAgICAgIF0KCiAgICAgICAgQW5pbWFsIFsKICAgICAgICAg ICAgICAgIGxhYmVsID0gIntBbmltYWx8KyBuYW1lIDogc3RyaW5nXGwrIGFnZSA6IGludFxsfCsg ZGllKCkgOiB2b2lkXGx9IgogICAgICAgIF0KfQo=