Bug 1008414

Summary: problems running wine on x86_64 system
Product: [Fedora] Fedora EPEL Reporter: o.h.weiergraeber
Component: wineAssignee: Andreas Bierfert <andreas.bierfert>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: medium    
Version: el6CC: andreas.bierfert, pablo
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-09-08 13:29:06 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description o.h.weiergraeber 2013-09-16 10:29:21 UTC
Description of problem:

Several reports on the web seem to indicate that, e.g., MS Office 2007 runs quite well with wine nowadays, so I decided to give it a try. Unfortunately, the wine packages provided by EPEL (version 1.4.1) do not work very well:

(1) Creating a 32-bit prefix (required for 32-bit apps like Office 2007) with the 64-bit wine distribution does not work, since wineboot cannot be found. Indeed, the 32-bit version of wineboot.exe.so is missing from the packages. Other 32-bit parts are present, it seems that this file simply has been missed. 
See also
https://bugzilla.redhat.com/show_bug.cgi?id=742456
https://bugzilla.redhat.com/show_bug.cgi?id=842820

The error messages disappear after manually extracting the file from wine-wow.i686 and copying or linking it into /usr/lib/wine. However, I'm not sure if this completely cures the issue or will ultimately lead to other problems...
I think being able to create a 32-bit environment is quite essential.
Since it appears that this issue has been fixed in later versions of wine, it would be great to have, e.g., wine 1.6 in EPEL.

(2) Installation of dotnet20 with the latest winetricks script (recommended for MS Office) does not work. The package is downloaded normally, the installer is launched, but after accepting the license agreement it encounters an error and is closed. I did not find a way to work around this.

Issues (1) and (2) have been reproduced several times with fresh prefixes.
In principle, I cannot exclude that the failure in (2) is due to a still-incomplete 32-bit environment, despite the addition of winboot.exe.so (see issue 1).

On the other hand, 32-bit prefixes have been supported for quite some time now, and I found protocols for installation of dotnet20 for 1.3.x versions of wine, so I'm wondering whether this might be issues specific to 1.4, or packaging problems with the EPEL version.

Version-Release number of selected component (if applicable):
1.4.1

How reproducible:
always

Steps to Reproduce:
1. install wine on EL6.4 (x86_64)
2. run "WINEARCH=win32; winecfg"
3. observe error messages (issue 1)
[after adding 32-bit winboot.exe.so and creating the prefix]
4. run "winetricks dotnet20"
5. observe error messages (issue 2)

Actual results:
(1) creating 32-bit prefix fails
(2) installing dotnet20 fails

Expected results:
no failures


Additional info:

Comment 1 Andreas Bierfert 2013-09-17 05:19:28 UTC
There a plans to push wine 1.6 to EPEL soon. Thanks for reporting.

Comment 2 o.h.weiergraeber 2013-09-25 08:23:07 UTC
(In reply to Andreas Bierfert from comment #1)
> There a plans to push wine 1.6 to EPEL soon. Thanks for reporting.

That's good to know ;-)

Can you estimate when this will happen?

Comment 3 Andreas Bierfert 2013-09-26 16:04:32 UTC
I'd like to push a test build on Saturday...

Comment 5 Michael Cronenworth 2016-09-08 13:29:06 UTC
Wine 1.8 is now in EPEL6 and EPEL7. Open any bugs with software in the upstream bug tracker.