Tag Archives: python-debianbts


Two months ago I asked for help porting python-debianbts, to Python3. Python-debianbts is a tiny little library that allows for querying Debian’s bug tracking system. Since Debian’s reportbug depends on it, the library is installed on ca 80% of the Debian installations. The main blocker back then was that python-debianbts depended on SOAPpy which was not available for Python3. So before we could port python-debianbts to Python3 we had to migrate from SOAPpy to pysimplesoap — a daunting task given the beast that SOAP is.

Fortunately, Gaetano Guerriero heard my call and helped a lot. First he migrated python-debianbts to pysimplesoap. Then, he ported python-debianbts to Python3 and now he is still busy fixing bugs and providing me with pull requests. I’m very satisfied with the outcome. His pull requests are very high-quality and come usually with the appropriate unit tests included. While he is doing the major grunt work, I merely do some occasional nitpicking and uploading to Debian/unstable.

Thank you very much Gaetano! If you ever come to Berlin, please drop me a note so I can invite you to a beer or two.

Please Help to Port python-debianbts to Python3

Dear Lazyweb,

I’m currently trying to find a way to port python-debianbts to Python3. Debian’s standard bugreport tool reportbug depends on python-debianbts and can thus not convert to Python3 if python-debianbts does not as well. Unfortunately python-debianbts depends on SoapPy for parsing the Debian bugtracker’s responses, and that library is not ported to Python3 yet, and probably never will.

I’m planning to replace SoapPy with pysimplesoap which is available for Python2 and Python3. Unfortunately debbugs does not support WSDL which makes parsing of the replies extremely painful and error-prone. I wonder if there is a  SOAP/Python expert out there who’d be willing to give some assistance in porting python-reportbug to pysimplesoap? python-reportbug’s repository is on GitHub and patches are very welcome.

Since SOAP is quite a beast and debbugs uses it for read-only purposes only, another attractive solution would be to replace/augment debbugs’ API with something much more simple, like JSON. That would make parsing extremely easy as many programming languages including Python support JSON without any external libraries. In theory this could be quite easy but requires some serious Perl skills.

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.