(→When to report a bug: fixing links) |
(→When to report a bug: fix formatting) |
||
Line 21: | Line 21: | ||
* You haven't modified Wine in any way; i.e. you are using a prepackaged binary without any custom patches or modifications or have built from the official WineHQ source by doing: | * You haven't modified Wine in any way; i.e. you are using a prepackaged binary without any custom patches or modifications or have built from the official WineHQ source by doing: | ||
./configure ; make depend ; make | |||
* You are '''not''' using a third party wrapper for Wine (e.g., Crossover, PlayOnLinux, PlayOnMac, Wineskin, Q4Wine, etc.) or custom patches. | * You are '''not''' using a third party wrapper for Wine (e.g., Crossover, PlayOnLinux, PlayOnMac, Wineskin, Q4Wine, etc.) or custom patches. |
Revision as of 15:49, 17 January 2016
Translations of this page:
简体中文
日本語
This page is for notes on how to use Bugzilla to report and triage bugs. There is also some information in the Wine User's Guide, and some generic information on writing good bug reports.
When to report a bug
You should report a bug when:
- Wine doesn't run a program the same way as Windows does (e.g. crashes) with the default Wine configuration (i.e. no dlls from Windows, or DllOverrides set).
- You are using the latest development version of Wine (not stable) (See downloads for information on how to get the latest).
- You tested with a clean Wine directory (default location: "~/.wine", z: drive -> / link exists, no DLL overrides).
- Your system isn't at fault (system hangs/lockups that require a system reboot are usually driver problems).
- Your system has all the libraries that Wine needs.
- You haven't modified Wine in any way; i.e. you are using a prepackaged binary without any custom patches or modifications or have built from the official WineHQ source by doing:
./configure ; make depend ; make
- You are not using a third party wrapper for Wine (e.g., Crossover, PlayOnLinux, PlayOnMac, Wineskin, Q4Wine, etc.) or custom patches.
- You have searched bugzilla, and the problem hasn't been reported already. Check Known Issues as well.
- Also search for the application in the AppDB and look at the bug links for that application, as it could be already reported.
How to report
<!> Each bug report should cover one problem. If there are additional problems with the same application or game, file separate reports for each.
Go to Bugzilla (http://bugs.winehq.org), login, and click Enter bug, then Wine.
* Put the name of the application in the Summary field, followed by a short description of the error, e.g. {{{
WinZip 7: crashes when extracting a zip archive}}}
Use a summary explaining the bug symptoms and the name and version of the program that displays them, not what you think the problem is, so that:
* Users can find duplicates * The problem can be marked as solved by checking that the symptom is gone * The bug remains valid even if your analysis is incorrect
* Describe the bug in the Comments field, e.g. how to make the crash happen: {{{
Wine crashes when I click on the Extract button on the toolbar in WinZip 7.01}}}
If you have any clues as to what the problem is, write them in here. Don't paste too much information in the comments field, just what looks relevant. Do not paste backtraces or error logs in the comments field (attach them instead). For bugs related to graphics, sound, and hardware devices, be sure to write down what hardware and drivers you're using.
Here is an example of what NOT to do
'
* Set Product to Wine and specify Wine version you are using, if in doubt run `wine --version`.
* Provide a download link to a free version of the program / program installer that shows the bug if possible, e.g. {{{
http://download.winzip.com/ngs/winzip175.exe}}}
The download link should point to the exact program version you encountered the bug with (to improve reproducibility).BR Ideally also provide a SHA1 checksum of the installation file, along with the filename, e.g. {{{
$ sha1sum winzip175.exe
885c7e4ea128351e5fe325d98344f27a46222d73 winzip175.exe}}}
This makes it easier for other people to try to reproduce the bug using the same program version, especially when the original download link is broken and it has to be retrieved elsewhere.
* Attach complete terminal output to the bug per instructions [wiki:Self:FAQ#get_log in the FAQ]. You have to Submit the bug first before you're given the option to attach files.
/!\ Please do not paste [:Backtraces:backtraces] or error logs in the comments field, but attach them to your bug report (use a `.txt` file extension, or set MIME type to `text/plain`). Also, please do not paste to the Wiki, AppDB, or the IRC channel. A trace may be temporarily stored at a Pastebin so it can be referred to on IRC (it should still be attached to the bug report itself so everything is archived in one place).
* Set the severity to
* Trivial for a UI glitch that doesn't affect running of a program * Minor for minor loss of functionality, or other problem where an easy workaround is present * Normal for an application crash or other issue * Major for major loss of functionality for a wide range of applications * Critical for a critical problem that prevents all applications from working * Blocker when development and/or testing work cannot be done
For the above example, the severity is Normal. Severity levels above Normal should only be set by experienced users or bugzilla admins, and are not even necessary for 99% of issues. Also, after making your initial report, please leave changing the bug's severity to someone with admin permissions.
* After you have submitted your bug, please add it to the appropriate AppDB page(s). If there is no entry in the AppDB for an application, it might be helpful to add one (though that is not required for the bug report).
Do's and Don't's
* Do write your bug report in English. While many developers speak other languages, English is the language of choice for Wine. * Do select appropriate keywords in your report (a list of accepted keywords is here). * Do attach terminal output (instead of pasting it in a comment). * Do attach small files that clarify the problem (e.g. a screenshot for visual bugs, a sample script for scripting engines) * Do check on your bug every release or two and let us know if the bug is still present. If not, mark it fixed. * ~+Do attach the bug to the correct application in the AppDB.+~
* Don't change the reported version. It should reflect the earliest version of Wine that had the bug. Don't update it every time you test for the bug. * Don't attach large files such as executables unless they are explicitly requested (link to a legitimate download page instead) * Don't ask when the bug will be fixed. If a fix is in progress, it'll likely be posted in the bug. * Don't close fixed bugs. We'll close it whenever the next release is made. * Don't cc yourself to bugs you have reported (there's no need) or reply to email notifications of bug updates (add your comment using the webpage).
Bugzilla Policies
Some general policies for WineHQ's Bugzilla:
- Bug reporters are expected to check their bug on newer Wine versions periodically and to update the bug if it's fixed or still present. If it's still present, simply a comment saying still in wine-1.x.y is enough. If the behavior of the bug has changed in any way, please update the bug with that info as well as an updated log.
- The NEEDINFO status should be used for bugs where A: the reporter did not provide enough information to act on (missing program name, no terminal output, etc.), B: there has been no comment on the bug within 1 year AND no download is available to test (or the download is not enough on its own, e.g., a login is required).
- Bugs that are NEEDINFO for one year will be CLOSED ABANDONED.
See Also
CategoryQualityAssurance