chromium: add widevine support on aarch64

[robgssp]

Description of changes

I packaged the arm64 build of widevine for chromium. The main weirdness here is widevine is built with DT_RELR relocations, which our version of glibc does support, but it checks for a particular symbol GLIBC_ABI_DT_RELR as a sort of compatibility flag. This widevine build doesn't have that flag, for what I understand to be ChromeOS reasons, so chromium fails to load the lib at startup. The fix I went with was to disable that check, as boldly copied from here. Another possibility would be to hand-patch that compatibility symbol into the widevine .so's, but I'm not sure where to start with that or how we'd carry that as a patch.

The main issue with this patch as it stands is by my understanding Hydra won't build/cache the patched glibc since it's not exposed anywhere, so users are stuck building glibc on their raspis or whatever. Alternatives that I know of would be to either expose the patched glibc as a package, or to just pull that patch into our glibc everywhere. My understanding is that wouldn't break anything (DT_RELR works the same way whether GLIBC_ABI_DT_RELR is present or not), but it's probably still more invasive than this warrants. I'd like to hear folks' thoughts on the best approach there.

The other issue is the widevine version/hash being inline when the other downloads are updateable through upstream-info.nix. I'm open to suggestions there.

Fixes #220828

Things done

• Built on platform(s)
  • x86_64-linux - confirmed derivation unchanged
  • aarch64-linux - confirmed working on netflix/hbo
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 23.11 Release Notes (or backporting 23.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

[diamondburned]

Is it possible to also expand this PR to work with Firefox?

Also, would using Arch's widevine_fixup.py work as well? This is detailed in The Quest for Netflix on Asahi Linux.

[psanford]

This doesn't work for me on my aarch64 system (macbook m2 air). Chromium reports the following error when visiting a widevine site:

 [377601:1:1021/172733.020604:ERROR:cdm_module.cc(114)] CDM at /nix/store/qjbp2y9qbx88q518ny9ic49xhmcrv201-chromium-unwrapped-118.0.5993.88-wv/libexec/chromium/WidevineCdm/_platform_specific/linux_arm64/libwidevinecdm.so could not be loaded.
[377601:1:1021/172733.020667:ERROR:cdm_module.cc(115)] Error: /nix/store/qjbp2y9qbx88q518ny9ic49xhmcrv201-chromium-unwrapped-118.0.5993.88-wv/libexec/chromium/WidevineCdm/_platform_specific/linux_arm64/libwidevinecdm.so: cannot open shared object file: Operation not permitted

EDIT: I'm guessing the issue is 4k pages. I'll see if I can get this to work with the widevie_fixup.py script.

[diamondburned]

I'll see if I can get this to work with the widevie_fixup.py script.

Perhaps my comment at #220828 (comment) can help?

[psanford]

This worked for me on Apple Silicon with 16k pages: https://gist.github.com/afilini/7fb5624c850f39af4938f4a5d087f2dc

[emilylange]

We managed to get rid of the whole logic widevineCdm derivation in favor of the roughly two years old widevine-cdm package that is also used by qutebrowser and vivaldi in #311202.

This should, at least theoretically, allow us to concentrate the /Widevine on aarch64-linux efforts/ on a single derivation (widevine-cdm) instead of multiple mostly redundant implementations.

I am sorry that this PR has been left unreviewed for so long.
I've since been added as one of the two {ungoogled-,}chromium maintainers and did some Widevine related work in #310209.

While I don't actually use chromium with Widevine (or chromium at all, really), I would certainly like to help and eventually merge something like this.

At least assuming you didn't lose interest in it, which, well, I could totally understand if you did.
But I hope I can provide a better experience from now on.

[robgssp]

Good to hear there's a better approach in the works. Unfortunately I don't have a test setup for this package anymore (I'd fixed up widevine for a Raspberry Pi media PC, which I since abandoned for other reasons), so this PR should probably be closed.

[dxwil]

#337261