jiebi/CodeConvo huggingface dataset:
Code change:
"Source" link in search result on for Poetry package is pointing to poetry2nix source code instead of poetry. Steps to reproduce the behavior: on "Source" link in "poetry" package. This will point you to instead of When clicking on "Source" link in "poetry" package search results I want to get to "poetry" source code If applicable, add screenshots to help explain your problem. Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Maintainer information:
This is really a bigger issue in how source code locations are extracted and it isn't unique to Poetry/Poetry2nix. The root cause is related to how is extracted: In this case is resolved to where Poetry2nix inherits descriptions from /. You can explicitly pass to which I just implemented in :
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Related discussion:
text: ) { inherit app; }; }; <ins> # Extract position from explicitly passed attrs so meta.position won't point to poetry2nix internals pos = builtins.unsafeGetAttrPos (lib.elemAt (lib.attrNames attrs) 0) attrs; </ins> meta = lib.optionalAttrs (lib.hasAttr "description" pyProject.tool.poetry) { inherit (pyProject.tool.poetry) description;
Code change:
"Source" link in search result on for Poetry package is pointing to poetry2nix source code instead of poetry. Steps to reproduce the behavior: on "Source" link in "poetry" package. This will point you to instead of When clicking on "Source" link in "poetry" package search results I want to get to "poetry" source code If applicable, add screenshots to help explain your problem. Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Maintainer information:
This is really a bigger issue in how source code locations are extracted and it isn't unique to Poetry/Poetry2nix. The root cause is related to how is extracted: In this case is resolved to where Poetry2nix inherits descriptions from /. You can explicitly pass to which I just implemented in :
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Related discussion:
text: } ); <ins> cheroot = super.cheroot.overridePythonAttrs ( old: { dontPreferSetupPy = true; } ); </ins> colour = super.colour.overridePythonAttrs ( old: { buildInputs = (old.buildInputs or [ ]) ++ [ self.d2to1 ];
Code change:
"Source" link in search result on for Poetry package is pointing to poetry2nix source code instead of poetry. Steps to reproduce the behavior: on "Source" link in "poetry" package. This will point you to instead of When clicking on "Source" link in "poetry" package search results I want to get to "poetry" source code If applicable, add screenshots to help explain your problem. Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Maintainer information:
This is really a bigger issue in how source code locations are extracted and it isn't unique to Poetry/Poetry2nix. The root cause is related to how is extracted: In this case is resolved to where Poetry2nix inherits descriptions from /. You can explicitly pass to which I just implemented in :
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Related discussion:
text: self.pytestrunner self.cryptography self.pyjwt <ins> self.setuptools-scm-git-archive </ins> ]; } );
Code change:
is "no longer maintained" or distributed, and the releases are unavailable: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Maintainer information:
A closed source substituting another one? Well, it can be fixed by aliasing them to a failure.

Related discussion:
text: <del> { appimageTools, fetchurl, lib, runCommand, stdenv, gsettings-desktop-schemas, gtk3, zlib }: let name = "${pname}-${version}"; pname = "minetime"; version = "1.8.10"; appimage = fetchurl { url = "https://github.com/marcoancona/MineTime/releases/download/v${version}/${name}.AppImage"; sha256 = "1a80lgk6v9kv9xb2y3i08gk25jm0pqyl57kfr5p1rbc33prhmcgw"; }; extracted = appimageTools.extractType2 { inherit name; src = appimage; }; patched = runCommand "minetime-patchelf" {} '' cp -av ${extracted} $out x=$out/resources/app.asar.unpacked/services/scheduling/dist/MinetimeSchedulingService chmod +w $x patchelf  --set-interpreter ${stdenv.cc.bintools.dynamicLinker}  --replace-needed libz.so.1 ${zlib}/lib/libz.so.1  $x ''; in appimageTools.wrapAppImage rec { inherit name; src = patched; profile = '' export LC_ALL=C.UTF-8 export XDG_DATA_DIRS=${gsettings-desktop-schemas}/share/gsettings-schemas/${gsettings-desktop-schemas.name}:${gtk3}/share/gsettings-schemas/${gtk3.name}:$XDG_DATA_DIRS ''; multiPkgs = null; # no 32bit needed extraPkgs = ps: appimageTools.defaultFhsEnvArgs.multiPkgs ps ++ (with ps; [ at-spi2-core at-spi2-atk libsecret libnotify ]); extraInstallCommands = "mv $out/bin/{${name},${pname}}"; meta = with lib; { description = "Modern, intuitive and smart calendar application"; homepage = "https://minetime.ai"; license = licenses.unfree; # Should be cross-platform, but for now we just grab the appimage platforms = [ "x86_64-linux" ]; maintainers = with maintainers; [ dtzWill ]; }; } </del>
Code change:
is "no longer maintained" or distributed, and the releases are unavailable: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Maintainer information:
A closed source substituting another one? Well, it can be fixed by aliasing them to a failure.

Related discussion:
text: mirage = throw "mirage has been removed from nixpkgs, as it's unmaintained"; # added 2019-12-10 minergate = throw "minergate has been removed from nixpkgs, because the package is unmaintained and the site has a bad reputation"; # added 2021-08-13 minergate-cli = throw "minergatecli has been removed from nixpkgs, because the package is unmaintained and the site has a bad reputation"; # added 2021-08-13 <ins> minetime = throw "minetime has been removed from nixpkgs, because it was discontinued 2021-06-22"; # added 2021-10-14 </ins> mopidy-gmusic = throw "mopidy-gmusic has been removed because Google Play Music was discontinued"; # added 2021-03-07 <del> mopidy-local-images = throw "mopidy-local-images has been removed as it's unmaintained. It's functionality has been merged into the mopidy-local extension."; # added 2020-10-18 mopidy-local-sqlite = throw "mopidy-local-sqlite has been removed as it's unmaintained. It's functionality has been merged into the mopidy-local extension."; # added 2020-10-18 </del> <ins> mopidy-local-images = throw "mopidy-local-images has been removed as it's unmaintained. Its functionality has been merged into the mopidy-local extension."; # added 2020-10-18 mopidy-local-sqlite = throw "mopidy-local-sqlite has been removed as it's unmaintained. Its functionality has been merged into the mopidy-local extension."; # added 2020-10-18 </ins> mysql-client = hiPrio mariadb.client; memtest86 = memtest86plus; # added 2019-05-08 mesa_noglu = mesa; # added 2019-05-28
Code change:
is "no longer maintained" or distributed, and the releases are unavailable: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Maintainer information:
A closed source substituting another one? Well, it can be fixed by aliasing them to a failure.

Related discussion:
text: mimetic = callPackage ../development/libraries/mimetic { }; <del> minetime = callPackage ../applications/office/minetime { }; </del> minio-client = callPackage ../tools/networking/minio-client { }; minio-certgen = callPackage ../tools/security/minio-certgen { };
Code change:
I would like to do this myself, but I'm getting some errors. I fixed the version fetching in , but now I am a bit stuck: No change to the actual package file is seen. I was able to work out that those errors are coming from inside but that's as far as I got. <!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on github to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the the current version of the package --- <!-- 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! --- name: bluejeans-gui <!-- The current version can be found easily with the same process than above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 2.23.0.39 desired version: 2.24.0.89 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: (tagging because just merged my bluejeans version fetch PR ()) and (tagging because seems to have committed to the package recently) Please tag this issue in your PR.
this is why it fails:
something like this will work:
Oh! I thought the I saw when checking was from something else. Thanks.
Thanks for picking this up!
First step:
looks like my work paid off and the bots are taking it the rest of the way

Related discussion:
text: stdenv.mkDerivation rec { pname = "bluejeans"; <del> version = "2.23.0.39"; </del> <ins> version = "2.24.0.89"; </ins> src = fetchurl { url = "https://swdl.bluejeans.com/desktop-app/linux/${getFirst 3 version}/BlueJeans_${version}.rpm"; <del> sha256 = "sha256-LGg14KJ/hEnSaSrdTltY9YXv7Nekkfo66uLkxjMx8AI="; </del> <ins> sha256 = "sha256-rneX8ys/oKfVLavAZk5RJouOZkVsp+9BIAReSeYiKJc="; </ins> }; nativeBuildInputs = [ rpmextract makeWrapper ];
Code change:
To make sure that we are on the same page: Kernel: (run ) 4.5.0 System: (NixOS: , Ubuntu/Fedora: , ...) (Flounder) Nix version: (run ) 1.11.2 Nixpkgs version: (run ) During testing of I managed to get at least two different hashes for . After some discussion with it seems that this derivation can produce non-deterministic output. Hashes of outputs are always the same. They are not. Build several times.
How would one work around that? It basically means the system cannot be rebuild :cry:
cc
You can work around it by updating SHA checksum in the affected package locally.
:confused: Is there any documentation you could point me too. I know how I would to it for packages that I install as a user: out nixpkgs repo the last commit that build for unstable on hydra that out the exa's file 5 run But I think it's also possible to override it in a nix expression, like the one in , since I installed it as a systems package. The thing is that all ressources I find either explain how to do it for that they link to
I changed my to include that: but to no avail :confused:
Sadly we don't have a mechanism to override (it needs to be supported). However, you can rebuild your whole NixOS from a modified repository:
Another way to do it is to call patched nixpkgs from your :
Thanks for your help! I really appreciate it. I tried your last suggestions, but that leads to: It looks like some network hick up, but I tried it multiple times and I opened the github repository from the same machine and it loads fine. Maybe it has something to do with this line: ?
Hm, unfortunately I have no idea what's going on -- you've fixed the hash, so it seems like another problem in .
Still thanks for the help. I learned a lot!
depends on a git repository in which doesn't work with
maybe fetchcargo could take an argument to pin git-based dependencies on a certain commit?
I can confirm that this is still an issue when building : through AUR/exa-git. cc
Are there any updates on this issue, please?
Should be fixed.

Related discussion:
text: { stdenv, callPackage }: callPackage ./generic.nix { <del> shortVersion = "2016-02-22"; </del> <ins> shortVersion = "2016-03-22"; </ins> isRelease = false; forceBundledLLVM = true; <del> srcRev = "d1f422ec280b881b8236c5d173103bc799e1590e"; srcSha = "b0753045ae438c0869d37f429fe84451dcacc4b2ab9413d34bf29fde94fde462"; </del> <ins> srcRev = "6cc502c986d42da407e26a49d4f09f21d3072fcb"; srcSha = "096lsc8irh9a7w494yaji28kzy9frs2myqrfyj0fzbxkvs3yfhzz"; </ins> /* Rust is bootstrapped from an earlier built version. We need to fetch these earlier versions, which vary per platform.
Code change:
To make sure that we are on the same page: Kernel: (run ) 4.5.0 System: (NixOS: , Ubuntu/Fedora: , ...) (Flounder) Nix version: (run ) 1.11.2 Nixpkgs version: (run ) During testing of I managed to get at least two different hashes for . After some discussion with it seems that this derivation can produce non-deterministic output. Hashes of outputs are always the same. They are not. Build several times.
How would one work around that? It basically means the system cannot be rebuild :cry:
cc
You can work around it by updating SHA checksum in the affected package locally.
:confused: Is there any documentation you could point me too. I know how I would to it for packages that I install as a user: out nixpkgs repo the last commit that build for unstable on hydra that out the exa's file 5 run But I think it's also possible to override it in a nix expression, like the one in , since I installed it as a systems package. The thing is that all ressources I find either explain how to do it for that they link to
I changed my to include that: but to no avail :confused:
Sadly we don't have a mechanism to override (it needs to be supported). However, you can rebuild your whole NixOS from a modified repository:
Another way to do it is to call patched nixpkgs from your :
Thanks for your help! I really appreciate it. I tried your last suggestions, but that leads to: It looks like some network hick up, but I tried it multiple times and I opened the github repository from the same machine and it loads fine. Maybe it has something to do with this line: ?
Hm, unfortunately I have no idea what's going on -- you've fixed the hash, so it seems like another problem in .
Still thanks for the help. I learned a lot!
depends on a git repository in which doesn't work with
maybe fetchcargo could take an argument to pin git-based dependencies on a certain commit?
I can confirm that this is still an issue when building : through AUR/exa-git. cc
Are there any updates on this issue, please?
Should be fixed.

Related discussion:
text: with the set you want at the top. */ <del> snapshotHashLinux686 = "a09c4a4036151d0cb28e265101669731600e01f2"; snapshotHashLinux64 = "97e2a5eb8904962df8596e95d6e5d9b574d73bf4"; snapshotHashDarwin686 = "ca52d2d3ba6497ed007705ee3401cf7efc136ca1"; snapshotHashDarwin64 = "3c44ffa18f89567c2b81f8d695e711c86d81ffc7"; snapshotDate = "2015-12-18"; snapshotRev = "3391630"; </del> <ins> snapshotHashLinux686 = "0e0e4448b80d0a12b75485795244bb3857a0a7ef"; snapshotHashLinux64 = "1273b6b6aed421c9e40c59f366d0df6092ec0397"; snapshotHashDarwin686 = "9f9c0b4a2db09acbce54b792fb8839a735585565"; snapshotHashDarwin64 = "52570f6fd915b0210a9be98cfc933148e16a75f8"; snapshotDate = "2016-03-18"; snapshotRev = "235d774"; </ins> patches = [ ./patches/remove-uneeded-git.patch ] ++ stdenv.lib.optional stdenv.needsPax ./patches/grsec.patch; }
Code change:
To make sure that we are on the same page: Kernel: (run ) 4.5.0 System: (NixOS: , Ubuntu/Fedora: , ...) (Flounder) Nix version: (run ) 1.11.2 Nixpkgs version: (run ) During testing of I managed to get at least two different hashes for . After some discussion with it seems that this derivation can produce non-deterministic output. Hashes of outputs are always the same. They are not. Build several times.
How would one work around that? It basically means the system cannot be rebuild :cry:
cc
You can work around it by updating SHA checksum in the affected package locally.
:confused: Is there any documentation you could point me too. I know how I would to it for packages that I install as a user: out nixpkgs repo the last commit that build for unstable on hydra that out the exa's file 5 run But I think it's also possible to override it in a nix expression, like the one in , since I installed it as a systems package. The thing is that all ressources I find either explain how to do it for that they link to
I changed my to include that: but to no avail :confused:
Sadly we don't have a mechanism to override (it needs to be supported). However, you can rebuild your whole NixOS from a modified repository:
Another way to do it is to call patched nixpkgs from your :
Thanks for your help! I really appreciate it. I tried your last suggestions, but that leads to: It looks like some network hick up, but I tried it multiple times and I opened the github repository from the same machine and it loads fine. Maybe it has something to do with this line: ?
Hm, unfortunately I have no idea what's going on -- you've fixed the hash, so it seems like another problem in .
Still thanks for the help. I learned a lot!
depends on a git repository in which doesn't work with
maybe fetchcargo could take an argument to pin git-based dependencies on a certain commit?
I can confirm that this is still an issue when building : through AUR/exa-git. cc
Are there any updates on this issue, please?
Should be fixed.

Related discussion:
text: with ((import ./common.nix) { inherit stdenv rustc; <del> version = "2016-02-25"; </del> <ins> version = "2016-03-20"; </ins> }); buildRustPackage rec {
Code change:
To make sure that we are on the same page: Kernel: (run ) 4.5.0 System: (NixOS: , Ubuntu/Fedora: , ...) (Flounder) Nix version: (run ) 1.11.2 Nixpkgs version: (run ) During testing of I managed to get at least two different hashes for . After some discussion with it seems that this derivation can produce non-deterministic output. Hashes of outputs are always the same. They are not. Build several times.
How would one work around that? It basically means the system cannot be rebuild :cry:
cc
You can work around it by updating SHA checksum in the affected package locally.
:confused: Is there any documentation you could point me too. I know how I would to it for packages that I install as a user: out nixpkgs repo the last commit that build for unstable on hydra that out the exa's file 5 run But I think it's also possible to override it in a nix expression, like the one in , since I installed it as a systems package. The thing is that all ressources I find either explain how to do it for that they link to
I changed my to include that: but to no avail :confused:
Sadly we don't have a mechanism to override (it needs to be supported). However, you can rebuild your whole NixOS from a modified repository:
Another way to do it is to call patched nixpkgs from your :
Thanks for your help! I really appreciate it. I tried your last suggestions, but that leads to: It looks like some network hick up, but I tried it multiple times and I opened the github repository from the same machine and it loads fine. Maybe it has something to do with this line: ?
Hm, unfortunately I have no idea what's going on -- you've fixed the hash, so it seems like another problem in .
Still thanks for the help. I learned a lot!
depends on a git repository in which doesn't work with
maybe fetchcargo could take an argument to pin git-based dependencies on a certain commit?
I can confirm that this is still an issue when building : through AUR/exa-git. cc
Are there any updates on this issue, please?
Should be fixed.

Related discussion:
text: # Needs to use fetchgit instead of fetchFromGitHub to fetch submodules src = fetchgit { url = "git://github.com/rust-lang/cargo"; <del> rev = "e7212896dc1b182493a0252a2a126db8be067153"; sha256 = "1qbic7gp7cpihi40kfv3kagja8zsngica8sq9jcm9czb6ba44dsa"; </del> <ins> rev = "132b82d75f607dcb1116b8d44fe60f202f1eb110"; sha256 = "0kx2m0p45zr0ils2ax19sr32cibjppgwj8xvsgrfvzvlnc540xpl"; </ins> }; <del> depsSha256 = "1xfpj1233p4314j6jmip0jjl5m3kj2wbac1ll3yvh7383zb83i1s"; </del> <ins> depsSha256 = "19d2fl5p92108a0yjpix0qxdc23jy122xc87k69hk0pwwxa92l3a"; </ins> buildInputs = [ file curl pkgconfig python openssl cmake zlib makeWrapper ];
Code change:
To make sure that we are on the same page: Kernel: (run ) 4.5.0 System: (NixOS: , Ubuntu/Fedora: , ...) (Flounder) Nix version: (run ) 1.11.2 Nixpkgs version: (run ) During testing of I managed to get at least two different hashes for . After some discussion with it seems that this derivation can produce non-deterministic output. Hashes of outputs are always the same. They are not. Build several times.
How would one work around that? It basically means the system cannot be rebuild :cry:
cc
You can work around it by updating SHA checksum in the affected package locally.
:confused: Is there any documentation you could point me too. I know how I would to it for packages that I install as a user: out nixpkgs repo the last commit that build for unstable on hydra that out the exa's file 5 run But I think it's also possible to override it in a nix expression, like the one in , since I installed it as a systems package. The thing is that all ressources I find either explain how to do it for that they link to
I changed my to include that: but to no avail :confused:
Sadly we don't have a mechanism to override (it needs to be supported). However, you can rebuild your whole NixOS from a modified repository:
Another way to do it is to call patched nixpkgs from your :
Thanks for your help! I really appreciate it. I tried your last suggestions, but that leads to: It looks like some network hick up, but I tried it multiple times and I opened the github repository from the same machine and it loads fine. Maybe it has something to do with this line: ?
Hm, unfortunately I have no idea what's going on -- you've fixed the hash, so it seems like another problem in .
Still thanks for the help. I learned a lot!
depends on a git repository in which doesn't work with
maybe fetchcargo could take an argument to pin git-based dependencies on a certain commit?
I can confirm that this is still an issue when building : through AUR/exa-git. cc
Are there any updates on this issue, please?
Should be fixed.

Related discussion:
text: /* Cargo binary snapshot */ <del> let snapshotDate = "2015-06-17"; </del> <ins> let snapshotDate = "2016-01-31"; </ins> in with ((import ./common.nix) {