Re: [Nix-dev] Current path to installing on Raspberry Pi?
Oh that makes sense. Might not be too hard to fix either. I'll try
when I get home tonight. Thanks!
On 1/23/15, Wout Mertens wout.mert...@gmail.com wrote:
those errors seem to come from a shell trying to interpret perl source...
On Mon Jan 12 2015 at 9:04:34 PM Jeff Johnson jef...@gmail.com wrote:
Hi all! I just tried to install NixOS on my Raspberry Pi following the
wiki page (https://nixos.org/wiki/Raspberry_Pi). I think I got pretty
close, but not quite all the way. I wrote the image to an sd card, booted
it up, logged in as root, changed the nix-channel from unstable to 13.10,
and tried to upgrade with:
nixos-rebuild switch --upgrade
It gave an error about needing at least nix 1.7 to parse the current nix
expressions. I found the latest build and installed it following the
directions on the wiki (
https://nixos.org/wiki/How_to_update_when_nix_is_too_old_to_evaluate_nixpkgs
):
nix-install-package --non-interactive --url
http://hydra.nixos.org/build/18524521/nix/pkg/nix-1.8-armv6l-linux.nixpkg
That appeared to work, but now when I rerun the upgrade command I get an
error from the perl interpreter:
[root@nixos:~]# nixos-rebuild switch --upgrade
/root/.nix-profile/bin/nix-channel: line 3: use: command not found
/root/.nix-profile/bin/nix-channel: line 4: use: command not found
/root/.nix-profile/bin/nix-channel: line 5: use: command not found
/root/.nix-profile/bin/nix-channel: line 6: syntax error near unexpected
token '('
/root/.nix-profile/bin/nix-channel: line 6: `use File::Path qw(mkpath);'
I tried moving /root/.nix-profile but the version in /nix/var/... that it
falls back on gives the same error. Do I need to manually find and
install
some dependencies?
Thanks
Jeff
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How to create dirs needed by a module before it runs?
Oh weird, maybe I need to go back and see if I did something wrong
with the hostname, because now that I think about it you're
right--they should all be evaluated at once. I think the
system.activationScripts are an exception though. They seem to run
after everything's evaluated (they print their installing messages
right after nix does setting up /etc... but before it starts systemd
units). Which is the sensible way to do it, you wouldn't want them to
run before nix knows the expressions are valid. I was mostly wondering
if there's a separate pre-nix-eval hook somewhere. I could see it
being useful for other things too, like checking that the nixpkgs repo
exists if you have your own or aborting if there's no network
connection.
Jeff
On 1/23/15, Wout Mertens wout.mert...@gmail.com wrote:
What do you mean with only get installed at the end?
Also, networking.hostName should work, the whole config gets evaluated at
once. There's no running in Nix, only side-effects of evaluation.
Wout.
On Fri Jan 23 2015 at 7:45:38 PM Jeff Johnson jef...@gmail.com wrote:
Hi all! I'm trying to set up tarsnap on nixos. This is my tarsnap.nix so
far:
config:
let
keySrc = ../rawpriv/tarsnap;
cacheDir = /var/cache/tarsnap;
rcSrc = builtins.toFile tarsnaprc ''
aggressive-networking # TODO is this a good idea?
humanize-numbers
'';
script = homeDir:
let
keyDst = ${homeDir}/tarsnap.key;
rcDst = ${homeDir}/.tarsnaprc;
in ''
echo installing ${keyDst} ; install -m400
${keySrc}/`hostname`.key ${keyDst}
echo installing ${rcDst} ; ln -fs ${rcSrc} ${rcDst}
echo installing ${cacheDir}; mkdir -p ${cacheDir}
'';
in {
system.activationScripts = { tarsnap = script /root; };
services.tarsnap = {
inherit config;
enable = true;
keyfile = keyDst;
cachedir = cacheDir;
};
}
It works except that the keyfile and cachedir only get installed at
the end, so nix complains that they don't exist unless I create them
manually first. Is there a way to make the script run earlier? And
another possibly-related question: is there a way to find out the
hostname? I can't just do `networking.hostName` because that's set in
the top-level config after this module runs. Do I just pass it as an
argument? Thanks
Jeff
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How to create dirs needed by a module before it runs?
In case there isn't a hook I just thought of the obvious solution:
wrap `nixos-rebuild` in a shell script.
On 1/23/15, Jeff Johnson jef...@gmail.com wrote:
Oh weird, maybe I need to go back and see if I did something wrong
with the hostname, because now that I think about it you're
right--they should all be evaluated at once. I think the
system.activationScripts are an exception though. They seem to run
after everything's evaluated (they print their installing messages
right after nix does setting up /etc... but before it starts systemd
units). Which is the sensible way to do it, you wouldn't want them to
run before nix knows the expressions are valid. I was mostly wondering
if there's a separate pre-nix-eval hook somewhere. I could see it
being useful for other things too, like checking that the nixpkgs repo
exists if you have your own or aborting if there's no network
connection.
Jeff
On 1/23/15, Wout Mertens wout.mert...@gmail.com wrote:
What do you mean with only get installed at the end?
Also, networking.hostName should work, the whole config gets evaluated
at
once. There's no running in Nix, only side-effects of evaluation.
Wout.
On Fri Jan 23 2015 at 7:45:38 PM Jeff Johnson jef...@gmail.com wrote:
Hi all! I'm trying to set up tarsnap on nixos. This is my tarsnap.nix so
far:
config:
let
keySrc = ../rawpriv/tarsnap;
cacheDir = /var/cache/tarsnap;
rcSrc = builtins.toFile tarsnaprc ''
aggressive-networking # TODO is this a good idea?
humanize-numbers
'';
script = homeDir:
let
keyDst = ${homeDir}/tarsnap.key;
rcDst = ${homeDir}/.tarsnaprc;
in ''
echo installing ${keyDst} ; install -m400
${keySrc}/`hostname`.key ${keyDst}
echo installing ${rcDst} ; ln -fs ${rcSrc} ${rcDst}
echo installing ${cacheDir}; mkdir -p ${cacheDir}
'';
in {
system.activationScripts = { tarsnap = script /root; };
services.tarsnap = {
inherit config;
enable = true;
keyfile = keyDst;
cachedir = cacheDir;
};
}
It works except that the keyfile and cachedir only get installed at
the end, so nix complains that they don't exist unless I create them
manually first. Is there a way to make the script run earlier? And
another possibly-related question: is there a way to find out the
hostname? I can't just do `networking.hostName` because that's set in
the top-level config after this module runs. Do I just pass it as an
argument? Thanks
Jeff
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] How to create dirs needed by a module before it runs?
Hi all! I'm trying to set up tarsnap on nixos. This is my tarsnap.nix so far:
config:
let
keySrc = ../rawpriv/tarsnap;
cacheDir = /var/cache/tarsnap;
rcSrc = builtins.toFile tarsnaprc ''
aggressive-networking # TODO is this a good idea?
humanize-numbers
'';
script = homeDir:
let
keyDst = ${homeDir}/tarsnap.key;
rcDst = ${homeDir}/.tarsnaprc;
in ''
echo installing ${keyDst} ; install -m400
${keySrc}/`hostname`.key ${keyDst}
echo installing ${rcDst} ; ln -fs ${rcSrc} ${rcDst}
echo installing ${cacheDir}; mkdir -p ${cacheDir}
'';
in {
system.activationScripts = { tarsnap = script /root; };
services.tarsnap = {
inherit config;
enable = true;
keyfile = keyDst;
cachedir = cacheDir;
};
}
It works except that the keyfile and cachedir only get installed at
the end, so nix complains that they don't exist unless I create them
manually first. Is there a way to make the script run earlier? And
another possibly-related question: is there a way to find out the
hostname? I can't just do `networking.hostName` because that's set in
the top-level config after this module runs. Do I just pass it as an
argument? Thanks
Jeff
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How to create dirs needed by a module before it runs?
What do you mean with only get installed at the end?
Also, networking.hostName should work, the whole config gets evaluated at
once. There's no running in Nix, only side-effects of evaluation.
Wout.
On Fri Jan 23 2015 at 7:45:38 PM Jeff Johnson jef...@gmail.com wrote:
Hi all! I'm trying to set up tarsnap on nixos. This is my tarsnap.nix so
far:
config:
let
keySrc = ../rawpriv/tarsnap;
cacheDir = /var/cache/tarsnap;
rcSrc = builtins.toFile tarsnaprc ''
aggressive-networking # TODO is this a good idea?
humanize-numbers
'';
script = homeDir:
let
keyDst = ${homeDir}/tarsnap.key;
rcDst = ${homeDir}/.tarsnaprc;
in ''
echo installing ${keyDst} ; install -m400
${keySrc}/`hostname`.key ${keyDst}
echo installing ${rcDst} ; ln -fs ${rcSrc} ${rcDst}
echo installing ${cacheDir}; mkdir -p ${cacheDir}
'';
in {
system.activationScripts = { tarsnap = script /root; };
services.tarsnap = {
inherit config;
enable = true;
keyfile = keyDst;
cachedir = cacheDir;
};
}
It works except that the keyfile and cachedir only get installed at
the end, so nix complains that they don't exist unless I create them
manually first. Is there a way to make the script run earlier? And
another possibly-related question: is there a way to find out the
hostname? I can't just do `networking.hostName` because that's set in
the top-level config after this module runs. Do I just pass it as an
argument? Thanks
Jeff
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How to create dirs needed by a module before it runs?
Why not cd into the modules directory and grep for mkdir? Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How to create dirs needed by a module before it runs?
That would work except the mkdir commands are evaluated using ${nixVars} so
the dirs aren't literally in there. I think I'm more comfortable adding
duplicated variables one by one in the shell script than trying to do any
magic.
Jeff
On Fri, Jan 23, 2015 at 11:49 AM, Marc Weber marco-owe...@gmx.de wrote:
Why not cd into the modules directory and grep for mkdir?
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] A Journey into the Haskell NG infrastructure: Part I
Hi Luke, How difficult would it be to track a different repository? Say, Stackage? Simply replace the current contents of defaultPackageOverrides in [1] with the choices from [2], run hackage2nix, and then you'll have a package set that corresponds to Stackage. Alternatively, we could add the Stackage package list to extraPackages [3] and create a pkgs/development/haskell-modules/configuration-stackage.nix file that overrides the default attributes with the ones from Stackage. I intend to make these package choices configurable instead of hard-coding them in the binary, but I haven't gotten around to it yet. Best regards, Peter [1] http://www.stackage.org/lts/cabal.config [2] https://github.com/NixOS/cabal2nix/blob/d28596b492ef4321a0bbf27de31820b6ae15f76f/src/hackage2nix.hs#L234-237 [3] https://github.com/NixOS/cabal2nix/blob/d28596b492ef4321a0bbf27de31820b6ae15f76f/src/hackage2nix.hs#L275-288 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] NixOS configuration unit tests
I'm thinking that it might be a good idea to have unit tests for the configuration.nix descriptions. That way we can be more sure that a change doesn't have unintended consequences. For example, we could have tests like if you set config.foo and config.bar, the evaluation should fail and if you set config.foo then config.baz should get a value. One specific use case is the license whitelisting/blacklisting ( https://github.com/NixOS/nixpkgs/pull/5892), where we don't ever want to inadvertently allow forbidden licenses. Any thoughts on how to implement this? An approach might be a shell script that runs a few nix-instantiate command lines and expects errors and values, but how would that integrate with the nixos tests? Wout. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Current path to installing on Raspberry Pi?
OK I'm a little lost. The shell is doing something weird, but I'm not sure
what. When I `_NIXOS_REBUILD_REEXEC=1 nixos-rebuild switch`, it says:
/run/current-system/sw/bin/nixos-rebuild: like 141:
/root/.nix-profile/bin/nix-instantiate: cannot execute binary file
building the system configuration...
/root/.nix-profile/bin/nix-build: line 3: user: command not found
... that repeats for each line up to 18 ...
If I try to run nix-instantiate directly it has the same cannot execute
binary file error, which means it's mistakenly being interpreted by bash
too right? I tried `perl $(which nixos-rebuild) switch`, but same error.
The other thing I tried is looking for older builds. Somebody reported
being able to upgrade to 13.10 in September, so if I take a build of nix
from then maybe it'll still work. But I can't find the armv6l ones listed
anywhere on the hydra site. Is it possible to find them without knowing the
hash URL already?
Jeff
On Fri, Jan 23, 2015 at 11:18 AM, Jeff Johnson jef...@gmail.com wrote:
Oh that makes sense. Might not be too hard to fix either. I'll try
when I get home tonight. Thanks!
On 1/23/15, Wout Mertens wout.mert...@gmail.com wrote:
those errors seem to come from a shell trying to interpret perl source...
On Mon Jan 12 2015 at 9:04:34 PM Jeff Johnson jef...@gmail.com wrote:
Hi all! I just tried to install NixOS on my Raspberry Pi following the
wiki page (https://nixos.org/wiki/Raspberry_Pi). I think I got pretty
close, but not quite all the way. I wrote the image to an sd card,
booted
it up, logged in as root, changed the nix-channel from unstable to
13.10,
and tried to upgrade with:
nixos-rebuild switch --upgrade
It gave an error about needing at least nix 1.7 to parse the current nix
expressions. I found the latest build and installed it following the
directions on the wiki (
https://nixos.org/wiki/How_to_update_when_nix_is_too_old_to_evaluate_nixpkgs
):
nix-install-package --non-interactive --url
http://hydra.nixos.org/build/18524521/nix/pkg/nix-1.8-armv6l-linux.nixpkg
That appeared to work, but now when I rerun the upgrade command I get an
error from the perl interpreter:
[root@nixos:~]# nixos-rebuild switch --upgrade
/root/.nix-profile/bin/nix-channel: line 3: use: command not found
/root/.nix-profile/bin/nix-channel: line 4: use: command not found
/root/.nix-profile/bin/nix-channel: line 5: use: command not found
/root/.nix-profile/bin/nix-channel: line 6: syntax error near unexpected
token '('
/root/.nix-profile/bin/nix-channel: line 6: `use File::Path qw(mkpath);'
I tried moving /root/.nix-profile but the version in /nix/var/... that
it
falls back on gives the same error. Do I need to manually find and
install
some dependencies?
Thanks
Jeff
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Pulseaudio broken in 14.12: Daemon already running
Pulseaudio stopped working for me after upgrading to 14.12. It seems that all PA clients start their own server, which eventually fails because the pulseaudio daemon is already running. For example, if I kill pulseaudio and then start it by hand with -vvv, I can see it start correctly and write its PID into a file. Then, if I run anything that needs to access pulse, like speaker-test, alsamixer, pavucontrol, etc., I can see in journalctl that another instance of pulseaudio is started and then dies with the error Daemon already running. The client usually dies with connection refused. I've turned off autospawning, and that doesn't change anything. Disabling pulseaudio and rebooting gives me sound again. Any idea why each client is trying to start their own pulseaudio daemon? -- Peter Jones, Founder, Devalot.com Defending the honor of good code ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Enable openntpd instead ntp by default
Hi William, Feel free to try enabling timesyncd by simply setting `services.timesyncd.enable` in your nixos config. It should work as a drop in replacement and respect the servers set in `services.ntp. servers`. I tried that on a system running the current unstable channel, but the service fails an assertion: https://github.com/NixOS/nixpkgs/issues/5913 Best regards, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Funding Hydra Development
On 01/22/2015 10:43 PM, Raahul Kumar wrote: bit-identical builds. How far are we from that point? Is it the timestamps that most build tools add to their build that prevents it? What's the blocker? We still don't even have fully reproducible stdenv, not even with all of https://github.com/NixOS/nixpkgs/pull/2281 . I have some further WIP on perl, but it ate many days of my time and still isn't fully deterministic. Timestamps are relatively easy to detect, as they always differ, but other things are more difficult: uname, build user name, etc. I think in most cases it just needs some work on *each* package to track it down, although you don't know if it's difficult until you try. Some impurity sources are already blocked generally in all builds. AFAIK only Haskell needs nontrivial changes upstream https://ghc.haskell.org/trac/ghc/ticket/4012 , but there might be more such problems hidden. (I even read about security research that introduces non-determinism into compiler output in a way that's supposed to make common exploits unusable on multiple outputs of the same compilation, so you supposedly wouldn't be able to attack many systems at once.) Vladimir smime.p7s Description: S/MIME Cryptographic Signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] [Haskell NG] Equivalent of the old eval $configurePhase eval $buildPhase eval $checkPhase ?
Peter Simons sim...@cryp.to writes: We could also add the runHook setupCompilerEnvironmentPhase ... bit to the nix-shell variable in the build environment so that these commands are run automatically when you enter the interactive environment. Does that sound useful? It does to me. John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] [Haskell NG] Equivalent of the old eval $configurePhase eval $buildPhase eval $checkPhase ?
On 01/23/2015 07:57 AM, Peter Simons wrote: Hi Mateusz, Does http://permalink.gmane.org/gmane.linux.distributions.nixos/15524 help? Yes though it seems that we now need to update two files when making any changes: default.nix so that we can callPackage it in overrides and such (for example if it's a private package) and shell.nix so that we can enter sane environment. I'm not sure what you mean. The number of files that you have to change to accomplish non-standard behavior should not be different from what it fwas before, i.e. the use of nix-shell certainly shouldn't have gotten more complicated than it was. Could you please elaborate a little how you've used nix-shell before and why that particular use-case won't now work anymore? Previously we could simply cabal2nix into default.nix and from shell.nix callPackage ./. in simple case or add any extra shell-only settings in there. Now it seems that if I add a dependency I need to regenerate both files which is not fun if we have written any customisation. Am I wrong? Previously, you generated a default.nix file with cabal2nix and ran that from a hand-written shell.nix file. Why do you think that this use-case is no longer possible? What exactly do you mean by re-generating both files? I merely meant that a ‘simple’ callPackage did not work (dependency problems) but Richard Wallace set it straight for me now: adding .env pretty much let's me use my old setup. So that part is solved. Another downside is that manual use of Setup won't inherit flags specified in the expression: we manually have to --enable-testsuite whereas eval $configurePhase would do that for use when doCheck = true;. It never occurred to me to configure interactive builds with the same flags Nixpkgs uses, because the default builder sets options that I wouldn't want (--prefix=$out) while leaving out flags that I would want (--ghc-option=-j). If you think this is important, then we can define a shell variable in the interactive environment, say $configureFlags, that you can pass to ./Setup or cabal during the configure phase. Would you like that? That sounds useful. Note that you can always use the old-style nix-shell approach and run the default builder, i.e.: $ cabal get haddock $ cd haddock-2.15.0.2 $ nix-shell --pure ~/.nix-defexpr -A haskellngPackages.haddock $ runHook setupCompilerEnvironmentPhase runHook jailbreakPhase runHook compileBuildDriverPhase $ eval $configurePhase eval $buildPhase eval $checkPhase We could also add the runHook setupCompilerEnvironmentPhase ... bit to the nix-shell variable in the build environment so that these commands are run automatically when you enter the interactive environment. Does that sound useful? This also sounds useful. I think this solves all my ‘problems’ for now. Thank you for all your work! I hope this helps, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NixOS configuration unit tests
On 23-01-2015 14:04:22, Wout Mertens wrote: I'm thinking that it might be a good idea to have unit tests for the configuration.nix descriptions. That way we can be more sure that a change doesn't have unintended consequences. Really good idea! For example, we could have tests like if you set config.foo and config.bar, the evaluation should fail and if you set config.foo then config.baz should get a value. One specific use case is the license whitelisting/blacklisting (https://github.com/NixOS/nixpkgs/pull/5892), where we don't ever want to inadvertently allow forbidden licenses. Any thoughts on how to implement this? An approach might be a shell script that runs a few nix-instantiate command lines and expects errors and values, but how would that integrate with the nixos tests? Wout. -- Mit freundlichen Grüßen, Kind regards, Matthias Beyer Proudly sent with mutt. Happily signed with gnupg. pgpmQGIPeWGWy.pgp Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NixOS configuration unit tests
Hi,
On 23/01/15 15:04, Wout Mertens wrote:
I'm thinking that it might be a good idea to have unit tests for the
configuration.nix descriptions. That way we can be more sure that a change
doesn't have unintended consequences.
For example, we could have tests like if you set config.foo and config.bar,
the
evaluation should fail and if you set config.foo then config.baz should get
a
value.
One specific use case is the license whitelisting/blacklisting
(https://github.com/NixOS/nixpkgs/pull/5892), where we don't ever want to
inadvertently allow forbidden licenses.
Any thoughts on how to implement this? An approach might be a shell script
that
runs a few nix-instantiate command lines and expects errors and values, but
how
would that integrate with the nixos tests?
Basically by adding a job like this to nixos/release.nix (not tested):
bla = runCommand bla
{ buildInputs = [ nix ];
src = ./..;
}
''
# Ugly hack to make read-only evaluation work.
export NIX_DB_DIR=$TMPDIR
export NIX_STATE_DIR=$TMPDIR
nix-store --init
echo '{ config.foo = true; config.bar = true; }' foo.nix
nix-instantiate --dry-run $src/nixos -A system \
-I nixos-configuration=$(pwd)/foo.nix
...
'';
and then add this job to tested in nixos/release-combined.nix to make the
NixOS channel depend on it.
--
Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
