Bug#736605: RFA: graphviz -- rich set of graph drawing tools
On 25/01/14 14:28, Christoph Egger wrote: Package: wnpp Severity: normal Hi all! Both, tokkee and myself, do not have the time to take care of graphviz (even if it's just being available for review and sponsoring). David may still be motivated, if so, please speak up! Still it's a somewhat complex library package and someone with upload priviledges helping him would certainly be usefull. Christoph The package description is: Graph drawing addresses the problem of visualizing structural information by constructing geometric representations of abstract graphs and networks. Automatic generation of graph drawings has important applications in key technologies such as database design, software engineering, VLSI and network design and visual interfaces in other domains. Situations where these tools might be particularly useful include: . * you would like to restructure a program and first need to understand the relationships between its types, procedures, and source files * you need to find the bottlenecks in an Internet backbone - not only individual links, but their relationships * you're debugging a protocol or microarchitecture represented as a finite state machine and need to figure out how a certain error state arises * you would like to browse a database schema, knowledge base, or distributed program represented graphically * you would like to see an overview of a collection of linked documents * you would like to discover patterns and communities of interest in a database of telephone calls or e-mail messages . This package contains the command-line tools. Hi, TBH, it is probably true that I have also not been able to find the time recently to do justice to the package. I'll continue to try and complete the release currently sitting in the git archive in time for Jessie, but if someone out there wants to take over, I think it is probably time I handed over the reins. Cheers, David. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729273: graphviz: buffer overflow in dijkstra
tags 729273 + pending thanks Hi, I have a fix for this in git which is more or less ready, expect that the repo is on Alioth which is down right now. I'll see about getting it uploaded as soon as it is operational again. Cheers, David. On 11/11/13 02:23, Sang Kil Cha wrote: Package: graphviz Version: 2.26.3-14 Severity: grave Tags: security Justification: user security hole dijkstra (also nop) has a buffer overflow vulnerability. A PoC file is attached. command line to reproduce: $ /usr/bin/dijkstra a foo or $ /usr/bin/nop foo Program received signal SIGSEGV, Segmentation fault. 0x41414141 in ?? () (gdb) -- System Information: Debian Release: 7.1 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-3-686-pae (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages graphviz depends on: ii libc6 2.13-38 ii libcdt4 2.26.3-14 ii libcgraph5 2.26.3-14 ii libexpat1 2.1.0-1 ii libgd2-xpm 2.0.36~rc1~dfsg-6.1 ii libgraph4 2.26.3-14 ii libgvc5 2.26.3-14 ii libgvpr12.26.3-14 ii libx11-62:1.5.0-1+deb7u1 ii libxaw7 2:1.0.10-2 ii libxmu6 2:1.1.1-1 ii libxt6 1:1.1.3-1+deb7u1 Versions of packages graphviz recommends: ii ttf-liberation 1.07.2-6 Versions of packages graphviz suggests: pn graphviz-doc none ii gsfonts 1:8.11+urwcyr1.0.7~pre44-4.2 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722660: libgraphviz-dev and blt-dev: error when trying to install together
reassign 722660 blt thanks Hi, I'm reassigning this to blt as it looks like this might be a regression. The changelog for version 2.4z-3 says the following: Moved the man pages and HTML docs for the BLT commands from the blt-dev package to the blt package, where they really belong. Left just the man pages for the BLT C API calls in the blt-dev package. Renamed the command man pages to have the extension .3blt (I wanted to use .3tcl, but that caused a conflict with the tcllib package). This appears to be the case up to the latest version, where the files seem to be back in the dev package and are no longer renamed .3blt. I can't see anything in the more recent changelog entries that would suggest that this is deliberate. Cheers, David. On 13/09/13 07:10, Ralf Treinen wrote: Package: blt-dev,libgraphviz-dev Version: blt-dev/2.4z-6 Version: libgraphviz-dev/2.26.3-15+b1 Severity: serious User: trei...@debian.org Usertags: edos-file-overwrite Date: 2013-09-13 Architecture: amd64 Distribution: sid Hi, automatic installation tests of packages that share a file and at the same time do not conflict by their package dependency relationships has detected the following problem: WARNING: The following packages cannot be authenticated! libdrm2 libffi6 libglapi-mesa libllvm3.2 libxau6 libxdmcp6 libxcb1 libxcb-dri2-0 libgbm1 libwayland-client0 libwayland-server0 libx11-data libx11-6 libx11-xcb1 libxcb-render0 libxcb-shape0 libxcb-xfixes0 libegl1-mesa libexpat1 libfreetype6 ucf fonts-dejavu-core ttf-dejavu-core fontconfig-config libfontconfig1 libxcb-glx0 libxfixes3 libxdamage1 libxext6 libxxf86vm1 libgl1-mesa-glx libpixman-1-0 libpng12-0 libxcb-shm0 libxrender1 libcairo2 libdatrie1 libjpeg8 libjbig0 libtiff4 libvpx1 libxpm4 libgd3 libglib2.0-0 libgraphite2-3 libharfbuzz0a libltdl7 libthai-data libthai0 fontconfig libpango-1.0-0 libpangoft2-1.0-0 libpangocairo-1.0-0 libxft2 x11-common libxss1 tcl8.5 tk8.5 blt libc-dev-bin linux-libc-dev libc6-dev libcdt4 libcgraph5 libexpat1-dev zlib1g-dev libfreetype6-dev pkg-config libfontconfig1-dev libgraph4 libpathplan4 libxdot4 libgvc5 libgvpr1 libltdl-dev libgraphviz-dev libpthread-stubs0 libpthread-stubs0-dev xorg-sgml-doctools x11proto-core-dev libxau-dev libxdmcp-dev x11proto-input-dev x11proto-kb-dev xtrans-dev libxcb1-dev libx11-dev x11proto-xext-dev libxext-dev x11proto-render-dev libxrender-dev libxft-dev x11proto-scrnsaver-dev libxss-dev tcl8.5-dev tk8.5-dev blt-dev Extracting templates from packages: 30% Extracting templates from packages: 61% Extracting templates from packages: 92% Extracting templates from packages: 100% Preconfiguring packages ... Authentication warning overridden. Selecting previously unselected package libdrm2:amd64. (Reading database ... 10882 files and directories currently installed.) Unpacking libdrm2:amd64 (from .../libdrm2_2.4.46-2_amd64.deb) ... Selecting previously unselected package libffi6:amd64. Unpacking libffi6:amd64 (from .../libffi6_3.0.13-4_amd64.deb) ... Selecting previously unselected package libglapi-mesa:amd64. Unpacking libglapi-mesa:amd64 (from .../libglapi-mesa_9.1.6-2+b1_amd64.deb) ... Selecting previously unselected package libllvm3.2:amd64. Unpacking libllvm3.2:amd64 (from .../libllvm3.2_1%3a3.2repack-11_amd64.deb) ... Selecting previously unselected package libxau6:amd64. Unpacking libxau6:amd64 (from .../libxau6_1%3a1.0.8-1_amd64.deb) ... Selecting previously unselected package libxdmcp6:amd64. Unpacking libxdmcp6:amd64 (from .../libxdmcp6_1%3a1.1.1-1_amd64.deb) ... Selecting previously unselected package libxcb1:amd64. Unpacking libxcb1:amd64 (from .../libxcb1_1.9.1-3_amd64.deb) ... Selecting previously unselected package libxcb-dri2-0:amd64. Unpacking libxcb-dri2-0:amd64 (from .../libxcb-dri2-0_1.9.1-3_amd64.deb) ... Selecting previously unselected package libgbm1:amd64. Unpacking libgbm1:amd64 (from .../libgbm1_9.1.6-2+b1_amd64.deb) ... Selecting previously unselected package libwayland-client0:amd64. Unpacking libwayland-client0:amd64 (from .../libwayland-client0_1.2.1-1_amd64.deb) ... Selecting previously unselected package libwayland-server0:amd64. Unpacking libwayland-server0:amd64 (from .../libwayland-server0_1.2.1-1_amd64.deb) ... Selecting previously unselected package libx11-data. Unpacking libx11-data (from .../libx11-data_2%3a1.6.1-1_all.deb) ... Selecting previously unselected package libx11-6:amd64. Unpacking libx11-6:amd64 (from .../libx11-6_2%3a1.6.1-1_amd64.deb) ... Selecting previously unselected package libx11-xcb1:amd64. Unpacking libx11-xcb1:amd64 (from .../libx11-xcb1_2%3a1.6.1-1_amd64.deb) ... Selecting previously unselected package libxcb-render0:amd64. Unpacking libxcb-render0:amd64 (from .../libxcb-render0_1.9.1-3_amd64.deb) ... Selecting previously unselected package libxcb-shape0:amd64. Unpacking libxcb-shape0:amd64 (from .../libxcb-shape0_1.9.1-3_amd64.deb) ...
Bug#695088: graphviz: Please mark Multi-Arch: foreign
tags 695088 + pending thanks On 15/05/13 01:35, Colin Watson wrote: It's been applied to 655 packages already, so this is work that is well underway ... Good enough for me, I've applied the changes to the git archive. If you want to, you can build it from there using git-buildpackage - any feedback would be gratefully accepted ;-) Cheers, David. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#707502: graphviz: FTBFS: cp: cannot stat 'debian/tmp/usr/lib/graphviz/python26': No such file or directory
tags 707502 + pending thanks On 19/05/13 10:18, Roland Stigge wrote: Hi, the attached patch fixes the build error. There might be issues left for a complete python transition, though. Roland Thanks Roland, I've applied this fix to the git archive. Cheers, David. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695088: graphviz: Please mark Multi-Arch: foreign
On 04/12/12 02:48, Colin Watson wrote:
Package: graphviz
Version: 2.26.3-12
Severity: wishlist
Tags: patch
User: crossbu...@debian.org
Usertags: cross
graphviz is Architecture: any, but on a multiarch system it doesn't
matter which architecture you get as long as you can execute its
binaries. It's a build-dependency of 179 packages in unstable.
Accordingly, it would be helpful to mark it Multi-Arch: foreign to avoid
blocking cross-builds of those packages; that would allow cross-builds
to use the version of graphviz for the architecture being built on,
which is generally best for tools as opposed to libraries.
* Mark graphviz Multi-Arch: foreign.
diff -Nru graphviz-2.26.3/debian/control graphviz-2.26.3/debian/control
--- graphviz-2.26.3/debian/control2012-07-10 23:37:19.0 +0100
+++ graphviz-2.26.3/debian/control2012-12-04 02:44:20.0 +
@@ -49,6 +49,7 @@
Package: graphviz
Architecture: any
+Multi-Arch: foreign
Depends: ${shlibs:Depends}, ${misc:Depends}
Conflicts: gdtclft
Recommends: ttf-liberation
Thanks,
Hi Colin,
Apologies for not responding sooner, but I've been taking a bit of an
hiatus from graphviz while the freeze was in place.
Can I just clarify - is your suggestion of Multi-Arch: foreign
intended as a stop-gap pending the implementation of a full Multi-Arch
implementation of graphviz? The reason I ask, is because I have 2.28
waiting in the wings on the git archive which has multi-arch implemented
(or nearly so, I just need to test the -dev package and then actually
mark the packages Multi-Arch: same).
Would a Multi-Arch:same graphviz meet your needs? If so, I'll close
this bug with 2.28 when it's uploaded. (If not, I've badly
misunderstood something somewhere).
Cheers,
David.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695088: graphviz: Please mark Multi-Arch: foreign
On 14/05/13 23:37, Colin Watson wrote: I don't understand how graphviz itself could possibly be Multi-Arch: same. Things like libgraph4, sure, but you can't make a package that ships compiled code in /usr/bin/ M-A: same - builds on different architectures will inevitably clash - and it wouldn't really be very useful to try. M-A: same is normally for packages containing libraries and such, not for packages containing executables on $PATH. I certainly encourage you to make libraries M-A: same wherever possible, but it's orthogonal to this bug. Ah, now I understand. I was indeed referring to making the libraries Multi-Arch:same, not the main graphviz package. Hmm, so the idea is that you might be, for example, cross compiling doxygen for sparc on a x86 machine, and you want the dependancy on graphviz to match to the x86 graphviz which might already be installed - something along those lines? ISTM the same logic could apply to quite a large number of other packages. Usage of Multi-Arch:foreign in the documentation I've seen (primarily http://wiki.debian.org/Multiarch/Implementation) seems to focus more on support packages within the same source package, rather than this apparently more extensive usage. Has there been any discussion around this sort of use on -devel to your knowledge? Just be clear, I'm not particularly against marking graphviz M-A:foreign, but my concern is if the same logic could apply to lots of other packages, then it would be nice to see some sort of consensus that this is the Right-Thing-To-Do(tm) OTOH, it's late in my timezone, so I might just not be thinking clearly ;-) Cheers, David. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703467: pu: package graphviz/2.26.3-5+b1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: pu Hi Stable Release Team, Bug #702436 has recently been reported against graphviz, which advises that graphviz is being linked with an ancient shipped version of libltdl instead of the system version. On investigation it has become clear that the version being linked against is susceptible to a known security issue - DSA-1958-1 (CVE-2009-3736). I have already uploaded a fixed version to unstable for release with wheezy, but the issue also affects version 2.26.3-5 of the package in squeeze. Accordingly I have created an stable update and the debdiff for this is attached - it modifies the package to use the system ltdl as it should have been doing all along. I have contacted the security team (RT bug #4230) and they advise that this is relatively minor and should be approached as a stable update. I'd appreciate it if you could take a look and advise if you would like me to upload it. Cheers, David. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.38-2-686 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash diff -Nru graphviz-2.26.3/debian/changelog graphviz-2.26.3/debian/changelog --- graphviz-2.26.3/debian/changelog 2010-07-04 10:12:32.0 +0100 +++ graphviz-2.26.3/debian/changelog 2013-03-19 23:25:23.0 + @@ -1,3 +1,14 @@ +graphviz (2.26.3-5+squeeze1) stable; urgency=low + + * Use system ltdl in place of version in subdir (Closes: #702436) +- Currently an ancient version of libltdl is being + shipped by upstream and linked against, unnoticed until now. + Changed configure.ac to ensure system ltdl is used instead +- Security issue - shipped ltdl is susceptible to issue + described in DSA-1958-1 (CVE-2009-3736) + + -- David Claughton d...@eclecticdave.com Tue, 19 Mar 2013 23:24:52 + + graphviz (2.26.3-5) unstable; urgency=low [ David Claughton ] diff -Nru graphviz-2.26.3/debian/patches/series graphviz-2.26.3/debian/patches/series --- graphviz-2.26.3/debian/patches/series 2010-07-04 10:09:19.0 +0100 +++ graphviz-2.26.3/debian/patches/series 2013-03-19 23:25:23.0 + @@ -8,3 +8,4 @@ 3_fix_dot_output 3_fix_circo_segfault 3_fix_vimdot_bashism +use-system-ltdl.patch diff -Nru graphviz-2.26.3/debian/patches/use-system-ltdl.patch graphviz-2.26.3/debian/patches/use-system-ltdl.patch --- graphviz-2.26.3/debian/patches/use-system-ltdl.patch 1970-01-01 01:00:00.0 +0100 +++ graphviz-2.26.3/debian/patches/use-system-ltdl.patch 2013-03-19 23:25:23.0 + @@ -0,0 +1,66 @@ +Index: graphviz/configure.ac +=== +--- graphviz.orig/configure.ac 2013-03-10 22:51:42.0 + graphviz/configure.ac 2013-03-10 22:52:01.0 + +@@ -464,30 +464,29 @@ + dnl --- + dnl libtool ltdl on-demand plugin loading + +-m4_ifdef([LT_INIT], +-[ #code that is for Libtool 2.x +-AM_PROG_LIBTOOL +-], +-[ #code that is for 1.5.x +-]) ++LT_INIT([dlopen]) ++LT_CONFIG_LTDL_DIR([libltdl]) ++LTDL_INIT ++ + AC_ARG_ENABLE(ltdl, + [AS_HELP_STRING([--enable-ltdl],[support on-demand plugin loading])]) + if test x$enable_ltdl != xno; then + AC_DEFINE(ENABLE_LTDL,1,[Define if you want on-demand plugin loading]) +- AC_LIBTOOL_DLOPEN +-m4_ifdef([LT_INIT], +-[ #code that is for Libtool 2.x +- LT_CONFIG_LTDL_DIR([libltdl]) +- LTDL_INIT +-], +-[ #code that is for 1.5.x +- AC_CONFIG_SUBDIRS([libltdl]) +-]) + use_ltdl=Yes +- +- AC_LIBLTDL_CONVENIENCE +- if test x$DARWIN9 = xyes; then +- LIBLTDL_LDFLAGS=-Wl,-unexported_symbol,_lt_* ++ # The lt_dladvise_init symbol was added with libtool-2.2 ++ if test x$with_included_ltdl != xyes; then ++save_CFLAGS=$CFLAGS ++save_LDFLAGS=$LDFLAGS ++CFLAGS=$CFLAGS $LTDLINCL ++LDFLAGS=$LDFLAGS $LIBLTDL ++AC_CHECK_LIB([ltdl], [lt_dladvise_init], [], ++ [AC_MSG_ERROR([installed libltdl is too old])]) ++LDFLAGS=$save_LDFLAGS ++CFLAGS=$save_CFLAGS ++ else ++if test x$DARWIN9 = xyes; then ++ LIBLTDL_LDFLAGS=-Wl,-unexported_symbol,_lt_* ++fi + fi + else + use_ltdl=No (disabled) +@@ -496,12 +495,6 @@ + AC_SUBST(INCLTDL) + AC_SUBST(LIBLTDL) + AC_SUBST(LIBLTDL_LDFLAGS) +-m4_ifdef([LT_INIT], +-[ #code that is for Libtool 2.x +-], +-[ #code that is for 1.5.x +-AM_PROG_LIBTOOL +-]) + + # Checks for libraries. + #AC_CHECK_LIB([ICE], [main])
Bug#702920: unblock: graphviz/2.26.3-14
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package graphviz Version 2.26.3-14 fixes RC bug #702436 which addresses a security issue (links with ancient libltdl which suffers from DSA-1958-1) by switching to linking with system libltdl which it should have been doing all along. unblock graphviz/2.26.3-14 -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.38-2-686 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702436: Ships and uses an ancient version of libtool
Hi Michael, I've done some digging and the good news is this issue seems to have already been fixed upstream in 2.28, which is sitting in the git archive to be uploaded more or less when unstable reopens for business. It looks like 2.26 should also potentially be patched for wheezy, as security advice DSA-1958-1 may apply to the ltdl version being used. I'll look into this. Cheers, David. On 06/03/13 23:06, Michael Tautschnig wrote: Hi again, [...] Yes, you are correct that upstream ships an ancient libtool version. However I do not believe you are correct when you say that we are linking against it. [...] Here's the proper proof - the error message is produced by our compiler, thus can be safely ignored. The key point is the command line, which includes libltdlc.a (and no -lltdl). root@dkr13:~/graphviz-2.26.3/lib/gvc# make ; make V=1 CCLD libgvc.la file libltdlcS.c line 18: error: conflicting definition for variable `c::lt_libltdlc_LTX_preloaded_symbols' [... error details snipped ...] make: *** [libgvc.la] Error 64 /bin/bash ../../libtool --tag=CC --mode=link x86_64-linux-gnu-gcc -g -O2 -Wno-unknown-pragmas -Wstrict-prototypes -Wpointer-arith -Wall -ffast-math -version-info 5:0:0 -no-undefined -Wl,--as-needed -o libgvc.la -rpath /usr/lib gvrender.lo gvlayout.lo gvdevice.lo gvloadimage.lo gvcontext.lo gvjobs.lo gvevent.lo gvplugin.lo gvconfig.lo gvtextlayout.lo gvusershape.lo gvc.lo ../../lib/pack/libpack_C.la ../../lib/xdot/libxdot_C.la ../../lib/common/libcommon_C.la ../../libltdl/libltdlc.la ../../lib/xdot/libxdot.la ../../lib/cdt/libcdt.la ../../lib/graph/libgraph.la ../../lib/pathplan/libpathplan.la -lexpat -lz -lm -lz -lm libtool: link: rm -fr .libs/libgvc.so.5.0.0.gcc-binary libtool: link: x86_64-linux-gnu-gcc -shared .libs/gvrender.o .libs/gvlayout.o .libs/gvdevice.o .libs/gvloadimage.o .libs/gvcontext.o .libs/gvjobs.o .libs/gvevent.o .libs/gvplugin.o .libs/gvconfig.o .libs/gvtextlayout.o .libs/gvusershape.o .libs/gvc.o -Wl,--whole-archive ../../lib/pack/.libs/libpack_C.a ../../lib/xdot/.libs/libxdot_C.a ../../lib/common/.libs/libcommon_C.a ../../libltdl/.libs/libltdlc.a -Wl,--no-whole-archive -Wl,-rpath -Wl,/home/mictau/build/graphviz/graphviz-2.26.3/lib/xdot/.libs -Wl,-rpath -Wl,/home/mictau/build/graphviz/graphviz-2.26.3/lib/cdt/.libs -Wl,-rpath -Wl,/home/mictau/build/graphviz/graphviz-2.26.3/lib/graph/.libs -Wl,-rpath -Wl,/home/mictau/build/graphviz/graphviz-2.26.3/lib/pathplan/.libs -L/home/mictau/build/graphviz/graphviz-2.26.3/lib/cdt/.libs ../../lib/xdot/.libs/libxdot.so ../../lib/cdt/.libs/libcdt.so ../../lib/graph/.libs/libgraph.so /home/mictau/build/graphviz/graphviz-2.26.3/lib/cdt/.libs/libcdt.so ../../lib/pathplan/.libs/libpathp lan.so -l dl /usr/lib/x86_64-linux-gnu/libexpat.so -lz -lm -Wl,--as-needed -Wl,-soname -Wl,libgvc.so.5 -o .libs/libgvc.so.5.0.0 file libltdlcS.c line 18: error: conflicting definition for variable `c::lt_libltdlc_LTX_preloaded_symbols' Best, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702436: Ships and uses an ancient version of libtool
On 06/03/13 14:54, Michael Tautschnig wrote: Package: graphviz Version: 2.26.3-12 Usertags: goto-cc graphviz currently links against a shipped version of libtool that appears to be pre-2009, and at the very least is broken when using type-checking linkers. This was fixed in 2010: http://git.savannah.gnu.org/cgit/libtool.git/commit/libltdl/ltdl.c?id=03feff471901aeaac97b36964f88ed4d694dff99 Furthermore, libtool has even seen security fixes since that time. It may be worth updating the shipped libtool; preferably, however, the packaged version of libtool should be used instead by adding --with-included-ltdl to the configure command line. Best, Michael Hi Michael, Yes, you are correct that upstream ships an ancient libtool version. However I do not believe you are correct when you say that we are linking against it. I can't claim to be any kind of great expert in autoconf, but as far as I can see the configure command line option --with-included-ltdl actually does the opposite of what you suggest - below is quoted from the libtool docs ... --with-included-ltdl If there is no installed libltdl, or in any case if the person building your package would rather use the libltdl sources shipped with the package in the subdirectory named by LT_CONFIG_LTDL_DIR, they should pass this option to configure. If the --with-included-ltdl is not passed at configure time, and an installed libltdl is not found, then configure will exit immediately with an error that asks the user to either specify the location of an installed libltdl using the --with-ltdl-include and --with-ltdl-lib options, or to build with the libltdl sources shipped with the package by passing --with-included-ltdl. Cheers, David. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645410:
On 31/01/13 15:00, Loyall, David wrote: I am trying to build from git://git.debian.org/git/collab-maint/graphviz.git using git-buildpackage... But the build fails for [unstable] and [upstream/2.28.0] doesn’t contain debian magic. That’s as far as I got. :) Hi David, Sorry about that, I'd thought I'd left the git archive in a buildable state, but it seems I was mistaken :-) I've just pushed an update, if you feel like having another go. I currently intend to upload 2.28 pretty much as soon as unstable re-opens for business (once wheezy has been released). It could use a bit more testing though, so any feedback would be very welcome. Cheers, David. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688445: Can't select a font with Graphviz
Hi Gauthier,
In the examples you give, you appear to have left a space between the
words font and name. I think you intended to put fontname?
Works for me if I specify things like Helvetica or just for fun junkyard:
digraph G {
xyz [label =
hello\nworld,color=blue,fontsize=24,fontname=junkyard,style=filled,fontcolor=pink];
node [style=filled];
red [color=red];
green [color=green];
red - green;
}
$ dot -Tpdf -octext.pdf -v ctext.dot 21 | grep font
fontname: junkyard resolved to: (PangoCairoFcFont) Junkyard 24
fontname: Times-Roman resolved to: (ps:pango Times Roman,)
(PangoCairoFcFont) DejaVu Sans 14
AIUI The lookup for Times-Roman is happening because it is the default
font as used by the other nodes.
OTOH, Times New Roman does still resolve to DejaVu for me too, even
though fc-match thinks it should be Liberation Serif on my machine, so
it still looks like graphviz doesn't always end up with the font you expect.
Cheers,
David.
On 22/09/12 19:28, Gauthier Vandemoortele wrote:
Package: graphviz
Version: 2.26.3-12
I can't select a font in the graphs made by dot or neato. Regardless of
the fontname I specify, the result is always DejaVu Sans 24.
For example:
$ cat ctext.dot
digraph G {
xyz [label = hello\nworld,color=blue,fontsize=24,font name=Times
New Roman,style=filled,fontcolor=pink];
node [style=filled];
red [color=red];
green [color=green];
red - green;
}
$ fc-match Times New Roman
Times_New_Roman.ttf: Times New Roman Normal
$ dot -Tpdf -octext.pdf -v ctext.dot 21 | grep font
fontname: Times-Roman resolved to: (ps:pango Times Roman,)
(PangoCairoFcFont) DejaVu Sans 24
So i try this fontname...
$ fc-match Times-Roman
n021003l.pfb: Nimbus Roman No9 L Regular
$ cat ctext.dot
digraph G {
xyz [label = hello\nworld,color=blue,fontsize=24,font
name=Times-Roman,style=filled,fontcolor=pink];
node [style=filled];
red [color=red];
green [color=green];
red - green;
}
$ dot -Tpdf -octext.pdf -v ctext.dot 21 | grep font
fontname: Times-Roman resolved to: (ps:pango Times Roman,)
(PangoCairoFcFont) DejaVu Sans 24
Note that when I choose eps or ps as device, I get a serif font, but the
message returned by dot/neato is always the same. And in this case, I
can't get a sans-serif font by specifying helvetica or so.
Note also that dot/neato associates strangely Times-Roman with a
sans-serif font.
I am using Debian GNU/Linux wheezy/sid Linux 2.6.32-5-686 i686
Regards,
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683041: Info received (Bug#683041: Acknowledgement (graphviz: please mark Multi-arch: foreign))
Hi Shawn,
Thanks for your patch submission, sorry for the delay in responding to it.
Unfortunately I don't believe Multi-arch:Foreign is correct for graphviz
as this is intended to be used for arch:all support packages or packages
where it doesn't matter if its arch matches the one you are building
against. This is very much not the case for graphviz. See [1] for more
info.
However I have almost completed packaging the new upstream release
(2.28) and this includes Multiarch support. It just needs some proper
testing, in particular with regards to the -dev package and checking if
rdepends correctly build against it. I've not yet found the time to do
this, but you're welcome to give it a whirl if you wish. The code is
currently in the git archive at [2] which you can build with the
'git-buildpackage' utility.
[1]
http://wiki.debian.org/Multiarch/Implementation#Multi-Arch:_foreign_support_packages
[2] http://git.debian.org/?p=collab-maint/graphviz.git
Cheers,
David.
On 28/07/12 02:44, shawn wrote:
usertag 683041 cross
tag 683041 patch
thanks
diff --git a/debian/control b/debian/control
index 0362d43..4d11729 100644
--- a/debian/control
+++ b/debian/control
@@ -50,6 +50,7 @@ Homepage: http://www.graphviz.org/
Package: graphviz
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
+Multi-arch: foreign
Conflicts: gdtclft
Recommends: ttf-liberation
Suggests: gsfonts, graphviz-doc
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681437: unblock: graphviz/2.26.3-12
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package graphviz Testing contains version 2.26.3-10 of graphviz which currently FTBFS due to removal of python 2.5 and change to ruby to 1.9 by default. The previous 2.26.3-11 version fixed RC bug #669517 by removing a reference to python 2.5. However RC bug #676098 was raised before this could transit to testing. Version 2.26.3-12 fixes bug #676098 by explicitly referring to ruby 1.8 in both debian/control and configure.ac. debdiffs for both versions below: debdiff between 2.26.3-10 and 2.26.3-11 diff -Nru graphviz-2.26.3/debian/changelog graphviz-2.26.3/debian/changelog --- graphviz-2.26.3/debian/changelog2012-03-14 23:18:03.0 + +++ graphviz-2.26.3/debian/changelog2012-05-02 21:56:03.0 +0100 @@ -1,3 +1,10 @@ +graphviz (2.26.3-11) unstable; urgency=low + + * Remove reference to python 2.5 which is no longer available in sid +(Closes: #669517) + + -- David Claughton d...@eclecticdave.com Wed, 02 May 2012 21:53:08 +0100 + graphviz (2.26.3-10) unstable; urgency=low * Fixes for compatibility with Automake 1.11.2 (Closes: #661909) diff -Nru graphviz-2.26.3/debian/libgv-python.install graphviz-2.26.3/debian/libgv-python.install --- graphviz-2.26.3/debian/libgv-python.install 2011-05-18 20:41:03.0 +0100 +++ graphviz-2.26.3/debian/libgv-python.install 2012-05-02 21:56:03.0 +0100 @@ -1,5 +1,4 @@ usr/lib/graphviz/python -usr/lib/graphviz/python25 usr/lib/graphviz/python26 usr/lib/graphviz/python27 usr/share/man/man3/gv.3python debdiff between 2.26.3-11 and 2.26.3-12 diff -Nru graphviz-2.26.3/debian/changelog graphviz-2.26.3/debian/changelog --- graphviz-2.26.3/debian/changelog2012-05-02 21:56:03.0 +0100 +++ graphviz-2.26.3/debian/changelog2012-07-10 23:37:19.0 +0100 @@ -1,3 +1,11 @@ +graphviz (2.26.3-12) unstable; urgency=low + + * Fixes to explicitly use ruby 1.8 as default for ruby is now 1.9 +(Graphviz doesn't currently support ruby 1.9) +(Closes: #676098) + + -- David Claughton d...@eclecticdave.com Tue, 10 Jul 2012 21:41:24 +0100 + graphviz (2.26.3-11) unstable; urgency=low * Remove reference to python 2.5 which is no longer available in sid diff -Nru graphviz-2.26.3/debian/control graphviz-2.26.3/debian/control --- graphviz-2.26.3/debian/control 2012-05-02 21:56:03.0 +0100 +++ graphviz-2.26.3/debian/control 2012-07-10 23:37:19.0 +0100 @@ -27,7 +27,7 @@ ghostscript, lua5.1, liblua5.1-0-dev, - ruby, + ruby1.8, ruby1.8-dev, php5-dev, php5-cli, diff -Nru graphviz-2.26.3/debian/patches/explicit_ruby_1.8 graphviz-2.26.3/debian/patches/explicit_ruby_1.8 --- graphviz-2.26.3/debian/patches/explicit_ruby_1.81970-01-01 01:00:00.0 +0100 +++ graphviz-2.26.3/debian/patches/explicit_ruby_1.82012-07-10 23:37:19.0 +0100 @@ -0,0 +1,13 @@ +diff --git a/configure.ac b/configure.ac +index cacafe1..36c34b2 100644 +--- a/configure.ac b/configure.ac +@@ -1400,7 +1400,7 @@ else + if test `$SWIG -help 21 | $GREP -c '\-ruby *- Generate'` = 0; then + use_ruby=No (swig does not support -ruby option) + else +- AC_CHECK_PROG(RUBY,ruby,ruby) ++ AC_CHECK_PROG(RUBY,ruby1.8,ruby1.8) + if test x$RUBY = x; then + use_ruby=No (ruby not available) + else diff -Nru graphviz-2.26.3/debian/patches/series graphviz-2.26.3/debian/patches/series --- graphviz-2.26.3/debian/patches/series 2012-05-02 21:56:03.0 +0100 +++ graphviz-2.26.3/debian/patches/series 2012-07-10 23:37:19.0 +0100 @@ -13,3 +13,4 @@ fix-kfreebsd-chroots fix-hurd-autotools automake_1.11.2_fixes +explicit_ruby_1.8 unblock graphviz/2.26.3-12 -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.38-2-686 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676098: graphviz: FTBFS: cp: cannot stat `debian/tmp/usr/lib/graphviz/ruby/libgv_ruby.so': No such file or directory
tags 676098 + pending thanks Hi Lucas, Thanks for your efforts - looks like the package was broken by the recent change to use ruby 1.9 by default. I've pushed changes to the git repo that fixes the build, just needs a little testing before I get it uploaded... Cheers, David. On 04/06/12 23:19, Lucas Nussbaum wrote: Source: graphviz Version: 2.26.3-11 Severity: serious Tags: wheezy sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20120604 qa-ftbfs User: debian-r...@lists.debian.org Usertags: default19 Justification: FTBFS on amd64 Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part: make[3]: Entering directory `/«PKGBUILDDIR»' make[3]: Nothing to be done for `install-exec-am'. /bin/mkdir -p '/«PKGBUILDDIR»/debian/tmp/usr/share/man/man7' /usr/bin/install -c -m 644 graphviz.7 '/«PKGBUILDDIR»/debian/tmp/usr/share/man/man7' /bin/mkdir -p '/«PKGBUILDDIR»/debian/tmp/usr/include/graphviz' /usr/bin/install -c -m 644 graphviz_version.h '/«PKGBUILDDIR»/debian/tmp/usr/include/graphviz' /bin/mkdir -p '/«PKGBUILDDIR»/debian/tmp/usr/share/graphviz/doc' /usr/bin/install -c -m 644 AUTHORS COPYING ChangeLog NEWS cpl1.0.txt '/«PKGBUILDDIR»/debian/tmp/usr/share/graphviz/doc' make[3]: Leaving directory `/«PKGBUILDDIR»' make[2]: Leaving directory `/«PKGBUILDDIR»' make[1]: Leaving directory `/«PKGBUILDDIR»' # Remove .la files find -name '*.la' -delete # Strip the rpath on /usr/lib (at least on amd64), but not # on /usr/lib/graphviz (needed for the plugins), and bail # out if it is another case, while ignoring if there's no # RPATH at all (there are shell scripts under /usr/bin). for i in `find debian/tmp/usr/bin debian/tmp/usr/lib -type f` ; do \ case `chrpath -l -k $i` in \ *RPATH=/usr/lib/graphviz) ;; \ *RPATH=/usr/lib) chrpath -d $i ;; \ *RPATH=/usr/lib:/usr/lib/graphviz) chrpath -r /usr/lib/graphviz $i ;; \ *RPATH=*) echo Unknown RPATH: $i ; exit 1 ;; \ *) ;; \ esac ; \ done `debian/tmp/usr/bin/dotty' probably isn't a 64-bit LSB-first ELF file. elf_open: Exec format error `debian/tmp/usr/bin/lneato' probably isn't a 64-bit LSB-first ELF file. elf_open: Exec format error `debian/tmp/usr/bin/vimdot' probably isn't a 64-bit LSB-first ELF file. elf_open: Exec format error `debian/tmp/usr/lib/graphviz/python/gv.py' probably isn't a 64-bit LSB-first ELF file. elf_open: Exec format error `debian/tmp/usr/lib/graphviz/python27/gv.py' probably isn't a 64-bit LSB-first ELF file. elf_open: Exec format error `debian/tmp/usr/lib/graphviz/python26/gv.py' probably isn't a 64-bit LSB-first ELF file. elf_open: Exec format error `debian/tmp/usr/lib/graphviz/php/gv.php' probably isn't a 64-bit LSB-first ELF file. elf_open: Exec format error `debian/tmp/usr/lib/graphviz/perl/gv.pm' probably isn't a 64-bit LSB-first ELF file. elf_open: Exec format error `debian/tmp/usr/lib/graphviz/tcl/pkgIndex.tcl' probably isn't a 64-bit LSB-first ELF file. elf_open: Exec format error `debian/tmp/usr/lib/pkgconfig/libgvpr.pc' probably isn't a 64-bit LSB-first ELF file. elf_open: Exec format error `debian/tmp/usr/lib/pkgconfig/libgvc.pc' probably isn't a 64-bit LSB-first ELF file. elf_open: Exec format error `debian/tmp/usr/lib/pkgconfig/libxdot.pc' probably isn't a 64-bit LSB-first ELF file. elf_open: Exec format error `debian/tmp/usr/lib/pkgconfig/libpathplan.pc' probably isn't a 64-bit LSB-first ELF file. elf_open: Exec format error `debian/tmp/usr/lib/pkgconfig/libcgraph.pc' probably isn't a 64-bit LSB-first ELF file. elf_open: Exec format error `debian/tmp/usr/lib/pkgconfig/libgraph.pc' probably isn't a 64-bit LSB-first ELF file. elf_open: Exec format error `debian/tmp/usr/lib/pkgconfig/libcdt.pc' probably isn't a 64-bit LSB-first ELF file. elf_open: Exec format error # Compute the dependencies of the -dev package # NOTE: It is important to do that before splitting the files into # their respective packages, otherwise the symlinks are broken d-devlibdeps \ --override s/libpathplan4-dev// \ --override s/libgraph4-dev//\ --override s/libcdt4-dev// \ --override s/libcgraph5-dev// \ --override s/libgvpr4-dev// \ --override s/libxdot4-dev// \ /«PKGBUILDDIR»/debian/libgraphviz-dev.substvars \ /«PKGBUILDDIR»/debian/tmp/usr/lib/*.so -- libexpat1-dev package exists. -- zlib1g-dev package exists. # Move from debian/tmp to the appropriate packages, rename one binary dh_install --sourcedir=debian/tmp --list-missing cp: cannot stat `debian/tmp/usr/lib/graphviz/ruby/libgv_ruby.so': No such file or directory dh_install: cp -a debian/tmp/usr/lib/graphviz/ruby/libgv_ruby.so debian/libgv-ruby//usr/lib/graphviz/ruby/
Bug#674150: libgvc5 install fails
Hi Sylvestre, I'm afraid I'm having trouble reproducing your problem. Although I don't use cowbuilder, I've successfully installed the package both directly and on an sbuild schroot. Could be a corrupt package download - can you re-download and try again, maybe from a different mirror? Cheers, David. On 23/05/12 13:10, Sylvestre Ledru wrote: Package: libgvc5 Version: 2.26.3-11 Severity: grave Justification: renders package unusable Hello, The install of libgvc5 2.26.3-11 is failing with: Setting up libgvc5 (2.26.3-11) ... Warning: Could not load /usr/lib/graphviz/libgvplugin_pango.so.6 - file not found Warning: Could not load /usr/lib/graphviz/libgvplugin_gd.so.6 - file not found Segmentation fault dpkg: error processing libgvc5 (--configure): subprocess installed post-installation script returned error exit status 139 Installed within a cowbuilder i386 chroot. Thanks, Sylvestre -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (600, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.0-2-686-pae (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libgvc5 depends on: ii libc6 2.13-27 ii libcairo2 1.10.2-7 ii libcdt42.26.3-10 ii libexpat1 2.1.0~beta3-2 ii libfreetype6 2.4.8-1 ii libgd2-xpm 2.0.36~rc1~dfsg-6+b1 ii libglib2.0-0 2.32.2-1 ii libgraph4 2.26.3-10 ii libjpeg8 8d-1 ii libpango1.0-0 1.30.0-1 ii libpathplan4 2.26.3-10 ii libpng12-0 1.2.47-2 ii libx11-6 2:1.4.4-4 ii libxdot4 2.26.3-10 ii zlib1g 1:1.2.6.dfsg-2 libgvc5 recommends no packages. libgvc5 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639288: graphviz: FTBFS: Cannot install gv.3python
tags 639288 - patch thanks On 28/08/11 20:51, David Claughton wrote: On 26/08/11 03:49, Daniel Schepler wrote: On Thursday, August 25, 2011 12:36:13 PM David Claughton wrote: On 25/08/11 17:58, Daniel Schepler wrote: [...] and tcl-dev and tk-dev aren't in the Build-Depends, it can't find tclConfig.sh in any of those locations. Can you try the attached patch? It should do the trick, but I can't test it myself as I'm still running 32-bit here. Actually, forget the patch - your original suggestion of switching to unversioned tcl-dev and tk-dev is spot on - I hadn't made the connection that these packages include a /usr/lib/tclConfig.sh symlink, which I now realise is what you were getting at ;-) I've updated the git archive for the 2.28 release which I'm working towards, but if you have the chance, I'd appreciate it if you can confirm that this change fixes the issue (both the tcl and python aspects) for you. Cheers, David. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639288: graphviz: FTBFS: Cannot install gv.3python
tags 639288 + patch pending
thanks
On 26/08/11 03:49, Daniel Schepler wrote:
On Thursday, August 25, 2011 12:36:13 PM David Claughton wrote:
On 25/08/11 17:58, Daniel Schepler wrote:
When I tried removing gv.3python from debian/libgv-python.install to get the
packages built, I ran into a more serious issue: configure couldn't find
tclConfig.sh and therefore the Tcl/Tk bindings weren't built. From looking
through configure.ac, it looks like it only looks in /usr/lib64/tcl8.5,
/usr/lib64, and /usr/lib. But since the /usr/lib64 symlink was recently
removed (it's incompatible with multiarch), and tcl-dev and tk-dev aren't in
the Build-Depends, it can't find tclConfig.sh in any of those locations.
Hi Daniel,
Yes, this is a bug in configure.ac, on 64-bit machines it looks in
/usr/lib64/tclversion and /usr/lib, but not in /usr/lib/tclversion.
Can you try the attached patch? It should do the trick, but I can't
test it myself as I'm still running 32-bit here.
I suspect this will also fix the python issue - due to the bad placement
of a couple of key lines in patch 0_python_27_support, which end up
inside a if WITH_TCL block.
Cheers,
David.
diff --git a/configure.ac b/configure.ac
index cacafe1..d1ffa00 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1476,8 +1476,12 @@ if test x$use_tcl = x; then
if test -f ${TCLSH_EXEC_PREFIX}/lib${LIBPOSTFIX}/tclConfig.sh; then
TCLCONFIG=${TCLSH_EXEC_PREFIX}/lib${LIBPOSTFIX}/tclConfig.sh
else
- if test -f ${TCLSH_EXEC_PREFIX}/lib/tclConfig.sh; then
-TCLCONFIG=${TCLSH_EXEC_PREFIX}/lib/tclConfig.sh
+ if test -f
${TCLSH_EXEC_PREFIX}/lib/tcl${TCL_VERSION_FOUND}/tclConfig.sh; then
+TCLCONFIG=${TCLSH_EXEC_PREFIX}/lib/tcl${TCL_VERSION_FOUND}/tclConfig.sh
+ else
+if test -f ${TCLSH_EXEC_PREFIX}/lib/tclConfig.sh; then
+ TCLCONFIG=${TCLSH_EXEC_PREFIX}/lib/tclConfig.sh
+fi
fi
fi
fi
Bug#639288: graphviz: FTBFS: Cannot install gv.3python
On 25/08/11 17:58, Daniel Schepler wrote: An interesting line from earlier in the log: /usr/bin/install -c -m 644 gv.3guile gv.3lua gv.3ocaml gv.3perl gv.3php gv.3ruby '/tmp/buildd/graphviz-2.26.3/debian/tmp/usr/share/man/man3' I'm not sure why gv.3python is missing in that line. Hmm, what version of python have you got installed? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575797: some more stuff
On 04/05/11 23:32, Christoph Egger wrote: (unstable-kfreebsd-i386-sbuild)root@escher:~# dot --help There is no layout engine support for dot Perhaps dot -c needs to be run (with installer's privileges) to register the plugins? (unstable-kfreebsd-i386-sbuild)root@escher:~# sh -x /var/lib/dpkg/info/libgvc5.postinst + set -e + [ -x /usr/sbin/libgvc5-config-update ] + libgvc5-config-update -c + [ -f /usr/lib/graphviz/config ] + [ = configure ] (unstable-kfreebsd-i386-sbuild)root@escher:~# dot --help There is no layout engine support for dot Perhaps dot -c needs to be run (with installer's privileges) to register the plugins? Hmm, very strange! Does /usr/lib/graphviz/config6 exist in the chroot after running the postinst? If so, does it contain an entry for libgvplugin_dot_layout.so.6 (and just to be sure, hopefully this file does exist in the same directory)? Cheers, David. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623165: Updated graphviz to fix FTBFS caused by python 2.7
On 23/04/11 23:32, David Claughton wrote: On 22/04/11 21:10, Mehdi Dogguy wrote: I've been able to build the package using Barry's patch, and successfully tested the python binary package produced. So, ok upstream's Graphviz doesn't have Python 2.7 support… but you can hack configure.ac a bit to get that working. Attached is a debdiff between sid's version and mine (well, with Barry's patch). Please consider applying it. Thanks, I'll take a look at it. OK, I've applied the patch to the git repo - looks good. Thanks again to you both. Christoph, please can you pull the new commit and include it in the release. Cheers, David. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623165: Updated graphviz to fix FTBFS caused by python 2.7
On 24/04/11 23:45, Mehdi Dogguy wrote: On 04/25/2011 12:17 AM, David Claughton wrote: OK, I've applied the patch to the git repo - looks good. Thanks again to you both. Thanks. However, you might want to revert the other patch that turned pyversions -s into pyversions -r. The former allows us to update the package by a simple binNMU while the latter forces source changes in the source package. Regards, Hmm, I'm not sure I agree. As we have just seen, graphviz requires source changes anyway to support a new python version. Surely all pyversions -s does in this situation is guarantee that the binNMU will fail, just as it did this time? I left pyversions -r in as it seemed the better approach in this case. It should mean that transitions are smoother - an OCAML transition shouldn't come to a grinding halt because a new python version has been uploaded to the archive! Cheers, David. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623165: Updated graphviz to fix FTBFS caused by python 2.7
On 22/04/11 21:10, Mehdi Dogguy wrote: I'm sorry but 65883762c382d200cc5001433d060474045c7e30 looks wrong. If python 2.7 is set as default python interpreter, libgv-python will be useless, unless you install python2.6. I realise that this will probably happen at some point, but I didn't think this was going to be soon? I went with the quickest option to fix the FTBFS, so I wasn't holding up the transition, with a view that I could revisit the issue later if the new upstream release doesn't turn up soonish (which will support 2.7). Backporting python 2.7 support seemed over the top for a release that might only last a few days, however that was before ... Barry Warsaw kindly proposed a patch [1] in this bugreport, which was applied in Ubuntu. Did you test it? Did you have a look at it? ... Barry posted this. Since Barry's been kind enough to do all the hard work for me (thanks Barry!), that obviously changes things. I've been able to build the package using Barry's patch, and successfully tested the python binary package produced. So, ok upstream's Graphviz doesn't have Python 2.7 support… but you can hack configure.ac a bit to get that working. Attached is a debdiff between sid's version and mine (well, with Barry's patch). Please consider applying it. Thanks, I'll take a look at it. Cheers, David. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623165: Updated graphviz to fix FTBFS caused by python 2.7
Hi Christoph, Hope you're having a happy Easter (you too Seb). I've just pushed some changes to the git repo to fix the recent FTBFS which was caused by the introduction of python 2.7 to the archive. I've thrown in a couple of other things including a patch for Hurd which was submitted - just so you know I have no way to test this so I'm just taking a flyer on it. Could you please take a look and (assuming it looks OK) upload it for me? Cheers, David. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623165: src:graphviz: FTBFS with Python 2.7 enabled
It seems that all supported Python versions are explicit in the configure script, and Python 2.7 is missing. Hi Stéphane, Thanks for the report. It looks like the current graphviz doesn't offer support for python 2.7. Upstream have advised that version 2.28 is due to be released any day now and this release will support 2.7 (tested using the nightly snapshots). Cheers, David. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620801: graphviz: Text on self-edges of a node is poorly placed
forwarded 620801 gviz-b...@research.att.com
thanks
Hi Eddy,
Thanks for the report. I've confirmed that the problem continues to
exist with the latest nightly builds and have forwarded it upstream for
them to look at.
Cheers,
David.
On 04/04/11 10:41, e...@opera.com wrote:
Subject: graphviz: Text on self-edges of a node is poorly placed
Package: graphviz
Version: 2.26.3-5
Severity: normal
*** Please type your report below this line ***
I'm making a digraph showing state-transitions for the terrain in
freeciv; a simple dot file has done very nicely for the transitions
between states; irrigation (blue arcs) turns forest into plains, mining
converts back, etc. When I try to add arcs indicating 'internal' state
transitions - irrigating hills doesn't change the fact that they're
hills but does improve their food output - I run up against a limitation
on the placement of text on such self-arrows.
By default, all the self-arrows come out on the right; when there are
several on a node, each self-edge's loop goes round the last one's label
and nodes are moved apart enough to make room for these edges and
labels. This is all readable but aesthetically messy; it would look
nicer if self-edges protruded in different directions so as not to push
one another further from the node to which they relate. I can set the
headport and tailport to move the edges around, but it turns out that
the placement of their text labels is then messed up.
If I put an edge :nw-:nw or :sw-:sw, its text gets placed exactly as
if the edge were :w-:w (and in a position sensible for this port but
not for nw or sw). So I can only put one label (hence one edge) on the
left. Fortunately (!) this is asymmetric: :se-:se and :ne-:ne are
placed differently than one another and :e-:e (the default).
Sadly, however, even then I see a more severe problem, also present for
the left-side self-loops: node, edge and label positions are not
adjusted to make space for the labels of non-default-port self-loops.
While I may be able to concoct some abomination of a way to stretch
labelangle and labeldistance to work round this, the default clearly
does take account of label texts when placing the rest of the graph and
its labels, so it's a shame that setting an edge's ports breaks that.
Example small dot file showing all symptoms described above:
digraph BugExample {
/* Trivial graph: */
Left - Bottom [label=Down Right];
Right - Bottom [label=Down Left];
/* Two left self-edge labels collide: */
Left:nw - Left:nw [label=North-West];
Left:sw - Left:sw [label=South-West];
/* Self-edge labels collide with normal edge label (Down Right): */
Left:se - Left:se [label=South-East];
Bottom:ne - Bottom:ne [label=North-East];
/* Labels over-lap one another and nodes */
Right:w - Right:w [label=West];
/* Skip this last to see West overlap Left instead of East: */
Left:e - Left:e [label=East];
}
Note that the graph-drawing *does* take account of the self-edges, it's
only the labels that are left out of consideration; and the :e-:e
edge's label, unlike all others, *is* correctly provided for (delete its
line to see Left and Right move closer together, causing West to overlap
Left instead of East), even when its ports are specified explicitly as
:e (where the default isn't actually representable by specifying port;
it's sort of :ene-ese; remove the :e specifiers to see the edge loop
open up a bit without the nodes or labels moving).
Some of the problems are alleviated if I use different ports for head
and tail; but, even then, some label texts overlap other label texts.
I normally emit the image as SVG using
/usr/bin/dot -Tsvg
(automated by a .htaccess hack and a cgi-bin script in my local
web-server) but see exactly the same result when running dot -Tpng
manually. (For my reference:
http://vortex/~eddy/img/misc/graphviz-label-placement-bug.dot
is my local copy.)
-- System Information:
Debian Release: 6.0.1
APT prefers oldstable
APT policy: (500, 'oldstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15
(charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/dash
Versions of packages graphviz depends on:
ii libc6 2.11.2-10 Embedded GNU C Library:
Shared lib
ii libcdt42.26.3-5 rich set of graph drawing
tools -
ii libcgraph5 2.26.3-5 rich set of graph drawing
tools -
ii libexpat1 2.0.1-7 XML parsing C library -
runtime li
ii libgd2-xpm 2.0.36~rc1~dfsg-5 GD Graphics Library version 2
ii libgraph4 2.26.3-5 rich set of graph drawing
tools -
ii libgvc52.26.3-5 rich set of graph drawing
tools -
ii libgvpr1 2.26.3-5 rich set of graph drawing
Bug#617517: graphviz: Menus don't seem to work
On 09/03/11 23:46, Reuben Thomas wrote: On 9 March 2011 22:36, David Claughton d...@eclecticdave.com wrote: Do you have NUMLOCK on by any chance? No. My keyboard doesn't have a NumLock key or light. I loaded up GNOME Keyboard Properties, and the key is greyed out in the diagram, and the light is shown off. Hmm, even though GNOME knows better, I wonder if X has a NumLock key mapped anyway, regardless of whether a physical key exists. Could you post the output of 'xmodmap -pm'? Cheers, David. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617517: graphviz: Menus don't seem to work
On 11/03/11 00:06, Reuben Thomas wrote: On 10 March 2011 22:31, David Claughton d...@eclecticdave.com wrote: Could you post the output of 'xmodmap -pm'? xmodmap: up to 4 keys per modifier, (keycodes in parentheses): shift Shift_L (0x32), Shift_R (0x3e) lock control Control_L (0x25), Control_L (0x42), Control_R (0x69) mod1Alt_L (0x40), Meta_L (0xcd) mod2Num_Lock (0x4d) mod3 mod4Super_L (0x85), Super_R (0x86), Super_L (0xce), Hyper_L (0xcf) mod5ISO_Level3_Shift (0x5c), Mode_switch (0xcb) So indeed there's a NumLock, and one can only imagine that it is thought to be engaged. A pity, as I have no idea how to disengage it. You could try installing the 'numlockx' package. This should allow you to turn numlock off using 'numlockx off'. Cheers, David. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617517: graphviz: Menus don't seem to work
On 09/03/11 14:47, Reuben Thomas wrote: Package: graphviz Version: 2.26.3-4 Severity: normal I start dotty, and right click once. Nothing happens (I would expect the menu to appear). Note that the window already has the focus. I click again. The menu appears, but when I move the mouse over it, the entries are not highlighted, so I can’t seem to select anything. Hi Reuben, Do you have NUMLOCK on by any chance? I can reproduce this behaviour here with NUMLOCK on and turning NUMLOCK off fixes it! This seems to have been around for a while, the lenny version also appears to suffer from the same issue. I had a look at the upstream bug list and it seems this has already been reported[1] back in 2006. [1] http://www.graphviz.org:8080/bugs/b1042.html Cheers, David. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#578320: dot fails with assertion on hurd-i386
tags 578320 + pending thanks On 08/03/11 21:20, Samuel Thibault wrote: Could you apply the attached patch to force adding -lpthread? (Yes, it needs to be passed with -Wl, else libtool reorders it. Samuel Hi Samuel, Thanks for this! I've applied your patch to the git repo on Alioth. Upstream has recently announced that graphviz 2.28 is just around the corner, so I'll most probably wait for that before doing a release. I should note I don't have any way of testing this, so I will have to rely on feedback from yourself and the submitter to make sure I've applied it correctly. Fortunately it's a simple job which even I probably can't screw up ;-) Cheers, David. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605993: corrupted PostScript output from neato
On 05/12/10 12:07, Ian Jackson wrote: Package: graphviz Version: 2.20.2-3 When I run this command neato -Gsize=7.5,7.5 -Gcenter=1 -Tps bug.neato bug.ps on the attached input file, the output Postscript file contains unwanted high-bit-set characters where a pair of coordinates ought to be. See line 1943 of the attached output file. Ian. Hi Ian, Yes, confirmed in a lenny chroot. The problem looks like some sort of numeric overflow caused when neato tries to position the label of a particular edge. Take a look at the raw output (without a -T option), this is line 161: n83O - n53O [label=91+:PB8:143.81, pos=e,541,617 538,607 538,607 538,607 538,607, lp=-2147483640,-2147483648]; This problem does not seem to occur in the latest 2.26.3-5 release which will ship with Squeeze. Are you able to give this version a try? Alternatively removing the label from this edge (line 107 of the input file) seems to work around the issue. Cheers, David. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596707: graphviz: Please include smyrna binary
Hi Paul, Yes this is quite deliberate I'm afraid. smyrna is marked in the upstream configure as disabled by default - experimental. That makes it unsuitable for a stable release. Once squeeze is released, I'll be happy to consider including it, on the theory that its bound to be stable in time for wheezy (the next stable release). Cheers, David. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#593798: libsoqt3-20 is linked against Qt 4 (should be Qt 3)
On 21/08/10 15:36, Steve M. Robbins wrote: On Sat, Aug 21, 2010 at 02:52:48AM +0200, Gerhard Dirschl wrote: Package: libsoqt3-20 Version: 1.4.2~svn20090224-2 libsoqt3 should be linked against Qt 3 but actually it is linked against Qt 4 (apart from the suffix, there is no difference between libsoqt3 and libsoqt4). Wow. This was broken perhaps as long ago as March 2009 and no-one noticed until now. Must not be an important package :-) FWIW, I could be wrong, but it looks like configure is invoking pkgconfig to determine the QT version and it's always finding QT4 regardless of what QTDIR is set to. Maybe --enable-pkgconfig wasn't the default in the previous release? In any case adding --disable-pkgconfig *seems* to do the trick, although I didn't have time to test it thoroughly. Cheers, David. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591089: graphviz: Bad arrow direction between same rank nodes
forwarded 591089 http://www.graphviz.org/bugs/b2011.html thanks On 31/07/10 20:10, Aleksey Sergushichev wrote: Package: graphviz Version: 2.26.3-5 Severity: normal dot draws wrong direction arrow when to nodes have the same rank Hi Aleksey, I've forwarded this as upstream bug 2011, and it has been fixed in upstream CVS. It should appear in the next upstream release (2.28) Thanks for your report. David. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592839: dpkg-source option to remove files on unpack: debian/source/remove-files
On 13/08/10 17:58, Russ Allbery wrote: Raphael Hertzog hert...@debian.org writes: As suggested by Ian on -devel (see attachment), it would be nice to have a way to remove files during unpack of a source package to hide non-free files from our users without stripping them from the original tarball. I also prefer this approach over repacking upstream files so let's implement this feature. I'm pretty sure ftp-master isn't going to allow source packages with non-free content in the main archive regardless of whether that content is hidden on unpack (I certainly wouldn't if I were them), so implementing this is kind of pointless for Debian. Another use-case might be to remove convenience copies of system libraries. Might be useful (e.g. for security reasons) to be able to guarantee that this code isn't being accidentally used by a build (in a way that can be easily checked by a script). Cheers, David. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#578320: dot fails with assertion on hurd-i386
Mattias Ellert wrote: Package: graphviz Version: 2.26.3-4 Severity: serious User: debian-h...@lists.debian.org Usertags: hurd Packages that use doxygen to generate documentation FTBFS on hurd-i386 due to the dot binary bailing out due to a pthread asertion: dot: /var/tmp/hurd-20090404/./libpthread/sysdeps/generic/pt-mutex-timedlock.c:68: __pthread_mutex_timedlock_internal: Assertion `__pthread_threads' failed. Here is a list of builds suffering from this problem: https://buildd.debian.org/fetch.cgi?pkg=globus-commonarch=hurd-i386ver=11.4-1stamp=1271469707file=logas=raw https://buildd.debian.org/fetch.cgi?pkg=globus-openssl-modulearch=hurd-i386ver=1.2-1stamp=1271499050file=logas=raw https://buildd.debian.org/fetch.cgi?pkg=globus-gsi-cert-utilsarch=hurd-i386ver=6.5-1stamp=1271488752file=logas=raw https://buildd.debian.org/fetch.cgi?pkg=globus-gsi-sysconfigarch=hurd-i386ver=3.1-1stamp=1271484978file=logas=raw https://buildd.debian.org/fetch.cgi?pkg=globus-gsi-credentialarch=hurd-i386ver=3.3-1stamp=1271527529file=logas=raw https://buildd.debian.org/fetch.cgi?pkg=globus-gsi-proxy-corearch=hurd-i386ver=4.4-1stamp=1271491425file=logas=raw https://buildd.debian.org/fetch.cgi?pkg=globus-gss-assistarch=hurd-i386ver=5.8-1stamp=1271493967file=logas=raw https://buildd.debian.org/fetch.cgi?pkg=globus-ftp-clientarch=hurd-i386ver=5.3-1stamp=1271471151file=logas=raw https://buildd.debian.org/fetch.cgi?pkg=globus-gass-copyarch=hurd-i386ver=5.4-1stamp=1271473543file=logas=raw https://buildd.debian.org/fetch.cgi?pkg=globus-rslarch=hurd-i386ver=7.2-1stamp=1271501917file=logas=raw https://buildd.debian.org/fetch.cgi?pkg=globus-authz-callout-errorarch=hurd-i386ver=0.5-1stamp=1271463560file=logas=raw Mattias Hi Hurd Porters, I've received the above bug report concerning the Hurd port. Unfortunately I have zero experience with Hurd so I'm hoping someone here can help me understand the problem. Google appears to be telling me this error is some sort of a conflict between cthreads and pthreads, but all the references I can find are quite old - typically around 2005, so I'm not sure if this information is still accurate. graphviz uses -pthreads when linking, so perhaps the problem is that one of it's dependencies doesn't? I would really appreciate it if someone could point me in the right direction. Please CC me and/or the bug as I am not subscribed. Cheers, David. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575797: There is no layout engine support for dot. Perhaps dot -c needs to be run (with installer's privileges) to register the plugins?
Trent W. Buck wrote: Package: graphviz Version: 2.26.3-3 Severity: important Upon installing graphviz, I am confronted with $ dot --help There is no layout engine support for dot Perhaps dot -c needs to be run (with installer's privileges) to register the plugins? I don't remember seeing this before. Is there any reason this operation can't be done at build time (debian/rules) or at install time (debian/postinst)? Running sudo dot -c appears to fix it. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.33-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages graphviz depends on: ii libc62.10.2-6Embedded GNU C Library: Shared lib ii libcdt4 2.26.3-3rich set of graph drawing tools - ii libcgraph5 2.26.3-3rich set of graph drawing tools - ii libexpat12.0.1-7 XML parsing C library - runtime li ii libgd2-noxpm 2.0.36~rc1~dfsg-3.1 GD Graphics Library version 2 (wit ii libgraph42.26.3-3rich set of graph drawing tools - ii libgvc5 2.26.3-3rich set of graph drawing tools - ii libgvpr1 2.26.3-3rich set of graph drawing tools - ii libx11-6 2:1.3.3-2 X11 client-side library ii libxaw7 2:1.0.7-1 X11 Athena Widget library ii libxmu6 2:1.0.5-1 X11 miscellaneous utility library ii libxt6 1:1.0.7-1 X11 toolkit intrinsics library Versions of packages graphviz recommends: ii ttf-liberation 1.05.2.20091019-4 Fonts with the same metrics as Tim Versions of packages graphviz suggests: pn graphviz-doc none (no description available) ii gsfonts 1:8.11+urwcyr1.0.7~pre44-4 Fonts for the Ghostscript interpre -- no debconf information Hi Trent, Strange, it works fine here. It should be doing exactly what you suggest - /usr/sbin should have command libgvc5-config-update installed, which is actually a copy of dot, and it should run libgvc5-config-update -c in libgvc5.postinst. The only change I've made to this file recently is to remove the absolute path from the command (i.e. it used to say /usr/sbin/libgvc5-config-update -c). This was because lintian was complaining about it and since /usr/sbin should be in root's path, I decided to appease it. Is it possible that /usr/sbin isn't on root's path on your machine? Cheers, David. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575255: graphviz: *** glibc detected *** circo: free(): invalid next size (fast): 0x00000000007032c0 ***
severity 575255 important thanks Francis Russell wrote: Package: graphviz Severity: normal I did a little investigation into this which may or may not be helpful. The problem appears to be with the call to position in lib/circogen/circpos.c. position iterates over a linked list and conditionally saves values into an array called parents. parents has the size 'childCount', however, in the single place position is called the linked list has the size 'length'. If lengthchildCount and enough iterations add a value to the parents array, its bounds may be overrun. Changing the line 'posinfo_t* parents = N_NEW(childCount, posinfo_t);' to 'posinfo_t* parents = N_NEW(length, posinfo_t);' fixes the segfault, though it's not clear if this method's being called with an incorrect assumption about the values of childCount and length anyway. Francis Many thanks for your help Francis! I've passed the bug report upstream, along with your suggested fix which I can confirm works here too ;-) In the meantime I've downgraded the bug to Important since it now seems clear it only affects circo. Cheers, David. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574070: graphviz: Please add a 'dot -T help' option to cleanly list plugin renderer formats.
A. Costa wrote: On Tue, 16 Mar 2010 19:18:26 + David Claughton d...@eclecticdave.com wrote: dot -Tsvg -P -o dotformats.svg Cool tip, but with v2.20.2-8 +b1 it doesn't happen: Sorry I should have mentioned, I'm using version 2.26.3-2 which hit testing a few days ago - you're right it's not present in the older version. Cheers, David. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574070: graphviz: Please add a 'dot -T help' option to cleanly list plugin renderer formats.
A. Costa wrote: Package: graphviz Version: 2.20.2-8+b1 Severity: wishlist Oddly enough, 'dot' almost has this feature, but the helpful output itself is currently tricky to parse and list. Model example; 'mplayer': mplayer -vo help | tail mpegpes MPEG-PES to DVB card yuv4mpeg yuv4mpeg output for mjpegtools png PNG file jpeg JPEG file gif89aanimated GIF output tga Targa output pnm PPM/PGM/PGMYUV file md5summd5sum of each frame 112 audio 235 video codecs 'man dot' asks users to guess poll, or go online: % man dot | grep -A 17 OUTPUT FORMATS OUTPUT FORMATS Dot uses an extensible plugin mechanism for its output renderers, so to see what output formats your installation of dot supports you can use ``dot -Txxx'' (where xxx is an unlikely format) and check the warning message. Also, The plugin mechanism supports multiple implementations of the output formats. To see what variants are available, use, for example: ``dot -Tpng:'' and to force a particu- lar variant, use, for example: ``dot -Tpng:gd'' Traditionally, dot supports the following: -Tps (PostScript), -Tsvg -Tsvgz (Structured Vector Graphics), -Tfig (XFIG graphics), -Tmif (FrameMaker graphics), -Thpgl (HP pen plotters), and -Tpcl (Laser- jet printers), -Tpng -Tgif (bitmap graphics), -Tdia (GTK+ based diagrams), -Timap (imagemap files for httpd servers for each node or edge that has a non(hynull href attribute.), -Tcmapx (client- side imagemap for use in html and xhtml). Additional less common or more special-purpose output formats can be found at http://www.graphviz.org/cvs/doc/info/output.html.) (Bonus: if an 'mplayer'-like '-T help' option were added, most of those two paragraphs won't be needed.) When testing what the 'man' says, the user is surprised to find that the warning message is close what a '-T help' option should be: # there's no 'help' graphics format, so try that... % dot -T help Format: help not recognized. Use one of: canon cmap cmapx cmapx_np dia dot eps fig gd gd2 gif hpgl imap imap_np ismap jpe jpeg jpg mif mp pcl pdf pic plain plain-ext png ps ps2 svg svgz tk vml vmlz vrml vtx wbmp xdot xlib The above listing is incomplete; subtypes exist: # show help for 'png' dot -Tpng: Format: png: not recognized. Use one of: png:cairo:cairo png:cairo:gd png:gd:gd More than one format followed by only a colon (e.g. 'dia:') make 'dot' wait for input, (another bug?), so getting a complete list is a kludgy business. Until something better comes along, here's one way to do it: # parse '-T' error from stderr, mine that for suboptions, # ending needless processes as they occur. % for f in $(dot -T help 21 | sed 's/.*://') ; do echo Format: $f ; dot -T$f: n=$! ; sleep .1s ; kill -9 $n ; done 21 | grep Format | sed 's/.*: //g;s/ /\n/g' On my system it shows 80 items. Anyway, the 'mplayer -vo help' style would be better. HTH... Hi, You might want to check out the -P option which outputs a graph of the available plugins e.g. dot -Tsvg -P -o dotformats.svg Of course it's not quite the same as the simple list that your script produces, but it does show the requisite information. Cheers, David. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573781: Info received (Bug#573781: graphviz: Output of dot -y broken, severely effects monotone-viz)
Francis Russell wrote: So, this bug has been acknowledged and apparently fixed upstream: http://www.graphviz.org/bugs/b1902.html http://www.graphviz.org/bugs/b1903.html I've attached a diff I made of the changes to lib/common/output.c from upstream CVS. I believe the fix only touches this file although CVS makes this rather difficult to confirm. As far as I can tell, the patch works correctly. Francis Ah thanks - I'll take a look at it. Cheers, David. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573781: graphviz: Output of dot -y broken, severely effects monotone-viz
Francis Russell wrote: monotone-viz uses dot to lay out its graphs. Specifically, it passes the '-q -y -s72' options to dot, but it's only the '-y' option that's broken. I intercepted the input of dot and created the attached test file dot-in.dot. Running though 'dot -y' creates a dot output file with additional position information for the nodes and edges. Looking at the output file (attached as dot-out.dot), the position of the edge joining the two nodes is nowhere near the nodes. In this case, all the y-positions are negative while the nodes themselves are on the other side of the x-axis. Hi Francis, I can't say I've ever tried the -y option, but I agree that there appears to be something odd going on here. I've confirmed that the 2.20 version on lenny does not suffer from this problem. The odd thing is, the only time the problem manifests itself is when the file is output in dot format (i.e. without a -Tformat switch). When a -T option is passed the output always seems to look OK. Here's the output of -Tplain for example: Without -y ... graph 1 4.8056 0.97222 node 1f50b586d83ff72f6ddc3768e5065e27fe730049 2.4028 0.18056 4.8194 0.36111 1f50b586d83ff72f6ddc3768e5065e27fe730049 solid box black lightgrey node 3fef041abc1169fdd55d05530ffb754b75a4bd73 2.4028 0.79167 4.7778 0.36111 3fef041abc1169fdd55d05530ffb754b75a4bd73 solid box black lightgrey edge 3fef041abc1169fdd55d05530ffb754b75a4bd73 1f50b586d83ff72f6ddc3768e5065e27fe730049 4 2.4028 0.60499 2.4028 0.57241 2.4028 0.5377 2.4028 0.5027 solid black stop With -y ... graph 1 4.8056 0.97222 node 1f50b586d83ff72f6ddc3768e5065e27fe730049 2.4028 0.79167 4.8194 0.36111 1f50b586d83ff72f6ddc3768e5065e27fe730049 solid box black lightgrey node 3fef041abc1169fdd55d05530ffb754b75a4bd73 2.4028 0.18056 4.7778 0.36111 3fef041abc1169fdd55d05530ffb754b75a4bd73 solid box black lightgrey edge 3fef041abc1169fdd55d05530ffb754b75a4bd73 1f50b586d83ff72f6ddc3768e5065e27fe730049 4 2.4028 0.36723 2.4028 0.39981 2.4028 0.43452 2.4028 0.46953 solid black stop I'm not at all familiar with monotone-viz ... does it render the resulting dot file itself rather that asking dot to do it? Anyway, I'll pass your report upstream, together with the results of my investigations. Cheers, David. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#572839: transition: graphviz
Marc 'HE' Brockschmidt wrote: If you have verified that these packages all build with the new sources, you can do it tomorrow and we will do this quickly before taking on the directfb soname bump. Please ping us again after you've uploaded, so that we can schedule the needed binNMUs. Marc Hi, Graphviz has now been uploaded, please schedule the following binNMUs : nmu imagemagick_6.5.8.3-1 . ALL . -m rebuild against graphviz 2.26.3 nmu python-pygraphviz_0.99.1-1 . ALL . -m rebuild against graphviz 2.26.3 nmu anjuta-extras_2.28.0-1 . ALL . -m rebuild against graphviz 2.26.3 nmu flowcanvas_0.6.0-1 . ALL . -m rebuild against graphviz 2.26.3 Turns out ggobi needs a sourceful upload - I've contacted the maintainer and arranged for this. I wasn't sure if I should have provided dep-waits against graphviz for these or if this happens automatically? Let me know if you need these, I'll be happy to oblige. Cheers, David. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#572839: transition: graphviz
Package: release.debian.org User: release.debian@packages.debian.org Usertags: transition Severity: normal *** Please type your report below this line *** Hi, I sent the following to the list last week but didn't get a response - maybe it fell through the cracks? If so, that might have been my fault for failing to file it as a bug report - so allow me to rectify that now ... Cheers, David. --- Hi Release Team, Graphviz 2.26.3 has been in experimental for just about a month and we (as in the graphviz maintainers) now feel it is ready for uploading to unstable. This involves a transition as the existing libgraphviz4 package has been split into separate packages for each library and two libraries have soname bumps. Once uploaded it looks like BinNMUs will be required for the following packages. imagemagick python-pygraphviz anjuta-extras ggobi flowcanvas When would you like us to upload? Cheers, David. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.32-trunk-686 (SMP w/1 CPU core) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568031: Please upgrade to 0.99.1
Subject: python-pygraphviz: Please update to 0.99.1 Package: python-pygraphviz Severity: wishlist *** Please type your report below this line *** Hi KiBi, New upstream version 2.26.3 of graphviz has just been uploaded to experimental. This version no longer contains libagraph. This means that the existing version of python-pygraphviz will not compile against it. Please consider upgrading to version 0.99.1 which includes the port to libcgraph. If possible it would be great if you could do this soonish, as I'm hoping to get the new graphviz into unstable ahead of the freeze. Cheers, David. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.32-trunk-686 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536245: ITA: graphviz -- rich set of graph drawing tools
retitle 536245 ITA: graphviz -- rich set of graph drawing tools owner 536245 ! thanks Hi, At this point, I would like to formalize my intention to adopt graphviz. In addition to myself I have been in discussion with Christoph Egger and Sebastian Harl who have agreed to join me as co-maintainers. Also, FYI, I have now committed my 2.24 packaging work to the git repo on collab-maint. In order to avoid stepping on anyone's toes WRT the current QA work, I've created a separate branch 'dev-2.24' for this. The current plan is to merge this into 'unstable' when it is ready for release and to leave 'unstable' for any 2.20 changes that may be required in the meantime. Cheers, David. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536245: New upstream version 2.24
On Tue, Dec 08, 2009 at 09:29:34AM +0100, Sebastian Harl wrote: Heya, On Tue, Dec 08, 2009 at 03:21:58PM +1100, Trent W. Buck wrote: Sebastian Harl wrote: Thanks for your interest and offering your help! To be honest, I'm not sure about what needs to be done at the moment. Normally when adopting a package I would start by: - triaging any open bugs; - adopting dpkg source format 3.0 (quilt); - adopting dh(1) for debian/rules; - uupdating to a new upstream (if any); and finally - adopting DEP-5 for debian/copyright and updating it. I'll leave this (graphviz) at the bottom of my IN tray for now; if I get around to working on it, I'll send patches to you rather than applying them directly. This will give you a chance to veto anything you don't like. Great! I'm not convinced about 3.0 (quilt) yet, so I'd prefer not to use that for graphviz. Anything else sounds good to me, though. Thanks again for your interest! In the meantime you organize the new maintianership for graphviz, I am going to do a QA upload addressing at least #493974. Package FTBFS currently and it is necesary getting it buildeable becaus it is stalling ongoing porting efforts. Ana Hi All, As I've mentioned above, I've done some work on the new upstream version, and I was just preparing to commit my stuff to the git repo, when I spotted this update. Fair enough Ana, you beat me to it ;-) (BTW, did you mean bug #504569? That's the one you seem to have fixed!, I also notice you haven't committed a changelog update, if you want to do this, I'll make sure I merge mine with yours) In the interests of co-operation I thought it would a good idea for me to detail here what I've done so far ... Triaging - upstream have fixed #522356 and #521539. I've applied the minor changes for #504571, #504569 (duplicating Ana's change but never mind!), #493974 and #521538. Note, not all of these are in the version uploaded to mentors - I'm going to update this shortly. I also switched to using 3.0 (quilt) - the main reason being that upstream are now distributing a debian directory in the tarball (a position they do not seem to be prepared to move from AIUI) and updating to the new format seemed expedient to avoid repacking. Sebastian, do you think I should revert this? I've added a couple of patches, one to kill upstream's attempt to generate debian/changelog from changelog.in (!) and a second to fix a segfault in the new 'prune' executable. What I still have to do is to split libgraphviz into seperate packages for each library ... I had originally thought to keep them together despite the soname update on libgvc, at least for now, but following some good advice from Christoph, I'm going to revisit this. Apologies for cc'ing everyone ... I have no idea who is subscribed to this bug (I am BTW). Cheers, David. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536245: New upstream version 2.24
David Claughton wrote: Hi All, (BTW, did you mean bug #504569? That's the one you seem to have fixed!, I also notice you haven't committed a changelog update, if you want to do this, I'll make sure I merge mine with yours) Apologies, Ana - I see now you've fixed both bugs and added a changelog entry - I don't know how I missed this :-( Cheers, David. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536245: Package for 2.24 available on mentors
Hi, FYI - I've uploaded an updated graphviz package based on the latest 2.24.0 upstream version to mentors [1] I'm interested in possibly adopting the package, but this is the first library package I've worked on, so before I go ahead I'd like to get some feedback - is what I've done reasonably close to passing muster? I've also started a thread on debian-mentors.l.d.o [2] so please feel free to respond there ;-) [1] http://mentors.debian.net/debian/pool/main/g/graphviz [2] http://lists.debian.org/debian-mentors/2009/11/msg00478.html Cheers, David. P.S. Sebastian, are you still interested in this package? I wouldn't be opposed to sharing if you are :-) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539187: Patch is broken - packaging is too
Josselin Mouette wrote: Furthermore, it is not the role of dh_pysupport to fix broken symbolic links. Hi Josselin, I think maybe I wasn't clear enough about the problem - I'm not suggesting dh_pysupport should fix a broken symlink - I'm suggesting it breaks a symlink that wasn't broken before :-) Specifically, prior to the call to dh_pysupport 'site-packages' contains the following files (I've removed the cruft from the ls -l output for clarity) ... $ pwd /home/david/src/graphviz-2.24.0/debian/libgv-python/usr/lib/python2.5/site-packages $ ls -l -rw-r--r-- gv.py lrwxrwxrwx _gv.so - libgv_python25.so -rw-r--r-- libgv_python25.so After dh_pysupport is called, 'pyshared' has the following ... $ pwd /home/david/src/graphviz-2.24.0/debian/libgv-python/usr/lib/pyshared/python2.5 $ ls -l lrwxrwxrwx _gv.so - ../../python2.5/site-packages/libgv_python25.so -rw-r--r-- libgv_python25.so In other words, dh_pysupport moves the '_gv.so' link and adjusts it so it continues to point to 'libgv_python25.so' in site_packages. However it then proceeds to also move 'libgv_python25.so' to pyshared and this breaks the link. The intent of my patch is to check if the link destination is in the same directory as the link (i.e. both in site_packages) and just do a plain 'os.renames' on the link if it is, on the assumption that the link destination will also be moved and will end up in the same directory under pyshared. I don't quite see how running dh_link before dh_pysupport will help here ... I suppose I could delete the link prior to calling dh_pysupport and then recreate it with dh_link in all the pyshared/python2.X directories afterwards ... but it just seems to me that this is something that dh_pysupport should be able to do for me, and of course it worked prior to the introduction of the 'rename_subtle' function (in 1.0.3 I think) Also note that the package should be named python-gv instead. Well it's not my package - although I have expressed an interest in adopting it, which is why I thought I'd have a poke at the bug reports... If I end up taking it on, I'll look into renaming it ;-) Cheers, David. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539187: (no subject)
reassign 539187 python-support
retitle 539187 Moving symlink fails where linkdest is also moved
affects 539187 libgv-python
tags 539187 patch
thanks
Hi,
I've tracked this problem down to the 'rename_subtle' function in
'movemodules'.
This function is designed to modify relative symlinks that are being
moved to pyshared so they continue to point to the correct place.
However it fails to take account of the case where the link destination
is *also* going to be moved to pyshared. This causes it to create a
dangling symlink pointing to where the destination file used to be.
I think the case here - where both the symlink and destination are in
the same site-packages directory - is probably the most obvious way this
bug manifests, although there may be more unusual possibilities. The
attached patch should fix this common case.
Cheers,
David.
--- movemodules 2009-12-02 22:50:03.0 +
+++ movemodules.new 2009-12-02 22:49:41.0 +
@@ -68,7 +68,7 @@
def rename_subtle (source, destination):
if os.path.islink (source):
linkdest = os.readlink (source)
-if not os.path.isabs (linkdest):
+if not os.path.isabs (linkdest) and os.path.normpath(linkdest).count('/') 0:
linkdest = os.path.normpath(os.path.join(os.path.dirname(source),linkdest))
prefix = os.path.dirname(os.path.commonprefix((linkdest, destination)))
linkdest = os.path.normpath(destination)[len(prefix)+1:].count('/') * '../' + \
Bug#404811: [update-manager] Also filter on non-functional updates
Package: update-manager Version: 0.68.debian-6 --- Please enter the report below this line. --- I'd like to add a refinement to this ... I'd love it if there were a way to (automatically) identify and filter out non-functional updates. By that I mean updates that fix no bugs nor add any new functionality, for example policy updates or updates to some of the debian control files (like the recent updates to the copyright file for machine-readability). I understand that these updates necessarily result in a new version being put on the archive, and some people might use them but I would like an easy way of avoiding downloading and installing them if they're not actually useful for an average end-user. I know I can do this manually by reading the changelogs and unchecking the package, but I think an automatic mechanism would be very useful and more user-friendly. Regards, David. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#479200: [exim4-base] E: /var/cache/apt/archives/exim4-base_4.69-5+b1_i386.deb: subprocess new post-removal script killed by signal (Segmentation fault)
Package: exim4-base Version: 4.69-5+b1 Severity: grave --- Please enter the report below this line. --- When updating from 4.69-5 to 4.69-5+b1 the install fails with the following output... Unpacking replacement exim4-base ... Use of uninitialized value in subroutine entry at /usr/lib/perl/5.10/DynaLoader.pm line 219. dpkg: warning - old post-removal script killed by signal (Segmentation fault) dpkg - trying script from the new package instead ... Use of uninitialized value in subroutine entry at /usr/lib/perl/5.10/DynaLoader.pm line 219. dpkg: error processing /var/cache/apt/archives/exim4-base_4.69-5+b1_i386.deb (--unpack): subprocess new post-removal script killed by signal (Segmentation fault) Use of uninitialized value in subroutine entry at /usr/lib/perl/5.10/DynaLoader.pm line 219. dpkg: error while cleaning up: subprocess post-removal script killed by signal (Segmentation fault) Thanks, David. --- System information. --- Architecture: i386 Kernel: Linux 2.6.22-2-vserver-686 Debian Release: lenny/sid 900 unstable www.debian-multimedia.org 900 unstable ftp.uk.debian.org 800 experimental ftp.uk.debian.org 700 testing ftp.uk.debian.org --- Package information. --- Depends (Version) | Installed =-+-=== libc6 (= 2.7-1) | 2.7-10 libdb4.6 | 4.6.21-8 debconf (= 0.5) | 1.5.21 OR debconf-2.0 | cron | 3.0pl1-104 OR fcron | exim4-config (= 4.30) | 4.69-5 OR exim4-config-2 | adduser | 3.107 netbase | 4.32 lsb-base (= 3.0-3) | 3.2-12 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#479200: [exim4-base] E: /var/cache/apt/archives/exim4-base_4.69-5+b1_i386.deb: subprocess new post-removal script killed by signal (Segmentation fault)
Marc Haber wrote:
On Sat, May 03, 2008 at 04:24:55PM +0100, David Claughton wrote:
When updating from 4.69-5 to 4.69-5+b1 the install fails with the
following output...
Unpacking replacement exim4-base ...
Use of uninitialized value in subroutine entry at
/usr/lib/perl/5.10/DynaLoader.pm line 219.
dpkg: warning - old post-removal script killed by signal (Segmentation
fault)
That looks like some perl bug caused by the recent perl transition.
Please set EX4DEBUG=1 and try installing again, and paste the output
here.
Greetings
Marc
This didn't produce any debug output, so I did a bit of digging and it
looks like it was actually falling over in the debconf Gnome frontend
... specifically ...
require Debconf/FrontEnd/Gnome.pm called at (eval
33)[/usr/share/perl5/Debconf/AutoSelect.pm:52] line 2
Debconf::AutoSelect::BEGIN() called at /usr/lib/perl5/Gnome2.pm line 0
eval {...} called at /usr/lib/perl5/Gnome2.pm line 0
eval '
use Debconf::FrontEnd::Gnome;
Debconf::FrontEnd::Gnome-new();
;' called at /usr/share/perl5/Debconf/AutoSelect.pm line 52
Debconf::AutoSelect::make_frontend() called at
/usr/share/debconf/frontend line 15
Signal SEGV at /usr/lib/perl5/Gnome2.pm line 26
require Gnome2.pm called at (eval
34)[/usr/share/perl5/Debconf/FrontEnd/Gnome.pm:13] line 3
Debconf::FrontEnd::Gnome::BEGIN() called at /usr/lib/perl5/Gnome2.pm
line 0
eval {...} called at /usr/lib/perl5/Gnome2.pm line 0
eval '
use Gtk2;
use Gnome2;
;' called at /usr/share/perl5/Debconf/FrontEnd/Gnome.pm line 13
Switching to Dialog fixed the problem. I'm not sure if this is related
to bug #443753 or if it's an entirely separate SEGV ;-)
Rgrds,
David.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#186005: Suggested Patch
Package: apt-src
Version: 0.25.1-0.1
--- Please enter the report below this line. ---
Hi,
This is because when error() is called it doesn't pop the @unwind array
prior to calling the unwind function, so if the unwind function itself
calls error, it goes into a loop.
Trivial patch below.
Regards, David.
www.encoresoup.com
==
diff --git a/AptSrc.pm b/AptSrc.pm
index f2a01ad..8df1fa1 100644
--- a/AptSrc.pm
+++ b/AptSrc.pm
@@ -638,7 +638,7 @@ sub error {
my $class=shift;
print STDERR E: .shift().\n;
# Error unwind.
- foreach (reverse @unwind) {
+ while ($_ = pop @unwind) {
$_-();
}
exit(1);
==
--- System information. ---
Architecture: i386
Kernel: Linux 2.6.18-4-vserver-686
Debian Release: 4.0
500 testing ftp.uk.debian.org
--- Package information. ---
Depends (Version) | Installed
=-+-==
libapt-pkg-perl (= 0.1.6) | 0.1.21
dpkg-dev | 1.13.25
apt | 0.7.3
perl (= 5.6.0-16) | 5.8.8-7
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344848: Suggest change of option description
Package: apt-src Version: 0.25.1-0.1 --- Please enter the report below this line. --- Correct su command should be su -c -- to prevent apt-get's -y switch from being intercepted by su. IMHO this is probably best dealt with by changing the description of the RootCommand option. Trivial patch below. Regards, David. == diff --git a/apt-src b/apt-src old mode 100755 new mode 100644 index 861e3dd..2efb973 --- a/apt-src +++ b/apt-src @@ -217,7 +217,7 @@ The command to use to build a tree. Run in the tree to build The command to use if a non-root user needs to become root. This is used for, example, to satisfy build-deps. sudo is a good choice and the default. -If you want to use su, you'll need to set it to su -c. +If you want to use su, you'll need to set it to su -c --. =item APT::Src::BuildDeps = --- System information. --- Architecture: i386 Kernel: Linux 2.6.18-4-vserver-686 Debian Release: 4.0 500 testing ftp.uk.debian.org --- Package information. --- Depends (Version) | Installed =-+-== libapt-pkg-perl (= 0.1.6) | 0.1.21 dpkg-dev | 1.13.25 apt | 0.7.3 perl (= 5.6.0-16) | 5.8.8-7 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#290443: apt-src: Suggested patch
Package: apt-src
Version: 0.25.1-0.1
Followup-For: Bug #290443
Hi,
Please consider the following patch, which should fix this issue.
Thanks,
David.
diff --git a/AptSrc.pm b/AptSrc.pm
index 02d273f..f2a01ad 100644
--- a/AptSrc.pm
+++ b/AptSrc.pm
@@ -323,22 +323,25 @@ sub install {
return @ret;
}
- my $item=$class-new(
- status = 'removed',
- basedir = $cwd,
- source = $source,
- version = $version,
- sourcepkgversion = $version,
- );
-
# Go to the loclimit directory, to install a package there.
+ my $basedir;
if (defined $loclimit ! $ignoreloclimit) {
chdir($loclimit) || $class-error(Cannot chdir to $loclimit);
+ $basedir = $loclimit;
}
else {
chdir($dir) || $class-error(Cannot chdir to $dir);
+ $basedir = $dir;
}
+ my $item=$class-new(
+ status = 'removed',
+ basedir = $basedir,
+ source = $source,
+ version = $version,
+ sourcepkgversion = $version,
+ );
+
# source=version used to get exactly the version the user asked
# for.
if ($class-do(qw{apt-get source}, $source=$version) != 0) {
diff --git a/apt-src b/apt-src
old mode 100755
new mode 100644
-- System Information:
Debian Release: 4.0
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.18-4-vserver-686 (SMP w/1 CPU core)
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Versions of packages apt-src depends on:
ii apt 0.7.3 Advanced front-end for dpkg
ii dpkg-dev 1.13.25package building tools for Debian
ii libapt-pkg-perl 0.1.21 Perl interface to libapt-pkg
ii perl 5.8.8-7Larry Wall's Practical Extraction
Versions of packages apt-src recommends:
ii build-essential 11.3 informational list of build-essent
ii fakeroot 1.7.1 Gives a fake root environment
ii sudo 1.6.8p12-4 Provide limited super user privile
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407200: MPEG 2.5 Support
Hi, I could be wrong, but the announcement for MAD v0.12.3b (http://www.mars.org/mailman/public/mad-announce/2001-January/01.html) suggests that MPEG 2.5 support has been present for some time? Dave. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414746: Possible fix upstream.
Hi, I looks to me like this bug matches upstream bug RT #24145, which has been marked as resolved. Although it's not 100% clear it looks as if XML::Twig v3.29 includes this fix. Rgrds, Dave. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
