stdenv/check-meta: route warnings through handleEvalIssue

[caverav]

Summary

Fixes #523712.

meta.problems (from #494416) currently can't be used on any package: the moment a maintainer adds e.g. meta.problems.removal.message = "...", the Eval CI job aborts on every system. The eval driver in ci/eval/default.nix treats any stderr output as a chunk failure, and meta.problems warnings are emitted via lib.warn, which writes to stderr. That's blocking #522364 (gemini-cli deprecation notice).

The change

giveWarning in pkgs/stdenv/generic/check-meta.nix now routes through the existing config.handleEvalIssue hook (the same one the error path already uses), falling back to lib.warn when no handler is set:

if config ? handleEvalIssue then
  builtins.seq (config.handleEvalIssue warning.kind msg) acc
else
  warn msg acc;

To pass the problem's kind (matching how the error path calls handleEvalIssue problem.kind ...), the warning record in pkgs/stdenv/generic/problems.nix now carries kind alongside the existing fields.

CI's existing handleEvalIssue in ci/eval/outpaths.nix already returns true for these kinds (it only aborts/throws for unknown-meta, broken-outputs, broken, unfree, unsupported), so no change to outpaths.nix is needed: the warning simply stops reaching stderr during CI eval. Interactive users (no handleEvalIssue set) still get the warning via lib.warn.

This reuses the existing eval hook rather than adding a new config.handleEvalWarning attribute (the first version of this PR) or overriding problems.matchers.

This follows @infinisil's suggestion to reuse config.handleEvalIssue rather than add a new hook.

Issue linkage

Fixes #523712.
Unblocks #522364.

Note: ChatGPT was used to enhance translations and scaffolding tests.

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.
• Follows the automation/AI policy.

[emilazy]

Yeah, this needs to be solved for us to start making full use of the problems machinery.

I see you haven't ticked the automation policy box in the PR checklist - have you looked over it? All contributions are required to follow it.

[emilazy]

This doesn't appear to be hooked up anywhere?

Edit: Ah, never mind, I see it's using the existing framework.

[caverav]

Yeah, this needs to be solved for us to start making full use of the problems machinery.

I see you haven't ticked the automation policy box in the PR checklist - have you looked over it? All contributions are required to follow it.

hey @emilazy, sorry for the slow response and thanks for the review, i'm currently on vacation and didn't notice the new policy reference, my bad on missing the checkbox, going to read through the automation/AI policy properly and make sure this complies.

[caverav]

side note: reason = "problem" on the warning record isn't read anywhere (or I didn't find it), the warning path never branched on it the way the error path does, happy to delete it if you'd prefer

[infinisil]

While the code here looks fine, this would break channel updates, because those require no warnings to be generated. See #371223 for more context.

Specifically nix-build pkgs/top-level/release.nix -A release-checks (defined here) fails if there's any package that has a problem.

I'll think about other potential approaches, but blocking this for now.

Edit: See #523712 (comment)