jiebi/CodeConvo huggingface dataset:
Code change:
This project is no longer activily maintained! there is a spiritual successor, so maybe package that instead cc maintainer
I marked this as stale due to inactivity. &rarr;

Related discussion:
text: featherpad = qt5.callPackage ../applications/editors/featherpad {}; <del> feedreader = callPackage ../applications/networking/feedreaders/feedreader {}; </del> fend = callPackage ../tools/misc/fend { }; ferm = callPackage ../tools/networking/ferm { };
Code change:
NixOS's wrappers for gcc also apply for gcj, which is a Java compiler. The wrappers add the flag to gcj's command line, however the Java language does not have a preprocessor, and means a different thing for gcj. This means that gcj cannot compile anything. Another issue is that gcj links to zlib by default, but does not pull zlib into the environment. This means that, even if the former issue is silenced with , compilation still wouldn't work.
A similar problem for gfortran:
I marked this as stale due to inactivity. &rarr;

Related discussion:
text: ''; strictDeps = true; <del> propagatedBuildInputs = [ bintools ] ++ extraTools ++ optionals cc.langD or false [ zlib ]; </del> <ins> propagatedBuildInputs = [ bintools ] ++ extraTools ++ optionals cc.langD or cc.langJava or false [ zlib ]; </ins> depsTargetTargetPropagated = optional (libcxx != null) libcxx ++ extraPackages; setupHooks = [
Code change:
NixOS's wrappers for gcc also apply for gcj, which is a Java compiler. The wrappers add the flag to gcj's command line, however the Java language does not have a preprocessor, and means a different thing for gcj. This means that gcj cannot compile anything. Another issue is that gcj links to zlib by default, but does not pull zlib into the environment. This means that, even if the former issue is silenced with , compilation still wouldn't work.
A similar problem for gfortran:
I marked this as stale due to inactivity. &rarr;

Related discussion:
text: + optionalString propagateDoc '' ln -s ${cc.man} $man ln -s ${cc.info} $info <del> '' + optionalString (cc.langD or false) '' </del> <ins> '' + optionalString (cc.langD or cc.langJava or false) '' </ins> echo "-B${zlib}${zlib.libdir or "/lib/"}" >> $out/nix-support/libc-cflags ''
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 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 than above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 4.6.3 desired version: 4.11.2 <!-- 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: buildGoModule rec { pname = "yq-go"; <del> version = "4.6.3"; </del> <ins> version = "4.11.2"; </ins> src = fetchFromGitHub { owner = "mikefarah"; <del> rev = "v${version}"; </del> repo = "yq"; <del> sha256 = "sha256-+qSGdskv8qUZRl7wYKn8WsgAcD8DYw1BwZnVKK6g/sI="; </del> <ins> rev = "v${version}"; sha256 = "sha256-IzsI0jS+chm/xOdL1O11qxQTstKcUeZ9YxL7RtKHBZw="; </ins> }; <del> vendorSha256 = "sha256-vpvIl1lfaziuoHs+oDEIztufH1somphiBAn6qTaQaZw="; </del> <ins> vendorSha256 = "sha256-X162NQ+NgOUbwEA6xdnuy0u18/GQLhR3zzi+TVgzMIc="; </ins> doCheck = false;
Code change:
After enabling the GNUnet service with , it prints a lot of errors at startup: Additionally, attempting to stop the deamon with reveals that it is apparently not even running: Please run and paste the result.

Related discussion:
text: cfg = config.services.gnunet; <del> homeDir = "/var/lib/gnunet"; </del> <ins> stateDir = "/var/lib/gnunet"; </ins> <del> configFile = with cfg; pkgs.writeText "gnunetd.conf" </del> <ins> configFile = with cfg; </ins> '' [PATHS] <del> SERVICEHOME = ${homeDir} </del> <ins> GNUNET_HOME = ${stateDir} GNUNET_RUNTIME_DIR = /run/gnunet GNUNET_USER_RUNTIME_DIR = /run/gnunet GNUNET_DATA_HOME = ${stateDir}/data </ins> [ats] WAN_QUOTA_IN = ${toString load.maxNetDownBandwidth} b
Code change:
After enabling the GNUnet service with , it prints a lot of errors at startup: Additionally, attempting to stop the deamon with reveals that it is apparently not even running: Please run and paste the result.

Related discussion:
text: users.users.gnunet = { group = "gnunet"; description = "GNUnet User"; <del> home = homeDir; createHome = true; </del> uid = config.ids.uids.gnunet; };
Code change:
After enabling the GNUnet service with , it prints a lot of errors at startup: Additionally, attempting to stop the deamon with reveals that it is apparently not even running: Please run and paste the result.

Related discussion:
text: # so install them globally. environment.systemPackages = [ cfg.package ]; <ins> environment.etc."gnunet.conf".text = configFile; </ins> systemd.services.gnunet = { description = "GNUnet"; after = [ "network.target" ]; wantedBy = [ "multi-user.target" ]; <ins> restartTriggers = [ configFile ]; </ins> path = [ cfg.package pkgs.miniupnpc ]; <del> environment.TMPDIR = "/tmp"; serviceConfig.PrivateTmp = true; serviceConfig.ExecStart = "${cfg.package}/lib/gnunet/libexec/gnunet-service-arm -c ${configFile}"; </del> <ins> serviceConfig.ExecStart = "${cfg.package}/lib/gnunet/libexec/gnunet-service-arm -c /etc/gnunet.conf"; </ins> serviceConfig.User = "gnunet"; serviceConfig.UMask = "0007"; <del> serviceConfig.WorkingDirectory = homeDir; </del> <ins> serviceConfig.WorkingDirectory = stateDir; serviceConfig.RuntimeDirectory = "gnunet"; serviceConfig.StateDirectory = "gnunet"; </ins> }; };
Code change:
When adding to and running , emacs 25 builds and fails with 4 unexpected TRAMP mode test errors: The full output contains null bytes and weird control characters that don't let me paste this into a gist easily. Is that part of the test or indicative of the problem? cc
ok... i think this will contain the build output? again if i open it in emacs there are lots of control characters. had to zip so github wouldn't complain.
I disabled for emacs25pre, for now, on my system. I hope this will be resolved upstream before next release ...
It's quite possible that tramp-related tests fail because there is no proper networking support in the build chroot, i.e. it's not possible to resolve host names or service names. Another source of trouble could be the lack of an UTF-8 capable locale in our default build environment. Anyhow, it would be really good to report those errors upstream to make sure that the next Emacs release has them fixed in one way or another.
I've been working with the Tramp author for the past several days about these failures, and we've identified that the problem is somewhere in the environment that the tests are presented with, but we don't yet know what exactly. I'm still digging into it.

Related discussion:
text: mv nextstep/Emacs.app $out/Applications ''; <del> # https://github.com/NixOS/nixpkgs/issues/13573 doCheck = false; </del> meta = with stdenv.lib; { description = "GNU Emacs 25 (pre), the extensible, customizable text editor"; homepage    = http://www.gnu.org/software/emacs/;
Code change:
I tried updating it, but no luck. I think the new glibc 2.23 is the reason for configure fail: I've only been able to find arch having the same issue, no patch yet. cc
This is strange. I do reproduce the build problem, but when I compile the configure test and run it myself, it succeeds (and measures bytes). (Of course I do compile it with the stdenv from 16.03.)
Comments on note a workaround.
Temporary workaround on arch:
Fixed then?
FYI the fix to Xen build system is committed. See ;a=commit;h=

Related discussion:
text: # TODO add plugins having various licenses, see http://www.vamp-plugins.org/download.html <del> { stdenv, fetchurl, alsaLib, bzip2, fftw, jackaudio, libX11, liblo, libmad, libogg, librdf, librdf_raptor, librdf_rasqal, libsamplerate, libsndfile, makeWrapper, pulseaudio, qt4, redland, rubberband, vampSDK </del> <ins> { stdenv, fetchurl, alsaLib, bzip2, fftw, jackaudio, libX11, liblo , libmad, libogg, librdf, librdf_raptor, librdf_rasqal, libsamplerate , libsndfile, makeWrapper, pkgconfig, pulseaudio, qt4, redland , rubberband, vampSDK </ins> }: <del> stdenv.mkDerivation { name = "sonic-visualiser-1.8"; </del> <ins> stdenv.mkDerivation rec { name = "sonic-visualiser-${version}"; version = "1.9"; </ins> src = fetchurl { <del> url = http://downloads.sourceforge.net/sv1/sonic-visualiser-1.8.tar.gz; sha256 = "16ik6q9n92wljvnqcv7hyzb9v3yp3ixxp6df9kasf53fii973dh7"; </del> <ins> url = "http://code.soundsoftware.ac.uk/attachments/download/194/${name}.tar.gz"; sha256 = "00igf7j6s8xfyxnlkbqma0yby9pknxqzy8cmh0aw95ix80cw56fq"; </ins> }; buildInputs = [ libsndfile qt4 fftw /* should be fftw3f ??*/ bzip2 librdf rubberband libsamplerate vampSDK alsaLib librdf_raptor librdf_rasqal redland <ins> pkgconfig </ins> # optional jackaudio # portaudio
Code change:
I tried updating it, but no luck. I think the new glibc 2.23 is the reason for configure fail: I've only been able to find arch having the same issue, no patch yet. cc
This is strange. I do reproduce the build problem, but when I compile the configure test and run it myself, it succeeds (and measures bytes). (Of course I do compile it with the stdenv from 16.03.)
Comments on note a workaround.
Temporary workaround on arch:
Fixed then?
FYI the fix to Xen build system is committed. See ;a=commit;h=

Related discussion:
text: description = "View and analyse contents of music audio files"; homepage = http://www.sonicvisualiser.org/; license = "GPLv2"; <del> maintainers = [ stdenv.lib.maintainers.marcweber stdenv.lib.maintainers.goibhniu ]; </del> <ins> maintainers = [ stdenv.lib.maintainers.marcweber stdenv.lib.maintainers.goibhniu ]; </ins> platforms = stdenv.lib.platforms.linux; }; }
Code change:
I want to use the TTS Mimic on a Debian 11. After installation, I Tried reading a text. Cli usage give me an "alsa lib error". Steps to reproduce the behavior: -env -iA -t "hello world" A clear and concise description of what you expected to happen. If applicable, add screenshots to help explain your problem. Add any other context about the problem here. Please run and paste the result. Maintainer information:
works perfectly on NixOS 21.05. Can you elaborate more about your sound setup? While geared toward NixOS, this thread might give useful information to debug further: Also try running ALSA tools or CLI audio applications natively from Debian and via to observe any differences in behaviour.
The above works for me too on NixOS, at least. I'm not familiar with how ALSA and PulseAudio in nixpkgs integrate with non-NixOS systems; perhaps a thread on Discourse might be of more help.
I was able to reproduce your issue on Ubuntu 20.04. It seems this is . A few workarounds are mentioned in the linked issue.
It seems mimic just needs a proper wrapper: should give you some output.
Ok, I found a solution with inspiration. alsa-lib-1.2.4 doesn't containt but if i installed alsaPlugin (nix-build -A alsaPlugins '<nixpkgs'), this works for me : However, not really user friendly.

Related discussion:
text: <del> { config, lib, stdenv, autoreconfHook, fetchFromGitHub, pkg-config , alsa-lib, libtool, icu </del> <ins> { config, lib, stdenv, autoreconfHook, fetchFromGitHub, pkg-config, makeWrapper , alsa-lib, alsa-plugins, libtool, icu, pcre2 </ins> , pulseaudioSupport ? config.pulseaudio or false, libpulseaudio }: stdenv.mkDerivation rec { pname = "mimic"; <del> version = "1.2.0.2"; </del> <ins> version = "1.3.0.1"; </ins> src = fetchFromGitHub { rev = version; <del> repo = "mimic"; </del> <ins> repo = "mimic1"; </ins> owner = "MycroftAI"; <del> sha256 = "1wkpbwk88lsahzkc7pzbznmyy0lc02vsp0vkj8f1ags1gh0lc52j"; </del> <ins> sha256 = "1agwgby9ql8r3x5rd1rgx3xp9y4cdg4pi3kqlz3vanv9na8nf3id"; </ins> }; nativeBuildInputs = [ autoreconfHook pkg-config <ins> makeWrapper </ins> ]; buildInputs = [ alsa-lib <ins> alsa-plugins </ins> libtool icu <ins> pcre2 </ins> ] ++ lib.optional pulseaudioSupport libpulseaudio; <ins> postInstall = '' wrapProgram $out/bin/mimic  --run "export ALSA_PLUGIN_DIR=${alsa-plugins}/lib/alsa-lib" ''; </ins> meta = { description = "Mycroft's TTS engine, based on CMU's Flite (Festival Lite)"; homepage = "https://mimic.mycroft.ai/";
Code change:
Project description A cross-platform TUI database management tool written in Rust Metadata homepage URL: source URL: license: mit platforms: unix

Related discussion:
text: <ins> { lib, rustPlatform, fetchFromGitHub }: rustPlatform.buildRustPackage rec { pname = "gobang"; version = "0.1.0-alpha.5"; src = fetchFromGitHub { owner = "tako8ki"; repo = pname; rev = "v${version}"; sha256 = "02glb3hlprpdc72ji0248a7g0vr36yxr0gfbbms2m25v251dyaa6"; }; cargoSha256 = "sha256-Tiefet5gLpiuYY6Scg5fjnaPiZfVl5Gy2oZFdhgNRxY="; meta = with lib; { description = "A cross-platform TUI database management tool written in Rust"; homepage = "https://github.com/tako8ki/gobang"; license = licenses.mit; maintainers = with maintainers; [ figsoda ]; }; } </ins>
Code change:
Project description A cross-platform TUI database management tool written in Rust Metadata homepage URL: source URL: license: mit platforms: unix

Related discussion:
text: go-junit-report = callPackage ../development/tools/go-junit-report { }; <ins> gobang = callPackage ../development/tools/database/gobang { }; </ins> gogetdoc = callPackage ../development/tools/gogetdoc { }; gox = callPackage ../development/tools/gox { };
Code change:
Currently we have two expressions that both build the kernel, whose only interface differences are in whether or not the .config is generated or provided. These builds should be merged with the two different interfaces simply being two ways to call the same underlying function, reducing code duplication and allowing the generic kernel builds to benefit from the IMO better structure of the newer manual kernel builds.
+1 on getting rid of duplication What is the "better structure"?
Structure may have been the wrong word, but the manual kernel build uses multiple outputs (suboptimally currently, which was part of the problem with the old PR) and uses the official kernel build system for building and installing, while the generic one (last I checked) had a manually maintained shell script to handle the install and parts of the build.
Fixed by

Related discussion:
text: in assert lib.all (p: p.enabled -> ! (builtins.elem null p.buildInputs)) plugins; stdenv.mkDerivation rec { <del> version = "2.6"; </del> <ins> version = "2.7"; </ins> pname = "weechat"; src = fetchurl { url = "https://weechat.org/files/src/weechat-${version}.tar.bz2"; <del> sha256 = "1narazk28m7lmn1vqi7bhyvnr8apjrmaa4w1hbadn64hwr8ya1hb"; </del> <ins> sha256 = "00hzchzw1w2181kczcrrnj8ngml3bwk7qciha3higxq3qynf0h8c"; </ins> }; outputs = [ "out" "man" ] ++ map (p: p.name) enabledPlugins;
Code change:
Currently we have two expressions that both build the kernel, whose only interface differences are in whether or not the .config is generated or provided. These builds should be merged with the two different interfaces simply being two ways to call the same underlying function, reducing code duplication and allowing the generic kernel builds to benefit from the IMO better structure of the newer manual kernel builds.
+1 on getting rid of duplication What is the "better structure"?
Structure may have been the wrong word, but the manual kernel build uses multiple outputs (suboptimally currently, which was part of the problem with the old PR) and uses the official kernel build system for building and installing, while the generic one (last I checked) had a manually maintained shell script to handle the install and parts of the build.
Fixed by

Related discussion:
text: cmakeFlags = with stdenv.lib; [ "-DENABLE_MAN=ON" "-DENABLE_DOC=ON" <ins> "-DENABLE_JAVASCRIPT=OFF"  # Requires v8 <= 3.24.3, https://github.com/weechat/weechat/issues/360 "-DENABLE_PHP=OFF" </ins> ] ++ optionals stdenv.isDarwin ["-DICONV_LIBRARY=${libiconv}/lib/libiconv.dylib" "-DCMAKE_FIND_FRAMEWORK=LAST"] ++ map (p: "-D${p.cmakeFlag}=" + (if p.enabled then "ON" else "OFF")) plugins
Code change:
Currently we have two expressions that both build the kernel, whose only interface differences are in whether or not the .config is generated or provided. These builds should be merged with the two different interfaces simply being two ways to call the same underlying function, reducing code duplication and allowing the generic kernel builds to benefit from the IMO better structure of the newer manual kernel builds.
+1 on getting rid of duplication What is the "better structure"?
Structure may have been the wrong word, but the manual kernel build uses multiple outputs (suboptimally currently, which was part of the problem with the old PR) and uses the official kernel build system for building and installing, while the generic one (last I checked) had a manually maintained shell script to handle the install and parts of the build.
Fixed by

Related discussion:
text: in assert lib.all (p: p.enabled -> ! (builtins.elem null p.buildInputs)) plugins; stdenv.mkDerivation rec { <del> version = "2.6"; </del> <ins> version = "2.7.1"; </ins> pname = "weechat"; src = fetchurl { url = "https://weechat.org/files/src/weechat-${version}.tar.bz2"; <del> sha256 = "1narazk28m7lmn1vqi7bhyvnr8apjrmaa4w1hbadn64hwr8ya1hb"; </del> <ins> sha256 = "0acz41jg7lmipni9z2agfqw4dhmx5hf6k9w4pvr4zih1fhkldva2"; </ins> }; outputs = [ "out" "man" ] ++ map (p: p.name) enabledPlugins;
Code change:
Practical consequence: with (this log snippet is cleaner thanks to ) I checked that it really is the patch by applying Some bugs are discussed in the upstream ML thread: I'm not sure about the best approach for us so far; the rebuild amounts complicate this. Perhaps just temporarily fixup the kernel build and get a properly fixed cpio with the next iteration? I expect that three to five upstream commits will be needed; maybe just the whole diff since the last release.
I think we should just fix this in master; the channel isn't going to advance anyway, and I'd rather not ship a known-buggy version of by fixing just the cpio used by the kernel. Is that reasonable?
Maybe the current channel version with public code-execution exploit (linked above) is a worse bug than this, but I don't know how commonly this bug manifests. ( channel has advanced, by the way)

Related discussion:
text: { lib, stdenv, fetchurl, fetchpatch }: <del> let </del> <ins> stdenv.mkDerivation rec { pname = "cpio"; </ins> version = "2.13"; <del> name = "cpio-${version}"; in stdenv.mkDerivation { inherit name; </del> src = fetchurl { <del> url = "mirror://gnu/cpio/${name}.tar.bz2"; </del> <ins> url = "mirror://gnu/cpio/cpio-${version}.tar.bz2"; </ins> sha256 = "0vbgnhkawdllgnkdn6zn1f56fczwk0518krakz2qbwhxmv2vvdga"; }; <del> patches = [ (fetchpatch { name = "CVE-2021-38185.patch"; url = "https://git.savannah.gnu.org/cgit/cpio.git/patch/?id=dd96882877721703e19272fe25034560b794061b"; sha256 = "0vmr0qjwj2ldnzsvccl105ckwgx3ssvn9mp3f27ss0kiyigrzz32"; }) </del> <ins> patches = let fp = suffix: rev: sha256: fetchpatch { name = "CVE-2021-38185-${suffix}.patch"; url = "https://git.savannah.gnu.org/cgit/cpio.git/patch/?id=${rev}"; inherit sha256; }; in [ (fp "1" "dd96882877721703e19272fe25034560b794061b" "0vmr0qjwj2ldnzsvccl105ckwgx3ssvn9mp3f27ss0kiyigrzz32") (fp "2" "dfc801c44a93bed7b3951905b188823d6a0432c8" "1qkrhi3lbxk6hflp6w3h4sgssc0wblv8r0qgxqzbjrm36pqwxiwh") (fp "3" "236684f6deb3178043fe72a8e2faca538fa2aae1" "0pidkbxalpj5yz4fr95x8h0rizgjij0xgvjgirfkjk460giawwg6") </ins> ]; <del> preConfigure = if stdenv.isCygwin then '' </del> <ins> preConfigure = lib.optionalString stdenv.isCygwin '' </ins> sed -i gnu/fpending.h -e 's,include <stdio_ext.h>,,' <del> '' else null; </del> <ins> ''; </ins> enableParallelBuilding = true;
Code change:
fails to build as There is an invasive change that fixed it in newer version: . But maybe it's a good time to remove old version? Maintainer information:
Started with commit
Is there a reason to still keep Ardour 5.x in nixpkgs? Edit: The reads: Is that still the case ?
Yes it is, but I'm not sure it's worth the effort to fix Ardour 5.
I prepared a PR which drops ardour_5 if we decide to go this way:

Related discussion:
text: amsn = throw "amsn has been removed due to being unmaintained."; # added 2020-12-09 antimicro = throw "antimicro has been removed as it was broken, see antimicroX instead."; # added 2020-08-06 arduino_core = arduino-core;  # added 2015-02-04 <ins> ardour_5 = throw "ardour_5 has been removed. see https://github.com/NixOS/nixpkgs/issues/139549"; # added 2021-09-28 </ins> arora = throw "arora has been removed."; # added 2020-09-09 asciidocFull = asciidoc-full;  # added 2014-06-22 asterisk_15 = throw "asterisk_15: Asterisk 15 is end of life and has been removed."; # added 2020-10-07
Code change:
fails to build as There is an invasive change that fixed it in newer version: . But maybe it's a good time to remove old version? Maintainer information:
Started with commit
Is there a reason to still keep Ardour 5.x in nixpkgs? Edit: The reads: Is that still the case ?
Yes it is, but I'm not sure it's worth the effort to fix Ardour 5.
I prepared a PR which drops ardour_5 if we decide to go this way:

Related discussion:
text: ardour = callPackage ../applications/audio/ardour { }; <del> ardour_5 = lowPrio (callPackage ../applications/audio/ardour/5.nix { }); </del> arelle = with python3Packages; toPythonApplication arelle; argo = callPackage ../applications/networking/cluster/argo { };
Code change:
"Source" link in search result on for Poetry package is pointing to poetry2nix source code instead of poetry. Steps to reproduce the behavior: on "Source" link in "poetry" package. This will point you to instead of When clicking on "Source" link in "poetry" package search results I want to get to "poetry" source code If applicable, add screenshots to help explain your problem. Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Maintainer information:
This is really a bigger issue in how source code locations are extracted and it isn't unique to Poetry/Poetry2nix. The root cause is related to how is extracted: In this case is resolved to where Poetry2nix inherits descriptions from /. You can explicitly pass to which I just implemented in :
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Related discussion:
text: }: let # Poetry2nix version <del> version = "1.20.0"; </del> <ins> version = "1.21.0"; </ins> inherit (poetryLib) isCompatible readTOML moduleName;