David Guntner wrote:
> Bob Proulx grabbed a keyboard and wrote:
> > If the documented procedure isn't working then please file a bug
> > against it.
>
> Where/how does one do that, exactly?
Use the 'reportbug' tool. Start off by browsing the man page so that
you are familiar with the basic capabilities. Such as that it can
report bugs against packages and that it can deduce the package itself
if given a file name. There is a *lot* of useful information in the
man page. But don't get overwhelmed. The tweaking is only important
after you have filed a dozen bugs and want to tune it for the next
hundred.
man reportbug
It is important to only use the text interface. 'reportbug -u text'
or setting "ui text" in the ~/.reportbugrc file. If it opens a
graphical interface please exit it and try again until you get the
text interface. Some time ago I and another person here got into a
*huge* fuss because they said reportbug always failed and crashed for
them and I couldn't understand why since it is so simple that it
always works for me. I would recommend reportbug. They would
disparage it. We were in severe disagreement.
It finally turned out that they were using the gtk graphical mouse gui
interface to reportbug and it was the graphical gui that was crashing.
I have been using reportbug for many years but didn't even know it had
a graphical interface! A bad feature apparently. The text interface
is rock solid however so I recommend to use it. If the gui works for
you then that is fine but you have been warned.
Then use reportbug to report the bug on the package.
reportbug PACKAGENAME
It will ask you for a bug title, and some other information and then
start up an editor on a template. Fill out the template with the
information needed to recreate the bug. You are in an editor at that
time so just edit the file with the needed information. Whatever the
maintainer will need to replicate the bug. If they can't understand
the bug or can't replicate it then they won't be able to deal with it.
The template always starts out with some boilerplate to help you fill
out the report. Things to get you thinking about the problem. It
isn't necessary to answer each question specifically because not all
bugs make sense with those questions. For example they don't make
sense for a documentation bug. It says the following:
Dear Maintainer,
*** Please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome of this action?
* What outcome did you expect instead?
*** End of the template - remove these lines ***
You would be surprised at how many people leave that template in place
and never edit or remove it! What are they thinking? I have no idea.
But leaving that in place clearly says they weren't following the
directions. Because what does it say? It says "End of the template -
remove these lines"! :-) And I have seen people answer each of those
in turn for things like a documentation bug. Those are not rigid form
processed by a computer. Humans read those bug reports. Just say
that there is a spelling error and where and the correction. You are
talking to a human when you fill out that bug report.
Thank you for giving me an opportunity to rant about people who leave
those lines in the bug report. :-)
Here is the official documentation on reporting bugs in Debian.
Please take a moment and browse it before reporting a bug. It has a
lot of useful information there.
http://www.debian.org/Bugs/Reporting
And it describes how bug reports are simply an email message. If you
can send email then you can submit a bug report. So if the system you
want to report a bug about isn't on the network that is no problem.
Simply send an email from a connected machine. Don't like the
reportbug interface? That is no problem if you can send an email and
submit a bug that way.
Bob
Attachment:
signature.asc
Description: Digital signature