Before reporting bugs/problems with released versions, go through this checklist:
If nothing looks like it addresses your problem, then please become acquainted with sendbug(1) before submitting a bug report.Current version problem reports
If your problem is with the -current source tree rather than -release or -stable,
Always provide as much information as possible. Try to pinpoint the exact problem. Give clear instructions on how to reproduce the problem. Try to describe it with as much accuracy and non-confusing terminology as possible, especially if it is not easy to reproduce. Describing problems by saying "it crashes" or "I get strange interrupt issues on this one box that I built" are of no use. Communicate with others (on the mailing lists or any other forum where knowledgeable users congregate) to confirm that the problem is new and preferably repeatable. Please try to make sure it is not a local problem created by using broken or unsupported hardware, or by using unsupported build options or software.
Please don't start fixing problems that require significant work until you are sure you understand them, especially during our release periods when we must not change major sections of code. If you are going to write significant amounts of code, mention it on the mailing lists to make sure no one else is already working on the problem (saving duplication of effort).
The following items should be contained in every bug report:
Note: In case of fatal errors, the error message provided might not
contain all the information available.
In that case, also look at the output in the system log files, such
as those stored in
Also, if you are dealing with an application that has its own log files,
such as httpd, check for errors where it keeps its logs.
/var/run/dmesg.boot. If this is the case, include information from both. Please include this in all bug reports.
/var/log/Xorg.0.logfile in your report in addition to the
Do not be afraid if your bug report becomes rather lengthy. That is a fact of life. It's better to report everything the first time than us having to squeeze the facts out of you. On the other hand, if your input files are huge, it is fair to ask first whether somebody is interested in looking into it.Sending in bug reports
If possible, use the sendbug(1) command to help generate your bug report. It will automatically include some useful information about your hardware that helps diagnose many issues. This tool requires that your system can properly send email. If you cannot use sendbug on a functional SecBSD machine, please send your bug report to firstname.lastname@example.org.
Perhaps what you are sending in is a feature request, not necessarily a bug. New features are accepted, especially with code that implements your suggested new feature.
For debugging some problems, we must have the hardware that has the problem. Please remember that the SecBSD project's resources are limited. You could donate some hardware.