jiebi/CodeConvo huggingface dataset:
Change:
, backendStdenv , fetchFromGitHub , which <del> , cudaPackages ? { } , addOpenGLRunpath </del> <ins> , autoAddOpenGLRunpathHook , cuda_cccl , cuda_cudart , cuda_nvcc , cudaFlags , cudaVersion </ins> }: <del> with cudaPackages; </del> let # Output looks like "-gencode=arch=compute_86,code=sm_86 -gencode=arch=compute_86,code=compute_86" gencode = lib.concatStringsSep " " cudaFlags.gencode; in <del> backendStdenv.mkDerivation rec { name = "nccl-${version}-cuda-${cudaPackages.cudaMajorVersion}"; </del> <ins> backendStdenv.mkDerivation (finalAttrs: { name = "nccl-${finalAttrs.version}-cuda-${cudaVersion}"; </ins> version = "2.16.5-1"; src = fetchFromGitHub { owner = "NVIDIA"; repo = "nccl"; <del> rev = "v${version}"; </del> <ins> rev = "v${finalAttrs.version}"; </ins> hash = "sha256-JyhhYKSVIqUKIbC1rCJozPT1IrIyRLGrTjdPjJqsYaU="; };

Discussion:
is only ever built with the default version of because the line which adds the derivation never changes the version of provided: I confirmed this by making this change to the derivation and trying to build it with two different versions of . Notice that the error is the same: <details</detailsIn the pattern seems to be passing . However, it is relatively rare that the derivation takes as an argument. Instead, it seems to be preferred to have the derivation take, as arguments, the actual python packages required. To bring the NCCL derivation in line with this pattern, it should take the CUDA packages it requires as arguments. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
We only expose nccl as . Let's change it to take cudaPackages' individual attributes as arguments, so that works properly. Nccl already uses solely the redist packages, so I guess we needn't worry about cuda10
Agreed -- WIP at Running a now :)
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Well, since gh pushed a notification anyway: that's one long nixpkgs-review:)

As proposed in , should switch to because invoking is manual and can easily cause breakages if files are missed. This is a followup from <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
jq '{ name, version, dependencies: (.dependencies + .devDependencies) }' "$node_src/package.json"  >"$build_deps/package.json.new" <ins> # FIXME: rollup@2.55.0 breaks the build: https://github.com/rollup/rollup/issues/4195 sed 's/"rollup": ".*"/"rollup": "=2.51.1"/' --in-place "$build_deps/package.json.new" </ins> if cmp --quiet "$build_deps"/package.json{.new,}; then echo "package.json not changed, skip updating nodePackages" rm "$build_deps"/package.json.new

Discussion:
The extension fails to activate. Steps to reproduce the behavior: the extension via home-manager to activate it by opening VS Code to a Rust project For the extension to activate successfully. Logs: Maintainer information:
Note: rolling back to fixes the issue.
Hello, I've been looking at this since yesterday. I think we need to pin rollup to 2.51 and/or update plugin-commonjs to 19 to avoid / - I am presently regenerating node- to test this fix. I think you are right that my 08-02 update introduced the regression. I apologize, ~can cut a revert PR later today if my fix doesn't work and if this would be desirable.~ The fix seems to work!
Change:
pkgconfig ]; <del> LUA_CPATH = "${luaPackages.lpeg}/lib/lua/${lua.luaversion}/?.so;${luaPackages.mpack}/lib/lua/${lua.luaversion}/?.so;${luaPackages.luabitop}/lib/lua/${lua.luaversion}/?.so"; </del> <ins> LUA_PATH = stdenv.lib.concatStringsSep ";" (map luaPackages.getLuaPath lualibs); LUA_CPATH = stdenv.lib.concatStringsSep ";" (map luaPackages.getLuaCPath lualibs); lualibs = [ luaPackages.mpack luaPackages.lpeg luaPackages.luabitop ]; </ins> <del> configureFlags = [ "-DCMAKE_BUILD_TYPE=RelWithDebInfo" "-DENABLE_JEMALLOC=ON" </del> <ins> cmakeFlags = [ "-DLUA_PRG=${luaPackages.lua}/bin/lua" </ins> ]; preConfigure = ''

Discussion:
does not build as the dependency is not supported on . With set to true the dependency fails to build. System: OS X Darwin 15.5.0 x8664 Nix version: 1.11.2 Nixpkgs version: 16.09pre-git /cc
Change:
pname = "ansi2html"; version = "1.6.0"; <ins> disabled = !isPy3k; </ins> src = fetchPypi { inherit pname version; sha256 = "0f124ea7efcf3f24f1f9398e527e688c9ae6eab26b0b84e1299ef7f94d92c596";

Discussion:
Describe the bug Installing mdcat/ansi2html fails To Reproduce Expected behavior It installs Additional context Notify maintainers (Removed actual author github handle) Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(andreas): nixpkgs:
I do not maintain this nixpkg; this is not my bug, I don't even know what Nixos is. You need to mention whoever is responsible for this packaging, but please keep me out.
I'm sorry. I was using the github owner field, but nixpkgs maintainer field refers to
Change:
<ins> { lib, buildPythonPackage, fetchPypi }: buildPythonPackage rec { pname = "reretry"; version = "0.11.8"; src = fetchPypi { inherit pname version; hash = "sha256-8nkfzr5RLqLx0VOih0d4UjqAZIYLWRzZCvwhqL7UMuM="; }; meta = with lib; { description = "An easy to use retry decorator."; homepage = "https://github.com/leshchenko1979/reretry"; license = licenses.asl20; maintainers = with maintainers; [ renatoGarcia ]; }; } </ins>

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:
stdenv.mkDerivation rec { pname = "opencl-clhpp"; <del> version = "2.0.15"; </del> <ins> version = "2024.05.08"; </ins> src = fetchFromGitHub { owner = "KhronosGroup"; repo = "OpenCL-CLHPP"; rev = "v${version}"; <del> sha256 = "sha256-A12GdevbMaO2QkGAk3VsXzwcDkF+6dEapse2xfdqzPM="; </del> <ins> sha256 = "sha256-bIm4tGqwWX0IPKH3BwLgkf0T7YFrkN6vemYvdPrqUpw="; </ins> }; nativeBuildInputs = [ cmake python3 ];

Discussion:
Auto-updates for this package seem to fail due to changes to opencl-headers that introduce cmake Seems to me like should fix this issue and no manual intervention will be needed, but I'm not entirely sure. At the moment this package is very outdated and misses bugfixes without which software using this library fails to build with certain compiler flags. I'm not sure who to tag here since the package has no maintainers. this issue seems relevant. Package name: opencl-clhpp Latest released version: 2023.12.14 <!-- Search your package here: --- Current version on the unstable channel: 2.0.15 Current version on the stable/release channel: 2.0.15 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Indeed seems like cmake patch has resolved auto-update issue:
Change:
<ins> { lib , rustPlatform , fetchFromGitHub }: rustPlatform.buildRustPackage rec { pname = "cargo-pgo"; version = "0.2.6"; src = fetchFromGitHub { owner = "kobzol"; repo = pname; rev = "v${version}"; hash = "sha256-u3kWYPLJYarwwudRpeBdJglP9kNbLRTYgEvZT2pBBoY="; }; cargoHash = "sha256-Peicupa2vFDzPCH0OQYk7plkWIn82o45oGutOyMlI2s="; # Integration tests do not run in Nix build environment due to needing to # create and build Cargo workspaces. doCheck = false; meta = with lib; { description = "Cargo subcommand for optimizing Rust binaries/libraries with PGO and BOLT"; homepage = "https://github.com/kobzol/cargo-pgo"; license = with licenses; [ mit ]; maintainers = with maintainers; [ dannixon ]; }; } </ins>

Discussion:
Project description Cargo subcommand for optimizing binaries with PGO and BOLT. Metadata homepage URL: source URL: license: mit platforms: linux
Change:
wbg = callPackage ../applications/misc/wbg { }; <del> hikari = callPackage ../applications/window-managers/hikari { wlroots = wlroots_0_15; }; </del> i3 = callPackage ../applications/window-managers/i3 { xcb-util-cursor = if stdenv.isDarwin then xcb-util-cursor-HEAD else xcb-util-cursor; };

Discussion:
With merged we want to eventually drop . That'll take at least a couple of months though and we still have around as well. I'll just open this issue so that we don't forget about it. The affected packages should switch to the latest wlroots release when possible (usually a new upstream release). There's no hurry but let's use this issue to track the current progress. Packages: TODO (currently all packages that depend on wlroots -I'll update this when we're getting closer) Previous issue:
need rebuild [x] waybar [x] mpvpaper [x] qt-video-wlr [x] wl-gammactl [x] hyprpicker TODO [ ] hikari [x] waybox: [x] pywlroots: 0.16 has been released and adapted to wlroots 0.16, but qtile need pywlroots 0.15 [x] qtile [x] phoc [x] cage: [x] cagebreak
Change:
stdenv.mkDerivation rec { pname = "gnome-shell-extension-emoji-selector"; <del> version = "20"; </del> <ins> version = "22"; </ins> src = fetchFromGitHub { owner = "maoschanz"; repo = "emoji-selector-for-gnome"; rev = version; <del> sha256 = "sha256-I5aEHDC5GaGkAoH+1l4eyhBmJ+lmyZZoDw2Fq2SSlmo="; </del> <ins> sha256 = "sha256-sD/xlNrs2ntI7KaPMopT5CnFyuXd9ZKuKPNQYgiho0U="; </ins> }; passthru = {

Discussion:
<!-- 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 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: gnome-shell-extension-emoji-selector <!-- The current version can be found easily with the same process as 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: 20 desired version: 22 <!-- 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. The emoji selector is not working with 22.05 gnome, it has to be updated to version 21 or 22.
Change:
inherit vimrcFile; # shell script with custom name passing [-u vimrc] [-U gvimrc] to vim <del> vimWithRC = {vimExecutable, name ? null, vimrcFile ? null, gvimrcFile ? null}: let rcOption = o: file: stdenv.lib.optionalString (file != null) "-${o} ${file}"; in writeScriptBin (if name == null then "vim" else name) '' #!${stdenv.shell} exec ${vimExecutable} ${rcOption "u" vimrcFile} ${rcOption "U" gvimrcFile} "$@" </del> <ins> vimWithRC = { vimExecutable, gvimExecutable, vimManPages, wrapManual, wrapGui, name ? "vim", vimrcFile ? null, gvimrcFile ? null, vimExecutableName, gvimExecutableName, }: let rcOption = o: file: stdenv.lib.optionalString (file != null) "-${o} ${file}"; vimWrapperScript = writeScriptBin vimExecutableName '' #!${stdenv.shell} exec ${vimExecutable} ${rcOption "u" vimrcFile} ${rcOption "U" gvimrcFile} "$@" </ins> ''; <ins> gvimWrapperScript = writeScriptBin gvimExecutableName '' #!${stdenv.shell} exec ${gvimExecutable} ${rcOption "u" vimrcFile} ${rcOption "U" gvimrcFile} "$@" ''; in buildEnv { inherit name; paths = [ vimWrapperScript ] ++ lib.optional wrapGui gvimWrapperScript ++ lib.optional wrapManual vimManPages ; }; </ins> # add a customize option to a vim derivation makeCustomizable = vim: vim // { <del> customize = { name, vimrcConfig }: vimWithRC { </del> <ins> customize = { name, vimrcConfig, wrapManual ? true, wrapGui ? false, vimExecutableName ? name, gvimExecutableName ? (lib.concatStrings [ "g" name ]), }: vimWithRC { </ins> vimExecutable = "${vim}/bin/vim"; <del> inherit name; </del> <ins> gvimExecutable = "${vim}/bin/gvim"; inherit name wrapManual wrapGui vimExecutableName gvimExecutableName; </ins> vimrcFile = vimrcFile vimrcConfig; <ins> vimManPages = buildEnv { name = "vim-doc"; paths = [ vim ]; pathsToLink = [ "/share/man" ]; }; </ins> }; override = f: makeCustomizable (vim.override f);

Discussion:
The wrapper only has , so the corresponding where would check for manpages is absent. don't have regular vim installed install something like 09pre104936.
You can find a fix in /
Change:
firefoxWrapper = firefox-wrapper; fuse_exfat = exfat;                   # 2015-09-11 grantlee5 = qt5.grantlee;  # added 2015-12-19 <ins> gupnptools = gupnp-tools;  # added 2015-12-19 </ins> htmlTidy = html-tidy;  # added 2014-12-06 inherit (haskell.compiler) jhc uhc;   # 2015-05-15 inotifyTools = inotify-tools;

Discussion:
I wanted to check out gupnp-tools, but the build fails with: This happens on unstable channel (nixos-16.03pre73316.) and on master.
Sounds like it needs ?
Change:
and query development modules where you can manage MySQL server instances and execute SQL queries. ''; homepage = "http://wb.mysql.com/"; <del> license = licenses.gpl2; maintainers = [ ]; platforms = platforms.linux; </del> <ins> license = lib.licenses.gpl2Only; </ins> mainProgram = "mysql-workbench"; <ins> maintainers = with lib.maintainers; [ tomasajt ]; platforms = lib.platforms.linux; </ins> }; <del> } </del> <ins> }) </ins>

Discussion:
Steps to reproduce the behavior: Stumbled upon this when upgrading my NixOS flake from to No maintainers so I'll just ping the last person to touch 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]:
It broke in this PR merge Okay, the problem's with libxml2, which changed its interface a bit
Okay, I managed to fix the build, will open a PR shortly.
Thank you for writing the fix and creating the PR. Is something holding up the pull request? It's been open for over a week now.
I guess noone really reviewed the PR. I can maybe ask for a review.
I tried building mysql-workbench again today but it is still failing. Is it building properly for you? Or is it something on my end? output of
the pr that fixed this hasn't hit nixos-unstable yet, wait until it does. You can check here
Change:
<ins> { config, lib, pkgs, ... }: let cfg = config.hardware.intel-gpu-tools; in { options = { hardware.intel-gpu-tools = { enable = lib.mkEnableOption "a setcap wrapper for intel-gpu-tools"; }; }; config = lib.mkIf cfg.enable { security.wrappers.intel_gpu_top = { owner = "root"; group = "root"; source = "${pkgs.intel-gpu-tools}/bin/intel_gpu_top"; capabilities = "cap_perfmon+ep"; }; }; meta = { maintainers = with lib.maintainers; [ kira-bruneau ]; }; } </ins>

Discussion:
For Intel dGPUs, requires in order to access GPU utilization. Steps to reproduce the behavior: an Intel dGPU, such as the Arc A380 and the following relevant logs: This error should not happen, and should be able to read GPU utilization. ! As you can see, GPU utilization information is not being displayed. N.A. CC Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hi It looks like there's an upstream issue tracking this: I'll look into this more to see how we can get this working, but I don't think this is something we can solve directly in the mangohud package. We'll need to use a separate NixOS module for since it'll require a security wrapper to enable . After creating a intel-gpu-tools module that sets the capabilities, I'm pretty sure we'll be able to get it working through something like this: but this would need to be used in addition to installing mangohud. Installing mangohud by itself wouldn't be enough.
Was able to get this working : Before | After ----------|--------- ! | ! Now just need to add this to a new module.
Change:
{ stdenv, fetchurl, unzip, jdk, makeWrapper }: stdenv.mkDerivation rec { <del> name = "gradle-2.1"; </del> <ins> name = "gradle-2.2.1"; </ins> src = fetchurl { url = "http://services.gradle.org/distributions/${name}-bin.zip"; <del> sha256 = "0y7qifc61nng24zn73bdwh5d0m25dnllfiwfkyw220mblag4zviy"; </del> <ins> sha256 = "420aa50738299327b611c10b8304b749e8d3a579407ee9e755b15921d95ff418"; </ins> }; installPhase = ''

Discussion:
When the user of the SSH connection used by the SSH substituter does not have a shell configured it defaults to , which causes the following error: Which actually is the decimal representation of the first few letters of the following error reported by (thanks for figuring that out). Since with the release of Nix 2.0 it has become easy to setup a SSH substituter, so I expect that more people might run into this problem. I know of at least another that reported it on the IRC. Instead of the serialized integer error it should just have reported the actual error, or at least it should have given a more specific error about the response being bogus. Forget to set for the user of the SSH substituter connection. system: host os: multi-user?: sandbox: version: (from nixos-unstable around 5 Mar) channels(root): channels(matthijs): nixpkgs: (nixos-17.09 around 22 Feb)
I some debug echo messages to my profile scripts and I got this error as well (with a different number). To fix it, I had to remove any output from the profiles ...
Just stumbled into this too. I figured should be enough on the server part, but alas.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .
I'm 90% sure this issue is still valid.
It is.
It is.
I marked this as stale due to inactivity. &rarr;
Probably still
Made to show a better error message. But I feel that should print its message to stderr instead of stdout...
I just run into this error running
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
}; }; <ins> fcitx5-skk = libsForQt5.callPackage ../tools/inputmethods/fcitx5/fcitx5-skk.nix { }; fcitx5-skk-qt = fcitx5-skk.override { enableQt = true; }; </ins> fcitx5-unikey = libsForQt5.callPackage ../tools/inputmethods/fcitx5/fcitx5-unikey.nix { }; fcitx5-configtool = libsForQt5.callPackage ../tools/inputmethods/fcitx5/fcitx5-configtool.nix { };

Discussion:
Project description fcitx5-skk is an input method engine for Fcitx5, which uses libskk as its backend. It seems some of the fcitx5 engines (including fcitx5-skk) are missing. Probably the other engines also need to be . Metadata homepage URL: source URL: license: gpl3+ platforms: linux
I wrote a package anyhow, but I'm not sure if it is OK.
PR is wellcome. What is for? Is it involved in fcitx5-qt? gcc is not necessary in because it is always here and someone may want to use other compiler such as clang.
Change:
let pname = "pgadmin"; <del> version = "6.12"; </del> <ins> version = "6.13"; </ins> src = fetchurl { url = "https://ftp.postgresql.org/pub/pgadmin/pgadmin4/v${version}/source/pgadmin4-${version}.tar.gz"; <del> sha256 = "sha256-cO7GdZDfJ0pq1jpMyrVy0UM49WhrKOIJOmMJauSkbyo="; </del> <ins> sha256 = "sha256-vLItmE76R1IzgMYEGEvIeOmbfQQac5WK12AkkZknTFU="; </ins> }; yarnDeps = mkYarnModules {

Discussion:
Steps to reproduce the behavior: pgadmin.service Add any other context about the problem here. Please run and paste the result.
I know. The PR needs to be merged.
seems like it might be some time before this gets fixed. In the meantime, is there a way I could force my system to use an older version of pgadmin? I'm using flakes for my system config.
The way I do it, is to maintain my own fork of and cherry-pick PR's like that. An older version will not work, because they will run into similar errors. You could only run an older version of . This is a problem due to updated dependencies in nixpkgs. I re-requested an review from and/or maybe someone else has time to review/commit the PR.
OK I got it working for now by changing my as follows: Please let me know if that's a terrible idea in your opinion ...
No, not really. I use my branch which I regularly update, which includes my cherry-picked commits. The commit you picked reflects the status of at the time of the commit of pgadmin (and obviously the changes to pgadmin) You just need to be aware that due to the pinning, a will not update currently and should probably be reverted once the PR got merged.
thanks that's what I'll do!
I'm a little fuzzy on what happens next here. Am I seeing correctly that this problem is still not resolved?
The PR needs to be merged. AFAIK everything is done with the PR
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Got it working using in my flake.
Change:
{ lib , stdenv <del> , fetchgit </del> <ins> , fetchFromRepoOrCz , gnu-efi </ins> , fetchurl <ins> , fetchpatch </ins> , libuuid , makeWrapper , mtools , nasm <ins> , nixosTests </ins> , perl , python3 }:

Discussion:
Steps to reproduce the behavior: The src is: We tried to use from nixpkgs in , but that made nix-build . -A fail. I guess that happened due to one of the commits between and (which is the latest commit on ) <!-- 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]:
Change:
klayout = libsForQt5.callPackage ../applications/misc/klayout { }; <del> klee = callPackage ../applications/science/logic/klee (with llvmPackages_12; { </del> <ins> klee = callPackage ../applications/science/logic/klee (with llvmPackages_13; { </ins> clang = clang; llvm = llvm; stdenv = stdenv;

Discussion:
klee building stucks at 99% Steps to reproduce the behavior: -shell -p klee Building should continue after 99% without hanging. If applicable, add screenshots to help explain your problem. The output stucks at: <!-- 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]:
Please report this upstream. nixpkgs cannot do anything about their failing tests.
I keep open this issue for tracking. Here the opened issue ticket upstream:
Thanks!
Following the advice in and looking at their Flake I used the following flake for a local development environment
Thanks. I'll do an update to latest and add that.