jiebi/CodeConvo huggingface dataset:
Code change:
Tried to make a system upgrade, got this: Obviously, upgrade can't be completed. have in . run Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
This looks like the offending line: This could be related to what file system you are using?
Actually this looks like unrelated to glslang. Works on master:

Related discussion:
text: <ins> diff --git a/CMakeLists.txt b/CMakeLists.txt index c9f73ce96..d14ffeed9 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -339,13 +339,13 @@ macro(run_vk_xml_generate dependency output) endmacro() # Define macro used for generating header files containing commit IDs for external dependencies -macro(run_external_revision_generate source_dir symbol_name output) +macro(run_external_revision_generate rev_file symbol_name output) add_custom_command(OUTPUT ${output} # NOTE: If you modify this call to use --rev_file instead of --git_dir (to read the commit ID from a file instead of # parsing from a Git repository), you probably also want to add the revision file to the list of DEPENDS on the # subsequent line (to ensure that the script is re-run when the revision file is modified). -    COMMAND ${PYTHON_CMD} ${SCRIPTS_DIR}/external_revision_generator.py --git_dir ${source_dir} -s ${symbol_name} -o ${output} -    DEPENDS ${SCRIPTS_DIR}/external_revision_generator.py ${source_dir}/.git/HEAD ${source_dir}/.git/index +    COMMAND ${PYTHON_CMD} ${SCRIPTS_DIR}/external_revision_generator.py --rev_file ${rev_file} -s ${symbol_name} -o ${output} +    DEPENDS ${SCRIPTS_DIR}/external_revision_generator.py ${rev_file} ) endmacro() </ins>
Code change:
Tried to make a system upgrade, got this: Obviously, upgrade can't be completed. have in . run Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
This looks like the offending line: This could be related to what file system you are using?
Actually this looks like unrelated to glslang. Works on master:

Related discussion:
text: let spirv_sources = { <del> # `vulkan-loader` requires a specific version of `spirv-tools` and `spirv-headers` as specified in # `<vulkan-loader-repo>/external_revisions/spirv-tools_revision`. </del> <ins> # `glslang` requires a specific version of `spirv-tools` and `spirv-headers` as specified in `known-good.json`. </ins> tools = fetchFromGitHub { owner = "KhronosGroup"; repo = "SPIRV-Tools"; <del> rev = "7e2d26c77b606b21af839b37fd21381c4a669f23"; sha256 = "1nlzj081v1xdyfz30nfs8hfcnqd072fra127h46gav179f04kss2"; </del> <ins> rev = "9e19fc0f31ceaf1f6bc907dbf17dcfded85f2ce8"; sha256 = "1zpwznq0fyvkzs5h9nnkr7g6svr0w8z6zx62xgnss17c2a5cz0lk"; </ins> }; headers = fetchFromGitHub { owner = "KhronosGroup"; repo = "SPIRV-Headers"; <del> rev = "2bb92e6fe2c6aa410152fc6c63443f452acb1a65"; sha256 = "1rgjd7kpa7xpbwpzd6m3f6yq44s9xn5ddhz135213pxwbi5c0c26"; </del> <ins> rev = "ce309203d7eceaf908bea8862c27f3e0749f7d00"; sha256 = "1sv1iy2d46sg7r3xy591db6fn9h78wd079yvfa87vwmwsdkhiqhm"; </ins> }; };
Code change:
Tried to make a system upgrade, got this: Obviously, upgrade can't be completed. have in . run Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
This looks like the offending line: This could be related to what file system you are using?
Actually this looks like unrelated to glslang. Works on master:

Related discussion:
text: stdenv.mkDerivation rec { name = "spirv-tools-${version}"; <del> version = "2017-09-01"; </del> <ins> version = "2018-02-05"; </ins> src = spirv_sources.tools; patchPhase = ''ln -sv ${spirv_sources.headers} external/spirv-headers'';
Code change:
does not build after "boto{3,core}: {1.6.0,1.9.3} -{1.7.9,1.10.9}" by system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Whoops, sorry about that! I keep forgetting they're all linked

Related discussion:
text: in py.pkgs.buildPythonApplication rec { pname = "awscli"; <del> version = "1.14.50"; </del> <ins> version = "1.15.10"; </ins> src = py.pkgs.fetchPypi { inherit pname version; <del> sha256 = "1yiwj7cl9r1k9226mdq6pcmrs044k7p3d133lzgv9rb1dgp4053c"; </del> <ins> sha256 = "0nwpanbfx5h0bad8wwvvbhpjf9r6n885bbv2w8mw7vijdgclkq8x"; </ins> }; # No tests included
Code change:
does not build after "boto{3,core}: {1.6.0,1.9.3} -{1.7.9,1.10.9}" by system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Whoops, sorry about that! I keep forgetting they're all linked

Related discussion:
text: less ]; <ins> postPatch = '' for i in {py,cfg}; do substituteInPlace setup.$i --replace "botocore==1.10.10" "botocore>=1.10.9,<=1.11" done ''; </ins> postInstall = '' mkdir -p $out/etc/bash_completion.d echo "complete -C $out/bin/aws_completer aws" > $out/etc/bash_completion.d/awscli
Code change:
nixpkgs rev
I wonder if this is another case of the socket path being too long...
Tests appear to work iff sandboxing is disabled.
Same issue reproduced locally on
If the hydra build failed, how did this get released to the 18.03 stable channel?
It is not a release blocking build. Here are the constituents: I'm more curious how it ever worked. I can't really imagine that it hasn't changed since the sandbox was enabled on Hydra.
I tried some older revisions and it really looks like DBD-Pg tests never worked in a sandbox. The package was last updated 2015. Bumping to current DBD-Pg 3.7.4 doesn't help either - it first results in an error about the socket path being too long, and after patching that the tests freeze at the same point as with 3.5.3. So let's stick to 3.5.3 and just set .
Sounds good to me, will you or shall I?
I'm working on it.

Related discussion:
text: makeMakerFlags = "POSTGRES_HOME=${postgresql}"; <ins> # tests freeze in a sandbox doCheck = false; </ins> meta = { homepage = http://search.cpan.org/dist/DBD-Pg/; description = "DBI PostgreSQL interface";
Code change:
pxelinux (from syslinux) is compiled without support for UEFI PXE boot: I had a quick look at getting it to compile uefi support but I didn't get very far. system: host os: multi-user?: sandbox: version: channels(root): channels(peter): nixpkgs:
Does the NixOS netboot image support UEFI boot? I did try netbooting NixOS (18.03) a few weeks ago with a pre-compiled iPXE UEFI loader. It started booting the kernel but failed to mount the initrd (kernel panic no root).
The image is using pxelinux.0 instead of lpxelinux.0 it seems and you need lpxelinux for HTTP support so maybe that's what is going on.
The http support seemed to worked just fine in my case. I did serve the iPXE UEFI loader via tftp, the kernel image and the initrd via http (initrd is too big to load trouble-free via tftp). The iPXE loader pulled bzImage and initrd via http and began booting the kernel. The kernel then failed to mount the ramdisk for some reason I do not understand. I solved the problem by setting 'Legacy mode' in the firmware (Supermicro) and booting everything in classical BIOS/PXE mode (no UEFI components involved). I can try to reproduce the problem and send you some screenshots if that helps. My vague guess is that the NixOS netboot image needs some modifications to be UEFI capable. I just wanted to raise awareness that there are potential problems with UEFI-PXE down the road.
IIRC, specifying on the kernel command line is required with EFI booting for some reason (edit: when booting with iPXE, that is).
would fix this.

Related discussion:
text: <del> { stdenv, fetchFromRepoOrCz, fetchurl, nasm, perl, python3, libuuid, mtools, makeWrapper }: </del> <ins> { stdenv, fetchgit, fetchurl, fetchpatch, nasm, perl, python3, libuuid, mtools, makeWrapper }: </ins> stdenv.mkDerivation { <del> name = "syslinux-2019-02-07"; </del> <ins> pname = "syslinux"; version = "unstable-20190207"; </ins> # This is syslinux-6.04-pre3^1; syslinux-6.04-pre3 fails to run. # Same issue here https://www.syslinux.org/archives/2019-February/026330.html <del> src = fetchFromRepoOrCz { repo = "syslinux"; </del> <ins> src = fetchgit { url = "https://repo.or.cz/syslinux"; </ins> rev = "b40487005223a78c3bb4c300ef6c436b3f6ec1f7"; <del> sha256 = "1qrxl1114sr2i2791z9rf8v53g200aq30f08808d7i8qnmgvxl2w"; </del> <ins> sha256 = "1acf6byx7i6vz8hq6mra526g8mf7fmfhid211y8nq0v6px7d3aqs"; fetchSubmodules = true; </ins> }; patches = let
Code change:
pxelinux (from syslinux) is compiled without support for UEFI PXE boot: I had a quick look at getting it to compile uefi support but I didn't get very far. system: host os: multi-user?: sandbox: version: channels(root): channels(peter): nixpkgs:
Does the NixOS netboot image support UEFI boot? I did try netbooting NixOS (18.03) a few weeks ago with a pre-compiled iPXE UEFI loader. It started booting the kernel but failed to mount the initrd (kernel panic no root).
The image is using pxelinux.0 instead of lpxelinux.0 it seems and you need lpxelinux for HTTP support so maybe that's what is going on.
The http support seemed to worked just fine in my case. I did serve the iPXE UEFI loader via tftp, the kernel image and the initrd via http (initrd is too big to load trouble-free via tftp). The iPXE loader pulled bzImage and initrd via http and began booting the kernel. The kernel then failed to mount the ramdisk for some reason I do not understand. I solved the problem by setting 'Legacy mode' in the firmware (Supermicro) and booting everything in classical BIOS/PXE mode (no UEFI components involved). I can try to reproduce the problem and send you some screenshots if that helps. My vague guess is that the NixOS netboot image needs some modifications to be UEFI capable. I just wanted to raise awareness that there are potential problems with UEFI-PXE down the road.
IIRC, specifying on the kernel command line is required with EFI booting for some reason (edit: when booting with iPXE, that is).
would fix this.

Related discussion:
text: url = mkURL "fa1349f1" "0002-gfxboot-menu-label.patch"; sha256 = "06ifgzbpjj4picpj17zgprsfi501zf4pp85qjjgn29i5rs291zni"; }) <del> (fetchurl { url = mkURL "477e56d2" "0005-gnu-efi-version-compatibility.patch"; sha256 = "041568b4abb79wynyps1n04lg4fr26rc3sbjncz99pp0mbz0ajlm"; </del> <ins> (fetchpatch { url = "https://git.archlinux.org/svntogit/packages.git/plain/trunk/0005-gnu-efi-version-compatibility.patch?h=packages/syslinux"; sha256 = "0fbqz56hj8az8ws26m39hyp3l5fvcbzvzdddqz3x6n56hzdpz1p6"; </ins> }) (fetchurl { # mbr.bin: too big (452 > 440)
Code change:
pxelinux (from syslinux) is compiled without support for UEFI PXE boot: I had a quick look at getting it to compile uefi support but I didn't get very far. system: host os: multi-user?: sandbox: version: channels(root): channels(peter): nixpkgs:
Does the NixOS netboot image support UEFI boot? I did try netbooting NixOS (18.03) a few weeks ago with a pre-compiled iPXE UEFI loader. It started booting the kernel but failed to mount the initrd (kernel panic no root).
The image is using pxelinux.0 instead of lpxelinux.0 it seems and you need lpxelinux for HTTP support so maybe that's what is going on.
The http support seemed to worked just fine in my case. I did serve the iPXE UEFI loader via tftp, the kernel image and the initrd via http (initrd is too big to load trouble-free via tftp). The iPXE loader pulled bzImage and initrd via http and began booting the kernel. The kernel then failed to mount the ramdisk for some reason I do not understand. I solved the problem by setting 'Legacy mode' in the firmware (Supermicro) and booting everything in classical BIOS/PXE mode (no UEFI components involved). I can try to reproduce the problem and send you some screenshots if that helps. My vague guess is that the NixOS netboot image needs some modifications to be UEFI capable. I just wanted to raise awareness that there are potential problems with UEFI-PXE down the road.
IIRC, specifying on the kernel command line is required with EFI booting for some reason (edit: when booting with iPXE, that is).
would fix this.

Related discussion:
text: # fix tests substituteInPlace tests/unittest/include/unittest/unittest.h  --replace /usr/include/ "" <ins> # Hack to get `gcc -m32' to work without having 32-bit Glibc headers. mkdir gnu-efi/inc/ia32/gnu touch gnu-efi/inc/ia32/gnu/stubs-32.h </ins> ''; nativeBuildInputs = [ nasm perl python3 ];
Code change:
pxelinux (from syslinux) is compiled without support for UEFI PXE boot: I had a quick look at getting it to compile uefi support but I didn't get very far. system: host os: multi-user?: sandbox: version: channels(root): channels(peter): nixpkgs:
Does the NixOS netboot image support UEFI boot? I did try netbooting NixOS (18.03) a few weeks ago with a pre-compiled iPXE UEFI loader. It started booting the kernel but failed to mount the initrd (kernel panic no root).
The image is using pxelinux.0 instead of lpxelinux.0 it seems and you need lpxelinux for HTTP support so maybe that's what is going on.
The http support seemed to worked just fine in my case. I did serve the iPXE UEFI loader via tftp, the kernel image and the initrd via http (initrd is too big to load trouble-free via tftp). The iPXE loader pulled bzImage and initrd via http and began booting the kernel. The kernel then failed to mount the ramdisk for some reason I do not understand. I solved the problem by setting 'Legacy mode' in the firmware (Supermicro) and booting everything in classical BIOS/PXE mode (no UEFI components involved). I can try to reproduce the problem and send you some screenshots if that helps. My vague guess is that the NixOS netboot image needs some modifications to be UEFI capable. I just wanted to raise awareness that there are potential problems with UEFI-PXE down the road.
IIRC, specifying on the kernel command line is required with EFI booting for some reason (edit: when booting with iPXE, that is).
would fix this.

Related discussion:
text: makeFlags = [ "BINDIR=$(out)/bin" "SBINDIR=$(out)/sbin" <del> "LIBDIR=$(out)/lib" "INCDIR=$(out)/include" </del> "DATADIR=$(out)/share" "MANDIR=$(out)/share/man" "PERL=perl" <del> "bios" </del> ]; doCheck = false; # fails. some fail in a sandbox, others require qemu
Code change:
When using with and the build fails when trying to write to a in the It works fine if the list of packages is empty or only contains packages that are normally in the environment. Oddly enough, if you run in the it does not produce an error, but it also does not actually include the package, No idea if this is related to system: "x86_64-darwin" host os: Darwin Kernel Version 16.7.0, Sierra multi-user?: no version: nix-env (Nix) 1.11.4 nixpkgs: nixpkgs-channels, commit
I believe the root cause of this problem is that the libraries like , etc are being installed in but the extra packages by are being installed in and the is only looking in one of those locations. I have a work-around hack which I will post when I get a chance.
Can you confirm that fixes this for you?

Related discussion:
text: ghcCommand'    = if isGhcjs then "ghcjs" else "ghc"; ghcCommand = "${ghc.targetPrefix}${ghcCommand'}"; ghcCommandCaps= lib.toUpper ghcCommand'; <del> libDir        = if isHaLVM then "$out/lib/HaLVM-${ghc.version}" else "$out/lib/${ghcCommand}-${ghc.version}"; </del> <ins> libDir        = if isHaLVM then "$out/lib/HaLVM-${ghc.version}" else if isGhcjs then "$out/libexec" else "$out/lib/${ghcCommand}-${ghc.version}"; </ins> docDir        = "$out/share/doc/ghc/html"; packageCfgDir = "${libDir}/package.conf.d"; paths         = lib.filter (x: x ? isHaskellLibrary) (lib.closePropagation packages);
Code change:
This should be . A similar issue happens for 7.59.
Ha! Yes! Currently this happens: Will submit a PR for this shortly, thanks!

Related discussion:
text: configureFlags = [ ( if sslSupport then "--with-ssl=${openssl.crossDrv}" else "--without-ssl" ) ( if gnutlsSupport then "--with-gnutls=${gnutls.crossDrv}" else "--without-gnutls" ) <del> "--with-random /dev/urandom" </del> <ins> "--with-random=/dev/urandom" </ins> ]; };
Code change:
After got merged, and is in the nixos-unstable channel, I noticed after I rebuilt my system that when sddm starts and I type in my password it just goes black and restarts sddm. Meaning that I can never reach the desktop :( I could also not find anything useful in the journal. cc
In a VT, try this as root:
Ahh that makes perfect sense and worked :hand: Is there any real way to make sure this doesn't happen for someone else?
There was a PR some time ago that was supposed to address this (it was merged) that would simply clear out the directory on start but it looks like that didn't do the trick. I don't remember which. IMHO, the proper way to handle this is something like this:
I also often have this problem.. could you open a pull request that removes the old solution and that adds your solution?
The commit was - I'll PR this.

Related discussion:
text: Xsetup = pkgs.writeScript "Xsetup" '' #!/bin/sh <del> # Prior to Qt 5.9.2, there is a QML cache invalidation bug which sometimes # strikes new Plasma 5 releases. If the QML cache is not invalidated, SDDM # will segfault without explanation. We really tore our hair out for awhile # before finding the bug: # https://bugreports.qt.io/browse/QTBUG-62302 # We work around the problem by deleting the QML cache before startup. It # will be regenerated, causing a small but perceptible delay when SDDM # starts. rm -fr /var/lib/sddm/.cache/sddm-greeter/qmlcache </del> ${cfg.setupScript} '';
Code change:
After got merged, and is in the nixos-unstable channel, I noticed after I rebuilt my system that when sddm starts and I type in my password it just goes black and restarts sddm. Meaning that I can never reach the desktop :( I could also not find anything useful in the journal. cc
In a VT, try this as root:
Ahh that makes perfect sense and worked :hand: Is there any real way to make sure this doesn't happen for someone else?
There was a PR some time ago that was supposed to address this (it was merged) that would simply clear out the directory on start but it looks like that didn't do the trick. I don't remember which. IMHO, the proper way to handle this is something like this:
I also often have this problem.. could you open a pull request that removes the old solution and that adds your solution?
The commit was - I'll PR this.

Related discussion:
text: # To enable user switching, allow sddm to allocate TTYs/displays dynamically. services.xserver.tty = null; services.xserver.display = null; <ins> systemd.tmpfiles.rules = [ # Prior to Qt 5.9.2, there is a QML cache invalidation bug which sometimes # strikes new Plasma 5 releases. If the QML cache is not invalidated, SDDM # will segfault without explanation. We really tore our hair out for awhile # before finding the bug: # https://bugreports.qt.io/browse/QTBUG-62302 # We work around the problem by deleting the QML cache before startup. # This was supposedly fixed in Qt 5.9.2 however it has been reported with # 5.10 and 5.11 as well. The initial workaround was to delete the directory # in the Xsetup script but that doesn't do anything. # Instead we use tmpfiles.d to ensure it gets wiped. # This causes a small but perceptible delay when SDDM starts. "e ${config.users.users.sddm.home}/.cache - - - 0" ]; </ins> }; }
Code change:
Passing to a Haskell package has no effect, the resulting binary is . CC
I have checked that at the time runs, shows as but shows as .
The solution seems to be to pass  in when is given.
PR with the fix at

Related discussion:
text: "--enable-library-for-ghci" # TODO: Should this be configurable? ] ++ optionals (enableDeadCodeElimination && (stdenv.lib.versionOlder "8.0.1" ghc.version)) [ "--ghc-option=-split-sections" <ins> ] ++ optionals dontStrip [ "--disable-library-stripping" "--disable-executable-stripping" </ins> ] ++ optionals isGhcjs [ "--ghcjs" ] ++ optionals isCross ([
Code change:
I expect all of these to not return "No such file or directory" and I expect the "bad interpreter" to be patched. I think it still "works", but compilation output should be clean such that when debugging something in the future there is not first a mess of other warnings to go through. Multiple issues: system: host os: multi-user?: sandbox: version: nixpkgs:
cc maintainers
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 .
The build currently complains that is missing: This program comes from ; I believe needs in .
I marked this as stale due to inactivity. &rarr;
As above, I think this is just a matter of adding the right .
I marked this as stale due to inactivity. &rarr;

Related discussion:
text: ./hplip-3.20.11-nixos-cups-ppd-search-path.patch ]; <del> prePatch = '' </del> <ins> postPatch = '' # https://github.com/NixOS/nixpkgs/issues/44230 substituteInPlace createPPD.sh  --replace ppdc "${cups}/bin/ppdc"  --replace "gzip -c" "gzip -cn" </ins> # HPLIP hardcodes absolute paths everywhere. Nuke from orbit. find . -type f -exec sed -i  -e s,/etc/hp,$out/etc/hp,g
Code change:
I expect all of these to not return "No such file or directory" and I expect the "bad interpreter" to be patched. I think it still "works", but compilation output should be clean such that when debugging something in the future there is not first a mess of other warnings to go through. Multiple issues: system: host os: multi-user?: sandbox: version: nixpkgs:
cc maintainers
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 .
The build currently complains that is missing: This program comes from ; I believe needs in .
I marked this as stale due to inactivity. &rarr;
As above, I think this is just a matter of adding the right .
I marked this as stale due to inactivity. &rarr;

Related discussion:
text: export CUPS_DATADIR="${cups}/share/cups" ''; <ins> postConfigure = '' # don't save timestamp, in order to improve reproducibility substituteInPlace Makefile  --replace "GZIP_ENV = --best" "GZIP_ENV = --best -n" ''; </ins> enableParallelBuilding = true; #
Code change:
seem the Keras preprocessing routines were split off into their own package in 2.0. The Nix version was then updated to 2.0 in commit without verifying that it worked. This broke the package as it is now necessary to also package the new package and provide it as a dependency to
We do semi-automatic batch upgrades to the Python packages because not all of them are well maintained. This also means we cannot fix all breakage that occurs during these batch upgrades, however we try to fix as much as possible. If you have the time, please package the new dependency and make a pull request.
Thanks for taking care of that.

Related discussion:
text: <ins> { lib, buildPythonPackage, fetchPypi, numpy, h5py }: buildPythonPackage rec { pname = "Keras_Applications"; version = "1.0.4"; src = fetchPypi { inherit pname version; sha256 = "8c95300328630ae74fb0828b6fa38269a25c0228a02f1e5181753bfd48961f49"; }; # Cyclic dependency: keras-applications requires keras, which requires keras-applications postPatch = '' sed -i "s/keras>=[^']*//" setup.py ''; # No tests in PyPI tarball doCheck = false; propagatedBuildInputs = [ numpy h5py ]; meta = with lib; { description = "Reference implementations of popular deep learning models"; homepage = https://github.com/keras-team/keras-applications; license = licenses.mit; }; } </ins>