jiebi/CodeConvo huggingface dataset:
Change:
buildDunePackage rec { pname = "google-drive-ocamlfuse"; <del> version = "0.7.22"; </del> <ins> version = "0.7.26"; </ins> useDune2 = true;

Discussion:
<!-- 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: () <!-- 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: desired version: <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
Change:
hash = "sha256-3EKxuEpFm+lp2myMfymYYY9boSXGOF2iAdjtGKnjJK0="; }; <del> vendorSha256 = "sha256-tYZtnD7RUurhl8yccXlTIvOxybBJITM+it1ollYJ1OI="; </del> <ins> patches = [ ./bump-golang-x-sys.patch ]; vendorSha256 = "sha256-VsPdMUfS4UVem6uJgFISfFHQEKtIumDQktHQFPC1muc="; </ins> ldflags = [ "-s" "-w" "-X main.version=${version}" ];

Discussion:
Steps to reproduce the behavior: build -L 'nixpkgs#curlie' <details</detailsNot a go developer. I think the issue is the same as . That requires a fix from upstream; I don't know whether this is the same, though, and my attempts to patch the build (and thus demonstrate it needs an upstream fix) have been unsuccessful. I used with the following patch. This resulted in the following error. I tried vendoring the derivation and adding the call to (using ) but at this point I hit the time limit I'd set to investigate this. Please run and paste the result.
You need to update vendorSha256, too. IF you get it working please create a PR.
Change:
stdenv.mkDerivation rec { pname = "qucs-s"; <del> version = "1.1.0"; </del> <ins> version = "2.0.0"; </ins> src = fetchFromGitHub { owner = "ra3xdh"; repo = "qucs_s"; rev = version; <del> sha256 = "sha256-cQ9UNCTwRW61dOQYJX0mPNtCTk0qXKx8VQ6BIXl6Fa8="; </del> <ins> sha256 = "sha256-9/1sgxFqn9d9zlwrzjQosFO3m+2lC83qVcCtzfqY5XY="; </ins> }; nativeBuildInputs = [ flex bison wrapQtAppsHook cmake ];

Discussion:
Package name: qucs-s Latest released version: 2.0.0 Current version on the unstable channel: 1.1.0 Current version on the stable/release channel: 1.0.2 Notify maintainers Release: Note for maintainers: Please tag this issue in your PR.
Change:
passwordFile = mkOption { type = types.path; <del> description = "A file containing the initial password for the admin user."; </del> <ins> description = '' A file containing the initial password for the administrator account "admin". ''; </ins> example = "/run/keys/mediawiki-password"; };

Discussion:
Thank you greatly For fixing the recent "spaces" bug in MediaWiki . I would like to note that the default MediaWiki administrator username is implied, but has yet to be made explicit. Since there is no option to set the default administrator username, I propose to edit the documentation to make it Explicit that the default administrator username is "admin". Changing from (ambiguous) "for the admin user." Changing to (unambiguous) "for the initial user "admin"."
thanks for the suggestion. How about: ? This matches more closely the article on the subject. Plus, it avoids using the initial word twice in the same sentence. PS: I have a PR ready to submit if you agree with the suggestion.
Thanks . PR submitted.
Change:
connection-pool datrie docutils <del> filelock </del> gitpython <ins> humanfriendly </ins> jinja2 jsonschema nbformat <del> networkx </del> psutil pulp <del> pygraphviz </del> pyyaml <del> ratelimiter </del> requests <del> retry </del> <ins> reretry </ins> smart-open stopit tabulate <ins> throttler </ins> toposort wrapt yte

Discussion:
A clear and concise description of what the bug is. Steps to reproduce the behavior: a simple Snakefile such as shown below command fails with (truncated) exception message as shown below The command does not fail with an exception This is a known issue that has been fixed in the recent versions of Snakemake Please run and paste the result.
Change:
otpw = callPackage ../os-specific/linux/otpw { }; <del> ovftool = callPackage ../tools/virtualization/ovftool { }; </del> <ins> ovftool = callPackage ../tools/virtualization/ovftool { libressl = libressl_3_4; }; </ins> overcommit = callPackage ../development/tools/overcommit { };

Discussion:
LibreSSL 3.4 version will go EOL in October of this year, so we'll need to switch to 3.5
Change:
postPatch = optionalString stdenv.isDarwin '' substituteInPlace cmake/modules/AddLLVM.cmake  <del> --replace 'set(_install_name_dir INSTALL_NAME_DIR "@rpath")' "set(_install_name_dir INSTALL_NAME_DIR "$lib/lib")"  </del> <ins> --replace 'set(_install_name_dir INSTALL_NAME_DIR "@rpath")' "set(_install_name_dir)"  </ins> --replace 'set(_install_rpath "@loader_path/../lib" ''${extra_libdir})' "" '' # Patch llvm-config to return correct library path based on --link-{shared,static}.

Discussion:
Run , observe: Please run and paste the results.
Very weird... It must have come in from a recent update. You can find libLLDB in the lldb derivation:
/cc
Change:
pname = "thumbor"; version = "6.4.2"; <ins> disabled = isPy3k; # see https://github.com/thumbor/thumbor/issues/1004 </ins> src = fetchPypi { inherit pname version; sha256 = "0y9mf78j80vjh4y0xvgnybc1wqfcwm5s19xhsfgkn12hh8pmh14d";

Discussion:
The expression at is compatible with Python 3, but Thumbor itself does not support Python 3, see I think Thumbor should fail to build under Python 3 for now until it is actually supported.
cc
ouch, sorry! Will file a patch in the afternoon:)
I've opened
Change:
openssl eventlog glib <del> perl python3 </del> <ins> myPy3 </ins> systemd riemann_c_client protobufc

Discussion:
I tried to update it, but it seems like it wants to build a virtualenv and fetch dependencies. Not sure how to to properly fix it. Maybe just customizing the python and adding the deps will be enough. Package name: syslogng Latest released version: 4.1.1 <!-- Search your package here: --- Current version on the unstable channel: 3.38.1 Current version on the stable/release channel: 3.38.1 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.
will be fixed by
Change:
mitama-cpp-result = callPackage ../development/libraries/mitama-cpp-result { }; <del> mitscheme = callPackage ../development/compilers/mit-scheme { texLive = texlive.combine { inherit (texlive) scheme-small epsf texinfo; }; }; </del> <ins> mitscheme = callPackage ../development/compilers/mit-scheme { texLive = texlive.combine { inherit (texlive) scheme-small epsf texinfo; }; texinfo = texinfo6; }; </ins> mitschemeX11 = mitscheme.override { enableX11 = true;

Discussion:
Steps to reproduce the behavior: from latest master I have not seen this build successfully on my machine since before March 18. I imagine there was some wide-reaching change merged in from that caused this. Please run and paste the result.
This was caused by , The texinfo package could be overridden in for mitscheme to use texinfo6
Change:
"-DgRPC_PROTOBUF_PROVIDER=package" "-DgRPC_GFLAGS_PROVIDER=package" "-DBUILD_SHARED_LIBS=ON" <ins> "-DCMAKE_SKIP_BUILD_RPATH=OFF" </ins> ]; # CMake creates a build directory by default, this conflicts with the

Discussion:
Describe the bug grpc doesn't build on macOS. To Reproduce Steps to reproduce the behavior: -shell -p grpc Expected behavior Should have built without errors. Additional context Build log here: Metadata system: host os: multi-user?: sandbox: version: channels(kaali): nixpkgs: Maintainer information:
grpc appears to be pretty out of date , so I'm suspecting that updating all of the pieces would resolve this.
Seems to fail in CI even with an updated version:
That particular package requires manual intervention, as that PR was automatically generated by a bot.
Change:
DEPENDENCIES RedCloth jekyll <ins> jekyll-feed jekyll-paginate minima </ins> rdiscount BUNDLED WITH <del> 1.10.6 </del> <ins> 1.14.4 </ins>

Discussion:
One uses to create a new tree of files for generating a web site. So the intent is to edit those files. But the files produced are read-only, so user must do a before each new file can be edited. I haven't looked at the source yet, but I imagine this is because jekyll copies the site template out of an installed gem or something, and all the files there are 444 (read-only) because it's in the Nix store. System: NixOS 16.09.1600. (Flounder) Nix version: nix-env (Nix) 1.11.6 Nixpkgs version: 16.09.1698.
Have you tried reporting this upstream?
I have not. Will consider that – it seems that a fix would be a one-liner after to do or so. But I'm not able to test easily if that's all that would be needed – the nixpkgs expression is quite behind, carrying jekyll 3.0.1 when current release is 3.4.1. I tried updating too, but ran into bundler problems, and I don't know much about ruby.
You seem to have idea how to fix it. Should really bring this up with upstream. I don't know much about ruby, but nixpkgs manual has a step by step guide: Turned out to be very easy:
So I ran into bundler problems)
Ok, I've pushed a workaround for that
Change:
else throw "nvidia-x11 does not support platform ${stdenv.hostPlatform.system}"; patches = if libsOnly then null else patches; <del> inherit prePatch; </del> <ins> inherit prePatch postPatch; </ins> inherit version useGLVND useProfiles; inherit (stdenv.hostPlatform) system; inherit i686bundled;

Discussion:
with nixpkgs Steps to reproduce the behavior: kernel 6.1.10 <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- system: host os: multi-user?: sandbox: version: nixpkgs:
Looks like this is the patch other distros are using: Bonus patch for 6.3 if Nvidia doesn't release a maintenance update:
Change:
, enableOCR ? false , skipLint ? false , passthru ? {} <ins> , interactive ? false </ins> }: let # Reifies and correctly wraps the python test driver for

Discussion:
When building an interactive test driver with and running the generated binary, the test just runs without an interactivity. Steps to reproduce the behavior: that the test just starts instead of displaying the interactive prompt. I'd expect to be dropped into the interactive prompt. cc as someone who's touched a lot.
Mostly reviews and minor additions though. Maybe broke it, but that's just a guess. Probably best to bisect with if going back to before that doesn't fix the problem.
Ah, it was broken by
Change:
, sndio , libjack2 , speechd <ins> , removeReferencesTo </ins> }: ## configurability of the wrapper itself

Discussion:
Steps to reproduce the behavior: .config.contentAddressedByDefault = true; .firefox.package = pkgs.wrapFirefox pkgs.firefox-devedition-unwrapped {}; to build I also have march/mtune set and can't/won't use firefox-bin Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I think this is $outPath of gcc
I think my fix worked
Change:
setuptools ]; <del> buildInputs = [ libsndfile ]; </del> <ins> buildInputs = [ libsndfile glib ]; </ins> nativeCheckInputs = with python3.pkgs; [ twisted

Discussion:
it's impossible to use due to an import error: Steps to reproduce the behavior: to run eg ratbagctl "shows something". (i.e. current mouse hardware/mapping etc.) (no gui, cli only) I (may) need because it has infos/options that are not yet fully implemented in Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

When trying to launch whipper it instead fails with the following trace: Steps to reproduce the behavior: or any equivalent way of running the whipper program Clearly, I expect the program to execute without an error. I bisected the error and the bug was introduced in which bumped . <!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Note: Adding to double-wraps all executables, but allows to run successfully.
Also no double-wrapping.

As title says, openrazer-daemon no longer work after update. Steps to reproduce the behavior: system -daemon fail to start. Openrazer-daemon start on boot. If applicable, add screenshots to help explain your problem. Manually calling openrazer-daemon -Fv print me this: <!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
overlay fix for anyone who have this issue.
This overlay fix worked for me, thank you!
Change:
description = "Programming library for Agda"; license = stdenv.lib.licenses.mit; platforms = stdenv.lib.platforms.unix; <del> maintainers = with maintainers; [ fuuzetsu ]; </del> <ins> maintainers = with maintainers; [ fuuzetsu mudri ]; </ins> }; })

Discussion:
As of Agda 2.5.1 (which comes on the latest nixos-unstable release), both nixpkgs' agda-stdlib (from git nominally at version 2.4.2.3) and an updated version (v0.12, the most recent release) fail to build. Some modules are checked successfully, but it gets stuck at (the first builtin module it finds). For this module only, it tries to write to . Output: System: (Flounder) Nix version: nix-env (Nix) 1.11.2 Nixpkgs version: ""
has the same issue, meaning that there has probably been some change in Agda. The problem seems to be that writes a file for each file it checks, and some files it's checking are in the Nix store (specifically, in ). I think it's to do with . Maybe it would work if these were checked when building .
Current status: .
Fixed by .
Let's keep this open until the fix lands in master.
Change:
in buildDotnetModule rec { pname = "fsautocomplete"; <del> version = "0.67.0"; </del> <ins> version = "0.68.0"; </ins> src = fetchFromGitHub { owner = "fsharp"; repo = "FsAutoComplete"; rev = "v${version}"; <del> sha256 = "sha256-txHkQDLyIejsEZGpfIGqeiJ8EUePZq1btxfd+EZD4aM="; </del> <ins> sha256 = "sha256-wAPTJXD2CxZQA2EG4rQCM9v3dIu6hn3q23K7Vv9wkAk="; </ins> }; nugetDeps = ./deps.nix;

Discussion:
Package name: fsautocomplete Latest released version: Current version on the unstable channel: 0.67.0 Current version on the stable/release channel: nil <!-- 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.
Change:
"-DQTERMWIDGET_INCLUDE_DIRS=${qtermwidget}/include/qtermwidget5" ]; <del> patches = [ (fetchpatch { # drop with next update url = "https://github.com/F1ash/qt-virt-manager/commit/0d338b037ef58c376d468c1cd4521a34ea181edd.patch"; sha256 = "1wjqyc5wsnxfwwjzgqjr9hcqhd867amwhjd712qyvpvz8x7p2s24"; }) ]; </del> buildInputs = [ qtbase qtmultimedia qtsvg krdc libvirt libvncserver pcre pixman qtermwidget spice-gtk spice-protocol

Discussion:
Steps to reproduce the behavior: virt-manager-qt on 24.05 (or, I assume, unstable) Full log: Bisecting the build yields from as the first bad commit. It updates from to . <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Relevant upstream commit:
Change:
{ lib, vscode-utils <del> , fetchurl, mono, writeScript, runtimeShell </del> <ins> , fetchurl, writeScript, runtimeShell </ins> , jq, clang-tools , gdbUseFixed ? true, gdb # The gdb default setting will be fixed to specified. Use version from `PATH` otherwise. <ins> , autoPatchelfHook, makeWrapper, stdenv, lttng-ust, libkrb5, zlib </ins> }: /*

Discussion:
OpenDebug does not work. vscode-cpptools working opendebug -not work !
correct path ) !
Change:
item=${desktopItem} makeWrapper "$out/$pname/bin/${loName}.sh" "$out/bin/${pname}"  <del> --prefix PATH : "$out/libexec/${pname}:${lib.makeBinPath [ jdk coreutils gnugrep which git ]}"  </del> <ins> --prefix PATH : "$out/libexec/${pname}:${lib.makeBinPath [ jdk coreutils gnugrep which git python3 ]}"  </ins> --prefix LD_LIBRARY_PATH : "${lib.makeLibraryPath ([ # Some internals want libstdc++.so.6 stdenv.cc.cc.lib libsecret e2fsprogs

Discussion:
IntelliJ (and I'm assuming other jetbrains products) uses a Python script to restart itself whenever needed (e.g. a plugin update), and if it detects that there is no Python, it shutdowns instead. Steps to reproduce the behavior: intellij. In the menu, select "File" -"Invalidate Caches..." there is no python in path, the opened window will have a button "Invalidate and Exit" run from , it will have "Invalidate and Restart" Same thing happens whenever it needs to restart, with/without python it shows "Restart"/"Shutdown" buttons respectively, and in some conditions it just asks "Restart now?" and then does not come back up when you agree. I know it's easy to fix on my end, but it's not super clear that that's even an issue, and I think python should be to dependencies and made visible to jetbrains IDEs. And yes I don't have system-wide python installed, that's the whole point of NixOS, is it not? :) I guess
I can confirm this affects the other JetBrains IDEs as well. Adding to the solves this problem. I'll open a PR for it shortly.
Change:
lib, buildPythonPackage, cryptography, <ins> esptool, </ins> fetchFromGitHub, netifaces, pyserial, pythonOlder, <ins> replaceVars, </ins> setuptools, }:

Discussion:
I want to use binaries from . I am able to install it and run it but once I get to the part of the program that requires ( ) it fails with this error: But I can see listed as dependency, so I am not sure what is going on. Steps to reproduce the behavior: to your packages and select correct values for your device it downloads the firmware and tries to flash it, it will fail with the error above is recognized as installed dependency Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Digging a bit deeper it seems like the program is generating some python script in my config folder which is executed outside of the context of the package. Any idea how to solve it?
It seems to download its own version of esptool. We should patch the code to use the esptool package from Nixpkgs.
I think this is what's happening: It's literally writing a script to file and then calling it. I thought about changing the shebang to use the Nixpkgs python3 version via , but I don't know how to also include the dependency as part of it.
You could probably replace it with something like this? (taken from ) Not sure if there are other dependencies that are needed or how to patch the code (I am so far only user of NixOS)
OK this are the imports from the file that gets decoded: no other imports in the rest of the file. So it seems like only the needs to be .
I sent a PR here: do you wanna test it out? You can build it locally by pulling down this PR and running this in the root of nixpkgs directory:
Look what I have found: Could this be the whole reason behind this?
Change:
pythonOlder, setuptools, six, <ins> fetchpatch2, </ins> }: buildPythonPackage rec {

Discussion:
wfuzz installation returns the following error: Steps to reproduce the behavior: <!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
There is PR upstream that supposedly fixes compatibility with python 3.12 (removed imp module): so it may be as simple as getting that patch into nixpkgs
Change:
<ins> module github.com/namecoin/ncdns go 1.22.5 replace github.com/namecoin/x509-compressed => ./x509 replace gopkg.in/alecthomas/kingpin.v2 => github.com/alecthomas/kingpin/v2 v2.3.2 require ( github.com/btcsuite/btcd v0.24.2 github.com/fxamacker/cbor v1.5.1 github.com/golang/groupcache v0.0.0-20210331224755-41bb18bfe9da github.com/hlandau/buildinfo v0.0.0-20161112115716-337a29b54997 github.com/hlandau/degoutils v0.0.0-20161011040956-8fa2440b6344 github.com/hlandau/dexlogconfig v0.0.0-20220319061854-86a3fc314fe7 github.com/hlandau/nctestsuite v0.0.0-20151129185958-a9b78806c85c github.com/hlandau/xlog v1.0.0 github.com/kr/pretty v0.3.1 github.com/miekg/dns v1.1.61 github.com/namecoin/certinject v0.1.1 github.com/namecoin/ncbtcjson v0.1.0 github.com/namecoin/ncrpcclient v0.1.0 github.com/namecoin/splicesign v0.0.1 github.com/namecoin/tlsrestrictnss v0.0.5 github.com/namecoin/x509-compressed v0.0.0-00010101000000-000000000000 gopkg.in/hlandau/easyconfig.v1 v1.0.18 gopkg.in/hlandau/madns.v2 v2.0.2 gopkg.in/hlandau/service.v2 v2.0.17 ) require ( github.com/BurntSushi/toml v1.4.0 // indirect github.com/alecthomas/units v0.0.0-20211218093645-b94a6e3cc137 // indirect github.com/btcsuite/btcd/btcec/v2 v2.1.3 // indirect github.com/btcsuite/btcd/btcutil v1.1.5 // indirect github.com/btcsuite/btcd/chaincfg/chainhash v1.1.0 // indirect github.com/btcsuite/btclog v0.0.0-20170628155309-84c8d2346e9f // indirect github.com/btcsuite/go-socks v0.0.0-20170105172521-4720035b7bfd // indirect github.com/btcsuite/websocket v0.0.0-20150119174127-31079b680792 // indirect github.com/coreos/go-systemd v0.0.0-20191104093116-d3cd4ed1dbcf // indirect github.com/decred/dcrd/crypto/blake256 v1.0.0 // indirect github.com/decred/dcrd/dcrec/secp256k1/v4 v4.0.1 // indirect github.com/erikdubbelboer/gspt v0.0.0-20210805194459-ce36a5128377 // indirect github.com/kr/text v0.2.0 // indirect github.com/mattn/go-isatty v0.0.20 // indirect github.com/namecoin/crosssignnameconstraint v0.0.3 // indirect github.com/ogier/pflag v0.0.1 // indirect github.com/rogpeppe/go-internal v1.9.0 // indirect github.com/shiena/ansicolor v0.0.0-20230509054315-a9deabde6e02 // indirect github.com/x448/float16 v0.8.4 // indirect github.com/xhit/go-str2duration/v2 v2.1.0 // indirect golang.org/x/crypto v0.25.0 // indirect golang.org/x/mod v0.18.0 // indirect golang.org/x/net v0.26.0 // indirect golang.org/x/sync v0.7.0 // indirect golang.org/x/sys v0.22.0 // indirect golang.org/x/tools v0.22.0 // indirect gopkg.in/alecthomas/kingpin.v2 v2.0.0-00010101000000-000000000000 // indirect gopkg.in/hlandau/configurable.v1 v1.0.1 // indirect gopkg.in/hlandau/svcutils.v1 v1.0.11 // indirect ) </ins>

Discussion:
Steps to reproduce the behavior: ncdns.goModules with or 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The goModules derivation can't be built since go 1.17, see I don't think I can fix it.