vdboor

Long time no blog... I didn't make much room for it lately.

Previous week we've had Sinterklaas in The Netherlands. It's an annual Dutch tradition, which can be compared somewhat with Santa Claus. At 5 December, Sinterklaas brings presents to both children and adults. Some presents are also camouflaged in an imaginative way, accompanied by a fitting poem to make fun of the recipient.

This year I had to make a nice present for my father. The present contains a pocket-size book about wine. This is the end result after two weekends

The body consists of a soft-drink bottle and two small wooden planks. These planks form a cross which is nailed on the soft-drink bottle. The whole part has been wrapped with paper maché. The small book didn't fit entirely, resulting in the amazing booster effect below the wings

Additionally two pictures of the construction:

The present sticking out:

That was enough creativity for me this year.

Image speaking to a new developer. With excitement you tell about the debugging features of KMess. We've got a network output window, and lots, really lots of console output. The console is literally flooded with messages when you run the debug-build of KMess. This allows us to trace how KMess interacted with the protocol messages, how it parsed those and sent responses back.

Now imagine this new developer doesn't see anything of it.

That's an annoying way to become challenged as developer. First you start guessing where the output could be. SuSE has a nice ~/.xsession-errors file that contains the output of all GUI applications. However, the messages also didn't appear either when KMess was started from a console window. Googling gave no insight either. It started to feel something is really different in Fedora Core.

My next stop was kdebugdialog. This is a tool that allows you to turn off debug output in KDE, separated by application and message type. I guessed the output was disabled there, which seamed logical from an end-user perspective. After some inspection, the settings were identical to my SuSE system.

KMess uses standard kdDebug() calls to output the messages, so I sent a little C++ file that did the most basic thing possible. Eliminating compiler flags, and #ifdef statements we use to hide output:

#include <kdebug.h>

int main()
{
  kdDebug() << "test output" << endl;
  return 0;
}

Again, this simple test application gave no output on STDERR or whatsoever.

I seriously started to fear KDE was patched by the developers of Fedora Core. This could mean the developer would never see the output. Stephan Binner has a site of distributor patches, for which I can't thank him enough. Browsing the folders I found a patch on kdelibs/kdebug. Compare the original file with this patch, and notice how Fedora Core hides all output by default! arhg! This not only costs one or two hours of debugging, but it's even more annoying it isn't mentioned anywhere. A simple note would have been enough.

The code of the original file acted as a good reference to find a solution. By creating the file ~/.kde/share/config/kdebugrc with the following contents, the new developer got his debugging output:

[0]
InfoOutput=2
ErrorOutput=2

This extends the global configuration in $KDEDIR/share/config/kdebugrc, and outputs all messages to STDERR.

Needless to say, I'll propably disfavour distributor patches even more then I already did (i.e. how a Wine developer wasted his Sunday afternoon on debugging packaging problems, scroll to "another example"). When something needs to be patched, it's likely the upsteam software lacks some option, not an other patch. In the case of KDE this wasn't needed at all, kdebugdialog is available already. Guess it's time to file some bugs, and hoping this post helps a bit too.