Please report bugs via the GNUstep Bug Tracking database. You can then query the database any time to see the status of your bug report. Due to spam being sent through bug reports, you now have to be a registered user before submitting a bug. Alternatively, you may report bugs by sending a message to email@example.com.
User testing is vital for improving GNUstep, so please report any bugs you find!
What to Report
Please include as much of this information as possible when submitting your report:
- GNUstep version and snapshot date or date of last update from CVS (ideally, on finding a bug you should update your system to the latest version in the CVS repository, in order to avoid reporting problems that have already been fixed).
- Machine/Operating system on which you are running
- Compiler version you use
- A description of the problem, along with either a test program to demonstrate the problem, or a description of how to make the problem appear in one of the test programs that come as part of the GNUstep distribution.
- If you have a problem configuring the libraries, please send the config.log file
- If you have a problem compiling a library or application, please send the complete output of make or at least enough to show what went wrong. If you are using sh or bash, do this: make messages=yes > output.txt 2>&1
The provision of a test/demonstration program is very important for getting the bug fixed quickly. Often, with no test program, we will not do anything with the report for a long time unless it is immediately obvious what the problem is.
If your problem is that some API from OSX 10.5 or later is unimplemented, please report it as a 'Change Request' rather than a 'Bug', and (ideally) contribute an implementation of the missing functionality. In this case please provide documentation for the missing API and a test case to demonstrate what it does.
Actually fixing problems is even more appreciated than sending in bug reports. To do this, first fix the bug and make sure it works. Then send in a diff file containing the differences between the old version of the file(s) you changed and the new version. Use the diff (diff -u oldfile newfile > file.patch) program to do this. For new APIs, provide header changes as well as source code changes, with macros bracketing the changes to specify which version of OSX they correspond to (see existing headers or examples) and comments in the headers documenting the behaviors of new methods etc. For both bugfixes and new functionality, please provide testcases (see the existing testsuite for examples) which demonstrate the correct behavior of the code. Then add a ChangeLog entry in front of this and send the whole thing to the bug database.
If you use emacs, it is easy to add a ChangeLog entry. Just edit the file you changed, and move the cursor to the function or method you changed, then type M-x add-change-log-entry and emacs automatically formats an entry in the ChangeLog file with the information on the file and function you changed. You just need to add a comment about what was fixed. Note: Don't send a diff of the ChangeLog file, just send a copy of your ChangeLog entry normally. Here is an example ChangeLog:
* src/NSAutoreleasePool.m ([NSAutoreleasePool -addObject:]): Remove double_release checking. Increment released_count after setting released array. ([NSAutoreleasePool -dealloc]): Catch release errors. ([NSAutoreleasePool -enableDoubleReleaseCheck:]): Removed method. * src/NSObject.h ([NSObject -autorelease], [NSObject -release]): Add double_release checking. ([NSObject +enableDoubleReleaseCheck:]): New method. * src/Foundation/NSAutoreleasePool.h: Remove +enableDoubleReleaseCheck:, add +autoreleaseCountForObject:. * src/Foundation/NSObject.h: Add +enableDoubleReleaseCheck:. * src/Foundation/objc-load.h: Include objc-api file.