[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Question regarding debianbts' SOAP



I sent this mail to Don this morning but I think I should have sent it
to this list instead. Sorry Don!

Hi Don,

I'm trying my best to parse the SOAP replies provided by debbugs, but
now I'm kind of stucked.

A general and probably very easy question first: what is the difference
between:

fixed_versions and fixed
found_versions and found
id and bug_num
summary and subject -- here also: why is summary always empty?

Usually (always?) they seem to contain the same values.


Here a small example of a Bugreport as I currently "see" it:

fixed_versions: []
blockedby:
done: True
unarchived: False
keywords: []
id: 112233
subject: /tmp/.X11-unix created with "suspicious ownership"
archived: True
forwarded:
bug_num: 112233
msgid: <20010914150808.A1007@cube.sascha.silbe.org>
source: xfree86, xorg, xorg-x11
ownwer:
location: archive
pending: done
found_date: []
originator: Sascha@silbe.org
blocks:
tags: []
date: 2001-09-14 13:18:01
mergedwith:
severity: important
package: xserver-xfree86
summary:
log_modified: 2001-09-14 20:48:08
fixed_date: []
found_versions: [u'4.1.0-5']
affects:
found: [u'4.1.0-5']
fixed: []


The second and currently most urgent question: Some fields like "found"
are very hard to parse. Usually found is a dictionary (pardon my Python
:) containing a key "item" which contains a single or a list of
dictionaries containing a "key" key which has the version as value. So
far so good. Bug I encountered at least two different things so far:

1. Sometimes "item" has only an empty string as value.
2. Sometimes the innermost dictionary don't contain a "key" key I'd
expect but some interesting key like "please".

Here an normal example:

debianbts.server.get_status(112233)
[...]
'found': <SOAPpy.Types.structType found at 156909964>:
	{'item': <SOAPpy.Types.structType item at 156910924>:
		{'value': None, 'key': '4.1.0-5'}
	},

Here an interesting one #426378:

'found': <SOAPpy.Types.structType found at 156910668>:
	{'please': None},

Note also how the wrapping "item" dictionary is missing. The
found_versions contains a list with a single item "please".

Related to this question: in both cases the found_versions just
contained plain lists with the versions as strings. Very easy to parse.
Again, why the difference between found and found_versions and why is
found so hard to parse? Or better what should found contain?

The same goes probably for "fixed".


Cheers,

Bastian


-- 
Bastian Venthur                                      http://venthur.de
Debian Developer                                 venthur at debian org


Reply to: