Arch Linux User Repository

Notes about this package

• If you encounter issues while using this package, please contact me here first before reporting an issue to the upstream repository. Don't post logs, link to them. If you are using Manjaro, another derivative or an AUR helper, please mention it, I DO NOT TEST AGAINST THEM AND I CANNOT KNOW WHAT MIGHT BE WRONG WITH THE DISTRO/HELPER OF YOUR CHOICE.

• It takes a LOT of time and space to build. Building with multiple jobs helps but might cause builds to fail in rare cases. Be sure to have at least 16GB of RAM if you are building on tmpfs

• It is NOT built against Steam Linux Runtime (Sniper, Soldier, etc) and as such it doesn't require it. Still, is detected by Steam and works properly (preferable through steam-native).

• This PKGBUILD uses CFLAGS, CXXFLAGS and LDFLAGS hardcoded in the PKGBUILD itself. By default it uses the same C[XX]FLAGS as upstream, namely -march=nocona and -mtune=core-avx2. To change them you will have to edit the PKGBUILD itself. Due to the nature of this package some flags can cause it to fail to build or not function properly. I try to filter them out but it is based on testing. If you have a feeling that compile-time options are involved in the issues you are having please include them in your comment. Currently the filtered options are -fstack-protector-{,-strong,-all}(dxvk and vkd3d only), -fno-plt, -z,relro, -z,now. Also the use of AVX instructions is disabled through -mno-avx.

• There have been reports with afdko failing to find its dependencies during building. I can't do anything about that as I don't maintain that package. It is NOT an issue with this package and I haven't found a way to not depend on it. Please don't report fails due to afdko (or any of its python- dependencies, they are pulled in due to afdko and only used by that), it has been discussed enough. There are possible workarounds in the comments.

• It contains a patch to store game prefixes in the main Steam Library under $HOME/.local/share/Steam/steamapps/compatdata. It helps with isolation of game prefixes between users and works around issues with shared libraries on NTFS partitions due to drive symlinks. To enable it, set the PROTON_USER_COMPAT_DATA env variable to 1.

• This package requires a Rust 32 bit target, please run rustup target install i686-unknown-linux-gnu BEFORE posting any issues if you're using rustup.

@nisarg13 Did you file an orphan request because you had an issue? Seriously?

In any way, the issue you are having is not related to this package but to afdko, it is because it can't find the exact version of a library it requires as in indicated in this line

pkg_resources.DistributionNotFound: The 'ufoProcessor<=1.0.6,>=1.0.5' distribution was not found and is required by afdko

You can either ask there for a fix, or create a python virtualenv, install afdko with pip and use that environment and makepkg to build proton-native

This error pops up while building the package

Traceback (most recent call last):
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 583, in _build_master
    ws.require(__requires__)
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 900, in require
    needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 791, in resolve
    raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.ContextualVersionConflict: (ufoProcessor 1.8 (/usr/lib/python3.8/site-packages), Requirement.parse('ufoProcessor<=1.0.6,>=1.0.5'), {'afdko'})

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/makeotf", line 6, in <module>
    from pkg_resources import load_entry_point
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 3252, in <module>
    def _initialize_master_working_set():
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 3235, in _call_aside
    f(*args, **kwargs)
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 3264, in _initialize_master_working_set
    working_set = WorkingSet._build_master()
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 585, in _build_master
    return cls._build_from_requirements(__requires__)
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 598, in _build_from_requirements
    dists = ws.resolve(reqs, Environment())
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 786, in resolve
    raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'ufoProcessor<=1.0.6,>=1.0.5' distribution was not found and is required by afdko
make[1]: *** [../proton/build/makefile_base.mak:1881: obj-fonts/SourceHanSansSCRegular.otf] Error 1
make[1]: Leaving directory '/var/tmp/pamac-build-nisarg/proton-native/src/build'
make: *** [../proton/build/makefile_base.mak:17: nested_make] Error 2
==> ERROR: A failure occurred in build().
    Aborting...

Yeah, I should stop pushing changes in the late night. I messed up the CFLAGS filter. Will fix.

That explains some of the issues I have been having with the latest version myself. In my case it is that dxvk (and wine for that matter) really dislikes being build with AVX. In your specific case though it was the -fstack-protector[-whatever] flag.

Anyways the relevant sections in the PKGBUILD should be

dxvk_cflags="${dxvk_cflags// -O+([0-3s]|fast)/}"

dxvk_cflags="${dxvk_cflags/ -fno-plt/}"
dxvk_ldflags="${dxvk_ldflags/,-z,relro,-z,now/}"

Will push the fix when I test it again.

meson is required to build:

/bin/bash: line 1: meson: command not found
make[1]: *** [../proton/build/makefile_base.mak:1239: obj-dxvk32/build.ninja] Error 127
make[1]: Leaving directory '/home/yochanan/Documents/pkgbuilds/proton-native/src/build'
make: *** [../proton/build/makefile_base.mak:17: nested_make] Error 2

EDIT: Probably glslang as well since it's required to build dxvk-mingw.

EDIT: ...and it failed to build again, not sure why this time. Here's the relevant part of the build log: https://del.dog/aghinyghon

As far as wine-valve-git is concerned, I am against it because it would require extensive patching to proton to use it from the system-wide installation path, and it would require replacing the official wine or wine-staging packages. Personally I use wine-staging from the repos to run games outside steam. Also, wine-valve-git is installed to the regular paths /usr/lib32 and /usr/lib where wine built to be used with proton uses usr/lib and usr/lib64 respectively. There are a few other subtle differences here and there and that is why I used this route (patching the makefile) to build proton locally. Also, I like having control over how wine is built to avoid inconsistencies.

I have considered adding vkd3d-valve-git and lib32-vkd3d-valve-git in the previous release that it wouldn't build without vkd3d from valve. I don't like that they are git packages and don't point to specific fragments and that they require spirv-headers-git. If they were in sync with the commit of the submodule in proton I would reconsider it. Also I am not sure where I stand in requiring to replace them system-wide. I don't want to force any specific version of another package if I don't need to onto anyone using proton-native. On the other hand, they add about 5Mb to the installation, IIRC, so space-wise it is negligible.

Also, what the fuck is dxvk_config? Fucking hell, it's gonna have to build dxvk now too...

@yochananmarqos: I would also like your input on using a python virtualenv and installing afdko through pip install during the build process to use that to build the fonts. Usually whenever I try to build proton-native there is a version mismatch in one of the python libraries required by afdko. I know, doing that it is fugly and I hate it myself, but have you experienced it yourself? Do you have any better solutions or suggestions?

What do you think about adding the wine-valve-git, vkd3d-valve-git & lib32-vkd3d-valve-gitpackages as dependencies instead of directly pulling git repos? That would make things a bit more concise with sorting what dependencies are actually for what instead of having all the wine dependencies.

I am using the valve wine package: wine-valve-git 4.16-1 and am getting the same error as below: wine/wined3d-interop.h: No such file or directory

wine_gecko is now wine-gecko, FYI.

I just tested it with dxvk-bin. makepkg detected it and started building correctly. I assumed that the issue was that dxvk-bin was using a split-package workflow while building only one package, but that is not the case. I have no idea why this is happening either.

It does it with both makepkg and yay. It doesn't make any sense because everything looks right.