[opensuse-project] GSoC 2011: Bug reporting tool.

newer
[opensuse-project] A project focus...

Mihnea Dobrescu-Balaur

22 Mar 2011 22 Mar '11

14:46

Hello, I'm applying at this year's GSoC to work on the bug reporting tool [0]. I've made my list of features to implement but, before I finalized my proposal, I thought it would be a good idea to ask you, guys: Is there's any particular feature that you wish to find in the openSUSE bug reporting tool? Thank you! Mihnea Dobrescu-Balaur [0] http://en.opensuse.org/openSUSE:GSOC_2011_Ideas#Bug_reporting_tool_for_openS... -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Show replies by date

Greg Freemyer

22 Mar 22 Mar

15:18

On Tue, Mar 22, 2011 at 10:46 AM, Mihnea Dobrescu-Balaur wrote:

...

Hello,

I'm applying at this year's GSoC to work on the bug reporting tool [0]. I've made my list of features to implement but, before I finalized my proposal, I thought it would be a good idea to ask you, guys:

Is there's any particular feature that you wish to find in the openSUSE bug reporting tool?

Thank you!

Mihnea Dobrescu-Balaur

[0] http://en.opensuse.org/openSUSE:GSOC_2011_Ideas#Bug_reporting_tool_for_openS...

Very cool, I think one of the hopefully obvious, but easily overlooked features is to ensure you are reporting against the right package. zypper and osc will be tools you will get to know rather well I suspect. For instance: ===

...

zypper se -s virtualbox | grep " virtualbox " i | virtualbox | package | 4.0.4-1.2.3 | x86_64 | openSUSE-11.4 OSS v | virtualbox | package | 4.0.4-1.2 | x86_64 | Tumbleweed v | virtualbox | package | 4.0.4-1.2.3 | i586 | openSUSE-11.4 OSS v | virtualbox | package | 4.0.4-1.2 | i586 | Tumbleweed | virtualbox | srcpackage | 4.0.4-1.2 | noarch | Tumbleweed ===

can be used to show that virtualbox 4.0.4-1.2.3 from the 11.4 OSS repo is installed (note the 'i' in the first column). You can also see it is the x86_64 architecture. You can then drill down into virtualbox from that repo and find out who the maintainer is. I don't know if that is done via zypper, or osc, but either way you can see that a lot of the data needed to file a bugzilla can be gathered automatically. It would be great if that could be used to populate a ncurses form and/or a GUI form for the user to fill out. I don't know if you should allow the automatically collected data to be edited by the user or not, but the bug details clearly need to manually input. Then when the user clicks "file" (or whatever), you submit the bug to bugzilla and maybe email the submitter an email with a link to their bugzilla entry. Niceties would include: - looking to ensure they have a bugzilla account, and if not walking the user through creating one. - pulling dmesg logs, yast logs, etc. as needed for specific bugs. ie. When filing a yast subsystem bug, there is a process the user is supposed to follow. - see http://en.opensuse.org/openSUSE:Report_a_YaST_bug for just one set of features you could add to your tool I don't know that your tool would need to be part of the follow-on questions etc. In fact I'm not sure how you could really assist with that. Good Luck Greg -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Mihnea Dobrescu-Balaur

16:31

> [...]
> You can then drill down into virtualbox from that repo and find out
> who the maintainer is.  I don't know if that is done via zypper, or
> osc, but either way you can see that a lot of the data needed to file
> a bugzilla can be gathered automatically.
>
Yes, I've thought of that. I was planning on using the "-i" search option
to crawl through installed packages. :)

> It would be great if that could be used to populate a ncurses form
> and/or a GUI form for the user to fill out.  I don't know if you
> should allow the automatically collected data to be edited by the user
> or not, but the bug details clearly need to manually input.
Here, I was thinking to request the user to enter details like:
 - required steps to reproduce the behavior
 - expected behavior
 - actual behavior
 - severity (although it depends on the user's objectiveness)
 - also, something like a tick box to say if the issue is security related
or not ( i feel that this is important, aside from the severity scale )
 - last but not least, maybe a set of predefined tags; what do you
think?

> Then when the user clicks "file" (or whatever), you submit the bug to
> bugzilla and maybe email the submitter an email with a link to their
> bugzilla entry.
>
I would need to have the user's email. I think it can be marked as an
optional step for the user.

> Niceties would include:
>
> - looking to ensure they have a bugzilla account, and if not walking
> the user through creating one.
Don't know about walking through those steps, but at least a link to
the register page.

> - pulling dmesg logs, yast logs, etc. as needed for specific bugs.
> ie. When filing a yast subsystem bug, there is a process the user is
> supposed to follow.
>
> - see http://en.opensuse.org/openSUSE:Report_a_YaST_bug for just one
> set of features you could add to your tool
I'll do some research!

> I don't know that your tool would need to be part of the follow-on
> questions etc.  In fact I'm not sure how you could really assist with
> that.
Maybe I could ask the user if he agrees to be contacted via e-mail if
in need for more details?

Thank you,
Mihnea
-- 
To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org
For additional commands, e-mail: opensuse-project+help@opensuse.org

Greg Freemyer

16:44

On Tue, Mar 22, 2011 at 12:31 PM, Mihnea Dobrescu-Balaur wrote:

...

...
[...] You can then drill down into virtualbox from that repo and find out who the maintainer is. I don't know if that is done via zypper, or osc, but either way you can see that a lot of the data needed to file a bugzilla can be gathered automatically.

Yes, I've thought of that. I was planning on using the "-i" search option to crawl through installed packages. :)

...
It would be great if that could be used to populate a ncurses form and/or a GUI form for the user to fill out. I don't know if you should allow the automatically collected data to be edited by the user or not, but the bug details clearly need to manually input. Here, I was thinking to request the user to enter details like: - required steps to reproduce the behavior - expected behavior - actual behavior - severity (although it depends on the user's objectiveness) - also, something like a tick box to say if the issue is security related or not ( i feel that this is important, aside from the severity scale ) - last but not least, maybe a set of predefined tags; what do you think?

...
Then when the user clicks "file" (or whatever), you submit the bug to bugzilla and maybe email the submitter an email with a link to their bugzilla entry.

I would need to have the user's email. I think it can be marked as an optional step for the user.

...
Niceties would include:

- looking to ensure they have a bugzilla account, and if not walking the user through creating one. Don't know about walking through those steps, but at least a link to the register page.

...
- pulling dmesg logs, yast logs, etc. as needed for specific bugs. ie. When filing a yast subsystem bug, there is a process the user is supposed to follow.

- see http://en.opensuse.org/openSUSE:Report_a_YaST_bug for just one set of features you could add to your tool I'll do some research!

...
I don't know that your tool would need to be part of the follow-on questions etc. In fact I'm not sure how you could really assist with that. Maybe I could ask the user if he agrees to be contacted via e-mail if in need for more details?

Thank you, Mihnea

To file a bug, your users will have to have a bugzilla account. And to have an account I think a email address is mandatory. You will have to get the login / password info from the user. Then you can login and get the email address they have in their profile: see https://bugzilla.novell.com/userprefs.cgi Greg -- Greg Freemyer Head of EDD Tape Extraction and Processing team Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer CNN/TruTV Aired Forensic Imaging Demo - http://insession.blogs.cnn.com/2010/03/23/how-computer-evidence-gets-retriev... The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Mihnea Dobrescu-Balaur

16:51

On Tue, Mar 22, 2011 at 6:44 PM, Greg Freemyer wrote:

...

On Tue, Mar 22, 2011 at 12:31 PM, Mihnea Dobrescu-Balaur wrote:

...
...
[...] You can then drill down into virtualbox from that repo and find out who the maintainer is. I don't know if that is done via zypper, or osc, but either way you can see that a lot of the data needed to file a bugzilla can be gathered automatically.

Yes, I've thought of that. I was planning on using the "-i" search option to crawl through installed packages. :)

...
It would be great if that could be used to populate a ncurses form and/or a GUI form for the user to fill out. I don't know if you should allow the automatically collected data to be edited by the user or not, but the bug details clearly need to manually input. Here, I was thinking to request the user to enter details like: - required steps to reproduce the behavior - expected behavior - actual behavior - severity (although it depends on the user's objectiveness) - also, something like a tick box to say if the issue is security related or not ( i feel that this is important, aside from the severity scale ) - last but not least, maybe a set of predefined tags; what do you think?

...
Then when the user clicks "file" (or whatever), you submit the bug to bugzilla and maybe email the submitter an email with a link to their bugzilla entry.

I would need to have the user's email. I think it can be marked as an optional step for the user.

...
Niceties would include:

- looking to ensure they have a bugzilla account, and if not walking the user through creating one. Don't know about walking through those steps, but at least a link to the register page.

...
- pulling dmesg logs, yast logs, etc. as needed for specific bugs. ie. When filing a yast subsystem bug, there is a process the user is supposed to follow.

- see http://en.opensuse.org/openSUSE:Report_a_YaST_bug for just one set of features you could add to your tool I'll do some research!

...
I don't know that your tool would need to be part of the follow-on questions etc. In fact I'm not sure how you could really assist with that. Maybe I could ask the user if he agrees to be contacted via e-mail if in need for more details?

Thank you, Mihnea

To file a bug, your users will have to have a bugzilla account. And to have an account I think a email address is mandatory.

You will have to get the login / password info from the user. Then you can login and get the email address they have in their profile:

see https://bugzilla.novell.com/userprefs.cgi

I was thinking on something like, at install request for the user's username and password and, optionally, for his e-mail address, so I wouldn't have to find a way to extract data from the profile. Seemed easier. What do you think? :) Mihnea -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Greg Freemyer

17:05

On Tue, Mar 22, 2011 at 12:51 PM, Mihnea Dobrescu-Balaur wrote:

...

On Tue, Mar 22, 2011 at 6:44 PM, Greg Freemyer wrote:

...
On Tue, Mar 22, 2011 at 12:31 PM, Mihnea Dobrescu-Balaur wrote:

...
...
[...] You can then drill down into virtualbox from that repo and find out who the maintainer is. I don't know if that is done via zypper, or osc, but either way you can see that a lot of the data needed to file a bugzilla can be gathered automatically.

Yes, I've thought of that. I was planning on using the "-i" search option to crawl through installed packages. :)

...
It would be great if that could be used to populate a ncurses form and/or a GUI form for the user to fill out. I don't know if you should allow the automatically collected data to be edited by the user or not, but the bug details clearly need to manually input. Here, I was thinking to request the user to enter details like: - required steps to reproduce the behavior - expected behavior - actual behavior - severity (although it depends on the user's objectiveness) - also, something like a tick box to say if the issue is security related or not ( i feel that this is important, aside from the severity scale ) - last but not least, maybe a set of predefined tags; what do you think?

...
Then when the user clicks "file" (or whatever), you submit the bug to bugzilla and maybe email the submitter an email with a link to their bugzilla entry.

I would need to have the user's email. I think it can be marked as an optional step for the user.

...
Niceties would include:

- looking to ensure they have a bugzilla account, and if not walking the user through creating one. Don't know about walking through those steps, but at least a link to the register page.

...
- pulling dmesg logs, yast logs, etc. as needed for specific bugs. ie. When filing a yast subsystem bug, there is a process the user is supposed to follow.

- see http://en.opensuse.org/openSUSE:Report_a_YaST_bug for just one set of features you could add to your tool I'll do some research!

...
I don't know that your tool would need to be part of the follow-on questions etc. In fact I'm not sure how you could really assist with that. Maybe I could ask the user if he agrees to be contacted via e-mail if in need for more details?

Thank you, Mihnea

To file a bug, your users will have to have a bugzilla account. And to have an account I think a email address is mandatory.

You will have to get the login / password info from the user. Then you can login and get the email address they have in their profile:

see https://bugzilla.novell.com/userprefs.cgi

I was thinking on something like, at install request for the user's username and password and, optionally, for his e-mail address, so I wouldn't have to find a way to extract data from the profile. Seemed easier. What do you think? :)

Mihnea

I guess that's up to you and your mentor. btw: Will google let you specify core requirements and then optional add-on requirements? If so, pulling the email address might make a good add-on requirement. Again, you should discuss it with your mentor. Greg -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Mihnea Dobrescu-Balaur

17:08

On Tue, Mar 22, 2011 at 7:05 PM, Greg Freemyer wrote:

...

On Tue, Mar 22, 2011 at 12:51 PM, Mihnea Dobrescu-Balaur wrote:

...
On Tue, Mar 22, 2011 at 6:44 PM, Greg Freemyer wrote:

...
On Tue, Mar 22, 2011 at 12:31 PM, Mihnea Dobrescu-Balaur wrote:

...
...
[...] You can then drill down into virtualbox from that repo and find out who the maintainer is. I don't know if that is done via zypper, or osc, but either way you can see that a lot of the data needed to file a bugzilla can be gathered automatically.

Yes, I've thought of that. I was planning on using the "-i" search option to crawl through installed packages. :)

...
It would be great if that could be used to populate a ncurses form and/or a GUI form for the user to fill out. I don't know if you should allow the automatically collected data to be edited by the user or not, but the bug details clearly need to manually input. Here, I was thinking to request the user to enter details like: - required steps to reproduce the behavior - expected behavior - actual behavior - severity (although it depends on the user's objectiveness) - also, something like a tick box to say if the issue is security related or not ( i feel that this is important, aside from the severity scale ) - last but not least, maybe a set of predefined tags; what do you think?

...
Then when the user clicks "file" (or whatever), you submit the bug to bugzilla and maybe email the submitter an email with a link to their bugzilla entry.

I would need to have the user's email. I think it can be marked as an optional step for the user.

...
Niceties would include:

- looking to ensure they have a bugzilla account, and if not walking the user through creating one. Don't know about walking through those steps, but at least a link to the register page.

...
- pulling dmesg logs, yast logs, etc. as needed for specific bugs. ie. When filing a yast subsystem bug, there is a process the user is supposed to follow.

- see http://en.opensuse.org/openSUSE:Report_a_YaST_bug for just one set of features you could add to your tool I'll do some research!

...
I don't know that your tool would need to be part of the follow-on questions etc. In fact I'm not sure how you could really assist with that. Maybe I could ask the user if he agrees to be contacted via e-mail if in need for more details?

Thank you, Mihnea

To file a bug, your users will have to have a bugzilla account. And to have an account I think a email address is mandatory.

You will have to get the login / password info from the user. Then you can login and get the email address they have in their profile:

see https://bugzilla.novell.com/userprefs.cgi

I was thinking on something like, at install request for the user's username and password and, optionally, for his e-mail address, so I wouldn't have to find a way to extract data from the profile. Seemed easier. What do you think? :)

Mihnea

I guess that's up to you and your mentor.

btw: Will google let you specify core requirements and then optional add-on requirements?

If so, pulling the email address might make a good add-on requirement. Again, you should discuss it with your mentor.

Greg

I don't know, I will ask. Thank you very much for your opinions! Mihnea -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Christian Boltz

20:52

Hello, on Dienstag, 22. März 2011, Mihnea Dobrescu-Balaur wrote:

...

I was thinking on something like, at install request for the user's username and password and, optionally, for his e-mail address, so I wouldn't have to find a way to extract data from the profile. Seemed easier. What do you think? :)

IMHO asking for the mail address is superfluous because bugzilla already knows it. In detail: If you (or $tool) enter a bugreport in bugzilla, bugzilla auto-fills the "reporter" field depending on the logged in user. The mail notification about the bugreport, additional comments, status changes etc. are also handled by bugzilla already. This means the bug reporting tool does not need to know the email address at all. Well, this might change if you want to provide more features, for example bug lists like "bugs reported by me" or "bugs where I'm in CC" - but this is probably nothing you want to implement in a "report a bug" tool. (I won't object to have a complete desktop client for bugzilla ;-) but this would be far beyond a bugreporting tool...) What I'd consider more important is a duplicate check - based on the package (and repo?) and/or on the summary of the bugreport. Which brings up a more interesting question that is not really solvable with $tool: The user needs to know which package causes the bug. This might be easy in some cases ("xy crashes"), but can become quite difficult in other cases (random crashes, slowness etc.). https://wiki.ubuntu.com/Bugs/FindRightPackage is quite helpful to answer this question (and might give you some ideas), however I'm not sure if the page is helpful for average users. Maybe having a multi-step "find the right package" assistant [1] and/or offering various methods ("click the window of the buggy program") in the bugreporting tool could make this easier. That said: regarding the assignee, it can only become better than the current situation in bugzilla where most bugreports initially go to the (overworked?) screening team and take lots of time until they reach the developers. Oh, and I just see I might have something to celebrate soon ;-) Bugzilla says I have reported 972 bugs (starting with SUSE Linux 9.2 [2]) - that's not too far from 1000 bugreports. Let's hope I won't reach the 1000 with 11.4 ;-) Regards, Christian Boltz [1] just an idea: this assistant could regularly update the options it offers online so that we can react to unclear parts or "popular" buggy programs easily. [2] that means that not all of my bugreports are public - the 9.x reports are non-public AFAIK. -- switch2nvidia: * fixed disabling Composite extension; script replaced "Option" with "Optioff" :-( [Stefan Dirsch in opensuse-commit] -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Mihnea Dobrescu-Balaur

21:52

> What I'd consider more important is a duplicate check - based on the
> package (and repo?) and/or on the summary of the bugreport.
I'm not sure how accurate an automated check based on the summary
would be, but I'm thinking about a scenario like this:
 - User wants to report a bug for package Foo
 - the tools shows him a list with short descriptions of the already
reported bugs for the Foo package
 - he _decides_ if it's been already posted or not;
Could I automate it more than that? Without AI stuff :).

> Which brings up a more interesting question that is not really solvable
> with $tool: The user needs to know which package causes the bug. This
> might be easy in some cases ("xy crashes"), but can become quite
> difficult in other cases (random crashes, slowness etc.).
> https://wiki.ubuntu.com/Bugs/FindRightPackage is quite helpful to answer
> this question (and might give you some ideas), however I'm not sure if
> the page is helpful for average users.
> Maybe having a multi-step "find the right package" assistant [1] and/or
> offering various methods ("click the window of the buggy program") in
> the bugreporting tool could make this easier.
Will do some reading, maybe I could also check some process information
(like %CPU, %MEM, TIME etc) ?

> That said: regarding the assignee, it can only become better than the
> current situation in bugzilla where most bugreports initially go to the
> (overworked?) screening team and take lots of time until they reach the
> developers.
Yes, the plan is to figure who the maintainer is and to use that info.

>
> Oh, and I just see I might have something to celebrate soon ;-)
> Bugzilla says I have reported 972 bugs (starting with SUSE Linux 9.2
> [2]) - that's not too far from 1000 bugreports. Let's hope I won't reach
> the 1000 with 11.4 ;-)
Wow, you really have some bug reporting experience! Maybe we could
keep in touch, in case I have some more questions?

Mihnea
-- 
To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org
For additional commands, e-mail: opensuse-project+help@opensuse.org

Dominique Leuenberger

22:21

On Tue, 2011-03-22 at 23:52 +0200, Mihnea Dobrescu-Balaur wrote:

...

...
That said: regarding the assignee, it can only become better than the current situation in bugzilla where most bugreports initially go to the (overworked?) screening team and take lots of time until they reach the developers. Yes, the plan is to figure who the maintainer is and to use that info.

I think this is a dangerous statement. For the GNOME Team for example, as soon as you enter a gnome bug, it gets assigned to the 'gnome-maintainer' user, which is fine and who all of us GNOMEies monitor. Only very rare cases do we actually assign them to a specific person.. That does not mean though that bugs don't get addressed or fixed. Dominique -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Mihnea Dobrescu-Balaur

22:28

On Wed, Mar 23, 2011 at 12:21 AM, Dominique Leuenberger wrote:

...

On Tue, 2011-03-22 at 23:52 +0200, Mihnea Dobrescu-Balaur wrote:

...
...
That said: regarding the assignee, it can only become better than the current situation in bugzilla where most bugreports initially go to the (overworked?) screening team and take lots of time until they reach the developers. Yes, the plan is to figure who the maintainer is and to use that info.

I think this is a dangerous statement. For the GNOME Team for example, as soon as you enter a gnome bug, it gets assigned to the 'gnome-maintainer' user, which is fine and who all of us GNOMEies monitor.

Now I'm confused. I understand both points of view. I guess as long the team that the package belongs to has some user like 'gnome-maintainer', the bug should be assigned to that user, otherwise it should be assigned to it's "rightful" maintainer. What do you say? -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Christian Boltz

23:29

Hello, on Dienstag, 22. März 2011, Mihnea Dobrescu-Balaur wrote:

...

...
What I'd consider more important is a duplicate check - based on the package (and repo?) and/or on the summary of the bugreport.

I'm not sure how accurate an automated check based on the summary would be, but I'm thinking about a scenario like this: - User wants to report a bug for package Foo - the tools shows him a list with short descriptions of the already reported bugs for the Foo package - he _decides_ if it's been already posted or not;

Yes, that basically sounds like a good way. The problem is that bugzilla does not know about packages, so you'll need an interesting[tm] method for searching and sorting the results. (Often the bugreports contain the package name in the summary or a comment.) I would also ask the user for a summary of the bug and use it as additonal search condition (in case a user has chosen a wrong package, but a good bugreport summary ;-)

...

Could I automate it more than that? Without AI stuff :).

Probably not. Checking for duplicates is something that requires /dev/brain. (Some rare exceptions might apply - for example bugreports with backtraces or symbol codes could have some automation.) BTW: Regarding the workflow in the bugreporting tool, https://bugs.kde.org/enter_bug.cgi?format=guided might give you some inspiration.

...

...
https://wiki.ubuntu.com/Bugs/FindRightPackage is quite helpful [...]

...

Will do some reading, maybe I could also check some process information (like %CPU, %MEM, TIME etc) ?

Indeed, "uses >95% CPU" and "uses >50% MEM" can be good indicators ;-) and might also be useful if included in the bugreport (obviously only if the process is still running).

...

...
That said: regarding the assignee, it can only become better than the current situation in bugzilla where most bugreports initially go to the (overworked?) screening team and take lots of time until they reach the developers.

Yes, the plan is to figure who the maintainer is and to use that info.

That's the easy part: osc maintainer -e -B $project $package (or use the osc libraries directly) will give you the mail address of the bugowner/assignee. Be warned that $package means the source package, which may or may not be the same as the binary package name (think of packages with subpackages etc.). The good thing is that the disturl will give you this information (rpm -q --qf '%{disturl}\n' $packagename). @Dominique: as long as you have set "gnome-maintainer" as bugowner on (nearly) all GNOME packages, everything should work as expected.

...

...
Oh, and I just see I might have something to celebrate soon ;-) Bugzilla says I have reported 972 bugs (starting with SUSE Linux 9.2 [2]) - that's not too far from 1000 bugreports. Let's hope I won't reach the 1000 with 11.4 ;-)

Wow, you really have some bug reporting experience! Maybe we could keep in touch, in case I have some more questions?

Yes, of course. I'm reading the -project and -factory mailinglist and some more lists more or less regularly (depending on my available time, which is usually the limiting factor). IMHO the best way is to ask on a mailinglist. You can CC me if you have specific questions, but I'd prefer to have all mails also on public mailinglists so that others can read them and/or reply if they want. Regards, Christian Boltz -- Yeah, Windows is great... I used it to download Linux. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Mihnea Dobrescu-Balaur

23 Mar 23 Mar

11:19

On Wed, Mar 23, 2011 at 1:29 AM, Christian Boltz wrote:

...

Hello,

on Dienstag, 22. März 2011, Mihnea Dobrescu-Balaur wrote:

...
...
What I'd consider more important is a duplicate check - based on the package (and repo?) and/or on the summary of the bugreport.

I'm not sure how accurate an automated check based on the summary would be, but I'm thinking about a scenario like this: - User wants to report a bug for package Foo - the tools shows him a list with short descriptions of the already reported bugs for the Foo package - he _decides_ if it's been already posted or not;

Yes, that basically sounds like a good way.

The problem is that bugzilla does not know about packages, so you'll need an interesting[tm] method for searching and sorting the results. (Often the bugreports contain the package name in the summary or a comment.)

I would also ask the user for a summary of the bug and use it as additonal search condition (in case a user has chosen a wrong package, but a good bugreport summary ;-)

...
Could I automate it more than that? Without AI stuff :).

Probably not. Checking for duplicates is something that requires /dev/brain. (Some rare exceptions might apply - for example bugreports with backtraces or symbol codes could have some automation.)

BTW: Regarding the workflow in the bugreporting tool, https://bugs.kde.org/enter_bug.cgi?format=guided might give you some inspiration.

...
...
https://wiki.ubuntu.com/Bugs/FindRightPackage is quite helpful [...]

...
Will do some reading, maybe I could also check some process information (like %CPU, %MEM, TIME etc) ?

Indeed, "uses >95% CPU" and "uses >50% MEM" can be good indicators ;-) and might also be useful if included in the bugreport (obviously only if the process is still running).

...
...
That said: regarding the assignee, it can only become better than the current situation in bugzilla where most bugreports initially go to the (overworked?) screening team and take lots of time until they reach the developers.

Yes, the plan is to figure who the maintainer is and to use that info.

That's the easy part: osc maintainer -e -B $project $package (or use the osc libraries directly) will give you the mail address of the bugowner/assignee.

Be warned that $package means the source package, which may or may not be the same as the binary package name (think of packages with subpackages etc.). The good thing is that the disturl will give you this information (rpm -q --qf '%{disturl}\n' $packagename).

@Dominique: as long as you have set "gnome-maintainer" as bugowner on (nearly) all GNOME packages, everything should work as expected.

...
...
Oh, and I just see I might have something to celebrate soon ;-) Bugzilla says I have reported 972 bugs (starting with SUSE Linux 9.2 [2]) - that's not too far from 1000 bugreports. Let's hope I won't reach the 1000 with 11.4 ;-)

Wow, you really have some bug reporting experience! Maybe we could keep in touch, in case I have some more questions?

Yes, of course. I'm reading the -project and -factory mailinglist and some more lists more or less regularly (depending on my available time, which is usually the limiting factor). IMHO the best way is to ask on a mailinglist. You can CC me if you have specific questions, but I'd prefer to have all mails also on public mailinglists so that others can read them and/or reply if they want.

Sure, it's better on the mailing list. I've noted all the inputs, on to writing the proposal now :). If you have any other suggestions, please, don't hesitate to tell them to me. Thanks, everybody! Mihnea -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Greg Freemyer

12:39

On Tue, Mar 22, 2011 at 7:29 PM, Christian Boltz wrote:

...

Hello,

on Dienstag, 22. März 2011, Mihnea Dobrescu-Balaur wrote:

...
...
What I'd consider more important is a duplicate check - based on the package (and repo?) and/or on the summary of the bugreport.

I'm not sure how accurate an automated check based on the summary would be, but I'm thinking about a scenario like this: - User wants to report a bug for package Foo - the tools shows him a list with short descriptions of the already reported bugs for the Foo package - he _decides_ if it's been already posted or not;

Yes, that basically sounds like a good way.

The problem is that bugzilla does not know about packages, so you'll need an interesting[tm] method for searching and sorting the results. (Often the bugreports contain the package name in the summary or a comment.)

Maybe there is a bugzilla field that could be re-purposed for packages? If this tool is part of the next distro release, it could start depending on data that it itself populates even if the manually input bugzillas don't do the same.. Greg -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Mihnea Dobrescu-Balaur

13:57

On Wed, Mar 23, 2011 at 2:39 PM, Greg Freemyer wrote:

...

On Tue, Mar 22, 2011 at 7:29 PM, Christian Boltz wrote:

...
Hello,

on Dienstag, 22. März 2011, Mihnea Dobrescu-Balaur wrote:

...
...
What I'd consider more important is a duplicate check - based on the package (and repo?) and/or on the summary of the bugreport.

I'm not sure how accurate an automated check based on the summary would be, but I'm thinking about a scenario like this: - User wants to report a bug for package Foo - the tools shows him a list with short descriptions of the already reported bugs for the Foo package - he _decides_ if it's been already posted or not;

Yes, that basically sounds like a good way.

The problem is that bugzilla does not know about packages, so you'll need an interesting[tm] method for searching and sorting the results. (Often the bugreports contain the package name in the summary or a comment.)

Maybe there is a bugzilla field that could be re-purposed for packages?

That, or maybe an auto generated header in the bug summary? -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Vincent Untz

24 Mar 24 Mar

00:32

Le mercredi 23 mars 2011, à 08:39 -0400, Greg Freemyer a écrit :

...

On Tue, Mar 22, 2011 at 7:29 PM, Christian Boltz wrote:

...
The problem is that bugzilla does not know about packages, so you'll need an interesting[tm] method for searching and sorting the results. (Often the bugreports contain the package name in the summary or a comment.)

Maybe there is a bugzilla field that could be re-purposed for packages?

You can use the whiteboard for that; for example, adding "package:gnome-panel" there would work fine. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Mihnea Dobrescu-Balaur

04:43

On Thu, Mar 24, 2011 at 2:32 AM, Vincent Untz wrote:

...

Le mercredi 23 mars 2011, à 08:39 -0400, Greg Freemyer a écrit :

...
On Tue, Mar 22, 2011 at 7:29 PM, Christian Boltz wrote:

...
The problem is that bugzilla does not know about packages, so you'll need an interesting[tm] method for searching and sorting the results. (Often the bugreports contain the package name in the summary or a comment.)

Maybe there is a bugzilla field that could be re-purposed for packages?

You can use the whiteboard for that; for example, adding "package:gnome-panel" there would work fine.

Great idea! As i see here [0], I could use the whiteboard also having a set of predefined tags. Am I right? [0] http://www.bugzilla.org/docs/tip/en/html/parameters.html Mihnea -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Matt Barringer

22 Mar 22 Mar

17:16

On Tue, 22 Mar 2011, Mihnea Dobrescu-Balaur wrote:

...

I would need to have the user's email. I think it can be marked as an optional step for the user.

You'll need the user's login and password to submit a bug in the first place. From there, you can get an email address through Bugzilla's XMLRPC interface (http://www.bugzilla.org/docs/3.4/en/html/api/Bugzilla/WebService/User.html#U...), and submit a bug using the Bug.create call (http://www.bugzilla.org/docs/3.4/en/html/api/Bugzilla/WebService/Bug.html#Bu...) Matt -- Matt Barringer, Software Engineer SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) http://susestudio.com http://www.novell.com/linux

Mihnea Dobrescu-Balaur

17:24

On Tue, Mar 22, 2011 at 7:16 PM, Matt Barringer wrote:

...

On Tue, 22 Mar 2011, Mihnea Dobrescu-Balaur wrote:

...
I would need to have the user's email. I think it can be marked as an optional step for the user.

You'll need the user's login and password to submit a bug in the first place. From there, you can get an email address through Bugzilla's XMLRPC interface (http://www.bugzilla.org/docs/3.4/en/html/api/Bugzilla/WebService/User.html#U...), and submit a bug using the Bug.create call (http://www.bugzilla.org/docs/3.4/en/html/api/Bugzilla/WebService/Bug.html#Bu...)

Great, I didn't know that, noted. Thanks! Mihnea -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Matt Barringer

17:33

On Tue, 22 Mar 2011, Mihnea Dobrescu-Balaur wrote:

...

Great, I didn't know that, noted. Thanks!

You can use the XMLRPC interface to do almost all of the interactions with Novell's Bugzilla that you would need to do: getting the iChain login cookie would need to be handled with a POST call, but everything else can be done with XMLRPC. -- Matt Barringer, Software Engineer SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) http://susestudio.com http://www.novell.com/linux

Dominique Leuenberger a.k.a DimStar

15:52

Quoting Mihnea Dobrescu-Balaur :

...

Hello,

I'm applying at this year's GSoC to work on the bug reporting tool [0]. I've made my list of features to implement but, before I finalized my proposal, I thought it would be a good idea to ask you, guys:

Is there's any particular feature that you wish to find in the openSUSE bug reporting tool?

Sounds like a fun project :) I think it would be interesting and essential to have linking in both directions: A package in OBS should be able to list 'bugs' of this specific package, taking into account the possibility of devel projects (don't ask me how.. I'm just blurring here) Of course vice-versa, a bug should be able to be assigned to a package, but that you already covered. Dominique -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Mihnea Dobrescu-Balaur

16:19

...

A package in OBS should be able to list 'bugs' of this specific package, taking into account the possibility of devel projects (don't ask me how.. I'm just blurring here)

Yes, I intend to implement listing a packages reported bugs, so that the user reporting it could first check that his bug is not already reported. Thank you for your opinion! Mihnea -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Jos Poortvliet

6 Apr 6 Apr

13:52

On 2011-03-22 Mihnea wrote:

...

Hello,

I'm applying at this year's GSoC to work on the bug reporting tool [0]. I've made my list of features to implement but, before I finalized my proposal, I thought it would be a good idea to ask you, guys:

Is there's any particular feature that you wish to find in the openSUSE bug reporting tool?

Thank you!

Mihnea Dobrescu-Balaur

[0] http://en.opensuse.org/openSUSE:GSOC_2011_Ideas#Bug_reporting_too l_for_openSUSE it is a bit late, but check out the KDE bug report tool. It does pretty much what you want - collect crash report and all relevant system information, ask a few questions, look for duplicates automatically (!), let the user view the duplicates and mark his report as possible or sure duplicate (in the sure duplicate case the tool adds the new report as a comment to the current one!) and finally show all info to be send in and execute the sending. As KDE uses bugzilla too, it'd be easy to adapt the tool for openSUSE. But this is only crash reporting, not sure if there is code you could re-use if you want to report more 'generic' bugs...

Mihnea Dobrescu-Balaur

16:08

On Wed, Apr 6, 2011 at 4:52 PM, Jos Poortvliet wrote:

...

On 2011-03-22 Mihnea wrote:

...
Hello,

I'm applying at this year's GSoC to work on the bug reporting tool [0]. I've made my list of features to implement but, before I finalized my proposal, I thought it would be a good idea to ask you, guys:

Is there's any particular feature that you wish to find in the openSUSE bug reporting tool?

Thank you!

Mihnea Dobrescu-Balaur

[0] http://en.opensuse.org/openSUSE:GSOC_2011_Ideas#Bug_reporting_too l_for_openSUSE it is a bit late, but check out the KDE bug report tool. It does pretty much what you want - collect crash report and all relevant system information, ask a few questions, look for duplicates automatically (!), let the user view the duplicates and mark his report as possible or sure duplicate (in the sure duplicate case the tool adds the new report as a comment to the current one!) and finally show all info to be send in and execute the sending. As KDE uses bugzilla too, it'd be easy to adapt the tool for openSUSE. But this is only crash reporting, not sure if there is code you could re-use if you want to report more 'generic' bugs...

Yes, I have looked at it a while ago. :) Thanks for the tip, though! Mihnea -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Mihnea Dobrescu-Balaur

30 Apr 30 Apr

13:06

Hello, As you probably know, this project has been accepted. I need a bit of help with two things at the moment: * What do you think is an OK prefix to add to the bug reports generated (at least at the moment) with the tool? Is [SUSEREPORT] ok? * I will have to submit quite a number of test bug reports and I don't want to cause havoc on bugzilla. Is there a way to have something like a sandbox? Thank you, Mihnea -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Matt Barringer

17:38

On Sat, 30 Apr 2011, Mihnea Dobrescu-Balaur wrote:

...

* I will have to submit quite a number of test bug reports and I don't want to cause havoc on bugzilla. Is there a way to have something like a sandbox?

Bugzilla has a test server with all of their releases. The applicable version Novell uses is: https://landfill.bugzilla.org/bugzilla-3.4-branch/ -- Matt Barringer, Software Engineer SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) http://susestudio.com http://www.novell.com/linux

Mihnea Dobrescu-Balaur

17:56

On Sat, Apr 30, 2011 at 8:38 PM, Matt Barringer wrote:

...

On Sat, 30 Apr 2011, Mihnea Dobrescu-Balaur wrote:

...
* I will have to submit quite a number of test bug reports and I don't want to cause havoc on bugzilla. Is there a way to have something like a sandbox?

Bugzilla has a test server with all of their releases. The applicable version Novell uses is: https://landfill.bugzilla.org/bugzilla-3.4-branch/

Great, thanks! -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Mihnea Dobrescu-Balaur

15 May 15 May

13:41

Hello, everybody! I'm having trouble using the XMLRPC interface. I've found some info on the web but I'm stuck. Does bugzilla.novell.com have an xmlrpc.cgi file? I can't seem to find it. Also, what's the preffered way of communicating with a bugzilla instance in python? I've found that I can use one of the two: the pyzilla package, or "manually" built requests sent via http to bugzilla. Thanks for your help! Mihnea DB -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Matt Barringer

14:02

On Sun, 15 May 2011, Mihnea Dobrescu-Balaur wrote:

...

Does bugzilla.novell.com have an xmlrpc.cgi file? I can't seem to find it.

It does, but you'll first need to get through the iChain login. So before you make a call for the first time to the XMLRPC interface, you'll need to POST "username=XXXXX&password=YYYYY" to https://bugzilla.novell.com/ICSLogin/auth-up, and then save the cookies it gives you (there's probably a way to have python do this automatically).

...

From there you can call xmlrpc.cgi just like you would using a normal Bugzilla instance.

But you can't access xmlrpc.cgi from a web browser, if that was confusing you.

...

Also, what's the preffered way of communicating with a bugzilla instance in python? I've found that I can use one of the two: the pyzilla package, or "manually" built requests sent via http to bugzilla.

I'd just use xmlrpclib, personally. It's very easy. Hope that helps, Matt -- Matt Barringer, Software Engineer SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)

Mihnea Dobrescu-Balaur

14:05

On Sun, May 15, 2011 at 5:02 PM, Matt Barringer wrote:

...

On Sun, 15 May 2011, Mihnea Dobrescu-Balaur wrote:

...
Does bugzilla.novell.com have an xmlrpc.cgi file? I can't seem to find it.

It does, but you'll first need to get through the iChain login. So before you make a call for the first time to the XMLRPC interface, you'll need to POST "username=XXXXX&password=YYYYY" to https://bugzilla.novell.com/ICSLogin/auth-up, and then save the cookies it gives you (there's probably a way to have python do this automatically). From there you can call xmlrpc.cgi just like you would using a normal Bugzilla instance.

But you can't access xmlrpc.cgi from a web browser, if that was confusing you.

...
Also, what's the preffered way of communicating with a bugzilla instance in python? I've found that I can use one of the two: the pyzilla package, or "manually" built requests sent via http to bugzilla.

I'd just use xmlrpclib, personally. It's very easy.

Hope that helps,

It does, a lot. Thanks! -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Mihnea Dobrescu-Balaur

14:44

On Sun, May 15, 2011 at 5:02 PM, Matt Barringer wrote:

...

On Sun, 15 May 2011, Mihnea Dobrescu-Balaur wrote:

...
Does bugzilla.novell.com have an xmlrpc.cgi file? I can't seem to find it.

It does, but you'll first need to get through the iChain login. So before you make a call for the first time to the XMLRPC interface, you'll need to POST "username=XXXXX&password=YYYYY" to https://bugzilla.novell.com/ICSLogin/auth-up, and then save the cookies it gives you (there's probably a way to have python do this automatically). From there you can call xmlrpc.cgi just like you would using a normal Bugzilla instance.

Matt, Could you please give me some details on the POST form? If I use a dictionary like this: {'username': 'XXXXX', 'password' : 'YYYYY' } I get Bad Request. If i use a dictionary like: {'login': XXXXXX', 'password' : 'YYYYY'} I get "Missing some field(s). Please try again.". What am I doing wrong? Thanks Mihnea -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Rajko M.

21:10

On Sunday, May 15, 2011 09:44:03 AM Mihnea Dobrescu-Balaur wrote: ...

...

Matt, Could you please give me some details on the POST form? ... What am I doing wrong?

Install Wireshark, or something lighter, to track exchange between your browser and server. Then mimic that with python.

...

Thanks Mihnea

-- Regards, Rajko -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Mihnea Dobrescu-Balaur

30 May 30 May

19:19

Hello everyone! First of all, please excuse me for my delay - I had an important exam today and I really had to be prepared. Moving on, so far I have written a login module[0] that checks if the user has an account or not, logs him in and stores his credentials serialized and base64 encoded in a local file, along with the iChain cookie. Also, I've written a raw concept module[1] for the gathering part of the program - the tool which will auto generate system info in order to help get detailed reports. The code was mostly to show my mentor what I intend it to do (like a proof of concept) and after he's seen it, he gave me some great guidelines. I'm switching to using the subprocess module, JSON for the gathered data to make parsing easy and so on. You can see a raw pastebin of what I'm trying to achieve. This[2] is for the lsmod gatherer. Plans for this week: Finish the gathering modules, write some common 'hub' for them, because in the end product we expect to have something like a gather.d/ folder where programs can install their own gathering modules. Also, as Michal (my mentor) has suggested, I will integrate my code with (or even move entirely to) the python-bugzilla[3] library. All in all, it was an OK week for me. I didn't have so much time as I wanted because I'm still in my exams session, but I really enjoy researching and developing on this project. Have a great week! Mihnea DB [0] https://github.com/mihneadb/Suse-Bug-Reporter/blob/master/login.py [1] https://github.com/mihneadb/Suse-Bug-Reporter/blob/master/gather.py [2] http://pastebin.com/ihmMwjJF [3] https://gitorious.org/opensuse/python-bugzilla/ -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Mihnea Dobrescu-Balaur

22 Jun 22 Jun

14:24

Hello, I'm having trouble using the osc python bindings and was hoping I could get some help here. I'm at the part of figuring out who the maintainer/bug owner of a package is. I managed to do it in the shell, but I am trying to do it via the osc library. My problem is using the meta_exists function from osc.core. I've tried various ways of calling it and I've got no success. The source on gitourious[0] isn't commented so it doesn't really help. Some sample output:

...

...
...
osc.core.meta_exists(metatype='prj', path_args='openSUSE:Factory') makeurl: https://api.opensuse.org ['source/openSUSE:Factory/_meta'] []

-- GET https://api.opensuse.org/source/openSUSE:Factory/_meta Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python2.7/site-packages/osc/core.py", line 2954, in meta_exists data = http_GET(url).readlines() File "/usr/lib/python2.7/site-packages/osc/core.py", line 2661, in http_GET def http_GET(*args, **kwargs): return http_request('GET', *args, **kwargs) File "/usr/lib/python2.7/site-packages/osc/core.py", line 2600, in http_request if conf.is_known_apiurl(url): File "/usr/lib/python2.7/site-packages/osc/conf.py", line 333, in is_known_apiurl return config['api_host_options'].has_key(apiurl) KeyError: 'api_host_options' I don't really understand what's happening. That url after GET is OK and it actually contains the meta information that I need. Any ideas? Thanks! Mihnea DB [0] http://www.gitorious.org/opensuse/osc/blobs/master/osc/core.py - line 3227 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Marcus Hüwe

24 Jun 24 Jun

11:21

On 2011-06-22 17:24:12 +0300, Mihnea Dobrescu-Balaur wrote:

...

Hello,

I'm having trouble using the osc python bindings and was hoping I could get some help here.

I'm at the part of figuring out who the maintainer/bug owner of a package is. I managed to do it in the shell, but I am trying to do it via the osc library.

My problem is using the meta_exists function from osc.core. I've tried various ways of calling it and I've got no success. The source on gitourious[0] isn't commented so it doesn't really help.

Some sample output:

...
...
...
osc.core.meta_exists(metatype='prj', path_args='openSUSE:Factory') makeurl: https://api.opensuse.org ['source/openSUSE:Factory/_meta'] []

-- GET https://api.opensuse.org/source/openSUSE:Factory/_meta Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python2.7/site-packages/osc/core.py", line 2954, in meta_exists data = http_GET(url).readlines() File "/usr/lib/python2.7/site-packages/osc/core.py", line 2661, in http_GET def http_GET(*args, **kwargs): return http_request('GET', *args, **kwargs) File "/usr/lib/python2.7/site-packages/osc/core.py", line 2600, in http_request if conf.is_known_apiurl(url): File "/usr/lib/python2.7/site-packages/osc/conf.py", line 333, in is_known_apiurl return config['api_host_options'].has_key(apiurl) KeyError: 'api_host_options'

I don't really understand what's happening. That url after GET is OK and it actually contains the meta information that I need.

Before you can use osc you have to call osc.conf.get_config() (which requires a ~/.oscrc - it's also possible to specify a different path for the config: osc.conf.get_config(override_conffile='/path/to/oscrc')). Afterwards it should work as expected. I know it is quite "hard" to use the current osc code in a different application but we're currently rewriting the existing code... so it will (probably) be easier in the future:) Marcus -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Mihnea Dobrescu-Balaur

12:00

On Fri, Jun 24, 2011 at 2:21 PM, Marcus Hüwe wrote:

...

On 2011-06-22 17:24:12 +0300, Mihnea Dobrescu-Balaur wrote:

...
Hello,

I'm having trouble using the osc python bindings and was hoping I could get some help here.

I'm at the part of figuring out who the maintainer/bug owner of a package is. I managed to do it in the shell, but I am trying to do it via the osc library.

My problem is using the meta_exists function from osc.core. I've tried various ways of calling it and I've got no success. The source on gitourious[0] isn't commented so it doesn't really help.

Some sample output:

...
...
...
osc.core.meta_exists(metatype='prj', path_args='openSUSE:Factory') makeurl: https://api.opensuse.org ['source/openSUSE:Factory/_meta'] []

-- GET https://api.opensuse.org/source/openSUSE:Factory/_meta Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python2.7/site-packages/osc/core.py", line 2954, in meta_exists data = http_GET(url).readlines() File "/usr/lib/python2.7/site-packages/osc/core.py", line 2661, in http_GET def http_GET(*args, **kwargs): return http_request('GET', *args, **kwargs) File "/usr/lib/python2.7/site-packages/osc/core.py", line 2600, in http_request if conf.is_known_apiurl(url): File "/usr/lib/python2.7/site-packages/osc/conf.py", line 333, in is_known_apiurl return config['api_host_options'].has_key(apiurl) KeyError: 'api_host_options'

I don't really understand what's happening. That url after GET is OK and it actually contains the meta information that I need.

Before you can use osc you have to call osc.conf.get_config() (which requires a ~/.oscrc - it's also possible to specify a different path for the config: osc.conf.get_config(override_conffile='/path/to/oscrc')). Afterwards it should work as expected.

I know it is quite "hard" to use the current osc code in a different application but we're currently rewriting the existing code... so it will (probably) be easier in the future:)

Thanks, my mentor has already pointed it out to me. It worked! Mihnea -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Mihnea Dobrescu-Balaur

1 Jul 1 Jul

21:32

Hello guys, I've implemented the query part of the tool, including the search duplicates functionality. In case you don't want to test it yourself, here's some raw output from the testing phase [0]. Also, all the code is here [1], you are welcome to try using it! :) Have a great weekend! Mihnea DB [0] http://pastebin.com/QpzJSWJM [1] https://github.com/mihneadb/suse_bug_reporter -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Mihnea Dobrescu-Balaur

18 Aug 18 Aug

08:31

Hello everybody, Just so you know, the tool is now packaged and you can try installing it. The bin's name is bugreporter. I've also provided a man page - man bugreporter. https://build.opensuse.org/package/show?package=suse-bug-reporter&project=home%3Amihneadb You also need to install python-bugzilla 0.6.2, which can be found in the Factory repo atm. Mihnea -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

4640

Age (days ago)

4789

Last active (days ago)

List overview

Download

37 comments

10 participants

participants (10)

Christian Boltz
Dominique Leuenberger
Dominique Leuenberger a.k.a DimStar
Greg Freemyer
Jos Poortvliet
Marcus Hüwe
Matt Barringer
Mihnea Dobrescu-Balaur
Rajko M.
Vincent Untz