Change:
in stdenv.mkDerivation (finalAttrs: { pname = "gamescope"; <del> version = "3.14.23"; </del> <ins> version = "3.14.24"; </ins> src = fetchFromGitHub { owner = "ValveSoftware"; repo = "gamescope"; rev = "refs/tags/${finalAttrs.version}"; fetchSubmodules = true; <del> hash = "sha256-qXwCzNGlkGmO3BkQ74tJxufmjh4dUWzIgjHzDCEShU8="; </del> <ins> hash = "sha256-+8uojnfx8V8BiYAeUsOaXTXrlcST83z6Eld7qv1oboE="; </ins> }; patches = [ # Make it look for shaders in the right place ./shaders-path.patch <ins> # patch relative gamescopereaper path with absolute ./gamescopereaper.patch </ins> ]; # We can't substitute the patch itself because substituteAll is itself a derivation,

Discussion:
gamescope 3.14.23 seems to be packaged incorrectly, looks like this automatic upgrade missed some new runtime dependency, as the command now fails when run. Steps to reproduce the behavior: A window is displayed ! I am running on KDE Plasma 6.1, but this issue seems to happen on a standalone session as well. I'm also running Nvidia hardware, RTX 4090, on driver 555.58.02 Written logs: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Did a quick test to tryout the previous gamescope version, 3.14.22: Seems like the issue was definitely introduced in 3.14.23. !
Are you running it from nix-shell or something? should be in the package and thus on your PATH.
No, it's part of my system configuration flake. Sharing the relevant host file for context, is the only part of my configuration that is related to gamescope (): My configuration lives here: Some changes I haven't pushed yet. You can see by my that 'unstable' referes to nixos-unstable channel, and stable to the latest stable release, 24.05.
At the very least you can't mix unstable gamescope and stable WSI.
Thank you for pointing that out, I changed it to both be on "unstable" but the issue persists.
It looks to me like "gamescoperreaper" is a new binary that Valve recently with 3.14.23 that gamescope calls at some point. I was looking into their releases . Not a CPP developer so I am making a some assumptions about the nature of gamescopereaper and the layout of their project. Perhaps gamescopereaper needs to be packaged as part of the gamescope derivation? It doesn't look like it does that currently.
The binary is there in our gamescope package, though?
Agh, seems like adding though the was not enough to add into the path. I solved the issue by adding the package explicitly inside of .
I think the issue is with the module -- looks like it doesn't actually add the gamescope package into , but instead a wrapper.
I can confirm that adding the package through the gamescope module makes gamescope not work.

Adding it through other means such as does work.
Ok, so possible solutions: 1 - simple but less optimal: add a symlink below this line: 2 - complex but more Nix-friendly: find the exec portion in C code and patch it to find the executable in $out/bin/ 3 - alternative similar to (1): add $out/bin to wrapper's PATH (using makeWrapper argument) Good opportunity to open a PR with any of these solutions, tag the module and package's maintainers, and make the requested changes (which might be even a change of which strategy). Don't worry, the worst thing that could happen is your PR being closed to favorite a committer's PR, it's still seen as a good contribution (and good opportunity to learn).
Opened to attempt to resolve.