Translations of this page: not yet ported. Translators, please see Discussion page.
This page is for notes on how to use Bugzilla to report and triage bugs. There is also 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).
- You installed and ran the application using Wine, not on your Windows installation.
- 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. If a similar problem appears with multiple applications or games, file separate reports for each. No, really. Even though it may look the same to you, the underlying problem is likely different. If it really is the same, we'll resolve the report as duplicate afterward.
- 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.
- Set Product to Wine and specify Wine version you are using, if in doubt run `wine --version`. If you are using wine-staging, mention this in the comments.
- 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). 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. Please do not paste 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`). If a file is large, compress it first (e.g. with gzip or xz). If you have many files to upload (i.e. more than two), please use an archive (e.g. tar) rather than uploading them all individually. 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 importance 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'ts
- ✔Specify your distribution and architecture.
- ✔Write your bug report in English. While many developers speak other languages, English is the language of choice for Wine.
- ✔Include a download link (if one is available) from the software's website.
- ✔Select appropriate keywords in your report (a list of accepted keywords is here).
- ✔Attach terminal output (instead of pasting it in a comment).
- ✔Attach small files that clarify the problem (e.g. a screenshot for visual bugs, a sample script for scripting engines)
- ✔If this is a regression (if it used to work, but doesn't any more), please mention the working/broken versions. If you can, running a regression test is very helpful.
- ✔Check on your bug every release or two and let us know if the bug is still present. If not, mark it fixed.
- ✔Attach the bug to the correct application in the AppDB.
- ✖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.
- ✖Attach large files such as executables unless they are explicitly requested (link to a legitimate download page instead)
- ✖Use pirated/cracked software.
- ✖Post links to file-sharing websites to download executables instead of the developer's site.
- ✖Ask when the bug will be fixed. If a fix is in progress, it'll likely be posted in the bug.
- ✖Close fixed bugs. We'll close it whenever the next release is made.
- ✖cc yourself to bugs you have reported (the system will notify you of updates regardless) or reply to email notifications of bug updates (add your comment using the webpage).
Some general policies for WineHQ's Bugzilla:
- Bug reporters are expected to check their bug on newer Wine versions periodically (3-6 months) and to update the bug if it's fixed or still present. If it's still present, simply a comment saying still in wine-x.y.z 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:
- the reporter did not provide enough information to act on (missing program name, no terminal output, etc.),
- 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.
- Please don't CC yourself on EVERY bug, this spams a lot of people. Users who do this are subject to a ban. If you want to watch all bugs, subscribe to wine-bugs at https://www.winehq.org/mailman/listinfo/wine-bugs
- All Wine developers are entitled to bugzilla triage permissions. If you don't have them, contact AustinEnglish or send an email to [email protected]