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