treewide: unpin apple-sdk_11

[khaneliman]

Things done

Min SDK version was bumped in nixpkgs, unpinning derivations.

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• 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/)
• 25.05 Release Notes (or backporting 24.11 and 25.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.

---

Add a 👍 reaction to pull requests you find important.

[emilazy]

Can we just do a treewide to remove all apple-sdk_11s and darwinMinVersionHooks ≤ 11.3? (No worries if you don’t feel like it, but it was on my to‐do list, so if you’re already doing this then maybe we can just knock it all out in one go. It’s not as big a job as it sounds like since a lot of the long tail of packages are still on the old pattern; those I can check my old branch for later.)

[khaneliman]

Can we just do a treewide to remove all apple-sdk_11s and darwinMinVersionHooks ≤ 11.3? (No worries if you don’t feel like it, but it was on my to‐do list, so if you’re already doing this then maybe we can just knock it all out in one go. It’s not as big a job as it sounds like since a lot of the long tail of packages are still on the old pattern; those I can check my old branch for later.)

I can try doing that, if you'd like.

[emilazy]

If you feel up to it, it would be great :)

[paparodeo]

wait -- can this be merged tho -- I looked over the 100 files.

[khaneliman]

@emilazy Guessing this will have to go to staging.

wait -- can this be merged tho -- I looked over the 100 files.

I was wondering if it had to go to staging with how many are affected now.

[nix-owners]

The PR's base branch is set to staging, but 20 commits from the master branch are included. Make sure you know the right base branch for your changes, then:

• If the changes should go to the master branch, change the base branch to master
• If the changes should go to the staging branch, rebase your PR onto the merge base with the staging branch:

  # git rebase --onto $(git merge-base upstream/staging HEAD) $(git merge-base upstream/master HEAD)
  git rebase --onto 89019580b73ddd7d4b05fa5f6952a4676538c031 771c7e608ec7551137b2d239355ccf5856c4f0e7
  git push --force-with-lease

[emilazy]

I guess there’s no PR for the staging-only ones yet? (I had assumed it was just split entirely into master‐targeting PRs, which seemed wrong.)

[khaneliman]

I guess there’s no PR for the staging-only ones yet? (I had assumed it was just split entirely into master‐targeting PRs, which seemed wrong.)

Sorry, just waiting for the other merges before ripping them out of here. I suppose I don't have to. But, I was just double checking rebuild count on the packages left. Although, according to @paparodeo I might be able to include some more straight to master.

[emilazy]

FWIW the Facebook libraries (folly, edencommon, etc.) are only huge rebuilds on Linux, which this PR shouldn’t rebuild. So I think a lot of this can still go straight to master – presumably everything except the changes in #370445 (comment).

[khaneliman]

FWIW the Facebook libraries (folly, edencommon, etc.) are only huge rebuilds on Linux, which this PR shouldn’t rebuild. So I think a lot of this can still go straight to master – presumably everything except the changes in #370445 (comment).

Yeah, I didn't think they should rebuild either... just saw a lot of stuff getting flagged in my nixpkgs-review locally and was being cautious. Running it again looks like it was listing them as just affected but not actual needing rebuild. So I think we are good.

[emilazy]

Probably Mic92/nixpkgs-review#446.

[emilazy]

BTW, I’m not sure we need xcbuild here any more. xcrun is in the stdenv already and I’d be surprised if many Go packages need xcodebuild itself. cc @zowoq

[zowoq]

Looks like it was xcrun: #107937 (comment).

#370779