Build wineWow by default

[lukateras]

Steps to reproduce

$ nix-shell -p wine --run 'env WINEARCH=win64 WINEPREFIX=$(mktemp -d) wine /dev/null'
wine: WINEARCH set to win64 but '/run/user/1000/tmp.rCVRFbzbyt' is a 32-bit installation.

Technical details

• system: "x86_64-linux"
• host os: Linux 4.14.3, NixOS, 18.03pre121925.3eccd0b11d1 (Impala)
• multi-user?: yes
• sandbox: yes
• version: nix-env (Nix) 1.11.15
• channels(root): "overlay, nixos-18.03pre121925.3eccd0b11d1"
• channels(chronos): ""
• nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs

[orivej]

The default wine is the wine32 build: https://github.com/NixOS/nixpkgs/blob/f2f524a31c14a516ab84a0819019cdd3a8d7dc07/pkgs/top-level/all-packages.nix#L19798. You may choose wine64 and wineWow instead (but in my limited and possibly obsolete experience wineWow does not run as well as wine32 or at all).

[lukateras]

I agree that 32-bit Wine has better compatibility, but in some cases you want 64-bit Wine prefix. The problem with wineWow is that complete build matrix is not available: e.g. there is no wineUnstableWow.

[lukateras]

Another problem is that, I think, most other distributions ship Wine with both win32 and win64 prefix support by default.

[jokogr]

I use wine.override { wineBuild = "wineWow"; } as mentioned in the wiki.

[ikervagyok]

@yegortimoshenko is there any progress on this? what blocks switching the default to a wow-build? or just add a wine{,-staging,-unstable}-wow package to all-packages.nix until it can be the default?

@jokogr i've used this, but rebuild wine twice for a wow-build locally is time consuming. i believe it should be coming from the mirrors when there are more than a few people using/requesting it.

[ikervagyok]

any news?

[ghost]

@yegortimoshenko @ikervagyok ok, opened pr https://github.com/NixOS/nixpkgs/pull/43065

[ghost]

@orivej

but in my limited and possibly obsolete experience wineWow does not run as well as wine32 or at all

Many 3A games are now playable thx to dxvk project like witcher 3 or far cry 5. And these do require winewow

[lukateras]

Still we should consider building winewow by default (and have wine attr point to that). I don't know of any regressions that this might cause as long as one creates a 32-bit Wine prefix.

[ikervagyok]

step one is merged, good job @gnidorah!

@yegortimoshenko i can live with the default being 32bit, until there is evidence for a wow-build being significantly better/worse. but until there is a consensus, we should keep this issue open.

@yegortimoshenko @gnidorah after looking at this again, would it make sense to let winetricks also depend on config.wine.release and config.wine.build, so people using a non-default wine only depend on one version?

[ghost]

@ikervagyok The first step fixed these issues

i've used this, but rebuild wine twice for a wow-build locally is time consuming. i believe it should be coming from the mirrors when there are more than a few people using/requesting it.

The problem with wineWow is that complete build matrix is not available: e.g. there is no wineUnstableWow

What about

after looking at this again, would it make sense to let winetricks also depend on config.wine.release and config.wine.build, so people using a non-default wine only depend on one version?

Just override winetricks package, its a shell script, so building is zero time: winetricks.override { wine = wineWowPackages.staging; } config.wine.release and config.wine.build are not good settings to use because they may trigger a local wine rebuild.

[ikervagyok]

@gnidorah i am already doing this, as i have a gaming environment and config.wine.* doesn't work in buildFHSUserEnv. ;)

[nh2]

Hi, I'm currently using (wineStaging.override { wineBuild = "wineWow"; }) as explained on https://nixos.wiki/wiki/Wine but that rebuilds Wine from source on every update which takes forever.

Is this still the right way to do it?

What's the difference between this and the wineWowPackages.staging mentioned above?

[nh2]

wineWowPackages.staging seems to work just fine for me. Should the wiki be updated?

[ghost]

@nh2 Yes, sure!

[nh2]

I've updated the wiki, writing:

    # support both 32- and 64-bit applications
    wineWowPackages.stable

    # support 32-bit only
    # wine

    # support 64-bit only
    # (wine.override { wineBuild = "wine64"; })

    # wine-staging (version with experimental features)
    # wineWowPackages.staging

Please let me know if there are remaining mistakes in it.

[stale[bot]]

Hello, I'm a bot and I thank you in the name of the community for opening this issue.

To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human.

The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it.

If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use Git blame or GitHub's web interface on the relevant files to find them.

Lastly, you can always ask for help at our Discourse Forum or at #nixos' IRC channel.

[enolan]

Still relevant, bot. I was bit by this today.

[acertain]

It'd be nice to be able to get wineWowPackages.full.override { wineRelease = "staging"; } pre-built somehow. wineWowPackages.staging (built by hydra) is based on wineWowPackages.base, which is missing stuff.

Maybe nixpkgs.wine-staging should be updated to be based on wineWow? Or staging in wine-packages.nix could be based on full?

[stale[bot]]

I marked this as stale due to inactivity. → More info

[acertain]

wineWowPackages.stagingFull now exists, so I think this can be closed