This FAQ is very incomplete
Important: Reading this FAQ will get your bugs fixed faster
Feelgood: And the world will be a slightly better place for everyone. (-:
One of the important things about developing is to have time to actually develop. In order to do this, Mandrake's developers have to spend less time asking for more information about a bug, and less time reading unhelpful bug reports.
The main point in reporting a bug is to get it fixed. Paying attention to this FAQ will get your bugs fixed faster and more often.
One of the great opportunities in Open Source is to get involved and learn, another is to contribute to something truly worthwhile, something larger than yourself. You will learn from seeing how your bugs fixed, and each bug you help to squash is one less to plague millions of other Mandrake (and other Linux) users worldwide.
The developers will like you more if your reports are comprehensive and helpful.
Cooker is for development of the next Mandrake release; it is not a forum for fixing bugs in the current or past releases, and it is most definitely not a user support forum. For those, we recommend the Mandrake User website.
Questions posted to Cooker which are about non-development systems may be silently ignored, and they may attract chastisement from list members irritated by what they see as pollution on an already very busy list.
Check the Cooker list archives, or if you have been on the list for a while, search your mailbox to see if the problem has been mentioned before. It may have already been fixed, there may already be a workaround posted which you can use immediately, or you may have important differences to report.
You might want to try MandrakeForum first if you're not entirely certain that it's not just a mistake in configuration or understanding.
Cooker is a development list, so if your Linux skills are wobbly, it's generally more effective to try bouncing the questions off forums more suited to that level of expertise first. At the very least, they're likely to help you to define your bug better, and so help its chances in Cooker.
(Read The, er, Fine Manual) to make sure you're using the app correctly. A simple `man dhcpcd' would have saved eight or nine messages on the list, had it been done before posting on the day this was written. Other local sources of information include running the app with the --help option, and looking in the /usr/share/doc/nameofapp directory. Many configuration files also have man pages (e.g. `man hosts.deny') and you can do a keyword search with the -k option, or an exhaustive, word-by-word search (takes a long time) with the -K option (e.g. `man -K perl.tools'). Many of the basic GNU system tools (like cp) also have info entries (`info nameofcommand') and builtin BASH commands are described by `help nameofcommand'.
Mention your hardware. ``Dell Inspiron 8100'' is succinct, but saying what kind of video card, CD/DVD drive, PCMCIA cards, USB devices etc that it uses might also be helpful, as might be the country of purchase. For a desktop system, the kind of SCSI controller, motherboard type if known and so on are usually relevant. Don't be put off if you don't know these things, just report what you do know and can find out.
Report the exact version of Cooker you're using; this can be found in /etc/mandrake-release; you can display this file in a console window by typing cat /etc/mandrake-release, then use the mouse to select the text and Ctrl-V to paste it into your email message.
If your problem involves a particular device in your machine (sound card, video card, network card, SCSI controller), get a PCI listing using lspcidrake -f -v which can also be copied and pasted into your email. Devices built into the motherboard are almost certainly PCI of some kind.
Many problems with devices, networks and particular kinds of file systems also involve kernel modules. You can obtain a listing of these to paste in by using the command lsmod.
USB device information can be obtained with lsusb (or in a briefer form with lsusb -t).
Problems with particular packages are often helped by knowing the exact package version. For example, if you're unhappy with something that Konqueror does, you can right-click on the K button, choose Panel, Menu Editor and find out that Konqueror's real name is kfmclient. You will already know the program's name if it is run from a shell prompt.
Now type rpm -qf $(which kfmclient) and rpm will respond (in the case of Mandrake 8.1) with `kdebase-2.2.1-7mdk' which is the name of the base RPM that Konqueror came in. Using rpm -qR packagename will tell you about some of the packages it depends on (for example, mozilla requires the libnspr4 libnss3 indexhtml and perl packages, plus a passel<*> of specific libraries like libXi and libjpeg), and you can use rpm -q packagename to get the exact versions of those to report too, if they seem likely to be involved or you are asked to.
If you have a graphic display problem, the contents of the file /etc/X11/XF86Config-4 may be useful.
If you are running a program from a graphic menu, the program may spit out more debugging information if run from a shell prompt (AKA `terminal window'), and may also have debugging options. Often, such messages are collected in a file called ~/.xsession-error. Sometimes it helps to report the run level for graphics programs (type runlevel at a shell prompt).
If you have some programming knowledge, and are dealing with a problem where a program is bombing out or giving unhelpful error messages, it is often useful to strace the program, for example, strace -f -o program.log program, and look at the strace log in program.log to see what it was actually doing.
If names are not resolving, or are taking a long time to resolve, the contents of the /etc/resolv.conf file may be useful.
If you have a problem during installation, there are log files in the /root directory which are generally useful. In particular, report.bug.gz is likely to be worth reading (use zless) as the vast majority of messages spat out by the installer are collected here.
Screenshots from X (KDE, Gnome, WindowMaker, whatever) can be had from ksnapshot. This can be run from a shell prompt or is available in the menus under Multimedia, Graphics. Use a program like The GIMP to crop the image down to the essentials, and if the result is bigger than a few kilobytes, don't post the image up front but do offer it in your post, or put it on a website and include a link to it.
Screenshots can be made during installation using the F2 key.
Cooker changes rapidly. Check that the version of the package you are running is the latest available at the Cooker mirror you fetched your copy of Cooker from. If it's not, download the new package, and check again for updated versions of the packages it is dependent on. Test again with the updates before reporting. If you still have a problem, but it is different now, mention that in your report.
rpmmon is a handy little PERL script which, amongst other things, will tell you who the maintainer(s) for a package are. It is useful to send them a bug report, and to CC the list so that Mandrake can see that you've reported it directly, and don't need to make their own report.
Unless you strongly suspect that they're connected.
`BUG: package action when I action' is a good start. For example, `BUG: Konqueror 2.2.1-7 freezes when I visit old-firestation.net with Java enabled'.
What this means is: use short words, keep it simple, but describe everything related to the problem.
Whenever I visit xyz.com, abc.org or xyzzy.net in Konqueror with Java enabled, the browser becomes unresponsive and I have to xkill it to close it. This did not happen with Beta5. Mozilla and Netscape render these sites happily.
Paste in all of the information you think will help. Click send.
If you see no response at all after a few days' waiting, try a repost with a slightly different subject, like `Konqueror Java broken in 2.2.1-7, wasn't in 2.2.1-4'.
If you see another problem float past for which you may have an answer, by all means post a `have-you-tried-?' message; this isn't a spoon-fed situation like a classroom, everyone can pitch in and help.
Developers have a lot of stuff to work through. They also have bad days, just like other human beings. Your mileage will vary, so be prepared for days of elation with instant fixes, and days of unresponsive boredom.
Leon Brooks [leon#brooks.fdns.net]
Hamster [hamster#hamsternet.org]
Buchan Milne [bgmilne#cae.co.za]
Guillaume Cottenceau [gc#mandrakesoft.com]
Guillaume Rousse [rousse#ccr.jussieu.fr]
<*> A `passel' is a large collection.