Package Details: proton-ge-custom 2:GE.Proton9.22-1

Git Clone URL: https://aur.archlinux.org/proton-ge-custom.git (read-only, click to copy)
Package Base: proton-ge-custom
Description: Compatibility tool for Steam Play based on Wine and additional components, GloriousEggroll's custom build
Upstream URL: https://github.com/GloriousEggroll/proton-ge-custom
Keywords: dxvk proton steam valve vkd3d wine
Licenses: custom
Provides: proton
Submitter: loathingkernel
Maintainer: loathingkernel
Last Packager: loathingkernel
Votes: 40
Popularity: 2.23
First Submitted: 2020-03-23 23:52 (UTC)
Last Updated: 2024-12-30 14:02 (UTC)

Dependencies (117)

Required by (7)

Sources (12)

Pinned Comments

loathingkernel commented on 2023-10-12 10:43 (UTC) (edited on 2023-10-12 10:45 (UTC) by loathingkernel)

@rekman, thank you for looking into CUDA issues, at least it gives me an idea on how to fix it. That being said, my position remains to build it in a clean chroot, away from the locally installed packages. It is not feasible for me to carry patches for the build systems of various subprojects in the long run.

By enabling the 0003-AUR-Remove-kaldi-openfst-vosk-api-modules-because-of patch, you lose voice recognition which I assume is not that big of a loss as I haven't encountered a use for it, so I think it is an acceptable alternative.

patlefort commented on 2022-09-22 00:33 (UTC)

Compilation will fail if you happen to have jwasm installed, due to vulkan loader. Workaround: uninstall jwasm or add this line to prepape() in the PKGBUILD:

sed -i 's/VULKAN_LOADER_CMAKE_ARGS = -DUSE_MASM=OFF/VULKAN_LOADER_CMAKE_ARGS = -DUSE_MASM=OFF -DJWASM_FOUND=0/' "$srcdir/$pkgname/Makefile.in"

loathingkernel commented on 2020-11-21 10:28 (UTC) (edited on 2022-09-13 10:55 (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 (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.

  • If you are not using CFLAGS and CXXFLAGS specific to your system this package won't offer much in terms of performance as the upstream build flags already target the nocona (Core2) architecture. It will possibly perform worse than upstream. The only benefits you get is not depending on steam linux runtime as well as linking to Arch libraries. If you still want to build it, you can uncomment the relevant lines in the PKGBUILD to enable CFLAGS and CXXFLAGS similar to the upstream.

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

Latest Comments

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

Pook commented on 2024-12-06 01:22 (UTC) (edited on 2024-12-14 23:42 (UTC) by Pook)

In order to help users who rely on AUR helpers, I wrote a guide to help users build this package in a chroot with an AUR helper.

It is located here.

If that guide does not work, build in a clean chroot as per the wiki, or use the pre-compiled binary.

rekman commented on 2024-10-17 21:18 (UTC)

Please do tell for which user it is more convenient to have an automated AUR helper fail when it can be avoided.

Maintainers may not be obligated to accept suggestions unless they fix building in a clean chroot, but they certainly look like self-centered assholes for rejecting improvement beyond the bare fucking minimum. Why not make the PKGBUILD work in more, and certainly common circumstances? Basically every other package on the AUR plays well with automated tools. Well, I mean, other than the one your prideful ass "maintains", if it can be called that, which errors out for even more trivial reasons on every update. Certainly rich to claim I think the AUR revolves around me when my suggestions are aimed at making it easier for end users, and you're the one saying "it's the user's responsibility" about something other maintainers don't mind. Fucking sterotype of a Gentoo dickhead you are.

xiota commented on 2024-10-17 17:49 (UTC)

@rekman What is "convenient" for one user may be inconvenient for others. AUR does not revolve around you. If you cannot demonstrate an actual problem with packages when built in clean chroot, maintainers are correct to reject your demands.

rekman commented on 2024-10-17 15:33 (UTC)

“Why make the PKGBUILD smoother and more convenient for users when we can just not do that?” Why even have an automated build system if things are still going to require manual steps and a full 30 minute build every update?

xiota commented on 2024-10-17 06:19 (UTC) (edited on 2024-10-17 06:20 (UTC) by xiota)

User responsibility to clean the build directory, if desired. PKGBUILD should not because there are cases when it may not be wanted. makepkg and AUR helpers have options to clean the build directory. Building in a clean chroot always cleans the build directory.

rekman commented on 2024-10-17 06:10 (UTC) (edited on 2024-10-17 06:11 (UTC) by rekman)

While PKGBUILDS may not be strictly meant to be built incrementally, many do build fine that way or AUR helpers would be much less useful. This is true also for many VCS packages. So even if it’s not required it’s a nice convenience for those who use AUR helpers.

loathingkernel commented on 2024-10-16 17:57 (UTC)

@rekman PKGBUILDs are not supposed to be built incrementally. Some time ago I had asked about the package's obligation to reset the build directory on Archlinux IRC and the consensus was that it is up to the user to make sure that they are building in a clean directory, either by using makepkg options or manually.

rekman commented on 2024-10-15 21:23 (UTC) (edited on 2024-10-15 21:27 (UTC) by rekman)

Incremental builds will sometimes error out when checking out sources because that would overwrite changes made by applying the patch files ("commit or stash your changes"). I think this could be resolved by adding git restore .; git submodule foreach --recursive git restore . to prepare().

tikilou commented on 2024-05-01 07:22 (UTC)

Hi,i don't know why, but Dualshock 4 Gamepad not working on latest releases. It's very strange, because it's working on Wine-GE.

loathingkernel commented on 2024-04-17 08:11 (UTC) (edited on 2024-04-17 08:14 (UTC) by loathingkernel)

@cwrau I do not know why people are randomly getting this build issue with git-lfs, it is really not an issue with the PKGBUILD. Builds just fine in my clean-chroot CI https://github.com/loathingKernel/PKGBUILDs/actions/runs/8693427397

For the sake of clarity, the build happens in a brand new Arch Linux docker image every time, and anything installed in it (outside of implicit base-devel and multilib-devel metapackages) is controlled by the PKGBUILD's dependencies.

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