[opensuse-project] Suse Bug Reporter - GSoC midterm report
Hello everyone, The expected/requested functionalities for the project are done. I'm talking about the CLI version of the tool. Its main functionalities are splitted in four categories at the moment: * aid - helps the user to determine which is the „suspected” package that causes a problem * gather - scans the system for relevant data to provide in a bug report or to someone that helps, via IRC let's say * query - search the Bugzilla instance for bug reports that fit given keywords and sorts them by relevance * submit - gets input from the user and submits the bug report to Bugzilla Underlying nice stuff: * duplicate search - this feature was very wanted from what I could tell. I managed to implement it using a sorting by relevance of bug reports. From what I could see in the tests I've done, it works great. Also, it supports "excluded words" functionality. * get assignee + maintainers - I use data from the rpm and then get the relevant information via OBS, using it's python bindings, not the shell tool * check account - verifies that the user has a valid account and if so, it stores the user's credentials in a hidden file, base64 encrypted and pickled to make them not human readable; if the data is stored, the user isn't prompted again for username & password when interacting with bugzilla * globbing : when searching for a package, you can also do something like search for ' kde* ' and it will show you what packages match * searching local rpm database: it also looks in 'provides', not only in 'name' There are also some other things that I've implemented by necessity, but I think the ones listed above are the ones that deserve to be mentioned in this report. Some sample usage for submitting is here [0]. You can find the repo here: [1] There is more to the tool that I can think of right now, so if you got any questions, fire away! I intend to do also a GUI version but I don't know what to use. Maybe if libYUI comes along nicely I could use it. What do you think? Also, I'll research what I can do to have maybe the bug reporter pop up when something crashes. I'm thinking of listening for specific signals, like SIGSEGV. Any suggestions are welcome! Have a nice week! Mihnea [0] http://pastebin.com/qxXy5S28 [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
Hello, most important thing first: your bugreporting tool (at least what I've seen in the usage example) looks good :-) Nevertheless, there are always things that can be improved. You probably already know/remember I'm scaring each and every developer with bugreports, and you are not an exception ;-) on Montag, 11. Juli 2011, Mihnea Dobrescu-Balaur wrote:
* aid - helps the user to determine which is the „suspected” package that causes a problem
Can you paste an example, please?
* check account - verifies that the user has a valid account and if so, it stores the user's credentials in a hidden file, base64 encrypted and pickled to make them not human readable; if the data is
Just for the records: base64 does not mean "encryption", it's only "make it unreadable for humans".
Some sample usage for submitting is here [0].
I'll include parts of the sample usage in the mail:
These are the similar bug reports found 0. python-django-annoying just scheduled and can't commit to OBS
Do you want to contribute to one of the bug reports above or submit a new one? yes (contribute)/no (new one) Yes: contribute No: submit new
Answer: no
Instead of yes/no, something self-explaining would be good - maybe c/n for [c]ontribute / [n]ew And please include the bug number of the "similar bug reports" in the output so that I can check the content if needed.
Getting list of components from Bugzilla for product openSUSE 11.4. Available components: 0. Apache 1. AppArmor 2. AutoYaST 3. Banshee 4. Basesystem 5. Bootloader 6. Commercial 7. Compiz 8. Development 9. Documentation 10. Evolution 11. Firefox [...] Which one? Enter a valid index number between 0 and 48: Index: 8 Using component Development.
The component is a difficult beast (in general, not only in your tool) - the question is if there is some way to autodetect it based on the package name. The special thing in your tool is that you already know the package (and therefore the assignee), which makes the component less important (but not superfluous, it's still needed for QA contact, statistics etc.). Besides that, I'd say you should avoid index "0" - humans usually start at 1 ;-) (that's valid for more "choose one" options)
This/these address(es) were found: assignee: bg@suse.com
I wonder about the assignee - osc maintainer openSUSE:11.4 python gives me jmatejek@, not bg@.
cc: ['mrueckert@suse.com', 'ro@suse.com', 'cgardner@novell.com']
Just curious: where do you get the CC list from? I can't get any of those people via "osc maintainer".
Do you want to change the assignee? Yes/No
Answer: no Do you want to add another cc(s)? Yes/No
Answer: no
What about an option to remove someone from the default CC list?
Please describe the impact of the bug, choose a severity for the issue. Available severities: 0. Blocker
"Blocker" is a separate field in bnc, not an option for severity.
1. Critical 2. Major 3. Normal 4. Minor 5. Enhancement
Would you like to see their descriptions? Yes/No
Answer: 3 Invalid answer: yes/no only! Try again: no
Thanks for showing this usability bug yourself ;-) I like the concept zypper uses - in this case it woul mean "enter a number to choose the severity, or ? to see the description" It does not annoy users with "do you need help" questions, but still offers help for those who need it.
Which one? Enter a valid index number between 0 and 5: Index: 3
Do you want to add an automatically gathered system description? Yes/No
Answer: yes
Is the system description gathering the same for all reports or do you have some special handling to include specific logs - for example the y2logs when reporting a YaST bug, zypper.log for zypper, X.org*.log for X bugs, ...? BTW: Is there a real bugreport in bnc that was created with your tool? OK, that are enough bugreports, enhancement requests and questions for one mail ;-) No, wait, I have one more:
You can find the repo here: [1]
An OBS repo with a nice RPM package would be nice ;-) Regards, Christian Boltz -- Funktionieren Windows 98-Witze auch unter Windows 2000 oder braucht man da ein Update? -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Mon, Jul 11, 2011 at 11:32 PM, Christian Boltz
Hello,
most important thing first: your bugreporting tool (at least what I've seen in the usage example) looks good :-)
Thank you! :)
Nevertheless, there are always things that can be improved. You probably already know/remember I'm scaring each and every developer with bugreports, and you are not an exception ;-)
on Montag, 11. Juli 2011, Mihnea Dobrescu-Balaur wrote:
* aid - helps the user to determine which is the „suspected” package that causes a problem
Can you paste an example, please?
At the moment the only thing now is a prompt to click on the window of the program that you want to report against and it will return the package name via xprop WM_CLASS. Can't paste you an example right now because I'm replying from my macbook.
* check account - verifies that the user has a valid account and if so, it stores the user's credentials in a hidden file, base64 encrypted and pickled to make them not human readable; if the data is
Just for the records: base64 does not mean "encryption", it's only "make it unreadable for humans".
Of course, but I did say that. ( "to make them not human readable" )
Some sample usage for submitting is here [0].
I'll include parts of the sample usage in the mail:
These are the similar bug reports found 0. python-django-annoying just scheduled and can't commit to OBS
Do you want to contribute to one of the bug reports above or submit a new one? yes (contribute)/no (new one) Yes: contribute No: submit new
Answer: no
Instead of yes/no, something self-explaining would be good - maybe c/n for [c]ontribute / [n]ew
Sure, I can do that.
And please include the bug number of the "similar bug reports" in the output so that I can check the content if needed.
Well, you can see the list and if you pick one to contribute to it gives you the bug number and an URL to it. But no problem, I can also add the bug number in the list.
Getting list of components from Bugzilla for product openSUSE 11.4. Available components: 0. Apache 1. AppArmor 2. AutoYaST 3. Banshee 4. Basesystem 5. Bootloader 6. Commercial 7. Compiz 8. Development 9. Documentation 10. Evolution 11. Firefox [...] Which one? Enter a valid index number between 0 and 48: Index: 8 Using component Development.
The component is a difficult beast (in general, not only in your tool) - the question is if there is some way to autodetect it based on the package name. The special thing in your tool is that you already know the package (and therefore the assignee), which makes the component less important (but not superfluous, it's still needed for QA contact, statistics etc.).
My mentor said not to focus on this because of the assignee part, just like you said. But stil, from what I've said, I have a path from the rpm info, I could use that. I will check.
Besides that, I'd say you should avoid index "0" - humans usually start at 1 ;-) (that's valid for more "choose one" options)
I do place the index number near each entry, but if everybody agrees, sure, I can shift the numbering, it's easy to do.
This/these address(es) were found: assignee: bg@suse.com
I wonder about the assignee - osc maintainer openSUSE:11.4 python gives me jmatejek@, not bg@.
cc: ['mrueckert@suse.com', 'ro@suse.com', 'cgardner@novell.com']
Just curious: where do you get the CC list from? I can't get any of those people via "osc maintainer".
Make sure you check the devel package. My tool uses osc to check if the package has a devel package associated and, if so, it gets the people from that one. You can check the code here [0]. From what I tested via some manual queries when I was working on it, it was fine.
Do you want to change the assignee? Yes/No
Answer: no Do you want to add another cc(s)? Yes/No
Answer: no
What about an option to remove someone from the default CC list?
I didn't want to have too many prompts, but I guess you are right, it wouldn't hurt.
Please describe the impact of the bug, choose a severity for the issue. Available severities: 0. Blocker
"Blocker" is a separate field in bnc, not an option for severity.
I did not know that, I've inspired that part from some code of Michal's (my mentor) and that's the way he used it. I'm not sure where to put that info in the bug report dictionary, but I'll check again the source code of python-bugzilla.
1. Critical 2. Major 3. Normal 4. Minor 5. Enhancement
Would you like to see their descriptions? Yes/No
Answer: 3 Invalid answer: yes/no only! Try again: no
Thanks for showing this usability bug yourself ;-)
All the prompts are like that. You can find the functions for console input/output in the util/console.py module.
I like the concept zypper uses - in this case it woul mean "enter a number to choose the severity, or ? to see the description"
I can do that.
It does not annoy users with "do you need help" questions, but still offers help for those who need it.
Which one? Enter a valid index number between 0 and 5: Index: 3
Do you want to add an automatically gathered system description? Yes/No
Answer: yes
Is the system description gathering the same for all reports or do you have some special handling to include specific logs - for example the y2logs when reporting a YaST bug, zypper.log for zypper, X.org*.log for X bugs, ...?
At the moment, I only gather what you have seen in the sample. If anybody would help me with what kind of .log would be needed for what package, I could make some conditionals, of course. The code allows that easily, I'd say. I'm not sure about the add attachment functionality (via python-bugzilla, I mean), but I could just append them at the end of the report, right? Or maybe paste them automatically to a service like pastebin and add the link to the report? What do you say?
BTW: Is there a real bugreport in bnc that was created with your tool?
Short answer: no. I completed all the above last week, but I didn't want to make a report on the running Bugzila instance because I was afraid not to cause trouble, so I asked my mentor to check it and test it on the testing Bugzilla instance (we've agreed on that a while ago). He was in vacation last week and I didn't find anybody else with rights to use that instance. Anyway, submitting the bug is a matter of: bug = self.bz.createbug(**self.data), and the data dict is created correctly. The tool is ready, just need to test sending a bug report.
OK, that are enough bugreports, enhancement requests and questions for one mail ;-)
No, wait, I have one more:
I thought so! :-P
You can find the repo here: [1]
An OBS repo with a nice RPM package would be nice ;-)
I've never done that and I don't know how, but I will read the wiki and whatever I can find on the net and I'll package it. I was waiting on my mentor's input but then the midterm came and I figured I'd better send the report also here. :)
Regards,
Christian Boltz
Thanks a lot for your ideas! -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tue, Jul 12, 2011 at 1:12 AM, Mihnea Dobrescu-Balaur
On Mon, Jul 11, 2011 at 11:32 PM, Christian Boltz
wrote: Hello,
most important thing first: your bugreporting tool (at least what I've seen in the usage example) looks good :-)
Thank you! :)
Nevertheless, there are always things that can be improved. You probably already know/remember I'm scaring each and every developer with bugreports, and you are not an exception ;-)
on Montag, 11. Juli 2011, Mihnea Dobrescu-Balaur wrote:
* aid - helps the user to determine which is the „suspected” package that causes a problem
Can you paste an example, please?
At the moment the only thing now is a prompt to click on the window of the program that you want to report against and it will return the package name via xprop WM_CLASS. Can't paste you an example right now because I'm replying from my macbook.
There: http://pastebin.com/uUHFD29K
* check account - verifies that the user has a valid account and if so, it stores the user's credentials in a hidden file, base64 encrypted and pickled to make them not human readable; if the data is
Just for the records: base64 does not mean "encryption", it's only "make it unreadable for humans".
Of course, but I did say that. ( "to make them not human readable" )
Some sample usage for submitting is here [0].
I'll include parts of the sample usage in the mail:
These are the similar bug reports found 0. python-django-annoying just scheduled and can't commit to OBS
Do you want to contribute to one of the bug reports above or submit a new one? yes (contribute)/no (new one) Yes: contribute No: submit new
Answer: no
Instead of yes/no, something self-explaining would be good - maybe c/n for [c]ontribute / [n]ew
Sure, I can do that.
I've made a function that takes the options as arguments and generates the output automatically. It works nicely. See here: https://github.com/mihneadb/suse_bug_reporter/blob/master/util/console.py#L3...
And please include the bug number of the "similar bug reports" in the output so that I can check the content if needed.
Well, you can see the list and if you pick one to contribute to it gives you the bug number and an URL to it. But no problem, I can also add the bug number in the list.
Done. Also, I've modified the generic function I've made to work that way. See here https://github.com/mihneadb/suse_bug_reporter/blob/master/util/console.py#L1...
Getting list of components from Bugzilla for product openSUSE 11.4. Available components: 0. Apache 1. AppArmor 2. AutoYaST 3. Banshee 4. Basesystem 5. Bootloader 6. Commercial 7. Compiz 8. Development 9. Documentation 10. Evolution 11. Firefox [...] Which one? Enter a valid index number between 0 and 48: Index: 8 Using component Development.
The component is a difficult beast (in general, not only in your tool) - the question is if there is some way to autodetect it based on the package name. The special thing in your tool is that you already know the package (and therefore the assignee), which makes the component less important (but not superfluous, it's still needed for QA contact, statistics etc.).
My mentor said not to focus on this because of the assignee part, just like you said. But stil, from what I've said, I have a path from the rpm info, I could use that. I will check.
I've done some further checking. The only help I get is from the 'group' tag in the rpm header. Unfortunately, it doesn't really help. Here's what I mean: For konsole, I get System/X11/Terminals; For rhythmbox, I get Productivity/Multimedia/Sound/Players I've looked in everything that the rpm contains (see here: http://pastebin.com/PnaZvGdA ) and I can't find anything that would help to automatically detect the component. If anybody has an idea, maybe something via osc, please let me know.
Besides that, I'd say you should avoid index "0" - humans usually start at 1 ;-) (that's valid for more "choose one" options)
I do place the index number near each entry, but if everybody agrees, sure, I can shift the numbering, it's easy to do.
Also done, numbering starts from 1 in the output.
This/these address(es) were found: assignee: bg@suse.com
I wonder about the assignee - osc maintainer openSUSE:11.4 python gives me jmatejek@, not bg@.
cc: ['mrueckert@suse.com', 'ro@suse.com', 'cgardner@novell.com']
Just curious: where do you get the CC list from? I can't get any of those people via "osc maintainer".
Make sure you check the devel package. My tool uses osc to check if the package has a devel package associated and, if so, it gets the people from that one. You can check the code here [0]. From what I tested via some manual queries when I was working on it, it was fine.
Do you want to change the assignee? Yes/No
Answer: no Do you want to add another cc(s)? Yes/No
Answer: no
What about an option to remove someone from the default CC list?
I didn't want to have too many prompts, but I guess you are right, it wouldn't hurt.
Done.
Please describe the impact of the bug, choose a severity for the issue. Available severities: 0. Blocker
"Blocker" is a separate field in bnc, not an option for severity.
I did not know that, I've inspired that part from some code of Michal's (my mentor) and that's the way he used it. I'm not sure where to put that info in the bug report dictionary, but I'll check again the source code of python-bugzilla.
Still don't know.
1. Critical 2. Major 3. Normal 4. Minor 5. Enhancement
Would you like to see their descriptions? Yes/No
Answer: 3 Invalid answer: yes/no only! Try again: no
Thanks for showing this usability bug yourself ;-)
All the prompts are like that. You can find the functions for console input/output in the util/console.py module.
I like the concept zypper uses - in this case it woul mean "enter a number to choose the severity, or ? to see the description"
I can do that.
Done, but not with the '?' option. It shows you the list with descriptions aside from the start, since they fit OK anyway.
It does not annoy users with "do you need help" questions, but still offers help for those who need it.
Which one? Enter a valid index number between 0 and 5: Index: 3
Do you want to add an automatically gathered system description? Yes/No
Answer: yes
Is the system description gathering the same for all reports or do you have some special handling to include specific logs - for example the y2logs when reporting a YaST bug, zypper.log for zypper, X.org*.log for X bugs, ...?
At the moment, I only gather what you have seen in the sample. If anybody would help me with what kind of .log would be needed for what package, I could make some conditionals, of course. The code allows that easily, I'd say. I'm not sure about the add attachment functionality (via python-bugzilla, I mean), but I could just append them at the end of the report, right? Or maybe paste them automatically to a service like pastebin and add the link to the report? What do you say?
Nothing new here.
BTW: Is there a real bugreport in bnc that was created with your tool?
Short answer: no. I completed all the above last week, but I didn't want to make a report on the running Bugzila instance because I was afraid not to cause trouble, so I asked my mentor to check it and test it on the testing Bugzilla instance (we've agreed on that a while ago). He was in vacation last week and I didn't find anybody else with rights to use that instance. Anyway, submitting the bug is a matter of: bug = self.bz.createbug(**self.data), and the data dict is created correctly. The tool is ready, just need to test sending a bug report.
OK, that are enough bugreports, enhancement requests and questions for one mail ;-)
No, wait, I have one more:
I thought so! :-P
You can find the repo here: [1]
An OBS repo with a nice RPM package would be nice ;-)
I've never done that and I don't know how, but I will read the wiki and whatever I can find on the net and I'll package it. I was waiting on my mentor's input but then the midterm came and I figured I'd better send the report also here. :)
Regards,
Christian Boltz
Thanks a lot for your ideas!
Mihnea -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Hello, on Dienstag, 12. Juli 2011, Mihnea Dobrescu-Balaur wrote:
On Tue, Jul 12, 2011 at 1:12 AM, Mihnea Dobrescu-Balaur wrote:
On Mon, Jul 11, 2011 at 11:32 PM, Christian Boltz wrote:
on Montag, 11. Juli 2011, Mihnea Dobrescu-Balaur wrote:
* aid - helps the user to determine which is the „suspected” package that causes a problem
Can you paste an example, please?
At the moment the only thing now is a prompt to click on the window of the program that you want to report against and it will return the package name via xprop WM_CLASS. Can't paste you an example right now because I'm replying from my macbook.
There: http://pastebin.com/uUHFD29K
Look good and really useful for people who prefer the mouse :-) (Console users will know the program name anyway.)
* check account - verifies that the user has a valid account and if so, it stores the user's credentials in a hidden file, base64 encrypted and pickled to make them not human readable; if the data is
Just for the records: base64 does not mean "encryption", it's only "make it unreadable for humans".
Of course, but I did say that. ( "to make them not human readable" )
Well, you shouldn't have used the word "encrypted". Yes, I know that's nitpicking ;-)
Some sample usage for submitting is here [0].
I'll include parts of the sample usage in the mail:
Do you want to contribute to one of the bug reports above or submit a new one? yes (contribute)/no (new one)
Yes: contribute No: submit new
Answer: no
Instead of yes/no, something self-explaining would be good - maybe c/n for [c]ontribute / [n]ew
Sure, I can do that.
I've made a function that takes the options as arguments and generates the output automatically. It works nicely. See here: https://github.com/mihneadb/suse_bug_reporter/blob/master/util/consol e.py#L36
Your code has a small bug: What happens if you display the options "contribute" and "create new"? In short: you'll get the shortcut "c" for both. Something like this might happen if someone translates the options and also if you accidently provide two options with the same first letter. I'm afraid you'll have to check for duplicate shortcuts and use the second/third/forth/... character (until you find a unused one).
And please include the bug number of the "similar bug reports" in the output so that I can check the content if needed.
Well, you can see the list and if you pick one to contribute to it gives you the bug number and an URL to it. But no problem, I can also add the bug number in the list.
BTW: The reason why I'm asking for the bug number is that it isn't always easy to tell from only the bug summary if I'm going to report a duplicate or a different issue.
Done. Also, I've modified the generic function I've made to work that
Thanks!
The component is a difficult beast (in general, not only in your
My mentor said not to focus on this because of the assignee part, just like you said. But stil, from what I've said, I have a path from the rpm info, I could use that. I will check.
I've done some further checking. The only help I get is from the 'group' tag in the rpm header. Unfortunately, it doesn't really help. Here's what I mean: For konsole, I get System/X11/Terminals; For rhythmbox, I get Productivity/Multimedia/Sound/Players
I've looked in everything that the rpm contains (see here: http://pastebin.com/PnaZvGdA ) and I can't find anything that would help to automatically detect the component. If anybody has an idea, maybe something via osc, please let me know.
AFAIK there is no automatic way to autodetect the correct bugzilla component :-( You might be able to do some autodetection based on the Requires (if something requires kdelibs4, it is probably a KDE application ;-) but that isn't a real solution. Another option might be to check if the package is in any pattern - but again that's not a real solution. If it comforts you: even seasoned bug reporters sometimes have to guess which component is the best match. "Basesystem" is always a good fallback for programs that run in a console, and "Basesystem" or "Network" are nice fallbacks for various daemons (except Apache, which has its own component). BTW: Security bugs are restricted to the security team by default - does you tool have this special handling? (And an option to make it public?)
Besides that, I'd say you should avoid index "0" - humans usually start at 1 ;-) (that's valid for more "choose one" options)
I do place the index number near each entry, but if everybody agrees, sure, I can shift the numbering, it's easy to do.
Also done, numbering starts from 1 in the output.
:-)
This/these address(es) were found: assignee: bg@suse.com
I wonder about the assignee - osc maintainer openSUSE:11.4 python gives me jmatejek@, not bg@.
cc: ['mrueckert@suse.com', 'ro@suse.com', 'cgardner@novell.com']
Just curious: where do you get the CC list from? I can't get any of those people via "osc maintainer".
Make sure you check the devel package. My tool uses osc to check if the package has a devel package associated and, if so, it gets the people from that one. You can check the code here [0]. From what I tested via some manual queries when I was working on it, it was fine.
You forgot to add the link referred as [0]...
Please describe the impact of the bug, choose a severity for the issue. Available severities: 0. Blocker
"Blocker" is a separate field in bnc, not an option for severity.
I did not know that, I've inspired that part from some code of Michal's (my mentor) and that's the way he used it. I'm not sure where to put that info in the bug report dictionary, but I'll check again the source code of python-bugzilla.
Michal's code is probably not up-to-date - the separate blocker field exists since (I guess) two years. Before that, blocker was part of the severity.
1. Critical 2. Major 3. Normal 4. Minor 5. Enhancement
Would you like to see their descriptions? Yes/No
Answer: 3 Invalid answer: yes/no only! Try again: no
Thanks for showing this usability bug yourself ;-)
All the prompts are like that. You can find the functions for console input/output in the util/console.py module.
I don't complain about the yes/no prompt itsself - the issue is that the question "do you need help?" is/was unexpected.
I like the concept zypper uses - in this case it woul mean "enter a number to choose the severity, or ? to see the description"
I can do that.
Done, but not with the '?' option. It shows you the list with descriptions aside from the start, since they fit OK anyway.
OK.
Is the system description gathering the same for all reports or do you have some special handling to include specific logs - for example the y2logs when reporting a YaST bug, zypper.log for zypper, X.org*.log for X bugs, ...?
At the moment, I only gather what you have seen in the sample. If anybody would help me with what kind of .log would be needed for what package, I could make some conditionals, of course. The code allows that easily, I'd say. I'm not sure about the add attachment functionality (via python-bugzilla, I mean), but I could just append them at the end of the report, right? Or maybe paste them automatically to a service like pastebin and add the link to the report? What do you say?
http://en.opensuse.org/openSUSE:Submitting_bug_reports#Reporting_a_bug contains instructions for various components. Reading them should give you some insight. The logs should be uploaded as bugzilla attachments. I'm not sure if compression always makes sense - maybe something like "compress everything that is > 300 kB" would be a good rule. BTW: The YaST logs are automatically compressed if you call "save_y2logs". Please don't append them to the report text itsself - having a 300 kB logfile included in the bug description will give you a very big chance of being killed ;-) (IMHO up to 10 log lines are OK in the bug description.)
BTW: Is there a real bugreport in bnc that was created with your tool?
Short answer: no. I completed all the above last week, but I didn't want to make a report on the running Bugzila instance because I was afraid not to cause trouble, so I asked my mentor to check it and test it on the testing Bugzilla instance (we've agreed on that a while ago). He was in vacation last week and I didn't find anybody else with rights to use that instance.
OK. Once you have a sample bug report in public bugzilla, please post the bug number ;-)
An OBS repo with a nice RPM package would be nice ;-)
I've never done that and I don't know how, but I will read the wiki and whatever I can find on the net and I'll package it. I was waiting on my mentor's input but then the midterm came and I figured I'd better send the report also here. :)
http://en.opensuse.org/openSUSE:Packaging_guidelines http://en.opensuse.org/openSUSE:Packaging_Python You can also ask on the opensuse-packaging mailinglist if you have specific questions. Regards, Christian Boltz --
ganz im Gegensatz zu dir süffisanten Personal-Firewall-/-Knallkopp. cool ... du bist ja putzig. Geh mal einen Psychologen aufsuchen. ich dachte ich bin der Psychologe. soll ich mich also selber aufsuchen, ja? [> Timo Nentwig und Michael Meyer in suse-linux] -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tue, Jul 12, 2011 at 7:25 PM, Christian Boltz
Hello,
on Dienstag, 12. Juli 2011, Mihnea Dobrescu-Balaur wrote:
On Tue, Jul 12, 2011 at 1:12 AM, Mihnea Dobrescu-Balaur wrote:
On Mon, Jul 11, 2011 at 11:32 PM, Christian Boltz wrote:
on Montag, 11. Juli 2011, Mihnea Dobrescu-Balaur wrote:
* aid - helps the user to determine which is the „suspected” package that causes a problem
Can you paste an example, please?
At the moment the only thing now is a prompt to click on the window of the program that you want to report against and it will return the package name via xprop WM_CLASS. Can't paste you an example right now because I'm replying from my macbook.
There: http://pastebin.com/uUHFD29K
Look good and really useful for people who prefer the mouse :-) (Console users will know the program name anyway.)
Indeed, it's intended to work for all users. :)
* check account - verifies that the user has a valid account and if so, it stores the user's credentials in a hidden file, base64 encrypted and pickled to make them not human readable; if the data is
Just for the records: base64 does not mean "encryption", it's only "make it unreadable for humans".
Of course, but I did say that. ( "to make them not human readable" )
Well, you shouldn't have used the word "encrypted". Yes, I know that's nitpicking ;-)
Sure is, but yes, you are right. I should have said encoded. Although, it's a matter of nuance. But anyway. You are right.
Some sample usage for submitting is here [0].
I'll include parts of the sample usage in the mail:
Do you want to contribute to one of the bug reports above or submit a new one? yes (contribute)/no (new one)
Yes: contribute No: submit new
Answer: no
Instead of yes/no, something self-explaining would be good - maybe c/n for [c]ontribute / [n]ew
Sure, I can do that.
I've made a function that takes the options as arguments and generates the output automatically. It works nicely. See here: https://github.com/mihneadb/suse_bug_reporter/blob/master/util/consol e.py#L36
Your code has a small bug: What happens if you display the options "contribute" and "create new"? In short: you'll get the shortcut "c" for both.
Yes, I noticed that when I was typing but I figured it can be solved by using another word. I will implement what you said, but it's rather inefficient and not really necessary in my opinion. I mean, checking that those words don't overlap is a quadratic complexity problem. Sure, the data size should be small. I'll look into it but for now I'll just keep it like that and document it. It's better anyway imo than writing it up by hand just for that one use case.
Something like this might happen if someone translates the options and also if you accidently provide two options with the same first letter.
I'm afraid you'll have to check for duplicate shortcuts and use the second/third/forth/... character (until you find a unused one).
And please include the bug number of the "similar bug reports" in the output so that I can check the content if needed.
Well, you can see the list and if you pick one to contribute to it gives you the bug number and an URL to it. But no problem, I can also add the bug number in the list.
BTW: The reason why I'm asking for the bug number is that it isn't always easy to tell from only the bug summary if I'm going to report a duplicate or a different issue.
I understand, you are right.
Done. Also, I've modified the generic function I've made to work that
Thanks!
The component is a difficult beast (in general, not only in your
My mentor said not to focus on this because of the assignee part, just like you said. But stil, from what I've said, I have a path from the rpm info, I could use that. I will check.
I've done some further checking. The only help I get is from the 'group' tag in the rpm header. Unfortunately, it doesn't really help. Here's what I mean: For konsole, I get System/X11/Terminals; For rhythmbox, I get Productivity/Multimedia/Sound/Players
I've looked in everything that the rpm contains (see here: http://pastebin.com/PnaZvGdA ) and I can't find anything that would help to automatically detect the component. If anybody has an idea, maybe something via osc, please let me know.
AFAIK there is no automatic way to autodetect the correct bugzilla component :-(
You might be able to do some autodetection based on the Requires (if something requires kdelibs4, it is probably a KDE application ;-) but that isn't a real solution.
Another option might be to check if the package is in any pattern - but again that's not a real solution.
If it comforts you: even seasoned bug reporters sometimes have to guess which component is the best match. "Basesystem" is always a good fallback for programs that run in a console, and "Basesystem" or "Network" are nice fallbacks for various daemons (except Apache, which has its own component).
None of the above represents a general solution that works for any package. The components list isn't that big and it's quite intuitive so I think it's okay to leave it like that for now.
BTW: Security bugs are restricted to the security team by default - does you tool have this special handling? (And an option to make it public?)
I don't know about that. I will look into it, thanks for the heads up!
Besides that, I'd say you should avoid index "0" - humans usually start at 1 ;-) (that's valid for more "choose one" options)
I do place the index number near each entry, but if everybody agrees, sure, I can shift the numbering, it's easy to do.
Also done, numbering starts from 1 in the output.
:-)
This/these address(es) were found: assignee: bg@suse.com
I wonder about the assignee - osc maintainer openSUSE:11.4 python gives me jmatejek@, not bg@.
cc: ['mrueckert@suse.com', 'ro@suse.com', 'cgardner@novell.com']
Just curious: where do you get the CC list from? I can't get any of those people via "osc maintainer".
Make sure you check the devel package. My tool uses osc to check if the package has a devel package associated and, if so, it gets the people from that one. You can check the code here [0]. From what I tested via some manual queries when I was working on it, it was fine.
You forgot to add the link referred as [0]...
Please excuse me. This was the link: https://github.com/mihneadb/suse_bug_reporter/blob/master/util/packageInfo.p... You should scroll down from there, that's where the magic happens.
Please describe the impact of the bug, choose a severity for the issue. Available severities: 0. Blocker
"Blocker" is a separate field in bnc, not an option for severity.
I did not know that, I've inspired that part from some code of Michal's (my mentor) and that's the way he used it. I'm not sure where to put that info in the bug report dictionary, but I'll check again the source code of python-bugzilla.
Michal's code is probably not up-to-date - the separate blocker field exists since (I guess) two years. Before that, blocker was part of the severity.
I'll ask. :)
1. Critical 2. Major 3. Normal 4. Minor 5. Enhancement
Would you like to see their descriptions? Yes/No
Answer: 3 Invalid answer: yes/no only! Try again: no
Thanks for showing this usability bug yourself ;-)
All the prompts are like that. You can find the functions for console input/output in the util/console.py module.
I don't complain about the yes/no prompt itsself - the issue is that the question "do you need help?" is/was unexpected.
I like the concept zypper uses - in this case it woul mean "enter a number to choose the severity, or ? to see the description"
I can do that.
Done, but not with the '?' option. It shows you the list with descriptions aside from the start, since they fit OK anyway.
OK.
Is the system description gathering the same for all reports or do you have some special handling to include specific logs - for example the y2logs when reporting a YaST bug, zypper.log for zypper, X.org*.log for X bugs, ...?
At the moment, I only gather what you have seen in the sample. If anybody would help me with what kind of .log would be needed for what package, I could make some conditionals, of course. The code allows that easily, I'd say. I'm not sure about the add attachment functionality (via python-bugzilla, I mean), but I could just append them at the end of the report, right? Or maybe paste them automatically to a service like pastebin and add the link to the report? What do you say?
http://en.opensuse.org/openSUSE:Submitting_bug_reports#Reporting_a_bug contains instructions for various components. Reading them should give you some insight.
The logs should be uploaded as bugzilla attachments. I'm not sure if compression always makes sense - maybe something like "compress everything that is > 300 kB" would be a good rule. BTW: The YaST logs are automatically compressed if you call "save_y2logs".
Please don't append them to the report text itsself - having a 300 kB logfile included in the bug description will give you a very big chance of being killed ;-) (IMHO up to 10 log lines are OK in the bug description.)
OK, I will work on implementing this.
BTW: Is there a real bugreport in bnc that was created with your tool?
Short answer: no. I completed all the above last week, but I didn't want to make a report on the running Bugzila instance because I was afraid not to cause trouble, so I asked my mentor to check it and test it on the testing Bugzilla instance (we've agreed on that a while ago). He was in vacation last week and I didn't find anybody else with rights to use that instance.
OK. Once you have a sample bug report in public bugzilla, please post the bug number ;-)
Of course, I will.
An OBS repo with a nice RPM package would be nice ;-)
I've never done that and I don't know how, but I will read the wiki and whatever I can find on the net and I'll package it. I was waiting on my mentor's input but then the midterm came and I figured I'd better send the report also here. :)
http://en.opensuse.org/openSUSE:Packaging_guidelines http://en.opensuse.org/openSUSE:Packaging_Python
You can also ask on the opensuse-packaging mailinglist if you have specific questions.
On it.
Regards,
Christian Boltz --
Thanks again for your input! Mihnea DB -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Wednesday 13 July 2011 01:38:57 Mihnea Dobrescu-Balaur wrote:
http://en.opensuse.org/openSUSE:Packaging_guidelines http://en.opensuse.org/openSUSE:Packaging_Python
You can also ask on the opensuse-packaging mailinglist if you have specific questions.
you can also drop in opensuse-kde, opensuse-factory or opensuse-buildservice irc channels and ask... we should be able to help... Alin -- Without Questions there are no Answers! _____________________________________________________________________ Alin Marin ELENA Advanced Molecular Simulation Research Laboratory School of Physics, University College Dublin ---- Ardionsamblú Móilíneach Saotharlann Taighde Scoil na Fisice, An Coláiste Ollscoile, Baile Átha Cliath ----------------------------------------------------------------------------------- http://alin.elenaworld.net ______________________________________________________________________
On Wed, Jul 13, 2011 at 1:45 AM, Alin Marin Elena
On Wednesday 13 July 2011 01:38:57 Mihnea Dobrescu-Balaur wrote:
http://en.opensuse.org/openSUSE:Packaging_guidelines http://en.opensuse.org/openSUSE:Packaging_Python
You can also ask on the opensuse-packaging mailinglist if you have specific questions.
you can also drop in opensuse-kde, opensuse-factory or opensuse-buildservice irc channels and ask... we should be able to help...
I sure will, thanks!
Without Questions there are no Answers!
Exactly! :) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Hello, on Mittwoch, 13. Juli 2011, Mihnea Dobrescu-Balaur wrote:
On Tue, Jul 12, 2011 at 7:25 PM, Christian Boltz wrote:
on Dienstag, 12. Juli 2011, Mihnea Dobrescu-Balaur wrote:
On Tue, Jul 12, 2011 at 1:12 AM, Mihnea Dobrescu-Balaur wrote:
On Mon, Jul 11, 2011 at 11:32 PM, Christian Boltz wrote:
on Montag, 11. Juli 2011, Mihnea Dobrescu-Balaur wrote:
Your code has a small bug: What happens if you display the options "contribute" and "create new"? In short: you'll get the shortcut "c" for both.
Yes, I noticed that when I was typing but I figured it can be solved by using another word. I will implement what you said, but it's rather inefficient and not really necessary in my opinion. I mean, checking that those words don't overlap is a quadratic complexity problem. Sure, the data size should be small. I'll look into it but for now I'll just keep it like that and document it. It's better anyway imo than writing it up by hand just for that one use case.
OK.
This/these address(es) were found: assignee: bg@suse.com
I wonder about the assignee - osc maintainer openSUSE:11.4 python gives me jmatejek@, not bg@.
cc: ['mrueckert@suse.com', 'ro@suse.com', 'cgardner@novell.com']
Just curious: where do you get the CC list from? I can't get any of those people via "osc maintainer".
Make sure you check the devel package. My tool uses osc to check if the package has a devel package associated and, if so, it gets the people from that one.
I just did (see below) and still couldn't find those people.
You can check the code here [0]. From what I tested via some manual queries when I was working on it, it was fine.
https://github.com/mihneadb/suse_bug_reporter/blob/master/util/packag eInfo.py#L123
You should scroll down from there, that's where the magic happens.
Reading your code, I think the most important/relevant function is getAssignedPersons (line 224). I don't know python (but at least it looks quite easy to understand), therefore I'll translate it to osc commands to make sure I understood it correctly (correct me if I'm wrong ;-) Your example output (http://pastebin.com/qxXy5S28) says you are going to report a bug for the "python" package on openSUSE 11.4. prj_data=`osc meta prj openSUSE:11.4` -> maintainer: coolo pkg_data=`osc meta pkg openSUSE:11.4 python` -> bugowner: jmatejcik devel_prj,devel_pkg=`osc develproject openSUSE:11.4 python` -> no develproject for 11.4 That would mean the bugreport goes to jmatejek, optionally with coolo in CC. That doesn't match your example output :-( Let's assume we'll report a bug against factory instead - there we have: prj_data=`osc meta prj openSUSE:Factory` -> maintainer: coolo, autobuild-team, factory-maintainers -> reviewer: legal-auto, factory-auto pkg_data=`osc meta pkg openSUSE:Factory python` -> no maintainer/bugowner -> devel project: devel:languages:python:Factory - package python devel_prj,devel_pkg=`osc develproject openSUSE:Factory python` -> (same as meta pkg) Now let's look at the devel project: prj_data=`osc meta prj devel:languages:python:Factory` -> maintainer: matajcik, coolo, jimfunk -> bugowner: matajcik pkg_data=`osc meta pkg devel:languages:python:Factory python` -> bugowner: matajcik That's completely different from the people you listed as assignee (bg) and CC (mrueckert, ro, cgardner) in your example output. Options are: - your example is wrong (partly edited etc.) - you have a bug somewhere or - my understanding/testing is wrong Choose one ;-) - if unsure, test again with the python package and compare the results. Regards, Christian Boltz --
Ich nehme also das apache.spm von SuSE und ...befördere es in einen Mülleimer. Dann gehe ich auf www.apachetoolbox.com und mache mir das Leben leicht. [> Soeren Mindorf und Ratti in suse-linux] -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thu, Jul 14, 2011 at 1:27 AM, Christian Boltz
Hello,
on Mittwoch, 13. Juli 2011, Mihnea Dobrescu-Balaur wrote:
On Tue, Jul 12, 2011 at 7:25 PM, Christian Boltz wrote:
on Dienstag, 12. Juli 2011, Mihnea Dobrescu-Balaur wrote:
On Tue, Jul 12, 2011 at 1:12 AM, Mihnea Dobrescu-Balaur wrote:
On Mon, Jul 11, 2011 at 11:32 PM, Christian Boltz wrote:
on Montag, 11. Juli 2011, Mihnea Dobrescu-Balaur wrote:
Your code has a small bug: What happens if you display the options "contribute" and "create new"? In short: you'll get the shortcut "c" for both.
Yes, I noticed that when I was typing but I figured it can be solved by using another word. I will implement what you said, but it's rather inefficient and not really necessary in my opinion. I mean, checking that those words don't overlap is a quadratic complexity problem. Sure, the data size should be small. I'll look into it but for now I'll just keep it like that and document it. It's better anyway imo than writing it up by hand just for that one use case.
OK.
> This/these address(es) were found: > assignee: bg@suse.com
I wonder about the assignee - osc maintainer openSUSE:11.4 python gives me jmatejek@, not bg@.
> cc: ['mrueckert@suse.com', 'ro@suse.com', > 'cgardner@novell.com']
Just curious: where do you get the CC list from? I can't get any of those people via "osc maintainer".
Make sure you check the devel package. My tool uses osc to check if the package has a devel package associated and, if so, it gets the people from that one.
I just did (see below) and still couldn't find those people.
You can check the code here [0]. From what I tested via some manual queries when I was working on it, it was fine.
https://github.com/mihneadb/suse_bug_reporter/blob/master/util/packag eInfo.py#L123
You should scroll down from there, that's where the magic happens.
Reading your code, I think the most important/relevant function is getAssignedPersons (line 224).
I don't know python (but at least it looks quite easy to understand), therefore I'll translate it to osc commands to make sure I understood it correctly (correct me if I'm wrong ;-)
Your example output (http://pastebin.com/qxXy5S28) says you are going to report a bug for the "python" package on openSUSE 11.4.
prj_data=`osc meta prj openSUSE:11.4` -> maintainer: coolo
pkg_data=`osc meta pkg openSUSE:11.4 python` -> bugowner: jmatejcik
devel_prj,devel_pkg=`osc develproject openSUSE:11.4 python` -> no develproject for 11.4
That would mean the bugreport goes to jmatejek, optionally with coolo in CC. That doesn't match your example output :-(
Let's assume we'll report a bug against factory instead - there we have:
prj_data=`osc meta prj openSUSE:Factory` -> maintainer: coolo, autobuild-team, factory-maintainers -> reviewer: legal-auto, factory-auto
pkg_data=`osc meta pkg openSUSE:Factory python` -> no maintainer/bugowner -> devel project: devel:languages:python:Factory - package python
devel_prj,devel_pkg=`osc develproject openSUSE:Factory python` -> (same as meta pkg)
Now let's look at the devel project:
prj_data=`osc meta prj devel:languages:python:Factory` -> maintainer: matajcik, coolo, jimfunk -> bugowner: matajcik
pkg_data=`osc meta pkg devel:languages:python:Factory python` -> bugowner: matajcik
That's completely different from the people you listed as assignee (bg) and CC (mrueckert, ro, cgardner) in your example output.
Options are: - your example is wrong (partly edited etc.) - you have a bug somewhere or - my understanding/testing is wrong Choose one ;-) - if unsure, test again with the python package and compare the results.
I found the difference - it gets the data for python in openSUSE:11.4:Update:Test.
import rpm ts = rpm.TransactionSet() match = ts.dbMatch('name', 'python') for h in match: ... print h['disturl'] ... obs://build.opensuse.org/openSUSE:11.4:Update:Test/standard/c108b9d66129e93f2c69a3cde8f67b71-python
mihnea@suseVM:~/localCode> osc maintainer -e openSUSE:11.4:Update:Test python bugowner of openSUSE:11.4:Update:Test : - maintainer of openSUSE:11.4:Update:Test : bg@suse.com, mrueckert@suse.com, ro@suse.com, cgardner@suse.com As you can see, it is working properly. After I changed my version of python to the opensuse 11.4 oss one it gets ('jmatejek@novell.com', []). All good, mystery solved, right? :) Mihnea -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thu, Jul 14, 2011 at 12:02 PM, Mihnea Dobrescu-Balaur
On Thu, Jul 14, 2011 at 1:27 AM, Christian Boltz
wrote: Hello,
on Mittwoch, 13. Juli 2011, Mihnea Dobrescu-Balaur wrote:
On Tue, Jul 12, 2011 at 7:25 PM, Christian Boltz wrote:
on Dienstag, 12. Juli 2011, Mihnea Dobrescu-Balaur wrote:
On Tue, Jul 12, 2011 at 1:12 AM, Mihnea Dobrescu-Balaur wrote:
On Mon, Jul 11, 2011 at 11:32 PM, Christian Boltz wrote: > on Montag, 11. Juli 2011, Mihnea Dobrescu-Balaur wrote:
Your code has a small bug: What happens if you display the options "contribute" and "create new"? In short: you'll get the shortcut "c" for both.
Yes, I noticed that when I was typing but I figured it can be solved by using another word. I will implement what you said, but it's rather inefficient and not really necessary in my opinion. I mean, checking that those words don't overlap is a quadratic complexity problem. Sure, the data size should be small. I'll look into it but for now I'll just keep it like that and document it. It's better anyway imo than writing it up by hand just for that one use case.
OK.
>> This/these address(es) were found: >> assignee: bg@suse.com > > I wonder about the assignee - osc maintainer openSUSE:11.4 > python gives me jmatejek@, not bg@. > >> cc: ['mrueckert@suse.com', 'ro@suse.com', >> 'cgardner@novell.com'] > > Just curious: where do you get the CC list from? I can't get > any of those people via "osc maintainer".
Make sure you check the devel package. My tool uses osc to check if the package has a devel package associated and, if so, it gets the people from that one.
I just did (see below) and still couldn't find those people.
You can check the code here [0]. From what I tested via some manual queries when I was working on it, it was fine.
https://github.com/mihneadb/suse_bug_reporter/blob/master/util/packag eInfo.py#L123
You should scroll down from there, that's where the magic happens.
Reading your code, I think the most important/relevant function is getAssignedPersons (line 224).
I don't know python (but at least it looks quite easy to understand), therefore I'll translate it to osc commands to make sure I understood it correctly (correct me if I'm wrong ;-)
Your example output (http://pastebin.com/qxXy5S28) says you are going to report a bug for the "python" package on openSUSE 11.4.
prj_data=`osc meta prj openSUSE:11.4` -> maintainer: coolo
pkg_data=`osc meta pkg openSUSE:11.4 python` -> bugowner: jmatejcik
devel_prj,devel_pkg=`osc develproject openSUSE:11.4 python` -> no develproject for 11.4
That would mean the bugreport goes to jmatejek, optionally with coolo in CC. That doesn't match your example output :-(
Let's assume we'll report a bug against factory instead - there we have:
prj_data=`osc meta prj openSUSE:Factory` -> maintainer: coolo, autobuild-team, factory-maintainers -> reviewer: legal-auto, factory-auto
pkg_data=`osc meta pkg openSUSE:Factory python` -> no maintainer/bugowner -> devel project: devel:languages:python:Factory - package python
devel_prj,devel_pkg=`osc develproject openSUSE:Factory python` -> (same as meta pkg)
Now let's look at the devel project:
prj_data=`osc meta prj devel:languages:python:Factory` -> maintainer: matajcik, coolo, jimfunk -> bugowner: matajcik
pkg_data=`osc meta pkg devel:languages:python:Factory python` -> bugowner: matajcik
That's completely different from the people you listed as assignee (bg) and CC (mrueckert, ro, cgardner) in your example output.
Options are: - your example is wrong (partly edited etc.) - you have a bug somewhere or - my understanding/testing is wrong Choose one ;-) - if unsure, test again with the python package and compare the results.
I found the difference - it gets the data for python in openSUSE:11.4:Update:Test.
import rpm ts = rpm.TransactionSet() match = ts.dbMatch('name', 'python') for h in match: ... print h['disturl'] ... obs://build.opensuse.org/openSUSE:11.4:Update:Test/standard/c108b9d66129e93f2c69a3cde8f67b71-python
mihnea@suseVM:~/localCode> osc maintainer -e openSUSE:11.4:Update:Test python bugowner of openSUSE:11.4:Update:Test : -
maintainer of openSUSE:11.4:Update:Test : bg@suse.com, mrueckert@suse.com, ro@suse.com, cgardner@suse.com
As you can see, it is working properly.
After I changed my version of python to the opensuse 11.4 oss one it gets ('jmatejek@novell.com', []).
All good, mystery solved, right? :)
I've updated the header so that it shows what project & version is the person using. Sample: -------------------------------------------------------------- Package: python Project: openSUSE:11.4:Update:Test Version: 2.7-9.10.2 Apiurl: https://api.opensuse.org Summary: testing Product: openSUSE 11.4 Platform: i586 Component: Development Severity: Normal Assigned to: bg@suse.com CC: mrueckert@suse.com, ro@suse.com, cgardner@suse.com testing2 -------------------------------------------------------------- Also, regarding the security reports, Michal has given me some info. I'll implement it today. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thu, Jul 14, 2011 at 12:30 PM, Mihnea Dobrescu-Balaur
On Thu, Jul 14, 2011 at 12:02 PM, Mihnea Dobrescu-Balaur
wrote: On Thu, Jul 14, 2011 at 1:27 AM, Christian Boltz
wrote: Hello,
on Mittwoch, 13. Juli 2011, Mihnea Dobrescu-Balaur wrote:
On Tue, Jul 12, 2011 at 7:25 PM, Christian Boltz wrote:
on Dienstag, 12. Juli 2011, Mihnea Dobrescu-Balaur wrote:
On Tue, Jul 12, 2011 at 1:12 AM, Mihnea Dobrescu-Balaur wrote: > On Mon, Jul 11, 2011 at 11:32 PM, Christian Boltz wrote: >> on Montag, 11. Juli 2011, Mihnea Dobrescu-Balaur wrote:
Your code has a small bug: What happens if you display the options "contribute" and "create new"? In short: you'll get the shortcut "c" for both.
Yes, I noticed that when I was typing but I figured it can be solved by using another word. I will implement what you said, but it's rather inefficient and not really necessary in my opinion. I mean, checking that those words don't overlap is a quadratic complexity problem. Sure, the data size should be small. I'll look into it but for now I'll just keep it like that and document it. It's better anyway imo than writing it up by hand just for that one use case.
OK.
>>> This/these address(es) were found: >>> assignee: bg@suse.com >> >> I wonder about the assignee - osc maintainer openSUSE:11.4 >> python gives me jmatejek@, not bg@. >> >>> cc: ['mrueckert@suse.com', 'ro@suse.com', >>> 'cgardner@novell.com'] >> >> Just curious: where do you get the CC list from? I can't get >> any of those people via "osc maintainer". > > Make sure you check the devel package. My tool uses osc to check > if the package has a devel package associated and, if so, it > gets the people from that one.
I just did (see below) and still couldn't find those people.
> You can check the code here [0]. > From what I tested via some manual queries when I was working > on it, it was fine.
https://github.com/mihneadb/suse_bug_reporter/blob/master/util/packag eInfo.py#L123
You should scroll down from there, that's where the magic happens.
Reading your code, I think the most important/relevant function is getAssignedPersons (line 224).
I don't know python (but at least it looks quite easy to understand), therefore I'll translate it to osc commands to make sure I understood it correctly (correct me if I'm wrong ;-)
Your example output (http://pastebin.com/qxXy5S28) says you are going to report a bug for the "python" package on openSUSE 11.4.
prj_data=`osc meta prj openSUSE:11.4` -> maintainer: coolo
pkg_data=`osc meta pkg openSUSE:11.4 python` -> bugowner: jmatejcik
devel_prj,devel_pkg=`osc develproject openSUSE:11.4 python` -> no develproject for 11.4
That would mean the bugreport goes to jmatejek, optionally with coolo in CC. That doesn't match your example output :-(
Let's assume we'll report a bug against factory instead - there we have:
prj_data=`osc meta prj openSUSE:Factory` -> maintainer: coolo, autobuild-team, factory-maintainers -> reviewer: legal-auto, factory-auto
pkg_data=`osc meta pkg openSUSE:Factory python` -> no maintainer/bugowner -> devel project: devel:languages:python:Factory - package python
devel_prj,devel_pkg=`osc develproject openSUSE:Factory python` -> (same as meta pkg)
Now let's look at the devel project:
prj_data=`osc meta prj devel:languages:python:Factory` -> maintainer: matajcik, coolo, jimfunk -> bugowner: matajcik
pkg_data=`osc meta pkg devel:languages:python:Factory python` -> bugowner: matajcik
That's completely different from the people you listed as assignee (bg) and CC (mrueckert, ro, cgardner) in your example output.
Options are: - your example is wrong (partly edited etc.) - you have a bug somewhere or - my understanding/testing is wrong Choose one ;-) - if unsure, test again with the python package and compare the results.
I found the difference - it gets the data for python in openSUSE:11.4:Update:Test.
import rpm ts = rpm.TransactionSet() match = ts.dbMatch('name', 'python') for h in match: ... print h['disturl'] ... obs://build.opensuse.org/openSUSE:11.4:Update:Test/standard/c108b9d66129e93f2c69a3cde8f67b71-python
mihnea@suseVM:~/localCode> osc maintainer -e openSUSE:11.4:Update:Test python bugowner of openSUSE:11.4:Update:Test : -
maintainer of openSUSE:11.4:Update:Test : bg@suse.com, mrueckert@suse.com, ro@suse.com, cgardner@suse.com
As you can see, it is working properly.
After I changed my version of python to the opensuse 11.4 oss one it gets ('jmatejek@novell.com', []).
All good, mystery solved, right? :)
I've updated the header so that it shows what project & version is the person using.
Sample:
--------------------------------------------------------------
Package: python Project: openSUSE:11.4:Update:Test Version: 2.7-9.10.2 Apiurl: https://api.opensuse.org Summary: testing Product: openSUSE 11.4 Platform: i586 Component: Development Severity: Normal Assigned to: bg@suse.com CC: mrueckert@suse.com, ro@suse.com, cgardner@suse.com
testing2
--------------------------------------------------------------
Also, regarding the security reports, Michal has given me some info. I'll implement it today.
As promised, I've implemented the security issue reporting. This is what Michal suggested: About security bugs - the best method is * use SUSE Security incidets product * add security-team@suse.de to CC * optionally add VUL-0 or VUL-1 prefix to the summary (VUL-0 means needed to be fixed yet, VUL-1 is should be fixed on next maint update) Sample usage: http://pastebin.com/RtbwnMv3 Mihnea -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Hello, on Donnerstag, 14. Juli 2011, Mihnea Dobrescu-Balaur wrote: ["strange" results for assignee and CC for 11.4 python package]
I found the difference - it gets the data for python in openSUSE:11.4:Update:Test.
mihnea@suseVM:~/localCode> osc maintainer -e openSUSE:11.4:Update:Test python bugowner of openSUSE:11.4:Update:Test : -
maintainer of openSUSE:11.4:Update:Test : bg@suse.com, mrueckert@suse.com, ro@suse.com, cgardner@suse.com
As you can see, it is working properly.
Indeed - Update:Test has a different set of maintainers. Never noticed that before ;-) The "official" Update repo has the "normal" bugowner again - jmatajek for python.
After I changed my version of python to the opensuse 11.4 oss one it gets ('jmatejek@novell.com', []).
All good, mystery solved, right? :)
Yes, indeed :-) Thanks for checking the mystery! Regards, Christian Boltz -- Bei Windows hat man Mailreader, der alles kann. Bei Linux hat man ein MUA, das eigentlich gar nichts kann, aber das verdammt gut. [Bernd Brodesser in suse-linux] -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
participants (3)
-
Alin Marin Elena
-
Christian Boltz
-
Mihnea Dobrescu-Balaur