Re: Post-release plans

[Scott Ritchie]

On 07/16/2010 11:22 AM, Alexandre Julliard wrote:
> Folks,
> 
> First I want to thank everybody for your great work of the past two
> years. I'm very happy with what we have achieved with 1.2 (even if we
> didn't manage to get the regression numbers down ;-) You should all go
> out and have a drink to celebrate.

Agreed, congrats everyone.  Even on my end these last few days were
quite intense, I can only imagine what it's like for everyone else.

> Code freeze is of course lifted now, so once you have recovered from
> your hangover you can go wild with patches again. Please resubmit any
> patch that was marked deferred (rebased to the current tip of course).
> Releases will be made from the 1.3.x development branch every two weeks
> as usual.
> 

Is the current patch tracking system good enough to make sure none slip
through the cracks?  I'm worried what might happen if someone doesn't
resubmit.

> Bugs that are currently on the 1.2 milestone should not be automatically
> carried forward to the 1.4 milestone. We'll want to reevaluate which
> bugs are really important for 1.4, based on the release criteria once
> these are defined. But of course fixing the remaining 1.2-nominated bugs
> is still allowed...
> 

At the risk of being a curmudgeon, I'd like to start this discussion as
soon as we're done partying ;)

Thanks,
Scott Ritchie

Re: Sending patches for bug #22918

[Eliot Blennerhassett]

On 17/07/10 10:22, Misha Koshelev wrote:
> Also, if anyone knows how to make git format-patch only output the 10
> _bottom-most_ patches, please let me know.

Partial solution:

use git format-patch without the --stdout, to generate all the patches
as files, then git send-email or imap-send  

Re: Sending patches for bug #22918

[Hin-Tak Leung]

Misha Koshelev wrote:

Dear All:

Congrats on 1.2!

I have begun sending my patches from my repository:
http://github.com/misha680/wine/commits/master

Specifically, I have sent the first 10 patches (of approx 70 currently).

I look forward to your comments/commits ;)

Also, if anyone knows how to make git format-patch only output the 10
_bottom-most_ patches, please let me know.

I tried:
git format-patch -n --stdout origin --branches --not --remotes=upstream
-10 | git imap-send

(note the -10 in the command above)

but that sends the 10 topmost patches, sadly :(


Bottom of git-format-patch man-page, example:

Extract commits between revisions R1 and R2, and apply them on top of the 
current branch using git am to cherry-pick them:


   $ git format-patch -k --stdout R1..R2 | git am -3 -k

also read 'man git-rev-parse' about how to do address revision . You want ^10 or
 ~10 .

Re: Sending patches for bug #22918

[James McKenzie]

Misha Koshelev wrote:

Dear All:

Congrats on 1.2!

I have begun sending my patches from my repository:
http://github.com/misha680/wine/commits/master

  

Misha:

Might I make a tiny suggestion:  Send in one set of patches and wait for 
AJ's and others feedback.  Make appropriate corrections and then 
resubmit.  Repeat until the first set is accepted and incorporated into 
Wine.  Go back to your remaining patches and make all necessary 
corrections.  This will save your time and reduce the number of 
correction messages. 

If you need to, post them to the Wine Developers list, but I remember 
you doing this already.


Seventy patches is a very large number of patches to submit all in one go.

James McKenzie

Re: Sending patches for bug #22918

[Vitaliy Margolen]

On 07/16/2010 04:22 PM, Misha Koshelev wrote:
> Also, if anyone knows how to make git format-patch only output the 10
> _bottom-most_ patches
If you have 70 patches in your tree then:
git format-patch  HEAD~70..HEAD~60

Vitaliy.

Re: Please remove / block user from bugzilla

[James McKenzie]

Michael Stefaniuc wrote:

Austin English wrote:
  

On Thu, Jul 15, 2010 at 9:30 PM, James McKenzie
 wrote:


Rosanne DiMesio wrote:
  

On Thu, 15 Jul 2010 17:08:30 +0200
Gert van den Berg  wrote:




On Thu, Jul 15, 2010 at 16:23, James Mckenzie
 wrote:

  

Rosanne and you have a good point, but I would restrict it the limit to
four lines.  You should be able to describe a valid bug in that space.
 Anything more, and it becomes an attachement.



4 lines is horribly short... Especially for posting instructions to
reproduce problems, an overview of your system configuration, etc...


  

I agree. I've often exceeded 4 lines in comments.




I see your point.  However, should it not be sufficient to state a problem
in ten lines or less?  This prevents pasting lengthy logs, statements, etc.
in bugzilla?  I'll go with that number then.
  

I've often seen 10 exceeded as well. Like earlier discussed, a regex
for fixme/err/etc. would be more useful.


What Austin says. E.g. a git bisect result is at minimum 9 lines long,
with more than 1 line of changelog it gets longer. And we do want those
pasted into the comment and not attached.

  
Again, I agree.  What method do we want to use to prevent the post that 
started this long conversation, that is the posting of a 'broken' patch 
sequence? 

I would say look for "what file to patch" or the actual wording used by 
the patch program to state I cannot find the file to patch.


As to the catching of 'fixme/error/trace/etc. I'm for this as well using 
regex.  Capture it and post a warning.  Flag the account.  Give a set 
number of warnings in a certain time period.  Then lock the account.   
The poster will have to ask permission to be allowed to post again.


Does this sound doable and is it permissible?  I don't want folks 
walking away because they cannot post, but if they are posting garbage 
it doesn't help us.  Also, give them a posting link if they cannot, for 
some reason, add attachments.  Sort of like a bugzilla for the Bugzilla 
thing.  If something is broken with Bugzilla we certainly should be 
interested.


James McKenzie

Re: [resubmit] cmd: Fix cmd's mishandling of quote-enclosed command strings

[testbot]

Hi,

While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=3367

Your paranoid android.


=== WNT4WSSP6 (32 bit) ===
batch.c:188: Test failed: unexpected end of output in line 48, expected 0x74

=== W2KPROSP4 (32 bit) ===
batch.c:188: Test failed: unexpected end of output in line 48, expected 0x74

=== WXPPROSP3 (32 bit) ===
batch.c:188: Test failed: unexpected end of output in line 48, expected 0x74

=== W2K3R2SESP2 (32 bit) ===
batch.c:188: Test failed: unexpected end of output in line 48, expected 0x74

=== WVISTAADM (32 bit) ===
batch.c:188: Test failed: unexpected end of output in line 48, expected 0x74

=== W2K8SE (32 bit) ===
batch.c:188: Test failed: unexpected end of output in line 48, expected 0x74

=== W7PRO (32 bit) ===
batch.c:188: Test failed: unexpected end of output in line 48, expected 0x74

=== W7PROX64 (32 bit) ===
batch.c:188: Test failed: unexpected end of output in line 48, expected 0x74

=== W7PROX64 (64 bit) ===
batch.c:188: Test failed: unexpected end of output in line 48, expected 0x74

Re: [PATCH 06/10] d3dx9: Add comment to delineate vertex buffer and index buffer tests.

[testbot]

Hi,

While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=3362

Your paranoid android.


=== WINEBUILD (build) ===
Make failed

Re: [PATCH 09/10] d3dx9: Implement D3DXCreateBox for the case of incorrect parameters.

[testbot]

Hi,

While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=3365

Your paranoid android.


=== WINEBUILD (build) ===
Make failed

Re: [PATCH 03/10] d3dx9: Add tests for D3DXCreateSphere vertex buffer description.

[testbot]

Hi,

While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=3359

Your paranoid android.


=== WINEBUILD (build) ===
Make failed

Re: [PATCH 08/10] d3dx9: Add tests for D3DXCreateBox index buffer description.

[testbot]

Hi,

While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=3364

Your paranoid android.


=== WINEBUILD (build) ===
Make failed

Re: [PATCH 10/10] d3dx9: Add NULL mesh parameter test to D3DXCreateBox.

[testbot]

Hi,

While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=3366

Your paranoid android.


=== WINEBUILD (build) ===
Make failed

Re: [PATCH 07/10] d3dx9: Add test for number of faces in D3DXCreateBox.

[testbot]

Hi,

While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=3363

Your paranoid android.


=== WINEBUILD (build) ===
Make failed

Re: [PATCH 01/10] d3dx9: Add stub and basic test for D3DXCreateSphere.

[testbot]

Hi,

While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=3357

Your paranoid android.


=== WINEBUILD (build) ===
Make failed

Re: [PATCH 05/10] d3dx9: Add tests for D3DXCreateBox.

[testbot]

Hi,

While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=3361

Your paranoid android.


=== WINEBUILD (build) ===
Make failed

Re: [PATCH 04/10] d3dx9: Test raw vertex data for D3DXCreateSphere.

[testbot]

Hi,

While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=3360

Your paranoid android.


=== WINEBUILD (build) ===
Make failed

Re: [PATCH 01/10] d3dx9: Add stub and basic test for D3DXCreateSphere.

[Misha Koshelev]

On Fri, Jul 16, 2010 at 5:37 PM, Marvin  wrote:
> Hi,
>
> While running your changed tests on Windows, I think I found new failures.
> Being a bot and all I'm not very good at pattern recognition, so I might be
> wrong, but could you please double-check?
> Full results can be found at
> http://testbot.winehq.org/JobDetails.pl?Key=3357
>
> Your paranoid android.
>
>
> === WINEBUILD (build) ===
> Make failed
>

Umm Marvin reports:
/var/lib/winetestbot/build-mingw32/dlls/d3dx9_36/tests/../../../../wine-git/dlls/d3dx9_36/tests/mesh.c:491:
undefined reference to `_d3dxcreatesph...@24'
/var/lib/winetestbot/build-mingw32/dlls/d3dx9_36/tests/../../../../wine-git/dlls/d3dx9_36/tests/mesh.c:494:
undefined reference to `_d3dxcreatesph...@24'
/var/lib/winetestbot/build-mingw32/dlls/d3dx9_36/tests/../../../../wine-git/dlls/d3dx9_36/tests/mesh.c:497:
undefined reference to `_d3dxcreatesph...@24'
/var/lib/winetestbot/build-mingw32/dlls/d3dx9_36/tests/../../../../wine-git/dlls/d3dx9_36/tests/mesh.c:500:
undefined reference to `_d3dxcreatesph...@24'
/var/lib/winetestbot/build-mingw32/dlls/d3dx9_36/tests/../../../../wine-git/dlls/d3dx9_36/tests/mesh.c:529:
undefined reference to `_d3dxcreatesph...@24'
mesh.o:/var/lib/winetestbot/build-mingw32/dlls/d3dx9_36/tests/../../../../wine-git/dlls/d3dx9_36/tests/mesh.c:532:
more undefined references to `_d3dxcreatesph...@24' follow
collect2: ld returned 1 exit status
winegcc: i686-pc-mingw32-gcc failed
make: *** [d3dx9_36_test.exe] Error 2
make: Leaving directory `/var/lib/winetestbot/build-mingw32/dlls/d3dx9_36/tests'

I believe as was the case previously, this is the case of the actual
DLL not being regenerated when the spec file changes :(

Thank you for your attention to this. I will forward to Dan & Greg as well.

Misha

Sending patches for bug #22918

[Misha Koshelev]

Dear All:

Congrats on 1.2!

I have begun sending my patches from my repository:
http://github.com/misha680/wine/commits/master

Specifically, I have sent the first 10 patches (of approx 70 currently).

I look forward to your comments/commits ;)

Also, if anyone knows how to make git format-patch only output the 10
_bottom-most_ patches, please let me know.

I tried:
git format-patch -n --stdout origin --branches --not --remotes=upstream
-10 | git imap-send

(note the -10 in the command above)

but that sends the 10 topmost patches, sadly :(

Thanks again!
Misha

Re: dlls/ntdll/file.c: Use FIXME_ONCE for quieter reports.

[Saulius Krasuckas]

* On Thu, 15 Jul 2010, Michael Stefaniuc wrote:
> Saulius Krasuckas wrote:
> > 
> > TRACE_ONCE probably could help in some cases too.  There I see another 
> 
> I fail to see how TRACE_ONCE could make any sense.
> TRACE is used to trace the important parts of the code flow. Just 
> printing a TRACE once is less than helpful; it is waay better to not 
> print the TRACE at all.

I was in a hurry a bit and I am persuaded now :), thanks.

> Of course TRACE_ONCE should be defined for symmetry and preventing
> somebody wasting time to send a patch with an implementation for it.
> Too bad that Alexandre is too nice else that would be something like:
> 
> #define TRACE_ONCE  TRACE_ONCE_Misguided_developer_detected

I am away from development now, but you will never know :).  Such define 
sounds OK.  Or has it already been decided on IRC to not exist?


S.
PS: Congrats to all the folks for Wine-1.2!

Re: Administrative privileges and running tests under Windows

[Mariusz Pluciński]

W dniu 16.07.2010 19:59, Reece Dunn pisze:

Use broken() to denote the administrator case --

 ok(hr == S_OK || broken(hr == E_ACCESSDENIED) /* non-Admin user
*/, IGameExplorer_AddGame(...));

This means that E_ACCESSDENIED is a valid case on Windows, but not on Wine.

- Reece
   

Yes, I know how broken() works, but there are two problems with it:

First problem, is that this is not what I want to do. I did not wrote
about it in previous mail, but I do a little more than only calling
this procedure. In details, this routine writes some data into registry
and after call I check these data. These data depends on the parameter
I described before (installScope). The problem is that I can run these
tests on Windows, manually selecting permission level (and they behave
as I described before), and they behave as I expected (I described how
this routine behaves on several cases). I hope that making it able to
run on Windows will let me to be sure that data produced by my library
are identical like this created by Windows' one.

Second problem is that I cannot simply compare result with some
ACCESSDENIED error code, cause this routine simply does not return it.
Instead, when the "access denied" occurs, it returns E_FAIL, as in
almost every other problem. And I cannot do broken(hr==E_FAIL), because
then test will be always passed on Windows, even if completely other
problem occurs. So, even if I give up with checking data, broken() won't
work here.

Re: [website] German translation of stable release news 1.2

[Paul Vriens]

On 07/16/2010 05:50 PM, André Hentschel wrote:

+Der Quellcode ist jetzthttp://prdownloads.sourceforge.net/wine/wine-1.2-rc7.tar.bz2";>verfügbar.


Hi André,

You've listed the wrong download.

--
Cheers,

Paul.

Post-release plans

[Alexandre Julliard]

Folks,

First I want to thank everybody for your great work of the past two
years. I'm very happy with what we have achieved with 1.2 (even if we
didn't manage to get the regression numbers down ;-) You should all go
out and have a drink to celebrate.

Code freeze is of course lifted now, so once you have recovered from
your hangover you can go wild with patches again. Please resubmit any
patch that was marked deferred (rebased to the current tip of course).
Releases will be made from the 1.3.x development branch every two weeks
as usual.

The 'stable' git branch has been reset to point to 1.2. Fixes can be
nominated for cherry-picking to the stable branch by setting the '1.2.x'
milestone in bugzilla. Please only nominate bugs that are already fixed
in the tip and that contain the sha1 of the corresponding commit. There
will be a 1.2.1 release in a couple of months. There may be further
stable releases if enough fixes can be still be cherry-picked cleanly to
make it worth it.

Bugs that are currently on the 1.2 milestone should not be automatically
carried forward to the 1.4 milestone. We'll want to reevaluate which
bugs are really important for 1.4, based on the release criteria once
these are defined. But of course fixing the remaining 1.2-nominated bugs
is still allowed...

-- 
Alexandre Julliard
julli...@winehq.org

Re: Administrative privileges and running tests under Windows

[Reece Dunn]

2010/7/16 Mariusz Pluciński :
> Hi wine-devel
> I have problems with tests I written last time.
> The problem is connected with privileges levels under Windows.
>
> The method I'm testing is IGameExplorer::AddGame,
> which registers given game in Windows Game Explorer.
> One of it's parameters (installScope) defines if game should
> be registered for all users or only currently logged one. The
> problem is that routine's behaviour depends on if application
> was started with administrative privileges or not.
>
> If I call method with GIS_ALL_USERS parameter, it succeeds
> only with administrative privileges (fails if I run it as normal
> user). If I call it with GIS_CURRENT_USER parameter, it succeeds
> under normal user level, and fails (sic!) under administrative.
>
> My question is, how I should write tests to support both
> of these cases. Both seems to be exclusive, and I prefer first
> to ask, rather than trying implement it in some odd
> (and probably wrong) way. I also want to make it available
> to run under Wine project's test machines, but I don't know
> how they're configured and will them allow me to test
> administrative case.

Use broken() to denote the administrator case --

ok(hr == S_OK || broken(hr == E_ACCESSDENIED) /* non-Admin user
*/, IGameExplorer_AddGame(...));

This means that E_ACCESSDENIED is a valid case on Windows, but not on Wine.

- Reece

Administrative privileges and running tests under Windows

[Mariusz Pluciński]

Hi wine-devel
I have problems with tests I written last time.
The problem is connected with privileges levels under Windows.

The method I'm testing is IGameExplorer::AddGame,
which registers given game in Windows Game Explorer.
One of it's parameters (installScope) defines if game should
be registered for all users or only currently logged one. The
problem is that routine's behaviour depends on if application
was started with administrative privileges or not.

If I call method with GIS_ALL_USERS parameter, it succeeds
only with administrative privileges (fails if I run it as normal
user). If I call it with GIS_CURRENT_USER parameter, it succeeds
under normal user level, and fails (sic!) under administrative.

My question is, how I should write tests to support both
of these cases. Both seems to be exclusive, and I prefer first
to ask, rather than trying implement it in some odd
(and probably wrong) way. I also want to make it available
to run under Wine project's test machines, but I don't know
how they're configured and will them allow me to test
administrative case.

Re: Please remove / block user from bugzilla

[Wolfram Sang]

> Very BAD:
> -
> Changelog: This fixes bug #4711
> 
> BAD:
> 
> Changelog: Change the handling of flags X Y Z because this fixes bug #4711
> 
> OK:
> ---
> Changelog: Change a corner case in the handling of flags X Y Z (with tests).
> This resolve the issue from bug #4711.
> 
> 
> The bug number is *only* additional information. It isn't the 
> justification for a patch and definitely not the sole changelog.

ACK. This was my rationale until two hours ago ;)

Re: RFC: Detecting the wine prefix

[Michael Stefaniuc]

On 07/16/2010 04:58 PM, André Hentschel wrote:

Am 16.07.2010 11:32, schrieb Michael Stefaniuc:

Hello Paul,

Paul Chitescu wrote:

I would want to implement a change in where the wine prefix is assumed by
default.

The current behavior of only considering WINEPREFIX is cumbersome and risky.
Slip a finger, forget a letter and you end running a potential disastrous
command in the wrong prefix. I ruined my main prefix by accidenatlly running
"winetricks ie6" in it...

To fix that I use a wrapper script (unimaginatively named "win") that detects
the proper prefix from the current directory and calls wine or other programs
(winecfg, wineserver, winetricks, etc.) after setting WINEPREFIX. I am
satisfied by this wrapper but has several disadvantages:
- You need to remember to run it instead of wine.
- You may paste a command from somewhere and forget to add "win" in front.
- Needs to be distributed.

The proposed solution is to incorporate the prefix detection logic in wine
itself so no wrapper is needed.

The modified behavior would be like this:
- If WINEPREFIX is set obey that, user knows better. This is also required to
create a new prefix.
- Starting from current working directory descend towards root looking for a
directory that:
1. Has a dosdevices/ subdirectory and a system.reg file
or
2. Has a .wine symlink pointing to a directory matching condition 1.
or
3. Holds a .wine regular file whose content is the name of a directory
matching condition 1.
- If a valid prefix (matches condition 1. above) is found use it for wine
- Else use the default ~/.wine

The extra checks 2. and 3. are to be able to handle the case when the current
directory is on a path that is symlinked from inside the prefix. In particular
test 3. is used when the files are on a FAT (or other symlink incapable)
partition. I have several wine prefixes whose "Program Files" is located on a
much larger FAT32 partition shared with you know what.

What do you think about this? Should I go on coding it?

I like the idea as it follows the DWIM (Do What I Mean) principle.
But the working directory shouldn't be the primary means to detect what
WINEPREFIX to use. That should be inherited first from the location of
the Win32 binary that is run. E.g. working on multiple regression bugs I
have used a separate git tree as well as a separate WINEPREFIX per bug.
My CWD was always the SRCDIR/BUILDIR thus useless to find the WINEPREFIX
but the path to the binary always had the WINEPREFIX informations in it:
   ./wine ~/wine/prefixes/21409/drive_c/Program\ Files/foo/foo.exe

The "descend towards root" is used extensively by git so that one can
provide a good inspiration on how to do it, especially the corner cases.




Both cases should be taken into account:

That's what I said.


user:~/.wineprefix/drive_c$ wine myapp.exe
user:~/$  wine .wineprefix/drive_c/myapp.exe

Both should work and use .wineprefix

Also dont forget about worst case situations like:

user:~/.wineA/drive_c$ WINEPREFIX=~/.wineB wine ../../.wineC/drive_c/myapp.exe

This makes clear IMHO that the env var WINEPREFIX should have the highest 
priority, as i think this should be started using .wineB

So i think if no WINEPREFIX is specified then the cwd should be used and if 
that is not in some wineprefix the apppatch should be used.

The second part is wrong.
If the user *explicitly* requests something we have to honor it. So
- Highest priority: WINEPREFIX aka "I know what I'm doing, stop ASSuming 
and do what I tell you to do!"
- Second highest priority: application path. The user explicitly passes 
that to Wine; we have to honor that.
- Last priority: current working directory. This actually is needed 
*only* for stuff like "wineconsole cmd" or "winetricks bla" as "wine 
foo.exe" already specifies the path to the app and is handled by the 
second rule.


bye
michael

Re: RFC: Detecting the wine prefix

[André Hentschel]

Am 16.07.2010 11:32, schrieb Michael Stefaniuc:
> Hello Paul,
> 
> Paul Chitescu wrote:
>> I would want to implement a change in where the wine prefix is assumed by 
>> default.
>>
>> The current behavior of only considering WINEPREFIX is cumbersome and risky. 
>> Slip a finger, forget a letter and you end running a potential disastrous 
>> command in the wrong prefix. I ruined my main prefix by accidenatlly running 
>> "winetricks ie6" in it...
>>
>> To fix that I use a wrapper script (unimaginatively named "win") that 
>> detects 
>> the proper prefix from the current directory and calls wine or other 
>> programs 
>> (winecfg, wineserver, winetricks, etc.) after setting WINEPREFIX. I am 
>> satisfied by this wrapper but has several disadvantages:
>> - You need to remember to run it instead of wine.
>> - You may paste a command from somewhere and forget to add "win" in front.
>> - Needs to be distributed.
>>
>> The proposed solution is to incorporate the prefix detection logic in wine 
>> itself so no wrapper is needed.
>>
>> The modified behavior would be like this:
>> - If WINEPREFIX is set obey that, user knows better. This is also required 
>> to 
>> create a new prefix.
>> - Starting from current working directory descend towards root looking for a 
>> directory that:
>>  1. Has a dosdevices/ subdirectory and a system.reg file
>>or
>>  2. Has a .wine symlink pointing to a directory matching condition 1.
>>or
>>  3. Holds a .wine regular file whose content is the name of a directory 
>> matching condition 1.
>> - If a valid prefix (matches condition 1. above) is found use it for wine
>> - Else use the default ~/.wine
>>
>> The extra checks 2. and 3. are to be able to handle the case when the 
>> current 
>> directory is on a path that is symlinked from inside the prefix. In 
>> particular 
>> test 3. is used when the files are on a FAT (or other symlink incapable) 
>> partition. I have several wine prefixes whose "Program Files" is located on 
>> a 
>> much larger FAT32 partition shared with you know what.
>>
>> What do you think about this? Should I go on coding it?
> I like the idea as it follows the DWIM (Do What I Mean) principle.
> But the working directory shouldn't be the primary means to detect what
> WINEPREFIX to use. That should be inherited first from the location of
> the Win32 binary that is run. E.g. working on multiple regression bugs I
> have used a separate git tree as well as a separate WINEPREFIX per bug.
> My CWD was always the SRCDIR/BUILDIR thus useless to find the WINEPREFIX
> but the path to the binary always had the WINEPREFIX informations in it:
>   ./wine ~/wine/prefixes/21409/drive_c/Program\ Files/foo/foo.exe
> 
> The "descend towards root" is used extensively by git so that one can
> provide a good inspiration on how to do it, especially the corner cases.
> 
> bye
>   michael
> 
> 

Both cases should be taken into account:

user:~/.wineprefix/drive_c$ wine myapp.exe
user:~/$  wine .wineprefix/drive_c/myapp.exe

Both should work and use .wineprefix

Also dont forget about worst case situations like:

user:~/.wineA/drive_c$ WINEPREFIX=~/.wineB wine ../../.wineC/drive_c/myapp.exe

This makes clear IMHO that the env var WINEPREFIX should have the highest 
priority, as i think this should be started using .wineB

So i think if no WINEPREFIX is specified then the cwd should be used and if 
that is not in some wineprefix the apppatch should be used.

-- 

Best Regards, André Hentschel

Re: Please remove / block user from bugzilla

[Michael Stefaniuc]

On 07/16/2010 03:50 PM, Dan Kegel wrote:

So it boils down to disagreements about two things:

- mentioning a bug number when posting a patch
I think this is a misunderstanding. There are different ways of adding 
the bug number when posting a patch:


Very BAD:
-
Changelog: This fixes bug #4711

BAD:

Changelog: Change the handling of flags X Y Z because this fixes bug #4711

OK:
---
Changelog: Change a corner case in the handling of flags X Y Z (with tests).
   This resolve the issue from bug #4711.


The bug number is *only* additional information. It isn't the 
justification for a patch and definitely not the sole changelog.


bye
michael

Re: Please remove / block user from bugzilla

[Henri Verbeet]

On 16 July 2010 16:31, Dan Kegel  wrote:
> Without actual examples, I can't see what you're objecting to.
There are three specific examples in this thread, two of those were
provided by yourself, one was by me. If you read carefully you can
probably find them. I also explicitly spelled the issue out three
times. I think that should be enough for you to be able to figure it
out. I'd suggest to take all this as valuable advice, but you're of
course also free to ignore it.

Re: Please remove / block user from bugzilla

[Dan Kegel]

On Fri, Jul 16, 2010 at 7:08 AM, Henri Verbeet  wrote:
> No, you're mistaking specific instances for the larger issue there.
> What it boils down to is giving bad advice from a perceived position
> of authority. Please don't make me search through the archives to find
> every single specific instance.

Without actual examples, I can't see what you're objecting to.
- Dan

Re: Please remove / block user from bugzilla

[James Mckenzie]

Luke Benstead  wrote:
>Sent: Jul 16, 2010 7:18 AM
>To: Henri Verbeet 
>Cc: wine-devel@winehq.org, Dan Kegel 
>Subject: Re: Please remove / block user from bugzilla
>
>> How do frequent wine committers, and especially Alexandre, feel about
>> > these two issues?
>> I'd say Alexandre's opinion is pretty clear, as always:
>> http://www.winehq.org/pipermail/wine-devel/2010-February/081744.html.
>>
>>
>That's doesn't settle this at all, Alexandre is almost certainly referring
>to the bug number in the patch itself there, rather than the subject line.

Actually, during the first part of the Wine 1.2 rc set, it was suggested to put 
the bug number somewhere in either the changelog or in the subject line.  What 
I seen in the message is that AJ wanted something more meaningful in the code 
than just "testing for bug ".  The comment could become part of the Wine 
code base and is not clear.

James McKenzie

Re: Please remove / block user from bugzilla

[Luke Benstead]

> How do frequent wine committers, and especially Alexandre, feel about
> > these two issues?
> I'd say Alexandre's opinion is pretty clear, as always:
> http://www.winehq.org/pipermail/wine-devel/2010-February/081744.html.
>
>
That's doesn't settle this at all, Alexandre is almost certainly referring
to the bug number in the patch itself there, rather than the subject line.

Luke.

Re: Please remove / block user from bugzilla

[Henri Verbeet]

On 16 July 2010 15:50, Dan Kegel  wrote:
> So it boils down to disagreements about two things:
>
> - mentioning a bug number when posting a patch
>
> - turning spammy FIXMEs into oneshots
>
No, you're mistaking specific instances for the larger issue there.
What it boils down to is giving bad advice from a perceived position
of authority. Please don't make me search through the archives to find
every single specific instance.

> These both seem like things reasonable developers could disagree about.
> (Indeed, Roderick recently posted a patch with a bug number in the subject 
> line,
> http://www.winehq.org/pipermail/wine-patches/2010-March/086152.html )
>
> How do frequent wine committers, and especially Alexandre, feel about
> these two issues?
I'd say Alexandre's opinion is pretty clear, as always:
http://www.winehq.org/pipermail/wine-devel/2010-February/081744.html.

Re: Cascading test failures

[Jeff Zaroyko]

On Fri, Jul 16, 2010 at 11:35 PM, Hans Leidekker  wrote:
> On Fri, 2010-07-16 at 15:12 +0200, Paul Vriens wrote:
>
>> In the past we have seen that on slower machines the number of tests
>> just exceeded the timeout. That has been 'corrected' back than by making
>> some tests interactive. I guess because of the multitude of new tests we
>> have ended up in the same situation.
>
> The msi:install test completes in 90 seconds here in a vm, so well
> within the timeout of 300 seconds.
>

I haven't run a full winetest for a few weeks, but I just gave
msi:install a run on my laptop, Vista 32bit SP2, Intel Core 2 Duo @
2.53GHz, 4GB ram.

install: 8535 tests executed (0 marked as todo, 76 failures), 1 skipped.

Took 4 minutes 47 seconds, as another data point.

RE: Cascading test failures

[Greg Geldorp]

> From: Hans Leidekker [mailto:h...@meelstraat.net]
>
> On Fri, 2010-07-16 at 15:12 +0200, Paul Vriens wrote:
>
> > In the past we have seen that on slower machines the number of tests
> > just exceeded the timeout. That has been 'corrected' back than by making
> > some tests interactive. I guess because of the multitude of new tests we
> > have ended up in the same situation.
>
> The msi:install test completes in 90 seconds here in a vm, so well
> within the timeout of 300 seconds.

The winetest.exe timeout is 120 seconds, not 300 (TestBot uses 300). So 90
seconds isn't that far off from the timeout.
The MsiInstallProductA() call in test_delete_services() consistently took 30
seconds (25% of the available time) during my testing.

Ge.

Re: Please remove / block user from bugzilla

[Dan Kegel]

So it boils down to disagreements about two things:

- mentioning a bug number when posting a patch

- turning spammy FIXMEs into oneshots

These both seem like things reasonable developers could disagree about.
(Indeed, Roderick recently posted a patch with a bug number in the subject line,
http://www.winehq.org/pipermail/wine-patches/2010-March/086152.html )

How do frequent wine committers, and especially Alexandre, feel about
these two issues?
- Dan

Re: Cascading test failures

[Alexandre Julliard]

Hans Leidekker  writes:

> On Fri, 2010-07-16 at 04:36 -0700, Greg Geldorp wrote:
>
>>  For all the cases I've checked, when these 1574 errors occur the preceding
>>  msi:install test timed out (the reverse is not true, I see msi:install
>>  timeouts followed by a successful msi:package). 
>
> Do you have any clue why the test times out? Is there a dialog waiting
> to be clicked?

Yes, it seems the install test often triggers dialogs.

-- 
Alexandre Julliard
julli...@winehq.org

Re: Cascading test failures

[Hans Leidekker]

On Fri, 2010-07-16 at 15:12 +0200, Paul Vriens wrote:

> In the past we have seen that on slower machines the number of tests 
> just exceeded the timeout. That has been 'corrected' back than by making 
> some tests interactive. I guess because of the multitude of new tests we 
> have ended up in the same situation.

The msi:install test completes in 90 seconds here in a vm, so well
within the timeout of 300 seconds.

Re: kernel32: Update the Dutch translation

[Sven Baars]

Paul Vriens wrote:

On 07/16/2010 03:05 PM, Sven Baars wrote:

  MessageId=1207
  SymbolicName=ERROR_NOT_CONTAINER
  Language=NLD
-Not a container
+Geen
  .


You are missing something here I guess.


I guess so too. New patch sent

Sven

Re: kernel32: Update the Dutch translation

[Paul Vriens]

On 07/16/2010 03:05 PM, Sven Baars wrote:

  MessageId=1207
  SymbolicName=ERROR_NOT_CONTAINER
  Language=NLD
-Not a container
+Geen
  .


You are missing something here I guess.

--
Cheers,

Paul.

Re: Cascading test failures

[Paul Vriens]

On 07/16/2010 03:05 PM, Hans Leidekker wrote:

On Fri, 2010-07-16 at 04:36 -0700, Greg Geldorp wrote:


  For all the cases I've checked, when these 1574 errors occur the preceding
  msi:install test timed out (the reverse is not true, I see msi:install
  timeouts followed by a successful msi:package).


Do you have any clue why the test times out? Is there a dialog waiting
to be clicked?






In the past we have seen that on slower machines the number of tests 
just exceeded the timeout. That has been 'corrected' back than by making 
some tests interactive. I guess because of the multitude of new tests we 
have ended up in the same situation.


--
Cheers,

Paul.

Re: Cascading test failures

[Hans Leidekker]

On Fri, 2010-07-16 at 04:36 -0700, Greg Geldorp wrote:

>  For all the cases I've checked, when these 1574 errors occur the preceding
>  msi:install test timed out (the reverse is not true, I see msi:install
>  timeouts followed by a successful msi:package). 

Do you have any clue why the test times out? Is there a dialog waiting
to be clicked?

Re: wineboot: fix Serbian Latin translation

[Paul Vriens]

On 07/16/2010 02:31 PM, Marko Nikolic wrote:

Paul Vriens wrote:


On 07/14/2010 09:40 AM, Damjan Jovanovic wrote:

Changelog:
* wineboot: fix Serbian Latin translation

Damjan Jovanovic



Hi Damjan,

Thanks for looking into this. I guess we need the pragma statement now
as you are introducing UTF-8, not?

I did talk to Nenad about the fact that his translations appeared to be
all ASCII (and I did see some non-ASCII ones on wikipedia) but no
response so I'd figured it was correct.



Hi,

No, it is not correct, Serbian Latin translation must include non-ASCII
character. The article on wikipedia is correct.

Regards,

Marko



Hi Marko,

Nenad has already provided me with some correct translations (with 
respect to the characters). I hope to sent out some patches soon to add 
more Serbian translations (but not before 1.2 of course).


Feel free to help out of course.

--
Cheers,

Paul.

Re: Please remove / block user from bugzilla

[Henri Verbeet]

On 16 July 2010 14:10, Wolfram Sang  wrote:
> I am confused. Following this list only, I so far did not notice someone
> saying "don't tell the bug number" (ok, might be my fault), but a few
> times asking the question "does this patch fix an actual" bug. Also,
> SubmittingPatches says:
>
> ===
>
> ...
> Include a description
> ...
> If you're working on a bug in bugzilla, mention the bug number, and
> consider filing a bug if none exists.
>
> ===
>
I'd say that's misinformation. As for "Does this patch fix an actual
bug?", I could see how that may confuse someone, but you should
generally interpret that as "Does this fix a real issue in the code.",
or "Are there any real applications that care about this.", as opposed
to the patch making a style change, changing something that
applications don't care about in practice, or only fixing a perceived
bug because the patch author simply misunderstood the original code.
An associated bug in bugzilla is not required for patches, and if the
patch is good and gets applied it would only serve to spam wine-bugs,
which is already a fairly high-volume list these days. I suppose you
could open a bug if the patch gets rejected and the issue turns out to
be too hard to fix though.

> Maybe this is a misunderstanding of terminology? 'commit log' is for me
> the combination of the single-line 'header' plus the 'description', which
> can be multiple paragraphs. (and is usually dropped when patches are
> imported to the official repo. Why is that BTW?) I would agree, that the
> bug number should not be in the header, but having it as additional
> information besides the regular description should not really hurt?
>
If parts of the description are dropped, that's usually because
they're considered superfluous. E.g., should be obvious from the patch
itself, should be obvious for someone familiar with the code, etc. It
should be pretty rare for a patch to need more than a couple of lines
as a description. It's of course possibly that the issue you're fixing
is really subtle / tricky, but in that case it probably makes more
sense to document that in a comment directly in the code. Chances are
though that if your patch *needs* a long description it's because it's
trying to do too much at once, or tries to do it in a way that's too
complicated.

Re: wineboot: fix Serbian Latin translation

[Marko Nikolic]

Paul Vriens wrote:

> On 07/14/2010 09:40 AM, Damjan Jovanovic wrote:
>> Changelog:
>> * wineboot: fix Serbian Latin translation
>>
>> Damjan Jovanovic
>>
> 
> Hi Damjan,
> 
> Thanks for looking into this. I guess we need the pragma statement now
> as you are introducing UTF-8, not?
> 
> I did talk to Nenad about the fact that his translations appeared to be
> all ASCII (and I did see some non-ASCII ones on wikipedia) but no
> response so I'd figured it was correct.
> 

Hi,

No, it is not correct, Serbian Latin translation must include non-ASCII 
character. The article on wikipedia is correct.

Regards,

Marko

Re: RFC: Detecting the wine prefix

[Michael Stefaniuc]

Paul Chitescu wrote:
> On Friday 16 July 2010 12:32:33 pm Michael Stefaniuc wrote:
>> Hello Paul,
>>
>> Paul Chitescu wrote:
>>> I would want to implement a change in where the wine prefix is assumed by 
>>> default.
>>>
>>> The current behavior of only considering WINEPREFIX is cumbersome and 
> risky. 
>>> Slip a finger, forget a letter and you end running a potential disastrous 
>>> command in the wrong prefix. I ruined my main prefix by accidenatlly 
>>> running 
>>> "winetricks ie6" in it...
>>>
>>> To fix that I use a wrapper script (unimaginatively named "win") that 
> detects 
>>> the proper prefix from the current directory and calls wine or other 
> programs 
>>> (winecfg, wineserver, winetricks, etc.) after setting WINEPREFIX. I am 
>>> satisfied by this wrapper but has several disadvantages:
>>> - You need to remember to run it instead of wine.
>>> - You may paste a command from somewhere and forget to add "win" in front.
>>> - Needs to be distributed.
>>>
>>> The proposed solution is to incorporate the prefix detection logic in wine 
>>> itself so no wrapper is needed.
>>>
>>> The modified behavior would be like this:
>>> - If WINEPREFIX is set obey that, user knows better. This is also required 
> to 
>>> create a new prefix.
>>> - Starting from current working directory descend towards root looking for 
> a 
>>> directory that:
>>> 1. Has a dosdevices/ subdirectory and a system.reg file
>>>or
>>> 2. Has a .wine symlink pointing to a directory matching condition 1.
>>>or
>>> 3. Holds a .wine regular file whose content is the name of a directory 
>>> matching condition 1.
>>> - If a valid prefix (matches condition 1. above) is found use it for wine
>>> - Else use the default ~/.wine
>>>
>>> The extra checks 2. and 3. are to be able to handle the case when the 
> current 
>>> directory is on a path that is symlinked from inside the prefix. In 
> particular 
>>> test 3. is used when the files are on a FAT (or other symlink incapable) 
>>> partition. I have several wine prefixes whose "Program Files" is located on 
> a 
>>> much larger FAT32 partition shared with you know what.
>>>
>>> What do you think about this? Should I go on coding it?
>> I like the idea as it follows the DWIM (Do What I Mean) principle.
>> But the working directory shouldn't be the primary means to detect what
>> WINEPREFIX to use. That should be inherited first from the location of
>> the Win32 binary that is run. E.g. working on multiple regression bugs I
>> have used a separate git tree as well as a separate WINEPREFIX per bug.
>> My CWD was always the SRCDIR/BUILDIR thus useless to find the WINEPREFIX
>> but the path to the binary always had the WINEPREFIX informations in it:
>>   ./wine ~/wine/prefixes/21409/drive_c/Program\ Files/foo/foo.exe
>>
>> The "descend towards root" is used extensively by git so that one can
>> provide a good inspiration on how to do it, especially the corner cases.
>>
 > Right.
> 
> 
> A problem here would be to detect an executable name is present on the 
> command 
> line - and not only for wine but for other commands like winedbg and 
> wineconsole too.
> 
Not really a problem as those are just shell script wrappers that
translate, e.g.
  winedbg $program
to
  wine winedbg $program

So you can either handle that in the wrapper of the handful of scripts
that should do that or have a list of wine commands that need that
handling in the wine loader.

bye
michael

Re: Please remove / block user from bugzilla

[Wolfram Sang]

> For reference, there are two basic reasons for not referring to
> bugzilla when sending patches, in the commit log or otherwise. The
> first one is that patches should stand on their own. If the bug
> contains important information that's relevant to the patch, that
> should be included directly in the commit log. If it doesn't, well,
> the reference it just redundant. The other reason is that it's not
> unlikely that the commit log will outlive bugzilla. I.e., you can't
> depend on bugzilla always being there. That's essentially the same
> reason as for not including hyperlinks in comments, although at least
> the source code can easily be changed, while for the commit log that
> would be a serious pain.

I am confused. Following this list only, I so far did not notice someone
saying "don't tell the bug number" (ok, might be my fault), but a few
times asking the question "does this patch fix an actual" bug. Also,
SubmittingPatches says:

===

...
Include a description
...
If you're working on a bug in bugzilla, mention the bug number, and
consider filing a bug if none exists.

===

Maybe this is a misunderstanding of terminology? 'commit log' is for me
the combination of the single-line 'header' plus the 'description', which
can be multiple paragraphs. (and is usually dropped when patches are
imported to the official repo. Why is that BTW?) I would agree, that the
bug number should not be in the header, but having it as additional
information besides the regular description should not really hurt?

Kind regards,

   Wolfram

Re: RFC: Detecting the wine prefix

[Paul Chitescu]

On Friday 16 July 2010 12:32:33 pm Michael Stefaniuc wrote:
> Hello Paul,
> 
> Paul Chitescu wrote:
> > I would want to implement a change in where the wine prefix is assumed by 
> > default.
> > 
> > The current behavior of only considering WINEPREFIX is cumbersome and 
risky. 
> > Slip a finger, forget a letter and you end running a potential disastrous 
> > command in the wrong prefix. I ruined my main prefix by accidenatlly 
> > running 
> > "winetricks ie6" in it...
> > 
> > To fix that I use a wrapper script (unimaginatively named "win") that 
detects 
> > the proper prefix from the current directory and calls wine or other 
programs 
> > (winecfg, wineserver, winetricks, etc.) after setting WINEPREFIX. I am 
> > satisfied by this wrapper but has several disadvantages:
> > - You need to remember to run it instead of wine.
> > - You may paste a command from somewhere and forget to add "win" in front.
> > - Needs to be distributed.
> > 
> > The proposed solution is to incorporate the prefix detection logic in wine 
> > itself so no wrapper is needed.
> > 
> > The modified behavior would be like this:
> > - If WINEPREFIX is set obey that, user knows better. This is also required 
to 
> > create a new prefix.
> > - Starting from current working directory descend towards root looking for 
a 
> > directory that:
> > 1. Has a dosdevices/ subdirectory and a system.reg file
> >or
> > 2. Has a .wine symlink pointing to a directory matching condition 1.
> >or
> > 3. Holds a .wine regular file whose content is the name of a directory 
> > matching condition 1.
> > - If a valid prefix (matches condition 1. above) is found use it for wine
> > - Else use the default ~/.wine
> > 
> > The extra checks 2. and 3. are to be able to handle the case when the 
current 
> > directory is on a path that is symlinked from inside the prefix. In 
particular 
> > test 3. is used when the files are on a FAT (or other symlink incapable) 
> > partition. I have several wine prefixes whose "Program Files" is located on 
a 
> > much larger FAT32 partition shared with you know what.
> > 
> > What do you think about this? Should I go on coding it?
> I like the idea as it follows the DWIM (Do What I Mean) principle.
> But the working directory shouldn't be the primary means to detect what
> WINEPREFIX to use. That should be inherited first from the location of
> the Win32 binary that is run. E.g. working on multiple regression bugs I
> have used a separate git tree as well as a separate WINEPREFIX per bug.
> My CWD was always the SRCDIR/BUILDIR thus useless to find the WINEPREFIX
> but the path to the binary always had the WINEPREFIX informations in it:
>   ./wine ~/wine/prefixes/21409/drive_c/Program\ Files/foo/foo.exe
> 
> The "descend towards root" is used extensively by git so that one can
> provide a good inspiration on how to do it, especially the corner cases.
> 
> bye
>   michael

Right.


A problem here would be to detect an executable name is present on the command 
line - and not only for wine but for other commands like winedbg and 
wineconsole too.


Paul

Re: Please remove / block user from bugzilla

[Henri Verbeet]

On 16 July 2010 12:26, Luke Benstead  wrote:
> Probably not my place to wade in here, but that's not true, he didn't
> mention the commit log:
>
> "Be sure to mention in the post that it fixes
>
> http://bugs.winehq.org/show_bug.cgi?id=21233";
>
> I'm pretty sure he meant in the email when he emails wine-patches rather
> than in the commit log.
>
Sure. Practically speaking there's no real distinction between those
though, especially not if you're using "git send-email" (recommended)
to send your patches.

For reference, there are two basic reasons for not referring to
bugzilla when sending patches, in the commit log or otherwise. The
first one is that patches should stand on their own. If the bug
contains important information that's relevant to the patch, that
should be included directly in the commit log. If it doesn't, well,
the reference it just redundant. The other reason is that it's not
unlikely that the commit log will outlive bugzilla. I.e., you can't
depend on bugzilla always being there. That's essentially the same
reason as for not including hyperlinks in comments, although at least
the source code can easily be changed, while for the commit log that
would be a serious pain.

> I've got to say Henri, I think you are being a little unfair here. Yes,
> possibly Dan has given flawed advice in the past, but it's nothing that a
> private email or chat on IRC wouldn't have solved.
>
> Launching into a tirade against him publically isn't helping anything, all
> these instances are Dan trying to help out, quite obviously not to be
> "insidious" or to harm the project.
>
"Insidious" doesn't imply intention, nor did I claim intention
anywhere else. I'm sure Dan (like others) is just trying to help
people get their patches committed. But then, I don't think Vitaliy is
thinking "Let's have some fun being rude to people in bugzilla"
either. That doesn't change the fact that I *do* think both of those
hurt the project, or at best just irritate people. As for "tirade", I
think the discussion has been fairly civil so far, and I also think
wine-devel is the correct place for issues like these.

Cascading test failures

[Greg Geldorp]

Ideally, tests should be independent on each other. That's not the case right 
now. A clear example is msi:package, which often fails (on XP) with 1574 
errors, see http://test.winehq.org/data/tests/msi:package.html. For all the 
cases I've checked, when these 1574 errors occur the preceding msi:install test 
timed out (the reverse is not true, I see msi:install timeouts followed by a 
successful msi:package). My current theory is that the Windows Installer 
service gets confused when the msi:install test times out and is bluntly 
terminated by the winetest wrapper.

A possible solution might be to introduce a cleanup mechanism invoked by 
winetest.exe when it detects a timeout or crash in one of the test executables. 
After terminating the test executable, winetest.exe would then call 
"testname_test.exe --cleanup failed_test_name". The --cleanup argument could be 
handled by the tests main(), just like --list is handled by main(). A test 
executable would be able to register a cleanup function by setting a global 
function pointer to its cleanup function. In the case of msi_test.exe, that 
cleanup function could try to stop and restart the Windows Installer service.

Does this sound worthwhile to pursue? Any other/better ideas?

Ge.

Re: cmd: Fix cmd's mishandling of quote-enclosed command strings

[Jacek Caban]

 On 7/16/10 1:16 PM, Wilbert Ho wrote:

cmd mishandles quote-enclosed command strings because the leading
quote is included in the string when wine searches through the
built-in commands (dir is a builtin, but "dir is not).

$ ./wine cmd.exe /c "dir README"
wine: cannot find L"C:\\windows\\system32\\dir.exe"
File not found

To fix this, offset the string being compared to the array of builtins
by the number of leading quotes before doing the comparison.



+dir /b Makefile test_builtins.cmd
+dir /b Makefile
+dir /b test_builtins.cmd
+dir /b "Makefile"
+dir /b "test_builtins.cmd"
+"dir /b Makefile"
+"dir /b test_builtins.cmd"

You can't assume that these files are present when running the test. If you 
need additional files for test, you have to create them in runtime. In this 
particular case it looks like you could choose other builtin command for test 
that doesn't require any additional file.

Jacek

Re: cmd: Fix cmd's mishandling of quote-enclosed command strings

[testbot]

Hi,

While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=3340

Your paranoid android.


=== WNT4WSSP6 (32 bit) ===
batch.c:188: Test failed: unexpected end of output in line 46, expected 0x4d

=== W2KPROSP4 (32 bit) ===
batch.c:188: Test failed: unexpected end of output in line 46, expected 0x4d

=== WXPPROSP3 (32 bit) ===
batch.c:188: Test failed: unexpected end of output in line 46, expected 0x4d

=== W2K3R2SESP2 (32 bit) ===
batch.c:188: Test failed: unexpected end of output in line 46, expected 0x4d

=== WVISTAADM (32 bit) ===
batch.c:188: Test failed: unexpected end of output in line 46, expected 0x4d

=== W2K8SE (32 bit) ===
batch.c:188: Test failed: unexpected end of output in line 46, expected 0x4d

=== W7PRO (32 bit) ===
batch.c:188: Test failed: unexpected end of output in line 46, expected 0x4d

=== W7PROX64 (32 bit) ===
batch.c:188: Test failed: unexpected end of output in line 46, expected 0x4d

=== W7PROX64 (64 bit) ===
batch.c:188: Test failed: unexpected end of output in line 46, expected 0x4d

Re: Please remove / block user from bugzilla

[Luke Benstead]

> > - Misha; I told him tests were ok to submit during a code freeze; this is
> true,
> > given that Alexandre accepted tests as last as last Friday.  I should
> have
> > told him that tests which add stubs probably aren't ok, but he learned
> > that as soon as he submitted.
> > http://www.winehq.org/pipermail/wine-devel/2010-June/084632.html
> > so that seems fine.
> >
> From the look of things Misha will be ok, but I imagine he would have
> been anyway.
>
> But there are also cases like e.g.
> http://bugs.winehq.org/show_bug.cgi?id=21233#c8 where you completely
> miss the real issues in the patch, and instead recommend referring to
> a bug number in the commit log,
>

Probably not my place to wade in here, but that's not true, he didn't
mention the commit log:

"Be sure to mention in the post that it fixes

http://bugs.winehq.org/show_bug.cgi?id=21233";



I'm pretty sure he meant in the email when he emails wine-patches rather
than in the commit log.

I've got to say Henri, I think you are being a little unfair here. Yes,
possibly Dan has given flawed advice in the past, but it's nothing that a
private email or chat on IRC wouldn't have solved.

Launching into a tirade against him publically isn't helping anything, all
these instances are Dan trying to help out, quite obviously not to be
"insidious" or to harm the project.

Luke.

Re: RFC: Detecting the wine prefix

[Scott Ritchie]

On 07/16/2010 02:32 AM, Michael Stefaniuc wrote:
> Hello Paul,
> 
> Paul Chitescu wrote:
>> I would want to implement a change in where the wine prefix is assumed by 
>> default.
>>
>> The current behavior of only considering WINEPREFIX is cumbersome and risky. 
>> Slip a finger, forget a letter and you end running a potential disastrous 
>> command in the wrong prefix. I ruined my main prefix by accidenatlly running 
>> "winetricks ie6" in it...
>>
>> To fix that I use a wrapper script (unimaginatively named "win") that 
>> detects 
>> the proper prefix from the current directory and calls wine or other 
>> programs 
>> (winecfg, wineserver, winetricks, etc.) after setting WINEPREFIX. I am 
>> satisfied by this wrapper but has several disadvantages:
>> - You need to remember to run it instead of wine.
>> - You may paste a command from somewhere and forget to add "win" in front.
>> - Needs to be distributed.
>>
>> The proposed solution is to incorporate the prefix detection logic in wine 
>> itself so no wrapper is needed.
>>
>> The modified behavior would be like this:
>> - If WINEPREFIX is set obey that, user knows better. This is also required 
>> to 
>> create a new prefix.
>> - Starting from current working directory descend towards root looking for a 
>> directory that:
>>  1. Has a dosdevices/ subdirectory and a system.reg file
>>or
>>  2. Has a .wine symlink pointing to a directory matching condition 1.
>>or
>>  3. Holds a .wine regular file whose content is the name of a directory 
>> matching condition 1.
>> - If a valid prefix (matches condition 1. above) is found use it for wine
>> - Else use the default ~/.wine
>>
>> The extra checks 2. and 3. are to be able to handle the case when the 
>> current 
>> directory is on a path that is symlinked from inside the prefix. In 
>> particular 
>> test 3. is used when the files are on a FAT (or other symlink incapable) 
>> partition. I have several wine prefixes whose "Program Files" is located on 
>> a 
>> much larger FAT32 partition shared with you know what.
>>
>> What do you think about this? Should I go on coding it?
> I like the idea as it follows the DWIM (Do What I Mean) principle.
> But the working directory shouldn't be the primary means to detect what
> WINEPREFIX to use. That should be inherited first from the location of
> the Win32 binary that is run. E.g. working on multiple regression bugs I
> have used a separate git tree as well as a separate WINEPREFIX per bug.
> My CWD was always the SRCDIR/BUILDIR thus useless to find the WINEPREFIX
> but the path to the binary always had the WINEPREFIX informations in it:
>   ./wine ~/wine/prefixes/21409/drive_c/Program\ Files/foo/foo.exe
> 
> The "descend towards root" is used extensively by git so that one can
> provide a good inspiration on how to do it, especially the corner cases.
> 

This seems the more sensible approach, particularly in the case of old
.desktop entries that don't, to my knowledge, set the wine prefix.

Thanks,
Scott Ritchie

Re: Please remove / block user from bugzilla

[Henri Verbeet]

On 15 July 2010 17:45, Dan Kegel  wrote:
> I'm listening.  Can you give some examples of problems I've caused?
> Candidates include
>
> - the FIXME_ONCE guy; I think you and I are giving him the same advice;
> http://www.winehq.org/pipermail/wine-devel/2010-July/085069.html
> so that seems fine.
>
As you noted in your other mail, the problem with what you're telling
him is mostly that you're telling him to work on a bug like 15435 at
all. You might as well have told him to work on "fixing" coding style
or naming conventions.

> - Misha; I told him tests were ok to submit during a code freeze; this is 
> true,
> given that Alexandre accepted tests as last as last Friday.  I should have
> told him that tests which add stubs probably aren't ok, but he learned
> that as soon as he submitted.
> http://www.winehq.org/pipermail/wine-devel/2010-June/084632.html
> so that seems fine.
>
From the look of things Misha will be ok, but I imagine he would have
been anyway.

But there are also cases like e.g.
http://bugs.winehq.org/show_bug.cgi?id=21233#c8 where you completely
miss the real issues in the patch, and instead recommend referring to
a bug number in the commit log, if not directly putting in a link.
Alexandre has told people several times in the past not to do that,
and I believe even to you yourself. Now it turns out Mikko didn't do
that, but listening to that advice would have hurt that patch more
than it would have helped.

This is of course not a new thing, you've been doing that for at least
as long as I've been contributing patches, but the difference is that
previously you didn't give a damn about Direct3D or D3DX, focusing on
real, useful applications and associated APIs instead. That means this
was mostly Alexandre's problem, and whoever happened to be the
relevant module maintainer, if any. Alexandre and most other Wine
developers are much nicer people than me, and Alexandre enjoys
rejecting patches anyway. But *I* care about Wine's Direct3D, so I'm
saying something about it.

> Would you really prefer I retire from Wine?
I haven't given that much thought, mostly because I don't think it's
an option that has a realistic chance of happening, either way. More
importantly, the "really" there is misleading, I didn't mention or ask
for that. What I *would* like to ask is that you don't misrepresent
yourself as somehow speaking for the Wine project, or being an
experienced Wine developer. And just so it's clear, it's perfectly
fine that not everyone is an active developer. Austin and Wylda for
example do lots of useful work in bugzilla, without primarily being
developers. But if you're giving people development advice, or are
trying to influence development direction, you'd better make sure that
you actually know what you're talking about. (And no, you're certainly
not the only person giving questionable development advice either. I'm
mostly pointing this out because you started pointing fingers.)

Re: RFC: Detecting the wine prefix

[Michael Stefaniuc]

Hello Paul,

Paul Chitescu wrote:
> I would want to implement a change in where the wine prefix is assumed by 
> default.
> 
> The current behavior of only considering WINEPREFIX is cumbersome and risky. 
> Slip a finger, forget a letter and you end running a potential disastrous 
> command in the wrong prefix. I ruined my main prefix by accidenatlly running 
> "winetricks ie6" in it...
> 
> To fix that I use a wrapper script (unimaginatively named "win") that detects 
> the proper prefix from the current directory and calls wine or other programs 
> (winecfg, wineserver, winetricks, etc.) after setting WINEPREFIX. I am 
> satisfied by this wrapper but has several disadvantages:
> - You need to remember to run it instead of wine.
> - You may paste a command from somewhere and forget to add "win" in front.
> - Needs to be distributed.
> 
> The proposed solution is to incorporate the prefix detection logic in wine 
> itself so no wrapper is needed.
> 
> The modified behavior would be like this:
> - If WINEPREFIX is set obey that, user knows better. This is also required to 
> create a new prefix.
> - Starting from current working directory descend towards root looking for a 
> directory that:
>   1. Has a dosdevices/ subdirectory and a system.reg file
>or
>   2. Has a .wine symlink pointing to a directory matching condition 1.
>or
>   3. Holds a .wine regular file whose content is the name of a directory 
> matching condition 1.
> - If a valid prefix (matches condition 1. above) is found use it for wine
> - Else use the default ~/.wine
> 
> The extra checks 2. and 3. are to be able to handle the case when the current 
> directory is on a path that is symlinked from inside the prefix. In 
> particular 
> test 3. is used when the files are on a FAT (or other symlink incapable) 
> partition. I have several wine prefixes whose "Program Files" is located on a 
> much larger FAT32 partition shared with you know what.
> 
> What do you think about this? Should I go on coding it?
I like the idea as it follows the DWIM (Do What I Mean) principle.
But the working directory shouldn't be the primary means to detect what
WINEPREFIX to use. That should be inherited first from the location of
the Win32 binary that is run. E.g. working on multiple regression bugs I
have used a separate git tree as well as a separate WINEPREFIX per bug.
My CWD was always the SRCDIR/BUILDIR thus useless to find the WINEPREFIX
but the path to the binary always had the WINEPREFIX informations in it:
  ./wine ~/wine/prefixes/21409/drive_c/Program\ Files/foo/foo.exe

The "descend towards root" is used extensively by git so that one can
provide a good inspiration on how to do it, especially the corner cases.

bye
michael

RFC: Detecting the wine prefix

[Paul Chitescu]

Hi!

I would want to implement a change in where the wine prefix is assumed by 
default.

The current behavior of only considering WINEPREFIX is cumbersome and risky. 
Slip a finger, forget a letter and you end running a potential disastrous 
command in the wrong prefix. I ruined my main prefix by accidenatlly running 
"winetricks ie6" in it...

To fix that I use a wrapper script (unimaginatively named "win") that detects 
the proper prefix from the current directory and calls wine or other programs 
(winecfg, wineserver, winetricks, etc.) after setting WINEPREFIX. I am 
satisfied by this wrapper but has several disadvantages:
- You need to remember to run it instead of wine.
- You may paste a command from somewhere and forget to add "win" in front.
- Needs to be distributed.

The proposed solution is to incorporate the prefix detection logic in wine 
itself so no wrapper is needed.

The modified behavior would be like this:
- If WINEPREFIX is set obey that, user knows better. This is also required to 
create a new prefix.
- Starting from current working directory descend towards root looking for a 
directory that:
1. Has a dosdevices/ subdirectory and a system.reg file
   or
2. Has a .wine symlink pointing to a directory matching condition 1.
   or
3. Holds a .wine regular file whose content is the name of a directory 
matching condition 1.
- If a valid prefix (matches condition 1. above) is found use it for wine
- Else use the default ~/.wine

The extra checks 2. and 3. are to be able to handle the case when the current 
directory is on a path that is symlinked from inside the prefix. In particular 
test 3. is used when the files are on a FAT (or other symlink incapable) 
partition. I have several wine prefixes whose "Program Files" is located on a 
much larger FAT32 partition shared with you know what.

What do you think about this? Should I go on coding it?

Paul Chitescu


win
Description: application/shellscript

Re: Please remove / block user from bugzilla

[Michael Stefaniuc]

Austin English wrote:
> On Thu, Jul 15, 2010 at 9:30 PM, James McKenzie
>  wrote:
>> Rosanne DiMesio wrote:
>>> On Thu, 15 Jul 2010 17:08:30 +0200
>>> Gert van den Berg  wrote:
>>>
>>>
 On Thu, Jul 15, 2010 at 16:23, James Mckenzie
  wrote:

> Rosanne and you have a good point, but I would restrict it the limit to
> four lines.  You should be able to describe a valid bug in that space.
>  Anything more, and it becomes an attachement.
>
 4 lines is horribly short... Especially for posting instructions to
 reproduce problems, an overview of your system configuration, etc...


>>> I agree. I've often exceeded 4 lines in comments.
>>>
>>>
>> I see your point.  However, should it not be sufficient to state a problem
>> in ten lines or less?  This prevents pasting lengthy logs, statements, etc.
>> in bugzilla?  I'll go with that number then.
> 
> I've often seen 10 exceeded as well. Like earlier discussed, a regex
> for fixme/err/etc. would be more useful.
What Austin says. E.g. a git bisect result is at minimum 9 lines long,
with more than 1 line of changelog it gets longer. And we do want those
pasted into the comment and not attached.

bye
michael