Monthly Archives: October 2009

reportbug-ng has localization support again

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.

Amarok going downhill

Amarok 2.2 is probably the only audio application on the market unable connect properly to the IPod. It is impossible to copy podcasts within Amarok to the IPod since Amarok 2.x. This functionality simply disappeared during the 1.x to 2.x version jump. You can download and listen to podcasts, you can connect your IPod, but you cannot drag the podcast to the IPod.

A few weeks ago you could help yourself if you know where Amarok stores the podcasts (~/.kde/share/apps/amarok/podcasts): just navigate to this directory and drag the audio file to the IPod, but looks this rake was also disabled within the last versions, since Amarok now only segfaults if you dare to do this.


Python 2.6 Transition

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!

python-debianbts 1.0 uploaded to unstable

Today I was working all day on python-debianbts 1.0 and uploaded it to unstable a few minutes ago. This version breaks backwards compatibility with previous versions. I removed lots of unneeded old cruft like the HTMLStripper class needed ages ago when I was still using HTML instead of debbugs’ SOAP interface.

A new method get_usertag(email, *tags) was introduced. It returns a dict containing usertag-buglist mappings. If tags are given the dict is limited to matching tags, otherwise all available tags of the given user are returned:

In [1]: import debianbts as bts

In [2]: bts.get_usertag("")
{'dist-packages': [547838, 547832, ..., 547858],
 'dpmt-todo': [332913],
 'policy': [373301, 373302, ..., 377089],
 'python-oldnum': [478467, 478442, ..., 478441],
 'python2.1': [351108, 351110, ..., 351131],
 'python2.2': [351108, 351109, ..., 351161],
 'python2.6': [547838, 547832, ... 547858]}

In [3]: bts.get_usertag("", "python2.1", "python2.2")
{'python2.1': [351108, 351110, ..., 351131],
 'python2.2': [351108, 351109, ..., 351161]}

get_bug_log(nr) now returns a list of dicts with the keys: header (string), body (string), msg_num (int) and attachments (list). Before 1.0 it returned a list of Buglog objects.

The Bugreport class now supports every information provided by the SOAP interface. I tried to stay as close as possible to the data SOAP provides, so I renamed existing attributes (like which is not supported by SOAP but is now Bugreport.bug_num) and also added the quirky ones like: id and bug_nr, found and found_versions, keywords and tags, fixed and fixed_date which always seem to provide the same data.

Instead of the Bugreport.value() method which provided a number representing the openness (in terms of: open, closed and archived) and urgency (like: grave, important, …) to make bugreports sortable by their status, the Bugreport class now has a __cmp__ method which makes bugreports comparable. The more open and urgent a bug is, the greater it is. Openness always beats urgency (eg: an open whishlist bug is greater than a closed grave one).

While pre 1.0 versions of python-debianbts more or less served the needs of reportbug-ng, it now tries to stay as close as possible to the data provided by SOAP. As a result many parts of reportbug-ng had to be fixed for the new version. I hope this makes python-debianbts more attractive for other projects dealing with Debian’s bug tracker. As always: python-debianbts is on github and forks, patches or other kinds of collaboration are very welcome.

For the curious here a litte quickstart. it shows how to get all important bugs from reportbug-ng and prints out the bugnumber and summary:

# Get all important bugs of reportbug-ng (returns a list of integers)
bugnrlist = bts.get_bugs("package", "reportbug-ng", "severity", "important")

[548871, 439203, 542759]

# Get the actual bugreports (returns a list of Bugreport-objects)
bugs = bts.get_status(bugnrlist)

for bug in bugs: print bug.bug_num, bug.subject
542759 [reportbug-ng] Erroneously reports nothing or repeats previous package's report
439203 Doesn't give any explanations of the severities and what they mean
548871 reportbug-ng: does not check for newer versions before reporting a bug