[pull] master from NixOS:master

.github/CODEOWNERS

@@ -14,9 +14,10 @@
 # CI
 /.github/workflows @NixOS/Security @Mic92 @zowoq
 /.github/workflows/check-nix-format.yml @infinisil
-/ci @infinisil @NixOS/Security
+/.github/workflows/nixpkgs-vet.yml @infinisil @philiptaron
+/ci @infinisil @philiptaron @NixOS/Security
 
-# Develompent support
+# Development support
 /.editorconfig @Mic92 @zowoq
 /shell.nix @infinisil @NixOS/Security
 
@@ -43,6 +44,7 @@
 /pkgs/top-level/stage.nix                        @Ericson2314
 /pkgs/top-level/splice.nix                       @Ericson2314
 /pkgs/top-level/release-cross.nix                @Ericson2314
+/pkgs/top-level/by-name-overlay.nix              @infinisil @philiptaron
 /pkgs/stdenv                                     @philiptaron
 /pkgs/stdenv/generic                             @Ericson2314
 /pkgs/stdenv/generic/check-meta.nix              @Ericson2314
@@ -58,12 +60,6 @@
 /pkgs/pkgs-lib/formats/libconfig                 @h7x4
 /pkgs/pkgs-lib/formats/hocon                     @h7x4
 
-# pkgs/by-name
-/pkgs/test/check-by-name @infinisil
-/pkgs/by-name/README.md @infinisil
-/pkgs/top-level/by-name-overlay.nix @infinisil
-/.github/workflows/check-by-name.yml @infinisil
-
 # Nixpkgs build-support
 /pkgs/build-support/writers @lassulus @Profpatsch
 
@@ -91,6 +87,7 @@ nixos/modules/installer/tools/nix-fallback-paths.nix  @NixOS/nix-team @raitobeza
 /doc/README.md @infinisil
 /nixos/README.md @infinisil
 /pkgs/README.md @infinisil
+/pkgs/by-name/README.md @infinisil
 /maintainers/README.md @infinisil
 
 # User-facing development documentation
@@ -254,6 +251,7 @@ pkgs/development/python-modules/buildcatrust/ @ajs124 @lukegb @mweinelt
 
 # Idris
 /pkgs/development/idris-modules @Infinisil
+/pkgs/development/compilers/idris2 @mattpolzin
 
 # Bazel
 /pkgs/development/tools/build-managers/bazel @Profpatsch
@@ -389,3 +387,8 @@ pkgs/by-name/lx/lxc*                    @adamcstephens
 /pkgs/os-specific/linux/checkpolicy @RossComputerGuy
 /pkgs/os-specific/linux/libselinux  @RossComputerGuy
 /pkgs/os-specific/linux/libsepol    @RossComputerGuy
+
+# installShellFiles
+/pkgs/by-name/in/installShellFiles/*     @Ericson2314
+/pkgs/test/install-shell-files/*         @Ericson2314
+/doc/hooks/installShellFiles.section.md  @Ericson2314

.github/labeler.yml

@@ -270,6 +270,12 @@
     - changed-files:
       - any-glob-to-any-file:
         - .github/**/*
+        - CONTRIBUTING.md
+        - pkgs/README.md
+        - nixos/README.md
+        - maintainers/README.md
+        - lib/README.md
+        - doc/README.md
 
 "6.topic: printing":
   - any:

.github/workflows/check-nix-format.yml

@@ -7,7 +7,7 @@ name: Check that Nix files are formatted
 
 on:
   pull_request_target:
-    # See the comment at the same location in ./check-by-name.yml
+    # See the comment at the same location in ./nixpkgs-vet.yml
     types: [opened, synchronize, reopened, edited]
 permissions:
   contents: read

.github/workflows/nixpkgs-vet.yml

@@ -0,0 +1,116 @@
+# `nixpkgs-vet` is a tool to vet Nixpkgs: its architecture, package structure, and more.
+# Among other checks, it makes sure that `pkgs/by-name` (see `../../pkgs/by-name/README.md`) follows the validity rules outlined in [RFC 140](https://github.com/NixOS/rfcs/pull/140).
+# When you make changes to this workflow, please also update `ci/nixpkgs-vet.sh` to reflect the impact of your work to the CI.
+# See https://github.com/NixOS/nixpkgs-vet for details on the tool and its checks.
+name: Vet nixpkgs
+
+on:
+  # Using pull_request_target instead of pull_request avoids having to approve first time contributors.
+  pull_request_target:
+    # This workflow depends on the base branch of the PR, but changing the base branch is not included in the default trigger events, which would be `opened`, `synchronize` or `reopened`.
+    # Instead it causes an `edited` event, so we need to add it explicitly here.
+    # While `edited` is also triggered when the PR title/body is changed, this PR action is fairly quick, and PRs don't get edited **that** often, so it shouldn't be a problem.
+    # There is a feature request for adding a `base_changed` event: https://github.com/orgs/community/discussions/35058
+    types: [opened, synchronize, reopened, edited]
+
+permissions: {}
+
+# We don't use a concurrency group here, because the action is triggered quite often (due to the PR edit trigger), and contributors would get notified on any canceled run.
+# There is a feature request for suppressing notifications on concurrency-canceled runs: https://github.com/orgs/community/discussions/13015
+
+jobs:
+  check:
+    name: nixpkgs-vet
+    # This needs to be x86_64-linux, because we depend on the tooling being pre-built in the GitHub releases.
+    runs-on: ubuntu-latest
+    # This should take 1 minute at most, but let's be generous. The default of 6 hours is definitely too long.
+    timeout-minutes: 10
+    steps:
+      # This step has to be in this file, because it's needed to determine which revision of the repository to fetch, and we can only use other files from the repository once it's fetched.
+      - name: Resolving the merge commit
+        env:
+          GH_TOKEN: ${{ github.token }}
+        run: |
+          # This checks for mergeability of a pull request as recommended in
+          # https://docs.github.com/en/rest/guides/using-the-rest-api-to-interact-with-your-git-database?apiVersion=2022-11-28#checking-mergeability-of-pull-requests
+
+          # Retry the API query this many times
+          retryCount=5
+          # Start with 5 seconds, but double every retry
+          retryInterval=5
+          while true; do
+            echo "Checking whether the pull request can be merged"
+            prInfo=$(gh api \
+              -H "Accept: application/vnd.github+json" \
+              -H "X-GitHub-Api-Version: 2022-11-28" \
+              /repos/"$GITHUB_REPOSITORY"/pulls/${{ github.event.pull_request.number }})
+            mergeable=$(jq -r .mergeable <<< "$prInfo")
+            mergedSha=$(jq -r .merge_commit_sha <<< "$prInfo")
+
+            if [[ "$mergeable" == "null" ]]; then
+              if (( retryCount == 0 )); then
+                echo "Not retrying anymore. It's likely that GitHub is having internal issues: check https://www.githubstatus.com/"
+                exit 1
+              else
+                (( retryCount -= 1 )) || true
+
+                # null indicates that GitHub is still computing whether it's mergeable
+                # Wait a couple seconds before trying again
+                echo "GitHub is still computing whether this PR can be merged, waiting $retryInterval seconds before trying again ($retryCount retries left)"
+                sleep "$retryInterval"
+
+                (( retryInterval *= 2 )) || true
+              fi
+            else
+              break
+            fi
+          done
+
+          if [[ "$mergeable" == "true" ]]; then
+            echo "The PR can be merged, checking the merge commit $mergedSha"
+            echo "mergedSha=$mergedSha" >> "$GITHUB_ENV"
+          else
+            echo "The PR cannot be merged, it has a merge conflict, skipping the rest.."
+          fi
+      - uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
+        if: env.mergedSha
+        with:
+          # pull_request_target checks out the base branch by default
+          ref: ${{ env.mergedSha }}
+          # Fetches the merge commit and its parents
+          fetch-depth: 2
+      - name: Checking out base branch
+        if: env.mergedSha
+        run: |
+          base=$(mktemp -d)
+          git worktree add "$base" "$(git rev-parse HEAD^1)"
+          echo "base=$base" >> "$GITHUB_ENV"
+      - uses: cachix/install-nix-action@ba0dd844c9180cbf77aa72a116d6fbc515d0e87b # v27
+        if: env.mergedSha
+      - name: Fetching the pinned tool
+        if: env.mergedSha
+        # Update the pinned version using ci/nixpkgs-vet/update-pinned-tool.sh
+        run: |
+          # The pinned version of the tooling to use.
+          toolVersion=$(<ci/nixpkgs-vet/pinned-version.txt)
+
+          # Fetch the x86_64-linux-specific release artifact containing the gzipped NAR of the pre-built tool.
+          toolPath=$(curl -sSfL https://github.com/NixOS/nixpkgs-vet/releases/download/"$toolVersion"/x86_64-linux.nar.gz \
+            | gzip -cd | nix-store --import | tail -1)
+
+          # Adds a result symlink as a GC root.
+          nix-store --realise "$toolPath" --add-root result
+      - name: Running nixpkgs-vet
+        if: env.mergedSha
+        env:
+          # Force terminal colors to be enabled. The library that `nixpkgs-vet` uses respects https://bixense.com/clicolors/
+          CLICOLOR_FORCE: 1
+        run: |
+          if result/bin/nixpkgs-vet --base "$base" .; then
+            exit 0
+          else
+            exitCode=$?
+            echo "To run locally: ./ci/nixpkgs-vet.sh $GITHUB_BASE_REF https://github.com/$GITHUB_REPOSITORY.git"
+            echo "If you're having trouble, ping @NixOS/nixpkgs-vet"
+            exit "$exitCode"
+          fi

.github/workflows/update-terraform-providers.yml

@@ -46,7 +46,7 @@ jobs:
         run: |
           git clean -f
       - name: create PR
-        uses: peter-evans/create-pull-request@c5a7806660adbe173f04e3e038b0ccdcd758773c # v6.1.0
+        uses: peter-evans/create-pull-request@6cd32fd93684475c31847837f87bb135d40a2b79 # v7.0.3
         with:
           body: |
             Automatic update by [update-terraform-providers](https://github.com/NixOS/nixpkgs/blob/master/.github/workflows/update-terraform-providers.yml) action.

.mailmap

@@ -3,9 +3,11 @@ Anderson Torres <[email protected]>
 Atemu <[email protected]> <[email protected]>
 Daniel Løvbrøtte Olsen <[email protected]> <[email protected]>
 Fabian Affolter <[email protected]> <[email protected]>
-goatastronaut0212 <goatastronaut0212@proton.me> <goatastronaut0212@outlook.com>
+goatastronaut0212 <goatastronaut0212@outlook.com> <goatastronaut0212@proton.me>
 Janne Heß <[email protected]> <[email protected]>
 Jörg Thalheim <[email protected]> <[email protected]>
+Lin Jian <[email protected]> <[email protected]>
+Lin Jian <[email protected]> <[email protected]>
 Martin Weinelt <[email protected]> <[email protected]>
 R. RyanTM <[email protected]>
 Robert Hensing <[email protected]> <[email protected]>

CONTRIBUTING.md

@@ -315,6 +315,22 @@ When reviewing a pull request, please always be nice and polite. Controversial c
 
 GitHub provides reactions as a simple and quick way to provide feedback to pull requests or any comments. The thumb-down reaction should be used with care and if possible accompanied with some explanation so the submitter has directions to improve their contribution.
 
+When doing a review:
+- Aim to drive the proposal to a timely conclusion.
+- Focus on the proposed changes to keep the scope of the discussion narrow.
+- Help the contributor prioritise their efforts towards getting their change merged.
+
+If you find anything related that could be improved but is not immediately required for acceptance, consider
+- Implementing the changes yourself in a follow-up pull request (and request review from the person who inspired you)
+- Tracking your idea in an issue
+- Offering the original contributor to review a follow-up pull request
+- Making concrete [suggestions](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/incorporating-feedback-in-your-pull-request) in the same pull request.
+
+For example, follow-up changes could involve refactoring code in the affected files.
+
+But please remember not to make such additional considerations a blocker, and communicate that to the contributor, for example by following the [conventional comments](https://conventionalcomments.org/) pattern.
+If the related change is essential for the contribution at hand, make clear why you think it is important to address that first.
+
 Pull request reviews should include a list of what has been reviewed in a comment, so other reviewers and mergers can know the state of the review.
 
 All the review template samples provided in this section are generic and meant as examples. Their usage is optional and the reviewer is free to adapt them to their liking.
@@ -354,7 +370,7 @@ The following paragraphs about how to deal with unactive contributors is just a
 Please note that contributors with commit rights unactive for more than three months will have their commit rights revoked.
 -->
 
-Please see the discussion in [GitHub nixpkgs issue #50105](https://github.com/NixOS/nixpkgs/issues/50105) for information on how to proceed to be granted this level of access.
+Please see the discussion in [GitHub nixpkgs issue #321665](https://github.com/NixOS/nixpkgs/issues/321665) for information on how to proceed to be granted this level of access.
 
 In a case a contributor definitively leaves the Nix community, they should create an issue or post on [Discourse](https://discourse.nixos.org) with references of packages and modules they maintain so the maintainership can be taken over by other contributors.