Re: [Nix-dev] NixOS 15.09 released

[Bjørn Forsman]

On 1 October 2015 at 00:18, Domen Kožar  wrote:
> Hi all,
>
> NixOS community is proud to announce the third NixOS stable release "Dingo"
> 15.09.

Finally!

A big thanks to all contributors :-)

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

Re: [Nix-dev] Using a remote machine for builds with two NixOS machines.

[Vladimír Čunát]

On 09/30/2015 10:09 PM, Jonathan Glines wrote:
> I did this for a short time, but I ran into a problem where my
> Sandybridge desktop was compiling AVR instructions that my AMD netbook
> did not understand. This was troublesome for the few packages I
> compiled all the time (Asterisk, VirtualBox), but I was also worried
> that AVR instructions would sneak into other packages, so I stopped
> using this.

Uh, I suspect the main Hydra machines don't support AVX, but that's not
the point. Such packages should be fixed to create a generic build.
(Multimedia stuff often does compile for various instruction sets, but
they switch during runtime, so that's still generic.)

In quick inspection of virtualbox build log
http://hydra.nixos.org/build/26387080/log/raw , I can only see
-mtune=generic (fine) and no -march specified, though it's possible the
problem is (still) somewhere deeper.


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

[Nix-dev] NixOS 15.09 released

[Domen Kožar]

Hi all,

NixOS community is proud to announce the third NixOS stable release "Dingo"
15.09.

There are no words to describe how much I'm proud and thankful to each one
of you contributing to this release. We had 14064 commits from 438
contributors in this release (31% increase since last release that had 333).

The release brings many improvements including Nix 1.10 and many packages
updates. See
http://hydra.nixos.org/build/26476442/download/2/nixos/release-notes.html#sec-release-15.09

ISO images, VirtualBox images and EC2 AMIs can be downloaded from:

http://nixos.org/nixos/download.html

NixOS manual is at http://nixos.org/nixos/manual/ (it will take another day
to sync)

Fresh installation can be done by following "Installation chapter" in the
manual:

http://nixos.org/nixos/manual/index.html#sec-installation

Upgrading existing NixOS installations:

$ nix-channel --add https://nixos.org/channels/nixos-15.09 nixos
$ nixos-rebuild switch --upgrade

Report any issues to the bug tracker on
https://github.com/NixOS/nixos/issues

Thank you all for being involved and hope to see you at the conference!

http://conf.nixos.org/

PS: note that according to our policy, 14.12 is now unmaintained (we'll
still backport *only critical* security updates)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Feature request: replace the Darwin stdenv with the pure Darwin stdenv

[Brandon Martin]

Big thanks to pikajude, copumpkin, and anyone else. I really would like this to 
happen. As pikajude said I have been staying on impure because of compile times 
so if we could get hydra builds that would be awesome.

--
Brandon Martin


> On Sep 30, 2015, at 1:48 PM, Jude  wrote:
> 
> Hi all, pikajude here, maintainer of the pure-darwin stdenv in nixpkgs.
> 
> Over the past few days in ##nix-darwin, I've discovered that the impure 
> Darwin stdenv on master is broken for nearly everyone due to Xcode 7's 
> introduction of `.tbd` files for library stubs; see 
> https://forums.developer.apple.com/thread/4572 
> .
> 
> As far as I have been able to investigate, .tbd compatibility is an Xcode 
> 7-exclusive feature, and I'm not sure whether the changes required to use 
> them are open-source yet. There is a temporary fix to downgrade to Xcode 6.4, 
> but that will obviously only work for a limited time. For people who do use 
> Xcode, I don’t want to restrict them to an older version because our nixpkgs 
> stdenv completely fails at what it is intended to do.
> 
> This continues the precedent of OSX updates breaking parts of nixpkgs without 
> warning.
> 
> pure-darwin mitigates this problem because the entire compiler toolchain and 
> environment (save a symlink to libSystem, which won't be changing anytime 
> soon) is in the Nix store. If I can get approval, I would love to replace the 
> current Darwin stdenv with the pure one, because it would allow us to upgrade 
> our toolchain on our own terms, as well as work nicely alongside any Xcode 
> version a user would care to install.
> 
> I would also like to merge the pure stdenv because it will result in us 
> getting Hydra builds for it, which is the main roadblock that turns people 
> off of using pure-darwin. Having Hydra build the pure stdenv also gives us an 
> easy way to see which packages are broken on pure-darwin.
> 
> Answers to some common questions:
> 
> Q: Does pure-darwin fix the missing -lgcc_s.10.5 problem?
> A: Yes. In the Xcode update, libgcc_s.10.5.dylib was changed from a symlink 
> to /usr/lib/libSystem.dylib to a text-based library stub that (AFAIK) only 
> Xcode 7 can currently use. In pure-darwin, libgcc_s is still a symlink, so ld 
> will understand it just fine.
> 
> Q: Will pure-darwin break anything for me?
> A: Right now, probably. I’ve been largely the only pure-darwin maintainer for 
> a few months, and my time and ability to fix packages are limited. I welcome 
> you to try the pure-darwin stdenv to see if there are any broken packages. 
> Over the next few days I will be working on building every package that 
> claims to be Darwin-compatible, in order to weed out the remaining errors. 
> Most fixes are trivial. About half of the broken packages I encounter just 
> need to have libiconv added as a build input.
> 
> If breakages concern you, you can use the “replaceStdenv” feature of your 
> nixpkgs config to revert to the old stdenv for as long as necessary. Packages 
> built with either stdenv will coexist peacefully.
> 
> Q: Do I have to turn on the build sandbox to use pure-darwin?
> A: Not if you don’t want to. The sandbox is just an extra layer of security 
> to make sure that the outside world isn’t polluting our builds, but it 
> certainly isn’t mandatory. Even without the sandbox, your compiler will still 
> be using its own toolchain, which means that Xcode updates will not break it.
> 
> Q: How do I turn on the build sandbox?
> A: Add "build-use-chroot = true” to your /etc/nix/nix.conf. The sandbox is 
> not enabled by default.
> 
> Q: Anything else I need to know?
> A: In nix-1.10, the sandbox is very imperfect and will cause a lot of false 
> negatives. This causes building polyml and Haskell packages to fail, among a 
> few other things.
> 
> Nix pull request #562 (https://github.com/NixOS/nix/pull/562 
> ) addresses these problems. If you 
> intend to make heavy usage of the sandbox feature, you should definitely use 
> the checkout of nix in that pull request until it gets merged into master.
> 
> Again, if you’re worried about the sandbox breaking builds, feel free to 
> disable it.
> 
> Please let me know if you have other questions.
> 
> Jude
> 
> PS: Sorry for double-post! I sent an email from my old address, which is now 
> stuck in the moderation queue.
> ___
> 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] Feature request: replace the Darwin stdenv with the pure Darwin stdenv

[Ryan Trinkle]

This looks fantastic.  The pure-darwin work has been critical to getting my
originally-linux-based toolchain working properly on mac, and I'm glad to
see it continuing to move forward like this.  Thanks very much to pikajude,
copumpkin, and all the others who have contributed to this work.


Ryan

On Wed, Sep 30, 2015 at 3:48 PM, Jude  wrote:

> Hi all, pikajude here, maintainer of the pure-darwin stdenv in nixpkgs.
>
> Over the past few days in ##nix-darwin, I've discovered that the impure
> Darwin stdenv on master is broken for nearly everyone due to Xcode 7's
> introduction of `.tbd` files for library stubs; see
> https://forums.developer.apple.com/thread/4572.
>
> As far as I have been able to investigate, .tbd compatibility is an Xcode
> 7-exclusive feature, and I'm not sure whether the changes required to use
> them are open-source yet. There is a temporary fix to downgrade to Xcode
> 6.4, but that will obviously only work for a limited time. For people who
> do use Xcode, I don’t want to restrict them to an older version because our
> nixpkgs stdenv completely fails at what it is intended to do.
>
> This continues the precedent of OSX updates breaking parts of nixpkgs
> without warning.
>
> pure-darwin mitigates this problem because the entire compiler toolchain
> and environment (save a symlink to libSystem, which won't be changing
> anytime soon) is in the Nix store. If I can get approval, I would love to
> replace the current Darwin stdenv with the pure one, because it would allow
> us to upgrade our toolchain on our own terms, as well as work nicely
> alongside any Xcode version a user would care to install.
>
> I would also like to merge the pure stdenv because it will result in us
> getting Hydra builds for it, which is the main roadblock that turns people
> off of using pure-darwin. Having Hydra build the pure stdenv also gives us
> an easy way to see which packages are broken on pure-darwin.
>
> Answers to some common questions:
>
> Q: Does pure-darwin fix the missing -lgcc_s.10.5 problem?
> A: Yes. In the Xcode update, libgcc_s.10.5.dylib was changed from a
> symlink to /usr/lib/libSystem.dylib to a text-based library stub that
> (AFAIK) only Xcode 7 can currently use. In pure-darwin, libgcc_s is still a
> symlink, so ld will understand it just fine.
>
> Q: Will pure-darwin break anything for me?
> A: Right now, probably. I’ve been largely the only pure-darwin maintainer
> for a few months, and my time and ability to fix packages are limited. I
> welcome you to try the pure-darwin stdenv to see if there are any broken
> packages. Over the next few days I will be working on building every
> package that claims to be Darwin-compatible, in order to weed out the
> remaining errors. Most fixes are trivial. About half of the broken packages
> I encounter just need to have libiconv added as a build input.
>
> If breakages concern you, you can use the “replaceStdenv” feature of your
> nixpkgs config to revert to the old stdenv for as long as necessary.
> Packages built with either stdenv will coexist peacefully.
>
> Q: Do I have to turn on the build sandbox to use pure-darwin?
> A: Not if you don’t want to. The sandbox is just an extra layer of
> security to make sure that the outside world isn’t polluting our builds,
> but it certainly isn’t mandatory. Even without the sandbox, your compiler
> will still be using its own toolchain, which means that Xcode updates will
> not break it.
>
> Q: How do I turn on the build sandbox?
> A: Add "build-use-chroot = true” to your /etc/nix/nix.conf. The sandbox is
> not enabled by default.
>
> Q: Anything else I need to know?
> A: In nix-1.10, the sandbox is very imperfect and will cause a lot of
> false negatives. This causes building polyml and Haskell packages to fail,
> among a few other things.
>
> Nix pull request #562 (https://github.com/NixOS/nix/pull/562) addresses
> these problems. If you intend to make heavy usage of the sandbox feature,
> you should definitely use the checkout of nix in that pull request until it
> gets merged into master.
>
> Again, if you’re worried about the sandbox breaking builds, feel free to
> disable it.
>
> Please let me know if you have other questions.
>
> Jude
>
> PS: Sorry for double-post! I sent an email from my old address, which is
> now stuck in the moderation queue.
>
> ___
> 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] Using a remote machine for builds with two NixOS machines.

[Jonathan Glines]

2015-09-30 14:09 GMT-06:00 Jonathan Glines :
> 2015-09-30 13:31 GMT-06:00  :
>> I have a slow laptop that needs a custom kernel.  It usually takes
>> overnight to recompile a kernel, so to combat this, I've recently set up
>> my laptop to use my desktop to perform builds.
>
> I did this for a short time, but I ran into a problem where my
> Sandybridge desktop was compiling AVR instructions that my AMD netbook
> did not understand. This was troublesome for the few packages I
> compiled all the time (Asterisk, VirtualBox), but I was also worried
> that AVR instructions would sneak into other packages, so I stopped
> using this.
>
> I didn't have time to look into it at the time, but if someone knows
> how Hydra avoids this problem (is it even using chips with AVR
> instructions?) I would be very happy to hear about it. I tried adding
> a few flags to gcc-wrapper (without messing with Asterisk's build
> system) to try and convince it that using AVR instructions was bad,
> but I never got it working.
>
> I am very interested in this new documentation. I might try this again.

Sorry I meant AVX not AVR.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Using a remote machine for builds with two NixOS machines.

[Jonathan Glines]

2015-09-30 13:31 GMT-06:00  :
> I have a slow laptop that needs a custom kernel.  It usually takes
> overnight to recompile a kernel, so to combat this, I've recently set up
> my laptop to use my desktop to perform builds.

I did this for a short time, but I ran into a problem where my
Sandybridge desktop was compiling AVR instructions that my AMD netbook
did not understand. This was troublesome for the few packages I
compiled all the time (Asterisk, VirtualBox), but I was also worried
that AVR instructions would sneak into other packages, so I stopped
using this.

I didn't have time to look into it at the time, but if someone knows
how Hydra avoids this problem (is it even using chips with AVR
instructions?) I would be very happy to hear about it. I tried adding
a few flags to gcc-wrapper (without messing with Asterisk's build
system) to try and convince it that using AVR instructions was bad,
but I never got it working.

I am very interested in this new documentation. I might try this again.

> Since this process isn't so well documented, I though I would try to
> make a record of what I did, or rather what I would do if I were doing
> this again.  I'll replace the contents of
> https://nixos.org/wiki/Distributed_build with this, if there are no
> complaints.
>
>
> Step 1.  Create and exchange signing keys.
>
> To generate signing keys I vaguely follow the directions in
> https://github.com/NixOS/nix/blob/master/doc/signing.txt
>
> As root I run
>
> # (umask 277 && `nix-build --no-out-link "" -A libressl`/bin/openssl 
> genrsa -out /etc/nix/signing-key.sec 4096)
> # `nix-build --no-out-link "" -A libressl`/bin/Aopenssl rsa -in 
> /etc/nix/signing-key.sec -pubout > /etc/nix/signing-key.pub
>
> This generates /etc/nix/signing-key.sec and /etc/nix/signing-key.pub.
> This step can be done on either the client or server.  The created files
> should be copied to the other machine.  Now both machines have copies of
> both the private and public signing keys.  These keys are used to share
> closures between the two machines, via nix-copy-closure --sign, without
> needing to necessarly use root accounts.
>
>
> Step 2. Generate ssh keys
>
> On the client (i.e. my laptop):
>
> # ssh-keygen -t ed25519 -N "" -C nixBuild -f /root/.ssh/id_nixBuild -N ""
>
> This will create both /root/.ssh/id_nixBuild and
> /root/.ssh/id_nixBuild.pub files.
>
>
> Step 3. Create a nixBuild account
>
> On the server (i.e. my desktop), update /etc/nixos/configuration.nix to
> add a new user
>
>users.extraUsers.nixBuild = {
>  name = "nixBuild";
>  useDefaultShell = true;
>  openssh.authorizedKeys.keys = [ "ssh-ed25519 AAA... nixBuild" ];
>};
>
> replacing the string in the openssh.authorizedKeys.keys with the contents
> of the /root/.ssh/id_nixBuild.pub file generated on the client machine.
> The client will access the server via this account in order to run Nix
> commands.
>
>
> Step 4. Enable distributed builds.
>
> On the client (i.e. my laptop), update /etc/nixos/configuration.nix to
> enable distributed builds.
>
>nix = {
>  distributedBuilds = true;
>  buildMachines = [{
>hostName = "";
>maxJobs = ;
>sshKey = "/root/.ssh/id_nixBuild";
>sshUser = "nixBuild";
>system = "x86_64-linux";
>  }];
>};
>
> For the maxJobs field, run
>
> $ nixos-option nix.maxJobs
>
> on the server machine and use the "Value:" listed.
>
> For the system field, run
>
> $ nix-instantiate --eval -E 'builtins.currentSystem'
>
> on both the client and server machines.  They should both print the same
> value, and you should use that value in the system field.  You cannot use
> a remote machine with a different system for remote builds.
>
>
> And that is all.  For testing purposes, you can set the nix.maxJobs value
> in your client machines /etc/nixos/hardware-configuation.nix value
> temporarily to 0.  This will force all builds to be done remotely.  You
> can restore the value after you are done testing.
>
> It goes without saying that after updating configuration.nix files, you
> will need to run nixos-rebuild to realize the changes.
>
>
> Some general comments:  This setup means that both the client and server
> trust each other's binaries.  I'd prefer that only the client trust the
> server's binaries, and have the client only upload source files to the
> server to build; however I don't know how to force this.
>
> Also it would be nice to restrict the nixBuild user on the server to only
> run nix-commands.
>
> --
> Russell O'Connor  
> ``All talk about `theft,''' the general counsel of the American Graphophone
> Company wrote, ``is the merest claptrap, for there exists no property in
> ideas musical, literary or artistic, except as defined by statute.''
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
___

Re: [Nix-dev] Using a remote machine for builds with two NixOS machines.

[Peter Simons]

Hi,

 > Step 3. Create a nixBuild account
 >
 > On the server (i.e. my desktop), update /etc/nixos/configuration.nix to
 > add a new user
 >
 >users.extraUsers.nixBuild = {
 >  name = "nixBuild";
 >  useDefaultShell = true;
 >  openssh.authorizedKeys.keys = [ "ssh-ed25519 AAA... nixBuild" ];
 >};
 >
 > replacing the string in the openssh.authorizedKeys.keys with the contents
 > of the /root/.ssh/id_nixBuild.pub file generated on the client machine.

personally, I use the 'root' account for that purpose like so:

  users.extraUsers.root.openssh.authorizedKeys.keys = pkgs.lib.singleton ''
command="nice -n20 nix-store --serve --write" 
  '';

As far as I know, other unprivileged users cannot use nix-store in that
way, so you cannot easily configure a forced command for them (which is
desirable, IMHO). I might be wrong, though.

Best regards,
Peter

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

[Nix-dev] Feature request: replace the Darwin stdenv with the pure Darwin stdenv

[Jude]

Hi all, pikajude here, maintainer of the pure-darwin stdenv in nixpkgs.

Over the past few days in ##nix-darwin, I've discovered that the impure Darwin 
stdenv on master is broken for nearly everyone due to Xcode 7's introduction of 
`.tbd` files for library stubs; see 
https://forums.developer.apple.com/thread/4572 
.

As far as I have been able to investigate, .tbd compatibility is an Xcode 
7-exclusive feature, and I'm not sure whether the changes required to use them 
are open-source yet. There is a temporary fix to downgrade to Xcode 6.4, but 
that will obviously only work for a limited time. For people who do use Xcode, 
I don’t want to restrict them to an older version because our nixpkgs stdenv 
completely fails at what it is intended to do.

This continues the precedent of OSX updates breaking parts of nixpkgs without 
warning.

pure-darwin mitigates this problem because the entire compiler toolchain and 
environment (save a symlink to libSystem, which won't be changing anytime soon) 
is in the Nix store. If I can get approval, I would love to replace the current 
Darwin stdenv with the pure one, because it would allow us to upgrade our 
toolchain on our own terms, as well as work nicely alongside any Xcode version 
a user would care to install.

I would also like to merge the pure stdenv because it will result in us getting 
Hydra builds for it, which is the main roadblock that turns people off of using 
pure-darwin. Having Hydra build the pure stdenv also gives us an easy way to 
see which packages are broken on pure-darwin.

Answers to some common questions:

Q: Does pure-darwin fix the missing -lgcc_s.10.5 problem?
A: Yes. In the Xcode update, libgcc_s.10.5.dylib was changed from a symlink to 
/usr/lib/libSystem.dylib to a text-based library stub that (AFAIK) only Xcode 7 
can currently use. In pure-darwin, libgcc_s is still a symlink, so ld will 
understand it just fine.

Q: Will pure-darwin break anything for me?
A: Right now, probably. I’ve been largely the only pure-darwin maintainer for a 
few months, and my time and ability to fix packages are limited. I welcome you 
to try the pure-darwin stdenv to see if there are any broken packages. Over the 
next few days I will be working on building every package that claims to be 
Darwin-compatible, in order to weed out the remaining errors. Most fixes are 
trivial. About half of the broken packages I encounter just need to have 
libiconv added as a build input.

If breakages concern you, you can use the “replaceStdenv” feature of your 
nixpkgs config to revert to the old stdenv for as long as necessary. Packages 
built with either stdenv will coexist peacefully.

Q: Do I have to turn on the build sandbox to use pure-darwin?
A: Not if you don’t want to. The sandbox is just an extra layer of security to 
make sure that the outside world isn’t polluting our builds, but it certainly 
isn’t mandatory. Even without the sandbox, your compiler will still be using 
its own toolchain, which means that Xcode updates will not break it.

Q: How do I turn on the build sandbox?
A: Add "build-use-chroot = true” to your /etc/nix/nix.conf. The sandbox is not 
enabled by default.

Q: Anything else I need to know?
A: In nix-1.10, the sandbox is very imperfect and will cause a lot of false 
negatives. This causes building polyml and Haskell packages to fail, among a 
few other things.

Nix pull request #562 (https://github.com/NixOS/nix/pull/562 
) addresses these problems. If you 
intend to make heavy usage of the sandbox feature, you should definitely use 
the checkout of nix in that pull request until it gets merged into master.

Again, if you’re worried about the sandbox breaking builds, feel free to 
disable it.

Please let me know if you have other questions.

Jude

PS: Sorry for double-post! I sent an email from my old address, which is now 
stuck in the moderation queue.___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Using a remote machine for builds with two NixOS machines.

[Eelco Dolstra]

Hi,

On 30/09/15 21:31, rocon...@theorem.ca wrote:

> I have a slow laptop that needs a custom kernel.  It usually takes 
> overnight to recompile a kernel, so to combat this, I've recently set up 
> my laptop to use my desktop to perform builds.
> 
> Since this process isn't so well documented, I though I would try to 
> make a record of what I did, or rather what I would do if I were doing 
> this again.  I'll replace the contents of 
> https://nixos.org/wiki/Distributed_build with this, if there are no 
> complaints.
> 
> 
> Step 1.  Create and exchange signing keys.

Creating signing keys is not necessary if you set

  nix.trustedUsers = [ "nixBuild" ];

on the build machine.

-- 
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

[Nix-dev] Using a remote machine for builds with two NixOS machines.

[roconnor]

I have a slow laptop that needs a custom kernel.  It usually takes 
overnight to recompile a kernel, so to combat this, I've recently set up 
my laptop to use my desktop to perform builds.

Since this process isn't so well documented, I though I would try to 
make a record of what I did, or rather what I would do if I were doing 
this again.  I'll replace the contents of 
https://nixos.org/wiki/Distributed_build with this, if there are no 
complaints.


Step 1.  Create and exchange signing keys.

To generate signing keys I vaguely follow the directions in 
https://github.com/NixOS/nix/blob/master/doc/signing.txt

As root I run

# (umask 277 && `nix-build --no-out-link "" -A libressl`/bin/openssl 
genrsa -out /etc/nix/signing-key.sec 4096)
# `nix-build --no-out-link "" -A libressl`/bin/Aopenssl rsa -in 
/etc/nix/signing-key.sec -pubout > /etc/nix/signing-key.pub

This generates /etc/nix/signing-key.sec and /etc/nix/signing-key.pub.
This step can be done on either the client or server.  The created files 
should be copied to the other machine.  Now both machines have copies of 
both the private and public signing keys.  These keys are used to share 
closures between the two machines, via nix-copy-closure --sign, without 
needing to necessarly use root accounts.


Step 2. Generate ssh keys

On the client (i.e. my laptop):

# ssh-keygen -t ed25519 -N "" -C nixBuild -f /root/.ssh/id_nixBuild -N ""

This will create both /root/.ssh/id_nixBuild and 
/root/.ssh/id_nixBuild.pub files.


Step 3. Create a nixBuild account

On the server (i.e. my desktop), update /etc/nixos/configuration.nix to 
add a new user

   users.extraUsers.nixBuild = {
 name = "nixBuild";
 useDefaultShell = true;
 openssh.authorizedKeys.keys = [ "ssh-ed25519 AAA... nixBuild" ];
   };

replacing the string in the openssh.authorizedKeys.keys with the contents 
of the /root/.ssh/id_nixBuild.pub file generated on the client machine.
The client will access the server via this account in order to run Nix 
commands.


Step 4. Enable distributed builds.

On the client (i.e. my laptop), update /etc/nixos/configuration.nix to 
enable distributed builds.

   nix = {
 distributedBuilds = true;
 buildMachines = [{
   hostName = "";
   maxJobs = ;
   sshKey = "/root/.ssh/id_nixBuild";
   sshUser = "nixBuild";
   system = "x86_64-linux";
 }];
   };

For the maxJobs field, run

$ nixos-option nix.maxJobs

on the server machine and use the "Value:" listed.

For the system field, run

$ nix-instantiate --eval -E 'builtins.currentSystem'

on both the client and server machines.  They should both print the same 
value, and you should use that value in the system field.  You cannot use 
a remote machine with a different system for remote builds.


And that is all.  For testing purposes, you can set the nix.maxJobs value 
in your client machines /etc/nixos/hardware-configuation.nix value 
temporarily to 0.  This will force all builds to be done remotely.  You 
can restore the value after you are done testing.

It goes without saying that after updating configuration.nix files, you 
will need to run nixos-rebuild to realize the changes.


Some general comments:  This setup means that both the client and server 
trust each other's binaries.  I'd prefer that only the client trust the 
server's binaries, and have the client only upload source files to the 
server to build; however I don't know how to force this.

Also it would be nice to restrict the nixBuild user on the server to only 
run nix-commands.

-- 
Russell O'Connor  
``All talk about `theft,''' the general counsel of the American Graphophone
Company wrote, ``is the merest claptrap, for there exists no property in
ideas musical, literary or artistic, except as defined by statute.''
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] [nix-dev] travis blocks pull request because log is too long

[Tomas Hlavaty]

Hi Luca,

thank you for your reply.  Good to know that travis is not a blocker.  I
have fixed the issues that @bjornfor and @vcunat raised.  I hope someone
will find time to merge it now.

Thanks a lot!

Tomas

Luca Bruno  writes:

> On 29/09/2015 10:34, Tomas Hlavaty wrote:
>
> Hi,
> 
> I have made a pull request, which is now blocked by travis because of
> too long log.
> 
> Could somebody please commit this?
> https://github.com/NixOS/nixpkgs/pull/10104
> 
> It seems that changes to that part of nixpkgs never go through pull
> requests and travis, because it is impossible for them to pass.
> 
> Thanks a lot!
> 
> You got a comment from @bjornfor which asked you to change
> format to the commit messages. The PR will hardly be considered
> until the commit format is fixed.
> Ignore travis for your PR.
>
> Best regards,
>
> ___
> 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] subversion

[Karn Kallio]

The kdesvn kio helper from kde 4.14.3 does not build with the newer subversion 
1.9.x series.  The attached patch restores the subversion 1.8.x to nixpkgs and 
uses it with kde4.
>From b91c3d65902fb349569092d34296806b6ba521e0 Mon Sep 17 00:00:00 2001
From: Karn Kallio 
Date: Wed, 30 Sep 2015 10:43:14 -0430
Subject: [PATCH] Restore subversion 1.8.x because kdesvn does not build with
 1.9.x

---
 .../version-management/subversion/1.8.x.nix| 85 ++
 pkgs/top-level/all-packages.nix| 11 ++-
 2 files changed, 94 insertions(+), 2 deletions(-)
 create mode 100644 pkgs/applications/version-management/subversion/1.8.x.nix

diff --git a/pkgs/applications/version-management/subversion/1.8.x.nix b/pkgs/applications/version-management/subversion/1.8.x.nix
new file mode 100644
index 000..ffe6883
--- /dev/null
+++ b/pkgs/applications/version-management/subversion/1.8.x.nix
@@ -0,0 +1,85 @@
+{ bdbSupport ? false # build support for Berkeley DB repositories
+, httpServer ? false # build Apache DAV module
+, httpSupport ? false # client must support http
+, pythonBindings ? false
+, perlBindings ? false
+, javahlBindings ? false
+, saslSupport ? false
+, stdenv, fetchurl, apr, aprutil, zlib, sqlite
+, apacheHttpd ? null, expat, swig ? null, jdk ? null, python ? null, perl ? null
+, sasl ? null, serf ? null
+}:
+
+assert bdbSupport -> aprutil.bdbSupport;
+assert httpServer -> apacheHttpd != null;
+assert pythonBindings -> swig != null && python != null;
+assert javahlBindings -> jdk != null && perl != null;
+
+stdenv.mkDerivation (rec {
+
+  version = "1.8.14";
+
+  name = "subversion-${version}";
+
+  src = fetchurl {
+url = "mirror://apache/subversion/${name}.tar.bz2";
+sha1 = "0698efc58373e7657f6dd3ce13cab7b002ffb497";
+  };
+
+  buildInputs = [ zlib apr aprutil sqlite ]
+++ stdenv.lib.optional httpSupport serf
+++ stdenv.lib.optional pythonBindings python
+++ stdenv.lib.optional perlBindings perl
+++ stdenv.lib.optional saslSupport sasl;
+
+  configureFlags = ''
+${if bdbSupport then "--with-berkeley-db" else "--without-berkeley-db"}
+${if httpServer then "--with-apxs=${apacheHttpd}/bin/apxs" else "--without-apxs"}
+${if pythonBindings || perlBindings then "--with-swig=${swig}" else "--without-swig"}
+${if javahlBindings then "--enable-javahl --with-jdk=${jdk}" else ""}
+--disable-keychain
+${if saslSupport then "--with-sasl=${sasl}" else "--without-sasl"}
+${if httpSupport then "--with-serf=${serf}" else "--without-serf"}
+--with-zlib=${zlib}
+--with-sqlite=${sqlite}
+  '';
+
+  preBuild = ''
+makeFlagsArray=(APACHE_LIBEXECDIR=$out/modules)
+  '';
+
+  postInstall = ''
+if test -n "$pythonBindings"; then
+make swig-py swig_pydir=$(toPythonPath $out)/libsvn swig_pydir_extra=$(toPythonPath $out)/svn
+make install-swig-py swig_pydir=$(toPythonPath $out)/libsvn swig_pydir_extra=$(toPythonPath $out)/svn
+fi
+
+if test -n "$perlBindings"; then
+make swig-pl-lib
+make install-swig-pl-lib
+cd subversion/bindings/swig/perl/native
+perl Makefile.PL PREFIX=$out
+make install
+cd -
+fi
+
+mkdir -p $out/share/bash-completion/completions
+cp tools/client-side/bash_completion $out/share/bash-completion/completions/subversion
+  '';
+
+  inherit perlBindings pythonBindings;
+
+  enableParallelBuilding = true;
+
+  meta = {
+description = "A version control system intended to be a compelling replacement for CVS in the open source community";
+homepage = http://subversion.apache.org/;
+maintainers = with stdenv.lib.maintainers; [ eelco lovek323 ];
+hydraPlatforms = stdenv.lib.platforms.linux ++ stdenv.lib.platforms.darwin;
+  };
+} // stdenv.lib.optionalAttrs stdenv.isDarwin {
+  CXX = "clang++";
+  CC = "clang";
+  CPP = "clang -E";
+  CXXCPP = "clang++ -E";
+})
diff --git a/pkgs/top-level/all-packages.nix b/pkgs/top-level/all-packages.nix
index a3f764e..aa70f0c 100644
--- a/pkgs/top-level/all-packages.nix
+++ b/pkgs/top-level/all-packages.nix
@@ -12775,7 +12775,7 @@ let
 
   sublime3 = lowPrio (callPackage ../applications/editors/sublime3 { });
 
-  subversion = callPackage ../applications/version-management/subversion/default.nix {
+  subversionFun = versionPath: callPackage versionPath {
 bdbSupport = true;
 httpServer = false;
 httpSupport = true;
@@ -12786,12 +12786,18 @@ let
 sasl = cyrus_sasl;
   };
 
-  subversionClient = appendToName "client" (subversion.override {
+  subversionClientFun = subversion: appendToName "client" (subversion.override {
 bdbSupport = false;
 perlBindings = true;
 pythonBindings = true;
   });
 
+  subversion = subversionFun ../applications/version-management/subversion/default.nix;
+
+  subversionClient = subversionClientFun subversion;
+
+  subversionClient_1_8 = subversionClientFun (subversionFun ../applications/version-management/subversion/1.8.x.nix);
+
  

Re: [Nix-dev] NixCon: Venue announcement and short status update

[Rok Garbas]

Quoting Luca Bruno (2015-09-30 14:27:44)
> On 30/09/2015 14:12, Rok Garbas wrote:
> > Hi,
> >
> > It took us a bit longer then planned, but we finally have a conference
> > venue booked. NixCon is going to take place at new Ahoy!Berlin[1] offices.
> >
> > Ahoy!Berlin address:
> >   Wattstrasse 11
> >   13355 Berlin
> >
> > 54 tickets were sold up to today. Thank you!
> >
> > We are in last stage of the CfP review process and full program with
> > accepted talks will be announced in a week time.
> >
> > Enough money was raised until now to video record the talks, which we
> > will make available online after the conference. We are still missing
> > few euros to complete our plan and I would kindly ask you to help to
> > ask your CEO/CTO if they would be willing to sponsor[2] NixCon. More
> > details how we spend money can be found online in the NixCon Budget[3]
> > document.
> >
> > See you in Berlin,
> > Rok
> >
> > [1] http://www.ahoyberlin.com
> > [2] http://conf.nixos.org/sponsorship-prospectus.html
> > [3] 
> > https://docs.google.com/spreadsheets/d/1kIwsyG6U1U3MTKJOP8jVM_Zj1JuvyJbjXNoLFmNaP9I/edit?usp=sharing
> >
> >
> Thanks for the info. Would someone update http://conf.nixos.org/  with
> the street details?

sry, i fixed it but forgot to push

--
Rok Garbas - http://www.garbas.si


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

Re: [Nix-dev] Next release updates

[Domen Kožar]

15.09 will be released tonight (CET). Make sure you've all updated release
notes :-)

On Thu, Sep 24, 2015 at 1:22 PM, Domen Kožar  wrote:

> It takes about a day to do a stdenv rebuild (given that all nixos tests
> pass), so I don't see an issue with that.
>
> On Thu, Sep 24, 2015 at 10:17 AM, Vladimír Čunát  wrote:
>
>> On 09/23/2015 10:33 PM, Domen Kožar wrote:
>> > Last blocker is releasing nixops 1.3, which has issues with new sshd
>> > keys and their incompatibilities with previous release.
>>
>> I see also this as a relevant issue:
>> https://github.com/NixOS/nixpkgs/commit/453b986d2f1061
>> If we do opt to rebuild now, it would be nice to announce after we have
>> the new binaries. I wouldn't call it a "blocker" issue; it's just that
>> stdenv rebuilds are so expensive.
>>
>> 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

Re: [Nix-dev] What license does the content of the nixos wiki and the manuals have?

[Matthias Beyer]

Hey!

Thank you for reporting back! This sounds really really great for me!

So can we please have a poll on which license to choose?
If yes, how? Mailinglist? Github?

On 30-09-2015 21:28:11, Eric Sagnes wrote:
> Hi,
> 
> While editing a page in the current wiki I found a page mentioning 
> the copyright used:
> https://nixos.org/wiki/Nix_Wiki:Copyrights
> (The page is linked from the edition interface of the wiki)
> 
> Quoting below:
> 
> ---
> Right now we don't have a final choice about the license.
> 
> For now when contributing to the wiki you agree that your content may be
> relicensed to whatever license is choosen by the nix community.
> Subscribe to the mailinglist to stay up to date. 
> ---
> 
> I am not a lawyer but this sounds legit enough to avoid deleting pages and
> anonymous contributions.
> 

-- 
Mit freundlichen Grüßen,
Kind regards,
Matthias Beyer

Proudly sent with mutt.
Happily signed with gnupg.


pgpnIBbOxdHWK.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] Nix logo poll results

[Domen Kožar]

I think conference in November would be a good time to talk about this :)

On Sun, Sep 27, 2015 at 11:24 PM, Jascha Geerds  wrote:

> Would be nice to release NixOS 15.09 with a new logo! :-)
>
> @edolstra: What are your thoughts?
> --
>   Jascha Geerds
>   j...@ekby.de
> ___
> 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] What license does the content of the nixos wiki and the manuals have?

[Eric Sagnes]

Hi,

While editing a page in the current wiki I found a page mentioning 
the copyright used:
https://nixos.org/wiki/Nix_Wiki:Copyrights
(The page is linked from the edition interface of the wiki)

Quoting below:

---
Right now we don't have a final choice about the license.

For now when contributing to the wiki you agree that your content may be
relicensed to whatever license is choosen by the nix community.
Subscribe to the mailinglist to stay up to date. 
---

I am not a lawyer but this sounds legit enough to avoid deleting pages and
anonymous contributions.


On Fri, Sep 25, 2015 at 01:50:54PM +0300, Kirill Elagin wrote:
> I’d like to also point out another problem.
> In case some of contributors do not agree to the new terms, how are we
> going to delete their contributions? My understanding is that simply
> deleting the content in question from the page is not enough, it’s wiki
> actually. We’ll have to see how, for example, Wikipedia deals with this
> kind of issues, I’m sure they often have to remove copyrighted content.
> 
> That said, I’m pretty sure other projects also had to deal with changing
> the licence of their docs, so we can learn from their experience instead of
> inventing something new.
> 
> On Fri, Sep 25, 2015 at 10:28 AM, Joachim Schiele  wrote:
> 
> > two problems i see here:
> > - text can't be covered by GPL thus they created CC
> > - some edits in the wiki are anonymous (whom to ask?)
> >
> > i like that we are adressing this issue now. it is very important.
> >
> > i'd go for CC BY SA 3.0
> > https://creativecommons.org/licenses/by-sa/3.0/
> > as IMHO this fits the other licenses pretty well
> >
> > On 25.09.2015 03:48, stewart mackenzie wrote:
> > > According to my understanding:
> > >
> > > * 1st agree on a license for the wiki.
> > > * we need to get all wiki contributors to agree on said license.
> > > * we'll need a written statement from all wiki contributors, could be
> > > something simple like "I agree to publish my contributions to the nixos
> > > wiki under the X license" these statements could be on a new mailing
> > > list thread. It'll be mundane receiving these mails but it's needed..
> > >
> > > (longerterm strategy)
> > > * The Nixos Foundation could use selected parts of the C4.1(
> > > http://rfc.zeromq.org/spec:22) particularly the licensing bits to create
> > > a nixos contributors 'contract'. It /should/ be difficult but not
> > > impossible to change the license of wiki, nix{pkgs,os,} as this prevents
> > > vendor lockins / foundation / consortium clusterfuck takeovers where
> > > dishonest agents could for example purchase the copyright to a codebase.
> > > i.e. what happened to Berkeleydb and oracle.
> > > * so far all the contribution copyrights to nix{os,pkgs} belong to the
> > > contributors and not the nixos foundation. It is preferable (IMHO) that
> > > copyright remain in the contributors hands and not the nixos foundation.
> > > Foundations can be corrupted, this prevents sillybuggers happening in
> > > foundations.
> > >
> > > Personally, i'd prefer the whole nix{os,pkgs} to be a license like gpl3
> > > or mpl2. These licenses create prevent an org like redhat form forking
> > > and sublicensing.
> > >
> > > I am not a lawyer.
> > >
> > > There are treasures of untold wealth in nixos let's at least properly
> > > protect them.
> > >
> > > On 25 Sep 2015 01:52, "Vladimír Čunát"  > > > wrote:
> > >
> > > On 09/24/2015 05:24 PM, Domen Kožar wrote:
> > > > I'm all for permissive creative commons license.
> > >
> > > It might be good to have the same license for wiki and nix{pkgs,os,}
> > > docs, allowing us to move content around freely.
> > >
> > > I'm no lawyer, too, but I think there's also the issue of the
> > copyright
> > > holder, which might be the foundation, for example. And the question
> > of
> > > "asking everyone" seems rather difficult; moreover, I'm not sure what
> > > kind of approval is needed (I'm afraid a paper-written one in some
> > > jurisdictions).
> > >
> > >
> > > 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
> > >
> >
> >
> > ___
> > 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


-- 
Eric Sagnes
サニエ エリック
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
htt

Re: [Nix-dev] NixCon: Venue announcement and short status update

[Luca Bruno]

On 30/09/2015 14:12, Rok Garbas wrote:
> Hi,
>
> It took us a bit longer then planned, but we finally have a conference
> venue booked. NixCon is going to take place at new Ahoy!Berlin[1] offices.
>
> Ahoy!Berlin address:
>   Wattstrasse 11
>   13355 Berlin
>
> 54 tickets were sold up to today. Thank you!
>
> We are in last stage of the CfP review process and full program with
> accepted talks will be announced in a week time.
>
> Enough money was raised until now to video record the talks, which we
> will make available online after the conference. We are still missing
> few euros to complete our plan and I would kindly ask you to help to
> ask your CEO/CTO if they would be willing to sponsor[2] NixCon. More
> details how we spend money can be found online in the NixCon Budget[3]
> document.
>
> See you in Berlin,
> Rok
>
> [1] http://www.ahoyberlin.com
> [2] http://conf.nixos.org/sponsorship-prospectus.html
> [3] 
> https://docs.google.com/spreadsheets/d/1kIwsyG6U1U3MTKJOP8jVM_Zj1JuvyJbjXNoLFmNaP9I/edit?usp=sharing
>
>
Thanks for the info. Would someone update http://conf.nixos.org/  with
the street details?
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] NixCon: Venue announcement and short status update

[Rok Garbas]

Hi,

It took us a bit longer then planned, but we finally have a conference
venue booked. NixCon is going to take place at new Ahoy!Berlin[1] offices.

Ahoy!Berlin address:
  Wattstrasse 11
  13355 Berlin

54 tickets were sold up to today. Thank you!

We are in last stage of the CfP review process and full program with
accepted talks will be announced in a week time.

Enough money was raised until now to video record the talks, which we will
make available online after the conference. We are still missing few euros
to complete our plan and I would kindly ask you to help to ask your CEO/CTO
if they would be willing to sponsor[2] NixCon. More details how we spend
money can be found online in the NixCon Budget[3] document.

See you in Berlin,
Rok

[1] http://www.ahoyberlin.com
[2] http://conf.nixos.org/sponsorship-prospectus.html
[3]
https://docs.google.com/spreadsheets/d/1kIwsyG6U1U3MTKJOP8jVM_Zj1JuvyJbjXNoLFmNaP9I/edit?usp=sharing
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] texlive archive

[Vladimír Čunát]

On 09/30/2015 05:25 AM, Karn Kallio wrote:
> The textlive-new package currently does not build since there is not an 
> anonymous ftp server at tug.ctan.org.  The attached patch switches to an http 
> server at http://ftp.math.utah.edu.

Thanks, applied both on master and 15.09.
https://github.com/NixOS/nixpkgs/issues/10026


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