Andreas Bierfert andreas.bierfert@lowlatency.de wrote:
could you please stop arguing about the validity of the bug. What you are stating in comment 6 is really not exclusive. The Fedora wine packages are in fact 'prepackaged binary'.
Using the term 'prepackaged binary' doesn't make the package suddenly valid for WineHQ bugzilla, since it clearly contains not supported patches. Same applies for instance to crossover, ies4linux, wineskin or any other.
For the Fedora users pulse support in wine is an important feature. This is why the patches are in the Fedora build in the first place. I'd much rather have them included with upstream... Maybe sometime wine will gain openal support for audio input/output and this issue will go away.
Once again, packages with custom patches can't be supported through WineHQ bugzilla for obvious reasons. If the packager knows what he/she is dooing by including such patches - he/she should take the full resposibility for that, including accepting bug reports for his package. If he/she doesn't want to carry the support burden then using Wine source without any custom patches is the way to go.
Hello Dmitry,
Dmitry Timoshkov wrote:
Andreas Bierfert andreas.bierfert@lowlatency.de wrote:
could you please stop arguing about the validity of the bug. What you are stating in comment 6 is really not exclusive. The Fedora wine packages are in fact 'prepackaged binary'.
Using the term 'prepackaged binary' doesn't make the package suddenly valid for WineHQ bugzilla, since it clearly contains not supported patches. Same applies for instance to crossover, ies4linux, wineskin or any other.
For the Fedora users pulse support in wine is an important feature. This is why the patches are in the Fedora build in the first place. I'd much rather have them included with upstream... Maybe sometime wine will gain openal support for audio input/output and this issue will go away.
Once again, packages with custom patches can't be supported through WineHQ bugzilla for obvious reasons. If the packager knows what he/she is dooing by
I disagree with this statement. Each distribution modifies the upstream Wine in one way or the other. And a blanket "Screw you, use upstream Wine if you want support" doesn't cut it. The distributions are for us the main consumers of Wine and we should help them provide a good Wine experience to their users.
Of course in this specific case aka bug 26271 we cannot help as it involves winepulse.drv which is an unsupported outside patch.
including such patches - he/she should take the full resposibility for that, including accepting bug reports for his package. If he/she doesn't want to carry the support burden then using Wine source without any custom patches is the way to go.
bye michael
On Wed, 2011-03-02 at 17:15 +0100, Michael Stefaniuc wrote:
I disagree with this statement. Each distribution modifies the upstream Wine in one way or the other. And a blanket "Screw you, use upstream Wine if you want support" doesn't cut it. The distributions are for us the main consumers of Wine and we should help them provide a good Wine experience to their users.
Thanks.
Of course in this specific case aka bug 26271 we cannot help as it involves winepulse.drv which is an unsupported outside patch
As stated in 26271 the problem also occurs if build without the pulse patches. Help/insight in fixing this would be appreciated.
- Andreas
Hello Michael,
Once again, packages with custom patches can't be supported through WineHQ bugzilla for obvious reasons. If the packager knows what he/she is dooing by
I disagree with this statement. Each distribution modifies the upstream Wine in one way or the other. And a blanket "Screw you, use upstream Wine if you want support" doesn't cut it. The distributions are for us the main consumers of Wine and we should help them provide a good Wine experience to their users.
I don't understand. How are we supposed to support our distributions when they include unsupported patches? --Juan
Hello Juan,
Juan Lang wrote:
Once again, packages with custom patches can't be supported through WineHQ bugzilla for obvious reasons. If the packager knows what he/she is dooing by
I disagree with this statement. Each distribution modifies the upstream Wine in one way or the other. And a blanket "Screw you, use upstream Wine if you want support" doesn't cut it. The distributions are for us the main consumers of Wine and we should help them provide a good Wine experience to their users.
I don't understand. How are we supposed to support our distributions when they include unsupported patches?
Wine is big and those patches cover only a small aspect. E.g. if a distribution reports a crypt32 bug it doesn't matter if they use winepulse.drv or not, right? I'm just opposing the blanket "reject all" distribution Wine binaries created from modified source. For the Wine aspects modified by the distributions the distributions will have to do the heavy lifting. But the way we word that matters too. And of course we are always free to request a bug reporter to try to reproduce the bug with unmodified/latest Wine source. bye michael
Wine is big and those patches cover only a small aspect. E.g. if a distribution reports a crypt32 bug it doesn't matter if they use winepulse.drv or not, right? I'm just opposing the blanket "reject all" distribution Wine binaries created from modified source. For the Wine aspects modified by the distributions the distributions will have to do the heavy lifting. But the way we word that matters too. And of course we are always free to request a bug reporter to try to reproduce the bug with unmodified/latest Wine source.
Ah. Yes, you're right. The nuances of your disagreement escaped me, as this bug was clearly in an area affected by the unsupported patches. Thanks for the clarification. --Juan
Michael Stefaniuc mstefani@redhat.com wrote:
Once again, packages with custom patches can't be supported through WineHQ bugzilla for obvious reasons. If the packager knows what he/she is dooing by
I disagree with this statement. Each distribution modifies the upstream Wine in one way or the other.
Could you please list other Wine packages provided by distributions with custom patches applied you are aware of?
And a blanket "Screw you, use upstream Wine if you want support" doesn't cut it. The distributions are for us the main consumers of Wine and we should help them provide a good Wine experience to their users.
Of course in this specific case aka bug 26271 we cannot help as it involves winepulse.drv which is an unsupported outside patch.
That's precisely my point. How many users are prepared to compile Wine from source when they report a bug with such a Wine build, and somebody asks them to either use a package without custom patches or compile Wine om their own instead? What are the advantages of this "support"? Do the unsuspecting users really deserve to get such a hidden problem with presumably "official" Wine package they have recieved? It's very doubtful in the first place that the term "official" should be used for such packages. Are you going to encourage packagers to include whatever patches they deem to be "an important feature" for the users, and still claim that provide an official Wine binary package?
-
Andreas Bierfert -
Dmitry Timoshkov -
Juan Lang -
Michael Stefaniuc