179 lines
6.8 KiB
Plaintext
179 lines
6.8 KiB
Plaintext
|
|
SAVE THIS! SAVE THIS! It contains important instructions.
|
|
|
|
The Linux Email Support System is now ready for general use.
|
|
It is not bug free, and there will be delays and other teething
|
|
problems for a while.
|
|
|
|
Purpose:
|
|
The purpose of the Linux Email Support System is to provide
|
|
a forum for people to ask questions without worrying about being
|
|
flamed for a non-Linux specific question or for asking a FAQ.
|
|
|
|
Who Should Use it?
|
|
The Linux Email Support System is for anyone who is having
|
|
a problem with Linux. It is not intended to replace comp.os.linux[.announce]
|
|
or the mailing lists, but rather to supplement them with a forum
|
|
designed specifically to deal with the volume of questions on
|
|
comp.os.linux which are easily answered.
|
|
|
|
Why Use It?
|
|
If you send a question to the Linux Email Support System, it
|
|
will be routed to a single individual who will take responsibility for
|
|
answering it. If that individual can't answer it, (s)he will forward
|
|
it to someone that may be able to. Everyone is likely to benefit
|
|
because there will be less traffic in comp.os.linux, and each question
|
|
will get a single individual to deal with it, rather than many people
|
|
answering one question while a second question is ignored.
|
|
|
|
When Should I use It?
|
|
This is a tough question, and is really a judgement call. If
|
|
you believe your question is interesting or otherwise very current, you
|
|
should probably post it directly. However if you are having problems
|
|
with a common program or subsystem, you should probably use the
|
|
Linux Email Support System based on the philosophy that if it really
|
|
worked that poorly, everyone would be screaming about it. Also if you
|
|
don't have much experience with Unix in general you should read the
|
|
FAQ from comp.unix.questions and use the Linux Email Support System
|
|
until you feel more confident (or get asbestos under ware 8-).
|
|
|
|
How do I know the answer I got is correct?
|
|
There is no guarantee of the correctness of any given answer.
|
|
However to help prevent the distribution of misinformation, all answers
|
|
(The first time they are answered only) are sent to the appropriate
|
|
channel of the mailing list. That way many people see the answer, and
|
|
if it is incorrect, someone will probably say something. You are
|
|
also free to ask the question again in a more public forum
|
|
such as comp.os.linux and point out why you think the answer as in error.
|
|
|
|
SAVE THIS PART !!!!
|
|
|
|
How do I use It?
|
|
|
|
You just mail your question to linux-bugs@sunsite.unc.edu (It
|
|
is not only for bugs, but any question. We hope to have the
|
|
additional name linux-support@???? sometime soon.) There is one
|
|
caveat; however, the Linux Email Support System has been designed to
|
|
be easy for the software maintainers and volunteers to use. The net
|
|
affect is that there is a reasonably rigid format. Every message must
|
|
contain the following fields.
|
|
|
|
Keywords:
|
|
Summary:
|
|
Program:
|
|
Kernel:
|
|
Hardware:
|
|
Description:
|
|
Expected:
|
|
|
|
The order is not important; but ALL the fields must be present in ALL
|
|
problem-reports, or the software will return the question to you. The
|
|
format purpose of each of the fields is
|
|
|
|
Keywords: Single line.
|
|
Used to try to see if this is a FAQ and can be auto answered
|
|
by machine. Proper use of this field will greatly increase the number
|
|
of messages which can be handled per day.
|
|
|
|
Summary: Single Line.
|
|
Quick summary of the problem. Also used by the software to see if
|
|
it's a FAQ. And makes it easier for the Volunteer to answer it.
|
|
|
|
Program: Single Line.
|
|
Program and Version number that is causing problems. This should be
|
|
included whenever possible; even if you think it is a general problem
|
|
as it makes things easier to reproduce and track down.
|
|
|
|
Kernel: Multi Line.
|
|
This is kernel version number and options configured in. You should also
|
|
include where you got it (compiled it yourself, SLS, ...) in case it turns
|
|
out to be a kernel problem and a system map file is needed.
|
|
|
|
Hardware: Multi Line.
|
|
This is the hardware you are experiencing the problem on. It is not
|
|
always relevant, but it is often hard to tell, and should be as complete
|
|
as possible. Especially include things like the type of hard drive
|
|
controller etc.
|
|
|
|
Description: Multi Line.
|
|
This is a complete description of the problem; including how to reproduce
|
|
it. Include transcripts generated via the script program, dejagnu scripts,
|
|
or xterm whenever possible.
|
|
|
|
Expected: Multi Line.
|
|
This is mostly for cases when something happens that is different from
|
|
what you expect; i.e. select alters the timeout value. It should also
|
|
be included when you are asking about features that you don't think
|
|
are present in Linux, or need to be emulated. If you can include a
|
|
portion of a man page or other documentation which backs up the
|
|
behavior you wish, it would be helpful. You can also leave this field
|
|
blank in cases of programs simply crashing, or if you feel the Description is
|
|
enough.
|
|
|
|
Here is an example
|
|
------
|
|
mail linux-bugs@sunsite.unc.edu
|
|
Subject: problem with gcc
|
|
|
|
Keywords: gcc link ld math library
|
|
Summary: Math externals not linked in.
|
|
Program: gcc -lm foo.c
|
|
Kernel: .99 pl9 from SLS with tcp/ip and ipc_delta patches
|
|
Hardware: 386-20 8M ram ESDI hard drive
|
|
Description: gcc -lm foo.c can't find floor.
|
|
|
|
Script started on Mon May 31 12:22:25 1993
|
|
gcc -lm foo.c
|
|
elaine30-[1> gcc -lm foo.c
|
|
foo.o: Undefined symbol _floor referenced from text segment
|
|
elaine30-[2> exit
|
|
exit
|
|
|
|
script done on Mon May 31 12:22:36 1993
|
|
--- foo.c --
|
|
#include <math.h>
|
|
|
|
|
|
main ()
|
|
{
|
|
int x;
|
|
x = floor (12.30);
|
|
}
|
|
--- end of foo.c ---
|
|
|
|
Expected:
|
|
.
|
|
-----
|
|
End Example.
|
|
|
|
|
|
This is great how can I help?
|
|
If you would like to help, there are many things you can do.
|
|
If you feel capable, you can volunteer to answer questions. You
|
|
can fix problems with the software. Donating resources (hard drive
|
|
space etc.) might also be useful. You could combine our scripts
|
|
with GNATS for an incredibly powerful bug tracking system.
|
|
If you would like to help mail bir7@leland.stanford.edu and tell me
|
|
what you would like to do.
|
|
|
|
Who do we have to thank for this?
|
|
You should thank all the volunteers as well as the sunsite admins,
|
|
especially jem@sunsite.unc.edu, and Ted. Currently the volunteers are
|
|
(group by category they intend to answer questions about.)
|
|
|
|
Jacques Gelinas,dthumim@athena.mit.edu,Edward T. Shiobara,
|
|
Matthew D. Stock ,Michael K. Johnson, Peter F. Couvares,
|
|
Andrew Tridgell:,probreak@matt.ksu.ksu.edu,Eric Johnson,
|
|
John Turnbull,Brian E. Gallew,Joeri van Ruth,John Henders,
|
|
Matt Welsh,Philip Copeland,Richie Lai,Erik Troan,
|
|
Arnt Gulbrandsen,Mitchum Dsouza,Ross Biro,Jeff Grills,
|
|
Michael Oreilly,Darren Stadler?,Thomas Dunbar,Andreas Neubacher
|
|
Ian Jackson,Johannes Grosen,Nick Holloway,Onnei ?,Jeremy Bettis,
|
|
Paul Gover,David Hoelzer,H. Peter Anvin,Kevin Cummings,
|
|
Scott A. Laird.
|
|
|
|
Send comments to bir7@leland.stanford.edu
|
|
Ross Biro bir7@leland.stanford.edu
|
|
Member League for Programming Freedom (LPF)
|
|
mail lpf@uunet.uu.net to protect your Freedom
|