Dear Maintainer,

Bug #1011399 was closed as fixed in 0.3.58-1 with the creation of the
  `pipewire` group and `/etc/security/limits.d/pipewire.conf`. The limits
  file correctly grants rtprio 95, nice -19, and memlock 4194304 to members
  of @pipewire.

  However, no post-install or post-upgrade script adds existing or new
  desktop users to the `pipewire` group. The result is that RT scheduling
  silently fails for all users on all installations unless they manually
  discover and run `usermod -aG pipewire <user>`.

  What led up to the situation:
  Investigating wireplumber logging "Failed to set scheduler settings:
  Operation not permitted" on every start on a clean Bookworm installation
  with pipewire 0.3.65-3+deb12u1.

  What was found:

    $ getent group pipewire
    pipewire:x:128:

  Group exists with no members.

    $ chrt -p $(pgrep wireplumber)
    pid 2558's current scheduling policy: SCHED_OTHER
    pid 2558's current scheduling priority: 0

  wireplumber running at normal priority despite rtkit being active.

  What fixed it:

    sudo usermod -aG pipewire patrick

  After logout/login, the error disappears and wireplumber runs with
  appropriate scheduling priority.

  Suggested remediation (in order of preference):

  1. Add desktop users (UID >= 1000) to the `pipewire` group in postinst,
     consistent with how other audio packages handle group membership.
  2. If automatic user modification is out of scope, document the
     requirement prominently in README.Debian -- currently there is no
     mention of the group membership requirement.
  3. Consider whether members of the `audio` group should inherit these
     limits instead, since `audio` is the established group for desktop
     audio access and users are typically already members.