An exchange with the author (below) on this topic produced this result.
Apparently the source tarball README strongly encourages filelight to be
built with --disable-debug. Please add this to the build.
.example. added to email addresses since bts seems a spam source.
Thanks,
-josh
----- Forwarded message from Max Howell <[EMAIL PROTECTED]> -----
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
version=3.1.7
Date: Thu, 8 Feb 2007 08:32:27 +0000
From: Max Howell <[EMAIL PROTECTED]>
To: Joshua Rodman <[EMAIL PROTECTED]>
Subject: Re: Filelight produces copious debug output on standard error
X-Google-Sender-Auth: 60a17437de3dcea3
The app should have been compiled ./configure --disable-debug. KDE's
build system does --enable-debug by default, so a pox on KDE! A pox on
your packager too as I do say in the README that you should disable
teh debug... ;-)
So yes, none of it is error output, just useful stuff for development.
I wish I could somehow force it to be off by default for my shipped
tarballs..
Sorry about that,
If you feel up to it you could compile your own, it only depends on
kdelibs. Otherwise you'll have to raise it with your packager I'm
afraid.
Max
On 08/02/07, Joshua Rodman <[EMAIL PROTECTED]> wrote:
>Application: filelight
>Version: 1.0-beta4 3.5.5, Debian Package 4:3.5.5a.dfsg.1-5 (4.0)
>OS: Linux (x86_64) release 2.6.19.2-jsr1
>Compiler: Target: x86_64-linux-gnu
>Severity: Normal
>
>Perhaps this is really a distribution problem, and if so I apologise.
>However, filelight seems to produce extensive debug output on standard
>error of the controlling terminal, for example a refresh of a view
>produces:
>
>filelight: >> void RadialMap::Map::invalidate(bool)
>filelight: Scan requested for: file:///home/jrodman/
>QThread object destroyed while thread is still running.
>filelight: >> void RadialMap::Map::make(const Directory*, bool)
>filelight: >> void RadialMap::Map::setRingBreadth()
>filelight: >> void RadialMap::Map::colorise()
>filelight: >> void RadialMap::Map::paint(unsigned int)
>
>Are any of these errors upon which the user can take any meaningful
>action or decision? If not, these should not be produced unless a
>-debug or -verbose switch is thrown on program start.
----- End forwarded message -----
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
