Re: Possible MBF: Packages depending on iceweasel but not firefox/firefox-esr

[Guillem Jover]

On Sun, 2016-03-20 at 20:31:13 +, Ben Hutchings wrote:
> On Sun, 2016-03-20 at 12:39 -0700, Josh Triplett wrote:
> > Leaving aside any other reasons: many packages have a versioned
> > dependency on iceweasel, and we don't have versioned provides.

> Yes we do, since dpkg 1.18.

Actually since dpkg 1.17.11 (as documented in deb-control(5)), and
apt 1.0.7. Both in Debian jessie.

Thanks,
Guillem

Re: a poll for Dgit workflows

[Daniel Stender]

On 20.03.2016 13:58, Ian Jackson wrote:
> Daniel Stender writes ("a poll for Dgit workflows"):
>> I've experimented with applying `gbp import-orig` on an extra
>> upstream branch and merging into e.g. dgit/sid, but this seems to be
>> substandard because `dgit quilt-fixup` wants to quiltify all the
>> changes in the working tree, which isn't wanted.
> 
> FYI I am (still) working on support in dgit for pushing from a
> patches-unapplied git branch, which might be helpful.
> 
> Another easy approach is to switch to a non-quilt source format.  This
> will work if you don't need the other things that `3.0 (quilt)' does.
> 
>> The next thing which would be interesting is how to rework patches
>> e.g. unfuzzing them (for rebase isn't possible on freshly cloned
>> repos with no previous Git history?).
> 
> It's quite easy with git to rebase a series of commits onto another
> branch with disjoint hitory.  (And if the other history has the right
> files in it, it will actually work.)  See git-rebase(1), specifically
> --onto.
> 
> Ian.

Ah yes, source format 1.0 fits better here. Thanks for the pointer and
comments (Manoj, too).

DS

-- 
4096R/DF5182C8
http://www.danielstender.com/blog/

Re: Mass Bug Filing: Missing Build-Depends: graphviz

[Santiago Vila]

On Mon, Mar 21, 2016 at 05:04:24AM +, Bas Wijnen wrote:
> On Sun, Mar 20, 2016 at 08:07:55PM +0100, Adam Borowski wrote:
> > On Sun, Mar 20, 2016 at 06:51:23PM +, Bas Wijnen wrote:
> > > That also means that programs calling dot will need graphviz in their
> > > Build-Depends, no matter what the default is.
> > 
> > As is, a number of them do call dot without the build-dependency.
> 
> Yes, so that's a bug in those programs, not in doxygen.  It would be "fixed" 
> by
> adding graphviz as a Depends to doxygen, but that would be incorrect.

Please note that it is really doxygen who calls dot while those
programs are being built, not really those programs. And doxygen calls
dot because the HAVE_DOT variable is set to yes by doxygen, indicating
that the dot command is available.

Do you agree, at least, that it is not doxygen business to claim
that the dot command is available without a Depends?

Since we are all Cc:ing the bug address: This bug report is not to ask
doxygen to depend on graphviz, that would be only one of the two possible
outcomes.

This bug report is about the inconsistency of having HAVE_DOT defaulting
to yes without a Depends.

> > That would be the case if doxygen propagated the error, which it does not.
> 
> And that _is_ a bug in doxygen, IMO.  If it cannot produce the requested
> output, it should abort with an error.

Yes, that's definitely a bug and it's already reported (Bug #818379).

Thanks.

Bug#818881: ITP: right-encoding -- Adds the Character Encoding menu to the context menu

[Ximin Luo]

Package: wnpp
Severity: wishlist
Owner: Ximin Luo 

* Package name: right-encoding
  Version : 0.3.5
  Upstream Author : JoungKyun 
* URL : 
https://addons.mozilla.org/ko/firefox/addon/right-encoding-76838/
* License : BSD
  Programming Lang: JS
  Description : Adds the Character Encoding menu to the context menu

Right Encoding is added menu that set the character set on the context menu
(mouse right-click) on Firefox and Thunderbird.

Equivalent functionality already exists in Firefox/Iceweasel, but amazingly
Thunderbird/Icedove does not provide a way to temporarily override the encoding
for a single message. That's where this extension is most useful.

Re: Possible MBF: Packages depending on iceweasel but not firefox/firefox-esr

[Adam Borowski]

On Sun, Mar 20, 2016 at 05:38:05PM -0700, Josh Triplett wrote:
> James McCoy wrote:
> > > > Leaving aside any other reasons: many packages have a versioned
> > > > dependency on iceweasel, and we don't have versioned provides.
> > > [...]
> > >
> > > Yes we do, since dpkg 1.18.
> 
> > Yet others parts of our infrastructure still need updates to handle then 
> > (e.g., britney).
> 
> Ah.  So I assume that packages using versioned Provides probably
> shouldn't get uploaded to the archive until that happens?

Not in this case -- you need britney only for testing migration, dose for
archive satisfiability checks.  These are fine as long as "iceweasel" is a
real package, and at present it is.

As for actually installing the packages, both apt and dpkg do support
versioned provides.  Thus, if "firefox" gains such a Provides: (it currently
lacks it), such dependencies will be satisfied.

-- 
A tit a day keeps the vet away.

Re: a poll for Dgit workflows

[Adam Borowski]

On Mon, Mar 21, 2016 at 10:19:01AM +0100, Daniel Stender wrote:
> On 20.03.2016 13:58, Ian Jackson wrote:
> > Another easy approach is to switch to a non-quilt source format.  This
> > will work if you don't need the other things that `3.0 (quilt)' does.
> 
> Ah yes, source format 1.0 fits better here. Thanks for the pointer and
> comments (Manoj, too).

Please don't use source format 1.0, it sucks.  Instead, you can:
  echo single-debian-patch >debian/source/options
which gives you all upsides of 3.0 without the big downside, aka quilt.

-- 
A tit a day keeps the vet away.

Bug#818895: ITP: libxio -- Mellanox(R) Technologies IO, Message, and RPC Acceleration Library

[Chrysostomos Nanakos]

Package: wnpp
Severity: wishlist
Owner: Chrysostomos Nanakos 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: libxio
  Version : 1.15
  Upstream Author : Eyal Salomon 
* URL : http://www.accelio.org
* License : GPLv2 or BSD
  Programming Lang: C
  Description : Mellanox(R) Technologies IO, Message, and RPC Acceleration 
Library

Accelio is a high-performance asynchronous reliable messaging and RPC library
optimized for hardware acceleration. RDMA as well as other transport
implementations, such as TCP/IP, shared-memory, and others can take advantage
of efficient and convenient API.

Accelio is designed to maximize message and CPU parallelism, while minimizing
CPU contention and locking and enabling zero data copy communication
procedures. The result is an unparalleled performance gains as measured by
transactions per second, latency (Ping-Pong and under load), bandwidth, and CPU
overhead.

Accelio guarantees lossless end-to-end transaction delivery/execution, and
automatically recovers from communication failures or failed message delivery.
Accelio supports transactional request/replay communication model, or reliable
(acceptance of) messages.

Accelio aims to provide an easy-to-use, reliable, scalable, and high
performance data/message delivery middleware that maximizes the efficiency of
modern CPU and network infrastructure.


signature.asc
Description: Digital signature

Re: Mass Bug Filing: Missing Build-Depends: graphviz

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Mar 21, 2016 at 11:26:16AM +0100, Santiago Vila wrote:
> > Yes, so that's a bug in those programs, not in doxygen.  It would be 
> > "fixed" by
> > adding graphviz as a Depends to doxygen, but that would be incorrect.
> 
> Please note that it is really doxygen who calls dot while those
> programs are being built, not really those programs. And doxygen calls
> dot because the HAVE_DOT variable is set to yes by doxygen, indicating
> that the dot command is available.

No, it is a configuration option which is set by the calling program.  It
defaults to yes, and for that reason it makes sense that there should be a
Recommends relation.  But the caller is not required to keep the default, so if
it does, it is calling dot through doxygen.

> Do you agree, at least, that it is not doxygen business to claim
> that the dot command is available without a Depends?

I just reread policy, and changed my mind on this.

Policy says: The Depends field should be used if the depended-on package is
required for the depending package to provide a significant amount of
functionality.  The Recommends field should list packages that would be found
together with this one in all but unusual installations.

I wouldn't consider the graphs a "significant amount of functionality", but
that is subjective.  I'd leave it to the package maintainer to decide whether
that is the case.  Given that they chose to make HAVE_DOT the default, it seems
that they do, so then a Depends would be in order.

On the other hand, if they decide that it isn't, then the proper way to use
doxygen with HAVE_DOT enabled (explicitly or as the default) is to depend on
graphviz.

So I agree that if HAVE_DOT defaults to yes, it should be a Depends relation.

> Since we are all Cc:ing the bug address: This bug report is not to ask
> doxygen to depend on graphviz, that would be only one of the two possible
> outcomes.

Agreed.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJW8AViAAoJEJzRfVgHwHE6nVAP/Rz/av7mSDWdE2ZbLuhHi53h
rLhES9CKE3YGIY7rXIyrKDIr3o2XiKYQtO4yLEhyBzxRPjMdxta2hnr/xUGyzlaW
icR+/ugj9agt8oN11As/kTdr1HZVxjgyaGWAlbaNu6xrFFoK0EZ8atKmroPXtL6R
jjfVJBDWpssX+G5oI4xWX0toVRCp6r9HYMuJIei33qDoSzyVekx0GUXaG/zSE5Pe
tpKHR+swiYbM6d9s0MB7TyjTDDdN83XX9LnBEwXOtEn6FVeFJ1eBl2VgTXNF1wRu
q01jIQFmdIgrpJey6GImfwA1uqrCg8QNqThvOA7//NY0iBXIb37jLNsi5ir90Ot5
LYakDtJtwpi6bq+AZo+THQ4AKChQX28PCuZHGAVbaDycbM0fhbfriJ6pqAQZ5Ut/
dZhjrP6FaPZ/AxowS14lv+tl5dreP9ZnaQE6yqNvKztPNp8AkQPerne0EPYlNr4I
OFw4/CzOyMjaT7U7Hb0xjzJw5CHsZodjPkdTysgNzBfHsNLKsIzKiL29HtwA7bIR
QNiuP9ANAgPIL/XYidiSpTVwrjj3kKKQ7/niAAwVRq4aPJBACKxYeT7Zy3a9BDDk
mnmU4Ahfnu6Q6RB/wYKxChs/CZgadcGrWWuRUfELP/HEfHIig6PWLR5nFAuTBG9r
YAgQtIkupO2lRRVOBqBM
=5Z8f
-END PGP SIGNATURE-

Bug#818900: [Lua Policy] integrate debian's lua modules into Debian's Luarocks

[lumin]

Package: lua5.1-policy
Version: 33
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, h...@hisham.hm

Hi,
(Talking about policy, hence CC'ing -devel)
(CC'ing luarocks upstream)

When I'm dealing with one of my ITP's I found that this is
a noticeable problem to Debian's lua packages. And I think
this may require some changes to our lua policy, or the dh-lua
scripts.

Luarocks is a lua module manager, just like pip to python.
However Debian's luarocks is blind to Debian's lua modules,
i.e. `luarocks list` won't list lua modules installed by dpkg,
besides, lua modules installed by dpkg won't participate
lua module dependency resolution, that's bad.

When pulling new lua modules from the internet with `luarocks`,
it will scan lua module dependency and automatically pull missing
modules and install them. For example, I need to install a lua
module that is not packaged by us, say lua-xxx, and it depends
on lua-cjson. Then `luarocks install xxx` will cause luarocks
to install a new lua-cjson module, ignoring the lua-cjson package
installed by dpkg. Why do we provide lua-cjson package?

*** What to do to make improvement? ***

IMHO following changes should be considered:

1. update default configuration file of luarocks
   /etc/luarocks/config-5.1.lua

```patch
  rocks_trees = { 
 home..[[/.luarocks]],
 [[/usr/local]],
+[[/usr]],
  }
+ deps_mode = 'all'
```

2. let luarocks package install this directory

   /usr/lib/luarocks/rocks/

3. update lua-* packages with luarocks integration,
   e.g. update their postinst and prerm scripts.
   
   To this point I have a solution that works but is not good enough:
   (patch parts copied from my locally modified lua-cjson package)

```patch
--- /dev/null
+++ b/debian/lua-cjson.postinst
@@ -0,0 +1,31 @@
+#!/bin/sh
+set -e
+
+prepare_luarocks ()
+{
+  local rockdir
+  rockdir='/usr/lib/luarocks/rocks/lua-cjson/2.1.0-1/'
+  mkdir -p $rockdir
+  echo 'rock_manifest = {}' > $rockdir/rock_manifest
+  cp /usr/share/doc/lua-cjson/lua-cjson-2.1.0-1.rockspec $rockdir
+  if [ -x /usr/bin/luarocks-admin ]; then
+luarocks-admin make-manifest --local-tree --tree=/usr
+  fi
+}
[...]
```

and this one

```patch
--- /dev/null
+++ b/debian/lua-cjson.prerm
@@ -0,0 +1,27 @@
+#!/bin/sh
+set -e
+
+remove_luarocks ()
+{
+  if [ -x /usr/bin/luarocks ]; then
+   luarocks remove lua-cjson --local-tree --tree=/usr
+  fi
+}
+
```

Thanks! :-)
-- 
 .''`.
: :' :
`. `' 
  `-  

Re: Bug#818900: [Lua Policy] integrate debian's lua modules into Debian's Luarocks

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Mar 21, 2016 at 02:37:44PM +, lumin wrote:
> When I'm dealing with one of my ITP's I found that this is
> a noticeable problem to Debian's lua packages. And I think
> this may require some changes to our lua policy, or the dh-lua
> scripts.

What you describe should be fixed.  There is a problem with how your scripts
work, though: if some packages are installed before luarocks, they will not be
indexed. Not unless luarocks scans for installed packages on installation
anyway.  If it can do that, it might make more sense to just trigger that
procedure when a new lua module is installed as well.

Making that part of dh-lua seems like the way to go.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJW8A3zAAoJEJzRfVgHwHE6Qu8QAIglXrTQ5g3fuMIfAMoUz+Z/
qmtOu18LBZ+c20D1GgXRSz5AC+v9/9qLrEwYxM5smmOOaW7nEtNDfBOBY2Zme4Mm
NcTe1kqzaR/QOQ6zCRANzTD5ZcLsk88DSRxXby0cOBBXrPr+QtDruDESre3Wmu67
BW24kAD79kAp+W/gLxN2IIvRPMkOWF2/Q8ElxujD6Hm1qLanpkIvkJwqoQmrRnrL
eN/EG+LbOOwoJ+sXeH/SXE/Cox6XrECahb2PQQPlxRN3KElMnu+JspV76eOAF53r
sn7hsPl7TfNHHC63ciWOiMv5JfXGGikl3/UMfJSCiqQB29iE3H7/xLkK/euEI0wL
cVUEMeVC6AsgldAGlufiqIgQgXK4pcms+sOt6/AlnwkWL6JtoQuf3cp0dCFtGMtu
0AUcre3I/9DG7lrkHFcI1GITt//kXsDajodhqIfgzK+rfmctfNb79fe3Indb/1OI
t0u7AompBTqTA+adojbjvRgj2XXmcgk/hcUGzTlD6Rfwkbv3dHE4EicUOdM/XL2g
jhSbNmrfnpAWg9Mf5rcGyB9uFjiKIz2pcI7zfl/B9B12zWsgpt4qq8l0Ktl0apcs
OwlQ6Ocp5m/N7vq3x2Ml7i2Rbo6JsinVeQJ9Q4zA+1V0uozR5s2yMYbL92X8AcWp
YDmDAUpOfKl91w6h17+F
=GHup
-END PGP SIGNATURE-

Re: Bug#818900: [Lua Policy] integrate debian's lua modules into Debian's Luarocks

[Enrico Tassi]

On Mon, Mar 21, 2016 at 03:06:28PM +, Bas Wijnen wrote:
> On Mon, Mar 21, 2016 at 02:37:44PM +, lumin wrote:
> > When I'm dealing with one of my ITP's I found that this is
> > a noticeable problem to Debian's lua packages. And I think
> > this may require some changes to our lua policy, or the dh-lua
> > scripts.
> 
> What you describe should be fixed.  There is a problem with how your scripts
> work, though: if some packages are installed before luarocks, they will not be
> indexed. Not unless luarocks scans for installed packages on installation
> anyway.  If it can do that, it might make more sense to just trigger that
> procedure when a new lua module is installed as well.
> 
> Making that part of dh-lua seems like the way to go.

Undoubtedly.  Each lua package could ship a luarocks manifest, something
like /usr/lib/luarocks/5.1/rocks/lua-cjson/2.1.0-1/manifest

Such manifest could be generated by some code pretty close to postinst
script attached to the bugreport, but at package build time (by dh-lua)
and not at package installation time.

Lumin, if you have time, please try to patch dh-lua.  You could look for
the code that generates .pc files, and start from that.
Otherwise I'll do it myself, but I'm a bit busy these days.

Best,
-- 
Enrico Tassi

Re: Possible MBF: Packages depending on iceweasel but not firefox/firefox-esr

[Santiago Vila]

On Sun, Mar 20, 2016 at 12:04:32PM +, Simon McVittie wrote:
> it has an artificial RC bug to stop it from entering testing, because
> the non-ESR releases aren't supportable in stable.

An artificial bug to keep something out of testing is a little bit
strange. Isn't this why we have the "experimental" branch?

We could have firefox ESR in unstable and firefox latest in
experimental, both named "firefox".

Re: Possible MBF: Packages depending on iceweasel but not firefox/firefox-esr

[Ben Hutchings]

On Mon, 2016-03-21 at 21:18 +0100, Santiago Vila wrote:
> On Sun, Mar 20, 2016 at 12:04:32PM +, Simon McVittie wrote:
> > 
> > it has an artificial RC bug to stop it from entering testing, because
> > the non-ESR releases aren't supportable in stable.
> An artificial bug to keep something out of testing is a little bit
> strange.

There is precedent for it.  Another example would be linux-grsec..

> Isn't this why we have the "experimental" branch?
>
> We could have firefox ESR in unstable and firefox latest in
> experimental, both named "firefox".

I see experimental as a place for short-lived branches, and I think
that where there are long periods between stable releases it can be
useful to provide both stable and unstable versions in unstable.  (We
don't do this with linux, but with more developer effort available I
could imagine providing a linux-lts that e.g. would follow 4.4.y until
4.10 is released.  But only one of them could build linux-libc-dev.)

(I would be interested to know what fraction of unstable users also
have experimental enabled as a source.  Does popcon report which suites
are enabled in APT sources, and if not could that be added?  Does it
report enough information to tell how many users install experimental
versions?)

Ben.

-- 
Ben Hutchings
Editing code like this is akin to sticking plasters on the bleeding stump
of a severed limb. - me, 29 June 1999

signature.asc
Description: This is a digitally signed message part

Re: Bug#782264: grub-install fails in nested LVM

[Pierre-Elliott Bécue]

Le mercredi 27 janvier 2016 à 18:13:29+, Martin Read a écrit :
> On 26/01/16 15:52, Pierre-Elliott Bécue wrote:
> >Bump.
> >
> >It's been more than 10 months and still nothing (even a simple ack).
> >
> >Could you consider adding a stable version of grub in a partial release of 
> >Jessie?
> 
> A cursory inspection of the public browsing interface[1] to the relevant git
> repo makes it clear that there is no newer *version*, despite 2.02 beta 2
> being two years old and there having been significant numbers of git commits
> since then.
> 
> [1] http://git.savannah.gnu.org/cgit/grub.git/

Right, 2.02 beta 3 is out now, maybe it's worth a try.

Anyway, I was more concerned by the non-ack of my report.

Cheers,

-- 
PEB

Bug#818941: ITP: golang-github-xiang90-probing -- Golang probing

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov 
X-Debbugs-CC: debian-devel@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org

   Package name: golang-github-xiang90-probing
Version: 0.0~git20150806
Upstream Author: Xiang Li
License: Expat
URL: https://github.com/xiang90/probing
Description: Golang probing
 Library for simple probing.


signature.asc
Description: This is a digitally signed message part.

Bug#818942: ITP: python-bitcoinlib -- Easy interface to the Bitcoin data structures and protocol

[Carlo Stemberger]

Package: wnpp
Severity: wishlist
Owner: Carlo Stemberger 

* Package name: python-bitcoinlib
  Version : 0.5.1
  Upstream Author : Peter Todd 
* URL : https://github.com/petertodd/python-bitcoinlib
* License : LGPL
  Programming Lang: Python
  Description : Easy interface to the Bitcoin data structures and protocol

This Python2/3 library provides an easy interface to the bitcoin data
structures and protocol. The approach is low-level and "ground up", with
a
focus on providing tools to manipulate the internals of how Bitcoin
works.

"The Swiss Army Knife of the Bitcoin protocol." - Wladimir J. van der
Laan

Re: Possible MBF: Packages depending on iceweasel but not firefox/firefox-esr

[Adam Borowski]

On Mon, Mar 21, 2016 at 11:05:30PM +, Ben Hutchings wrote:
> (I would be interested to know what fraction of unstable users also
> have experimental enabled as a source.  Does popcon report which suites
> are enabled in APT sources, and if not could that be added?

No, it doesn't.

But what about wgetting[1] a substantial set of bug reports and taking those
which were submitted using reportbug, which does include such info?  I
already did so once in the past, to gather info about locale settings[2].

For example, #758969 says:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
which is what you want.

> Does it report enough information to tell how many users install
> experimental versions?)

Only for popcon itself.  I have no idea how to get that data.


[1]. There's probably some method that puts way less load on the BTS server
available for DDs.

[2]. Bad news: if we dropped non-Unicode locales there'd be kvetching.
-- 
A tit a day keeps the vet away.

Bug#818945: ITP: golang-github-appc-cni -- container network interface

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov 
X-Debbugs-CC: debian-devel@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org

   Package name: golang-github-appc-cni
Version: 0.1.0
Upstream Author: CoreOS, Inc
License: Apache-2.0
URL: https://github.com/appc/cni
Description: container network interface
 CNI, the Container Network Interface, is a proposed standard for
 configuring network interfaces for Linux application containers. The
 standard consists of a simple specification for how executable plugins can
 be used to configure network namespaces.


signature.asc
Description: This is a digitally signed message part.

Bug#818946: ITP: golang-github-coreos-gexpect -- library for starting and controlling subprocesses

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov 
X-Debbugs-CC: debian-devel@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org

   Package name: golang-github-coreos-gexpect
Version: 0.0~git20160223
Upstream Author: Thomas Rooney, CoreOS
License: Expat
URL: https://github.com/coreos/gexpect
Description: library for starting and controlling subprocesses
 Pure golang expect library, for easily starting and controlling subprocesses.


signature.asc
Description: This is a digitally signed message part.

Re: Possible MBF: Packages depending on iceweasel but not firefox/firefox-esr

[Colin Watson]

On Tue, Mar 22, 2016 at 12:51:20AM +0100, Adam Borowski wrote:
> [1]. There's probably some method that puts way less load on the BTS server
> available for DDs.

https://www.debian.org/Bugs/Access documents rsync access for this kind
of thing.

-- 
Colin Watson   [cjwat...@debian.org]

Re: Mass Bug Filing: Missing Build-Depends: graphviz

[Adam Borowski]

On Sun, Mar 20, 2016 at 08:07:55PM +0100, Adam Borowski wrote:
> > In other words, my solution to this bug would be to make doxygen exit with 
> > an
> > error code when calling dot fails.  Then make will fail, it's an FTBFS, it 
> > gets
> > fixed, and everyone is happy.
> 
> I've started a rebuild of all 552 packages in unstable that build-depend on
> doxygen

Here are the results: 60 packages call /usr/bin/dot without depending on
graphviz.  During the rebuild, there was a number of unrelated FTBFSes (7
failed, 36 attempted), some of them might possibly try calling dot later.
I'll investigate/retry/file bugs todorrow.

alsa-lib
apr
apr-util
asl
cmocka
coinor-ipopt
cppunit
frei0r
gammu
gazebo
gconfmm2.6
gnuradio
gtkspellmm
hamlib
jaula
libaccounts-qt
libaqbanking
libassa
libccrtp
libevhtp
libgadu
libgnomecanvasmm2.6
libgpiv
libgwenhywfar
liblightify
libmediainfo
libmpdclient
libmusicbrainz3
libopenobex
libpqxx
libsdl2
libsidplayfp
libssh
libsyncml
libwibble
linphone
log4c
lucene++
mpqc
netcdf
netcdf-cxx
nifticlib
open-vm-tools
openafs
openigtlink
opensurgsim
pidgin
qca2
roboptim-core
scim
sdformat
silly
sipxtapi
sombok
tango
thepeg
vdk2
wimlib
wxwidgets3.0
zipios++

-- 
A tit a day keeps the vet away.