jiebi/CodeConvo huggingface dataset:
Change:
Project description A dbus api to start programs on a different GPU Metadata homepage URL: source license: gpl3 platforms: linux
Duplicate

Discussion:
<ins> { config, pkgs, lib, ... }: with lib; let pkg = [ pkgs.switcheroo-control ]; cfg = config.services.switcherooControl; in { options.services.switcherooControl = { enable = mkEnableOption "switcheroo-control, a D-Bus service to check the availability of dual-GPU"; }; config = mkIf cfg.enable { services.dbus.packages = pkg; environment.systemPackages = pkg; systemd.packages = pkg; systemd.targets.multi-user.wants = [ "switcheroo-control.service" ]; }; } </ins>

<ins> { lib , ninja , meson , fetchFromGitLab , systemd , libgudev , pkg-config , glib , python3 , gobject-introspection }: python3.pkgs.buildPythonApplication rec { pname = "switcheroo-control"; version = "2.3"; format = "other"; src = fetchFromGitLab { domain = "gitlab.freedesktop.org"; owner = "hadess"; repo = pname; rev = version; hash = "sha256-1Pze2TJ9mggfcpiLFwJ7/9WhsdJx4G3GoA7+Z47shuc="; }; nativeBuildInputs = [ ninja meson pkg-config # needed for glib-compile-resources glib ]; buildInputs = [ systemd libgudev ]; propagatedBuildInputs = [ python3.pkgs.pygobject3 ]; mesonFlags = [ "-Dsystemdsystemunitdir=${placeholder "out"}/etc/systemd/system" "-Dhwdbdir=${placeholder "out"}/etc/udev/hwdb.d" ]; meta = with lib; { description = "D-Bus service to check the availability of dual-GPU"; homepage = "https://gitlab.freedesktop.org/hadess/switcheroo-control/"; changelog = "https://gitlab.freedesktop.org/hadess/switcheroo-control/-/blob/${version}/NEWS"; license = licenses.gpl3Plus; maintainers = [ ]; platforms = platforms.linux; }; } </ins>

storm = callPackage ../servers/computing/storm { }; <ins> switcheroo-control = callPackage ../os-specific/linux/switcheroo-control { }; </ins> slurm = callPackage ../servers/computing/slurm { gtk2 = null; }; slurm-spank-x11 = callPackage ../servers/computing/slurm-spank-x11 { };
Change:
This is required for HEIF/HEIC support in eog work. Modules are trying to install to gdk-pixbuf prefix, (we are patching it in ) where it works. (That can be fixed using the pkg-config env var.) But the file is not generated/installed so the setup hook cannot pick it up. Originally posted by in
I marked this as stale due to inactivity. &rarr;
Does not look stale to me.
I marked this as stale due to inactivity. &rarr;
Still important to me.
I marked this as stale due to inactivity. &rarr;
will make this possible.

Discussion:
, wrapGAppsHook , librsvg , webp-pixbuf-loader <ins> , libheif </ins> , libexif , gobject-introspection , gi-docgen

extraLoaders = [ librsvg webp-pixbuf-loader <ins> libheif.out </ins> ]; }}" '';

, libpng , libjpeg , libaom <ins> , gdk-pixbuf </ins> # for passthru.tests , gimp

sha256 = "sha256-JwPeSNUc++z6RfMe0qAuXdekzLWR/MCmsT+Ykvp9a/s="; }; <del> nativeBuildInputs = [ autoreconfHook pkg-config ]; buildInputs = [ dav1d rav1e libde265 x265 libpng libjpeg libaom ]; </del> <ins> nativeBuildInputs = [ autoreconfHook pkg-config ]; buildInputs = [ dav1d rav1e libde265 x265 libpng libjpeg libaom gdk-pixbuf ]; </ins> enableParallelBuilding = true; <ins> # Fix installation path for gdk-pixbuf module PKG_CONFIG_GDK_PIXBUF_2_0_GDK_PIXBUF_MODULEDIR = "${placeholder "out"}/${gdk-pixbuf.moduleDir}"; </ins> passthru.tests = { inherit gimp imagemagick imlib2Full imv vips; };
Change:
Describe the bug The package for ZAProxy seems to be broken. It's at least missing Java in the path, but even after installing or separately it just starts up a grey screen with no errors to the console. To Reproduce Steps to reproduce the behavior: zap it simply as Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Later today I could try and copy how the adds JDK to . Also I could bump zap to 2.9.0 to see if that helps, but after that I'm not sure what to do?
I had a try to bump Zap to 2.9.0, but they transitioned their build system from to since the latest version present in . Not too familiar with that, I gave it a try anyway, using , but tadfisher/gradle2nix killed my progress...
Thanks for the heads up! I don't have a huge amount of time to work on this and I'm not too familiar with either, so I'll have to take a backseat on this one for the time being.
I marked this as stale due to inactivity. &rarr;

Discussion:
<del> { lib, stdenv, fetchFromGitHub, jdk8, ant, runtimeShell }: </del> <ins> { lib, stdenv, fetchurl, jre, runtimeShell }: </ins> <del> let jdk = jdk8; in </del> stdenv.mkDerivation rec { pname = "zap"; <del> version = "2.7.0"; src = fetchFromGitHub { owner = "zaproxy"; repo = "zaproxy"; rev =version; sha256 = "1bz4pgq66v6kxmgj99llacm1d85vj8z78jlgc2z9hv0ha5i57y32"; </del> <ins> version = "2.10.0"; src = fetchurl { url = "https://github.com/zaproxy/zaproxy/releases/download/v${version}/ZAP_${version}_Linux.tar.gz"; sha256 = "1mz9s56pbs62g4pnd1ml8y6jpf9ilisdwwvjv5kn6yxrcdi2zzqh"; </ins> }; <del> buildInputs = [ jdk ant ]; </del> <ins> buildInputs = [ jre ]; </ins> <del> buildPhase = '' cd build echo -n "${version}" > version.txt ant -f build.xml setup init  compile dist copy-source-to-build package-linux ''; </del> <ins> # From https://github.com/zaproxy/zaproxy/blob/master/zap/src/main/java/org/parosproxy/paros/Constant.java version_tag = "2010000"; # Copying config and adding version tag before first use to avoid permission # issues if zap tries to copy config on it's own. </ins> installPhase = '' <del> mkdir -p "$out/share" tar xvf  "ZAP_${version}_Linux.tar.gz" -C "$out/share/" mkdir -p "$out/bin" echo "#!${runtimeShell}" > "$out/bin/zap" echo "$out/share/ZAP_${version}/zap.sh" >> "$out/bin/zap" chmod +x "$out/bin/zap" </del> <ins> mkdir -p "$out/bin" "$out/share" cp -pR . "$out/share/${pname}/" cat >> "$out/bin/${pname}" << EOF #!${runtimeShell} export PATH="${lib.makeBinPath [ jre ]}:$PATH" export JAVA_HOME='${jre}' if ! [ -f "~/.ZAP/config.xml" ];then mkdir -p "$HOME/.ZAP" head -n 2 $out/share/${pname}/xml/config.xml > "$HOME/.ZAP/config.xml" echo "<version>${version_tag}</version>" >> "$HOME/.ZAP/config.xml" tail -n +3 $out/share/${pname}/xml/config.xml >> "$HOME/.ZAP/config.xml" fi exec "$out/share/${pname}/zap.sh"  "$@" EOF chmod u+x  "$out/bin/${pname}" </ins> ''; meta = with lib; {
Change:
Describe the bug The files shipped in the output of the library refer to invalid include paths. This prevents building software with the library if they trying finding it using cmake (instead of pkg-config). To Reproduce Steps to reproduce the behavior: to of the package (currently it's falling back on its vendored copy). the package. Expected behavior builds. Additional context In : The include directory is invalid, looking up in the default output. Notify maintainers cc Metadata system: host os: multi-user?: sandbox: version: channels(delroth): nixpkgs:
(Seems like a variant of -- cc as well)
The file seems to be generated here: Maybe it is a CMake bug? I do not understand CMake enough to be able to tell for sure.

Discussion:
stdenv.mkDerivation rec { pname = "fmt"; <del> version = "6.2.0"; </del> <ins> version = "6.2.1"; </ins> outputs = [ "out" "dev" ];

owner = "fmtlib"; repo = "fmt"; rev = version; <del> sha256 = "1vr08a8q94j66gas7ddbpdbq72b2ikd0mkgd5zd3l63610n8qajs"; </del> <ins> sha256 = "1i6nfxazq4d05r3sxyc3ziwkqq7s8rdbv9p16afv66aqmsbqqqic"; </ins> }; patches = [

url = "https://github.com/fmtlib/fmt/commit/78f041ab5b40a1145ba686aeb8013e8788b08cd2.patch"; sha256 = "hjE6Q/ubA4UhvuJXgcsA3wiGoDK031P19njQRL9JF8M="; }) <ins> # Fix cmake config paths. (fetchpatch { url = "https://github.com/fmtlib/fmt/pull/1702.patch"; sha256 = "18cadqi7nac37ymaz3ykxjqs46rvki396g6qkqwp4k00cmic23y3"; }) </ins> ]; nativeBuildInputs = [ cmake ];
Change:
Describe the bug The dbus service doesn't seem properly started when lightdm+i3 is used. To Reproduce Expected behavior Doing the same within an lightdm+i3 session results in: Notify maintainers /cc Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
In the session running lightdm+i3, I can see: In the session running Gnome, I can see:
Here is some info about the user's unit:
I don't know if it's helpful, but I also get this on SDDM+Plasma5. This on the other hand works:

Discussion:
${optionalString cfg.startDbusSession '' if test -z "$DBUS_SESSION_BUS_ADDRESS"; then <del> exec ${pkgs.dbus.dbus-launch} --exit-with-session "$0" "$@" </del> <ins> ${config.systemd.package}/bin/systemctl --user start dbus.socket </ins> fi ''}
Change:
Describe the bug In Nix configuration file, user’s specification of  will be overridden by the default rules. Default is specified in To Reproduce Steps to reproduce the behavior: any rule in . the rules by running Expected behavior In , the rules I define should be after the default rules. Screenshots I see that my rules are before the default rules, so it has lower precedence. Additional context I found this issue when installing from scratch. Notify maintainers No maintainer found. made which might be related. Metadata system: host os: multi-user?: sandbox: version: nixpkgs: Maintainer information:
I believe should fix your issue. In the interim, you can use on your list of , like so:

Discussion:
config = mkIf cfg.enable { <del> security.sudo.extraRules = [ </del> <ins> # We `mkOrder 600` so that the default rule shows up first, but there is # still enough room for a user to `mkBefore` it. security.sudo.extraRules = mkOrder 600 [ </ins> { groups = [ "wheel" ]; commands = [ { command = "ALL"; options = (if cfg.wheelNeedsPassword then [ "SETENV" ] else [ "NOPASSWD" "SETENV" ]); } ]; }
Change:
Describe the bug The installation of the package RclusTool freezes just after this message: To Reproduce Steps to reproduce the behavior: Additional context I am the main maintainer of this package. This issue may be related to the fact that our package requires a X server (issue already noticed with mac os X). I have some difficulties to build the package with Nixos.This may be related too : Metadata** Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): channels(hebert): nixpkgs:
I marked this as stale due to inactivity. &rarr;
I took a look at this and attached to the R process during the byte compilation. Looks like it's stuck in an infinite loop that continuously looks through the r-tcltk2 package files. Other packages that depend on tcltk2 (PDE) seem to work fine, so something specific to RclusTool is triggering this.
Yeah it was missing from the list of packages requiring X.
Thanks for your answer. I will think about giving another chance to Nixos. (I went back to Linux, because I couldn’t use R and its packages properly…) Regards, Pierre Hébert
No worries, you can always run Nix on top of your current distribution and see if R is suitable for your needs without installing NixOS. A healthy R ecosystem is very important to me as we use R heavily in my lab. Tag me in on any R related issues you might have and I'll do my best to resolve them.

Discussion:
"RandomFields" "rareNMtests" "rAverage" <ins> "RclusTool" </ins> "Rcmdr" "RcmdrPlugin_coin" "RcmdrPlugin_depthTools"
Change:
Describe the bug Ipykernel 5.2.1 (via ) introduced a test for UNC paths on windows which fail on darwin. To Reproduce Steps to reproduce the behavior: Expected behavior Build of ipykernel for python 3.7 to succeed. Logs Additional context Adding the test to solves this Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:

Discussion:
"test_subprocess_print" "test_subprocess_error" "test_ipython_start_kernel_no_userns" <ins> # https://github.com/ipython/ipykernel/issues/506 "test_unc_paths" </ins> ] ++ lib.optionals (pythonOlder "3.8") [ # flaky test https://github.com/ipython/ipykernel/issues/485 "test_shutdown"
Change:
Describe the bug The indicates a dependency on . However, this unit is not automatically included with the help of . It is therefore listed as : highlights this: Expected behavior Units that are relied upon should be found. Additional context Commit seems to something to do with it. Notify maintainers Metadata Please run and paste the result. Maintainer information:
This has last been touched in I see we set in if , so we could move there as well. After reading a bit on and , is this currently halfway broken? Maybe more of the logic should be moved into …
Can you see if fixes this for you? You might want to reboot, to make sure the mount isn't active. Also, do you use any binfmt stuff?
Yes, it fixes the problem: I do not think so. I am not familiar with binfmt.

Discussion:
mkdir -p -m 0755 /run/binfmt ${lib.concatStringsSep "n" (lib.mapAttrsToList activationSnippet config.boot.binfmt.registrations)} ''; <del> systemd.additionalUpstreamSystemUnits = lib.mkIf (config.boot.binfmt.registrations != {}) [ "proc-sys-fs-binfmt_misc.automount" "proc-sys-fs-binfmt_misc.mount" ]; </del> <ins> systemd.additionalUpstreamSystemUnits = lib.mkIf (config.boot.binfmt.registrations != {}) [ "proc-sys-fs-binfmt_misc.automount" "proc-sys-fs-binfmt_misc.mount" "systemd-binfmt.service" ]; </ins> }; }

"systemd-timedated.service" "systemd-localed.service" "systemd-hostnamed.service" <del> "systemd-binfmt.service" </del> "systemd-exit.service" "systemd-update-done.service" ] ++ optionals config.services.journald.enableHttpGateway [

systemd.targets.local-fs.unitConfig.X-StopOnReconfiguration = true; systemd.targets.remote-fs.unitConfig.X-StopOnReconfiguration = true; systemd.targets.network-online.wantedBy = [ "multi-user.target" ]; <del> systemd.services.systemd-binfmt.wants = [ "proc-sys-fs-binfmt_misc.mount" ]; </del> systemd.services.systemd-importd.environment = proxy_env; # Don't bother with certain units in containers.

syncthing-relay = handleTest ./syncthing-relay.nix {}; systemd = handleTest ./systemd.nix {}; systemd-analyze = handleTest ./systemd-analyze.nix {}; <ins> systemd-binfmt = handleTestOn ["x86_64-linux"] ./systemd-binfmt.nix {}; </ins> systemd-boot = handleTestOn ["x86_64-linux"] ./systemd-boot.nix {}; systemd-confinement = handleTest ./systemd-confinement.nix {}; systemd-timesyncd = handleTest ./systemd-timesyncd.nix {};

<ins> # Teach the kernel how to run armv7l and aarch64-linux binaries, # and run GNU Hello for these architectures. import ./make-test-python.nix ({ pkgs, ... }: { name = "systemd-binfmt"; machine = { boot.binfmt.emulatedSystems = [ "armv7l-linux" "aarch64-linux" ]; }; testScript = let helloArmv7l = pkgs.pkgsCross.armv7l-hf-multiplatform.hello; helloAarch64 = pkgs.pkgsCross.aarch64-multiplatform.hello; in '' machine.start() assert "world" in machine.succeed( "${helloArmv7l}/bin/hello" ) assert "world" in machine.succeed( "${helloAarch64}/bin/hello" ) ''; }) </ins>
Change:
Describe the bug SANE does not find the backend To Reproduce Steps to reproduce the behavior: backend to the error Expected behavior SANE loads the airscan backend. Screenshots Listing of symlinks to SANE-Backends: Additional context is missing the version suffix, so SANE does not use the library. The issue has been fixed on upstream master, but no new version has been released yet. Should we just update the package via commit-hash (it's still in early development anyhow), or wait for the next release for updating it? Using in my local nixpkgs fixes the problem. Notify maintainers Metadata Maintainer information:
I will quickly get in touch with the maintainer of to see if he can cut another release for us. It feels important enough to cut a bugfix release ;) thanks for taking the time for writing such a detailed explanation!

Discussion:
<del> { lib, stdenv, fetchFromGitHub, pkg-config, avahi, libsoup, libjpeg </del> <ins> { lib, stdenv, fetchFromGitHub, pkg-config, avahi, libsoup, libjpeg, libpng </ins> , sane-backends, meson, ninja }: stdenv.mkDerivation rec { pname = "sane-airscan"; <del> version = "0.9.17"; </del> <ins> version = "0.99.0"; </ins> nativeBuildInputs = [ meson ninja pkg-config ]; <del> buildInputs = [ avahi libsoup libjpeg sane-backends ]; </del> <ins> buildInputs = [ avahi libsoup libjpeg libpng sane-backends ]; </ins> src = fetchFromGitHub { owner = "alexpevzner"; repo = pname; rev = version; <del> sha256 = "03y0c1z5s3wbvxa9nvji62w42cmvcgm2sw72j7wm831995q3abmx"; </del> <ins> sha256 = "0bbw3s95v5fmkpmmd26v9cf1c40dm85bgxlhs06ski5my803ck0a"; </ins> }; meta = with lib; {
Change:
Describe the bug The desktop file packaged with VSCodium specifies the wrong StartupWMClass To Reproduce VSCodium on the started application Expected behavior Step 4 prints . Therefore step 5 should print one of those strings. But instead, the file contains . Additional context Those must match or else the application won't be linked to the .desktop file when started. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels: nixpkgs: Maintainer information:
I'm surprised says that the is . After all, for it seems to be , as , and as I also just tested on my system: After all, the executable for vscode is and for vscodium it's . Nevertheless, I can reproduce your output. Since I don't know whether that could be changed, it's probably easier to simply change the file. Will push a PR in a moment.
I wish I could assign myself to this issue.
I had a quick look at the history of the and they had it this way since the beginning. So I think it's safe to assume this won't change anytime soon.

Discussion:
executableName = "codium"; longName = "VSCodium"; <del> shortName = "Codium"; </del> <ins> shortName = "vscodium"; </ins> src = fetchurl { url = "https://github.com/VSCodium/vscodium/releases/download/${version}/VSCodium-${plat}-${version}.${archive_fmt}";
Change:
Project description Bombadillo is a non-web browser for the terminal. It supports several protocols, such as gopher, gemini, and finger. Metadata homepage URL: source URL: license: gpl3 platforms: unix, linux, darwin

Discussion:
<ins> { lib, fetchgit, buildGoModule }: buildGoModule rec { pname = "bombadillo"; version = "2.3.3"; src = fetchgit { url = "https://tildegit.org/sloum/bombadillo.git"; rev = version; sha256 = "02w6h44sxzmk3bkdidl8xla0i9rwwpdqljnvcbydx5kyixycmg0q"; }; vendorSha256 = "0sjjj9z1dhilhpc8pq4154czrb79z9cm044jvn75kxcjv6v5l2m5"; meta = with lib; { description = "Non-web client for the terminal, supporting Gopher, Gemini and more"; homepage = "https://bombadillo.colorfield.space/"; license = licenses.gpl3; maintainers = with maintainers; [ ehmry ]; }; } </ins>

blugon = callPackage ../applications/misc/blugon { }; <ins> bombadillo = callPackage ../applications/networking/browsers/bombadillo { }; </ins> bombono = callPackage ../applications/video/bombono {}; bomi = libsForQt5.callPackage ../applications/video/bomi {
Change:
Describe the bug On my system the nvidia card is . However the udev rules create and . To Reproduce system where nvidia is card1 nvidia system and try to use card (e.g. run nvidia-smi) Expected behavior is created Screenshots Additional context Add any other context about the problem here. Notify maintainers Metadata
That is the line, where the nvidiaX file is created. Ubuntu is calling nvidia-smi to create the node files But there is a pull request to stop doing it, because it is a workaround see
I marked this as stale due to inactivity. &rarr;
I think I might have just had this issue. I reset my bios settings and it took me a while to realize it had re-enabled the Intel iGPU, and the display manager was failing to show up. I didn't realize until I saw 2 nodes in /dev/dri. It was working some of the time, I think it could be due to random module loading order? I think could be a related issue too.
Thanks for the ping. On workstation with Nvidia cards (dual Xeon, dual Nvidia 1070s), I'm using the Nouveau driver, and have the following /dev entries: I'm not sure how to see what this looks like using the Nvidia driver, since it can't boot into a usable state.
I think you would have a 3rd render node if you had the Intel driver loading like I had, but maybe there is an issue in general with Nvidia and multiple GPUs.
might be related, too? (I may be wrong since I'm just starting to dig into this because I think I'm having a very similar problem with one GPU not being accessible after boot.)

Discussion:
services.udev.extraRules = '' # Create /dev/nvidia-uvm when the nvidia-uvm module is loaded. <del> KERNEL=="nvidia", RUN+="${pkgs.runtimeShell} -c 'mknod -m 666 /dev/nvidiactl c $$(grep nvidia-frontend /proc/devices | cut -d   -f 1) 255'" KERNEL=="nvidia_modeset", RUN+="${pkgs.runtimeShell} -c 'mknod -m 666 /dev/nvidia-modeset c $$(grep nvidia-frontend /proc/devices | cut -d   -f 1) 254'" KERNEL=="card*", SUBSYSTEM=="drm", DRIVERS=="nvidia", RUN+="${pkgs.runtimeShell} -c 'mknod -m 666 /dev/nvidia%n c $$(grep nvidia-frontend /proc/devices | cut -d   -f 1) %n'" </del> <ins> KERNEL=="nvidia", RUN+="${pkgs.runtimeShell} -c 'mknod -m 666 /dev/nvidiactl c 195 255'" KERNEL=="nvidia_modeset", RUN+="${pkgs.runtimeShell} -c 'mknod -m 666 /dev/nvidia-modeset c 195 254'" KERNEL=="card*", SUBSYSTEM=="drm", DRIVERS=="nvidia", PROGRAM="${pkgs.gnugrep}/bin/grep 'Device Minor:' /proc/driver/nvidia/gpus/%b/information",  RUN+="${pkgs.runtimeShell} -c 'mknod -m 666 /dev/nvidia%c{3} c 195 %c{3}" </ins> KERNEL=="nvidia_uvm", RUN+="${pkgs.runtimeShell} -c 'mknod -m 666 /dev/nvidia-uvm c $$(grep nvidia-uvm /proc/devices | cut -d   -f 1) 0'" <del> KERNEL=="nvidia_uvm", RUN+="${pkgs.runtimeShell} -c 'mknod -m 666 /dev/nvidia-uvm-tools c $$(grep nvidia-uvm /proc/devices | cut -d   -f 1) 0'" </del> <ins> KERNEL=="nvidia_uvm", RUN+="${pkgs.runtimeShell} -c 'mknod -m 666 /dev/nvidia-uvm-tools c $$(grep nvidia-uvm /proc/devices | cut -d   -f 1) 1'" </ins> '' + optionalString cfg.powerManagement.finegrained '' # Remove NVIDIA USB xHCI Host Controller devices, if present ACTION=="add", SUBSYSTEM=="pci", ATTR{vendor}=="0x10de", ATTR{class}=="0x0c0330", ATTR{remove}="1"
Change:
doesn't build with GHCJS as of due to an issue on and/or as suggested in It looks like this is related to
I'm trying to build again with at the moment, I'll report afterwards if it was successful.
Yep. Updating 's dependency on did the trick. Everything built just fine. See pull-request

Discussion:
ninka = callPackage ../development/tools/misc/ninka { }; <del> nodejs-0_12 = callPackage ../development/web/nodejs { libuv = libuvVersions.v1_2_0; }; </del> <ins> nodejs-0_12 = callPackage ../development/web/nodejs { libuv = libuvVersions.v1_6_1; }; </ins> nodejs-unstable = callPackage ../development/web/nodejs { libuv = libuvVersions.v1_2_0; unstableVersion = true; }; nodejs-0_10 = callPackage ../development/web/nodejs/v0_10.nix { };