jiebi/CodeConvo huggingface dataset:
Change:
The top-level and derivations refer to different versions of NodeJS: refers to v8x while refers to v10x. This is quite unexpected, resulting in different versions of being installed in the store, and any build steps executed under a different version of node than the version that's used by any app using . Expected: the same nodejs interpreter should be referenced in both cases. The two different declarations can be found at Ideally this is done like / , where merely refers to . system: host os: multi-user?: sandbox: version: channels(llunesu): nixpkgs:

Discussion:
nixnote2 = libsForQt5.callPackage ../applications/misc/nixnote2 { }; <del> nodejs = hiPrio nodejs-8_x; </del> <ins> nodejs = hiPrio nodejs-10_x; </ins> <del> nodejs-slim = nodejs-slim-8_x; </del> <ins> nodejs-slim = nodejs-slim-10_x; </ins> nodejs-8_x = callPackage ../development/web/nodejs/v8.nix {}; nodejs-slim-8_x = callPackage ../development/web/nodejs/v8.nix { enableNpm = false; };
Change:
I have the latest version of VSCode installed ( channel). I tried running in my shells (zsh, bash, sh) and all of them failed with this error: My version: . However, runs fine. What could possibly be interfering?
cc
I've ran into this before, and I thought I had fixed it: . This fix didn't actually work it turns out, but the gist of it is correct: you want to set to a predetermined value instead of "deducing" it.
Unable to replicate this, my output derivation is .
strange, I ran and my vscode version remains . if this isn't reproducible, any pointers to restoring the environment's integrity?
Yeah, it seems to be kinda finicky, it also randomly fixed itself again on my device. However, I still think this is a problem we should solve. I opened , could you check if that fixes your problem?
This feels like a recurring design issue in Nix from personal experience. A similar situation for me is occurring with my LaTeX path interacting with Anki in . Are there any broader discussions about conflicts between environments being at odds with reproducibility and declarativeness? What's the heuristic for solving issues where packages launch perfectly fine in , and fail in ? thanks, will try soon--probably tomorrow.
In terms of conflicts, could be used, though it would be better to figure out which packages are causing the conflict before adding the attribute randomly.

Discussion:
mkdir -p $out/share/pixmaps cp $out/lib/vscode/resources/app/resources/linux/code.png $out/share/pixmaps/code.png <ins> # Override the previously determined VSCODE_PATH with the one we know to be correct sed -i "/ELECTRON=/iVSCODE_PATH='$out/lib/vscode'" $out/bin/code grep -q "VSCODE_PATH='$out/lib/vscode'" $out/bin/code # check if sed succeeded </ins> ''; preFixup = lib.optionalString (system == "i686-linux" || system == "x86_64-linux") ''

homepage = https://code.visualstudio.com/; downloadPage = https://code.visualstudio.com/Updates; license = licenses.unfree; <del> maintainers = with maintainers; [ eadwu ]; </del> <ins> maintainers = with maintainers; [ eadwu synthetica ]; </ins> platforms = [ "i686-linux" "x86_64-linux" "x86_64-darwin" ]; }; }
Change:
nixpkgs documentation is outdated: Announcement for new ruby infrastructure: I have one question: how do we handle packages that depend on a single rubt lib? See
Anything happenning here? Current state of affairs seems very frustrating to me from a user perspective.
cc
I'll be willing to help with bundix and ruby infrastructure tools if someone is willing to get me up to speed with this. cc
Hey, Here's a PR to bring back , along with my thoughts (and open questions) on the subject: I'm on - could we perhaps chat over IRC?
Is it the outdated documentation that's frustrating, or the requirement to use that you find frustrating? If it's the latter, why?
I linked to the mailing list announcement on page as a stop-gap.
I just worked with this yesterday and I'm happy to update the documentation to reflect that status quo. Not sure about the rubyLibs thing. Even if you depend on only a single package: using bundix is quite straight forward and there is no reason not to use it even in that situation. I'll try to work on this today.

Discussion:
<section xml:id="ssec-language-ruby"><title>Ruby</title> <del> <para>For example, to package yajl-ruby package, use gem-nix:</para> </del> <ins> <para>There currently is support to bundle applications that are packaged as Ruby gems. The utility "bundix" allows you to write a <filename>Gemfile</filename>, let bundler create a <filename>Gemfile.lock</filename>, and then convert this into a nix expression that contains all Gem dependencies automatically.</para> <para>For example, to package sensu, we did:</para> </ins> <screen> <del> $ nix-env -i gem-nix $ gem-nix --no-user-install --nix-file=pkgs/development/interpreters/ruby/generated.nix yajl-ruby $ nix-build -A rubyPackages.yajl-ruby </del> <ins> <![CDATA[$ cd pkgs/servers/monitoring $ mkdir sensu $ cat > Gemfile source 'https://rubygems.org' gem 'sensu' $ bundler package --path /tmp/vendor/bundle $ $(nix-build '&nixpkgs>' -A bundix)/bin/bundix $ cat > default.nix { lib, bundlerEnv, ruby }: bundlerEnv { name = "sensu-0.17.1"; inherit ruby; gemfile = ./Gemfile; lockfile = ./Gemfile.lock; gemset = ./gemset.nix; meta = with lib; { description = "A monitoring framework that aims to be simple, malleable, and scalable."; homepage    = http://sensuapp.org/; license     = with licenses; mit; maintainers = with maintainers; [ theuni ]; platforms   = platforms.unix; }; }]]> </ins> </screen> <del> </section> </del> <ins> <para>Please check in the <filename>Gemfile</filename>, <filename>Gemfile.lock</filename> and the <filename>gemset.nix</filename> so future updates can be run easily. </para> </section> </ins> <section xml:id="ssec-language-go"><title>Go</title>
Change:
is broken in current 19.03 nixpkgs: Attempt to build , this also fails if I pull in the with something like system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Seems like the package was updated in but the list of its dependencies was not. I fixed it in

Discussion:
{ stdenv , buildPythonPackage , fetchPypi <ins> , pythonAtLeast </ins> , numpy , decorator , imageio <ins> , imageio-ffmpeg </ins> , isPy3k <ins> , proglog , requests </ins> , tqdm <ins> # Advanced image processing (triples size of output) , advancedProcessing ? false , opencv ? null , scikitimage ? null , scikitlearn ? null , scipy ? null , matplotlib ? null , youtube-dl ? null </ins> }: <ins> assert advancedProcessing -> ( opencv != null && scikitimage != null && scikitlearn != null && scipy != null && matplotlib != null && youtube-dl != null); </ins> buildPythonPackage rec { pname = "moviepy"; version = "1.0.0"; <ins> disabled = !(pythonAtLeast "3.4"); </ins> src = fetchPypi { inherit pname version; sha256 = "16c7ffca23d90c76dd7b163f648c8166dfd589b7c180b8ff75aa327ae0a2fc6d"; }; <del> # No tests </del> <ins> # No tests, require network connection </ins> doCheck = false; <del> propagatedBuildInputs = [ numpy decorator imageio tqdm ]; </del> <ins> propagatedBuildInputs = [ numpy decorator imageio imageio-ffmpeg tqdm requests proglog ] ++ (stdenv.lib.optionals advancedProcessing [ opencv scikitimage scikitlearn scipy matplotlib youtube-dl ]); </ins> meta = with stdenv.lib; { description = "Video editing with Python";

<ins> { stdenv, fetchPypi, buildPythonPackage, tqdm }: buildPythonPackage rec { pname = "proglog"; version = "0.1.9"; src = fetchPypi { inherit pname version; sha256 = "13diln950wk6nnn4rpmzx37rvrnpa7f803gwygiwbq1q46zwri6q"; }; propagatedBuildInputs = [ tqdm ]; meta = with stdenv.lib; { description = "Logs and progress bars manager for Python"; homepage = https://github.com/Edinburgh-Genome-Foundry/Proglog; license = licenses.mit; }; } </ins>

progress = callPackage ../development/python-modules/progress { }; <ins> proglog = callPackage ../development/python-modules/proglog { }; </ins> pure-python-adb-homeassistant = callPackage ../development/python-modules/pure-python-adb-homeassistant { }; pymysql = callPackage ../development/python-modules/pymysql { };
Change:
sounddevice patching fails on unstable
I upgraded it to version 0.3.13 which and also fixed the outdated patch in

Discussion:
buildPythonPackage rec { pname = "sounddevice"; <del> version = "0.3.12"; </del> <ins> version = "0.3.13"; </ins> src = fetchPypi { inherit pname version; <del> sha256 = "f59ae4e2ec12cb1e5940f06f08804ecca855d959de25ca45a3938de45d0f81a2"; </del> <ins> sha256 = "01x2hm3xxzhxrjcj21si4ggmvkwmy5hag7f6yabqlhwskws721cd"; </ins> }; propagatedBuildInputs = [ cffi numpy portaudio ];

license = with lib.licenses; [ mit ]; maintainers = with lib.maintainers; [ fridh ]; }; <del> } </del>  No newline at end of file <ins> } </ins>

<del> diff --git a/sounddevice.py b/sounddevice.py index f03476c..5745b6e 100644 --- a/sounddevice.py +++ b/sounddevice.py @@ -58,28 +58,7 @@ from ctypes.util import find_library as _find_library </del> <ins> diff --git i/sounddevice.py w/sounddevice.py index c7c1d62..aabcb12 100644 --- i/sounddevice.py +++ w/sounddevice.py @@ -58,29 +58,7 @@ from ctypes.util import find_library as _find_library </ins> from _sounddevice import ffi as _ffi

-    for _libname in ( -            'portaudio',  # Default name on POSIX systems -            'binlibportaudio-2.dll',  # DLL from conda-forge <ins> -            'lib/libportaudio.dylib',  # dylib from anaconda </ins> -            ): -        _libname = _find_library(_libname) -        if _libname is not None:
Change:
In and it is described that to get working on a Linux kernel build, you should do: Inside that shell though, to build the kernel breaks with . Removing from the list fixes the issue. Why is that happening? If we can't fix it, we should at least update the wiki and manual. Full repro with and nixpkgs commit :
Seems to be caused by this change in the kernel: With this recent change, the kernel tries to use to find include and library flags for libelf, and fails back to the old behavior of assuming it's available in the default include/library directories. Running within shows something like: . These are flags so the compiler does not treat them like system includes and does not inhibit warnings from these headers. Making available makes the kernel use those flags, so libelf is included normally, leading to the warning and error, presumably because some kernel makefile adds to compiler flags. Without available, the libelf headers are found through include paths automatically by which are flags so warnings from those headers are ignored. I see different ways to fix this: Patch the libelf file to use instead of . Patch libelf headers to not produce those warnings. Patch the kernel to disable those warnings before including libelf (and re-enable). Any opinions?
is it normal for libelf headers to generate these warnings ? isn't that an upstream issue in some way ? I would vote for 2 ("fix libelf headers") since other approaches have their downsides: patching libelf's .pc may hide warnings for normal packages as I sometimes develop on the kernel, the more we patch its sourcecode, the more annoyed I get (pollutes git status etc.)
I'd agree that it's an upstream bug. Ran into this on my Gentoo system earlier, noticed something about those headers, and figured I'd chime in: they should be using instead of Relatively simple change, should fix the problem entirely. Edit: I'll try to send a patch upstream tomorrow or Friday. Uh, that is, today or Friday. It's past midnight. Oops.

Discussion:
"--enable-add-ons" "--sysconfdir=/etc" "--localedir=/var/run/current-system/sw/lib/locale" <ins> "libc_cv_ssp=no" </ins> (if kernelHeaders != null then "--with-headers=${kernelHeaders}/include" else "--without-headers")
Change:
Hydra log: This might be related to this upstream issue: I tried to apply the PR fixing the above issue but the patch is on master and therefore can't be applied directly to 1.2.19 without conflicts on latest nixpkgs master
A quick fix would be to use protobuf 3.6 instead of 3.7
That would be acceptable.
I opened a PR :

Discussion:
{ stdenv, fetchurl, fetchFromGitHub, fetchpatch, makeWrapper, pkgconfig <del> , qt4, qmake4Hook, qt5, avahi, boost, libopus, libsndfile, protobuf, speex, libcap </del> <ins> , qt4, qmake4Hook, qt5, avahi, boost, libopus, libsndfile, protobuf3_6, speex, libcap </ins> , alsaLib, python , jackSupport ? false, libjack2 ? null , speechdSupport ? false, speechd ? null

nativeBuildInputs = [ pkgconfig python ] ++ { qt4 = [ qmake4Hook ]; qt5 = [ qt5.qmake ]; }."qt${toString source.qtVersion}" ++ (overrides.nativeBuildInputs or [ ]); <del> buildInputs = [ boost protobuf avahi ] </del> <ins> # protobuf is freezed to 3.6 because of this bug: https://github.com/mumble-voip/mumble/issues/3617 # this could be reverted to the latest version in a future release of mumble as it is already fixed in master buildInputs = [ boost protobuf3_6 avahi ] </ins> ++ { qt4 = [ qt4 ]; qt5 = [ qt5.qtbase ]; }."qt${toString source.qtVersion}" ++ (overrides.buildInputs or [ ]);
Change:
system: host os: multi-user?: sandbox: version: channels(davidak): channels(root): nixpkgs:
Feel free to make a PR adding these two as dependencies.

Discussion:
, toml , notebook , ruamel_yaml <ins> , aiohttp , watchdog </ins> }: buildPythonPackage rec {

doit pygments pillow dateutil docutils Mako markdown unidecode lxml Yapsy PyRSS2Gen Logbook blinker natsort requests piexif Babel # requirements-extras.txt <del> phpserialize jinja2 toml notebook ruamel_yaml </del> <ins> phpserialize jinja2 toml notebook ruamel_yaml aiohttp watchdog </ins> ]; src = fetchPypi {
Change:
pyhamcrest is packaged using buildPythonApplication. However, pyhamcrest is a library and not an application. Try to install pyhamcrest and then import it. You cannot. Please run and paste the results.

Discussion:
<del> { stdenv, buildPythonApplication, fetchPypi </del> <ins> { stdenv, buildPythonPackage, fetchPypi </ins> , mock, pytest , six }: <del> buildPythonApplication rec { </del> <ins> buildPythonPackage rec { </ins> pname = "PyHamcrest"; version = "1.9.0";
Change:
Installing xmonad result in the following error: Looking at the git log leads to commit cc
This is indeed due to , upgrading should fix it, I'm doing it right now.
IMHO, the best way to ensure that works properly in the future is to port the NixOS module to the package set (which should not be difficult). Many Haskell users in Nix have converted already, and so the stuff in doesn't get as much anymore attention as it used to.

Discussion:
cabal.mkDerivation (self: { pname = "shelly"; <del> version = "1.5.6"; sha256 = "1vnn0s3i3n76286b7rc70qjzgkmfwllpg7w4zin627v6466pfpzl"; </del> <ins> version = "1.6.0"; sha256 = "0yrx7sv1s8pddpap143d3yi3ypvf84jjh16i8b3dm4kb3m4x3mdv"; </ins> buildDepends = [ async enclosedExceptions exceptions liftedAsync liftedBase monadControl mtl systemFileio systemFilepath text time transformers
Change:
On NixOS 19.03 When running the Awesome Window Manager, if it's restarted within the same X session (e.g. by sending a or with the default shortcut ), the same options are to the command line. Example of relevant NixOS configuration: using into an X session that uses the a terminal and run that is highlighted twice in line with awesome, e.g. by pressing that the number of times that is highlighted has doubled, i.e. the options have been appended to the previous command. Note that is not affected, i.e. the options for those modules is not re-appended on restarts: NixOS system: host os: multi-user?: sandbox: version: channels(root): channels(user): nixpkgs: awesome 4.3 (Too long) Compiled against Lua 5.2.4 (running with Lua 5.2) D-Bus support: execinfo support: xcb-randr version: 1.6 LGI version: 0.9.2
AwesomeWM restarts via . In NixOS, is used to generate a wrapper around the real binary. calls with . I guess this is what makes awesomeWM run the wrapper again on restart. Without this would directly restart itself instead of the wrapper, I think. output in tools like would change, showing the real binary instead of the wrapper as the command being run (this could be an unintended side effect of dropping the argument).
I see. I am not sure about actual consequences of this behavior, but it seems to worth a fix. Would using directly rather than help?
I have tried this out and That is correct, and in fact the issue of the repeated options disappears altogether This does not happen with my patch (see below) where I rename the executable the same way does, but I use without the argument. (Incidentally, I have discovered that calling creates a file , obviously because of the wrapper) What do you think? could this be merged (I already have the commit so submitting a PR would be quick)
Well, I'd prefer a version that sounds less like "awesome is doing something wrong". How about "or the wrapper will duplicate the --search arguments every restart"?
Sure, your wording make definitely more sense and is more accurate. If that's OK, I can prepare a PR.

Discussion:
LUA_PATH  = "${lgi}/share/lua/${lua.luaversion}/?.lua;;"; postInstall = '' <del> wrapProgram $out/bin/awesome  </del> <ins> # Don't use wrapProgram or or the wrapper will duplicate the --search # arguments every restart mv "$out/bin/awesome" "$out/bin/.awesome-wrapped" makeWrapper "$out/bin/.awesome-wrapped" "$out/bin/awesome"  </ins> --set GDK_PIXBUF_MODULE_FILE "$GDK_PIXBUF_MODULE_FILE"  --add-flags '--search ${lgi}/lib/lua/${lua.luaversion}'  --add-flags '--search ${lgi}/share/lua/${lua.luaversion}'
Change:
This is pretty confusing: ! Install and try to launch it from your DE. Which icon do you click on? They both do the same thing anyway. system: host os: multi-user?: sandbox: version: channels(root): channels(stanislas): nixpkgs:
I can reproduce this issue. I think it is caused by this line Would need to have more of a look but at least one of the desktop items is coming from this line and removing it would likely solve the problem
Thanks! I submitted a PR to remove the custom desktop file.

Discussion:
<del> { stdenv, fetchFromGitHub, fetchurl, makeDesktopItem, pkgconfig, cmake, python3 </del> <ins> { stdenv, fetchFromGitHub, fetchurl, pkgconfig, cmake, python3 </ins> , libX11, libXrandr, qtbase, qtwebchannel, qtwebengine, qtx11extras , libvdpau, SDL2, mpv, libGL }: let

buildInputs = [ libX11 libXrandr qtbase qtwebchannel qtwebengine qtx11extras libvdpau SDL2 mpv libGL ]; <del> desktopItem = makeDesktopItem { name = "plex-media-player"; exec = "plexmediaplayer"; icon = "plex-media-player"; comment = "View your media"; desktopName = "Plex Media Player"; genericName = "Media Player"; categories = "AudioVideo;Video;Player;TV;"; }; </del> preConfigure = with depSrcs; '' mkdir -p build/dependencies ln -s ${webClient} build/dependencies/buildid-${webClientBuildId}.cmake

ln -s ${webClientTv} build/dependencies/web-client-tv-${webClientTvBuildId}.tar.xz ''; <del> postInstall = '' mkdir -p $out/share/{applications,pixmaps} cp ${src}/resources/images/icon.png $out/share/pixmaps/plex-media-player.png cp ${desktopItem}/share/applications/* $out/share/applications ''; </del> cmakeFlags = [ "-DCMAKE_BUILD_TYPE=RelWithDebInfo" "-DQTROOT=${qtbase}" ]; meta = with stdenv.lib; {
Change:
When I execute nix-shell with substitute = false my build fails with I suspect this is because produces a 404 because. It should be in nix-bitcoin repo @ to your nix-shell to build from source Occured during testing of

Discussion:
#    dynamically using sysconf(_SC_PAGE_SIZE) instead of hardcoded value that hopefully is correct. # [1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html # [2] http://www.openwall.com/lists/musl/2015/09/11/8 <del> url = "https://raw.githubusercontent.com/voidlinux/void-packages/a0ece13ad7ab2aae760e09e41e0459bd999a3695/srcpkgs/thin-provisioning-tools/patches/musl.patch"; </del> <ins> url = "https://raw.githubusercontent.com/void-linux/void-packages/a0ece13ad7ab2aae760e09e41e0459bd999a3695/srcpkgs/thin-provisioning-tools/patches/musl.patch"; </ins> sha256 = "1m8r3vhrnsy8drgs0svs3fgpi3mmxzdcqsv6bmvc0j52cvfqvhvy"; extraPrefix = ""; # empty means add 'a/' and 'b/' })
Change:
Running fails with message . system: host os: multi-user?: sandbox: version: channels(root): channels(mnacamura): nixpkgs:
I tried this patch: Then, it says It seems that the module is now visible from python but another problem has popped up.
looks like an intentional bug in the program. Try running without variable in the environment to trigger the alternative branch.
Oh, it comes from our packaging.

Discussion:
<del> { stdenv, pkgconfig, fetchurl, python3, dropbox }: </del> <ins> { stdenv , substituteAll , pkgconfig , fetchurl , python3 , dropbox , gtk3 , gnome3 , gdk_pixbuf , gobject-introspection }: </ins> let version = "2019.02.14"; dropboxd = "${dropbox}/bin/dropbox";

stdenv.mkDerivation { name = "dropbox-cli-${version}"; <ins> outputs = [ "out" "nautilusExtension" ]; </ins> src = fetchurl { url = "https://linux.dropboxstatic.com/packages/nautilus-dropbox-${version}.tar.bz2"; sha256 = "09yg7q45sycl88l3wq0byz4a9k6sxx3m0r3szinvisfay9wlj35f"; }; <del> nativeBuildInputs = [ pkgconfig ]; buildInputs = [ python3 ]; phases = "unpackPhase installPhase"; installPhase = '' mkdir -p "$out/bin/" "$out/share/applications" cp data/dropbox.desktop "$out/share/applications" cp -a data/icons "$out/share/icons" find "$out/share/icons" -type f ! -name '*.png' -delete substitute "dropbox.in" "$out/bin/dropbox"  --replace '@PACKAGE_VERSION@' ${version}  --replace '@DESKTOP_FILE_DIR@' "$out/share/applications"  --replace '@IMAGEDATA16@' '"too-lazy-to-fix"'  --replace '@IMAGEDATA64@' '"too-lazy-to-fix"' sed -i 's:db_path = .*:db_path = "${dropboxd}":' $out/bin/dropbox chmod +x "$out/bin/"* patchShebangs "$out/bin" ''; </del> <ins> strictDeps = true; patches = [ (substituteAll { src = ./fix-cli-paths.patch; inherit dropboxd; }) ]; nativeBuildInputs = [ pkgconfig gobject-introspection gdk_pixbuf # only for build, the install command also wants to use GTK through introspection # but we are using Nix for installation so we will not need that. (python3.withPackages (ps: with ps; [ docutils pygobject3 ])) ]; buildInputs = [ python3 gtk3 gnome3.nautilus ]; configureFlags = [ "--with-nautilus-extension-dir=${placeholder ''nautilusExtension''}/lib/nautilus/extensions-3.0" ]; makeFlags = [ "EMBLEM_DIR=${placeholder ''nautilusExtension''}/share/nautilus-dropbox/emblems" ]; </ins> meta = { <del> homepage = http://dropbox.com; </del> <ins> homepage = https://www.dropbox.com; </ins> description = "Command line client for the dropbox daemon"; <del> license = stdenv.lib.licenses.gpl3; </del> <ins> license = stdenv.lib.licenses.gpl3Plus; </ins> maintainers = with stdenv.lib.maintainers; [ the-kenny ]; # NOTE: Dropbox itself only works on linux, so this is ok. platforms = stdenv.lib.platforms.linux;

<ins> --- a/dropbox.in +++ b/dropbox.in @@ -71,7 +71,7 @@ PARENT_DIR = os.path.expanduser("~") DROPBOX_DIST_PATH = "%s/.dropbox-dist" % PARENT_DIR -DROPBOXD_PATH = os.path.join(DROPBOX_DIST_PATH, "dropboxd") +DROPBOXD_PATH = "@dropboxd@" DESKTOP_FILE = "@DESKTOP_FILE_DIR@/dropbox.desktop" enc = locale.getpreferredencoding() </ins>
Change:
When I execute nix-shell with substitute = false my build gets stuck with I suspect this is because the test suite gets stuck on systems other than just Darwin. Would it be a solution to disable the test suite entirely? nix-bitcoin repo @ substitute = false to your nix-shell to build from source Occured during testing of fort-nix/nix-bitcoin

Discussion:
substituteInPlace setup.py --replace "six==1.10.0" "six>=1.10.0" ''; <del> # Do not test on Python 2 darwin because the tests suite gets stuck # https://github.com/JBKahn/rednose/issues/23 doCheck = !(stdenv.isDarwin && isPy27); </del> <ins> # Do not test on Python 2 because the tests suite gets stuck # https://github.com/NixOS/nixpkgs/issues/60786 doCheck = !(isPy27); </ins> checkInputs = [ six ]; propagatedBuildInputs = [ nose colorama termstyle ];