January 2011 - Wine-Devel - list.winehq.org

RE: Test timeouts

by Greg Geldorp

> From: Alexandre Julliard > > I think it would be better to make the test detect such an environment > and have it skip some things if it finds that it's taking too long. I guess that's what we currently have... In effect, if it takes too long, the final tests are skipped. I was hoping we could do better than that. Greg.

Jan. 6, 2011

Re: Test timeouts

by Alexandre Julliard

Greg Geldorp <ggeldorp(a)vmware.com> writes: > Although the number of timeouts in msi tests has dropped considerably after > Hans decided to do something about them, they're unfortunately not > completely gone. It seems that the remaining timeouts have a strong > dependency on the environment. It's possible to tweak the environment > (disable system restore points, for TestBot I found it makes a difference > on which physical disk the virtual disk files are located) but the goal > should be to have the tests run consistently on whatever the environment > happens to be. Perhaps it's time to accept that some tests in some > environments can simply take longer than the current winetest.exe timeout > value of 2 minutes. I think it would be better to make the test detect such an environment and have it skip some things if it finds that it's taking too long. IOW it would be the responsibility of the test itself to keep its run time under 2 minutes. -- Alexandre Julliard julliard(a)winehq.org

Jan. 6, 2011

Re: [PATCH 2/2] shell32: Don't fill SHITEMID data with random values if file doesn't exist

by Alexandre Julliard

Piotr Caban <piotr(a)codeweavers.com> writes: > @@ -538,6 +538,8 @@ static char* UNIXFS_build_shitemid(char *pszUnixPath, LPBC pbc, void *pIDL) { > if (stat(pszUnixPath, &fileStat)){ > if (must_exist || errno != ENOENT) > return NULL; > + > + memset(&fileStat, 0, sizeof(struct stat)); That may not be random, but it's still wrong values. It seems to me that this is what the IFileSystemBindData should be used for. -- Alexandre Julliard julliard(a)winehq.org

Jan. 6, 2011

Re: New winetricks 20110105: improved download error recovery, added first-run optin dialog. New winetricks 20110105-alpha: menu divided into categories, added 35 games

by Reece Dunn

On 5 January 2011 22:45, Dan Kegel <dank(a)kegel.com> wrote: > Another month, another Winetricks - or, rather, two new Winetricks. Very nice! Here is some games information you may find useful: == Big Fish Games client winetricks -- gecko ie8 * gecko -- suppress the gecko download UI, not strictly necessary * ie8 -- I find that with newer versions of wine (since the IUri support?) IE8 works well for the client; for older versions of wine, ie6 works. PROGRAM = c:\Program Files\bfgclient\bfgclient.exe == Bejeweled 3 (PopCap Games) winetricks -- gecko msls31 riched30 * gecko -- suppress the gecko download UI, not strictly necessary * msls31 -- suppress a "dll not found" error using native riched30; works without this, you just get an annoying dialog box :) * riched30 -- the popcap game installer hang when viewing the license agreement on recent wine versions (or recent popcap installers); this prevents the hang [http://bugs.winehq.org/show_bug.cgi?id=25455] PROGRAM = c:\Program Files\PopCap Games\Bejeweled 3\Bejeweled3.exe NOTE: Bejeweled 3 crashes on exit (D3D reference error?) and then hangs (audio thread deadlock?), but is otherwise very playable :). - Reece

Jan. 5, 2011

New winetricks 20110105: improved download error recovery, added first-run optin dialog. New winetricks 20110105-alpha: menu divided into categories, added 35 games

by Dan Kegel

Another month, another Winetricks - or, rather, two new Winetricks. New version 20110105 has only two notable changes: 1. it will retry a corrupt download for you (this should get rid of most cryptic warnings about needing to rename a file and retry), 2. a first run dialog now asks whether you'd like to help winetricks development by reporting usage stats. You should only see this dialog once (and only if you're using the gui, and only if you're using zenity). This has been very helpful already, as people have been running it from svn. Please let me know what you think of it. Online as always at http://kegel.com/wine/winetricks Experimental new version 20110105-alpha has a few further changes: 3. The menu is now broken up by category; there's now a top-level menu which gives you a choice of category (dll, font, app, or setting). This ought to make the menu a little less overwhelming. Let me know what you think of the new menu navigation. 4. There's now a progress dialog during downloads in gui mode. 5. It should work better when the user has removed the Z: drive. 6. It's been refactored to make adding new verbs much easier (you no longer have to edit the script in multiple places to add a verb, and you can even put verbs in external files). 7. Added 35 games. (A bunch more remain to be ported from wisotool.) 8. Removed (or, rather, haven't ported yet) a number of less-common verbs. The statistics gathered by the new version will tell us which of the remaining verbs to port first. The experimental version is only at http://kegel.com/wine/winetricks-alpha SVN and bug tracker are online at http://winezeug.googlecode.com Changes in version 20110105: Dan Kegel: - remove old synonym dotnet2 for dotnet20 - mpc: remove broken call to append_path - handle 'winetricks win31 vista' properly - make dotnet20sp2 warn that it's broken. Don't list in menu. - w_download: don't redownload if no expected checksum given. Also remove == typo from r2207. - don't declare checksum error unless, y'know, there was a checsum error - as favor for etersoft, avoid referring directly to zenity/kdialog/xmssage to avoid pulling them all in as dependencies when building a package - automatically retry download once if cached file has wrong checksum - ie8: avoid writing to / (just like ie7 fix). Don't bother running ie8 when finished; point user to workaround instead. Also move a verb that got sandwiched between ie6 and ie7. - ie7: when / is writable as on macosx, move z: out of the way during ie7 install to avoid scribbling temporary files in /. Had to run with WINEDEBUG=warn+heap to avoid memory bugs in setupapi? - when reporting usage, also report version. - in zenity gui case, ask user on first run whether to opt in to usage reporting. - on MacOS X, put cache in /home/dank/Library/Caches - delete msxml6.dll before running installer. Fixes bug 211. - tahoma: don't download to top of cache - finish renaming WINETRICKS_UNIXQUIET to W_UNATTENDED_DASH_Q - make cabextract quiet Austin English: - add win31 verb (needed internally by ole2)

Jan. 5, 2011

Re: "N" shows up as missing on the translations status website

by Paul Vriens

On 01/05/2011 09:44 PM, Sven Baars wrote: > Hey all, > > since today, the "N" string shows up as missing on > http://source.winehq.org/transl/ even though it's there in the po file. > This happened for both xcopy and cmd. In the po file it says > > #: cmd.rc:257 xcopy.rc:41 > msgctxt "No key" > msgid "N" > msgstr "N" > > so this is probably because the string is present in both cmd and xcopy. > Just thought I'd let you know. > > Sven > > It's not the duplicate string. See en_US.po: 546 #: cmd.rc:256 xcopy.rc:40 547 msgctxt "Yes key" 548 msgid "Y" 549 msgstr "Y" 550 551 #: cmd.rc:257 xcopy.rc:41 552 msgctxt "No key" 553 msgid "N" 554 msgstr "" So for some reason the "No key" is not picked up in the English po file. -- Cheers, Paul.

Jan. 5, 2011

"N" shows up as missing on the translations status website

by Sven Baars

Hey all, since today, the "N" string shows up as missing on http://source.winehq.org/transl/ even though it's there in the po file. This happened for both xcopy and cmd. In the po file it says #: cmd.rc:257 xcopy.rc:41 msgctxt "No key" msgid "N" msgstr "N" so this is probably because the string is present in both cmd and xcopy. Just thought I'd let you know. Sven

Jan. 5, 2011

Re: / is writable on mac... leading to lots of awkward msi droppings?

by Steve Brown

On Wed, 5 Jan 2011, Charles Davis wrote: > On 1/5/11 1:18 AM, Charles Davis wrote: >> On 1/5/11 12:31 AM, Dan Kegel wrote: >>> Quentin Paris informs me that the root directory is >>> user-writable on MacOSX (shudder), which means >>> our beloved z: mapping leads to lots of garbage >>> directories named e.g. /fd91216cc2ce81eb2ce16a058619 >>> after running msi installers. >> Now where would he get that idea from? >> <<snip>> > > But why is MSI putting anything in Z:\ at all? I'm guessing those > folders really belong in the temp directory; if the temp dir is Z:\, > then we really need to fix that. No program should be using the root > directory as a dumping ground :). It's not just Macs -- it seems to be a global .msi issue. I'm no Windows guru, but I find several of those directories on Windows machines I administer as well (in C:\). I've never taken the time to dig deeper, but they seem to be left over from _failed_ installs. As far as permissions to write in the root directory, an installer has to be running with administrator rights to be mucking around in system directories no matter how it gets those rights -- directory permissions, sudo, UACs, whatever. Steve Brown sbrown7(a)umbc.edu

Jan. 5, 2011

Re: Test timeouts

by Hans Leidekker

On Wed, 2011-01-05 at 14:01 +0100, wylda(a)volny.cz wrote: > s there is an activity to make (not only) WylBOT green and happy > ;c) i can add more info, based on WyldBOT's install documentation i > looked right now and found there: > > * Turn off system restore > > So longer time out may not help my BOTs, as it's already turned off > on all of the BOTs and the HW isn't so weak/slow, i guess... Greg was talking about timeouts caused by msi tests simply taking too long to run on some configurations. This problem can be addressed by increasing timeouts. There are other sources of timeouts, such as dialogs popping up, which cannot be fixed that way. Please report those directly to me or create a bug report.

Jan. 5, 2011

Re: windowscodecs: Use Mac OS X native ICNS support, not libicns.

by Ken Thomases

On Jan 5, 2011, at 5:45 AM, Damjan Jovanovic wrote: > On Wed, Jan 5, 2011 at 1:31 PM, Ken Thomases <ken(a)codeweavers.com> wrote: >> OK. Do you think my patch should be held up until you find an approach that works for both? > > The patch seems fine (doesn't seem to regress anything), but aren't > ICNS files invisible anyway with winemenubuilder writing .desktop > files which MacOS can't use? Well, yes, the ICNS files are not currently used. Still, things get improved bit by bit. :) Besides being referenced by .desktop files which aren't used, the ICNS files are written to /tmp, as things stand. -Ken

Jan. 5, 2011