Bug 533988

Summary:	Wine 64-bit isn't ready and breaks Wine installs on x86_64
Product:	[Fedora] Fedora	Reporter:	Michael Stefaniuc <mstefani>
Component:	wine	Assignee:	Andreas Bierfert <andreas.bierfert>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	high
Version:	11	CC:	andreas.bierfert, arethusa26, lyarwood, pembo13, rjones, robatino
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-11-10 15:21:53 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Michael Stefaniuc 2009-11-09 23:43:58 UTC

Description of problem:
Wine 64-bit isn't ready; that is the release criteria for wine-1.2 and the release freeze is still a few month out as there is still a lot of important work to be done.

More important is that Wine 64-bit will break existing wine installations:
- wine.i586 and wine.x86_64 are mutually exclusive; they cannot be installed at the same time as they cannot work with the WINEPREFIX (aka $HOME/.wine) created by the other arch. Wine 64-bit will just refuse to start when it sees a 32-bit $HOME/.wine

- wine.x86_64 needs to include a 32-bit Wine version compiled to work in the 64-bit environment (configure --with-wine64=DIR # use the 64-bit Wine in DIR for a Wow64 build). That's the way how Windows implements 64-bit too.

- The WoW64 code isn't finished yet, the registry part is still missing and 32-bit and 64-bit apps will clobber the registry.

We got a few help requests from Fedora Wine users on the #winehq channel as their Wine is "broken". The fix is just to remove any wine*.x86_64 packages and make sure they have only the .i586 rpms installed. Please consider making wine again a i586 app only until the wine-1.2 is out.

Version-Release number of selected component (if applicable):
wine-1.1.32-1.fc11

Comment 1 Arthur Pemberton 2009-11-10 12:07:16 UTC

Yah, an update of Wine seems to have screwed up my .wine even though I explicitly used `wine32`. I do see the following in my yum.log

Nov 07 15:56:09 Updated: wine-fonts-1.1.32-1.fc11.noarch
Nov 07 15:56:13 Updated: wine-core-1.1.32-1.fc11.x86_64
Nov 07 15:56:47 Updated: wine-core-1.1.32-1.fc11.i586
Nov 07 15:56:48 Updated: wine-twain-1.1.32-1.fc11.x86_64
Nov 07 15:56:48 Updated: wine-capi-1.1.32-1.fc11.x86_64
Nov 07 15:56:49 Updated: wine-ldap-1.1.32-1.fc11.x86_64
Nov 07 15:56:49 Updated: wine-pulseaudio-1.1.32-1.fc11.x86_64
Nov 07 15:56:49 Updated: wine-cms-1.1.32-1.fc11.x86_64
Nov 07 15:56:50 Updated: wine-ldap-1.1.32-1.fc11.i586
Nov 07 15:56:50 Updated: wine-pulseaudio-1.1.32-1.fc11.i586
Nov 07 15:56:51 Updated: wine-cms-1.1.32-1.fc11.i586
Nov 07 15:56:51 Updated: wine-twain-1.1.32-1.fc11.i586
Nov 07 15:56:51 Updated: wine-capi-1.1.32-1.fc11.i586
Nov 07 15:56:52 Updated: wine-desktop-1.1.32-1.fc11.noarch
Nov 07 15:56:52 Updated: wine-common-1.1.32-1.fc11.noarch
Nov 07 15:56:54 Updated: wine-1.1.32-1.fc11.x86_64

Now I get this "it cannot be used with wow64 Wine" which I assume has nothing to do with World of Warcraft

Comment 2 Arthur Pemberton 2009-11-10 12:26:14 UTC

`yum remove "wine*.x86_64" && yum install "wine*.i586"` leaves me with a broken wine:
wine: could not exec wineserver

`yum remove "*wine*" && yum install wine` brings me back to where I was:
wine: '/home/pembo13/.wine' is a 32-bit prefix, it cannot be used with wow64 Wine

I really need an app that requires wine right now, couldn't have happened at a worse time.

Comment 3 Arthur Pemberton 2009-11-10 12:28:57 UTC

I had to "remove" my ~/.wine to get things workings again.

Comment 4 Arthur Pemberton 2009-11-10 14:02:23 UTC

(In reply to comment #3)
> I had to "remove" my ~/.wine to get things workings again.  

I seem to have to do this after each wine32 use

Comment 5 Andreas Bierfert 2009-11-10 15:21:53 UTC


*** This bug has been marked as a duplicate of bug 533806 ***