jiebi/CodeConvo huggingface dataset:
Change:
mkdir -p $out/bin $out/libexec cp -R libphutil $out/libexec/libphutil cp -R arcanist  $out/libexec/arcanist <del> ln -s $out/libexec/arcanist/bin/arc $out/bin wrapProgram $out/bin/arc  --prefix PATH : "${php}/bin" </del> <ins> ${if stdenv.isDarwin then '' echo "#! $shell -e" > $out/bin/arc echo "exec ${php}/bin/php $out/libexec/arcanist/scripts/arcanist.php "'"$@"' >> $out/bin/arc chmod +x $out/bin/arc'' else '' ln -s $out/libexec/arcanist/scripts/arcanist.php $out/bin/arc''} </ins> ''; meta = {

Discussion:
Describe the bug To Reproduce Steps to reproduce the behavior: on Darwin it Expected behavior The program runs, via PHP being used to execute the top-level script. Additional context Guessing this is related to , which appears stalled, or perhaps there was uncertainty about which MacOS versions this applied to. The mentioned above begins and it is invoked via the bin wrapper which begins while is itself a bash wrapper, and is The is the native executable. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(steve): nixpkgs: Maintainer information:
cc
you're the only member of the team I'm aware of having access to a mac... do you have any capacity to look at this?
I looked into it yesterday and may have fixed it in , but I don't use arcanist, so if someone who does can try it out, that would be great :)
sorry I've never used that application either.
Change:
]); checkPhase = '' <ins> # Temporarily disable a test failing after a patch imagemagick update. # It might only due to the reporting and matching used in the test. # See https://github.com/NixOS/nixpkgs/issues/223446 # See https://sourceforge.net/p/gscan2pdf/bugs/417/ # #   Failed test 'valid TIFF created' #   at t/131_save_tiff.t line 44. #                   'test.tif TIFF 70x46 70x46+0+0 8-bit sRGB 10024B 0.000u 0:00.000 # ' #     doesn't match '(?^:test.tif TIFF 70x46 70x46+0+0 8-bit sRGB [7|9][.d]+K?B)' rm t/131_save_tiff.t </ins> # Temporarily disable a dubiously failing test: # t/169_import_scan.t ........................... 1/1 # #   Failed test 'variable-height scan imported with expected size'

Discussion:
Steps to reproduce the behavior: Bisected: Introduced in
From the build log: What the heck is that meant to do? This test would pass if the reported size of the TIFF starts with a 7, a 9, or a pipe character, and fails otherwise? Surely this is an upstream gscan2pdf issue.
Issue reported to the gscan2pdf project: Since this should not be impacting the other features of the program, I think it's safe to temporarily disable that one test for that package on our side.
Disabling the test temporarily in:
With merged, let's close this. There's nothing we can do until upstream reacts.
Apparently upstream did update their test according to , but we need to wait for a new release containing the fix.
Change:
./services/misc/podgrab.nix ./services/misc/polaris.nix ./services/misc/portunus.nix <ins> ./services/misc/preload.nix </ins> ./services/misc/prowlarr.nix ./services/misc/pufferpanel.nix ./services/misc/pykms.nix

Discussion:
Project description Runs as a daemon and records statistics about usage of programs using Markov chains; files of more frequently-used programs are, during a computer's spare time, loaded into memory. Metadata homepage URL: source URL: license: gpl2 platforms: linux
Same here! Preload can really help out when using Linux on older hardware or when using programs that generally take long to start.
Change:
# includes <del> ln -s ${glibc_multi.dev}/include $out/ </del> <ins> mkdir -p $out/include ln -s ${glibc_multi.dev}/include/* $out/include ln -s ${gcc64.cc}/include/c++ $out/include/c++ </ins> # dynamic linkers mkdir -p $out/lib/32

Discussion:
the error has changed to any ideas? perhaps a issue here
Investigating...
Well this will get you back to where you were before: See if you can nudge it a bit further; if not I can work on this again tomorrow or Monday.
Change:
url = "https://gitlab.alpinelinux.org/alpine/aports/-/raw/78fde4aaf1a74eb13a3f083cb6dfb29f578c3265/community/wlroots/0001-Revert-layer-shell-error-on-0-dimension-without-anch.patch"; sha256 = "1zjn7mwdj21z0jsc2mz90cnrzk97yqkiq58qqgpjav4h4dgpfb38"; }) <del> # To fix missing header `EGL/eglmesaext.h` dropped upstream (fetchpatch { name = "0002-stop-including-eglmesaext-h.patch"; url = "https://github.com/swaywm/wlroots/commit/e18599b05e0f0cbeba11adbd489e801285470eab.patch"; sha256 = "17ax4dyk0584yhs3lq8ija5bkainjf7psx9c9r50cr4jm9c0i37l"; }) </del> # xwayland: Allow to retrieve _NET_STARTUP_ID (fetchpatch {

Discussion:
We've temporarily introduced as part of to avoid breaking some reverse dependencies. The affected attributes should switch to when possible (usually a new upstream release). There's no hurry but let's use this issue to track the current progress. : [x] phoc [x] cage (): [x] hikari ( and ): [x] waybox (): [x] wayfire (supported since ): [x] wio (, turns out the pending patches on the ML should fix the build with wlroots 0.13): [x] cagebreak ( and additional commits): () : [x] sway: [x] hikari (downstream patches: ): [x] wio (, send via git-send-email to ):
cage: was just merged, do we want to: until a next release it using the now-merged patch the latest version from master
I think waiting for the next release is the best option for now (we're in no hurry). For some other packages that are already based on commits instead of releases there's no need to wait if the package maintainers deem a newer version stable (in that case I'd leave it up to the package maintainers).
(though I hope that doesn't have the same problems as cage)
(kinda flew under the radar for me, but it happened!)
Don't we want to split this issue up per version? It seems like we're always gonna have a handful of wlroots versions around, would be nice if we could close those issues individually instead of having one perpetually open issue
I thought about that too but I was hoping we can close this before the next wlroots release. is the main blocker, should be fairly easy to drop (I'm waiting for patches and, if necessary, I might be able to patch again but I might also mark it as broken instead (until there's a maintained fork) as I don't intend to do that every release).
I have merely made a new fork for wio outside SourceHut, but me myself do not plan to maintain it alone.
in that case we should eventually drop it from Nixpkgs, at least IMO. I had some time yesterday so I've sent you a patch for wlroots 0.14 (, tested with ).
I have patched it on my particular fork
Phoc 0.11.0 was released targeting wlroots 0.14.0 (), so this can finally be closed.
Change:
libva vulkan-loader gcc.cc <ins> nss nspr </ins> ]; ourRuntime = if runtimeOnly then []

Discussion:
I have just updated to NixOS 17.09 commit . After the update I found out that all browser based tabs in steam don't work. This error message is printed: A quick grep in nixpkgs shows that steam runtime is using libnss 3.19.2. So that might be the cause of the problem. Install NixOS commit . Run steam. Open STORE or COMMUNITY tab. system: host os:
The solution is in I'll open a PR. Thanks for filing that.
I tried your patch and can confirm that it fixes the issue. Thank you!
Change:
# Fix https://ghc.haskell.org/trac/ghc/ticket/12130 (fetchFilteredPatch { url = https://git.haskell.org/ghc.git/patch/4d71cc89b4e9648f3fbb29c8fcd25d725616e265; sha256 = "0syaxb4y4s2dc440qmrggb4vagvqqhb55m6mx12rip4i9qhxl8k0"; }) (fetchFilteredPatch { url = https://git.haskell.org/ghc.git/patch/2f8cd14fe909a377b3e084a4f2ded83a0e6d44dd; sha256 = "06zvlgcf50ab58bw6yw3krn45dsmhg4cmlz4nqff8k4z1f1bj01v"; }) <del> ]; </del> <ins> ] ++ stdenv.lib.optional stdenv.isLinux ./ghc-no-madv-free.patch; </ins> buildInputs = [ ghc perl hscolour ];

Discussion:
Post merge, lots of Haskell programs print the following errors: Incidentally, it seemed that some Haskell builds were running out of memory (None left on Hydra as I restarted all of the them). There's a GHC issue mentioning this problem along with a suggested patch: should we apply?
There is some information about this issue to grab from Apparently the problem is not related to Haskell but to the version of which is fairly recent for the default nixos kernel. So if you upgrade the kernel the error should disappear. I haven't tested or try to upgrade the kernel but instead was hoping the issue would disappear with some recent nix-channel updates (the unstable channel). But so far it hasn't. I still hope for a fix to come up in a near future.
Well sorry I probably misunderstood the messages from the IRC channel. Initially this happens to me on only but it has just started to show up in another linux distro after updating the nix channel:
Also see post on nix-dev: Worked for me. Still an issue given that hydra runs on 4.4.x…
the glibc, or binutils, or hardening flags could all be causing this but using kernel 4.7 does fix it.
Personally, I'd rather configure the build with than patch the script. IMHO that's a cleaner solution. Does anyone understand the implications of this setting, i.e. does it reduce performance in any significant way etc.?
The idea is to reduce the number of system calls. With , GHC s a 1TB region of virtual memory and does its own allocations there. Disabling this feature will incur a small performance penalty when allocating. GHC has a different implementation of if it doesn't detect MADV_FREE, so I think forcibly disabling that check in the configure script is the right way to go. That way there is no performance penalty (even if it is small).
OK. Does anyone have a patch ready that accomplishes this? The patch from goes a different route which doesn't feel ideal.
Change:
name = "ttyd"; meta.maintainers = with lib.maintainers; [ stunkymonkey ]; <del> nodes.machine = { pkgs, ... }: { </del> <ins> nodes.readonly = { pkgs, ... }: { services.ttyd = { enable = true; entrypoint = [ (lib.getExe pkgs.htop) ]; writeable = false; }; }; nodes.writeable = { pkgs, ... }: { </ins> services.ttyd = { enable = true; username = "foo"; passwordFile = pkgs.writeText "password" "bar"; <ins> writeable = true; </ins> }; }; testScript = '' <del> machine.wait_for_unit("ttyd.service") machine.wait_for_open_port(7681) response = machine.succeed("curl -vvv -u foo:bar -s -H 'Host: ttyd' http://127.0.0.1:7681/") assert '<title>ttyd - Terminal</title>' in response, "Page didn't load successfully" </del> <ins> for machine in [readonly, writeable]: machine.wait_for_unit("ttyd.service") machine.wait_for_open_port(7681) response = machine.succeed("curl -vvv -u foo:bar -s -H 'Host: ttyd' http://127.0.0.1:7681/") assert '<title>ttyd - Terminal</title>' in response, "Page didn't load successfully" </ins> ''; })

Discussion:
After a recent upgrade ( followed by ) the browser-based terminal in my setup, served with ttyd, no longer accepts user input (i.e. where the user can type and enter commands through the browser). Normally you are greeted with a terminal login screen and can enter username/password and log in, but it is now no longer possible to type or submit either. After researching, there is a breaking change in ttyd version =1.7.4, where the terminal is now readonly by default, users must pass or to get an interactive terminal. Note that the release notes appear to incorrectly indicate a lower-case flag, upper-case is needed. Consulting both the listed and the nixpkgs , there is no currently no way to pass this option. I am unsure who if anyone is the maintainer of this service, although I see that maintains the ttyd package. I will attempt to fix and submit a PR.
Change:
enableParallelBuilding = true; <ins> # Ignore broken test, likely not causing huge breakage # (https://github.com/canonical/raft/issues/292) postPatch = '' substituteInPlace test/integration/test_uv_tcp_connect.c --replace  "TEST(tcp_connect, closeDuringHandshake, setUp, tearDownDeps, 0, NULL)"  "TEST(tcp_connect, closeDuringHandshake, setUp, tearDownDeps, MUNIT_TEST_OPTION_TODO, NULL)" ''; </ins> preConfigure = '' substituteInPlace configure --replace /usr/bin/ " " '';

Discussion:
... on both and . Looks like a test failed. This at least prevents (and therefore ) from being built on Linux. Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result.
IIRC this is since PR merged in .
Not like I want to work on this, but I see
Nope, 13 is not errno, but a file descriptor. See strace output of the failing test: This is likely caused by . Reverting libuv to 1.44.1 results in a successful build. Looking at libuv changes, I guess that might be the reason. I'll file a bug upstream.
Oh, and sounded very much like error codes.
/cc
Change:
sha256 = "1pdb4gbjrs8mk6r0ipw5vxyvzav1wvkjq46kiq53r3nyznfpdfyw"; }; <ins> patches = [ # Extracted from: https://github.com/Homebrew/homebrew-core/blob/2a27fb86b08afc7ae6dff79cf64aafb8ecc93275/Formula/gspell.rb#L125-L149 ./0001-Darwin-build-fix.patch ]; </ins> nativeBuildInputs = [ pkg-config vala gobject-introspection libxml2 <ins> autoreconfHook gtk-doc </ins> ]; buildInputs = [ glib gtk3 icu <ins> ] ++ lib.optionals stdenv.hostPlatform.isDarwin [ gtk-mac-integration </ins> ]; propagatedBuildInputs = [

Discussion:
Project description CherryTree by Giuspen, currently, we are using version 0.39.4, meanwhile the latest application is on 0.99.37. There's a weird jump of version from 0.39.4 to 0.99.13. I don't know why this happens. Metadata homepage URL: source URL: license: GPL3 + platforms: Linux
Package request is the wrong issue type for this, Out-of-date package report would've been better. ! The package is sadly orphaned so there's no maintainer to ping for this.
Change:
# file generated from go.mod using vgo2nix (https://github.com/adisbladis/vgo2nix) [ { <del> goPackagePath = "github.com/Microsoft/go-winio"; fetch = { type = "git"; url = "https://github.com/Microsoft/go-winio"; rev = "v0.4.12"; sha256 = "10v2f1xaw2cc97mjqnxzgs9ydpqv71f0ynp1spcywqw97la56zqw"; }; } { goPackagePath = "github.com/pkg/errors"; fetch = { type = "git"; url = "https://github.com/pkg/errors"; rev = "v0.8.1"; sha256 = "0g5qcb4d4fd96midz0zdk8b9kz8xkzwfa8kr1cliqbg8sxsy5vd1"; }; } { </del> goPackagePath = "golang.org/x/crypto"; fetch = { type = "git"; url = "https://go.googlesource.com/crypto"; <del> rev = "a29dc8fdc734"; sha256 = "07f0jj4haqs0ywc1akk1qjwn5msl2j0pry1rxjkkbfcq4r6ihc1p"; </del> <ins> rev = "9756ffdc2472"; sha256 = "0q7hxaaq6lp0v8qqzifvysl47z5rfdlrxkh3d29vsl3wyby3dxl8"; </ins> }; } {

Discussion:
I can't compile on macOS: Metadata system: host os: multi-user?: sandbox: version: channels(eridius): nixpkgs: Maintainer information:
Change:
./docbook2texi.patch ./symlinks-in-bin.patch ./git-sh-i18n.patch <ins> ./ssh-path.patch </ins> ]; <ins> postPatch = '' for x in connect.c git-gui/lib/remote_add.tcl ; do substituteInPlace "$x"  --subst-var-by ssh "${openssh}/bin/ssh" done ''; </ins> buildInputs = [curl openssl zlib expat gettext cpio makeWrapper libiconv] ++ stdenv.lib.optionals withManual [ asciidoc texinfo xmlto docbook2x docbook_xsl docbook_xml_dtd_45 libxslt ]

Discussion:
Running with my still-quite-new nix environment, I get: Installing openssh fixes the problem for me, of course. But this means that git really ought to declare a dependency on openssh, no?
Hmm, currently I see two other alternatives: wrap all to have ssh in path (this seems the cleanest way), add it to , or or leave it as it is.
Or patch git to invoke ssh via an absolute path. (I'm not really fond of wrappers...)
Personally, I'd be very much in favor of patching git to call via an absolute path. At the same time, maintaining that patch over time is tedious and error-prone work, and I'd rather not be responsible for that. IMHO, patching SSH would be a feasible alternative only if we get that patch included upstream.
Has anyone taken a look at patching git to see how hard it will be?
There are two places. One is in connect.c where it reads GIT_SSH and then does Another is in git-gui where it does more or less the same, but in TCL.
I just found out that openssh isn't even a build input of git at the moment. :-)
I've decided to add a wrapper, since maintaining patches for references is going to be a burden. We still need to be able to specify public keys for ssh to pick them up.
your patch broke git-annex:
Reverted
that's an old build, now src is using https for sxiv
Is there a recommended solution for this now?
The recommended solution is to patch git, IMHO. It's not hard, as pointed out.
Triage: this issue does still exist on 16.03-beta:
Patched in
The solution to this issue is now causing a different issue on Fedora: () I'm not sure if we should really hard-code a SSH binary or if we should e.g. just reference a SSH binary as a fallback. Opinions welcome :)
FYI: is about to revert this and I currently believe that this is a good idea.
Change:
# List of components used in config extraComponents = filter useComponent availableComponents; <del> package = if cfg.autoExtraComponents </del> <ins> package = if (cfg.autoExtraComponents && cfg.config != null) </ins> then (cfg.package.override { inherit extraComponents; }) else cfg.package;

Discussion:
I think this should be clearly mentioned in the manual. cc
Sorry for that. That's definitely not intended. In , I changed it so that is only overridden if .
Change:
<ins> { lib, fetchFromGitHub, buildGoModule, go-bindata }: buildGoModule rec { name = "gvisor-containerd-shim-${version}"; version = "2019-10-09"; src = fetchFromGitHub { owner  = "google"; repo   = "gvisor-containerd-shim"; rev    = "f299b553afdd8455a0057862004061ea12e660f5"; sha256 = "077bhrmjrpcxv1z020yxhx2c4asn66j21gxlpa6hz0av3lfck9lm"; }; modSha256 = "1jdhgbrn59ahnabwnig99i21f6kimmqx9f3dg10ffwfs3dx0gzlg"; buildPhase = '' make ''; doCheck = true; checkPhase = '' make test ''; installPhase = '' make install DESTDIR="$out" ''; meta = with lib; { description = "containerd shim for gVisor"; homepage    = https://github.com/google/gvisor-containerd-shim; license     = licenses.asl20; maintainers = with maintainers; [ andrew-d ]; platforms   = [ "x86_64-linux" ]; }; } </ins>

Discussion:
"Sandboxed container runtime" Bonus points for NixOS option for docker support :P. But just having it to poke at would be neat, i think!
I've looked quickly at this, and it seems like the main limitation in implementing this is . I think we either have to patch Bazel in NixOS or any Bazel package that compiles Go to fix this...
Change:
elerea = callPackage ../development/libraries/haskell/elerea {}; <ins> Elm = callPackage ../development/compilers/elm/elm.nix {}; elmServer = callPackage ../development/compilers/elm/elm-server.nix {}; </ins> emailValidate = callPackage ../development/libraries/haskell/email-validate {}; encoding = callPackage ../development/libraries/haskell/encoding {};

Discussion:
Kdenlive build fails because CMake can't find QtConcurrent. Error: It appears to have been broken by some changes made to qtbase but I am not familiar enough with it to know what specifically. Changes between success and first failure: Latest Hydra failure: cc Attempt to install Kdenlive System: NixOS: 17.09pre107928. (Hummingbird) Nix version: nix-env (Nix) 1.11.9 Nixpkgs version: "17.09pre107928." Sandboxing enabled: build-use-sandbox = true
You need to modify the to We should send a patch upstream. This must be a required change since QT5.8.
Fixed by:
Change:
inherit (darwin.apple_sdk.frameworks) Security; }; <del> onthespot = libsForQt5.callPackage ../applications/misc/onthespot { }; </del> opencorsairlink = callPackage ../tools/misc/opencorsairlink { }; openfpgaloader = callPackage ../development/embedded/fpga/openfpgaloader { };

Discussion:
Steps to reproduce the behavior: onthespot Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
postFixup = let LD_LIBRARY_PATH = [ ] <del> ++ lib.optionals with_cublas [ (lib.getLib libcublas) cuda_cudart addDriverRunpath.driverLink ] </del> <ins> ++ lib.optionals with_cublas [ # driverLink has to be first to avoid loading the stub version of libcuda.so # https://github.com/NixOS/nixpkgs/issues/320145#issuecomment-2190319327 addDriverRunpath.driverLink (lib.getLib libcublas) cuda_cudart ] </ins> ++ lib.optionals with_clblas [ clblast ocl-icd ] ++ lib.optionals with_openblas [ openblas ] ++ lib.optionals with_tts [ piper-phonemize ];

Discussion:
Not sure if it's a local-ai (or rather one of its dependency llama-cpp/gpt4all) but I can't leverage GPU inference of my nvidia RTX3060 because of error I think. nvidia-smi output looks ok: +
----------+ |-----------------------------------------+------------------------+----------------------+ [90m10:21PM[0m DBG GRPC(mistral-7b-): stderr : search path=/nix/store/bn7pnigb0f8874m6riiw6dngsmdyic1g-gcc-13.3.0-lib/lib/glibc-hwcaps/x86-64-v3:/nix/store/bn7pnigb0f8874m6riiw6dngsmdyic1g-gcc-13.3.0-lib/lib/glibc-hwcaps/x86-64-v2:/nix/store/bn7pnigb0f8874m6riiw6dngsmdyic1g-gcc-13.3.0-lib/lib:/nix/store/zx9yfgv4ag607b8m3dgcp5p94b6vd13c-cudacudart-12.2.140-lib/lib/stubs/glibc-hwcaps/x86-64-v3:/nix/store/zx9yfgv4ag607b8m3dgcp5p94b6vd13c-cudacudart-12.2.140-lib/lib/stubs/glibc-hwcaps/x86-64-v2:/nix/store/zx9yfgv4ag607b8m3dgcp5p94b6vd13c-cudacudart-12.2.140-lib/lib/stubs (RUNPATH from file /tmp/localai/backend_data/backend-assets/grpc/llama-cpp-avx2) ls -l /run/opengl-driver/lib | head lrwxrwxrwx - root 1 janv. 1970 d3d -/nix/store/fh3p3s1gg0ick2f295zfwi2jlr78166r-mesa-24.1.1-drivers/lib/d3d dr-xr-xr-x - root 1 janv. 1970 dri lrwxrwxrwx - root 1 janv.

1970 gbm -/nix/store/w7fcnyxkxara9fixrmigzrir3k8fbdb3-nvidia-x11-550.90.07-6.8.12/lib/gbm lrwxrwxrwx - root 1 janv. 1970 nvidia -/nix/store/w7fcnyxkxara9fixrmigzrir3k8fbdb3-nvidia-x11-550.90.07-6.8.12/lib/nvidia lrwxrwxrwx - root 1 janv. 1970 systemd -/nix/store/w7fcnyxkxara9fixrmigzrir3k8fbdb3-nvidia-x11-550.90.07-6.8.12/lib/systemd dr-xr-xr-x - root 1 janv. 1970 vdpau lrwxrwxrwx - root 1 janv. 1970 -/nix/store/w7fcnyxkxara9fixrmigzrir3k8fbdb3-nvidia-x11-550.90.07- lrwxrwxrwx - root 1 janv. 1970 -/nix/store/w7fcnyxkxara9fixrmigzrir3k8fbdb3-nvidia-x11-550.90.07- console [user nix-shell -p nix-info --run "nix-info -m" output here Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
using llama-cpp directly works fine so I suspect a problem in local-ai building. I will stick to llama-cpp for now
This is being loaded instead of
Change:
preBuild = let tags = optional pamSupport "pam" <del> ++ optional sqliteSupport "sqlite"; </del> <ins> ++ optional sqliteSupport "sqlite sqlite_unlock_notify"; </ins> tagsString = concatStringsSep " " tags; in '' export buildFlagsArray=(

Discussion:
At: This should also add as per Gitea's docs. ( ) Without this tag sqlite will frequently report that the database is locked and cause multiple internal server errors. See
If someone needs a quick fix in `:
Change:
github = "13r0ck"; githubId = 58987761; }; <ins> _1nv0k32 = { name = "Armin"; email = "Armin.Mahdilou@gmail.com"; github = "1nv0k32"; githubId = 30079271; }; </ins> _21CSM = { name = "21CSM"; email = "21CSM@tutanota.com";

Discussion:
Project description It's a forward proxy with PAC file support. Metadata homepage URL: source URL: license: apache version 2.0 platforms: linux, darwin Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
(I took that name)
Change:
# darwin build fails with format hardening since v7.12 hardeningDisable = stdenv.lib.optionals stdenv.isDarwin [ "format" ]; <ins> NIX_CFLAGS_COMPILE = "-Wno-format-nonliteral"; </ins> configureFlags = with stdenv.lib; [ "--with-gmp=${gmp.dev}" "--with-mpfr=${mpfr.dev}" "--with-system-readline" "--with-system-zlib" "--with-expat" "--with-libexpat-prefix=${expat.dev}"

Discussion:
gdb on Darwin likes to output a lot it seems. Nixpkgs master at
Might be fixed on staging
Seems OK now on the very same derivation. I suppose it was some random error that won't frequently happen.
Hmm, . Perhaps the build is simply too chatty.