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: "0x80004005
(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.