Gstreamer 1.28.2

[hesiod]

See 1.28.0 and following release notes:

• https://gstreamer.freedesktop.org/
• https://gstreamer.freedesktop.org/releases/1.28/#1.28.2

Does anyone have opinions about whether this should make the cut for 26.05? I think 1.28 shouldn't cause many issues, but otoh I don't see a reason to rush this into 26.05.

Note:

• There currently is an issue building devdocs for orc, see hotdoc: libclang/LLVM path discovery failure #514723. PR hotdoc: refactor clang usage, move to pkgs/by-name #431131 would likely fix the issue.
• Based on the request in gst_all_1.gst-plugins-bad: not built with separateDebugInfo #512439 I've enabled separateDebugInfo for most gstreamer packages where it makes sense
• I also went ahead and enabled __structuredAttrs and strictDeps for most packages. The change is in a separate commit to make a potential revert easier.
• There is now a warning for gst-vaapi since it has been removed upstream. The old version 1.26.11 still builds fine against gstreamer 1.28, but consumers of gst-vaapi should prefer using gst-plugins-bad in the future. (I hope lib.warn is a good fit for this, I haven't really added a warning before and AFAIK there is no guideline documentation regarding which warning mechanism is correct)

TODO:

• gstreamer-vaapi has been removed by upstream, should we remove/deprecate it as well?

Closes #492107 and #512439.

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

[RSWilli]

My two cents since I was just about to create a PR for this as well (to fix my issue #492107):

• gstreamer-vaapi was removed, but should be able to be built against newer GStreamer versions, according to the release notes you linked
• IMHO separateDebugInfo = true should be added to these libraries/plugins, some of them have it, and some don't. (see my issue gst_all_1.gst-plugins-bad: not built with separateDebugInfo #512439) Doing this in the update PR will only rebuild the world once AFAIU

Both of these issues I created are effectively dead, but I saw that @tmarkus was added as a new maintainer

[SuperSandro2000]

otherwise LGTM

[hesiod]

I've since found that the docs build using hotdoc doesn't work in orc, most likely due to issues fixed by this PR: #431131
I'll therefore disable devdocs in orc for now.

[hesiod]

I'm unsure about the warning for gst-vaapi, since it obviously causes evaluation to fail.
My idea was to inform consumers of gst-vaapi that they should migrate to gst-plugins-bad at some point. If it was just one or two packages I'd just do it myself, but there's a few of them and one is Qt 6 so my motivation to debug this is limited (don't have access to a sufficiently fast build host atm so it would take ages).

@SuperSandro2000 If you happen to have any suggestions or ideas on what the best way to handle gst-vaapi would be I'd be very curious. I am currently considering simply removing the warning and hoping that the maintainers of affected packages somehow find out about the deprecation themselves.

[RSWilli]

@hesiod in Arch Linux they simply dropped it, gstreamer 1.28+ is marked incompatible with gst-plugins-vaapi.

Also gst-plugins-vaapi was always documented as unstable by gstreamer.

[leona-ya]

gstremer 1.28.2 also fixes quite a few security vulnerabilities. We're not doing ourselves any favors by not updating gstreamer, as we then have problems backporting the vulnerabilities. Opinion @NixOS/nixos-release-managers?

[hesiod]

@RSWilli Yeah, I would like to get rid of gst-vaapi as well. It's just that I'm not really keen on removing it right in this PR, since removing it from Qt 6 should be done with caution. I thought I could simply add either an evaluation or instantiation warning to gst-vaapi in the PR, but apparently it's impossible to actually add a warning without causing the CI checks to error out? I can't find any documentation regarding best practices on warnings.
My suspicion is that warnings are only supported for packages that have no downstream consumers inside Nixpkgs, which is not the case for gst-vaapi.

@leona-ya Yes, while we just did the update to 1.26.11 which contains a number of backported security fixes, there currently are a number of issues would are only fixed in 1.28.2 (i.e. we'd have to manually add patches from upstream to 1.26.11 otherwise).

I'm really looking for some feedback regarding the warning. Should I simply remove the warning? Use a different kind (warnOnInstantiate)? Try to simply outright remove gst-vaapi, potentially breaking Qt?

[vcunat]

I'm assuming that this upgrade will miss NixOS 26.05. Otherwise we would need to quickly get it into #517946