I'm not trying to be a whiner here, but I think enough is enough when it comes to having to close bugs as a duplicate. There has to be some simple solution to cut down on the number of new bugs filed that report that winecfg crashes when clicking on the audio tab. I know that the subject above isn't it, but it is at least a start. I was about to create it myself, but my better judgement said I should ask here first.
Can someone please(!) put something on some page that almost everyone sees saying that if you are having a problem with winecfg crashing when clicking on the audio tab to check out bug 4051 first? Please!
Thanks
Tom
On Mon, 2006-03-20 at 22:28 -0600, Tom Spear (Dustin Booker, Dustin Navea) wrote:
clicking on the audio tab to check out bug 4051 first? Please!
How about we fix the problem instead? :)
Dimi Paun wrote:
On Mon, 2006-03-20 at 22:28 -0600, Tom Spear (Dustin Booker, Dustin Navea) wrote:
clicking on the audio tab to check out bug 4051 first? Please!
How about we fix the problem instead? :)
The best way to fix it is probably to rearrange the code so that the Audio tab shows, then there's a [Detect] button that the user can click to run the autodetect code that might crash. At least then the user can set their Wine Audio settings manually.
Mike
On Tue, 2006-03-21 at 14:14 +0900, Mike McCormack wrote:
The best way to fix it is probably to rearrange the code so that the Audio tab shows, then there's a [Detect] button that the user can click to run the autodetect code that might crash. At least then the user can set their Wine Audio settings manually.
There is a patch in Bugzilla (posted Sun) that simply catches the exception and avoids the crash that way. I think it's probably good enough for the arts business, it's a dead-end anyway.
Dimi Paun wrote:
On Tue, 2006-03-21 at 14:14 +0900, Mike McCormack wrote:
The best way to fix it is probably to rearrange the code so that the Audio tab shows, then there's a [Detect] button that the user can click to run the autodetect code that might crash. At least then the user can set their Wine Audio settings manually.
There is a patch in Bugzilla (posted Sun) that simply catches the exception and avoids the crash that way. I think it's probably good enough for the arts business, it's a dead-end anyway.
aRts in and of itself is a b/uggy ha/ck, KDE is droipping it in the 4.0 release, Skype crashes if you use artsdsp with it and play sound, arts is also known to just segfault for no reason whatsoever. Best suggestion is to drop support for aRts entirely, it won't be around much longer.
Segin wrote:
aRts in and of itself is a b/uggy ha/ck, KDE is droipping it in the 4.0 release, Skype crashes if you use artsdsp with it and play sound, arts is also known to just segfault for no reason whatsoever. Best suggestion is to drop support for aRts entirely, it won't be around much longer.
aRts is not the only library giving trouble here. Here's one caused by ALSA:
http://bugs.winehq.org/show_bug.cgi?id=4901
Getting rid of aRts may cripple Wine on older systems, and it won't solve the problem. We can't rely on all 3rd party sound libs to be bug free, especially since there's a lot of dodgy homebrew systems out there built by people who *think* they know what they're doing...
Allowing users to use the Audio tab in WineCfg without forcing possibly buggy libraries to load is a better option.
Mike
On Tue, 2006-03-21 at 15:35 +0900, Mike McCormack wrote:
Allowing users to use the Audio tab in WineCfg without forcing possibly buggy libraries to load is a better option.
Sure, but they are not mutually exclusive. If the current patch also prevents the crash, they can go well hand in hand.
Dimi Paun wrote:
On Tue, 2006-03-21 at 15:35 +0900, Mike McCormack wrote:
Allowing users to use the Audio tab in WineCfg without forcing possibly buggy libraries to load is a better option.
Sure, but they are not mutually exclusive. If the current patch also prevents the crash, they can go well hand in hand.
Looks to me like the patch in bug #4051 only catches aRts exceptions. Bug 4901 looks like it's caused by libasound problems.
Exception handlers can't catch system hangs, which I've seen when some audio drivers are loaded, they can't clean up properly after the buggy library, and the library might leave the stack or heap corrupted.
Moving the autodetect feature to a button in the Audio tab seems like a simple design change that will solve the problem once and for all. It allows configuration to be done manually, even if buggy libraries are present, which the current implementation doesn't.
Mike
Mike McCormack wrote:
Segin wrote:
aRts in and of itself is a b/uggy ha/ck, KDE is droipping it in the 4.0 release, Skype crashes if you use artsdsp with it and play sound, arts is also known to just segfault for no reason whatsoever. Best suggestion is to drop support for aRts entirely, it won't be around much longer.
aRts is not the only library giving trouble here. Here's one caused by ALSA:
http://bugs.winehq.org/show_bug.cgi?id=4901
Getting rid of aRts may cripple Wine on older systems, and it won't solve the problem. We can't rely on all 3rd party sound libs to be bug free, especially since there's a lot of dodgy homebrew systems out there built by people who *think* they know what they're doing...
Allowing users to use the Audio tab in WineCfg without forcing possibly buggy libraries to load is a better option.
Mike
Well, can we at least put in warnings when aRts support is enabled in winecfg (e.g. a popup that states that arts itself is buggy and it's use is not recomended?)
Well, if we can't take support out, that there is a hell of a lot better than doing absoutly nothing. at least people get a warning when they do stupid stuff.
aRts in and of itself is a buggy hack, KDE is droipping it in the 4.0 release, Skype crashes if you use artsdsp with it and play sound, arts is also known to just segfault for no reason whatsoever. Best suggestion is to drop support for aRts entirely, it won't be around much longer.
Arts has been unmaintained for many years now. As the original author I was on the mailing list for a number of years and support was bad even when the arts plugin was originally written. The website documentation was out of date, it was difficult to find the latest version of the code.
If there is something we can do to get arts working now that would be great since many people still use it and will continue to do so for some years. I'm certainly looking forward to when it is end-of-lifed with kde 4.0.
Chris
On 3/20/06, Mike McCormack mike@codeweavers.com wrote:
Dimi Paun wrote:
On Mon, 2006-03-20 at 22:28 -0600, Tom Spear (Dustin Booker, Dustin Navea) wrote:
clicking on the audio tab to check out bug 4051 first? Please!
How about we fix the problem instead? :)
The best way to fix it is probably to rearrange the code so that the Audio tab shows, then there's a [Detect] button that the user can click to run the autodetect code that might crash. At least then the user can set their Wine Audio settings manually.
Mike
This is not enough, as when I click the audio tab, it will lock up in the kernel. I already identified where it happens and patch the kernel myself. I told the ALSA devs, but they haven't looked at why certain register usage causes a lockup. So it remains in the stable kernel who knows who else hits it.
Jesse
Jesse Allen wrote:
On 3/20/06, Mike McCormack mike@codeweavers.com wrote:
Dimi Paun wrote:
On Mon, 2006-03-20 at 22:28 -0600, Tom Spear (Dustin Booker, Dustin Navea) wrote:
clicking on the audio tab to check out bug 4051 first? Please!
How about we fix the problem instead? :)
The best way to fix it is probably to rearrange the code so that the Audio tab shows, then there's a [Detect] button that the user can click to run the autodetect code that might crash. At least then the user can set their Wine Audio settings manually.
Mike
This is not enough, as when I click the audio tab, it will lock up in the kernel. I already identified where it happens and patch the kernel myself. I told the ALSA devs, but they haven't looked at why certain register usage causes a lockup. So it remains in the stable kernel who knows who else hits it.
Jesse
Which is why I agree with the ideas from Mike and Dimi AND Segin.. Why not put an autodetect button, have the exception handler catch the crash if arts decides to die, and then still have a popup dialog for when arts is manually selected that tells users it is buggy and not recommended to use? That doesn't fix your specific problem Jesse, I know, but at least it keeps winecfg open when you click on the audio tab.
Tom
Tom Spear (Dustin Booker, Dustin Navea) wrote:
Jesse Allen wrote:
On 3/20/06, Mike McCormack mike@codeweavers.com wrote:
Dimi Paun wrote:
On Mon, 2006-03-20 at 22:28 -0600, Tom Spear (Dustin Booker, Dustin Navea) wrote:
clicking on the audio tab to check out bug 4051 first? Please!
How about we fix the problem instead? :)
The best way to fix it is probably to rearrange the code so that the Audio tab shows, then there's a [Detect] button that the user can click to run the autodetect code that might crash. At least then the user can set their Wine Audio settings manually.
Mike
This is not enough, as when I click the audio tab, it will lock up in the kernel. I already identified where it happens and patch the kernel myself. I told the ALSA devs, but they haven't looked at why certain register usage causes a lockup. So it remains in the stable kernel who knows who else hits it.
Jesse
Which is why I agree with the ideas from Mike and Dimi AND Segin.. Why not put an autodetect button, have the exception handler catch the crash if arts decides to die, and then still have a popup dialog for when arts is manually selected that tells users it is buggy and not recommended to use? That doesn't fix your specific problem Jesse, I know, but at least it keeps winecfg open when you click on the audio tab.
Tom
The reason I added the probe of all drivers in winecfg was so that the broken and marginal drivers would get used and hopefully fixed. Moving the problem will just create different bugs: [BUG xxx] winecfg crashes when autodetect button pressed or [BUG yyy] winecfg crashes when driver xyz selected.
On 3/21/06, Robert Reif reif@earthlink.net wrote:
Tom Spear (Dustin Booker, Dustin Navea) wrote:
Jesse Allen wrote:
On 3/20/06, Mike McCormack mike@codeweavers.com wrote:
Dimi Paun wrote:
On Mon, 2006-03-20 at 22:28 -0600, Tom Spear (Dustin Booker, Dustin Navea) wrote:
clicking on the audio tab to check out bug 4051 first? Please!
How about we fix the problem instead? :)
The best way to fix it is probably to rearrange the code so that the Audio tab shows, then there's a [Detect] button that the user can
click
to run the autodetect code that might crash. At least then the user can set their Wine Audio settings manually.
Mike
This is not enough, as when I click the audio tab, it will lock up in the kernel. I already identified where it happens and patch the kernel myself. I told the ALSA devs, but they haven't looked at why certain register usage causes a lockup. So it remains in the stable kernel who knows who else hits it.
Jesse
Which is why I agree with the ideas from Mike and Dimi AND Segin.. Why not put an autodetect button, have the exception handler catch the crash if arts decides to die, and then still have a popup dialog for when arts is manually selected that tells users it is buggy and not recommended to use? That doesn't fix your specific problem Jesse, I know, but at least it keeps winecfg open when you click on the audio
tab.
Tom
The reason I added the probe of all drivers in winecfg was so that the broken and marginal drivers would get used and hopefully fixed. Moving the problem will just create different bugs: [BUG xxx] winecfg crashes when autodetect button pressed or [BUG yyy] winecfg crashes when driver xyz selected.
Yes, and I agree that that is a good idea, which is why I asked about putting a known issues page somewhere where a lot of users will see it. It wouldnt just have to be used for the issue mentioned above. It could be done for anything that is frequently reported. I'm going to go ahead and get started on putting it in tonight. Since it will be in the wiki, as the issues are fixed, they can be removed, and as other issues become more frequently reported, they can be added. I think it will be a good supplement to bugzilla and the appdb, as more people check out wiki's (as well as README's) than do the appdb, and so therefore they will see that the issue is already reported, and can find out what bug # it is instead of filing a duplicate bug. It also helps cut down on the number of bug submissions in the comments of the appdb..
Tom
Tuesday, March 21, 2006, 8:38:48 AM, Tom Spear wrote:
On 3/21/06, Robert Reif reif@earthlink.net wrote:Tom Spear (Dustin Booker, Dustin Navea) wrote:
Jesse Allen wrote:
On 3/20/06, Mike McCormack mike@codeweavers.com wrote:
Dimi Paun wrote:
On Mon, 2006-03-20 at 22:28 -0600, Tom Spear (Dustin Booker, Dustin Navea) wrote:
clicking on the audio tab to check out bug 4051 first? Please!
How about we fix the problem instead? :)
The best way to fix it is probably to rearrange the code so that the Audio tab shows, then there's a [Detect] button that the user can click to run the autodetect code that might crash. At least then the user can set their Wine Audio settings manually.
Mike
This is not enough, as when I click the audio tab, it will lock up in the kernel. I already identified where it happens and patch the kernel myself. I told the ALSA devs, but they haven't looked at why certain register usage causes a lockup. So it remains in the stable kernel who knows who else hits it.
Jesse
Which is why I agree with the ideas from Mike and Dimi AND Segin.. Why not put an autodetect button, have the exception handler catch the crash if arts decides to die, and then still have a popup dialog for when arts is manually selected that tells users it is buggy and not recommended to use? That doesn't fix your specific problem Jesse, I know, but at least it keeps winecfg open when you click on the audio tab.
Tom
The reason I added the probe of all drivers in winecfg was so that the broken and marginal drivers would get used and hopefully fixed. Moving the problem will just create different bugs: [BUG xxx] winecfg crashes when autodetect button pressed or [BUG yyy] winecfg crashes when driver xyz selected.
Yes, and I agree that that is a good idea, which is why I asked about putting a known issues page somewhere where a lot of users will see it. It wouldnt just have to be used for the issue mentioned above. It could be done for anything that is frequently reported. I'm going to go ahead and get started on putting it in tonight. Since it will be in the wiki, as the issues are fixed, they can be removed, and as other issues become more frequently reported, they can be added. I think it will be a good supplement to bugzilla and the appdb, as more people check out wiki's (as well as README's) than do the appdb, and so therefore they will see that the issue is already reported, and can find out what bug # it is instead of filing a duplicate bug. It also helps cut down on the number of bug submissions in the comments of the appdb..
I sure hope all users will go look at this page first. But some how I don't think they will. When we getting _exact_ duplicates with the same summary and almost identical comments. I don't think users will bother to look anywhere else.
But that will add extra work on our side to keep this list in synch. On top of the usual stuff that we already do.
Vitaliy.
On 3/21/06, Vitaliy Margolen wine-devel@kievinfo.com wrote:
Tuesday, March 21, 2006, 8:38:48 AM, Tom Spear wrote:
On 3/21/06, Robert Reif reif@earthlink.net wrote:Tom Spear (Dustin
Booker, Dustin Navea) wrote:
Jesse Allen wrote:
On 3/20/06, Mike McCormack mike@codeweavers.com wrote:
Dimi Paun wrote:
On Mon, 2006-03-20 at 22:28 -0600, Tom Spear (Dustin Booker, Dustin Navea) wrote:
> clicking on the audio tab to check out bug 4051 first? Please! >
How about we fix the problem instead? :)
The best way to fix it is probably to rearrange the code so that the Audio tab shows, then there's a [Detect] button that the user can
click
to run the autodetect code that might crash.At least then the user can set their Wine Audio settings manually.
Mike
This is not enough, as when I click the audio tab, it will lock up in the kernel.I already identified where it happens and patch the kernel myself.I told the ALSA devs, but they haven't looked at why certain register usage causes a lockup.So it remains in the stable kernel who knows who else hits it.
Jesse
Which is why I agree with the ideas from Mike and Dimi AND Segin.. Why not put an autodetect button, have the exception handler catch the crash if arts decides to die, and then still have a popup dialog for when arts is manually selected that tells users it is buggy and not recommended to use?That doesn't fix your specific problem Jesse, I know, but at least it keeps winecfg open when you click on the audio
tab.
Tom
The reason I added the probe of all drivers in winecfg was so that the broken and marginal drivers would get used and hopefully fixed.Moving the problem will just create different bugs: [BUG xxx] winecfg crashes when autodetect button pressed or [BUG yyy] winecfg crashes when driver xyz selected.
Yes, and I agree that that is a good idea, which is why I asked about putting a known issues page somewhere where a lot of users will see it. It wouldnt just have to be used for the issue mentioned above. It could be done for anything that is frequently reported. I'm going to go ahead and get started on putting it in tonight. Since it will be in the wiki, as the issues are fixed, they can be removed, and as other issues become more frequently reported, they can be added. I think it will be a good supplement to bugzilla and the appdb, as more people check out wiki's (as well as README's) than do the appdb, and so therefore they will see that the issue is already reported, and can find out what bug # it is instead of filing a duplicate bug. It also helps cut down on the number of bug submissions in the comments of the appdb..
I sure hope all users will go look at this page first. But some how I don't think they will. When we getting _exact_ duplicates with the same summary and almost identical comments. I don't think users will bother to look anywhere else.
But that will add extra work on our side to keep this list in synch. On top of the usual stuff that we already do.
Vitaliy.
It wouldnt take much extra time outta my day to do it. 5 mins at max and only 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.
Tom
Tom Spear wrote:
On 3/21/06, *Vitaliy Margolen* <wine-devel@kievinfo.com mailto:wine-devel@kievinfo.com> wrote:
I sure hope all users will go look at this page first. But some how I don't think they will. When we getting _exact_ duplicates with the same summary and almost identical comments. I don't think users will bother to look anywhere else. But that will add extra work on our side to keep this list in synch. On top of the usual stuff that we already do. Vitaliy.It wouldnt take much extra time outta my day to do it. 5 mins at max and only 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.
Tom
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[1].
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.
[1] 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)
--
Tony Lambregts
Tony Lambregts wrote:
Tom Spear wrote:
On 3/21/06, **Vitaliy Margolen** <wine-devel@kievinfo.com mailto:wine-devel@kievinfo.com> wrote:
[...]
[...]
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.
I have an idea, let's add a update check program to wine, so that when a person run it, they get to know what the latest version is, and their current version, plus make a standard executable of it for use on older versions.
Segin wrote:
Tony Lambregts wrote:
Tom Spear wrote:
On 3/21/06, **Vitaliy Margolen** <wine-devel@kievinfo.com mailto:wine-devel@kievinfo.com> wrote:
[...]
[...] 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.
I have an idea, let's add a update check program to wine, so that when a person run it, they get to know what the latest version is, and their current version, plus make a standard executable of it for use on older versions.
That is a good supplement, but we already have the wine-announce mailing list. I guess you are right though, not everyone subscribes to it that uses wine.
Tom
Tony Lambregts wrote:
Tom Spear wrote:
On 3/21/06, *Vitaliy Margolen* <wine-devel@kievinfo.com mailto:wine-devel@kievinfo.com> wrote:
I sure hope all users will go look at this page first. But some how I don't think they will. When we getting _exact_ duplicates with the
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.
[1] 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)
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, but I'm unable to help here (perl). (Browse the cvs: "http://cvs.winehq.org/cvsweb/bugzilla/")
Hello,
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, but I'm unable to help here (perl). (Browse the cvs: "http://cvs.winehq.org/cvsweb/bugzilla/")
Hmm, in principle one only needs to tweek at http://bugs.winehq.org/editparams.cgi the 'mostfreqthreshold' option.
Running ./checksetup.pl doesn't harm either
The essential task is to fill the duplicates table using the script: http://cvs.winehq.org/cvsweb/bugzilla/collectstats.pl You need to run it using cron.
Tobias
When I try to run the collectstats.pl script I get this:
wineowner@wine:~/opt/bugzilla$ ./collectstats.pl No value for param loginmethod at Bugzilla/Config.pm line 135. BEGIN failed--compilation aborted at Bugzilla/Auth.pm line 36. Compilation failed in require at Bugzilla.pm line 27. BEGIN failed--compilation aborted at Bugzilla.pm line 27. Compilation failed in require at ./collectstats.pl line 37. BEGIN failed--compilation aborted at ./collectstats.pl line 37.
I have not looked into the code to find why it does not work. Seems odd since the rest of bugzilla works fine.
On Wed, 2006-03-22 at 21:22 +0100, Tobias Burnus wrote:
Hello,
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, but I'm unable to help here (perl). (Browse the cvs: "http://cvs.winehq.org/cvsweb/bugzilla/")
Hmm, in principle one only needs to tweek at http://bugs.winehq.org/editparams.cgi the 'mostfreqthreshold' option.
Running ./checksetup.pl doesn't harm either
The essential task is to fill the duplicates table using the script: http://cvs.winehq.org/cvsweb/bugzilla/collectstats.pl You need to run it using cron.
Tobias
Jeremy Newman wrote:
On Wed, 2006-03-22 at 21:22 +0100, Tobias Burnus wrote:
Hello,
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, but I'm unable to help here (perl). (Browse the cvs: "http://cvs.winehq.org/cvsweb/bugzilla/")
Hmm, in principle one only needs to tweek at http://bugs.winehq.org/editparams.cgi the 'mostfreqthreshold' option.
Running ./checksetup.pl doesn't harm either
The essential task is to fill the duplicates table using the script: http://cvs.winehq.org/cvsweb/bugzilla/collectstats.pl You need to run it using cron.
Tobias
When I try to run the collectstats.pl script I get this:
wineowner@wine:~/opt/bugzilla$ ./collectstats.pl No value for param loginmethod at Bugzilla/Config.pm line 135. BEGIN failed--compilation aborted at Bugzilla/Auth.pm line 36. Compilation failed in require at Bugzilla.pm line 27. BEGIN failed--compilation aborted at Bugzilla.pm line 27. Compilation failed in require at ./collectstats.pl line 37. BEGIN failed--compilation aborted at ./collectstats.pl line 37.
I have not looked into the code to find why it does not work. Seems odd since the rest of bugzilla works fine.
Looks like you need to give loginmethod a value in Bugzilla.pm. For whatever reason this file is not part of CVS.
I can look at my local copy of this file when I get home.
--
Tony Lambregts
Tony Lambregts wrote:
Jeremy Newman wrote:
On Wed, 2006-03-22 at 21:22 +0100, Tobias Burnus wrote:
Hello,
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, but I'm unable to help here (perl). (Browse the cvs: "http://cvs.winehq.org/cvsweb/bugzilla/")
Hmm, in principle one only needs to tweek at http://bugs.winehq.org/editparams.cgi the 'mostfreqthreshold' option.
Running ./checksetup.pl doesn't harm either
The essential task is to fill the duplicates table using the script: http://cvs.winehq.org/cvsweb/bugzilla/collectstats.pl You need to run it using cron.
Tobias
When I try to run the collectstats.pl script I get this:
wineowner@wine:~/opt/bugzilla$ ./collectstats.pl No value for param loginmethod at Bugzilla/Config.pm line 135. BEGIN failed--compilation aborted at Bugzilla/Auth.pm line 36. Compilation failed in require at Bugzilla.pm line 27. BEGIN failed--compilation aborted at Bugzilla.pm line 27. Compilation failed in require at ./collectstats.pl line 37. BEGIN failed--compilation aborted at ./collectstats.pl line 37.
I have not looked into the code to find why it does not work. Seems odd since the rest of bugzilla works fine.
Looks like you need to give loginmethod a value in Bugzilla.pm. For whatever reason this file is not part of CVS.
I can look at my local copy of this file when I get home.
--
This is because we do not have loginmenthod defined in data/params
'letsubmitterchoosepriority' => 1, + 'loginmethod' => 'DB', 'loginnetmask' => '32',
-- Tony Lambregts
-
Chris Morgan -
Detlef Riekenberg -
Dimi Paun -
Jeremy Newman -
Jesse Allen -
Mike McCormack -
Robert Reif -
Segin -
Tobias Burnus -
Tom Spear -
Tom Spear (Dustin Booker, Dustin Navea)
-
Tony Lambregts -
Vitaliy Margolen