Re: [Nix-dev] In multi-user Nix, let the daemon handle creation of GC roots

2017-06-19 Thread Adrien Devresse 
> Note, sharing /nix is already not really possible because the metadata
> is stored in sqlite and its locking does not play nice with nfs. (*)

Sharing is possible if you use a distributed file system that handle
consistency correctly, like GPFS, Lustre or similar.

We use Nix in shared model in production everyday in my organization.


> Another issue is that right now, nix does not /require/ the daemon to
> work, and this proposal would change that.

It is not really an issue. It could be done the same way it is done
currently. The client does the GC management if configured in single
user mode, or does it through the daemon if configure in multi user mode.

The strong point here is that only ONE user should write to /nix :
- Yourself in single user mode
- The nix-daemon in multi user mode.

This is not the case currently.

>
> The features that come to mind:
> - Allows later implementing policy about GC roots/space consumption
> - Allows avoiding complicated locking around doing GC
> - Allows /nix to be put on network storage transparently
> - Allows /nix to be shared between containers transparently
>
> The network-storage-/nix use case may be the most important, since there
> seems to be a lot of people who want to put /nix on NFS.
>
> Thoughts? Has this been considered?

I strongly support your idea.

The roots / profile implementation is currently hacky, not really
reliable, and potentially a security issue.


Regards,
Adev


Le 18. 06. 17 à 07:43, Wout Mertens a écrit :
>
> Note, sharing /nix is already not really possible because the metadata
> is stored in sqlite and its locking does not play nice with nfs. (*)
>
> Another issue is that right now, nix does not /require/ the daemon to
> work, and this proposal would change that.
>
> However, you can totally share /nix between multiple hosts, you just
> have to pinkie-promise not to write to it from multiple hosts at the
> same time.
>
> Wout.
>
> (*): the reason is that fnctl() locking is broken on many
> implementations. If this testing
> project https://sourceforge.net/projects/locktests/files/?source=navbar says
> it's not broken, you can totally use nix on nfs.
>
> On Sun, 18 Jun 2017, 5:10 AM ,  > wrote:
>
>
> My understanding is that currently GC roots (symlinks in
> profiles/gcroots) are created and deleted directly by the various Nix
> tools, even in multi-user configurations. (whether on NixOS or on
> another Linux distribution)
>
> It seems to me that it would be useful for the daemon to handle making
> GC roots, and forbid users to directly create GC roots.
>
> The features that come to mind:
> - Allows later implementing policy about GC roots/space consumption
> - Allows avoiding complicated locking around doing GC
> - Allows /nix to be put on network storage transparently
> - Allows /nix to be shared between containers transparently
>
> The network-storage-/nix use case may be the most important, since
> there
> seems to be a lot of people who want to put /nix on NFS.
>
> Thoughts? Has this been considered?
>
> Thanks for Nix!
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl 
> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>
>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> https://mailman.science.uu.nl/mailman/listinfo/nix-dev




signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

2017-03-21 Thread Adrien Devresse 
Le 21. 03. 17 à 16:56, William Casarin a écrit :
> Eelco Dolstra  writes:
>> On 03/19/2017 12:10 PM, Jan Malakhovski wrote:
>>> For eeePC try disabling hardening. Seriously. 
>> Hm, I wasn't aware hardening has a significant performance impact. Do you 
>> have
>> more info on that?
> I have a feeling in my case the performance issues are due to the fact
> there are simply more IO operations happening, and I was running off an
> SD card D:
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev

Yep I wanted to say that too :D

NixOS, contrary to arch and the other Linux distributions, does not use
ld cache, and consequently do significantly more "stat()" stress on the
file system each time it charges an executable with dynamic libraries.

In case of something like a python software, which load hundred shared
objects for its module resolution, and on machine with low-RAM / low-IO
, that can be very significant.


Adev





signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

2017-03-21 Thread Adrien Devresse 
Le 21. 03. 17 à 11:52, Alexey Shmalko a écrit :
> Eelco Dolstra  writes:
>
>> Hi,
>>
>> On 03/19/2017 12:10 PM, Jan Malakhovski wrote:
>>
>>> William Casarin  writes:
>>>
 I tried to run NixOS on my eeepc, it feels a lot more sluggish than when
 I used to run arch on it. I would love to see how this plays out, if
 only to have
 a smaller, lightweight version of NixOS to run on my pi's and eeepc.
>>> For eeePC try disabling hardening. Seriously. 
>> Hm, I wasn't aware hardening has a significant performance impact. Do you 
>> have
>> more info on that?
> Basically, most of hardening is inserting runtime checks into
> application. (e.g., inserting buffer overflow checks.) So it takes some
> additional CPU cycles to check.
>
> Some hardenings also insert additional values on stack (e.g., canaries),
> so application consumes more memory.
>
> I could say, on modern desktop computers the performance penalty is
> neglectable, but there are old hardware (where software is sluggish
> already), embedde devices, and various cases when "performance matters."

That also depend of the kind of hardening :

- _FORTIFY_SOURCE=2 is static and has, we can say, no impact.

- -fstrack-protector-strong has almost not impact on any modern machine
from Raspberry PI to modern laptop

- PIE can have an impact on some specific code ( with performance
critical sections with bad inlining )


However, all major Linux distributions without exceptions enable
"moderate" hardening by default for very good reasons, and all of them
can run on eeePC without issues.

If your aim is not to run NixOS on arduino, or little embedded MIPS or
RISC-V machines, it does not matter at all. If you want to run on this
can of machine, you know what you are doing and you know how to tune
your code anyway.


Regards,
Adev



signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

2017-03-18 Thread Adrien Devresse 

Note that NixOS FreeBSD/NetBSD is just SLNOS with a different kernel,
because we are gonna to be free from glibc and GNU tools.


I am sorry in advance for this comment.

But I can only get amused of seeing some GNU, Linux and systemD-haters 
spitting on C++ and software complexity on their main website 
(http://suckless.org/sucks/) and on the other side using Nix, the most 
complex package manager up to date, coded in C++, for their main 
packaging system.



Just for the troll : Do you also plan to redo also Nix entirely in C, 
like everything else, just for fun ?



Cheers,

Adev





Le 18/03/17 à 17:46, Jan Malakhovski a écrit :

Mayeu  writes:


I would love to see that in upstream, independence from systemd will open the 
door to have some kind of NixBSD and other fun stuff like that. (No longer than 
3 days ago there was a discussion for GSOC to have a project to make NixOS + 
freebsd).

Note that NixOS FreeBSD/NetBSD is just SLNOS with a different kernel,
because we are gonna to be free from glibc and GNU tools.


And besides, since I am following NixOS I have always heard that one of the 
long-term goal would be to abstract away from systemd.

Apparently not.


* Some of us want to drop GRUB in favor of running on top of minimal
  Xen payload on Coreboot firmware and isolate everything like in
  QubesOS, but we are not united on that point at this point. (Yes, we
  are aware of Heads:ROM, thank you, we are discussing all of this.)

Again, there are regular discussions in multiple space to have some kind of 
Qubes OS + Nix merge (or related) [1][2][3][4]. Note that Qubes uses SaltStack 
[5] to have some kind of declarative VM management. Nix would be a really nice 
improvement over that.

[1] Qubes OS ML: https://groups.google.com/forum/#!topic/qubes-devel/QDM2YNdWdXI 

[2] Harden(ed) NixOS issue reference Qubes multiple time: 
https://github.com/NixOS/nixpkgs/issues/7220 

[3] Package MirageOS for NixOS: https://github.com/NixOS/nixpkgs/issues/23955 

[4] Trying to run NixOS in a Qubes VM: https://github.com/NixOS/nixpkgs/issues/21402 

[5] Qubes OS SaltSack doc: https://www.qubes-os.org/doc/salt/ 


All of that would be awesome for NixOS :)

Yep, but someone needs to do all that work first :)

Cheers,
   Jan
___
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] Fosdem

2017-02-04 Thread Adrien Devresse 

Ok to meet up :)

name: adev


Le 04/02/17 à 01:09, Franz Pletz a écrit :

We will probably be hacking somewhere on the venue in between talks. Ping me on 
IRC if you want to meet up.


___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Fosdem

2017-02-01 Thread Adrien Devresse 
I will also be there

Adrien

Le 01. 02. 17 à 10:27, José San Leandro a écrit :
> Me too (+1)
>
> On Tue, Jan 31, 2017 at 9:55 AM, Théophane Hufschmitt
> > wrote:
>
> I'll be there too !
> With another nixer friend
>
> Quoting zimbatm (2017-01-31 09:16:22)
> > Count me in!
> >
> > On Mon, 30 Jan 2017, 21:56 Putten, A. van (Arian),
> >
> > wrote:
> >
> > > I will be there!
> > > --
> > > *From:* nix-dev-boun...@lists.science.uu.nl
>  [
> > > nix-dev-boun...@lists.science.uu.nl
> ] on behalf of Nathan
> Bijnens [
> > > nat...@nathan.gs ]
> > > *Sent:* Monday, January 30, 2017 9:35 PM
> > > *To:* Louis Taylor
> > > *Cc:* nix-dev
> > > *Subject:* Re: [Nix-dev] Fosdem
> > >
> > > I will be there on Saturday, mostly at the Big Data track.
> > >
> > > N.
> > >
> > > On Mon, Jan 30, 2017, 21:33 Louis Taylor  > wrote:
> > >
> > > On Mon, Jan 30, 2017 at 8:16 PM, Nathan Bijnens
> > wrote:
> > > > Anyone going to Fosdem?
> > >
> > > February just isn't right without a trip to Brussels!
> > >
> > > ___
> > > 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 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




signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] List of companies using NixOS

2016-12-09 Thread Adrien Devresse 
The Human Brain Project (https://www.humanbrainproject.eu/) and The Blue
Brain Project (http://bluebrain.epfl.ch/) uses NIX
in its HPC to deploy our softwares on all our Supercomputers and  our
HPC computing clusters.

This includes 3 of the most powerful machines in the TOP 500.

That allows us to have a high degree on tuning in our software stack, 
to get highly reproduisible scientific environments through all our
platforms, and to help to garantee we can reproduce our scientifics
results presented in our publications.

Regards,
Adrien

Le 08/12/2016 à 21:22, Vladimír Čunát a écrit :
> On 12/08/2016 02:06 PM, zimbatm wrote:
>> Thanks, added to the list.
>>
>> @vladimir: do you know what the Intel guys are using nix for? It would
>> be great to have them on the list.
> Verification of chip design.  NixCon recording:
> https://www.youtube.com/watch?v=eA-pvrGxciA=9=PL_IxoDz1Nq2Y7mIxMZ28mVtjRbbnlVdmy
>
>
>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev




signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] [y...@cock.li: Re: Malicious installation methods]

2016-06-17 Thread Adrien Devresse 
> I agree with this. A key that is trusted itself (rather then trusting a
> domain name) would be a very large security increase.

I agree too.

And this more or less the way taken by RPM / DPKG that ship their
trusted key on the client side when you install a new repository instead
of relying on any CA or PGP keyserver.


Adev



Le 17/06/2016 16:35, Kevin Cox a écrit :
> On 17/06/16 10:33, Yui Hirasawa wrote:
>>> Signing the installer script would provide only a minor increase in
>>> security (in that it would require the signing key to be compromised,
>>> rather than the nixos.org certificate). I don't object to doing that
>>> though.
>> That is quite a major increase in security actually. Compromising a key
>> that can be kept offline most of the time is a lot harder than obtaining
>> a signed certificate for the nixos.org domain. You do not have to have
>> the original nixos.org certificate to perform man-in-the-middle attack.
>>
> I agree with this. A key that is trusted itself (rather then trusting a
> domain name) would be a very large security increase.
>
>
>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev



signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Malicious installation methods

2016-06-17 Thread Adrien Devresse 
> So you're trusting a hash from the same site that you are downloading
> the script from? I can see a lot of value in a cryptographic signature
> (like PGP) but I see almost no value in a hash.
>
Briefly, yes.

This is already a security improvement.

Like already said before, detecting if a user run a curl-pipe-bash and
injecting a malicious binary on the fly is rather trivial to do compared
to compromise the nixos website itself, and create a phising to fake
both the tarball and the displayed hash.

However, I entirely agree with you that a cryptographic signature would
be the best way to go.

Cheers,
Adev


Le 17/06/2016 15:23, Kevin Cox a écrit :
> On 17/06/16 09:17, Adrien Devresse wrote:
>>> The installer, when run, will fetch more code for users to blindly execute 
>>> (as most of that code will be provided in compiled form). How is blindly 
>>> running an installer worse than running other code from the same provider?
>> Simply put the shasum of your installer on the website and ask the user
>> to verify. That is what many projets do, and it's a three lines of
>> installation instead of one.
>>
> So you're trusting a hash from the same site that you are downloading
> the script from? I can see a lot of value in a cryptographic signature
> (like PGP) but I see almost no value in a hash.
>
>




signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Malicious installation methods

2016-06-17 Thread Adrien Devresse 
> The installer, when run, will fetch more code for users to blindly execute 
> (as most of that code will be provided in compiled form). How is blindly 
> running an installer worse than running other code from the same provider?

Simply put the shasum of your installer on the website and ask the user
to verify. That is what many projets do, and it's a three lines of
installation instead of one.


>> PS. There are ways of detecthing when something is piped straight to an
>> interpreter and thus even if someone did curl and read the output and
>> then curled into a shell they could still get infected as serving
>> different pages depending on the circumstances isn't all that
>> difficult.
> This assumes https://nixos.org is already malicious - and then you shouldn't 
> run *anything* that comes from there.
>

The problem is not *ONLY* nixos.org.

Depending of your country and your environment, TLS / HTTPS alone is not
anymore a protocol that you can trust blindly
- https://blog.filippo.io/untrusting-an-intermediate-ca-on-os-x/
-
https://yro.slashdot.org/story/15/12/08/1451239/in-kazakhstan-the-internet-backdoors-you
- https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning



But without even considering that, "curl-pipe-bash" will cause your
sysadmin to blow a fuse or heartbreak in most companies / environments.
And for very good reasons.

Transforming this into a three lines installation script with a simple
"sha256sum -c " verification would not make users run away and would
make the project look more professional.


Adev






Le 17/06/2016 14:07, Tomasz Kontusz a écrit :
>
> Dnia 17 czerwca 2016 13:12:57 CEST, Yui Hirasawa  napisał(a):
>> I recently noticed that you recommend very malicious installation
>> methods on your download page for nix[1]
>>
>> Retrieving code straight from the internet and blindly executing is
>> never a good thing and you don't give any sort of recommendation for
>> the
>> user to inspect the script before running it. This completely defeats
>> the point of having reproducible builds when your system can be
>> completely infected when you install the package manager. This also
>> means that anything installed through the package manager is
>> potentially
>> malicious as well.
> The installer, when run, will fetch more code for users to blindly execute 
> (as most of that code will be provided in compiled form). How is blindly 
> running an installer worse than running other code from the same provider?
>
>>> $ curl https://nixos.org/nix/install | sh
>> And this isn't made any better by the fact that you want users to run
>> the script blindly as the superuser.
>>
>>> This script requires that you have sudo access to root,
> The installer needs elevated privileges to do it's job.
>
>> I ask you to PLEASE remove this installation method from the
>> recommendations on the page because it makes it look like you don't
>> care
>> about computer secuirty one bit.
> Now, that's an interesting point. Are there many people who never installed 
> nix because the installer is the recommended installation method?
>
>> PS. There are ways of detecthing when something is piped straight to an
>> interpreter and thus even if someone did curl and read the output and
>> then curled into a shell they could still get infected as serving
>> different pages depending on the circumstances isn't all that
>> difficult.
> This assumes https://nixos.org is already malicious - and then you shouldn't 
> run *anything* that comes from there.
>
>> [1]: https://nixos.org/nix/download.html
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev




signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] gitFetchPrivate on NixOS

2016-06-16 Thread Adrien Devresse 
Hi Ash,

I join to this mail the script I use to use gitFetchPrivate in a
multi-user configuration.

Have a look, you should be able to adapt it to your usage quite easily.

The trick is to give to the nix-daemon access to three things :
- rw access to your ssh-agent socket
- read access to your ssh config file
- the option that will request ssh to ignore the user read-only
permission on the config file.


Cheers,
Adrien

Le 16/06/2016 00:46, zimbatm a écrit :
> I believe you could run nix-prefetch-git to pre-populate the store but
> I don't know if it's still possible, the derivation might not match
> exactly anymore. Also it's only really useful for developer machines,
> on a CI you still want it to have access to the repo isn't it?
>
> On Wed, 15 Jun 2016 at 13:42 Ashley Gillman  > wrote:
>
> Thanks Zimbatm,
>
> Actually I don't think the issue is the socket (yet). For example,
> I get exactly the same error when just calling `nix-shell -I
> ssh-config-file=$HOME/.ssh/config`. The current "wall" I think is
> either that config file or the referenced id_rsa file, but the
> error indicates its the config file itself. I have tried `chmod
> o+rw` on the file, and with group (`chmod g+rw` and `chgrp`ing to
> nixbld), but to no avail.
>
> I should mention also, I do not have my heart set on
> gitFetchPrivate. If there is another way to access a remote
> (BitBucket) server requiring credentials, that would be great.
> Although pulling each manually and using a local file path is not
> preferred.
>
> Cheers,
> Ash
>
> On Wed, Jun 15, 2016 at 10:07 PM, zimbatm  > wrote:
>
> Hi,
>
> Yes the difference is that the build user is nixbld[1-9]. Also
> the SSH agent doesn't allow other users to access to the socket.
>
> Sorry I don't know the solution. You could maybe build a
> bridge on the socket using `socat` to hide the caller's user.
>
>
> On Wed, 15 Jun 2016, 11:57 Ashely Gillman,
> > wrote:
>
> Hi all,
> I have been attempting to use gitFetchPrivate to fetch
> from a private bitbucket repo over SSH, on both Ubuntu
> running Nix and on NixOS. I am able to get the setup
> working on Ubuntu.
>
> - Set up SSH-Agent the usual way.
> - Ensure that `git clone ssh://g...@bitbucket.domain.com
> ://.git` 
> works,
> it does
> - Use `nix-shell -I ssh-config-file=$HOME/.ssh/config -I
> ssh-auth-sock=$SSH_AUTH_SOCK`, with a local shell.nix
> specifying requirements
>
> However, I am unable to repeat the process on a NixOS machine.
>
> gil@gil-nixos:~/proj/pylx $ git clone
> ssh://git@bitbucket.:7999/~/milx-view.git
> 
>
> gil@gil-nixos:~/proj/pylx $ nix-shell -I
> ssh-config-file=$HOME/.ssh/config -I
> ssh-auth-sock=$SSH_AUTH_SOCK
> these derivations will be built:
>  
> /nix/store/48cz61di3gf6fpkydgri74h5i2s8qh3h-vtk-qvtk-5.10.1.drv
>  
> /nix/store/pcj22pnchg10bq63a32jcc53l75cy8z1-boost-1.59.0.drv
>  
> /nix/store/sb7xc3pan2h7n1qdh94ynblb9cv12a3p-milx-view-585a819.drv
>  
> /nix/store/dzh8jzl90ghsl0l71p9v2zqzh9wn2ngb-milx-view.drv
> building path(s)
> ‘/nix/store/603gs7mcgpf7cnyv3k2bkxk1kbj4smbq-boost-1.59.0’, 
> ‘/nix/store/q26zzdzy5zngyxyah8fhqmnqwbmz4gl4-boost-1.59.0-lib’,
> ‘/nix/store/zggqsmrh9l70yrcdagmgqjmv8i6a9rls-boost-1.59.0-dev’
> building path(s)
> ‘/nix/store/ra27851hlszq1k0n9zfa14xwhxqvn8zs-milx-view-585a819’
> building path(s)
> ‘/nix/store/j70pal3svpcip7xv21bxf5xy2c4chl84-vtk-qvtk-5.10.1’
> exporting
> ssh://git@bitbucket.:7999/~/milx-view.git
> (rev 585a8195804) into
> /nix/store/ra27851hlszq1k0n9zfa14xwhxqvn8zs-milx-view-585a819
> Initialized empty Git repository in
> 
> /nix/store/ra27851hlszq1k0n9zfa14xwhxqvn8zs-milx-view-585a819/.git/
> Can't open user config file /home/gil/.ssh/config:
> Permission denied
> fatal: Could not read from remote repository.
>
> Please make sure you have the correct access rights
> and the repository exists.
> unpacking sources
> unpacking source archive
> /nix/store/cdz3wd9r8vlnp193kv091pal401mg9kc-boost_1_59_0.tar.bz2
> Can't open user config file /home/gil/.ssh/config:
> Permission

[Nix-commits] [NixOS/nixpkgs] d7749f: bup: add ${git} to the $PATH of the wrapper

2016-05-27 Thread Adrien Devresse 
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: d7749f27f3df976be82eef36f2dbc4b13de5ad9d
  
https://github.com/NixOS/nixpkgs/commit/d7749f27f3df976be82eef36f2dbc4b13de5ad9d
  Author: Florent Becker <florent.bec...@ens-lyon.org>
  Date:   2016-05-28 (Sat, 28 May 2016)

  Changed paths:
M pkgs/tools/backup/bup/default.nix

  Log Message:
  ---
  bup: add ${git} to the $PATH of the wrapper

Otherwise, bup tries to run git from the user's PATH, which may or may not
exist.

Closes #15691


  Commit: b6193dbac7961a412c106932f6af5a07e875fc1b
  
https://github.com/NixOS/nixpkgs/commit/b6193dbac7961a412c106932f6af5a07e875fc1b
  Author: Adrien Devresse <adrien.devre...@epfl.ch>
  Date:   2016-05-28 (Sat, 28 May 2016)

  Changed paths:
M pkgs/servers/computing/slurm/default.nix

  Log Message:
  ---
  slurm-llnl: improvements

- add support for numa and hwloc
- add support for lua scripting module
- make slurm compatible with system configuration by default, in case of  Nix 
used
  as a side package manager (tested on redhat)
- strip the libtool generated files

Closes #15673


Compare: https://github.com/NixOS/nixpkgs/compare/89aab4f3516e...b6193dbac796___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

Re: [Nix-dev] How to use binaries from other hosts?

2016-03-14 Thread Adrien Devresse 
> I tried _everything_. I cannot nix-copy-closure, as this one does not allow me
> to set the SSH port (which isn't 22 but something above 1).

You can define any host / port matching through the configuration file
"~/.ssh/config" for any program using SSH.

Something like

""
Host [youHost]
port 1

"""

should do the trick

Adrien


Le 14/03/2016 10:07, Matthias Beyer a écrit :
> Hi,
>
> I'm on nixos unstable. As racket does not build and my thinkpad takes hours to
> build it, I got myself a debian VM in my university cloud and compiled racket
> there.
>
> How can I retrieve the closure from there?
>
> I tried _everything_. I cannot nix-copy-closure, as this one does not allow me
> to set the SSH port (which isn't 22 but something above 1).
>
> I tried to nix-store --export, copy via SCP and then nix-store --import, but 
> it
> fails as the closure is not signed...
>
> Can someone please help me with this?
>
> I normally install racket with a nix-shell for my blog environment. I guess I
> should make this shell env persistent to be save of GC, though I cannot find
> documentation on how to _remove_ a persistent shell env... and I want to know
> how to remove it, before making it permanent.
>
>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev



signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] --ftls-model=global-dynamic for every lib?

2016-02-28 Thread Adrien Devresse 
Thx Domen, this is exactly what I was looking for.




Le 28/02/2016 11:33, Domen Kožar a écrit :
> See 
> https://github.com/NixOS/nixpkgs/pull/12895/files#diff-8ac87a75c3dd650a7f760fa3b2d041bfR239
>
> On Sun, Feb 28, 2016 at 10:31 AM, Adrien Devresse <a...@adev.name
> <mailto:a...@adev.name>> wrote:
>
> To generalize a bit on this.
>
> Most of the Linux distributions have a mandatory default set of flags
> for all libraries / binaries that are enforced through "configure /
> cmake" macros ( -fPIC is part of them ). They do this for very good
> reasons: security, protability, compatibility.
>
> It would be good to have a bit of documentation on how to handle
> this in
> NixOS.
>
>
> Adev~~
>
> Le 28/02/2016 01:31, stewart mackenzie a écrit :
> > Just to clarify the correct argument passed to gcc or clang
> should be -fpic .
> > ___
> > nix-dev mailing list
> > nix-dev@lists.science.uu.nl <mailto: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 <mailto:nix-dev@lists.science.uu.nl>
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>



signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] --ftls-model=global-dynamic for every lib?

2016-02-28 Thread Adrien Devresse 
To generalize a bit on this.

Most of the Linux distributions have a mandatory default set of flags
for all libraries / binaries that are enforced through "configure /
cmake" macros ( -fPIC is part of them ). They do this for very good
reasons: security, protability, compatibility.

It would be good to have a bit of documentation on how to handle this in
NixOS.


Adev~~

Le 28/02/2016 01:31, stewart mackenzie a écrit :
> Just to clarify the correct argument passed to gcc or clang should be -fpic .
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev




signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] On nixpkgs and reasonable code size

2016-02-24 Thread Adrien Devresse 
> I'm totally for that, but do note that there is an equivalent problem
> in deciding who gets "PR approval" access. But, I suppose since we
> control hydra/whatever and not github, we can roll our own logic like
> allowing people to only approve PRs for automatic merging that affect
> certain files / subtrees.

Exactly.

This is more or less what Fedora does through there fedpkg and pkgdb
interface. Fedora maintainers can merge / modify only the packages they
are associated with.

You could easily transpose this to NixOS with something like :

* Nobody has right to push master
* The maintainer of a package can merge all incoming "hydra-built" pull
requests associated with this package and nothing more.
* New packages are reviewed and merged by a list of senior Nix-devs /
maintainers for safety.

And that's it.

Again, this is nothing new. All others major distributions have a
similar workflow.

I'm convinced that the problem is more about "Who does what" than
anything else, specially when I see how active the Nix community is.


Adev


Le 23/02/2016 17:13, Ericson, John a écrit :
> And now this leads into my thread
> https://www.mail-archive.com/nix-dev@lists.science.uu.nl/msg18287.html
> :).
>
> I'm totally for that, but do note that there is an equivalent problem
> in deciding who gets "PR approval" access. But, I suppose since we
> control hydra/whatever and not github, we can roll our own logic like
> allowing people to only approve PRs for automatic merging that affect
> certain files / subtrees.
>
> On Tue, Feb 23, 2016 at 7:12 AM, Matthias Beyer  wrote:
>> On 23-02-2016 16:08:37, Matthias Beyer wrote:
>>> On 21-02-2016 15:28:08, Bjørn Forsman wrote:
 On 21 February 2016 at 15:17, zimbatm  wrote:
> tl,td; I think that we should split nixpkgs/pkgs in two
 Another way to do it is the Linux kernel way. Instead of splitting the
 (git) repository in two (or more) pieces, split _maintenance
 responsibility_ into a hierarchy. This is opposite to the flat
 responsibility model NixOS development use today.
>>> I completely second this. The problem is IMHO _not_ that the repo gets big
>>> (there are other repos which are way, way bigger than nixpkgs) but the
>>> development model. AFAIK I said that before on this list. The problem is 
>>> that
>>> everyone who wants to be a contributer gets push access to master. It just
>>> screams at you "I won't scale"!
>>>
>> Let me add: In my opinion, nobody should be able to push to master. Merging 
>> into
>> master should be done either automatically (by a build-bot or something like
>> this) or by a "merge this PR"-click in github, after some checks are 
>> succeeded
>> (something like CI or lgtm.co (not proposing tools here but functionality)).
>>
>>
>> --
>> Mit freundlichen Grüßen,
>> Kind regards,
>> Matthias Beyer
>>
>> Proudly sent with mutt.
>> Happily signed with gnupg.
>>
>> ___
>> 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




signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] On nixpkgs and reasonable code size

2016-02-22 Thread Adrien Devresse 
> I think the inflow of PRs *is* high wrt. the number of active
> contributors with push access. Certainly too much to keep quality very
> high all the time, but on the other hand, for those less important
> packages it's not a big deal...

The way the other distributions solved this issue is by distributing the
responsabilities. A model where a little minority has to approve /
validate the merge each package modification can not scale to a huge
number of packages.

If you look at the Fedora/Debian model, each package maintainer is
responsible and has full commit access on their packages and only on
their packages.  They do not need any merge,  excepted when they
stabilize the unstable branch. This is quite similar to the way the
Linux kernel development works in this respect.


Adev~~


Le 21/02/2016 21:39, Vladimír Čunát a écrit :
> On 02/21/2016 09:10 PM, Patrick Callahan wrote:
>> Does anyone here know what other distros do to engage more
>> developers+maintainers? Could we, among other things, organize some kind
>> of drive to encourage more systematic contributions? Or is integrating
>> all the current PRs too much work already for that to be helpful?
> Well, I think the number of contributors grows fast enough since we
> migrated to github:
> https://www.openhub.net/p/nixos/contributors/summary
>
> I think the inflow of PRs *is* high wrt. the number of active
> contributors with push access. Certainly too much to keep quality very
> high all the time, but on the other hand, for those less important
> packages it's not a big deal...
>
> --Vladimir
>
>
>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev



signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Debugging Symbols

2016-02-15 Thread Adrien Devresse 

+1 to this proposal.

The current solution to recompile with a nix function is far to be a 
perfect solution:


- It happens often that recompiling with debug flags change the behavior 
of the progrm itself and make the crash/problem impossible to reproduce 
with debinfos.


- It is a pain when a crash happen in a low level library ( e.g libc ) 
and that half of the stack has to be recompiled just to get some debug 
informations.


Having an additional output with the deb symbols per derivation would be 
similar to the others packaging system (RPM, Deb) approach ( *-dbg.deb, 
*-debuginfo.rpm ).



Adev



Le 15/02/16 16:00, Kevin Cox a écrit :

On Mon, 2016-02-15 at 15:50 +0100, Luca Bruno wrote:
+1, with the multi outputs branch [1] it makes a lot of sense to ship 
an additional output for debug symbols, instead of rebuilding the 
program using Nix functions [2]


[1] https://github.com/NixOS/nixpkgs/pull/7701
[2] https://github.com/NixOS/nixpkgs/blob/master/pkgs/misc/misc.nix#L113


Definitely! Having the debug function would still be useful because 
debugging optimized programs is often difficult but the symbols 
version can go away because all programs would have symbols already.



___
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] Providing Debian, Arch etc. packages counterproductive?

2015-09-23 Thread Adrien Devresse 
An other point to consider is the integration aspect.

Nix requires a system install in a shared environment. The daemon needs
to be setup properly, group created, etc
In most companies, the sysadmin will simply refuse to install on any
existing  shared system anything which is not packaged properly, and for
very good reasons.

Not providing platform specific packages will very likely slow down the
adoption of Nix in professional environment for such reasons.
I agree the platform specific packages have their own issues, but from
an administration point of view, they are needed.


Adrien



Le 23/09/2015 00:50, Thomas Hunger a écrit :
> The deb can be inspected with "dpkg -c". It contains all the nix-*
> commands, man pages, some perl, headers and some basic nix library
> functions. What's missing is a postinst script that setting up the
> things according to [1] (probably needs updating).
>
> On reflection platform specific packages would be useful to work
> around issues like [2] which one of my friends hit today. And as
> Vladimir says for the multi-user setup with the daemon. I'm not sure I
> have the energy to go around and fix all the packages but maybe debian
> and arch would be a good start.
>
> ~
>
> [1]
> https://nixos.org/wiki/Installing_Nix_on_Debian
>
> [2]
> https://github.com/NixOS/nix/issues/599
>
>
> On 22 September 2015 at 22:31, Vladimír Čunát  > wrote:
>
> On 09/22/2015 10:03 PM, zimbatm wrote:
> > On the other end, it would be nice if installing nix was just a
> > matter of running `curl -L
> > https://nixos.org/nix-current/$(uname)-$(arch).tar.bz2
>  |
> tar xa -C
> > /nix && ln -s /nix/bin/nix-env /usr/local/bin` and then setup the
> > profile.
>
> I think the nix daemon complicates things a bit, as you need to
> plug it
> into the host OS services.
>
> Vladimir
>
>
> ___
> 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



signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Impossible to use Nix + fetchgit on any Linux configured with LDAP authentication /libnss_sss

2015-06-23 Thread Adrien Devresse 
 Ideally, libnss_sss should be part of stdenv.
 That's not going to happen because there are any number of NSS modules that we
 can't possibly all add to stdenv.


Indeed, I was not thinking about making it part of stdenv by default.

What about  enrich stdenv ( through config.nix or configuration.nix)
on some specific platforms without triggering a full recompilation ?


 Yes, by using nscd.

It is not a solution. Red Hat itself documents  to not use nscd and sssd
together

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/usingnscd-sssd.html

sssd is very likely going to be the new norm for ldap authentication (
for good reasons ) .

Make it supported into Nix by wrapping old daemons around is probably
not a very good long term solution.

 If possible, you could also enable chroot builds. It might be possible to
 override /etc/nsswitch.conf in the chroot by setting the Nix option
 build-chroot-dirs = /etc/nsswitch.conf=/path/to/my-nsswitch.conf (where
 my-nsswitch.conf doesn't contain libnss_nss). However, looking at the code, it
 may not be possible to override /etc/nsswitch.conf at the moment, but fixing
 that wouldn't be hard.

Would this work as a non-root user ?
If the current user is an LDAP-referenced user, this will cause a
failure too even if sss is not configured through /etc/nsswitch.conf


 As a hack, it might also be possible to add LD_LIBRARY_PATH to the 
 impureEnvVars
 attribute of fetchgit and other affected fixed-output derivations. 
 (Fixed-output
 derivations are allowed to have some impure inputs because their output is
 guaranteed to be the same regardless of the inputs.) So you could pass in an
 LD_LIBRARY_PATH pointing to a directory containing the required NSS modules.

That's would make it for git.
But like I said, the problem is not limited to git.

For instance, all core-utils derivations would still fail.

core-util check phase run some tests related to user-right command line
tools ... and naturally, these tests need libnss_sss to succeed too...

Any other derivation that use user/passwd/group syscall triggers the
error too.


Adrien



Le 23/06/2015 12:48, Eelco Dolstra a écrit :
 Hi,

 On 23/06/15 11:47, Adrien Devresse wrote:

 Ideally, libnss_sss should be part of stdenv.
 That's not going to happen because there are any number of NSS modules that we
 can't possibly all add to stdenv.

 Do you have any elegant way in Nix to add a module / modify the stdenv
 without retriggering a compilation of the entire system ?
 Yes, by using nscd.

 If possible, you could also enable chroot builds. It might be possible to
 override /etc/nsswitch.conf in the chroot by setting the Nix option
 build-chroot-dirs = /etc/nsswitch.conf=/path/to/my-nsswitch.conf (where
 my-nsswitch.conf doesn't contain libnss_nss). However, looking at the code, it
 may not be possible to override /etc/nsswitch.conf at the moment, but fixing
 that wouldn't be hard.

 As a hack, it might also be possible to add LD_LIBRARY_PATH to the 
 impureEnvVars
 attribute of fetchgit and other affected fixed-output derivations. 
 (Fixed-output
 derivations are allowed to have some impure inputs because their output is
 guaranteed to be the same regardless of the inputs.) So you could pass in an
 LD_LIBRARY_PATH pointing to a directory containing the required NSS modules.





signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Impossible to use Nix + fetchgit on any Linux configured with LDAP authentication /libnss_sss

2015-06-23 Thread Adrien Devresse 
 Would this work as a non-root user ?
 No, you need to be root to do chroot builds.


This is unfortunately a problem: Nix is advertised to work in non-root
environment and is used as this.

You have common situations where root access is just not possible.

A Linux cluster configured with LDAP ( libnss_sss ) is one of the most
common type of shared / non-root environment existing around.
Almost all scientific or academic organizations in this world have one
and All HPC centers are in this situation too.

Solving this issue by enforcing chroot for any Nix build is like
forbidding any usage of Nix in these environments.


Would it not  be possible to create a wrapper that map any host
libnss-* plugin  into the stdenv build path ? That would allow to use
any kind of exotic nss/pam auth configured on the host transparently.

It is an impure solution but a solution that would fix this kind of
issue definitively.


Adrien




Le 23/06/2015 15:38, Eelco Dolstra a écrit :
 Hi,

 On 23/06/15 14:50, Adrien Devresse wrote:

 If possible, you could also enable chroot builds. It might be possible to
 override /etc/nsswitch.conf in the chroot by setting the Nix option
 build-chroot-dirs = /etc/nsswitch.conf=/path/to/my-nsswitch.conf (where
 my-nsswitch.conf doesn't contain libnss_nss). However, looking at the code, 
 it
 may not be possible to override /etc/nsswitch.conf at the moment, but fixing
 that wouldn't be hard.
 Would this work as a non-root user ?
 No, you need to be root to do chroot builds.

 If the current user is an LDAP-referenced user, this will cause a
 failure too even if sss is not configured through /etc/nsswitch.conf
 The user inside the chroot is always called nixbld and has an entry in the
 chroot's /etc/passwd file, so looking up that user would not require LDAP 
 lookups.





signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Impossible to use Nix + fetchgit on any Linux configured with LDAP authentication /libnss_sss

2015-06-23 Thread Adrien Devresse 
(back on this problem)

 Ah, sorry, I'm not really familiar with nss. Does the libnss_sss
 version have to match what's installed system-wide, rather than e.g.
 being a build input?
I would say no.
It need to be verified but it is very likely that any libnss_sss version
able to connect on the sss unix socket would be ok.


Ideally, libnss_sss should be part of stdenv.
Without it, some syscall like getpwuid would simply do not work.

Making it a build-input of git would just provide a workaround for git
only... any other apps using a group/shadow related function (getpwuid,
getpwnam, etc.. ) would trigger the bug again.

However, making it part of stdenv would trigger a recompilation of the
integrality of the packages

Do you have any elegant way in Nix to add a module / modify the stdenv
without retriggering a compilation of the entire system ?


Adrien




Le 07/06/2015 02:15, James Cook a écrit :
 Ah, sorry, I'm not really familiar with nss. Does the libnss_sss
 version have to match what's installed system-wide, rather than e.g.
 being a build input?

 Also, doesn't fetchgit produce fixed-output derivations*, meaning
 purity depends only on the sh256 hash of the output matching, and not
 on how the output was produced?

 James

 *Not sure if it's really fixed-output when leaveDotGit = true.


 On 6 June 2015 at 14:38, Adrien Devresse a...@adev.name wrote:
 I would say, it does not solve the problem.

 If adding the system libnss_sss path to the LD_LIBRARY_PATH can be an
 acceptable solution for firefox, I think it is not for fetchgit/git.
 Adding libnss_sss to the LD_PATH as requirement for any invocation of
 igt would make any build using fetchgit impure.

 Adrien



 Le 06/06/2015 22:16, James Cook a écrit :
 e get re-opened? Was that never implemented, or does it not
 solve the problem?

 James





signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Impossible to use Nix + fetchgit on any Linux configured with LDAP authentication /libnss_sss

2015-06-06 Thread Adrien Devresse 
I would say, it does not solve the problem.

If adding the system libnss_sss path to the LD_LIBRARY_PATH can be an
acceptable solution for firefox, I think it is not for fetchgit/git.
Adding libnss_sss to the LD_PATH as requirement for any invocation of
igt would make any build using fetchgit impure.

Adrien



Le 06/06/2015 22:16, James Cook a écrit :
 e get re-opened? Was that never implemented, or does it not
 solve the problem?

 James




signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Impossible to use Nix + fetchgit on any Linux configured with LDAP authentication /libnss_sss

2015-06-05 Thread Adrien Devresse 
Hi Eleco,

Thank you for your reply.

Here is the nsswitch.conf

http://pastebin.com/bErcjfkk

I am currently evaluating Nix for software deployment in a quite large
scientific collaboration. Some sites are configured with sss and not
under control unfortunatly.


Adrien


Le 05/06/2015 12:58, Eelco Dolstra a écrit :
 Hi,

 On 05/06/15 00:10, Adrien Devresse wrote:

 I triggered this failure (http://pastebin.com/Lw6a0p4J) while trying to
 use nix on a RHEL 6.5 configuration setup with ldap authentication (
 sssd + libnss_sss ).

 After a bit of research, this is due to the dependency of git on
 getpwuid and to the fact that the nix glibc do not have by default
 libnss_sss nor can use the one of the host operating system.
 Doesn't RHEL 6.5 use nscd? When nscd is enabled, the Nix glibc will use it 
 to
 perform lookups, so it won't need to be able to find libnss_sss on its own.

 Can you show the contents of /etc/nsswitch.conf?





signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Impossible to use Nix + fetchgit on any Linux configured with LDAP authentication /libnss_sss

2015-06-04 Thread Adrien Devresse 
Hi,

I triggered this failure (http://pastebin.com/Lw6a0p4J) while trying to
use nix on a RHEL 6.5 configuration setup with ldap authentication (
sssd + libnss_sss ).

After a bit of research, this is due to the dependency of git on
getpwuid and to the fact that the nix glibc do not have by default
libnss_sss nor can use the one of the host operating system.


The problem has already been reported in case of firefox (
https://github.com/NixOS/nix/issues/209 ).

However, it is way more harmful in case of git/fetchgit : it makes
impossible to compile any expression using fetchgit on a host using
sssd, which is a configuration unfortunatly quite common in the academic
world .

What would be the best solution of this problem ? Is there any other
solution than extending stdenv with libnss_sss and recompiling the
entire software stack ?




signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev