jiebi/CodeConvo huggingface dataset:
Code change:
Package name: solana-cli Latest released version: 1.16.27 <!-- Search your package here: --- Current version on the unstable channel: 1.14.23 Current version on the stable/release channel: 1.14.23 <!-- 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 <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hello I was able make the building script work so solana-cli is updated to 1.16.27 expect solana has bug in a which doesn't let me compile. The issue was already reported back back in 22 november 2023: solana-labs/solana So until is fixed I can't do anything more, as soon as it is fixed I will post my pr
Thanks , did you manage to build it for the current version? () On the master of nixpkgs I couldn't even build the existing version of Solana due a rocksdb issue I also found this commit on homebrew PRs. Seems like they patched this part in order to make the build work:
Hello I didn't test it and I don't think I need since I made it able to compile 1.16.27 I appreciate the citation, with the patch used by them I was able to fix it, appreciate your help

Related discussion:
text: "solana-gossip" "solana-install" "solana-keygen" <ins> "solana-ledger-tool" </ins> "solana-log-analyzer" "solana-net-shaper" <del> "solana-sys-tuner" "rbpf-cli" </del> "solana-validator" <del> "solana-ledger-tool" "cargo-build-bpf" "cargo-test-bpf" "solana-dos" "solana-install-init" "solana-stake-accounts" "solana-test-validator" "solana-tokens" "solana-watchtower" "cargo-test-sbf" "cargo-build-sbf" </del> ] ++ [ # XXX: Ensure `solana-genesis` is built LAST! # See https://github.com/solana-labs/solana/issues/5826
Code change:
Package name: solana-cli Latest released version: 1.16.27 <!-- Search your package here: --- Current version on the unstable channel: 1.14.23 Current version on the stable/release channel: 1.14.23 <!-- 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 <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hello I was able make the building script work so solana-cli is updated to 1.16.27 expect solana has bug in a which doesn't let me compile. The issue was already reported back back in 22 november 2023: solana-labs/solana So until is fixed I can't do anything more, as soon as it is fixed I will post my pr
Thanks , did you manage to build it for the current version? () On the master of nixpkgs I couldn't even build the existing version of Solana due a rocksdb issue I also found this commit on homebrew PRs. Seems like they patched this part in order to make the build work:
Hello I didn't test it and I don't think I need since I made it able to compile 1.16.27 I appreciate the citation, with the patch used by them I was able to fix it, appreciate your help

Related discussion:
text: ] }: let <del> version = "1.14.23"; sha256 = "sha256-NUkkLzLNh8P7PFh/SVtd9JM18w3egDaaK80urGw1SSs="; cargoSha256 = "sha256-7t8Quh6T2MzJWEM5Y50CgCyFfx2ZJRAdCpZyyYvJrt4="; </del> <ins> version = "1.16.27"; sha256 = "sha256-xd0FCSlpPJDVWOlt9rIlnSbjksmvlXJWHkvlZONd2dM="; </ins> inherit (darwin.apple_sdk_11_0) Libsystem; inherit (darwin.apple_sdk_11_0.frameworks) System IOKit AppKit Security; in rustPlatform.buildRustPackage rec { pname = "solana-cli"; <del> inherit version cargoSha256; </del> <ins> inherit version; </ins> src = fetchFromGitHub { owner = "solana-labs";
Code change:
Package name: solana-cli Latest released version: 1.16.27 <!-- Search your package here: --- Current version on the unstable channel: 1.14.23 Current version on the stable/release channel: 1.14.23 <!-- 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 <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hello I was able make the building script work so solana-cli is updated to 1.16.27 expect solana has bug in a which doesn't let me compile. The issue was already reported back back in 22 november 2023: solana-labs/solana So until is fixed I can't do anything more, as soon as it is fixed I will post my pr
Thanks , did you manage to build it for the current version? () On the master of nixpkgs I couldn't even build the existing version of Solana due a rocksdb issue I also found this commit on homebrew PRs. Seems like they patched this part in order to make the build work:
Hello I didn't test it and I don't think I need since I made it able to compile 1.16.27 I appreciate the citation, with the patch used by them I was able to fix it, appreciate your help

Related discussion:
text: inherit sha256; }; <ins> cargoLock = { lockFile = ./Cargo.lock; outputHashes = { "crossbeam-epoch-0.9.5" = "sha256-Jf0RarsgJiXiZ+ddy0vp4jQ59J9m0k3sgXhWhCdhgws="; "ntapi-0.3.7" = "sha256-G6ZCsa3GWiI/FeGKiK9TWkmTxen7nwpXvm5FtjNtjWU="; }; }; patches = [ # Fix: https://github.com/solana-labs/solana/issues/34203 # From https://github.com/Homebrew/homebrew-core/pull/156930/files#diff-f27c55b86df31cd4935c956efee1be743eae0958e3850f3f9891d51bfea50b1cR76 ./account-info.patch ]; </ins> strictDeps = true; cargoBuildFlags = builtins.map (n: "--bin=${n}") solanaPkgs;
Code change:
Package name: solana-cli Latest released version: 1.16.27 <!-- Search your package here: --- Current version on the unstable channel: 1.14.23 Current version on the stable/release channel: 1.14.23 <!-- 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 <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hello I was able make the building script work so solana-cli is updated to 1.16.27 expect solana has bug in a which doesn't let me compile. The issue was already reported back back in 22 november 2023: solana-labs/solana So until is fixed I can't do anything more, as soon as it is fixed I will post my pr
Thanks , did you manage to build it for the current version? () On the master of nixpkgs I couldn't even build the existing version of Solana due a rocksdb issue I also found this commit on homebrew PRs. Seems like they patched this part in order to make the build work:
Hello I didn't test it and I don't think I need since I made it able to compile 1.16.27 I appreciate the citation, with the patch used by them I was able to fix it, appreciate your help

Related discussion:
text: description = "Web-Scale Blockchain for fast, secure, scalable, decentralized apps and marketplaces. "; homepage = "https://solana.com"; license = licenses.asl20; <del> maintainers = with maintainers; [ netfox happysalada ]; </del> <ins> maintainers = with maintainers; [ netfox happysalada aikooo7 ]; </ins> platforms = platforms.unix; };
Code change:
Optipng crashes with a segmentation fault on current as of . points to the library used to throw/catch exceptions. relevant source: Automatic points to being the first bad revision. However, I don't have enough knowledge of this piece of nix to understand why it causes optipng to fail in the . System: nixos-master Nix version: 1.11.11 Nixpkgs version: Sandboxing enabled: yes CC
Reading into the causing commit's comments made me try which seems to work around the issue. However, I'm hesitant to commit this as a fix without understanding the issue here.
So some packages use the C compiler instead of linker directly to link. Nixpkgs's cc-wrapper is aware of this, for example, with separate and environment variables. Classic make builtin rules however only have , , , and , so then either in a configure script or make itself they seem to default to , but manually specifying breaks this. Manually specifying , however, avoids that pitfall, and, unlike , will also work for cross compilation.
Here's a blurb from optipng's script: If I understand your comment, it looks like optipng's build system is doing precisely what you describe: So when isn't set, it defaults to configuring the such that it uses as the linker, and I suppose the theory is that they depend on behavior available when invoking through e.g. (though I don't know precisely what that may be). It would seem reasonable take the (on a per package basis) approach as a solution. I think this can safely be considered a bug in the upstream packages' build systems.
Probably the use of to pass actual ld flags, e.g. .
I implemented the workaround in . Feel free to reopen this if you don't think the fix to be adequate.

Related discussion:
text: -e 's^addCVars^addCVars${_infixSalt}^g'  -e 's^[ -z "$crossConfig" ]^[[ "${builtins.toString (targetPlatform != hostPlatform)}" || -z "$crossConfig" ]]^g' <del> '' + stdenv.lib.optionalString (textFile == ./setup-hook.sh) '' cat << 'EOF' >> $out for CMD in ar as nm objcopy ranlib strip strings size ld windres do # which is not part of stdenv, but compgen will do for now if PATH=$_PATH type -p ${prefix}$CMD > /dev/null then export ''$(echo "$CMD" | tr "[:lower:]" "[:upper:]")=${prefix}''${CMD}; fi done EOF sed -i $out -e 's_envHooks_crossEnvHooks_g' '' + '' </del> # NIX_ things which we don't both use and define, we revert them #asymmetric=$( #  for pre in "" "$"
Code change:
Optipng crashes with a segmentation fault on current as of . points to the library used to throw/catch exceptions. relevant source: Automatic points to being the first bad revision. However, I don't have enough knowledge of this piece of nix to understand why it causes optipng to fail in the . System: nixos-master Nix version: 1.11.11 Nixpkgs version: Sandboxing enabled: yes CC
Reading into the causing commit's comments made me try which seems to work around the issue. However, I'm hesitant to commit this as a fix without understanding the issue here.
So some packages use the C compiler instead of linker directly to link. Nixpkgs's cc-wrapper is aware of this, for example, with separate and environment variables. Classic make builtin rules however only have , , , and , so then either in a configure script or make itself they seem to default to , but manually specifying breaks this. Manually specifying , however, avoids that pitfall, and, unlike , will also work for cross compilation.
Here's a blurb from optipng's script: If I understand your comment, it looks like optipng's build system is doing precisely what you describe: So when isn't set, it defaults to configuring the such that it uses as the linker, and I suppose the theory is that they depend on behavior available when invoking through e.g. (though I don't know precisely what that may be). It would seem reasonable take the (on a per package basis) approach as a solution. I think this can safely be considered a bug in the upstream packages' build systems.
Probably the use of to pass actual ld flags, e.g. .
I implemented the workaround in . Feel free to reopen this if you don't think the fix to be adequate.

Related discussion:
text: inherit cc shell libc_bin libc_dev libc_lib binutils_bin coreutils_bin; gnugrep_bin = if nativeTools then "" else gnugrep; <ins> binPrefix = prefix; </ins> passthru = { inherit libc nativeTools nativeLibc nativePrefix isGNU isClang default_cxx_stdlib_compile
Code change:
Optipng crashes with a segmentation fault on current as of . points to the library used to throw/catch exceptions. relevant source: Automatic points to being the first bad revision. However, I don't have enough knowledge of this piece of nix to understand why it causes optipng to fail in the . System: nixos-master Nix version: 1.11.11 Nixpkgs version: Sandboxing enabled: yes CC
Reading into the causing commit's comments made me try which seems to work around the issue. However, I'm hesitant to commit this as a fix without understanding the issue here.
So some packages use the C compiler instead of linker directly to link. Nixpkgs's cc-wrapper is aware of this, for example, with separate and environment variables. Classic make builtin rules however only have , , , and , so then either in a configure script or make itself they seem to default to , but manually specifying breaks this. Manually specifying , however, avoids that pitfall, and, unlike , will also work for cross compilation.
Here's a blurb from optipng's script: If I understand your comment, it looks like optipng's build system is doing precisely what you describe: So when isn't set, it defaults to configuring the such that it uses as the linker, and I suppose the theory is that they depend on behavior available when invoking through e.g. (though I don't know precisely what that may be). It would seem reasonable take the (on a per package basis) approach as a solution. I think this can safely be considered a bug in the upstream packages' build systems.
Probably the use of to pass actual ld flags, e.g. .
I implemented the workaround in . Feel free to reopen this if you don't think the fix to be adequate.

Related discussion:
text: wrap ${prefix}ld.bfd ${preWrap ./ld-wrapper.sh} ${binutils_bin}/bin/${prefix}ld.bfd fi <del> export real_cc=${prefix}cc export real_cxx=${prefix}c++ </del> <ins> # We export environment variables pointing to the wrapped nonstandard # cmds, lest some lousy configure script use those to guess compiler # version. export named_cc=${prefix}cc export named_cxx=${prefix}c++ </ins> export default_cxx_stdlib_compile="${default_cxx_stdlib_compile}" if [ -e $ccPath/${prefix}gcc ]; then wrap ${prefix}gcc ${preWrap ./cc-wrapper.sh} $ccPath/${prefix}gcc ln -s ${prefix}gcc $out/bin/${prefix}cc <del> export real_cc=${prefix}gcc export real_cxx=${prefix}g++ </del> <ins> export named_cc=${prefix}gcc export named_cxx=${prefix}g++ </ins> elif [ -e $ccPath/clang ]; then wrap ${prefix}clang ${preWrap ./cc-wrapper.sh} $ccPath/clang ln -s ${prefix}clang $out/bin/${prefix}cc <del> export real_cc=clang export real_cxx=clang++ </del> <ins> export named_cc=${prefix}clang export named_cxx=${prefix}clang++ </ins> fi if [ -e $ccPath/${prefix}g++ ]; then
Code change:
Optipng crashes with a segmentation fault on current as of . points to the library used to throw/catch exceptions. relevant source: Automatic points to being the first bad revision. However, I don't have enough knowledge of this piece of nix to understand why it causes optipng to fail in the . System: nixos-master Nix version: 1.11.11 Nixpkgs version: Sandboxing enabled: yes CC
Reading into the causing commit's comments made me try which seems to work around the issue. However, I'm hesitant to commit this as a fix without understanding the issue here.
So some packages use the C compiler instead of linker directly to link. Nixpkgs's cc-wrapper is aware of this, for example, with separate and environment variables. Classic make builtin rules however only have , , , and , so then either in a configure script or make itself they seem to default to , but manually specifying breaks this. Manually specifying , however, avoids that pitfall, and, unlike , will also work for cross compilation.
Here's a blurb from optipng's script: If I understand your comment, it looks like optipng's build system is doing precisely what you describe: So when isn't set, it defaults to configuring the such that it uses as the linker, and I suppose the theory is that they depend on behavior available when invoking through e.g. (though I don't know precisely what that may be). It would seem reasonable take the (on a per package basis) approach as a solution. I think this can safely be considered a bug in the upstream packages' build systems.
Probably the use of to pass actual ld flags, e.g. .
I implemented the workaround in . Feel free to reopen this if you don't think the fix to be adequate.

Related discussion:
text: <del> export NIX_CC=@out@ </del> addCVars () { if [ -d $1/include ]; then export NIX_CFLAGS_COMPILE+=" ${ccIncludeFlag:--isystem} $1/include"
Code change:
Optipng crashes with a segmentation fault on current as of . points to the library used to throw/catch exceptions. relevant source: Automatic points to being the first bad revision. However, I don't have enough knowledge of this piece of nix to understand why it causes optipng to fail in the . System: nixos-master Nix version: 1.11.11 Nixpkgs version: Sandboxing enabled: yes CC
Reading into the causing commit's comments made me try which seems to work around the issue. However, I'm hesitant to commit this as a fix without understanding the issue here.
So some packages use the C compiler instead of linker directly to link. Nixpkgs's cc-wrapper is aware of this, for example, with separate and environment variables. Classic make builtin rules however only have , , , and , so then either in a configure script or make itself they seem to default to , but manually specifying breaks this. Manually specifying , however, avoids that pitfall, and, unlike , will also work for cross compilation.
Here's a blurb from optipng's script: If I understand your comment, it looks like optipng's build system is doing precisely what you describe: So when isn't set, it defaults to configuring the such that it uses as the linker, and I suppose the theory is that they depend on behavior available when invoking through e.g. (though I don't know precisely what that may be). It would seem reasonable take the (on a per package basis) approach as a solution. I think this can safely be considered a bug in the upstream packages' build systems.
Probably the use of to pass actual ld flags, e.g. .
I implemented the workaround in . Feel free to reopen this if you don't think the fix to be adequate.

Related discussion:
text: fi if [ -z "$crossConfig" ]; then <del> export CC=@real_cc@ export CXX=@real_cxx@ </del> <ins> ENV_PREFIX="" </ins> else <del> export BUILD_CC=@real_cc@ export BUILD_CXX=@real_cxx@ </del> <ins> ENV_PREFIX="BUILD_" </ins> fi <ins> export NIX_${ENV_PREFIX}CC=@out@ export ${ENV_PREFIX}CC=@named_cc@ export ${ENV_PREFIX}CXX=@named_cxx@ for CMD in  cpp  ar as nm objcopy ranlib strip strings size ld windres do if PATH=$_PATH type -p "@binPrefix@$CMD" > /dev/null then export "${ENV_PREFIX}${CMD^^}=@binPrefix@${CMD}"; fi done # No local scope available for sourced files unset ENV_PREFIX </ins>
Code change:
I would absolutely love for somebody to package up :)
will attempt to reserve some time to give it a try in the next days :-)
I created a first working version which compiles on my machine ( ): Unfortunately I had to use an older revision since the latest revisions require language features from Rust 1.19 and I'll have to bump it in nixpkgs before using the latest revision, after that I'll open a PR :-)
btw do we want to add an option which allows to change the coreutils pkg from to ? Something like and every module should start start using .
I had contemplated using a package override and just make equal to . Not sure how well that would work out... This may be something where is one of the few qualified to chime in.
Please don't introduce this as a NixOS option. This rewrite is not compatible with the GNU coreutils. This will certainly break NixOS. The package override will break lots of packages and will trigger a full rebuild anyway. Packaging these for testing is fine. :+1:
Could you just wrap this into a PR then? I will certainly test this and create some aliases to replace the GNU tools (in the user environment)
sorry for the delay at first. I'm aware of this. I just proposed an approach to switch the package just for system-wide testing purposes. This is actually the better approach. Furthermore this is something anyone can do locally, so shouldn't have concers with it as it shouldn't affect code in for now :-) I'll certainly do. However we have to wait for since the latest revisions of require Rust 1.19 (I'm currenty using an older revision from July 2017 locally). I checked out this change tried to compile uutils-coreutils against the new Rust compiler, but it cargo builds seem to fail ()
Ah, of course. Let's wait for then.
after has been merged it should be possible to finally implement this. Will open a PR in th next days...

Related discussion:
text: <ins> { stdenv, fetchFromGitHub, rustPlatform, cargo, cmake, sphinx, lib, prefix ? "uutils-" }: rustPlatform.buildRustPackage { name = "uutils-coreutils-2018-02-09"; src = fetchFromGitHub { owner = "uutils"; repo = "coreutils"; rev = "f333ab26b03294a32a10c1c203a03c6b5cf8a89a"; sha256 = "0nkggs5nqvc1mxzzgcsqm1ahchh4ll11xh0xqmcljrr5yg1rhhzf"; }; # too many impure/platform-dependent tests doCheck = false; cargoSha256 = "0qv2wz1bxhm5xhzbic7cqmn8jj8fyap0s18ylia4fbwpmv89nkc5"; makeFlags = [ "CARGO=${cargo}/bin/cargo" "PREFIX=$(out)" "PROFILE=release" "INSTALLDIR_MAN=$(out)/share/man/man1" ] ++ lib.optional (prefix != null) [ "PROG_PREFIX=${prefix}" ]; nativeBuildInputs = [ cmake ]; buildInputs = [ cargo sphinx ]; # empty {build,install}Phase to use defaults of `stdenv.mkDerivation` rather than rust defaults buildPhase = ""; installPhase = ""; meta = with stdenv.lib; { description = "Cross-platform Rust rewrite of the GNU coreutils"; longDescription = '' uutils is an attempt at writing universal (as in cross-platform) CLI utils in Rust. This repo is to aggregate the GNU coreutils rewrites. ''; homepage = https://github.com/uutils/coreutils; maintainers = with maintainers; [ ma27 ]; license = licenses.mit; platforms = platforms.unix; }; } </ins>