Re: change wording of ok()-messages in winspool-tests?
Julian Rüger j...@gmx.net writes: Hi Francois and list, [/nitpick-mode on] I'm preparing a patch to fix typos/spelling/grammar in dlls/winspool.drv/tests/info.c, where I stumbled across repeated messages like ok( !retval, function result wrong! False expected\n); or ok( size == exact, Parameter size wrong! %d expected got %d\n, exact, size); Do you think it's worth changing these? (I think Wrong function result: 'false' expected\n, and Wrong parameter size: expected %d, got %d\n would be better) Do we have guidelines for strings like these? For example: start with a captial letter, no punctuation at the end... What tests have good style I can use as reference? Best regards, Julian PS: Am I bike shedding here? Does anyone care about stuff like this? Test failure messages are not supposed to be seen, if they are seen it's a bug. So it's not worth spending effort making them look nice or consistent. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH 2/2] opengl32: Check for valid context in wglGetProcAddress
On Sunday, June 24, 2012 10:42:11 PM Roderick Colenbrander wrote: @@ -797,7 +797,7 @@ static void test_getprocaddress(HDC hdc) /* Temporarily disable the context, so we can see that we can't retrieve functions now. */ wglMakeCurrent(hdc, NULL); func = wglGetProcAddress(glActiveTextureARB); -todo_wine ok(func == NULL, Function lookup without a context passed, expected a failure; last error %#x\n, GetLastError()); +ok(func == NULL, Function lookup without a context passed, expected a failure; last error %#x\n, GetLastError()); wglMakeCurrent(hdc, ctx); } Does this apply to all functions, or just the ones MS's DLL doesn't implement? I could imagine wlgGetProcAddress still returning functions that are in opengl32.dll without worrying about the driver.
Re: [3/5] gdiplus: Implement GdipGetPropertyIdList.
On 6/25/2012 14:30, Dmitry Timoshkov wrote: + +return hr == S_OK ? Ok : hresult_to_status(hr); } No need for special case for S_OK here.
Re: [PATCH 2/2] opengl32: Check for valid context in wglGetProcAddress
On Mon, Jun 25, 2012 at 1:22 AM, Chris Robinson chris.k...@gmail.com wrote: On Sunday, June 24, 2012 10:42:11 PM Roderick Colenbrander wrote: @@ -797,7 +797,7 @@ static void test_getprocaddress(HDC hdc) /* Temporarily disable the context, so we can see that we can't retrieve functions now. */ wglMakeCurrent(hdc, NULL); func = wglGetProcAddress(glActiveTextureARB); - todo_wine ok(func == NULL, Function lookup without a context passed, expected a failure; last error %#x\n, GetLastError()); + ok(func == NULL, Function lookup without a context passed, expected a failure; last error %#x\n, GetLastError()); wglMakeCurrent(hdc, ctx); } Does this apply to all functions, or just the ones MS's DLL doesn't implement? I could imagine wlgGetProcAddress still returning functions that are in opengl32.dll without worrying about the driver. From what I remember wglGetProcAddress doesn't return GL1.1 functions which are in opengl32.dll. I can easily add a test for this. Roderick
Is it safe yet for developers to upgrade to Ubuntu 12.04?
I know that for a while there were some packaging problems that meant that upgrading to 12.04 made compiling 32-bit Wine on a 64-bit PC extremely difficult. Is this still the case? I'd like to upgrade to the new OS version, but I'm not willing to sacrifice the ability to build Wine in order to do so. Thanks in advance! Erich Hoover ehoo...@mines.edu
Re: Is it safe yet for developers to upgrade to Ubuntu 12.04?
Am 25.06.2012 19:29, schrieb Erich E. Hoover: I know that for a while there were some packaging problems that meant that upgrading to 12.04 made compiling 32-bit Wine on a 64-bit PC extremely difficult. Is this still the case? I'd like to upgrade to the new OS version, but I'm not willing to sacrifice the ability to build Wine in order to do so. Thanks in advance! You should wait until Scott Ritchie gives green light here. I blindly upgraded and it was a mess, so don't hurt yourself. I'm now back at 11.04 and that's pretty comfort, i also really dislike every non-gnome2 desktop, most likely i'll switch to cinnamon desktop at some point. -- Best Regards, André Hentschel
Re: Is it safe yet for developers to upgrade to Ubuntu 12.04?
I know that for a while there were some packaging problems that meant that upgrading to 12.04 made compiling 32-bit Wine on a 64-bit PC extremely difficult. I was able to patch and build 32-bit wine on 64-bit 12.04, using a debootstrap chroot: https://help.ubuntu.com/community/DebootstrapChroot/ Setting up the chroot took a couple of minutes, and was trivial to do. However, there appears to be a bug in wine or ubuntu which prevents SW:TOR from forking the display process, so I can't actually use wine on 12.04 to play the game I want. But building custom wine works fine. cheers, Joey
Re: Is it safe yet for developers to upgrade to Ubuntu 12.04?
André Hentschel wrote: Am 25.06.2012 19:29, schrieb Erich E. Hoover: You should wait until Scott Ritchie gives green light here. I blindly upgraded and it was a mess, so don't hurt yourself. I'm now back at 11.04 and that's pretty comfort, i also really dislike every non-gnome2 desktop, most likely i'll switch to cinnamon desktop at some point. Ubuntu 12.04 is still buggy in general (but not crashy!). Most of the reported bugs have not been fixed yet. I would also recommend waiting at least for 12.04.1 before considering it again.
Building WoW64 packages
Hi, after the effort on the Debian wine packages has progressed to a point where it's likely that we'll release wheezy with a stable wine version that is not completely out of date, I'd like to take things a step further. I recently spent some time looking at ways how we could build Debian packages for a shared WoW64 setup similar to what is described in http://wiki.winehq.org/Wine64. We will have to use separate build environments because having 32-bit and 64-bit -dev packages installed at the same time is not possible. Installing a 64-bit package that contains the build tools into a 32-bit environment should be possible, though. From looking at the build system, things happen in a different way when I run configure for the 32-bit components with --wine64=...: 1. Manpages are not installed (WOW64_DISABLE) 2. --disable-fonts is implied 3. --disable-server is implied, so wineserver is not built. (The 64-bit wineserver is used instead, right?) 4. --disable-tools is implied because the existing build tools are being used. Did I miss anything? Leaving parts out is easy to understand, but how do the build tools that have been built for the x86_64 architecture affect the 32-bit components that are being built with them? Are different paths encoded into libwine? Cheers, -Hilko
Re: Building WoW64 packages
On Mon, Jun 25, 2012 at 11:21:33PM +0200, Hilko Bengen wrote: Hi, after the effort on the Debian wine packages has progressed to a point where it's likely that we'll release wheezy with a stable wine version that is not completely out of date, I'd like to take things a step further. I recently spent some time looking at ways how we could build Debian packages for a shared WoW64 setup similar to what is described in http://wiki.winehq.org/Wine64. We will have to use separate build environments because having 32-bit and 64-bit -dev packages installed at the same time is not possible. Installing a 64-bit package that contains the build tools into a 32-bit environment should be possible, though. This is not necessary. From looking at the build system, things happen in a different way when I run configure for the 32-bit components with --wine64=...: 1. Manpages are not installed (WOW64_DISABLE) 2. --disable-fonts is implied 3. --disable-server is implied, so wineserver is not built. (The 64-bit wineserver is used instead, right?) Correct. 4. --disable-tools is implied because the existing build tools are being used. Did I miss anything? Leaving parts out is easy to understand, but how do the build tools that have been built for the x86_64 architecture affect the 32-bit components that are being built with them? Are different paths encoded into libwine? Not really ... you can create 32bit and 64bit built Wine packages without having cross dependencies. You just need to pack less files for the 32bit one if you use it with a 64 prefix. So for 32bit, do not use --with-wine64, just package the relevant things for the -32bit build. What is needed from the 32bit build in a WoW context is: /usr/bin/wine /usr/bin/wine-preloader /usr/lib/wine/fakedlls/* /usr/lib/libwine*.so* /usr/lib/wine/*.so* and for development additionally: /usr/lib/wine/*.def Ciao, Marcus
Re: change wording of ok()-messages in winspool-tests?
On Sun, 24 Jun 2012, Julian Rüger wrote: [...] ok( !retval, function result wrong! False expected\n); or ok( size == exact, Parameter size wrong! %d expected got %d\n, exact, size); Do you think it's worth changing these? Not necessarily. The only thing I'd feel like changing would be to include the function name in the message. That said if the test fails you get the line number and thus can inspect the code to figure it out (and most likely you'll have to inspect the code anyway). I just feel like it's nice to know what function was tested just by looking at the message. [...] Do we have guidelines for strings like these? For example: start with a captial letter, no punctuation at the end... What tests have good style I can use as reference? We don't have guidelines for this. -- Francois Gouget fgou...@free.fr http://fgouget.free.fr/ Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.
Re: Is it safe yet for developers to upgrade to Ubuntu 12.04?
2012/6/25 Erich E. Hoover ehoo...@mymail.mines.edu: I know that for a while there were some packaging problems that meant that upgrading to 12.04 made compiling 32-bit Wine on a 64-bit PC extremely difficult. Is this still the case? I've spent several hours on this over the past few days and rewrote the wiki page with instructions for using chroot: http://wiki.winehq.org/WineOn64bit It seems to work fine now. Good luck! -Alex
Re: change wording of ok()-messages in winspool-tests?
Francois Gouget wrote: Do you think it's worth changing these? Not necessarily. The only thing I'd feel like changing would be to [...] Alexandre Julliard wrote: Test failure messages are not supposed to be seen, if they are seen it's a bug. So it's not worth spending effort making them look nice or consistent. OK, I won't bother then ;) Thanks a lot for your comments!
Re: [PATCH] opengl32: Disable wglGetProcAddress for core GL 1.0/1.1 functions
On Mon, Jun 25, 2012 at 10:40 PM, Marvin test...@testbot.winehq.org 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=19550 Your paranoid android. === WINEBUILD (build) === Patch failed to apply I don't think the test-bot didn't picked up the patch since the file it links to on the page is empty. Roderick
