nbench: supply stdenv.glibc.static since Makefile uses -static

[ghost]

ZHF: #172160

Description of changes

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.

nbench's Makefile always compiles with -static, so we need it to be
able to see libc.a. Let's add stdenv.glibc.static to the buildInputs.

[ghost]

The ZHF announcement PR says: "Please ping @NixOS/nixos-release-managers on the PR and add the 0.kind: build failure label to the pull request. If you're unable to because you're not a member of the NixOS org please ping @dasJ, @tomberek, @jonringer, @Mic92"

I am unable to add this build label, so I therefore am issuing this ping.

[davidak]

Please squash the commits.

[Mindavi]

I squashed them in the github UI.

[davidak]

We usually create merge commits which are missing with this, that's why i haven't used it.

[ghost]

We usually create merge commits which are missing with this, that's why i haven't used it.

I massively prefer squashing, it keeps the history readable and cherry-pickable (you can't git cherry-pick a merge commit).

Git merges were never meant to be used the way the github web UI uses them -- for applying patchsets. Git merges were always meant for long-lived branches that get merged more than once, like our staging and staging-next.

Github pushes excessive use of merge commits because they don't like the fact that rebasing/cherrypicking a commit changes its hash. This costs them more storage (less deduplication), but the real problem is that it breaks all their big data analytics.

[davidak]

I agree, but this is not the place to change the rules.

[ghost]

I agree, but this is not the place to change the rules.

Oh, I didn't know there was a formal policy about this. I've seen people merge my PRs using both styles.

In any event, I should try to remember to squash commits myself.

[davidak]

It's even worse. There is an informal policy.
We should document a sane policy, so it's done consistently.
But not in this issue...