Mailinglist Archive: opensuse-project (120 mails)

< Previous Next >
Re: [opensuse-project] Suse Bug Reporter - GSoC midterm report
On Tue, Jul 12, 2011 at 7:25 PM, Christian Boltz <opensuse@xxxxxxxxx> 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:
* 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.


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:

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

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


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: ) 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@xxxxxxxx

I wonder about the assignee - osc maintainer openSUSE:11.4 python
gives me jmatejek@, not bg@.

cc: ['mrueckert@xxxxxxxx', 'ro@xxxxxxxx', 'cgardner@xxxxxxxxxx']

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

You forgot to add the link referred as [0]...

Please excuse me. This was the link:

You should scroll down from there, that's where the magic happens.

Please describe the impact of the bug, choose a severity for the
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

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/ 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

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.


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,*.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?
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

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

OK, I will work on implementing this.

BTW: Is there a real bugreport in bnc that was created with your

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. :)

You can also ask on the opensuse-packaging mailinglist if you have
specific questions.

On it.


Christian Boltz

Thanks again for your input!
Mihnea DB
To unsubscribe, e-mail: opensuse-project+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-project+help@xxxxxxxxxxxx

< Previous Next >