From 0be441df8b25bcc18f36af13aa9dc6b8cc9c8f4f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dani=C3=ABl=20de=20Kok?= Date: Fri, 11 Dec 2020 07:36:36 +0100 Subject: [PATCH 1/7] libtorch-bin: 1.7.0 -> 1.7.1 Changelog: https://github.com/pytorch/pytorch/releases/tag/v1.7.1 --- pkgs/development/libraries/science/math/libtorch/bin.nix | 2 +- .../libraries/science/math/libtorch/binary-hashes.nix | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/pkgs/development/libraries/science/math/libtorch/bin.nix b/pkgs/development/libraries/science/math/libtorch/bin.nix index 7c78f61af694..fba8bcb9367b 100644 --- a/pkgs/development/libraries/science/math/libtorch/bin.nix +++ b/pkgs/development/libraries/science/math/libtorch/bin.nix @@ -12,7 +12,7 @@ }: let - version = "1.7.0"; + version = "1.7.1"; device = if cudaSupport then "cuda" else "cpu"; srcs = import ./binary-hashes.nix version; unavailable = throw "libtorch is not available for this platform"; diff --git a/pkgs/development/libraries/science/math/libtorch/binary-hashes.nix b/pkgs/development/libraries/science/math/libtorch/binary-hashes.nix index 6048fe8676b7..7f815a31a51e 100644 --- a/pkgs/development/libraries/science/math/libtorch/binary-hashes.nix +++ b/pkgs/development/libraries/science/math/libtorch/binary-hashes.nix @@ -1,14 +1,14 @@ version: { x86_64-darwin-cpu = { url = "https://download.pytorch.org/libtorch/cpu/libtorch-macos-${version}.zip"; - sha256 = "1912lklil0i7i10j1fm4qzcq96cc8c281l9fn5gfbwa2wwry0r59"; + sha256 = "0n93r7bq6wjjxkczp8r5pjm1nvl75wns5higsvh7gsir0j6k7b5b"; }; x86_64-linux-cpu = { url = "https://download.pytorch.org/libtorch/cpu/libtorch-cxx11-abi-shared-with-deps-${version}%2Bcpu.zip"; - sha256 = "0jdd7bjcy20xz2gfv8f61zdrbzxz5425bnqaaqgrwpzvd45ay8px"; + sha256 = "0gpcj90nxyc69p53jiqwamd4gi7wzssk29csxfsyxsrzg3h36s7z"; }; x86_64-linux-cuda = { url = "https://download.pytorch.org/libtorch/cu102/libtorch-cxx11-abi-shared-with-deps-${version}.zip"; - sha256 = "1ag6lvf3a400ivqq4g9cxpmxzlfrga0y5ssjy0rfpw6i1xljibn6"; + sha256 = "01z61ryrflq306x7ay97k2fqc2q2z9c4c1zcnjfzr6412vg4fjb8"; }; } From 71a7249a483db8faa90a6c00dd63e78aa6621e14 Mon Sep 17 00:00:00 2001 From: Ben Siraphob Date: Sun, 29 Nov 2020 20:48:45 +0700 Subject: [PATCH 2/7] doc/stdenv/cross-compilation: convert to markdown --- doc/manual.xml | 2 +- doc/stdenv/cross-compilation.chapter.md | 197 ++++++++++++ doc/stdenv/cross-compilation.xml | 394 ------------------------ 3 files changed, 198 insertions(+), 395 deletions(-) create mode 100644 doc/stdenv/cross-compilation.chapter.md delete mode 100644 doc/stdenv/cross-compilation.xml diff --git a/doc/manual.xml b/doc/manual.xml index 2c75bd4ec09f..4367c023b402 100644 --- a/doc/manual.xml +++ b/doc/manual.xml @@ -18,7 +18,7 @@ - + diff --git a/doc/stdenv/cross-compilation.chapter.md b/doc/stdenv/cross-compilation.chapter.md new file mode 100644 index 000000000000..bc7a1a138173 --- /dev/null +++ b/doc/stdenv/cross-compilation.chapter.md @@ -0,0 +1,197 @@ +# Cross-compilation {#chap-cross} + +## Introduction {#sec-cross-intro} + +"Cross-compilation" means compiling a program on one machine for another type of machine. For example, a typical use of cross-compilation is to compile programs for embedded devices. These devices often don't have the computing power and memory to compile their own programs. One might think that cross-compilation is a fairly niche concern. However, there are significant advantages to rigorously distinguishing between build-time and run-time environments! Significant, because the benefits apply even when one is developing and deploying on the same machine. Nixpkgs is increasingly adopting the opinion that packages should be written with cross-compilation in mind, and Nixpkgs should evaluate in a similar way (by minimizing cross-compilation-specific special cases) whether or not one is cross-compiling. + +This chapter will be organized in three parts. First, it will describe the basics of how to package software in a way that supports cross-compilation. Second, it will describe how to use Nixpkgs when cross-compiling. Third, it will describe the internal infrastructure supporting cross-compilation. + + +## Packaging in a cross-friendly manner {#sec-cross-packaging} + +### Platform parameters {#ssec-cross-platform-parameters} + +Nixpkgs follows the [conventions of GNU autoconf](https://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html). We distinguish between 3 types of platforms when building a derivation: _build_, _host_, and _target_. In summary, _build_ is the platform on which a package is being built, _host_ is the platform on which it will run. The third attribute, _target_, is relevant only for certain specific compilers and build tools. + +In Nixpkgs, these three platforms are defined as attribute sets under the names `buildPlatform`, `hostPlatform`, and `targetPlatform`. They are always defined as attributes in the standard environment. That means one can access them like: + +```nix +{ stdenv, fooDep, barDep, .. }: ...stdenv.buildPlatform... +``` + +`buildPlatform` + +: The "build platform" is the platform on which a package is built. Once someone has a built package, or pre-built binary package, the build platform should not matter and can be ignored. + +`hostPlatform` + +: The "host platform" is the platform on which a package will be run. This is the simplest platform to understand, but also the one with the worst name. + +`targetPlatform` + +: The "target platform" attribute is, unlike the other two attributes, not actually fundamental to the process of building software. Instead, it is only relevant for compatibility with building certain specific compilers and build tools. It can be safely ignored for all other packages. + +: The build process of certain compilers is written in such a way that the compiler resulting from a single build can itself only produce binaries for a single platform. The task of specifying this single "target platform" is thus pushed to build time of the compiler. The root cause of this is that the compiler (which will be run on the host) and the standard library/runtime (which will be run on the target) are built by a single build process. + +: There is no fundamental need to think about a single target ahead of time like this. If the tool supports modular or pluggable backends, both the need to specify the target at build time and the constraint of having only a single target disappear. An example of such a tool is LLVM. + +: Although the existence of a "target platform" is arguably a historical mistake, it is a common one: examples of tools that suffer from it are GCC, Binutils, GHC and Autoconf. Nixpkgs tries to avoid sharing in the mistake where possible. Still, because the concept of a target platform is so ingrained, it is best to support it as is. + +The exact schema these fields follow is a bit ill-defined due to a long and convoluted evolution, but this is slowly being cleaned up. You can see examples of ones used in practice in `lib.systems.examples`; note how they are not all very consistent. For now, here are few fields can count on them containing: + +`system` + +: This is a two-component shorthand for the platform. Examples of this would be "x86_64-darwin" and "i686-linux"; see `lib.systems.doubles` for more. The first component corresponds to the CPU architecture of the platform and the second to the operating system of the platform (`[cpu]-[os]`). This format has built-in support in Nix, such as the `builtins.currentSystem` impure string. + +`config` + +: This is a 3- or 4- component shorthand for the platform. Examples of this would be `x86_64-unknown-linux-gnu` and `aarch64-apple-darwin14`. This is a standard format called the "LLVM target triple", as they are pioneered by LLVM. In the 4-part form, this corresponds to `[cpu]-[vendor]-[os]-[abi]`. This format is strictly more informative than the "Nix host double", as the previous format could analogously be termed. This needs a better name than `config`! + +`parsed` + +: This is a Nix representation of a parsed LLVM target triple with white-listed components. This can be specified directly, or actually parsed from the `config`. See `lib.systems.parse` for the exact representation. + +`libc` + +: This is a string identifying the standard C library used. Valid identifiers include "glibc" for GNU libc, "libSystem" for Darwin's Libsystem, and "uclibc" for µClibc. It should probably be refactored to use the module system, like `parse`. + +`is*` + +: These predicates are defined in `lib.systems.inspect`, and slapped onto every platform. They are superior to the ones in `stdenv` as they force the user to be explicit about which platform they are inspecting. Please use these instead of those. + +`platform` + +: This is, quite frankly, a dumping ground of ad-hoc settings (it's an attribute set). See `lib.systems.platforms` for examples—there's hopefully one in there that will work verbatim for each platform that is working. Please help us triage these flags and give them better homes! + +### Theory of dependency categorization {#ssec-cross-dependency-categorization} + +::: note +This is a rather philosophical description that isn't very Nixpkgs-specific. For an overview of all the relevant attributes given to `mkDerivation`, see . For a description of how everything is implemented, see . +::: + +In this section we explore the relationship between both runtime and build-time dependencies and the 3 Autoconf platforms. + +A run time dependency between two packages requires that their host platforms match. This is directly implied by the meaning of "host platform" and "runtime dependency": The package dependency exists while both packages are running on a single host platform. + +A build time dependency, however, has a shift in platforms between the depending package and the depended-on package. "build time dependency" means that to build the depending package we need to be able to run the depended-on's package. The depending package's build platform is therefore equal to the depended-on package's host platform. + +If both the dependency and depending packages aren't compilers or other machine-code-producing tools, we're done. And indeed `buildInputs` and `nativeBuildInputs` have covered these simpler build-time and run-time (respectively) changes for many years. But if the dependency does produce machine code, we might need to worry about its target platform too. In principle, that target platform might be any of the depending package's build, host, or target platforms, but we prohibit dependencies from a "later" platform to an earlier platform to limit confusion because we've never seen a legitimate use for them. + +Finally, if the depending package is a compiler or other machine-code-producing tool, it might need dependencies that run at "emit time". This is for compilers that (regrettably) insist on being built together with their source languages' standard libraries. Assuming build != host != target, a run-time dependency of the standard library cannot be run at the compiler's build time or run time, but only at the run time of code emitted by the compiler. + +Putting this all together, that means we have dependencies in the form "host → target", in at most the following six combinations: + + +#### Possible dependency types +| Dependency's host platform | Dependency's target platform | +| -- | -- | +| build | build | +| build | host | +| build | target | +| host | host | +| host | target | +| target | target | + + +Some examples will make this table clearer. Suppose there's some package that is being built with a `(build, host, target)` platform triple of `(foo, bar, baz)`. If it has a build-time library dependency, that would be a "host → build" dependency with a triple of `(foo, foo, *)` (the target platform is irrelevant). If it needs a compiler to be built, that would be a "build → host" dependency with a triple of `(foo, foo, *)` (the target platform is irrelevant). That compiler, would be built with another compiler, also "build → host" dependency, with a triple of `(foo, foo, foo)`. + +### Cross packaging cookbook {#ssec-cross-cookbook} + +Some frequently encountered problems when packaging for cross-compilation should be answered here. Ideally, the information above is exhaustive, so this section cannot provide any new information, but it is ludicrous and cruel to expect everyone to spend effort working through the interaction of many features just to figure out the same answer to the same common problem. Feel free to add to this list! + +#### What if my package's build system needs to build a C program to be run under the build environment? {#cross-qa-build-c-program-in-build-environment} +Add the following to your `mkDerivation` invocation. +```nix +depsBuildBuild = [ buildPackages.stdenv.cc ]; +``` + +#### My package fails to find `ar`. {#cross-qa-fails-to-find-ar} +Many packages assume that an unprefixed `ar` is available, but Nix doesn't provide one. It only provides a prefixed one, just as it only does for all the other binutils programs. It may be necessary to patch the package to fix the build system to use a prefixed `ar`. + +#### My package's testsuite needs to run host platform code. {#cross-testsuite-runs-host-code} + +Add the following to your `mkDerivation` invocation. +```nix +doCheck = stdenv.hostPlatform == stdenv.buildPlatfrom; +``` + +## Cross-building packages {#sec-cross-usage} + +Nixpkgs can be instantiated with `localSystem` alone, in which case there is no cross-compiling and everything is built by and for that system, or also with `crossSystem`, in which case packages run on the latter, but all building happens on the former. Both parameters take the same schema as the 3 (build, host, and target) platforms defined in the previous section. As mentioned above, `lib.systems.examples` has some platforms which are used as arguments for these parameters in practice. You can use them programmatically, or on the command line: + +```ShellSession +$ nix-build '' --arg crossSystem '(import ).systems.examples.fooBarBaz' -A whatever +``` + +::: note +Eventually we would like to make these platform examples an unnecessary convenience so that + +```ShellSession +$ nix-build '' --arg crossSystem '{ config = "---"; }' -A whatever +``` + +works in the vast majority of cases. The problem today is dependencies on other sorts of configuration which aren't given proper defaults. We rely on the examples to crudely to set those configuration parameters in some vaguely sane manner on the users behalf. Issue [\#34274](https://github.com/NixOS/nixpkgs/issues/34274) tracks this inconvenience along with its root cause in crufty configuration options. +::: + +While one is free to pass both parameters in full, there's a lot of logic to fill in missing fields. As discussed in the previous section, only one of `system`, `config`, and `parsed` is needed to infer the other two. Additionally, `libc` will be inferred from `parse`. Finally, `localSystem.system` is also _impurely_ inferred based on the platform evaluation occurs. This means it is often not necessary to pass `localSystem` at all, as in the command-line example in the previous paragraph. + +::: note +Many sources (manual, wiki, etc) probably mention passing `system`, `platform`, along with the optional `crossSystem` to Nixpkgs: `import { system = ..; platform = ..; crossSystem = ..; }`. Passing those two instead of `localSystem` is still supported for compatibility, but is discouraged. Indeed, much of the inference we do for these parameters is motivated by compatibility as much as convenience. +::: + +One would think that `localSystem` and `crossSystem` overlap horribly with the three `*Platforms` (`buildPlatform`, `hostPlatform,` and `targetPlatform`; see `stage.nix` or the manual). Actually, those identifiers are purposefully not used here to draw a subtle but important distinction: While the granularity of having 3 platforms is necessary to properly *build* packages, it is overkill for specifying the user's *intent* when making a build plan or package set. A simple "build vs deploy" dichotomy is adequate: the sliding window principle described in the previous section shows how to interpolate between the these two "end points" to get the 3 platform triple for each bootstrapping stage. That means for any package a given package set, even those not bound on the top level but only reachable via dependencies or `buildPackages`, the three platforms will be defined as one of `localSystem` or `crossSystem`, with the former replacing the latter as one traverses build-time dependencies. A last simple difference is that `crossSystem` should be null when one doesn't want to cross-compile, while the `*Platform`s are always non-null. `localSystem` is always non-null. + +## Cross-compilation infrastructure {#sec-cross-infra} + +### Implementation of dependencies {#ssec-cross-dependency-implementation} + +The categories of dependencies developed in are specified as lists of derivations given to `mkDerivation`, as documented in . In short, each list of dependencies for "host → target" of "foo → bar" is called `depsFooBar`, with exceptions for backwards compatibility that `depsBuildHost` is instead called `nativeBuildInputs` and `depsHostTarget` is instead called `buildInputs`. Nixpkgs is now structured so that each `depsFooBar` is automatically taken from `pkgsFooBar`. (These `pkgsFooBar`s are quite new, so there is no special case for `nativeBuildInputs` and `buildInputs`.) For example, `pkgsBuildHost.gcc` should be used at build-time, while `pkgsHostTarget.gcc` should be used at run-time. + +Now, for most of Nixpkgs's history, there were no `pkgsFooBar` attributes, and most packages have not been refactored to use it explicitly. Prior to those, there were just `buildPackages`, `pkgs`, and `targetPackages`. Those are now redefined as aliases to `pkgsBuildHost`, `pkgsHostTarget`, and `pkgsTargetTarget`. It is acceptable, even recommended, to use them for libraries to show that the host platform is irrelevant. + +But before that, there was just `pkgs`, even though both `buildInputs` and `nativeBuildInputs` existed. \[Cross barely worked, and those were implemented with some hacks on `mkDerivation` to override dependencies.\] What this means is the vast majority of packages do not use any explicit package set to populate their dependencies, just using whatever `callPackage` gives them even if they do correctly sort their dependencies into the multiple lists described above. And indeed, asking that users both sort their dependencies, _and_ take them from the right attribute set, is both too onerous and redundant, so the recommended approach (for now) is to continue just categorizing by list and not using an explicit package set. + +To make this work, we "splice" together the six `pkgsFooBar` package sets and have `callPackage` actually take its arguments from that. This is currently implemented in `pkgs/top-level/splice.nix`. `mkDerivation` then, for each dependency attribute, pulls the right derivation out from the splice. This splicing can be skipped when not cross-compiling as the package sets are the same, but still is a bit slow for cross-compiling. We'd like to do something better, but haven't come up with anything yet. + +### Bootstrapping {#ssec-bootstrapping} + +Each of the package sets described above come from a single bootstrapping stage. While `pkgs/top-level/default.nix`, coordinates the composition of stages at a high level, `pkgs/top-level/stage.nix` "ties the knot" (creates the fixed point) of each stage. The package sets are defined per-stage however, so they can be thought of as edges between stages (the nodes) in a graph. Compositions like `pkgsBuildTarget.targetPackages` can be thought of as paths to this graph. + +While there are many package sets, and thus many edges, the stages can also be arranged in a linear chain. In other words, many of the edges are redundant as far as connectivity is concerned. This hinges on the type of bootstrapping we do. Currently for cross it is: + +1. `(native, native, native)` + +2. `(native, native, foreign)` + +3. `(native, foreign, foreign)` + +In each stage, `pkgsBuildHost` refers to the previous stage, `pkgsBuildBuild` refers to the one before that, and `pkgsHostTarget` refers to the current one, and `pkgsTargetTarget` refers to the next one. When there is no previous or next stage, they instead refer to the current stage. Note how all the invariants regarding the mapping between dependency and depending packages' build host and target platforms are preserved. `pkgsBuildTarget` and `pkgsHostHost` are more complex in that the stage fitting the requirements isn't always a fixed chain of "prevs" and "nexts" away (modulo the "saturating" self-references at the ends). We just special case each instead. All the primary edges are implemented is in `pkgs/stdenv/booter.nix`, and secondarily aliases in `pkgs/top-level/stage.nix`. + +::: note +The native stages are bootstrapped in legacy ways that predate the current cross implementation. This is why the bootstrapping stages leading up to the final stages are ignored in the previous paragraph. +::: + +If one looks at the 3 platform triples, one can see that they overlap such that one could put them together into a chain like: +``` +(native, native, native, foreign, foreign) +``` +If one imagines the saturating self references at the end being replaced with infinite stages, and then overlays those platform triples, one ends up with the infinite tuple: +``` +(native..., native, native, native, foreign, foreign, foreign...) +``` +On can then imagine any sequence of platforms such that there are bootstrap stages with their 3 platforms determined by "sliding a window" that is the 3 tuple through the sequence. This was the original model for bootstrapping. Without a target platform (assume a better world where all compilers are multi-target and all standard libraries are built in their own derivation), this is sufficient. Conversely if one wishes to cross compile "faster", with a "Canadian Cross" bootstrapping stage where `build != host != target`, more bootstrapping stages are needed since no sliding window provides the pesky `pkgsBuildTarget` package set since it skips the Canadian cross stage's "host". + + +::: note +It is much better to refer to `buildPackages` than `targetPackages`, or more broadly package sets that do not mention "target". There are three reasons for this. + +First, it is because bootstrapping stages do not have a unique `targetPackages`. For example a `(x86-linux, x86-linux, arm-linux)` and `(x86-linux, x86-linux, x86-windows)` package set both have a `(x86-linux, x86-linux, x86-linux)` package set. Because there is no canonical `targetPackages` for such a native (`build == host == target`) package set, we set their `targetPackages` + +Second, it is because this is a frequent source of hard-to-follow "infinite recursions" / cycles. When only package sets that don't mention target are used, the package set forms a directed acyclic graph. This means that all cycles that exist are confined to one stage. This means they are a lot smaller, and easier to follow in the code or a backtrace. It also means they are present in native and cross builds alike, and so more likely to be caught by CI and other users. + +Thirdly, it is because everything target-mentioning only exists to accommodate compilers with lousy build systems that insist on the compiler itself and standard library being built together. Of course that is bad because bigger derivations means longer rebuilds. It is also problematic because it tends to make the standard libraries less like other libraries than they could be, complicating code and build systems alike. Because of the other problems, and because of these innate disadvantages, compilers ought to be packaged another way where possible. +::: + +::: note +If one explores Nixpkgs, they will see derivations with names like `gccCross`. Such `*Cross` derivations is a holdover from before we properly distinguished between the host and target platforms—the derivation with "Cross" in the name covered the `build = host != target` case, while the other covered the `host = target`, with build platform the same or not based on whether one was using its `.nativeDrv` or `.crossDrv`. This ugliness will disappear soon. +::: diff --git a/doc/stdenv/cross-compilation.xml b/doc/stdenv/cross-compilation.xml deleted file mode 100644 index 690578b78c6e..000000000000 --- a/doc/stdenv/cross-compilation.xml +++ /dev/null @@ -1,394 +0,0 @@ - - Cross-compilation -
- Introduction - - - "Cross-compilation" means compiling a program on one machine for another type of machine. For example, a typical use of cross-compilation is to compile programs for embedded devices. These devices often don't have the computing power and memory to compile their own programs. One might think that cross-compilation is a fairly niche concern. However, there are significant advantages to rigorously distinguishing between build-time and run-time environments! Significant, because the benefits apply even when one is developing and deploying on the same machine. Nixpkgs is increasingly adopting the opinion that packages should be written with cross-compilation in mind, and nixpkgs should evaluate in a similar way (by minimizing cross-compilation-specific special cases) whether or not one is cross-compiling. - - - - This chapter will be organized in three parts. First, it will describe the basics of how to package software in a way that supports cross-compilation. Second, it will describe how to use Nixpkgs when cross-compiling. Third, it will describe the internal infrastructure supporting cross-compilation. - -
- -
- Packaging in a cross-friendly manner - -
- Platform parameters - - - Nixpkgs follows the conventions of GNU autoconf. We distinguish between 3 types of platforms when building a derivation: build, host, and target. In summary, build is the platform on which a package is being built, host is the platform on which it will run. The third attribute, target, is relevant only for certain specific compilers and build tools. - - - - In Nixpkgs, these three platforms are defined as attribute sets under the names buildPlatform, hostPlatform, and targetPlatform. They are always defined as attributes in the standard environment. That means one can access them like: -{ stdenv, fooDep, barDep, .. }: ...stdenv.buildPlatform... - . - - - - - - buildPlatform - - - - The "build platform" is the platform on which a package is built. Once someone has a built package, or pre-built binary package, the build platform should not matter and can be ignored. - - - - - - hostPlatform - - - - The "host platform" is the platform on which a package will be run. This is the simplest platform to understand, but also the one with the worst name. - - - - - - targetPlatform - - - - The "target platform" attribute is, unlike the other two attributes, not actually fundamental to the process of building software. Instead, it is only relevant for compatibility with building certain specific compilers and build tools. It can be safely ignored for all other packages. - - - The build process of certain compilers is written in such a way that the compiler resulting from a single build can itself only produce binaries for a single platform. The task of specifying this single "target platform" is thus pushed to build time of the compiler. The root cause of this is that the compiler (which will be run on the host) and the standard library/runtime (which will be run on the target) are built by a single build process. - - - There is no fundamental need to think about a single target ahead of time like this. If the tool supports modular or pluggable backends, both the need to specify the target at build time and the constraint of having only a single target disappear. An example of such a tool is LLVM. - - - Although the existence of a "target platfom" is arguably a historical mistake, it is a common one: examples of tools that suffer from it are GCC, Binutils, GHC and Autoconf. Nixpkgs tries to avoid sharing in the mistake where possible. Still, because the concept of a target platform is so ingrained, it is best to support it as is. - - - - - - - The exact schema these fields follow is a bit ill-defined due to a long and convoluted evolution, but this is slowly being cleaned up. You can see examples of ones used in practice in lib.systems.examples; note how they are not all very consistent. For now, here are few fields can count on them containing: - - - - - - system - - - - This is a two-component shorthand for the platform. Examples of this would be "x86_64-darwin" and "i686-linux"; see lib.systems.doubles for more. The first component corresponds to the CPU architecture of the platform and the second to the operating system of the platform ([cpu]-[os]). This format has built-in support in Nix, such as the builtins.currentSystem impure string. - - - - - - config - - - - This is a 3- or 4- component shorthand for the platform. Examples of this would be x86_64-unknown-linux-gnu and aarch64-apple-darwin14. This is a standard format called the "LLVM target triple", as they are pioneered by LLVM. In the 4-part form, this corresponds to [cpu]-[vendor]-[os]-[abi]. This format is strictly more informative than the "Nix host double", as the previous format could analogously be termed. This needs a better name than config! - - - - - - parsed - - - - This is a Nix representation of a parsed LLVM target triple with white-listed components. This can be specified directly, or actually parsed from the config. See lib.systems.parse for the exact representation. - - - - - - libc - - - - This is a string identifying the standard C library used. Valid identifiers include "glibc" for GNU libc, "libSystem" for Darwin's Libsystem, and "uclibc" for µClibc. It should probably be refactored to use the module system, like parse. - - - - - - is* - - - - These predicates are defined in lib.systems.inspect, and slapped onto every platform. They are superior to the ones in stdenv as they force the user to be explicit about which platform they are inspecting. Please use these instead of those. - - - - - - platform - - - - This is, quite frankly, a dumping ground of ad-hoc settings (it's an attribute set). See lib.systems.platforms for examples—there's hopefully one in there that will work verbatim for each platform that is working. Please help us triage these flags and give them better homes! - - - - -
- -
- Theory of dependency categorization - - - - This is a rather philosophical description that isn't very Nixpkgs-specific. For an overview of all the relevant attributes given to mkDerivation, see . For a description of how everything is implemented, see . - - - - - In this section we explore the relationship between both runtime and build-time dependencies and the 3 Autoconf platforms. - - - - A run time dependency between two packages requires that their host platforms match. This is directly implied by the meaning of "host platform" and "runtime dependency": The package dependency exists while both packages are running on a single host platform. - - - - A build time dependency, however, has a shift in platforms between the depending package and the depended-on package. "build time dependency" means that to build the depending package we need to be able to run the depended-on's package. The depending package's build platform is therefore equal to the depended-on package's host platform. - - - - If both the dependency and depending packages aren't compilers or other machine-code-producing tools, we're done. And indeed buildInputs and nativeBuildInputs have covered these simpler build-time and run-time (respectively) changes for many years. But if the dependency does produce machine code, we might need to worry about its target platform too. In principle, that target platform might be any of the depending package's build, host, or target platforms, but we prohibit dependencies from a "later" platform to an earlier platform to limit confusion because we've never seen a legitimate use for them. - - - - Finally, if the depending package is a compiler or other machine-code-producing tool, it might need dependencies that run at "emit time". This is for compilers that (regrettably) insist on being built together with their source langauges' standard libraries. Assuming build != host != target, a run-time dependency of the standard library cannot be run at the compiler's build time or run time, but only at the run time of code emitted by the compiler. - - - - Putting this all together, that means we have dependencies in the form "host → target", in at most the following six combinations: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Possible dependency types
Dependency's host platformDependency's target platform
buildbuild
buildhost
buildtarget
hosthost
hosttarget
targettarget
- - - - Some examples will make this table clearer. Suppose there's some package that is being built with a (build, host, target) platform triple of (foo, bar, baz). If it has a build-time library dependency, that would be a "host → build" dependency with a triple of (foo, foo, *) (the target platform is irrelevant). If it needs a compiler to be built, that would be a "build → host" dependency with a triple of (foo, foo, *) (the target platform is irrelevant). That compiler, would be built with another compiler, also "build → host" dependency, with a triple of (foo, foo, foo). - -
- -
- Cross packaging cookbook - - - Some frequently encountered problems when packaging for cross-compilation should be answered here. Ideally, the information above is exhaustive, so this section cannot provide any new information, but it is ludicrous and cruel to expect everyone to spend effort working through the interaction of many features just to figure out the same answer to the same common problem. Feel free to add to this list! - - - - - - - What if my package's build system needs to build a C program to be run under the build environment? - - - - -depsBuildBuild = [ buildPackages.stdenv.cc ]; - Add it to your mkDerivation invocation. - - - - - - - My package fails to find ar. - - - - - Many packages assume that an unprefixed ar is available, but Nix doesn't provide one. It only provides a prefixed one, just as it only does for all the other binutils programs. It may be necessary to patch the package to fix the build system to use a prefixed ar. - - - - - - - My package's testsuite needs to run host platform code. - - - - -doCheck = stdenv.hostPlatform == stdenv.buildPlatfrom; - Add it to your mkDerivation invocation. - - - - -
-
- -
- Cross-building packages - - - Nixpkgs can be instantiated with localSystem alone, in which case there is no cross-compiling and everything is built by and for that system, or also with crossSystem, in which case packages run on the latter, but all building happens on the former. Both parameters take the same schema as the 3 (build, host, and target) platforms defined in the previous section. As mentioned above, lib.systems.examples has some platforms which are used as arguments for these parameters in practice. You can use them programmatically, or on the command line: - -nix-build '<nixpkgs>' --arg crossSystem '(import <nixpkgs/lib>).systems.examples.fooBarBaz' -A whatever - - - - - Eventually we would like to make these platform examples an unnecessary convenience so that - -nix-build '<nixpkgs>' --arg crossSystem '{ config = "<arch>-<os>-<vendor>-<abi>"; }' -A whatever - works in the vast majority of cases. The problem today is dependencies on other sorts of configuration which aren't given proper defaults. We rely on the examples to crudely to set those configuration parameters in some vaguely sane manner on the users behalf. Issue #34274 tracks this inconvenience along with its root cause in crufty configuration options. - - - - - While one is free to pass both parameters in full, there's a lot of logic to fill in missing fields. As discussed in the previous section, only one of system, config, and parsed is needed to infer the other two. Additionally, libc will be inferred from parse. Finally, localSystem.system is also impurely inferred based on the platform evaluation occurs. This means it is often not necessary to pass localSystem at all, as in the command-line example in the previous paragraph. - - - - - Many sources (manual, wiki, etc) probably mention passing system, platform, along with the optional crossSystem to nixpkgs: import <nixpkgs> { system = ..; platform = ..; crossSystem = ..; }. Passing those two instead of localSystem is still supported for compatibility, but is discouraged. Indeed, much of the inference we do for these parameters is motivated by compatibility as much as convenience. - - - - - One would think that localSystem and crossSystem overlap horribly with the three *Platforms (buildPlatform, hostPlatform, and targetPlatform; see stage.nix or the manual). Actually, those identifiers are purposefully not used here to draw a subtle but important distinction: While the granularity of having 3 platforms is necessary to properly *build* packages, it is overkill for specifying the user's *intent* when making a build plan or package set. A simple "build vs deploy" dichotomy is adequate: the sliding window principle described in the previous section shows how to interpolate between the these two "end points" to get the 3 platform triple for each bootstrapping stage. That means for any package a given package set, even those not bound on the top level but only reachable via dependencies or buildPackages, the three platforms will be defined as one of localSystem or crossSystem, with the former replacing the latter as one traverses build-time dependencies. A last simple difference is that crossSystem should be null when one doesn't want to cross-compile, while the *Platforms are always non-null. localSystem is always non-null. - -
- -
- Cross-compilation infrastructure - -
- Implementation of dependencies - - - The categorizes of dependencies developed in are specified as lists of derivations given to mkDerivation, as documented in . In short, each list of dependencies for "host → target" of "foo → bar" is called depsFooBar, with exceptions for backwards compatibility that depsBuildHost is instead called nativeBuildInputs and depsHostTarget is instead called buildInputs. Nixpkgs is now structured so that each depsFooBar is automatically taken from pkgsFooBar. (These pkgsFooBars are quite new, so there is no special case for nativeBuildInputs and buildInputs.) For example, pkgsBuildHost.gcc should be used at build-time, while pkgsHostTarget.gcc should be used at run-time. - - - - Now, for most of Nixpkgs's history, there were no pkgsFooBar attributes, and most packages have not been refactored to use it explicitly. Prior to those, there were just buildPackages, pkgs, and targetPackages. Those are now redefined as aliases to pkgsBuildHost, pkgsHostTarget, and pkgsTargetTarget. It is acceptable, even recommended, to use them for libraries to show that the host platform is irrelevant. - - - - But before that, there was just pkgs, even though both buildInputs and nativeBuildInputs existed. [Cross barely worked, and those were implemented with some hacks on mkDerivation to override dependencies.] What this means is the vast majority of packages do not use any explicit package set to populate their dependencies, just using whatever callPackage gives them even if they do correctly sort their dependencies into the multiple lists described above. And indeed, asking that users both sort their dependencies, and take them from the right attribute set, is both too onerous and redundant, so the recommended approach (for now) is to continue just categorizing by list and not using an explicit package set. - - - - To make this work, we "splice" together the six pkgsFooBar package sets and have callPackage actually take its arguments from that. This is currently implemented in pkgs/top-level/splice.nix. mkDerivation then, for each dependency attribute, pulls the right derivation out from the splice. This splicing can be skipped when not cross-compiling as the package sets are the same, but still is a bit slow for cross-compiling. We'd like to do something better, but haven't come up with anything yet. - -
- -
- Bootstrapping - - - Each of the package sets described above come from a single bootstrapping stage. While pkgs/top-level/default.nix, coordinates the composition of stages at a high level, pkgs/top-level/stage.nix "ties the knot" (creates the fixed point) of each stage. The package sets are defined per-stage however, so they can be thought of as edges between stages (the nodes) in a graph. Compositions like pkgsBuildTarget.targetPackages can be thought of as paths to this graph. - - - - While there are many package sets, and thus many edges, the stages can also be arranged in a linear chain. In other words, many of the edges are redundant as far as connectivity is concerned. This hinges on the type of bootstrapping we do. Currently for cross it is: - - - - (native, native, native) - - - - - (native, native, foreign) - - - - - (native, foreign, foreign) - - - - In each stage, pkgsBuildHost refers to the previous stage, pkgsBuildBuild refers to the one before that, and pkgsHostTarget refers to the current one, and pkgsTargetTarget refers to the next one. When there is no previous or next stage, they instead refer to the current stage. Note how all the invariants regarding the mapping between dependency and depending packages' build host and target platforms are preserved. pkgsBuildTarget and pkgsHostHost are more complex in that the stage fitting the requirements isn't always a fixed chain of "prevs" and "nexts" away (modulo the "saturating" self-references at the ends). We just special case each instead. All the primary edges are implemented is in pkgs/stdenv/booter.nix, and secondarily aliases in pkgs/top-level/stage.nix. - - - - - Note the native stages are bootstrapped in legacy ways that predate the current cross implementation. This is why the bootstrapping stages leading up to the final stages are ignored inthe previous paragraph. - - - - - If one looks at the 3 platform triples, one can see that they overlap such that one could put them together into a chain like: - -(native, native, native, foreign, foreign) - - If one imagines the saturating self references at the end being replaced with infinite stages, and then overlays those platform triples, one ends up with the infinite tuple: - -(native..., native, native, native, foreign, foreign, foreign...) - - On can then imagine any sequence of platforms such that there are bootstrap stages with their 3 platforms determined by "sliding a window" that is the 3 tuple through the sequence. This was the original model for bootstrapping. Without a target platform (assume a better world where all compilers are multi-target and all standard libraries are built in their own derivation), this is sufficient. Conversely if one wishes to cross compile "faster", with a "Canadian Cross" bootstraping stage where build != host != target, more bootstrapping stages are needed since no sliding window providess the pesky pkgsBuildTarget package set since it skips the Canadian cross stage's "host". - - - - - It is much better to refer to buildPackages than targetPackages, or more broadly package sets that do not mention "target". There are three reasons for this. - - - First, it is because bootstrapping stages do not have a unique targetPackages. For example a (x86-linux, x86-linux, arm-linux) and (x86-linux, x86-linux, x86-windows) package set both have a (x86-linux, x86-linux, x86-linux) package set. Because there is no canonical targetPackages for such a native (build == host == target) package set, we set their targetPackages - - - Second, it is because this is a frequent source of hard-to-follow "infinite recursions" / cycles. When only package sets that don't mention target are used, the package set forms a directed acyclic graph. This means that all cycles that exist are confined to one stage. This means they are a lot smaller, and easier to follow in the code or a backtrace. It also means they are present in native and cross builds alike, and so more likely to be caught by CI and other users. - - - Thirdly, it is because everything target-mentioning only exists to accommodate compilers with lousy build systems that insist on the compiler itself and standard library being built together. Of course that is bad because bigger derivations means longer rebuilds. It is also problematic because it tends to make the standard libraries less like other libraries than they could be, complicating code and build systems alike. Because of the other problems, and because of these innate disadvantages, compilers ought to be packaged another way where possible. - - - - - - If one explores Nixpkgs, they will see derivations with names like gccCross. Such *Cross derivations is a holdover from before we properly distinguished between the host and target platforms—the derivation with "Cross" in the name covered the build = host != target case, while the other covered the host = target, with build platform the same or not based on whether one was using its .nativeDrv or .crossDrv. This ugliness will disappear soon. - - -
-
- From ad023b0c886fd10f39ecda46250a4f5030a047d8 Mon Sep 17 00:00:00 2001 From: Vika Date: Sun, 29 Nov 2020 23:00:52 +0300 Subject: [PATCH 3/7] nixos/mailman: make Postfix support optional (provided you configure the MTA yourself) Mailman can now work with MTAs other than Postfix. You'll have to configure it yourself using the options in `services.mailman.settings.mta`. This addition is reflected in the release notes for 21.03. --- nixos/doc/manual/release-notes/rl-2103.xml | 13 ++++++++ nixos/modules/services/mail/mailman.nix | 36 ++++++++++++++++---- nixos/modules/services/mail/mailman.xml | 39 ++++++++++++++++++++-- 3 files changed, 79 insertions(+), 9 deletions(-) diff --git a/nixos/doc/manual/release-notes/rl-2103.xml b/nixos/doc/manual/release-notes/rl-2103.xml index 3186eb7449fe..bc3315f468f1 100644 --- a/nixos/doc/manual/release-notes/rl-2103.xml +++ b/nixos/doc/manual/release-notes/rl-2103.xml @@ -250,6 +250,19 @@ Other Notable Changes + + + The Mailman NixOS module (services.mailman) has a new + option , defaulting + to true, that controls integration with Postfix. + + + If this option is disabled, default MTA config becomes not set and you + should set the options in services.mailman.settings.mta + according to the desired configuration as described in + Mailman documentation. + + The default-version of nextcloud is nextcloud20. diff --git a/nixos/modules/services/mail/mailman.nix b/nixos/modules/services/mail/mailman.nix index 5c61cfbebf6c..5471d5243e94 100644 --- a/nixos/modules/services/mail/mailman.nix +++ b/nixos/modules/services/mail/mailman.nix @@ -38,7 +38,7 @@ let webSettingsJSON = pkgs.writeText "settings.json" (builtins.toJSON webSettings); # TODO: Should this be RFC42-ised so that users can set additional options without modifying the module? - mtaConfig = pkgs.writeText "mailman-postfix.cfg" '' + postfixMtaConfig = pkgs.writeText "mailman-postfix.cfg" '' [postfix] postmap_command: ${pkgs.postfix}/bin/postmap transport_file_type: hash @@ -81,7 +81,7 @@ in { enable = mkOption { type = types.bool; default = false; - description = "Enable Mailman on this host. Requires an active Postfix installation."; + description = "Enable Mailman on this host. Requires an active MTA on the host (e.g. Postfix)."; }; package = mkOption { @@ -92,6 +92,20 @@ in { description = "Mailman package to use"; }; + enablePostfix = mkOption { + type = types.bool; + default = true; + example = false; + description = '' + Enable Postfix integration. Requires an active Postfix installation. + + If you want to use another MTA, set this option to false and configure + settings in services.mailman.settings.mta. + + Refer to the Mailman manual for more info. + ''; + }; + siteOwner = mkOption { type = types.str; example = "postmaster@example.org"; @@ -182,7 +196,7 @@ in { pid_file = "/run/mailman/master.pid"; }; - mta.configuration = lib.mkDefault "${mtaConfig}"; + mta.configuration = lib.mkDefault (if cfg.enablePostfix then "${postfixMtaConfig}" else throw "When Mailman Postfix integration is disabled, set `services.mailman.settings.mta.configuration` to the path of the config file required to integrate with your MTA."); "archiver.hyperkitty" = lib.mkIf cfg.hyperkitty.enable { class = "mailman_hyperkitty.Archiver"; @@ -211,14 +225,22 @@ in { See . ''; }; - in [ + in (lib.optionals cfg.enablePostfix [ { assertion = postfix.enable; - message = "Mailman requires Postfix"; + message = '' + Mailman's default NixOS configuration requires Postfix to be enabled. + + If you want to use another MTA, set services.mailman.enablePostfix + to false and configure settings in services.mailman.settings.mta. + + Refer to + for more info. + ''; } (requirePostfixHash [ "relayDomains" ] "postfix_domains") (requirePostfixHash [ "config" "transport_maps" ] "postfix_lmtp") (requirePostfixHash [ "config" "local_recipient_maps" ] "postfix_lmtp") - ]; + ]); users.users.mailman = { description = "GNU Mailman"; @@ -275,7 +297,7 @@ in { ''; }) ]; - services.postfix = { + services.postfix = lib.mkIf cfg.enablePostfix { recipientDelimiter = "+"; # bake recipient addresses in mail envelopes via VERP config = { owner_request_special = "no"; # Mailman handles -owner addresses on its own diff --git a/nixos/modules/services/mail/mailman.xml b/nixos/modules/services/mail/mailman.xml index cbe50ed0b917..8da491ccbe9f 100644 --- a/nixos/modules/services/mail/mailman.xml +++ b/nixos/modules/services/mail/mailman.xml @@ -13,9 +13,9 @@
- Basic usage + Basic usage with Postfix - For a basic configuration, the following settings are suggested: + For a basic configuration with Postfix as the MTA, the following settings are suggested: { config, ... }: { services.postfix = { enable = true; @@ -56,4 +56,39 @@ necessary, but outside the scope of the Mailman module.
+
+ Using with other MTAs + + Mailman also supports other MTA, though with a little bit more configuration. For example, to use Mailman with Exim, you can use the following settings: + { config, ... }: { + services = { + mailman = { + enable = true; + siteOwner = "mailman@example.org"; + enablePostfix = false; + settings.mta = { + incoming = "mailman.mta.exim4.LMTP"; + outgoing = "mailman.mta.deliver.deliver"; + lmtp_host = "localhost"; + lmtp_port = "8024"; + smtp_host = "localhost"; + smtp_port = "25"; + configuration = "python:mailman.config.exim4"; + }; + }; + exim = { + enable = true; + # You can configure Exim in a separate file to reduce configuration.nix clutter + config = builtins.readFile ./exim.conf; + }; + }; +} + + + The exim config needs some special additions to work with Mailman. Currently + NixOS can't manage Exim config with such granularity. Please refer to + Mailman documentation + for more info on configuring Mailman for working with Exim. + +
From 756632f741e9f9780100b97fc783369ef716e9d4 Mon Sep 17 00:00:00 2001 From: "R. RyanTM" Date: Sat, 12 Dec 2020 13:53:08 +0000 Subject: [PATCH 4/7] malcontent: 0.9.0 -> 0.10.0 --- pkgs/development/libraries/malcontent/default.nix | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/pkgs/development/libraries/malcontent/default.nix b/pkgs/development/libraries/malcontent/default.nix index 97cc4f7ff2a6..49ffade85460 100644 --- a/pkgs/development/libraries/malcontent/default.nix +++ b/pkgs/development/libraries/malcontent/default.nix @@ -19,7 +19,7 @@ stdenv.mkDerivation rec { pname = "malcontent"; - version = "0.9.0"; + version = "0.10.0"; outputs = [ "bin" "out" "lib" "pam" "dev" "man" "installedTests" ]; @@ -28,7 +28,7 @@ stdenv.mkDerivation rec { owner = "pwithnall"; repo = pname; rev = version; - sha256 = "DEtibrGgHSgRjaarAzizzLN1xsJKXl+LCQ29FmpPoJo="; + sha256 = "1b6rgf7h9gj2kw1b7ba0mvhsb89riwf9p4pviqjfzd1i5nmbmnyx"; }; patches = [ From b7a29b2f71fc84f5c41f4c9f8efdcceb10800771 Mon Sep 17 00:00:00 2001 From: Maximilian Bosch Date: Mon, 14 Dec 2020 12:04:54 +0100 Subject: [PATCH 5/7] strace: 5.9 -> 5.10 https://github.com/strace/strace/releases/tag/v5.10 --- pkgs/development/tools/misc/strace/default.nix | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/pkgs/development/tools/misc/strace/default.nix b/pkgs/development/tools/misc/strace/default.nix index 14f4d5ef12e1..6b797481799e 100644 --- a/pkgs/development/tools/misc/strace/default.nix +++ b/pkgs/development/tools/misc/strace/default.nix @@ -2,11 +2,11 @@ stdenv.mkDerivation rec { pname = "strace"; - version = "5.9"; + version = "5.10"; src = fetchurl { url = "https://strace.io/files/${version}/${pname}-${version}.tar.xz"; - sha256 = "1nb6bm6ll6cxd6a2fc67c0qn39gbh6rkqrpv83lw6ijm8sw3wirr"; + sha256 = "sha256-/jmC6kzZrrO0ujX2J58LV3o3F10ygr4kuaVTe1a48Bw="; }; depsBuildBuild = [ buildPackages.stdenv.cc ]; @@ -23,6 +23,6 @@ stdenv.mkDerivation rec { description = "A system call tracer for Linux"; license = with licenses; [ lgpl21Plus gpl2Plus ]; # gpl2Plus is for the test suite platforms = platforms.linux; - maintainers = with maintainers; [ globin ]; + maintainers = with maintainers; [ globin ma27 ]; }; } From cd8fac0c299feac9e54e0a40864ca378abddfcd5 Mon Sep 17 00:00:00 2001 From: Maximilian Bosch Date: Mon, 14 Dec 2020 12:05:23 +0100 Subject: [PATCH 6/7] docker-ls: 0.3.2 -> 0.5.0 https://github.com/mayflower/docker-ls/releases/tag/v0.5.0 https://github.com/mayflower/docker-ls/releases/tag/v0.4.1 https://github.com/mayflower/docker-ls/releases/tag/v0.4.0 --- pkgs/tools/misc/docker-ls/default.nix | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/pkgs/tools/misc/docker-ls/default.nix b/pkgs/tools/misc/docker-ls/default.nix index 8522256c7d52..e53f020fc6bd 100644 --- a/pkgs/tools/misc/docker-ls/default.nix +++ b/pkgs/tools/misc/docker-ls/default.nix @@ -1,17 +1,17 @@ -{ buildGoPackage, fetchFromGitHub, stdenv, docker }: +{ buildGoModule, fetchFromGitHub, stdenv, docker }: -buildGoPackage rec { +buildGoModule rec { pname = "docker-ls"; - version = "0.3.2"; + version = "0.5.0"; src = fetchFromGitHub { owner = "mayflower"; repo = "docker-ls"; rev = "v${version}"; - sha256 = "1hb9b0jhaf01zlmkm353mz608kwb79dzic3gvb2fhyrh8d17w2iv"; + sha256 = "sha256-VyVrCBdIZAQ+p0leD6i4sMxD4p6nEXG9Si+nJGdUQPM="; }; - goPackagePath = "github.com/mayflower/docker-ls"; + vendorSha256 = "sha256-UulcjQOLEIP++eoYQTEIbCJW51jyE312dMxB8+AKcdU="; meta = with stdenv.lib; { description = "Tools for browsing and manipulating docker registries"; From 267bb1df046fbad76a64440994afdb5c0fd3bc99 Mon Sep 17 00:00:00 2001 From: 06kellyjac Date: Sun, 13 Dec 2020 12:31:22 +0000 Subject: [PATCH 7/7] nerdctl: 0.2.0 -> 0.3.0 --- pkgs/applications/networking/cluster/nerdctl/default.nix | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/pkgs/applications/networking/cluster/nerdctl/default.nix b/pkgs/applications/networking/cluster/nerdctl/default.nix index 050c414ce1e9..4afb7458ff3e 100644 --- a/pkgs/applications/networking/cluster/nerdctl/default.nix +++ b/pkgs/applications/networking/cluster/nerdctl/default.nix @@ -14,16 +14,16 @@ let in buildGoModule rec { pname = "nerdctl"; - version = "0.2.0"; + version = "0.3.0"; src = fetchFromGitHub { owner = "AkihiroSuda"; repo = pname; rev = "v${version}"; - sha256 = "181qapqgp7zd0imk0zkn4wzpsw292ai2yz9pbiirpjcjx9h26w5h"; + sha256 = "1bxxdsx8aqbrbjm0bn6makw77z96mng5by7k3licbk0vdgakaix6"; }; - vendorSha256 = "0scywhllxk1m6456wggdmn7sgvy5x3gz2xnyfq9jnvvzap8byr2v"; + vendorSha256 = "1d2bqv7bc7q82z6sd8kkqj4xdccs660mj34ggwb09a59law139li"; nativeBuildInputs = [ makeWrapper ];