Announce: graphviz-2.20.2 stable release

After a couple of false starts, we are pleased to announce
our next 
stable release: graphviz-2.20.2
available from:    <http://www.graphviz.org/
>


This is primarily a bug fix release.    I have tried to
incorporate all 
fixes from SuSE, NetBSD, Ubuntu, and Fedora that I'm aware
of.  If you 
have patches in your distro that you feel should be in our
upstream 
sources please point me to them.

For Redhat distributions, this release relies on recent
versions of 
rpmbuild, so support for the old Redhat7..9 has been
dropped, and
graphviz.spec now works for Fedora's "fc10" dist
tag.


There is a new libcgraph in this releases. The gvpr tools
have migrated 
to this new library.  We hope to migrate
all the other tools to libcgraph in the next release,
eventually 
dropping all usage of libgraph or libagraph.


There is a new "folder" shape for nodes, and a
-Teps format for 
single-page output in encapsulated-PostScript format.


As usual, please report any bugs to: <http://www.graph
viz.org/Bugs.php>


John Ellson


   
_______________________________________________
graphviz-interestresearch.att.com
https://mailman.research.att.com/mailman/list
info/graphviz-interest

John Ellson <ellsonresearch.att.com> (02/07/2008):
> After a couple of false starts, we are pleased to
announce our next
> stable release: graphviz-2.20.2
> available from:    <http://www.graphviz.org/
>

Just an update from Debian: currently we have 2.20.0 in both
unstable
and testing, and virtually 2.20.0 in the next stable
version, since the
freeze just started.

However, I've got a release-critical bug to fix, on the php5
bindings.
It looks like I've got no clue how to actually load and use
this php5
extension, although I've tried various combinations on .php
and .so
locations. Maybe someone would have a working example of the
php5
bindings? (Locations of the files, and tiny script to test
it would be
more than welcome.)

Bugfixes for important bugs should still be OK for inclusion
in further
uploads to unstable: migration to testing is currently
blocked, but a
freeze exception can be granted by the release managers if
we prove we
include important bugfixes. Continued below…

> This is primarily a bug fix release.    I have tried to
incorporate
> all  fixes from SuSE, NetBSD, Ubuntu, and Fedora that
I'm aware of.
> If you  have patches in your distro that you feel
should be in our
> upstream  sources please point me to them.

(I think Debian gave them all already, what I keep currently
should only
be integration patches.)

> There is a new libcgraph in this releases. The gvpr
tools have
> migrated  to this new library.  We hope to migrate all
the other tools
> to libcgraph in the next release, eventually  dropping
all usage of
> libgraph or libagraph.
>
> There is a new "folder" shape for nodes, and
a -Teps format for
> single-page output in encapsulated-PostScript format.

… having a quick look at the diff between 2.20.0 and
2.20.2, the
bugfixes sounded like acceptable, meaning I could think of
uploading
2.20.2 as-is, once the php5 bug fixed. Although, I'm not
sure a new
library will be allowed, so I might have to backport the
fixes instead.
I'll keep you posted once I've actually built 2.20.2, and
check the
binary differences. If it looks fine, I'll eventually ask
for a freeze
exception quite soon (and keep you posted), but the real
problem I'm
facing now is the php5 bindings.

Mraw,
KiBi.

_______________________________________________
graphviz-interestresearch.att.com
https://mailman.research.att.com/mailman/list
info/graphviz-interest

Cyril,

Here is a simple php test program that loads hello.gv,
modifies it, does 
a layout, and renders to a .png on stdout.

Run it with:

./test.php | display -

The installation of the php binding requires write
permission into 
PHP_INSTALL_DIR and  PHP_INSTALL_DATADIR
(typically: /usr/lib/php/modules and /usr/share/php ) These
are the 
directories that php looks in for its extensions, without
requiring the 
script writer
to mess with extra search paths.

Check that ./configure.ac is identifying these directories
correctly 
from the installed php, and that the installation in
tclpkg/Makefile.am
is working. It will just generate a warning rather than
failing if write 
permission is not available. This is to support
installation, without 
the softlinks,
in a private --prefix during development without root
priviledges.

The installed files on Fedora (over the base graphviz
installation) are:
/usr/lib/graphviz/php/gv.php
/usr/lib/graphviz/php/gv.so ->
/usr/lib/graphviz/php/libgv_php.so
/usr/lib/graphviz/php/libgv_php.so
/usr/lib/php/modules/gv.so ->
/usr/lib/graphviz/php/libgv_php.so
/usr/share/graphviz/demo/modgraph.php
/usr/share/man/mann/gv_php.n.gz
/usr/share/php/gv.php -> /usr/lib/graphviz/php/gv.php


John


Cyril Brulebois wrote:
> John Ellson <ellsonresearch.att.com>
(02/07/2008):
>   
>> After a couple of false starts, we are pleased to
announce our next
>> stable release: graphviz-2.20.2
>> available from:    <http://www.graphviz.org/
>
>>     
>
> Just an update from Debian: currently we have 2.20.0 in
both unstable
> and testing, and virtually 2.20.0 in the next stable
version, since the
> freeze just started.
>
> However, I've got a release-critical bug to fix, on the
php5 bindings.
> It looks like I've got no clue how to actually load and
use this php5
> extension, although I've tried various combinations on
.php and .so
> locations. Maybe someone would have a working example
of the php5
> bindings? (Locations of the files, and tiny script to
test it would be
> more than welcome.)
>
> Bugfixes for important bugs should still be OK for
inclusion in further
> uploads to unstable: migration to testing is currently
blocked, but a
> freeze exception can be granted by the release managers
if we prove we
> include important bugfixes. Continued below…
>
>   
>> This is primarily a bug fix release.    I have
tried to incorporate
>> all  fixes from SuSE, NetBSD, Ubuntu, and Fedora
that I'm aware of.
>> If you  have patches in your distro that you feel
should be in our
>> upstream  sources please point me to them.
>>     
>
> (I think Debian gave them all already, what I keep
currently should only
> be integration patches.)
>
>   
>> There is a new libcgraph in this releases. The gvpr
tools have
>> migrated  to this new library.  We hope to migrate
all the other tools
>> to libcgraph in the next release, eventually 
dropping all usage of
>> libgraph or libagraph.
>>
>> There is a new "folder" shape for nodes,
and a -Teps format for
>> single-page output in encapsulated-PostScript
format.
>>     
>
> … having a quick look at the diff between 2.20.0 and
2.20.2, the
> bugfixes sounded like acceptable, meaning I could think
of uploading
> 2.20.2 as-is, once the php5 bug fixed. Although, I'm
not sure a new
> library will be allowed, so I might have to backport
the fixes instead.
> I'll keep you posted once I've actually built 2.20.2,
and check the
> binary differences. If it looks fine, I'll eventually
ask for a freeze
> exception quite soon (and keep you posted), but the
real problem I'm
> facing now is the php5 bindings.
>
> Mraw,
> KiBi.
>   
>
------------------------------------------------------------
------------
>
> _______________________________________________
> graphviz-interestresearch.att.com
> https://mailman.research.att.com/mailman/list
info/graphviz-interest
>   


_______________________________________________
graphviz-interestresearch.att.com
https://mailman.research.att.com/mailman/list
info/graphviz-interest

John Ellson <john.ellsoncomcast.net>
(27/07/2008):
> Here is a simple php test program that loads hello.gv,
modifies it,
> does  a layout, and renders to a .png on stdout.

Thanks, works very fine, now that I've fixed the packaging
as explained
below.

(Oh, and I got all attachments the first time.)

> Run it with:
>
> ./test.php | display -
>
> The installation of the php binding requires write
permission into  
> PHP_INSTALL_DIR and  PHP_INSTALL_DATADIR
> (typically: /usr/lib/php/modules and /usr/share/php )
These are the  
> directories that php looks in for its extensions,
without requiring the  
> script writer
> to mess with extra search paths.
>
> Check that ./configure.ac is identifying these
directories correctly  
> from the installed php, and that the installation in
tclpkg/Makefile.am
> is working. It will just generate a warning rather than
failing if write  
> permission is not available. This is to support
installation, without  
> the softlinks,
> in a private --prefix during development without root
priviledges.
>
> The installed files on Fedora (over the base graphviz
installation) are:
> /usr/lib/graphviz/php/gv.php
> /usr/lib/graphviz/php/gv.so ->
/usr/lib/graphviz/php/libgv_php.so
> /usr/lib/graphviz/php/libgv_php.so
> /usr/lib/php/modules/gv.so ->
/usr/lib/graphviz/php/libgv_php.so
> /usr/share/graphviz/demo/modgraph.php
> /usr/share/man/mann/gv_php.n.gz
> /usr/share/php/gv.php ->
/usr/lib/graphviz/php/gv.php

OK, my problem is that I was trying to ship the .php file
under
/usr/share/php5 (which is our default version), while the
search path,
regardless of the version, is only /usr/share/php. I've
chosen to ship
gv.php and gv.so, without the symlinks (as for the other
bindings), and
things look like going very fine.

The only thing I've got to do right now is to update the
bindings
documentation since we have to ship the extensions as
follows:
/usr/share/php/<package>/<extension files>, so
people will have to use
  include("libgv-php5/gv.php");
instead of just
  include("gv.php");

(Probably to prevent possible file overlapping.)


As for the new 'cgraph' library, that should be no problem
since it was
actually in 2.20.0 already, so I guess 2.20.2 could make it
into the
next stable release without my backporting fixes onto 2.20.0
(which
functionally would be the very same, the version numbers
left apart).

Thank you very much for your responsiveness, as always!

Mraw,
KiBi.

_______________________________________________
graphviz-interestresearch.att.com
https://mailman.research.att.com/mailman/list
info/graphviz-interest

Cyril Brulebois wrote:
> OK, my problem is that I was trying to ship the .php
file under
> /usr/share/php5 (which is our default version), while
the search path,
> regardless of the version, is only /usr/share/php. I've
chosen to ship
> gv.php and gv.so, without the symlinks (as for the
other bindings), and
> things look like going very fine.
>
> The only thing I've got to do right now is to update
the bindings
> documentation since we have to ship the extensions as
follows:
> /usr/share/php/<package>/<extension files>,
so people will have to use
>   include("libgv-php5/gv.php");
> instead of just
>   include("gv.php");
>
> (Probably to prevent possible file overlapping.)
>   

It would be better for script portability, and for
documentation, and 
for general ease of use, if
the user didn't have to work this out and change it.

Ideally, the installed php executable, or a pkgconfig
mechanism, would 
tell us the right
locations for PHP_INSTALL_DIR and PHP_INSTALL_DATADIR.  
Currently
these are hard-coded in configure.ac, so a better fix would
be for you 
to change those values
with a patch to configure.

John
_______________________________________________
graphviz-interestresearch.att.com
https://mailman.research.att.com/mailman/list
info/graphviz-interest