Question regarding debianbts' SOAP

[Bastian Venthur-3]

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@...>
source: xfree86, xorg, xorg-x11
ownwer:
location: archive
pending: done
found_date: []
originator: Sascha@...
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


--
To UNSUBSCRIBE, email to debian-debbugs-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Don Armstrong]

On Wed, 14 Oct 2009, Bastian Venthur wrote:
> 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

fixed and found are hashrefs which indicate when a bug was marked
fixed and found; currently that's not implemented, so they are
hashrefs which have a key of the version, and a value of ''.
Eventually I'll probably make it work, though.

fixed_versions and found_versions are arrayrefs which just have the
version that things are fixed and found in. It's probably what you
actually want.

> id and bug_num

These are the same; it's basically repeated because some things in the
code refer to a bug by id, and others by bug_num. I'm going to be
standardizing on bug_num, so if you can avoid using ID, that'd be
optimal.

> summary and subject -- here also: why is summary always empty?

It's not, actually. See
http://www.debian.org/Bugs/server-control#summary and FE:

$ bts status 441151|grep summary
summary It's already fixed in my tree and will be fixed in the BTS the next  time that I sync things up.

> 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.

Vice versa, actually. The version is the key, and the timestamp at
which the version was marked or the empty string is the value.


Don Armstrong

--
There is no more concentrated form of evil
than apathy.

http://www.donarmstrong.com              http://rzlab.ucr.edu


--
To UNSUBSCRIBE, email to debian-debbugs-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Bastian Venthur-3]

Don Armstrong schrieb:

> On Wed, 14 Oct 2009, Bastian Venthur wrote:
>> 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
>
> fixed and found are hashrefs which indicate when a bug was marked
> fixed and found; currently that's not implemented, so they are
> hashrefs which have a key of the version, and a value of ''.
> Eventually I'll probably make it work, though.
>
> fixed_versions and found_versions are arrayrefs which just have the
> version that things are fixed and found in. It's probably what you
> actually want.

So does that mean fixed_versions contains only *one* (the first) version
where the bug was fixed and fixed contains all versions? Then the name
fixed_version*s* would be a bit misleading (and also being an array :)
-- if not, again, what would the difference between fixed if fixed would
be implemented? Both should then contain all the versions where the bug
was/is fixed, right?

>
>> id and bug_num
>
> These are the same; it's basically repeated because some things in the
> code refer to a bug by id, and others by bug_num. I'm going to be
> standardizing on bug_num, so if you can avoid using ID, that'd be
> optimal.

Ok, then I just leave out id in future releases with reference to this mail.

>
>> summary and subject -- here also: why is summary always empty?
>
> It's not, actually. See
> http://www.debian.org/Bugs/server-control#summary and FE:
>
> $ bts status 441151|grep summary
> summary It's already fixed in my tree and will be fixed in the BTS the next  time that I sync things up.

Thanks!

>
>> 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.
>
> Vice versa, actually. The version is the key, and the timestamp at
> which the version was marked or the empty string is the value.

Ok, I'll have a look at it again from this direction.

One last question for now: This is the list of all attributes a
bugreport can have, could you quickly mark all those with an X which are
currently not correctly implemented (like fixed and found) or
superfluous like "id":

fixed_versions:
fixed:
fixed_date:
found_versions:
found:
found_date:
keywords:
tags:
subject:
summary:
source:
package:
done:
unarchived:
archived:
location:
id:
bug_num:
blockedby:
forwarded:
msgid:
ownwer:
originator:
date:
log_modified:
pending:
blocks:
mergedwith:
severity:
affects:


I will try to update http://wiki.debian.org/DebbugsSoapInterface upon
this data.


Thank you very much!

Bastian

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


--
To UNSUBSCRIBE, email to debian-debbugs-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Don Armstrong]

On Wed, 14 Oct 2009, Bastian Venthur wrote:

> Don Armstrong schrieb:
> > On Wed, 14 Oct 2009, Bastian Venthur wrote:
> >> 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
> >
> > fixed and found are hashrefs which indicate when a bug was marked
> > fixed and found; currently that's not implemented, so they are
> > hashrefs which have a key of the version, and a value of ''.
> > Eventually I'll probably make it work, though.
> >
> > fixed_versions and found_versions are arrayrefs which just have the
> > version that things are fixed and found in. It's probably what you
> > actually want.
>
> So does that mean fixed_versions contains only *one* (the first) version
> where the bug was fixed and fixed contains all versions? Then the name
> fixed_version*s* would be a bit misleading (and also being an array :)
> -- if not, again, what would the difference between fixed if fixed would
> be implemented? Both should then contain all the versions where the bug
> was/is fixed, right?

Nope; let me give an example which will make it clearer. At some point
in the future, it will look something like this:

{fixed_versions => ['1.0.1','1.0.2'],
 found_versions => ['1.0.0','1.0.1.1'],
 fixed => {'1.0.1' => 1255560307,
           '1.0.2' => 1255560321,
          },
 found => {'1.0.0' => 1255560137,
           '1.0.1.1' => 420620400,
          },
 ...
}



> One last question for now: This is the list of all attributes a
> bugreport can have, could you quickly mark all those with an X which
> are currently not correctly implemented (like fixed and found) or
> superfluous like "id":
>
> fixed_versions:
1 > fixed:
1 > fixed_date:
> found_versions:
1 > found:
1 > found_date:

> keywords:
> tags:
> subject:
> summary:
> source:
> package:
> done:
> unarchived:
> archived:
> location:

2 > id:

> bug_num:
> blockedby:
> forwarded:
> msgid:
> ownwer:
> originator:
> date:
> log_modified:
> pending:
> blocks:
> mergedwith:
> severity:
> affects:

id is superfluous; the fixed, fixed_date, found and found_date all go
together. [found_date contains the values for the keys in the found
array, same for fixed_date and fixed.]

> I will try to update http://wiki.debian.org/DebbugsSoapInterface
> upon this data.

It'd be ideal if you could work that into a writeup which was a patch
to the documentation of Debbugs::Status::get_bug_status and possibly
also the pod for Debbugs::SOAP.
 

Don Armstrong

--
Your village called.
They want their idiot back.
 -- xkcd http://xkcd.com/c23.html

http://www.donarmstrong.com              http://rzlab.ucr.edu


--
To UNSUBSCRIBE, email to debian-debbugs-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...