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