Nabble - debian-debbugs

Re: how to get the last modified timestamp of a given bug?

2009-11-30T12:33:36Z

On Sun, Nov 29, 2009 at 08:30:50PM -0800, Don Armstrong wrote [edited]:
> $ bts status 400000|grep modified

Thanks!

I'm embarrassed by the simplicity of the answer, but it wasn't really obvious
by looking up the manpage.

ps. please cc me on replies

--
debtags-organised WNPP bugs: http://members.hellug.gr/serzan/wnpp

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

Re: how to get the last modified timestamp of a given bug?

2009-11-29T20:30:50Z

On Sun, 29 Nov 2009, Serafeim Zanikolas wrote:
> I need to be able to get the timestamp of the latest change in a
> given bug (last modified).

[...]

> Is there a proper way, or shall I just parse the related web pages?

Use the SOAP interface. Call get_status, and see the last_modified
record returned. For example:

$ bts status 400000|grep modified
log_modified 1182672172
last_modified 1182672172

Don Armstrong

--
[The] JK-88 [coffee] percolator is capable of acheiving the ultimate
balance of aroma and density, aftertaste and emollience, pentosans and
tannins. The next step is to reduce the cost of the HPLC-E technology
to the point where it can be manufactured for less than the cost of a
Boeing 757.
-- Charles Stross "Extracts from the Club Diary" in _Toast_ p83-4

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

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

how to get the last modified timestamp of a given bug?

2009-11-29T09:03:35Z

Hi,

As part of a patch for maintainers-needed.pl (the scripts that sends the
weekly WNPP report to -devel), I need to be able to get the timestamp of the
latest change in a given bug (last modified).

The script's main source of data is the output of
/org/qa.debian.org/data/bts/bts2ldap-filter (which consumes
/org/qa.debian.org/data/bts2ldap/fullindex). The only timestamp I can get is
that of the bug creation (called debbugsDate in the fullindex file, and
``time'' in Debbugs.pm).

Is there a proper way, or shall I just parse the related web pages? FYI this
is for a small number of bugs (it's for closed RFA/O bugs), and I'll try to
use caching anyway.

Cheers,
Serafeim

ps. please CC me as I'm not subscribed on this list

--
debtags-organised WNPP bugs: http://members.hellug.gr/serzan/wnpp

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

[Future Icon Records] You've been added to our mailing list.

2009-11-28T19:57:04Z

Hi I represent KONVICT MUSIC recording artist COLBY O'DONIS <br/>(Just Dance Ft Colby O'Donis. Beautiful Ft Colby O'Donis) <br/>and we want to share with you His first Original<br/>Christmas song <br/> <br/>I made a radio edit of so happy <br/>here it is if you like it<br/>Radio Edit Of - So Happy<br/>https://rcpt.yousendit.com/782608652/9a8972b464bfc006aa5139a89722060d<br/> <br/>Instrumental Radio Edit - So Happy<br/>https://rcpt.yousendit.com/782608822/4c2efde9129f9900fe9782387ef48410<br/>

--------
Get your free download from Future Icon Records here: http://fburls.com/23-XCHTAF5f
--------

You have been added to the Future Icon Records fan list!

If you would like to verify your info or add more to your fan profile, you can do so by clicking on the following link:

http://www.FanBridge.com/signup/fansignup.php?userid=129853&email=debian-debbugs@...&confCode=Bra417BK1K4YUBd1hXFr7F997r

--
This list is powered by FanBridge, the world's leading provider of fan relationship management services for artists.

With FanBridge your information is always secure.

For more information about FanBridge please visit http://www.FanBridge.com/learn/
--

***Important: Please be sure to add the email address (futureiconrecords@...) to your safe senders list.***

Here's how:

Gmail
1. Click Contacts along the left side of any Gmail page.
2. Click Add Contact.
3. In the primary email address box, type futureiconrecords@....
4. Click Save.

AOL (version 9.0 or higher)
1. Click the Mail menu and select Address Book.
2. In the pop up box, click the Add button.
3. In the "Other E-Mail" field, type futureiconrecords@....
4. Make our From address the "Primary E-Mail" address by checking the associated check box.
5. Click the Save button.

AOL 8.0
1. Open this confirmation email.
2. Click Add Address.
3. Verify the sender's contact information (futureiconrecords@...).
4. Click Save.

Yahoo!
1. Click the "addresses" button
2. Select "Add Contact"
3. Save the futureiconrecords@... to your contacts list.

Hotmail
1. Click Options.
2. On the left side of the page, click Mail, and then click Junk E-Mail Protection.
3. Click Safe List.
4. Type futureiconrecords@..., and then click Add.

Outlook
1. Right-click on a message from futureiconrecords@....
2. Point to Junk E-mail, and click Add Sender to Safe Senders List.

----------------------------------------
Future Icon Records sent this email to debian-debbugs@...
Questions? Contact futureiconrecords@... or Future Icon Records, c/o FanBridge, Inc. - 14525 SW Millikan Way, #16910, Beaverton, Oregon 97005, United States

Update Your Information - http://fburls.com/58-R7BWs6ID
Forward to a friend - http://fburls.com/98-eu5cD8CD
Unsubscribe - http://fburls.com/12-gwGnrxF5
Privacy Policy - http://www.FanBridge.com/learn/privacy.php

This email message is powered by FanBridge:
http://www.FanBridge.com/b.php?id=129853
Powering Valuable Fan Relationships

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

Bug#558380: SOAP: Please add 'pending' per version (possible optional)

2009-11-28T05:04:47Z

Package: debbugs
Severity: wishlist

Hi,

I need the "pending" information for each package version seperate.
Currently I do this with asking all package versions in testing and
unstable, but it would be way more efficient if get_status could
(perhaps optionally) not only give the final "pending" state, but
rather for each package version.

Speaking in code (s is my soap handler)
st = s.get_status(bug)
stt = st[0][1]
for version in packageversions(stt['package']):
p=s.get_status(('bug', bug, 'version', version))
# do something with stt['package', ...], version, p[0][1]['pending']

I would prefer:
st = s.get_status(('bug', bug, 'pendingforsuite', ['testing', 'unstable']))
stt = st[0][1]
for version in stt['pending_per_version']:
# do something with stt['package', ...], version, stt['pending_per_version'][version]

Would be great if that could be added there.

Cheers,
Andi

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

Bug#558379: SOAP: Please allow to restrict get_bugs to certain suites

2009-11-28T04:58:06Z

Package: debbugs
Severity: wishlist

Hi,

I'd like to make the following question via soap:
(handler).get_bugs('severity', ['serious', 'grave', 'critical'], 'distribution', ['testing', 'unstable']))

However, this currently doesn't work, so I have to ask for
(handler).get_bugs('severity', ['serious', 'grave', 'critical'])
and get rid of the remaining bugs later on (which just costs computing
power, but also on bugs.debian.org as I'm doing useless questions
there).

Would be great if that could be added there.

Cheers,
Andi

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

Bug#556863: bugs.debian.org: can't search with a usertag and a maintainer

2009-11-17T22:44:52Z

On mar., 2009-11-17 at 15:07 -0800, Don Armstrong wrote:
> reassign 556863 debbugs
> retitle 556863 bugs assigned to a source package not searched properly
> when searching by maintainer
> thanks
>
>
> The issue is that bugs assigned to the source package aren't being
> searched properly by maintainer.

Ha, thanks for investigating :)

Cheers,
--
Yves-Alexis

signature.asc (205 bytes) Download Attachment

Processed: Re: Bug#556863: bugs.debian.org: can't search with a usertag and a maintainer

2009-11-17T15:12:08Z

Processing commands for control@...:

> reassign 556863 debbugs
Bug #556863 [bugs.debian.org] bugs.debian.org: can't search with a usertag and a maintainer
Bug reassigned from package 'bugs.debian.org' to 'debbugs'.
> retitle 556863 bugs assigned to a source package not searched properly when searching by maintainer
Bug #556863 [debbugs] bugs.debian.org: can't search with a usertag and a maintainer
Changed Bug title to 'bugs assigned to a source package not searched properly when searching by maintainer' from 'bugs.debian.org: can't search with a usertag and a maintainer'
> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

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

Bug#556863: bugs.debian.org: can't search with a usertag and a maintainer

2009-11-17T15:07:42Z

reassign 556863 debbugs
retitle 556863 bugs assigned to a source package not searched properly when searching by maintainer
thanks

The issue is that bugs assigned to the source package aren't being
searched properly by maintainer.

Don Armstrong

--
When I was a kid I used to pray every night for a new bicycle. Then I
realized that the Lord doesn't work that way so I stole one and asked
Him to forgive me.
-- Emo Philips.

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

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

Bug#556629: In submitter acknowledgement mail, attach original message

2009-11-17T00:44:22Z

Package: debbugs
Severity: wishlist

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

just a small convenience-increasing suggestion:

Often, after I have submitted a new bug, I want to add more information
to it. The bts sends me a mail with a Reply-To: set to the new bug
address (“Thank you for filing a new Bug report with Debian...”), but it
does not contain anything of my report that I can use for quoting.

In case I have set the X-List-CC header to a mailing list that I
receive, I would find a mail there with a proper Reply-To:-header and
with my text available for useful quoting, which I’d prefer.

How about attaching the mail that is sent to the package maintainer and
possible X-List-CC-receipients also as an attached message to the
Submitter acknowledgement mail? This would allow for easy follow up with
good quoting and threading.

Additionally, for those of us submitters using reportbug (probably the
majority), it would put us our mail in our mailbox, for personal
archival and storage reasons, which is slightly more useful than the BCC
sent by reportbug, as you can use it later to reply to.

The only problem I see is the additional traffic generated by large
attachements.

Greetings,
Joachim

- -- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.31-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAksCYmUACgkQ9ijrk0dDIGzy0QCcCTM4q03seDgYGDNhl8/d7U/R
rLIAoIj6N+fEpZCO9oxBG+ZwCIE+8z2X
=I0gD
-----END PGP SIGNATURE-----

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

Processed: debbugs: Please add a comaint option, like on, http://qa.debian.org/developer.php

2009-11-15T08:33:06Z

Processing commands for control@...:

> block 485803 by 120262
Bug #485803 [debbugs] debbugs: Please add a comaint option, like on http://qa.debian.org/developer.php
Was blocked by: 120262
Ignoring request to alter blocking bugs of bug #485803 to the same blocks previously set
> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

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

Processed: Bug #120262: ftp.debian.org: create a file containing Uploaders information

2009-11-15T08:33:05Z

Processing commands for control@...:

> block 485803 by 120262
Bug #485803 [debbugs] debbugs: Please add a comaint option, like on http://qa.debian.org/developer.php
Was not blocked by any bugs.
Added blocking bug(s) of 485803: 120262
> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

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

Bug#555023: debbugs: src: bugs should be displayed on the binary package of the same name

2009-11-07T17:38:12Z

Package: debbugs
Version: 2.4.1
Severity: minor

Hi,

Since the last big update bugs filed with Source: <package> do no longer show
up on the bugs list of <package> even when there's only one binary package
and both, source and binary, package names match.

I got hit by this change and I think it either needs to be clearly documented
(together with some visual feedback on the BTS pages) or some other solution
implemented (like the one I'm using on the subject).

Cheers,
--
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net

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

questions about computer to computer usb file transfer for linux Debian

2009-11-06T08:15:46Z

Hello

Can you referer me to Debian help for
Computer to Computer linux usb file transfer

thank you

Dave

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

Processed: reassign 553591 to debbugs

2009-11-01T22:36:12Z

Processing commands for control@...:

> reassign 553591 debbugs
Bug #553591 [bugs.debian.org] allow voting for bugs
Bug reassigned from package 'bugs.debian.org' to 'debbugs'.
>
End of message, stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

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

Processed: Re: Bug#553661: bugs.debian.org: provide some way through the SOAP interface to determine if a package exists

2009-11-01T15:45:18Z

Processing commands for control@...:

> reassign 553661 debbugs
Bug #553661 [bugs.debian.org] bugs.debian.org: provide some way through the SOAP interface to determine if a package exists
Bug reassigned from package 'bugs.debian.org' to 'debbugs'.
> retitle 553661 expose Debbugs::Common::package_maintainer via soap
Bug #553661 [debbugs] bugs.debian.org: provide some way through the SOAP interface to determine if a package exists
Changed Bug title to 'expose Debbugs::Common::package_maintainer via soap' from 'bugs.debian.org: provide some way through the SOAP interface to determine if a package exists'
> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

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

Bug#153536: but not as often

2009-10-31T03:11:24Z

were little boats
http://elomynejyr.100megsfree5.com/cowyja.html

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

land in portugal

2009-10-27T17:14:47Z

I got a land in Portugal that cost £140:000 In North of Portugal for sale. You can do 4-8 houses or apartments included swimming pool. And pass to your friends if you think they might be interested. And in Portugal you don’t pay council tax etc…..

If you are interested or you want more information: Please email: Daniela_bbe_@...

Many thanks.

Fwd: Fw: This may help someone...

2009-10-19T04:35:19Z

Fwd: Fw: This may help someone...

Original message for debian-debbugs@...

Wising you a Happy Diwali....

I got the mail below from a friend of mine and following the unwritten code of conduct, I am forwarding it to my friends but all efforts of people who have been forwarding this mail would go waste if this mail doesn't reach YOU......

We have an updated database of 7000 of India's leading journalists. (TV
and print)
This email database maintained and updated as of 30th June'2009
contains the following details:-

1. Name 2. Office email id: @dnaindia.net etc. and/or Personal email id:
(@yahoo/gmail etc) 3. Media Name/(Hindu etc.) 4. City (New Delhi etc.)
Maintained in Microsoft Excel Format and YOU will not find it anywhere
else.

Includes senior and middle level journalists with leading newspapers,
television channels, business press and magazines. e.g . ToI, IE,
Outlook, Business Today, NDTV etc. Includes VS (HT), BK (ToI), RS
(CNN-IBN) and PC (Aaj Tak) among 7000 others.
Can be imported into all email merge software for personalised sending.

You ARE going to use it for blasting Press Releases, new product
announcements,corporate briefs or press conferences to these 7000
public opinion moulders.

We would like to sell this CLICKING database to you.

If interested, to receive a no-obligatory, sample list of 100 from our
master database of 7000 pls reply blank email
media.database.2009@... with
SEND100_15oCt09* in the Subject.
the "answer" now lies in your hands........

regards,

customer support

*case sensitive - read autoreply to this blank email as it will contain instructions to download your sample database of 100

If not interested pls forward to YOUR cmd/head of Corporate
Communications or PR agency/PR industry contacts who may be interested
in this database.

REPLY validity of this offer: Valid for all responses received

Kindly BUTTON up this offer immediately...
It's NOW.

The early birds get the fruits.

spell check test:
PRESSURE ON MAO'S SON TO MEET THE PM AND REPLY HIS LINK TO TIBET NOW.

We follow the American Government regulations on spam which states that any mail containing removal instructions and containing phone number of the sender is not spam.- do not forget to read autoreply to your blank email ( as it will contain instructions to download your sample database of 100 SEND100_15oCt09*)
To opt out pls blank email customer.support.global@... with NoSuB_iDaY_1009* You will never receive any email from us if you choose to opt out, as you will be automatically removed.

*extremely case sensitive

Re: Question regarding debianbts' SOAP

2009-10-14T15:49:09Z

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

Re: Question regarding debianbts' SOAP

2009-10-14T14:22:54Z

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

Re: Question regarding debianbts' SOAP

2009-10-14T13:54:22Z

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

Question regarding debianbts' SOAP

2009-10-14T07:44:44Z

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

Bug#162486: Don't waste time waiting for the delivery of software CD.

2009-10-09T11:32:49Z

Perfectly working software for Windows and Mac in many European languages can be purchased from our site. Just try and you will appreciate the service and prices.

Original software only.

http://groups.yahoo.com/group/wicyqekulidavybyhu/message/1

The Summer Sale promo gives you 30% discount on
ALL software available at the Our Software Store.

Use CODE: D33W-1234 for 30% discount

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

Bug#162486: Worldwide delivery instantly to your home

2009-10-09T09:27:31Z

Girls don't like you ?
We have a solution !
U can restore your health just right now .
Simple way to enhance your sexual life .
Fast-acting sexual boost pills

http://groups.yahoo.com/group/nekerypyhybotycato/message/1

Perfect service, instant delivery, friendly support

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

Bug#173970: Failed to find necessary software in English?

2009-10-07T19:49:17Z

Perfectly working software for Windows and Mac in many European languages can be purchased from our site. Just try and you will appreciate the service and prices.

Great selection of applications.

http://groups.yahoo.com/group/jarijybukuligypeca/message/1

The Summer Sale promo gives you 30% discount on
ALL software available at the Our Software Store.

Use CODE: D33W-1234 for 30% discount

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

Bug#549439: pkgreport.cgi - internal server errors when using include= parameter

2009-10-05T11:39:26Z

On Tue, 6 Oct 2009, Don Armstrong wrote:

>> Ah. Lovely! Well hidden, but then all the more rewarding when found.
>> I do still think it would be useful to show them in the bug when it is
>> fully displayed.
>
> They are supposed to be; it's just a small bug that caused them not to
> be, which (as I've said), I'll be fixing sometime later.

oh, sorry. I misparsed your previous reply. It's too late here...

Vince

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

Bug#549439: pkgreport.cgi - internal server errors when using include= parameter

2009-10-05T11:33:30Z

On Tue, 06 Oct 2009, Vincent.McIntyre@... wrote:
> >They're actually in the information for each bug, too. If you click on
> >the [i|N|ÿÿ] bits, you'll see them.
>
> Ah. Lovely! Well hidden, but then all the more rewarding when found.
> I do still think it would be useful to show them in the bug when it is
> fully displayed.

They are supposed to be; it's just a small bug that caused them not to
be, which (as I've said), I'll be fixing sometime later.

Don Armstrong

--
If it jams, force it. If it breaks, it needed replacing anyway.
-- Lowery's Law

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

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

Bug#549439: pkgreport.cgi - internal server errors when using include= parameter

2009-10-05T11:05:01Z

>
> They're actually in the information for each bug, too. If you click on
> the [i|N|ÿÿ] bits, you'll see them.

Ah. Lovely! Well hidden, but then all the more rewarding when found.
I do still think it would be useful to show them in the bug when it is
fully displayed.

Cheers
Vince

Bug#549439: pkgreport.cgi - internal server errors when using include= parameter

2009-10-05T10:55:16Z

On Mon, 05 Oct 2009, Vincent.McIntyre@... wrote:
> It's, erm, subtle. Which is fine. I do think it would help to use
> some slightly different formatting of the usertags' text, but
> looking at common.pl:htmlizebugs() I can see that this might be
> difficult to arrange; it's not obvious by that stage of execution
> which part of header string is tag text.

They're actually in the information for each bug, too. If you click on
the [i|N|☺] bits, you'll see them.

[It's a bug that the bugreport.cgi script errors out, which, as I
mentioned previously, has been fixed in my branch and will be deployed
shortly.]

Don Armstrong

--
We must realize that today's Establishment is the New George III.
Whether it will continue to adhere to his tactics, we do not know. If
it does, the redress, honored in tradition, is also revolution.
-- William O. Douglas _Points of Rebellion_

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

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

Bug#549439: pkgreport.cgi - internal server errors when using include= parameter

2009-10-04T23:57:36Z

you're more patient than I realised.

>>> One thing I have been trying to figure out is how to get the
>>> usertags defined for a given bug report to be displayed in the
>>> browser.
>>
>> If you give the user in the users field, they're displayed as if they
>> were actual tags.
>
> Really? I mean here when I am looking at one particular bug, eg the url
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=214790
> This is the first hit in the general search for usertags
> http://bugs.debian.org/cgi-bin/bugreport.cgi?users=debian-boot@...
> so it would seem there should be usertags to show.
> Yet I can't see any usertags in the display of the individual bug.

I looked carefully again at the output of the general search

> http://bugs.debian.org/cgi-bin/bugreport.cgi?users=debian-boot@...

and *finally* saw where the tags are displayed;
appended to the 'table of contents' links, and at the top of each
sublist.
It's, erm, subtle. Which is fine. I do think it would help to use some
slightly different formatting of the usertags' text, but looking at
common.pl:htmlizebugs() I can see that this might be difficult to arrange;
it's not obvious by that stage of execution which part of header string is
tag text.

So from this display I can conclude that bug #214790 has at least one
usertag, 'not-di'. Correct?

It still would be useful to have the usertags shown in the display of
the individual bug. For one thing, I guess that if there are multiple
usertags on a bug (eg i386,serial) only one of them is used to determine
which subgroup the bug is shown in (the first one that was added?).
I think it would be helpful to show all of them in the display of the
individual bug.

Kind Regards
Vince

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

Processed: Re: Bug#549439: pkgreport.cgi - internal server errors when using include= parameter

2009-10-04T23:15:09Z

Processing commands for control@...:

> clone 549439 -1
Bug#549439: more informative error messages for invalid urls
Bug 549439 cloned as bug 549631.

> retitle -1 propogate users= cgi option to further queries in pkgreport.cgi
Bug #549631 [debbugs] more informative error messages for invalid urls
Changed Bug title to 'propogate users= cgi option to further queries in pkgreport.cgi' from 'more informative error messages for invalid urls'
> clone 549439 -2
Bug#549439: more informative error messages for invalid urls
Bug 549439 cloned as bug 549632.

> retitle -2 some include options screw up the summary counts in pkgreport.cgi
Bug #549632 [debbugs] more informative error messages for invalid urls
Changed Bug title to 'some include options screw up the summary counts in pkgreport.cgi' from 'more informative error messages for invalid urls'
> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

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

Bug#549439: pkgreport.cgi - internal server errors when using include= parameter

2009-10-04T23:06:16Z

clone 549439 -1
retitle -1 propogate users= cgi option to further queries in pkgreport.cgi
clone 549439 -2
retitle -2 some include options screw up the summary counts in pkgreport.cgi
thanks

On Mon, 05 Oct 2009, Vincent.McIntyre@... wrote:
> sure, I realised I could use that method. However I was interested
> to check whether for example this URL (taken from [1]) would/could
> ever work:
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=debian-boot@...;include=alpha
> which amounts to wondering what the include= keyword does for you.

I don't know who wrote that url, but presumably what they were
actually looking for was
http://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=debian-boot@...;include=tags:alpha

> What form would be most useful?
> A distinct file or a patch to e.g. [2]?

It actually will have to be entirely new html documentation, ideally
written in wml against the web pages, which you can see in the webwml
CVS repository for the Debian website. The documentation in 2 is
really outdated, and I haven't been keeping it up to date.

> I tried the obvious
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=214790;users=debian-boot@...
> and got a 500 error.

This is the right query; there was a bug which I've fixed in my source
copy, which will be fixed when I next merge my changes.

> >It actually already does that at the top of the display:
>
> Ah. I am pretty sure it wasn't doing that for me before, when I started
> asking all these dumb questions. I tried again just now, and got the
> list of tags. Yay. Have you updated the running code in between?

Nope.

> So now I think I am starting to get this. Then I tried:
>
> lynx -mime_header -source
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=alpha;users=debian-boot@...
>
> and got the attached file (pkgreport.cgi.usertag.test1.txt).
>
> I see the Summary and the Options sections but no, er, bug numbers listed.
> Yet the Summary says there are bugs to display.

I'm not sure what the deal is with this; I'd have to look more
carefully.

> If I do the obvious thing and hit the 'submit' button on the displayed
> page, the URL changes to
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=alpha
> and I get "No reports found!".

That's because the alpha tag is a user tag, and the url doesn't
include the users= option any more. I need to fix this, but I haven't
had a chance yet; cloned out as a sepearate bug.

Don Armstrong

--
We were at a chinese resturant.
He was yelling at the waitress because there was a typo in his fortune
cookie.
-- hugh http://www.gapingvoid.com/Moveable_Type/archives/000321.html

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

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

Bug#549439: pkgreport.cgi - internal server errors when using include= parameter

2009-10-04T22:31:44Z

Thanks for your patient answers.

>> I am experimenting with pulling out groups of bugs using usertags.
>> Specifically I was attempting to make some of the urls in [2], that
>> claim to pull out arch-specific bugs, actually work.
>
> Assuming the architecture specific bits are done by usertags that are
> against the debian-boot@... user, you can just do the
> following:
>
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=debian-boot@...;tag=amd64;users=debian-boot@...

sure, I realised I could use that method. However I was interested to
check whether for example this URL (taken from [1]) would/could ever work:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=debian-boot@...;include=alpha
which amounts to wondering what the include= keyword does for you.

>> I can't find any documentation for how to construct such URLs more
>> advanced than setting users= and tag= in the URL. Reading the source
>> of pkgreport.cgi[3] suggests not much of the vision actually ended
>> up getting implemented, but I am having trouble following the code.
>
> The only bit that isn't implemented is the ability to enter users= and
> other bits in the url selection at the bottom.

ok, that helps quite a bit.

>> I'm happy to help write something that documents the current
>> functionality.
>
> That'd be great.

What form would be most useful?
A distinct file or a patch to e.g. [2]?

>> One thing I have been trying to figure out is how to get the
>> usertags defined for a given bug report to be displayed in the
>> browser.
>
> If you give the user in the users field, they're displayed as if they
> were actual tags.

Really? I mean here when I am looking at one particular bug, eg the url
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=214790
This is the first hit in the general search for usertags
http://bugs.debian.org/cgi-bin/bugreport.cgi?users=debian-boot@...
so it would seem there should be usertags to show.
Yet I can't see any usertags in the display of the individual bug.

I tried the obvious
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=214790;users=debian-boot@...
and got a 500 error.
I tried a newer bug
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=326109;users=debian-boot@...;
and I aslo get a 500 error.

>> I would also like to be able to display all the usertags set by a
>> given user. If I just set users= in the URL, but omit tag=, I'd get
>> all bugs tagged by that user but would then have to compile the
>> usertags. It seems it would be easy for pkgreport.cgi to do that for
>> me and show it as a line at the top of the summary display.
>
> It actually already does that at the top of the display:

Ah. I am pretty sure it wasn't doing that for me before, when I started
asking all these dumb questions. I tried again just now, and got the
list of tags. Yay. Have you updated the running code in between?

I found also that this:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-boot@...;include=alpha
"works", where it did not before. By "works" I mean that the Options
section shows a whole stack of 'tagged' selectors, that I did not see
before.

So now I think I am starting to get this. Then I tried:

lynx -mime_header -source
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=alpha;users=debian-boot@...

and got the attached file (pkgreport.cgi.usertag.test1.txt).

I see the Summary and the Options sections but no, er, bug numbers listed.
Yet the Summary says there are bugs to display.

If I do the obvious thing and hit the 'submit' button on the displayed
page, the URL changes to
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=alpha
and I get "No reports found!".

If I select unarchived & archived in the Misc options -
the URL changes to
http://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;tag=alpha
and I get "No reports found!".

If I do the same thing for the i386 architecture, I do get some bug
numbers displayed, but far fewer than what the summary states.
(pkgreport.cgi.usertag.test2.txt)
The URLs
http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-boot@...;tag=i386
http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-boot@...;tag=i386;archive=both;
both yield the same result.

Assuming there's not some reason for this behaviour,
this should probably be broken out into a separate bug.

Kind regards,
Vince

[1] http://wiki.debian.org/DebianInstaller/Bugs
[2] http://bugs.debian.org/debbugs-source/mainline/html/Access.html.in
HTTP/1.1 200 OK
Date: Mon, 05 Oct 2009 05:07:30 GMT
Server: Apache
Connection: close
Content-Type: text/html; charset=utf-8

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML><HEAD>
<TITLE>Bugs tagged alpha -- Debian Bug report logs</TITLE>
<link rel="stylesheet" href="/css/bugs.css" type="text/css"></HEAD>
<BODY onload="pagemain();">
<DIV id="status_mask"></DIV>
<H1>Debian Bug report logs: Bugs tagged alpha</H1>
<HR><H2>No reports found!</H2></HR>
<script type="text/javascript">

</script>

<h2 class="outstanding">Options</h2>
<form method="GET">
<input type="hidden" name="_fo_combine_key_fo_searchkey_value_fo_searchvalue" value="1">
<input type="hidden" name="form_options" value="1">
<table class="forms">
<tr><td><h2>Select bugs</h2>
</td>
<td>
<nobr><select name="_fo_searchkey">
<option value="package">in package</option>
<option value="tag" selected>tagged</option>
<option value="severity">with severity</option>
<option value="src">in source package</option>
<option value="maint">in packages maintained by</option>
<option value="submitter">submitted by</option>
<option value="owner">owned by</option>
<option value="status">with status</option>
<option value="affects">which affect package</option>
<option value="correspondent">with mail from</option>
<option value="newest">newest bugs</option>
<option value="bugs">in bug</option>

</select>
<input type="text" name="_fo_searchvalue" value ="alpha">

</nobr>
<br>
<nobr><select name="_fo_searchkey">
<option value="package">in package</option>
<option value="tag">tagged</option>
<option value="severity">with severity</option>
<option value="src">in source package</option>
<option value="maint">in packages maintained by</option>
<option value="submitter">submitted by</option>
<option value="owner">owned by</option>
<option value="status">with status</option>
<option value="affects">which affect package</option>
<option value="correspondent">with mail from</option>
<option value="newest">newest bugs</option>
<option value="bugs">in bug</option>

</select>
<input type="text" name="_fo_searchvalue" value ="">

</nobr>

</td>
<td>
<p>The same search fields are ORed, different fields are ANDed.</p>
<p>Valid severities are critical, grave, serious, important, normal, minor, wishlist, fixed</p>
<p>Valid tags are patch, wontfix, moreinfo, unreproducible, fixed, potato, woody, sid, help, security, upstream, pending, sarge, sarge-ignore, experimental, d-i, confirmed, ipv6, lfs, fixed-in-experimental, fixed-upstream, l10n, etch, etch-ignore, lenny, lenny-ignore, squeeze, squeeze-ignore</p>
</td>
</tr>
<tr><td><h2>Include Bugs</h2></td>
<td><input type="hidden" name="_fo_concatenate_into_include_fo_includekey_fo_includevalue" value="1">
<nobr><select name="_fo_includekey">
<option value="subject">with subject containing</option>
<option value="tags">tagged</option>
<option value="severity">with severity</option>
<option value="pending">with pending state</option>
<option value="originator">with submitter containing</option>
<option value="forwarded">with forwarded containing</option>
<option value="owner">with owner containing</option>
<option value="package">with package</option>

</select>
<input type="text" name="_fo_includevalue" value ="">

</nobr>

</td>
<td></td>
</tr>
<tr><td><h2>Exclude Bugs</h2></td>
<td>
<input type="hidden" name="_fo_concatenate_into_exclude_fo_excludekey_fo_excludevalue" value="1">
<nobr><select name="_fo_excludekey">
<option value="subject">with subject containing</option>
<option value="tags">tagged</option>
<option value="severity">with severity</option>
<option value="pending">with pending state</option>
<option value="originator">with submitter containing</option>
<option value="forwarded">with forwarded containing</option>
<option value="owner">with owner containing</option>
<option value="package">with package</option>

</select>
<input type="text" name="_fo_excludevalue" value ="">

</nobr>

</td>
<td></td>
</tr>
<tr><td><h2>Categorize using</h2></td>
<td></td>
</tr>
<tr><td><h2>Order by</h2></td>
<td><select name="ordering"><option value="normal" selected>normal</option>
<option value="oldview">oldview</option>
<option value="raw">raw</option>
<option value="age">age</option>
</td>
<td></td>
</tr>
<tr><td><h2>Misc options</h2></td>
<td>
<input type="checkbox" name="repeatmerged" > Repeat Merged<br>
<input type="checkbox" name="bug-rev" > Reverse Bugs<br>
<input type="checkbox" name="pend-rev" > Reverse Pending<br>
<input type="checkbox" name="sev-rev" > Reverse Severity<br>
<select name="dist">
<option value="" selected>None</option>
<option value="testing">testing</option>
<option value="oldstable">oldstable</option>
<option value="experimental">experimental</option>
<option value="unstable">unstable</option>
<option value="stable">stable</option>
</select><br>
<select name="archive">
<option value="0" selected>Unarchived</option>
<option value="1">Archived</option>
<option value="both">Archived and Unarchived</option>
</select><br>
<a href="javascript:toggle_extra_status_visible()">Toggle all extra information</a>
</td>
</tr>
<tr><td><h2>Submit</h2></td><td colspan=2>
<input type="submit" name="submit" value="Submit">
</td></tr>
</table>

<hr>
<ADDRESS>Debian bug tracking system administrator <<A HREF="mailto:owner@...">owner@...</A>>.
Last modified:
Mon Oct 5 05:07:31 2009;
Machine Name:
rietz.debian.org
<P>
<A HREF="http://www.debian.org/Bugs/">Debian Bug tracking system</A><BR>
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.
</ADDRESS>
</body></html>

HTTP/1.1 200 OK
Date: Mon, 05 Oct 2009 05:14:27 GMT
Server: Apache
Connection: close
Content-Type: text/html; charset=utf-8

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML><HEAD>
<TITLE>Bugs tagged i386 -- Debian Bug report logs</TITLE>
<link rel="stylesheet" href="/css/bugs.css" type="text/css"></HEAD>
<BODY onload="pagemain();">
<DIV id="status_mask"></DIV>
<H1>Debian Bug report logs: Bugs tagged i386</H1>
<HR><H2>No reports found!</H2></HR>
<script type="text/javascript">

</script>

<h2 class="outstanding">Options</h2>
<form method="GET">
<input type="hidden" name="_fo_combine_key_fo_searchkey_value_fo_searchvalue" value="1">
<input type="hidden" name="form_options" value="1">
<table class="forms">
<tr><td><h2>Select bugs</h2>
</td>
<td>
<nobr><select name="_fo_searchkey">
<option value="package">in package</option>
<option value="tag" selected>tagged</option>
<option value="severity">with severity</option>
<option value="src">in source package</option>
<option value="maint">in packages maintained by</option>
<option value="submitter">submitted by</option>
<option value="owner">owned by</option>
<option value="status">with status</option>
<option value="affects">which affect package</option>
<option value="correspondent">with mail from</option>
<option value="newest">newest bugs</option>
<option value="bugs">in bug</option>

</select>
<input type="text" name="_fo_searchvalue" value ="i386">

</nobr>
<br>
<nobr><select name="_fo_searchkey">
<option value="package">in package</option>
<option value="tag">tagged</option>
<option value="severity">with severity</option>
<option value="src">in source package</option>
<option value="maint">in packages maintained by</option>
<option value="submitter">submitted by</option>
<option value="owner">owned by</option>
<option value="status">with status</option>
<option value="affects">which affect package</option>
<option value="correspondent">with mail from</option>
<option value="newest">newest bugs</option>
<option value="bugs">in bug</option>

</select>
<input type="text" name="_fo_searchvalue" value ="">

</nobr>

</td>
<td>
<p>The same search fields are ORed, different fields are ANDed.</p>
<p>Valid severities are critical, grave, serious, important, normal, minor, wishlist, fixed</p>
<p>Valid tags are patch, wontfix, moreinfo, unreproducible, fixed, potato, woody, sid, help, security, upstream, pending, sarge, sarge-ignore, experimental, d-i, confirmed, ipv6, lfs, fixed-in-experimental, fixed-upstream, l10n, etch, etch-ignore, lenny, lenny-ignore, squeeze, squeeze-ignore</p>
</td>
</tr>
<tr><td><h2>Include Bugs</h2></td>
<td><input type="hidden" name="_fo_concatenate_into_include_fo_includekey_fo_includevalue" value="1">
<nobr><select name="_fo_includekey">
<option value="subject">with subject containing</option>
<option value="tags">tagged</option>
<option value="severity">with severity</option>
<option value="pending">with pending state</option>
<option value="originator">with submitter containing</option>
<option value="forwarded">with forwarded containing</option>
<option value="owner">with owner containing</option>
<option value="package">with package</option>

</select>
<input type="text" name="_fo_includevalue" value ="">

</nobr>

</td>
<td></td>
</tr>
<tr><td><h2>Exclude Bugs</h2></td>
<td>
<input type="hidden" name="_fo_concatenate_into_exclude_fo_excludekey_fo_excludevalue" value="1">
<nobr><select name="_fo_excludekey">
<option value="subject">with subject containing</option>
<option value="tags">tagged</option>
<option value="severity">with severity</option>
<option value="pending">with pending state</option>
<option value="originator">with submitter containing</option>
<option value="forwarded">with forwarded containing</option>
<option value="owner">with owner containing</option>
<option value="package">with package</option>

</select>
<input type="text" name="_fo_excludevalue" value ="">

</nobr>

</td>
<td></td>
</tr>
<tr><td><h2>Categorize using</h2></td>
<td></td>
</tr>
<tr><td><h2>Order by</h2></td>
<td><select name="ordering"><option value="normal" selected>normal</option>
<option value="oldview">oldview</option>
<option value="raw">raw</option>
<option value="age">age</option>
</td>
<td></td>
</tr>
<tr><td><h2>Misc options</h2></td>
<td>
<input type="checkbox" name="repeatmerged" > Repeat Merged<br>
<input type="checkbox" name="bug-rev" > Reverse Bugs<br>
<input type="checkbox" name="pend-rev" > Reverse Pending<br>
<input type="checkbox" name="sev-rev" > Reverse Severity<br>
<select name="dist">
<option value="" selected>None</option>
<option value="testing">testing</option>
<option value="oldstable">oldstable</option>
<option value="experimental">experimental</option>
<option value="unstable">unstable</option>
<option value="stable">stable</option>
</select><br>
<select name="archive">
<option value="0" selected>Unarchived</option>
<option value="1">Archived</option>
<option value="both">Archived and Unarchived</option>
</select><br>
<a href="javascript:toggle_extra_status_visible()">Toggle all extra information</a>
</td>
</tr>
<tr><td><h2>Submit</h2></td><td colspan=2>
<input type="submit" name="submit" value="Submit">
</td></tr>
</table>

<hr>
<ADDRESS>Debian bug tracking system administrator <<A HREF="mailto:owner@...">owner@...</A>>.
Last modified:
Mon Oct 5 05:14:28 2009;
Machine Name:
rietz.debian.org
<P>
<A HREF="http://www.debian.org/Bugs/">Debian Bug tracking system</A><BR>
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.
</ADDRESS>
</body></html>

Bug#549439: pkgreport.cgi - internal server errors when using include= parameter

2009-10-04T12:31:45Z

On Sun, 04 Oct 2009, Vincent.McIntyre@... wrote:
> I am experimenting with pulling out groups of bugs using usertags.
> Specifically I was attempting to make some of the urls in [2], that
> claim to pull out arch-specific bugs, actually work.

Assuming the architecture specific bits are done by usertags that are
against the debian-boot@... user, you can just do the
following:

http://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=debian-boot@...;tag=amd64;users=debian-boot@...

> I can't find any documentation for how to construct such URLs more
> advanced than setting users= and tag= in the URL. Reading the source
> of pkgreport.cgi[3] suggests not much of the vision actually ended
> up getting implemented, but I am having trouble following the code.

The only bit that isn't implemented is the ability to enter users= and
other bits in the url selection at the bottom.

> I'm happy to help write something that documents the current
> functionality.

That'd be great.

> One thing I have been trying to figure out is how to get the
> usertags defined for a given bug report to be displayed in the
> browser.

If you give the user in the users field, they're displayed as if they
were actual tags.

> I would also like to be able to display all the usertags set by a
> given user. If I just set users= in the URL, but omit tag=, I'd get
> all bugs tagged by that user but would then have to compile the
> usertags. It seems it would be easy for pkgreport.cgi to do that for
> me and show it as a line at the top of the summary display.

It actually already does that at the top of the display:

Debian Bug report logs: Bugs (tagged netcfg or debootstrap or
accessibility or network or floppy or sarge-ext or etch-beta1 or
partman or daily or etch-beta3 or etch or mipsel or hw-sata or l10n or
arm or hw-cdrom or serial or old-report or netinst or sarge-rc2 or
full or boot or none or hw or netboot or tasksel or usability or
sarge-r1 or alpha or ia64 or kfreebsd or sparc or bc or not-d-i or
debian-edu or cd or reboot or mips or m68k or lenny-beta2 or hd-media
or s390 or sarge-r0 or etch-rc1 or hppa or powerpc or amd64 or i386)

See http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-boot@...

Don Armstrong

--
"For those who understand, no explanation is necessary.
For those who do not, none is possible."

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

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