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

Git Clone URL: https://aur.archlinux.org/wine-git.git (read-only)
Package Base: wine-git
Description: A compatibility layer for running Windows programs (git version)
Upstream URL: https://www.winehq.org/
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.864948
First Submitted: 2007-07-18 16:01
Last Updated: 2019-06-27 21:57

Dependencies (160)

Required by (226)

Sources (3)

Latest Comments

1 2 3 4 5 6 ... Next › Last »

dbermond commented on 2019-04-19 17:04

@electricprism The version will be automatically updated by the pkgver() function when you run makepkg. No need to update the major version at each upstream release. This is how VCS packages work. See the Wiki:

https://wiki.archlinux.org/index.php/PKGBUILD#pkgver

https://wiki.archlinux.org/index.php/VCS_package_guidelines#The_pkgver()_function

electricprism commented on 2019-04-14 21:49

I noticed that the version on this package is 3.18 prefix but current version of wine is 4.6 https://www.winehq.org/announce/4.6

Maybe if you want to drop the subversion and keep the main number which will increment annually that might be a good idea or use something else to minimize confusion I'd like to suggest it.

Tom_B commented on 2018-10-22 13:23

I'm not sure why but using this package, I cannot use Steam in offline mode. The standard arch package works fine but with wine-git steam via wine doesn't connect. Is there something I can add to the ./configure or make line to enable networking?

I'm not sure if it's a problem with wine itself or this package but it makes it slightly difficult to try custom patches in wine if you need to test a steam game.

dbermond commented on 2018-10-11 21:41

@Morguldir Thank you for reporting this. Package updated.

Morguldir commented on 2018-10-10 16:56

They applied the freetype patch upstream

https://source.winehq.org/git/wine.git/commitdiff/66e446c5ec5c7f4f072358712151d75305dfbd49?hp=935eed8e980a62557b19b3313e32106752b4e4f6

dbermond commented on 2018-07-03 17:12

@Enverex If you are building with avx support enabled then you're modifying the default Arch Linux build flags. By doing this you're pretty aware of the issues that it can cause (like the one you're having). Users wanting the most vanilla experience should 1) not modify the build flags, and/or 2) build the package in a clean chroot. It's user reponsibility to control the build flags, unless some major intervention is required.

Forcedly disabling avx support is not a good idea. Firstly, because it's not intended to use avx by default in any way (due to the default Arch build flags being x86_64 generic ones). Secondly, because it will impact users that want to benefit from avx support. Thirdly, because this is affecting only your application. If it would be a broad wine issue affecting a huge amount of applications, then well, we could disable avx here, but this is not the case.

I suggest you to fill a bug report in upstream wine saying that you're having issues in your application when avx is enabled, instead of asking for forcedly disabling avx here.

Enverex commented on 2018-06-29 12:49

@dbermond - Wine will literally just crash if it tries to use it, there is no benefit to leaving it enabled. You have 2 possible situations:

  1. The user doesn't have an AVX capable CPU, the flag won't do anything because AVX was never supported in the first place.

  2. The user has an AVX capable CPU. As soon as Wine tries to use AVX, Wine will crash. Adding the flag negates this situation.

Essentially leaving AVX enabled will do nothing other than cause Wine to crash whenever it's used (universally, until it's fixed upstream, if that will actually happen). There is zero positive to enabling the flag (which will be enabled by default for anyone using native or CPU specific compiler flags).

But it's up to you.

dbermond commented on 2018-06-05 15:26

@Enverex I don't think it's a good idea to force users to compile without avx support. It can be a user choice to use avx.

Enverex commented on 2018-06-04 14:32

@dbermond - I've actually tracked down the real reason now. It will technically affect anyone with an AVX capable processor but only triggers in very rare circumstances: https://bugs.winehq.org/show_bug.cgi?id=45289

May be worth adding "-mno-avx" to C/XXFLAGS in the build section somewhere to negate it.

dbermond commented on 2018-06-03 02:28

@Enverex I'm glad that you found the answer. But yes, this package is the same as wine from the official repositories, except for being the development version.

Packages from the official repositories are built in a clean chroot to avoid linking against undesired libraries and other interferences that may occur. For example, in a chroot it will not link against any nvidia specific library that the user might have installed. In order to better reproduce the official repository package, the user should build it in a clean chroot. And as you know, official repository packages are built with generic x86_64 compiler flags, and this can also cause runtime differences.