On Sun, Aug 04, 2013 at 08:47:49PM +0200, George Danchev wrote: > Thanks for your understanding. I disagree a bit with the "report was not > overly helpful" because I provided the affected version of doxygen, the > version > of the libburn (resp. the public header) which provokes this FAIL in doxygen, > and I also mentioned that the FAIL is reliably reproducible (Sorry, I'm in > VAC, properly documented, so I can not go further into tracking doxygen > entrails). I also disagree with the statement that "part of the issue is with > doxygen"... the whole FAIL is with doxygen, because however awkward the > header > is, doxygen should not get stuck, even in a endless loop.
If you are on VAC, then maybe enjoy that time instead of replying to nasty bug reports? Responding in a hurry rarely works out well as we have seen again. It's not as if this couldn't wait or others could pick it up. Your reassignment was very brief. It did nothing to track down the issue. It was not even clear whether the issue really resided in doxygen or whether libburn was using doxygen in an unspecified way. libburn uses both automatic linking and employed an unspecified syntax for referencing a function. It invoked undefined behaviour in doxygen. I agree that an endless loop is not the best implementation of undefined behaviour, but clearly libburn needs this fixed regardless of how or when the loop is fixed in doxygen. A quick search on udd.d.o/bugs.cgi indicates, that no other package is suffering from this issue. It will probably take some time for upstream to produce a fixed release and you have a fix. Now forget about it and enjoy your time. Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
