Re: kdebug defaults/build options
On August 4, 2011 12:37:37 PM Diggory Hardy wrote:
> Hi all
>
> Regarding default debug output in kde on debian:
>
> 1. A while ago I reported this: https://bugs.kde.org/show_bug.cgi?id=269882
> Perhaps disabling logging kget's debug messages makes sense? Or perhaps
> this is occasionally useful less often a problem? I don't have a strong
> opinion on this really.
>
> 2. At times I've been annoyed by the number of *spam* messages kwrite/kate
> leave on the console when run that way. Looking into it, these messages are
> kDebug outputs. The kde techbase suggests [1] this output is intended to be
> disabled in releases. Would you have any objections to doing this in the
> future, with kwrite at least? There's not many programs I've had problems
> with, but I do wince when running kwrite from a console every so often.
> [1]:
> http://techbase.kde.org/Development/FAQs/Debugging_FAQ#Is_there_a_preferred
> _way_to_print_debug_output_on_stderr.3F
My work-around to this problem is to tack "&>/dev/null &" onto the end of all
cmdline issued KDE commands...
...but, ya, it would be real nice if that wasn't necessary and could open the
door to wider use of Debian's KDE. e.g.: I'd love to run a KDE based system
off a USB flash drive but all those (typically useless during normal
operation*) messages will drastically shorten the flash drive's life--I expect
the same would be true of any device using solid state HDDs. I have also run
into apps dying when /home gets flled up by .xsession-errors, this is more of
a PITA than anything else but lowering the bar a bit by reducing the HDD
overhead--and consequently improving startup times--will allow KDE to run
better on slower systems or those with limited HDD space (or with /home as a
network FS!) than it does currently.
If Debian rebuilt packages for each archive I'd say an argument could be made
to leave it as it is for Unstable, reduce the output to only errors for
Testing, and turn them all off for Stable--but since packages migrate into the
archives (prehaps soon even those in Experimental will start migrating) it may
be best to turn off all messages from the start and educate users on the use
of kdebugdialog when problems arise.
- Bruce
* Here is a short extract from the end of my current .xsesion-errors...
QSslSocket: cannot resolve SSLv2_client_method
QSslSocket: cannot resolve SSLv2_server_method
QSslSocket: cannot resolve SSLv2_client_method
QSslSocket: cannot resolve SSLv2_server_method
QSslSocket: cannot resolve SSLv2_client_method
QSslSocket: cannot resolve SSLv2_server_method
QSslSocket: cannot resolve SSLv2_client_method
QSslSocket: cannot resolve SSLv2_server_method
QPainter::begin: Widget painting can only begin as a result of a paintEvent
QPainter::translate: Painter not active
QPainter::setClipRect: Painter not active
plasma-desktop(2975)/plasma StatusNotifierItemSource::refreshCallback:
DBusMenu disabled for this application
plasma-desktop(2975)/plasma StatusNotifierItemSource::refreshCallback:
DBusMenu disabled for this application
plasma-desktop(2975)/plasma StatusNotifierItemSource::refreshCallback:
DBusMenu disabled for this application
QSslSocket: cannot resolve SSLv2_client_method
QSslSocket: cannot resolve SSLv2_server_method
QGraphicsLinearLayout::removeAt: invalid index 1
QGraphicsLinearLayout::removeAt: invalid index 1
true
... if one knew the messages were the result of turning on output for a
specific app or subsystem they may be useful in tracking down a problem, but
without that context they appear to be just noise. This may be a case where
less output could improve debuggabilty (sp. :) ).
Reply to: