`mpv.vapoursynth.python3.sitePackages` expands to `/lib/python3.8/site-packages`, thus `/lib/lib/python3.8/site-packages` being produced in wrapper, which is wrong
samba support will be dropped in mpv upstream in its next release (see
3b8b7cb9d4).
Also, using it triggered segmentation faults when using luasocket.
Closes#88584
Inspired by `wrapNeovim`, write a wrapMpv Nix function that creates a
derivation that has all of the environment that was added if needed at
the unwrapped version.
Add derivations to all-packages.nix in an almost compatible way and make
`mpv-with-scripts` throw a message implying to switch to `wrapMpv` which
has an incompatible signature.
Add to vapoursynth a new passthru attribute `python3` that is used in
passed down to the wrapper to ensure ABI compatibility with
`PYTHONPATH`.
mpv uses lua without directly executing the "lua" binary, so prefixing
$PATH wasn't enough. Without this change, lua scripts were unable to
import luasocket.
Make sure mpris.so is stripped.
mpv-with-scripts: use a standard location for scripts in $out.
mpvScripts.convert: install to the new location of mpv scripts.
Replaced gobject-introspection dependency with glib.
This cleans up our dependency footprint by ensuring a consistent version, and
also avoids duplicating the logic for how to build a waf package by deferring to
the `wafHook` helper for the `configurePhase`, `buildPhase`, and `installPhase`.
Idea shamelessly stolen from 4e60b0efae.
I realized that I don't really know anymore where I'm listed as maintainer and what
I'm actually (co)-maintaining which means that I can't proactively take
care of packages I officially maintain.
As I don't have the time, energy and motivation to take care of stuff I
was interested in 1 or 2 years ago (or packaged for someone else in the
past), I decided that I make this explicit by removing myself from several
packages and adding myself in some other stuff I'm now interested in.
I've seen it several times now that people remove themselves from a
package without removing the package if it's unmaintained after that
which is why I figured that it's fine in my case as the affected pkgs
are rather low-prio and were pretty easy to maintain.
I haven't been doing any maintenance for a long time now and not only
do I get notified, it also creates a fake impression that all these
packages had at least one maintainer when in practice they had none.
