commit 97b0ae26f7c8a1682b5437a64edcd73ab1798c9b · pyrox.dev/nixpkgs

+1 -1

doc/hooks/autopatchelf.section.md

···

6
6

7
7

In certain situations you may want to run the main command (`autoPatchelf`) of the setup hook on a file or a set of directories instead of unconditionally patching all outputs. This can be done by setting the `dontAutoPatchelf` environment variable to a non-empty value.

8
8

9
9
-
By default `autoPatchelf` will fail as soon as any ELF file requires a dependency which cannot be resolved via the given build inputs. In some situations you might prefer to just leave missing dependencies unpatched and continue to patch the rest. This can be achieved by setting the `autoPatchelfIgnoreMissingDeps` environment variable to a non-empty value. `autoPatchelfIgnoreMissingDeps` can be set to a list like `autoPatchelfIgnoreMissingDeps = [ "libcuda.so.1" "libcudart.so.1" ];` or to simply `[ "*" ]` to ignore all missing dependencies.

9
9
+
By default `autoPatchelf` will fail as soon as any ELF file requires a dependency which cannot be resolved via the given build inputs. In some situations you might prefer to just leave missing dependencies unpatched and continue to patch the rest. This can be achieved by setting the `autoPatchelfIgnoreMissingDeps` environment variable to a non-empty value. `autoPatchelfIgnoreMissingDeps` can be set to a list like `autoPatchelfIgnoreMissingDeps = [ "libcuda.so.1" "libcudart.so.1" ];` or to `[ "*" ]` to ignore all missing dependencies.

10
10

11
11

The `autoPatchelf` command also recognizes a `--no-recurse` command line flag, which prevents it from recursing into subdirectories.

+2 -2

doc/languages-frameworks/agda.section.md

···

       146
       146
        
       

     

       147
       147
        
       ### Building Agda packages {#building-agda-packages}

     

       148
       148
        
       

     

       149
       149
       -
       The default build phase for `agdaPackages.mkDerivation` simply runs `agda` on the `Everything.agda` file.

     

       149
       149
       +
       The default build phase for `agdaPackages.mkDerivation` runs `agda` on the `Everything.agda` file.

     

       150
       150
        
       If something else is needed to build the package (e.g. `make`) then the `buildPhase` should be overridden.

     

       151
       151
        
       Additionally, a `preBuild` or `configurePhase` can be used if there are steps that need to be done prior to checking the `Everything.agda` file.

     

       152
       152
        
       `agda` and the Agda libraries contained in `buildInputs` are made available during the build phase.

     
···

       250
       250
        
       Bumping the version of that reverse dependency should be a further commit on your PR.

     

       251
       251
        
       

     

       252
       252
        
       In the rare case that a new release is not to be expected within an acceptable time,

     

       253
       253
       -
       simply mark the broken package as broken by setting `meta.broken = true;`.

     

       253
       253
       +
       mark the broken package as broken by setting `meta.broken = true;`.

     

       254
       254
        
       This will exclude it from the build test.

     

       255
       255
        
       It can be added later when it is fixed,

     

       256
       256
        
       and does not hinder the advancement of the whole package set in the meantime.

+1 -1

doc/languages-frameworks/beam.section.md

···

       44
       44
        
       

     

       45
       45
        
       ## How to Install BEAM Packages {#how-to-install-beam-packages}

     

       46
       46
        
       

     

       47
       47
       -
       BEAM builders are not registered at the top level, simply because they are not relevant to the vast majority of Nix users.

     

       47
       47
       +
       BEAM builders are not registered at the top level, because they are not relevant to the vast majority of Nix users.

     

       48
       48
        
       To use any of those builders into your environment, refer to them by their attribute path under `beamPackages`, e.g. `beamPackages.rebar3`:

     

       49
       49
        
       

     

       50
       50
        
       ::: {.example #ex-beam-ephemeral-shell}

+1 -1

doc/languages-frameworks/dart.section.md

···

       8
       8
        
       

     

       9
       9
        
       If you are packaging a Flutter desktop application, use [`buildFlutterApplication`](#ssec-dart-flutter) instead.

     

       10
       10
        
       

     

       11
       11
       -
       `vendorHash`: is the hash of the output of the dependency fetcher derivation. To obtain it, simply set it to `lib.fakeHash` (or omit it) and run the build ([more details here](#sec-source-hashes)).

     

       11
       11
       +
       `vendorHash`: is the hash of the output of the dependency fetcher derivation. To obtain it, set it to `lib.fakeHash` (or omit it) and run the build ([more details here](#sec-source-hashes)).

     

       12
       12
        
       

     

       13
       13
        
       If the upstream source is missing a `pubspec.lock` file, you'll have to vendor one and specify it using `pubspecLockFile`. If it is needed, one will be generated for you and printed when attempting to build the derivation.

     

       14
       14

+2 -2

doc/languages-frameworks/haskell.section.md

···

       177
       177
        
       given in the `.cabal` file of your package and all its dependencies.

     

       178
       178
        
       

     

       179
       179
        
       The [Haskell builder in nixpkgs](#haskell-mkderivation) does no such thing.

     

       180
       180
       -
       It will simply take as input packages with names off the desired dependencies

     

       180
       180
       +
       It will take as input packages with names off the desired dependencies

     

       181
       181
        
       and just check whether they fulfill the version bounds and fail if they don’t

     

       182
       182
        
       (by default, see `jailbreak` to circumvent this).

     

       183
       183
        
       

     
···

       780
       780
        
       The top level `pkgs.haskell-language-server` attribute is just a convenience

     

       781
       781
        
       wrapper to make it possible to install HLS for multiple GHC versions at the

     

       782
       782
        
       same time. If you know, that you only use one GHC version, e.g., in a project

     

       783
       783
       -
       specific `nix-shell` you can simply use

     

       783
       783
       +
       specific `nix-shell` you can use

     

       784
       784
        
       `pkgs.haskellPackages.haskell-language-server` or

     

       785
       785
        
       `pkgs.haskell.packages.*.haskell-language-server` from the package set you use.

     

       786
       786

+1 -1

doc/languages-frameworks/lisp.section.md

···

       268
       268
        
       

     

       269
       269
        
       ### Loading systems {#lisp-loading-systems}

     

       270
       270
        
       

     

       271
       271
       -
       There, you can simply use `asdf:load-system`. This works by setting the right

     

       271
       271
       +
       There, you can use `asdf:load-system`. This works by setting the right

     

       272
       272
        
       values for the `CL_SOURCE_REGISTRY`/`ASDF_OUTPUT_TRANSLATIONS` environment

     

       273
       273
        
       variables, so that systems are found in the Nix store and pre-compiled FASLs are

     

       274
       274
        
       loaded.

+1 -1

doc/languages-frameworks/maven.section.md

···

       53
       53
        
       

     

       54
       54
        
       Maven defines default versions for its core plugins, e.g. `maven-compiler-plugin`. If your project does not override these versions, an upgrade of Maven will change the version of the used plugins, and therefore the derivation and hash.

     

       55
       55
        
       

     

       56
       56
       -
       When `maven` is upgraded, `mvnHash` for the derivation must be updated as well: otherwise, the project will simply be built on the derivation of old plugins, and fail because the requested plugins are missing.

     

       56
       56
       +
       When `maven` is upgraded, `mvnHash` for the derivation must be updated as well: otherwise, the project will be built on the derivation of old plugins, and fail because the requested plugins are missing.

     

       57
       57
        
       

     

       58
       58
        
       This clearly prevents automatic upgrades of Maven: a manual effort must be made throughout nixpkgs by any maintainer wishing to push the upgrades.

     

       59
       59

+3 -3

doc/languages-frameworks/php.section.md

···

       58
       58
        
         ++ [ all.imagick ])

     

       59
       59
        
       ```

     

       60
       60
        
       

     

       61
       61
       -
       To build your list of extensions from the ground up, you can simply

     

       61
       61
       +
       To build your list of extensions from the ground up, you can

     

       62
       62
        
       ignore `enabled`:

     

       63
       63
        
       

     

       64
       64
        
       ```nix

     
···

       140
       140
        
       ### Overriding PHP packages {#ssec-php-user-guide-overriding-packages}

     

       141
       141
        
       

     

       142
       142
        
       `php-packages.nix` form a scope, allowing us to override the packages defined

     

       143
       143
       -
       within. For example, to apply a patch to a `mysqlnd` extension, you can simply

     

       143
       143
       +
       within. For example, to apply a patch to a `mysqlnd` extension, you can

     

       144
       144
        
       pass an overlay-style function to `php`’s `packageOverrides` argument:

     

       145
       145
        
       

     

       146
       146
        
       ```nix

     
···

       191
       191
        
       automatically linked and made accessible in the derivation. In this context,

     

       192
       192
        
       "binaries" refer to PHP scripts that are intended to be executable.

     

       193
       193
        
       

     

       194
       194
       -
       To use the helper effectively, simply add the `vendorHash` attribute, which

     

       194
       194
       +
       To use the helper effectively, add the `vendorHash` attribute, which

     

       195
       195
        
       enables the wrapper to handle the heavy lifting.

     

       196
       196
        
       

     

       197
       197
        
       Internally, the helper operates in three stages:

+4 -4

doc/languages-frameworks/python.section.md

···

       264
       264
        
       ```

     

       265
       265
        
       

     

       266
       266
        
       This is particularly useful for numpy and scipy users who want to gain speed with other blas implementations.

     

       267
       267
       -
       Note that using simply `scipy = super.scipy.override { blas = super.pkgs.mkl; };` will likely result in

     

       267
       267
       +
       Note that using `scipy = super.scipy.override { blas = super.pkgs.mkl; };` will likely result in

     

       268
       268
        
       compilation issues, because scipy dependencies need to use the same blas implementation as well.

     

       269
       269
        
       

     

       270
       270
        
       #### `buildPythonApplication` function {#buildpythonapplication-function}

     
···

       433
       433
        
       

     

       434
       434
        
       Now, `ps` is set to `python3Packages`, matching the version of the interpreter.

     

       435
       435
        
       

     

       436
       436
       -
       As [`python.withPackages`](#python.withpackages-function) simply uses [`python.buildEnv`](#python.buildenv-function) under the hood, it also

     

       436
       436
       +
       As [`python.withPackages`](#python.withpackages-function) uses [`python.buildEnv`](#python.buildenv-function) under the hood, it also

     

       437
       437
        
       supports the `env` attribute. The `shell.nix` file from the previous section can

     

       438
       438
        
       thus be also written like this:

     

       439
       439
        
       

     
···

       682
       682
        
       print(f"The dot product of {a} and {b} is: {np.dot(a, b)}")

     

       683
       683
        
       ```

     

       684
       684
        
       

     

       685
       685
       -
       Then we simply execute it, without requiring any environment setup at all!

     

       685
       685
       +
       Then we execute it, without requiring any environment setup at all!

     

       686
       686
        
       

     

       687
       687
        
       ```sh

     

       688
       688
        
       $ ./foo.py

     
···

       1713
       1713
        
       a virtual environment created by `venv`, and install Python modules through

     

       1714
       1714
        
       `pip` the traditional way.

     

       1715
       1715
        
       

     

       1716
       1716
       -
       Create this `default.nix` file, together with a `requirements.txt` and simply

     

       1716
       1716
       +
       Create this `default.nix` file, together with a `requirements.txt` and

     

       1717
       1717
        
       execute `nix-shell`.

     

       1718
       1718
        
       

     

       1719
       1719
        
       ```nix

+2 -2

doc/languages-frameworks/ruby.section.md

···

       94
       94
        
       $ bundix

     

       95
       95
        
       ```

     

       96
       96
        
       

     

       97
       97
       -
       If you already have a `Gemfile.lock`, you can simply run `bundix` and it will work the same.

     

       97
       97
       +
       If you already have a `Gemfile.lock`, you can run `bundix` and it will work the same.

     

       98
       98
        
       

     

       99
       99
        
       To update the gems in your `Gemfile.lock`, you may use the `bundix -l` flag, which will create a new `Gemfile.lock` in case the `Gemfile` has a more recent time of modification.

     

       100
       100
        
       

     
···

       251
       251
        
       end

     

       252
       252
        
       ```

     

       253
       253
        
       

     

       254
       254
       -
       If you want to package a specific version, you can use the standard Gemfile syntax for that, e.g. `gem 'mdl', '0.5.0'`, but if you want the latest stable version anyway, it's easier to update by simply running the `bundle lock` and `bundix` steps again.

     

       254
       254
       +
       If you want to package a specific version, you can use the standard Gemfile syntax for that, e.g. `gem 'mdl', '0.5.0'`, but if you want the latest stable version anyway, it's easier to update by running the `bundle lock` and `bundix` steps again.

     

       255
       255
        
       

     

       256
       256
        
       Now you can also make a `default.nix` that looks like this:

     

       257
       257

+2 -2

doc/languages-frameworks/swift.section.md

···

       32
       32
        
         (If not targeting macOS, replace `macosx` with the Xcode platform name.)

     

       33
       33
        
       - On other platforms: `lib/swift/linux/x86_64`

     

       34
       34
        
         (Where `linux` and `x86_64` are from lowercase `uname -sm`.)

     

       35
       35
       -
       - For convenience, Nixpkgs also adds simply `lib/swift` to the search path.

     

       35
       35
       +
       - For convenience, Nixpkgs also adds `lib/swift` to the search path.

     

       36
       36
        
         This can save a bit of work packaging Swift modules, because many Nix builds

     

       37
       37
        
         will produce output for just one target any way.

     

       38
       38
        
       

     
···

       123
       123
        
       

     

       124
       124
        
       The default `buildPhase` already passes `-j` for parallel building.

     

       125
       125
        
       

     

       126
       126
       -
       If these two customization options are insufficient, simply provide your own

     

       126
       126
       +
       If these two customization options are insufficient, provide your own

     

       127
       127
        
       `buildPhase` that invokes `swift build`.

     

       128
       128
        
       

     

       129
       129
        
       ### Running tests {#ssec-swiftpm-running-tests}

+1 -1

doc/packages/urxvt.section.md

···

       34
       34
        
       map (p: p.name) pkgs.rxvt-unicode.plugins

     

       35
       35
        
       ```

     

       36
       36
        
       

     

       37
       37
       -
       Alternatively, if your shell is bash or zsh and have completion enabled, simply type `nixpkgs.rxvt-unicode.plugins.<tab>`.

     

       37
       37
       +
       Alternatively, if your shell is bash or zsh and have completion enabled, type `nixpkgs.rxvt-unicode.plugins.<tab>`.

     

       38
       38
        
       

     

       39
       39
        
       In addition to `plugins` the options `extraDeps` and `perlDeps` can be used to install extra packages. `extraDeps` can be used, for example, to provide `xsel` (a clipboard manager) to the clipboard plugin, without installing it globally:

     

       40
       40

+4 -4

doc/stdenv/stdenv.chapter.md

···

319
319

let f(h, h + 1, i) = i + h

320
320

```

321
321

322
322
-
This is where “sum-like” comes in from above: We can just sum all of the host offsets to get the host offset of the transitive dependency. The target offset is the transitive dependency is simply the host offset + 1, just as it was with the dependencies composed to make this transitive one; it can be ignored as it doesn’t add any new information.

322
322
+
This is where “sum-like” comes in from above: We can just sum all of the host offsets to get the host offset of the transitive dependency. The target offset is the transitive dependency is the host offset + 1, just as it was with the dependencies composed to make this transitive one; it can be ignored as it doesn’t add any new information.

323
323

324
324

Because of the bounds checks, the uncommon cases are `h = t` and `h + 2 = t`. In the former case, the motivation for `mapOffset` is that since its host and target platforms are the same, no transitive dependency of it should be able to “discover” an offset greater than its reduced target offsets. `mapOffset` effectively “squashes” all its transitive dependencies’ offsets so that none will ever be greater than the target offset of the original `h = t` package. In the other case, `h + 1` is skipped over between the host and target offsets. Instead of squashing the offsets, we need to “rip” them apart so no transitive dependencies’ offset is that one.

325
325

···

649
649

650
650

#### Directories in the Nix store {#directories-in-the-nix-store}

651
651

652
652
-
These are simply copied to the current directory. The hash part of the file name is stripped, e.g. `/nix/store/1wydxgby13cz...-my-sources` would be copied to `my-sources`.

652
652
+
These are copied to the current directory. The hash part of the file name is stripped, e.g. `/nix/store/1wydxgby13cz...-my-sources` would be copied to `my-sources`.

653
653

654
654

Additional file types can be supported by setting the `unpackCmd` variable (see below).

655
655

···

788
788

789
789

### The build phase {#build-phase}

790
790

791
791
-
The build phase is responsible for actually building the package (e.g. compiling it). The default `buildPhase` simply calls `make` if a file named `Makefile`, `makefile` or `GNUmakefile` exists in the current directory (or the `makefile` is explicitly set); otherwise it does nothing.

791
791
+
The build phase is responsible for actually building the package (e.g. compiling it). The default `buildPhase` calls `make` if a file named `Makefile`, `makefile` or `GNUmakefile` exists in the current directory (or the `makefile` is explicitly set); otherwise it does nothing.

792
792

793
793

#### Variables controlling the build phase {#variables-controlling-the-build-phase}

794
794

···

1317
1317

1318
1318

In order to alleviate this burden, the setup hook mechanism was written, where any package can include a shell script that \[by convention rather than enforcement by Nix\], any downstream reverse-dependency will source as part of its build process. That allows the downstream dependency to merely specify its dependencies, and lets those dependencies effectively initialize themselves. No boilerplate mirroring the list of dependencies is needed.

1319
1319

1320
1320
-
The setup hook mechanism is a bit of a sledgehammer though: a powerful feature with a broad and indiscriminate area of effect. The combination of its power and implicit use may be expedient, but isn’t without costs. Nix itself is unchanged, but the spirit of added dependencies being effect-free is violated even if the latter isn’t. For example, if a derivation path is mentioned more than once, Nix itself doesn’t care and simply makes sure the dependency derivation is already built just the same—depending is just needing something to exist, and needing is idempotent. However, a dependency specified twice will have its setup hook run twice, and that could easily change the build environment (though a well-written setup hook will therefore strive to be idempotent so this is in fact not observable). More broadly, setup hooks are anti-modular in that multiple dependencies, whether the same or different, should not interfere and yet their setup hooks may well do so.

1320
1320
+
The setup hook mechanism is a bit of a sledgehammer though: a powerful feature with a broad and indiscriminate area of effect. The combination of its power and implicit use may be expedient, but isn’t without costs. Nix itself is unchanged, but the spirit of added dependencies being effect-free is violated even if the latter isn’t. For example, if a derivation path is mentioned more than once, Nix itself doesn’t care and makes sure the dependency derivation is already built just the same—depending is just needing something to exist, and needing is idempotent. However, a dependency specified twice will have its setup hook run twice, and that could easily change the build environment (though a well-written setup hook will therefore strive to be idempotent so this is in fact not observable). More broadly, setup hooks are anti-modular in that multiple dependencies, whether the same or different, should not interfere and yet their setup hooks may well do so.

1321
1321

1322
1322

The most typical use of the setup hook is actually to add other hooks which are then run (i.e. after all the setup hooks) on each dependency. For example, the C compiler wrapper’s setup hook feeds itself flags for each dependency that contains relevant libraries and headers. This is done by defining a bash function, and appending its name to one of `envBuildBuildHooks`, `envBuildHostHooks`, `envBuildTargetHooks`, `envHostHostHooks`, `envHostTargetHooks`, or `envTargetTargetHooks`. These 6 bash variables correspond to the 6 sorts of dependencies by platform (there’s 12 total but we ignore the propagated/non-propagated axis).

1323
1323

+1 -1

doc/using/overlays.chapter.md

···

       156
       156
        
       

     

       157
       157
        
       -   [MVAPICH](https://mvapich.cse.ohio-state.edu/), attribute name `mvapich`

     

       158
       158
        
       

     

       159
       159
       -
       To provide MPI enabled applications that use `MPICH`, instead of the default `Open MPI`, simply use the following overlay:

     

       159
       159
       +
       To provide MPI enabled applications that use `MPICH`, instead of the default `Open MPI`, use the following overlay:

     

       160
       160
        
       

     

       161
       161
        
       ```nix

     

       162
       162
        
       self: super:

+1 -1

nixos/doc/manual/configuration/declarative-packages.section.md

···

       37
       37
        
       the `nixos` channel and works only in CLI tools. In declarative

     

       38
       38
        
       configuration use `pkgs` prefix (variable).

     

       39
       39
        
       

     

       40
       40
       -
       To "uninstall" a package, simply remove it from

     

       40
       40
       +
       To "uninstall" a package, remove it from

     

       41
       41
        
       [](#opt-environment.systemPackages) and run `nixos-rebuild switch`.

     

       42
       42
        
       

     

       43
       43
        
       ```{=include=} sections

+2 -2

nixos/doc/manual/configuration/modularity.section.md

···

       36
       36
        
       Note that both `configuration.nix` and `kde.nix` define the option

     

       37
       37
        
       [](#opt-environment.systemPackages). When multiple modules define an

     

       38
       38
        
       option, NixOS will try to *merge* the definitions. In the case of

     

       39
       39
       -
       [](#opt-environment.systemPackages), that's easy: the lists of

     

       40
       40
       -
       packages can simply be concatenated. The value in `configuration.nix` is

     

       39
       39
       +
       [](#opt-environment.systemPackages) the lists of packages will be

     

       40
       40
       +
       concatenated. The value in `configuration.nix` is

     

       41
       41
        
       merged last, so for list-type options, it will appear at the end of the

     

       42
       42
        
       merged list. If you want it to appear first, you can use `mkBefore`:

     

       43
       43

+1 -1

nixos/doc/manual/configuration/xfce.chapter.md

···

       28
       28
        
       

     

       29
       29
        
       Thunar (the Xfce file manager) is automatically enabled when Xfce is

     

       30
       30
        
       enabled. To enable Thunar without enabling Xfce, use the configuration

     

       31
       31
       -
       option [](#opt-programs.thunar.enable) instead of simply adding

     

       31
       31
       +
       option [](#opt-programs.thunar.enable) instead of adding

     

       32
       32
        
       `pkgs.xfce.thunar` to [](#opt-environment.systemPackages).

     

       33
       33
        
       

     

       34
       34
        
       If you'd like to add extra plugins to Thunar, add them to

+1 -1

nixos/doc/manual/development/writing-documentation.chapter.md

···

       50
       50
        
       Pandoc can also quickly convert a single `section.xml` to HTML, which is

     

       51
       51
        
       helpful when drafting.

     

       52
       52
        
       

     

       53
       53
       -
       Sometimes writing valid DocBook is simply too difficult. In this case,

     

       53
       53
       +
       Sometimes writing valid DocBook is too difficult. In this case,

     

       54
       54
        
       submit your documentation updates in a [GitHub

     

       55
       55
        
       Issue](https://github.com/NixOS/nixpkgs/issues/new) and someone will

     

       56
       56
        
       handle the conversion to XML for you.

+1 -1

nixos/doc/manual/installation/installing-pxe.section.md

···

       4
       4
        
       setup.

     

       5
       5
        
       

     

       6
       6
        
       These instructions assume that you have an existing PXE or iPXE

     

       7
       7
       -
       infrastructure and simply want to add the NixOS installer as another

     

       7
       7
       +
       infrastructure and want to add the NixOS installer as another

     

       8
       8
        
       option. To build the necessary files from your current version of nixpkgs,

     

       9
       9
        
       you can run:

     

       10
       10

+1 -1

nixos/doc/manual/release-notes/rl-1609.section.md

···

       46
       46
        
       

     

       47
       47
        
       Other notable improvements:

     

       48
       48
        
       

     

       49
       49
       -
       - Revamped grsecurity/PaX support. There is now only a single general-purpose distribution kernel and the configuration interface has been streamlined. Desktop users should be able to simply set

     

       49
       49
       +
       - Revamped grsecurity/PaX support. There is now only a single general-purpose distribution kernel and the configuration interface has been streamlined. Desktop users should be able to set

     

       50
       50
        
       

     

       51
       51
        
         ```nix

     

       52
       52
        
         {

+1 -1

nixos/doc/manual/release-notes/rl-1909.section.md

···

       198
       198
        
       

     

       199
       199
        
         For nginx, the dependencies are still automatically managed when `services.nginx.virtualhosts.<name>.enableACME` is enabled just like before. What changed is that nginx now directly depends on the specific certificates that it needs, instead of depending on the catch-all `acme-certificates.target`. This target unit was also removed from the codebase. This will mean nginx will no longer depend on certificates it isn't explicitly managing and fixes a bug with certificate renewal ordering racing with nginx restarting which could lead to nginx getting in a broken state as described at [NixOS/nixpkgs\#60180](https://github.com/NixOS/nixpkgs/issues/60180).

     

       200
       200
        
       

     

       201
       201
       -
       - The old deprecated `emacs` package sets have been dropped. What used to be called `emacsPackagesNg` is now simply called `emacsPackages`.

     

       201
       201
       +
       - The old deprecated `emacs` package sets have been dropped. What used to be called `emacsPackagesNg` is now called `emacsPackages`.

     

       202
       202
        
       

     

       203
       203
        
       - `services.xserver.desktopManager.xterm` is now disabled by default if `stateVersion` is 19.09 or higher. Previously the xterm desktopManager was enabled when xserver was enabled, but it isn't useful for all people so it didn't make sense to have any desktopManager enabled default.

     

       204
       204

+1 -1

nixos/doc/manual/release-notes/rl-2003.section.md

···

       482
       482
        
       

     

       483
       483
        
         - If you use `postgresql` on a different server, you don't need to change anything as well since this module was never designed to configure remote databases.

     

       484
       484
        
       

     

       485
       485
       -
         - If you use `postgresql` and configured your synapse initially on `19.09` or older, you simply need to enable postgresql-support explicitly:

     

       485
       485
       +
         - If you use `postgresql` and configured your synapse initially on `19.09` or older, you need to enable postgresql-support explicitly:

     

       486
       486
        
       

     

       487
       487
        
           ```nix

     

       488
       488
        
           { ... }: {

+1 -1

nixos/doc/manual/release-notes/rl-2009.section.md

···

422
422

423
423

- The `systemd-networkd` option `systemd.network.networks._name_.dhcpConfig` has been renamed to [systemd.network.networks._name_.dhcpV4Config](options.html#opt-systemd.network.networks._name_.dhcpV4Config) following upstream systemd's documentation change. See systemd.network 5 for details.

424
424

425
425
-
- In the `picom` module, several options that accepted floating point numbers encoded as strings (for example [services.picom.activeOpacity](options.html#opt-services.picom.activeOpacity)) have been changed to the (relatively) new native `float` type. To migrate your configuration simply remove the quotes around the numbers.

425
425
+
- In the `picom` module, several options that accepted floating point numbers encoded as strings (for example [services.picom.activeOpacity](options.html#opt-services.picom.activeOpacity)) have been changed to the (relatively) new native `float` type. To migrate your configuration remove the quotes around the numbers.

426
426

427
427

- When using `buildBazelPackage` from Nixpkgs, `flat` hash mode is now used for dependencies instead of `recursive`. This is to better allow using hashed mirrors where needed. As a result, these hashes will have changed.

428
428

+1 -1

nixos/doc/manual/release-notes/rl-2211.section.md

···

14
14

- Support for algorithms that `libxcrypt` [does not consider strong](https://github.com/besser82/libxcrypt/blob/v4.4.28/lib/hashes.conf#L41) are **deprecated** as of this release, and will be removed in NixOS 23.05.

15
15

- This includes system login passwords. Given this, we **strongly encourage** all users to update their system passwords, as you will be unable to login if password hashes are not migrated by the time their support is removed.

16
16

- When using `users.users.<name>.hashedPassword` to configure user passwords, run `mkpasswd`, and use the yescrypt hash that is provided as the new value.

17
17
-
- On the other hand, for interactively configured user passwords, simply re-set the passwords for all users with `passwd`.

17
17
+
- On the other hand, for interactively configured user passwords, re-set the passwords for all users with `passwd`.

18
18

- This release introduces warnings for the use of deprecated hash algorithms for both methods of configuring passwords. To make sure you migrated correctly, run `nixos-rebuild switch`.

19
19

20
20

- The NixOS documentation is now generated from markdown. While docbook is still part of the documentation build process, it's a big step towards the full migration.

+1 -1

nixos/doc/manual/release-notes/rl-2305.section.md

···

       611
       611
        
       - adding new rules with `*.rules`

     

       612
       612
        
       - running custom PulseAudio commands with `pulse.cmd`

     

       613
       613
        
       

     

       614
       614
       -
       Simply move the definitions into the drop-in.

     

       614
       614
       +
       Move the definitions into the drop-in.

     

       615
       615
        
       

     

       616
       616
        
       Note that the use of `context.exec` is not recommended and other methods of running your thing are likely a better option.

     

       617
       617

+1 -1

nixos/doc/manual/release-notes/rl-2311.section.md

···

       304
       304
        
       

     

       305
       305
        
       - Emacs macport version 29 was introduced.

     

       306
       306
        
       

     

       307
       307
       -
       - The option `services.networking.networkmanager.enableFccUnlock` was removed in favor of `networking.networkmanager.fccUnlockScripts`, which allows specifying unlock scripts explicitly. The previous option simply did enable all unlock scripts bundled with ModemManager, which is risky, and didn't allow using vendor-provided unlock scripts at all.

     

       307
       307
       +
       - The option `services.networking.networkmanager.enableFccUnlock` was removed in favor of `networking.networkmanager.fccUnlockScripts`, which allows specifying unlock scripts explicitly. The previous option enabled all unlock scripts bundled with ModemManager, which is risky, and didn't allow using vendor-provided unlock scripts at all.

     

       308
       308
        
       

     

       309
       309
        
       - The `html-proofer` package has been updated from major version 3 to major version 5, which includes [breaking changes](https://github.com/gjtorikian/html-proofer/blob/v5.0.8/UPGRADING.md).

     

       310
       310