jiebi/CodeConvo huggingface dataset:
Code change:
This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.
Hi Opened PR for this.

Related discussion:
text: <para> This chapter contains information about how to use and maintain the Nix expressions for a number of specific packages, such as the Linux kernel or X.org. </para> <del> <xi:include href="citrix.xml" /> </del> <ins> <xi:include href="citrix.section.xml" /> </ins> <xi:include href="dlib.xml" /> <xi:include href="eclipse.section.xml" /> <xi:include href="elm.section.xml" />
Code change:
This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.
I will also work on this

Related discussion:
text: <xi:include href="shell-helpers.xml" /> <xi:include href="steam.xml" /> <xi:include href="cataclysm-dda.section.xml" /> <del> <xi:include href="urxvt.xml" /> </del> <ins> <xi:include href="urxvt.section.xml" /> </ins> <xi:include href="weechat.section.xml" /> <xi:include href="xorg.section.xml" /> </chapter>
Code change:
This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.
I will also work on this

Related discussion:
text: <ins> # Urxvt {#sec-urxvt} Urxvt, also known as rxvt-unicode, is a highly customizable terminal emulator. ## Configuring urxvt {#sec-urxvt-conf} In `nixpkgs`, urxvt is provided by the package `rxvt-unicode`. It can be configured to include your choice of plugins, reducing its closure size from the default configuration which includes all available plugins. To make use of this functionality, use an overlay or directly install an expression that overrides its configuration, such as ```nix rxvt-unicode.override { configure = { availablePlugins, ... }: { plugins = with availablePlugins; [ perls resize-font vtwheel ]; }; } ``` If the `configure` function returns an attrset without the `plugins` attribute, `availablePlugins` will be used automatically. In order to add plugins but also keep all default plugins installed, it is possible to use the following method: ```nix rxvt-unicode.override { configure = { availablePlugins, ... }: { plugins = (builtins.attrValues availablePlugins) ++ [ custom-plugin ]; }; } ``` To get a list of all the plugins available, open the Nix REPL and run ```ShellSession $ nix repl :l <nixpkgs> map (p: p.name) pkgs.rxvt-unicode.plugins ``` Alternatively, if your shell is bash or zsh and have completion enabled, simply type `nixpkgs.rxvt-unicode.plugins.<tab>`. 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: ```nix rxvt-unicode.override { configure = { availablePlugins, ... }: { pluginsDeps = [ xsel ]; }; } ``` `perlDeps` is a handy way to provide Perl packages to your custom plugins (in `$HOME/.urxvt/ext`). For example, if you need `AnyEvent` you can do: ```nix rxvt-unicode.override { configure = { availablePlugins, ... }: { perlDeps = with perlPackages; [ AnyEvent ]; }; } ``` ## Packaging urxvt plugins {#sec-urxvt-pkg} Urxvt plugins resides in `pkgs/applications/misc/rxvt-unicode-plugins`. To add a new plugin create an expression in a subdirectory and add the package to the set in `pkgs/applications/misc/rxvt-unicode-plugins/default.nix`. A plugin can be any kind of derivation, the only requirement is that it should always install perl scripts in `$out/lib/urxvt/perl`. Look for existing plugins for examples. If the plugin is itself a perl package that needs to be imported from other plugins or scripts, add the following passthrough: ```nix passthru.perlPackages = [ "self" ]; ``` This will make the urxvt wrapper pick up the dependency and set up the perl path accordingly. </ins>
Code change:
Describe the bug Suspend to disk / hibernation in combination with ZFS may lead to filesystem corruption. To Reproduce The problem only shows up occasionally about once on every 30 startups. I had been using suspend to disk on my laptop without problem for several years. After changing from BTRFS to ZFS the import of the ZFS pool occasionally stalls when resuming from hibernate. A message says that the pool is corrupted and gets reconstructed. Once the pool was corrupted irreparably. Root cause ZFS does not support filesystem freeze and thaw under Linux at the moment. (see ) The problem is that when resuming from hibernation the initrd tries to import the pool (it also tries to fix a corrupted pool and effectively modifies the pool/partition). This happens before checks for a possible resume from hibernation and before the system returns to the state in which it had been suspended. Expected behavior It may be possible to fix the problem by reordering the sequence of actions in initrd. Unless there is a fix for this NixOS should disable the combination of ZFS and hibernation. (More precisely, initrd should either contain the setup scripts for ZFS or the scripts for return-from-hibernate). At least there should be a warning.
BTRFS is native to Linux, so its suspension mechanism and Linux's were (presumably) always set up to work with each other. On the other hand, ZFS's suspension code has not yet been hooked up to Linux's properly: I agree that— One potential problem seems to be that there seem to be multiple packages that can cause suspension. In my NixOS configuration, I tell and not to suspend, but I don't know whether that's everything that might cause suspension.
Thanks for adding the link. I've a corresponding line of warning here:
Do you suspend to disk with a zvol swap? Because I'm running with root on ZFS on my laptop and I have never encountered problems with suspend to disk, but I'm also using a separate regular swap partition.
I for one use a regular swap partition. I recall hearing that swap-on-ZVOL is dangerous independently of hibernation.
I marked this as stale due to inactivity. &rarr;
Would it make sense to automatically add in cases where zfs is in use?
This. A note in wiki or manual will be good too. EDIT: Done ().
I marked this as stale due to inactivity. &rarr;
Let's see if we can close this with
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Related discussion:
text: </listitem> <listitem> <para> <ins> ZFS module will not allow hibernation by default, this is a safety measure to prevent data loss cases like the ones described at <link xlink:href="https://github.com/openzfs/zfs/issues/260">OpenZFS/260</link> and <link xlink:href="https://github.com/openzfs/zfs/issues/12842">OpenZFS/12842</link>. Use the <literal>boot.zfs.allowHibernation</literal> option to configure this behaviour. </para> </listitem> <listitem> <para> </ins> The Redis module now disables RDB persistence when <literal>services.redis.servers.&lt;name&gt;.save = []</literal> instead of using the Redis default.
Code change:
Describe the bug Suspend to disk / hibernation in combination with ZFS may lead to filesystem corruption. To Reproduce The problem only shows up occasionally about once on every 30 startups. I had been using suspend to disk on my laptop without problem for several years. After changing from BTRFS to ZFS the import of the ZFS pool occasionally stalls when resuming from hibernate. A message says that the pool is corrupted and gets reconstructed. Once the pool was corrupted irreparably. Root cause ZFS does not support filesystem freeze and thaw under Linux at the moment. (see ) The problem is that when resuming from hibernation the initrd tries to import the pool (it also tries to fix a corrupted pool and effectively modifies the pool/partition). This happens before checks for a possible resume from hibernation and before the system returns to the state in which it had been suspended. Expected behavior It may be possible to fix the problem by reordering the sequence of actions in initrd. Unless there is a fix for this NixOS should disable the combination of ZFS and hibernation. (More precisely, initrd should either contain the setup scripts for ZFS or the scripts for return-from-hibernate). At least there should be a warning.
BTRFS is native to Linux, so its suspension mechanism and Linux's were (presumably) always set up to work with each other. On the other hand, ZFS's suspension code has not yet been hooked up to Linux's properly: I agree that— One potential problem seems to be that there seem to be multiple packages that can cause suspension. In my NixOS configuration, I tell and not to suspend, but I don't know whether that's everything that might cause suspension.
Thanks for adding the link. I've a corresponding line of warning here:
Do you suspend to disk with a zvol swap? Because I'm running with root on ZFS on my laptop and I have never encountered problems with suspend to disk, but I'm also using a separate regular swap partition.
I for one use a regular swap partition. I recall hearing that swap-on-ZVOL is dangerous independently of hibernation.
I marked this as stale due to inactivity. &rarr;
Would it make sense to automatically add in cases where zfs is in use?
This. A note in wiki or manual will be good too. EDIT: Done ().
I marked this as stale due to inactivity. &rarr;
Let's see if we can close this with
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Related discussion:
text: ''; }; <ins> allowHibernation = mkOption { type = types.bool; default = false; description = lib.mdDoc '' Allow hibernation support, this may be a unsafe option depending on your setup. Make sure to NOT use Swap on ZFS. ''; }; </ins> extraPools = mkOption { type = types.listOf types.str; default = [];
Code change:
Describe the bug Suspend to disk / hibernation in combination with ZFS may lead to filesystem corruption. To Reproduce The problem only shows up occasionally about once on every 30 startups. I had been using suspend to disk on my laptop without problem for several years. After changing from BTRFS to ZFS the import of the ZFS pool occasionally stalls when resuming from hibernate. A message says that the pool is corrupted and gets reconstructed. Once the pool was corrupted irreparably. Root cause ZFS does not support filesystem freeze and thaw under Linux at the moment. (see ) The problem is that when resuming from hibernation the initrd tries to import the pool (it also tries to fix a corrupted pool and effectively modifies the pool/partition). This happens before checks for a possible resume from hibernation and before the system returns to the state in which it had been suspended. Expected behavior It may be possible to fix the problem by reordering the sequence of actions in initrd. Unless there is a fix for this NixOS should disable the combination of ZFS and hibernation. (More precisely, initrd should either contain the setup scripts for ZFS or the scripts for return-from-hibernate). At least there should be a warning.
BTRFS is native to Linux, so its suspension mechanism and Linux's were (presumably) always set up to work with each other. On the other hand, ZFS's suspension code has not yet been hooked up to Linux's properly: I agree that— One potential problem seems to be that there seem to be multiple packages that can cause suspension. In my NixOS configuration, I tell and not to suspend, but I don't know whether that's everything that might cause suspension.
Thanks for adding the link. I've a corresponding line of warning here:
Do you suspend to disk with a zvol swap? Because I'm running with root on ZFS on my laptop and I have never encountered problems with suspend to disk, but I'm also using a separate regular swap partition.
I for one use a regular swap partition. I recall hearing that swap-on-ZVOL is dangerous independently of hibernation.
I marked this as stale due to inactivity. &rarr;
Would it make sense to automatically add in cases where zfs is in use?
This. A note in wiki or manual will be good too. EDIT: Done ().
I marked this as stale due to inactivity. &rarr;
Let's see if we can close this with
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Related discussion:
text: boot = { kernelModules = [ "zfs" ]; <ins> # https://github.com/openzfs/zfs/issues/260 # https://github.com/openzfs/zfs/issues/12842 # https://github.com/NixOS/nixpkgs/issues/106093 kernelParams = lib.optionals (!config.boot.zfs.allowHibernation) [ "nohibernate" ]; </ins> extraModulePackages = [ (if config.boot.zfs.enableUnstable then
Code change:
Describe the bug is missing a menu entry to launch the application. To Reproduce Steps to reproduce the behavior: Expected behavior There should be a menu entry to launch the application. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata
see (probably shouldn't have been closed)

Related discussion:
text: in (concatStringsSep "n" (flatten [ <ins> "runHook preInstall" </ins> (optionalString (withScripting) "buildPythonPath "${base} $pythonPath" n") # wrap each of the directly usable tools
Code change:
Describe the bug is missing a menu entry to launch the application. To Reproduce Steps to reproduce the behavior: Expected behavior There should be a menu entry to launch the application. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata
see (probably shouldn't have been closed)

Related discussion:
text: # link in the CLI utils (map (util: "ln -s ${base}/bin/${util} $out/bin/${util}") utils) <ins> "runHook postInstall" </ins> ]) ) ; <ins> postInstall = '' mkdir -p $out/share ln -s ${base}/share/applications $out/share/applications ln -s ${base}/share/icons $out/share/icons ln -s ${base}/share/mime $out/share/mime ''; </ins> # can't run this for each pname # stable and unstable are in the same versions.nix # and kicad-small reuses stable
Code change:
Describe the bug is missing a menu entry to launch the application. To Reproduce Steps to reproduce the behavior: Expected behavior There should be a menu entry to launch the application. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata
see (probably shouldn't have been closed)

Related discussion:
text: KiCad is an open source software suite for Electronic Design Automation. The Programs handle Schematic Capture, and PCB Layout with Gerber output. ''; <del> license = lib.licenses.agpl3; </del> <ins> license = lib.licenses.gpl3Plus; </ins> # berce seems inactive... maintainers = with lib.maintainers; [ evils kiwi berce ]; # kicad is cross platform
Code change:
With the update to 1.48, rustc is missing some host platform libraries when built as a cross-compiler. Most notably, is missing which causes cross-compiled packages with scripts to fail with the following error: The native (host == target) compiler is not affected. The diff between the native and cross directory is as follows: This seems like an upstream regression. Interestingly, the list of missing libraries exactly matches the list of libraries installed in . cc
looks kind of suspicious.
Or actually looks like it would explain the issue. I think we need to add the host platform to targets as well.
That makes sense to me and sounds like a good solution.

Related discussion:
text: }: let <del> inherit (stdenv.lib) optionals optional optionalString; </del> <ins> inherit (stdenv.lib) optionals optional optionalString concatStringsSep; </ins> inherit (darwin.apple_sdk.frameworks) Security; llvmSharedForBuild = pkgsBuildBuild.llvm_10.override { enableSharedLibraries = true; };
Code change:
With the update to 1.48, rustc is missing some host platform libraries when built as a cross-compiler. Most notably, is missing which causes cross-compiled packages with scripts to fail with the following error: The native (host == target) compiler is not affected. The diff between the native and cross directory is as follows: This seems like an upstream regression. Interestingly, the list of missing libraries exactly matches the list of libraries installed in . cc
looks kind of suspicious.
Or actually looks like it would explain the issue. I think we need to add the host platform to targets as well.
That makes sense to me and sounds like a good solution.

Related discussion:
text: "--enable-vendor" "--build=${rust.toRustTargetSpec stdenv.buildPlatform}" "--host=${rust.toRustTargetSpec stdenv.hostPlatform}" <del> "--target=${rust.toRustTargetSpec stdenv.targetPlatform}" </del> <ins> # std is built for all platforms in --target. When building a cross-compiler # we need to add the host platform as well so rustc can compile build.rs # scripts. "--target=${concatStringsSep "," ([ (rust.toRustTargetSpec stdenv.targetPlatform) ] ++ optionals (stdenv.hostPlatform != stdenv.targetPlatform) [ (rust.toRustTargetSpec stdenv.hostPlatform) ])}" </ins> "${setBuild}.cc=${ccForBuild}" "${setHost}.cc=${ccForHost}"
Code change:
Describe the bug on a NixOS configuration with systemd-boot as bootloader (the default for NixOS installs on UEFI systems) fails with this error: I checked that the file exists, so what's missing in the kernel since it reports "No such device"? Steps to reproduce This happens with nixos-20.09 and nixos-unstable, but not nixos-20.03. (Just change the command above.) Expected behavior The build succeeds, like it did before (on nixos-20.03). Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata Please run and paste the result. Maintainer information:
Disabling ~systemd-boot~ efi settings from results in So the insmod error is the same, but now the init script doesn't die on
Ah, the default value of is , and with that value it actually succeeds. So it's not really the systemd-boot part of the config that is broken.
Oh, this comment recommends NOT to set , because it can wear out the NVRAM:
Ah, the default value of is false, [...] Well, except that sets it to true, so it is enabled by default for NixOS EFI installs.
Interestingly, the uses . That results in success!
Now the question is, where to set (or )? I see at least these places where conditionally adding it could make sense: Call site: Option declaration, in qemu- Implementation, in qemu- In the systemd- module:

Related discussion:
text: virtualisation.bootDevice = mkDefault (driveDeviceName 1); <ins> virtualisation.useEFIBoot = mkDefault (config.boot.loader.systemd-boot.enable || config.boot.loader.efi.canTouchEfiVariables); </ins> virtualisation.pathsInNixDB = [ config.system.build.toplevel ]; # FIXME: Consolidate this one day.
Code change:
Describe the bug on a NixOS configuration with systemd-boot as bootloader (the default for NixOS installs on UEFI systems) fails with this error: I checked that the file exists, so what's missing in the kernel since it reports "No such device"? Steps to reproduce This happens with nixos-20.09 and nixos-unstable, but not nixos-20.03. (Just change the command above.) Expected behavior The build succeeds, like it did before (on nixos-20.03). Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata Please run and paste the result. Maintainer information:
Disabling ~systemd-boot~ efi settings from results in So the insmod error is the same, but now the init script doesn't die on
Ah, the default value of is , and with that value it actually succeeds. So it's not really the systemd-boot part of the config that is broken.
Oh, this comment recommends NOT to set , because it can wear out the NVRAM:
Ah, the default value of is false, [...] Well, except that sets it to true, so it is enabled by default for NixOS EFI installs.
Interestingly, the uses . That results in success!
Now the question is, where to set (or )? I see at least these places where conditionally adding it could make sense: Call site: Option declaration, in qemu- Implementation, in qemu- In the systemd- module:

Related discussion:
text: let common = { virtualisation.useBootLoader = true; <del> virtualisation.useEFIBoot = true; </del> boot.loader.systemd-boot.enable = true; boot.loader.efi.canTouchEfiVariables = true; environment.systemPackages = [ pkgs.efibootmgr ];
Code change:
current version: unstable-2017-10-06 desired version: 0.2.0 maintainers:
An option in the service definition to overwrite the package would be nice, too! :smile:
Why is this needed? -options are usually implemented if modifying the package in question with an overlay is a bad idea because it would mean that a lot of leaf-packages would require a rebuild as well. An example for that would be .
Ah, okay.
could you please update this package?
Oh sure, thank you for the ping :)

Related discussion:
text: Based on <xref linkend="opt-system.stateVersion" />, existing installations will continue to work. </para> </listitem> <ins> <listitem> <para> The prometheus json exporter is now managed by the prometheus community. Together with additional features some backwards incompatibilities were introduced. Most importantly the exporter no longer accepts a fixed command-line parameter to specify the URL of the endpoint serving JSON. It now expects this URL to be passed as an URL parameter, when scraping the exporter's <literal>/probe</literal> endpoint. In the prometheus scrape configuration the scrape target might look like this: <programlisting> http://some.json-exporter.host:7979/probe?target=https://example.com/some/json/endpoint </programlisting> </para> <para> Existing configuration for the exporter needs to be updated, but can partially be re-used. Documentation is available in the upstream repository and a small example for NixOS is available in the corresponding NixOS test. </para> <para> These changes also affect <xref linkend="opt-services.prometheus.exporters.rspamd.enable" />, which is just a preconfigured instance of the json exporter. </para> <para> For more information, take a look at the <link xlink:href="https://github.com/prometheus-community/json_exporter"> official documentation</link> of the json_exporter. </para> </listitem> </ins> </itemizedlist> </section>