Otherwise, wayland-scanner would be picked up from the wayland in
buildInputs, which isn't cross-friendly and will stop working when we
split wayland-scanner into a separate package.
Revert this commit to avoid dependency on <span> that is not providede
by GCC 9 that we currently use on aarch64:
9a34ebbffc
Part of NixOS/nixpkgs#191357
The capability wrapper raises CAP_SYS_NICE into the ambient set. As a
result, not only is kwin_wayland itself granted that capability, but
also all applications started by it (even transitively, i.e. the entire
desktop environment). While CAP_SYS_NICE is not a particularly dangerous
capability, that behaviour is still not great; furthermore it's annoying
because it breaks programs checking that they are not granted any
capabilities (e.g. bubblewrap).
Fix this behaviour by adding a patch that causes kwin_wayland to lower
CAP_SYS_NICE from the ambient capability set at startup. That way,
expected upstream behaviour is restored.
fixes
-- The following OPTIONAL packages have not been found:
* QAccessibilityClient, KDE client-side accessibility library, <https://www.kde.org>
Required to enable accessibility features
KWin for wayland uses the `.desktop` file to determine whether a process
is allowed to access some wayland services.
This would be fine if there was a stable interface to map a process to a
`.desktop` file.
Since there is no such interface, they are scanning `.desktop` files for
one where the executable path matches the resolved file "exe" from
`/proc/$PID/exe`.
This would be fine, if we didn't wrap many (most?) KDE/Plasma binaries.
Since we are wrapping binaries, the `exe` symlink points to a wrapped
binary. No `.desktop` file will match for the wrapped binary.
The solution here is to peel away at the `.${name}-wrapped` layers until
we have the intended name for the executable.
It is expected that no `.desktop` file will ever point to a wrapped
binary.
Nix expressions provide all the features that Quilt series files have,
so using those instead is pointless. Also, lib.readPathsFromFile
(the function used to read series files) has the following warning:
> NOTE: This function is not performant and should be avoided.
This also removes some orphaned series files, and unused references to
copyPathsToStore (which were probably missed in previous commits
where calls to lib.readPathsFromFile were removed)