Re: bug reporting and packages

2016-04-04 Thread Cindy-Sue Causey 
On 4/4/16, Alan Fujinami  wrote:
> Hi,
> I was going to use the bugreport feature of my Debian 8.3 install... it say
> if I don't know the package then I should contact you...
> my bug is that I have a ps2mouse. Whenever the computer goes into
> screensaver mode, the mouse icon disappears. I have to reboot to bring it
> back. I tried modprobe and a few other things to no avail.
> So what package is affected?
> alan


While you're waiting for others to respond, how many PS/2 ports do you
have? If there's more than one, can you take a quick peek and make
sure you're actually plugged into the mouse port and not the keyboard
one?

That option came up as a fix on a recent Debian-User thread.
Additionally, I also experienced that a few years ago. In those
instances, the mouse would function seemingly normal for a while and
then would eventually glitch to where nothing short of a reboot would
fix things.

Just out of curiosity, too, how much memory do you have? Occasionally
memory (or the lack of it) plays a part in glitches related to paths
that head towards hibernate, suspend, etc.

A PS to it is this is a good trigger for learning the keyboard
shortcuts necessary for at least getting to "Log Out" and/or "Settings
> Mouse and Touchpad" under the Applications menu. ALT+F1 works for
me, grin.

Just thinking out loud.. :)

Cindy :)

-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with plastic sporks *

Re: Bug Reporting

2015-08-15 Thread tomas 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, Aug 16, 2015 at 04:16:33AM +0800, Nafiez wrote:
 Hi,
 
 I wanted to ask on what is the process to submit bug via e-mail. Can you
 help?

I assume you are talking about reporting a bug against a Debian package:
there's a comand for that called reportbug. As argument you give it
the package name -- alternatively a complete file path belonging to the
package.

It goes then to gather information from the system to help package
maintainers pin-point the relevant software versions, asks you for
whatever information it thinks relevant and formats a mail with all
the necessary parts for a proper bug report.

Read the manual page of report-bug (type man reportbug at the command
line) and come back if you stumble upon any difficulties.

Regards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlXPpx8ACgkQBcgs9XrR2kaXKQCfQ25KxCQwurk4hzVl23GLu3Ry
Ns0An2OWK5CpgrgfR5x4XgpSnG2UpxBJ
=oAOh
-END PGP SIGNATURE-

Re: Bug Reporting

2015-08-15 Thread Francesco Ariis 
On Sun, Aug 16, 2015 at 04:16:33AM +0800, Nafiez wrote:
 Hi,
 
 I wanted to ask on what is the process to submit bug via e-mail. Can you
 help?
 
 Thank you,
 Nafiez
 

Hello Nafiez,
you usually report bugs via reportbug (open a terminal, type
`reportbug enter` and follow the instructions).

There is a way to report directly using the mail, more info on
http://www.debian.org/Bugs/Reporting

Hope this helps

Re: Bug reporting

2012-02-02 Thread Rob Owens 
On Wed, Feb 01, 2012 at 01:38:37PM -0800, Gary Roach wrote:
 I've been using Debian for years and still can't seem to submit a
 bug report successfully.  One of the main problems is that I have no
 mail server active on my system. I use Icedove. I have tried to
 setup exim several times and have always given up in disgust. The
 instructions for reporting by normal email are way to complicated
 for easy understanding. The examples given include copies of the
 world. I need something straight forward and relatively simple. Any
 help will be sincerely appreciated.
 
If you tell reportbug that you do not have an smtp server, it will use a
Debian smtp server.  My .reportbugrc has this line:

smtphost reportbug.debian.org


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120202124246.gb11...@aurora.owens.net

Re: Bug reporting

2012-02-02 Thread Camaleón 
On Wed, 01 Feb 2012 13:38:37 -0800, Gary Roach wrote:

 I've been using Debian for years and still can't seem to submit a bug
 report successfully.  One of the main problems is that I have no mail
 server active on my system. I use Icedove. I have tried to setup exim
 several times and have always given up in disgust. The instructions for
 reporting by normal email are way to complicated for easy understanding.
 The examples given include copies of the world. I need something
 straight forward and relatively simple. Any help will be sincerely
 appreciated.

Reportbug is a nice tool, in the event it does not crash :-)

And I don't remember of having to configure an e-mail server to use it, 
you can provide your e-mail address, your smtp server settings and it 
will ask you for the password.

You can also report bugs manually by e-mail. It is more complicated but 
works well.

Greetings,

-- 
Camaleón


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/jge1fk$qa4$4...@dough.gmane.org

Re: Bug reporting

2012-02-02 Thread Andrei Popescu 
On Jo, 02 feb 12, 07:42:46, Rob Owens wrote:
  
 If you tell reportbug that you do not have an smtp server, it will use a
 Debian smtp server.  My .reportbugrc has this line:
 
 smtphost reportbug.debian.org

+1 for this method. I know the wording is not very... obvious, but read 
the messages carefully when doing 'reportbug --configure' it's 
definitely there.

Kind regards,
Andrei
-- 
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature

Re: Bug reporting

2012-02-01 Thread Tom H 
On Wed, Feb 1, 2012 at 4:38 PM, Gary Roach gary719_li...@verizon.net wrote:

 I've been using Debian for years and still can't seem to submit a bug report
 successfully.  One of the main problems is that I have no mail server active
 on my system. I use Icedove. I have tried to setup exim several times and
 have always given up in disgust.

You can set up reportbug to use your Verizon account through
reportbug --configure.


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAOdo=SzPctJ=vscvnvxu_+e8qdboqoqry-9ptregl8lbqv+...@mail.gmail.com

Re: Bug reporting

2012-02-01 Thread green 
Gary Roach wrote at 2012-02-01 15:38 -0600:
 I've been using Debian for years and still can't seem to submit a
 bug report successfully.  One of the main problems is that I have no
 mail server active on my system. I use Icedove.

You should be able to just use reportbug's SMTP options with credentials 
necessary for your email service. See the man page; search for smtp.

I certainly would not set up a mail server just for reportbug.


signature.asc
Description: Digital signature

Re: Bug reporting

2012-02-01 Thread Bob Proulx 
Gary Roach wrote:
 I've been using Debian for years and still can't seem to submit a
 bug report successfully.  One of the main problems is that I have no
 mail server active on my system. I use Icedove. I have tried to
 setup exim several times and have always given up in disgust. The
 instructions for reporting by normal email are way to complicated
 for easy understanding. The examples given include copies of the
 world. I need something straight forward and relatively simple. Any
 help will be sincerely appreciated.

Since bug reports are simply email messages all that you really need
to know is how to include two special lines in the top of your email
message.  If you do that then you can simply send an email.

Here is a reference.  Scroll down to An Example Bug Report.

  http://www.debian.org/Bugs/Reporting

The example is showing the parts of the email message that go off to
the bug report.  The top part is the email information including the
email To: and Subject: and of course From:.  But that is just your
mailer message the same as the message you sent to this mailing list.
Pick a good subject is the most important part of that section.  Just
saying Bug or Help is bad.  Try to be descriptive in the subject.
A pet peeve of mine.

The second includes the two important lines.

  Package: hello
  Version: 1.3-16

Set the package name to the package you are submitting the bug
against.  Set the version of that package.  Those are the only two
special critical lines in the message.

Follow with the body of the message with your bug report.

That is all there is to it!

Now everyone will recommend 'reportbug'.  I recommend reportbug.  It
generates this information and more automatically.  But if the machine
you are using isn't on the network or doesn't have a way to send email
then just sending your own email message is perfectly acceptable.

HTH,
Bob


signature.asc
Description: Digital signature

Re: Bug reporting

2012-02-01 Thread Nate Bargmann 
* On 2012 01 Feb 17:04 -0600, Gary Roach wrote:
 I've been using Debian for years and still can't seem to submit a
 bug report successfully.  One of the main problems is that I have no
 mail server active on my system. I use Icedove. I have tried to
 setup exim several times and have always given up in disgust. The
 instructions for reporting by normal email are way to complicated
 for easy understanding. The examples given include copies of the
 world. I need something straight forward and relatively simple. Any
 help will be sincerely appreciated.

The esmtp package is easy to setup wand will function nicely for
reportbug.

- Nate 

-- 

The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true.

Ham radio, Linux, bikes, and more: http://www.n0nb.us


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120202003446.gb2...@n0nb.us

Re: Bug reporting

2012-02-01 Thread Celejar 
On Wed, 01 Feb 2012 13:38:37 -0800
Gary Roach gary719_li...@verizon.net wrote:

 I've been using Debian for years and still can't seem to submit a bug 
 report successfully.  One of the main problems is that I have no mail 
 server active on my system. I use Icedove. I have tried to setup exim 
 several times and have always given up in disgust. The instructions for 
 reporting by normal email are way to complicated for easy understanding. 
 The examples given include copies of the world. I need something 
 straight forward and relatively simple. Any help will be sincerely 
 appreciated.

Setting up reportbug to do its own SMTP is really not all that hard;
my .reportbugrc (in $HOME) contains the following lines, for using
Gmail's SMTP server:

email cele...@gmail.com
realname Celejar
smtphost smtp.gmail.com:587
smtpuser cele...@gmail.com
smtppasswd 
smtptls

That should be pretty much all you'll need. You won't be using Icedove,
but reportbug itself (although the actual message composition can be in
your editor of choice).

Celejar


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120201210557.cb56ef8b.cele...@gmail.com

Re: Bug-Reporting

2007-09-24 Thread Johannes Wiedersich 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[redirect to debian-user-german. Request for asking smart questions.]

Ralph Rupprich wrote:
 Hallo liebe Leute,

Hallo Ralph,

wir haben auf der englischsprachigen Debian-user-Mailingliste deinen
Eintrag gefunden, der sich dort nicht zuordnen lässt, weil er dort nicht
hingehört. Bitte wende dich an [1] oder schreibe auf Englisch.

[1] http://lists.debian.org/debian-user-german/

Bevor du das tust, solltest du dir überlegen, wie du deine Frage
kleverer formulieren kannst. Der Betreff deiner Nachricht hat nichts mit
deren Inhalt zu tun. Suche auch nach relevanten Fehlermeldungen. Falls
du englisch verstehst hilft dir hier vermutlich [2] weiter.

[2] http://www.catb.org/~esr/faqs/smart-questions.html

Hoffe, dies hilft,

Johannes

 
 ich hab an meinem Notebook einen Fehler und kann den nicht zuordnen.
 
 Nach willkürlicher Laufzeit schaltet sich der USB-Controller oder der
 interne USB-Hub einfach ab, aber nicht komplett.
 
 Geräte, die zum Abschaltzeitpunkt noch angesteckt sind, haben zwar
 noch Strom, bekommen aber keine Daten mehr und werden vom BS auch
 nicht mehr erkannt.
 
 Geräte, die neu angesteckt werden, bekommen auch keinen Strom mehr
 (klar, der wird ja beim Anstecken durch die erkennung erst
 initiiert).
 
 Notebook: Toshiba Satellite A100-512 (PSAA2E), aktuelles BIOS (2.20 -
 trat aber unter der BIOS-Version 1.40 auch auf).
 
 Ideen ??
 
 Oder doch 'n Bug ??
 
 Gürsse,
 
 Ralph Rupprich
 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFG97p0C1NzPRl9qEURAr8xAJ0WB/nTzJte/Kx7KlCgik+BQ71vfQCfYAdk
Naw0G1VwS6sqQiwG801ipWM=
=iQcj
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Bug Reporting for Woody Sarge Installations

2004-11-21 Thread Wim De Smet 
On Sun, 21 Nov 2004 11:50:42 -0600, John J Waldeck [EMAIL PROTECTED] wrote:
 I was directed to file bug reports for installations of Woody
 (which failed with a P4 system), and Sarge (which failed on a P3 system
 and succeeded on a P4 system).  My question is which package should I
 indicate for the bug reports?
 
 jjwdeck
 

I would suggest debian-installer.

greets,
Wim


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: bug reporting about conflicts in sid

2001-09-29 Thread Blars Blarson 
In article [EMAIL PROTECTED] you write:
On Fri, Sep 28, 2001 at 09:41:09AM -0700, Blars Blarson wrote:
 After getting sid successfully installed, I ran dselect to install the
 rest of the packages I wanted.  There are a few complaints about
 recomended packages not being available, but the only real headake was
 with olvwm.  Apparently, it requires xlib and recomends xpm4g, and
 xpm4g conflicts with xlib.

That's weird. xpm4g should indeed be forced out by something or other,
because it's obsolete with the new organization of the X packages.
However, olvwm just depends on libc6 and xlibs, and doesn't recommend
xpm4g.

Are you sure that's the problem? What *could* be the case is that you
ran 'apt-get update', but not 'dselect update' (or [U]pdate from
dselect's main menu). If you try to run dselect on a system that's been
upgraded to sid without updating its view of available packages past
potato, it will understandably get rather confused.

I was sure I had done so, but after doing it again I can't duplicate the
problem, so maybe I didn't.  Thanks.

It also appears that olvwm now includes olwm, and the olwm package is
obsolete.

In any event, my new hard drives arrived so my temporary test system
isn't available anymore.  (It's getting potato, and will replace a
redhat and a solaris 7 box.  The redhat box will get woody or sid, and
the sun may as well.)


-- 
Blars Blarson   [EMAIL PROTECTED]
http://www.blars.org/blars.html
Text is a way we cheat time. -- Patrick Nielsen Hayden

Re: bug reporting about conflicts in sid

2001-09-28 Thread Colin Watson 
On Fri, Sep 28, 2001 at 09:41:09AM -0700, Blars Blarson wrote:
 After getting sid successfully installed, I ran dselect to install the
 rest of the packages I wanted.  There are a few complaints about
 recomended packages not being available, but the only real headake was
 with olvwm.  Apparently, it requires xlib and recomends xpm4g, and
 xpm4g conflicts with xlib.

That's weird. xpm4g should indeed be forced out by something or other,
because it's obsolete with the new organization of the X packages.
However, olvwm just depends on libc6 and xlibs, and doesn't recommend
xpm4g.

Are you sure that's the problem? What *could* be the case is that you
ran 'apt-get update', but not 'dselect update' (or [U]pdate from
dselect's main menu). If you try to run dselect on a system that's been
upgraded to sid without updating its view of available packages past
potato, it will understandably get rather confused.

See the recent thread about the division between dpkg/dselect and apt
for more information.

 3. report a bug in dselect -- it shouldn't treat recomends as 
requires if it makes packages uninstallable.

dselect's treatment of recommends is certainly a known bug. :) It'll be
fixed in version 1.10, but I don't believe that's going to be released
until after woody freezes.

If you want a preview and are brave, you can check it out of CVS. See
http://cvs.debian.org/ for instructions: project root dpkg, module dpkg.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Bug reporting proceedure, was Re: Bug#24066: libc6: rsh segfaults as , a result of new libc 2.0.7r2

1998-07-16 Thread Raul Miller 
Dale Scheetz [EMAIL PROTECTED] writes:
  Well, I disagree with this point of view. Yes, Debian wishes to support
  newcomers to Linux. That is why we have debian-user. We have a
  responsibility to those new users to train them to be free users.
  They can only do that if they become familiar with the ins and outs of the
  Debian Way.

John Goerzen [EMAIL PROTECTED] wrote:
 But by actually submitting a bug report in the first place, they're
 already helping.  The maintainer can either fix it or open a dialogue
 up with the submitter if more information is needed.

Slow down folks.  [Er... except on getting hamm released.]

Dale is talking from the viewpoint of being libc maintainer.  John
is talking about the application view of the system.

In general, I agree with John's point of view. However, before reporting
that something about libc is broken, it's worthwhile doing a certain
amount of research. [If you find that the point you're researching is
undocumented, or that the documentation doesn't adequately describe the
situation, that may itself be a bug, of course.]

That said, info libc doesn't even mention the debian bug tracking
system, let alone that the web pages should be consulted before
reporting a bug on libc.

-- 
Raul


--  
Unsubscribe?  mail -s unsubscribe [EMAIL PROTECTED]  /dev/null

Re: Bug reporting proceedure, was Re: Bug#24066: libc6: rsh segfaults as , a result of new libc 2.0.7r2

1998-07-16 Thread Bill Bell 
Hello everyone,

I would like to add my comments to this discussion.  I am new to Linux.  
I have been using the Debian, (Hamm), distribution for about two months 
now, and Slink for the last couple of days.  I am a Windoz drop-out with 
UNIX sys-adin experience.  Being so new to Linux and Debian, I feel my 
input to a REAL bug is minimum.  By the time I find I have a problem, 
this community has identified the problem, fixed it and are putting it 
out to the mirrors!  I have personally found that if I have a problem, I 
just wait a few hours, update my system and I am back on the road.  
Someday I WILL be a REAL contributor to this wonderful effort, but today 
I am just having fun with the basic stuff.

Please continue the interesting conversation, but don't forget, a Linux 
newbie may really be NEW!

Bill Bell
[EMAIL PROTECTED]

To: Dale Scheetz [EMAIL PROTECTED]
Cc: Manoj Srivastava [EMAIL PROTECTED],
  Rob Browning [EMAIL PROTECTED], debian-devel@lists.debian.org,
  debian-user@lists.debian.org, debian-policy@lists.debian.org
Subject: Re: Bug reporting proceedure, was Re: Bug#24066: libc6: rsh 
segfaults as , a result of new libc 2.0.7r2
From: John Goerzen [EMAIL PROTECTED]
Date: 15 Jul 1998 14:48:56 -0500

Dale Scheetz [EMAIL PROTECTED] writes:

 Suggesting, even strongly, that it is proper proceedure when 
submitting a
 bug, to research the bug reporting system first, and provide useful
 information second, doesn't seem onerous to me, and has several 
practical
 uses for the bug submitter, as well as the maintainer.

I disagree.  When I am doing an upgrade, I may notice a number of
bugs.  Perhaps I can log on to a terminal next to the computer I'm
upgrading and submit bug reports.

However, I do not have time to check the bug logs and webpages (which
may be out-of-date, remember).  Sometimes (often, actually, for me)
the Internet connection is slow.  I use Debian at work and I'm not
paid to research the Debian bug logs when, for instance, X suddenly
breaks because KDE has removed the /etc/X11/Xsession file.  (Still
haven't received a reply to this one yet, and it's in hamm!)

 Merging bugs is not that hard, but it also doesn't provide any 
bookkeeping
 advantages to the maintainer. The bugs still get reported in the
 problems report separately. Nags still come separately. This 
requires
 that the maintainer keep records of which bugs have been merged.

Well then we ought to fix those reporting mechanisms.

 I am only suggesting that we make clear that the socially correct way 
to
 report a bug involves adequate research on the part of the bug 
reporter.

We can SUGGEST this as before.  However, I will be Very Upset if
people start complaining at me because I filed bug reports without
checking the webpages first after a particularly frustrating upgrade
experience that took three times longer than it should have because
people delete me config files or fail to put a read at the end of
their postinst and important information goes whizzing by the screen.

 This requirement provides additional service to the user at the 
same
 time that it provides the maintainer with more chance to fix the 
problem.

I feel that I'm already helping out the project by reporting a bug.
I often don't have time to figure out the problem and end up deleting
packages if they're non-essential -- or doing some quick hack to fix
it.

BTW, while we're on this topic, I am ASTOUNDED at the number of
packages that display messages in postinst but don't prompt for Enter
keypress -- the messages then scroll by.  Even though policy requires
a prompt.

-- 
John Goerzen   Linux, Unix consulting  programming   
[EMAIL PROTECTED] |
Developer, Debian GNU/Linux (Free powerful OS upgrade)   
www.debian.org |
+
Visit the Air Capitol Linux Users Group on the web at 
http://www.aclug.org


--  
Unsubscribe?  mail -s unsubscribe [EMAIL PROTECTED] 
 /dev/null




__
Get Your Private, Free Email at http://www.hotmail.com


--  
Unsubscribe?  mail -s unsubscribe [EMAIL PROTECTED]  /dev/null

Re: Bug reporting proceedure, was Re: Bug#24066: libc6: rsh segfaults as , a result of new libc 2.0.7r2

1998-07-16 Thread Pat Kennedy 


He who wonders discovers that this in itself is wonder.
-- M.C. Escher


On Wed, 15 Jul 1998, Raul Miller wrote:

 Dale Scheetz [EMAIL PROTECTED] writes:
   Well, I disagree with this point of view. Yes, Debian wishes to support
   newcomers to Linux. That is why we have debian-user. We have a
   responsibility to those new users to train them to be free users.
   They can only do that if they become familiar with the ins and outs of the
   Debian Way.
 
 John Goerzen [EMAIL PROTECTED] wrote:
  But by actually submitting a bug report in the first place, they're
  already helping.  The maintainer can either fix it or open a dialogue
  up with the submitter if more information is needed.
 
 Slow down folks.  [Er... except on getting hamm released.]
 
 Dale is talking from the viewpoint of being libc maintainer.  John
 is talking about the application view of the system.
 

Just from the point of view of a typical user, eg, me
just doing a quick scan of the debian-user archives doesn't
take all that long.  They're very up-to-date, usually just a
day or so behind.  Browsing the archives with navigator presents
a nice threaded layout, easily scanned in a few minutes.
Besides, you might actually learn something in spite of yourself.
And if you find an answer, you'll conserve Net bandwidth + make
it easier for the next user to perhaps find HIS answer in the
 100 emails/per day posted to debian-user.  


--  
Unsubscribe?  mail -s unsubscribe [EMAIL PROTECTED]  /dev/null

Re: Bug reporting proceedure, was Re: Bug#24066: libc6: rsh segfaults as , a result of new libc 2.0.7r2

1998-07-16 Thread Raul Miller 
Pat Kennedy [EMAIL PROTECTED] wrote:
 Just from the point of view of a typical user, eg, me just doing
 a quick scan of the debian-user archives doesn't take all that long.
 They're very up-to-date, usually just a day or so behind. Browsing
 the archives with navigator presents a nice threaded layout, easily
 scanned in a few minutes. Besides, you might actually learn something
 in spite of yourself. And if you find an answer, you'll conserve Net
 bandwidth + make it easier for the next user to perhaps find HIS
 answer in the  100 emails/per day posted to debian-user.

Certainly.

And, if it's feasable to check the bug archives, you should check those
as well.

http://www.debian.org/Bugs (skip down a bit, enter the package name,
then browse).

But that's a recommendation, not an iron-clad rule.  Once you've
successfully reported some real bugs, I think we should trust your
judgement some, too.  If you find yourself in the akward position of
having information that looks like a significant bug, but not having
a system which is capable of checking the bug-tracking system for
outstanding reports against that bug, it's sometimes still worthwhile
filing that bug report.

There's a certain amount of judgement that's required here. For example,
if it's something that's likely to hurt someone else, it's much more
important than if it's something that won't hurt anyone and is easy to
work around.

Good luck,

-- 
Raul


--  
Unsubscribe?  mail -s unsubscribe [EMAIL PROTECTED]  /dev/null

Re: Bug reporting proceedure, was Re: Bug#24066: libc6: rsh segfaults as , a result of new libc 2.0.7r2

1998-07-15 Thread John Goerzen 
Dale Scheetz [EMAIL PROTECTED] writes:

 Well, I disagree with this point of view. Yes, Debian wishes to support
 newcomers to Linux. That is why we have debian-user. We have a
 responsibility to those new users to train them to be free users.
 They can only do that if they become familiar with the ins and outs of the
 Debian Way.

But by actually submitting a bug report in the first place, they're
already helping.  The maintainer can either fix it or open a dialogue
up with the submitter if more information is needed.

The fact is -- if we require research beforehand, there will be FAR
fewer reports.  I for one will not submit any (or very few at least)
bug reports if this happens.  This will end up hurting Debian
seriously.


-- 
John Goerzen   Linux, Unix consulting  programming   [EMAIL PROTECTED] |
Developer, Debian GNU/Linux (Free powerful OS upgrade)   www.debian.org |
+
Visit the Air Capitol Linux Users Group on the web at http://www.aclug.org


--  
Unsubscribe?  mail -s unsubscribe [EMAIL PROTECTED]  /dev/null

Re: Bug reporting proceedure, was Re: Bug#24066: libc6: rsh segfaults as , a result of new libc 2.0.7r2

1998-07-15 Thread John Goerzen 
Dale Scheetz [EMAIL PROTECTED] writes:

 Suggesting, even strongly, that it is proper proceedure when submitting a
 bug, to research the bug reporting system first, and provide useful
 information second, doesn't seem onerous to me, and has several practical
 uses for the bug submitter, as well as the maintainer.

I disagree.  When I am doing an upgrade, I may notice a number of
bugs.  Perhaps I can log on to a terminal next to the computer I'm
upgrading and submit bug reports.

However, I do not have time to check the bug logs and webpages (which
may be out-of-date, remember).  Sometimes (often, actually, for me)
the Internet connection is slow.  I use Debian at work and I'm not
paid to research the Debian bug logs when, for instance, X suddenly
breaks because KDE has removed the /etc/X11/Xsession file.  (Still
haven't received a reply to this one yet, and it's in hamm!)

 Merging bugs is not that hard, but it also doesn't provide any bookkeeping
 advantages to the maintainer. The bugs still get reported in the
 problems report separately. Nags still come separately. This requires
 that the maintainer keep records of which bugs have been merged.

Well then we ought to fix those reporting mechanisms.

 I am only suggesting that we make clear that the socially correct way to
 report a bug involves adequate research on the part of the bug reporter.

We can SUGGEST this as before.  However, I will be Very Upset if
people start complaining at me because I filed bug reports without
checking the webpages first after a particularly frustrating upgrade
experience that took three times longer than it should have because
people delete me config files or fail to put a read at the end of
their postinst and important information goes whizzing by the screen.

 This requirement provides additional service to the user at the same
 time that it provides the maintainer with more chance to fix the problem.

I feel that I'm already helping out the project by reporting a bug.
I often don't have time to figure out the problem and end up deleting
packages if they're non-essential -- or doing some quick hack to fix
it.

BTW, while we're on this topic, I am ASTOUNDED at the number of
packages that display messages in postinst but don't prompt for Enter
keypress -- the messages then scroll by.  Even though policy requires
a prompt.

-- 
John Goerzen   Linux, Unix consulting  programming   [EMAIL PROTECTED] |
Developer, Debian GNU/Linux (Free powerful OS upgrade)   www.debian.org |
+
Visit the Air Capitol Linux Users Group on the web at http://www.aclug.org


--  
Unsubscribe?  mail -s unsubscribe [EMAIL PROTECTED]  /dev/null

Re: Bug reporting proceedure, was Re: Bug#24066: libc6: rsh segfaults as , a result of new libc 2.0.7r2

1998-07-01 Thread Ed Cogburn 
Larry Walewski wrote:
 
 I think your ideas are great.  I too am a newbie to Linux.  First tried 
 installing
 Caldera's OpenLinux Lite, but couldn't get it to work on my machine with
 only 5 megs (probably could've with a little more work).  Someone then
 pointed me, thankfully, to Debian!  So, I got Dale's book and I'm up and
 running.  Got LOTS of reading to do, but I'm up.  And since this thread
 is involving Dale, he can add this info right into the update of his book,
 which would have been nice to have had in mine.
 
 Larry
 
 
Here is my two cents worth as a novice user:
 
First, lets get the above information put in a place where new novice
  users
  can't miss.  In other words put it right under their nose.  At the end of
  the install procedure of future Debs, have the tail end of the install
  script (before they are taken to dselect?) point them to a few critical
  plain text files *already on the system* (put them in the base system) in a
  /usr/doc/dir location.  Consider making everyone page thru this info (in the
  install script) before 'letting them go'.  Make them plain text so you don't
  force a tender newbie to have to figure out how to use latex/tex/whatever.
  This file(s) should do the following things:
 
a) Tell them of the existence not only of www.debian.org but this user
  mailing list as well.  Don't assume every person is going to come to
  www.debian.org right off the bat on their own initiative, discover the
  mailing lists (and figure out how to sign themselves up), plus discover the
  bug reporting system.  They may not get a browser set up for awhile, so let
  them know *before-hand* what is expected.  Otherwise, when they do get their
  ppp/mail/browser working, if they ran into a problem, they might blunder
  right in to submitting a bug or wasting bandwidth on the mailing list when
  they should have done something else.  They need to know about this
  important source of information (www.debian.org) from  the very beginning.
 
b) Explain how to submit a bug including the concerns mentioned above.
  A
  very, VERY helpful option would be to provide an http-based (via
  www.debian.org) automated procedure to fill out a bug report.  This
  procedure would include a check of previous bug reports, so the user can see
  whether his problem has already been reported.  I know setting up something
  like this is a non-trivial operation - so take my suggestion here as an item
  for the wish-list.  Don't simply tell them to use the bug package.  The
  bug package is not useful to everyone, because it assumes everyone has
  installed a standard mail system, which will increasingly not be the case.
  A lazy novice user (refugee from DOS/Win world) like me will prefer to just
  use NS Communicator (or future equivalent) which does www/mail/news without
  the difficulty of install and configuring the arcane
  smail/fetchmail/mutt/inews/inewsinn combination (plus God knows what else is
  required).
 
c) Other locations on the net where they can get info and support 
  (when
  Deb
  starts using GNOME, for example, we can point them to gnome.org).
 
I don't know of polite way to say this, but a little hand-holding at 
  the
  very beginning will save you maintainers some grief later on down the road.
 
The current bug reporting procedure is already complicated; look at 
  how
  long http://www.debian.org/Bugs/Reporting.html is already.  We need to find
  a way to make it simpler, not add more to it.
 
  Feel free to flame away! :-)
 
 
  --
  Ed
 
 
Thanx Larry, part of what prompted me to say this was my first 
experience
with Deb back in the .9x days.  I still think the install sequence ends in a
rather 'jarring' fashion, leaving the user to sink or swim.  With a little
forethought that shouldn't be the case.


-- 
Ed


--  
Unsubscribe?  mail -s unsubscribe [EMAIL PROTECTED]  /dev/null

Re: Bug reporting proceedure, was Re: Bug#24066: libc6: rsh segfaults as , a result of new libc 2.0.7r2

1998-06-30 Thread Manoj Srivastava 
Hi,
Rob == Rob Browning [EMAIL PROTECTED] writes:

 Rob Dale Scheetz [EMAIL PROTECTED] writes:
  What I am requesting is that the submitter of a bug take some time, in
  exchange for the time they expect from the maintainer, and verify that the
  bug has not been reported already. If it has, it is appropriate to send
  the maintainer a confirmation that you also experienced the bug and any
  additional information you can contribute to the solution. This
  confirmation should be CC'd to the original bug report, for continuity
  purposes. But creating an additional report is both confusing and
  administrativly ugly.

 Rob This should be mandated (I thought it was).  Not that I've always been
 Rob as careful as I should have been, but I've tried to be pretty good.
 Rob It's extremely helpful (especially for high-traffic-area/critical
 Rob packages like X and libc) that you not end up with floods of redundant
 Rob bugs.

Umm, no. It would be nice if they did it, but a novce user is
 perfectly free to just file a bug report. I know I often do. I find
 an error, usually that by itself is a frustrating experience, also,
 it is likely to be in the middle of a largish upgrade (I upgrade ever
 so often). I am not into going over and looking up stuff in the
 archive for a dozen pacxkages; I just send a report.

Make bug reporting any more onerous than it is, and peole
 merely stop filing reports.

For the most part the maintainer knows the bugs on a package
 better than anyone else, and the maintainers are fairly well versed
 in the Bug system; merging bugs is not all that hard.

I realize when you inherit a package with a gazillion bugs
 that is not as easy; but it gets better as you get more familiar with
 the bugs on your packages.

 Rob Not only that, but the user might discover a workaround in the bug log
 Rob that helps them out.  This might be the best way to sell the idea :

Yes. It is a good idea. It just should not be mandatory.

manoj

-- 
 The most merciful thing in the world ... is the inability of the
 human mind to correlate all its contents. Lovecraft
Manoj Srivastava  [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Bug reporting proceedure, was Re: Bug#24066: libc6: rsh segfaults as , a result of new libc 2.0.7r2

1998-06-30 Thread Rob Browning 
Manoj Srivastava [EMAIL PROTECTED] writes:

   Make bug reporting any more onerous than it is, and peole
  merely stop filing reports.

I suppose there is something to that.

   For the most part the maintainer knows the bugs on a package
  better than anyone else, and the maintainers are fairly well versed
  in the Bug system; merging bugs is not all that hard.

Yeah, I just got finished merging several duplicate bugs for
emacsen-common.

   Yes. It is a good idea. It just should not be mandatory.

OK, I'll buy that.  We should just *suggest* it then.

-- 
Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Bug reporting proceedure, was Re: Bug#24066: libc6: rsh segfaults as , a result of new libc 2.0.7r2

1998-06-30 Thread Dale Scheetz 
On 29 Jun 1998, Manoj Srivastava wrote:

 Hi,
 Rob == Rob Browning [EMAIL PROTECTED] writes:
 
  Rob Dale Scheetz [EMAIL PROTECTED] writes:
   What I am requesting is that the submitter of a bug take some time, in
   exchange for the time they expect from the maintainer, and verify that the
   bug has not been reported already. If it has, it is appropriate to send
   the maintainer a confirmation that you also experienced the bug and any
   additional information you can contribute to the solution. This
   confirmation should be CC'd to the original bug report, for continuity
   purposes. But creating an additional report is both confusing and
   administrativly ugly.
 
  Rob This should be mandated (I thought it was).  Not that I've always been
  Rob as careful as I should have been, but I've tried to be pretty good.
  Rob It's extremely helpful (especially for high-traffic-area/critical
  Rob packages like X and libc) that you not end up with floods of redundant
  Rob bugs.
 
   Umm, no. It would be nice if they did it, but a novce user is
  perfectly free to just file a bug report. I know I often do. I find
  an error, usually that by itself is a frustrating experience, also,
  it is likely to be in the middle of a largish upgrade (I upgrade ever
  so often). I am not into going over and looking up stuff in the
  archive for a dozen pacxkages; I just send a report.

When you do so, without adequate investigation, you imply that the
understanding and repair of the bug is the sole responsibility of the
maintianer. I submit, in the free software community, that this is a bogus
position. Because of the freedom we provide, the user bears some
responsibility in the maintainance of the products they use. I suggest
that any bug report that says no more than xxx is broken is a useless
report submitted by a lazy user, and, until more information is
forthcoming, is not likely to produce results.

 
   Make bug reporting any more onerous than it is, and peole
  merely stop filing reports.
 
What is so onerous about checking to see if the bug has already been
reported? As Rob said, it could provide the work around information that
is needed to resolve the problem.

Suggesting, even strongly, that it is proper proceedure when submitting a
bug, to research the bug reporting system first, and provide useful
information second, doesn't seem onerous to me, and has several practical
uses for the bug submitter, as well as the maintainer.


   For the most part the maintainer knows the bugs on a package
  better than anyone else, and the maintainers are fairly well versed
  in the Bug system; merging bugs is not all that hard.
 
Merging bugs is not that hard, but it also doesn't provide any bookkeeping
advantages to the maintainer. The bugs still get reported in the
problems report separately. Nags still come separately. This requires
that the maintainer keep records of which bugs have been merged.

   I realize when you inherit a package with a gazillion bugs
  that is not as easy; but it gets better as you get more familiar with
  the bugs on your packages.

NO, it doesn't. I spent one hole weekend, just after I took over glibc,
going over all of the bug reports on that package. I was able to retire 30
bugs (out of 120) that were either fixed, or no longer a problem. During
that time period 50 bug reports were submitted against this package. So,
after a weekends work I had managed to get behind by an additional 20 bug
reports. :-(

If you look at the list today, you will see many ancient bug reports on
locales and timezones which pre-date glibc. How does one deal with these?

I am tempted to close all ancient bug reports on principle, but that
certainly violates the spirit, if not the letter of policy.

 
  Rob Not only that, but the user might discover a workaround in the bug log
  Rob that helps them out.  This might be the best way to sell the idea :
 
   Yes. It is a good idea. It just should not be mandatory.

Mandatory is a non-functional term in this group. Nothing is mandatory
(even though some would wish it were) in a voluntary organization.

I am only suggesting that we make clear that the socially correct way to
report a bug involves adequate research on the part of the bug reporter.
This requirement provides additional service to the user at the same
time that it provides the maintainer with more chance to fix the problem.

Waiting is,

Dwarf
--
_-_-_-_-_-   Author of The Debian Linux User's Guide  _-_-_-_-_-_-

aka   Dale Scheetz   Phone:   1 (850) 656-9769
  Flexible Software  11000 McCrackin Road
  e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Bug reporting proceedure, was Re: Bug#24066: libc6: rsh segfaults as , a result of new libc 2.0.7r2

1998-06-30 Thread Manoj Srivastava 
Hi,
Dale == Dale Scheetz [EMAIL PROTECTED] writes:

 Dale On 29 Jun 1998, Manoj Srivastava wrote:

  Umm, no. It would be nice if they did it, but a novce user is
  perfectly free to just file a bug report. I know I often do. I find
  an error, usually that by itself is a frustrating experience, also,
  it is likely to be in the middle of a largish upgrade (I upgrade ever
  so often). I am not into going over and looking up stuff in the
  archive for a dozen pacxkages; I just send a report.

 Dale When you do so, without adequate investigation, you imply that
 Dale the understanding and repair of the bug is the sole
 Dale responsibility of the maintianer. I submit, in the free
 Dale software community, that this is a bogus position. Because of
 Dale the freedom we provide, the user bears some responsibility in
 Dale the maintainance of the products they use. I suggest that any
 Dale bug report that says no more than xxx is broken is a useless
 Dale report submitted by a lazy user, and, until more information is
 Dale forthcoming, is not likely to produce results.

I agree. However; Debiasn is also for novices and newcomers to
 Linux, and to Debian. They may well not have the skill, or the time,
 to understand and repair bugs (heck -- most of the time even seasoned
 veterans don't). 

I would rather have bugs reports, than none. People are
 lazy. Mandate more work for a bug report, people won't report bugs. 

You are thinking from a We are all contributors mind set;
 which is nice, but we have to address people who are casual users
 too, I think.
 
  Make bug reporting any more onerous than it is, and peole
  merely stop filing reports.

 Dale What is so onerous about checking to see if the bug has
 Dale already been reported? As Rob said, it could provide the work
 Dale around information that is needed to resolve the problem.

In the middle of an upgrade when one gets 10 bugs, One does
 not have time to research them. You just report this, this, and that
 went wrong, this is all the data I have, thought you would like to
 know. 

And I say I like to get reports like that. I may ask for more
 information, but I do not demand the reporter do anything more. 

 Dale Suggesting, even strongly, that it is proper proceedure when
 Dale submitting a bug, to research the bug reporting system first,
 Dale and provide useful information second, doesn't seem onerous to
 Dale me, and has several practical uses for the bug submitter, as
 Dale well as the maintainer.

Oh, suggestions are fine. 

  Yes. It is a good idea. It just should not be mandatory.

 Dale Mandatory is a non-functional term in this group. Nothing is
 Dale mandatory (even though some would wish it were) in a voluntary
 Dale organization.

Also, the users may not be quite as vested in Debian as the
 developers are, it is even harder to tell them to do stuff. It has
 vbeen suggested we should be grateful they take time out their busy
 lives to even report the bug. 

 Dale I am only suggesting that we make clear that the socially
 Dale correct way to report a bug involves adequate research on the
 Dale part of the bug reporter.  This requirement provides
 Dale additional service to the user at the same time that it
 Dale provides the maintainer with more chance to fix the problem.

Sure. Umm, well, maybe not as strongly as that. More on the
 lines of  we suggest that you look into the BTS to see if the
 problem has been reported before, and see if a workaround has been
 suggested there . Socially correct may sound like talking down
 to and berating the users

Having written that, I don't think I made much of an
 improvement in the wording. Maybe better hands than I can write the
 gentle exhortation to check the BTS.

However, no developer should take that statement and berate
 the reporter for shirking their duty (unless, of course, it is a
 fellow developer) ;-)

manoj
-- 
 We all agree on the necessity of compromise.  We just can't agree on
 when it's necessary to compromise. --Larry Wall in
 [EMAIL PROTECTED]
Manoj Srivastava  [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E


--  
Unsubscribe?  mail -s unsubscribe [EMAIL PROTECTED]  /dev/null

Re: Bug reporting proceedure, was Re: Bug#24066: libc6: rsh segfaults as , a result of new libc 2.0.7r2

1998-06-30 Thread Adam P. Harris 

Geeze, the crossposting is horrendous.  I don't see this as a policy
issue, so followups to debian-devel or debian-user only please.

Dale Scheetz [EMAIL PROTECTED] writes:
 On 29 Jun 1998, Manoj Srivastava wrote:
  Make bug reporting any more onerous than it is, and peole
   merely stop filing reports.

 What is so onerous about checking to see if the bug has already been
 reported? As Rob said, it could provide the work around information that
 is needed to resolve the problem.
 
 Suggesting, even strongly, that it is proper proceedure when submitting a
 bug, to research the bug reporting system first, and provide useful
 information second, doesn't seem onerous to me, and has several practical
 uses for the bug submitter, as well as the maintainer.

I agree with Dale.  I think we should encourage submitters to check
the BTS before posting.  But the reality is, this will not always
happen; I don't think we should flame people for not checking first.

I think it's important to at the same time make it easy for bug
submitters and easy for package maintainers.  I don't think we're out
of line asking a bug submitter to check if the bug is already
reported.  For instance, if I submit a bug against CVS or bash, they
always say, read the known problems list first, and/or read the FAQ
first.  Checking the BTS is easy in comparison to having to read a
whole big FAQ.

--
.A. P. [EMAIL PROTECTED]URL:http://www.onShore.com/


--  
Unsubscribe?  mail -s unsubscribe [EMAIL PROTECTED]  /dev/null

Re: Bug reporting proceedure, was Re: Bug#24066: libc6: rsh segfaults as , a result of new libc 2.0.7r2

1998-06-30 Thread Ed Cogburn 
Dale Scheetz wrote:
 
 On 29 Jun 1998, Manoj Srivastava wrote:
 
  Hi,
  Rob == Rob Browning [EMAIL PROTECTED] writes:
 
   Rob Dale Scheetz [EMAIL PROTECTED] writes:
What I am requesting is that the submitter of a bug take some time, in
exchange for the time they expect from the maintainer, and verify that 
  the
bug has not been reported already. If it has, it is appropriate to send
the maintainer a confirmation that you also experienced the bug and any
additional information you can contribute to the solution. This
confirmation should be CC'd to the original bug report, for continuity
purposes. But creating an additional report is both confusing and
administrativly ugly.
 
   Rob This should be mandated (I thought it was).  Not that I've always been
   Rob as careful as I should have been, but I've tried to be pretty good.
   Rob It's extremely helpful (especially for high-traffic-area/critical
   Rob packages like X and libc) that you not end up with floods of redundant
   Rob bugs.
 
Umm, no. It would be nice if they did it, but a novce user is
   perfectly free to just file a bug report. I know I often do. I find
   an error, usually that by itself is a frustrating experience, also,
   it is likely to be in the middle of a largish upgrade (I upgrade ever
   so often). I am not into going over and looking up stuff in the
   archive for a dozen pacxkages; I just send a report.
 
 When you do so, without adequate investigation, you imply that the
 understanding and repair of the bug is the sole responsibility of the
 maintianer. I submit, in the free software community, that this is a bogus
 position. Because of the freedom we provide, the user bears some
 responsibility in the maintainance of the products they use. I suggest
 that any bug report that says no more than xxx is broken is a useless
 report submitted by a lazy user, and, until more information is
 forthcoming, is not likely to produce results.
 
 
Make bug reporting any more onerous than it is, and peole
   merely stop filing reports.
 
 What is so onerous about checking to see if the bug has already been
 reported? As Rob said, it could provide the work around information that
 is needed to resolve the problem.
 
 Suggesting, even strongly, that it is proper proceedure when submitting a
 bug, to research the bug reporting system first, and provide useful
 information second, doesn't seem onerous to me, and has several practical
 uses for the bug submitter, as well as the maintainer.
 
For the most part the maintainer knows the bugs on a package
   better than anyone else, and the maintainers are fairly well versed
   in the Bug system; merging bugs is not all that hard.
 
 Merging bugs is not that hard, but it also doesn't provide any bookkeeping
 advantages to the maintainer. The bugs still get reported in the
 problems report separately. Nags still come separately. This requires
 that the maintainer keep records of which bugs have been merged.
 
I realize when you inherit a package with a gazillion bugs
   that is not as easy; but it gets better as you get more familiar with
   the bugs on your packages.
 
 NO, it doesn't. I spent one hole weekend, just after I took over glibc,
 going over all of the bug reports on that package. I was able to retire 30
 bugs (out of 120) that were either fixed, or no longer a problem. During
 that time period 50 bug reports were submitted against this package. So,
 after a weekends work I had managed to get behind by an additional 20 bug
 reports. :-(
 
 If you look at the list today, you will see many ancient bug reports on
 locales and timezones which pre-date glibc. How does one deal with these?
 
 I am tempted to close all ancient bug reports on principle, but that
 certainly violates the spirit, if not the letter of policy.
 
 
   Rob Not only that, but the user might discover a workaround in the bug log
   Rob that helps them out.  This might be the best way to sell the idea :
 
Yes. It is a good idea. It just should not be mandatory.
 
 Mandatory is a non-functional term in this group. Nothing is mandatory
 (even though some would wish it were) in a voluntary organization.
 
 I am only suggesting that we make clear that the socially correct way to
 report a bug involves adequate research on the part of the bug reporter.
 This requirement provides additional service to the user at the same
 time that it provides the maintainer with more chance to fix the problem.
 
 Waiting is,
 
 Dwarf


Here is my two cents worth as a novice user:

First, lets get the above information put in a place where new novice 
users
can't miss.  In other words put it right under their nose.  At the end of
the install procedure of future Debs, have the tail end of the install
script (before they are taken to dselect?) point them to a few critical
plain text files *already on the system* (put them in the base system) in a
/usr/doc/dir

Re: Bug reporting proceedure, was Re: Bug#24066: libc6: rsh segfaults as , a result of new libc 2.0.7r2

1998-06-30 Thread Dale Scheetz 
On 30 Jun 1998, Manoj Srivastava wrote:

 Hi,
 Dale == Dale Scheetz [EMAIL PROTECTED] writes:
 
  Dale On 29 Jun 1998, Manoj Srivastava wrote:
 
   Umm, no. It would be nice if they did it, but a novce user is
   perfectly free to just file a bug report. I know I often do. I find
   an error, usually that by itself is a frustrating experience, also,
   it is likely to be in the middle of a largish upgrade (I upgrade ever
   so often). I am not into going over and looking up stuff in the
   archive for a dozen pacxkages; I just send a report.
 
  Dale When you do so, without adequate investigation, you imply that
  Dale the understanding and repair of the bug is the sole
  Dale responsibility of the maintianer. I submit, in the free
  Dale software community, that this is a bogus position. Because of
  Dale the freedom we provide, the user bears some responsibility in
  Dale the maintainance of the products they use. I suggest that any
  Dale bug report that says no more than xxx is broken is a useless
  Dale report submitted by a lazy user, and, until more information is
  Dale forthcoming, is not likely to produce results.
 
   I agree. However; Debiasn is also for novices and newcomers to
  Linux, and to Debian. They may well not have the skill, or the time,
  to understand and repair bugs (heck -- most of the time even seasoned
  veterans don't). 

Well, I disagree with this point of view. Yes, Debian wishes to support
newcomers to Linux. That is why we have debian-user. We have a
responsibility to those new users to train them to be free users.
They can only do that if they become familiar with the ins and outs of the
Debian Way.

I am simply suggesting that we should put some additional thought into how
we educate these new users to be productive members of the community.

 
   I would rather have bugs reports, than none. People are
  lazy. Mandate more work for a bug report, people won't report bugs. 
 
This suggests that I should start forwarding all my bugs to you, until you
change your mind ;-)

Seriously though, a bug report that says libc6 is broken is not a bug
report, as far as I can tell. The only way to get a better class of bug
report is to educate a better class of user (and developer).

   You are thinking from a We are all contributors mind set;
  which is nice, but we have to address people who are casual users
  too, I think.

And we should address them as potential contributors as well, providing
the instructions that will make them better casual users.

You have been making the case for why we are all about sofware freedom
with reguard to the DFSG thread, what makes this position any different.
Educating members of the community, both new and old, on the social
responsibilities of the membersion is very much a part of our job.

  
   Make bug reporting any more onerous than it is, and peole
   merely stop filing reports.
 
  Dale What is so onerous about checking to see if the bug has
  Dale already been reported? As Rob said, it could provide the work
  Dale around information that is needed to resolve the problem.
 
   In the middle of an upgrade when one gets 10 bugs, One does
  not have time to research them. You just report this, this, and that
  went wrong, this is all the data I have, thought you would like to
  know. 

During upgrade or new installation, the problems that occur can be
adequately reported as couldn't install xxx because of conflit with YYY
without any research being done. However, I would still suggest to you (or
anyone reporting such problems) that you will be well served by looking at
the BTS for similar bug reports in hopes of finding a work around. The pay
off for the user is larger here than for the developer.

 
   And I say I like to get reports like that. I may ask for more
  information, but I do not demand the reporter do anything more. 
 
I never said demand anything. I am talking about higher education for
users, not binding them to a post in the town square and giving them 20
lashes.

BTW, if you don't have enough bug reports, I have some I would gladly lend
you ;-)

  Dale Suggesting, even strongly, that it is proper proceedure when
  Dale submitting a bug, to research the bug reporting system first,
  Dale and provide useful information second, doesn't seem onerous to
  Dale me, and has several practical uses for the bug submitter, as
  Dale well as the maintainer.
 
   Oh, suggestions are fine. 
 
   Yes. It is a good idea. It just should not be mandatory.
 
  Dale Mandatory is a non-functional term in this group. Nothing is
  Dale mandatory (even though some would wish it were) in a voluntary
  Dale organization.
 
   Also, the users may not be quite as vested in Debian as the
  developers are, it is even harder to tell them to do stuff. It has
  vbeen suggested we should be grateful they take time out their busy
  lives to even report the bug. 

Well, grateful is not the term I would always use ;-)

 
  Dale I am

Re: Bug reporting proceedure, was Re: Bug#24066: libc6: rsh segfaults as , a result of new libc 2.0.7r2

1998-06-30 Thread Manoj Srivastava 
Hi,
Dale == Dale Scheetz [EMAIL PROTECTED] writes:

 Dale I never said demand anything. I am talking about higher
 Dale education for users, not binding them to a post in the town
 Dale square and giving them 20 lashes.

;-) Well said. I agree with this post, completely. (If you
 ;look back, I jumped in when people said mandatory). However, this
 ;post represents a sentiment that I support.

If langiuage to this effect is included somewhere, I would
 like to have (excerpts from) this message to be recorded as
 rationale. 

manoj
-- 
 If all economists were laid end to end, they would not reach a
 conclusion. George Benard Shaw
Manoj Srivastava  [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E


--  
Unsubscribe?  mail -s unsubscribe [EMAIL PROTECTED]  /dev/null

Re: Bug reporting proceedure, was Re: Bug#24066: libc6: rsh segfaults as , a result of new libc 2.0.7r2

1998-06-30 Thread Dale Scheetz 
On 30 Jun 1998, Manoj Srivastava wrote:

 Hi,
 Dale == Dale Scheetz [EMAIL PROTECTED] writes:
 
  Dale I never said demand anything. I am talking about higher
  Dale education for users, not binding them to a post in the town
  Dale square and giving them 20 lashes.
 
   ;-) Well said. I agree with this post, completely. (If you
  ;look back, I jumped in when people said mandatory). However, this
  ;post represents a sentiment that I support.
 
   If langiuage to this effect is included somewhere, I would
  like to have (excerpts from) this message to be recorded as
  rationale. 
 
I really don't have anything to say here but thank you! It was your tag
line that prompted the reply...

   manoj
 -- 
  If all economists were laid end to end, they would not reach a
  conclusion. George Benard Shaw

I don't know why, but the above quote reminded me of a funny joke that
bears on the current discussion, if obliquely.

Q: Why is computer documentation like sex?

A: Because even when it is the worst you have ever had, it is better than
   nothing.

Luck, 

Dwarf
--
_-_-_-_-_-   Author of The Debian Linux User's Guide  _-_-_-_-_-_-

aka   Dale Scheetz   Phone:   1 (850) 656-9769
  Flexible Software  11000 McCrackin Road
  e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-


--  
Unsubscribe?  mail -s unsubscribe [EMAIL PROTECTED]  /dev/null

Re: Bug reporting proceedure, was Re: Bug#24066: libc6: rsh segfaults as , a result of new libc 2.0.7r2

1998-06-29 Thread Rob Browning 
Dale Scheetz [EMAIL PROTECTED] writes:

 What I am requesting is that the submitter of a bug take some time, in
 exchange for the time they expect from the maintainer, and verify that the
 bug has not been reported already. If it has, it is appropriate to send
 the maintainer a confirmation that you also experienced the bug and any
 additional information you can contribute to the solution. This
 confirmation should be CC'd to the original bug report, for continuity
 purposes. But creating an additional report is both confusing and
 administrativly ugly.

This should be mandated (I thought it was).  Not that I've always been
as careful as I should have been, but I've tried to be pretty good.
It's extremely helpful (especially for high-traffic-area/critical
packages like X and libc) that you not end up with floods of redundant
bugs.

 I am not looking to stifle information flow about bugs. I am suggesting
 that if the reporter of the bug will spend some time doing the filing
 correctly the task becomes possible and the end user and the maintainer
 both benefit.

Not only that, but the user might discover a workaround in the bug log
that helps them out.  This might be the best way to sell the idea :

-- 
Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Bug reporting mode?

1997-04-09 Thread Barry A. Warsaw 

 KMH == Karl M Hegbloom [EMAIL PROTECTED] writes:

KMH Is there a bug reporting mode for reporting XEmacs crashes
KMH and package blonk spiels?

Well reporter.el is something I wrote a while back that package
authors can use for bug reports.  It's standard now with both Emacsen
and quite a few packages are using it.  The convention I use (and I
think ought to be the standard) is C-c C-b starts the bug reporting
composition buffer.

-Barry