GNU Info

Info Node: (kpathsea.info)Bug checklist

(kpathsea.info)Bug checklist


Next: Mailing lists Up: Reporting bugs
Enter node , (file) or (file)node

Bug checklist
-------------

  Before reporting a bug, please check below to be sure it isn't already
known (Note: 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 (Note: TeX or Metafont failing.).

   * Any additional information that will be helpful in reproducing,
     diagnosing, or fixing the bug.


automatically generated by info2www version 1.2.2.9