jiebi/CodeConvo huggingface dataset:
Code change:
Steps to reproduce the behavior: -shell -p quickbms Please run and paste the result.
It's possible that this package just isn't buildable One of the errors encountered is: is not supported in recent openssl versions.

Related discussion:
text: <ins> --- src/Makefile	2023-05-25 18:16:56.000296653 +0900 +++ src/Makefile	2023-05-25 18:17:00.772272861 +0900 @@ -23,7 +23,6 @@ EXTRA_TARGETS  = libs/amiga/amiga.s libs/powzix/*.cpp CFLAGS += -msse2 endif -USE_OPENSSL	= 1 endif # -liconv and -fPIC are necessary on Android </ins>
Code change:
Steps to reproduce the behavior: -shell -p quickbms Please run and paste the result.
It's possible that this package just isn't buildable One of the errors encountered is: is not supported in recent openssl versions.

Related discussion:
text: <del> { stdenv, lib, fetchzip, bzip2, lzo, openssl, zlib }: </del> <ins> { stdenv , lib , fetchzip , fetchpatch , bzip2 , lzo , openssl_1_1 , opensslSupport ? false , zlib }: </ins> stdenv.mkDerivation rec { version = "0.11.0";
Code change:
Steps to reproduce the behavior: -shell -p quickbms Please run and paste the result.
It's possible that this package just isn't buildable One of the errors encountered is: is not supported in recent openssl versions.

Related discussion:
text: hash = "sha256-uQKTE36pLO8uhrX794utqaDGUeyqRz6zLCQFA7DYkNc="; }; <del> buildInputs = [ bzip2 lzo openssl zlib ]; </del> <ins> patches = [ # Fix errors on x86_64 and _rotl definition (fetchpatch { name = "0001-fix-compile.patch"; url = "https://aur.archlinux.org/cgit/aur.git/plain/fix-compile.patch?h=quickbms&id=a2e3e4638295d7cfe39513bfef9447fb23154a6b"; hash = "sha256-49fT/L4BNzMYnq1SXhFMgSDLybLkz6KSbgKmUpZZu08="; stripLen = 1; }) ] ++ lib.optional (!opensslSupport) ./0002-disable-openssl.patch; buildInputs = [ bzip2 lzo zlib ] ++ lib.optional (opensslSupport) openssl_1_1; </ins> makeFlags = [ "PREFIX=$(out)" ];
Code change:
Project description CLI for interacting with Scalr. Metadata homepage URL: source URL: license: apache 2 platforms: windows, linux, darwin

Related discussion:
text: githubId = 6689924; name = "David Terry"; }; <ins> dylanmtaylor = { email = "dylan@dylanmtaylor.com"; github = "dylamtaylor"; githubId = 277927; name = "Dylan Taylor"; }; </ins> dysinger = { email = "tim@dysinger.net"; github = "dysinger";
Code change:
Project description CLI for interacting with Scalr. Metadata homepage URL: source URL: license: apache 2 platforms: windows, linux, darwin

Related discussion:
text: <ins> { lib , buildGoModule , fetchFromGitHub }: buildGoModule rec { pname = "scalr-cli"; version = "0.14.5"; src = fetchFromGitHub { owner = "Scalr"; repo = "scalr-cli"; rev = "v${version}"; hash = "sha256-X/fZDM1OYw1a0la8os9TFUrl1h5BnO+C40h2XH32vmw="; }; vendorHash = "sha256-EdDhq6LnxagutxjiOoYElhHVnSKhr/Ekt928gSooPYY="; ldflags = [ "-s" "-w" ]; preConfigure = '' # Set the version. substituteInPlace main.go --replace '"0.0.0"' '"${version}"' ''; postInstall = '' mv $out/bin/cli $out/bin/scalr ''; doCheck = false; # Skip tests as they require creating actual Scalr resources. meta = with lib; { description = "A command-line tool that communicates directly with the Scalr API."; homepage = "https://github.com/Scalr/scalr-cli"; changelog = "https://github.com/Scalr/scalr-cli/releases/tag/v${version}"; license = licenses.asl20; maintainers = with maintainers; [ dylanmtaylor ]; mainProgram = "scalr"; platforms = platforms.unix; }; } </ins>
Code change:
Project description CLI for interacting with Scalr. Metadata homepage URL: source URL: license: apache 2 platforms: windows, linux, darwin

Related discussion:
text: sampler = callPackage ../applications/misc/sampler { }; <ins> scalr-cli = callPackage ../tools/admin/scalr-cli { }; </ins> shairplay = callPackage ../servers/shairplay { avahi = avahi-compat; }; shairport-sync = callPackage ../servers/shairport-sync { };
Code change:
Package name: oracle-instantclient Latest released version:21.9.0.0.0 <!-- Search your package here: --- Current version on the unstable channel:19.16.0.0.0 Current version on the stable/release channel:19.16.0.0.0 <!-- 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! -- looks like it tried to upgrade v19 of instant client, but it is stale and not targeting v21. 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.
It looks like you were the last one to touch instant client.
Package sources:

Related discussion:
text: # determine the version number, there might be different ones per architecture version = { <del> x86_64-linux = "19.16.0.0.0"; </del> <ins> x86_64-linux = "21.9.0.0.0"; </ins> aarch64-linux = "19.10.0.0.0"; <del> x86_64-darwin = "19.3.0.0.0"; </del> <ins> x86_64-darwin = "19.8.0.0.0"; </ins> }.${stdenv.hostPlatform.system} or throwSystem; directory = { <del> x86_64-linux = "1916000"; </del> <ins> x86_64-linux = "219000"; </ins> aarch64-linux = "191000"; <del> x86_64-darwin = "193000"; </del> <ins> x86_64-darwin = "198000"; </ins> }.${stdenv.hostPlatform.system} or throwSystem; # hashes per component and architecture hashes = { x86_64-linux = { <del> basic = "sha256-Sq1rWvbC1YME7EjSYPaP2g+1Xxxkk4ZkGaBmLo2cKcQ="; sdk = "sha256-yJ8f/Hlq6vZoPxv+dfY4z1E7rWvcqlK+ou0SU0KKlEI="; sqlplus = "sha256-C44srukpCB9et9UWm59daJmU83zr0HAktnWv7R42Irw="; tools = "sha256-GP4E1REIoU3lctVYmLsAiwTJEvGRpCmOFlRuZk+A8HE="; odbc = "sha256-JECxK7Ia1IJtve2goZJdTkvm5NJjqB2rc6k5BXUt3oA="; </del> <ins> basic = "sha256-wiygUvZFYvjp5pndv3b9yTPxe8sC5HZkJ7jZqO1Mss8="; sdk = "sha256-ehqHV52yLRe8ehrKqpLaN0HnN3zjHU7WrfjtqvQadgY="; sqlplus = "sha256-tYvoG+7l5jXyTpxFUYZXaHCT0xGDeah78AinJ2qIsE8="; tools = "sha256-6K2Ni0ZqqpqCrGFrBD06s0QNjNEDtNPrvDQ1U97lTKY="; odbc = "sha256-yTANMLhaEqm9/ZEVqhEn1Gl8eJukgvqpqdaMRjxWxgs="; </ins> }; aarch64-linux = { basic = "sha256-DNntH20BAmo5kOz7uEgW2NXaNfwdvJ8l8oMnp50BOsY=";
Code change:
Package name: oracle-instantclient Latest released version:21.9.0.0.0 <!-- Search your package here: --- Current version on the unstable channel:19.16.0.0.0 Current version on the stable/release channel:19.16.0.0.0 <!-- 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! -- looks like it tried to upgrade v19 of instant client, but it is stale and not targeting v21. 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.
It looks like you were the last one to touch instant client.
Package sources:

Related discussion:
text: odbc = "sha256-T+RIIKzZ9xEg/E72pfs5xqHz2WuIWKx/oRfDrQbw3ms="; }; x86_64-darwin = { <del> basic = "f4335c1d53e8188a3a8cdfb97494ff87c4d0f481309284cf086dc64080a60abd"; sdk = "b46b4b87af593f7cfe447cfb903d1ae5073cec34049143ad8cdc9f3e78b23b27"; sqlplus = "f7565c3cbf898b0a7953fbb0017c5edd9d11d1863781588b7caf3a69937a2e9e"; tools = "b2bc474f98da13efdbc77fd05f559498cd8c08582c5b9038f6a862215de33f2c"; odbc = "f91da40684abaa866aa059eb26b1322f2d527670a1937d678404c991eadeb725"; </del> <ins> basic = "sha256-V+1BmPOhDYPNXdwkcsBY1MOwt4Yka66/a7/HORzBIIc="; sdk = "sha256-D6iuTEQYqmbOh1z5LnKN16ga6vLmjnkm4QK15S/Iukw="; sqlplus = "sha256-08uoiwoKPZmTxLZLYRVp0UbN827FXdhOukeDUXvTCVk="; tools = "sha256-1xFFGZapFq9ogGQ6ePSv4PrXl5qOAgRZWAp4mJ5uxdU="; odbc = "sha256-S6+5P4daK/+nXwoHmOkj4DIkHtwdzO5GOkCCI612bRY="; </ins> }; }.${stdenv.hostPlatform.system} or throwSystem;
Code change:
Package name: oracle-instantclient Latest released version:21.9.0.0.0 <!-- Search your package here: --- Current version on the unstable channel:19.16.0.0.0 Current version on the stable/release channel:19.16.0.0.0 <!-- 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! -- looks like it tried to upgrade v19 of instant client, but it is stale and not targeting v21. 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.
It looks like you were the last one to touch instant client.
Package sources:

Related discussion:
text: sourceProvenance = with sourceTypes; [ binaryBytecode ]; license = licenses.unfree; platforms = [ "x86_64-linux" "aarch64-linux" "x86_64-darwin" ]; <del> maintainers = with maintainers; [ flokli ]; </del> <ins> maintainers = with maintainers; [ flokli dylanmtaylor ]; </ins> hydraPlatforms = [ ]; }; }
Code change:
Package name: swayws Latest released version: 1.2.0 <!-- Search your package here: --- Current version on the unstable channel: 2022-03-10 Current version on the stable/release channel: 2022-03-10 <!-- 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.

Related discussion:
text: <ins> diff --git a/Cargo.lock b/Cargo.lock index f01f824..e00d079 100644 --- a/Cargo.lock +++ b/Cargo.lock @@ -328,7 +328,7 @@ dependencies = [ [[package]] name = "swayws" -version = "1.1.1" +version = "1.2.0" dependencies = [ "clap", "env_logger", </ins>
Code change:
Package name: swayws Latest released version: 1.2.0 <!-- Search your package here: --- Current version on the unstable channel: 2022-03-10 Current version on the stable/release channel: 2022-03-10 <!-- 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.

Related discussion:
text: rustPlatform.buildRustPackage rec { pname = "swayws"; <del> version = "unstable-2022-03-10"; </del> <ins> version = "1.2.0"; </ins> src = fetchFromGitLab { owner = "w0lff"; repo = pname; <del> rev = "514f3c664439cf2c11bb9096c7e1d3b8c0b898a2"; sha256 = "sha256-vUnbn79v08riYLMBI8BxeBPpe/pHOWlraG7QAaohw3s="; </del> <ins> rev = "v${version}"; sha256 = "sha256-f0kXy7/31imgHHqKPmW9K+QrLqroaPaXwlJkzOoezRU="; </ins> }; <del> cargoSha256 = "sha256-PvKpcTewajvbzUHPssBahWVcAQB3V/aMmOJ/wA0Nrv4="; </del> <ins> cargoSha256 = "sha256-VYT6wV59fraAoJgR/i6GlO8s7LUoehGtxPAggEL1eLo="; # Required patch until upstream fixes https://gitlab.com/w0lff/swayws/-/issues/1 cargoPatches = [ ./ws-update-Cargo-lock.patch ]; </ins> # swayws does not have any tests doCheck = false;
Code change:
This is a continuation of the topic from the initial "upgrade datadog-agent to v7" ticket - see for details on that. The is a metrics and log collection agent intended to run on linux systems for use with 's paid service. On other linux distributions, installing the datadog-agent includes the integration/plugin code, there is no separate install for those, or post-install steps to install the plugins (only config to activate/configure them). Configure the in , and add some extra integration, such as the docker integration. and look at the installed, the plugins are not available. You should see logs from the agent about those. When configuring the datadog-agent, the standard integrations/plugins (docker, nginx, apache, postgres, etc, etc) should be installed and available to the agent if the agent is configured to use them. Please run and paste the result.
There's still something wrong with the Python environment.
Most likely we need to use pyproject to build it properly: That results into missing ddtrace package, which needs to be .
Looks like setuptools wasn't building the and modules. and should fix the integrations. Datadog is planning on dropping setuptools, so we should switch over to pyproject. The blocker is that there are a number of missing dependencies that aren't on nixpkgs yet, but I've started working on that. the Docker integration was rewritten in Go and is now built together with the . You can enable it with: I have no idea why they're now called Yeah, we need to rethink how these integrations are enabled. Now that some of them are part of the , it's become quite a pain to set up.
Fixed in
Thanks! Note that, to get this to run for me, nixpkgs needed an overlay specifying that all packages wanting would get . That looks liked: It seems that, while is deprecated and python 3 is "the default", the package maps to , so a lot of packages effectively default to python 2. Thanks to for coming up with that workaround. I haven't yet see the docker integration work, but I've seen the plugins and such install, so that is promising, and it's likely the last bits are in my config to sort out.
are you on an older release of nixpkgs? has been set to for the datadog integrations since .
We determined the evaluation error came from here: Did we mess that up somehow?
There's a good chance that can be removed from there with no impact. We recently did so for the systemd service.
is a vestige of the old agent. It was a python wrapper that launched that jmx java thing. can most definitely be removed check is broken. I imagine we'd need to package

Related discussion:
text: bimmer-connected = callPackage ../development/python-modules/bimmer-connected { }; <ins> binary = callPackage ../development/python-modules/binary { }; </ins> binaryornot = callPackage ../development/python-modules/binaryornot { }; bincopy = callPackage ../development/python-modules/bincopy { };
Code change:
Project description Gut is a CLI designed to make Git easier to use. Metadata homepage URL: source URL: license: mit platforms: linux, darwin, windows

Related discussion:
text: <ins> { buildGoModule , fetchFromGitHub , lib , nix-update-script }: buildGoModule rec { pname = "gut"; version = "0.2.7"; src = fetchFromGitHub { owner = "julien040"; repo = "gut"; rev = version; sha256 = "sha256-qmp6QWmyharyTzUVXlX/oJZWbeyegX/u8/vzi/pTSaA="; }; vendorSha256 = "sha256-E4jr+dskBdVXj/B5RW1AKyxxr+f/+ZW42OTO9XbCLuw="; ldflags = [ "-s" "-w" "-X github.com/julien040/gut/src/telemetry.gutVersion=${version}" ]; # Checks if `/home` exists doCheck = false; passthru.updateScript = nix-update-script { }; meta = { description = "An easy-to-use git client for Windows, macOS, and Linux"; homepage = "https://github.com/slackhq/go-audit"; maintainers = [ lib.maintainers.paveloom ]; license = [ lib.licenses.mit ]; }; } </ins>
Code change:
Project description Gut is a CLI designed to make Git easier to use. Metadata homepage URL: source URL: license: mit platforms: linux, darwin, windows

Related discussion:
text: gst = callPackage ../applications/version-management/gst { }; <ins> gut = callPackage ../applications/version-management/gut { }; </ins> hred = callPackage ../development/tools/hred { }; hub = callPackage ../applications/version-management/hub { };
Code change:
libnfc from the cache does not seem to work for me: ~ What happens is a null-pointer dereference somewhere inside IOKit: ~ I am really not sure what is going on, but what troubles me is that I cannot reproduce the build on my laptop: apparently, the examples depend on readline, which is not listed as a dependency. ~ How does the manage to succeed on Hydra? What’s wrong with libnfc or libusb built on Hydra? After I as a dependency the build succeded and the resulting libnfc is fully functional.
Do you use sandboxing?
I honestly do not know how it works and if it is enabled by default.
I have opened to address the readline issue (which is probably completely unrelated).
I ask because it could account for the difference (that is, there could be an impurity in the build, causing it to break in unsandboxed environments EDIT: or allowing it to succeed, whichever). It's not enabled by default, but I'm not sure about how stuff works on MacOS wrt sandboxing.
Hm, you have a point. I guess it’s not sandboxing but something similar: building in a pure nix-shell yields non-functional utils.
Ok, now I see. Without it found Homebrew (as the expression does not depend on and therefore the system is not shadowed) and it told it about libusb installed from Homebrew. So, apparently libusb is the culprit.
On my end, I've found that with to the build environment, the readline error manifests (whereas it builds fine otherwise); adding both & allows it to build. There's no segfault, however. As a side note, FWIW, is much weaker than the isolation provided by the build sandbox (it just clears most of the shell environment, you can still traverse the rootfs & pick up all sorts of impurities).
How did you build this? Do you see the same result with ?
Try running: in your nix-shell. see
We need some proper way to fix that.
We could have it set in at least temporarily. There are no real side effects to just setting it besides the potential impurities.
I spent most of yesterday trying to debug the issue but with no luck: I did not manage to build libusb and libnfc with debug symbols (I have no idea how works on macOS; apparently it puts debug symbols into but does not copy them to the resulting binary, therefore, when the library is installed into the store, debug symbols are gone. It would be great if someone taught me how to do this properly).
What exactly is that impure thing that makes pull system CF?
In this case it's the framework, that's linked against the system CoreFoundation, I'm still testing some stuff but I'm pretty sure that I have a proper solution.

Related discussion:
text: propagatedBuildInputs = deps; <ins> # don't use pure CF for dylibs that depend on frameworks setupHook = ../../../build-support/setup-hooks/fix-darwin-frameworks.sh; </ins> # allows building the symlink tree __impureHostDeps = [ "/System/Library/Frameworks/${name}.framework" ];
Code change:
libnfc from the cache does not seem to work for me: ~ What happens is a null-pointer dereference somewhere inside IOKit: ~ I am really not sure what is going on, but what troubles me is that I cannot reproduce the build on my laptop: apparently, the examples depend on readline, which is not listed as a dependency. ~ How does the manage to succeed on Hydra? What’s wrong with libnfc or libusb built on Hydra? After I as a dependency the build succeded and the resulting libnfc is fully functional.
Do you use sandboxing?
I honestly do not know how it works and if it is enabled by default.
I have opened to address the readline issue (which is probably completely unrelated).
I ask because it could account for the difference (that is, there could be an impurity in the build, causing it to break in unsandboxed environments EDIT: or allowing it to succeed, whichever). It's not enabled by default, but I'm not sure about how stuff works on MacOS wrt sandboxing.
Hm, you have a point. I guess it’s not sandboxing but something similar: building in a pure nix-shell yields non-functional utils.
Ok, now I see. Without it found Homebrew (as the expression does not depend on and therefore the system is not shadowed) and it told it about libusb installed from Homebrew. So, apparently libusb is the culprit.
On my end, I've found that with to the build environment, the readline error manifests (whereas it builds fine otherwise); adding both & allows it to build. There's no segfault, however. As a side note, FWIW, is much weaker than the isolation provided by the build sandbox (it just clears most of the shell environment, you can still traverse the rootfs & pick up all sorts of impurities).
How did you build this? Do you see the same result with ?
Try running: in your nix-shell. see
We need some proper way to fix that.
We could have it set in at least temporarily. There are no real side effects to just setting it besides the potential impurities.
I spent most of yesterday trying to debug the issue but with no luck: I did not manage to build libusb and libnfc with debug symbols (I have no idea how works on macOS; apparently it puts debug symbols into but does not copy them to the resulting binary, therefore, when the library is installed into the store, debug symbols are gone. It would be great if someone taught me how to do this properly).
What exactly is that impure thing that makes pull system CF?
In this case it's the framework, that's linked against the system CoreFoundation, I'm still testing some stuff but I'm pretty sure that I have a proper solution.

Related discussion:
text: fixDarwinDylibNames = makeSetupHook { } ../build-support/setup-hooks/fix-darwin-dylib-names.sh; <ins> fixDarwinFrameworks = makeSetupHook { } ../build-support/setup-hooks/fix-darwin-frameworks.sh; </ins> keepBuildTree = makeSetupHook { } ../build-support/setup-hooks/keep-build-tree.sh; enableGCOVInstrumentation = makeSetupHook { } ../build-support/setup-hooks/enable-coverage-instrumentation.sh;
Code change:
libnfc from the cache does not seem to work for me: ~ What happens is a null-pointer dereference somewhere inside IOKit: ~ I am really not sure what is going on, but what troubles me is that I cannot reproduce the build on my laptop: apparently, the examples depend on readline, which is not listed as a dependency. ~ How does the manage to succeed on Hydra? What’s wrong with libnfc or libusb built on Hydra? After I as a dependency the build succeded and the resulting libnfc is fully functional.
Do you use sandboxing?
I honestly do not know how it works and if it is enabled by default.
I have opened to address the readline issue (which is probably completely unrelated).
I ask because it could account for the difference (that is, there could be an impurity in the build, causing it to break in unsandboxed environments EDIT: or allowing it to succeed, whichever). It's not enabled by default, but I'm not sure about how stuff works on MacOS wrt sandboxing.
Hm, you have a point. I guess it’s not sandboxing but something similar: building in a pure nix-shell yields non-functional utils.
Ok, now I see. Without it found Homebrew (as the expression does not depend on and therefore the system is not shadowed) and it told it about libusb installed from Homebrew. So, apparently libusb is the culprit.
On my end, I've found that with to the build environment, the readline error manifests (whereas it builds fine otherwise); adding both & allows it to build. There's no segfault, however. As a side note, FWIW, is much weaker than the isolation provided by the build sandbox (it just clears most of the shell environment, you can still traverse the rootfs & pick up all sorts of impurities).
How did you build this? Do you see the same result with ?
Try running: in your nix-shell. see
We need some proper way to fix that.
We could have it set in at least temporarily. There are no real side effects to just setting it besides the potential impurities.
I spent most of yesterday trying to debug the issue but with no luck: I did not manage to build libusb and libnfc with debug symbols (I have no idea how works on macOS; apparently it puts debug symbols into but does not copy them to the resulting binary, therefore, when the library is installed into the store, debug symbols are gone. It would be great if someone taught me how to do this properly).
What exactly is that impure thing that makes pull system CF?
In this case it's the framework, that's linked against the system CoreFoundation, I'm still testing some stuff but I'm pretty sure that I have a proper solution.

Related discussion:
text: libusb = callPackage ../development/libraries/libusb {}; libusb1 = callPackage ../development/libraries/libusb1 { <del> inherit (darwin) libobjc IOKit; </del> <ins> inherit (darwin) libobjc; inherit (darwin.apple_sdk.frameworks) IOKit; </ins> }; libusbmuxd = callPackage ../development/libraries/libusbmuxd { };