libpisp: update to 1.6.0.

[Rutpiv]

Testing the changes

• I tested the changes in this PR: briefly

Local build testing

• I built this PR locally for these architectures (crossbuilds):
  • aarch64
  • aarch64-musl
  • armv7l
  • armv7l-musl
  • armv6l
  • armv6l-musl

---

Restricts archs to "aarch64* armv*". I added this package originally without an archs restriction, which was a mistake: PiSP is Raspberry Pi ISP hardware, and libpisp's only consumer in the repo, libcamera, already gates its libpisp-devel dependency to aarch64*/armv* (its rpi/pisp pipeline handler is ARM-only). The library compiles on x86 but has no build-time consumer and no runtime hardware there, so building it for those arches never made sense. This corrects that.

1.6.0 also adds an optional GStreamer plugin (pispconvert), gated behind the gstreamer meson feature and disabled by default. This template keeps it disabled: the plugin references GST_VIDEO_FORMAT_NV12_128C8 and GST_VIDEO_FORMAT_NV12_10LE32_128C8, which are not present in any released GStreamer (absent through the current main), so it fails to compile against Void's gstreamer. Those formats come from gstreamer MR !9247 (https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9247), which is still under active review and not yet merged. Carrying it as a downstream patch is not worth it while it keeps moving, so the plugin stays off until the formats land in a gstreamer release.

[Rutpiv]

One question for maintainers: this package was previously published for x86_64/i686. When restricting archs on an already-distributed package, is there anything to handle on the repo side for the now-obsolete binaries (e.g. do they get cleaned up automatically, or is a manual step / noarch handling needed)? Happy to follow whatever the standard procedure is.

[Duncaen]

Those need to be manually cleaned.