GNO Bug Reports
A critical part of GNO development is user feedback. What works
well? What needs improvement? What is broken?
By telling GNO developers this information, you are much
more likely to see improvements.
The traditional method of sending in bug reports is to email the
developer. While this mechanism is simple, it has a few drawbacks:
The GNO Consortium now provides a common bug reporting and tracking system.
While it is primarily intended for bug reports on the GNO base distribution,
reports are also welcome on programs that are not part of the base
distribution (but that still run under GNO). This system is accessible
both though the web and through email.
- Sometimes the original author has moved or is otherwise no longer around,
making it impossible (or at least difficult) to submit bug reports.
- Only the author sees the report. Consequently nobody else knows of
the problem, which can result in unnecessary frusteration and
wasted time for other users.
Bug Reports -- Web Access
The recommended way to submit GNO bug reports is to use the web-based
bug reporting package. There are two ways to access this system:
Note that this reporting system is accessible from Lynx, but is more
readable using a graphical browser. This is unfortunate, but fixing
this problem will require modifications to the bug tracking software
itself. This will be addressed when time permits.
- Guest Access.
This will allow you to submit, update, and view problem
reports, but not perform any other operations.
- Developer Access.
This allows full access to the problem report system, but
is restricted to a small number of "core" developers.
If you feel you should have developer access, you should send
Please do not feel insulted if you are not granted access.
While the web interface allows replies and followups to existing reports,
it is also possible to send replies and followups using regular email.
See the Report Followups subsection under Email Access, below.
Bug Reports -- Email Access
If you prefer to send your bug reports via regular email, you can
send them to
If you do this method, please ensure that your subject line contains
a concise description of the problem, such as
open(2) doesn't set errno
rm broken for HFS volumes
When sending your bug reports in email, please also include the following
information, in addition to your informative subject line:
- With which distribution did you observe the problem? It should be
one of the following:
- the base 2.0.4 distribution
- the v2.0.4 kernel with v2.0.6 libraries
- beta 2.0.6
- Which component is affected? It should be one of the following:
- The GNO Shell
- The Kernel
- Libraries and Header Files
- If you are reporting a problem with a utility or library routine,
include the name of the utility (or routine). If it's available,
also quote the version. This is often given as an rVersion
resource on programs and libraries.
- Give a clear description of the problem. If possible, include
precise instructions on how to reproduce the problem.
- If your problem is with a library routine, give a short
program which exhibits the problem.
- If your program is longer
than one hundred or so, then you can upload the program to
ftp://ftp.gno.org/incoming, preferably as a NuFX (Shrinkit)
archive. Please include a brief description with your upload.
The description can either be included in the NuFX archive or
uploaded as a separate text file.
Note that bug reports to the above address will go straight into
the reporting system. If your bug report contains proprietary information,
you should send it to
If you wish to use the email interface to enter followup text on a
particular, you can do it by emailing your message to
provided that your subject line follows a particular format.
Specifically, the subject line must contain the text
(PR#nn), where nn is the problem report
number. This string must not contain any whitespace or other characters,
except as shown. The parenthesis are part of the string.
The subject line may contain other text, but the above is required
for the message to be recognised as a followup rather than a new problem