jiebi/CodeConvo huggingface dataset:
Change:
}; }; <del> bash-language-server = prev.bash-language-server.override { nativeBuildInputs = [ pkgs.buildPackages.makeWrapper ]; postInstall = '' wrapProgram "$out/bin/bash-language-server"  --prefix PATH : ${lib.makeBinPath [ pkgs.shellcheck ]} ''; }; </del> bower2nix = prev.bower2nix.override { nativeBuildInputs = [ pkgs.buildPackages.makeWrapper ]; postInstall = ''

Discussion:
Steps to reproduce the behavior: This seems to have been caused by although I'm not familiar with the package, so I could be wrong. It is causing to fail as a result. I don't quite understand the organization of the structure, so I'm not sure who the appropriate maintainer is. As a fallback, and were involved in the above linked PR, so they may be of help here. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
sorry for the breakage, i opened to fix this
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Had the same issue. But I think it's fixed in PR as mentioned You can track the progress of the PR , apparently it hasn't been merged into nixpkgs-unstable yet.
Change:
meta = with lib; { description = "Provides library functionality for FIDO 2.0, including communication with a device over USB."; <del> homepage = https://github.com/Yubico/python-fido2; license = licenses.mpl20; </del> <ins> homepage = "https://github.com/Yubico/python-fido2"; license = licenses.bsd2; maintainers = with maintainers; [ prusnak ]; </ins> }; }

Discussion:
Describe the bug Since the commit this package does not build. It fails with the following output: To Reproduce Steps to reproduce the behavior: Expected behavior Package should be building without errors. Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Can reproduce, strange. Good news is bumping (as I happened to do locally earlier today for other reasons, haha) seems to fix things-- can you confirm that moving to 0.8.1 as in fixes this?
I can confirm that bump to 0.8.1 fixes the build. (However we have 0.7.3 already in master, so the change from does not apply cleanly). I sent the PR in where I also add myself as a maintainer.
Change:
sha256 = "1msp7w3563vb43w70myjmqsdb97kna54dcfa7yvi9l3bvamb92w3"; }; <del> buildInputs = [ cmake ] ++ (if stdenv.isDarwin then with darwin.apple_sdk.frameworks; [ Cocoa OpenGL ] else [libGLU_combined freeglut]); </del> <ins> nativeBuildInputs = [ cmake ]; buildInputs = stdenv.lib.optionals stdenv.isLinux [ libGLU_combined freeglut ] ++ stdenv.lib.optionals stdenv.isDarwin [ Cocoa OpenGL ]; </ins> patches = [ ./gwen-narrowing.patch ];

Discussion:
! See the . This is to discuss Darwin-specific issues for ZHF. (or more)
Change:
<ins> From e97f418803c1db9a753fa755a9ee0cf04eabaed3 Mon Sep 17 00:00:00 2001 From: rembo10 <rembo10@users.noreply.github.com> Date: Sun, 11 Sep 2022 13:00:29 +0530 Subject: [PATCH] Allow running on unsupported Python versions --- sickgear.py | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/sickgear.py b/sickgear.py index 9d0440bb..6d65e65d 100755 --- a/sickgear.py +++ b/sickgear.py @@ -43,10 +43,7 @@ versions = [((2, 7, 9), (2, 7, 18)), ((3, 7, 1), (3, 8, 14)), ((3, 9, 0), (3, 9, 2)), ((3, 9, 4), (3, 9, 14)), ((3, 10, 0), (3, 10, 7))]  # inclusive version ranges if not any(list(map(lambda v: v[0] <= sys.version_info[:3] <= v[1], versions))) and not int(os.environ.get('PYT', 0)): -    print('Python %s.%s.%s detected.' % sys.version_info[:3]) -    print('Sorry, SickGear requires a Python version %s' % ', '.join(map( -        lambda r: '%s - %s' % tuple(map(lambda v: str(v).replace(',', '.')[1:-1], r)), versions))) -    sys.exit(1) +    pass sys.path.insert(1, os.path.abspath(os.path.join(os.path.dirname(__file__), 'lib'))) is_win = 'win' == sys.platform[0:3] -- 2.37.2 </ins>

Discussion:
A number of dependencies which are technically optional (but without which some features don't work) appear to be missing from the SickRage package: (Presumably this requires some Python package?) (Presumably this requires ?) Steps to reproduce the behavior: SickGear from nixpkgs subtitle fetching a show with subtitles enabled at regular logs (for the subtitle warning) and error logs (for the rar error) I'm not entirely sure when or why SickGear fetches the file, but I think the subtitle fetch is attempted when a show episode is being searched for. Features should work out of the box. N/A N/A Please run and paste the result. Note: SickGear is installed from , even though I am running stable.
The only problem I can see is that unrar is unfree.... Just looking through the , it looks like it can also use bsdtar from libarchive.... so I'm not sure the best way to handle it.
Maybe you can test out
Change:
buildInputs = lib.optional pamSupport pam; patches = [ <del> ./../gitea/static-root-path.patch </del> <ins> ./static-root-path.patch </ins> ]; postPatch = '' <del> substituteInPlace modules/setting/setting.go --subst-var data </del> <ins> substituteInPlace modules/setting/server.go --subst-var data </ins> ''; tags = lib.optional pamSupport "pam"

Discussion:
forgejo fails to start up because the static file root path that is meant to point at the output of the package was not correctly patched at build time Steps to reproduce the behavior: forgejo (I used nixpkgs-unstable) (I was moving an existing install to the nix package to be up to date) the following output: Forgejo should find the required frontend files provided by the output and start properly. I am aware that using nix and especially nixpkgs-unstable on a non-NixOS system comes with essentially no warranty whatsoever. However, given that the nix derivation is clearly intended to remove this placeholder () and that it failing to do so seems to be the only thing wrong with my installation, I do not believe there is an error on my part. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
Hi, thanks a lot for the report! Turns out, there is a typo in It should be not , just like the patch: This went unnoticed when using forgejo with the nixos module, because we explicitly set in the to by default[^1]. Will open a PR with a fix shortly :) [^1]:
Thank you very much! I didn't notice the typo, glad I was able to provide enough information anyhow ^^
I heard substituteInPlace has a new --replace-fail option(?). Using that should prevent silent failures like this.
There is now. From what I can tell, does not apply to . But feel free to check and write a review in :)
Change:
# both are auto-generated by pkgs/development/tools/haskell/haskell-language-server/update.sh haskell-language-server = self.callPackage ../tools/haskell/haskell-language-server { }; hls-ghcide = self.callPackage ../tools/haskell/haskell-language-server/hls-ghcide.nix { }; <ins> hls-brittany = self.callPackage ../tools/haskell/haskell-language-server/hls-brittany.nix { }; </ins> # cabal2nix --revision <rev> https://github.com/hasura/ci-info-hs.git ci-info = self.callPackage ../misc/haskell/hasura/ci-info {};

Discussion:
Describe the bug , a nested dependency, requires < 4.1.14. To Reproduce
Can probably be closed now?
Yes, I thought that would happen automatically.
I just bumped on (something very similar to?) this:
Change:
autoreconfHook = buildPackages.autoreconfHook269; }; <ins> asusctl = callPackage ../applications/system/asusctl { }; </ins> autorevision = callPackage ../tools/misc/autorevision { }; automirror = callPackage ../tools/misc/automirror { };

Discussion:
Project description It is a command line utility which adds features for asus laptops. For example graphics card switching, anime matrix control (for g14). fan control, keyboard backlight control, cpu boost control, profiles, fan curves and other stuff. It basically unlocks a lot of functionality for laptops and can be used for non asus laptops as well contrary to the name. Metadata homepage URL:https://asus- source license: Mozilla Public License 2.0 platforms: Linux
I've made a PR to introduce the asusctl package as well as a NixOS module to run asusd. Can someone give this a try, I personally do not have Asus hardware to test it properly. You can find the PR here:
Change:
--replace TargetFrameworks TargetFramework  ''; <del> dotnet-sdk = combinePackages [ sdk_7_0 sdk_6_0 ]; dotnet-runtime = sdk_6_0; </del> <ins> dotnet-sdk = sdk_7_0; dotnet-runtime = sdk_7_0; </ins> projectFile = "src/FsAutoComplete/FsAutoComplete.fsproj"; executables = [ "fsautocomplete" ];

Discussion:
After the upgrade to 0.68.0 fsautocomplete no longer attach properly to NixVim (neovim). Steps to reproduce the behavior: a minimal NixVim config enable fsautocomplete and Ionide-vim a .fsx file the LspInfo command a see the missing id The clients get associated with an id as before. Version 0.67.0 ! Version 0.68.0 ! I haven't explored if the problem persists outside NixVim, but I would strongly suspect it does, as there haven't been any major changes in NixVim lately. <!-- 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]:
I can confirm you findings. It's an issue with 0.68.0. I'll do some more investigation before filing an issue upstream. for now, you can pin you fsautocomplete to 0.67.0
I've just been testing it a bit as well and came to the same conclusion that it is an upstream problem. I reconfigured my nixvim to build the from the nuget package and that one has the same issue. How do I pin in nixvim?
sorry I am not familiar with nixvim, my neovim just calls fsautocomplete from PATH. So I've just installed an old version via thats the commit just before 0.68.0 update
are you able to test ?
Working on it.
Change:
buildPhase = "make"; }; <ins> beetle-pce-fast = (mkLibRetroCore rec { core = "mednafen-pce-fast"; src = fetchRetro { repo = "beetle-pce-fast-libretro"; rev = "6e2eaf75da2eb3dfcf2fd64413f471c8c90cf885"; sha256 = "0m946108wzawg0c4xvqpv6yzfmjngz6lji5hn4swgk0z5f2bj5a5"; }; description = "Port of Mednafen's PC Engine core to libretro"; }).override { buildPhase = "make"; name = "beetle-pce-fast"; }; beetle-psx = (mkLibRetroCore rec { core = "mednafen-psx"; src = fetchRetro { repo = "beetle-psx-libretro"; rev = "20c9b0eb0062b8768cc40aca0e2b2d626f1002a2"; sha256 = "192xzvdbjjqlxrnxxn45hmrr6yjpxw3gapkbax6nhrabnxhva43k"; }; description = "Port of Mednafen's PSX Engine core to libretro"; }).override { buildPhase = "make"; name = "beetle-psx"; }; beetle-saturn = (mkLibRetroCore rec { core = "mednafen-saturn"; src = fetchRetro { repo = "beetle-saturn-libretro"; rev = "bb5d0c126feb25cf980f5cc1fc57d6a5a6f6e7ab"; sha256 = "0bnsdy27378b71y6aa65k4jxxy2xw6ky2ici3z53hkky2jnnjq0b"; }; description = "Port of Mednafen's Saturn core to libretro"; }).override { buildPhase = "make"; name = "beetle-saturn"; }; </ins> bsnes-mercury = let bname = "bsnes-mercury"; in (mkLibRetroCore rec { core = bname + "-accuracy"; src = fetchRetro {

Discussion:
Please rename the libretro-mednafen- cores packages to libretro-beetle- or similar; the RetroArch/libretro project does not have permission nor blessings to use "Mednafen" branding for their forks, and have been cooperative in renaming the cores in light of this.
cc
Superseded by .
Change:
{ stdenv, fetchFromGitHub, rustPlatform }: rustPlatform.buildRustPackage rec { <del> name = "lsd-${version}"; version = "0.13.0"; </del> <ins> pname = "lsd"; version = "0.14.0"; </ins> src = fetchFromGitHub { owner = "Peltoche"; repo = "lsd"; rev = version; <del> sha256 = "0s0pgnhzhkjm78cp12jscpld0m2mslin5yb273wzdvx4wax2s17z"; </del> <ins> sha256 = "1k054c4mz0z9knfn7kvvs3305z2g2w44l0cjg4k3cax06ic1grlr"; </ins> }; cargoSha256 = "0pg4wsk2qaljrqklnl5p3iv83314wmybyxsn1prvsjsl4b64mil9";

Discussion:
In current master branch pythonPackages.mysqlclient fails to build. Checkout nixpkgs on revision and run: system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Most likely caused by . Unfortunately, the config-tools are not very configuration friendly. Until is resolved, I would add to the package.
Unfortunately this does not change anything, still failing with the same error message..
Hmm, apparently just hardcodes the path without the ability to override it from the attrset passed to : Is that intentional, Until this is resolved, you can use :
Change:
spice-gtk_libsoup2 = throw "'spice-gtk_libsoup2' has been renamed to/replaced by 'spice-gtk'"; # Added 2023-02-21 # spidermonkey is not ABI upwards-compatible, so only allow this for nix-shell spidermonkey = spidermonkey_78; # Added 2020-10-09 <ins> spotify-tui = throw "'spotify-tui' has been removed, as it was broken and unmaintained"; # Added 2024-03-12 </ins> spotify-unwrapped = spotify; # added 2022-11-06 spring-boot = spring-boot-cli; # added 2020-04-24 squid4 = throw "'squid4' has been renamed to/replaced by 'squid'"; # Converted to throw 2023-09-10

Discussion:
Steps to reproduce the behavior: spotify-tui-0.25.0 I see the package is basically abandoned upstream, should we just remove it? <!-- 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]:
I think removing it is a good idea, give a shot :)
Change:
{ lib, stdenv, fetchFromGitHub, cmake, dmenu }: <del> stdenv.mkDerivation rec { </del> <ins> stdenv.mkDerivation (finalAttrs: { </ins> pname = "j4-dmenu-desktop"; <del> version = "2.18"; </del> <ins> version = "unstable-2023-09-12"; </ins> src = fetchFromGitHub { owner = "enkore"; <del> repo = pname; rev = "r${version}"; sha256 = "1gxpgifzy0hnpd0ymw3r32amzr32z3bgb90ldjzl438p6h1q0i26"; </del> <ins> repo = "j4-dmenu-desktop"; rev = "7e3fd045482a8ea70619e422975b52feabc75175"; hash = "sha256-8PmfzQkHlEdMbrcQO0bPruP3jaKEcr/17x0/Z7Jedh0="; </ins> }; postPatch = '' <del> sed -e 's,dmenu -i,${dmenu}/bin/dmenu -i,g' -i ./src/Main.hh </del> <ins> substituteInPlace src/main.cc  --replace "dmenu -i" "${lib.getExe dmenu} -i" </ins> ''; nativeBuildInputs = [ cmake ];

Discussion:
Steps to reproduce the behavior: The maintainer has no activity on GitHub since June 2020. <!-- 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]:
This is an issue regarding the fact that no longer has as a default include. I'll open a PR with a fix
Change:
<ins> { stdenv , lib , fetchFromGitHub , cmake , qtbase , makeShellWrapper , wrapQtAppsHook , hyprland , grim , slurp , wayland }: let source = import ./source.nix { inherit lib fetchFromGitHub wayland; }; in stdenv.mkDerivation { pname = "hyprland-share-picker"; inherit (source) version; src = "${source.src}/hyprland-share-picker"; nativeBuildInputs = [ cmake wrapQtAppsHook makeShellWrapper ]; buildInputs = [ qtbase ]; dontWrapQtApps = true; postInstall = '' wrapProgramShell $out/bin/hyprland-share-picker  "''${qtWrapperArgs[@]}"  --prefix PATH ":" ${lib.makeBinPath [grim slurp hyprland]} ''; meta = source.meta // { description = "Helper program for xdg-desktp-portal-hyprland"; }; } </ins>

Discussion:
Project description A wlroots-compatible Wayland color picker that does not suck. Metadata homepage URL: source URL: license: platforms: linux Just because you made available on NixOS, I wanted to point you on hyprpicker, too - if you're interested to have a look into this(?)
I'll take a look into packaging this.
Change:
]; }; }; <ins> # disable private /tmp for this test systemd.services.mosquitto.serviceConfig.PrivateTmp = lib.mkForce false; </ins> }; client1 = client;

Discussion:
Describe the bug Expected behavior The nixos module should be aware of the deprecated options and the resulting config should be updated. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. Maintainer information:
Change:
}; buildInputs = [ libsecret libXScrnSaver libxshmfence ] <del> ++ lib.optionals (!stdenv.isDarwin) ([ gtk2 at-spi2-atk ] ++ atomEnv.packages); </del> <ins> ++ lib.optionals (!stdenv.isDarwin) ([ at-spi2-atk ] ++ atomEnv.packages); </ins> runtimeDependencies = lib.optional (stdenv.isLinux) [ (lib.getLib systemd) fontconfig.lib libdbusmenu ];

Discussion:
Describe the bug Running on vscode binary says that it depends only on gtk3: While the package depends on both gtk2 and gtk3: Probably there are some packaging issue? To Reproduce Steps to reproduce the behavior: vscode Expected behavior It depends only on gtk3 Notify maintainers Metadata Maintainer information:
Also gconf vs. dconf and libgnome-keyring vs. libsecret. See also
Hmm yeah, I removed and from , and both vscode and vscodium seem to still run fine. Not sure where the gconf/dconf thing is determined, possibly that that's an Atom issue
libsecret is the replacement for libgnome-keyring, not the other way around. It will probably be used at runtime when it needs to access keyring. dconf is used by GTK, gconf should not be used at all.
I marked this as stale due to inactivity. &rarr;
Still an issue
Change:
cliRev = "v${version}"; cliHash = "sha256-fpjSnUq3T6WZO/FLeT377FWxwevbULob9dPiSBxZdHI="; mobyRev = "v${version}"; <del> mobyHash = "sha256-v5uhFQPbBIpfnKtAkmbq4w+TbaG01tqTSWNBE3NvPKU="; </del> <ins> mobyHash = "sha256-xinRILDSuubAAJh/dmpaU3csTf0VgukJIfSUkcHpa28="; </ins> runcRev = "v1.1.13"; runcHash = "sha256-RQsM8Q7HogDVGbNpen3wxXNGR9lfqmNhkXTRoC+LBk8="; containerdRev = "v1.7.18";

Discussion:
In this , the docker27 version was updated from to , but only the hash of the CLI was updated, not the package. How was this built? The hash for the version should be . The value of the variable in should be updated. Here's how I installed Docker in my file: I'm not sure if it's relevant, but when I run the command, I see this output: This is odd because it should be the other way around! Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
It's to do with how FODs work in nix and nixpkgs; this would be ultimately looked at in some PRs such as . But we should also have the update script corrected (r-ryantm is an update bot).
Change:
python-lz4 = lz4; # added 2018-06-01 python_magic = python-magic; # added 2022-05-07 python_mimeparse = python-mimeparse; # added 2021-10-31 <ins> python-language-server = throw "python-language-server is no longer maintained, use the python-lsp-server community fork instead."; # Added 2022-08-03 </ins> python-subunit = subunit; # added 2021-09-10 pytest_xdist = pytest-xdist; # added 2021-01-04 python_simple_hipchat = python-simple-hipchat; # added 2021-07-21

Discussion:
add spyder and nixos-rebuild, I got this error error: python-language-server-0.36.2 not supported for interpreter python3.9 (use '--show-trace' to show detailed location information)
We should probably migrate to the community fork (), especially considering the current version is from Palantir.
I don't think the issue is specific to NixOS, it looks like the repo hasn't been updated in a year (and probably doesn't support Python 3.9 upstream). The community fork is available at , maybe we should alias to that now that Plantir's version is completely broken on the latest version of Python?
file with import <nixpkgs{}; with pkgs.python3Packages; buildPythonPackage rec { name = "spyder_latest"; src = /gh/prehonor/gitproject/spyder; nativeBuildInputs = [ pyqtwebengine.wrapQtAppsHook ]; propagatedBuildInputs = [ intervaltree jedi pycodestyle psutil rope numpy scipy matplotlib pylint keyring numpydoc qtconsole qtawesome nbconvert mccabe pyopengl cloudpickle spyder-kernels pygments qtpy pyzmq chardet pyqtwebengine qdarkstyle watchdog atomicwrites pyxdg diff-match-patch three-merge pyls-black pyls-spyder flake8 textdistance ]; } nix-shell : I got python-language-server-0.36.2 not supported for interpreter python3.9,how to take python-lsp-server stead of python-language-server
I add spyder by myselfif someone need use it he can visit the url
Change:
# Lightweight distribution and test inherit (bootstrap) dist test; # Test a full stdenv bootstrap from the bootstrap tools definition <del> inherit (bootstrap.test-pkgs) stdenv; </del> <ins> # TODO re-enable with https://github.com/NixOS/nixpkgs/pull/126411 # inherit (bootstrap.test-pkgs) stdenv; </ins> }; # Cross compiled bootstrap tools

Discussion:
is now failing, and blocking the unstable channel cc
Minimal reproducer: Bisected to Relevant snippet of cc
Oh I see, the stdenv setup logic is wrong when stdenv's cc version doesn't match the bootstrap tools because it tries to use a nonexistent include dir. The following patch should fix it but rebuilds the world, is there a clever way we can avoid rebuilds?
The bootstrap files contain some version of llvm, we could make this an explicit part of the tools. More generally, the test here is quite strict: it builds all the way to with new bootstrap tools but using current stdenv structure. When there are significant changes being made to the bootstrap tools that require stdenv changes this test makes it almost impossible. We've previously temporarily disabled this test to make such changes (). <details<summaryExplicit versions patch</summary</deatils
Yeah, the next bootstrap tools will depend on so it's somewhat expected that the stdenv test fails. I missed that build when testing.
Change:
<del> { callPackage, openssl, python3, enableNpm ? true }: </del> <ins> { callPackage, fetchpatch, openssl, python3, enableNpm ? true }: </ins> let buildNodejs = callPackage ./nodejs.nix {

Discussion:
does not build. See . Steps to reproduce the behavior: to build/install the build fail with: It should build successfully. Please run and paste the result.
Change:
<ins> { lib , buildPythonPackage , openvino-native , numpy , python }: buildPythonPackage { pname = "openvino"; inherit (openvino-native) version; format = "other"; src = openvino-native.python; propagatedBuildInputs = [ numpy ]; installPhase = '' runHook preInstall mkdir -p $out/${python.sitePackages} cp -Rv * $out/${python.sitePackages}/ runHook postInstall ''; pythonImportsCheck = [ "ngraph" "openvino" "openvino.runtime" ]; meta = with lib; { description = "OpenVINO(TM) Runtime"; homepage = "https://github.com/openvinotoolkit/openvino"; license = licenses.asl20; maintainers = with maintainers; [ hexa ]; }; } </ins>

Discussion:
When trying to get openvino in a shell, something fails to build with a linker error similar to shell nixpkgs#openvino OpenVINO builds successfully and it's provided in a shell. The nix build log is attached. Please run and paste the result.
Web-viewable logs on hydra:
Would also be nice to have a more recent version that could work with frigate.
The original error meant that tbb was built with gcc 11, while openvino was built using gcc 10.