gtk3: fix darwin build

[mikroskeem]

3.24.31 does not declare QuartzCore dependency properly and fails to link. Apply changes from https://gitlab.gnome.org/GNOME/gtk/-/commit/0ac61443694b477c41fc246cb387ef86aba441de to add missing QuartzCore dependency.

Motivation for this change

See #152948

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • 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/)
• 22.05 Release Notes (or backporting 21.11 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
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

[jtojnar]

Relevant upstream change: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4265

Guess it needs a framework listed here:

https://gitlab.gnome.org/GNOME/gtk/-/blob/3.24.31/gdk/quartz/meson.build#L47-52

[jtojnar]

Actually, we should just fetch https://gitlab.gnome.org/GNOME/gtk/-/commit/0ac61443694b477c41fc246cb387ef86aba441de.

[mikroskeem]

Will update PR later today (GMT+2).

[jtojnar]

Thanks.

[veprbl]

This is broken on staging-next:
https://hydra.nixos.org/build/164647419

trying https://gitlab.gnome.org/GNOME/gtk/-/commit/0ac61443694b477c41fc246cb387ef86aba441de.patch
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1723  100  1723    0     0   3218      0 --:--:-- --:--:-- --:--:--  3214
hash mismatch in fixed-output derivation '/nix/store/lz1d8bymwdfi2n3r6577p8ggbhxripcz-0ac61443694b477c41fc246cb387ef86aba441de.patch':
  wanted: sha256:1ya1likckhng96ragamvslvgnc1z235k5c6j9fcmw8iiw0szy93a
  got:    sha256:0v07lx5hqf9r26awwk0z61pkplgp324r8z9kqwwg70bzslhix8r9

cc #154708

[mikroskeem]

How did this hash change even...

[veprbl]

Did you check that it was the same after you've updated the URL?

[mikroskeem]

nix-prefetch-url "https://gitlab.gnome.org/GNOME/gtk/-/commit/0ac61443694b477c41fc246cb387ef86aba441de.patch"
path is '/nix/store/hjhmqapyyp4lyrcssdvxkhbg38053spw-0ac61443694b477c41fc246cb387ef86aba441de.patch'
1ya1likckhng96ragamvslvgnc1z235k5c6j9fcmw8iiw0szy93a

I'm confused

[veprbl]

fetchpatch does some preprocessing on the patch, so it's not the same as a plain fetchurl

[vcunat]

That's a common mistake. The point of fetchpatch is that dynamically generated patches do not have a stable hash unless normalized.

[mikroskeem]

Makes sense. Will grab updated hash and open a new PR targeting staging-next (?)

[vcunat]

I can do that directly without the PR complexity.

[mikroskeem]

Thank you :)