June 2012 - Wine-Devel - list.winehq.org

Re: change wording of ok()-messages in winspool-tests?

by Julian Rüger

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!

June 26, 2012

Re: Is it safe yet for developers to upgrade to Ubuntu 12.04?

by Alex Henrie

2012/6/25 Erich E. Hoover <ehoover(a)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

June 26, 2012

Re: change wording of ok()-messages in winspool-tests?

by Francois Gouget

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 <fgouget(a)free.fr> http://fgouget.free.fr/ Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.

June 25, 2012

Re: Building WoW64 packages

by Marcus Meissner

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

June 25, 2012

Building WoW64 packages

by Hilko Bengen

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

June 25, 2012

Re: Is it safe yet for developers to upgrade to Ubuntu 12.04?

by Julius Schwartzenberg

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.

June 25, 2012

Re: Is it safe yet for developers to upgrade to Ubuntu 12.04?

by Joey Yandle

> 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

June 25, 2012

Re: Is it safe yet for developers to upgrade to Ubuntu 12.04?

by André Hentschel

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

June 25, 2012

Is it safe yet for developers to upgrade to Ubuntu 12.04?

by 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! Erich Hoover ehoover(a)mines.edu

June 25, 2012

Re: [PATCH 2/2] opengl32: Check for valid context in wglGetProcAddress

by Roderick Colenbrander

On Mon, Jun 25, 2012 at 1:22 AM, Chris Robinson <chris.kcat(a)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

June 25, 2012