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

Re: finding out which version of a package a bug affects

On Wed, 21 Apr 2010, Robert Lemmen wrote:
> On Wed, Apr 21, 2010 at 10:19:44AM -0700, Don Armstrong wrote:
> > The raw data is rsyncable, but you should be using the soap interface
> > for everything. If there is something that the soap interface doesn't
> > do that you want to do, you should file a bug against debbugs
> > requesting a specific feature to be added.
> > 
> > There currently isn't a way to query the version graph using soap, but
> > in almost all cases, you actually don't want to do that. You should be
> > using the BTS's own routines to calculate whether a bug is buggy or
> > not instead of writing your own.
> > [snip]
> > Yes, but none of this is important. The BTS handles all of it for you.
> ok, perhaps i am missing something then. how do i query the bts to find
> out if package A in version V is affected by bug B?

get_status([bug=>nnn,version=>'yyy']); or similar.
> > > - in a similar manner, if i have only the "fixed" information,
> > >   all versions before that have to be considered affected?
> > 
> > No.
> but? it seems true for cases like #578032, but not for #577311.
> perhaps this doesn't really matter because there is a way to ask the
> bts whether a version is affected (see above), but just for my
> understanding: what does it mean if a bug has "fixed" but not
> "found"?

It means that versions which are ancestors (or otherwise out of the
path) are shown as 'absent'.

I'm not sure what's going on in the version graph of 578032, but it
doesn't look right to me. It's probably a mistake somewhere in the

Don Armstrong

My spelling ability, or rather the lack thereof, is one of the wonders
of the modern world.

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

Reply to: