still don’t have a title

Today I finally found the reason why the table in reportbug-ng was not always sorted correctly. The fix was trivial and I’m happy it’s finally corrected. As announced last week, reportbug-ng now also can optionally hide closed bugs, which makes reportbug-ng together with the complex queries a great tool for finding easy NMU candidates.

To play around with those new features, I also did 5 lazy NMUs today. Most of them where fixes for FTBFS/RC bugs which had already a patch in the BTS.

Until today you could only use reportbug-ng to query the BTS with simple queries like “packagename”, “bugnumber”, “tag:patch”, etc. But the BTS actually supports composite queries like “severity:grave tag:patch” which returns bugreports with severity grave and a patch. The underlying Python library python-debianbts also supported this right from the start, but reportbug-ng did not make use of it.

Last weekend I finally had the time to fix that and the result is on it’s way to unstable.

Composite queries provide a very convenient way to find cheap NMU candidates: the query "severity:critical severity:grave severity:serious tag:patch" will return release critical bugs which have a patch. Now you can just go through this list, pick an open bug, test the patch and do what’s necessary to release Squeeze in time.

Next item on my list is an option to hide closed bugs, maybe next weekend.

If you’re using KDE and upgraded to Thunderbird 3 lately you might have the problem that links in emails don’t open in a browser anymore. For my case that happened even without a user visible error message.

If that sounds familiar for you, check the error console (Tools/Error-Console). If there is an error like:

Error: uncaught exception: [Exception... "Component returned failure
code: 0x80004005 (NS_ERROR_FAILURE)
[nsIExternalProtocolService.loadUrl]”  nsresult: “0×80004005
(NS_ERROR_FAILURE)”  location: “JS frame ::
chrome://communicator/content/contentAreaClick.js :: openLinkExternally
:: line 188″  data: no]

Then Thunderbird just (silently) fails to launch the browser. Guido pointed me to gconftool. gconftool -R / | grep url-handlers told me that some components of gnome still had Firefox configured as http-handler (which is strange since it was rebranded to iceweasel ages ago). Resetting them solved the problem for me.

The sad part of the story: x-www-browser, sensible-browser and KDE’s http handler where all correctly configured and pointed to iceweasel. All applications behaved correctly only Icedove used a (for me) hidden setting pointing to firefox.

Dear Lazyweb,

since yesterday’s daily update, my laptop runs really sluggish. Is there a way to list all packages which where updated or installed yesterday to track down the problem?

Git bisect, ccache and cowbuilder: a combination made in heaven! Tracking down a commit which introduced an ugly bug with those tools was a breeze.

Git bisect is very useful finding a commit which introduced a bug very quickly, ccache massively reduces compiling time. Compiling icedove (thunderbird) on my laptop using cowbuilder takes roughly 30 minutes. Using cowbuilder with ccache, it only takes 10 minutes, where most of the time is spent setting up the build environment.

Funny coincidence that David writes how well Linux and Printers go together for 12 years, while it is apparently impossible to print something with CUPS in unstable since a week

Looking at the sorry state of Python in Debian, makes me wonder if we shouldn’t enforce team maintainance of packages above a certain popularity/importance/whatever threshold. People worked hard in the last months to fix any bugs that would prevent Python2.6 to land in unstable and yet nothing happens. Time passes by and we will eventually end up with Squeeze having a horribly outdated Python version.

Today’s work: 5 lazy NMUs (thanks again Kumar). Leaves us with only five open python2.6 blockers to fix and a whopping 62 of closed ones.

After having ported reportbug-ng from PyQt3 to PyQt4 over a year ago, reportbug-ng lost it’s localization, since the gettext based translations where incompatible with Qt4’s translation system.

This weekend I finally had the time to have a closer look at this problem. To make a long story short: I have ported the gettext based system to Qt4’s system. All the old .po files where converted to .ts files, but almost all strings are marked as “obsolete” so that they don’t appear in the translated program. But since they are still available in the .ts file, it is easy to get the translations up-to-date. So far only English and German are complete, but eventually other translations will be added.

PyQt4 makes it by the way really hard to get non-Qt strings translated.

Today I NMUed over a dozen of Python packages with bugs which blocked the Python 2.6 transition.

I really want to thank Kumar Appaiah for his work. He provided patches for all the bugs I NMUed today and lots more. I really did not much more than applying, testing and uploading his patches, but Kumar probably invested days of labor to create the patches and test them. Thanks to his effort, the number of 2.6-blockers shrinked considerably so that we now have like ~15 open blockers and ~50 closed ones!