Tag Archives: python-debianbts

Debconf: Day 2

Second day in the big city and after the obligatory pancakes, scrambled eggs and bacon breakfast, I spend almost the entire day in the hacklab fixing the documentation for the debbugs SOAP interface. Thanks to Don I think I finally have the get_status part at an accurate state. Accordingly I was very busy making changes in python-debianbts which uses the SOAP interface to query the BTS. Some Bugreport attributes disappeared, others got their data type fixed, Unittests where added and docstrings updated. Finally I uploaded the new version to unstable.

Between that mess I met a lot of nice people, and heard a talk whose slides consisted almost entirely of lolcat images — which was of course awesome! I definitively have to try that in one of my next scientific talks.

Hopefully tomorrow I’ll find some time to actually prepare my talk.

Reportbug-ng now supports complex queries

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.

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("debian-python@lists.debian.org")
{'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("debian-python@lists.debian.org", "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 Bugreport.nr 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

Please help to complete python-debianbts

I’m currently working on an updated version of python-debianbts a Python interface to Debian’s Bugtracker. The goal is to equip the Bugreport class with all available attributes delivered by the SOAP interface. The problem is, that for some attributes it is not quite clear what data they provide and in which datatype they are wrapped. For example the mergedwith attribute should be a list of bugnumbers, but it seems to be a single Integer when merged with one bug and an empty String when the bug is not merged at all. Some attributes have an ambiguous name and it’s hard to guess what they mean, for example there is an id and a bug_nr and both seem to contain the same information.

There is a git branch for this task and a wiki page collecting all available information. If you have some experience with SOAP, our BTS and some time to kill, your help would be appreciated.