jiebi/CodeConvo huggingface dataset:
Code change:
Commit from broke haskell.compiler.ghc6102Binary haskell.compiler.ghc704Binary and therefore the packages haskell.compiler.ghc6104 haskell.compiler.ghc704 haskell.compiler.ghc722 haskell.compiler.ghc742 haskell.compiler.ghc763 which depend on them.
Please try . I test-built the binary GHCs but no further.
Aha. I relied on the update being API-compatible, but the first bootstraping steps don't recompile...
I'm test-building the whole list above.
All succeeded on x86_64-linux.

Related discussion:
text: stdenv.lib.optionalString stdenv.isLinux '' find . -type f -perm -0100  -exec patchelf --interpreter "$(cat $NIX_CC/nix-support/dynamic-linker)"  <del> --set-rpath "${ncurses.out}/lib:${gmp.out}/lib" {} ; </del> <ins> --set-rpath "${ncurses5.out}/lib:${gmp.out}/lib" {} ; </ins> sed -i "s|/usr/bin/perl|perlx00        |" ghc-${version}/ghc/stage2/build/tmp/ghc-stage2 sed -i "s|/usr/bin/gcc|gccx00        |" ghc-${version}/ghc/stage2/build/tmp/ghc-stage2 for prog in ld ar gcc strip ranlib; do
Code change:
Commit from broke haskell.compiler.ghc6102Binary haskell.compiler.ghc704Binary and therefore the packages haskell.compiler.ghc6104 haskell.compiler.ghc704 haskell.compiler.ghc722 haskell.compiler.ghc742 haskell.compiler.ghc763 which depend on them.
Please try . I test-built the binary GHCs but no further.
Aha. I relied on the update being API-compatible, but the first bootstraping steps don't recompile...
I'm test-building the whole list above.
All succeeded on x86_64-linux.

Related discussion:
text: <del> {stdenv, fetchurl, perl, ncurses, gmp, libiconv, makeWrapper}: </del> <ins> {stdenv, fetchurl, perl, ncurses5, gmp, libiconv, makeWrapper}: </ins> stdenv.mkDerivation rec { version = "7.4.2";
Code change:
Commit from broke haskell.compiler.ghc6102Binary haskell.compiler.ghc704Binary and therefore the packages haskell.compiler.ghc6104 haskell.compiler.ghc704 haskell.compiler.ghc722 haskell.compiler.ghc742 haskell.compiler.ghc763 which depend on them.
Please try . I test-built the binary GHCs but no further.
Aha. I relied on the update being API-compatible, but the first bootstraping steps don't recompile...
I'm test-building the whole list above.
All succeeded on x86_64-linux.

Related discussion:
text: # find editline/gmp. stdenv.lib.optionalString stdenv.isLinux '' mkdir -p "$out/lib" <del> ln -sv "${ncurses.out}/lib/libncurses.so" "$out/lib/libncurses${stdenv.lib.optionalString stdenv.is64bit "w"}.so.5" </del> <ins> ln -sv "${ncurses5.out}/lib/libncurses.so" "$out/lib/libncurses${stdenv.lib.optionalString stdenv.is64bit "w"}.so.5" </ins> find . -type f -perm -0100  -exec patchelf --interpreter "$(cat $NIX_CC/nix-support/dynamic-linker)"  --set-rpath "$out/lib:${gmp.out}/lib" {} ;
Code change:
Commit from broke haskell.compiler.ghc6102Binary haskell.compiler.ghc704Binary and therefore the packages haskell.compiler.ghc6104 haskell.compiler.ghc704 haskell.compiler.ghc722 haskell.compiler.ghc742 haskell.compiler.ghc763 which depend on them.
Please try . I test-built the binary GHCs but no further.
Aha. I relied on the update being API-compatible, but the first bootstraping steps don't recompile...
I'm test-building the whole list above.
All succeeded on x86_64-linux.

Related discussion:
text: { lib, stdenv, fetchurl, pkgconfig <ins> , abiVersion </ins> , mouseSupport ? false , unicode ? true , gpm }: let <del> inherit (stdenv) isDarwin; abiVersion = if isDarwin then "5" else "6"; version = if isDarwin then "5.9" else "6.0"; sha256 = if isDarwin </del> <ins> version = if abiVersion == "5" then "5.9" else "6.0"; sha256 = if abiVersion == "5" </ins> then "0fsn7xis81za62afan0vvm38bvgzg5wfmv1m86flqcj0nj7jjilh" else "0q3jck7lna77z5r42f13c4xglc7azd19pxfrjrpgp2yf615w4lgm"; in
Code change:
Commit from broke haskell.compiler.ghc6102Binary haskell.compiler.ghc704Binary and therefore the packages haskell.compiler.ghc6104 haskell.compiler.ghc704 haskell.compiler.ghc722 haskell.compiler.ghc742 haskell.compiler.ghc763 which depend on them.
Please try . I test-built the binary GHCs but no further.
Aha. I relied on the update being API-compatible, but the first bootstraping steps don't recompile...
I'm test-building the whole list above.
All succeeded on x86_64-linux.

Related discussion:
text: inherit sha256; }; <del> patches = [ ./clang.patch ]; </del> <ins> patches = [ ./clang.patch ] ++ lib.optional (abiVersion == "5" && stdenv.cc.isGNU) ./gcc-5.patch; </ins> outputs = [ "dev" "out" "man" ]; setOutputFlags = false; # some aren't supported
Code change:
Commit from broke haskell.compiler.ghc6102Binary haskell.compiler.ghc704Binary and therefore the packages haskell.compiler.ghc6104 haskell.compiler.ghc704 haskell.compiler.ghc722 haskell.compiler.ghc742 haskell.compiler.ghc763 which depend on them.
Please try . I test-built the binary GHCs but no further.
Aha. I relied on the update being API-compatible, but the first bootstraping steps don't recompile...
I'm test-building the whole list above.
All succeeded on x86_64-linux.

Related discussion:
text: <ins> https://bugs.gentoo.org/545114 extracted from the upstream change (which had many unrelated commits in one) From 97bb4678dc03e753290b39bbff30ba2825df9517 Mon Sep 17 00:00:00 2001 From: "Thomas E. Dickey" <dickey@invisible-island.net> Date: Sun, 7 Dec 2014 03:10:09 +0000 Subject: [PATCH] ncurses 5.9 - patch 20141206 + modify MKlib_gen.sh to work around change in development version of gcc introduced here: https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02185.html https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00236.html (reports by Marcus Shawcroft, Maohui Lei). diff --git a/ncurses/base/MKlib_gen.sh b/ncurses/base/MKlib_gen.sh index d8cc3c9..b91398c 100755 --- a/ncurses/base/MKlib_gen.sh +++ b/ncurses/base/MKlib_gen.sh @@ -474,11 +474,22 @@ sed -n -f $ED1  -e 's/gen_$//'  -e 's/  / /g' >>$TMP +cat >$ED1 <<EOF +s/  / /g +s/^ // +s/ $// +s/P_NCURSES_BOOL/NCURSES_BOOL/g +EOF + +# A patch discussed here: +#	https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02185.html +# introduces spurious #line markers.  Work around that by ignoring the system's +# attempt to define "bool" and using our own symbol here. +sed -e 's/bool/P_NCURSES_BOOL/g' $TMP > $ED2 +cat $ED2 >$TMP + $preprocessor $TMP 2>/dev/null  -| sed  -	-e 's/  / /g'  -	-e 's/^ //'  -	-e 's/_Bool/NCURSES_BOOL/g'  +| sed -f $ED1  | $AWK -f $AW2  | sed -f $ED3  | sed  </ins>
Code change:
Commit from broke haskell.compiler.ghc6102Binary haskell.compiler.ghc704Binary and therefore the packages haskell.compiler.ghc6104 haskell.compiler.ghc704 haskell.compiler.ghc722 haskell.compiler.ghc742 haskell.compiler.ghc763 which depend on them.
Please try . I test-built the binary GHCs but no further.
Aha. I relied on the update being API-compatible, but the first bootstraping steps don't recompile...
I'm test-building the whole list above.
All succeeded on x86_64-linux.

Related discussion:
text: notify-sharp = callPackage ../development/libraries/notify-sharp { }; <del> ncurses = callPackage ../development/libraries/ncurses { }; </del> <ins> ncurses5 = callPackage ../development/libraries/ncurses { abiVersion = "5"; }; ncurses6 = callPackage ../development/libraries/ncurses { abiVersion = "6"; }; ncurses = if stdenv.isDarwin then ncurses5 else ncurses6; </ins> neardal = callPackage ../development/libraries/neardal { };
Code change:
Krita fails to build with the following error Steps to reproduce the behavior: Build Krita should build. nixpkgs @
In libraw was updated. Switch to the old stable libraw020 to fix this build.
Installing kirta is showing like it's not in the cache, any idea why?
You're attempting to build the older derivation. And building it would fail. Newer binaries are available:
If you rely on channels, you might want to watch
I'm using the "" and just updated it, and I get this: So, that means the PR is not in that channel yet? If it's that, good to know, didn't know that tool.
Yes, channels that are not -small usually lag by roughly one day.

Related discussion:
text: <del> { libraw, fetchFromGitHub }: libraw.overrideAttrs (_: rec { version = "0.20.2"; src = fetchFromGitHub { owner = "LibRaw"; repo = "LibRaw"; rev = version; sha256 = "16nm4r2l5501c9zvz25pzajq5id592jhn068scjxhr8np2cblybc"; }; }) </del>
Code change:
Krita fails to build with the following error Steps to reproduce the behavior: Build Krita should build. nixpkgs @
In libraw was updated. Switch to the old stable libraw020 to fix this build.
Installing kirta is showing like it's not in the cache, any idea why?
You're attempting to build the older derivation. And building it would fail. Newer binaries are available:
If you rely on channels, you might want to watch
I'm using the "" and just updated it, and I get this: So, that means the PR is not in that channel yet? If it's that, good to know, didn't know that tool.
Yes, channels that are not -small usually lag by roughly one day.

Related discussion:
text: stdenv.mkDerivation { pname = "libraw"; <del> version = "unstable-2021-12-03"; </del> <ins> version = "0.20.2.p2"; </ins> src = fetchFromGitHub { owner = "LibRaw"; repo = "LibRaw"; <del> rev = "52b2fc52e93a566e7e05eaa44cada58e3360b6ad"; sha256 = "kW0R4iPuqnFuWYDrl46ok3kaPcGgY2MqZT7mqVX+BDQ="; </del> <ins> rev = "fedad11e87daad7b7d389a3ef84ccf10b5e84710"; # current 0.20-stable branch sha256 = "1mklf8lzybzyg75ja34822xlv6h9nw93griyrjjna7darl1dyvja"; </ins> }; outputs = [ "out" "lib" "dev" "doc" ];
Code change:
Krita fails to build with the following error Steps to reproduce the behavior: Build Krita should build. nixpkgs @
In libraw was updated. Switch to the old stable libraw020 to fix this build.
Installing kirta is showing like it's not in the cache, any idea why?
You're attempting to build the older derivation. And building it would fail. Newer binaries are available:
If you rely on channels, you might want to watch
I'm using the "" and just updated it, and I get this: So, that means the PR is not in that channel yet? If it's that, good to know, didn't know that tool.
Yes, channels that are not -small usually lag by roughly one day.

Related discussion:
text: <ins> { libraw, fetchFromGitHub }: libraw.overrideAttrs (_: rec { version = "unstable-2021-12-03"; src = fetchFromGitHub { owner = "LibRaw"; repo = "LibRaw"; rev = "52b2fc52e93a566e7e05eaa44cada58e3360b6ad"; sha256 = "kW0R4iPuqnFuWYDrl46ok3kaPcGgY2MqZT7mqVX+BDQ="; }; }) </ins>
Code change:
Krita fails to build with the following error Steps to reproduce the behavior: Build Krita should build. nixpkgs @
In libraw was updated. Switch to the old stable libraw020 to fix this build.
Installing kirta is showing like it's not in the cache, any idea why?
You're attempting to build the older derivation. And building it would fail. Newer binaries are available:
If you rely on channels, you might want to watch
I'm using the "" and just updated it, and I get this: So, that means the PR is not in that channel yet? If it's that, good to know, didn't know that tool.
Yes, channels that are not -small usually lag by roughly one day.

Related discussion:
text: fplll = callPackage ../development/libraries/fplll {}; fplll_20160331 = callPackage ../development/libraries/fplll/20160331.nix {}; <del> freeimage = callPackage ../development/libraries/freeimage { }; </del> <ins> freeimage = callPackage ../development/libraries/freeimage { libraw = libraw_unstable; }; </ins> freetts = callPackage ../development/libraries/freetts { jdk = jdk8; # TODO: remove override https://github.com/NixOS/nixpkgs/pull/89731
Code change:
Krita fails to build with the following error Steps to reproduce the behavior: Build Krita should build. nixpkgs @
In libraw was updated. Switch to the old stable libraw020 to fix this build.
Installing kirta is showing like it's not in the cache, any idea why?
You're attempting to build the older derivation. And building it would fail. Newer binaries are available:
If you rely on channels, you might want to watch
I'm using the "" and just updated it, and I get this: So, that means the PR is not in that channel yet? If it's that, good to know, didn't know that tool.
Yes, channels that are not -small usually lag by roughly one day.

Related discussion:
text: gegl = callPackage ../development/libraries/gegl { inherit (darwin.apple_sdk.frameworks) OpenCL; <del> libraw = libraw_0_20; </del> }; gensio = callPackage ../development/libraries/gensio {};
Code change:
Krita fails to build with the following error Steps to reproduce the behavior: Build Krita should build. nixpkgs @
In libraw was updated. Switch to the old stable libraw020 to fix this build.
Installing kirta is showing like it's not in the cache, any idea why?
You're attempting to build the older derivation. And building it would fail. Newer binaries are available:
If you rely on channels, you might want to watch
I'm using the "" and just updated it, and I get this: So, that means the PR is not in that channel yet? If it's that, good to know, didn't know that tool.
Yes, channels that are not -small usually lag by roughly one day.

Related discussion:
text: }; libraw = callPackage ../development/libraries/libraw { }; <del> libraw_0_20 = callPackage ../development/libraries/libraw/0_20.nix { }; </del> <ins> libraw_unstable = callPackage ../development/libraries/libraw/unstable.nix { }; </ins> libraw1394 = callPackage ../development/libraries/libraw1394 { };
Code change:
The package is failing to build Steps to reproduce the behavior: The package to build successfully without errors
I'm sorry, I haven't used in years - but also nothing with that package has changed in some while. I'd assume an upstream problem?
I don't use but took a look out of curiosity. It was an upstream problem that is fixed by a few commits after the latest 2.4.0 release. There hasn't been a new release since then. Is the best thing to do here pull down that commit as an isolated patch or to bump the revision that's pulled down to that (untagged) revision?
Can we use in the meantime?

Related discussion:
text: { lib, fetchFromGitHub, cmake, curl, xorg, avahi, qtbase, mkDerivation, openssl, wrapGAppsHook, <del> avahiWithLibdnssdCompat ? avahi.override { withLibdnssdCompat = true; } </del> <ins> avahiWithLibdnssdCompat ? avahi.override { withLibdnssdCompat = true; }, fetchpatch </ins> }: mkDerivation rec {
Code change:
The package is failing to build Steps to reproduce the behavior: The package to build successfully without errors
I'm sorry, I haven't used in years - but also nothing with that package has changed in some while. I'd assume an upstream problem?
I don't use but took a look out of curiosity. It was an upstream problem that is fixed by a few commits after the latest 2.4.0 release. There hasn't been a new release since then. Is the best thing to do here pull down that commit as an isolated patch or to bump the revision that's pulled down to that (untagged) revision?
Can we use in the meantime?

Related discussion:
text: fetchSubmodules = true; }; <ins> patches = [ # This patch can be removed when a new version of barrier (greater than 2.4.0) # is released, which will contain this commit. (fetchpatch { name = "add-missing-cstddef-header.patch"; url = "https://github.com/debauchee/barrier/commit/4b12265ae5d324b942698a3177e1d8b1749414d7.patch"; sha256 = "sha256-ajMxP7szBFi4h8cMT3qswfa3k/QiJ1FGI3q9fkCFQQk="; }) ]; </ins> buildInputs = [ curl xorg.libX11 xorg.libXext xorg.libXtst avahiWithLibdnssdCompat qtbase ]; nativeBuildInputs = [ cmake wrapGAppsHook ];
Code change:
scipy doesn't build on Darwin right now (trunk). Hydra: The error in Hydra seems to be some builder failure and not actually related to the issue. It however fails as well when I try to build on my Mac. We should get rid of both issues. Steps to reproduce the behavior: to build It builds I don't need this Python module myself but a lot of other packages depend on it. This is currently the package with the most dependants (322) that fails so it'd be nice to have this cleaned up before ZHF starts. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
The too many open files sounds like it could be related to the very low default limit on open files on macOS. For me it defaults to 256, I think more recent versions have increased the limit but it's still lower than for Linux and the tests were probably written with that in mind.
scipy builds for me on both x86_64-darwin and aarch64-darwin. $ nix-info -m system: host os: multi-user?: sandbox: version: channels(reckenrode): channels(root): nixpkgs:
what does report for you?
Ok, then my hypothesis is debunked.
Could this be due to the file descriptor leak bug in nix ? This would explain why it fails to build for some users but not for others. I believe the bug was fixed in nix 2.8.
scipy seems to be build for me on , can anyone else confirm? Looks like it's still failing on .
can we just disable the tests on for now? as a note (or whatever) can bump the open file limit but you might then run into memory limits like I've experienced in
I'm going to disable tests on so we can work on other issues for ZHF. If anyone wants to debug specific failures in scipy please reply to this issue. It currently causes hundreds of other packages to transitively fail.
Wonder if reducing parallelism would help.

Related discussion:
text: rm scipy/linalg/tests/test_lapack.py ''; <del> doCheck = true; </del> <ins> doCheck = !(stdenv.isx86_64 && stdenv.isDarwin); </ins> preConfigure = '' sed -i '0,/from numpy.distutils.core/s//import setuptools;from numpy.distutils.core/' setup.py
Code change:
The issue is what the title says. By half, I mean and for my previously used from emacs-overlay to your system the eln cache in your home, e.g. to open emacs for the manual for by and inputing the eln cache in your home: , you will find together other eln cache. I think this is a bug since is builtin for emacs and it's eln cache should be distributed together with . Uses of will not need to native-compile builtin libraries themselves. does distributed together with from emacs-overlay I used before. It's . might be related to the bump of 28 , so
The difference between the two versions is that one is built from the tarball, while the other is built from Git. The tarball includes byte-compiled () files but not native-compiled () files. The build notices the files and does not rebuild them, but native-compilation is a side-effect of byte-compilation and so the files aren't built either. (Almost all of the files you see for the new version are trampolines, there are only 3 non-trampoline files.)
ideally we'd run , which is the expected way of deleting such things (or perhaps even ). But the tarball only has a , so we'd need to run , then , then again, which is super ugly. Hopefully deleting the files the naïve way is enough?
I think maybe we should just skip the tarball entirely and fetch it from git instead.
There are other side-effects caused by skipping the tarball. This claims, for example, that bootstrapping is only expected to happen to emacs developers. Part of bootstrapping is converting the Japanese input method dictionaries, and this takes some amount of time. They're in the tarball at , but are absent in the git checkout.
That's a good point, I would still rather inflate build times a bit and exercise bootstrapping as a part of our regular build though to completely avoid these types of issues.
I'm hesitant about building things in a way that upstream doesn't expect, unless necessary to adapt for nixpkgs. For a related example, using the repo instead of the tar distribution for Ruby caused a subtle problem where the commit hash was not propagated, which broke the bootsnap gem's cache invalidation (fixed in , by using the tarball). The real question here, I think, is how upstream expects native compilation to be used if their tarball doesn't support it.

Related discussion:
text: import ./generic.nix (rec { version = "28.1"; <del> sha256 = "sha256-KLGz0JkDegiPCkyiUdfnJi6rXqFneqv/psRCaWGtdeE="; </del> <ins> sha256 = "sha256-D33wnlxhx0LyG9WZaQDj2II3tG0HcJdZTC4dSA3lrgY="; </ins> patches = _: [ ]; })
Code change:
The issue is what the title says. By half, I mean and for my previously used from emacs-overlay to your system the eln cache in your home, e.g. to open emacs for the manual for by and inputing the eln cache in your home: , you will find together other eln cache. I think this is a bug since is builtin for emacs and it's eln cache should be distributed together with . Uses of will not need to native-compile builtin libraries themselves. does distributed together with from emacs-overlay I used before. It's . might be related to the bump of 28 , so
The difference between the two versions is that one is built from the tarball, while the other is built from Git. The tarball includes byte-compiled () files but not native-compiled () files. The build notices the files and does not rebuild them, but native-compilation is a side-effect of byte-compilation and so the files aren't built either. (Almost all of the files you see for the new version are trampolines, there are only 3 non-trampoline files.)
ideally we'd run , which is the expected way of deleting such things (or perhaps even ). But the tarball only has a , so we'd need to run , then , then again, which is super ugly. Hopefully deleting the files the naïve way is enough?
I think maybe we should just skip the tarball entirely and fetch it from git instead.
There are other side-effects caused by skipping the tarball. This claims, for example, that bootstrapping is only expected to happen to emacs developers. Part of bootstrapping is converting the Japanese input method dictionaries, and this takes some amount of time. They're in the tarball at , but are absent in the git checkout.
That's a good point, I would still rather inflate build times a bit and exercise bootstrapping as a part of our regular build though to completely avoid these types of issues.
I'm hesitant about building things in a way that upstream doesn't expect, unless necessary to adapt for nixpkgs. For a related example, using the repo instead of the tar distribution for Ruby caused a subtle problem where the commit hash was not propagated, which broke the bootsnap gem's cache invalidation (fixed in , by using the tarball). The real question here, I think, is how upstream expects native compilation to be used if their tarball doesn't support it.

Related discussion:
text: , sigtool, jansson, harfbuzz, sqlite, nixosTests , dontRecurseIntoAttrs, emacsPackagesFor , libgccjit, targetPlatform, makeWrapper # native-comp params <ins> , fetchFromSavannah </ins> , systemd ? null , withX ? !stdenv.isDarwin , withNS ? stdenv.isDarwin