Monday, February 12, 2007


In the true spirit of the lazy web, I'll put this out and see if anyone wants to take it up:

I'd like to improve kbugbuster to help with KDE bug triage. One of the main limitations at the moment is that it can only use the email interface to make changes, so that limits the app to closing bugs as FIXED, and very little else. So, what I want is a way to make any type of changes allowed by bugzilla. The only way I could find was to "fake" being a web browser by sending HTTP POSTs. But try as I might, I can't get it to work. Making comments or changes to bugs in the KDE bugzilla just POSTs the form data to the process_bug.cgi script, but whatever I try, I get strange errors from the server.

So, does anyone out there think they can do a better job of this? Ideally, I'd like to have C++ code using the KDE libraries to do this, but any kind of code would be fine - I can probably convert it to C++ if I can see exactly what's needed.

Monday, February 05, 2007

Guest blog!

So I'm playing at being a real blog writer, and having a guest blogger for this post. I guess Kurt Pfeifle needs no introduction, but here's some relevant info:

Kurt is a long-time KDE contributor, and living proof that you don't have to be a coder to have a real effect in improving KDE. He does a lot of work on the KDE Print system (just take a look at all the whatsthis help in the printing dialog), and has recently done a lot of work triaging kdeprint bug reports. He's currently working on the notorious problems with producing PDFs from KDE applications.

I need a bit of help from some Qt or KDE developer guru.

Here is the problem: an unknown-to-me (and escaping-my-tracing-attempts) process keeps writing into my qtrc setting file(s) one specific key value that I want to remain unchanged. I want it to remain "embedFonts=false" as long as *I* tell it so; but some alien thing reverts it to "embedFonts=true" after each and every time I printed something.

Here some more details about my qtrc problem.

I know of 2 GUI applications that write this specific setting, when a certain checkbox is enabled:

  • "kaddprinterwizard --kdeconfig"; select "Fonts"; enable "Embed fonts in PostScript data when printing"

  • "qtconfig"; select the "Printer" tab; activate "Enable Font Embedding"

The button "System Options" in kprinter does also start this same dialog ("kaddprinterwizard --kdeconfig".)

Here is what I do:

  • open a KWord document

  • start the print dialog

  • click button "System Options" (i.o.w.: "kaddprinterwizard --kdeconfig")

  • make sure fonts are *not* embedded; confirm

  • select the "Print to file (PDF)" printer

  • print it

Here is what happens:

  • Next time I want to print...

  • ...I start the print dialog...

  • ...I click button "System Options" (i.o.w.: "kaddprinterwizard --kdeconfig")...

  • ...and annoyingly, I find that in the meantime, font embedding has magically been re-enabled!

The file qtrc comes in different incarnations:

  • /etc/X11/qtrc (for system-level settings). This one is used, when root runs "qtconfig".

  • $HOME/.qt/qtrc (for user-level settings). This one is used, when user runs "qtconfig" or "kaddprinterwizard --kdeconfig".

I assume, the settings in $HOME/.qt/qtrc should override settings of the /etc/X11/qtrc file for a user.

I verified that my clicking/confirming the change in the KDEPrint GUI does indeed write into the qtrc file momentarily. But as I said, this gets again reverted by another process. I also manually edited the system-wide /etc/X11/qtrc file and made sure it had "embedFonts=false" when I saved it. The above described behavior still remained unchanged, and even that system wide /etc/X11/qtrc file got reset!

I don't know who or what does mess with my qtrc file(s) and who or what resets my configuration to something I do not want for now.

For now, as a temporary workaround, I have changed permissions to all qtrc files found on my system to "0444" (read-only for user, group and others). This now ensures that my darn "embedFonts=false" entry remains stable; but this hack obviously is not exactly what the doctor ordered, and may lead to other problems on other corners of the system which I currently am not aware of....

So here are my questions to you:

  • Does this happen on your system too? (Mine is a SUSE-10.0 with qt3-3.3.7-9.3 and KDE 3.5.5, *and* libqt4-4.2.2-2.1 *and* libqt4-qt3support-4.2.2-2.1... but in any case, Qt4 doesn't seem to use a qtrc file any more.)

  • How can I find out who/what is re-setting the qtrc file behind my back?

  • How do I get rid of that behavior???

Tuesday, January 09, 2007


Just a quick post to say that the Konqueror bug triage weekend was a huge success. Some highlights:

  • Getting the number of unconfirmed konqueror bugs (excluding wishes) down from over 950 to below 800.

  • Making konqueror green (ie, more bugs closed than opened) for the last 6 months. Of course, this builds on the great amount of hard work done over the longer term by the konqueror developers and other triagers, but as Adriaan would tell us, it's a nice metric.

  • mafitzpatrick's incredible testcase work. I don't know how he does it...

  • Kurt Pfeifle getting through all the khtml printing bugs

Of course, they weren't the only people working hard over the weekend - illogic-al, bram85 and logixoul did some great work co-ordinating the whole thing, and many more people checked, confirmed and otherwise triaged a lot of bugs. Thanks to all of them!

And some thoughts I had that we can try out next time:

  • Triage newer bugs instead of/as well as older bugs, since they're quite a different kettle of fish - easier in some ways, so nicer for people who haven't done triage before.

  • Make lists of bugs in one particular component, to aid in finding duplicates

  • Someone suggested we do KOffice next. Perhaps putting it here will help us remember :-)

The main bug weekend is over now, but if you want to get involved and help out with bug triage, just drop by in #kde-bugs on sometime.

Thursday, January 04, 2007

More bug triage!

We've got another bug triage extravaganza planned for this weekend, the 6th-7th. So if you're free and you feel like helping KDE, drop by #kde-bugs on for a bit - it's really easy, and all you need is a recent KDE installation. Some tips on bug triage can be found here.

Looking forward to seeing you there!

Friday, September 08, 2006


They said it couldn't be done[1], but we've got the number of unconfirmed Konqueror bugs (excluding wishlists) below 1000, from 1305 a couple of weeks ago:
Unconfirmed konq bugs.
There are also a huge bunch waiting for feedback ("Works for me. Does the bug still occur for you in KDE 3.5?") of which many, I suspect, will be closed in about a month.

1. OK, so no one actually said this, but it does look a daunting task...

Monday, August 28, 2006


Following a post on kde-devel about the number of UNCONFIRMED konqueror bugs, a few of us are going to try having a "konqueror bug triage day" this Wednesday, 30th Aug. We'll meet at 3pm UTC (10am CST, 5pm CET) in #konq-bugs on, and go on until whenever we like.

The aim is to sort through the bugs that have been reported, removing duplicates and bugs that are obsolete, so that the developers can spend their time fixing bugs instead of trawling through

We'd love to have more people to help, so whether or not you've done any bug triage before, please feel free to join us. All you'll need is a recent version of KDE (at least 3.5, but the newer the better), and a big of perseverance.

If you haven't done any bug triage before, you might like to
read these two pages to get an idea of what it involves:

Thursday, May 04, 2006

Let's go away for a while

Exams are looming, so it's time for my annual disappearance from all things KDE. If you need to get hold of me, I'll be checking my email (philip-rodrigues-at-chch-ox-ac-uk).