jiebi/CodeConvo huggingface dataset:
Code change:
As of , the build of is broken. This is currently breaking the build of other packages including and certainly many others... ~I suspect this was triggered by , , or one of the redis upgrades.~ I believe this was triggered by . Steps to reproduce the behavior: nixpkgs at failure The build to succeed. n/a 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.
I tried patching around the issue with but that gives me a test failure:
should fix that. Also please use postPatch.

Related discussion:
text: pytestCheckHook ]; <ins> patches = [ # Support for redis <= 4.1.0, https://github.com/jamesls/fakeredis/pull/324 (fetchpatch { name = "support-redis-4.1.0.patch"; url = "https://github.com/jamesls/fakeredis/commit/8ef8dc6dacc9baf571d66a25ffbf0fadd7c70f78.patch"; sha256 = "sha256-4DrF/5WEWQWlJZtAi4qobMDyRAAcO/weHIaK9waN00k="; }) ]; </ins> disabledTestPaths = [ # AttributeError: 'AsyncGenerator' object has no attribute XXXX "test/test_aioredis2.py"
Code change:
Project description Fprintd replacement which allows you to have your own backend as a standalone service. Metadata homepage URL: source URL: license: GPL2 platforms: linux

Related discussion:
text: <ins> { lib, fetchFromGitHub, python3Packages }: python3Packages.buildPythonPackage rec { pname = "open-fprintd"; version = "0.6"; src = fetchFromGitHub { owner = "uunicorn"; repo = pname; rev = version; sha256 = "sha256-uVFuwtsmR/9epoqot3lJ/5v5OuJjuRjL7FJF7oXNDzU="; }; propagatedBuildInputs = with python3Packages; [ dbus-python pygobject3 ]; checkInputs = with python3Packages; [ dbus-python ]; postInstall = '' install -D -m 644 debian/open-fprintd.service  $out/lib/systemd/system/open-fprintd.service install -D -m 644 debian/open-fprintd-resume.service  $out/lib/systemd/system/open-fprintd-resume.service install -D -m 644 debian/open-fprintd-suspend.service  $out/lib/systemd/system/open-fprintd-suspend.service substituteInPlace $out/lib/systemd/system/open-fprintd.service  --replace /usr/lib/open-fprintd "$out/lib/open-fprintd" substituteInPlace $out/lib/systemd/system/open-fprintd-resume.service  --replace /usr/lib/open-fprintd "$out/lib/open-fprintd" substituteInPlace $out/lib/systemd/system/open-fprintd-suspend.service  --replace /usr/lib/open-fprintd "$out/lib/open-fprintd" ''; postFixup = '' wrapPythonProgramsIn "$out/lib/open-fprintd" "$out $pythonPath" ''; meta = with lib; { description = "Fprintd replacement which allows you to have your own backend as a standalone service"; homepage = "https://github.com/uunicorn/open-fprintd"; license = licenses.gpl2Only; platforms = platforms.linux; }; } </ins>
Code change:
nix-shell -p supercollider [anders $ nixos-version (Flounder) [anders $ nix-env --version nix-env (Nix) 1.11.2 [anders $ nix-instantiate --eval '<nixpkgs' -A lib.nixpkgsVersion ""
you use supercollider ?
no, sorry.
Same here:

Related discussion:
text: , libXt, qt, readline , useSCEL ? false, emacs }: <del> let optional = stdenv.lib.optional; in stdenv.mkDerivation rec { </del> <ins> let optional = stdenv.lib.optional; ljack2 = libjack2.override { gcc = gcc; }; in stdenv.mkDerivation rec { </ins> name = "supercollider-3.6.6"; meta = {
Code change:
nix-shell -p supercollider [anders $ nixos-version (Flounder) [anders $ nix-env --version nix-env (Nix) 1.11.2 [anders $ nix-instantiate --eval '<nixpkgs' -A lib.nixpkgsVersion ""
you use supercollider ?
no, sorry.
Same here:

Related discussion:
text: cmakeFlags = '' -DSC_WII=OFF <del> -DSC_EL=${if useSCEL then "ON" else "OFF"} </del> <ins> -DSC_EL=${if useSCEL then "ON" else "OFF"} </ins> ''; nativeBuildInputs = [ cmake pkgconfig ]; <del> buildInputs = [ gcc libjack2 libsndfile fftw curl libXt qt readline ] </del> <ins> buildInputs = [ gcc ljack2 libsndfile fftw curl libXt qt readline ] </ins> ++ optional useSCEL emacs; }
Code change:
nix-shell -p supercollider [anders $ nixos-version (Flounder) [anders $ nix-env --version nix-env (Nix) 1.11.2 [anders $ nix-instantiate --eval '<nixpkgs' -A lib.nixpkgsVersion ""
you use supercollider ?
no, sorry.
Same here:

Related discussion:
text: { stdenv, fetchFromGitHub, pkgconfig, python, makeWrapper <del> , bash, libsamplerate, libsndfile, readline </del> <ins> , bash, libsamplerate, libsndfile, readline, gcc </ins> # Optional Dependencies , dbus ? null, pythonDBus ? null, libffado ? null, alsaLib ? null
Code change:
nix-shell -p supercollider [anders $ nixos-version (Flounder) [anders $ nix-env --version nix-env (Nix) 1.11.2 [anders $ nix-instantiate --eval '<nixpkgs' -A lib.nixpkgsVersion ""
you use supercollider ?
no, sorry.
Same here:

Related discussion:
text: }; nativeBuildInputs = [ pkgconfig python makeWrapper ]; <del> buildInputs = [ </del> <ins> buildInputs = [ gcc </ins> python libsamplerate libsndfile readline
Code change:
When using with the I get the following error. ! I'm assuming this is caused by the following code. Since it doesn't include the module. Steps to reproduce the behavior: the to open Libreoffice Writer The Languagetool plugin doesn't cause a runtime error. Please run and paste the result.
Hm, jre_minimal tests seem to confirm it; does adding "java.logging" there help?
Happy to take a look by the end of the week :)
That'd be great if you could do that. I tried building it on my laptop. But it was still building after ~3 hours. :)

Related discussion:
text: let jre' = jre_minimal.override { <del> modules = [ "java.base" "java.desktop" ]; </del> <ins> modules = [ "java.base" "java.desktop" "java.logging" ]; </ins> }; importVariant = f: import (./. + "/src-${variant}/${f}");
Code change:
<!-- 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: <!-- 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: 4.1.6 desired version: 4.1.7 <!-- 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.

Related discussion:
text: homepage = "https://www.jool.mx/"; description = "Fairly compliant SIIT and Stateful NAT64 for Linux - kernel modules"; platforms = platforms.linux; <ins> license = licenses.gpl2Only; </ins> maintainers = with maintainers; [ fpletz ]; }; }
Code change:
<!-- 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: <!-- 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: 4.1.6 desired version: 4.1.7 <!-- 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.

Related discussion:
text: { fetchFromGitHub }: rec { <del> version = "4.1.6"; </del> <ins> version = "4.1.7"; </ins> src = fetchFromGitHub { owner = "NICMx"; repo = "Jool"; rev = "v${version}"; <del> sha256 = "09avkiazpfxzrgr3av58jbina5x9jqvqhjkn39475pfhfhrlv9fv"; </del> <ins> sha256 = "08z23mi6xkr6zzp0hzh1cppvl2y0177s0lnpxqbpy8jiii5fxw8f"; </ins> }; }
Code change:
I don't use at all, but I'm getting this error when I'm trying to rebuild my flakes (same happens when I run ) and also I don't really use it or install it Steps to reproduce the behavior: or Expect or to work fine I ran before running <!-- 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.
By grepping through nixpkgs, depends on by default. (see ). However, abook is only lists linux as supported (Im not sure if this this is just nixpkgs or abook in general) Up until , lbdb has not depended on abook by default. Perhaps a mistake was made while refactoring. In the meantime, you can just override the package.

Related discussion:
text: description = "Text-based addressbook program designed to use with mutt mail client"; license = lib.licenses.gpl2; maintainers = [ lib.maintainers.edwtjo ]; <del> platforms = with lib.platforms; linux; </del> <ins> platforms = with lib.platforms; unix; </ins> }; }
Code change:
are you on top of this?
Thanks for the heads up, yeah, just waited for the GitHub releases to appear. I’ll create a PR soon.

Related discussion:
text: in py.pkgs.buildPythonApplication rec { pname = "salt"; <del> version = "3004"; </del> <ins> version = "3004.1"; </ins> src = py.pkgs.fetchPypi { inherit pname version; <del> sha256 = "PVNWG8huAU3KLsPcmBB5vgTVXqBHiQyr3iXlsQv6WxM="; </del> <ins> hash = "sha256-fzRKJDJkik8HjapazMaNzf/hCVzqE+wh5QQTVg8Ewpg="; </ins> }; propagatedBuildInputs = with py.pkgs; [
Code change:
are you on top of this?
Thanks for the heads up, yeah, just waited for the GitHub releases to appear. I’ll create a PR soon.

Related discussion:
text: }: python3.pkgs.buildPythonApplication rec { pname = "salt"; <del> version = "3003.3"; </del> <ins> version = "3003.4"; </ins> src = python3.pkgs.fetchPypi { inherit pname version; <del> sha256 = "pvnIyLXiYA6oYgtKZzcd4XYRvrT42X5LubCzCKN+0eI="; </del> <ins> sha256 = "53uAjlG0HX5Jae4VWIrAT9DbmzPfonEPVEGNfrOHJM0="; </ins> }; propagatedBuildInputs = with python3.pkgs; [
Code change:
<!-- 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: lapce <!-- 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: 0.0.10 desired version: 0.0.12 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Maybe it will fix the crash:
can you create a pull request?
I am using changes in local build. it is working fine

Related discussion:
text: rustPlatform.buildRustPackage rec { pname = "lapce"; <del> version = "0.0.10"; </del> <ins> version = "0.0.12"; </ins> src = fetchFromGitHub { owner = "lapce"; repo = pname; rev = "v${version}"; <del> sha256 = "tOVFm4DFQurFU4DtpPwxXQLbTGCZnrV1FfYKtvkRxRE="; </del> <ins> sha256 = "sha256-ZFQjQ5+G0b0Fgg3+du/drt+62rC/TCNR5MIdJXAkTrE="; </ins> }; <del> cargoPatches = [ ./fix-version.patch ]; cargoSha256 = "BwB3KgmI5XnZ5uHv6f+kGKBzpyxPWcoKvF7qw90eorI="; </del> <ins> cargoSha256 = "sha256-sMTootPsenaWzLLFImo6HWC1pcm2uFupPhVWsUJp1Ak="; </ins> nativeBuildInputs = [ cmake
Code change:
<!-- 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: lapce <!-- 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: 0.0.10 desired version: 0.0.12 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Maybe it will fix the crash:
can you create a pull request?
I am using changes in local build. it is working fine

Related discussion:
text: <del> diff --git a/Cargo.lock b/Cargo.lock index bc9a0f8..45a74ad 100644 --- a/Cargo.lock +++ b/Cargo.lock @@ -2165,7 +2165,7 @@ dependencies = [ [[package]] name = "lapce" -version = "0.0.9" +version = "0.0.10" dependencies = [ "lapce-core", "lapce-proxy", @@ -2173,7 +2173,7 @@ dependencies = [ [[package]] name = "lapce-core" -version = "0.0.9" +version = "0.0.10" dependencies = [ "Inflector", "alacritty_terminal 0.15.0", @@ -2233,7 +2233,7 @@ dependencies = [ [[package]] name = "lapce-proxy" -version = "0.0.9" +version = "0.0.10" dependencies = [ "alacritty_terminal 0.16.0-rc2", "anyhow", </del>
Code change:
Steps to reproduce the behavior: Please run and paste the result.
Thank you for reporting this issue; I can reproduce it. The problem is not in the warning displayed in the last 10 log lines, but in an earlier error: Unfortunately I don't think that I will be able to contribute further to this issue.
I'm aware of this failure, but fixing it will require a bit of patching. Upstream didn't update the package to ghc 9 yet. Right now I don't have much time to do that, so in the meantime you could install it from stable, where it does build. Please change the title to something like "jl: build failure due to ghc 9"
This has been correctly marked broken in . See also where there was a small amount of discussion about marking this broken.
I've created an upstream .
The PR is now merged, and the package is now on Hackage for the first time. However, since it's not been to Stackage Nightly yet, it won't make its way into for quite some time. I'll update the derivation to use the new version directly from Hackage.

Related discussion:
text: }: mkDerivation rec { pname = "jl"; <del> version = "0.0.5"; src = fetchFromGitHub { owner = "chrisdone"; repo = "jl"; rev = "v${version}"; sha256 = "1hlnwsl4cj0l4x8dxwda2fcnk789cwlphl9gv9cfrivl43mgkgar"; }; patches = [ # MonadFail compatibility patch. Should be removed with the next release (fetchpatch { url = "https://github.com/chrisdone/jl/commit/6d40308811cbc22a96b47ebe69ec308b4e9fd356.patch"; sha256 = "1pg92ffkg8kim5r8rz8js6fjqyjisg1266sf7p9jyxjgsskwpa4g"; }) ]; </del> <ins> version = "0.1.0"; sha256 = "15vvn3swjpc5qmdng1fcd8m9nif4qnjmpmxc9hdw5cswzl055lkj"; </ins> isLibrary = true; isExecutable = true; libraryHaskellDepends = [
Code change:
Steps to reproduce the behavior: Please run and paste the result.
Thank you for reporting this issue; I can reproduce it. The problem is not in the warning displayed in the last 10 log lines, but in an earlier error: Unfortunately I don't think that I will be able to contribute further to this issue.
I'm aware of this failure, but fixing it will require a bit of patching. Upstream didn't update the package to ghc 9 yet. Right now I don't have much time to do that, so in the meantime you could install it from stable, where it does build. Please change the title to something like "jl: build failure due to ghc 9"
This has been correctly marked broken in . See also where there was a small amount of discussion about marking this broken.
I've created an upstream .
The PR is now merged, and the package is now on Hackage for the first time. However, since it's not been to Stackage Nightly yet, it won't make its way into for quite some time. I'll update the derivation to use the new version directly from Hackage.

Related discussion:
text: description = "Functional sed for JSON"; maintainers = with lib.maintainers; [ fgaz ]; homepage = "https://github.com/chrisdone/jl"; <del> # jl needs to be updated to work with aeson-2.0. # As far as I can tell, there is unfortunately no where to report issues upstream # for us to be able to track when upstream adds aeson-2.0 support. hydraPlatforms = lib.platforms.none; broken = true; </del> }
Code change:
While checking why we have two subversion releases I noticed that both releases are LTS versions. They receive 4 years of support and 1.10 was first released on 2018-04-13, so it's probably wise to remove it before the 22.05 release. Originally posted by in
I don't see anything that depends on in nixpkgs (anymore), so IMO we can just remove it now, instead of waiting for some kind of EOL announcement.

Related discussion:
text: }); in { <del> subversion_1_10 = common { version = "1.10.8"; sha256 = "sha256-CnO6MSe1ov/7j+4rcCmE8qgI3nEKjbKLfdQBDYvlDlo="; }; </del> subversion = common { version = "1.14.2"; sha256 = "sha256-yRMOjQt1copm8OcDj8dwUuZxgw14W1YWqtU7SBDTzCg=";
Code change:
While checking why we have two subversion releases I noticed that both releases are LTS versions. They receive 4 years of support and 1.10 was first released on 2018-04-13, so it's probably wise to remove it before the 22.05 release. Originally posted by in
I don't see anything that depends on in nixpkgs (anymore), so IMO we can just remove it now, instead of waiting for some kind of EOL announcement.

Related discussion:
text: stanchion = throw "Stanchion was part of riak-cs which is not maintained anymore"; # added 2020-10-14 steam-run-native = steam-run; # added 2022-02-21 stumpwm-git = throw "stumpwm-git has been broken for a long time and lispPackages.stumpwm follows Quicklisp that is close to git version"; # Added 2021-05-09 <ins> subversion_1_10 = throw "subversion_1_10 has been removed as it has reached its end of life"; # Added 2022-04-26 </ins> subversion19 = throw "subversion19 has been removed as it has reached its end of life"; # Added 2021-03-31 sudolikeaboss = throw "sudolikeaboss is no longer maintained by upstream"; # Added 2022-04-16 sundials_3 = throw "sundials_3 was removed in 2020-02. outdated and no longer needed";
Code change:
While checking why we have two subversion releases I noticed that both releases are LTS versions. They receive 4 years of support and 1.10 was first released on 2018-04-13, so it's probably wise to remove it before the 22.05 release. Originally posted by in
I don't see anything that depends on in nixpkgs (anymore), so IMO we can just remove it now, instead of waiting for some kind of EOL announcement.

Related discussion:
text: sublime-merge-dev; inherit (callPackages ../applications/version-management/subversion { sasl = cyrus_sasl; }) <del> subversion_1_10 subversion; </del> <ins> subversion; </ins> subversionClient = subversion.override { bdbSupport = false;
Code change:
Try to build for . Note, I'm trying staging because is necessary. fails: staging is at :
This was caused by setuptools 60, which now uses bundled distutils. All Python packages with extension modules fail to cross-compile currently, but this will be fixed by . I also noticed that the libbtrfsutil Python bindings are never actually installed, so I also created .

Related discussion:
text: { stdenv , buildPythonPackage , fetchFromGitHub <ins> , fetchpatch </ins> , python , bootstrapped-pip , lib
Code change:
Try to build for . Note, I'm trying staging because is necessary. fails: staging is at :
This was caused by setuptools 60, which now uses bundled distutils. All Python packages with extension modules fail to cross-compile currently, but this will be fixed by . I also noticed that the libbtrfsutil Python bindings are never actually installed, so I also created .

Related discussion:
text: patches = [ ./tag-date.patch ./setuptools-distutils-C++.patch <ins> # Use sysconfigdata to find headers. Fixes cross-compilation of extension modules. # https://github.com/pypa/distutils/pull/145 (fetchpatch { url = "https://github.com/pypa/distutils/commit/aed7294b7b0c228cc0666a8b04f2959bf310ab57.patch"; hash = "sha256-/9+TKv0nllBfnj48zcXLrOgyBj52dBIVbrpnIaQ4O84="; stripLen = 2; extraPrefix = "setuptools/_distutils/"; }) </ins> ]; buildPhase = ''
Code change:
For example: fails similarly. The line that causes the failure according to my testing is: A list of some packages that didn't break: Could be this is an upstream issue.
So digging into it, this is an issue raised by Octave's package management system itself. Namely, this -statement from Line 80 in that file is the statement. It expects to remove a file, which is not existing. The reason the other packages did not break was because they either do not have a directory () or they actually do have a generated file (netcdf & control). You can technically solve this by adding an empty script to the directory. I manually did this, and the package built correctly again. As for why this change happened, I cannot tell. The particular statement shown did not change between 6.4.0 and 7.1.0 in the file.
Looks like
That's the exact issue. Seems like we will need to wait for upstream to fix it. How does this usually get handled
Seems like we should apply to the patch:
There are still 5 packages failing to build, but that is a lot fewer than before.

Related discussion:
text: sha256 = "sha256-1KnYHz9ntKbgfLeoDcsQrV6RdvzDB2LHCoFYCmS4sLY="; }; <ins> patches = [ # https://savannah.gnu.org/bugs/?func=detailitem&item_id=62436 ./patches/bug62436.patch ]; </ins> buildInputs = [ readline ncurses
Code change:
For example: fails similarly. The line that causes the failure according to my testing is: A list of some packages that didn't break: Could be this is an upstream issue.
So digging into it, this is an issue raised by Octave's package management system itself. Namely, this -statement from Line 80 in that file is the statement. It expects to remove a file, which is not existing. The reason the other packages did not break was because they either do not have a directory () or they actually do have a generated file (netcdf & control). You can technically solve this by adding an empty script to the directory. I manually did this, and the package built correctly again. As for why this change happened, I cannot tell. The particular statement shown did not change between 6.4.0 and 7.1.0 in the file.
Looks like
That's the exact issue. Seems like we will need to wait for upstream to fix it. How does this usually get handled
Seems like we should apply to the patch:
There are still 5 packages failing to build, but that is a lot fewer than before.

Related discussion:
text: <ins> # HG changeset patch # User John Donoghue <john.donoghue@ieee.org> # Date 1652358904 14400 #      Thu May 12 08:35:04 2022 -0400 # Branch stable # Node ID 8c940cfcce257369677c09154da2aab2c56eaa79 # Parent  63710f3bd9811c2d206ac9e7b4f47cf06c47e153 * scripts/pkg/private/build.m: check configure and Makefile exist before trying to unlink them (Bug #62436) diff -r 63710f3bd981 -r 8c940cfcce25 scripts/pkg/private/build.m --- a/scripts/pkg/private/build.m	Wed May 11 09:44:55 2022 -0700 +++ b/scripts/pkg/private/build.m	Thu May 12 08:35:04 2022 -0400 @@ -77,8 +77,12 @@ else arch_abi = getarch (); configure_make (desc, build_root, verbose); -      unlink (fullfile (build_root, "src", "configure")); -      unlink (fullfile (build_root, "src", "Makefile")); +      if exist (fullfile (build_root, "src", "configure"), "file") +        unlink (fullfile (build_root, "src", "configure")); +      endif +      if exist (fullfile (build_root, "src", "Makefile"), "file") +        unlink (fullfile (build_root, "src", "Makefile")); +      endif endif tar_name = [desc.name "-" desc.version "-" arch_abi ".tar"]; tar_path = fullfile (builddir, tar_name); </ins>