Merge remote-tracking branch 'origin/staging-next' into staging

            into: staging-next

          - from: staging-next

            into: staging

          - from: master

            into: staging-nixos

    uses: ./.github/workflows/periodic-merge.yml

    with:

      from: ${{ matrix.pairs.from }}

          github_token: ${{ steps.app-token.outputs.token }}

      - name: Comment on failure

        uses: peter-evans/create-or-update-comment@71345be0265236311c031f5c7866368bd1eff043 # v4.0.0

        uses: peter-evans/create-or-update-comment@e8674b075228eee787fea43ef493e45ece1004c9 # v5.0.0

        if: ${{ failure() }}

        with:

          issue-number: 105153

Here's an overview of the different branches:

| branch | `master` | `staging-next` | `staging` |

| --- | --- | --- | --- |

| Used for development | ✔️ | ❌ | ✔️ |

| Built by Hydra | ✔️ | ✔️ | ❌ |

| [Mass rebuilds][mass-rebuild] | ❌ | ⚠️  Only to fix Hydra builds | ✔️ |

| Critical security fixes | ✔️ for non-mass-rebuilds | ✔️ for mass-rebuilds | ❌ |

| Automatically merged into | `staging-next` | `staging` | - |

| Manually merged into | - | `master` | `staging-next` |

| branch | `master` | `staging-next` | `staging` | [`staging-nixos`](#test-driver-rebuild) |

| --- | --- | --- | --- | --- |

| Used for development | ✔️ | ❌ | ✔️ | ✔️ |

| Built by Hydra | ✔️ | ✔️ | ❌ | ❌ |

| [Mass rebuilds][mass-rebuild] | ❌ | ⚠️  Only to fix Hydra builds | ✔️ | ❌[^1]  |

| Critical security fixes | ✔️ for non-mass-rebuilds | ✔️ for mass-rebuilds | ❌ | ✔️ |

| Automatically merged into | `staging-next` & `staging-nixos` | `staging` | - | - |

| Manually merged into | - | `master` | `staging-next` | `master` |

The staging workflow is used for all stable branches with corresponding names:

- `master`/`release-YY.MM`

- `staging`/`staging-YY.MM`

- `staging-next`/`staging-next-YY.MM`

[^1]: Except changes that cause no more rebuilds than kernel updates

# Conventions

## Branch conventions

As a rule of thumb, if the number of rebuilds is **500 or more**, consider targeting the `staging` branch instead of `master`; if the number is **1000 or more**, the pull request causes a mass rebuild, and should target the `staging` branch.

See [previously merged pull requests to the staging branches](https://github.com/NixOS/nixpkgs/issues?q=base%3Astaging+-base%3Astaging-next+is%3Amerged) to get a sense for what changes are considered mass rebuilds.

Please note that changes to the Linux kernel are an exception to this rule.

These PRs go to `staging-nixos`, see [the next section for more context](#changes-rebuilding-all-tests).

### Changes rebuilding all NixOS tests

[test-driver-rebuild]: #changes-rebuilding-all-tests

Changes causing a rebuild of all NixOS tests get a special [`10.rebuild-nixos-tests`](https://github.com/NixOS/nixpkgs/issues?q=state%3Aopen%20label%3A10.rebuild-nixos-tests) label.

These changes pose a significant impact on the build infrastructure.

Hence, these PRs should either target a `staging`-branch or `staging-nixos`, provided one of following conditions applies:

* The label `10.rebuild-nixos-tests` is set, or

* The PR is a change affecting the Linux kernel.

The branch gets merged whenever mainline kernel updates or critical security fixes land on the branch.

This usually happens on a weekly basis.

Backports are not handled by such a branch.

The relevant PRs from this branch must be backported manually.

## Commit conventions

[commit-conventions]: #commit-conventions

  release: ['development', 'primary'],

  staging: ['development', 'secondary'],

  'staging-next': ['development', 'secondary'],

  'staging-nixos': ['development', 'secondary'],

  'haskell-updates': ['development', 'secondary'],

  nixos: ['channel'],

  nixpkgs: ['channel'],

  master: 0,

  release: 1,

  staging: 2,

  'staging-nixos': 2,

  'haskell-updates': 3,

  'staging-next': 4,

}

## `fetchFromBitbucket` {#fetchfrombitbucket}

This is used with BitBucket repositories. The arguments expected are very similar to `fetchFromGitHub` above.

Used for repositories hosted on Bitbucket (`"bitbucket.org"`) owned by the Australian-based Atlassian Corporation. It requires an `owner` and `repo` argument which are both strings that reference the workspace ID and repository name hosted on Bitbucket cloud as well as either a `tag` or `rev` argument.

By default, `fetchFromBitbucket` will attempt to download a commit snapshot tarball at the specified `tag` or `rev` at `https://bitbucket.org/<owner>/<repo>/get/<tag-or-rev>.tar.gz`

However, `fetchFromBitbucket` will automatically switch to using `fetchgit` and fetch from `https://bitbucket.org/<owner>/<repo>.git` in any of these cases:

- `forceFetchGit`, `leaveDotGit`, `deepClone`, `fetchLFS`, or `fetchSubmodules` are set to `true`

- `sparseCheckout` contains any entries (is a non-empty list)

- `rootDir` is set to a non-empty string

When `fetchgit` is used, refer to the `fetchgit` section for documentation of its available options.

## `fetchFromSavannah` {#fetchfromsavannah}