Package Details: wine-git 4.11.r138.g6e97461580-1

Git Clone URL: (read-only)
Package Base: wine-git
Description: A compatibility layer for running Windows programs (git version)
Upstream URL:
Keywords: windows wine
Licenses: LGPL
Conflicts: bin32-wine, wine, wine-wow64
Provides: bin32-wine=4.11.r138.g6e97461580, wine=4.11.r138.g6e97461580, wine-wow64=4.11.r138.g6e97461580
Replaces: bin32-wine
Submitter: None
Maintainer: dbermond
Last Packager: dbermond
Votes: 83
Popularity: 0.427922
First Submitted: 2007-07-18 16:01
Last Updated: 2019-06-27 21:57

Dependencies (160)

Required by (228)

Sources (3)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 ... Next › Last »

haagch commented on 2013-12-05 13:45

For me it is conflicting declaration.

In file included from /usr/include/tiffio.h:33:0,
from ../../../wine-git/dlls/windowscodecs/tiffformat.c:27:
/usr/include/tiff.h:77:23: Fehler: In Konflikt stehende Typen für »int64«
typedef TIFF_INT64_T int64;


In file included from /usr/include/tiffio.h:33:0,
from ../../../wine-git/dlls/windowscodecs/tiffformat.c:27:
/usr/include/tiff.h:78:23: Fehler: In Konflikt stehende Typen für »uint64«
typedef TIFF_UINT64_T uint64;

That's from libtiff from extra..

hepha commented on 2013-12-01 14:56

fix "Wine cannot find the ncurses library ("
sed -e 's|libncurses|libncursesw|g' -e 's|lncurses|lncursesw|g' -i configure

jonnybarnes commented on 2013-05-12 18:14

The lack of a is a known issue. In theory this bugfix should solve the issue:

However, I can't seem to get the patch applied at the moment.

jonnybarnes commented on 2013-05-12 17:04

It's definitely not the patches, I've just tried to compile this with the default PKGBUILD, the resulting binary won't run because it can't find the file

jonnybarnes commented on 2013-05-11 15:34

Hi, I'm trying to compile this with some patches from one of the winehq big reports. It worked before. And it seems to be working now. But the packaged .xz file doesn't have a file /usr/lib/ and thus trying to run wine results in an error of being unable to find the file. Does anyone know how to fix this?

sxe commented on 2013-04-24 17:38

ok, next try. Sry, i'm really busy lately so i need some time to react to your comments.

TheWaffleGuy commented on 2013-04-22 18:50

Sorry, no. The unstripped depends still gets added to makedepends. If i change it to the stripped one this is still overridden by the first line in the package function, depends=(${_depends[@]}) . You should probably either move this line so that it's only run on 64bit systems or change so that the stripped array is saved back to _depends instead of depends, that is change depends=(${_depends[@]/*32-*/}) to _depends=(${_depends[@]/*32-*/})

sxe commented on 2013-04-22 17:16

You are right, sry i fucked that one up.
Please let me know if it works now.

TheWaffleGuy commented on 2013-04-22 15:50


I've got some problems with this package. Where you test if arch is i686, and strip lib32 depends, you are using the variable depends when you should be using _depends, change depends=(${depends[@]/*32-*/}) to _depends=(${_depends[@]/*32-*/}) . Without this change makepkg complains that it can't find the lib32* packages on an 32bit install.

Wintershade commented on 2013-04-21 10:03

Hello, I'm having trouble with this package, as well as the stock WINE package from [multilib]. Essentially, winecfg and wineboot (and supposedly ALSA) fail on a 64-bit wineprefix. There are three of us (that I know) currently experiencing this problem.
I've opened a thread in the Arch BBS, if you'd like to check it out (I'd be very grateful):

TIA :)