October 2007 - Wine-Devel - list.winehq.org

any clues as to what's wrong with patches (system palette entries)?

by Alexander Dorofeyev

Hello. I've sent a patch that changes X11DRV_GetSystemPaletteEntries behavior and a test something like a week ago. I guess they fell into that so called not obviously correct category (or maybe not correct at all one). I'll appreciate any comments or suggestions on possible improvements. Thanks. > On Windows, GetSystemPaletteEntries() call in non-palettized graphics > modes returns back reserved colors from the default palette. This patch > modifies winex11.drv's X11DRV_GetSystemPaletteEntries() function to > imitate this behavior instead of just returning 0. This partially solves > bug #201 (helps igowin.exe transparency problem, untested with another app).

Oct. 25, 2007

Wine Gecko packaging

by Jacek Caban

Hello, As you probably have noticed, downloading Gecko on first use confuses users. Now, with last week patches, there is an other way to do it, transparent for users. MSHTML code looks for cab file in $data_dir/gecko (that is usually /usr/share/wine/gecko). Alternatively, if you run Wine from build dir, it looks for $build_dir/../gecko. Wine checks it both in wineprefixcreate and, if Gecko is not installed, on first usage. It means that if you download wine_gecko-0.1.0.cab from SourceForge and put it in the right place, you will no longer have to care about installing Gecko. Now, it's time to consider Linux packages to simplify its use. In Gentoo it may be a separate USE flag, but for other distributions that don't support such things, we'll need a separate package. Such package will need only one file placed in the right place, so it should be easy to do and maintain (I don't expect versions to change often). Are Wine packagers interested in creating Gecko packages? Thanks, Jacek

Oct. 24, 2007

Git Page on website

by Alistair Leslie-Hughes

Hi, On the git web page, the commands to run to perform "Cleaning up your existing tree" and "Staying Up-To-Date" have been merge to one line. Best Regards Alistair Leslie-Hughes

Oct. 24, 2007

Re: AppDB: login

by Alexander Nicolaysen Sørnes

On Wednesday 24 October 2007 23:58:51 speedator(a)gmx.de wrote: > Hi, > would be great to have a longer period to stay logged in. > A setting under preference for the period seems a good solution, > Btw: What is the status of appdb/bugzilla(wiki?)-account-fusion? > > Bye, > Julian The login period used to be longer, I don't know why that was changed as it was before my time. No one is working on the account integration (or they are doing it secretly). It would be a great improvement but right now I think it is more beneficial to improve the AppDB itself. Alexander N. Sørnes

Oct. 24, 2007

AppDB: login

by speedator＠gmx.de

Hi, would be great to have a longer period to stay logged in. A setting under preference for the period seems a good solution, Btw: What is the status of appdb/bugzilla(wiki?)-account-fusion? Bye, Julian

Oct. 24, 2007

Re: How long should 'make test' take?

by Hans Leidekker

On Wednesday 24 October 2007 20:57:08 Hans Leidekker wrote: > I count 20 InternetConnect calls in ftp.c so with your 20 second > quota we have about one second per connection. On my Windows VM > the test takes about 13 seconds so I think we should be able to > bring it down to below 20 seconds. I'll look into it. Switching to another server (vsftpd) the test finishes under 5 seconds. What stands out from Wireshark traces is that we never get a FIN packet from winehq. This leaves the connections in CLOSE_WAIT state, meaning long timeouts. vsftpd responds with RST to our FIN, ACK. So fast termination, but still not the way it should be. I need to find out why the ftp servers don't like our behaviour. Hmm, could it be as simple as not saying 'bye' to close the session? -Hans

Oct. 24, 2007

Re: How long should 'make test' take?

by Juan Lang

> Note that the http test also makes several connections to winehq > but it doesn't show up in your list. Okay, but those fail immediately for me, so they don't take any time. (Yes, I should log a bug. Sorry.) --Juan

Oct. 24, 2007

Re: How long should 'make test' take?

by Hans Leidekker

On Wednesday 24 October 2007 20:17:19 Dan Kegel wrote: > Here are all the tests that take more than five seconds: > > 5.407s advapi32_test.exe.so service.c > 6.010s kernel32_test.exe.so console.c > 6.252s user32_test.exe.so msg.c > 9.657s kernel32_test.exe.so process.c > 12.053s winmm_test.exe.so timer.c > 14.080s shell32_test.exe.so shlexec.c > 17.760s msi_test.exe.so install.c > 24.018s winmm_test.exe.so wave.c > 648.722s wininet_test.exe.so ftp.c > > Other than wininet's ftp test and maybe winmm's wave test, > the overall time seems reasonable. > > IMHO we should disable the ftp test until its runtime can > be brought down below 20 seconds. It's just too slow, > and too dependent on stuff not under Wine's control > (e.g. one's internet connection). Note that the http test also makes several connections to winehq but it doesn't show up in your list. And we can and do skip tests gracefully when a connection cannot be made. The ftp test used to rely on an *incoming* connection, so failure could only be handled with relatively long timeouts. I count 20 InternetConnect calls in ftp.c so with your 20 second quota we have about one second per connection. On my Windows VM the test takes about 13 seconds so I think we should be able to bring it down to below 20 seconds. I'll look into it. -Hans

Oct. 24, 2007

Re: How long should 'make test' take?

by Juan Lang

> IMHO we should disable the ftp test until its runtime can > be brought down below 20 seconds. It's just too slow, > and too dependent on stuff not under Wine's control > (e.g. one's internet connection). Agreed, it takes too long to bother with here as well, and I'm also suffering with a really fast connection on the west coast. --Juan

Oct. 24, 2007

How long should 'make test' take?

by Dan Kegel

Here are all the tests that take more than five seconds: 5.407s advapi32_test.exe.so service.c 6.010s kernel32_test.exe.so console.c 6.252s user32_test.exe.so msg.c 9.657s kernel32_test.exe.so process.c 12.053s winmm_test.exe.so timer.c 14.080s shell32_test.exe.so shlexec.c 17.760s msi_test.exe.so install.c 24.018s winmm_test.exe.so wave.c 648.722s wininet_test.exe.so ftp.c Other than wininet's ftp test and maybe winmm's wave test, the overall time seems reasonable. IMHO we should disable the ftp test until its runtime can be brought down below 20 seconds. It's just too slow, and too dependent on stuff not under Wine's control (e.g. one's internet connection). And I have a really fast internet connection... it's just that my ping time to winehq is 80ms. I bet the ftp test runs fast in Minneapolis... - Dan

Oct. 24, 2007