Re: [Nix-dev] NixOS small channel

2014-09-30 Thread Wout Mertens
Just to let you know I'm doing a happy dance right now :-)

Great stuff!

Wout.
On Sep 30, 2014 2:27 AM, Eelco Dolstra eelco.dols...@logicblox.com
wrote:

 Hi,

 Since last week there is a new NixOS channel:

   https://nixos.org/channels/nixos-14.04-small

 This is a variant of the regular NixOS 14.04 channel mainly intended for
 servers
 that need fast security updates. It differs from the regular 14.04 channel
 in
 the following ways:

 * It builds way, way fewer packages. In particular, there is no desktop
 stuff,
 and no gazillion Python/Perl/Haskel/... packages.

 * It has fewer release-critical tests. For instance, it doesn't require
 any of
 the X11 tests to succeed.

 * It only builds x86_64 binaries.

 These properties mean that the channel can update in about 2-3 hours after
 a Git
 commit that causes a full rebuild, rather than several days. The downside
 is
 that nixos-rebuild may need to build more stuff from source than with the
 regular channel.

 To switch an existing system to this channel:

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

 The channel currently builds a fairly arbitrary set of packages. These are
 defined here:


 https://github.com/NixOS/nixpkgs/blob/release-14.04/nixos/release-small.nix

 Feel free to add/suggest additional packages.

 The Hydra jobset is:

   http://hydra.nixos.org/jobset/nixos/release-14.04-small

 and the status of the release-critical jobs is here:


 http://hydra.nixos.org/job/nixos/release-14.04-small/tested#tabs-constituents

 --
 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 mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


Re: [Nix-dev] NixOS small channel

2014-09-30 Thread Pascal Wittmann
On 09/30/2014 02:27 AM, Eelco Dolstra wrote:
 Hi,
 
 Since last week there is a new NixOS channel:
 
   https://nixos.org/channels/nixos-14.04-small
 
 This is a variant of the regular NixOS 14.04 channel mainly intended for 
 servers
 that need fast security updates. It differs from the regular 14.04 channel in
 the following ways:

Much appreciated! I am already switching my server to the new channel.

Best regards, Pascal



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] Channel update knocks my box offline

2014-09-30 Thread Mateusz Kowalczyk
On 09/23/2014 07:02 AM, Mateusz Kowalczyk wrote:
 Most recent nixos-unstable channel move knocks my box offline somehow. I
 can reach my local network but nothing on the outside. My network
 config[1] is pretty simple. I noticed this few days ago when I tried to
 switch to master but had no time at that moment to pursue.
 
 Considering this and the Grub problem in the other thread, were the
 tests switched off for this channel move or something?
 
 Apparently --rollback felt the need to kill my X session too ;(
 
 [1]:
 https://github.com/Fuuzetsu/nix-project-defaults/blob/master/nixos-config/configuration.nix#L73
 

With some help on IRC, the mystery was solved. The default route was not
being set so after switch I had to manually run ‘systemctl restart
network-setup’, which the switch should have done itself.

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


[Nix-dev] Reengineered npm2nix: call for feedback

2014-09-30 Thread Sander van der Burg
Hi everybody,

Since the sprint in Ljubljana until now, I've been working on npm2nix's
issues. I basically reengineered most of it (e.g. rewritten it to
JavaScript and modularized it a bit further) and I think the implementation
is fairly complete now. I've incorporated as much of Shea's functionaility
into the reengineered version as I could.

The new implementation handles dependencies in such a way that its behavior
is closer to what NPM does. Moreover, it should also properly cope with
cyclic dependencies. The way dependencies are resolved is actually much
more advanced than the original npm2nix implementation. For example, it
uses semver to make matches between version ranges.

In theory, also cyclic dependencies that match on version ranges should be
handled properly, although I haven't encountered them yet.

Using the reengineered version is straight forward. You can obtain it from
my private Git fork:

https://github.com/svanderburg/npm2nix/tree/reengineering

I have updated the README.md file of npm2nix to elaborate a bit more about
the possible use cases of npm2nix. So I think it wouldn't be a bad idea to
read it first.

Installation can be done by opening the git checkout, and running:

$ nix-env -f default.nix -iA build

Moreover, you don't need to update Nixpkgs. The new build function is
actually part of npm2nix.

I've used the reengineered npm2nix on a private project for the company I
work for, as well as some other utilities and it seems to work fine for me.

Hopefully, you can also try npm2nix on your projects to find out whether
there any additional issues. :)

Furthermore, I'm still working a blog post to rationalize all the stuff,
which should give you better insights in the problem, details and the
choices I made.

Let me know what you think!

Regards,

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


[Nix-dev] NILFS2, NixOS, nixpart and Blivet

2014-09-30 Thread Tim Barbour
NILFS2 is a log-structured filesystem which is now in the Linux kernel source
tree, and supported by GRUB2. It should appeal to NixOS users because it
avoids destructive update (changing a file produces a new version of the
file).

I have installed NixOS with all filesystems on NILFS2, but encountered some
problems along the way.

The most serious problem is that NILFS2 needs to update /etc/mtab when
mounting a filesystem, so that it can store information about the
nilfs_cleanerd process associated with the mounted filesystem. If it cannot
write to /etc/mtab, it does not start nilfs_cleanerd, and thus does not do
garbage collection. In NixOS, /etc/mtab is just a symlink to /proc/mounts. I
have worked around this manually so far, by replacing the symlink with a copy
of /proc/mounts, then remounting all the NILFS2 filesystems. I am not sure how
to resolve this properly. It is possible to mount using the '-n' option, but
then NILFS2 will not start nilfs_cleanerd; it can be started later, but that
requires writing to /etc/mtab. Perhaps the right way would be to mount using
'-n', then start nilfs_cleanerd separately, but care would be necessary to
make sure that nilfs_cleanerd is started exactly once (per filesystem), and
shutdown appropriately at unmount.

Another problem is that nixpart does not work with NILFS2, because Blivet does
not support it. I modified Blivet (0.41) to support NILFS2, but the NixOS
Blivet packages use a very old version (0.17-1), so I cannot easily test my
change against the latest version of Blivet. I have back-ported it to 0.17-1,
and used that to setup partitions and filesystems for the above NixOS
installation. I noticed one problem: it did not label any of the volumes, not
even swap, even though I specified labels. I suspect this is a deficiency of
Blivet 0.17-1, and imagine it is already fixed in Blivet 0.41 .

I considered updating the NixOS Blivet package(s), but they do some
tricky-looking processing on the source code, and I doubt that I could update
that properly for the current source code. If the maintainer could update the
Blivet packages, then I would test my patch against the current Blivet, and
send it to the upstream maintainers.

I attach a tarball with patches for Blivet (note that the 0.41 patch is
untested).

Tim
---
GPG public key available at: 
 http://phasechangeit.com/~trb/gpg-key  or 
 http://subkeys.pgp.net:11371


patches.tar.gz
Description: Binary data
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


[Nix-dev] build server

2014-09-30 Thread Tim Barbour
I would like to set up a nix build server, particularly for use with nixops.
Is there a definitive document about how to do this, including cross-platform
builds (e.g. ARM) ?

Can it be done declaratively, or does one need to set environment variables ?

So far I have found the following documents, each with a different way:

https://nixos.org/wiki/Raspberry_Pi
 - distcc approach

https://nixos.org/wiki/Distributed_build
--- ignore this, look at nix.buildMachines in NixOS Manual

http://nixos.org/nix/manual/#chap-distributed-builds

http://sandervanderburg.blogspot.com.au/2013/04/setting-up-hydra-build-cluster-for_10.html

I would really like to know the current recommended way.

Tim
---
GPG public key available at: 
 http://phasechangeit.com/~trb/gpg-key  or 
 http://subkeys.pgp.net:11371
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


Re: [Nix-dev] NILFS2, NixOS, nixpart and Blivet

2014-09-30 Thread Mateusz Kowalczyk
On 09/30/2014 12:08 PM, Tim Barbour wrote:
 NILFS2 is a log-structured filesystem which is now in the Linux kernel source
 tree, and supported by GRUB2. It should appeal to NixOS users because it
 avoids destructive update (changing a file produces a new version of the
 file).
 
 I have installed NixOS with all filesystems on NILFS2, but encountered some
 problems along the way.
 
 The most serious problem is that NILFS2 needs to update /etc/mtab when
 mounting a filesystem, so that it can store information about the
 nilfs_cleanerd process associated with the mounted filesystem. If it cannot
 write to /etc/mtab, it does not start nilfs_cleanerd, and thus does not do
 garbage collection. In NixOS, /etc/mtab is just a symlink to /proc/mounts. I
 have worked around this manually so far, by replacing the symlink with a copy
 of /proc/mounts, then remounting all the NILFS2 filesystems. I am not sure how
 to resolve this properly. It is possible to mount using the '-n' option, but
 then NILFS2 will not start nilfs_cleanerd; it can be started later, but that
 requires writing to /etc/mtab. Perhaps the right way would be to mount using
 '-n', then start nilfs_cleanerd separately, but care would be necessary to
 make sure that nilfs_cleanerd is started exactly once (per filesystem), and
 shutdown appropriately at unmount.
 
 Another problem is that nixpart does not work with NILFS2, because Blivet does
 not support it. I modified Blivet (0.41) to support NILFS2, but the NixOS
 Blivet packages use a very old version (0.17-1), so I cannot easily test my
 change against the latest version of Blivet. I have back-ported it to 0.17-1,
 and used that to setup partitions and filesystems for the above NixOS
 installation. I noticed one problem: it did not label any of the volumes, not
 even swap, even though I specified labels. I suspect this is a deficiency of
 Blivet 0.17-1, and imagine it is already fixed in Blivet 0.41 .
 
 I considered updating the NixOS Blivet package(s), but they do some
 tricky-looking processing on the source code, and I doubt that I could update
 that properly for the current source code. If the maintainer could update the
 Blivet packages, then I would test my patch against the current Blivet, and
 send it to the upstream maintainers.
 
 I attach a tarball with patches for Blivet (note that the 0.41 patch is
 untested).
 
 Tim
 ---
 GPG public key available at: 
http://phasechangeit.com/~trb/gpg-key  or 
http://subkeys.pgp.net:11371
 
 
 

Looks to me that all the scary-looking block in the blivet package does
is replace hardcoded paths with paths to the nix-store that nix provides
it with, a common practice. I think if you build and try to run the
newer version in chroot, it should quickly become apparent what new
changes have to be made for 0.41.

If someone doesn't step up then I think you might actually be the most
qualified person to do the update. Notably there's no listed maintainer
for the blivet package.

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


Re: [Nix-dev] NILFS2, NixOS, nixpart and Blivet

2014-09-30 Thread aszlig
Good morning,

On Tue, Sep 30, 2014 at 12:29:12PM +0100, Mateusz Kowalczyk wrote:
 Looks to me that all the scary-looking block in the blivet package does
 is replace hardcoded paths with paths to the nix-store that nix provides
 it with, a common practice. I think if you build and try to run the
 newer version in chroot, it should quickly become apparent what new
 changes have to be made for 0.41.

Well, nixpart in the current version is more of a hack (it's an under-
statement - there's heavy monkey-patching involved) rather than a sane
implementation, and still relies on Kickstart syntax.

However, for version 1.0 I intend to use a native Nix syntax for
specifying the partition layout and use blivets device tree directly
rather involving pykickstart _at_ all.

i've scheduled version 1.0 of nixpart (and nixos-assimilate) for NixOS
14.10, so i'm going to pick up my (not yet pushed) branches in the next
few days.

The reason why blivet in nixpkgs is at 0.17 at the moment is that at
least right now it's solely used by nixpart. And i've already created a
nixpart0 a while ago in order to be prepared for the transition in
NixOps (so that older builds of NixOps won't fail horribly with updated
nixpart and/or dependencies).

 Notably there's no listed maintainer for the blivet package.

Probably should have added myself to the list of maintainers back then.

a!
-- 
aszlig


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


Re: [Nix-dev] NILFS2, NixOS, nixpart and Blivet

2014-09-30 Thread aszlig
On Tue, Sep 30, 2014 at 09:08:41PM +1000, Tim Barbour wrote:
 The most serious problem is that NILFS2 needs to update /etc/mtab when
 mounting a filesystem, so that it can store information about the
 nilfs_cleanerd process associated with the mounted filesystem. If it cannot
 write to /etc/mtab, it does not start nilfs_cleanerd, and thus does not do
 garbage collection. In NixOS, /etc/mtab is just a symlink to /proc/mounts. I
 have worked around this manually so far, by replacing the symlink with a copy
 of /proc/mounts, then remounting all the NILFS2 filesystems. I am not sure how
 to resolve this properly. It is possible to mount using the '-n' option, but
 then NILFS2 will not start nilfs_cleanerd; it can be started later, but that
 requires writing to /etc/mtab. Perhaps the right way would be to mount using
 '-n', then start nilfs_cleanerd separately, but care would be necessary to
 make sure that nilfs_cleanerd is started exactly once (per filesystem), and
 shutdown appropriately at unmount.

I don't have any experience with NILFS2 yet, but you might want to take
a look at how it is handled when using NFS in fileSystems:

https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/tasks/filesystems/nfs.nix

 Another problem is that nixpart does not work with NILFS2, because Blivet does
 not support it. I modified Blivet (0.41) to support NILFS2, but the NixOS
 Blivet packages use a very old version (0.17-1), so I cannot easily test my
 change against the latest version of Blivet. I have back-ported it to 0.17-1,
 and used that to setup partitions and filesystems for the above NixOS
 installation. I noticed one problem: it did not label any of the volumes, not
 even swap, even though I specified labels. I suspect this is a deficiency of
 Blivet 0.17-1, and imagine it is already fixed in Blivet 0.41 .

Nice :-) Have you considered submitting your patch for 0.41 upstream? If
it doesn't get upstreamed too soon, I could include it as well while
cleaning up the mess^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^Hupdating
blivet/nixpart.

But as mentioned in the other mail, I'm working on nixpart 1.0 already,
which should get rid of the monkey patching with 0.17.

 I attach a tarball with patches for Blivet (note that the 0.41 patch is
 untested).

Yah, probably would make sense to test against 0.41, because I think we
shouldn't aim for old versions, especially in terms of nixpart.

a!
-- 
aszlig


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


[Nix-dev] nixos on latest macbook air

2014-09-30 Thread Tobias Pflug
Hi, 

i was wondering if anyone on this list has any experiences running nixos on the 
latest macbook air.
I googled and searched the nixos wiki for some info on this but could not find 
anything. I just wonder
if there are problems that others have run into during the process that can be 
avoided. I am currently
still running ubuntu on my macbook (which also required some twiddling and 
fixing here and there)
but would very much like to try nixos instead.

I hope this isn't the wrong place to ask. Thanks in advance for any help or 
feedback.

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


Re: [Nix-dev] Dealing with self-updating packages

2014-09-30 Thread Mateusz Kowalczyk
On 09/19/2014 07:42 PM, Russell O'Connor wrote:
 Dear nixers,
 
 I'm working on packaging gsutil 
 https://developers.google.com/storage/docs/gsutil.  This software comes
 with a feature that it can update itself by downloading the latest
 version and replacing itself in place.
 
 Obviously this isn't going to work, and indeed when I force an update it
 fails with:
 
 $ gsutil update -f
 Checking for software update...
 This command will update to the 4.6 version of
 gsutil at
 /nix/store/4p33in0gqspwv2f4w2q0fq03cvj1iq9c-gsutil-4.6/share/gsutil
 Proceed? [y/N] y
 Copying gs://pub/gsutil.tar.gz...
 Downloading file://gsutil.tar.gz:2.1 MB/2.1
 MB
 Downloading file://gsutil.tar.gz:2.1 MB/2.1
 MB
 OSError: Read-only file system.
 
 My question is, how do you guys generally deal with this sort of software?
 
 I was thinking of creating a patch that will disable the update
 functionality.  I would try to keep the notification of newer versions are
 available, but instead direct the user to update their nix-channel and/or
 notify the maintainer to update the version in nixpkgs.
 
 Thanks.
 
 

I believe the general idea is to not do anything about it and trust the
users to not try to update. It seems less hassle than patching it out
and I haven't seen anyone complain yet. I would only bother patching
stuff out iff the software relied on being to update itself and you
could not ask it to do so. I'd also give upstream a good earful first.

PS: Your e-mail only came through today.

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


[Nix-dev] Dealing with self-updating packages

2014-09-30 Thread Russell O'Connor
Dear nixers,

I'm working on packaging gsutil 
https://developers.google.com/storage/docs/gsutil.  This software comes
with a feature that it can update itself by downloading the latest
version and replacing itself in place.

Obviously this isn't going to work, and indeed when I force an update it
fails with:

$ gsutil update -f
Checking for software update...
This command will update to the 4.6 version of
gsutil at
/nix/store/4p33in0gqspwv2f4w2q0fq03cvj1iq9c-gsutil-4.6/share/gsutil
Proceed? [y/N] y
Copying gs://pub/gsutil.tar.gz...
Downloading file://gsutil.tar.gz:2.1 MB/2.1
MB
Downloading file://gsutil.tar.gz:2.1 MB/2.1
MB
OSError: Read-only file system.

My question is, how do you guys generally deal with this sort of software?

I was thinking of creating a patch that will disable the update
functionality.  I would try to keep the notification of newer versions are
available, but instead direct the user to update their nix-channel and/or
notify the maintainer to update the version in nixpkgs.

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


Re: [Nix-dev] NixOS small channel

2014-09-30 Thread John Wiegley
 John Wiegley jo...@newartisans.com writes:

 Here's what the machine was trying to do when nixos-rebuild got hung:

 https://gist.github.com/e2e69a41a2dfea23ebc3

Just FYI: I left it running all night long, and it did at some point complete
normally, so I guess whatever it was trying to do was just slow.

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


Re: [Nix-dev] nixos on latest macbook air

2014-09-30 Thread Damien Cassou
On Tue, Sep 30, 2014 at 1:51 PM, Tobias Pflug tobias.pf...@gmx.net wrote:
 i was wondering if anyone on this list has any experiences running nixos on 
 the latest macbook air.


not answering your question: nixos runs fine on a MacBook Pro 9.2.

-- 
Damien Cassou
http://damiencassou.seasidehosting.st

Success is the ability to go from one failure to another without
losing enthusiasm.
Winston Churchill
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


Re: [Nix-dev] Reengineered npm2nix: call for feedback

2014-09-30 Thread Paul Colomiets
Hi,

On Tue, Sep 30, 2014 at 1:13 PM, Sander van der Burg
svanderb...@gmail.com wrote:
 Hopefully, you can also try npm2nix on your projects to find out whether
 there any additional issues. :)


If package.json doesn't contains name or version npm2nix, the
build fails with the following:

error: `buildNodePackage' at /tmp/react/node-env.nix:33:5 called
without required argument `version', at /tmp/react/registry.nix:5:27

It would be nicer, if npm2nix fails when generating nix files.

After I've filled both name and version I've got the following error:

 nix-build -A build
these derivations will be built:
  /nix/store/6g9vk21ag4rzjl13dnqnq3nabb1hgas0-node-reacttest-0.1.drv
building path(s)
`/nix/store/aksz62alq8903cnp88iv0z36n0lrybjh-node-reacttest-0.1'
building /nix/store/aksz62alq8903cnp88iv0z36n0lrybjh-node-reacttest-0.1
unpacking sources
unpacking source archive /nix/store/d394a7821m6sn02ymhvfa13c7dac2fiq-react
source root is react
patching sources
configuring
no configure script, doing nothing
building
installing
npm ERR! install Couldn't read dependencies
npm ERR! Error: Invalid version: 0.1
npm ERR! at Object.module.exports.fixVersionField
(/nix/store/ih3sbklf4ncxgs84pdi34hq0lk8lrfwg-nodejs-0.10.32/lib/node_modules/npm/node_modules/read-package-json/node_modules/normalize-p$
ckage-data/lib/fixer.js:183:13)
npm ERR! at
/nix/store/ih3sbklf4ncxgs84pdi34hq0lk8lrfwg-nodejs-0.10.32/lib/node_modules/npm/node_modules/read-package-json/node_modules/normalize-package-data/lib/normalize.js:30:38
npm ERR! at Array.forEach (native)
npm ERR! at normalize
(/nix/store/ih3sbklf4ncxgs84pdi34hq0lk8lrfwg-nodejs-0.10.32/lib/node_modules/npm/node_modules/read-package-json/node_modules/normalize-package-data/lib/normalize.js$
29:15)
npm ERR! at final
(/nix/store/ih3sbklf4ncxgs84pdi34hq0lk8lrfwg-nodejs-0.10.32/lib/node_modules/npm/node_modules/read-package-json/read-json.js:342:33)
npm ERR! at then
(/nix/store/ih3sbklf4ncxgs84pdi34hq0lk8lrfwg-nodejs-0.10.32/lib/node_modules/npm/node_modules/read-package-json/read-json.js:126:33)
npm ERR! at
/nix/store/ih3sbklf4ncxgs84pdi34hq0lk8lrfwg-nodejs-0.10.32/lib/node_modules/npm/node_modules/read-package-json/read-json.js:316:48
npm ERR! at evalmachine.anonymous:207:20
npm ERR! at OpenReq.Req.done
(/nix/store/ih3sbklf4ncxgs84pdi34hq0lk8lrfwg-nodejs-0.10.32/lib/node_modules/npm/node_modules/graceful-fs/graceful-fs.js:141:5)
npm ERR! at OpenReq.done
(/nix/store/ih3sbklf4ncxgs84pdi34hq0lk8lrfwg-nodejs-0.10.32/lib/node_modules/npm/node_modules/graceful-fs/graceful-fs.js:61:22)
npm ERR! If you need help, you may report this *entire* log,
npm ERR! including the npm and node versions, at:
npm ERR! http://github.com/npm/npm/issues

npm ERR! System Linux 3.15.5
npm ERR! command
/nix/store/ih3sbklf4ncxgs84pdi34hq0lk8lrfwg-nodejs-0.10.32/bin/node
/nix/store/ih3sbklf4ncxgs84pdi34hq0lk8lrfwg-nodejs-0.10.32/bin/npm
--registry http://www.example.c$
m --nodedir=/nix/store/qf80rbp1rrcmhkibmia2p64gqd881yvx-node-sources
--production --ignore-scripts install
npm ERR! cwd 
/nix/store/aksz62alq8903cnp88iv0z36n0lrybjh-node-reacttest-0.1/lib/node_modules/reacttest
npm ERR! node -v v0.10.32
npm ERR! npm -v 1.4.28
npm ERR!
npm ERR! Additional logging details can be found in:
npm ERR! 
/nix/store/aksz62alq8903cnp88iv0z36n0lrybjh-node-reacttest-0.1/lib/node_modules/reacttest/npm-debug.log
npm ERR! not ok code 0
builder for `/nix/store/6g9vk21ag4rzjl13dnqnq3nabb1hgas0-node-reacttest-0.1.drv'
failed with exit code 1
error: build of
`/nix/store/6g9vk21ag4rzjl13dnqnq3nabb1hgas0-node-reacttest-0.1.drv'
failed

The package.json is as simple as:

{
name: reacttest,
version: 0.1,
dependencies: {react: *}
}


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


[Nix-dev] Concurrent garbage collection

2014-09-30 Thread Vincent Laporte
Hi,

Out of curiosity, I wonder what happens if the garbage collection
(nix-collect-garbage) is run while some other process builds a package
(nix-build or nix-env -i), both operating on the same store at the same
time.

In particular, the collector may remove a path that is a dependency of a
package being built. How do you address this issue?

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


Re: [Nix-dev] NixOS small channel

2014-09-30 Thread Anderson Torres
Yes! t is cool! :)

But, how about the other channels? I use the nixos-unstable here, can
I mix both, small and unstable, in my local machine?

2014-09-30 11:34 GMT-03:00 John Wiegley jo...@newartisans.com:
 John Wiegley jo...@newartisans.com writes:

 Here's what the machine was trying to do when nixos-rebuild got hung:

 https://gist.github.com/e2e69a41a2dfea23ebc3

 Just FYI: I left it running all night long, and it did at some point complete
 normally, so I guess whatever it was trying to do was just slow.

 John
 ___
 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] build server

2014-09-30 Thread Tim Barbour
Tim Barbour writes:
  I would like to set up a nix build server, particularly for use with nixops.
  Is there a definitive document about how to do this, including cross-platform
  builds (e.g. ARM) ?

Well, I got it working (no cross-build yet) using nix.buildMachines as 
described here:

  
http://sandervanderburg.blogspot.com.au/2013/04/setting-up-hydra-build-cluster-for_10.html

together with archive signing as described here:

  
http://functional-orbitz.blogspot.com.au/2013/05/setting-up-nixops-on-mac-os-x-with.html

I have yet to setup cross-platform builds. I know that I need to configure the 
cross-build
capability on the build server, and tell the client that the server has it (the 
easy part). So
far I have found these instructions:

  https://nixos.org/wiki/CrossCompiling

Tim
---
GPG public key available at: 
 http://phasechangeit.com/~trb/gpg-key  or 
 http://subkeys.pgp.net:11371
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


Re: [Nix-dev] Concurrent garbage collection

2014-09-30 Thread Shea Levy
Check out https://github.com/NixOS/nix/blob/master/src/libstore/gc.cc,
particularly addTempRoot (which is called by nix before any new nix path
is written or considered valid) and openGCLock.

The answer to what happens is that invariants are preserved, though
possibly at the cost of a long wait.

~Shea

On Wed, Oct 01, 2014 at 01:58:33AM +0100, Vincent Laporte wrote:
 Hi,
 
 Out of curiosity, I wonder what happens if the garbage collection
 (nix-collect-garbage) is run while some other process builds a package
 (nix-build or nix-env -i), both operating on the same store at the same
 time.
 
 In particular, the collector may remove a path that is a dependency of a
 package being built. How do you address this issue?
 
 Thanks,
 --
 Vincent.
 ___
 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