jiebi/CodeConvo huggingface dataset:
Code change:
Run , observe: Please run and paste the results.
Very weird... It must have come in from a recent update. You can find libLLDB in the lldb derivation:
/cc

Related discussion:
text: nativeBuildInputs = [ cmake python which swig ]; buildInputs = [ ncurses zlib libedit libxml2 llvm ] <del> ++ stdenv.lib.optionals stdenv.isDarwin [ darwin.libobjc darwin.apple_sdk.libs.xpc darwin.apple_sdk.frameworks.Foundation darwin.bootstrap_cmds darwin.apple_sdk.frameworks.Carbon darwin.apple_sdk.frameworks.Cocoa ]; </del> <ins> ++ stdenv.lib.optionals stdenv.isDarwin [ darwin.libobjc darwin.apple_sdk.libs.xpc darwin.apple_sdk.frameworks.Foundation darwin.bootstrap_cmds darwin.apple_sdk.frameworks.Carbon darwin.apple_sdk.frameworks.Cocoa darwin.cf-private ]; </ins> CXXFLAGS = "-fno-rtti"; hardeningDisable = [ "format" ];
Code change:
Run , observe: Please run and paste the results.
Very weird... It must have come in from a recent update. You can find libLLDB in the lldb derivation:
/cc

Related discussion:
text: postPatch = optionalString stdenv.isDarwin '' substituteInPlace cmake/modules/AddLLVM.cmake  <del> --replace 'set(_install_name_dir INSTALL_NAME_DIR "@rpath")' "set(_install_name_dir INSTALL_NAME_DIR "$lib/lib")"  </del> <ins> --replace 'set(_install_name_dir INSTALL_NAME_DIR "@rpath")' "set(_install_name_dir)"  </ins> --replace 'set(_install_rpath "@loader_path/../lib" ''${extra_libdir})' "" '' # Patch llvm-config to return correct library path based on --link-{shared,static}.
Code change:
On running I get: Add to and run. system: host os: multi-user?: sandbox: version: channels(lev): channels(root): nixpkgs:
Well, the output has at least changed a bit:
my pull request fixes the . It broke down because the package had moved to but requires . But according to the browser is discontinued and `firefox-esr-5.2' is marked as unsecure so I would rather advocate for removing this package altogether.

Related discussion:
text: <del> { stdenv, fetchgit, unzip, firefox-esr, makeWrapper }: </del> <ins> { stdenv, fetchgit, unzip, firefox-esr-52, makeWrapper }: </ins> stdenv.mkDerivation rec { pkgname = "conkeror"; version = "1.0.4"; name = "${pkgname}-${version}"; src = fetchgit { url = git://repo.or.cz/conkeror.git; rev = "refs/tags/${version}";
Code change:
On running I get: Add to and run. system: host os: multi-user?: sandbox: version: channels(lev): channels(root): nixpkgs:
Well, the output has at least changed a bit:
my pull request fixes the . It broke down because the package had moved to but requires . But according to the browser is discontinued and `firefox-esr-5.2' is marked as unsecure so I would rather advocate for removing this package altogether.

Related discussion:
text: mkdir -p $out/libexec/conkeror cp -r * $out/libexec/conkeror <del> makeWrapper ${firefox-esr}/bin/firefox $out/bin/conkeror  </del> <ins> makeWrapper ${firefox-esr-52}/bin/firefox $out/bin/conkeror  </ins> --add-flags "-app $out/libexec/conkeror/application.ini" '';
Code change:
Whenever I try to install both and I get a collision error because both derivations contain : Do files need to be in the packages? The same problem can be reproduced by building a environment where both and are in:
I have the same problem between and .

Related discussion:
text: patchShebangs meson_post_install.py ''; <del> postInstall = '' rm $out/share/applications/mimeinfo.cache ''; </del> meta = { homepage = https://fontmanager.github.io/; description = "Simple font management for GTK+ desktop environments";
Code change:
Whenever I try to install both and I get a collision error because both derivations contain : Do files need to be in the packages? The same problem can be reproduced by building a environment where both and are in:
I have the same problem between and .

Related discussion:
text: "-Dsystemdunitdir=lib/systemd/system" ]; <del> postInstall = '' rm $out/share/applications/mimeinfo.cache ''; </del> passthru = { updateScript = gnome3.updateScript { packageName = pname;
Code change:
Whenever I try to install both and I get a collision error because both derivations contain : Do files need to be in the packages? The same problem can be reproduced by building a environment where both and are in:
I have the same problem between and .

Related discussion:
text: nativeBuildInputs = [ pkgconfig ]; buildInputs = [ glib libintl ]; <ins> setupHook = ./setup-hook.sh; </ins> meta = { homepage = http://www.freedesktop.org/wiki/Software/desktop-file-utils; description = "Command line utilities for working with .desktop files";
Code change:
Whenever I try to install both and I get a collision error because both derivations contain : Do files need to be in the packages? The same problem can be reproduced by building a environment where both and are in:
I have the same problem between and .

Related discussion:
text: <ins> # Remove mimeinfo cache mimeinfoPreFixupPhase() { rm -f $out/share/applications/mimeinfo.cache } preFixupPhases="$preFixupPhases mimeinfoPreFixupPhase" </ins>
Code change:
Commit from updated the default version of the GNU Privacy Guard a.k.a. GPG to version 2.1. Unfortunately, this update broke the gpg-related tests of , , apparently because there is some subtle change in the behavior of the GPG 1.x compatibility layer (git-annex relies on rather than using gpg2 directly). To remedy that issue, I fixed to use version 2.0 in . This is no good solution, unfortunately, because now people who rely on `gnupg1' end up having a version of GnuPG 2.0 in their profile that cannot talk to the gpg-agent from version 2.1, which happens to be the one that's installed in the system by default. In it's current state, gpg1 does not work reliably in NIxOS. To work around this issue, I would suggest that we revert to version 2.0 until we've had time to figure out what exactly has changed between versions 2.1 and 2.0 and why this affects .
FYI: Another thing I came across, due to a broken clawsmail pgp, was that the handling of gpg-agent differs from version 2.0 . GnuPG 2.1 do not use GPGAGENTINFO anymore. Instead it search for the gpg-agent socket in
For now at least, setting GPGAGENTINFO to $ seems to make claws-mail work.

Related discussion:
text: services.openssh.enable = false; services.lshd.enable = true; programs.ssh.startAgent = false; <del> services.xserver.startGnuPGAgent = true; </del> # TODO: GNU dico. # TODO: GNU Inetutils' inetd.
Code change:
Commit from updated the default version of the GNU Privacy Guard a.k.a. GPG to version 2.1. Unfortunately, this update broke the gpg-related tests of , , apparently because there is some subtle change in the behavior of the GPG 1.x compatibility layer (git-annex relies on rather than using gpg2 directly). To remedy that issue, I fixed to use version 2.0 in . This is no good solution, unfortunately, because now people who rely on `gnupg1' end up having a version of GnuPG 2.0 in their profile that cannot talk to the gpg-agent from version 2.1, which happens to be the one that's installed in the system by default. In it's current state, gpg1 does not work reliably in NIxOS. To work around this issue, I would suggest that we revert to version 2.0 until we've had time to figure out what exactly has changed between versions 2.1 and 2.0 and why this affects .
FYI: Another thing I came across, due to a broken clawsmail pgp, was that the handling of gpg-agent differs from version 2.0 . GnuPG 2.1 do not use GPGAGENTINFO anymore. Instead it search for the gpg-agent socket in
For now at least, setting GPGAGENTINFO to $ seems to make claws-mail work.

Related discussion:
text: (mkRemovedOptionModule [ "services" "openvpn" "enable" ]) (mkRemovedOptionModule [ "services" "printing" "cupsFilesConf" ]) (mkRemovedOptionModule [ "services" "printing" "cupsdConf" ]) <ins> (mkRemovedOptionModule [ "services" "xserver" "startGnuPGAgent" ]) </ins> ]; }
Code change:
Commit from updated the default version of the GNU Privacy Guard a.k.a. GPG to version 2.1. Unfortunately, this update broke the gpg-related tests of , , apparently because there is some subtle change in the behavior of the GPG 1.x compatibility layer (git-annex relies on rather than using gpg2 directly). To remedy that issue, I fixed to use version 2.0 in . This is no good solution, unfortunately, because now people who rely on `gnupg1' end up having a version of GnuPG 2.0 in their profile that cannot talk to the gpg-agent from version 2.1, which happens to be the one that's installed in the system by default. In it's current state, gpg1 does not work reliably in NIxOS. To work around this issue, I would suggest that we revert to version 2.0 until we've had time to figure out what exactly has changed between versions 2.1 and 2.0 and why this affects .
FYI: Another thing I came across, due to a broken clawsmail pgp, was that the handling of gpg-agent differs from version 2.0 . GnuPG 2.1 do not use GPGAGENTINFO anymore. Instead it search for the gpg-agent socket in
For now at least, setting GPGAGENTINFO to $ seems to make claws-mail work.

Related discussion:
text: fi ''} <del> ${optionalString cfg.startGnuPGAgent '' if test -z "$SSH_AUTH_SOCK"; then # Restart this script as a child of the GnuPG agent. exec "${pkgs.gnupg}/bin/gpg-agent"                          --enable-ssh-support --daemon                              --pinentry-program "${pkgs.pinentry}/bin/pinentry-gtk-2"   --write-env-file "$HOME/.gpg-agent-info"                   "$0" "$sessionType" fi ''} </del> # Handle being called by kdm. if test "''${1:0:1}" = /; then eval exec "$1"; fi
Code change:
Commit from updated the default version of the GNU Privacy Guard a.k.a. GPG to version 2.1. Unfortunately, this update broke the gpg-related tests of , , apparently because there is some subtle change in the behavior of the GPG 1.x compatibility layer (git-annex relies on rather than using gpg2 directly). To remedy that issue, I fixed to use version 2.0 in . This is no good solution, unfortunately, because now people who rely on `gnupg1' end up having a version of GnuPG 2.0 in their profile that cannot talk to the gpg-agent from version 2.1, which happens to be the one that's installed in the system by default. In it's current state, gpg1 does not work reliably in NIxOS. To work around this issue, I would suggest that we revert to version 2.0 until we've had time to figure out what exactly has changed between versions 2.1 and 2.0 and why this affects .
FYI: Another thing I came across, due to a broken clawsmail pgp, was that the handling of gpg-agent differs from version 2.0 . GnuPG 2.1 do not use GPGAGENTINFO anymore. Instead it search for the gpg-agent socket in
For now at least, setting GPGAGENTINFO to $ seems to make claws-mail work.

Related discussion:
text: ''; }; <del> startGnuPGAgent = mkOption { type = types.bool; default = false; description = '' Whether to start the GnuPG agent when you log in.  The GnuPG agent remembers private keys for you so that you don't have to type in passphrases every time you make an SSH connection or sign/encrypt data.  Use <command>ssh-add</command> to add a key to the agent. ''; }; </del> startDbusSession = mkOption { type = types.bool; default = true;
Code change:
Commit from updated the default version of the GNU Privacy Guard a.k.a. GPG to version 2.1. Unfortunately, this update broke the gpg-related tests of , , apparently because there is some subtle change in the behavior of the GPG 1.x compatibility layer (git-annex relies on rather than using gpg2 directly). To remedy that issue, I fixed to use version 2.0 in . This is no good solution, unfortunately, because now people who rely on `gnupg1' end up having a version of GnuPG 2.0 in their profile that cannot talk to the gpg-agent from version 2.1, which happens to be the one that's installed in the system by default. In it's current state, gpg1 does not work reliably in NIxOS. To work around this issue, I would suggest that we revert to version 2.0 until we've had time to figure out what exactly has changed between versions 2.1 and 2.0 and why this affects .
FYI: Another thing I came across, due to a broken clawsmail pgp, was that the handling of gpg-agent differs from version 2.0 . GnuPG 2.1 do not use GPGAGENTINFO anymore. Instead it search for the gpg-agent socket in
For now at least, setting GPGAGENTINFO to $ seems to make claws-mail work.

Related discussion:
text: in optional (driver != null) ({ inherit name; driverName = name; } // driver)); assertions = <del> [ { assertion = !(config.programs.ssh.startAgent && cfg.startGnuPGAgent); message = '' The OpenSSH agent and GnuPG agent cannot be started both. Please choose between ‘programs.ssh.startAgent’ and ‘services.xserver.startGnuPGAgent’. ''; } { assertion = config.security.polkit.enable; </del> <ins> [ { assertion = config.security.polkit.enable; </ins> message = "X11 requires Polkit to be enabled (‘security.polkit.enable = true’)."; } ];
Code change:
Commit from updated the default version of the GNU Privacy Guard a.k.a. GPG to version 2.1. Unfortunately, this update broke the gpg-related tests of , , apparently because there is some subtle change in the behavior of the GPG 1.x compatibility layer (git-annex relies on rather than using gpg2 directly). To remedy that issue, I fixed to use version 2.0 in . This is no good solution, unfortunately, because now people who rely on `gnupg1' end up having a version of GnuPG 2.0 in their profile that cannot talk to the gpg-agent from version 2.1, which happens to be the one that's installed in the system by default. In it's current state, gpg1 does not work reliably in NIxOS. To work around this issue, I would suggest that we revert to version 2.0 until we've had time to figure out what exactly has changed between versions 2.1 and 2.0 and why this affects .
FYI: Another thing I came across, due to a broken clawsmail pgp, was that the handling of gpg-agent differs from version 2.0 . GnuPG 2.1 do not use GPGAGENTINFO anymore. Instead it search for the gpg-agent socket in
For now at least, setting GPGAGENTINFO to $ seems to make claws-mail work.

Related discussion:
text: gnupatch = callPackage ../tools/text/gnupatch { }; gnupg1orig = callPackage ../tools/security/gnupg/1.nix { }; gnupg1compat = callPackage ../tools/security/gnupg/1compat.nix { }; <del> # use config.packageOverrides if you prefer original gnupg1 gnupg1 = gnupg1compat; </del> <ins> gnupg1 = gnupg1compat;    # use config.packageOverrides if you prefer original gnupg1 </ins> gnupg20 = callPackage ../tools/security/gnupg/20.nix { }; <del> gnupg21 = lowPrio (callPackage ../tools/security/gnupg/21.nix { }); gnupg = gnupg20; </del> <ins> gnupg21 = callPackage ../tools/security/gnupg/21.nix { }; gnupg = gnupg21; </ins> gnuplot = callPackage ../tools/graphics/gnuplot { qt = qt4; };
Code change:
repstopdf does not seem to be included anywhere in texlive or ghostscript. This means that texlive can't include .eps figures in pdf output.
Thanks!

Related discussion:
text: ln -sv "$(realpath $s)" "$out/bin/$tName" # wrapped below done ) <ins> '' + # A hacky way to provide repstopdf #  * Copy is done to have a correct "$0" so that epstopdf enables the restricted mode #  * ./bin/repstopdf needs to be a symlink to be processed by wrapBin '' if [[ -e ./bin/epstopdf ]]; then cp $(realpath ./bin/epstopdf) ./share/texmf/scripts/repstopdf ln -s "$out"/share/texmf/scripts/repstopdf ./bin/repstopdf fi '' + # finish up the wrappers '' </ins> rm "$out"/bin/*-sys wrapBin '' + <ins> # Perform a small test to verify that the restricted mode get enabled when # needed (detected by checking if it disallows --gscmd) '' if [[ -e ./bin/epstopdf ]]; then echo "Testing restricted mode for {,r}epstopdf" ! (epstopdf --gscmd echo /dev/null 2>&1 || true) | grep forbidden (repstopdf --gscmd echo /dev/null 2>&1 || true) | grep forbidden fi '' + </ins> # TODO: a context trigger https://www.preining.info/blog/2015/06/debian-tex-live-2015-the-new-layout/ # http://wiki.contextgarden.net/ConTeXt_Standalone#Unix-like_platforms_.28Linux.2FMacOS_X.2FFreeBSD.2FSolaris.29
Code change:
dvc () is version control system for "biggish" data and code It integrates with Git but offers a solution for managing and versioning big data sets that come with code commits. Related technology () are like git annex and git lfs. If nobody gets around to this, I may work on this later.
Need to first package the Python dependencies nanotime, grandalf and asciimatics dependencies.
The extra dependencies: These will need to be packaged as optional dependencies and provided as a separate alias. Something like and or something like that. What are some good suggestions for names? The and don't appear to be packaged.
Google cloud storage is packaged already here: However is still not packaged as is though. The pypi is:
Initial PR for azure-storage:
Inital PR for nanotime:
Initial PR for grandalf:
Initial PR for asciimatics:
For the smaller dependent packages that are unrelated it would have been preferred to group them in one pr.
However too late now :smile: so just to know in the future.
Yea that would have been better as I could have then worked on dvc commit as well, but now that all dependent packages are separated between different branches, that's not possible. So I'm just waiting for those to be merged to master.
Initial PR for dvc:

Related discussion:
text: <ins> { lib , python3Packages , fetchFromGitHub , enableGoogle ? false , enableAWS ? false , enableAzure ? false , enableSSH ? false }: with python3Packages; buildPythonApplication rec { pname = "dvc"; version = "0.24.3"; # PyPi only has wheel src = fetchFromGitHub { owner = "iterative"; repo = "dvc"; rev = version; sha256 = "1wqq4i23hppilp20fx5a5nj93xwf3wwwr2f8aasvn6jkv2l22vpl"; }; propagatedBuildInputs = [ ply configparser zc_lockfile future colorama configobj networkx pyyaml GitPython setuptools nanotime pyasn1 schema jsonpath_rw requests grandalf asciimatics distro appdirs ] ++ lib.optional enableGoogle google_cloud_storage ++ lib.optional enableAWS boto3 ++ lib.optional enableAzure azure-storage-blob ++ lib.optional enableSSH paramiko; # tests require access to real cloud services # nix build tests have to be isolated and run locally doCheck = false; patches = [ ./dvc-daemon.patch ]; postPatch = '' substituteInPlace dvc/daemon.py --subst-var-by dvc "$out/bin/dcv" ''; meta = with lib; { description = "Version Control System for Machine Learning Projects"; license = licenses.asl20; homepage = https://dvc.org; maintainers = with maintainers; [ cmcdragonkai ]; }; } </ins>
Code change:
dvc () is version control system for "biggish" data and code It integrates with Git but offers a solution for managing and versioning big data sets that come with code commits. Related technology () are like git annex and git lfs. If nobody gets around to this, I may work on this later.
Need to first package the Python dependencies nanotime, grandalf and asciimatics dependencies.
The extra dependencies: These will need to be packaged as optional dependencies and provided as a separate alias. Something like and or something like that. What are some good suggestions for names? The and don't appear to be packaged.
Google cloud storage is packaged already here: However is still not packaged as is though. The pypi is:
Initial PR for azure-storage:
Inital PR for nanotime:
Initial PR for grandalf:
Initial PR for asciimatics:
For the smaller dependent packages that are unrelated it would have been preferred to group them in one pr.
However too late now :smile: so just to know in the future.
Yea that would have been better as I could have then worked on dvc commit as well, but now that all dependent packages are separated between different branches, that's not possible. So I'm just waiting for those to be merged to master.
Initial PR for dvc:

Related discussion:
text: <ins> diff --git a/dvc/daemon.py b/dvc/daemon.py index 1d67a37..7ce6fde 100644 --- a/dvc/daemon.py +++ b/dvc/daemon.py @@ -67,14 +67,8 @@ def daemon(args): Args: args (list): list of arguments to append to `dvc daemon` command. """ -    cmd = [sys.executable] -    if not is_binary(): -        cmd += ['-m', 'dvc'] -    cmd += ['daemon', '-q'] + args - -    env = fix_env() -    file_path = os.path.abspath(inspect.stack()[0][1]) -    env['PYTHONPATH'] = os.path.dirname(os.path.dirname(file_path)) +    cmd = [ "@dvc@" , "daemon", "-q"] + args +    env = None logger.debug("Trying to spawn '{}' with env '{}'".format(cmd, env)) </ins>
Code change:
dvc () is version control system for "biggish" data and code It integrates with Git but offers a solution for managing and versioning big data sets that come with code commits. Related technology () are like git annex and git lfs. If nobody gets around to this, I may work on this later.
Need to first package the Python dependencies nanotime, grandalf and asciimatics dependencies.
The extra dependencies: These will need to be packaged as optional dependencies and provided as a separate alias. Something like and or something like that. What are some good suggestions for names? The and don't appear to be packaged.
Google cloud storage is packaged already here: However is still not packaged as is though. The pypi is:
Initial PR for azure-storage:
Inital PR for nanotime:
Initial PR for grandalf:
Initial PR for asciimatics:
For the smaller dependent packages that are unrelated it would have been preferred to group them in one pr.
However too late now :smile: so just to know in the future.
Yea that would have been better as I could have then worked on dvc commit as well, but now that all dependent packages are separated between different branches, that's not possible. So I'm just waiting for those to be merged to master.
Initial PR for dvc:

Related discussion:
text: duperemove = callPackage ../tools/filesystems/duperemove { }; <ins> dvc = callPackage ../applications/version-management/dvc { }; dvc-with-remotes = callPackage ../applications/version-management/dvc { enableGoogle = true; enableAWS = true; enableAzure = true; enableSSH = true; }; </ins> dylibbundler = callPackage ../tools/misc/dylibbundler { }; dynamic-colors = callPackage ../tools/misc/dynamic-colors { };
Code change:
Our current legacy nvidia driver of the 340 branch does not work with kernel version 4.19.2: NixOS is currently on the 340.104 version, but upstream is on 340.107: I hope that updating to 340.107 resolves the issue, but I don't understand how to update the different checksums for the nvidia driver. /nix/store/kic17fw8wil74k04kzh3dha43izrr9j3-bash-interactive-4.4-p23-dev copying path '/nix/store/kic17fw8wil74k04kzh3dha43izrr9j3-bash-interactive-4.4-p23-dev' from ''... system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
The hashes are located at and can be generated like so: Please try:
Thanks alot for giving me a hand and teaching me how to get those four hashes! :+1: Updating to 340.107 indeed resolves this issue. PR:

Related discussion:
text: beta = stable; legacy_340 = generic { <del> version = "340.104"; sha256_32bit = "1l8w95qpxmkw33c4lsf5ar9w2fkhky4x23rlpqvp1j66wbw1b473"; sha256_64bit = "18k65gx6jg956zxyfz31xdp914sq3msn665a759bdbryksbk3wds"; settingsSha256 = "1vvpqimvld2iyfjgb9wvs7ca0b0f68jzfdpr0icbyxk4vhsq7sxk"; persistencedSha256 = "0zqws2vsrxbxhv6z0nn2galnghcsilcn3s0f70bpm6jqj9wzy7x8"; </del> <ins> version = "340.107"; sha256_32bit = "0mh83affz6bim26ws7kkwwcfj2s6vkdy4d45hifsbshr82qd52wd"; sha256_64bit = "0pv9yv3x0kg9hfkmc50xb54ahxkbnyy2vyy4hj2h0s6m9sb5kqz3"; settingsSha256 = "1rgaa24acdyqa1rqrx56293vxpskr792njqqpigqmps04llsx703"; persistencedSha256 = "0nwv6kh4gxgy80x1zs6gcg5hy3amg25xhsfa2v4mwqa36sblxz6l"; </ins> useGLVND = false; patches = maybePatch_drm_legacy ++ [ ./vm_operations_struct-fault.patch ];