pyrox.dev
+1
-1
doc/using/configuration.chapter.md
+1
-1
doc/using/configuration.chapter.md
···-The difference between a package being unsupported on some system and being broken is admittedly a bit fuzzy. If a program *ought* to work on a certain platform, but doesn't, the platform should be included in `meta.platforms`, but marked as broken with e.g. `meta.broken = !hostPlatform.isWindows`. Of course, this begs the question of what \"ought\" means exactly. That is left to the package maintainer.+The difference between a package being unsupported on some system and being broken is admittedly a bit fuzzy. If a program *ought* to work on a certain platform, but doesn't, the platform should be included in `meta.platforms`, but marked as broken with e.g. `meta.broken = !hostPlatform.isWindows`. Of course, this begs the question of what "ought" means exactly. That is left to the package maintainer.
+1
-1
nixos/doc/manual/configuration/kubernetes.chapter.md
+1
-1
nixos/doc/manual/configuration/kubernetes.chapter.md
+1
-1
nixos/doc/manual/configuration/xfce.chapter.md
+1
-1
nixos/doc/manual/configuration/xfce.chapter.md
···
+2
-2
nixos/doc/manual/from_md/configuration/kubernetes.chapter.xml
+2
-2
nixos/doc/manual/from_md/configuration/kubernetes.chapter.xml
···
+4
-3
nixos/doc/manual/from_md/configuration/xfce.chapter.xml
+4
-3
nixos/doc/manual/from_md/configuration/xfce.chapter.xml
···
+3
-3
nixos/doc/manual/from_md/installation/installing-from-other-distro.section.xml
+3
-3
nixos/doc/manual/from_md/installation/installing-from-other-distro.section.xml
···
+3
-3
nixos/doc/manual/from_md/installation/installing-usb.section.xml
+3
-3
nixos/doc/manual/from_md/installation/installing-usb.section.xml
···
+4
-4
nixos/doc/manual/from_md/installation/installing-virtualbox-guest.section.xml
+4
-4
nixos/doc/manual/from_md/installation/installing-virtualbox-guest.section.xml
·········
+6
-6
nixos/doc/manual/from_md/release-notes/rl-1509.section.xml
+6
-6
nixos/doc/manual/from_md/release-notes/rl-1509.section.xml
·········
+3
-3
nixos/doc/manual/from_md/release-notes/rl-1603.section.xml
+3
-3
nixos/doc/manual/from_md/release-notes/rl-1603.section.xml
······
+5
-5
nixos/doc/manual/from_md/release-notes/rl-1803.section.xml
+5
-5
nixos/doc/manual/from_md/release-notes/rl-1803.section.xml
···
+1
-1
nixos/doc/manual/from_md/release-notes/rl-1903.section.xml
+1
-1
nixos/doc/manual/from_md/release-notes/rl-1903.section.xml
···
+3
-3
nixos/doc/manual/from_md/release-notes/rl-1909.section.xml
+3
-3
nixos/doc/manual/from_md/release-notes/rl-1909.section.xml
···
+6
-6
nixos/doc/manual/from_md/release-notes/rl-2009.section.xml
+6
-6
nixos/doc/manual/from_md/release-notes/rl-2009.section.xml
······
+5
-4
nixos/doc/manual/from_md/release-notes/rl-2105.section.xml
+5
-4
nixos/doc/manual/from_md/release-notes/rl-2105.section.xml
·········
+2
-2
nixos/doc/manual/installation/installing-from-other-distro.section.md
+2
-2
nixos/doc/manual/installation/installing-from-other-distro.section.md
···
+2
-2
nixos/doc/manual/installation/installing-usb.section.md
+2
-2
nixos/doc/manual/installation/installing-usb.section.md
···
+3
-3
nixos/doc/manual/installation/installing-virtualbox-guest.section.md
+3
-3
nixos/doc/manual/installation/installing-virtualbox-guest.section.md
·········
+2
-2
nixos/doc/manual/release-notes/rl-1509.section.md
+2
-2
nixos/doc/manual/release-notes/rl-1509.section.md
···-- The [Haskell](http://haskell.org/) packages infrastructure has been re-designed from the ground up (\"Haskell NG\"). NixOS now distributes the latest version of every single package registered on [Hackage](http://hackage.haskell.org/) \-- well in excess of 8,000 Haskell packages. Detailed instructions on how to use that infrastructure can be found in the [User's Guide to the Haskell Infrastructure](https://nixos.org/nixpkgs/manual/#users-guide-to-the-haskell-infrastructure). Users migrating from an earlier release may find helpful information below, in the list of backwards-incompatible changes. Furthermore, we distribute 51(!) additional Haskell package sets that provide every single [LTS Haskell](http://www.stackage.org/) release since version 0.0 as well as the most recent [Stackage Nightly](http://www.stackage.org/) snapshot. The announcement [\"Full Stackage Support in Nixpkgs\"](https://nixos.org/nix-dev/2015-September/018138.html) gives additional details.+- The [Haskell](http://haskell.org/) packages infrastructure has been re-designed from the ground up ("Haskell NG"). NixOS now distributes the latest version of every single package registered on [Hackage](http://hackage.haskell.org/) \-- well in excess of 8,000 Haskell packages. Detailed instructions on how to use that infrastructure can be found in the [User's Guide to the Haskell Infrastructure](https://nixos.org/nixpkgs/manual/#users-guide-to-the-haskell-infrastructure). Users migrating from an earlier release may find helpful information below, in the list of backwards-incompatible changes. Furthermore, we distribute 51(!) additional Haskell package sets that provide every single [LTS Haskell](http://www.stackage.org/) release since version 0.0 as well as the most recent [Stackage Nightly](http://www.stackage.org/) snapshot. The announcement ["Full Stackage Support in Nixpkgs"](https://nixos.org/nix-dev/2015-September/018138.html) gives additional details.- Nix has been updated to version 1.10, which among other improvements enables cryptographic signatures on binary caches for improved security.···-- \"`nix-env -qa`\" no longer discovers Haskell packages by name. The only packages visible in the global scope are `ghc`, `cabal-install`, and `stack`, but all other packages are hidden. The reason for this inconvenience is the sheer size of the Haskell package set. Name-based lookups are expensive, and most `nix-env -qa` operations would become much slower if we'd add the entire Hackage database into the top level attribute set. Instead, the list of Haskell packages can be displayed by running:+- "`nix-env -qa`" no longer discovers Haskell packages by name. The only packages visible in the global scope are `ghc`, `cabal-install`, and `stack`, but all other packages are hidden. The reason for this inconvenience is the sheer size of the Haskell package set. Name-based lookups are expensive, and most `nix-env -qa` operations would become much slower if we'd add the entire Hackage database into the top level attribute set. Instead, the list of Haskell packages can be displayed by running:
+2
-2
nixos/doc/manual/release-notes/rl-1603.section.md
+2
-2
nixos/doc/manual/release-notes/rl-1603.section.md
···you should either re-run `nixos-generate-config` or manually replace `"${config.boot.kernelPackages.broadcom_sta}"` by `config.boot.kernelPackages.broadcom_sta` in your `/etc/nixos/hardware-configuration.nix`. More discussion is on [ the github issue](https://github.com/NixOS/nixpkgs/pull/12595).-- The `services.xserver.startGnuPGAgent` option has been removed. GnuPG 2.1.x changed the way the gpg-agent works, and that new approach no longer requires (or even supports) the \"start everything as a child of the agent\" scheme we've implemented in NixOS for older versions. To configure the gpg-agent for your X session, add the following code to `~/.bashrc` or some file that's sourced when your shell is started:+- The `services.xserver.startGnuPGAgent` option has been removed. GnuPG 2.1.x changed the way the gpg-agent works, and that new approach no longer requires (or even supports) the "start everything as a child of the agent" scheme we've implemented in NixOS for older versions. To configure the gpg-agent for your X session, add the following code to `~/.bashrc` or some file that's sourced when your shell is started:···-The `gpg-agent(1)` man page has more details about this subject, i.e. in the \"EXAMPLES\" section.+The `gpg-agent(1)` man page has more details about this subject, i.e. in the "EXAMPLES" section.
+1
-1
nixos/doc/manual/release-notes/rl-1803.section.md
+1
-1
nixos/doc/manual/release-notes/rl-1803.section.md
···- `cc-wrapper` has been split in two; there is now also a `bintools-wrapper`. The most commonly used files in `nix-support` are now split between the two wrappers. Some commonly used ones, like `nix-support/dynamic-linker`, are duplicated for backwards compatability, even though they rightly belong only in `bintools-wrapper`. Other more obscure ones are just moved.-- The propagation logic has been changed. The new logic, along with new types of dependencies that go with, is thoroughly documented in the \"Specifying dependencies\" section of the \"Standard Environment\" chapter of the nixpkgs manual. The old logic isn't but is easy to describe: dependencies were propagated as the same type of dependency no matter what. In practice, that means that many `propagatedNativeBuildInputs` should instead be `propagatedBuildInputs`. Thankfully, that was and is the least used type of dependency. Also, it means that some `propagatedBuildInputs` should instead be `depsTargetTargetPropagated`. Other types dependencies should be unaffected.+- The propagation logic has been changed. The new logic, along with new types of dependencies that go with, is thoroughly documented in the "Specifying dependencies" section of the "Standard Environment" chapter of the nixpkgs manual. The old logic isn't but is easy to describe: dependencies were propagated as the same type of dependency no matter what. In practice, that means that many `propagatedNativeBuildInputs` should instead be `propagatedBuildInputs`. Thankfully, that was and is the least used type of dependency. Also, it means that some `propagatedBuildInputs` should instead be `depsTargetTargetPropagated`. Other types dependencies should be unaffected.- `lib.addPassthru drv passthru` is removed. Use `lib.extendDerivation true passthru drv` instead.
+1
-1
nixos/doc/manual/release-notes/rl-1903.section.md
+1
-1
nixos/doc/manual/release-notes/rl-1903.section.md
···- The option `services.xserver.displayManager.job.logToFile` which was previously set to `true` when using the display managers `lightdm`, `sddm` or `xpra` has been reset to the default value (`false`).-- Network interface indiscriminate NixOS firewall options (`networking.firewall.allow*`) are now preserved when also setting interface specific rules such as `networking.firewall.interfaces.en0.allow*`. These rules continue to use the pseudo device \"default\" (`networking.firewall.interfaces.default.*`), and assigning to this pseudo device will override the (`networking.firewall.allow*`) options.+- Network interface indiscriminate NixOS firewall options (`networking.firewall.allow*`) are now preserved when also setting interface specific rules such as `networking.firewall.interfaces.en0.allow*`. These rules continue to use the pseudo device "default" (`networking.firewall.interfaces.default.*`), and assigning to this pseudo device will override the (`networking.firewall.allow*`) options.- The `nscd` service now disables all caching of `passwd` and `group` databases by default. This was interferring with the correct functioning of the `libnss_systemd.so` module which is used by `systemd` to manage uids and usernames in the presence of `DynamicUser=` in systemd services. This was already the default behaviour in presence of `services.sssd.enable = true` because nscd caching would interfere with `sssd` in unpredictable ways as well. Because we're using nscd not for caching, but for convincing glibc to find NSS modules in the nix store instead of an absolute path, we have decided to disable caching globally now, as it's usually not the behaviour the user wants and can lead to surprising behaviour. Furthermore, negative caching of host lookups is also disabled now by default. This should fix the issue of dns lookups failing in the presence of an unreliable network.
+1
-1
nixos/doc/manual/release-notes/rl-1909.section.md
+1
-1
nixos/doc/manual/release-notes/rl-1909.section.md
···- Citrix Receiver (`citrix_receiver`) has been dropped in favor of Citrix Workspace (`citrix_workspace`).-- The `services.gitlab` module has had its literal secret options (`services.gitlab.smtp.password`, `services.gitlab.databasePassword`, `services.gitlab.initialRootPassword`, `services.gitlab.secrets.secret`, `services.gitlab.secrets.db`, `services.gitlab.secrets.otp` and `services.gitlab.secrets.jws`) replaced by file-based versions (`services.gitlab.smtp.passwordFile`, `services.gitlab.databasePasswordFile`, `services.gitlab.initialRootPasswordFile`, `services.gitlab.secrets.secretFile`, `services.gitlab.secrets.dbFile`, `services.gitlab.secrets.otpFile` and `services.gitlab.secrets.jwsFile`). This was done so that secrets aren't stored in the world-readable nix store, but means that for each option you'll have to create a file with the same exact string, add \"File\" to the end of the option name, and change the definition to a string pointing to the corresponding file; e.g. `services.gitlab.databasePassword = "supersecurepassword"` becomes `services.gitlab.databasePasswordFile = "/path/to/secret_file"` where the file `secret_file` contains the string `supersecurepassword`.+- The `services.gitlab` module has had its literal secret options (`services.gitlab.smtp.password`, `services.gitlab.databasePassword`, `services.gitlab.initialRootPassword`, `services.gitlab.secrets.secret`, `services.gitlab.secrets.db`, `services.gitlab.secrets.otp` and `services.gitlab.secrets.jws`) replaced by file-based versions (`services.gitlab.smtp.passwordFile`, `services.gitlab.databasePasswordFile`, `services.gitlab.initialRootPasswordFile`, `services.gitlab.secrets.secretFile`, `services.gitlab.secrets.dbFile`, `services.gitlab.secrets.otpFile` and `services.gitlab.secrets.jwsFile`). This was done so that secrets aren't stored in the world-readable nix store, but means that for each option you'll have to create a file with the same exact string, add "File" to the end of the option name, and change the definition to a string pointing to the corresponding file; e.g. `services.gitlab.databasePassword = "supersecurepassword"` becomes `services.gitlab.databasePasswordFile = "/path/to/secret_file"` where the file `secret_file` contains the string `supersecurepassword`.The state path (`services.gitlab.statePath`) now has the following restriction: no parent directory can be owned by any other user than `root` or the user specified in `services.gitlab.user`; i.e. if `services.gitlab.statePath` is set to `/var/lib/gitlab/state`, `gitlab` and all parent directories must be owned by either `root` or the user specified in `services.gitlab.user`.
+2
-2
nixos/doc/manual/release-notes/rl-2009.section.md
+2
-2
nixos/doc/manual/release-notes/rl-2009.section.md
···-The base package has also been upgraded to the 2020-07-29 \"Hogfather\" release. Plugins might be incompatible or require upgrading.+The base package has also been upgraded to the 2020-07-29 "Hogfather" release. Plugins might be incompatible or require upgrading.- The [services.postgresql.dataDir](options.html#opt-services.postgresql.dataDir) option is now set to `"/var/lib/postgresql/${cfg.package.psqlSchema}"` regardless of your [system.stateVersion](options.html#opt-system.stateVersion). Users with an existing postgresql install that have a [system.stateVersion](options.html#opt-system.stateVersion) of `17.03` or below should double check what the value of their [services.postgresql.dataDir](options.html#opt-services.postgresql.dataDir) option is (`/var/db/postgresql`) and then explicitly set this value to maintain compatibility:···Please note that Rust packages utilizing a custom build/install procedure (e.g. by using a `Makefile`) or test suites that rely on the structure of the `target/` directory may break due to those assumptions. For further information, please read the Rust section in the Nixpkgs manual.-- The cc- and binutils-wrapper's \"infix salt\" and `_BUILD_` and `_TARGET_` user infixes have been replaced with with a \"suffix salt\" and suffixes and `_FOR_BUILD` and `_FOR_TARGET`. This matches the autotools convention for env vars which standard for these things, making interfacing with other tools easier.+- The cc- and binutils-wrapper's "infix salt" and `_BUILD_` and `_TARGET_` user infixes have been replaced with with a "suffix salt" and suffixes and `_FOR_BUILD` and `_FOR_TARGET`. This matches the autotools convention for env vars which standard for these things, making interfacing with other tools easier.- Additional Git documentation (HTML and text files) is now available via the `git-doc` package.
+3
-3
nixos/doc/manual/release-notes/rl-2105.section.md
+3
-3
nixos/doc/manual/release-notes/rl-2105.section.md
···- If the `services.dbus` module is enabled, then the user D-Bus session is now always socket activated. The associated options `services.dbus.socketActivated` and `services.xserver.startDbusSession` have therefore been removed and you will receive a warning if they are present in your configuration. This change makes the user D-Bus session available also for non-graphical logins.-- The `networking.wireless.iwd` module now installs the upstream-provided 80-iwd.link file, which sets the NamePolicy= for all wlan devices to \"keep kernel\", to avoid race conditions between iwd and networkd. If you don't want this, you can set `systemd.network.links."80-iwd" = lib.mkForce {}`.+- The `networking.wireless.iwd` module now installs the upstream-provided 80-iwd.link file, which sets the NamePolicy= for all wlan devices to "keep kernel", to avoid race conditions between iwd and networkd. If you don't want this, you can set `systemd.network.links."80-iwd" = lib.mkForce {}`.- `rubyMinimal` was removed due to being unused and unusable. The default ruby interpreter includes JIT support, which makes it reference it's compiler. Since JIT support is probably needed by some Gems, it was decided to enable this feature with all cc references by default, and allow to build a Ruby derivation without references to cc, by setting `jitSupport = false;` in an overlay. See [\#90151](https://github.com/NixOS/nixpkgs/pull/90151) for more info.···Regarding the NixOS module, new options for HTTPS inspection have been added and `services.privoxy.extraConfig` has been replaced by the new [services.privoxy.settings](options.html#opt-services.privoxy.settings) (See [RFC 0042](https://github.com/NixOS/rfcs/blob/master/rfcs/0042-config-option.md) for the motivation).-- [Kodi](https://kodi.tv/) has been updated to version 19.1 \"Matrix\". See the [announcement](https://kodi.tv/article/kodi-19-0-matrix-release) for further details.+- [Kodi](https://kodi.tv/) has been updated to version 19.1 "Matrix". See the [announcement](https://kodi.tv/article/kodi-19-0-matrix-release) for further details.- The `services.packagekit.backend` option has been removed as it only supported a single setting which would always be the default. Instead new [RFC 0042](https://github.com/NixOS/rfcs/blob/master/rfcs/0042-config-option.md) compliant [services.packagekit.settings](options.html#opt-services.packagekit.settings) and [services.packagekit.vendorSettings](options.html#opt-services.packagekit.vendorSettings) options have been introduced.···- GNOME users may wish to delete their `~/.config/pulse` due to the changes to stream routing logic. See [PulseAudio bug 832](https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/832) for more information.-- The zookeeper package does not provide `zooInspector.sh` anymore, as that \"contrib\" has been dropped from upstream releases.+- The zookeeper package does not provide `zooInspector.sh` anymore, as that "contrib" has been dropped from upstream releases.- In the ACME module, the data used to build the hash for the account directory has changed to accommodate new features to reduce account rate limit issues. This will trigger new account creation on the first rebuild following this update. No issues are expected to arise from this, thanks to the new account creation handling.