Bug checklist

Before reporting a bug, please check below to be sure it isn't already known (see section Common problems).

Bug reports should be sent via electronic mail to <tex-k@mail.tug.org>, or by postal mail to 135 Center Hill Road / Plymouth, MA 02360 / USA.

The general principle is that a good bug report includes all the information necessary for reproduction. Therefore, to enable investigation, your report should include the following:

• The version number(s) of the program(s) involved, and of Kpathsea itself. You can get the former by giving a sole option `--version' to the program, and the latter by running `kpsewhich --version'. The `NEWS' and `ChangeLog' files also contain the version number.
• The hardware, operating system (including version number), compiler, and make program you are using (the output of uname -a is a start on the first two, though often incomplete). If the bug involves the X window system, include X version and supplier information as well (examples: X11R6 from MIT; X11R4 from HP; OpenWindows 3.3 bundled with SunOS 4.1.4).
• Any options you gave to configure. This is recorded in the `config.status' files. If you are reporting a bug in `configure' itself, it's probably system-dependent, and it will be unlikely the maintainers can do anything useful if you merely report that thus-and-such is broken. Therefore, you need to do some additional work: for some bugs, you can look in the file `config.log' where the test that failed should appear, along with the compiler invocation and source program in question. You can then compile it yourself by hand, and discover why the test failed. Other `configure' bugs do not involve the compiler; in that case, the only recourse is to inspect the configure shell script itself, or the Autoconf macros that generated configure.
• The log of all debugging output, if the bug is in path searching. You can get this by setting the environment variable KPATHSEA_DEBUG to `-1' before running the program. Please look at the log yourself to make sure the behavior is really a bug before reporting it; perhaps "old" environment variable settings are causing files not to be found, for example.
• The contents of any input files necessary to reproduce the bug. For bugs in DVI-reading programs, for example, this generally means a DVI file (and any EPS or other files it uses)---TeX source files are helpful, but the DVI file is necessary, because that's the actual program input. GNU shar, available from `ftp://prep.ai.mit.edu/pub/gnu' is a convenient way of packaging multiple (possibly binary) files for electronic mail. If you feel your input files are too big to send by email, you can ftp them to `ftp://ftp.tug.org/incoming' (that directory is writable, but not readable).
• If you are sending a patch (do so if you can!), please do so in the form of a context diff (`diff -c') against the original distribution source. Any other form of diff is either not as complete or harder for me to understand. Please also include a `ChangeLog' entry.
• If the bug involved is an actual crash (i.e., core dump), it is easy and useful to include a stack trace from a debugger (I recommend the GNU debugger GDB, available from `ftp://prep.ai.mit.edu/pub/gnu'). If the cause is apparent (a NULL value being dereferenced, for example), please send the details along. If the program involved is TeX or Metafont, and the crash is happening at apparently-sound code, however, the bug may well be in the compiler, rather than in the program or the library (see section TeX or Metafont failing).
• Any additional information that will be helpful in reproducing, diagnosing, or fixing the bug.

Go to the first, previous, next, last section, table of contents.