"Jim White" <[EMAIL PROTECTED]> wrote:
Your "efforts" don't add value to it either. All you trying to do, is
create another poor quality software that whole world just can't get rid of.
If you so much like to have bad quality patches, why don't you start
your own repository, and grant "patch ac
The current process is crippling this project, limiting the developer base
and reducing community value. Without some healthy dissent it will never
change and get better. I am a friend of change, a true believer in the
process of continuous improvement. I believe one day, the WIne project w
Steven Edwards wrote:
> What you and others are asking for is the right to add broken hacks for
> the sake of user experience.
> ...
I didn't ask for anything and I said I don't think WineHQ is even able
to change this process.
Misconstruing the words, intent, and plain meaning expressed by peo
On 9/23/06, Robert Lunnon <[EMAIL PROTECTED]> wrote:
1. Publish the patch acceptance policy - Make sure this is the acceptance
policy and not the patch acceptance process. The Patch acceptance policy
should be developed by community process and be subject to change (and change
control). Perhaps
Hi Jim,On 9/22/06, Jim White <[EMAIL PROTECTED]> wrote:
Steven cited the business at Wineconf of Alexandre never being "provedwrong on a technical matter". Another straw man. The part ofAlexandre's patch process that is the root of this conflict between Wine
development-focused developers vs. Win
Scott Ritchie wrote:
> Yup, that's the bug I ran into last time I tried.
>
> And by "install all prereqs", what exactly do you mean?
>
build-essentials, asound, Fontforge, Freetype, etc Any package that
the configure script indicates might be missing.
I wish I could say exactly which ones
Scott Ritchie wrote:
> Yup, that's the bug I ran into last time I tried.
>
> And by "install all prereqs", what exactly do you mean?
>
build-essentials, asound, Fontforge, Freetype, etc Any package that
the configure script indicates might be missing.
I wish I could say exactly which ones
Vitaliy Margolen wrote:
> Robert Lunnon wrote:
>
>>>Getting feedback isn't always easy, so listen when you get it.
>>>
>>>If you don't want to go to the effort required to get your patches into
>>>Alexandre's tree, they're not going to get in themselves.
>>>
>>>Mike
>>
>>Rubbish,
>> The curr
Hello Robert,I am an employee of CodeWeavers and one of the former project coordinators of the ReactOS Project though my views do not represent either the position of my employer or the ReactOS Project of which I am no longer actively affiliated.
This thread was part of the reason I wanted to chair
Robert Lunnon wrote:
>> Getting feedback isn't always easy, so listen when you get it.
>>
>> If you don't want to go to the effort required to get your patches into
>> Alexandre's tree, they're not going to get in themselves.
>>
>> Mike
>
> Rubbish,
> The current process is crippling this pr
Jeff Latimer wrote:
>> And exactly this information should probably be stated in the
>> wine-patches subscription welcome mail.
>>
>> "If for some reason the Wine patches you submit fail to get applied,
>> then we'd appreciate you taking the effort of submitting your current
>> patch
>> as a new it
Yup, that's the bug I ran into last time I tried.
And by "install all prereqs", what exactly do you mean?
Thanks,
Scott Ritchie
On Fri, 2006-09-22 at 18:44 -0500, Evil Jay wrote:
> I can compile it fine on Kubuntu AMD64, except for font support
> (http://bugs.winehq.org/show_bug.cgi?id=6243 ).
I can compile it fine on Kubuntu AMD64, except for font support
(http://bugs.winehq.org/show_bug.cgi?id=6243 ). Just download the
latest CVS or git, install all pre-reqs then ./configure && make depend
&& sudo make install.
-J
Scott Ritchie wrote:
> I haven't been able to get Wine to build on
James Courtier-Dutton wrote:
I have place some documentation on the ALSA wiki site:
https://bugtrack.alsa-project.org/wiki/wikka.php?wakka=ALSAresampler
It tries to explain the constraints that the current ALSA resampler
works under.
You might like to read it as I think it will have impact on
On Thursday 21 September 2006 07:09, Dr J A Gow wrote:
> After having followed this thread for some time, I feel that there is an
> aspect that is often missed in the debate.
>
> As I see it, it would appear that Wine contributors fall into essentially
> two camps. There are those who develop Wine
Tomas Carnecky wrote:
My ultimate goal was to solve the dsound underruns which were so
horrible that I had to disable sound in World of Warcraft. While I
managed to get the sound working flawlessly (really... I never heard
such clear sound under wine) in WoW, it required WoW-specific hacks so
On Tue, Sep 19, 2006, Stefan Dösinger wrote:
> Am Montag 18 September 2006 10:12 schrieb Christopher GAUTIER:
> > I've identified a bug in IWineD3DDeviceImpl_CopyRects. When CopyRects()
> > is called to copy the source entirely into the destination surface, and
> > that the sizes matches, a plain m
I haven't been able to get Wine to build on AMD64 at all, even using the
3+ different howto's I've seen. This is why there still is no AMD64
package.
Seriously, if someone gets it working, update the wiki page and post
here.
Thanks,
Scott Ritchie
On Fri, 2006-09-22 at 16:04 -0400, Gerald Britt
On Thursday 21 September 2006 04:25, Mike McCormack wrote:
> Robert Lunnon wrote:
> > Which you are entitled to, but my opinion happens to differ. Whether the
> > wine core source has all the patches, (Which it doesn't - many, but not
> > all) isn't relevant, it's the process that they go through
On Thursday 21 September 2006 03:48, Jeremy White wrote:
> >>Wine works fine as-is in my opinion ;)
> >
> > Which you are entitled to, but my opinion happens to differ. Whether the
> > wine core source has all the patches, (Which it doesn't - many, but not
> > all) isn't relevant, it's the process
OK -- I did all that stuff, but the build failed.
note, I used the command
sudo apt-get --build source wine
as per the page http://www.winehq.com/site/download-deb
below are the error messages from the build. the weird thing is I DO
haev libdl.s0.2:
$ls -l /lib32/libdl.so.2
lrwxrwxrwx 1 roo
Tomas Carnecky wrote:
My ultimate goal was to solve the dsound underruns which were so
horrible that I had to disable sound in World of Warcraft. While I
managed to get the sound working flawlessly (really... I never heard
such clear sound under wine) in WoW, it required WoW-specific hacks so
Keep us posted. I'm interested in getting better support for audio recording
under Wine.
Hiji
- Original Message
From: Tomas Carnecky <[EMAIL PROTECTED]>
To: wine-devel@winehq.org
Sent: Friday, September 22, 2006 9:34:14 AM
Subject: Re: my dsound/winealsa hacks
Tomas Carnecky wrote:
Lots of progress has been made in fixing installer bugs lately,
but there are probably many such bugs hiding in plain view still.
It would be very helpful if people could look for bugs which:
a) appear to be MSI or setupapi related, and
b) occur in freely downloadable executables (e.g. trial versi
On Fri, Sep 22, 2006 at 12:04:40PM +0100, Robert Shearman wrote:
> Damjan Jovanovic wrote:
> >Changelog:
> >* Makes RPCRT4 use Winsock2 instead of native sockets (needed for
> >event object support)
> >* Adds support for TCP (ncacn_ip_tcp protocol) servers
>
> I appreciate your attempt at solving
Tomas Carnecky wrote:
I'm fairly sure this all could be done in a WoW-independent way, eg.
configure the hardware as the application requests it (by passing
LPCDSBUFFERDESC to the low-level driver etc) and keeping track of the
read/write positions could also be done in a better way.
A small
Elie Morisse wrote:
> A new version of my refcounting patch, lighter and honoring Stefan Dösinger
> proposal.
You forgot to attach the patch.
bye
michael
--
Michael Stefaniuc Tel.: +49-711-96437-199
Sr. Network EngineerFax.: +49-711-96437-111
Red Hat GmbH
Damjan Jovanovic wrote:
Changelog:
* Makes RPCRT4 use Winsock2 instead of native sockets (needed for
event object support)
* Adds support for TCP (ncacn_ip_tcp protocol) servers
I appreciate your attempt at solving this hard problem, but I don't
believe this is the right approach. Using winsoc
My ultimate goal was to solve the dsound underruns which were so
horrible that I had to disable sound in World of Warcraft. While I
managed to get the sound working flawlessly (really... I never heard
such clear sound under wine) in WoW, it required WoW-specific hacks so
my patch will never mak
On 9/21/06, Andrey Turkin <[EMAIL PROTECTED]> wrote:
MsiSetTargetPath can be used to change target path for directory after
CostFinalize, and all affected file paths must be recalculated. James
Hawkins sent a patch to make Wine's MSI engine do it for most cases;
this patch fixes one remaining "co
30 matches
Mail list logo