Wine Bugzilla

From Wine-Wiki.org
Jump to: navigation, search

Note: this is not official documentation but rather an edited compilation of links from the Mailing lists. For Official Documents see the links section.

Contents

Bugzilla reporting

a user queried the wine-devel list: First I'd like to find out if this is the right place [to raise a bug], or if I should "bury" it into bugzilla. [In Winehq Bugzilla entry 18960 Vitamin instructed Do not submit bugs for illegal software]

D. Kegel [Oct 2006]: It's fine to bring it up here, but you should definitely create a bug report in bugzilla, including a small test program that reproduces the problem, with source if possible. (That doesn't bury it; rather, it exposes it to the blinding light of our crack debugging team :-) wine archive

Anon [Nov 06]: Lately it appears recommended to create a bug report rather than bring it up in the developer list. However you might want to post to the list if you are working on the bug and need information.

bugzilla requires a username and an email address.

D. Kegel [Oct 07 wine devel] queried about protecting these addresses as they are shown in bugzilla: Should we modify our Bugzilla to hide email addresses at least a little?

J. Zerebecki: Afaik this is not really possible with bugzilla as account names are the email address, so hiding them would remove quite some usability. Users that don't want to provide a email address can still use the bugmenot.com login to your bugzilla. But users better should have a distinguishable account. [...] someone who wants to actively participate in our project already reveals his email address on the mailinglists and in the git changelog. In the end there are various other ways to not reveal ones real or main email address that are not specific to this case.

anon: you might consider creating a free email address especially for your bugzilla account.

The Bugzilla Flow

The flow of using Bugzilla is shown in this Bugzilla entry:

A user identified a bug, detailed how to reproduce it and provided a screenshot. Another user identified the patch that caused the bug using regression testing. With the benefit of the analysis and detailed report, a patch was provided and accepted for the version of wine being developed in CVS. T. Lambregts: When the fix is in CVS then it should be marked RESOLVED [..] The next step is for the person who posted the bug to mark it as VERIFIED when the next release is out (or when he has updated to the latest cvs) So far waiting for people to verify bugs before marking CLOSED is almost impossible since so few people actually mark their bugs as verified. Please mark this as VERIFIED or reopen it as appropriate.

J. Hawkins July 08 noted in bug126124 Don't close fixed bugs. [each release] Julliard closes fixed bugs.

Developers may want to know is if this occurs in a clean wine. This means they need to know is this the fault of wine or has something you installed upset your wine. Something to test this without loosing all your settings is wineprefixcreate

Your bug in Bugzilla Helps Wine

Adding your bug to the Wine Bugzilla does help wine. Developers do use bugzilla to squash bugs in Wine. But before adding a bug, consider how you can assist a busy developer who reviews your bug...

T. Lambreghts [May 2007 wine devel]: there are lots of unresolved bug reports to keep developers busy on if they are looking for something to do.

K. Blin: Granted. I've been doing that when I had some spare time. Working on winsock bugs, I can tell that about one in ten bug reports is detailed enough (after requesting more information) to actually nail down a bug.

Providing the right information for your Bugzilla Entry

First, you need to check that it is a wine bug, as a number of bugs are fixed by starting with a clean wine prefix (these problems can arise when wine is not updated properly - which will continue to improve as more time goes by). see WINEPREFIX for a way to create a temporary wine folder.

J. Hawkins [Oct 07 bug 8033] To file a bug report, you have to be able to provide step-by-step instructions to reproduce the bug. That starts with a clean wineprefix: [temporarily save your current wine folder with all its installed software and settings, test using a new clean wine setup and file your bug. Afterwards, you can revert to your old setup by the command mv .wine-save .wine]

$ mv .wine .wine-save
$ wineprefixcreate
$ wine setup.exe
$ cd [dir containing exe]
$ wine app.exe
[crashes, bad behavior, etc]


A recent requirement was mentioned May 2009 in Winehq Bugzilla entry 18436 We welcome you to report bugs, but if a regression occurs (i.e. something was working but with a wine update it has been broken) it usually needs a person with a copy of the software to find out which patch stopped it from working. This has become a firmer rule with the number of bug reports of late: Winehq Bugzilla entry 18608 Bugzilla does state that a regression test should be completed BEFORE submitting a bug.

If you need assistance with the regression testing feel free to join the irc channel #winehq on irc.freenode.net or visit the forum at http://forum.winehq.org - If you follow the instructions, it's quite straight forward and shouldn't take much more than an hour or so.


[Ed there are some offering regression testing for users for an hourly fee if it is too scary for you to do. However dont be put off trying it. It is not that hard and with the help available, you can do it. On a computer older than a few years it may take a while and if you decide paying someone to do it for you is a better use of your time, that is available.]


What can really help a developer is a simple description on how to see the bug and if you can, add some further details. This might be

J. Hawkins [Oct 07 winedevel]: it's the responsibility of bugzilla maintainers/triagers to set and fix components if the user doesn't know (which most don't). [he suggested using wine-misc if you dont know which one to use]

Regression Tests

When something breaks, a regression test can identify the developer who broke it, and they can fix it. Wine developers now ask for a regression test if you report a breakage in wine. This is not too hard, so dont worry, it will only take some time. It is much better to use our time to regression test than take the valuable time from a developer who would rather be writing fixes.

Winehq Bugzilla entry 19293 notes: include the result of the regression test in your bug report instead of attaching it, this lets other people search for the commit. No need to cc yourself, you are copied on all changes because you are the reporter.


if everyone had their e-mails in bugzilla so they can be cc'ed. If you're already on wine-bugs, then set your e-mail settings to not e-mail you on cc.

Further Reading


Debugging Traces

When asked to provide a debug trace, be responsive and provide this as soon as possible. Compress the file and attach it to the bug report.

If you do not know what traces to supply, the bugzilla team will tell you what is needed. Recently (jul 09) developers have repeatedly requested uses to not provide a +all trace.

Winehq Bugzilla entry 18040 did some testing and wrote april 09: I recommend lzma for compressing debug logs.

Computer System Information

Winehq Bugzilla entry 19341 It would help a lot if you would attach glxinfo output instead of pasting it [..].

Using Winetricks when filing bugs

{{winebug|18070} when to use winetricks and when to submit a bug?

A. English Jul 09: Winetricks is used to workaround wine (e.g., msxml3/pdh) or application (not bundling visual basic/c runtimes) bugs. If you use winetricks to workaround a bug, be sure to mention it in the bug report (with a link to the bug you worked around).

Updating Your Bug Entry

Winehq Bugzilla entry 14717 [Sept 09] We ask if bugs are still present if they haven't seen activity for a relatively long time, since they might have been either fixed or abandoned in that time. Due to the amount of bugs it's not practical to verify this ourselves for every bug. In that regard you should consider it more or less as an automated reply.


J. Hawkins [Wine bug 8033 Oct 07] The [...] issue is that there are finitely many variables that affect a bug, and the more variables we can eliminate as a cause of the bug, the easier it is to find the actual bug. 95% of the time, a bug has nothing to do with having a dirty .wine, but there is that 5% where this is a problem, and we ask users to remove their wineprefix to remove this variable so the debugging process is easier. At this point in the development process, there are very few changes to the code base that require a new wine prefix. [...] A part of helping with the development process is running apps in a clean .wine environment so that no external factors affect the bug.

[...] you need to read the Wine User Guide to [.. understand] how Wine works, especially regarding wine prefixes. http://winehq.org/site/docs/wineusr-guide/index

[...]. [To get a clean .wine] all you have to do is

$ mv .wine .wine-save
$ wineprefixcreate

[...] Of course your gecko and configuration settings [won't] show up when you [move away your .wine and call] wineprefixcreate. All you have to do to get them [and your old wine settings] back is

$ mv .wine-save .wine

Storing Bug Patches yet to be accepted

A user asked: Is there someway of storing a patch on the winehq/appdb domain so that I can put a link on the APPDB page to it, rather than use links to other places [...] as we store screenshots it would be nice to store patches approved by the maintainers (prior to be incorporated into the code, or the code fixed).

T. Lambreghts: There are a number of places that patches can be stored within winehq. The first place that you could store them is in the wiki like http://wiki.winehq.org/InterestingPatches, or if they fix/hack around a bug in the application then you can start a bug report and attach the patch there and link back to it. Finally you can submit a patch to [email protected] and link to the archive.

http://www.winehq.org/pipermail/wine-patches/ ie: http://www.winehq.org/pipermail/wine-patches/2006-August/029455.html I do not know what the best way is but I tend to favor the wiki. wine archive


Marking Fixed after a release

Feb 08 D. Kegel wine devel:When we do a release, all the bugs in RESOLVED FIXED state can be closed (since they were only waiting on a release to be closed). [..] J. McKenzie: anyone should be able to close invalid, duplicate or otherwise erroneous bug reports. Only AJ should be closing fixed bug reports. [However] It should be permissible to mark a Fixed bug as Resolved.


H. Verbeet: You mark the bug as fixed once the patch is in git. The bug will be closed once a version of Wine with the patch in it is released.


Bugzilla upgrade
J. Newman:[Apr 06] We will be upgrading to the latest bugzilla down the road. I don't have an ETA of when it will happen, but rest assured it is in the works. Otherwise if you want things changed in bugzilla, email [email protected] I do not touch bugzilla myself anymore. I leave that to the volunteers at bugs-admin. wine archive

T. Lambregts who has consistantly worked long and hard on the bugzilla and the appdb cautiously reported [May 06]: I am still working on the upgrade to 2.20 for bugzilla and I think I am close to having it finished wine archive

Update. Bugzilla has apparently been updated.

My Linux Distribution Bug Reporting Tool noticed a crash

A user queried about Ubuntu: where should the bugs be filed - wine's bugzilla, or launchpad?]

D. Kegel [May 2007 winedevel]: The bugs should definitely go to launchpad, because each distribution has a different set of packages and bugs, each distribution's crash logger should go to its own bug tracker. winehq's bugzilla should be treated as an upstream bug tracker, and only manually triaged and distilled versions of the automated bug reports should go upstream.

Reactos which uses Wine Dlls has a Bug

Because Reactos uses Wine dlls, (which the license of Wine permits) You will need to confirm if the bug is in Wine. The best way to do this is install wine and see if the bug exists there. Perhaps Winehq Bugzilla entry 19336 is an example of why the developers want you to check before reporting a bug with Wine . It is about missing text in Reactos which at first might appear to be a problem in wine, but this does not occur with a plain Wine install. In other words, it appears to be a bug (hopefully squashed by now) in Reactos.

Patches found in Bugzilla

9Sept 08 Vitamin: Most patches in bugzilla are hacks or workarounds. They help one program, and possibly break all other programs.

Sept 8 08 Gert: Once you know that your system is set up correctly to compile Wine, start looking at patches...


jaypee wrote: [How] I can uninstall patches?

Vitaimin: You patch the source which you can always reset back to it's original state. Also you can revert patches with 'patch -R'.

jaypee wrote: In bugzilla, some patchs have a strikethrough(from google tradutor),> what the strikethrough means?

Vitamin: That there is a newer patch. Or the patch was deemed invalid.


Further Reading

Assigning bugs

One user complained [Ma r09] Usability is obviously not important to the wine developers because this [bug] has never been allocated to anybody.

Adys replied: You shouldn't make assumptions based on things like that. For what it's worth, I rarely even see any bug being assigned to somebody -- and even if they are, they usually get fixed by someone else. Yet, a lot of them are getting fixed.

Bumping bugs

A user asked: Any chance it will get bumped up?

Jeff: There is no bumping up... out of the odd 4000 bugs on bugzilla, people give attention to whichever bugs they think they can fix, some are just easier than others.

Avoiding Irritating the Developers

Remember that developers are very busy. They are working very hard for paying customers to get software working on Wine. If you want them to help you for free, make it easy for them by being responsive and providing exactly what they ask for. Oh, and avoid demanding action. Even if they were inclined to help you, they might quickly lose interest.

In one bug [jan 09] One person posted: Strange, this bug has a lot of votes, but isn't fixed yet!? I also want to have this game running with Wine, please do something...

J. Zoroyko pointed out how this was not helping developers: With comments like that people are less likely to look. Unless you have information on how to fix the bug or have been asked a question, there is no need to post. If you want to direct resources then you should consider paying someone to fix this bug under contract, eg CodeWeavers offer commercial support.

As one user posted: everyone posting in here needs to respect the hard (and voluntary!) work the developers are doing by not filling this thread with any more chatter.

D. Timoshkov Winehq Bugzilla entry 6971 http://wiki.winehq.org/Bugs: Don't ask when the bug will be fixed. If a fix is in progress, it'll likely be posted in the bug.

Wine is an open source and volunteer driven project, feel free to work on this bug on your own, hire or sponsor someone else to do the job for you.


Dan Kegel pointed to one way you can help your software get working: Even if we did mark this bug as targeted at release 1.2, that's no assurance that it would be fixed for that release. Has [a] test case been committed?

Further Reading

Attempting a Test Case - Test Cases are Welcomed

One person wrote to the wine devel list: I have attached to http://bugs.winehq.org/show_bug.cgi?id=15915#c3 ("Cinepak reportedly not installed") the skeleton of a test that wine fails but win2k passes.

M. Karcher: Nice work, thank you. Tests like this do help Wine development.

They asked Is it "right" to add compatibility tests that wine is known to fail now (people are already complaining that a wine build does not pass all tests), or are the tests considered more like regression aids and should be added only when they succeed for the first time?

M. Karcher: It is definitely right to add such a test. But you have to mark it todo_wine. In that case, "make test" will expect that the test fails and complain if it does *not* fail.

The user asked: What directory to add this test specific to vfw32 (or rather iccvid) ? winmm seems to test sound only, although in principle, it could be there as well. [This is a good idea - if you dont know where to put it, ask]

He was told: I would put it into msvfw32/tests. You would have to create it.

He asked: Which files to change (beside Makefile.in and testlist.c) so that the patch builds and becomes fully integrated into the wine source tree if it were located in a new file, instead of e.g. being added to tests/mmio.c?

M. Karcher: Just change Makefile.in, testlist.c is automatically generated. If you add a new tests dir, you need to run tools/make_makefiles in the top level directory of your wine sourcecode. If your wine sourcecode is a git repository, make_makefiles only considers Makefile.in files already added to the git index, so call git-add before make_makefiles. If you don't use git, make_makefiles scans all directories for Makefile.in to find about buildable directories.

Bugzilla Terms and Keywords

Around May2008 a number of bugs contained the keyword [Dogfood]. D. Kegel explained [wine user may 2008]: live in Wine, and report the bugs that this reveals. In other words, when doing dogfood testing, you don't have to go testing random apps; just go about your normal daily duties -- using only Windows apps running on Wine. A bug that keeps you from carrying out your normal duties / activities is a dogfood bug.

April 08 bug notes: A number of bugs contain comments that effectively say: Don't set the bug rating. After the developers have had a look at your bug, they will set it for you.


Dont use the bugzilla label REMIND or LATER. D. Timoshkov bug 14413: LATER and REMIND are considered as not appropriate resolutions in WineHQ bugzilla, they are meaningless. A. English Jan 09 wine devel:We've already went through and removed all of them from bug entries in bugzilla, so can an admin please remove these resolutions? A. English also posted: CVS/GIT versions have been moved. Whoever's got bugzilla admin privileges, please delete that version. April 2010 he posted that he removed keywords bugbuster, noappdbentry, tasklet, and tasklist from all bugs.[and requested] Could someone with the appropriate bugzilla permissions please delete the keywords themselves?

Blocker

D. Jovanovic [Aug 07 winebug 9356]: bugs with blocker rating don't get fixed any sooner than the others . Rather vote for the bug?

Invalid

[We dont] usually [leave invalid bugs open], but if a bug is bound to have a bunch of duplicates filed, we often do, until a fix is released. For example, this was done for the Nvidia Legacy driver text shearing bug. According to Winehq Bugzilla entry 21104 [while] Alexandre closes [bugs] before a new release. Invalid bugs can be closed by anyone.

Operating System and Processor

D. Kegel winedevel Jan 09: Does "mac" mean "powerpc mac only"? A. English: [...] for all intents and purposes, Intel Macs are PC's (especially if running Linux rather than OS X). Those running OS X still can be identified as such by the OS field. Yes, my goal was to separate x86/ppc bugs. Another posted: we should change the tab to read ppc rather than mac.

Patch

Jan 08 wine devel Vitamin: Patch keyword is for patches attached to bugs only and not sent to wine-patches.

Another felt: It's still useful, e.g., if patch is not accepted.

Vitamin: No it's not. The intension of that keyword was to fish all the patches out of buzilla and resubmit them to wine-patches. Or serve as a base for someone to improve upon. With mixing the two you make it nearly useless as most bugs will have it eventually. Especially all fixed ones.

A. English: Keep in mind, however, that I doubt anyone is searching fixed bugs for patches. [No decision appears to have been made, and check bugzilla for the decision]

Upstream

Winehq Bugzilla entry 26630 As a user, [it's bad] being told "your bug is invalid" when it, in fact, is not. Especially when it's serious stuff eg Xorg crashes, black screens, or even reboots.

Upstream at least means "We're taking care of it" somehow. [...] I propose RESOLVED UPSTREAM once the bug is filed, and CLOSED UPSTREAM once it's closed upstream for whatever reason. [A. Julliard agreed with this proposal]

download

F. Gouget:[sept 06] If the bug cannot be reproduced in the trial version, then it should not have the 'download' keyword since it cannot be reproduced simply by downloading the software. Same thing if the full version is downloadable but requires a paying subscription of some sort in order to reproduce the bug. The 'download' keyword really stands for 'the free download will let you reproduce the bug'. [Ed. If at all possible, provide a download link to a free version that shows the bug. If someone is curious and can download it - it is much easier to fix it.]

Winehq Bugzilla entry 15749 Jul 09: in general bugs with 'download' keyword can't be resolved as abandoned.

Bug Duplications

T. Spear suggested having an official wiki page for common bugs [Mar 06]: once I notice something is being reported rather frequently. I assume that these people who are reporting identical duplicates read some of the dodcumentation though, because otherwise they probably wouldn't have even known about winecfg. [...] I'll do something like Bug (x) - (Description) - Status: Resolved - Resolved as of wine v(x) wine archive

T. Lambregts: One Major advantage is that even if people keep on reporting duplicates then it will make it easier for those people doing QA in Bugzilla. If they have a place to go when they think a bug is a duplicate instead of having to search for or remember the bug numbers. Keeping them around for a while even after they are fixed would be a good idea since not everyone keeps up with the latest version of wine. Common bugs

http://bugs.winehq.org/show_bug.cgi?id=219 (SafeDisk)
http://bugs.winehq.org/show_bug.cgi?id=1631 (dsound: problem with underrun detection)
http://bugs.winehq.org/show_bug.cgi?id=1410 (mouse always recenterd)

D. Riekenberg: Just found, that gcc has "Most frequently reported Bugs": http://gcc.gnu.org/bugzilla/duplicates.cgi And since we have also bugzilla, i tested http://bugs.winehq.org/duplicates.cgi The Page is present, but not configured to be useful for wine. The code is in the cvs.

What about votes

One a duplication has been identified it is marked as a duplication (a dup). Winehq Bugzilla entry 18228 advised in May 09: I will mark this as a duplicate and link 18070 to Photoshop if it isn't done already. Please vote there instead, those of you who voted here.

It appears you will need to manually add your votes to the new bug.

When the same Bug affects different software

A. Julliard: if it's the same bug it should be a single report. If .NET doesn't install then obviously all apps that try to install it will be broken, it doesn't make sense to create a separate bug for each app that suffers from the problem.

P. Vriens: Only a comment will not increase the 'popularity' of a bug though. How do we determine the priority of such a bug? (Or don't we deal with priorities anyway?).

A. Julliard: We don't really, and a separate bug which will be closed as duplicate wouldn't help anyway. If there is evidence that it affects a lot of apps you can make the severity major.

A. English: Have them cc themselves to the original bug, and when its fixed, retest. No need to file a bug only to close it immediately as a duplicate. If, however, you're able to workaround that bug, then make a new bug, and have the second depend on the first. E.g., program foo needs native gdiplus and native richedit to install. File bug for gdiplus problem, then file a second one for richedit, marking it as depending on the gdiplus bug.

Difficulty

D. Timoshkov [Sept 07 bug 9037]: There is no point in changing Difficulty field unless you are working on this bug and know exactly how much time it will take.


MetaBugs

A develoepr queried [May 2007 wine devel]: is it against the rules in bugzilla to try to organize the bugs some way? He then referred to an old games metabug ( 1434)

V. Margolen: Bad idea. Metabugs are hard to follow and hard to use. Especially if _every game in the whole wide world_ will make it into your metabug. In turn _any_ change to _any_ of the bugs will create a huge number of e-mails sent. Sume people either subscribed to wine-bugs or watch ML archive.

The developer explained: Basically my idea was to make several tasklists to link to 1434 (bugs like dinput9, d3d8, etc), and then link individual games to each of those, so that someone working on games, and in specific on dinput9 for example could easily find bugs related to dinput 9 without having to do a query.

V. Margolen: As I explained above - using generic metabugs is bad. We have components that do exactly that. Also we have keywords that cover things from the different perspective. Those two are enough to do what you want to do.

J. Zerebecki:Bugzilla queries are just a URL and it remains valid. So there is not much advantage to having a bug, right? But using components and keywords (in newer bugzillas there are even more ways to classify bugs) has the advantage that a change only triggers one change-mail. If the current components are not fain grained enough, we can always add more (and change the current ones). BTW. I think the current component descriptions need to be enhanced, we should at least assign each .dll to one component (would make it much more obvious what should go where).

The components could use a major revamping and should be fairly trivial. However I think that one component for each dll might be a bit much.. Maybe narrow the dll's down to categories such as wine-common-controls, and wine-riched..

J. Hawkins: we had vague components before, and they're not useful. We need a component per dll. I don't think we should add them all right now, but when we have a bug report for a bug in a particular dll that isn't a component yet, the component should be added (by request).


J. Hawkins [Oct 07 wine devel] metabugs are a bad idea. With very few exceptions, Wine's bugzilla bug reports should be about apps only. If any apps fail because of the exact same cause (bug), then the appropriate bugs need to be marked as duplicates of the original bug report. Topics like "Wine should report 32bit color depth instead of 24bit" and "GetDeviceCaps: BITSPIXEL returning 15 on 15bit graphics" are development planning information, and as such this information belongs in the wiki.


Wine Version 1 and later

Bug78 [Oct 07] was closed with a Comment #7 from Dan Kegel 2007-10-06 04:17:34 We're switching to target milestone rather than metabugs for 1.0. Bug75 noted the reason: As discussed at wineconf.

D. Kegel: [wine devel via wine conf 07] We're sorting through bugzilla fixing the target milestones for important bugs, and it would be useful to have a 1.1 milestone (to go along with the existing 0.9 and 1.0 milestones).

J. Newman: No problem, it is done.

Components

A. English bug 16809 Jan 09:[There is no gecko component] any wine-gecko related bug should be marked as a bug of mshtml. D. Timoshkov: The reason of the bug and component should be figured out first, there are several components responsible for url/html rendering.

Bugzilla Rights and Administration

A developer asked: I'm not really sure what levels of permissions Bugzilla has, but could I get the ability to modify bugs? (things like assign them to myself, mark them as fixed, etc). If it's possibile, I suppose only having such access to the "wine-richedit" component would be fine[...]

T. Lambregts: Bugzilla is not that fine grained to allow that. Since you are a developer I have given you rights to confirm and edit bugs. If there are there any other developers that do not have these abilities and want them, Please let me know.wine archive


Winehq Bugzilla entry 18313 Noted that Wine have Upgraded to 3.2.3.

Bugzilla Troubleshooting

Bugzilla Offline

Occasionally Bugzilla goes offline though thanks to J. Newman this is not too often. He Posted [Jan 08] about a recent outage: I made some tweaks to the mysql config. Hopefully it this will happen less often to hopefully not at all now.

Re assigning bugs

A programmer noted [May 06]: When I created [the bug report] I left it to be assigned to the default of friendly Mr. Bugs. Since I am looking into it I would like to get it assigned to me. When I try to reassign it to me I get an error saying that only the owner, submitter or a "sufficiently empowered user". I am not the owner or a empowered user but I am the submitter.

T. Rollo: The easiest way is usually to ask on the #winehackers IRC channel on freenode, however based on the commentary attached to the bug at <http://bugs.winehq.org/show_bug.cgi?id=5285> it may be that nothing needs to be changed. You may get better results by asking about it on this list rather than in bugzilla. wine archive

V. Margolen [Bug 7055 Aug 07]: Make sure you add wine-bugs to CC whenever you reassign the bug

Bugzilla and wine-bugs

A programmer noticed:[May 06] I just have submited an additional attachment on my report page [*]. After this bugzilla said to me:

Changes Submitted
--
Attachment #2466 to Bug #2082 Created Email sent to:
[email addresses redacted]

Well, I don't understand, why this hasn't been sent to [email protected] Did that happen by a design?

D.Clark: New bugs are assigned by default to wine-bugs <AT> winehq.org, and so any additional postings get sent there. When a bug is reassigned to someone else, it is necessary to move the wine-bugs <AT> winehq.org to the CC list in order for the postings to continue to be sent out (at least that is the way it used to be, and apparently it has not changed). In the past, several moderators have attempted to catch these changes. But inevitably some will get missed.

I suppose this could be fixed by "subscribing" wine-bugs <AT> winehq.org. Would someone like to give that a try? wine archive Note: Email address has been munged slightly.

Mailing List Comments affecting Bugzilla

Administrator Rights

Unwanted Mail

A user wrote [Jun 07 wine devel]: I've been annoyed by how it sends out emails whenever someone subscribes/unsubscribes from a bug. Is this a simple configuration setting, or do we need to upgrade?

M. Meissner: This is a simple configuration setting of YOUR account. Go to:

My Prefs -> Tab Email Setting -> and click off the "CC field changes" checkbox. (and others if you dont need them)


Another user asked about mail sent by bugzilla:[What does it mean?] I just got two similar mails from bugzilla:

http://bugs.winehq.org/show_bug.cgi?id=14478
[email redacted] changed:
What |Removed |Added
----------------------------------------------------------------------------
Platform|Other |All


J. Drescher: Other users have added themselves to the watch list for this bug.

Disappearing Show List Option

One of the bug triage team explained [Wine devel Mar 07]: On the left there is a link to list just bugs with status: new, so I click that. Then I see a bug I would like to check out so I click on that bug. I add comments and hit submit. The next page that comes up gives me the option to return to the bug, but I would rather go back to the list. As it stands now I have to hit the back button 2 times to get back to the list (unrefreshed mind you, which is how I want it as I dont want to have to re-download the entire list every time I view it). At the bottom there are links for Query page and Enter a new bug.

J. Hawkins: The problem is that the list you are browsing is too long. Bugzilla gives the message, "This list is too long for Bugzilla's little mind; the Next/Prev/First/Last buttons won't appear on individual bugs." If the list is not too long, you would just hit the "Show list" link to get back to the list.

Bugzilla Staff Reviews

A question was asked [Aug 07] Is there a formal process for reviewing an arguably incompetent bugzilla staffer? Obviously it wouldn't be to submit their name as a bug. But is there any defined administrative layer that concerns itself with people on that level who are dragging on the project?

J. Hawkins: This is an open community. If you have a problem with someone or some process, let it be known. There is no formal process except for communication on wine-devel.

Obtaining a backtrace

Sometimes you are asked for a backtrace.Vitamin wineuser may 2008: Usually when something crashes Wine attaches it's own debugger and generating a backtrace of the crash [in the terminal window]. In some cases, programs might intercept this and create their own "bug report", "crash dump" or just "memory dump". If you don't get a backtrace from Wine, then try to find that other report and attach it. Or if it's a memory dump - load it with winedbg and do 'bt all'. Then attach the output.


Using Winedebug

A. English explained how to use winedebug to get a backtrace May 08 wine user:

Open two terminals: 

$ wine your_app.exe (#crash, but no backtrace)

$ winedbg
> bt all

Copy and paste into text file, and attach to bug.


After recieving advice to help with debugging a fault by typing backtrace (bt) a user posted May 06: 

$ winedbg FileMaker\ Pro.exe
WineDbg starting on pid 0xa
0x7fcbd019: subl        $12,%esp
Wine-dbg>bt

D. Skorka: Thats too early. If you start a process with winedbg, it will immediatly drop to the prompt. You have to type 'cont' and hit enter. Then, when the program crashes and you get back to the prompt, you have to type 'bt' wine archive

Updating Bugzilla

J. Newman [Wine Bugs 3431 Aug 07] mentioned that wine had upgraded to Bugzilla 3.0, Later he said under [Bug 9110] replace generic bug severity descriptions with wine specific ones: This is just a matter of updating that template. I can do this once the process of moving over from CVS to Git is complete.

J. Zerebecki [Jun 07] with the upgrade of Bugzilla we will use Git for what the "bugzilla" cvs module is currently used (if nothing unforeseen prevents this). This can be seen as a test for also moving our other remaining CVS modules. Anyone who has a problem with this should speak up now. Btw. the idea is to upgrade the server to "Etch" shortly before the Bugzilla upgrade.

T. Spear [Oct 06]: With a proper backup (or test) server in place, and given the proper privileges, I'd be happy to upgrade the installed version, however it may take a little bit of time to do because of time constraints.

J. Newman: See this bug:

and this patch:

If someone wants to continue this work they need to successfully upgrade our CVS version on a test box first. I can make a complete dump of our DB for them to test upgrading. Once they have proved it works, and submits a clean patch for our CVS that I can test on my development box, then I will do the upgrade. Note: this needs to be done by me via a "CVS update" and without needing root access to our box. I realize that the bugzilla configure script will need to be run to upgrade the tables, so that script will need to be modfied to not attempt changing permissions on the files. Either that or someone can send me a .sql that will ALTER the tables correctly.

This is a big messy job, our Bugzilla is very old and it's tables have been corrupted by the bugzilla upgrade before. wine archive

Links

Official Bugzilla Links

Other Links

When filling out a bug in bugzilla, some of the developers prefer debug traces to be posted as an attachment. This makes it easier for bug chasers to review the bug posts. wine archive

Further Reading

Retrieved from "http://wine-wiki.org/index.php/Wine_Bugzilla"
Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox