Merge staging-next into staging

This commit is contained in:
nixpkgs-ci[bot]
2026-01-30 12:11:07 +00:00
committed by GitHub
133 changed files with 804 additions and 535 deletions

View File

@@ -10,18 +10,18 @@ Some architectural notes about key decisions and concepts in our workflows:
Thus they should be lowered to the minimum with `permissions: {}` in every workflow by default.
- By definition `pull_request_target` runs in the context of the **base** of the pull request.
This means, that the workflow files to run will be taken from the base branch, not the PR, and actions/checkout will not checkout the PR, but the base branch, by default.
This means that the workflow files to run will be taken from the base branch, not the PR, and actions/checkout will not checkout the PR, but the base branch, by default.
To protect our secrets, we need to make sure to **never execute code** from the pull request and always evaluate or build nix code from the pull request with the **sandbox enabled**.
- To test the pull request's contents, we checkout the "test merge commit".
This is a temporary commit that GitHub creates automatically as "what would happen, if this PR was merged into the base branch now?".
This is a temporary commit that GitHub creates automatically as "what would happen if this PR was merged into the base branch now?".
The checkout could be done via the virtual branch `refs/pull/<pr-number>/merge`, but doing so would cause failures when this virtual branch doesn't exist (anymore).
This can happen when the PR has conflicts, in which case the virtual branch is not created, or when the PR is getting merged while workflows are still running, in which case the branch won't exist anymore at the time of checkout.
Thus, we use the `prepare` job to check whether the PR is mergeable and the test merge commit exists and only then run the relevant jobs.
- Various workflows need to make comparisons against the base branch.
In this case, we checkout the parent of the "test merge commit" for best results.
Note, that this is not necessarily the same as the default commit that actions/checkout would use, which is also a commit from the base branch (see above), but might be older.
Note that this is not necessarily the same as the default commit that actions/checkout would use, which is also a commit from the base branch (see above), but might be older.
## Terminology

View File

@@ -680,7 +680,7 @@ If you have any problems with formatting, please ping the [formatting team](http
{ buildInputs = if stdenv.hostPlatform.isDarwin then [ iconv ] else null; }
```
As an exception, an explicit conditional expression with null can be used when fixing a important bug without triggering a mass rebuild.
As an exception, an explicit conditional expression with null can be used when fixing an important bug without triggering a mass rebuild.
If this is done a follow up pull request _should_ be created to change the code to `lib.optional(s)`.
- Any style choices not covered here but that can be expressed as general rules should be left at the discretion of the authors of changes and _not_ commented in reviews.
@@ -865,7 +865,7 @@ If someone approved and didn't merge a few days later, they most likely just for
Please see it as your responsibility to actively remind reviewers of your open PRs.
The easiest way to do so is to notify them via GitHub.
Github notifies people involved, whenever you add a comment or push to your PR or re-request their review.
GitHub notifies people involved, whenever you add a comment or push to your PR or re-request their review.
Doing any of that will get their attention again.
Everyone deserves proper attention, and yes, that includes you!
However, please be mindful that committers can sadly not always give everyone the attention they deserve.

View File

@@ -70,7 +70,7 @@ For more information about contributing to the project, please visit the [contri
The infrastructure for NixOS and related projects is maintained by a nonprofit organization, the [NixOS Foundation](https://nixos.org/nixos/foundation.html).
To ensure the continuity and expansion of the NixOS infrastructure, we are looking for donations to our organization.
You can donate to the NixOS foundation through [SEPA bank transfers](https://nixos.org/donate.html) or by using Open Collective:
You can donate to the NixOS Foundation through [SEPA bank transfers](https://nixos.org/donate.html) or by using Open Collective:
<a href="https://opencollective.com/nixos#support"><img src="https://opencollective.com/nixos/tiers/supporter.svg?width=890" /></a>

View File

@@ -24,7 +24,7 @@ The Nixpkgs merge bot empowers package maintainers by enabling them to merge PRs
It serves as a bridge for maintainers to quickly respond to user feedback, facilitating a more self-reliant approach.
Especially when considering there are roughly 20 maintainers for every committer, this bot is a game-changer.
Following [RFC 172] the merge bot was originally implemented as a [python webapp](https://github.com/NixOS/nixpkgs-merge-bot), which has now been integrated into [`ci/github-script/bot.js`](./github-script/bot.js) and [`ci/github-script/merge.js`](./github-script/merge.js).
Following [RFC 172], the merge bot was originally implemented as a [python webapp](https://github.com/NixOS/nixpkgs-merge-bot), which has now been integrated into [`ci/github-script/bot.js`](./github-script/bot.js) and [`ci/github-script/merge.js`](./github-script/merge.js).
### Using the merge bot

View File

@@ -19,7 +19,7 @@ The following arguments can be used to fine-tune performance:
- `--max-jobs`: The maximum number of derivations to run at the same time.
Only each [supported system](../supportedSystems.json) gets a separate derivation, so it doesn't make sense to set this higher than that number.
- `--cores`: The number of cores to use for each job.
Recommended to set this to the amount of cores on your system divided by `--max-jobs`.
Recommended to set this to the number of cores on your system divided by `--max-jobs`.
- `--arg chunkSize`: The number of attributes that are evaluated simultaneously on a single core.
Lowering this decreases memory usage at the cost of increased evaluation time.
If this is too high, there won't be enough chunks to process them in parallel, and will also increase evaluation time.

View File

@@ -111,7 +111,7 @@ This syntax is taken from [MyST](https://myst-parser.readthedocs.io/en/latest/us
#### HTML
Inlining HTML is not allowed.
Parts of the documentation gets rendered to various non-HTML formats, such as man pages in the case of NixOS manual.
Parts of the documentation get rendered to various non-HTML formats, such as man pages in the case of NixOS manual.
#### Roles
@@ -407,7 +407,7 @@ To define a referenceable figure use the following fencing:
:::
```
Defining figures through the `figure` fencing class adds them to a `List of Figures` after the `Table of Contents`.
Defining figures through the `figure` fencing class adds them to a `List of Figures` after the `Table of Contents`.
Though this is not shown in the rendered documentation on nixos.org.
#### Footnotes

View File

@@ -4,7 +4,7 @@ The `nix-shell` command has popularized the concept of transient shell environme
<!--
We should try to document the product, not its development process in the Nixpkgs reference manual,
but *something* needs to be said to provide context for this library.
This is the most future proof sentence I could come up with while Nix itself does yet make use of this.
This is the most future proof sentence I could come up with while Nix itself does not yet make use of this.
Relevant is the current status of the devShell attribute "project": https://github.com/NixOS/nix/issues/7501
-->
However, `nix-shell` is not the only way to create such environments, and even `nix-shell` itself can indirectly benefit from this library.
@@ -60,7 +60,7 @@ devShellTools.unstructuredDerivationInputEnv {
#}
```
Note that `args` is not included, because Nix does not added it to the builder process environment.
Note that `args` is not included, because Nix does not add it to the builder process environment.
:::

View File

@@ -536,7 +536,7 @@ See [](#chap-pkgs-fetchers-caveats) for more details on how to work with the `ha
Returns a [fixed-output derivation](https://nixos.org/manual/nix/stable/glossary.html#gloss-fixed-output-derivation) which downloads an archive from a given URL and decompresses it.
Despite its name, `fetchzip` is not limited to `.zip` files but can also be used with [various compressed tarball formats](#tar-files) by default.
This can extended by specifying additional attributes, see [](#ex-fetchers-fetchzip-rar-archive) to understand how to do that.
This can be extended by specifying additional attributes, see [](#ex-fetchers-fetchzip-rar-archive) to understand how to do that.
### Inputs {#sec-pkgs-fetchers-fetchzip-inputs}
@@ -765,7 +765,7 @@ Used with Subversion. Expects `url` to a Subversion directory, `rev`, and `hash`
## `fetchgit` {#fetchgit}
Used with Git. Expects `url` to a Git repo, `rev` or `tag`, and `hash`. `rev` in this case can be full the git commit id (SHA1 hash), or use `tag` for a tag name like `refs/tags/v1.0`.
Used with Git. Expects `url` to a Git repo, `rev` or `tag`, and `hash`. `rev` in this case can be the full git commit id (SHA1 hash), or use `tag` for a tag name like `refs/tags/v1.0`.
If you want to fetch a tag you should pass the `tag` parameter instead of `rev` which has the same effect as setting `rev = "refs/tags"/${version}"`.
This is safer than just setting `rev = version` w.r.t. possible branch and tag name conflicts.
@@ -799,7 +799,7 @@ Additionally, the following optional arguments can be given:
*`deepClone`* (Boolean)
: Clone the entire repository as opposing to just creating a shallow clone.
: Clone the entire repository as opposed to just creating a shallow clone.
This implies `leaveDotGit`.
*`fetchTags`* (Boolean)

View File

@@ -8,7 +8,7 @@ Build helpers don't always support fixed-point arguments yet, as support in [`st
Developers can use the Nixpkgs library function [`lib.customisation.extendMkDerivation`](#function-library-lib.customisation.extendMkDerivation) to define a build helper supporting fixed-point arguments from an existing one with such support, with an attribute overlay similar to the one taken by [`<pkg>.overrideAttrs`](#sec-pkg-overrideAttrs).
Besides overriding, `lib.extendMkDerivation` also supports `excludeDrvArgNames` to optionally exclude some arguments in the input fixed-point arguments from passing down the base build helper (specified as `constructDrv`).
Besides overriding, `lib.extendMkDerivation` also supports `excludeDrvArgNames` to optionally exclude some arguments in the input fixed-point arguments from passing down to the base build helper (specified as `constructDrv`).
:::{.example #ex-build-helpers-extendMkDerivation}

View File

@@ -73,7 +73,7 @@ Similarly, if you encounter errors similar to `Error_Protocol ("certificate has
A value of `null` means that `buildImage` will use the first image available in the repository.
:::{.note}
This must be used with `fromImageName`. Using only `fromImageTag` without `fromImageName` will make `buildImage` use the first image available in the repository
This must be used with `fromImageName`. Using only `fromImageTag` without `fromImageName` will make `buildImage` use the first image available in the repository.
:::
_Default value:_ `null`.
@@ -1013,7 +1013,7 @@ Because of this, using this function requires the `kvm` device to be available,
A value of `null` means that `exportImage` will use the first image available in the repository.
:::{.note}
This must be used with `fromImageName`. Using only `fromImageTag` without `fromImageName` will make `exportImage` use the first image available in the repository
This must be used with `fromImageName`. Using only `fromImageTag` without `fromImageName` will make `exportImage` use the first image available in the repository.
:::
_Default value:_ `null`.
@@ -1145,7 +1145,7 @@ $ file /nix/store/by3f40xvc4l6bkis74l0fj4zsy0djgkn-hello.tar.gz
/nix/store/by3f40xvc4l6bkis74l0fj4zsy0djgkn-hello.tar.gz: POSIX tar archive (GNU)
```
If the archive was actually compressed, the output of file would've mentioned that fact.
If the archive was actually compressed, the output of `file` would've mentioned that fact.
Because of this, it may be important to set a proper `name` attribute when using `exportImage` with other functions from `dockerTools`.
:::

View File

@@ -8,7 +8,7 @@ This function can create images in two ways:
- using a virtual machine to create a full NixOS installation.
When testing early-boot or lifecycle parts of NixOS such as a bootloader or multiple generations, it is necessary to opt for a full NixOS system installation.
Whereas for many web servers, applications, it is possible to work with a Nix store only disk image and is faster to build.
Whereas for many web servers and applications, it is possible to work with a Nix store only disk image, which is faster to build.
NixOS tests also use this function when preparing the VM. The `cptofs` method is used when `virtualisation.useBootLoader` is false (the default). Otherwise the second method is used.
@@ -39,7 +39,7 @@ Features are separated in various sections depending on if you opt for a Nix-sto
### On bit-to-bit reproducibility {#sec-make-disk-image-features-reproducibility}
Images are **NOT** deterministic, please do not hesitate to try to fix this, source of determinisms are (not exhaustive) :
Images are **NOT** deterministic. Please do not hesitate to try to fix this. Sources of non-determinism are (not exhaustive):
- bootloader installation has timestamps
- SQLite Nix store database contains registration times

View File

@@ -5,8 +5,8 @@ It makes no assumptions about the container runner you choose to use to run the
The set of functions in `pkgs.ociTools` currently does not handle the [OCI image specification](https://github.com/opencontainers/image-spec).
At a high-level an OCI implementation would download an OCI Image then unpack that image into an OCI Runtime filesystem bundle.
At this point the OCI Runtime Bundle would be run by an OCI Runtime.
At a high level, an OCI implementation would download an OCI Image then unpack that image into an OCI Runtime filesystem bundle.
At this point, the OCI Runtime Bundle would be run by an OCI Runtime.
`pkgs.ociTools` provides utilities to create OCI Runtime bundles.
## buildContainer {#ssec-pkgs-ociTools-buildContainer}
@@ -54,7 +54,7 @@ Note that no user namespace is created, which means that you won't be able to ru
`os` **DEPRECATED**
: Specifies the operating system on which the container filesystem is based on.
: Specifies the operating system on which the container filesystem is based.
If specified, its value should follow the [OCI Image Configuration Specification](https://github.com/opencontainers/image-spec/blob/main/config.md#properties).
According to the linked specification, all possible values for `$GOOS` in [the Go docs](https://go.dev/doc/install/source#environment) should be valid, but will commonly be one of `darwin` or `linux`.

View File

@@ -6,7 +6,7 @@ For hermeticity, Nix derivations do not allow any state to be carried over betwe
However, we can tell Nix explicitly what the previous build state was, by representing that previous state as a derivation output. This allows the passed build state to be used for an incremental build.
To change a normal derivation to a checkpoint based build, these steps must be taken:
To change a normal derivation to a checkpoint-based build, these steps must be taken:
```nix
{
checkpointArtifacts = (pkgs.checkpointBuildTools.prepareCheckpointBuild pkgs.virtualbox);

View File

@@ -14,11 +14,11 @@ Accepted arguments are:
- `executableName`
The name of the wrapper executable. Defaults to `pname` if set, or `name` otherwise.
- `targetPkgs`
Packages to be installed for the main host's architecture (i.e. x86_64 on x86_64 installations). Along with libraries binaries are also installed.
Packages to be installed for the main host's architecture (i.e. x86_64 on x86_64 installations). Along with libraries, binaries are also installed.
- `multiPkgs`
Packages to be installed for all architectures supported by a host (i.e. i686 and x86_64 on x86_64 installations). Only libraries are installed by default.
- `multiArch`
Whether to install 32bit multiPkgs into the FHSEnv in 64bit environments
Whether to install 32-bit multiPkgs into the FHSEnv in 64-bit environments
- `extraBuildCommands`
Additional commands to be executed for finalizing the directory structure.
- `extraBuildCommandsMulti`

View File

@@ -1,6 +1,6 @@
# pkgs.makeSetupHook {#sec-pkgs.makeSetupHook}
`pkgs.makeSetupHook` is a build helper that produces hooks that go in to `nativeBuildInputs`
`pkgs.makeSetupHook` is a build helper that produces hooks that go into `nativeBuildInputs`
## Usage {#sec-pkgs.makeSetupHook-usage}

View File

@@ -136,7 +136,7 @@ A set of functions that build a predefined set of minimal Linux distributions im
### Attributes {#vm-tools-diskImageFuns-attributes}
* `size` (optional, defaults to `4096`). The size of the image, in MiB.
* `extraPackages` (optional). A list names of additional packages from the distribution that should be included in the image.
* `extraPackages` (optional). A list of names of additional packages from the distribution that should be included in the image.
### Examples {#vm-tools-diskImageFuns-examples}

View File

@@ -63,7 +63,7 @@ Note the moduleNames used in cmake find_package are case sensitive.
Check a packaged static site's links with the [`lychee` package](https://search.nixos.org/packages?show=lychee&type=packages&query=lychee).
You may use Nix to reproducibly build static websites, such as for software documentation.
Some packages will install documentation in their `out` or `doc` outputs, or maybe you have dedicated package where you've made your static site reproducible by running a generator, such as [Hugo](https://gohugo.io/) or [mdBook](https://rust-lang.github.io/mdBook/), in a derivation.
Some packages will install documentation in their `out` or `doc` outputs, or maybe you have a dedicated package where you've made your static site reproducible by running a generator, such as [Hugo](https://gohugo.io/) or [mdBook](https://rust-lang.github.io/mdBook/), in a derivation.
If you have a static site that can be built with Nix, you can use `lycheeLinkCheck` to check that the hyperlinks in your site are correct, and do so as part of your Nix workflow and CI.
@@ -578,7 +578,7 @@ Use the derivation hash to invalidate the output via name, for testing.
Type: `(a@{ name, ... } -> Derivation) -> a -> Derivation`
Normally, fixed output derivations can and should be cached by their output hash only, but for testing we want to re-fetch everytime the fetcher changes.
Normally, fixed output derivations can and should be cached by their output hash only, but for testing we want to re-fetch every time the fetcher changes.
Changes to the fetcher become apparent in the drvPath, which is a hash of how to fetch, rather than a fixed store path.
By inserting this hash into the name, we can make sure to re-run the fetcher every time the fetcher changes.

View File

@@ -8,7 +8,7 @@ Like [`stdenv.mkDerivation`](#sec-using-stdenv), each of these build helpers cre
The function `runCommandWith` returns a derivation built using the specified command(s), in a specified environment.
It is the underlying base function of all [`runCommand*` variants].
It is the underlying base function of all [`runCommand*` variants].
The general behavior is controlled via a single attribute set passed
as the first argument, and allows specifying `stdenv` freely.
@@ -45,7 +45,7 @@ runCommandWith :: {
:::
`stdenv` (Derivation)
: The [standard environment](#chap-stdenv) to use, defaulting to `pkgs.stdenv`
: The [standard environment](#chap-stdenv) to use, defaulting to `pkgs.stdenv`.
`derivationArgs` (Attribute set)
: Additional arguments for [`mkDerivation`](#sec-using-stdenv).
@@ -160,7 +160,7 @@ runCommandWith { inherit name derivationArgs; } buildCommand
## Writing text files {#trivial-builder-text-writing}
Nixpkgs provides the following functions for producing derivations which write text files or executable scripts into the Nix store.
They are useful for creating files from Nix expression, and are all implemented as convenience wrappers around `writeTextFile`.
They are useful for creating files from Nix expressions, and are all implemented as convenience wrappers around `writeTextFile`.
Each of these functions will cause a derivation to be produced.
When you coerce the result of each of these functions to a string with [string interpolation](https://nixos.org/manual/nix/stable/language/string-interpolation) or [`toString`](https://nixos.org/manual/nix/stable/language/builtins#builtins-toString), it will evaluate to the [store path](https://nixos.org/manual/nix/stable/store/store-path) of this derivation.
@@ -682,7 +682,7 @@ writeTextFile {
## `concatTextFile`, `concatText`, `concatScript` {#trivial-builder-concatText}
These functions concatenate `files` to the Nix store in a single file. This is useful for configuration files structured in lines of text. `concatTextFile` takes an attribute set and expects two arguments, `name` and `files`. `name` corresponds to the name used in the Nix store path. `files` will be the files to be concatenated. You can also set `executable` to true to make this file have the executable bit set.
`concatText` and`concatScript` are simple wrappers over `concatTextFile`.
`concatText` and `concatScript` are simple wrappers over `concatTextFile`.
Here are a few examples:
```nix

View File

@@ -2,6 +2,6 @@
* Make sure you have a [GitHub account](https://github.com/signup/free)
* Make sure there is no open issue on the topic
* [Submit a new issue](https://github.com/NixOS/nixpkgs/issues/new/choose) by choosing the kind of topic and fill out the template
* [Submit a new issue](https://github.com/NixOS/nixpkgs/issues/new/choose) by choosing the kind of topic and filling out the template
<!-- In the future this section could also include more detailed information on the issue templates -->

View File

@@ -28,7 +28,7 @@ Packages, including the Nix packages collection, are distributed through
[channels](https://nixos.org/nix/manual/#sec-channels). The collection is
distributed for users of Nix on non-NixOS distributions through the channel
`nixpkgs-unstable`. Users of NixOS generally use one of the `nixos-*` channels,
e.g. `nixos-22.11`, which includes all packages and modules for the stable NixOS
e.g., `nixos-22.11`, which includes all packages and modules for the stable NixOS
22.11. Stable NixOS releases are generally only given
security updates. More up-to-date packages and modules are available via the
`nixos-unstable` channel.
@@ -36,7 +36,7 @@ security updates. More up-to-date packages and modules are available via the
Both `nixos-unstable` and `nixpkgs-unstable` follow the `master` branch of the
Nixpkgs repository, although both do lag the `master` branch by generally
[a couple of days](https://status.nixos.org/). Updates to a channel are
distributed as soon as all tests for that channel pass, e.g.
distributed as soon as all tests for that channel pass, e.g.,
[this table](https://hydra.nixos.org/job/nixpkgs/trunk/unstable#tabs-constituents)
shows the status of tests for the `nixpkgs-unstable` channel.
@@ -47,4 +47,4 @@ The binaries are made available via a [binary cache](https://cache.nixos.org).
The current Nix expressions of the channels are available in the
[Nixpkgs repository](https://github.com/NixOS/nixpkgs) in branches
that correspond to the channel names (e.g. `nixos-22.11-small`).
that correspond to the channel names (e.g., `nixos-22.11-small`).

View File

@@ -16,7 +16,7 @@ It should have the following properties:
Non-goals are:
- Efficient:
If the abstraction proves itself worthwhile but too slow, it can be still be optimized further.
If the abstraction proves itself worthwhile but too slow, it can still be optimized further.
## Tests
@@ -90,7 +90,7 @@ One of the following:
- `"regular"`, `"symlink"`, `"unknown"` or any other non-`"directory"` string:
A nested file with its file type.
These specific strings are chosen to be compatible with `builtins.readDir` for a simpler implementation.
Distinguishing between different file types is not strictly necessary for the functionality this library,
Distinguishing between different file types is not strictly necessary for the functionality of this library,
but it does allow nicer printing of file sets.
- `null`:
@@ -127,7 +127,7 @@ Arguments:
### Empty file set without a base
There is a special representation for an empty file set without a base path.
This is used for return values that should be empty but when there's no base path that would makes sense.
This is used for return values that should be empty but when there's no base path that would make sense.
Arguments:
- Alternative: This could also be represented using `_internalBase = /.` and `_internalTree = null`.

View File

@@ -169,7 +169,7 @@ See its [README](./scripts/README.md) for further information.
# nixpkgs-merge-bot
To streamline autoupdates, leverage the nixpkgs-merge-bot by commenting `@NixOS/nixpkgs-merge-bot merge` if the package resides in pkgs-by-name, the commenter is among the package maintainers, and the pull request author is @r-ryantm or a Nixpkgs committer.
To streamline autoupdates, leverage the nixpkgs-merge-bot by commenting `@NixOS/nixpkgs-merge-bot merge` if the package resides in `pkgs/by-name`, the commenter is among the package maintainers, and the pull request author is @r-ryantm or a Nixpkgs committer.
The bot ensures that all ofborg checks, except for darwin, are successfully completed before merging the pull request.
Should the checks still be underway, the bot patiently waits for ofborg to finish before attempting the merge again.

View File

@@ -47,7 +47,7 @@ robustly than text search through `maintainer-list.nix`.
The maintainer is designated by a `selector` which must be one of:
- `handle` (default): the maintainer's attribute name in `lib.maintainers`;
- `email`, `name`, `github`, `githubId`, `matrix`, `name`:
- `email`, `name`, `github`, `githubId`, `matrix`:
attributes of the maintainer's object, matched exactly; see [`maintainer-list.nix`] for the fields' definition.
[`maintainer-list.nix`]: ../maintainer-list.nix

View File

@@ -4,12 +4,12 @@ Currently `nixpkgs` builds most of its packages using bootstrap seed binaries (w
- `bootstrap-tools`: an archive with the compiler toolchain and other helper tools enough to build the rest of the `nixpkgs`.
- initial binaries needed to unpack `bootstrap-tools.*`.
On `linux` it's just `busybox`, on `darwin` and `freebsd` it is unpack.nar.xz which contains the binaries and script needed to unpack the tools.
On `linux` it's just `busybox`, on `darwin` and `freebsd` it is `unpack.nar.xz` which contains the binaries and script needed to unpack the tools.
These binaries can be executed directly from the store.
These are called "bootstrap files".
Bootstrap files should always be fetched from hydra and uploaded to `tarballs.nixos.org` to guarantee that all the binaries were built from the code committed into `nixpkgs` repository.
Bootstrap files should always be fetched from Hydra and uploaded to `tarballs.nixos.org` to guarantee that all the binaries were built from the code committed into `nixpkgs` repository.
The uploads to `tarballs.nixos.org` are done by `@NixOS/infra` team members who have S3 write access.
@@ -93,7 +93,7 @@ To do that you will need the following:
2. Add your new target to `pkgs/stdenv/linux/make-bootstrap-tools-cross.nix`.
This will add a new hydra job to `nixpkgs:cross-trunk` jobset.
3. Wait for a hydra to build your bootstrap tarballs.
3. Wait for a Hydra to build your bootstrap tarballs.
4. Add your new target to `maintainers/scripts/bootstrap-files/refresh-tarballs.bash` around `CROSS_TARGETS=()`.
@@ -103,15 +103,15 @@ To do that you will need the following:
There are two types of bootstrap files:
- natively built `stdenvBootstrapTools.build` hydra jobs in [`nixpkgs:trunk`](https://hydra.nixos.org/jobset/nixpkgs/trunk#tabs-jobs) jobset.
- natively built `stdenvBootstrapTools.build` Hydra jobs in [`nixpkgs:trunk`](https://hydra.nixos.org/jobset/nixpkgs/trunk#tabs-jobs) jobset.
Incomplete list of examples is:
* `aarch64-unknown-linux-musl.nix`
* `i686-unknown-linux-gnu.nix`
These are Tier 1 hydra platforms.
These are Tier 1 Hydra platforms.
- cross-built by `bootstrapTools.build` hydra jobs in [`nixpkgs:cross-trunk`](https://hydra.nixos.org/jobset/nixpkgs/cross-trunk#tabs-jobs) jobset.
- cross-built by `bootstrapTools.build` Hydra jobs in [`nixpkgs:cross-trunk`](https://hydra.nixos.org/jobset/nixpkgs/cross-trunk#tabs-jobs) jobset.
Incomplete list of examples is:
* `mips64el-unknown-linux-gnuabi64.nix`

View File

@@ -105,7 +105,7 @@ in
# parallels
hardware.parallels.enable = lib.mkIf cfg.parallels.enable (lib.mkDefault true);
nixpkgs.config = lib.mkIf (!options.nixpkgs.pkgs.isDefined && cfg.parallels.enable) {
allowUnfreePredicate = pkg: builtins.elem (lib.getName pkg) [ "prl-tools" ];
allowUnfreePackages = [ "prl-tools" ];
};
};
}

View File

@@ -228,7 +228,7 @@ in
contents = {
"/EFI/BOOT/BOOTX64.EFI".source =
"''${pkgs.systemd}/lib/systemd/boot/efi/systemd-bootx64.efi";
}
};
repartConfig = {
Type = "esp";
Format = "vfat";

View File

@@ -300,7 +300,7 @@ if ($virt eq "oracle") {
# It is blocked by https://github.com/systemd/systemd/pull/23859
if ($virt eq "parallels") {
push @attrs, "hardware.parallels.enable = true;";
push @attrs, "nixpkgs.config.allowUnfreePredicate = pkg: builtins.elem (lib.getName pkg) [ \"prl-tools\" ];";
push @attrs, "nixpkgs.config.allowUnfreePackages = [ \"prl-tools\" ];";
}
# Likewise for QEMU.

View File

@@ -20,28 +20,49 @@ in
package = lib.mkPackageOption pkgs "nixos-init" { };
};
config = lib.mkIf cfg.enable {
assertions = [
{
assertion = config.boot.initrd.systemd.enable;
message = "nixos-init can only be used with boot.initrd.systemd.enable";
}
{
assertion = config.system.etc.overlay.enable;
message = "nixos-init can only be used with system.etc.overlay.enable";
}
{
assertion = config.services.userborn.enable || config.systemd.sysusers.enable;
message = "nixos-init can only be used with services.userborn.enable or systemd.sysusers.enable";
}
{
assertion = config.boot.postBootCommands == "";
message = "nixos-init cannot be used with boot.postBootCommands";
}
{
assertion = config.powerManagement.powerUpCommands == "";
message = "nixos-init cannot be used with powerManagement.powerUpCommands";
}
];
};
config = lib.mkMerge [
{
boot.bootspec.extensions = {
"org.nixos.nixos-init.v1" = {
firmware = "${config.hardware.firmware}/lib/firmware";
modprobe_binary = "${pkgs.kmod}/bin/modprobe";
nix_store_mount_opts = config.boot.nixStoreMountOpts;
}
// lib.optionalAttrs (config.environment.binsh != null) {
sh_binary = config.environment.binsh;
}
// lib.optionalAttrs (config.environment.usrbinenv != null) {
env_binary = config.environment.usrbinenv;
}
// lib.optionalAttrs config.system.etc.overlay.enable {
etc_metadata_image = config.system.build.etcMetadataImage;
etc_basedir = config.system.build.etcBasedir;
};
};
}
(lib.mkIf cfg.enable {
assertions = [
{
assertion = config.boot.initrd.systemd.enable;
message = "nixos-init can only be used with boot.initrd.systemd.enable";
}
{
assertion = config.system.etc.overlay.enable;
message = "nixos-init can only be used with system.etc.overlay.enable";
}
{
assertion = config.services.userborn.enable || config.systemd.sysusers.enable;
message = "nixos-init can only be used with services.userborn.enable or systemd.sysusers.enable";
}
{
assertion = config.boot.postBootCommands == "";
message = "nixos-init cannot be used with boot.postBootCommands";
}
{
assertion = config.powerManagement.powerUpCommands == "";
message = "nixos-init cannot be used with powerManagement.powerUpCommands";
}
];
})
];
}

View File

@@ -33,11 +33,6 @@ let
ln -s ${config.system.build.etc}/etc $out/etc
${lib.optionalString config.system.etc.overlay.enable ''
ln -s ${config.system.build.etcMetadataImage} $out/etc-metadata-image
ln -s ${config.system.build.etcBasedir} $out/etc-basedir
''}
ln -s ${config.system.path} $out/sw
ln -s "$systemd" $out/systemd

View File

@@ -733,17 +733,6 @@ in
cfg.package.util-linux
config.system.nixos-init.package
];
environment = {
FIRMWARE = "${config.hardware.firmware}/lib/firmware";
MODPROBE_BINARY = "${pkgs.kmod}/bin/modprobe";
NIX_STORE_MOUNT_OPTS = lib.concatStringsSep "," config.boot.nixStoreMountOpts;
}
// lib.optionalAttrs (config.environment.usrbinenv != null) {
ENV_BINARY = config.environment.usrbinenv;
}
// lib.optionalAttrs (config.environment.binsh != null) {
SH_BINARY = config.environment.binsh;
};
serviceConfig = {
ExecStart = [
""

View File

@@ -1,4 +1,4 @@
{ lib, ... }:
{ ... }:
{
name = "commafeed";

View File

@@ -60,7 +60,7 @@
];
# unrar is unfree
nixpkgs.config.allowUnfreePredicate = pkg: builtins.elem (lib.getName pkg) [ "unrar" ];
nixpkgs.config.allowUnfreePackages = [ "unrar" ];
};
testScript = ''

View File

@@ -20,7 +20,7 @@ See the [CONTRIBUTING.md](../CONTRIBUTING.md) document for more general informat
- [`pkgs-lib`](./pkgs-lib): Definitions for utilities that need packages but are not needed for packages
- [`test`](./test): Tests not directly associated with any specific packages
- [`by-name`](./by-name): Top-level packages organised by name ([docs](./by-name/README.md))
- All other directories loosely categorise top-level packages definitions, see [category hierarchy][categories]
- All other directories loosely categorise top-level package definitions, see [category hierarchy][categories]
## Quick Start to Adding a Package
@@ -148,7 +148,7 @@ To add a package to Nixpkgs:
- All other [`meta`](https://nixos.org/manual/nixpkgs/stable/#chap-meta) attributes are optional, but its still a good idea to provide at least the `description`, `homepage` and [`license`](https://nixos.org/manual/nixpkgs/stable/#sec-meta-license).
- The exact syntax and semantics of the Nix expression language, including the built-in functions, are [Nix language reference](https://nixos.org/manual/nix/stable/language/).
- The exact syntax and semantics of the Nix expression language, including the built-in functions, can be found in the [Nix language reference](https://nixos.org/manual/nix/stable/language/).
5. To test whether the package builds, run the following command from the root of the nixpkgs source tree:
@@ -437,7 +437,7 @@ Follow these guidelines:
- It _must_ be a valid identifier in Nix.
- If the `pname` starts with a digit, the attribute name _should_ be prefixed with an underscore.
Otherwise the attribute name _should not_ be prefixed with an underline.
Otherwise the attribute name _should not_ be prefixed with an underscore.
Example: The corresponding attribute name for `0ad` should be `_0ad`.
@@ -460,7 +460,7 @@ Follow these guidelines:
## Versioning
[versioning]: #versioning
These are the guidelines the `version` attribute of a package:
These are the guidelines for the `version` attribute of a package:
- It _must_ start with a digit.
This is required for backwards-compatibility with [how `nix-env` parses derivation names](https://nix.dev/manual/nix/latest/command-ref/nix-env#selectors).
@@ -487,7 +487,7 @@ See also [`pkgs/by-name/README.md`'s section on this topic](https://github.com/N
## Meta attributes
The `meta` attribute set should always be placed last in the derivativion and any other "meta"-like attribute sets like `passthru` should be written before it.
The `meta` attribute set should always be placed last in the derivation and any other "meta"-like attribute sets like `passthru` should be written before it.
* `meta.description` must:
* Be short, just one sentence.
@@ -655,7 +655,7 @@ The latter avoids link rot when the upstream abandons, squashes or rebases their
{ patches = [ ./0001-add-missing-include.patch ]; }
```
If you do need to do create this sort of patch file, one way to do so is with git:
If you do need to create this sort of patch file, one way to do so is with git:
1. Move to the root directory of the source code you're patching.
@@ -730,7 +730,7 @@ We use jbidwatcher as an example for a discontinued project here.
1. Create a pull request against Nixpkgs.
Mention the package maintainer.
This is how the pull request looks like in this case: [https://github.com/NixOS/nixpkgs/pull/116470](https://github.com/NixOS/nixpkgs/pull/116470)
This is what the pull request looks like in this case: [https://github.com/NixOS/nixpkgs/pull/116470](https://github.com/NixOS/nixpkgs/pull/116470)
## Package tests
@@ -743,7 +743,7 @@ To run the main types of tests locally:
Tests are important to ensure quality and make reviews and automatic updates easy.
The following types of tests exists:
The following types of tests exist:
* [NixOS **module tests**](https://nixos.org/manual/nixos/stable/#sec-nixos-tests), which spawn one or more NixOS VMs.
They exercise both NixOS modules and the packaged programs used within them.
@@ -1137,7 +1137,7 @@ Sample template for a package update review is provided below.
### New packages
New packages are a common type of pull requests.
These pull requests consist in adding a new nix-expression for a package.
These pull requests consist of adding a new nix-expression for a package.
Review process:
@@ -1146,7 +1146,7 @@ Review process:
- Ensure that the package versioning [fits the guidelines](#versioning).
- Ensure that the commit text [fits the guidelines](../CONTRIBUTING.md#commit-conventions).
- Ensure that the source is fetched from an official location, one of our [trusted mirrors](./build-support/fetchurl/mirrors.nix), or a mirror trusted by the authors.
- Ensure that the meta fields [fits the guidelines](#meta-attributes) and contain the correct information:
- Ensure that the meta fields [fit the guidelines](#meta-attributes) and contain the correct information:
- License must match the upstream license.
- Platforms should be set (or the package will not get binary substitutes).
- Maintainers must be set.
@@ -1250,7 +1250,7 @@ Note that there can be an extra comment containing links to previously reported
#### Triaging and Fixing
**Note**: An issue can be a "false positive" (i.e. automatically opened, but without the package it refers to being actually vulnerable).
If you find such a "false positive", comment on the issue an explanation of why it falls into this category, linking as much information as the necessary to help maintainers double check.
If you find such a "false positive", comment on the issue an explanation of why it falls into this category, linking as much information as necessary to help maintainers double check.
If you are investigating a "true positive":

View File

@@ -8,9 +8,9 @@ The jdk is in `pkgs/development/compilers/jetbrains-jdk`.
## How to use plugins:
- Pass your IDE package and a list of plugin packages to `jetbrains.plugins.addPlugins`.
E.g. `pkgs.jetbrains.plugins.addPlugins pkgs.jetbrains.idea [ ideavim ]`
- The list has to contain contain drvs giving the directory contents of the plugin or a single `.jar` (executable).
- The list has to contain drvs giving the directory contents of the plugin or a single `.jar` (executable).
Nixpkgs does not package Jetbrains plugins, however you can use third-party sources, such as
Nixpkgs does not package JetBrains plugins, however you can use third-party sources, such as
[nix-jetbrains-plugins](https://github.com/nix-community/nix-jetbrains-plugins).
Note that some plugins may not work without modification, if they are packaged in a way that is incompatible with NixOS.
You can try installing such plugins from within the IDE instead.
@@ -68,7 +68,7 @@ Any comments or other manual changes between these markers will be removed when
- from source builds:
- remove timestamps in output `.jar` of `jps-bootstrap`
- automated update scripts
- fetch `.jar` s from stuff built in nixpkgs when available
- fetch `.jar`s from stuff built in nixpkgs when available
- what stuff built in nixpkgs provides `.jar`s we care about?
- kotlin
- make `configurePhase` respect `$NIX_BUILD_CORES`

View File

@@ -9,7 +9,7 @@
* Currently `nixfmt-rfc-style` formatter is being used to format the VSCode extensions.
* Respect `alphabetical order` whenever adding extensions. On disorder, please, kindly open a PR re-establishing the order.
* Respect `alphabetical order` whenever adding extensions. If out of order, please kindly open a PR re-establishing the order.
* Avoid [unnecessary](https://nix.dev/guides/best-practices.html#with-scopes) use of `with`, particularly `nested with`.
@@ -27,7 +27,7 @@
- maintainers are listed in alphabetical order.
- verify `license` in upstream.
* On commit messages:
* Commit messages:
- Naming convention for:
- Adding a new extension:

View File

@@ -9,8 +9,8 @@ The basic steps to add a new core are:
1. Add a new core using `mkLibretroCore` function (use one of the existing
cores as an example)
2. Add your new core to [`default.nix`](./default.nix) file
3. Try to build your core with `nix-build -A libretro.<core>`
2. Add your new core to [`default.nix`](./default.nix) file.
3. Try to build your core with `nix-build -A libretro.<core>`.
## Using RetroArch with cores

View File

@@ -37,7 +37,7 @@ let
src = fetchurl {
url = "https://assets.unigine.com/d/Unigine_Superposition-${version}.run";
sha256 = "12hzlz792pf8pvxf13fww3qhahqzwzkxq9q3mq20hbhvaphbg7nd";
hash = "sha256-dJThxzv1nvIWFRPV1cudm/+9hHmSnUl2rFO2lV3lgPg=";
};
nativeBuildInputs = [

View File

@@ -11,8 +11,8 @@
- `ungoogled-chromium`: A patch set for Chromium, that has its own entry in Chromium's `upstream-info.nix`.
- `chromedriver`: Updated via Chromium's `upstream-info.nix` and not built
from source. Must match Chromium's major version.
- `electron-source`: Various versions of electron that are built from source using Chromium's
`-unwrapped` derivation, due to electron being based on Chromium.
- `electron-source`: Various versions of Electron that are built from source using Chromium's
`-unwrapped` derivation, due to Electron being based on Chromium.
# Upstream links

View File

@@ -1,6 +1,6 @@
# K3s
K3s is a simplified [Kubernetes](https://wiki.nixos.org/wiki/Kubernetes) version that bundles Kubernetes cluster components into a few small binaries optimized for Edge and IoT devices.
K3s is a simplified [Kubernetes](https://wiki.nixos.org/wiki/Kubernetes) distribution that bundles Kubernetes cluster components into a few small binaries optimized for Edge and IoT devices.
## Usage
@@ -8,8 +8,8 @@ K3s is a simplified [Kubernetes](https://wiki.nixos.org/wiki/Kubernetes) version
## Configuration Examples
* [Nvidia GPU Passthru](docs/examples/NVIDIA.md)
* [Intel GPU Passthru](docs/examples/INTEL.md)
* [Nvidia GPU Passthrough](docs/examples/NVIDIA.md)
* [Intel GPU Passthrough](docs/examples/INTEL.md)
* [Storage Examples](docs/examples/STORAGE.md)
## Cluster Maintenance and Troubleshooting

View File

@@ -7,27 +7,27 @@ General documentation for the K3s user for cluster tasks and troubleshooting ste
### Changing K3s Token
Changing the K3s token requires resetting cluster. To reset the cluster, you must do the following:
Changing the K3s token requires resetting the cluster. To reset the cluster, you must do the following:
#### Stopping K3s
Disabling K3s NixOS module won't stop K3s related dependencies, such as containerd or networking. For stopping everything, either run "k3s-killall.sh" script (available on $PATH under `/run/current-system/sw/bin/k3s-killall.sh`) or reboot host.
Disabling the K3s NixOS module won't stop K3s related dependencies, such as containerd or networking. To stop everything, either run "k3s-killall.sh" script (available on $PATH under `/run/current-system/sw/bin/k3s-killall.sh`) or reboot the host.
### Syncing K3s in multiple hosts
Nix automatically syncs hosts to `configuration.nix`, for syncing configuration.nix's git repository and triggering `nixos-rebuild switch` in multiple hosts, it is commonly used `ansible`, which enables automation of cluster provisioning, upgrade and reset.
Nix automatically syncs hosts to `configuration.nix`. To sync `configuration.nix`'s git repository and trigger `nixos-rebuild switch` on multiple hosts, `ansible` is commonly used, which enables automation of cluster provisioning, upgrade and reset.
### Cluster Reset
As upstream "k3s-uninstall.sh" is yet to be packaged for NixOS, it's necessary to run manual steps for resetting cluster.
As upstream "k3s-uninstall.sh" is yet to be packaged for NixOS, it's necessary to run manual steps for resetting the cluster.
Disable K3s instances in **all** hosts:
Disable K3s instances on **all** hosts:
In NixOS configuration, set:
```
services.k3s.enable = false;
```
Rebuild NixOS. This is going to remove K3s service files. But it won't delete K3s data.
Rebuild the NixOS configuration. This is going to remove K3s service files. But it won't delete K3s data.
To delete K3s files:
@@ -43,7 +43,7 @@ Delete k3s data:
```
When using Etcd, Reset Etcd:
Certify **all** K3s instances are stopped, because a single instance can re-seed etcd database with previous cryptographic key.
Ensure **all** K3s instances are stopped, because a single instance can re-seed etcd database with previous cryptographic key.
Disable etcd database in NixOS configuration:
```
@@ -55,22 +55,22 @@ Delete etcd files:
```
rm -rf /var/lib/etcd/
```
Reboot hosts.
Reboot the hosts.
In NixOS configuration:
```
Re-enable Etcd first. Rebuild NixOS. Certify service health. (systemctl status etcd)
Re-enable K3s second. Rebuild NixOS. Certify service health. (systemctl status k3s)
```
Etcd & K3s cluster will be provisioned new.
```
Re-enable Etcd first. Rebuild NixOS. Verify service health. (systemctl status etcd)
Re-enable K3s second. Rebuild NixOS. Verify service health. (systemctl status k3s)
```
The Etcd & K3s cluster will be provisioned anew.
Tip: Use Ansible to automate reset routine, like this.
## Troubleshooting
### Raspberry Pi not working
If the k3s.service/k3s server does not start and gives you the error FATA[0000] failed to find memory cgroup (v2) Here's the github issue: https://github.com/k3s-io/k3s/issues/2067 .
If the k3s.service/k3s server does not start and gives you the error FATA[0000] failed to find memory cgroup (v2) Here's the GitHub issue: https://github.com/k3s-io/k3s/issues/2067 .
To fix the problem, you can add these things to your configuration.nix.
```

View File

@@ -1,8 +1,8 @@
# Onboarding Maintainer
Anyone willing can become a maintainer, no pre-requisite knowledge is required. Willingness to learn is enough.
Anyone willing can become a maintainer, no prerequisite knowledge is required. Willingness to learn is enough.
A K3s maintainer, maintains K3s's:
A K3s maintainer maintains K3s's:
- [documentation](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/networking/cluster/k3s/README.md)
- [issues](https://github.com/NixOS/nixpkgs/issues?q=is%3Aissue+is%3Aopen+k3s)
@@ -24,7 +24,7 @@ Only consensus is required to move forward any proposal. Consensus meaning the a
If you cause a regression (we've all been there), you are responsible for fixing it, but in case you can't fix it (it happens), feel free to ask for help. That's fine, just let us know.
To merge code, you need to be a committer, or use the merge-bot, but currently the merge-bot only works for packages located at `pkgs/by-name/`, which means, K3s still need to be migrated there before you can use merge-bot for merging. As a non-committer, once you have approved a PR you need to forward the request to a committer. For deciding which committer, give preference initially to K3s committers, but any committer can commit. A committer usually has a green approval in PRs.
To merge code, you need to be a committer, or use the merge-bot, but currently the merge-bot only works for packages located at `pkgs/by-name/`, which means, K3s still needs to be migrated there before you can use merge-bot for merging. As a non-committer, once you have approved a PR you need to forward the request to a committer. For deciding which committer, give preference initially to K3s committers, but any committer can commit. A committer usually has a green approval in PRs.
K3s's committers currently are: marcusramberg, Mic92.
@@ -32,11 +32,11 @@ K3s's committers currently are: marcusramberg, Mic92.
@mic92 stepped up when @superherointj stepped down a time ago, as Mic92 has a broad responsibility in nixpkgs (he is responsible for far too many things already, nixpkgs-reviews, sops-nix, release manager, bot-whatever), we avoid giving him chore work for `nixos-unstable`, only pick him as committer last. As Mic92 runs K3s in a `nixos-stable` setting, he might help in testing stable backports.
On how to handle requests, it's the usual basics, such as, when reviewing PRs, issues, be welcoming, helpful, provide hints whenever possible, try to move things forward, assume good will, ignore [as don't react to] any negativity [since it spirals badly], delay and sort any (severe) disagreement in private. Even on disagrements, be thankful to people for their dedicated time, no matter what happens. In essence, on any unfortunate event, **always put people over code**.
On how to handle requests, it's the usual basics, such as, when reviewing PRs, issues, be welcoming, helpful, provide hints whenever possible, try to move things forward, assume good will, ignore [as don't react to] any negativity [since it spirals badly], delay and sort any (severe) disagreement in private. Even on disagreements, be thankful to people for their dedicated time, no matter what happens. In essence, on any unfortunate event, **always put people over code**.
Dumbshit happens, we make mistakes, the CI, reviews, fellow maintainers are there to nudge us on a better direction, no need to over think interactions, if a problem happens, we'll handle it.
Dumbshit happens, we make mistakes, the CI, reviews, fellow maintainers are there to nudge us on a better direction, no need to overthink interactions, if a problem happens, we'll handle it.
We should optimize for maintainers satisfaction, because it is maintainers that make the service great. The best kind of win we have is when someone new steps up for being a maintainer. This multiplies our capabilities of doing meaningful work and increases our knowledge pool.
We should optimize for maintainer satisfaction, because it is maintainers that make the service great. The best kind of win we have is when someone new steps up for being a maintainer. This multiplies our capabilities of doing meaningful work and increases our knowledge pool.
Know that your participation matters most for us. And we thank you for stepping up. It's good to have you here!

View File

@@ -12,7 +12,7 @@ This process split into two sections and adheres to the versioning policy outlin
* Prior to the breaking change window of the next release being closed:
* `nixos-unstable`: Ensure k3s points to latest versioned release
* `nixos-unstable`: Ensure release notes are up to date
* `nixos-unstable`: Remove k3s releases which will be end of life upstream prior to end-of-life for the next NixOS stable release are removed with proper deprecation notice (process listed below)
* `nixos-unstable`: Remove k3s releases which will be end of life upstream prior to end-of-life for the next NixOS stable release, with proper deprecation notice (process listed below)
### Post-Release
@@ -53,7 +53,7 @@ Package removal policy and timelines follow our reasoning in the [versioning doc
Quick checklist for reviewers of the k3s package:
* Is the version of the Go compiler pinned according to the go.mod file for the release?
* Update script will not pin nor change the go version.
* The update script will not pin nor change the Go version.
* Do the K3s passthru.tests work for all architectures supported? (linux-x86_64, aarch64-linux)
* For GitHub CI, [OfBorg](https://github.com/NixOS/ofborg) can be used to test all platforms.
* For Local testing, the following can be run in nixpkgs root on the upgrade branch: `nix build .#k3s_1_29.passthru.tests.{etcd,single-node,multi-node}` (Replace "29" to the version tested)

View File

@@ -25,7 +25,7 @@ Multi-node setup
## Multi-Node
it is simple to create a cluster of multiple nodes in a highly available setup (all nodes are in the control-plane and are a part of the etcd cluster).
It is simple to create a cluster of multiple nodes in a highly available setup (all nodes are in the control-plane and are a part of the etcd cluster).
The first node is configured like this:
@@ -62,7 +62,7 @@ Tip: If you run into connectivity issues between nodes for specific applications
### `prefer-bundled-bin`
K3s has a config setting `prefer-bundled-bin` (and CLI flag `--prefer-bundled-bin`) that makes k3s use binaries from the `/var/lib/rancher/k3s/data/current/bin/aux/` directory, as unpacked by the k3s binary, before the system `$PATH`.
This works with the official distribution of k3s but not with the package from nixpkgs, as it does not bundle the upstream binaries from [`k3s-root`](https://github.com/k3s-io/k3s-root) into the k3s binary.
This works with the official distribution of k3s but not with the package from Nixpkgs, as it does not bundle the upstream binaries from [`k3s-root`](https://github.com/k3s-io/k3s-root) into the k3s binary.
Thus the `prefer-bundled-bin` setting **cannot** be used to work around issues (like [this `mount` regression](https://github.com/util-linux/util-linux/issues/3474)) with binaries used/called by the kubelet.
### Building from a different source

View File

@@ -1,12 +1,12 @@
# Versioning
K3s, Kubernetes, and other clustered software has the property of not being able to update atomically. Most software in nixpkgs, like for example bash, can be updated as part of a "nixos-rebuild switch" without having to worry about the old and the new bash interacting in some way.
K3s, Kubernetes, and other clustered software have the property of not being able to update atomically. Most software in Nixpkgs, like for example bash, can be updated as part of a "nixos-rebuild switch" without having to worry about the old and the new bash interacting in some way.
K3s/Kubernetes, on the other hand, is typically run across several NixOS machines, and each NixOS machine is updated independently. As such, different versions of the package and NixOS module must maintain compatibility with each other through temporary version skew during updates.
The upstream Kubernetes project [documents this in their version-skew policy](https://kubernetes.io/releases/version-skew-policy/#supported-component-upgrade-order).
Within nixpkgs, we strive to maintain a valid "upgrade path" that does not run
Within Nixpkgs, we strive to maintain a valid "upgrade path" that does not run
afoul of the upstream version skew policy.
## Patch Release Support Lifecycle
@@ -15,11 +15,11 @@ K3s is built on top of K8s and typically provides a similar release cadence and
In short, a new Kubernetes version is released roughly every 4 months and each release is supported for a little over 1 year.
## Versioning in nixpkgs
## Versioning in Nixpkgs
There are two package types that are maintained within nixpkgs when we are looking at the `nixos-unstable` branch. A standard `k3s` package and versioned releases such as `k3s_1_28`, `k3s_1_29`, and `k3s_1_30`.
There are two package types that are maintained within Nixpkgs when we are looking at the `nixos-unstable` branch. A standard `k3s` package and versioned releases such as `k3s_1_28`, `k3s_1_29`, and `k3s_1_30`.
The standard `k3s` package will be updated as new versions of k3s are released upstream. Versioned releases, on the other hand, will follow the path release support lifecycle as detailed in the previous section and be removed from `nixos-unstable` when they are either end-of-life upstream or older than the current `k3s` package in `nixos-stable`.
The standard `k3s` package will be updated as new versions of k3s are released upstream. Versioned releases, on the other hand, will follow the patch release support lifecycle as detailed in the previous section and be removed from `nixos-unstable` when they are either end-of-life upstream or older than the current `k3s` package in `nixos-stable`.
## Versioning in NixOS Releases

View File

@@ -5,7 +5,7 @@ This article makes the following assumptions:
2. The Linux kernel running is modern enough to support your GPU out of the box
3. The desired driver is `i915` -- modify as needed for other drivers
> Note: at the time of writing, the author was using an Intel Arc A770 in k3s. The majority of this guide likely should work on other Kubernetes distributions, and will likely work identically for integrated graphics capabilities.
> Note: at the time of writing, the author was using an Intel Arc A770 in k3s. The majority of this guide should work on other Kubernetes distributions, and will likely work identically for integrated graphics capabilities.
### Enable the Intel driver in NixOS
@@ -15,13 +15,13 @@ Add the following NixOS configuration to enable the Intel driver (necessary on h
services.xserver.videoDrivers = [ "i915" ];
```
After rebuilding the configuration, reboot the host for the GPU driver to be assigned to the GPU. Use the following command to ensure the GPU is using the i915 kernel:
After rebuilding the configuration, reboot the host for the driver to be assigned to the GPU. Use the following command to ensure the GPU is using the i915 kernel:
```
sudo lspci -k
```
i.e. the output looks like this on a host with the Intel Arc A770:
For example, the output looks like this on a host with the Intel Arc A770:
```
sudo lspci -k | grep -A 3 'Arc'
@@ -117,7 +117,7 @@ Verify the number has been applied like so:
kubectl get nodes -o yaml | grep gpu.intel.com/i915 | sort -u
```
i.e. in this configuration, up to 10 pods can use the GPU:
For example, in this configuration, up to 10 pods can use the GPU:
```
kubectl get nodes -o yaml | grep gpu.intel.com/i915 | sort -u

View File

@@ -17,7 +17,7 @@ services.xserver = {
videoDrivers = [ "nvidia" ];
};
nixpkgs.config.allowUnfreePredicate = pkg: builtins.elem (lib.getName pkg) [
nixpkgs.config.allowUnfreePackages = [
"nvidia-x11"
"nvidia-settings"
];
@@ -58,7 +58,7 @@ Additionally, `lspci -k` can be used to ensure the driver has been assigned to t
## Configure k3s
You now need to create a new file in `/var/lib/rancher/k3s/agent/etc/containerd/config.toml.tmpl` with the following
You now need to create a new file in `/var/lib/rancher/k3s/agent/etc/containerd/config.toml.tmpl` with the following:
```
{{ template "base" . }}

View File

@@ -14,7 +14,7 @@ services.openiscsi = {
};
```
Longhorn container has trouble with NixOS path. Solution is to override PATH environment variable, such as:
The Longhorn container has trouble with the NixOS path. Solution is to override PATH environment variable, such as:
```
PATH: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/run/wrappers/bin:/nix/var/nix/profiles/default/bin:/run/current-system/sw/bin
@@ -42,7 +42,7 @@ metadata:
policies.kyverno.io/category: Other
policies.kyverno.io/description: >-
Longhorn invokes executables on the host system, and needs
to be aware of the host systems PATH. This modifies all
to be aware of the host system's PATH. This modifies all
deployments such that the PATH is explicitly set to support
NixOS based systems.
spec:

View File

@@ -1,7 +1,7 @@
# RKE2 Version
RKE2, Kubernetes, and other clustered software has the property of not being able to update
atomically. Most software in nixpkgs, like for example bash, can be updated as part of a
RKE2, Kubernetes, and other clustered software have the property of not being able to update
atomically. Most software in Nixpkgs, like for example bash, can be updated as part of a
`nixos-rebuild switch` without having to worry about the old and the new bash interacting in some
way. RKE2/Kubernetes, on the other hand, is typically run across several machines, and each machine
is updated independently. As such, different versions of the package and NixOS module must maintain
@@ -9,7 +9,7 @@ compatibility with each other through temporary version skew during updates. The
project documents this in their
[version-skew policy](https://kubernetes.io/releases/version-skew-policy/#supported-component-upgrade-order).
Within nixpkgs, we strive to maintain a valid "upgrade path" that does not run afoul of the upstream
Within Nixpkgs, we strive to maintain a valid "upgrade path" that does not run afoul of the upstream
version skew policy.
> [!NOTE]
@@ -18,13 +18,13 @@ version skew policy.
## Release Maintenance
This section describes how new RKE2 releases are published in nixpkgs.
This section describes how new RKE2 releases are published in Nixpkgs.
Before contributing new RKE2 packages or updating existing packages, make sure that
- New packages build (e.g. `nix-build -A rke2_1_34`)
- All tests pass (e.g. `nix-build -A rke2_1_34.tests`)
- You respect the nixpkgs [contributing guidelines](/CONTRIBUTING.md)
- You respect the Nixpkgs [contributing guidelines](/CONTRIBUTING.md)
### Release Channels
@@ -95,7 +95,7 @@ In order to remove a versioned RKE2 package, create a PR achieving the following
[pkgs/top-level/all-packages.nix](/pkgs/top-level/all-packages.nix)
4. Add a deprecation notice in [pkgs/top-level/aliases.nix](/pkgs/top-level/aliases.nix)
- Such as
`rke2_1_34 = throw "'rke2_1_34' has been removed from nixpkgs as it has reached end of life"; # Added 2026-10-27`
`rke2_1_34 = throw "'rke2_1_34' has been removed from Nixpkgs as it has reached end of life"; # Added 2026-10-27`
#### Handling EOL on stable

View File

@@ -28,11 +28,11 @@ Updating is done in 3 steps:
## Adding new libraries
To add a new package to this scope, simply add a new subdirectory containing a `default.nix` file with the appropriate package name. The scope automatically picks up any directories and adds an according toplevel package.
To add a new package to this scope, simply add a new subdirectory containing a `default.nix` file with the appropriate package name. The scope automatically picks up any directories and adds a corresponding toplevel package.
If the package you are adding is contained within the `linphone-sdk` monorepo, it makes sense to use the `mkLinphoneDerivation` function to streamline the build process.
If the package you are adding is a third-party libary with custom patches from BC, it should be prefixed with `bc-` for easy recognizability, so e.g. if BC were to patch `ffmpeg`, you would call the package `bc-ffmpeg`.
If the package you are adding is a third-party library with custom patches from BC, it should be prefixed with `bc-` for easy recognizability, so e.g. if BC were to patch `ffmpeg`, you would call the package `bc-ffmpeg`.
## Notes for the future

View File

@@ -136,11 +136,11 @@ stdenv.mkDerivation (finalAttrs: {
+ lib.optionalString nixosTestRunner "-for-vm-tests"
+ lib.optionalString toolsOnly "-utils"
+ lib.optionalString userOnly "-user";
version = "10.1.2";
version = "10.2.0";
src = fetchurl {
url = "https://download.qemu.org/qemu-${finalAttrs.version}.tar.xz";
hash = "sha256-nXXzMcGly5tuuP2fZPVj7C6rNGyCLLl/izXNgtPxFHk=";
hash = "sha256-njCtG4ufe0RjABWC0aspfznPzOpdCFQMDKbWZyeFiDo=";
};
depsBuildBuild = [
@@ -268,6 +268,50 @@ stdenv.mkDerivation (finalAttrs: {
sha256 = "sha256-oC+bRjEHixv1QEFO9XAm4HHOwoiT+NkhknKGPydnZ5E=";
revert = true;
})
# Implement termios2 (TCGETS2 etc) for glibc 2.42 compatibility. Should be in the next release.
# https://gitlab.com/qemu-project/qemu/-/issues/3065
# https://lore.kernel.org/qemu-devel/20260103153239.15787-1-dilfridge@gentoo.org/t/#u
(fetchpatch {
name = "0001-Add-termios2-support-to-linux-user.patch";
url = "https://gitlab.com/qemu-project/qemu/-/commit/e9a8a10e84c1bf6e2e8be000e4dd5c83ba0d8470.patch";
hash = "sha256-Zc+ZjiSug3uT/F7+mmoYc2VXqw2MV6UubYqB+pr2dNY=";
})
(fetchpatch {
name = "0002-Add-termios2-support-to-alpha-target.patch";
url = "https://gitlab.com/qemu-project/qemu/-/commit/8d8c6aeee8599a099e49ec4411f3d1e087ae40ad.patch";
hash = "sha256-5e5vUp9nr96ZmVA98W/ETReLbkofayysJXlx1Ck9gDs=";
})
(fetchpatch {
name = "0003-Add-termios2-support-to-hppa-target.patch";
url = "https://gitlab.com/qemu-project/qemu/-/commit/edc741710acedd61011f937967b960d154794258.patch";
hash = "sha256-nls6eTOB06eqACjQ/r1sQvb9YaYmrpJcegsDGqKAOaI=";
})
(fetchpatch {
name = "0004-Add-termios2-support-to-mips-target.patch";
url = "https://gitlab.com/qemu-project/qemu/-/commit/edf9184f4feb691b0f70dc544443db2380891598.patch";
hash = "sha256-GrBhyMq2QiCc+WlUwaB9j4G8vB3ipxJRV5Hvyab/5Fk=";
})
(fetchpatch {
name = "0005-Add-termios2-support-to-sh4-target.patch";
url = "https://gitlab.com/qemu-project/qemu/-/commit/afbe0ff81c29d674b9c18a588bcaab34ddcb8a7b.patch";
hash = "sha256-h+9eC6H8/GJ85Lt1Y0ggdJbbgTIvDfIJkPQfX/FgO4c=";
})
(fetchpatch {
name = "0006-Add-termios2-support-to-sparc-target.patch";
url = "https://gitlab.com/qemu-project/qemu/-/commit/947b971cad90375040f399899909a3f1f32b483f.patch";
hash = "sha256-/JvF25aSR2mBSvkpqupDySMJYZI+lv7L0YwhqiaDk3A=";
})
(fetchpatch {
name = "0007-linux-user-Add-missing-termios-baud-rates.patch";
url = "https://gitlab.com/qemu-project/qemu/-/commit/4f22fcb5c67f40a36e6654f6cfaee23f9f9e93d1.patch";
hash = "sha256-CM81yL0/i+fmQe8qzemre13N3A74J1HIC7ilCbb7ESQ=";
})
(fetchpatch {
name = "0008-linux-user-fixup-termios2-related-things-on-PowerPC.patch";
url = "https://gitlab.com/qemu-project/qemu/-/commit/d68f0e2e906939bef076d0cd52f902d433c8c3da.patch";
hash = "sha256-vF47CKqg0wBBOUkHeJ3hv3nUHCftl2OwD3Nh0dL1PNk=";
})
]
++ lib.optional nixosTestRunner ./force-uid0-on-9p.patch;

View File

@@ -3,11 +3,11 @@
Go promises that "programs written to the Go 1 specification will continue to compile and run correctly, unchanged, over the lifetime of that specification" [1].
Newer toolchain versions should build projects developed against older toolchains without problems.
**Definition(a "toolchain-breaking" package):**
**Definition (a "toolchain-breaking" package):**
There are however Go packages depending on internal APIs of the toolchain/runtime/stdlib that are not covered by the Go compatibility promise.
These packages may break on toolchain minor version upgrades.
**Definition(a "toolchain-latest" package):**
**Definition (a "toolchain-latest" package):**
Packages providing development support for the Go language (like `gopls`, `golangci-lint`,...) depend on the toolchain in another way: they must be compiled at least with the version they should be used for.
If `gopls` is compiled for Go 1.23, it won't work for projects that require Go 1.24.
@@ -21,13 +21,13 @@ Based on this, we align on the following policy for toolchain/builder upgrades f
2. The `go_latest` toolchain and the `buildGoLatestModule` are also bumped directly after release, but the update goes to the `master` branch.
Packages in `toolchain-latest` SHOULD use `go_latest`/`buildGoLatestModule`.
Packages in nixpkgs MUST only use this toolchain/builder if they have a good reason to do so
Packages in nixpkgs MUST only use this toolchain/builder if they have a good reason to do so.
A comment MUST be added explaining why this is the case for a certain package.
It is important to keep the number of packages using this builder within nixpkgs low, so the bump won't cause a mass rebuild.
`go_latest` MUST not point to release candidates of Go.
Consumer outside of nixpkgs on the other hand MAY rely on this toolchain/builder if they prefer being upgraded earlier to the newest toolchain minor version.
Consumers outside of nixpkgs on the other hand MAY rely on this toolchain/builder if they prefer being upgraded earlier to the newest toolchain minor version.
3. Packages in `toolchain-breaking` SHOULD pin a toolchain version by using a builder with a fixed Go version (`buildGo1xxModule`).
The use of `buildGo1xxModule` MUST be accompanied with a comment explaining why this has a dependency on a specific Go version.
@@ -40,7 +40,7 @@ Based on this, we align on the following policy for toolchain/builder upgrades f
When an end-of-life toolchain is removed, builders that pin the EOL version (according to 3.) will automatically be bumped to the then oldest pinned builder (e.g. Go 1.22 is EOL, `buildGo122Module` is bumped to `buildGo123Module`).
If the package won't build with that builder anymore, the package is marked broken.
It is the package maintainers responsibility to fix the package and get it working with a supported Go toolchain.
It is the package maintainer's responsibility to fix the package and get it working with a supported Go toolchain.
For the stable release, we recognize that (1) removing a Go version, or updating the `go_latest` or `go` packages to a new Go minor release, would be a breaking change, and (2) some packages will need backports (e.g. for security reasons) that require the latest Go version.
Therefore, on the stable release, new Go versions will be backported to the `release-2x.xx` branch, but the old versions will remain, and `go`, `buildGoModule`, `go_latest`, and `buildGoLatestModule` will remain unchanged.

View File

@@ -74,7 +74,7 @@ initrd to a minimum.
in less than a second, and the code is substantially easier to work
with.
- This will not require end users to install a rust toolchain to use
- This will not require end users to install a Rust toolchain to use
NixOS, as long as this tool is cached by Hydra. And if you're
bootstrapping NixOS from source, rustc is already required anyway.

View File

@@ -107,9 +107,11 @@ fi
# copy module ordering hints for depmod
cp $kernel/lib/modules/"$version"/modules.order $out/lib/modules/"$version"/.
cp $kernel/lib/modules/"$version"/modules.builtin $out/lib/modules/"$version"/.
cp $kernel/lib/modules/"$version"/modules.builtin.modinfo $out/lib/modules/"$version"/.
depmod -b $out -a $version
# remove original hints from final derivation
rm $out/lib/modules/"$version"/modules.order
rm $out/lib/modules/"$version"/modules.builtin
rm $out/lib/modules/"$version"/modules.builtin.modinfo

View File

@@ -64,7 +64,7 @@ The above expression is called using these arguments by default:
But the package might need `pkgs.libbar_2` instead.
While the `libbar` argument could explicitly be overridden in `all-packages.nix` with `libbar_2`, this would hide important information about this package from its interface.
The fact that the package requires a certain version of `libbar` to work should not be hidden in a separate place.
It is preferable to use `libbar_2` as a argument name instead.
It is preferable to use `libbar_2` as an argument name instead.
This approach also has the benefit that, if the expectation of the package changes to require a different version of `libbar`, a downstream user with an override of this argument will receive an error.
This is comparable to a merge conflict in git: It's much better to be forced to explicitly address the conflict instead of silently keeping the override - which might lead to a different problem that is likely much harder to debug.

View File

@@ -2,6 +2,7 @@
lib,
stdenv,
fetchFromGitHub,
unstableGitUpdater,
cmake,
pkg-config,
fmt,
@@ -36,7 +37,7 @@ let
in
stdenv.mkDerivation {
pname = "${lib.strings.toLower type}plug";
version = "unstable-2021-12-17";
version = "1.0.2-unstable-2021-12-17";
src = fetchFromGitHub {
owner = "jpcima";
@@ -112,6 +113,11 @@ stdenv.mkDerivation {
mv au/${mainProgram}.component $out/Library/Audio/Plug-Ins/Components/
'';
passthru.updateScript = unstableGitUpdater {
tagPrefix = "v";
tagFormat = "v*";
};
meta = {
inherit mainProgram;
description = "${chip} FM Chip Synthesizer";

View File

@@ -4,7 +4,7 @@
- Update `version` and `src.hash` in package.nix
- Check out the changes made to the azure-cli [setup.py](https://github.com/Azure/azure-cli/blob/dev/src/azure-cli/setup.py) since the last release
- Try build the CLI, will likely fail with `ModuleNotFoundError`, for example
- Try to build the CLI, will likely fail with `ModuleNotFoundError`, for example
```
ModuleNotFoundError: No module named 'azure.mgmt.storage.v2023_05_01'
```
@@ -21,7 +21,7 @@
There are two sets of extensions:
- `extensions-generated.nix` are extensions with no external requirements, which can be regenerated running:
- `extensions-generated.nix` are extensions with no external requirements, which can be regenerated by running:
> nix run .#azure-cli.passthru.generate-extensions
- `extensions-manual.nix` are extensions with requirements, which need to be manually packaged and maintained.

View File

@@ -29,11 +29,11 @@
stdenv.mkDerivation (finalAttrs: {
pname = "bind";
version = "9.20.17";
version = "9.20.18";
src = fetchurl {
url = "https://downloads.isc.org/isc/bind9/${finalAttrs.version}/bind-${finalAttrs.version}.tar.xz";
hash = "sha256-XMiaCdoJF+sd32QMwHwXL/RPqbvzo0raS2ovfucP8cg=";
hash = "sha256-38VGyZCsRRVSnNRcTdmVhisYrootDLKSCOiJal0yUzE=";
};
outputs = [

View File

@@ -4,16 +4,18 @@
fetchFromGitHub,
testers,
bombardier,
versionCheckHook,
nix-update-script,
}:
buildGoModule rec {
buildGoModule (finalAttrs: {
pname = "bombardier";
version = "2.0.2";
src = fetchFromGitHub {
owner = "codesenberg";
repo = "bombardier";
rev = "v${version}";
tag = "v${finalAttrs.version}";
hash = "sha256-FoaiUky0WcipkGN8KIpSd+iizinlqtHC5lskvNCnx/Y=";
};
@@ -26,12 +28,17 @@ buildGoModule rec {
ldflags = [
"-s"
"-w"
"-X=main.version=${version}"
"-X=main.version=${finalAttrs.version}"
];
__darwinAllowLocalNetworking = true;
doInstallCheck = true;
nativeInstallCheckInputs = [ versionCheckHook ];
versionCheckProgramArg = "--version";
passthru.tests = {
updateScript = nix-update-script { };
version = testers.testVersion {
package = bombardier;
};
@@ -40,9 +47,9 @@ buildGoModule rec {
meta = {
description = "Fast cross-platform HTTP benchmarking tool written in Go";
homepage = "https://github.com/codesenberg/bombardier";
changelog = "https://github.com/codesenberg/bombardier/releases/tag/${src.rev}";
changelog = "https://github.com/codesenberg/bombardier/releases/tag/v${finalAttrs.version}";
license = lib.licenses.mit;
maintainers = [ ];
maintainers = [ lib.maintainers.progrm_jarvis ];
mainProgram = "bombardier";
};
}
})

View File

@@ -24,15 +24,14 @@
}:
let
pname = "caribou";
version = "0.4.21";
pythonEnv = python3.withPackages (ps: with ps; [ pygobject3 ]);
in
stdenv.mkDerivation rec {
name = "caribou-${version}";
pname = "caribou";
version = "0.4.21";
src = fetchurl {
url = "mirror://gnome/sources/caribou/${lib.versions.majorMinor version}/${name}.tar.xz";
url = "mirror://gnome/sources/caribou/${lib.versions.majorMinor version}/caribou-${version}.tar.xz";
hash = "sha256-nEPZ9L0w9P6n94DU6LFPdYkQfFLpy2vSAr0NHCBk3lU=";
};

View File

@@ -1,6 +1,6 @@
# `devmode`
`devmode` is a daemon, that:
`devmode` is a daemon that:
1. watches the manual's source for changes and when they occur — rebuilds
2. HTTP serves the manual, injecting a script that triggers reload on changes
3. opens the manual in the default browser

View File

@@ -51,6 +51,12 @@ stdenv.mkDerivation (finalAttrs: {
configureFlags = [ "--enable-compat-symlinks" ];
outputs = [
"out"
"doc"
"man"
];
nativeCheckInputs = [ xxd ];
doCheck = true;

View File

@@ -19,7 +19,7 @@ After every NixOS release, the unsupported etcd versions should be removed by et
## User guidelines on etcd upgrades
Before upgrading a NixOS release, certify to upgrade etcd to the latest version in the current used release.
Before upgrading a NixOS release, make sure to upgrade etcd to the latest version in the current used release.
Manual steps might be required for the upgrade.

View File

@@ -1,20 +1,21 @@
{
lib,
fetchFromGitHub,
flutter332,
flutter338,
autoPatchelfHook,
buildGoModule,
keybinder3,
libayatana-appindicator,
}:
let
version = "1.8.3";
version = "1.9.0";
src = fetchFromGitHub {
owner = "GopeedLab";
repo = "gopeed";
tag = "v${version}";
hash = "sha256-ze0hoTR3e3Wrgtv2FlM81faXmij61NEcPLzO4WDXIak=";
hash = "sha256-kLWhAQfzqZ9/THYeU/W4YOJYfMnqoTbyobC2P9YYddI=";
};
metaCommon = {
@@ -29,14 +30,7 @@ let
inherit version src;
pname = "libgopeed";
vendorHash = "sha256-rIj4T+NEqWla6/+ofosTwagL4/VMovDp1NEYMuzbOrQ=";
# Fix C23 compat
preBuild = ''
chmod +w vendor/github.com/anacrolix/go-libutp/utp_types.h
substituteInPlace vendor/github.com/anacrolix/go-libutp/utp_types.h \
--replace-fail "typedef uint8 bool;" ""
'';
vendorHash = "sha256-XTVFqKn0JeOC/QFns0GhIYqu1FB+eFg6bgIi4G7Lw1o=";
buildPhase = ''
runHook preBuild
@@ -51,7 +45,7 @@ let
meta = metaCommon;
};
in
flutter332.buildFlutterApplication {
flutter338.buildFlutterApplication {
inherit version src;
pname = "gopeed";
@@ -63,7 +57,10 @@ flutter332.buildFlutterApplication {
nativeBuildInputs = [ autoPatchelfHook ];
buildInputs = [ libayatana-appindicator ];
buildInputs = [
keybinder3
libayatana-appindicator
];
preBuild = ''
mkdir -p linux/bundle/lib

View File

@@ -4,17 +4,11 @@
"dependency": "transitive",
"description": {
"name": "_fe_analyzer_shared",
"sha256": "f256b0c0ba6c7577c15e2e4e114755640a875e885099367bf6e012b19314c834",
"sha256": "0b2f2bd91ba804e53a61d757b986f89f1f9eaed5b11e4b2f5a2468d86d6c9fc7",
"url": "https://pub.dev"
},
"source": "hosted",
"version": "72.0.0"
},
"_macros": {
"dependency": "transitive",
"description": "dart",
"source": "sdk",
"version": "0.3.2"
"version": "67.0.0"
},
"after_layout": {
"dependency": "transitive",
@@ -30,11 +24,11 @@
"dependency": "transitive",
"description": {
"name": "analyzer",
"sha256": "b652861553cd3990d8ed361f7979dc6d7053a9ac8843fa73820ab68ce5410139",
"sha256": "37577842a27e4338429a1cbc32679d508836510b056f1eedf0c8d20e39c1383d",
"url": "https://pub.dev"
},
"source": "hosted",
"version": "6.7.0"
"version": "6.4.1"
},
"animations": {
"dependency": "transitive",
@@ -220,11 +214,11 @@
"dependency": "transitive",
"description": {
"name": "characters",
"sha256": "04a925763edad70e8443c99234dc3328f442e811f1d8fd1a72f1c8ad0f69a605",
"sha256": "f71061c654a3380576a52b451dd5532377954cf9dbd272a78fc8479606670803",
"url": "https://pub.dev"
},
"source": "hosted",
"version": "1.3.0"
"version": "1.4.0"
},
"checkable_treeview": {
"dependency": "direct main",
@@ -260,11 +254,11 @@
"dependency": "transitive",
"description": {
"name": "clock",
"sha256": "cb6d7f03e1de671e34607e909a7213e31d7752be4fb66a86d29fe1eb14bfb5cf",
"sha256": "fddb70d9b5277016c77a80201021d40a2247104d9f4aa7bab7157b7e3f05b84b",
"url": "https://pub.dev"
},
"source": "hosted",
"version": "1.1.1"
"version": "1.1.2"
},
"code_builder": {
"dependency": "transitive",
@@ -280,11 +274,11 @@
"dependency": "transitive",
"description": {
"name": "collection",
"sha256": "ee67cb0715911d28db6bf4af1026078bd6f0128b07a5f66fb2ed94ec6783c09a",
"sha256": "2f5709ae4d3d59dd8f7cd309b4e023046b57d8a6c82130785d2b0e5868084e76",
"url": "https://pub.dev"
},
"source": "hosted",
"version": "1.18.0"
"version": "1.19.1"
},
"contentsize_tabbarview": {
"dependency": "direct main",
@@ -370,11 +364,11 @@
"dependency": "transitive",
"description": {
"name": "dart_style",
"sha256": "7856d364b589d1f08986e140938578ed36ed948581fbc3bc9aef1805039ac5ab",
"sha256": "99e066ce75c89d6b29903d788a7bb9369cf754f7b24bf70bf4b6d6d6b26853b9",
"url": "https://pub.dev"
},
"source": "hosted",
"version": "2.3.7"
"version": "2.3.6"
},
"desktop_drop": {
"dependency": "direct main",
@@ -440,11 +434,11 @@
"dependency": "transitive",
"description": {
"name": "fake_async",
"sha256": "511392330127add0b769b75a987850d136345d9227c6b94c96a04cf4a391bf78",
"sha256": "5368f224a74523e8d2e7399ea1638b37aecfca824a3cc4dfdf77bf1fa905ac44",
"url": "https://pub.dev"
},
"source": "hosted",
"version": "1.3.1"
"version": "1.3.3"
},
"ffi": {
"dependency": "transitive",
@@ -526,11 +520,11 @@
"dependency": "direct main",
"description": {
"name": "flutter_form_builder",
"sha256": "c278ef69b08957d484f83413f0e77b656a39b7a7bb4eb8a295da3a820ecc6545",
"sha256": "ec74389c4af2361a5e9fe9a36fcfe722698be3f681d713cb3ebe099ae15ed863",
"url": "https://pub.dev"
},
"source": "hosted",
"version": "9.5.0"
"version": "10.2.0"
},
"flutter_launcher_icons": {
"dependency": "direct dev",
@@ -594,11 +588,11 @@
"dependency": "direct main",
"description": {
"name": "form_builder_validators",
"sha256": "c61ed7b1deecf0e1ebe49e2fa79e3283937c5a21c7e48e3ed9856a4a14e1191a",
"sha256": "1b03c74d1db740890e6af803b43e5ebe56f8fa1ff5609cbf744e8d980dc5f8c6",
"url": "https://pub.dev"
},
"source": "hosted",
"version": "11.0.0"
"version": "11.2.0"
},
"frontend_server_client": {
"dependency": "transitive",
@@ -660,6 +654,56 @@
"source": "hosted",
"version": "2.2.3"
},
"hotkey_manager": {
"dependency": "direct main",
"description": {
"name": "hotkey_manager",
"sha256": "06f0655b76c8dd322fb7101dc615afbdbf39c3d3414df9e059c33892104479cd",
"url": "https://pub.dev"
},
"source": "hosted",
"version": "0.2.3"
},
"hotkey_manager_linux": {
"dependency": "transitive",
"description": {
"name": "hotkey_manager_linux",
"sha256": "83676bda8210a3377bc6f1977f193bc1dbdd4c46f1bdd02875f44b6eff9a8473",
"url": "https://pub.dev"
},
"source": "hosted",
"version": "0.2.0"
},
"hotkey_manager_macos": {
"dependency": "transitive",
"description": {
"name": "hotkey_manager_macos",
"sha256": "03b5967e64357b9ac05188ea4a5df6fe4ed4205762cb80aaccf8916ee1713c96",
"url": "https://pub.dev"
},
"source": "hosted",
"version": "0.2.0"
},
"hotkey_manager_platform_interface": {
"dependency": "transitive",
"description": {
"name": "hotkey_manager_platform_interface",
"sha256": "98ffca25b8cc9081552902747b2942e3bc37855389a4218c9d50ca316b653b13",
"url": "https://pub.dev"
},
"source": "hosted",
"version": "0.2.0"
},
"hotkey_manager_windows": {
"dependency": "transitive",
"description": {
"name": "hotkey_manager_windows",
"sha256": "0d03ced9fe563ed0b68f0a0e1b22c9ffe26eb8053cb960e401f68a4f070e0117",
"url": "https://pub.dev"
},
"source": "hosted",
"version": "0.2.0"
},
"http": {
"dependency": "transitive",
"description": {
@@ -715,11 +759,11 @@
"dependency": "transitive",
"description": {
"name": "intl",
"sha256": "d6f56758b7d3014a48af9701c085700aac781a92a87a62b1333b46d8879661cf",
"sha256": "3df61194eb431efc39c4ceba583b95633a403f46c9fd341e550ce0bfa50e9aa5",
"url": "https://pub.dev"
},
"source": "hosted",
"version": "0.19.0"
"version": "0.20.2"
},
"io": {
"dependency": "transitive",
@@ -775,31 +819,31 @@
"dependency": "transitive",
"description": {
"name": "leak_tracker",
"sha256": "3f87a60e8c63aecc975dda1ceedbc8f24de75f09e4856ea27daf8958f2f0ce05",
"sha256": "33e2e26bdd85a0112ec15400c8cbffea70d0f9c3407491f672a2fad47915e2de",
"url": "https://pub.dev"
},
"source": "hosted",
"version": "10.0.5"
"version": "11.0.2"
},
"leak_tracker_flutter_testing": {
"dependency": "transitive",
"description": {
"name": "leak_tracker_flutter_testing",
"sha256": "932549fb305594d82d7183ecd9fa93463e9914e1b67cacc34bc40906594a1806",
"sha256": "1dbc140bb5a23c75ea9c4811222756104fbcd1a27173f0c34ca01e16bea473c1",
"url": "https://pub.dev"
},
"source": "hosted",
"version": "3.0.5"
"version": "3.0.10"
},
"leak_tracker_testing": {
"dependency": "transitive",
"description": {
"name": "leak_tracker_testing",
"sha256": "6ba465d5d76e67ddf503e1161d1f4a6bc42306f9d66ca1e8f079a47290fb06d3",
"sha256": "8d5a2d49f4a66b49744b23b018848400d23e54caf9463f4eb20df3eb8acb2eb1",
"url": "https://pub.dev"
},
"source": "hosted",
"version": "3.0.1"
"version": "3.0.2"
},
"lecle_downloads_path_provider": {
"dependency": "direct main",
@@ -851,25 +895,15 @@
"source": "hosted",
"version": "1.3.0"
},
"macros": {
"dependency": "transitive",
"description": {
"name": "macros",
"sha256": "0acaed5d6b7eab89f63350bccd82119e6c602df0f391260d0e32b5e23db79536",
"url": "https://pub.dev"
},
"source": "hosted",
"version": "0.1.2-main.4"
},
"matcher": {
"dependency": "transitive",
"description": {
"name": "matcher",
"sha256": "d2323aa2060500f906aa31a895b4030b6da3ebdcc5619d14ce1aada65cd161cb",
"sha256": "dc58c723c3c24bf8d3e2d3ad3f2f9d7bd9cf43ec6feaa64181775e60190153f2",
"url": "https://pub.dev"
},
"source": "hosted",
"version": "0.12.16+1"
"version": "0.12.17"
},
"material_color_utilities": {
"dependency": "transitive",
@@ -905,11 +939,11 @@
"dependency": "transitive",
"description": {
"name": "meta",
"sha256": "bdb68674043280c3428e9ec998512fb681678676b3c54e773629ffe74419f8c7",
"sha256": "23f08335362185a5ea2ad3a4e597f1375e78bce8a040df5c600c8d3552ef2394",
"url": "https://pub.dev"
},
"source": "hosted",
"version": "1.15.0"
"version": "1.17.0"
},
"mime": {
"dependency": "transitive",
@@ -975,11 +1009,11 @@
"dependency": "direct main",
"description": {
"name": "open_filex",
"sha256": "ba425ea49affd0a98a234aa9344b9ea5d4c4f7625a1377961eae9fe194c3d523",
"sha256": "9976da61b6a72302cf3b1efbce259200cd40232643a467aac7370addf94d6900",
"url": "https://pub.dev"
},
"source": "hosted",
"version": "4.5.0"
"version": "4.7.0"
},
"package_config": {
"dependency": "transitive",
@@ -1015,11 +1049,11 @@
"dependency": "direct main",
"description": {
"name": "path",
"sha256": "087ce49c3f0dc39180befefc60fdb4acd8f8620e5682fe2476afd0b3688bb4af",
"sha256": "75cca69d1490965be98c73ceaea117e8a04dd21217b37b292c9ddbec0d955bc5",
"url": "https://pub.dev"
},
"source": "hosted",
"version": "1.9.0"
"version": "1.9.1"
},
"path_parsing": {
"dependency": "transitive",
@@ -1336,21 +1370,21 @@
"dependency": "transitive",
"description": {
"name": "shared_preferences",
"sha256": "746e5369a43170c25816cc472ee016d3a66bc13fcf430c0bc41ad7b4b2922051",
"sha256": "6e8bf70b7fef813df4e9a36f658ac46d107db4b4cfe1048b477d4e453a8159f5",
"url": "https://pub.dev"
},
"source": "hosted",
"version": "2.3.2"
"version": "2.5.3"
},
"shared_preferences_android": {
"dependency": "transitive",
"description": {
"name": "shared_preferences_android",
"sha256": "3b9febd815c9ca29c9e3520d50ec32f49157711e143b7a4ca039eb87e8ade5ab",
"sha256": "9f9f3d372d4304723e6136663bb291c0b93f5e4c8a4a6314347f481a33bda2b1",
"url": "https://pub.dev"
},
"source": "hosted",
"version": "2.3.3"
"version": "2.4.7"
},
"shared_preferences_foundation": {
"dependency": "transitive",
@@ -1436,7 +1470,7 @@
"dependency": "transitive",
"description": "flutter",
"source": "sdk",
"version": "0.0.99"
"version": "0.0.0"
},
"source_gen": {
"dependency": "transitive",
@@ -1482,21 +1516,21 @@
"dependency": "transitive",
"description": {
"name": "stack_trace",
"sha256": "73713990125a6d93122541237550ee3352a2d84baad52d375a4cad2eb9b7ce0b",
"sha256": "8b27215b45d22309b5cddda1aa2b19bdfec9df0e765f2de506401c071d38d1b1",
"url": "https://pub.dev"
},
"source": "hosted",
"version": "1.11.1"
"version": "1.12.1"
},
"stream_channel": {
"dependency": "transitive",
"description": {
"name": "stream_channel",
"sha256": "ba2aa5d8cc609d96bbb2899c28934f9e1af5cddbd60a827822ea467161eb54e7",
"sha256": "969e04c80b8bcdf826f8f16579c7b14d780458bd97f56d107d3950fdbeef059d",
"url": "https://pub.dev"
},
"source": "hosted",
"version": "2.1.2"
"version": "2.1.4"
},
"stream_transform": {
"dependency": "transitive",
@@ -1542,11 +1576,11 @@
"dependency": "transitive",
"description": {
"name": "test_api",
"sha256": "5b8a98dafc4d5c4c9c72d8b31ab2b23fc13422348d2997120294d3bac86b4ddb",
"sha256": "ab2726c1a94d3176a45960b6234466ec367179b87dd74f1611adb1f3b5fb9d55",
"url": "https://pub.dev"
},
"source": "hosted",
"version": "0.7.2"
"version": "0.7.7"
},
"timing": {
"dependency": "transitive",
@@ -1589,6 +1623,16 @@
"source": "hosted",
"version": "1.4.0"
},
"uni_platform": {
"dependency": "transitive",
"description": {
"name": "uni_platform",
"sha256": "e02213a7ee5352212412ca026afd41d269eb00d982faa552f419ffc2debfad84",
"url": "https://pub.dev"
},
"source": "hosted",
"version": "0.1.3"
},
"uri_to_file": {
"dependency": "direct main",
"description": {
@@ -1723,11 +1767,11 @@
"dependency": "transitive",
"description": {
"name": "vector_math",
"sha256": "80b3257d1492ce4d091729e3a67a60407d227c27241d6927be0130c98e741803",
"sha256": "d530bd74fea330e6e364cda7a85019c434070188383e1cd8d9777ee586914c5b",
"url": "https://pub.dev"
},
"source": "hosted",
"version": "2.1.4"
"version": "2.2.0"
},
"vm_service": {
"dependency": "transitive",
@@ -1851,7 +1895,7 @@
}
},
"sdks": {
"dart": ">=3.5.0 <4.0.0",
"flutter": ">=3.24.0"
"dart": ">=3.9.0 <4.0.0",
"flutter": ">=3.35.0"
}
}

View File

@@ -47,14 +47,13 @@ let
unfree licenses.
configuration.nix:
nixpkgs.config.allowUnfreePredicate = pkg:
builtins.elem (lib.getName pkg) [
"joypixels"
];
nixpkgs.config.allowUnfreePackages = [
"joypixels"
];
nixpkgs.config.joypixels.acceptLicense = true;
config.nix:
allowUnfreePredicate = pkg: builtins.elem (lib.getName pkg) [
allowUnfreePackages = [
"joypixels"
];
joypixels.acceptLicense = true;

View File

@@ -18,6 +18,11 @@ stdenv.mkDerivation (finalAttrs: {
nativeBuildInputs = [ autoreconfHook ];
outputs = [
"out"
"dev"
];
meta = {
homepage = "https://libcpuid.sourceforge.net/";
description = "Small C library for x86 CPU detection and feature extraction";

View File

@@ -43,7 +43,7 @@ stdenv.mkDerivation (finalAttrs: {
"INSTALL=install"
"BINDIR=$(out)/sbin"
"SYSTEMD_DIR=$(out)/lib/systemd/system"
"MANDIR=$(out)/share/man"
"MANDIR=$(man)/share/man"
"RUN_DIR=/dev/.mdadm"
"STRIP="
]
@@ -51,6 +51,11 @@ stdenv.mkDerivation (finalAttrs: {
"CROSS_COMPILE=${stdenv.cc.targetPrefix}"
];
outputs = [
"out"
"man"
];
installFlags = [ "install-systemd" ];
enableParallelBuilding = true;

View File

@@ -16,7 +16,7 @@ stdenv.mkDerivation (finalAttrs: {
owner = "jmk-foofus";
repo = "medusa";
tag = finalAttrs.version;
hash = "sha256-devirQMmS8mtxT5H5XafRRvCyfcvwoWxtTp0V1SJeSM=";
hash = "sha256-ftn5RBE3NYfjXLq8Gm92sbFW+M925BDuL/VmwfPYXpo=";
};
outputs = [

View File

@@ -2,12 +2,12 @@ This directory contains a vendored copy of `games.json`, along with tooling to g
## Purpose
The games data is fetched at runtime by NexusMods.App, however it is also included at build time for two reasons:
The games data is fetched at runtime by NexusMods.App, however, it is also included at build time for two reasons:
1. It allows tests to run against real data.
2. It is used as cached data, speeding up the app's initial run.
It is not vital for the file to contain all games, however ideally it should contain all games _supported_ by this version of NexusMods.App.
It is not vital for the file to contain all games, however, ideally it should contain all games _supported_ by this version of NexusMods.App.
That way the initial run's cached data is more useful.
If this file grows too large, because we are including too many games, we can patch the `csproj` build spec so that `games.json` is not used at build time.

View File

@@ -14,6 +14,17 @@ version = "2.9.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "1b8e56985ec62d17e9c1001dc89c88ecd7dc08e47eba5ec7c29c7b5eeecde967"
[[package]]
name = "bootspec"
version = "2.0.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "75726e2aa2b4c5a9d5c4cf3cb7f24658b6ec861616088f3ef3fb72edc0599286"
dependencies = [
"serde",
"serde_json",
"thiserror",
]
[[package]]
name = "cfg-if"
version = "1.0.1"
@@ -73,6 +84,12 @@ version = "2.0.6"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "f4c7245a08504955605670dbf141fceab975f15ca21570696aebe9d2e71576bd"
[[package]]
name = "itoa"
version = "1.0.16"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "7ee5b5339afb4c41626dde77b7a611bd4f2c202b897852b4bcf5d03eddc61010"
[[package]]
name = "libc"
version = "0.2.174"
@@ -91,14 +108,23 @@ version = "0.4.27"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "13dc2df351e3202783a1fe0d44375f7295ffb4049267b0f3018346dc122a1d94"
[[package]]
name = "memchr"
version = "2.7.6"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "f52b00d39961fc5b2736ea853c9cc86238e165017a493d1d5c8eac6bdc4cc273"
[[package]]
name = "nixos-init"
version = "0.1.0"
dependencies = [
"anyhow",
"bootspec",
"env_logger",
"indoc",
"log",
"serde",
"serde_json",
"tempfile",
]
@@ -108,6 +134,24 @@ version = "1.21.3"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "42f5e15c9953c5e4ccceeb2e7382a716482c34515315f7b03532b8b4e8393d2d"
[[package]]
name = "proc-macro2"
version = "1.0.103"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "5ee95bc4ef87b8d5ba32e8b7714ccc834865276eab0aed5c9958d00ec45f49e8"
dependencies = [
"unicode-ident",
]
[[package]]
name = "quote"
version = "1.0.42"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "a338cc41d27e6cc6dce6cefc13a0729dfbb81c262b1f519331575dd80ef3067f"
dependencies = [
"proc-macro2",
]
[[package]]
name = "r-efi"
version = "5.3.0"
@@ -127,6 +171,66 @@ dependencies = [
"windows-sys 0.60.2",
]
[[package]]
name = "ryu"
version = "1.0.21"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "62049b2877bf12821e8f9ad256ee38fdc31db7387ec2d3b3f403024de2034aea"
[[package]]
name = "serde"
version = "1.0.228"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "9a8e94ea7f378bd32cbbd37198a4a91436180c5bb472411e48b5ec2e2124ae9e"
dependencies = [
"serde_core",
"serde_derive",
]
[[package]]
name = "serde_core"
version = "1.0.228"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "41d385c7d4ca58e59fc732af25c3983b67ac852c1a25000afe1175de458b67ad"
dependencies = [
"serde_derive",
]
[[package]]
name = "serde_derive"
version = "1.0.228"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "d540f220d3187173da220f885ab66608367b6574e925011a9353e4badda91d79"
dependencies = [
"proc-macro2",
"quote",
"syn",
]
[[package]]
name = "serde_json"
version = "1.0.145"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "402a6f66d8c709116cf22f558eab210f5a50187f702eb4d7e5ef38d9a7f1c79c"
dependencies = [
"itoa",
"memchr",
"ryu",
"serde",
"serde_core",
]
[[package]]
name = "syn"
version = "2.0.111"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "390cc9a294ab71bdb1aa2e99d13be9c753cd2d7bd6560c77118597410c4d2e87"
dependencies = [
"proc-macro2",
"quote",
"unicode-ident",
]
[[package]]
name = "tempfile"
version = "3.20.0"
@@ -140,6 +244,32 @@ dependencies = [
"windows-sys 0.59.0",
]
[[package]]
name = "thiserror"
version = "1.0.69"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "b6aaf5339b578ea85b50e080feb250a3e8ae8cfcdff9a461c9ec2904bc923f52"
dependencies = [
"thiserror-impl",
]
[[package]]
name = "thiserror-impl"
version = "1.0.69"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "4fee6c4efc90059e10f81e6d42c60a18f76588c3d74cb83a0b242a2b6c7504c1"
dependencies = [
"proc-macro2",
"quote",
"syn",
]
[[package]]
name = "unicode-ident"
version = "1.0.22"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "9312f7c4f6ff9069b165498234ce8be658059c6728633667c526e27dc2cf1df5"
[[package]]
name = "wasi"
version = "0.14.2+wasi-0.2.4"

View File

@@ -7,6 +7,9 @@ edition = "2024"
anyhow = "1.0.98"
log = "0.4.27"
env_logger = { version = "0.11.8", default-features = false }
serde = { version = "1.0.228", features = ["derive"] }
serde_json = "1.0.145"
bootspec = "2.0.0"
[dev-dependencies]
tempfile = "3.20.0"

View File

@@ -29,7 +29,7 @@ robust.
writing correct software easier and should improve the quality of the NixOS
boot code.
- Most things can be started much later than one might assume. Because systemd
services are parallelized, this should improve start up time.
services are parallelized, this should improve startup time.
## Invariants
@@ -50,7 +50,7 @@ closure. Currently nixos-init comes in at ~500 KiB.
- `initrd-init`: Initializes the system on boot, setting up the tree for
systemd to start.
- `find-etc`: Finds the `/etc` paths in `/sysroot` so that the initrd doesn't
directly depend on the toplevel reducing the need to rebuild the initrd on
directly depend on the toplevel, reducing the need to rebuild the initrd on
every generation.
- `chroot-realpath`: Figures out the canonical path inside a chroot.

View File

@@ -1,4 +1,7 @@
use std::{fs, path::Path};
use std::{
fs,
path::{Path, PathBuf},
};
use anyhow::{Context, Result};
@@ -9,7 +12,8 @@ use crate::{config::Config, fs::atomic_symlink};
/// This runs both during boot and during re-activation initiated by switch-to-configuration.
pub fn activate(prefix: &str, toplevel: impl AsRef<Path>, config: &Config) -> Result<()> {
log::info!("Setting up /run/current-system...");
atomic_symlink(&toplevel, format!("{prefix}/run/current-system"))?;
let system_path = PathBuf::from(prefix).join("run/current-system");
atomic_symlink(&toplevel, system_path)?;
log::info!("Setting up modprobe...");
setup_modprobe(&config.modprobe_binary)?;
@@ -92,10 +96,9 @@ fn setup_firmware_search_path(firmware: impl AsRef<Path>) -> Result<()> {
///
/// We do this here accidentally. `/usr/bin/env` is currently load-bearing for `NixOS`.
fn setup_usrbinenv(prefix: &str, env_binary: impl AsRef<Path>) -> Result<()> {
const USRBINENV_PATH: &str = "/usr/bin/env";
fs::create_dir_all(format!("{prefix}/usr/bin")).context("Failed to create /usr/bin")?;
atomic_symlink(&env_binary, format!("{prefix}{USRBINENV_PATH}"))
let usrbin_path = PathBuf::from(prefix).join("usr/bin");
fs::create_dir_all(&usrbin_path).context("Failed to create /usr/bin")?;
atomic_symlink(&env_binary, usrbin_path.join("env"))
}
/// Setup /bin/sh.
@@ -103,6 +106,6 @@ fn setup_usrbinenv(prefix: &str, env_binary: impl AsRef<Path>) -> Result<()> {
/// `/bin/sh` is an essential part of a Linux system as this path is hardcoded in the `system()` call
/// from libc. See `man systemd(3)`.
fn setup_binsh(prefix: &str, sh_binary: impl AsRef<Path>) -> Result<()> {
const BINSH_PATH: &str = "/bin/sh";
atomic_symlink(&sh_binary, format!("{prefix}{BINSH_PATH}"))
let binsh_path = PathBuf::from(prefix).join("bin/sh");
atomic_symlink(&sh_binary, binsh_path)
}

View File

@@ -1,43 +1,39 @@
use std::env;
use serde::Deserialize;
use std::fs;
use std::path::{Path, PathBuf};
use anyhow::{Context, Result};
use bootspec::BootJson;
#[derive(Deserialize)]
pub struct Config {
pub firmware: String,
pub modprobe_binary: String,
pub nix_store_mount_opts: Vec<String>,
pub env_binary: Option<String>,
pub sh_binary: Option<String>,
pub etc_basedir: Option<String>,
pub etc_metadata_image: Option<String>,
}
impl Config {
/// Read the config from the environment.
///
/// These options are provided by wrapping the binary when assembling the toplevel.
pub fn from_env() -> Result<Self> {
let nix_store_mount_opts = required("NIX_STORE_MOUNT_OPTS")?
.split(',')
.map(std::borrow::ToOwned::to_owned)
.collect();
/// Read the config from the metadata file in the toplevel directory.
pub fn from_toplevel(toplevel: impl AsRef<Path>, prefix: &str) -> Result<Self> {
let bootspec_path =
PathBuf::from(prefix).join(toplevel.as_ref().join("boot.json").strip_prefix("/")?);
Ok(Self {
firmware: required("FIRMWARE")?,
modprobe_binary: required("MODPROBE_BINARY")?,
nix_store_mount_opts,
env_binary: optional("ENV_BINARY"),
sh_binary: optional("SH_BINARY"),
})
let boot_json: BootJson = fs::read(bootspec_path)
.context("Failed to read bootspec file")
.and_then(|raw| serde_json::from_slice(&raw).context("Failed to read bootspec JSON"))?;
let config = boot_json
.extensions
.get("org.nixos.nixos-init.v1")
.context("Failed to extract nixos-init bootspec extension")
.and_then(|v| {
serde_json::from_value(v.clone()).context("Failed to deserialise config")
})?;
Ok(config)
}
}
/// Read a required environment variable
///
/// Fail with useful context if the variable is not set in the environment.
fn required(key: &str) -> Result<String> {
env::var(key).with_context(|| format!("Failed to read {key} from environment"))
}
/// Read an optional environment variable
fn optional(key: &str) -> Option<String> {
env::var(key).ok()
}

View File

@@ -2,6 +2,7 @@ use std::{os::unix, path::Path};
use anyhow::{Context, Result};
use crate::config::Config;
use crate::{SYSROOT_PATH, canonicalize_in_chroot, find_toplevel_in_prefix};
/// Entrypoint for the `find-etc` binary.
@@ -12,20 +13,23 @@ use crate::{SYSROOT_PATH, canonicalize_in_chroot, find_toplevel_in_prefix};
/// need to re-build it.
pub fn find_etc() -> Result<()> {
let toplevel = find_toplevel_in_prefix(SYSROOT_PATH)?;
let config = Config::from_toplevel(&toplevel, SYSROOT_PATH)?;
let etc_metadata_image = Path::new(SYSROOT_PATH).join(
canonicalize_in_chroot(SYSROOT_PATH, &toplevel.join("etc-metadata-image"))?
.strip_prefix("/")?,
);
let basedir = config
.etc_basedir
.context("Failed to read etc_basedir from bootspec")?;
let etc_basedir = Path::new(SYSROOT_PATH)
.join(canonicalize_in_chroot(SYSROOT_PATH, Path::new(&basedir))?.strip_prefix("/")?);
let etc_basedir = Path::new(SYSROOT_PATH).join(
canonicalize_in_chroot(SYSROOT_PATH, &toplevel.join("etc-basedir"))?.strip_prefix("/")?,
);
let metadata_image = config
.etc_metadata_image
.context("Failed to read etc_metadata_image from bootspec")?;
let etc_metadata_image = Path::new(SYSROOT_PATH)
.join(canonicalize_in_chroot(SYSROOT_PATH, Path::new(&metadata_image))?.strip_prefix("/")?);
unix::fs::symlink(etc_basedir, "/etc-basedir").context("Failed to link /etc-basedir")?;
unix::fs::symlink(etc_metadata_image, "/etc-metadata-image")
.context("Failed to link /etc-metadata-image")?;
unix::fs::symlink(etc_basedir, "/etc-basedir").context("Failed to link /etc-basedir")?;
Ok(())
}

View File

@@ -60,7 +60,7 @@ fn remount_nix_store(prefix: &str, nix_store_mount_opts: &[String]) -> Result<()
if let Some(last_nix_store_mount) = mounts.find_mountpoint(&nix_store_path) {
for opt in nix_store_mount_opts {
if !last_nix_store_mount.mntopts.contains(opt) {
missing_opts.push(opt.to_string());
missing_opts.push(opt.clone());
}
}
if !missing_opts.is_empty() {

View File

@@ -8,13 +8,14 @@ use crate::{
///
/// Initialize `NixOS` from a systemd initrd.
pub fn initrd_init() -> Result<()> {
let config = Config::from_env().context("Failed to get configuration")?;
let init_in_sysroot =
find_init_in_prefix(SYSROOT_PATH).context("Failed to find init in sysroot")?;
let init_path = if let Ok(toplevel) = verify_init_is_nixos(SYSROOT_PATH, &init_in_sysroot) {
log::info!("Initializing NixOS...");
init(SYSROOT_PATH, toplevel, &config)?;
let config = Config::from_toplevel(&toplevel, SYSROOT_PATH)
.context("Failed to get configuration")?;
init(SYSROOT_PATH, &toplevel, &config)?;
None
} else {
log::info!("Not initializing NixOS. Switching to new root immediately...");

View File

@@ -12,7 +12,7 @@
.Op Fl -verbose | v
.Op Fl I Ar path
.Op Fl -root Ar root
.Op Fl -system Ar path
.Op Fl -system | -closure | -store-path Ar path
.Op Fl -flake Ar flake-uri
.Op Fl -file | f Ar path
.Op Fl -attr | A Ar attrPath
@@ -94,8 +94,8 @@ Defaults to
.Ar root
as the root of the NixOS installation.
.
.It Fl -system Ar path
If this option is provided,
.It Fl -system Ar path , Fl -closure Ar path , Fl -store-path Ar path
If one of those options is provided,
.Nm
will install the specified closure rather than attempt to build one from
.Pa /mnt/etc/nixos/configuration.nix Ns

View File

@@ -36,7 +36,7 @@ while [ "$#" -gt 0 ]; do
--root)
mountPoint="$1"; shift 1
;;
--system|--closure)
--system|--closure|--store-path)
system="$1"; shift 1
;;
--flake)

View File

@@ -40,19 +40,23 @@ def get_parser() -> tuple[argparse.ArgumentParser, dict[str, argparse.ArgumentPa
common_build_flags.add_argument("--print-build-logs", "-L", action="store_true")
common_build_flags.add_argument("--show-trace", action="store_true")
# Flags that apply to both flake evaluation and building
flake_common_flags = argparse.ArgumentParser(add_help=False, allow_abbrev=False)
flake_common_flags.add_argument("--accept-flake-config", action="store_true")
flake_common_flags.add_argument("--refresh", action="store_true")
flake_common_flags.add_argument("--impure", action="store_true")
flake_common_flags.add_argument("--offline", action="store_true")
flake_common_flags.add_argument("--no-net", action="store_true")
flake_common_flags.add_argument("--recreate-lock-file", action="store_true")
flake_common_flags.add_argument("--no-update-lock-file", action="store_true")
flake_common_flags.add_argument("--no-write-lock-file", action="store_true")
flake_common_flags.add_argument("--no-registries", action="store_true")
flake_common_flags.add_argument("--commit-lock-file", action="store_true")
flake_common_flags.add_argument("--update-input", action="append")
flake_common_flags.add_argument("--override-input", nargs=2, action="append")
# Flags that only apply during flake evaluation (and thus aren't passed to remote builders)
flake_eval_flags = argparse.ArgumentParser(add_help=False, allow_abbrev=False)
flake_eval_flags.add_argument("--accept-flake-config", action="store_true")
flake_eval_flags.add_argument("--refresh", action="store_true")
flake_eval_flags.add_argument("--impure", action="store_true")
flake_eval_flags.add_argument("--recreate-lock-file", action="store_true")
flake_eval_flags.add_argument("--no-update-lock-file", action="store_true")
flake_eval_flags.add_argument("--no-write-lock-file", action="store_true")
flake_eval_flags.add_argument("--no-registries", action="store_true")
flake_eval_flags.add_argument("--commit-lock-file", action="store_true")
flake_eval_flags.add_argument("--update-input", action="append")
flake_eval_flags.add_argument("--override-input", nargs=2, action="append")
classic_build_flags = argparse.ArgumentParser(add_help=False, allow_abbrev=False)
classic_build_flags.add_argument(
@@ -74,6 +78,7 @@ def get_parser() -> tuple[argparse.ArgumentParser, dict[str, argparse.ArgumentPa
"common_flags": common_flags,
"common_build_flags": common_build_flags,
"flake_common_flags": flake_common_flags,
"flake_eval_flags": flake_eval_flags,
"classic_build_flags": classic_build_flags,
"copy_flags": copy_flags,
}

View File

@@ -150,8 +150,8 @@ class GroupedNixArgs:
build_flags: Args
common_flags: Args
copy_flags: Args
flake_eval_flags: Args
flake_build_flags: Args
flake_common_flags: Args
@classmethod
def from_parsed_args_groups(cls, args_groups: dict[str, Namespace]) -> Self:
@@ -159,6 +159,7 @@ class GroupedNixArgs:
common_build_flags = common_flags | vars(args_groups["common_build_flags"])
build_flags = common_build_flags | vars(args_groups["classic_build_flags"])
flake_common_flags = common_flags | vars(args_groups["flake_common_flags"])
flake_eval_flags = vars(args_groups["flake_eval_flags"])
flake_build_flags = common_build_flags | flake_common_flags
copy_flags = common_flags | vars(args_groups["copy_flags"])
# --no-build-output -> --no-link
@@ -169,8 +170,8 @@ class GroupedNixArgs:
build_flags=build_flags,
common_flags=common_flags,
copy_flags=copy_flags,
flake_eval_flags=flake_eval_flags,
flake_build_flags=flake_build_flags,
flake_common_flags=flake_common_flags,
)

View File

@@ -43,7 +43,9 @@ def reexec(
drv = nix.build_flake(
NIXOS_REBUILD_ATTR,
flake,
grouped_nix_args.flake_build_flags | {"no_link": True},
grouped_nix_args.flake_build_flags
| grouped_nix_args.flake_eval_flags
| {"no_link": True},
)
else:
build_attr = BuildAttr.from_arg(args.attr, args.file)
@@ -101,7 +103,8 @@ def _get_system_attr(
case Action.BUILD_IMAGE if flake:
variants = nix.get_build_image_variants_flake(
flake,
eval_flags=grouped_nix_args.flake_common_flags,
eval_flags=grouped_nix_args.flake_build_flags
| grouped_nix_args.flake_eval_flags,
)
_validate_image_variant(args.image_variant, variants)
attr = f"config.system.build.images.{args.image_variant}"
@@ -164,7 +167,8 @@ def _build_system(
attr,
flake,
build_host,
eval_flags=grouped_nix_args.flake_common_flags,
eval_flags=grouped_nix_args.flake_build_flags
| grouped_nix_args.flake_eval_flags,
flake_build_flags={"no_link": no_link, "dry_run": dry_run}
| grouped_nix_args.flake_build_flags,
copy_flags=grouped_nix_args.copy_flags,
@@ -174,7 +178,8 @@ def _build_system(
attr,
flake,
flake_build_flags={"no_link": no_link, "dry_run": dry_run}
| grouped_nix_args.flake_build_flags,
| grouped_nix_args.flake_build_flags
| grouped_nix_args.flake_eval_flags,
)
case (Remote(_), None):
path_to_config = nix.build_remote(
@@ -259,7 +264,8 @@ def _activate_system(
image_name = nix.get_build_image_name_flake(
flake,
args.image_variant,
eval_flags=grouped_nix_args.flake_common_flags,
eval_flags=grouped_nix_args.flake_build_flags
| grouped_nix_args.flake_eval_flags,
)
else:
image_name = nix.get_build_image_name(
@@ -329,7 +335,10 @@ def build_and_activate_system(
def edit(flake: Flake | None, grouped_nix_args: GroupedNixArgs) -> None:
if flake:
nix.edit_flake(flake, grouped_nix_args.flake_build_flags)
nix.edit_flake(
flake,
grouped_nix_args.flake_build_flags | grouped_nix_args.flake_eval_flags,
)
else:
nix.edit()
@@ -360,7 +369,10 @@ def repl(
grouped_nix_args: GroupedNixArgs,
) -> None:
if flake:
nix.repl_flake(flake, grouped_nix_args.flake_build_flags)
nix.repl_flake(
flake,
grouped_nix_args.flake_build_flags | grouped_nix_args.flake_eval_flags,
)
else:
nix.repl(build_attr, grouped_nix_args.build_flags)

View File

@@ -97,13 +97,8 @@ def test_parse_args() -> None:
"foo2",
"bar2",
]
assert nr.utils.dict_to_flags(g1.flake_common_flags) == [
"--option",
"foo1",
"bar1",
"--option",
"foo2",
"bar2",
# flake_eval_flags contains only eval-specific flags
assert nr.utils.dict_to_flags(g1.flake_eval_flags) == [
"--update-input",
"input1",
"--update-input",
@@ -115,6 +110,15 @@ def test_parse_args() -> None:
"override2",
"input2",
]
# flake_build_flags contains common build flags (for remote builds)
assert nr.utils.dict_to_flags(g1.flake_build_flags) == [
"--option",
"foo1",
"bar1",
"--option",
"foo2",
"bar2",
]
r2, g2 = nr.parse_args(
[

View File

@@ -180,3 +180,46 @@ def test_profile_from_arg(mock_mkdir: Mock) -> None:
Path("/nix/var/nix/profiles/system-profiles/something"),
)
mock_mkdir.assert_called_once()
def test_grouped_nix_args_flake_build_flags() -> None:
"""Test that flake_build_flags excludes evaluation-only flags."""
from argparse import Namespace
args_groups = {
"common_flags": Namespace(v=0, quiet=0, max_jobs=None, cores=None),
"common_build_flags": Namespace(builders=None, include=None),
"flake_common_flags": Namespace(offline=True, no_net=False),
"flake_eval_flags": Namespace(
override_input=[["nixpkgs", "/local"]],
impure=True,
refresh=True,
accept_flake_config=False,
recreate_lock_file=False,
no_update_lock_file=False,
no_write_lock_file=False,
no_registries=False,
commit_lock_file=False,
update_input=None,
),
"classic_build_flags": Namespace(no_build_output=False),
"copy_flags": Namespace(s=False),
}
grouped = m.GroupedNixArgs.from_parsed_args_groups(args_groups)
# flake_eval_flags should contain ONLY eval-only flags
assert "override_input" in grouped.flake_eval_flags
assert "impure" in grouped.flake_eval_flags
assert "refresh" in grouped.flake_eval_flags
# flake_eval_flags should NOT contain common/build flags
assert "offline" not in grouped.flake_eval_flags
# flake_build_flags should NOT contain eval-only flags
assert "override_input" not in grouped.flake_build_flags
assert "impure" not in grouped.flake_build_flags
assert "refresh" not in grouped.flake_build_flags
# But flake_build_flags should still have common flags
assert "offline" in grouped.flake_build_flags
assert grouped.flake_build_flags["offline"] is True

View File

@@ -23,8 +23,8 @@ def test_reexec(mock_build: Mock, mock_execve: Mock, monkeypatch: MonkeyPatch) -
build_flags={"build": True},
common_flags={"common": True},
copy_flags={"copy": True},
flake_eval_flags={"flake_eval": True},
flake_build_flags={"flake_build": True},
flake_common_flags={"flake_common": True},
)
s.reexec(argv, args, grouped_nix_args)
mock_build.assert_has_calls(
@@ -76,14 +76,14 @@ def test_reexec_flake(
build_flags={"build": True},
common_flags={"common": True},
copy_flags={"copy": True},
flake_eval_flags={"flake_eval": True},
flake_build_flags={"flake_build": True},
flake_common_flags={"flake_common": True},
)
s.reexec(argv, args, grouped_nix_args)
mock_build.assert_called_once_with(
s.NIXOS_REBUILD_ATTR,
n.models.Flake(ANY, ANY),
{"flake_build": True, "no_link": True},
{"flake_build": True, "flake_eval": True, "no_link": True},
)
# do not exec if there is no new version
mock_execve.assert_not_called()
@@ -122,8 +122,8 @@ def test_reexec_skip_if_already_reexec(mock_build: Mock, mock_execve: Mock) -> N
build_flags={"build": True},
common_flags={"common": True},
copy_flags={"copy": True},
flake_eval_flags={"flake_eval": True},
flake_build_flags={"flake_build": True},
flake_common_flags={"flake_common": True},
)
s.reexec(argv, args, grouped_nix_args)
mock_build.assert_not_called()

View File

@@ -13,7 +13,7 @@ Maintaining our own documentation rendering framework may appear extreme but has
- The amount of code involved is minimal because it's single-purpose
Several alternatives to `nixos-render-docs` were discussed in the past.
A detailed analysis can be found in a [table comparing documentation rendering framework](https://ethercalc.net/dc4vcnnl8zv0).
A detailed analysis can be found in a [table comparing documentation rendering frameworks](https://ethercalc.net/dc4vcnnl8zv0).
## Redirects system
@@ -78,7 +78,7 @@ In case this identifier is renamed, the mapping would change into:
## Rendering multiple pages
The `include` directive accepts an argument `into-file` to specify the file into which the imported markdown should be rendered to. We can use this argument to set up multipage rendering of the manuals.
The `include` directive accepts an argument `into-file` to specify the file into which the imported markdown should be rendered. We can use this argument to set up multipage rendering of the manuals.
For example

View File

@@ -7,16 +7,16 @@
rustPlatform.buildRustPackage (finalAttrs: {
pname = "nu_plugin_desktop_notifications";
version = "0.108.0";
version = "0.110.0";
src = fetchFromGitHub {
owner = "FMotalleb";
repo = "nu_plugin_desktop_notifications";
tag = "v${finalAttrs.version}";
hash = "sha256-9NkWPoTdMxFlI/BkP8w0ltC6UVh3/tg9gjwBuS3k/Cg=";
hash = "sha256-jd4T0+id/1rpjOWuzqbqxnyvmoe4LCiYux/dJlO3F6c=";
};
cargoHash = "sha256-GK6ytH/SDHh6GlLrSA2oJLza1tvYOUp4cR5CM6bloz8=";
cargoHash = "sha256-7ZiQr8RBQCNQK3/tLasilZcu+HWp066iDFI67L8iZMg=";
passthru.updateScript = nix-update-script { };

View File

@@ -9,16 +9,16 @@
rustPlatform.buildRustPackage (finalAttrs: {
pname = "nu_plugin_hcl";
version = "0.108.0";
version = "0.110.0";
src = fetchFromGitHub {
owner = "Yethal";
repo = "nu_plugin_hcl";
tag = finalAttrs.version;
hash = "sha256-WyZ8uSYWNzurqpE+BP0hKsknurP7Iyf5L8Y5DjVQZsA=";
hash = "sha256-8P0gNLe8OjB3NoDxHtDUp859O1O4WwmDeACJe5u8GPg=";
};
cargoHash = "sha256-2b/0B9W01gGuGc482DYQSbRR2LLZXQxUG2fYB5TklPQ=";
cargoHash = "sha256-ACtnklcypc2gjWujPSLUgwGbah2G+QHLD7fr7S7QNAg=";
nativeBuildInputs = [ pkg-config ] ++ lib.optionals stdenv.cc.isClang [ rustPlatform.bindgenHook ];

View File

@@ -9,17 +9,17 @@
rustPlatform.buildRustPackage (finalAttrs: {
pname = "nu_plugin_highlight";
version = "1.4.10+0.108.0";
version = "1.4.12+0.110.0";
src = fetchFromGitHub {
owner = "cptpiepmatz";
repo = "nu-plugin-highlight";
tag = "v${finalAttrs.version}";
hash = "sha256-ynvLvGMxFiYOYGPDdlv1509lWU5DpfBK9Mwa9gLeHsI=";
hash = "sha256-20b+EiB95BzDVWibWQuG8ozPRV8LbxG7fHEbyTk3xTE=";
fetchSubmodules = true;
};
cargoHash = "sha256-Xq7ctnzcrSPzo3M3p3Vxtj0U0U9Miw+2VuyYs6P3GlQ=";
cargoHash = "sha256-pkLcTjZYLERMhK18zPdfldHrECHXQpcg5i6rsyxw7nQ=";
nativeBuildInputs = [ pkg-config ] ++ lib.optionals stdenv.cc.isClang [ rustPlatform.bindgenHook ];

View File

@@ -7,16 +7,16 @@
rustPlatform.buildRustPackage (finalAttrs: {
pname = "nu_plugin_semver";
version = "0.11.8";
version = "0.11.14";
src = fetchFromGitHub {
owner = "abusch";
repo = "nu_plugin_semver";
tag = "v${finalAttrs.version}";
hash = "sha256-ui9zyE5g4LiU2+Csv4p0D61fmPXaDMhnpQ34ggEg3eA=";
hash = "sha256-mfwgwY/iYdMz8Qn6a9zfpMHWHl2n1Q8ClkT+KiCAGyk=";
};
cargoHash = "sha256-5W0GbKz18rQ+3TjNanzV4H4LE/7TLZ+8/FbGHffE2RY=";
cargoHash = "sha256-5zVqMUC+wg2joo1DKuTUdRwsC5iH7uuyML9SnB2bZCs=";
passthru.updateScript = nix-update-script { };

View File

@@ -8,16 +8,16 @@
rustPlatform.buildRustPackage (finalAttrs: {
pname = "nu_plugin_skim";
version = "0.20.1";
version = "0.22.0";
src = fetchFromGitHub {
owner = "idanarye";
repo = "nu_plugin_skim";
tag = "v${finalAttrs.version}";
hash = "sha256-2CqgtV2DnBd8HqnRdZRiT14aw+meaX4A3ndTGvbsMfo=";
hash = "sha256-TdsemIPbknJiglxhQwBch8iJ9GVa+Sj3fqSq4xaDqfk=";
};
cargoHash = "sha256-3Kua+gZl4Ff6jfSNyEVDbPVH4YfGXhwtuEjcUADecQE=";
cargoHash = "sha256-vpRL4oiOmhnGO+eWWTA7/RvVrtouVzqJvPGZY/cHeXY=";
nativeBuildInputs = lib.optionals stdenv.cc.isClang [ rustPlatform.bindgenHook ];

View File

@@ -23,7 +23,7 @@ let
# NOTE: when updating this to a new non-patch version, please also try to
# update the plugins. Plugins only work if they are compiled for the same
# major/minor version.
version = "0.109.1";
version = "0.110.0";
in
rustPlatform.buildRustPackage {
pname = "nushell";
@@ -33,10 +33,10 @@ rustPlatform.buildRustPackage {
owner = "nushell";
repo = "nushell";
tag = version;
hash = "sha256-XNDEfmvmUNS90PU4e/EWFyJeg428R8nFPJHpF3tgRWo=";
hash = "sha256-iytTJZ70kg2Huwj/BSwDX4h9DVDTlJR2gEHAB2pGn/k=";
};
cargoHash = "sha256-UX0WmvrzrWlrTnvMqaWAxoSie7RzQSC4thEb26LAz+A=";
cargoHash = "sha256-a/N0a9ZVqXAjAl5Z7BdEsIp0He3h0S/owS0spEPb3KI=";
nativeBuildInputs = [
pkg-config

View File

@@ -20,26 +20,26 @@
rustPlatform.buildRustPackage (finalAttrs: {
pname = "rclone-ui";
version = "3.2.2";
version = "3.3.0";
src = fetchFromGitHub {
owner = "rclone-ui";
repo = "rclone-ui";
tag = "v${finalAttrs.version}";
hash = "sha256-CQnjwbmVpCTvt9FSmQhYmU+0y+jSsR7bFBbeoZu16a4=";
hash = "sha256-GKOIS/kp1zfBu1/goH3zjQGrvs6opS4Sghpgc60xn0s=";
};
npmDeps = fetchNpmDeps {
name = "${finalAttrs.pname}-${finalAttrs.version}-npm-deps";
inherit (finalAttrs) src;
forceGitDeps = true;
hash = "sha256-zGgW/WikSVBE1goJ3zTf0ijBUghb+MlzMI+OxiLvzfY=";
hash = "sha256-uvtYyAE68atl933dhgpwBipO01xecSCMKsrv9NdSEhk=";
};
cargoRoot = "src-tauri";
buildAndTestSubdir = finalAttrs.cargoRoot;
cargoHash = "sha256-nQhZuG3CxoLZwBSbA8I/Ft6HRkdb/5CRrpF6423lsFo=";
cargoHash = "sha256-1RxgcRM0Qs/bMj8mVLFZXD1Y8L+JZnc4BTmD5Y609Sk=";
# Disable tauri bundle updater, can be removed when #389107 is merged
patches = [ ./remove_updater.patch ];

Some files were not shown because too many files have changed in this diff Show More