jiebi/CodeConvo huggingface dataset:
Code change:
Describe the bug I'm on a mission to get (and thence ) compiling on M1 Macs, and having fixed , the next stumbling block is 4.1.1. Sadly, the build fails with , presumably related to . To Reproduce Steps to reproduce the behavior: Expected behavior A clear and concise description of what you expected to happen. Screenshots Additional context This works fine when built for x8664 on the same machine. 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 system: host os: multi-user?: sandbox: version: channels(steve): nixpkgs: Maintainer information:
Submitted PR which disables Fortran support for OpenMPI on aarch64-darwin. Would that fix the issue for you or do you require Fortran?
This seems to be the build failure:
I actually have no idea if I require Fortran. I mean, presumably it's enabled for some reason, so I'm a little wary of disabling it on only one platform/arch combination: that feels like an atypical workaround.
To reproduce: I wonder if the gcc maintainers can offer any insight?
seems to hint at the stack-protector hardening, so perhaps something like could work around that? (no idea what's the real cause though, and I have no Darwin machine at hand)
You were right! Sent a PR in

Related discussion:
text: find -name "Makefile.in" -exec sed -i "s/`date`/$ts/" {} ; ''; <del> buildInputs = with stdenv; [ gfortran zlib ] ++ lib.optionals isLinux [ libnl numactl pmix ucx ] </del> <ins> buildInputs = [ zlib ] ++ lib.optionals fortranSupport [ gfortran ] ++ lib.optionals stdenv.isLinux [ libnl numactl pmix ucx ] </ins> ++ lib.optionals cudaSupport [ cudatoolkit ] ++ [ libevent hwloc ] <del> ++ lib.optional (isLinux || isFreeBSD) rdma-core </del> <ins> ++ lib.optional (stdenv.isLinux || stdenv.isFreeBSD) rdma-core </ins> ++ lib.optional fabricSupport [ libpsm2 libfabric ]; nativeBuildInputs = [ perl ]; <del> configureFlags = with stdenv; lib.optional (!cudaSupport) "--disable-mca-dso" ++ lib.optionals isLinux  [ </del> <ins> configureFlags = lib.optional (!cudaSupport) "--disable-mca-dso" ++ lib.optional (!fortranSupport) "--disable-mpi-fortran" ++ lib.optionals stdenv.isLinux  [ </ins> "--with-libnl=${libnl.dev}" "--with-pmix=${pmix}" "--with-pmix-libdir=${pmix}/lib"
Code change:
Describe the bug I'm on a mission to get (and thence ) compiling on M1 Macs, and having fixed , the next stumbling block is 4.1.1. Sadly, the build fails with , presumably related to . To Reproduce Steps to reproduce the behavior: Expected behavior A clear and concise description of what you expected to happen. Screenshots Additional context This works fine when built for x8664 on the same machine. 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 system: host os: multi-user?: sandbox: version: channels(steve): nixpkgs: Maintainer information:
Submitted PR which disables Fortran support for OpenMPI on aarch64-darwin. Would that fix the issue for you or do you require Fortran?
This seems to be the build failure:
I actually have no idea if I require Fortran. I mean, presumably it's enabled for some reason, so I'm a little wary of disabling it on only one platform/arch combination: that feels like an atypical workaround.
To reproduce: I wonder if the gcc maintainers can offer any insight?
seems to hint at the stack-protector hardening, so perhaps something like could work around that? (no idea what's the real cause though, and I have no Darwin machine at hand)
You were right! Sent a PR in

Related discussion:
text: sed -i 's:compiler=.*:compiler=${targetPackages.stdenv.cc}/bin/${targetPackages.stdenv.cc.targetPrefix}c++:'  $out/share/openmpi/mpic++-wrapper-data.txt <ins> '' + lib.optionalString fortranSupport '' </ins> sed -i 's:compiler=.*:compiler=${gfortran}/bin/${gfortran.targetPrefix}gfortran:'   $out/share/openmpi/mpifort-wrapper-data.txt
Code change:
Describe the bug I'm on a mission to get (and thence ) compiling on M1 Macs, and having fixed , the next stumbling block is 4.1.1. Sadly, the build fails with , presumably related to . To Reproduce Steps to reproduce the behavior: Expected behavior A clear and concise description of what you expected to happen. Screenshots Additional context This works fine when built for x8664 on the same machine. 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 system: host os: multi-user?: sandbox: version: channels(steve): nixpkgs: Maintainer information:
Submitted PR which disables Fortran support for OpenMPI on aarch64-darwin. Would that fix the issue for you or do you require Fortran?
This seems to be the build failure:
I actually have no idea if I require Fortran. I mean, presumably it's enabled for some reason, so I'm a little wary of disabling it on only one platform/arch combination: that feels like an atypical workaround.
To reproduce: I wonder if the gcc maintainers can offer any insight?
seems to hint at the stack-protector hardening, so perhaps something like could work around that? (no idea what's the real cause though, and I have no Darwin machine at hand)
You were right! Sent a PR in

Related discussion:
text: # fails to configure on darwin due to gmp not found configureFlags = [ "LIBS=-L${gmp}/lib" "CXXFLAGS=-I${gmp.dev}/include" ]; <del> # disable stackprotector on aarch64-darwin for now # https://github.com/NixOS/nixpkgs/issues/127608 hardeningDisable = lib.optionals (stdenv.isAarch64 && stdenv.isDarwin) [ "stackprotector" ]; </del> postPatch = '' sed -e "s@ /bin/bash@bash@g" -i Makefile.std find . -exec sed -e "s@/usr/bin/perl@${perl}/bin/perl@g" -i '{}' ';'
Code change:
Describe the bug I'm on a mission to get (and thence ) compiling on M1 Macs, and having fixed , the next stumbling block is 4.1.1. Sadly, the build fails with , presumably related to . To Reproduce Steps to reproduce the behavior: Expected behavior A clear and concise description of what you expected to happen. Screenshots Additional context This works fine when built for x8664 on the same machine. 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 system: host os: multi-user?: sandbox: version: channels(steve): nixpkgs: Maintainer information:
Submitted PR which disables Fortran support for OpenMPI on aarch64-darwin. Would that fix the issue for you or do you require Fortran?
This seems to be the build failure:
I actually have no idea if I require Fortran. I mean, presumably it's enabled for some reason, so I'm a little wary of disabling it on only one platform/arch combination: that feels like an atypical workaround.
To reproduce: I wonder if the gcc maintainers can offer any insight?
seems to hint at the stack-protector hardening, so perhaps something like could work around that? (no idea what's the real cause though, and I have no Darwin machine at hand)
You were right! Sent a PR in

Related discussion:
text: install_name_tool -change libblas.dylib ${blas}/lib/libblas.dylib $out/lib/libarpack.dylib ''; <del> # disable stackprotector on aarch64-darwin for now # https://github.com/NixOS/nixpkgs/issues/127608 hardeningDisable = lib.optionals (stdenv.isAarch64 && stdenv.isDarwin) [ "stackprotector" ]; </del> meta = { homepage = "https://github.com/opencollab/arpack-ng"; description = ''
Code change:
Describe the bug I'm on a mission to get (and thence ) compiling on M1 Macs, and having fixed , the next stumbling block is 4.1.1. Sadly, the build fails with , presumably related to . To Reproduce Steps to reproduce the behavior: Expected behavior A clear and concise description of what you expected to happen. Screenshots Additional context This works fine when built for x8664 on the same machine. 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 system: host os: multi-user?: sandbox: version: channels(steve): nixpkgs: Maintainer information:
Submitted PR which disables Fortran support for OpenMPI on aarch64-darwin. Would that fix the issue for you or do you require Fortran?
This seems to be the build failure:
I actually have no idea if I require Fortran. I mean, presumably it's enabled for some reason, so I'm a little wary of disabling it on only one platform/arch combination: that feels like an atypical workaround.
To reproduce: I wonder if the gcc maintainers can offer any insight?
seems to hint at the stack-protector hardening, so perhaps something like could work around that? (no idea what's the real cause though, and I have no Darwin machine at hand)
You were right! Sent a PR in

Related discussion:
text: )] ; <del> # disable stackprotector on aarch64-darwin for now # https://github.com/NixOS/nixpkgs/issues/127608 # # build error: # # /private/tmp/nix-build-sundials-6.3.0.drv-0/ccD2dUtR.s:21:15: error: index must be an integer in range [-256, 255]. #         ldr     x0, [x0, ___stack_chk_guard];momd #                          ^ # /private/tmp/nix-build-sundials-6.3.0.drv-0/ccD2dUtR.s:46:15: error: index must be an integer in range [-256, 255]. #         ldr     x0, [x0, ___stack_chk_guard];momd # # See also a proposed solution: https://github.com/NixOS/nixpkgs/pull/151983 hardeningDisable = lib.optionals (stdenv.isAarch64 && stdenv.isDarwin) [ "stackprotector" ]; </del> doCheck = true; checkTarget = "test";
Code change:
This tracks the conversion of from DocBook to CommonMark per . here that you intend to work on this. (Please also post if you stop working on this.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections in the NixOS and Nixpkgs manual for inspiration. the CommonMark back to DocBook xml with: from nixpkgs root dir with: a preview server with: your work at on steps 5-9. it looks good, commit both the new file and the generated file, submit a PR and reference this issue.

Related discussion:
text: <ins> # Adding Custom Packages {#sec-custom-packages} It's possible that a package you need is not available in NixOS. In that case, you can do two things. First, you can clone the Nixpkgs repository, add the package to your clone, and (optionally) submit a patch or pull request to have it accepted into the main Nixpkgs repository. This is described in detail in the [Nixpkgs manual](https://nixos.org/nixpkgs/manual). In short, you clone Nixpkgs: ```ShellSession $ git clone https://github.com/NixOS/nixpkgs $ cd nixpkgs ``` Then you write and test the package as described in the Nixpkgs manual. Finally, you add it to [](#opt-environment.systemPackages), e.g. ```nix environment.systemPackages = [ pkgs.my-package ]; ``` and you run `nixos-rebuild`, specifying your own Nixpkgs tree: ```ShellSession # nixos-rebuild switch -I nixpkgs=/path/to/my/nixpkgs ``` The second possibility is to add the package outside of the Nixpkgs tree. For instance, here is how you specify a build of the [GNU Hello](https://www.gnu.org/software/hello/) package directly in `configuration.nix`: ```nix environment.systemPackages = let my-hello = with pkgs; stdenv.mkDerivation rec { name = "hello-2.8"; src = fetchurl { url = "mirror://gnu/hello/${name}.tar.gz"; sha256 = "0wqd8sjmxfskrflaxywc7gqw7sfawrfvdxd9skxawzfgyy0pzdz6"; }; }; in [ my-hello ]; ``` Of course, you can also move the definition of `my-hello` into a separate Nix expression, e.g. ```nix environment.systemPackages = [ (import ./my-hello.nix) ]; ``` where `my-hello.nix` contains: ```nix with import <nixpkgs> {}; # bring all of Nixpkgs into scope stdenv.mkDerivation rec { name = "hello-2.8"; src = fetchurl { url = "mirror://gnu/hello/${name}.tar.gz"; sha256 = "0wqd8sjmxfskrflaxywc7gqw7sfawrfvdxd9skxawzfgyy0pzdz6"; }; } ``` This allows testing the package easily: ```ShellSession $ nix-build my-hello.nix $ ./result/bin/hello Hello, world! ``` </ins>
Code change:
This tracks the conversion of from DocBook to CommonMark per . here that you intend to work on this. (Please also post if you stop working on this.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections in the NixOS and Nixpkgs manual for inspiration. the CommonMark back to DocBook xml with: from nixpkgs root dir with: a preview server with: your work at on steps 5-9. it looks good, commit both the new file and the generated file, submit a PR and reference this issue.

Related discussion:
text: <del> <section xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xi="http://www.w3.org/2001/XInclude" version="5.0" xml:id="sec-custom-packages"> <title>Adding Custom Packages</title> <para> It’s possible that a package you need is not available in NixOS. In that case, you can do two things. First, you can clone the Nixpkgs repository, add the package to your clone, and (optionally) submit a patch or pull request to have it accepted into the main Nixpkgs repository. This is described in detail in the <link xlink:href="https://nixos.org/nixpkgs/manual">Nixpkgs manual</link>. In short, you clone Nixpkgs: <screen> <prompt>$ </prompt>git clone https://github.com/NixOS/nixpkgs <prompt>$ </prompt>cd nixpkgs </screen> Then you write and test the package as described in the Nixpkgs manual. Finally, you add it to <literal>environment.systemPackages</literal>, e.g. <programlisting> <xref linkend="opt-environment.systemPackages"/> = [ pkgs.my-package ]; </programlisting> and you run <command>nixos-rebuild</command>, specifying your own Nixpkgs tree: <screen> <prompt># </prompt>nixos-rebuild switch -I nixpkgs=/path/to/my/nixpkgs</screen> </para> <para> The second possibility is to add the package outside of the Nixpkgs tree. For instance, here is how you specify a build of the <link xlink:href="https://www.gnu.org/software/hello/">GNU Hello</link> package directly in <filename>configuration.nix</filename>: <programlisting> <xref linkend="opt-environment.systemPackages"/> = let my-hello = with pkgs; stdenv.mkDerivation rec { name = "hello-2.8"; src = fetchurl { url = "mirror://gnu/hello/${name}.tar.gz"; sha256 = "0wqd8sjmxfskrflaxywc7gqw7sfawrfvdxd9skxawzfgyy0pzdz6"; }; }; in [ my-hello ]; </programlisting> Of course, you can also move the definition of <literal>my-hello</literal> into a separate Nix expression, e.g. <programlisting> <xref linkend="opt-environment.systemPackages"/> = [ (import ./my-hello.nix) ]; </programlisting> where <filename>my-hello.nix</filename> contains: <programlisting> with import &lt;nixpkgs> {}; # bring all of Nixpkgs into scope stdenv.mkDerivation rec { name = "hello-2.8"; src = fetchurl { url = "mirror://gnu/hello/${name}.tar.gz"; sha256 = "0wqd8sjmxfskrflaxywc7gqw7sfawrfvdxd9skxawzfgyy0pzdz6"; }; } </programlisting> This allows testing the package easily: <screen> <prompt>$ </prompt>nix-build my-hello.nix <prompt>$ </prompt>./result/bin/hello Hello, world! </screen> </para> </section> </del>
Code change:
This tracks the conversion of from DocBook to CommonMark per . here that you intend to work on this. (Please also post if you stop working on this.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections in the NixOS and Nixpkgs manual for inspiration. the CommonMark back to DocBook xml with: from nixpkgs root dir with: a preview server with: your work at on steps 5-9. it looks good, commit both the new file and the generated file, submit a PR and reference this issue.

Related discussion:
text: <command>nixos-rebuild switch</command>. </para> <del> <xi:include href="customizing-packages.xml" /> </del> <ins> <xi:include href="../from_md/configuration/customizing-packages.section.xml" /> </ins> <del> <xi:include href="adding-custom-packages.xml" /> </del> <ins> <xi:include href="../from_md/configuration/adding-custom-packages.section.xml" /> </ins> </section>
Code change:
This tracks the conversion of from DocBook to CommonMark per . here that you intend to work on this. (Please also post if you stop working on this.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections in the NixOS and Nixpkgs manual for inspiration. the CommonMark back to DocBook xml with: from nixpkgs root dir with: a preview server with: your work at on steps 5-9. it looks good, commit both the new file and the generated file, submit a PR and reference this issue.

Related discussion:
text: <ins> <section xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xml:id="sec-custom-packages"> <title>Adding Custom Packages</title> <para> It’s possible that a package you need is not available in NixOS. In that case, you can do two things. First, you can clone the Nixpkgs repository, add the package to your clone, and (optionally) submit a patch or pull request to have it accepted into the main Nixpkgs repository. This is described in detail in the <link xlink:href="https://nixos.org/nixpkgs/manual">Nixpkgs manual</link>. In short, you clone Nixpkgs: </para> <programlisting> $ git clone https://github.com/NixOS/nixpkgs $ cd nixpkgs </programlisting> <para> Then you write and test the package as described in the Nixpkgs manual. Finally, you add it to <xref linkend="opt-environment.systemPackages" />, e.g. </para> <programlisting language="bash"> environment.systemPackages = [ pkgs.my-package ]; </programlisting> <para> and you run <literal>nixos-rebuild</literal>, specifying your own Nixpkgs tree: </para> <programlisting> # nixos-rebuild switch -I nixpkgs=/path/to/my/nixpkgs </programlisting> <para> The second possibility is to add the package outside of the Nixpkgs tree. For instance, here is how you specify a build of the <link xlink:href="https://www.gnu.org/software/hello/">GNU Hello</link> package directly in <literal>configuration.nix</literal>: </para> <programlisting language="bash"> environment.systemPackages = let my-hello = with pkgs; stdenv.mkDerivation rec { name = &quot;hello-2.8&quot;; src = fetchurl { url = &quot;mirror://gnu/hello/${name}.tar.gz&quot;; sha256 = &quot;0wqd8sjmxfskrflaxywc7gqw7sfawrfvdxd9skxawzfgyy0pzdz6&quot;; }; }; in [ my-hello ]; </programlisting> <para> Of course, you can also move the definition of <literal>my-hello</literal> into a separate Nix expression, e.g. </para> <programlisting language="bash"> environment.systemPackages = [ (import ./my-hello.nix) ]; </programlisting> <para> where <literal>my-hello.nix</literal> contains: </para> <programlisting language="bash"> with import &lt;nixpkgs&gt; {}; # bring all of Nixpkgs into scope stdenv.mkDerivation rec { name = &quot;hello-2.8&quot;; src = fetchurl { url = &quot;mirror://gnu/hello/${name}.tar.gz&quot;; sha256 = &quot;0wqd8sjmxfskrflaxywc7gqw7sfawrfvdxd9skxawzfgyy0pzdz6&quot;; }; } </programlisting> <para> This allows testing the package easily: </para> <programlisting> $ nix-build my-hello.nix $ ./result/bin/hello Hello, world! </programlisting> </section> </ins>
Code change:
has two forms of input for the field. and . I personally use the latter as it is the output of and better than having cleartext passphrases. (This also works with a random AES key - so long that it is shared) The current implementation lacks the distinction and only works with passphrases. I believe this should be .

Related discussion:
text: ${optionalString cfg.userControlled.enable '' ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=${cfg.userControlled.group} update_config=1''} <del> ${concatStringsSep "n" (mapAttrsToList (ssid: networkConfig: '' </del> <ins> ${concatStringsSep "n" (mapAttrsToList (ssid: networkConfig: let psk = if networkConfig.psk != null then ''"${networkConfig.psk}"'' else networkConfig.pskRaw; in '' </ins> network={ ssid="${ssid}" <del> ${optionalString (networkConfig.psk != null) ''psk="${networkConfig.psk}"''} ${optionalString (networkConfig.psk == null) ''key_mgmt=NONE''} </del> <ins> ${optionalString (psk != null) ''psk=${psk}''} ${optionalString (psk == null) ''key_mgmt=NONE''} </ins> } '') cfg.networks)} '' else "/etc/wpa_supplicant.conf";
Code change:
has two forms of input for the field. and . I personally use the latter as it is the output of and better than having cleartext passphrases. (This also works with a random AES key - so long that it is shared) The current implementation lacks the distinction and only works with passphrases. I believe this should be .

Related discussion:
text: Be aware that these will be written to the nix store in plaintext! <ins> Mutually exclusive with <varname>pskRaw</varname>. ''; }; pskRaw = mkOption { type = types.nullOr types.str; default = null; description = '' The network's pre-shared key in hex defaulting to being a network without any authentication. Mutually exclusive with <varname>psk</varname>. </ins> ''; }; };
Code change:
has two forms of input for the field. and . I personally use the latter as it is the output of and better than having cleartext passphrases. (This also works with a random AES key - so long that it is shared) The current implementation lacks the distinction and only works with passphrases. I believe this should be .

Related discussion:
text: config = mkMerge [ (mkIf cfg.enable { <ins> assertions = flip mapAttrsToList cfg.networks (name: cfg: { assertion = cfg.psk == null || cfg.pskRaw == null; message = ''networking.wireless."${name}".psk and networking.wireless."${name}".pskRaw are mutually exclusive''; }); </ins> environment.systemPackages =  [ pkgs.wpa_supplicant ]; services.dbus.packages = [ pkgs.wpa_supplicant ];
Code change:
Project description
I marked this as stale due to inactivity. &rarr;
ping! Is this still an issue?
has been The command still does not have documentation in the Nixpkgs manual.
Is satisfying? Could use approval to get merged.
It's a good step, but it doesn't (yet?) tell me what the options are.
Now it does.

Related discussion:
text: source $stdenv/setup ``` <del> to let `stdenv` set up the environment (e.g., process the `buildInputs`). If you want, you can still use `stdenv`’s generic builder: </del> <ins> to let `stdenv` set up the environment (e.g. by resetting `PATH` and populating it from build inputs). If you want, you can still use `stdenv`’s generic builder: </ins> ```bash source $stdenv/setup
Code change:
Project description
I marked this as stale due to inactivity. &rarr;
ping! Is this still an issue?
has been The command still does not have documentation in the Nixpkgs manual.
Is satisfying? Could use approval to get merged.
It's a good step, but it doesn't (yet?) tell me what the options are.
Now it does.

Related discussion:
text: ### The fixup phase {#ssec-fixup-phase} <del> The fixup phase performs some (Nix-specific) post-processing actions on the files installed under `$out` by the install phase. The default `fixupPhase` does the following: </del> <ins> The fixup phase performs (Nix-specific) post-processing actions on the files installed under `$out` by the install phase. The default `fixupPhase` does the following: </ins> - It moves the `man/`, `doc/` and `info/` subdirectories of `$out` to `share/`. - It strips libraries and executables of debug information. - On Linux, it applies the `patchelf` command to ELF executables and libraries to remove unused directories from the `RPATH` in order to prevent unnecessary runtime dependencies. <del> - It rewrites the interpreter paths of shell scripts to paths found in `PATH`. E.g., `/usr/bin/perl` will be rewritten to `/nix/store/some-perl/bin/perl` found in `PATH`. </del> <ins> - It rewrites the interpreter paths of shell scripts to paths found in `PATH`. E.g., `/usr/bin/perl` will be rewritten to `/nix/store/some-perl/bin/perl` found in `PATH`. See [](#patch-shebangs.sh) for details. </ins> #### Variables controlling the fixup phase {#variables-controlling-the-fixup-phase}