Package Details: proton 1:7.0.2-3

Git Clone URL: https://aur.archlinux.org/proton.git (read-only, click to copy)
Package Base: proton
Description: Compatibility tool for Steam Play based on Wine and additional components
Upstream URL: https://github.com/ValveSoftware/Proton
Keywords: dxvk proton steam valve vkd3d wine
Licenses: custom
Conflicts: proton-native
Provides: proton-native
Submitter: Forty-Bot
Maintainer: loathingkernel
Last Packager: loathingkernel
Votes: 94
Popularity: 0.52
First Submitted: 2018-08-22 01:23 (UTC)
Last Updated: 2022-05-08 15:05 (UTC)

Required by (1)

Sources (31)

Pinned Comments

Ninjoh commented on 2021-12-05 17:08 (UTC)

@loathingkernel After taking a detailed look at the PKGBUILD, I noticed that it explicitly, unconditionally, selects the stable Rust toolchain. I'm usually working with the nightly toolchain so that toolchain is set as my default. This means that when I run rustup target add i686-unknown-linux-gnu, it will add it to the nightly toolchain. But, the PKGBUILD selects the stable toolchain and I hadn't ran rustup target add i686-unknown-linux-gnu against that one, so the target was not available on the stable toolchain.

Setting the default toolchain to stable with rustup default stable, and then running rustup target add i686-unknown-linux-gnu solved the issue, and now it compiles just fine.

Perhaps it is of use to add to your notes comment that rustup users should ensure that the i686-unknown-linux-gnu target is installed on the stable toolchain.

loathingkernel commented on 2020-10-22 08:43 (UTC) (edited on 2021-10-22 11:50 (UTC) by loathingkernel)

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 and as such it doesn't require it.

  • 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.

Latest Comments

pvizc commented on 2022-05-07 13:51 (UTC)

@mihalycsaba I got the same problem building the package. I could fix it by disabling the threaded compilation. Eg: MAKEFLAGS=-j1

loathingkernel commented on 2022-05-06 14:21 (UTC)

@mihalycsaba I don't know then. I just re-built the package in a clean chroot to test and it built correctly. This is probably on your end.

mihalycsaba commented on 2022-05-06 14:17 (UTC)

@loathingkernel I don't use the testing repo, but the binutils got updated too on may 4, so it's now in the community repo. I don't know how to fix this.

loathingkernel commented on 2022-05-06 13:52 (UTC) (edited on 2022-05-06 13:54 (UTC) by loathingkernel)

@mihalycsaba To me it looks like the tool failing is part of mingw-w64-binutils

/usr/bin/i686-w64-mingw32-dlltool is owned by mingw-w64-binutils 2.38-2

Someone reported a similar issue with wine-ge-custom which was due to using mingw-w64-binutils from community-testing repository.

mihalycsaba commented on 2022-05-06 10:54 (UTC) (edited on 2022-05-06 10:56 (UTC) by mihalycsaba)

There was a mingw-w64-tools update a few days ago and the build fails now. Tried reinstalling the mingw-w64-tools.

  /home/csaba/.cache/yay/proton/src/build/src-wine/dlls/kernelbase/kernelbase.spec
Assembler messages:
Error: can't open rpcrt4_dll_t.s for reading: No such file or directory
/usr/bin/i686-w64-mingw32-dlltool: /usr/bin/i686-w64-mingw32-as exited with status 1
/usr/bin/i686-w64-mingw32-dlltool: failed to open temporary tail file: rpcrt4_dll_t.o: No such file or directory
winebuild: /usr/bin/i686-w64-mingw32-dlltool failed with status 1
make[3]: *** [Makefile:341657: dlls/rpcrt4/librpcrt4.delay.a] Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: Leaving directory '/home/csaba/.cache/yay/proton/src/build/obj-wine32'
make[2]: *** [../proton/Makefile.in:717: /home/csaba/.cache/yay/proton/src/build/.wine-build32] Error 2
make[2]: Leaving directory '/home/csaba/.cache/yay/proton/src/build'
make[1]: *** [../proton/Makefile.in:121: container-build] Error 2
make[1]: Leaving directory '/home/csaba/.cache/yay/proton/src/build'
make: *** [../proton/Makefile.in:32: nested_make] Error 2
==> ERROR: A failure occurred in build().
    Aborting...
 -> error making: proton

loathingkernel commented on 2022-03-30 22:25 (UTC) (edited on 2022-03-30 22:25 (UTC) by loathingkernel)

@Nu4425 Yes, the mingw-w64-crt package doesn't contain the following two tools which are required for the package to build.

mingw-w64-tools /usr/bin/i686-w64-mingw32-widl
mingw-w64-tools /usr/bin/x86_64-w64-mingw32-widl

The mingw-w64-tools package doesn't get updates regularly (it doesn't need them) so installing it manually through makepkg itself once is a workable alternative.

Nu4425 commented on 2022-03-30 22:09 (UTC) (edited on 2022-03-30 22:59 (UTC) by Nu4425)

@loathingkernel thanks. Also, is there any specific reason why mingw-w64-tools was chosen as a make dependency rather Arch's mingw-w64-crt when both packages pull from the same source?

I'm having integrity check problems with mingw-w64-tools when using paru, which is causing the build to fail

Edit: The integrity check problem seemed to be temporary. After re-trying sometime later, it was able to pass for some reason

loathingkernel commented on 2022-03-23 18:43 (UTC)

@Nu4425 No,it doesn't use any sandboxing, and basically that is the reason it exists as a package. The sandboxing in Proton from Valve and Proton-GE is in reality a side-effect of the runtime. It is used to make the process prioritize shared libraries existing in the runtime over those in the system.

This package doesn't need it, as it is built linking to the system libraries. Pressure vessel is avoided on purpose, and running this version in it would most likely break it.

I have not tried running it in a sandbox, and it is not something that I see the benefit of, but feel free to try it. It should be an interesting experiment.

Nu4425 commented on 2022-03-23 01:33 (UTC) (edited on 2022-03-23 02:02 (UTC) by Nu4425)

@loathingkernel do you happen to know if this proton build uses sandboxing?

When observing the process tree with this proton, games run through Steam are directly under a process called "reaper". While for another build, like proton-ge, games are nested under the "pv-bwrap" and a pressure-vessel process which are bubblewrap related.

If this is the case, that the sandboxing mechanism is absent, then is it advised that users apply their own sandboxing solution?

loathingkernel commented on 2022-02-28 12:26 (UTC)

@kopfik.petr No, they do not use this PKGBUILD and I don't think they will. They want a common base for everything in steam that won't break randomly due to Arch updates and I would also assume that they might want to be able move distributions at any point. They have done an excellent job at providing the stable base they needed with steam-runtime.

Possibly Steam Deck could use this package but it's better to leave it to the initiated for experimentation. I cannot test it nor I can endorse it.

If you want readily made packages, you can either use one for the repositories that provide them, or my own from here

kopfik.petr commented on 2022-02-10 11:04 (UTC)

steam deck is using Arch linux, am I right? do somebody know, whether they are using this AUR package for the proton? i wonder if gamers would need to compile the package each time there is an update or if steam distributes it precompiled? i have no problem compiling it on my 5800X in tmpfs, yes sure it takes like 15 minutes maybe?, but my mini PC with celeron j4125 has only 8GB and the cpu has a 1/10 of the 5800X horse power... it takes like... a half day to compile.

loathingkernel commented on 2022-01-13 23:05 (UTC) (edited on 2022-01-13 23:06 (UTC) by loathingkernel)

@Nu4425 The intention is the overwrite them, yes. The current default Arch FLAGS will make a number of things fail and this was the easier way to provide both easily mutable FLAGS and retain the original FLAGS at the same time. The lines you refer to were left in as documentation/notice of sorts.

On another note, the proton repo moved the submodules point to the github mirrors and I might update them too at some point if the issues continue.

Nu4425 commented on 2022-01-13 20:29 (UTC) (edited on 2022-01-13 20:30 (UTC) by Nu4425)

@loathingkernel thank you. Also, sorry if I am missing something, but are lines 295-306 in the PKGBUILD supposed to be commented? Presumably, redeclaration of CFLAGS, CXXFLAGS, and LDFLAGS will overwrite the previous states.

I just want to make sure that the intention wasn't to update than to overwrite.

loathingkernel commented on 2022-01-11 11:39 (UTC) (edited on 2022-01-11 11:39 (UTC) by loathingkernel)

@Nu4425 I am aware of the issue but thanks for finding the related issue in the bug tracker.

I could move it to the github mirrors but that would have the subtle side-effect of causing issues with the SRCDEST shared sources directory supported by pacman (which incidentally I use).

As a workaround, the other repositories can be updated manually and build it with the --holdver makepkg option to not update sources while building.

Nu4425 commented on 2022-01-10 06:01 (UTC)

@loathingkernel for this build to be successful it requires the hosts for the upstream gstreamer repositories to be online and reliable. Currently, there are connectivity issues in gstreamers gitlab servers that is causing this package's build process to hang when retrieving sources via git-clone.

See https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/407 for details.

Any suggested workarounds for this?

loathingkernel commented on 2021-12-28 18:48 (UTC)

@arvin Given that the package works through submodules I doubt that manually downloading the source will build the exact same package that upstream intents. It can be done it should be rather tedious.

arvin commented on 2021-12-28 03:48 (UTC) (edited on 2021-12-28 03:52 (UTC) by arvin)

The gstreamer repo fails to clone and the package building halts at that point. This happens with makepkg -si and aura AUR helper. I even disabled sslvarify on .gitconfig but it didn't work still. Is there a way to download the repo or change PKGBUILD?

loathingkernel commented on 2021-12-06 12:25 (UTC) (edited on 2021-12-06 13:01 (UTC) by loathingkernel)

@Ninjoh Thank you for looking into it and providing an answer, I am not particularly knowledgeable about how Rust tooling works and I wouldn't be able to figure it out on my own.

For now I have pinned your comment, pending looking into if the toolchain should be pinned to stable at all. It just seemed like the sanest of choices at the time.

Ninjoh commented on 2021-12-05 17:08 (UTC)

@loathingkernel After taking a detailed look at the PKGBUILD, I noticed that it explicitly, unconditionally, selects the stable Rust toolchain. I'm usually working with the nightly toolchain so that toolchain is set as my default. This means that when I run rustup target add i686-unknown-linux-gnu, it will add it to the nightly toolchain. But, the PKGBUILD selects the stable toolchain and I hadn't ran rustup target add i686-unknown-linux-gnu against that one, so the target was not available on the stable toolchain.

Setting the default toolchain to stable with rustup default stable, and then running rustup target add i686-unknown-linux-gnu solved the issue, and now it compiles just fine.

Perhaps it is of use to add to your notes comment that rustup users should ensure that the i686-unknown-linux-gnu target is installed on the stable toolchain.

loathingkernel commented on 2021-12-03 23:23 (UTC) (edited on 2021-12-03 23:34 (UTC) by loathingkernel)

@Ninjoh It does affect it. I believed that rustup target add i686-unknown-linux-gnu should have fixed it but apparently that is not the case. In the package this target is satisfied by the lib32-rust-libs dependency. Given that rustup is user-managed I don't know what you might be missing, you could take a look at what packages rustup provides from the repos or what lib32-rust-libs includes and see what could it be.

The other option is to build it in a clean chroot.

If you figure it out, please notify me so I can add a notice here for future reference.

Ninjoh commented on 2021-12-03 23:04 (UTC)

@loathingkernel Yes I am using community/rustup 1.24.3-2 After the first time I got the error I ran the suggested rustup target add i686-unknown-linux-gnu just to be sure that that wasn't the cause.. it's not clear to me whether this actually affects the build.

But even after installing said target, the error still occurs on a fresh clone of the PKGBUILD.

$ rustup target list | grep i686
i686-linux-android
i686-pc-windows-gnu
i686-pc-windows-msvc
i686-unknown-freebsd
i686-unknown-linux-gnu (installed)
i686-unknown-linux-musl

loathingkernel commented on 2021-12-03 20:53 (UTC) (edited on 2021-12-03 20:53 (UTC) by loathingkernel)

@Ninjoh Are you using the rustup package instead of the rust package?

Ninjoh commented on 2021-12-03 20:02 (UTC) (edited on 2021-12-03 20:02 (UTC) by Ninjoh)

On up to date Arch, fresh build using makepkg, the build fails at building obj-mediaconv32.

Rust compiler complains that it cannot find crate 'core', also noting: the 'i686-unknown-linux-gnu' target may not be installed.

Relevant part of build log:

   Compiling slab v0.4.5
     Running `rustc --crate-name build_script_build --edition=2018 /home/martijn/fastsrc/proton/src/build/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-channel-0.3.18/build.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type bin --emit=dep-info,link -C embed-bitcode=no -C debug-assertions=off --cfg 'feature="alloc"' --cfg 'feature="default"' --cfg 'feature="std"' -C metadata=4b2e39a5d220b126 -C extra-filename=-4b2e39a5d220b126 --out-dir /home/martijn/fastsrc/proton/src/build/obj-mediaconv32/release/build/futures-channel-4b2e39a5d220b126 -L dependency=/home/martijn/fastsrc/proton/src/build/obj-mediaconv32/release/deps --cap-lints allow`
     Running `rustc --crate-name slab --edition=2018 /home/martijn/fastsrc/proton/src/build/.cargo/registry/src/github.com-1ecc6299db9ec823/slab-0.4.5/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C linker-plugin-lto --cfg 'feature="default"' --cfg 'feature="std"' -C metadata=95049b3d4a3e50b3 -C extra-filename=-95049b3d4a3e50b3 --out-dir /home/martijn/fastsrc/proton/src/build/obj-mediaconv32/i686-unknown-linux-gnu/release/deps --target i686-unknown-linux-gnu -C linker=i686-pc-linux-gnu-gcc -L dependency=/home/martijn/fastsrc/proton/src/build/obj-mediaconv32/i686-unknown-linux-gnu/release/deps -L dependency=/home/martijn/fastsrc/proton/src/build/obj-mediaconv32/release/deps --cap-lints allow`
   Compiling pin-utils v0.1.0
     Running `rustc --crate-name pin_utils --edition=2018 /home/martijn/fastsrc/proton/src/build/.cargo/registry/src/github.com-1ecc6299db9ec823/pin-utils-0.1.0/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C linker-plugin-lto -C metadata=53c2cead86d9af1f -C extra-filename=-53c2cead86d9af1f --out-dir /home/martijn/fastsrc/proton/src/build/obj-mediaconv32/i686-unknown-linux-gnu/release/deps --target i686-unknown-linux-gnu -C linker=i686-pc-linux-gnu-gcc -L dependency=/home/martijn/fastsrc/proton/src/build/obj-mediaconv32/i686-unknown-linux-gnu/release/deps -L dependency=/home/martijn/fastsrc/proton/src/build/obj-mediaconv32/release/deps --cap-lints allow`
   Compiling either v1.6.1
     Running `rustc --crate-name either /home/martijn/fastsrc/proton/src/build/.cargo/registry/src/github.com-1ecc6299db9ec823/either-1.6.1/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debug-assertions=off -C metadata=7676d853b9c59c5c -C extra-filename=-7676d853b9c59c5c --out-dir /home/martijn/fastsrc/proton/src/build/obj-mediaconv32/release/deps -L dependency=/home/martijn/fastsrc/proton/src/build/obj-mediaconv32/release/deps --cap-lints allow`
error[E0463]: can't find crate for `std`
  |
  = note: the `i686-unknown-linux-gnu` target may not be installed
  = help: consider downloading the target with `rustup target add i686-unknown-linux-gnu`

For more information about this error, try `rustc --explain E0463`.
error: could not compile `slab` due to previous error

Caused by:
  process didn't exit successfully: `rustc --crate-name slab --edition=2018 /home/martijn/fastsrc/proton/src/build/.cargo/registry/src/github.com-1ecc6299db9ec823/slab-0.4.5/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C linker-plugin-lto --cfg 'feature="default"' --cfg 'feature="std"' -C metadata=95049b3d4a3e50b3 -C extra-filename=-95049b3d4a3e50b3 --out-dir /home/martijn/fastsrc/proton/src/build/obj-mediaconv32/i686-unknown-linux-gnu/release/deps --target i686-unknown-linux-gnu -C linker=i686-pc-linux-gnu-gcc -L dependency=/home/martijn/fastsrc/proton/src/build/obj-mediaconv32/i686-unknown-linux-gnu/release/deps -L dependency=/home/martijn/fastsrc/proton/src/build/obj-mediaconv32/release/deps --cap-lints allow` (exit status: 1)
warning: build failed, waiting for other jobs to finish...
error[E0463]: can't find crate for `core`
  |
  = note: the `i686-unknown-linux-gnu` target may not be installed
  = help: consider downloading the target with `rustup target add i686-unknown-linux-gnu`

error: build failed

emillynge commented on 2021-11-26 09:45 (UTC)

this patch seems to work:

https://gist.githubusercontent.com/emillynge/ab518a94c7adee22a19ca31ce944fcf4/raw/7416f876ac24cc844a48e9abaab4075652617840/wine-winevulkan_fsr.patch

loathingkernel commented on 2021-11-25 21:56 (UTC)

@emillynge I am really sorry, I forgot to comment it out when committing the update. Also thank you for investigating it. I will look into your comment and try to provide a fixed patch.

emillynge commented on 2021-11-25 21:28 (UTC)

These 2 commits: https://github.com/ValveSoftware/wine/commit/549f80abf79fc2900ecdaef9f0c1b9006dc1c11b

and

https://github.com/ValveSoftware/wine/commit/9871b0dbe3b4806ae6c4c3a9320e0fece83fabb7

Seems to be the offenders causing the bad patches. They throwing off the line numbers wine-winevulkan_fsr.patch with regards to vulkan.c. 8 lines are added at line 1209 and an additional 11 lines at 3033.

I think it would be possible to just manually adjust insertions points in the patch based on those additions.

emillynge commented on 2021-11-25 20:38 (UTC)

I think maybe the patch for winevulkan/vulkan.c/ defined in wine-winevulkan_fsr.patch is no longer good.

The functions srgb_to_unorm and is_srgb are being put inside the function create_descriptor_set causing a compilation error.

loathingkernel commented on 2021-11-19 19:34 (UTC) (edited on 2021-11-19 19:38 (UTC) by loathingkernel)

@BrainDamage Yep, I can reproduce it. I will push an update shortly that builds Wine without it, hopefully it is not used for something important in Proton. If you get compatibility issues that weren't present before, please report them.

BrainDamage commented on 2021-11-19 17:46 (UTC)

I'm having an issue doing a clean build with recent ldap versions (the same library incompatibility likely broke my old buid, since /usr/share/steam/compatibilitytools.d/proton-native/dist/lib64/wine/wldap32.dll.so cannot be loaded and lddtree points at ldap's libs )

build log:

gcc -m32 -m32 -c -o dlls/wldap32/compare.o /home/cloud/tempbuild/proton/src/build/src-wine/dlls/wldap32/compare.c \
    -Idlls/wldap32 -I/home/cloud/tempbuild/proton/src/build/src-wine/dlls/wldap32 -Iinclude \
    -I/home/cloud/tempbuild/proton/src/build/src-wine/include -D__WINESRC__ -D_REENTRANT -fno-PIC \
    -fasynchronous-unwind-tables -Wall -pipe -fcf-protection=none -fno-stack-protector \
    -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers \
    -Wno-packed-not-aligned -Wshift-overflow=2 -Wstrict-prototypes -Wtype-limits \
    -Wunused-but-set-parameter -Wvla -Wwrite-strings -Wpointer-arith -Wlogical-op \
    -fno-omit-frame-pointer -D_FORTIFY_SOURCE=2 -I/home/cloud/tempbuild/proton/src/build/dst-gst_orc32/include -I/home/cloud/tempbuild/proton/src/build/dst-gstreamer32/include -I/home/cloud/tempbuild/proton/src/build/dst-gst_base32/include -I/home/cloud/tempbuild/proton/src/build/dst-faudio32/include -I/home/cloud/tempbuild/proton/src/build/dst-jxrlib32/include/jxrlib  -gdwarf-2 -gstrict-dwarf -O3 -march=nocona -mtune=core-avx2 -pipe -mno-avx -mno-avx2 -mfpmath=sse -fwrapv -fno-strict-aliasing -ffile-prefix-map=/home/cloud/tempbuild/proton/src/build/src-wine=. -mstackrealign -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0
In file included from /home/cloud/tempbuild/proton/src/build/src-wine/dlls/wldap32/add.c:33:
/home/cloud/tempbuild/proton/src/build/src-wine/dlls/wldap32/winldap_private.h:323:13: error: conflicting types for ‘ldap_connect’; have ‘ULONG(WLDAP32_LDAP *, LDAP_TIMEVAL *)’ {aka ‘unsigned int(struct wldap32 *, struct l_timeval *)’}
    323 | ULONG CDECL ldap_connect(WLDAP32_LDAP*,LDAP_TIMEVAL*);
            |             ^~~~~~~~~~~~

loathingkernel commented on 2021-10-19 17:37 (UTC)

@somebody thanks, I just updated the package too. Thanks for letting me take care of this.

ptr1337 commented on 2021-10-19 14:32 (UTC)

Prebuilt packages can be found here: https://mirror.cachyos.org/?search=proton

how to add this repo:

https://wiki.cachyos.org/en/home/Repo

The packages are built with x86-64 and the optimized x86-64-v3 if your cpu supports that.

somebody commented on 2021-10-19 09:53 (UTC)

@loathingkernel done.

loathingkernel commented on 2021-10-19 09:20 (UTC) (edited on 2021-10-19 09:27 (UTC) by loathingkernel)

@somebody Yes disowning it should be enough (I don't know if maintainership goes automatically to the next co-maintainer though). I can talk to the chaotic people about adding it, as they have proton-ge-custom there too.

ptr1337 commented on 2021-10-19 09:19 (UTC) (edited on 2021-10-19 09:31 (UTC) by ptr1337)

Prebuilt packages can be found here: https://mirror.cachyos.org/?search=proton

how to add this repo:

https://wiki.cachyos.org/en/home/Repo

The packages are built with x86-64 and the optimized x86-64-v3 if your cpu supports that.

somebody commented on 2021-10-19 07:19 (UTC)

@loathingkernel i'm fine with transferring ownership... not sure how to do that though. do i just disown?

on a side note, after merging might be a good time to request to add this to chaotic

loathingkernel commented on 2021-10-18 19:50 (UTC)

@somebody sorry for the very late reply, I withheld any further comments because my package couldn't get updated due to an outdated dependency in Arch and then it kinda went to the backburner.

I could adopt this package and update it accordingly to the pkgbuild of proton-native. After that filling a merge request should solve the comment history. Otherwise if you would like to retain ownership, I could be added as a co-maintainer. Either is fine with me.

xiretza commented on 2021-09-25 12:09 (UTC)

@ynikitenko: I just don't understand why you posted this here, even though you had already figured out that it was an issue with a dependency, not this package. Oh well, glad you got it working!

ynikitenko commented on 2021-09-25 11:58 (UTC)

@somebody: thanks, it worked! All was finally installed. @xiretza - as I wrote in my comment, I installed proton (which involved automatic installation of a dependency). That is why I wrote about the problem here. Hope you didn't mean to sound aggressive even when asking about already established things.

somebody commented on 2021-09-25 10:57 (UTC)

see comments on wine-valve - installing vkd3d (not vkd3d-valve) manually beforehand should make it work

xiretza commented on 2021-09-25 10:48 (UTC)

@ynikitenko: so what you're saying is that this is in no way related to this package, but rather to wine-valve, and yet you commented here anyway?

ynikitenko commented on 2021-09-25 10:19 (UTC)

Failed to install, because it required wine-valve, which did not compile (the end of the log is here: https://pastebin.com/y1Q61tQU).

loathingkernel commented on 2021-08-17 08:35 (UTC) (edited on 2021-10-19 13:49 (UTC) by loathingkernel)

@BrainDamage no it is not missing, it is yay being silly and not retaining its environment during building. I have adapted the PKGBUILD since.

BrainDamage commented on 2021-08-17 01:57 (UTC) (edited on 2021-08-17 01:59 (UTC) by BrainDamage)

python-pefile is missing from the build deps list, otherwise it'll fail to build with the error:

cd /home/cloud/temp/proton-native/src/build/dst-lsteamclient32/lib && find -type f -name '*.dll' -printf '/home/cloud/temp/proton-native/src/build/dist/dist/lib/%p\0' | xargs --verbose -0 -r -P1 -n1 /home/cloud/temp/proton-native/src/proton/make/pefixup.py
/home/cloud/temp/proton-native/src/proton/make/pefixup.py /home/cloud/temp/proton-native/src/build/dist/dist/lib/./wine/fakedlls/lsteamclient.dll
Traceback (most recent call last):
  File "/home/cloud/temp/proton-native/src/proton/make/pefixup.py", line 6, in <module>
  import pefile
ModuleNotFoundError: No module named 'pefile'
make[2]: *** [../proton/build/makefile_base.mak:600: /home/cloud/temp/proton-native/src/build/.lsteamclient-dist32] Error 123

somebody commented on 2021-06-26 01:23 (UTC) (edited on 2021-06-26 01:25 (UTC) by somebody)

oops... not sure how i didn't notice the edit. re: transition... not quite sure tbh. i guess the only thing that may be a problem is a possible conflict re: the proton executable? i have it somehow, no idea what's providing it. pacman says it's owned by an old version of proton-ge-custom which is a bit odd

edit: other than that it should be fine? given that proton-native is (i'm assuming) basically this (so a drop-in replacement) but with... actual proton

loathingkernel commented on 2021-06-10 10:14 (UTC) (edited on 2021-06-10 10:15 (UTC) by loathingkernel)

fwiw might want to look into replacing proton-git too?

I don't think it is needed. They push updates to their git only on releases. Maybe a package like proton-experimental tracking the experimental releases would be useful.

EDIT: if you are ok with it, how do you think we should handle the transition?

somebody commented on 2021-06-10 04:57 (UTC)

i just make sure it builds, so no complaints here. don't think my system can handle building the entire thing anyway. fwiw might want to look into replacing proton-git too?

loathingkernel commented on 2021-06-09 20:00 (UTC) (edited on 2021-06-09 20:03 (UTC) by loathingkernel)

The original plan was to package proton itself. But that never came about.

I tried to do that split package for proton myself but due to the need for extensive patching and that I wanted to provide something that was as close as possible to the upstream package I decided to just patch it to the point that it built without issues instead of splitting it.

If you package proton-native provides the proton binary, then IMO it should replace this package.

It works and function just like proton from valve for all intents and purposes, just built on Arch libraries and without the need for the Valve runtime. It is one big monolithic thing that includes everything the upstream package would.

Forty-Bot commented on 2021-06-09 19:53 (UTC) (edited on 2021-06-09 19:54 (UTC) by Forty-Bot)

I want to ask, why is this named proton since it doesn't provide the main proton executable and it can't be used through steam?

The original plan was to package proton itself. But that never came about.

I am asking because I maintain a complete proton package but the name proton-native that I am using already exists as a React framework and it might cause confusion or issues in the future.

If your package proton-native provides the proton binary, then IMO it should replace this package.

loathingkernel commented on 2021-06-09 19:48 (UTC)

I want to ask, why is this named proton since it doesn't provide the main proton executable and it can't be used through steam? This looks to me more like a joint package of lsteamclient and vrclient from proton rather than a working proton for Arch.

I understand the usefulness of these components but I think this is misleading. I am asking because I maintain a complete proton package but the name proton-native that I am using already exists as a React framework and it might cause confusion or issues in the future.

somebody commented on 2021-05-01 06:31 (UTC)

updated to 6.3, it works fine for me but looking at the comments i can't be 100% sure, please comment if it doesn't work

heavysink commented on 2021-05-01 00:39 (UTC)

I disowned the package. I just cannot make it to work...

Anyone please try anything that may solve the problem for compilation. A possible way: https://github.com/ValveSoftware/Proton/issues/4108

loathingkernel commented on 2021-04-11 09:24 (UTC) (edited on 2021-04-11 11:30 (UTC) by loathingkernel)

@chn I tried that exact way of specifying the architecture before specifying it through the RUSTFLAGS and it failed for me. I will look into it when I rebuild the package. In the meantime, can you inform me of the configuration of your system where it has to do with rust? What version are you using, Is it installed through the repos or rustup etc.

Edit: What I was doing in the patch was nonsensical and it shouldn't work here either. For now I completely removed that -m$(3) from both env vars and it seems to build ok.

chn commented on 2021-04-11 05:41 (UTC)

I have found a workaround. In file proton-unfuck_makefile.patch, replace

diff --git a/make/rules-common.mk b/make/rules-common.mk
index fda3e3d..d49c448 100644
--- a/make/rules-common.mk
+++ b/make/rules-common.mk
@@ -101,17 +101,18 @@ all: $(1)

 $(2)_ENV$(3) = \
     CARGO_HOME=$$(OBJ)/.cargo \
-    CARGO_TARGET_$$(call toupper,$$(ARCH$(3))-unknown-linux-gnu)_LINKER="$$(ARCH$(3))-linux-gnu-gcc" \
+    CARGO_TARGET_$$(call toupper,$$(ARCH$(3))-unknown-linux-gnu)_LINKER="gcc" \
+    CARGO_TARGET_$$(call toupper,$$(ARCH$(3))-unknown-linux-gnu)_RUSTFLAGS="$$(RUSTFLAGS) -C -m$(3)" \
     CCACHE_BASEDIR="$$(CCACHE_BASEDIR)" \
     STRIP="$$(STRIP)" \

with

diff --git a/make/rules-common.mk b/make/rules-common.mk
index fda3e3d..d49c448 100644
--- a/make/rules-common.mk
+++ b/make/rules-common.mk
@@ -101,17 +101,17 @@ all: $(1)

 $(2)_ENV$(3) = \
     CARGO_HOME=$$(OBJ)/.cargo \
-    CARGO_TARGET_$$(call toupper,$$(ARCH$(3))-unknown-linux-gnu)_LINKER="$$(ARCH$(3))-linux-gnu-gcc" \
+    CARGO_TARGET_$$(call toupper,$$(ARCH$(3))-unknown-linux-gnu)_LINKER="gcc -m$(3)" \
     CCACHE_BASEDIR="$$(CCACHE_BASEDIR)" \
     STRIP="$$(STRIP)" \

chn commented on 2021-04-11 02:54 (UTC)

Build failed at 32bit mediacov rustc -C -m32:

:: configuring 32bit mediaconv...
touch /home/chn/.cache/yay/proton-native/src/build/.mediaconv-configure32
:: building 32bit mediaconv...
cd /home/chn/.cache/yay/proton-native/src/build/src-mediaconv && env CARGO_HOME=/home/chn/.cache/yay/proton-native/src/build/.cargo CARGO_TARGET_I686_UNKNOWN_LINUX_GNU_LINKER="gcc" CARGO_TARGET_I686_UNKNOWN_LINUX_GNU_RUSTFLAGS=" -C -m32" CCACHE_BASEDIR="/home/chn/.cache/yay/proton-native/src/build/src-mediaconv" STRIP="strip" CC=" gcc -m32" CXX=" g++ -m32" LD="i686-linux-gnu-ld" PKG_CONFIG="i686-pc-linux-gnu-pkg-config" CROSSCC=" i686-w64-mingw32-gcc" CROSSCXX=" i686-w64-mingw32-g++" CROSSLD="i686-w64-mingw32-ld" CROSSPKG_CONFIG="i686-pc-linux-gnu-pkg-config" PATH="/home/chn/.cache/yay/proton-native/src/build/dst-gst_orc32/bin:/home/chn/.cache/yay/proton-native/src/build/dst-gstreamer32/bin:/home/chn/.cache/yay/proton-native/src/build/dst-gst_base32/bin::/home/chn/.cache/yay/proton-native/src/proton/glslang/bin:$PATH" LD_LIBRARY_PATH="/home/chn/.cache/yay/proton-native/src/build/dst-gst_orc32/lib:/home/chn/.cache/yay/proton-native/src/build/dst-gstreamer32/lib:/home/chn/.cache/yay/proton-native/src/build/dst-gst_base32/lib:$LD_LIBRARY_PATH" PKG_CONFIG_PATH="/home/chn/.cache/yay/proton-native/src/build/dst-gst_orc32/lib/pkgconfig:/home/chn/.cache/yay/proton-native/src/build/dst-gstreamer32/lib/pkgconfig:/home/chn/.cache/yay/proton-native/src/build/dst-gst_base32/lib/pkgconfig" CFLAGS="-I/home/chn/.cache/yay/proton-native/src/build/dst-gst_orc32/include -I/home/chn/.cache/yay/proton-native/src/build/dst-gstreamer32/include -I/home/chn/.cache/yay/proton-native/src/build/dst-gst_base32/include  -gdwarf-2 -gstrict-dwarf -march=native -mtune=native -Ofast -pipe -mno-avx -mfpmath=sse -fwrapv -fno-strict-aliasing -ffile-prefix-map=/home/chn/.cache/yay/proton-native/src/build/src-mediaconv=. -mstackrealign" CXXFLAGS="-I/home/chn/.cache/yay/proton-native/src/build/dst-gst_orc32/include -I/home/chn/.cache/yay/proton-native/src/build/dst-gstreamer32/include -I/home/chn/.cache/yay/proton-native/src/build/dst-gst_base32/include  -gdwarf-2 -gstrict-dwarf -march=native -mtune=native -Ofast -pipe -mno-avx -mfpmath=sse -fwrapv -fno-strict-aliasing -ffile-prefix-map=/home/chn/.cache/yay/proton-native/src/build/src-mediaconv=. -mstackrealign -std=c++17" LDFLAGS="-L/home/chn/.cache/yay/proton-native/src/build/dst-gst_orc32/lib -L/home/chn/.cache/yay/proton-native/src/build/dst-gstreamer32/lib -L/home/chn/.cache/yay/proton-native/src/build/dst-gst_base32/lib -Wl,-rpath-link=/home/chn/.cache/yay/proton-native/src/build/dst-gst_orc32/lib -Wl,-rpath-link=/home/chn/.cache/yay/proton-native/src/build/dst-gstreamer32/lib -Wl,-rpath-link=/home/chn/.cache/yay/proton-native/src/build/dst-gst_base32/lib  -Wl,-Ofast,--sort-common,--as-needed" cargo build --target "i686-unknown-linux-gnu" --target-dir /home/chn/.cache/yay/proton-native/src/build/obj-mediaconv32 --release
error: failed to run `rustc` to learn about target-specific information

Caused by:
  process didn't exit successfully: `rustc - --crate-name ___ --print=file-names -C -m32 --target i686-unknown-linux-gnu --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro --print=sysroot --print=cfg` (exit code: 1)
  --- stderr
  error: unknown codegen option: `-m32`

make[2]: *** [../proton/build/makefile_base.mak:768: /home/chn/.cache/yay/proton-native/src/build/.mediaconv-build32] Error 101
make[2]: Leaving directory '/home/chn/.cache/yay/proton-native/src/build'
make[1]: *** [../proton/build/makefile_base.mak:89: container-build] Error 2
make[1]: Leaving directory '/home/chn/.cache/yay/proton-native/src/build'
make: *** [../proton/build/makefile_base.mak:20: nested_make] Error 2
==> ERROR: A failure occurred in build().
    Aborting...

EgidioCaprino commented on 2020-12-11 21:07 (UTC)

I'm getting this error when installing. Can you please help me?

heavysink commented on 2020-12-10 19:20 (UTC)

@ynikitenko update is on the way. I think you just ask each game to use custom proton and point it to the installed proton.

ynikitenko commented on 2020-12-10 18:21 (UTC)

Could you please update the package? The most recent version is proton-5.13-4, and it is the only one that supports Cyberpunk 2077 (which was released today). Do I understand right that there is no "proton" executable, and just several libraries and I have to use steam to run a game?

EgidioCaprino commented on 2020-12-05 17:57 (UTC)

==> ERROR: Could not resolve all dependencies.
error making: vkd3d-valve

heavysink commented on 2020-10-23 18:58 (UTC)

Sorry everyone, I forgot to change the version number to trigger rebuild at lilac. The lilac build bot will automatically update the version number tonight.

sperg512 commented on 2020-10-22 12:57 (UTC) (edited on 2020-10-23 03:01 (UTC) by sperg512)

Exactly. I think I know how to fix the problem and I'm gonna test it, it's just an undefined reference error.

Edit: yep, as I suspected, the patch should be removed to let it build properly. I'm 99% that having dlopen instead of wine_dlopen, etc is completely unnecessary. I'll do some testing

Edit2: yeah there's no reason for the patch. dlopen, dlsym aren't deprecated in Wine anymore iirc? but it does work sooo

loathingkernel commented on 2020-10-22 08:43 (UTC) (edited on 2021-10-22 11:50 (UTC) by loathingkernel)

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 and as such it doesn't require it.

  • 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.

loathingkernel commented on 2020-10-20 16:30 (UTC)

@damachine Please don't just post logs without reading them first and reading the comments in this thread. Your issue is that your afdko installation doesn't work. It has been discussed already multiple times. It is an issue with another package and the dependencies of that. I can't do anything about that because I don't maintain it. A few possible solutions have been posted in the comments.

damachine commented on 2020-10-20 16:26 (UTC) (edited on 2020-10-20 16:30 (UTC) by damachine)

Build error post a few lines before break:

File "/usr/lib/python3.8/site-packages/pkg_resources/init.py", line 770, in resolve raise DistributionNotFound(req, requirers) pkg_resources.DistributionNotFound: The 'defcon[lxml,pens]>=0.7.2' distribution was not found and is required by afdko make[1]: [../proton/build/makefile_base.mak:1532: obj-fonts/SourceHanSansSCRegular.otf] Fehler 1 make[1]: Verzeichnis „/tmp/makepkg/proton-native/src/build“ wird verlassen make: [../proton/build/makefile_base.mak:17: nested_make] Fehler 2 ==> FEHLER: Ein Fehler geschah in build(). Breche ab... error making: proton-native

thaewrapt commented on 2020-10-20 09:30 (UTC)

Yeah, it makes no sense to build (and ship) 5.0.9 if PKGBUILD states 5.1.13b as the version, so it's not only out-of-date but the package itself is broken. Either make pkgver 5.0.9 or provide a new version.

loathingkernel commented on 2020-10-20 08:03 (UTC) (edited on 2020-10-20 08:05 (UTC) by loathingkernel)

@xiretza the issue is in the PKGBUILD itself. It sources $_pkgver to download the source, which is still set to 5.0-9. .SRCINFO is autogenerated. Unless you have modified the PKGBUILD yourself, what you are building fine in a clean chroot is in fact the sources for 5.0-9

xiretza commented on 2020-10-19 11:46 (UTC)

Package builds fine in a clean chroot here, maintainer simply forgot to update the source = in .SRCINFO, which causes the aurweb interface to show the old URL under "Sources".

loathingkernel commented on 2020-10-19 07:57 (UTC) (edited on 2020-10-20 10:34 (UTC) by loathingkernel)

@sperg512 Then what is the reasoning behind updating the version number?

sperg512 commented on 2020-10-19 01:20 (UTC) (edited on 2020-10-19 01:20 (UTC) by sperg512)

@loathingkernel This seems to be unable to build on 5.13-1b, so it's not gonna get updated until a patch is made.

loathingkernel commented on 2020-10-18 21:16 (UTC)

The version is wrong, the package is versioned as 5.13.1b, it is downloading 5.0-9

crashandburn4 commented on 2020-08-02 14:26 (UTC)

That definitely explains why I couldn't find those symbols being defined! Nice work digging in further and finding the commit that removed them.

heavysink commented on 2020-07-31 12:28 (UTC)

@justinkb Thank you! If possible could you submit the patch upstream?

justinkb commented on 2020-07-31 11:54 (UTC)

Uploaded my fix for the wine_dl{sym,open} issue here https://dpaste.com/49U5YKK2D.txt

Was caused by https://source.winehq.org/git/wine.git/commit/b87256cd1db21a59484248a193b6ad12ca2853ca upstream commit

heavysink commented on 2020-07-31 01:35 (UTC) (edited on 2020-07-31 02:39 (UTC) by heavysink)

I haven't found a solution to this for now... I cannot compile it due to 'wine_dlsym' I think it is from upstream after updating wine-valve.

EDIT: proton-git still have this problem... I submitted an issue on Github: https://github.com/ValveSoftware/Proton/issues/4108

lietzu commented on 2020-07-30 23:23 (UTC)

I have the same problem as @awesome @crashandburn4

Unless someone can contradict me, I'm pretty sure this package is a broken state. I currently have an older version installed, but any compilation breaks using either wine-valve or wine-valve-git (albeit with different errors).

The problem with wine-valve-git seems to be on that packages end, but I can't be sure about if proton or wine-valve is at fault for the undefined reference to 'wine_dlsym'. Has anyone found a solution to this? If this is a universal problem can the maintainer address it?

EndlessEden commented on 2020-07-29 05:20 (UTC)

@heavysink @lilac - Would you consider taking over the proton-git package; it was orphaned, and needs a maintainer.

crashandburn4 commented on 2020-07-08 23:14 (UTC)

I get the same error as @awesome. Does anyone have a solution? had a quick glance at the packages, and couldn't see anything obvious. (in fact, I don't see that symbol in any of the header files for wine-valve, so I'm kinda confused).

awesome commented on 2020-07-06 16:11 (UTC)

I have wine-valve-5.11.1 and vkd3d-valve-1.1-2 installed.

When I try to compile, I get the following error

/usr/bin/ld: steamclient_main.o: in function load_steamclient.part.0': steamclient_main.c:(.text+0x40f): undefined reference towine_dlopen' /usr/bin/ld: steamclient_main.c:(.text+0x437): undefined reference to wine_dlsym' /usr/bin/ld: steamclient_main.c:(.text+0x463): undefined reference towine_dlsym' /usr/bin/ld: steamclient_main.c:(.text+0x48f): undefined reference to wine_dlsym' /usr/bin/ld: steamclient_main.c:(.text+0x4bb): undefined reference towine_dlsym' /usr/bin/ld: steamclient_main.c:(.text+0x4ed): undefined reference to `wine_dlsym' collect2: error: ld returned 1 exit status winegcc: /usr/bin/g++ failed make: *** [Makefile:377: lsteamclient.dll.so] Error 2

Any idea? Thanks.

heavysink commented on 2020-06-13 16:41 (UTC)

It compiles now, using the wine-valve package (non-git). The git version is yet to be fixed.

heavysink commented on 2020-06-13 02:56 (UTC)

wine/list.h is an include file inside include/wine, and somehow it does not install to /usr/include/wine. I fixed it in the wine-valve package. In addition, the release version of wine-valve does not have wined3d-interlop.h, so I included one here.

kionez commented on 2020-05-19 07:50 (UTC)

wined3d-interop.h is included only in src/Proton-proton-5.0-7/vrclient_x64/vrclient_x64/vrclient_main.c (checked with grep -r), so sed command should be:

sed -i 's,wined3d-interop.h,wine/wined3d-interop.h,g' vrclient_x64/vrclient_x64/vrclient_main.c

but now it fails with

steamclient_main.c:13:10: fatal error: wine/list.h: No such file or directory

hwaiting commented on 2020-05-18 13:22 (UTC) (edited on 2020-05-18 13:23 (UTC) by hwaiting)

I fixed it by changing:

sed -i 's,wined3d-interop.h,wine/wined3d-interop.h,g' vrclient_x64/vrclient_x64/*

to

sed -i 's,wined3d-interop.h,wine/wined3d-interop.h,g' vrclient_x64/vrclient_x64/*.* 
sed -i 's,wined3d-interop.h,wine/wined3d-interop.h,g' vrclient_x64/vrclient_x64/*/*.*

But then the build still fails because the wine folder is empty, which I'm guessing should have been filled by the commented:

git clone --recurse-submodules https://github.com/ValveSoftware/Proton.git .

Ota-Coder commented on 2020-05-08 05:49 (UTC)

I'm facing the same problem like @pagdot. How do I fix this?

pagdot commented on 2020-05-07 07:51 (UTC)

I get sed: couldn't edit vrclient_x64/vrclient_x64/json: not a regular file. It seems like the folder json got added to vrclient_x64/vrclient_x64

loathingkernel commented on 2020-04-16 13:54 (UTC) (edited on 2020-04-16 13:58 (UTC) by loathingkernel)

@yochananmarqos You are correct, neither does pacman. Thanks for pointing it out. I will add an epoch. Annoyingly, upstream is using the exact opposite convention for versioning than pacman and I hadn't looked it up.

yochananmarqos commented on 2020-04-16 13:28 (UTC)

@loathingkernel: You'll have to add an epoch otherwise AUR helpers won't see 5.0.6 as an update.

yochananmarqos commented on 2020-02-25 15:23 (UTC)

@SpaceGuy: That's an issue with afdko's dependencies, not this package. Do not use pip to install anything. See my comment on the afdko page.

SpaceGuy commented on 2020-02-25 12:36 (UTC) (edited on 2020-02-25 12:38 (UTC) by SpaceGuy)

If anyone gets errors because of missing dependencies for python-ufoprocessor (especially for python-fontparts, python-fontpens and python-booleanoperations), it might be a workaround to install python-ufoprocessor with pip. Also if errors occur about missing brotli or zopfli it seems to work if you install them over pip as well. I can confirm that @yochanmarqos's PKGBUILD works. Sorry if I missed something.

pagdot commented on 2020-02-13 20:17 (UTC)

@nisarg13 Just take a look at the built package! It's mostly in /usr/lib and /usr/lib32

nisarg13 commented on 2020-02-13 19:04 (UTC) (edited on 2020-02-13 19:04 (UTC) by nisarg13)

Hi,

where does proton get installed? I could not find it in the steam directory. Or anywhere for that matter.

loathingkernel commented on 2020-02-09 14:34 (UTC)

@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

nisarg13 commented on 2020-02-09 09:05 (UTC) (edited on 2020-02-09 09:06 (UTC) by nisarg13)

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...

loathingkernel commented on 2020-01-16 13:46 (UTC) (edited on 2020-01-16 14:11 (UTC) by loathingkernel)

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.

yochananmarqos commented on 2020-01-15 22:49 (UTC) (edited on 2020-01-15 23:56 (UTC) by yochananmarqos)

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

loathingkernel commented on 2020-01-14 22:01 (UTC) (edited on 2020-01-15 09:42 (UTC) by loathingkernel)

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?

yochananmarqos commented on 2020-01-14 21:30 (UTC)

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.

MrMallard commented on 2020-01-08 18:09 (UTC)

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

yochananmarqos commented on 2019-12-25 15:56 (UTC)

wine_gecko is now wine-gecko, FYI.

loathingkernel commented on 2019-12-19 23:57 (UTC) (edited on 2019-12-19 23:58 (UTC) by loathingkernel)

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.

yochananmarqos commented on 2019-12-19 23:40 (UTC)

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

loathingkernel commented on 2019-12-19 23:31 (UTC) (edited on 2019-12-19 23:33 (UTC) by loathingkernel)

The maintainer of dxvk-bin said something similar. Does it happen with makepkg or an AUR helper? makepkg finds it correctly here, but I have dxvk-mingw installed, although it has the same exact provides array.

yochananmarqos commented on 2019-12-19 23:22 (UTC)

Thanks, it built fine. Too late now, but you forgot to reset the pkgrel back to 1.

For some reason it won't detect dxvk-bin 1.5-3 as dxvk>=1.5

loathingkernel commented on 2019-12-19 22:21 (UTC)

Yeah, they need rebasing with almost every version. I just updated, please test as I can't build it right now.

yochananmarqos commented on 2019-12-19 21:58 (UTC)

The patches aren't working with v4.11.11:

patching file build/makefile_base.mak
Hunk #6 succeeded at 267 (offset -4 lines).
Hunk #7 succeeded at 383 (offset -5 lines).
Hunk #8 succeeded at 422 (offset -5 lines).
Hunk #9 succeeded at 434 (offset -5 lines).
Hunk #10 FAILED at 475.
Hunk #11 succeeded at 533 (offset -5 lines).
Hunk #12 succeeded at 567 (offset -5 lines).
Hunk #13 succeeded at 622 (offset -5 lines).
Hunk #14 succeeded at 658 (offset -5 lines).
Hunk #15 succeeded at 863 (offset -5 lines).
Hunk #16 succeeded at 1061 (offset -5 lines).
Hunk #17 succeeded at 1114 (offset -5 lines).
Hunk #18 succeeded at 1195 (offset -5 lines).
Hunk #19 succeeded at 1216 (offset -5 lines).
Hunk #20 FAILED at 1279.
Hunk #21 succeeded at 1276 with fuzz 2 (offset -53 lines).
Hunk #22 succeeded at 1286 (offset -53 lines).
Hunk #23 succeeded at 1311 (offset -53 lines).
Hunk #24 succeeded at 1336 (offset -53 lines).
Hunk #25 succeeded at 1362 (offset -53 lines).
Hunk #26 succeeded at 1404 (offset -53 lines).
2 out of 26 hunks FAILED -- saving rejects to file build/makefile_base.mak.rej

Agafron commented on 2019-11-17 19:43 (UTC) (edited on 2019-11-17 23:41 (UTC) by Agafron)

need modify PKGBUILD in prepare()

comment > #git clone --recurse-submodules https://github.com/ValveSoftware/Proton.git . uncoment > sed -i 's,wined3d-interop.h,wine/wined3d-interop.h,g' vrclient_x64/vrclient_x64/*

kescherAUR commented on 2019-11-17 17:43 (UTC)

Same issue as @Agafron and @jakbyte.

wackbyte commented on 2019-11-16 03:44 (UTC)

Same issue as Agafron.

Agafron commented on 2019-11-14 19:12 (UTC) (edited on 2019-11-14 19:33 (UTC) by Agafron)

in build proccess have an error ==> Starting prepare()... fatal: destination path '.' already exists and is not an empty directory.

?

loathingkernel commented on 2019-11-13 19:57 (UTC) (edited on 2019-11-21 13:35 (UTC) by loathingkernel)

It happens too me too, but not every time consistently. It is not going to forget it every time, but if it forgets it once, then it won't remember it at the next start.

My workaround has been to have a valve proton distribution selected in the global options and then select proton-native on a per game basis.

I don't know why it might be happening, it could be because it doesn't find the dist.lock file? But even if it was there, it should be user-writable, which defeats the whole system-wide installation.

If this happens for a title that has a native port, it will trigger a redownload, which in my case at least, is going to fail eventually to merge the newly downloaded files with the existing installation. In that case, the workaround I use, is to stop the download, select a Valve proton and restart a client.

This has happened to me no matter the way I have used to make steam aware of proton-native, either by placing it in /usr/share/steam/compatibilitytools.d or by the older way I used, by providing a compatibilitytools.vdf with a path to the install location (it used to be in /opt/proton-native)

yochananmarqos commented on 2019-11-13 15:54 (UTC)

If I choose to run other titles with proton-native and restart Steam, the Enable Steam Play for all other titles checkbox is unchecked. Checking it and restarting results in it being unchecked again.

loathingkernel commented on 2019-11-12 23:16 (UTC) (edited on 2019-11-12 23:24 (UTC) by loathingkernel)

You make some good points. Thanks for testing it. Anyways, enjoy it and when you find any issues please report them!

yochananmarqos commented on 2019-11-12 22:50 (UTC) (edited on 2019-11-12 22:59 (UTC) by yochananmarqos)

I created my wine-mono-bin PKGBUILD right before I flagged your package out of date. I never noticed you updated it, heh.

You might be right about the versioning of python-ufoprocessor, that is odd they went from 1.0.6 > 1.7. If the next version is 1.0.8, then I'll have to add an epoch: 1:1.0.8.

I was going to add the python- prefix for psautohint, but it's more than just a Python library. Just like afdko, there are binaries. Just about every other distro that has that package calls it psautohint. See on Repology.

Now to try it out and play some games. Thanks for creating this!

loathingkernel commented on 2019-11-12 22:03 (UTC) (edited on 2019-11-12 22:14 (UTC) by loathingkernel)

wine-mono-bin is one of my packages, I pushed the new version after the out-of-date flag.

nasm is a dependency of ffmpeg, added.

afdko is not my package, I just updated it and wrote PKGBUILDs for the missing components locally.

python-ufoprocessor is probably version 1.0.7 and not 1.7. In the git tags it is tagged as 1.07, probably they forgot a dot there as the previous one was 1.0.6. There isn't something you can do about it, but it will cause issues with the next version number if they go to 1.0.8.

I think psautohint should be named python-psautohint, at least that is what I named it in my case. Still, it is up to the maintainer of afdko to update it.

One last thing, it doesn't work with winelib versions of d9vk and dxvk. I can make it depend on some arbitrary name provided by the -mingw and -bin packages, but I only maintain d9vk.

Any other issues you can find, please report them.

loathingkernel commented on 2019-11-12 19:38 (UTC)

I updated with the dependencies from arch wine. For afdko you can use this https://gist.github.com/loathingKernel/a95ddab185d24bd62bfbce9590b6c1b8

yochananmarqos commented on 2019-11-12 16:44 (UTC)

fontforge is missing from makedepends():

fontforge -quiet -script ../proton/fonts/scripts/generatefont.pe obj-fonts/LiberationSans-Regular.sfd "Arial" "Arial" "Arial"
/bin/bash: fontforge: command not found

It still won't build as afdko is missing the ufoProcessor Python library. I'll work on that and update this comment as I go.

Traceback (most recent call last):
  File "/usr/sbin/makeotf", line 6, in <module>
    from pkg_resources import load_entry_point
  File "/usr/lib/python3.7/site-packages/pkg_resources/__init__.py", line 3250, in <module>
    @_call_aside
  File "/usr/lib/python3.7/site-packages/pkg_resources/__init__.py", line 3234, in _call_aside
    f(*args, **kwargs)
  File "/usr/lib/python3.7/site-packages/pkg_resources/__init__.py", line 3263, in _initialize_master_working_set
    working_set = WorkingSet._build_master()
  File "/usr/lib/python3.7/site-packages/pkg_resources/__init__.py", line 583, in _build_master
    ws.require(__requires__)
  File "/usr/lib/python3.7/site-packages/pkg_resources/__init__.py", line 900, in require
    needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3.7/site-packages/pkg_resources/__init__.py", line 786, in resolve
    raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'ufoProcessor==1.0.6' distribution was not found and is required by afdko
make[1]: *** [../proton/build/makefile_base.mak:1524: obj-fonts/SourceHanSansSCRegular.otf] Error 1
make[1]: Leaving directory '/home/yochanan/Documents/pkgbuilds/proton-native/src/build'
make: *** [../proton/build/makefile_base.mak:17: nested_make] Error 2

MagicAndWires commented on 2019-11-01 16:06 (UTC) (edited on 2019-11-01 17:19 (UTC) by MagicAndWires)

To the people getting the wine/wined3d-interop.h: No such file or directory the 4.17 proton requires a wine-valve version >=4.16, install wine-valve-git instead.

Update:
After some consideration, because new versions of proton require code that has not been released as a stable version yet any kind of "stable" package for wine-valve is going to be hell to maintain and always lagging slightly behind.

If anyone wants to continue a stable package despite this, I've disowned the package so you're welcome to give it a shot, but I'd advise users to just install wine-valve-git instead.

(No changes to the proton PKGBUILD necessary).

psurrena commented on 2019-10-28 16:57 (UTC)

Same exact issue as xiretza

xiretza commented on 2019-10-21 15:54 (UTC)

Still doesn't build, see the last three comments for the error (vrclient_main.c:23:10: fatal error: wine/wined3d-interop.h: No such file or directory).

sinatosk commented on 2019-10-19 15:10 (UTC)

trying to compile this package against proton 4.11-6 and ( manually ) 4.11-7 always shows

vrclient_main.c:23:10: fatal error: wine/wined3d-interop.h: No such file or directory

or ( with a line in the PKGBUILD prepare function commented out )

vrclient_main.c:23:10: fatal error: wined3d-interop.h: No such file or directory

and searching inside the source directory, there is no file called "wined3d-interop.h" anywhere

benbaz4 commented on 2019-10-18 16:16 (UTC)

same problem here.

fatal error : vrclient_main.c:23:10: fatal error: wine/wined3d-interop.h: No such file or directory 23|#include "wine/wined3d-interop.h"

I have no idea how to fix this.

pnehem commented on 2019-10-06 16:02 (UTC)

One little problem, when you download the archive, it doesn't contain the sub modules. All those folders are empty. This is the git clone line from the Valve site:

git clone --recurse-submodules https://github.com/ValveSoftware/Proton.git proton

I get an error vrclient_main.c:23:10: fatal error: wine/wined3d-interop.h: No such file or directory 23|#include "wine/wined3d-interop.h"

I saw this line in the PKGBUILD but I can't figure out where it originates from. I can file a file name wined3d-interop.idl in wine/include/wine Is this the file the sed is suppose to operate on?

sed -i 's,wined3d-interop.h,wine/wined3d-interop.h,g' vrclient_x64/vrclient_x64/*

MagicAndWires commented on 2019-10-03 22:36 (UTC)

I've created the stable wine-valve package so if you change the dependency to just wine-valve both that package and wine-valve-git will be able to fulfill it.

Forty-Bot commented on 2019-09-18 11:43 (UTC) (edited on 2019-09-18 11:45 (UTC) by Forty-Bot)

The issue when I was packaging it was that wine-valve had no tags/releases on github. Valve seems to have fixed that so you should be able to make a package which follows the point release.

MagicAndWires commented on 2019-09-18 03:26 (UTC) (edited on 2019-09-18 03:39 (UTC) by MagicAndWires)

Never mind, I am a dumb person who doesn't read pinned comments.

I'll try to work out that stable package, but since wine-valve-git already defines a provide to wine-valve you don't have to wait for the stable package to change the depend to just wine-valve. You can probably change the openvr-git dependency to its stable equivalent as well, provided there are any API incompatibilities or use of development package features I missed.

Forty-Bot commented on 2019-09-18 00:28 (UTC) (edited on 2019-09-18 00:29 (UTC) by Forty-Bot)

Proton is basically a meta-package that pulls in a bunch of dependencies and packages them together. Without wine-valve, you don't have much proton left. As far as I am aware there are no official binaries for wine-valve, so you will need to rebuild it if you want to update.

MagicAndWires commented on 2019-09-17 20:05 (UTC)

Is proton really dependant on the development versions of wine-valve and openvr specifically or does it work with any version of those packages?

With both of them being fairly large packages for simple dependencies, I'd prefer not to have to build them with every single update.

Moo-Crumpus commented on 2019-04-29 19:48 (UTC)

OPENVRPATHS-NOTFOUND Please install SteamVR SDK to continue..

yurikoles commented on 2019-03-29 08:36 (UTC)

@JoshH100 please accept proton-git package, that I had orphaned.

smd0665 commented on 2019-03-24 15:14 (UTC)

wine-valve-git has been updated and I've successfully installed that package. When I try to update proton, however, I get this error message:

ld: relocatable linking with relocations from format elf32-i386 (lsteamclient.m35YzV.o) to format elf64-x86-64 (lsteamclient.UlQ5S9.o) is not supported

and the build fails.

PrinceMachiavell commented on 2019-03-11 19:31 (UTC)

Updated to 3.16-8, thanks for the flag. I'm looking into getting wine-valve-git working...

Forty-Bot commented on 2019-03-08 00:27 (UTC) (edited on 2019-03-08 00:27 (UTC) by Forty-Bot)

I disowned wine-valve-git last week, so if you would like to update it you are welcome to adopt it. My suggestion is to further break out elements of the proton repo into their own packages.

PrinceMachiavell commented on 2019-03-06 22:41 (UTC)

I've updated the package to the latest release. Unforntuently, wine-valve-git isn't building so this package won't either until that is working. If someone can get a binary version of wine-valve working and creates an AUR package, I'll change the dependency wine-valve-git to just wine-valve.

yannleretaille commented on 2018-11-29 11:02 (UTC)

I can no longer use wine-staging to run programs like office because of bugs like https://bugs.archlinux.org/task/58607 that have been fixed recently (downgrading is also not an an option because it conflicts with wine-staging, but is required for proton). Wouldn't it make more sense to have wine-valve point to its own set of executables instead of fully replacing mainline wine?

Forty-Bot commented on 2018-11-15 22:00 (UTC)

According to #archlinux, the dependencies were correct, but I've switched to depending on the git versions until valve actually versions their other projects properly.

bulletproof commented on 2018-11-13 15:19 (UTC)

Same error at @evil5826 no results found for openvr (dependency tree: proton openvr) no results found for wine-valve (dependency tree: proton wine-valve)

Forty-Bot commented on 2018-11-12 13:44 (UTC)

@Modelmat Currently there is not much to this package except for the libraries being built. The vr library is included with proton, so I'm going to keep it. Perhaps at some future point.

@evil582 Hm, I'll have a look at it later.

evil5826 commented on 2018-11-12 13:36 (UTC) (edited on 2018-11-12 13:37 (UTC) by evil5826)

Having the same issue as ohunter.

Using Pamac, yaourt and pacaur all result in the same outcome:

:: no results found for openvr (dependency tree: proton openvr)

:: no results found for wine-valve (dependency tree: proton wine-valve)

Modelmat commented on 2018-11-12 05:23 (UTC) (edited on 2018-11-12 05:27 (UTC) by Modelmat)

I would appreciate not having openvr as a dependency, I have no VR setup and do not wish to have to enable SteamVR to use - It's 5GB. Please either create a proton-vr package or a proton non-vr package.

Forty-Bot commented on 2018-11-11 17:26 (UTC)

Should pull dependencies fine; I'm doing the same thing as openvr with wine-valve, and both show up in the aur interface fine. Perhaps it's a bug in your aur helper?

ohunter commented on 2018-11-11 17:22 (UTC)

Seems like there is a build dependency issue, because whenever I try to build proton through pikaur it's having issues with the fact that there is no package called openvr and wine-valve Checking now if installing the packages with the '-git' appended fixes the issue

Forty-Bot commented on 2018-11-11 00:33 (UTC)

@Kiwii as far as I can tell, vrclient depends on headers which are not present in other versions of wine.

Kiwii commented on 2018-10-24 17:32 (UTC)

@Tom_B, at this time, the package only builds lsteamclient.dll.so (in 32 and 64 bit), not Wine or the Proton run script.

From my understanding, this should be the library that allows a game run in regular Wine to communicate to the native Steam client, but I couldn't figure out how to set it up either. (And I lost my motivation to tinker with it when Valve updated Proton's Wine to 3.16)

Tom_B commented on 2018-10-01 09:14 (UTC)

Am I being stupid here? I've installed the package but don't know how to execute it:

$ proton bash: proton: command not found

$ wine --version wine-3.16 (Staging)

which is the version I already had installed. How do I launch proton?

Kiwii commented on 2018-09-27 20:53 (UTC)

What's the required setup to make an application in a prefix be able to use this lsteamclient.dll.so to communicate with the native Steam client?

Do I have to copy the stuff from the native Steam client's legacycompat directory somewhere into the prefix or the game folder?

greyltc commented on 2018-09-09 11:37 (UTC)

@Forty-Bot,

It would be difficult to replace the built-in version of proton which comes with steam. I will look into it when I've managed to integrate all existing components.

That comment seems to disagree with what Valve has written in their blog on 21 Aug 18 here: https://steamcommunity.com/games/221410/announcements/detail/1696055855739350561

If you're familiar with building open source projects, you can even make your own local builds of Proton; the Steam client has support for using those to run games in lieu of the built-in version...

Forty-Bot commented on 2018-08-29 03:21 (UTC)

Proton is built on top of a modified version of wine.

Correct.

This modified version of wine uses a library that is not built in any other version of wine, so proton won't work with other wine versions

vrclient depends on a header file which isn't present. I don't know if there is any additional functionality beyond that which isn't in standard wine.

You're planning to isolate this library (vrclient) so this package can be built with any wine version?

No. As Proton needs a custom version of wine, it currently can only be built with valve's wine patches. If these get merged upstream, then it is possible it could be built with other versions of wine in the future.

Also, once this package is compiled, how do I make Steam Play utilize it?

It would be difficult to replace the built-in version of proton which comes with steam. I will look into it when I've managed to integrate all existing components.

TankMissile commented on 2018-08-29 02:37 (UTC) (edited on 2018-08-29 02:38 (UTC) by TankMissile)

@Forty-Bot So let me get this straight. Proton is built on top of a modified version of wine. This modified version of wine uses a library that is not built in any other version of wine, so proton won't work with other wine versions. You're planning to isolate this library (vrclient) so this package can be built with any wine version? I hope that is the case, because I'd really like to test this out with wine-staging. Also, once this package is compiled, how do I make Steam Play utilize it?

benneti commented on 2018-08-28 07:28 (UTC)

According to https://github.com/ValveSoftware/Proton/blob/proton_3.7/CHANGELOG.md the latest version should work with both python2 and python3

Forty-Bot commented on 2018-08-27 12:06 (UTC)

I'll see if I can. The ./proton seems like the only part written in python; depending on how much needs to be changed, I could just rewrite it...

benneti commented on 2018-08-27 11:58 (UTC)

Wouldn't make it more sense to use python3 with the new version of proton, as this should be possible and is the default python in archlinux

Forty-Bot commented on 2018-08-24 01:53 (UTC) (edited on 2018-08-24 01:54 (UTC) by Forty-Bot)

From what I can tell, the vrclient library shipped with proton depends on wined3d-interop.h, which is found in the wine client on github (but not on the wine I currently have installed). I'm going to work more on this package this weekend, and hopefully get vrclient building.

If anyone would like to submit a patch you are more than welcome.

nonamethanks commented on 2018-08-24 01:37 (UTC)

Apologies if this is a stupid question, but I'm not sure I understand what's going on in the package build. Does proton only run the github-linked wine version? Does that mean we can't compile it against a more recent wine version or against wine-staging or wine-gaming-nine, or am I misunderstanding?

jpbd commented on 2018-08-23 01:56 (UTC)

@Forty-Bot Thanks for putting this out.

Forty-Bot commented on 2018-08-22 01:24 (UTC)

This is in an early state right now. vrclient_x64 needs the custom bundled version of wine, which I plan to make another package for. For now all that's packaged is lsteamclient.