jiebi/CodeConvo huggingface dataset:
Code change:
python27Packages.faulthandler fails to build on the unstable channel Cc () The output shows test failures due to regular expressions not matching. E.g. It seems that the tests are expecting to see in the message, while the actual error says . If it's just that, I hope that it would be easy to fix the build. I am happy to help if given some guidance. Full output: host os: multi-user?: sandbox: version: channels(root): channels(user): nixpkgs:
This is an upstream issue. See similar issue Best write them that they should also accept , , etc. Then you can open a PR here that adds a patch to the derivation.
Thanks, will look into that. It probably makes sense to keep this issue open to track the upstream one though.
Note that a patch is available ( ), it may make sense to apply it (e.g. done for Fedora ) while waiting for a new release. I am still happy to try and do that.
I don't think that patch will work. It accepts but not .
Sorry, I missed that :(
I opened an upstream PR: And I applied the patch in Nixpkgs:
fyi has now been merged and a release is pending (see )... hopefully we won't need the patch after that. Thanks everyone for your work!
I removed the patches in .

Related discussion:
text: sha256 = "acc10e10909f0f956ba1b42b6c450ea0bdaaa27b3942899f65931396cfcdd36a"; }; <ins> patches = [ (fetchpatch { url = https://github.com/vstinner/faulthandler/commit/67b661e.patch; sha256 = "1nn8c9nq5qypja949hzz0n4yprsyr63wihf5g3gwrinm2nkjnnv7"; }) (fetchpatch { url = https://github.com/vstinner/faulthandler/commit/07cbb7b.patch; sha256 = "0fh6rjyjw7z1hsiy3sgdc8j9mncg1vlv3y0h4bplqyw18vq3srb3"; }) ]; </ins> meta = { description = "Dump the Python traceback"; license = stdenv.lib.licenses.bsd2;
Code change:
Steps to reproduce the behavior: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hydra can reproduce:
I tracked down the potential source of this failure, and am working on a fix. These builds take 30 minutes for me though, so it's slow going.
Please see for a fix. Testing appreciated.
Thanks for the quick patch. EDIT: My way of installing to profile didn't pull the fix, I'll see if I can figure out a way to do it properly using the pr review package
Builds and runs... seg faults as soon as I load a model, but that's an AMD driver thing (whole WM crashes)... Ship it :laughing:
I did see some segfaults, but was able to restart and get it to load on my 6700xt. “Glad” to know it’s known and common.
Nice! Thanks for this - excited to see it roll into unstable soon. Ollama seems to always have some issue - is there a "working group" that has some focus on this program and nix? Anyway, thanks again!
The problems with crashing aren't nix problems, they're crappy amd driver issues. It doesn't crash if you don't load models close to the max vram available... obviously it shouldn't crash if you do, but amd... so yeah

Related discussion:
text: # this also disables necessary patches contained in `ollama/llm/patches/` # those patches are applied in `postPatch` ./disable-git.patch <ins> # we provide our own deps at runtime ./skip-rocm-cp.patch </ins> ]; postPatch = ''
Code change:
Steps to reproduce the behavior: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hydra can reproduce:
I tracked down the potential source of this failure, and am working on a fix. These builds take 30 minutes for me though, so it's slow going.
Please see for a fix. Testing appreciated.
Thanks for the quick patch. EDIT: My way of installing to profile didn't pull the fix, I'll see if I can figure out a way to do it properly using the pr review package
Builds and runs... seg faults as soon as I load a model, but that's an AMD driver thing (whole WM crashes)... Ship it :laughing:
I did see some segfaults, but was able to restart and get it to load on my 6700xt. “Glad” to know it’s known and common.
Nice! Thanks for this - excited to see it roll into unstable soon. Ollama seems to always have some issue - is there a "working group" that has some focus on this program and nix? Anyway, thanks again!
The problems with crashing aren't nix problems, they're crappy amd driver issues. It doesn't crash if you don't load models close to the max vram available... obviously it shouldn't crash if you do, but amd... so yeah

Related discussion:
text: <ins> diff --git a/llm/generate/gen_linux.sh b/llm/generate/gen_linux.sh index 48d08fd0..e50f7b36 100755 --- a/llm/generate/gen_linux.sh +++ b/llm/generate/gen_linux.sh @@ -284,9 +284,6 @@ if [ -z "${OLLAMA_SKIP_ROCM_GENERATE}" -a -d "${ROCM_PATH}" ]; then mkdir -p "${ROCM_DIST_DIR}" for dep in $(ldd "${BUILD_DIR}/bin/ollama_llama_server" | grep "=>" | cut -f2 -d= | cut -f2 -d' ' | grep -v "${GOARCH}/rocm${ROCM_VARIANT}" | grep -e rocm -e amdgpu -e libtinfo -e libnuma -e libelf ); do cp -a "${dep}"* "${ROCM_DIST_DIR}" -        if [ $(readlink -f "${dep}") != "${dep}" ] ; then -            cp $(readlink -f "${dep}") "${ROCM_DIST_DIR}" -        fi done install dist </ins>
Code change:
It would be nice to see packaged such that at least an executable is exposed.
How about doing it yourself? Have a look at the and at the many examples in If you have questions, just ask them in this thread.

Related discussion:
text: <ins> { python, stdenv }: with python.pkgs; buildPythonApplication rec { pname = "chkcrontab"; version = "1.7"; src = fetchPypi { inherit pname version; sha256 = "0gmxavjkjkvjysgf9cf5fcpk589gb75n1mn20iki82wifi1pk1jn"; }; meta = with stdenv.lib; { description = "A tool to detect crontab errors"; license = licenses.asl20; maintainers = with maintainers; [ ma27 ]; homepage = https://github.com/lyda/chkcrontab; }; } </ins>
Code change:
It would be nice to see packaged such that at least an executable is exposed.
How about doing it yourself? Have a look at the and at the many examples in If you have questions, just ask them in this thread.

Related discussion:
text: container-linux-config-transpiler = callPackage ../development/tools/container-linux-config-transpiler { }; <ins> chkcrontab = callPackage ../tools/admin/chkcrontab { }; </ins> djmount = callPackage ../tools/filesystems/djmount { }; dgsh = callPackage ../shells/dgsh { };
Code change:
fails with the following error since #diff-: on master The systemd build system changed to meson but the systemd-cryptsetup-generator was not updated.

Related discussion:
text: outputs = [ "out" ]; buildPhase = '' <del> make $makeFlags built-sources make $makeFlags systemd-cryptsetup make $makeFlags systemd-cryptsetup-generator </del> <ins> ninja systemd-cryptsetup systemd-cryptsetup-generator </ins> ''; <del> # For some reason systemd-cryptsetup-generator is a wrapper-script # with the current release of systemd. We want the real one. # TODO: Remove `.libs` prefix when the wrapper-script is gone </del> installPhase = '' mkdir -p $out/lib/systemd/ <del> cp .libs/systemd-cryptsetup $out/lib/systemd/systemd-cryptsetup cp .libs/*.so $out/lib/ </del> <ins> cp systemd-cryptsetup $out/lib/systemd/systemd-cryptsetup cp src/shared/*.so $out/lib/systemd/ </ins> mkdir -p $out/lib/systemd/system-generators/ <del> cp .libs/systemd-cryptsetup-generator $out/lib/systemd/system-generators/systemd-cryptsetup-generator </del> <ins> cp systemd-cryptsetup-generator $out/lib/systemd/system-generators/systemd-cryptsetup-generator </ins> ''; })
Code change:
Neomutt's bundled tool is unable to find . We should probably replace that string in the perl script. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:

Related discussion:
text: enableParallelBuilding = true; postPatch = '' <ins> substituteInPlace contrib/smime_keys  --replace /usr/bin/openssl ${openssl}/bin/openssl </ins> for f in doc/*.{xml,xsl}*  ; do substituteInPlace $f  --replace http://docbook.sourceforge.net/release/xsl/current     ${docbook_xsl}/share/xml/docbook-xsl
Code change:
I have a Samsung M2022W (usb) that works on a raspberrypi using raspbian (2017-11-29-raspbian-stretch-). I had to pick the ML-2160 driver in CUPS 2.2.1 as recommended by On NixOS (cups-2.2.2): [nawal nix-info system: "x8664-linux", multi-user?: yes, version: nix-env (Nix) 1.11.16, channels(nawal): "nixos-17.03-17.03.1082.", channels(root): "nixos-17.09.3149.", nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs If I use services.printing = { enable = true; drivers = [ pkgs.samsungUnifiedLinuxDriver ]; extraConf = '' LogLevel debug ''; extraFilesConf = '' FileDevice yes ''; }; and pick the same driver, I get garbage printed out. I tried to track down the ppd on raspbian, but only found: pi $ grep 2160 /usr/share/cups/drv/splix- ModelName "ML-2160" PCFileName "" and (i.e. it generated the ppd when I installed the printer apparently). On nixos: [nawal | grep 2160 /nix/store/6f2zx8dl4w0kzgw3wj8f466mvkcgc3dc-samsung-UnifiedLinuxDriver-4.00.39/opt/share/ppd/ML- /nix/store/nmp023llc8fix567f413a5rqbx4sw45g-cups-progs/share/cups/model/ML- Having diffed them, I notice amongst a huge number of differences: [nawal diff /nix/store/nmp023llc8fix567f413a5rqbx4sw45g-cups-progs/share/cups/model/ML- | grep Version < FileVersion: "2.0.0" < PSVersion: "(3010.000) 0" < QPDL QPDLVersion: "3" < *cupsVersion: 2.2 so raspbian is using a version "2.0.0" and "2.2" of something or other, whereas nixos is using a version "1.2" and "1.1" of similar things. I managed to get my printer to work by copying the ppd across, but I don't understand enough of cups (nor now have the inclination to learn) to figure out what's going on or how to make nixos do the right thing (i.e. in a word, print). I thought this might be useful for someone else who wants to pick it up? Happy to hack around the raspbian if you need more info, or try out things if you need me to while the sd card contains raspbian.
Can you find out what package on Raspbian provides the driver? Have you installed proprietary Samsung driver there? If not, can you try removing ? It seems we have latest version of but not the latest of the proprietary driver but you don't seem to use it.
I'll have a look tomorrow evening - how do i use the new splix without upgrading everything to the same commit?
Find out your current commit with (look at the suffix), then clone nixpkgs repository (), checkout current commit (), fetch my changes () and cherry-pick my patch atop your current commit (). Then you can rebuild nixpkgs with .
I can confirm this works. Thanks for the detailed instructions and for fixing it so quickly! NB: I had to do: (i.e. ) thanks

Related discussion:
text: <del> { stdenv, fetchsvn, fetchurl, cups, zlib }: </del> <ins> { stdenv, fetchsvn, cups, zlib, jbigkit }: </ins> let rev = "315"; in stdenv.mkDerivation rec { name = "splix-svn-${rev}"; src = fetchsvn { # We build this from svn, because splix hasn't been in released in several years # although the community has been adding some new printer models.
Code change:
When the user of the SSH connection used by the SSH substituter does not have a shell configured it defaults to , which causes the following error: Which actually is the decimal representation of the first few letters of the following error reported by (thanks for figuring that out). Since with the release of Nix 2.0 it has become easy to setup a SSH substituter, so I expect that more people might run into this problem. I know of at least another that reported it on the IRC. Instead of the serialized integer error it should just have reported the actual error, or at least it should have given a more specific error about the response being bogus. Forget to set for the user of the SSH substituter connection. system: host os: multi-user?: sandbox: version: (from nixos-unstable around 5 Mar) channels(root): channels(matthijs): nixpkgs: (nixos-17.09 around 22 Feb)
I some debug echo messages to my profile scripts and I got this error as well (with a different number). To fix it, I had to remove any output from the profiles ...
Just stumbled into this too. I figured should be enough on the server part, but alas.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .
I'm 90% sure this issue is still valid.
It is.
It is.
I marked this as stale due to inactivity. &rarr;
Probably still
Made to show a better error message. But I feel that should print its message to stderr instead of stdout...
I just run into this error running
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Related discussion:
text: { stdenv, fetchurl, unzip, jdk, makeWrapper }: stdenv.mkDerivation rec { <del> name = "gradle-2.1"; </del> <ins> name = "gradle-2.2.1"; </ins> src = fetchurl { url = "http://services.gradle.org/distributions/${name}-bin.zip"; <del> sha256 = "0y7qifc61nng24zn73bdwh5d0m25dnllfiwfkyw220mblag4zviy"; </del> <ins> sha256 = "420aa50738299327b611c10b8304b749e8d3a579407ee9e755b15921d95ff418"; </ins> }; installPhase = ''
Code change:
When the user of the SSH connection used by the SSH substituter does not have a shell configured it defaults to , which causes the following error: Which actually is the decimal representation of the first few letters of the following error reported by (thanks for figuring that out). Since with the release of Nix 2.0 it has become easy to setup a SSH substituter, so I expect that more people might run into this problem. I know of at least another that reported it on the IRC. Instead of the serialized integer error it should just have reported the actual error, or at least it should have given a more specific error about the response being bogus. Forget to set for the user of the SSH substituter connection. system: host os: multi-user?: sandbox: version: (from nixos-unstable around 5 Mar) channels(root): channels(matthijs): nixpkgs: (nixos-17.09 around 22 Feb)
I some debug echo messages to my profile scripts and I got this error as well (with a different number). To fix it, I had to remove any output from the profiles ...
Just stumbled into this too. I figured should be enough on the server part, but alas.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .
I'm 90% sure this issue is still valid.
It is.
It is.
I marked this as stale due to inactivity. &rarr;
Probably still
Made to show a better error message. But I feel that should print its message to stderr instead of stdout...
I just run into this error running
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Related discussion:
text: makeWrapper ${jdk}/bin/java $out/bin/gradle  --set JAVA_HOME ${jdk}  <del> --add-flags "-classpath $out/lib/gradle-launcher-2.1.jar org.gradle.launcher.GradleMain" </del> <ins> --add-flags "-classpath $out/lib/gradle-launcher-2.2.1.jar org.gradle.launcher.GradleMain" </ins> ''; phases = "unpackPhase installPhase";
Code change:
It is an intermittent failure, see , not much we can do about it other than restarting the build. I opened an upstream issue
I've now tried doing a third build locally for this: all have failed. That doesn't seem intermittent to me.
It is succeeding for me most of the time, hydra also managed to build it in the past.
Maybe try setting ? Not sure if it will help but it has helped with some derivations in the past.
managed to reproduce it even with parallel building disabled:
Interestingly lowering parallelism is what seems to trigger the issue for me. If I build with all cores (8) it seems to get past that part of the build all the time, I'm yet to see it succeed when building with a single core.
Can confirm that low parallelism is the problem. is building successfully, which is the first time it has worked for me. That's consistent with what I've seen, not having it build successfully a single time (and it has always only used a single core).
I also got the issue when doing a nixos-rebuild on my 2-core laptop, but it succeeded on the same laptop when using nix-build, which means that all cores are available for just webkitgtk. This is the error message I got:
Would it make sense to add the stopgap fix suggested in So something like this: diff diff --git index .. --- +++ -60,6 +60,12 stdenv.mkDerivation rec { "-DENABLEGTKDOC=OFF" ]; postConfigure = '' # A stopgap for a non-deterministic build failure when using only one core # Upstream bug: ninja JavaScriptCoreForwardingHeaders WTFForwardingHeaders ''; NIXCFLAGS_COMPILE = optionalString stdenv.isDarwin " -lintl";
Open the file Add the following in line 258: add_dependencies(LLIntOffsetsExtractor JavaScriptCoreForwardingHeaders)
This will be no longer neccesary with

Related discussion:
text: patchShebangs . ''; <ins> postConfigure = '' # A stopgap for a non-deterministic build failure when using only one core # Upstream bug: https://bugs.webkit.org/show_bug.cgi?id=183788#c4 ninja JavaScriptCoreForwardingHeaders WTFForwardingHeaders ''; </ins> cmakeFlags = [ "-DPORT=GTK" "-DUSE_LIBHYPHEN=0"
Code change:
Enchant 2 (now the default) is long supported by most packages. The following packages need to be updated or removed: [x] gtkspell2 (dead): [x] xiphos: [x] subtitleeditor: [x] xneur: (contains the removal of enchant1) [x] gnome2.gtkhtml (dead): [x] gnome2.gtkhtml4 (dead): [x] gnome.gtkhtml (dead?): [x] php.extensions.enchant:
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
This issue is still relevant.
the list from is not up-to-date. e.g. is already fixed maybe we can also close it, because defaults to version 2 and to version 1.
I marked this as stale due to inactivity. &rarr;
Updated the list.
Now with xiphos merged You can thick both xiphos and gnome2.gtkhtml4 off the checklist
Pushed the enchant1 removal commit to

Related discussion:
text: <del> { lib, stdenv, fetchurl, fetchpatch, pkg-config, intltool, xorg, pcre, gst_all_1, glib , xosd, libnotify, enchant, wrapGAppsHook, gdk-pixbuf }: </del> <ins> { stdenv , lib , fetchurl , fetchpatch , autoreconfHook , intltool , pkg-config , wrapGAppsHook , enchant , gdk-pixbuf , glib , gst_all_1 , libnotify , pcre , xorg , xosd }: </ins> stdenv.mkDerivation { <del> pname = "xneur"; version = "0.20.0"; </del> <ins> pname = "xneur"; version = "0.20.0"; </ins> src = fetchurl { url = "https://github.com/AndrewCrewKuznetsov/xneur-devel/raw/f66723feb272c68f7c22a8bf0dbcafa5e3a8a5ee/dists/0.20.0/xneur_0.20.0.orig.tar.gz";
Code change:
Enchant 2 (now the default) is long supported by most packages. The following packages need to be updated or removed: [x] gtkspell2 (dead): [x] xiphos: [x] subtitleeditor: [x] xneur: (contains the removal of enchant1) [x] gnome2.gtkhtml (dead): [x] gnome2.gtkhtml4 (dead): [x] gnome.gtkhtml (dead?): [x] php.extensions.enchant:
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
This issue is still relevant.
the list from is not up-to-date. e.g. is already fixed maybe we can also close it, because defaults to version 2 and to version 1.
I marked this as stale due to inactivity. &rarr;
Updated the list.
Now with xiphos merged You can thick both xiphos and gnome2.gtkhtml4 off the checklist
Pushed the enchant1 removal commit to

Related discussion:
text: }; nativeBuildInputs = [ <del> pkg-config intltool wrapGAppsHook </del> <ins> autoreconfHook intltool pkg-config wrapGAppsHook </ins> ]; buildInputs = [ <del> xorg.libX11 xorg.libXtst pcre gst_all_1.gstreamer glib xosd xorg.libXext xorg.libXi libnotify enchant gdk-pixbuf gst_all_1.gst-plugins-base gst_all_1.gst-plugins-good </del> <ins> enchant gdk-pixbuf glib gst_all_1.gst-plugins-base gst_all_1.gst-plugins-good gst_all_1.gstreamer libnotify pcre xorg.libX11 xorg.libXext xorg.libXi xorg.libXtst xosd </ins> ]; patches = [
Code change:
Enchant 2 (now the default) is long supported by most packages. The following packages need to be updated or removed: [x] gtkspell2 (dead): [x] xiphos: [x] subtitleeditor: [x] xneur: (contains the removal of enchant1) [x] gnome2.gtkhtml (dead): [x] gnome2.gtkhtml4 (dead): [x] gnome.gtkhtml (dead?): [x] php.extensions.enchant:
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
This issue is still relevant.
the list from is not up-to-date. e.g. is already fixed maybe we can also close it, because defaults to version 2 and to version 1.
I marked this as stale due to inactivity. &rarr;
Updated the list.
Now with xiphos merged You can thick both xiphos and gnome2.gtkhtml4 off the checklist
Pushed the enchant1 removal commit to

Related discussion:
text: url = "https://salsa.debian.org/debian/xneur/-/raw/da38ad9c8e1bf4e349f5ed4ad909f810fdea44c9/debian/patches/gcc-10.patch"; sha256 = "0pc17a4sdrnrc4z7gz28889b9ywqsm5mzm6m41h67j2f5zh9k3fy"; }) <ins> (fetchpatch { name = "enchant2.patch"; url = "https://salsa.debian.org/debian/xneur/-/raw/695b0fea56cde4ff6cf0f3988218c5cb9d7ff5ae/debian/patches/enchant2.patch"; sha256 = "02a3kkfzdvs5f8dfm6j5x3jcn5j8qah9ykfymp6ffqsf4fijp65n"; }) </ins> ]; postPatch = '' <del> sed -e 's@for xosd_dir in@for xosd_dir in ${xosd} @' -i configure </del> <ins> sed -e 's@for xosd_dir in@for xosd_dir in ${xosd} @' -i configure.ac </ins> ''; meta = with lib; {