jiebi/CodeConvo huggingface dataset:
Code change:
I'm trying to use from nixpkgs on my laptop and use remote builders (buildbarn). This fails due to patches that are applied in nixpkgs. Vanilla Bazel has a hardcoded fallback path for bash () . This has the downside of not producing a working fallback for (bash from nixpkgs will default initialize as ). The workaround for this is to default initialize the path variables somewhere else. Currently, this is done . This works fine for local execution, since this is where this function is called. However, this function is never called for remote execution (it is a hack to override things for the local execution environment only). So when using Bazel from nixpkgs locally and enabling remote execution, the shell is set to a bash from nixpkgs during the analysis phase but the variable is explicitly left unset by many actions, leading to the PATH in bash being and resulting in errors when executing tools in a script. I think there are two possible solutions: when using remote execution, do not replace the hardcoded (this is probably not a great fix since it only works for FHS executors) instead of replacing with a regular bash from nixpkgs, add a little helper script that adds shell utils to . This way, any shell rule created by bazel has a minimal set of tools. use when turning on remote execution. This has the downside of only working when the remote builder has a shell in that path. See this for a detailed reproducer: Using bazel from nixpkgs should work with remote execution. Using this version of bazel with remote execution is becoming more viable due to <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- [^1]: [^2]:
got reverted, I'll reopen it.
Could we also remove the related patch here -, or is it still needed for some reason ?
To the best of my understanding, it should be sufficient to use a prepared bash (with tools in the PATH) and remove the patch you mentioned. Probably still a good idea to test this in practice!

Related discussion:
text: in lib.optionalString stdenv.hostPlatform.isDarwin darwinPatches + genericPatches; <del> buildInputs = [buildJdk] ++ defaultShellUtils; </del> <ins> buildInputs = [buildJdk bashWithDefaultShellUtils] ++ defaultShellUtils; </ins> # when a command can’t be found in a bazel build, you might also # need to add it to `defaultShellPath`.
Code change:
Building the python 3 protobuf package fails for me on macOS. Digging in (by launching ), the cause seems to be that calls instead of . The call above fails, but the same call works after replacing by . Similarly, works fine. That in turn matters because of in the / wrappers, because the system include path is missing in the case. System: mac OS 10.12.5 Nix version: nix-env (Nix) 1.11.8 Nixpkgs version: "17.09pre108299." Sandboxing enabled: grep: No such file or directory :) When digging in, I used a checkout of nixpkgs with hash , but it seems to make no difference.
seems related.
uses Python on Darwin and might help here.
I've had a look at the python setup tools: The relevant line is (rather: appears to be, I haven't tested this) which causes C++ source files to be compile with . Not sure whether this is the right or wrong thing to do... I see two reasonable ways to fix this bug, in a more principled way than : python distutils to compile C++ files using nixpkg to treat like with respect to and friends If 1. is the right thing to do, it might still be nice to work around the bug in another way for now.
I've also been bitten by this problem once: The core problem is that setuptools pretty much ignores the difference between CC and CXX. This however is not a problem on a standard mac xcode installation, as both and link the C++ standard library there. However our nix-clang does not link against the C++ standard library (and probably should not) and that's why you will encounter this problem every once in a while when dealing with darwin and c++ python extensions. I'm not an expert on the darwin-stdenv, so I wouldn't know how to fix this in a way that does not require hacking our ways around that problem. To hack around this problem you simply have to grep the pythonPackages for . There are a few packages that use a workaround that involves adding to the C-compile flags: See e.g. here:
However our nix-clang does not link against the C++ standard library (and probably should not) and that's why you will encounter this problem every once in a while when dealing with darwin and c++ python extensions. any clue how to solve this issue?
The problem does not seem all-too widespread, but there are a few instances:
Any reason we can't just change to use ? Seems like it would work on Linux just fine, and fix a bunch of other stuff.
I knew this was an issue in general (), but assumed the problem was something more complicated.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Related discussion:
text: { stdenv, python, buildPythonPackage <del> , protobuf, google_apputils, pyext </del> <ins> , protobuf, google_apputils, pyext, libcxx </ins> , disabled, doCheck ? true }: with stdenv.lib;
Code change:
Building the python 3 protobuf package fails for me on macOS. Digging in (by launching ), the cause seems to be that calls instead of . The call above fails, but the same call works after replacing by . Similarly, works fine. That in turn matters because of in the / wrappers, because the system include path is missing in the case. System: mac OS 10.12.5 Nix version: nix-env (Nix) 1.11.8 Nixpkgs version: "17.09pre108299." Sandboxing enabled: grep: No such file or directory :) When digging in, I used a checkout of nixpkgs with hash , but it seems to make no difference.
seems related.
uses Python on Darwin and might help here.
I've had a look at the python setup tools: The relevant line is (rather: appears to be, I haven't tested this) which causes C++ source files to be compile with . Not sure whether this is the right or wrong thing to do... I see two reasonable ways to fix this bug, in a more principled way than : python distutils to compile C++ files using nixpkg to treat like with respect to and friends If 1. is the right thing to do, it might still be nice to work around the bug in another way for now.
I've also been bitten by this problem once: The core problem is that setuptools pretty much ignores the difference between CC and CXX. This however is not a problem on a standard mac xcode installation, as both and link the C++ standard library there. However our nix-clang does not link against the C++ standard library (and probably should not) and that's why you will encounter this problem every once in a while when dealing with darwin and c++ python extensions. I'm not an expert on the darwin-stdenv, so I wouldn't know how to fix this in a way that does not require hacking our ways around that problem. To hack around this problem you simply have to grep the pythonPackages for . There are a few packages that use a workaround that involves adding to the C-compile flags: See e.g. here:
However our nix-clang does not link against the C++ standard library (and probably should not) and that's why you will encounter this problem every once in a while when dealing with darwin and c++ python extensions. any clue how to solve this issue?
The problem does not seem all-too widespread, but there are a few instances:
Any reason we can't just change to use ? Seems like it would work on Linux just fine, and fix a bunch of other stuff.
I knew this was an issue in general (), but assumed the problem was something more complicated.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Related discussion:
text: inherit (protobuf) name src; inherit disabled doCheck; <ins> # work around python distutils compiling C++ with $CC NIX_CFLAGS_COMPILE = stdenv.lib.optionalString stdenv.isDarwin "-I${libcxx}/include/c++/v1"; </ins> propagatedBuildInputs = [ protobuf google_apputils ]; buildInputs = [ google_apputils pyext ];
Code change:
Project description Gruvbox Plus icon pack for Linux desktops based on Gruvbox color theme. Metadata homepage URL: source URL: license: GPL-3.0 platforms: linux

Related discussion:
text: githubId = 2147649; name = "Euan Kemp"; }; <ins> eureka-cpu = { email = "github.eureka@gmail.com"; github = "eureka-cpu"; githubId = 57543709; name = "Chris O'Brien"; }; </ins> evalexpr = { name = "Jonathan Wilkins"; email = "nixos@wilkins.tech";
Code change:
Project description Gruvbox Plus icon pack for Linux desktops based on Gruvbox color theme. Metadata homepage URL: source URL: license: GPL-3.0 platforms: linux

Related discussion:
text: <ins> { lib , stdenvNoCC , fetchFromGitHub , gtk3 , breeze-icons , gnome-icon-theme , hicolor-icon-theme }: stdenvNoCC.mkDerivation { pname = "gruvbox-plus-icons"; version = "unstable-2023-12-07"; src = fetchFromGitHub { owner = "SylEleuth"; repo = "gruvbox-plus-icon-pack"; rev = "f3109979fe93b31ea14eb2d5c04247a895302ea0"; sha256 = "sha256-EijTEDkPmcDcMhCuL6fOWjU9eXFUwmeOEwfGlxadb1U="; }; nativeBuildInputs = [ gtk3 ]; propagatedBuildInputs = [ breeze-icons gnome-icon-theme hicolor-icon-theme ]; installPhase = '' runHook preInstall mkdir -p $out/share/icons cp -r Gruvbox-Plus-Dark $out/share/icons/ gtk-update-icon-cache $out/share/icons/Gruvbox-Plus-Dark runHook postInstall ''; dontDropIconThemeCache = true; dontBuild = true; dontConfigure = true; meta = with lib; { description = "Icon pack for Linux desktops based on the Gruvbox color scheme"; homepage = "https://github.com/SylEleuth/gruvbox-plus-icon-pack"; license = licenses.gpl3Only; platforms = platforms.linux; maintainers = with maintainers; [ eureka-cpu RGBCube ]; }; } </ins>
Code change:
Currently we build with support for . Sonnet typically looks in for dictionaries That means it won't be able to find any dictionaries and thus spellchecking won't work.
Is this still a problem? It seems that hunspell paths are not hardcoded in hunspelldict.h anymore: But they are still hardcoded in
Yes, this is still a problem. It seems like we should disable hunspell and use aspell, which is configured correctly in NixOS.
I marked this as stale due to inactivity. &rarr;
I marked this with "good first bug" because I think we need only to change to depend on , and do some testing.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Related discussion:
text: { mkDerivation, lib , extra-cmake-modules <del> , hunspell, qtbase, qttools </del> <ins> , aspell, qtbase, qttools </ins> }: mkDerivation {
Code change:
Currently we build with support for . Sonnet typically looks in for dictionaries That means it won't be able to find any dictionaries and thus spellchecking won't work.
Is this still a problem? It seems that hunspell paths are not hardcoded in hunspelldict.h anymore: But they are still hardcoded in
Yes, this is still a problem. It seems like we should disable hunspell and use aspell, which is configured correctly in NixOS.
I marked this as stale due to inactivity. &rarr;
I marked this with "good first bug" because I think we need only to change to depend on , and do some testing.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Related discussion:
text: broken = builtins.compareVersions qtbase.version "5.7.0" < 0; }; nativeBuildInputs = [ extra-cmake-modules ]; <del> buildInputs = [ hunspell qttools ]; </del> <ins> buildInputs = [ aspell qttools ]; </ins> propagatedBuildInputs = [ qtbase ]; }
Code change:
Lily and I talked about this in Matrix, this is the requested issue. Basically it all narrows down to this package lock: Steps to reproduce the behavior: it it hangs forever lock it works It should either give an error or just work. If it helps narrowing the npm version down, the package- was created in September of 2020 and was last changed in September of 2021.
To clarify a bit, this isn't something specific to older lockfiles, it just looks like there is a version spec format that our fetcher does not currently support, but probably should

Related discussion:
text: packages.into_par_iter().try_for_each(|package| { eprintln!("{}", package.name); <del> let tarball = package.tarball()?; </del> <ins> let tarball = package .tarball() .map_err(|e| anyhow!("couldn't fetch {} at {}: {e:?}", package.name, package.url))?; </ins> let integrity = package.integrity().map(ToString::to_string); cache
Code change:
Lily and I talked about this in Matrix, this is the requested issue. Basically it all narrows down to this package lock: Steps to reproduce the behavior: it it hangs forever lock it works It should either give an error or just work. If it helps narrowing the npm version down, the package- was created in September of 2020 and was last changed in September of 2021.
To clarify a bit, this isn't something specific to older lockfiles, it just looks like there is a version spec format that our fetcher does not currently support, but probably should

Related discussion:
text: } if let UrlOrString::Url(v) = &package.version { <del> for (scheme, host) in [ ("github", "github.com"), ("bitbucket", "bitbucket.org"), ("gitlab", "gitlab.com"), ] { if v.scheme() == scheme { package.version = { let mut new_url = initial_url.clone(); new_url.set_host(Some(host))?; if v.path().ends_with(".git") { new_url.set_path(v.path()); } else { new_url.set_path(&format!("{}.git", v.path())); } new_url.set_fragment(v.fragment()); UrlOrString::Url(new_url) }; break; </del> <ins> if v.scheme() == "npm" { if let Some(UrlOrString::Url(ref url)) = &package.resolved { package.version = UrlOrString::Url(url.clone()); } } else { for (scheme, host) in [ ("github", "github.com"), ("bitbucket", "bitbucket.org"), ("gitlab", "gitlab.com"), ] { if v.scheme() == scheme { package.version = { let mut new_url = initial_url.clone(); new_url.set_host(Some(host))?; if v.path().ends_with(".git") { new_url.set_path(v.path()); } else { new_url.set_path(&format!("{}.git", v.path())); } new_url.set_fragment(v.fragment()); UrlOrString::Url(new_url) }; break; } </ins> } } }
Code change:
Lily and I talked about this in Matrix, this is the requested issue. Basically it all narrows down to this package lock: Steps to reproduce the behavior: it it hangs forever lock it works It should either give an error or just work. If it helps narrowing the npm version down, the package- was created in September of 2020 and was last changed in September of 2021.
To clarify a bit, this isn't something specific to older lockfiles, it just looks like there is a version spec format that our fetcher does not currently support, but probably should

Related discussion:
text: #[cfg(test)] mod tests { use super::{ <del> get_initial_url, to_new_packages, Hash, HashCollection, OldPackage, Package, UrlOrString, </del> <ins> get_initial_url, packages, to_new_packages, Hash, HashCollection, OldPackage, Package, UrlOrString, </ins> }; use std::{ cmp::Ordering,
Code change:
Lily and I talked about this in Matrix, this is the requested issue. Basically it all narrows down to this package lock: Steps to reproduce the behavior: it it hangs forever lock it works It should either give an error or just work. If it helps narrowing the npm version down, the package- was created in September of 2020 and was last changed in September of 2021.
To clarify a bit, this isn't something specific to older lockfiles, it just looks like there is a version spec format that our fetcher does not currently support, but probably should

Related discussion:
text: Some(Hash(String::from("sha512-foo"))) ); } <ins> #[test] fn parse_lockfile_correctly() { let packages = packages( r#"{ "name": "node-ddr", "version": "1.0.0", "lockfileVersion": 1, "requires": true, "dependencies": { "string-width-cjs": { "version": "npm:string-width@4.2.3", "resolved": "https://registry.npmjs.org/string-width/-/string-width-4.2.3.tgz", "integrity": "sha512-wKyQRQpjJ0sIp62ErSZdGsjMJWsap5oRNihHhu6G7JVO/9jIB6UyevL+tXuOqrng8j/cxKTWyWUwvSTriiZz/g==", "requires": { "emoji-regex": "^8.0.0", "is-fullwidth-code-point": "^3.0.0", "strip-ansi": "^6.0.1" } } } }"#).unwrap(); assert_eq!(packages.len(), 1); assert_eq!( packages[0].resolved, Some(UrlOrString::Url( Url::parse("https://registry.npmjs.org/string-width/-/string-width-4.2.3.tgz") .unwrap() )) ); } </ins> }
Code change:
Package name: gdtoolkit Latest released version: 4.1.0 <!-- Search your package here: --- Current version on the unstable channel: 3.3.1 Current version on the stable/release channel: 3.3.1 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers It's a bit of an odd situation because both Godot 3 and 4 are in use, so maybe this one should be renamed to gdtoolkit3 or the opposite for the time being. Haven't had any success yet trying to override the package on my own. <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR.

Related discussion:
text: <ins> { lib , python3 , fetchFromGitHub }: let python = python3.override { packageOverrides = self: super: { lark = super.lark.overridePythonAttrs (old: rec { # gdtoolkit needs exactly this lark version version = "0.8.0"; src = fetchFromGitHub { owner = "lark-parser"; repo = "lark"; rev = version; hash = "sha256-KN9buVlH8hJ8t0ZP5yefeYM5vH5Gg7a7TEDGKJYpozs="; fetchSubmodules = true; }; patches = [ ]; }); }; }; in python.pkgs.buildPythonApplication rec { pname = "gdtoolkit3"; version = "3.5.0"; # If we try to get using fetchPypi it requires GeoIP (but the package dont has that dep!?) src = fetchFromGitHub { owner = "Scony"; repo = "godot-gdscript-toolkit"; rev = version; hash = "sha256-cMGD5Xdf9ElS1NT7Q0NPB//EvUO0MI0VTtps5JRisZ4="; }; disabled = python.pythonOlder "3.7"; propagatedBuildInputs = with python.pkgs; [ docopt lark pyyaml setuptools ]; doCheck = true; nativeCheckInputs = with python.pkgs; [ pytestCheckHook hypothesis ]; preCheck = '' # The tests want to run the installed executables export PATH=$out/bin:$PATH # gdtoolkit tries to write cache variables to $HOME/.cache export HOME=$TMP ''; # The tests are not working on NixOS disabledTests = [ "test_cc_on_empty_file_succeeds" "test_cc_on_file_with_single_function_succeeds" ]; pythonImportsCheck = [ "gdtoolkit" "gdtoolkit.formatter" "gdtoolkit.linter" "gdtoolkit.parser" ]; meta = with lib; { description = "Independent set of tools for working with Godot's GDScript - parser, linter and formatter"; homepage = "https://github.com/Scony/godot-gdscript-toolkit"; license = licenses.mit; maintainers = with maintainers; [ shiryel tmarkus ]; }; } </ins>
Code change:
Package name: gdtoolkit Latest released version: 4.1.0 <!-- Search your package here: --- Current version on the unstable channel: 3.3.1 Current version on the stable/release channel: 3.3.1 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers It's a bit of an odd situation because both Godot 3 and 4 are in use, so maybe this one should be renamed to gdtoolkit3 or the opposite for the time being. Haven't had any success yet trying to override the package on my own. <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR.

Related discussion:
text: <ins> { lib , python3 , fetchFromGitHub }: let python = python3.override { packageOverrides = self: super: { lark = super.lark.overridePythonAttrs (old: rec { # gdtoolkit needs exactly this lark version version = "1.1.9"; src = fetchFromGitHub { owner = "lark-parser"; repo = "lark"; rev = version; hash = "sha256-vDu+VPAXONY8J+A6oS7EiMeOMgzGms0nWpE+DKI1MVU="; fetchSubmodules = true; }; patches = [ ]; }); }; }; in python.pkgs.buildPythonApplication rec { pname = "gdtoolkit"; version = "4.2.2"; src = fetchFromGitHub { owner = "Scony"; repo = "godot-gdscript-toolkit"; rev = version; hash = "sha256-SvEKKuDnfxV+5AArg5ssrQzgIwRITdek4KYEs3d0n4Y="; }; disabled = python.pythonOlder "3.7"; propagatedBuildInputs = with python.pkgs; [ docopt lark pyyaml setuptools ]; doCheck = true; nativeCheckInputs = with python.pkgs; [ pytestCheckHook hypothesis ]; preCheck = '' # The tests want to run the installed executables export PATH=$out/bin:$PATH # gdtoolkit tries to write cache variables to $HOME/.cache export HOME=$TMP ''; # The tests are not working on NixOS disabledTestPaths = [ "tests/generated/test_expression_parsing.py" "tests/gdradon/test_executable.py" ]; pythonImportsCheck = [ "gdtoolkit" "gdtoolkit.formatter" "gdtoolkit.linter" "gdtoolkit.parser" ]; meta = with lib; { description = "Independent set of tools for working with Godot's GDScript - parser, linter and formatter"; homepage = "https://github.com/Scony/godot-gdscript-toolkit"; license = licenses.mit; maintainers = with maintainers; [ squarepear ]; }; } </ins>
Code change:
Package name: gdtoolkit Latest released version: 4.1.0 <!-- Search your package here: --- Current version on the unstable channel: 3.3.1 Current version on the stable/release channel: 3.3.1 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers It's a bit of an odd situation because both Godot 3 and 4 are in use, so maybe this one should be renamed to gdtoolkit3 or the opposite for the time being. Haven't had any success yet trying to override the package on my own. <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR.

Related discussion:
text: godot-headless = throw "godot-headless has been renamed to godot3-headless to distinguish from version 4"; # Added 2023-07-16 godot-server = throw "godot-server has been renamed to godot3-server to distinguish from version 4"; # Added 2023-07-16 <ins> gdtoolkit = throw "gdtoolkit has been renamed to gdtoolkit_3 to distinguish from version 4"; # Added 2024-02-17 </ins> google-chrome-beta = throw "'google-chrome-beta' has been removed due to the lack of maintenance in nixpkgs. Consider using 'google-chrome' instead."; # Added 2023-10-18 google-chrome-dev = throw "'google-chrome-dev' has been removed due to the lack of maintenance in nixpkgs. Consider using 'google-chrome' instead."; # Added 2023-10-18 google-gflags = throw "'google-gflags' has been renamed to/replaced by 'gflags'"; # Converted to throw 2023-09-10
Code change:
Package name: gdtoolkit Latest released version: 4.1.0 <!-- Search your package here: --- Current version on the unstable channel: 3.3.1 Current version on the stable/release channel: 3.3.1 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers It's a bit of an odd situation because both Godot 3 and 4 are in use, so maybe this one should be renamed to gdtoolkit3 or the opposite for the time being. Haven't had any success yet trying to override the package on my own. <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR.

Related discussion:
text: gdmap = callPackage ../tools/system/gdmap { }; <del> gdtoolkit = callPackage ../development/tools/gdtoolkit { }; </del> gef = callPackage ../development/tools/misc/gef { }; gelasio = callPackage ../data/fonts/gelasio { };