jiebi/CodeConvo huggingface dataset:
Change:
Package name: Latest released version: <!-- Search your package here: --- Current version on the unstable channel: 44.3 Current version on the stable/release channel: 44.2 <!-- 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.

Discussion:
stdenv.mkDerivation rec { pname = "gnome-boxes"; <del> version = "44.2"; </del> <ins> version = "44.3"; </ins> src = fetchurl { url = "mirror://gnome/sources/${pname}/${lib.versions.major version}/${pname}-${version}.tar.xz"; <del> sha256 = "ndOJwUnQwPpXRW7DY9UaiCVflFVY+530KJTOeO+F34k="; </del> <ins> sha256 = "ZIpBuODIdfBOOnh+pnA2vJIehYo25jQ6Q9tyQu5z4XE="; </ins> }; patches = [

in stdenv.mkDerivation rec { pname = "gnome-shell"; <del> version = "44.3"; </del> <ins> version = "44.4"; </ins> outputs = [ "out" "devdoc" ]; src = fetchurl { url = "mirror://gnome/sources/gnome-shell/${lib.versions.major version}/${pname}-${version}.tar.xz"; <del> sha256 = "VWlLccLuTq72DZNCgAPy6qTPABhoSPXja0XP5Qb8Mb8="; </del> <ins> sha256 = "HdUebujZL7y5XObd8Ruf7OiNImIsAQFf+pNgFpzUGGY="; </ins> }; patches = [

stdenv.mkDerivation (finalAttrs: { pname = "mutter"; <del> version = "44.3"; </del> <ins> version = "44.4"; </ins> outputs = [ "out" "dev" "man" "devdoc" ]; src = fetchurl { url = "mirror://gnome/sources/mutter/${lib.versions.major finalAttrs.version}/mutter-${finalAttrs.version}.tar.xz"; <del> sha256 = "GFy+vyFQ0+RQVQ43G9sTqLTbCWl4sU+ZUh6WbqzHBVE="; </del> <ins> sha256 = "M3IKWGywqacyr1oH7RPj89MqGml4EjURQKVLygBrlAw="; </ins> }; mesonFlags = [
Change:
Steps to reproduce the behavior: emacs29-macport The emacs is installed using home-manager on MacOS Reverting NixOS/nixpkgs back to NixOS/nixpkgs fixes the problem.
Well, I don't have machine to test Darwin things. But, is this a home-manager related thing? Have you tried to run a nix-shell?
I am not sure, but it surely stopped working after NixOS/nixpkgs . Please also take a look at this file listings below <details<summary Working </summary<p</p</details<details<summary Latest </summary<p</p</detailsIt seems that there is fewer files now in the output for whatever reason?
I'm having the same issue on darwin with emacs28-macport
Running between the and yields this as the breaking commit:
Invoking
is gated on in : Which is set by checking for : Which, according to , fails because of more SDK issues: This is happening because is still including an old Libsystem, this time from : Looks like may have produced a non-failing build, but missed this usage of .
Also built on Hydra:
I think the issue we're concerned about is still not fixed. is missing and is incorrectly built.
I was wrong here. doesn't propagate Libsystem, it only depends on it. The correct (and baffling) solution is to explicitly inherit llvmPackages14 from .

Discussion:
inherit stdenv; inherit (pkgs.darwin) sigtool; <ins> inherit (pkgs.darwin.apple_sdk_11_0) llvmPackages_14; </ins> inherit (pkgs.darwin.apple_sdk_11_0.frameworks) Accelerate AppKit Carbon Cocoa GSS ImageCaptureCore ImageIO IOKit OSAKit Quartz QuartzCore UniformTypeIdentifiers WebKit;
Change:
Package name: betterbird Latest released version: 102.15.0-bb40 <!-- Search your package here: --- Current version on the unstable channel: 102.14.0 Current version on the stable/release channel: 102.12.0 <!-- 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: Can you please also backport to 23.05? Please tag this issue in your PR.
Anyone who is a maintainer can put that label on which would help me tremendously because I do not have a machine with NixOS stable and cannot verify if the graphical stack works.
Thank you!

Discussion:
let thunderbird-unwrapped = thunderbirdPackages.thunderbird-102; <del> version = "102.14.0"; </del> <ins> version = "102.15.0"; </ins> majVer = lib.versions.major version; betterbird-patches = fetchFromGitHub { owner = "Betterbird"; repo = "thunderbird-patches"; <del> rev = "${version}-bb39"; </del> <ins> rev = "${version}-bb40"; </ins> postFetch = '' echo "Retrieving external patches"

. ./external.sh rm external.sh ''; <del> hash = "sha256-O9nGlJs3OziQLbdbdt3eFRHvk1A9cdEsbKDtsZrnY5Q="; </del> <ins> hash = "sha256-7/JEcP76rp0hSSxzlIlHqkcxTSEJQswFhCoOLYntQ5I="; </ins> }; in ((buildMozillaMach { pname = "betterbird";

src = fetchurl { # https://download.cdn.mozilla.net/pub/thunderbird/releases/ url = "mirror://mozilla/thunderbird/releases/${version}/source/thunderbird-${version}.source.tar.xz"; <del> sha512 = "4ae3f216833aec55421f827d55bc1b5fc2f0ad4fefecb27724a5be3318c351df24d30a4897b924e733ed2e3995be284b6d135049d46001143fb1c961fefc1830"; </del> <ins> sha512 = "11d4c77049c532753c9b693d69ab9a0bcd0eb13d49f87a511ad8ba680b70041ac6f64c5f9cd5dd44246d46e7695d9bd51146b1fe62b0b7c9fbc862eb53d5cfda"; </ins> }; extraPostPatch = thunderbird-unwrapped.extraPostPatch or "" + /* bash */ ''
Change:
But: And: From what I see , it looks like the kind of problem one can have when executing bytecode with the wrong version of the bytecode interpreter. cc

Discussion:
<ins> {stdenv, fetchurl, yacc, flex, pkgconfig, glib, xz}: stdenv.mkDerivation rec { version = "0.15.2"; name = "vala-${version}"; src = fetchurl { url = "mirror://gnome/sources/vala/0.15/${name}.tar.xz"; sha256 = "0g71zq6dpqrw2f40wfzdf18fdw41ymr17laqniy2kr622hkxdi8w"; }; buildNativeInputs = [ yacc flex pkgconfig xz ]; buildInputs = [ glib ]; meta = { description = "Compiler for the GObject type system"; homepage = "http://live.gnome.org/Vala"; license = "free-copyleft"; platforms = stdenv.lib.platforms.all; maintainers = [ stdenv.lib.maintainers.antono ]; }; } </ins>

<ins> {stdenv, fetchurl, yacc, flex, pkgconfig, glib, xz}: stdenv.mkDerivation rec { version = "0.16.1"; name = "vala-${version}"; src = fetchurl { url = "mirror://gnome/sources/vala/0.16/${name}.tar.xz"; sha256 = "1n708n9ixyy9qrzyv1wf4ybvcclx43ib9ki028wwpvkz6kv8zqlb"; }; buildNativeInputs = [ yacc flex pkgconfig xz ]; buildInputs = [ glib ]; meta = { description = "Compiler for the GObject type system"; homepage = "http://live.gnome.org/Vala"; license = "free-copyleft"; platforms = stdenv.lib.platforms.all; maintainers = [ stdenv.lib.maintainers.antono ]; }; } </ins>

{stdenv, fetchurl, yacc, flex, pkgconfig, glib, xz}: stdenv.mkDerivation rec { <del> name = "vala-0.14.2"; </del> <ins> version = "0.17.2"; name = "vala-${version}"; </ins> src = fetchurl { <del> url = mirror://gnome/sources/vala/0.14/vala-0.14.2.tar.xz; sha256 = "1l5kllw9vpwv24lzv9fp64l3sad46wpxgvsgryrwlrjg91w6jzl0"; </del> <ins> url = "mirror://gnome/sources/vala/0.17/${name}.tar.xz"; sha256 = "09i2s0dwmrk147ind2dx7nq845g12fp6fsjqrphhrr0dbi0zzgh3"; </ins> }; buildNativeInputs = [ yacc flex pkgconfig xz ];

meta = { description = "Compiler for the GObject type system"; homepage = "http://live.gnome.org/Vala"; <ins> license = "free-copyleft"; platforms = stdenv.lib.platforms.all; maintainers = [ stdenv.lib.maintainers.antono ]; </ins> }; }

urweb = callPackage ../development/compilers/urweb { }; <del> vala = callPackage ../development/compilers/vala { }; </del> <ins> vala = vala17; vala15 = callPackage ../development/compilers/vala/15.2.nix { }; vala16 = callPackage ../development/compilers/vala/16.1.nix { }; vala17 = callPackage ../development/compilers/vala/default.nix { }; </ins> visualcpp = callPackage ../development/compilers/visual-c++ { };
Change:
Steps to reproduce the behavior: The builds are also failing on Hydra Please run and paste the result.
Several errors like this locally and in
is not set on the system outside the nix-shell and also does not seem to be set when the bazel command is executed within the nix-build. On the same system, with bazelisk, version 0.23.1 builds from source:
merge introduced a build failure (found via git bisect) which merged this change: Reverting it on master makes it work but also reverts bazel-watcher to an older version. AND only works if the is set. I assume it will not actually call the updated fetch logic at all since it just uses the fetched dependencies from the cache. Maybe can help out fixing it...
:)
The makes it hard to bisect since it will "hide" all fetch affecting changes behind that cached results. Long live fixed output derivations!
I was wrong. The fetchAttrs.sha256 hid that it was, in fact, broken before
I bisected this to the following commit: with this bisect script: Unfortunately, it is a huge merge.
Okay fetching broke when go was unpinned:
Maybe related to
: Could you maybe merge ? It would be appreciated.

Discussion:
rulesProto = fetchFromGitHub { owner = "bazelbuild"; repo = "rules_proto"; <del> rev = "4.0.0-3.19.2"; sha256 = "sha256-wdmp+Tmf63PPr7G4X5F7rDas45WEETU3eKb47PFVI6o="; </del> <ins> rev = "4.0.0"; hash = "sha256-WVPZx14thneAC4PdiDhBibnPwlCKEF9c93CHR0t1Efo="; </ins> postFetch = '' sed -i 's|name = "protoc"|name = "_protoc_original"|' $out/proto/private/BUILD.release cat <<EOF >>$out/proto/private/BUILD.release

in buildBazelPackage rec { pname = "bazel-watcher"; <del> version = "0.23.1"; </del> <ins> version = "0.24.0"; </ins> src = fetchFromGitHub { owner = "bazelbuild"; repo = "bazel-watcher"; rev = "v${version}"; <del> sha256 = "sha256-fnhbxrgwffFQDIRLGisi1Wk3EjfkN8Mi8wtWT/Gy+78="; </del> <ins> hash = "sha256-ebNHAYKyE3226KiCc2/VSz1OSITuPwuYlAIS3JrWzj0="; </ins> }; nativeBuildInputs = [ go git python3 ];

# currently present in PATH. Without removing the go_sdk from the marker # file, the hash of it will change anytime the Go derivation changes and # that would lead to impurities in the marker files which would result in <del> # a different sha256 for the fetch phase. </del> <ins> # a different hash for the fetch phase. </ins> rm -rf $bazelOut/external/{go_sdk,@go_sdk.marker} sed -e '/^FILE:@go_sdk.*/d' -i $bazelOut/external/@*.marker

rm -rf $bazelOut/external/com_google_protobuf ''; <del> sha256 = "sha256-7/sLGgUCG4SU2nbK0596467dlrKylewiewhIvNFTMvY="; </del> <ins> sha256 = "sha256-B2KVD/FmkAa7MNhLaH286gF3uA20qjN3CoA83KRB9E8="; </ins> }; buildAttrs = {
Change:
when trying to optimize a file larger than 8MB, then invoking OptiPNG on it again (such as from an "all files" script", it fails with a Warning with random text. trying to said warning results in the image getting permanently corrupted. this is probably because pulls in that uses libpng 1.2.59 and not which uses libpng 1.6.39 Steps to reproduce the behavior: a very large PNG file - 8MB or higher should work. to optimize the file using OptiPNG to optimize the file again. has a "recoverable error". says libpng 1.2.59, instead of a newer version. files to not be corrupted, optipng -v outputing a version of libpng newer than 1.2.59 how about logshots see i suspect the file too large causing problems part will apply to any software that uses this libpng. maybe deprecate the package? Please run and paste the result.
This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
goshdarnit where's my :wave: emote

Discussion:
optifine = optifinePackages.optifine-latest; <del> optipng = callPackage ../tools/graphics/optipng { libpng = libpng12; }; </del> <ins> optipng = callPackage ../tools/graphics/optipng { }; </ins> olsrd = callPackage ../tools/networking/olsrd { };
Change:
When I try to request new certificates I get a : New certificates Please run and paste the result. on nixos-unstable
duplicate of (by 2 minutes :grin:)

Discussion:
, six , zope-component , zope_interface <ins> , setuptools </ins> , dialog , gnureadline , pytest-xdist

buildPythonPackage rec { pname = "certbot"; <del> version = "2.4.0"; </del> <ins> version = "2.6.0"; </ins> src = fetchFromGitHub { owner = pname; repo = pname; rev = "refs/tags/v${version}"; <del> hash = "sha256-BQsdhlYABZtz5+SORiCVnWMZdMmiWGM9W1YLqObyFo8="; </del> <ins> hash = "sha256-CbYamk1+NvcyS6w7pOjpD5lqWHCk+VJqF9R3xYxzpQk="; </ins> }; sourceRoot = "${src.name}/${pname}";

six zope-component zope_interface <ins> setuptools # for pkg_resources </ins> ]; buildInputs = [ dialog gnureadline ];
Change:
Project description A CLI interface to Jinja2 Metadata homepage URL: source URL: license: bsd2 platforms: unix, linux, darwin Other info This was closed

Discussion:
<ins> { lib , python3 , fetchFromGitHub , extras ? [ "hjson" "json5" "toml" "xml" "yaml" ] }: python3.pkgs.buildPythonApplication rec { pname = "jinja2-cli"; version = "0.8.2"; format = "pyproject"; src = fetchFromGitHub { owner = "mattrobenolt"; repo = "jinja2-cli"; rev = version; hash = "sha256-67gYt0nZX+VTVaoSxVXGzbRiXD7EMsVBFWC8wHo+Vw0="; }; nativeBuildInputs = [ python3.pkgs.setuptools python3.pkgs.wheel ]; nativeCheckInputs = [ python3.pkgs.pytestCheckHook ]; propagatedBuildInputs = with python3.pkgs; [ jinja2 ] ++ lib.attrVals extras passthru.optional-dependencies; pythonImportsCheck = [ "jinja2cli" ]; passthru.optional-dependencies = with python3.pkgs; { hjson = [ hjson ]; json5 = [ json5 ]; toml = [ toml ]; xml = [ xmltodict ]; yaml = [ pyyaml ]; }; meta = with lib; { description = "CLI for Jinja2"; homepage = "https://github.com/mattrobenolt/jinja2-cli"; license = licenses.bsd2; maintainers = with maintainers; [ figsoda ]; mainProgram = "jinja2"; }; } </ins>
Change:
Upon launching,  white screens without any visible errors. or the app white screen It works without white screening Since runs fine when using its pre-built AppImage, I don't suspect that there is any issue with my hardware, drivers, or software. After testing, I have found out that the issue exists on specifically. It works fine on KDE. (Note: I haven't tried on similar environments like Sway) Running produces the following output upon exiting : Hello,
I am thinking of adding a package so that any user facing this or similar issues can use pre-built binaries as a instant solution than waiting for existing nix expressions to be fixed. Please guide me if you guys think this should/can be done. (The NixOS manual doesn't provide much help with wrappers around AppImages)
Could you please run in a terminal (in the environment where the issue occurs) and paste the output in a comment, in a . I also have a few questions, you get those same errors when you run from the terminal? this X11 KDE, or Wayland KDE? is your GPU, and which drivers are you using? I don't think we should do this. If a user wants to run pre-built binaries from upstream, there are straightforward ways to do so. Since Heroic ships an AppImage, you can use .
I've already tried running heroic from a terminal and weirdly, there's absolutely no error that shows up. Which makes me think it's a purely front-end error given heroic uses electron. , I do. KDE . My driver setup is contained in Yeah, that makes sense. But how do I make sure it's always installed on my system? Do I have to run every single time I need to launch?
Update: I have tested this in Sway as well and the app does white screen with no errors in the terminal.
Try running Heroic from the branch I just pushed (command below) to see if it resolves the issue. I've changed the Electron version the package uses to match that of the upstream package, as there seems to be a regression in the latest version of Electron.
Just tested this. I don't get the white screen anymore!!
This happens for me now, trying the nix shell now.
That fixed it, thanks!

Discussion:
gotypist = callPackage ../games/gotypist { }; <del> heroic-unwrapped = callPackage ../games/heroic { }; </del> <ins> heroic-unwrapped = callPackage ../games/heroic { # Match the version used by the upstream package. electron = electron_24; }; </ins> heroic = callPackage ../games/heroic/fhsenv.nix { };
Change:
Only happened to me on Darwin (x86_64). <!-- 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.
Can confirm that I the same issue, with essentially identical output, on x86_64-darwin.

Discussion:
poetry = self.callPackage ./unwrapped.nix { }; # version overrides required by poetry and its plugins <ins> deepdiff = super.deepdiff.overridePythonAttrs (old: rec { doCheck = false; }); </ins> poetry-core = super.poetry-core.overridePythonAttrs (old: rec { version = "1.7.0"; src = fetchFromGitHub {

rev = version; hash = "sha256-OfY2zc+5CgOrgbiPVnvMdT4h1S7Aek8S7iThl6azmsk="; }; <ins> patches = [ ]; </ins> }); } // (plugins self); };
Change:
Project description A command-line tool to prevent committing secret keys into your source code. It has a few features that distinguish it from other secret scanning tools. Metadata homepage URL: source URL: license: mit platforms: linux, darwin

Discussion:
<ins> { lib , rustPlatform , fetchFromGitHub }: rustPlatform.buildRustPackage rec { pname = "ripsecrets"; version = "0.1.6"; src = fetchFromGitHub { owner = "sirwart"; repo = "ripsecrets"; rev = "v${version}"; hash = "sha256-p3421sQko/WulSNUxXpjsHPAtRoHHg61angfxJpoyFg="; }; cargoHash = "sha256-DJkEhqW5DZOmoNiS4nw+i2G0+KN2d7FbBuKp7fdAwMk="; meta = with lib; { description = "A command-line tool to prevent committing secret keys into your source code"; homepage = "https://github.com/sirwart/ripsecrets"; changelog = "https://github.com/sirwart/ripsecrets/blob/${src.rev}/CHANGELOG.md"; license = licenses.mit; maintainers = with maintainers; [ figsoda ]; mainProgram = "ripsecrets"; }; } </ins>
Change:
fails to install because tests fail. The failing test is the clipboard test that is meant to be disabled on darwin through . This is not actually disabling the test but rather forcing it to fail, but this can be fixed with a small change. Then we reach a different failing test: I'm not sure if this is darwin specific, nixpkgs specific, or a known bug in . System: OSX Sierra 10.12.4 (16E195) Nix version: 1.11.6 Nixpkgs version: 17.03.1052.
I can't reproduce the issue on NixOS, and I didn't find an issue on the pandas tracker about it either. I did see some similar issues when ran against numpy 1.12 or a different version of numexpr.
From the environment I can see that the version of numpy is 1.11.3.
This may be related to a bug in numpy (numpy/numpy) that was fixed in numpy 1.12.1. I'm trying to build again against that version and I'll see if that fixes it.
I needed to fix pytables first to get to the error you are describing:

Discussion:
, openpyxl , tables , xlwt <del> , darwin ? {} </del> , libcxx ? null }:

openpyxl tables xlwt <del> ] ++ optional isDarwin darwin.locale; # provides the locale command </del> <ins> ]; </ins> # For OSX, we need to add a dependency on libcxx, which provides # `complex.h` and other libraries that pandas depends on to build.

substituteInPlace setup.py  --replace "['pandas/src/klib', 'pandas/src']"  "['pandas/src/klib', 'pandas/src', '$cpp_sdk']" <del> # disable clipboard tests since pbcopy/pbpaste are not open source substituteInPlace pandas/io/tests/test_clipboard.py  --replace pandas.util.clipboard no_such_module  --replace OSError ImportError </del> ''; checkPhase = '' runHook preCheck <del> py.test $out/${python.sitePackages}/pandas --skip-slow --skip-network </del> <ins> '' # TODO: Get locale and clipboard support working on darwin. #       Until then we disable the tests. + optionalString isDarwin '' # Fake the impure dependencies pbpaste and pbcopy echo "#!/bin/sh" > pbcopy echo "#!/bin/sh" > pbpaste chmod a+x pbcopy pbpaste export PATH=$(pwd):$PATH '' + '' py.test $out/${python.sitePackages}/pandas --skip-slow --skip-network  ${if isDarwin then "-k 'not test_locale and not test_clipboard'" else ""} </ins> runHook postCheck '';

homepage = "http://pandas.pydata.org/"; description = "Python Data Analysis Library"; license = stdenv.lib.licenses.bsd3; <del> maintainers = with stdenv.lib.maintainers; [ raskin fridh ]; </del> <ins> maintainers = with stdenv.lib.maintainers; [ raskin fridh knedlsepp ]; </ins> platforms = stdenv.lib.platforms.unix; }; }
Change:
Steps to reproduce the behavior: neomutt, I tested using because I didn't know how to do overrides from the CLI The fix on only fixed , it was that it could be fixed by adding into . I just tested this and it's still broken <!-- 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.

Discussion:
n8n = callPackage ../applications/networking/n8n { }; <del> neomutt = callPackage ../applications/networking/mailreaders/neomutt { }; </del> <ins> neomutt = darwin.apple_sdk_11_0.callPackage ../applications/networking/mailreaders/neomutt { }; </ins> neosay = callPackage ../applications/networking/instant-messengers/neosay { };
Change:
As said here , you can't download nvidia drivers from ftp, and downloads it from there. Place in your System: NixOS Nix version: Nixpkgs version:
Should be fixed by

Discussion:
let wantCurl = withRemote || withImportd; wantGcrypt = withResolved || withImportd; <del> version = "252.1"; </del> <ins> version = "252.3"; </ins> # Bump this variable on every (major) version change. See below (in the meson options list) for why. # command:

owner = "systemd"; repo = "systemd-stable"; rev = "v${version}"; <del> hash = "sha256-G43qbNF7znTITSM78sOL0qi8nqaA7qIhmiqP/rZKjXY="; </del> <ins> hash = "sha256-F2wtg12amigd5KNCWmG3b9Yu6PUOby9mQgZ2VFtxl5A=="; </ins> }; # On major changes, or when otherwise required, you *must* reformat the patches,
Change:
Deluge 2.x is compatible with libtorrent 2.0.9, but the current deluge install will use the old libtorrent 1.2.11 (both in 23.05 and unstable). This is unexpected, because the should build with the up-to-date and not the old . libtorrent version reported by deluge should be should not depend on should depend on If applicable, add screenshots to help explain your problem. When I manually rebuild deluge by copying the with no edits, I get the recent libtorrent version, with both the 23.05 as well as the unstable channels. Might it therefore be a cache problem? Currently, I have have this seemingly meaningless line in my NixOS configuration to fix the issue: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
is overridden in all-
Oh that explains it! Github search did not show this to me when I searched for it. Should this override be removed? Upstream Deluge has no constraints so a normal pypi install will use 2.0.x by default (even though 1.2.x is still ). Moreover, the test version is to 2.0.x. EDIT: Deluge libtorrent was pinned to 1.2 in this pr: Supposedly, Deluge 2.0.3 was not entirely compatible with libtorrent 2.0. There is no explicit mention in the Deluge changelog about this, except for a "Remove libtorrent deprecated functions." line in the changelog of Deluge 2.1. And as I mentioned, upstream uses libtorrent 2.0, so the override seems outdated. I have not spotted obvious issues with libtorrent 2.0.9 in Deluge 2.1.1 myself.

Discussion:
ddrutility = callPackage ../tools/system/ddrutility { }; <del> inherit (callPackages ../applications/networking/p2p/deluge { libtorrent-rasterbar = libtorrent-rasterbar-1_2_x; }) </del> <ins> inherit (callPackages ../applications/networking/p2p/deluge { }) </ins> deluge-gtk deluged deluge;