Package Details: wine-git 5.15.r0.g019fcaa3641-1

Git Clone URL: https://aur.archlinux.org/wine-git.git (read-only, click to copy)
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=5.15.r0.g019fcaa3641, wine=5.15.r0.g019fcaa3641, wine-wow64=5.15.r0.g019fcaa3641
Replaces: bin32-wine
Submitter: None
Maintainer: dbermond
Last Packager: dbermond
Votes: 83
Popularity: 0.000986
First Submitted: 2007-07-18 16:01
Last Updated: 2020-08-16 15:52

Dependencies (163)

Required by (250)

Sources (3)

Latest Comments

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

dbermond commented on 2020-01-03 19:52

@ekce xorgproto is being automatically pulled. Package is currently building fine without modifications.

ekce commented on 2019-12-21 18:29

This package now requires xorgproto.

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.