Bug#701832: doxygen consistently segfaults on kfreebsd-i386 when building opendnssec documentation

2013-03-05 Thread Steven Chamberlain
Hi,

On 05/03/13 03:26, Jeff Epler wrote:
> On Sun, Mar 03, 2013 at 12:20:57PM +, Steven Chamberlain wrote:
>>> #5  0x000800d21f2c in *__GI___libc_free (mem=) at 
>>> malloc.c:3736
>>> ar_ptr = 0x800ff3240
>>> p = 
>>> #6  0x000800844a79 in gvFreeContext () from /usr/lib/libgvc.so.5
>>> No symbol table info available.
>>> #7  0x00400fd8 in ?? ()
>>> No symbol table info available.
>>> #8  0x00080389bf04 in __pthread_sighandler
> 
> As many of you are probably aware, it's not permitted in POSIX to call free()
> in signal handler context without some additional guarantees about what the
> interrupted function may be.

Okay, that would make sense!

It seemed to me that some other thread (not shown by gdb) had received
the signal and freed something the active thread was still using.
Sometimes it caused a segfault, and less often resulted in a hang somehow.

The SIGINT handler sounds buggy, and maybe not that useful (who needs a
half-rendered diagram?) and so it might be best to disable it, which
would fix http://bugs.debian.org/524408

> ... and in main():
> signal(SIGINT, intr);


But this was probably unrelated to the cause of the hang seen on the
buildds (#701832).  That was hopefully fixed by disabling the relevant
code for now (which didn't seem useful either), with the patch in
http://bugs.debian.org/701832#53.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Bug#701832: doxygen consistently segfaults on kfreebsd-i386 when building opendnssec documentation

2013-03-04 Thread Jeff Epler
On Sun, Mar 03, 2013 at 12:20:57PM +, Steven Chamberlain wrote:
> > #5  0x000800d21f2c in *__GI___libc_free (mem=) at 
> > malloc.c:3736
> > ar_ptr = 0x800ff3240
> > p = 
> > #6  0x000800844a79 in gvFreeContext () from /usr/lib/libgvc.so.5
> > No symbol table info available.
> > #7  0x00400fd8 in ?? ()
> > No symbol table info available.
> > #8  0x00080389bf04 in __pthread_sighandler

As many of you are probably aware, it's not permitted in POSIX to call free()
in signal handler context without some additional guarantees about what the
interrupted function may be.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html
(search for "async-signal-safe")

It looks like this is what will happen when sending ctrl-c, though.
That's why a hang can be provoked in this way.

static void intr(int s)
{
/* if interrupted we try to produce a partial rendering before exiting */
if (G)
gvRenderJobs(Gvc, G);
/* Note that we don't call gvFinalize() so that we don't start event-driven
 * devices like -Tgtk or -Txlib */
exit (gvFreeContext(Gvc));
}
... and in main():
signal(SIGINT, intr);

for that matter, whatever gvRenderJobs is intended to do is likely hard
to guarantee to be only doing async-signal-safe things (let alone things that
are data-structure safe).  Indeed, I got a sigsegv when sending SIGINT exactly
when the first free inside gvLayoutJobs is holding the lock:

Breakpoint 3, 0x000800843b50 in gvLayoutJobs () from /usr/lib/libgvc.so.5
(gdb) ena 2
(gdb) c
Continuing.

Breakpoint 2, *__GI___libc_free (mem=0x61d940) at malloc.c:3736
3736in malloc.c
(gdb) signal 2
Continuing with signal SIGINT.

Program received signal SIGSEGV, Segmentation fault.
0x000800867778 in ?? () from /usr/lib/libgvc.so.5
(gdb) where
#0  0x000800867778 in ?? () from /usr/lib/libgvc.so.5
#1  0x000800870811 in ?? () from /usr/lib/libgvc.so.5
#2  0x000800873efd in emit_graph () from /usr/lib/libgvc.so.5
#3  0x000800875c9a in gvRenderJobs () from /usr/lib/libgvc.so.5
#4  0x00400fcc in ?? ()
#5  0x00080389bf04 in __pthread_sighandler (signo=6550134, _code=0, 
_sg=0x80063f276, ctx=0xa) at sighandler.c:39
#6  0x7083 in ?? ()
#7  0x00080389be60 in ?? () at internals.h:545
   from /lib/x86_64-kfreebsd-gnu/libpthread.so.0
#8  0x in ?? ()

possibly getting the segv is more common than the hang?  I haven't managed to
get the hang once using this break-and-signal-in-gdb methodology (amd64
kfreebsd sid/wheezy).

Jeff


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Bug#701832: doxygen consistently segfaults on kfreebsd-i386 when building opendnssec documentation

2013-03-03 Thread Steven Chamberlain
On 03/03/13 17:43, Steven Chamberlain wrote:
> I've no idea if my patch breaks any other functionality (it will fall
> back to 'GVLIBDIR only').  But I notice there is another patch
> fix-kfreebsd-chroots that already changed this same block of code.

The existing patch was a workaround for:
http://bugs.debian.org/575797

In case /proc/self/maps doesn't return useful info (e.g. in a chroot
environment on kfreebsd) it will fall back to GVLIBDIR.  On the buildds
it is always going to be the case.

I'm not sure what causes reading from /proc/self/maps to hang sometimes,
but there's not much point in doing this on kfreebsd.

So I think my patch is probably okay;  and it's not necessary to revert
the existing patch.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Processed: Re: Bug#701832: doxygen consistently segfaults on kfreebsd-i386 when building opendnssec documentation

2013-03-03 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> reassign 701832 graphviz
Bug #701832 [doxygen] doxygen consistently segfaults on kfreebsd-i386 when 
building opendnssec documentation
Bug reassigned from package 'doxygen' to 'graphviz'.
No longer marked as found in versions doxygen/1.8.1.2-1.
Ignoring request to alter fixed versions of bug #701832 to the same values 
previously set
> found 701832 2.26.3-12
Bug #701832 [graphviz] doxygen consistently segfaults on kfreebsd-i386 when 
building opendnssec documentation
Marked as found in versions graphviz/2.26.3-12.
> affects 701832 + opendnssec freefoam libdap witty
Bug #701832 [graphviz] doxygen consistently segfaults on kfreebsd-i386 when 
building opendnssec documentation
Added indication that 701832 affects opendnssec, freefoam, libdap, and witty
> tags 701832 + patch
Bug #701832 [graphviz] doxygen consistently segfaults on kfreebsd-i386 when 
building opendnssec documentation
Added tag(s) patch.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
701832: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701832
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Bug#701832: doxygen consistently segfaults on kfreebsd-i386 when building opendnssec documentation

2013-03-03 Thread Steven Chamberlain
reassign 701832 graphviz
found 701832 2.26.3-12
affects 701832 + opendnssec freefoam libdap witty
tags 701832 + patch
thanks

While running doxygen, I've seen 'dot' sometimes hang trying to read
/proc/self/maps;  I think this might be what causes the opendnssec build
to hang, and also affecting packages freefoam, libdap, witty in sid.

This happens usually on kfreebsd-i386 but also very rarely on
kfreebsd-amd64 too.  A gdb backtrace of a hung 'dot' process is below.

The relevant bit of code in graphviz lib/gvc/gvconfig.c even says:
> 298 /* this only works on linux, other systems will get GVLIBDIR only */
> 299 libdir = GVLIBDIR;
> 300 f = fopen ("/proc/self/maps", "r");

I'm unsure if this is supposed to work using GNU/kFreeBSD's linprocfs,
but I tried wrapping the problem code with #ifdef linux.  I was then
able to build the doxygen docs for opendnssec 250 times on
kfreebsd-amd64 and kfreebsd-i386 without recurrence of this bug yet.

I've no idea if my patch breaks any other functionality (it will fall
back to 'GVLIBDIR only').  But I notice there is another patch
fix-kfreebsd-chroots that already changed this same block of code.


> #0  0x000800d73080 in read () at ../sysdeps/unix/syscall-template.S:82
> No locals.
> #1  0x000800d19160 in _IO_new_file_underflow (fp=0x6030a0) at 
> fileops.c:606 
>   [0/751]
> count = 
> #2  0x000800d19bde in _IO_default_uflow (fp=0x4) at genops.c:440
> ch = 5
> #3  0x000800d102fa in _IO_getline_info (fp=0x6030a0, buf=0x80063b000 "", 
> n=1023, delim=10, extract_delim=1, eof=0x0) at iogetline.c:74
> c = 5
> len = 0
> ptr = 0x800a9bbc0 ""
> #4  0x000800d0f529 in _IO_fgets (buf=buf@entry=0x800a9bbc0 "", 
> n=, n@entry=1024, fp=fp@entry=0x6030a0) at iofgets.c:58
> _buffer = {__routine = 0x6030a0, __arg = 0x800614335, __canceltype = 
> 0, __prev = 0x0}
> _avail = 0
> _IO_acquire_lock_file = 0x6030a0
> count = 
> result = 
> #5  0x000800846944 in gvconfig_libdir (gvc=gvc@entry=0x602e80) at 
> gvconfig.c:303
> line = '\000' 
> libdir = 0x8008792b0 "/usr/lib/graphviz"
> path = 
> tmp = 
> f = 0x6030a0
> #6  0x000800846ab9 in gvconfig (gvc=gvc@entry=0x602e80, 
> rescan=rescan@entry=0 '\000') at gvconfig.c:472
> sz = 
> config_st = {st_dev = 13322904, st_ino = 8, st_mode = 24640, 
> __pad_mode = 99, st_nlink = 8, __pad_nlink = 0, st_uid = 13314984, st_gid = 
> 8, st_rdev = 6512704, 
>   st_atim = {tv_sec = 32, tv_nsec = 4294967295}, st_mtim = {tv_sec = 
> 4197488, tv_nsec = 34368266240}, st_ctim = {tv_sec = 4197488, tv_nsec = 0}, 
> st_size = 34368284856, 
>   st_blocks = 34366166680, st_blksize = 2534032, st_flags = 0, st_gen 
> = 4294967295, __unused1 = {1, 34368266240}}
> libdir_st = {st_dev = 4197488, st_ino = 0, st_mode = 0, __pad_mode = 
> 0, st_nlink = 0, __pad_nlink = 0, st_uid = 8518816, st_gid = 8, st_rdev = 
> 16725440, st_atim = {
> tv_sec = 2535432, tv_nsec = 34366087712}, st_mtim = {tv_sec = 1, 
> tv_nsec = 0}, st_ctim = {tv_sec = 536, tv_nsec = 34368284856}, st_size = 
> 6303360, st_blocks = 1, 
>   st_blksize = 4197488, st_flags = 0, st_gen = 6374197, __unused1 = 
> {6303360, 150}}
> f = 0x0
> config_text = 0x0
> libdir = 
> #7  0x000800847e13 in gvContextPlugins (builtins=, 
> demand_loading=1) at gvc.c:56
> gvc = 0x602e80

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org
Index: graphviz-2.26.3/lib/gvc/gvconfig.c
===
--- graphviz-2.26.3.orig/lib/gvc/gvconfig.c 2013-03-03 17:26:23.0 
+
+++ graphviz-2.26.3/lib/gvc/gvconfig.c  2013-03-03 17:29:41.235960554 +
@@ -297,6 +297,7 @@
 #else
/* this only works on linux, other systems will get GVLIBDIR only */
libdir = GVLIBDIR;
+#ifdef linux
f = fopen ("/proc/self/maps", "r");
if (f) {
while (!feof (f)) {
@@ -323,6 +324,7 @@
fclose (f);
}
 #endif
+#endif
}
if (gvc->common.verbose > 1) 
fprintf (stderr, "libdir = \"%s\"\n",


Bug#701832: doxygen consistently segfaults on kfreebsd-i386 when building opendnssec documentation

2013-03-03 Thread Steven Chamberlain
By hitting Ctrl-C at the right moment I can seem to cause 'dot' to hang
easily enough.  Attached is a quite different backtrace, which still
resulted in being stuck in __pthread_wait_for_restart_signal

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org
(gdb) thread apply all bt full

Thread 1 (process 17844):
#0  __pthread_sigsuspend () at 
../ports/sysdeps/unix/bsd/bsd4.4/kfreebsd/linuxthreads/pt-sigsuspend.S:24
No locals.
#1  0x0008038983b8 in __pthread_wait_for_restart_signal (self=) at pthread.c:1291
mask = {{__sigbits = {2, 0, 0, 0}, __bits = {2, 0, 0, 0}}}
#2  0x00080389a7b4 in suspend (self=) at restart.h:34
No locals.
#3  __pthread_alt_lock (lock=, self=0x1f) at spinlock.c:418
oldstatus = 0
newstatus = 140737488318816
wait_node = {next = 0x1, thr = 0x800637d20, abandoned = 0}
#4  0x000803898023 in *__GI___pthread_mutex_lock (mutex=0x6bc850) at 
mutex.c:123
self = 
#5  0x00080258a8d9 in ?? () from /usr/lib/x86_64-kfreebsd-gnu/libcairo.so.2
No symbol table info available.
#6  0x00080258c786 in ?? () from /usr/lib/x86_64-kfreebsd-gnu/libcairo.so.2
No symbol table info available.
#7  0x000802553e57 in ?? () from /usr/lib/x86_64-kfreebsd-gnu/libcairo.so.2
No symbol table info available.
#8  0x0008025542e0 in ?? () from /usr/lib/x86_64-kfreebsd-gnu/libcairo.so.2
No symbol table info available.
#9  0x0008025642df in ?? () from /usr/lib/x86_64-kfreebsd-gnu/libcairo.so.2
No symbol table info available.
#10 0x000802593d6a in ?? () from /usr/lib/x86_64-kfreebsd-gnu/libcairo.so.2
No symbol table info available.
#11 0x00080255cc71 in ?? () from /usr/lib/x86_64-kfreebsd-gnu/libcairo.so.2
No symbol table info available.
#12 0x00080254f833 in cairo_show_glyphs () from 
/usr/lib/x86_64-kfreebsd-gnu/libcairo.so.2
No symbol table info available.
#13 0x0008020dd8f5 in ?? () from 
/usr/lib/x86_64-kfreebsd-gnu/libpangocairo-1.0.so.0
No symbol table info available.
#14 0x0008020ddbc4 in ?? () from 
/usr/lib/x86_64-kfreebsd-gnu/libpangocairo-1.0.so.0
No symbol table info available.
#15 0x00080230c8dd in pango_renderer_draw_glyphs () from 
/usr/lib/x86_64-kfreebsd-gnu/libpango-1.0.so.0
No symbol table info available.
#16 0x00080230d4be in pango_renderer_draw_layout_line () from 
/usr/lib/x86_64-kfreebsd-gnu/libpango-1.0.so.0
No symbol table info available.
#17 0x00080230d6e5 in pango_renderer_draw_layout () from 
/usr/lib/x86_64-kfreebsd-gnu/libpango-1.0.so.0
No symbol table info available.
#18 0x0008020ddd18 in ?? () from 
/usr/lib/x86_64-kfreebsd-gnu/libpangocairo-1.0.so.0
No symbol table info available.
#19 0x000801ed1b4d in ?? () from /usr/lib/graphviz/libgvplugin_pango.so.6
No symbol table info available.
#20 0x000800842d5d in gvrender_textpara () from /usr/lib/libgvc.so.5
No symbol table info available.
#21 0x00080085f3bc in emit_label () from /usr/lib/libgvc.so.5
No symbol table info available.
#22 0x000800872e45 in emit_clusters () from /usr/lib/libgvc.so.5
No symbol table info available.
#23 0x000800873955 in emit_graph () from /usr/lib/libgvc.so.5
No symbol table info available.
#24 0x000800875c9a in gvRenderJobs () from /usr/lib/libgvc.so.5
No symbol table info available.
#25 0x00400fcc in ?? ()
No symbol table info available.
#26 0x00080389bf04 in __pthread_sighandler (signo=0, _code=65542, _sg=0x0, 
ctx=0x80e9f000) at sighandler.c:39
self = 
#27 0x7083 in ?? ()
No symbol table info available.
#28 0x00080389be60 in ?? () at internals.h:545 from 
/lib/x86_64-kfreebsd-gnu/libpthread.so.0
No symbol table info available.
#29 0x in ?? ()
No symbol table info available.
(gdb)


Bug#701832: doxygen consistently segfaults on kfreebsd-i386 when building opendnssec documentation

2013-03-03 Thread Steven Chamberlain
Hi,

On Wed, Feb 27, 2013 at 19:24:59 +0100, Ondřej Surý wrote:
> the doxygen segfaults on kfreebsd-i386 when building opendnssec
> package and it blocks it's transition from unstable to testing.
> [...]
> https://buildd.debian.org/status/logs.php?arch=kfreebsd-i386&pkg=opendnssec&ver=1%3A1.3.9-4

It looks more like it's the 'dot' program from graphviz that hangs.  I
ran its regression test suite repeatedly and managed to reproduce a
familiar thread-related hang in sigsuspend:

> steven   97235  0.0  0.1  83676  4436 ?T+   12:03   0:00 /usr/bin/dot 
> -Kdot -Tps -ondata/colors_dot.ps graphs/colors.gv

> (gdb) thread apply all bt full
> 
> Thread 1 (process 97235):
> #0  __pthread_sigsuspend () at 
> ../ports/sysdeps/unix/bsd/bsd4.4/kfreebsd/linuxthreads/pt-sigsuspend.S:24
> No locals.
> #1  0x0008038983b8 in __pthread_wait_for_restart_signal (self= out>) at pthread.c:1291
> mask = {{__sigbits = {2, 0, 0, 0}, __bits = {2, 0, 0, 0}}}
> #2  0x00080389a7b4 in suspend (self=) at restart.h:34
> No locals.
> #3  __pthread_alt_lock (lock=, self=0x1f) at spinlock.c:418
> oldstatus = 0
> newstatus = 140737488322416
> wait_node = {next = 0x1, thr = 0x800637d20, abandoned = 0}
> #4  0x000803898023 in *__GI___pthread_mutex_lock (mutex=0x800ff3240) at 
> mutex.c:123
> self = 
> #5  0x000800d21f2c in *__GI___libc_free (mem=) at 
> malloc.c:3736
> ar_ptr = 0x800ff3240
> p = 
> #6  0x000800844a79 in gvFreeContext () from /usr/lib/libgvc.so.5
> No symbol table info available.
> #7  0x00400fd8 in ?? ()
> No symbol table info available.
> #8  0x00080389bf04 in __pthread_sighandler (signo=0, _code=65542, 
> _sg=0x0, ctx=0x80e9f000) at sighandler.c:39
> self = 
> #9  0x7083 in ?? ()
> No symbol table info available.
> #10 0x00080389be60 in ?? () at internals.h:545 from 
> /lib/x86_64-kfreebsd-gnu/libpthread.so.0
> No symbol table info available.
> #11 0x in ?? ()
> No symbol table info available.
> (gdb) 

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Bug#701832: doxygen consistently segfaults on kfreebsd-i386 when building opendnssec documentation

2013-02-28 Thread Ondřej Surý
On Thu, Feb 28, 2013 at 8:49 PM, Julien Cristau  wrote:
> Is there any way you could work around this in opendnssec?  E.g. by not
> building the doc on that arch for now?

I could, and it was the plan if nobody comes up with some clever idea
till the end of the week.

O.
-- 
Ondřej Surý 


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Bug#701832: doxygen consistently segfaults on kfreebsd-i386 when building opendnssec documentation

2013-02-28 Thread Julien Cristau
On Wed, Feb 27, 2013 at 19:24:59 +0100, Ondřej Surý wrote:

> Package: doxygen
> Version: 1.8.1.2-1
> Severity: grave
> 
> Hi,
> 
> the doxygen segfaults on kfreebsd-i386 when building opendnssec
> package and it blocks it's transition from unstable to testing.
> 
> Could you please look at that?
> 
> The build logs are here:
> https://buildd.debian.org/status/logs.php?arch=kfreebsd-i386&pkg=opendnssec&ver=1%3A1.3.9-4
> 
> I have also opened this on debian-bsd list:
> http://lists.debian.org/debian-bsd/2013/02/msg00117.html
> 
Is there any way you could work around this in opendnssec?  E.g. by not
building the doc on that arch for now?

kfreebsd porters, a look at this issue would be appreciated.

Thanks,
Julien


signature.asc
Description: Digital signature


Bug#701832: doxygen consistently segfaults on kfreebsd-i386 when building opendnssec documentation

2013-02-28 Thread Ondřej Surý
Right, I have jumped to conclusions prematurely. Anyway it still
blocks only on kfreebsd-i386.

If you have an idea how to do a workaround, I am open to anything.

Ondrej

On Thu, Feb 28, 2013 at 9:13 AM, Helmut Grohne  wrote:
> On Wed, Feb 27, 2013 at 07:24:59PM +0100, Ond??ej Surı wrote:
>> the doxygen segfaults on kfreebsd-i386 when building opendnssec
>> package and it blocks it's transition from unstable to testing.
>
> How do you know that it segfaults? I looked at your build logs, but
> those looked more like hanging. They were all hanging while creating dot
> graphs (using multiple threads), so maybe this is a race condition
> leading to a dead lock? On the other hand they all hanged on graph 37
> out of 144, so it appears deterministic.
>
> Helmut



--
Ondřej Surý 


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Bug#701832: doxygen consistently segfaults on kfreebsd-i386 when building opendnssec documentation

2013-02-28 Thread Helmut Grohne
On Wed, Feb 27, 2013 at 07:24:59PM +0100, Ond??ej Surý wrote:
> the doxygen segfaults on kfreebsd-i386 when building opendnssec
> package and it blocks it's transition from unstable to testing.

How do you know that it segfaults? I looked at your build logs, but
those looked more like hanging. They were all hanging while creating dot
graphs (using multiple threads), so maybe this is a race condition
leading to a dead lock? On the other hand they all hanged on graph 37
out of 144, so it appears deterministic.

Helmut


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Bug#701832: doxygen consistently segfaults on kfreebsd-i386 when building opendnssec documentation

2013-02-27 Thread Ondřej Surý
Package: doxygen
Version: 1.8.1.2-1
Severity: grave

Hi,

the doxygen segfaults on kfreebsd-i386 when building opendnssec
package and it blocks it's transition from unstable to testing.

Could you please look at that?

The build logs are here:
https://buildd.debian.org/status/logs.php?arch=kfreebsd-i386&pkg=opendnssec&ver=1%3A1.3.9-4

I have also opened this on debian-bsd list:
http://lists.debian.org/debian-bsd/2013/02/msg00117.html

Ondrej

-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-3-amd64 (SMP w/4 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 doxygen depends on:
ii  libc6   2.13-38
ii  libgcc1 1:4.7.2-5
ii  libstdc++6  4.7.2-5

Versions of packages doxygen recommends:
ii  doxygen-latex  1.8.1.2-1

Versions of packages doxygen suggests:
pn  doxygen-doc  
pn  doxygen-gui  
ii  graphviz 2.26.3-12

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org