jiebi/CodeConvo huggingface dataset:
Code change:
Klee 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]:
Thanks for the report; looking into it.
Looks like a STP issue on master/unstable; any ideas?
KLEE works on 24.05, try that in the meantime.
See also: , , and others. Seems like this is treewide.
It looks like there's an update to ; I'll bump it after gets merged but those two changes should fix klee.

Related discussion:
text: --replace "#include <assert.h>" "" substituteInPlace lib/builtins/cpu_model${lib.optionalString (lib.versionAtLeast version "18") "/x86"}.c  --replace "#include <assert.h>" "" <del> '')); </del> <ins> '')) + lib.optionalString (lib.versionAtLeast release_version "13" && lib.versionOlder release_version "14") '' # https://github.com/llvm/llvm-project/blob/llvmorg-14.0.6/libcxx/utils/merge_archives.py # Seems to only be used in v13 though it's present in v12 and v14, and dropped in v15. substituteInPlace ../libcxx/utils/merge_archives.py  --replace-fail "import distutils.spawn" "from shutil import which as find_executable"  --replace-fail "distutils.spawn." "" ''; </ins> # Hack around weird upsream RPATH bug postInstall = lib.optionalString (stdenv.hostPlatform.isDarwin) ''
Code change:
fails: see: cc: n/a <!-- 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]:
(Fixed the title, my bad)
The current () tailscale builds fine for me on , but I gave it a try to be more "correct" anyway. I attempted to change to the following as a fix: However I seem to get the following error: I also tried running itself in the just to see what happens, and got an exec format error, presumably that's the cause of not having a completion in the first place.

Related discussion:
text: wrapProgram $out/bin/tailscaled  --prefix PATH : ${lib.makeBinPath [ iproute2 iptables getent shadow ]}  --suffix PATH : ${lib.makeBinPath [ procps ]} <ins> sed -i -e "s#/usr/sbin#$out/bin#" -e "/^EnvironmentFile/d" ./cmd/tailscaled/tailscaled.service install -D -m0444 -t $out/lib/systemd/system ./cmd/tailscaled/tailscaled.service '' + lib.optionalString (stdenv.buildPlatform.canExecute stdenv.hostPlatform) '' </ins> local INSTALL="$out/bin/tailscale" installShellCompletion --cmd tailscale  --bash <($out/bin/tailscale completion bash)  --fish <($out/bin/tailscale completion fish)  --zsh <($out/bin/tailscale completion zsh) <del> sed -i -e "s#/usr/sbin#$out/bin#" -e "/^EnvironmentFile/d" ./cmd/tailscaled/tailscaled.service install -D -m0444 -t $out/lib/systemd/system ./cmd/tailscaled/tailscaled.service </del> ''; passthru.tests = {
Code change:
Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

Related discussion:
text: <del> { lib, fetchFromGitHub, python3Packages }: </del> <ins> { lib, fetchFromGitHub, python3Packages, gobject-introspection, wrapGAppsNoGuiHook }: </ins> python3Packages.buildPythonPackage rec { pname = "open-fprintd";
Code change:
Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

Related discussion:
text: sha256 = "sha256-uVFuwtsmR/9epoqot3lJ/5v5OuJjuRjL7FJF7oXNDzU="; }; <ins> nativeBuildInputs = [ wrapGAppsNoGuiHook gobject-introspection ]; </ins> propagatedBuildInputs = with python3Packages; [ dbus-python pygobject3 ]; checkInputs = with python3Packages; [ dbus-python ];
Code change:
Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

Related discussion:
text: --replace /usr/lib/open-fprintd "$out/lib/open-fprintd" ''; <ins> dontWrapGApps = true; makeWrapperArgs = [ "${gappsWrapperArgs[@]}" ]; </ins> postFixup = '' wrapPythonProgramsIn "$out/lib/open-fprintd" "$out $pythonPath" '';
Code change:
Flexget is not building on python3.12 on NixOS Unstable since nose 1.3.7 does not run on python 3.12 According to flexget website only pything versions 3.7 to 3.11 are supported: Steps to reproduce the behavior: to nixos unstable to install flex A clear and concise description of what you expected to happen. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

Related discussion:
text: <del> { lib , python3 , fetchFromGitHub }: python3.pkgs.buildPythonApplication rec { pname = "flexget"; version = "3.11.39"; pyproject = true; # Fetch from GitHub in order to use `requirements.in` src = fetchFromGitHub { owner = "Flexget"; repo = "Flexget"; rev = "refs/tags/v${version}"; hash = "sha256-saNxs+Xdf6OTRRcMTceU8/ITcYzwtP8VqRKxsWyas+o="; }; postPatch = '' # remove dependency constraints but keep environment constraints sed 's/[~<>=][^;]*//' -i requirements.txt ''; build-system = with python3.pkgs; [ setuptools wheel ]; dependencies = with python3.pkgs; [ # See https://github.com/Flexget/Flexget/blob/master/requirements.txt apscheduler beautifulsoup4 click colorama commonmark feedparser guessit html5lib jinja2 jsonschema loguru more-itertools packaging pendulum psutil pynzb pyrsistent pyrss2gen python-dateutil pyyaml rebulk requests rich rpyc sqlalchemy typing-extensions # WebUI requirements cherrypy flask-compress flask-cors flask-login flask-restful flask-restx flask pyparsing werkzeug zxcvbn # Plugins requirements transmission-rpc ]; pythonImportsCheck = [ "flexget" "flexget.plugins.clients.transmission" ]; # ~400 failures doCheck = false; meta = with lib; { homepage = "https://flexget.com/"; changelog = "https://github.com/Flexget/Flexget/releases/tag/v${version}"; description = "Multipurpose automation tool for all of your media"; license = licenses.mit; maintainers = with maintainers; [ pbsds ]; }; } </del>
Code change:
Flexget is not building on python3.12 on NixOS Unstable since nose 1.3.7 does not run on python 3.12 According to flexget website only pything versions 3.7 to 3.11 are supported: Steps to reproduce the behavior: to nixos unstable to install flex A clear and concise description of what you expected to happen. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

Related discussion:
text: <ins> { lib , python3 , python311 , fetchFromGitHub }: let python = if (builtins.tryEval python3.pkgs.nose.outPath).success then python3 else python311; in python.pkgs.buildPythonApplication rec { pname = "flexget"; version = "3.11.41"; pyproject = true; # Fetch from GitHub in order to use `requirements.in` src = fetchFromGitHub { owner = "Flexget"; repo = "Flexget"; rev = "refs/tags/v${version}"; hash = "sha256-ZSqkD53fdDnKulVPgM9NWXVFXDR0sZ94mRyV1iKS87o="; }; postPatch = '' # remove dependency constraints but keep environment constraints sed 's/[~<>=][^;]*//' -i requirements.txt ''; build-system = with python.pkgs; [ setuptools wheel ]; dependencies = with python.pkgs; [ # See https://github.com/Flexget/Flexget/blob/master/pyproject.toml apscheduler beautifulsoup4 colorama feedparser guessit html5lib jinja2 jsonschema loguru psutil pynzb pyrss2gen python-dateutil pyyaml rebulk requests rich rpyc sqlalchemy # WebUI requirements cherrypy flask-compress flask-cors flask-login flask-restx flask packaging pyparsing werkzeug zxcvbn pendulum # Plugins requirements transmission-rpc qbittorrent-api deluge-client cloudscraper python-telegram-bot ]; pythonImportsCheck = [ "flexget" "flexget.api.core.authentication" "flexget.api.core.database" "flexget.api.core.plugins" "flexget.api.core.schema" "flexget.api.core.server" "flexget.api.core.tasks" "flexget.api.core.user" "flexget.components.thetvdb.api" "flexget.components.tmdb.api" "flexget.components.trakt.api" "flexget.components.tvmaze.api" "flexget.plugins.clients.aria2" "flexget.plugins.clients.deluge" "flexget.plugins.clients.nzbget" "flexget.plugins.clients.pyload" "flexget.plugins.clients.qbittorrent" "flexget.plugins.clients.rtorrent" "flexget.plugins.clients.transmission" "flexget.plugins.services.kodi_library" "flexget.plugins.services.myepisodes" "flexget.plugins.services.pogcal_acquired" ]; # ~400 failures doCheck = false; meta = with lib; { homepage = "https://flexget.com/"; changelog = "https://github.com/Flexget/Flexget/releases/tag/v${version}"; description = "Multipurpose automation tool for all of your media"; license = licenses.mit; maintainers = with maintainers; [ pbsds ]; }; } </ins>
Code change:
Flexget is not building on python3.12 on NixOS Unstable since nose 1.3.7 does not run on python 3.12 According to flexget website only pything versions 3.7 to 3.11 are supported: Steps to reproduce the behavior: to nixos unstable to install flex A clear and concise description of what you expected to happen. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

Related discussion:
text: flamp = callPackage ../applications/radio/flamp { }; <del> flexget = callPackage ../applications/networking/flexget { }; </del> fldigi = callPackage ../applications/radio/fldigi { hamlib = hamlib_4; };
Code change:
Package name: vkquake Latest released version: 1.22.3 Current version on the unstable channel: 1.22.3 Current version on the stable/release channel: 1.22.3 Notify maintainers Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

Related discussion:
text: githubId = 4201956; name = "pongo1231"; }; <ins> PopeRigby = { name = "PopeRigby"; github = "poperigby"; githubId = 20866468; }; </ins> poptart = { email = "poptart@hosakacorp.net"; github = "terrorbyte";
Code change:
Package name: vkquake Latest released version: 1.22.3 Current version on the unstable channel: 1.22.3 Current version on the stable/release channel: 1.22.3 Notify maintainers Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

Related discussion:
text: <del> { lib, stdenv, fetchFromGitHub, makeWrapper , SDL2, gzip, libvorbis, libmad, vulkan-headers, vulkan-loader, moltenvk </del> <ins> { lib, stdenv, fetchFromGitHub, meson, ninja, glslang, pkg-config, flac, libopus, opusfile, makeWrapper, SDL2, gzip, libvorbis, libmad, vulkan-loader, moltenvk, </ins> }: stdenv.mkDerivation rec { pname = "vkquake"; <del> version = "1.22.3"; </del> <ins> version = "1.31.0"; </ins> src = fetchFromGitHub { owner = "Novum"; repo = "vkQuake"; rev = version; <del> sha256 = "sha256-+8DU1QT3Lgqf1AIReVnXQ2Lq6R6eBb8VjdkJfAn/Rtc="; </del> <ins> sha256 = "sha256-3xWwqN0EcwDMEhVxfLa0bMMClM+zELEFWzO/EJvPNs0="; </ins> }; <del> sourceRoot = "${src.name}/Quake"; </del> nativeBuildInputs = [ makeWrapper <del> vulkan-headers </del> <ins> glslang meson ninja pkg-config </ins> ]; buildInputs = [ <del> gzip </del> SDL2 <del> libvorbis </del> <ins> flac gzip </ins> libmad <ins> libopus libvorbis opusfile </ins> vulkan-loader ] ++ lib.optional stdenv.isDarwin moltenvk; buildFlags = [ "DO_USERDIRS=1" ]; <del> preInstall = '' mkdir -p "$out/bin" ''; makeFlags = [ "prefix=$(out) bindir=$(out)/bin" ]; </del> env = lib.optionalAttrs stdenv.isDarwin { NIX_CFLAGS_COMPILE = "-Wno-error=unused-but-set-variable"; }; <del> postFixup = '' wrapProgram $out/bin/vkquake  --prefix LD_LIBRARY_PATH : ${vulkan-loader}/lib </del> <ins> installPhase = '' mkdir -p "$out/bin" cp vkquake "$out/bin" </ins> ''; <del> enableParallelBuilding = true; </del> <ins> postFixup = '' patchelf $out/bin/vkquake  --add-rpath ${lib.makeLibraryPath [ vulkan-loader ]} ''; </ins> meta = with lib; { description = "Vulkan Quake port based on QuakeSpasm"; <del> mainProgram = "vkquake"; </del> homepage = src.meta.homepage; longDescription = '' vkQuake is a Quake 1 port using Vulkan instead of OpenGL for rendering.
Code change:
Package name: vkquake Latest released version: 1.22.3 Current version on the unstable channel: 1.22.3 Current version on the stable/release channel: 1.22.3 Notify maintainers Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

Related discussion:
text: ''; platforms = with platforms; linux ++ darwin; <del> maintainers = with maintainers; [ ylh ]; </del> <ins> maintainers = with maintainers; [ PopeRigby ylh ]; mainProgram = "vkquake"; </ins> }; }
Code change:
Steps to reproduce the behavior: with One test is failing: only the relevant part Add any other context about the problem here. (note, I've set the project to the geospatial team, which should be enough to have it in the radar maybe?) Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I'm currently bisecting to confirm my intuition that it is a dependency version change that is triggering this failure.
The first bad commit could be any of: Probably an upstream issue?

Related discussion:
text: buildPythonPackage rec { pname = "momepy"; <del> version = "0.7.0"; </del> <ins> version = "0.8.0"; </ins> pyproject = true; disabled = pythonOlder "3.10";
Code change:
Steps to reproduce the behavior: with One test is failing: only the relevant part Add any other context about the problem here. (note, I've set the project to the geospatial team, which should be enough to have it in the radar maybe?) Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I'm currently bisecting to confirm my intuition that it is a dependency version change that is triggering this failure.
The first bad commit could be any of: Probably an upstream issue?

Related discussion:
text: owner = "pysal"; repo = "momepy"; rev = "v${version}"; <del> hash = "sha256-HVp2a0z+5fbfkNSxnTfZPCgG2SJMlKX/zso14M18mCk="; </del> <ins> hash = "sha256-r2iGzk54MsrkYB3Sp9/B1QGKnvqPGUj3MQhk6yqIoXE="; </ins> }; build-system = [ setuptools-scm ];
Code change:
Rendering a project in Kdenlive with default rendering settings leads to the following error: Steps to reproduce the behavior: ( is the latest revision of at the moment of writing this) any clip to the timeline (for example, drag in an image) "Render..." "Render to File" You might need to use as your desktop manager to reproduce this issue. There is claiming that this crash doesn't happen on Plasma 6. I am using Plasma 5, but I am currently unable to verify if Plasma 6 would fix this issue (Plasma 6 is broken for me for unrelated reasons). Render should succeed. See issue for the previous instance of this problem. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Are you using the kdenlive matching to your desktop? Edit: nope, you are using the plasma 6 package. You want to use plasma5Packages.kdenlive.
is plasma6? Wow, that's quite a foot gun. Shouldn't it be called ? Also, fails with the same error.
It really should not matter, and will (once is entirely gone) be whatever versions upstream ships.
it seems that the problem either wasn't fixed or has resurfaced again? I was able to reproduce the exact same error with and (where is the latest revision of at the moment of writing this)
Please try again after the staging-next merge (which should make its way to unstable in a few hours).
I will. Could you explain why staging-next is relevant in this case, though? I am just curious. I checked using and in the github UI directly, and it seems that the changes from should be already present in revision .
staging-next reshuffles protobuf versions again.
I wasn't sure which staging-next merge you were originally talking about, so I tried the same thing with commits (current nixos-unstable), (current staging-next) and (current master) and I am still getting the same error. Can you reopen this issue, or should I open a new one?
Hm. Actually, I think that I figured out, what the problem is. It seems that actually saves some paths in . For example, my had the following lines: Deleting the line fixes the issue, but then adds it back again with the new path, so it will almost certainly eventually break again. I am honestly not sure, why does do this, but we should probably either patch this behavior or report it upstream.
That sounds very wrong because you have defaults from two different kdenlive versions in there.
I can tell you that I've never touched prior to this debugging session. I didn't even know it existed. Those lines seem to be automatically populated on demand. Most likely, these lines were simply generated at different times, and so they picked up different paths to the "current" version of . Also, the fact that these paths are different from each other is mostly irrelevant in this case. The real problem is that they are cached once and aren't updated when a different version of is used.

Related discussion:
text: kpurpose kdeclarative wrapGAppsHook3 <del> glaxnimate </del> ]; # Both MLT and FFMpeg paths must be set or Kdenlive will complain that it
Code change:
Rendering a project in Kdenlive with default rendering settings leads to the following error: Steps to reproduce the behavior: ( is the latest revision of at the moment of writing this) any clip to the timeline (for example, drag in an image) "Render..." "Render to File" You might need to use as your desktop manager to reproduce this issue. There is claiming that this crash doesn't happen on Plasma 6. I am using Plasma 5, but I am currently unable to verify if Plasma 6 would fix this issue (Plasma 6 is broken for me for unrelated reasons). Render should succeed. See issue for the previous instance of this problem. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Are you using the kdenlive matching to your desktop? Edit: nope, you are using the plasma 6 package. You want to use plasma5Packages.kdenlive.
is plasma6? Wow, that's quite a foot gun. Shouldn't it be called ? Also, fails with the same error.
It really should not matter, and will (once is entirely gone) be whatever versions upstream ships.
it seems that the problem either wasn't fixed or has resurfaced again? I was able to reproduce the exact same error with and (where is the latest revision of at the moment of writing this)
Please try again after the staging-next merge (which should make its way to unstable in a few hours).
I will. Could you explain why staging-next is relevant in this case, though? I am just curious. I checked using and in the github UI directly, and it seems that the changes from should be already present in revision .
staging-next reshuffles protobuf versions again.
I wasn't sure which staging-next merge you were originally talking about, so I tried the same thing with commits (current nixos-unstable), (current staging-next) and (current master) and I am still getting the same error. Can you reopen this issue, or should I open a new one?
Hm. Actually, I think that I figured out, what the problem is. It seems that actually saves some paths in . For example, my had the following lines: Deleting the line fixes the issue, but then adds it back again with the new path, so it will almost certainly eventually break again. I am honestly not sure, why does do this, but we should probably either patch this behavior or report it upstream.
That sounds very wrong because you have defaults from two different kdenlive versions in there.
I can tell you that I've never touched prior to this debugging session. I didn't even know it existed. Those lines seem to be automatically populated on demand. Most likely, these lines were simply generated at different times, and so they picked up different paths to the "current" version of . Also, the fact that these paths are different from each other is mostly irrelevant in this case. The real problem is that they are cached once and aren't updated when a different version of is used.

Related discussion:
text: mlt shared-mime-info libv4l <del> glaxnimate </del> ]; qtWrapperArgs = [
Code change:
Steps to reproduce the behavior: (or try building pkgsLLVM.llvmPackages_git.compiler-rt) It seems like useLLVM causes the sanitizers to be disabled, not sure why this is the case as LLVM can rebuild itself with sanitizers enabled (outside of nixpkgs). See Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Ok, removing those useLLVM checks resulted in this:
cc may be helpful.
Unable to reproduce this.
Huh. I just ran into it with the new llvmPackages_git 19 -20 update in nixpkgs Hopefully the above nix file will be allow someone to reproduce it.
That seems to still produce the same result.
Turns out this is related to .
CC since this is related to sanitizers.
It's reproducible by building at version : Building version works fine:
Interesting, I wasn't using no-libc I think but I was doing it under pkgsLLVM and on aarch64-linux. That version doesn't look right.
Really? It seems to be the . Also, I have good news! Following the , I tried adding to , and it works:
Yeah, that's two weeks ago. Git is updated every week on Sunday. The PR for this week's update worked (although it only tests LLVM to clang). Interesting, I can get on this tonight.

Related discussion:
text: haveLibcxx = stdenv.cc.libcxx != null; isDarwinStatic = stdenv.hostPlatform.isDarwin && stdenv.hostPlatform.isStatic && lib.versionAtLeast release_version "16"; inherit (stdenv.hostPlatform) isMusl isAarch64; <ins> noSanitizers = !haveLibc || bareMetal || isMusl || isDarwinStatic; </ins> baseName = "compiler-rt"; pname = baseName + lib.optionalString (haveLibc) "-libc";
Code change:
Steps to reproduce the behavior: (or try building pkgsLLVM.llvmPackages_git.compiler-rt) It seems like useLLVM causes the sanitizers to be disabled, not sure why this is the case as LLVM can rebuild itself with sanitizers enabled (outside of nixpkgs). See Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Ok, removing those useLLVM checks resulted in this:
cc may be helpful.
Unable to reproduce this.
Huh. I just ran into it with the new llvmPackages_git 19 -20 update in nixpkgs Hopefully the above nix file will be allow someone to reproduce it.
That seems to still produce the same result.
Turns out this is related to .
CC since this is related to sanitizers.
It's reproducible by building at version : Building version works fine:
Interesting, I wasn't using no-libc I think but I was doing it under pkgsLLVM and on aarch64-linux. That version doesn't look right.
Really? It seems to be the . Also, I have good news! Following the , I tried adding to , and it works:
Yeah, that's two weeks ago. Git is updated every week on Sunday. The PR for this week's update worked (although it only tests LLVM to clang). Interesting, I can get on this tonight.

Related discussion:
text: "-DCOMPILER_RT_BUILD_LIBFUZZER=OFF" ] ++ lib.optionals (useLLVM && haveLibc) [ "-DCOMPILER_RT_BUILD_SANITIZERS=ON" <del> ] ++ lib.optionals (!haveLibc || bareMetal || isMusl || isDarwinStatic) [ </del> <ins> ] ++ lib.optionals (noSanitizers) [ </ins> "-DCOMPILER_RT_BUILD_SANITIZERS=OFF" ] ++ lib.optionals ((useLLVM && !haveLibcxx) || !haveLibc || bareMetal || isMusl || isDarwinStatic) [ "-DCOMPILER_RT_BUILD_XRAY=OFF"