[Nix-commits] [NixOS/nixpkgs] a99e4f: scala: put docs in correct subdirectory

2017-03-12 Thread Rodney Lorrimar 
  Branch: refs/heads/release-17.03
  Home:   https://github.com/NixOS/nixpkgs
  Commit: a99e4f28e95f51a7869a2f95abd7a98bff7093b0
  
https://github.com/NixOS/nixpkgs/commit/a99e4f28e95f51a7869a2f95abd7a98bff7093b0
  Author: Rodney Lorrimar <d...@rodney.id.au>
  Date:   2017-03-12 (Sun, 12 Mar 2017)

  Changed paths:
M pkgs/development/compilers/scala/default.nix

  Log Message:
  ---
  scala: put docs in correct subdirectory

Under NixOS, /run/current-system/sw/share/doc was getting the license
file, etc.

(cherry picked from commit e333a71478730c63510b48131282f97b5e9c1af9)


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

Re: [Nix-dev] Remapping Console Key Bindings

2017-01-29 Thread Rodney Lorrimar 
I just realised that the previous advice doesn't work very well after a
reboot (no keys work except control).

A better way is:
1. dumpkeys > /etc/nixos/keys.map
2. Edit keys.map and change keycode 58 from Caps_Lock to Control.
3. In configuration.nix:  i18n.consoleKeyMap = ./keys.map;


Cheers,

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

Re: [Nix-dev] Remapping Console Key Bindings

2017-01-13 Thread Rodney Lorrimar 
Hi Mark,

This is what I do for caps lock as control key:

# configuration.nix
i18n.consoleKeyMap = (pkgs.writeText "keys.map" ''
  keymaps 0-255
  keycode 58 = Control
'');

It works for the US keyboard layout. If you use another layout, you
might want to edit the output of dumpkeys ("kbd" package) yourself, and
load that file as i18n.consoleKeyMap.


Cheers,

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

[Nix-commits] [NixOS/nixpkgs] de2f9d: haskellPackages.ghcjs-dom: Add overrides (#20474)

2016-11-21 Thread Rodney Lorrimar 
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: de2f9d67196c05ac9b4efedc7cc880ea1315f7bf
  
https://github.com/NixOS/nixpkgs/commit/de2f9d67196c05ac9b4efedc7cc880ea1315f7bf
  Author: Rodney Lorrimar <d...@rodney.id.au>
  Date:   2016-11-21 (Mon, 21 Nov 2016)

  Changed paths:
M pkgs/development/haskell-modules/configuration-ghcjs.nix

  Log Message:
  ---
  haskellPackages.ghcjs-dom: Add overrides (#20474)


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

Re: [Nix-dev] Building ghcjs-dom

2016-11-01 Thread Rodney Lorrimar 
Hi Ryan,

I have been having much fun with reflex-platform, so thanks for that.

I think it works because it's using ghcjs-dom 0.2.

If reflex-dom starts using ghcjs-dom 0.5, then we will need an answer
for this question.


Cheers,

Rodney


On Tue, Nov 01 2016, Ryan Trinkle wrote:

> Hi Rodney,
>
> You could take a look at
> https://github.com/reflex-frp/reflex-platform/blob/develop/default.nix .  I
> didn't realize upstream wasn't building, but I always keep reflex-platform
> building (and with binary caches available, see
> https://github.com/reflex-frp/reflex-platform/blob/develop/notes/NixOS.md
> ).  If there's anything in there that can be reused upstream, please feel
> free to take the code you need, and I'll help move things upstream however
> I can.
>
>
> Best,
> Ryan
>
> On Tue, Nov 1, 2016 at 5:10 AM, Rodney Lorrimar <d...@rodney.id.au> wrote:
>
>> Hello List,
>>
>> I would really like this package to build:
>>
>>   nix-build -A pkgs.haskell.packages.ghcjs.ghcjs-dom
>>
>> I found that the layout upstream has changed, so updated the overrides
>> accordingly (see patch below).
>>
>> My current problem is that it won't build without Cabal >= 1.24.
>>
>> If I use (addBuildTool super.ghcjs-dom-jsffi [ self.cabal-install ]),
>> then it builds Cabal 1.24 as javascript, which is not quite what I want.
>>
>> Does anyone know how I could make it build?
>>
>>
>> Cheers,
>>
>> Rodney
>>
>>
>> ---
>>  pkgs/development/haskell-modules/configuration-ghcjs.nix | 8 ++--
>>  1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/pkgs/development/haskell-modules/configuration-ghcjs.nix
>> b/pkgs/development/haskell-modules/configuration-ghcjs.nix
>> index c97296c..e56d7eb 100644
>> --- a/pkgs/development/haskell-modules/configuration-ghcjs.nix
>> +++ b/pkgs/development/haskell-modules/configuration-ghcjs.nix
>> @@ -88,12 +88,16 @@ self: super:
>>   }) {};
>>
>>ghcjs-dom = overrideCabal super.ghcjs-dom (drv: {
>> -libraryHaskellDepends = [ self.ghcjs-base ] ++
>> +libraryHaskellDepends = [ self.ghcjs-base self.ghcjs-dom-jsffi ] ++
>>removeLibraryHaskellDepends [
>> -"glib" "gtk" "gtk3" "webkitgtk" "webkitgtk3"
>> +"ghcjs-dom-jsaddle" "ghcjs-dom-webkit"
>>] drv.libraryHaskellDepends;
>>});
>>
>> +  ghcjs-dom-jsffi = overrideCabal super.ghcjs-dom-jsffi (drv: {
>> +libraryHaskellDepends = [ self.ghcjs-base self.text ];
>> +  });
>> +
>>ghc-paths = overrideCabal super.ghc-paths (drv: {
>>  patches = [ ./patches/ghc-paths-nix-ghcjs.patch ];
>>});
>> --
>> 2.10.1
>> ___
>> 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] Building ghcjs-dom

2016-11-01 Thread Rodney Lorrimar 
Hello List,

I would really like this package to build:

  nix-build -A pkgs.haskell.packages.ghcjs.ghcjs-dom

I found that the layout upstream has changed, so updated the overrides
accordingly (see patch below).

My current problem is that it won't build without Cabal >= 1.24.

If I use (addBuildTool super.ghcjs-dom-jsffi [ self.cabal-install ]),
then it builds Cabal 1.24 as javascript, which is not quite what I want.

Does anyone know how I could make it build?


Cheers,

Rodney


---
 pkgs/development/haskell-modules/configuration-ghcjs.nix | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/pkgs/development/haskell-modules/configuration-ghcjs.nix 
b/pkgs/development/haskell-modules/configuration-ghcjs.nix
index c97296c..e56d7eb 100644
--- a/pkgs/development/haskell-modules/configuration-ghcjs.nix
+++ b/pkgs/development/haskell-modules/configuration-ghcjs.nix
@@ -88,12 +88,16 @@ self: super:
  }) {};
 
   ghcjs-dom = overrideCabal super.ghcjs-dom (drv: {
-libraryHaskellDepends = [ self.ghcjs-base ] ++
+libraryHaskellDepends = [ self.ghcjs-base self.ghcjs-dom-jsffi ] ++
   removeLibraryHaskellDepends [
-"glib" "gtk" "gtk3" "webkitgtk" "webkitgtk3"
+"ghcjs-dom-jsaddle" "ghcjs-dom-webkit"
   ] drv.libraryHaskellDepends;
   });
 
+  ghcjs-dom-jsffi = overrideCabal super.ghcjs-dom-jsffi (drv: {
+libraryHaskellDepends = [ self.ghcjs-base self.text ];
+  });
+
   ghc-paths = overrideCabal super.ghc-paths (drv: {
 patches = [ ./patches/ghc-paths-nix-ghcjs.patch ];
   });
-- 
2.10.1
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] DBus and XMonad

2016-10-20 Thread Rodney Lorrimar 
On Wed, Oct 19 2016, Rodney Lorrimar wrote:
> My next problem is that gnome-terminal will no longer start:
>
> dbus-daemon[6158]: Activating via systemd: service 
> name='org.gnome.Terminal' unit='gnome-terminal-server.service'
> dbus-daemon[6158]: Activation via systemd failed for unit 
> 'gnome-terminal-server.service': Unit gnome-terminal-server.service not found.
>
> I have found that this is due to
> https://github.com/NixOS/nixpkgs/issues/19110
>
> My workaround for that problem is simply:
>
> ln -vsf /run/current-system/sw/lib/systemd/user/* ~/.config/systemd/user

Hello List,

The submitter of #19110 notes that another way to get the user service
to start would be to configure this:

systemd.packages = [ pkgs.gnome3.gnome_terminal ];

However I'm not sure whether it's a good solution. This would mean every
program which provides a dbus-activated systemd user service needs to
added to NixOS systemd.packages.


Cheers,

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

Re: [Nix-dev] DBus and XMonad

2016-10-20 Thread Rodney Lorrimar 
On Wed, Oct 19 2016, Ruben Astudillo wrote:

> On 19/10/16 08:19, Michael Alan Dorman wrote:
>> Rodney Lorrimar <d...@rodney.id.au> writes:
>>> 
>>> DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-jp8hFEY1dV,guid=c6e01dc144bda2ae4ca47c84580747a5;unix:abstract=/tmp/dbus-BjlHWWC2xz,guid=3733c1a431ad4cb309cc622a580747a5
>>>
>>> I'm not quite sure why the dbus socket was unavailable, but my solution
>>> was to enable services.dbus.socketActivated in configuration.nix.
>> 
>> I have seen this, too---manifesting as an taffybar not starting---though
>> I was doing some more investigation before I enquired.
>> 
>> I was able to roll back to a version that worked, and the clearly
>> distinguishing feature was that there was only one listing in
>> DBUS_SESSION_BUS_ADDRESS; and indeed, if I set the environment variable
>> when starting taffybar, it works fine.
>> 
>>   $ 
>> DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-jp8hFEY1dV,guid=c6e01dc144bda2ae4ca47c84580747a5
>>  taffybar 
>> 
>> Works just fine.
>> 
>> I guess the question I'm left with is whether the error is in the nix
>> configuration providing us with two entries in the variable, or in the
>> haskell dbus package in not handling it properly?
>
> I've noticed this too (and fixed the same way). Before in 16.03
> DBUS_SESSION_BUS_ADDRESS only listed one abstract path, thus I it isn't
> a fault on the haskell side of things.

Hi,

I guess it must have been a change in either dbus-launch or the dbus
daemon.

The current freedesktop.org implementation handles semicolons in
DBUS_SESSION_BUS_ADDRESS. It also adds the user bus socket to the list
of addresses (if it exists). I have reported these two things to the
haskell-dbus author.


Cheers,

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

[Nix-dev] DBus and XMonad

2016-10-19 Thread Rodney Lorrimar 
Hello List,

I've recently had some troubles starting up my gnome3 + XMonad desktop
session.

My first problem was that Taffybar and xmonad.hs were unable connect to
DBus with the following error:

connectSession: DBUS_SESSION_BUS_ADDRESS is missing or invalid.

The value of DBUS_SESSION_BUS_ADDRESS probably came from dbus-launch:


DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-jp8hFEY1dV,guid=c6e01dc144bda2ae4ca47c84580747a5;unix:abstract=/tmp/dbus-BjlHWWC2xz,guid=3733c1a431ad4cb309cc622a580747a5

I'm not quite sure why the dbus socket was unavailable, but my solution
was to enable services.dbus.socketActivated in configuration.nix.

An additional problem is that the haskell-dbus library won't check the
socket $XDG_RUNTIME_DIR/bus after the connection fails using
DBUS_SESSION_BUS_ADDRESS. So my workaround is to change the environment
before connecting:

let bus d = "unix:path=" ++ d ++ "/bus"
maddr <- fmap bus <$> lookupEnv "XDG_RUNTIME_DIR"
case maddr of
  Just addr -> setEnv "DBUS_SESSION_BUS_ADDRESS" addr
  Nothing -> return ()

This allows me to start xmonad and taffybar.

My next problem is that gnome-terminal will no longer start:

dbus-daemon[6158]: Activating via systemd: service 
name='org.gnome.Terminal' unit='gnome-terminal-server.service'
dbus-daemon[6158]: Activation via systemd failed for unit 
'gnome-terminal-server.service': Unit gnome-terminal-server.service not found.

I have found that this is due to
https://github.com/NixOS/nixpkgs/issues/19110

My workaround for that problem is simply:

ln -vsf /run/current-system/sw/lib/systemd/user/* ~/.config/systemd/user

Now I have a working desktop session again. I have posted this in case
anyone else has similar difficulties.

In future, having a socket-activated dbus would allow the NixOS xsession
script to be partly replaced by systemd. I think that could be quite
exciting.


Cheers,

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

[Nix-commits] [NixOS/nixpkgs] 246c93: pump.io: git-2015-11-09 -> 1.0.0

2016-10-10 Thread Rodney Lorrimar 
  Branch: refs/heads/release-16.09
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 246c9375996e3bf5af8c1f2f8179390ee63a950a
  
https://github.com/NixOS/nixpkgs/commit/246c9375996e3bf5af8c1f2f8179390ee63a950a
  Author: Rodney Lorrimar <d...@rodney.id.au>
  Date:   2016-10-10 (Mon, 10 Oct 2016)

  Changed paths:
A pkgs/servers/web-apps/pump.io/composition.nix
M pkgs/servers/web-apps/pump.io/default.nix
A pkgs/servers/web-apps/pump.io/generate.sh
M pkgs/servers/web-apps/pump.io/node-packages.json
M pkgs/servers/web-apps/pump.io/node-packages.nix

  Log Message:
  ---
  pump.io: git-2015-11-09 -> 1.0.0

cherry-pick from 983f6819c7d0bf9692df591f2ce25e2122a24434 because of security
issue.


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

[Nix-dev] Three questions about node2nix

2016-09-16 Thread Rodney Lorrimar 
Hello List and Sander,

It's nice to see the all good work done to keep up with the node.js
enchilada. I have a few questions about what this means for packages in
the nixpkgs collection.

1. Should pkgs/top-level/node-packages.{nix,json} be removed now?

2. Because I would like to update bower2nix from 3.0.1 -> 3.1.0, I run
   pkgs/development/node-packages/generate.sh.

   (I noticed that this script could include the special nix-shell
   shebang to ensure node2nix is available when running the script).

   Is it possible/desirable to limit version changes to just bower2nix
   and maybe its direct dependencies -- to minimize possible disruption
   to other nodePackages. This whole topic is a can of worms of course.

3. I "maintain" another node.js package -- pump.io -- which I'm unsure
   what to do with. I was probably too eager to PR this into the nixpkgs
   collection in the first place.

   It recently had a 1.0.0 release which contains security-relevant
   fixes.

   If I update to 1.0.0 it means dumping another 112K of fluff into our
   git repo. This might be OK if it were for a decent language's package
   system, or if the software had lots of users.

   I think the best course of action is to remove the pump.io module and
   package from the main nixpkgs collection. Then maybe put it back when
   it's possible to generate derivations directly from a shrinkwrap.json.


Cheers,

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

[Nix-commits] [NixOS/nixpkgs] 0227c9: nodePackages.bower2nix: Add back PATH wrapping

2016-09-15 Thread Rodney Lorrimar 
  Branch: refs/heads/release-16.09
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 0227c99c1582ce362449f086502037605fe6cf07
  
https://github.com/NixOS/nixpkgs/commit/0227c99c1582ce362449f086502037605fe6cf07
  Author: Rodney Lorrimar <d...@rodney.id.au>
  Date:   2016-09-15 (Thu, 15 Sep 2016)

  Changed paths:
M pkgs/development/node-packages/default-v4.nix
M pkgs/development/node-packages/default-v5.nix
M pkgs/development/node-packages/default-v6.nix

  Log Message:
  ---
  nodePackages.bower2nix: Add back PATH wrapping

bower2nix and fetch-bower need git in the PATH to operate. This wrapping
got lost with the nodePackages updates.

(Fixes #18454)

(cherry picked from commit 952c477f901f35a99758bcc8fdf8b685ad8fa3e0)


  Commit: 35a87e41d59f9e7d0479a6c7a0eff787b6d29ed5
  
https://github.com/NixOS/nixpkgs/commit/35a87e41d59f9e7d0479a6c7a0eff787b6d29ed5
  Author: Rodney Lorrimar <d...@rodney.id.au>
  Date:   2016-09-15 (Thu, 15 Sep 2016)

  Changed paths:
M pkgs/development/node-packages/node-packages-v4.nix
M pkgs/development/node-packages/node-packages-v5.nix
M pkgs/top-level/node-packages-generated.nix

  Log Message:
  ---
  nodePackages.bower2nix: 3.0.1 -> 3.1.1

(cherry picked from commit 131b8d4edb39d302db64ff284a7f5863d2d53522)


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

Re: [Nix-dev] Three questions about node2nix

2016-09-13 Thread Rodney Lorrimar 
Hi Sander,

(Apologies to nix-dev who didn't receive my original message because I
sent it with the wrong address)

On Sun, Sep 11 2016, Sander van der Burg wrote:

> 1. Not yet, it will break a couple of non-NPM packages that have
> dependencies on them. I'm still in the progress of replacing them, but this
> will take some time. Once these packages have been fixed, the old npm2nix
> package set is obsolete.

Ah yes I see now -- I was only looking in all-packages.nix.

> 2. At the moment no. Ideally, it would be better to have a more
> sophisticated approach that would only regenerate affected pieces while
> leaving others intact. I believe this is something nixfromnpm implements,
> but node2nix does not having something like that.

Maybe, it seems like a lot of work to implement. IMO, the ideal
situation is that each node.js program is nix-shrinkwrapped, but without
the enormous amount of fluff in the main repo (fluff in auxiliary repos
would be fine).

> 3. This is indeed one the packages I have encountered that need to be
> fixed. Unfortunately, one of node2nix's undesired side effects is that is
> generates a lot of code churn when updating the package set. I guess for
> now we just have to live with it.

I'm not sure whether it's worth the trouble, but could the code churn be
mitigated slightly by using a compact generated format -- e.g.

{ buildNP, np }:
buildNP { name = "generated-node-packages"; parts = [
(np "colors" "0.6.0-1" "6dbb68ceb8bc60f2b313dcc5ce1599f06d19e67a")
(np "ejs" "2.3.4" "3c76caa09664b3583b0037af9dc136e79ec68b98")
# ...
]; }


> If it's ok to remove pump.io, then I will do it. We can always readd it
> later.

I'm pretty sure it's OK to remove pump.io. I can make the PR and add
something to the release notes about it.

Cheers,

Rodney


> On Sun, Sep 11, 2016 at 2:00 PM, Rodney Lorrimar <rod...@rodney.id.au>
> wrote:
>
>> Hello List and Sander,
>>
>> It's nice to see the all good work done to keep up with the node.js
>> enchilada. I have a few questions about what this means for packages in
>> the nixpkgs collection.
>>
>> 1. Should pkgs/top-level/node-packages.{nix,json} be removed now?
>>
>> 2. Because I would like to update bower2nix from 3.0.1 -> 3.1.0, I run
>>pkgs/development/node-packages/generate.sh.
>>
>>(I noticed that this script could include the special nix-shell
>>shebang to ensure node2nix is available when running the script).
>>
>>Is it possible/desirable to limit version changes to just bower2nix
>>and maybe its direct dependencies -- to minimize possible disruption
>>to other nodePackages. This whole topic is a can of worms of course.
>>
>> 3. I "maintain" another node.js package -- pump.io -- which I'm unsure
>>what to do with. I was probably too eager to PR this into the nixpkgs
>>collection in the first place.
>>
>>It recently had a 1.0.0 release which contains security-relevant
>>fixes.
>>
>>If I update to 1.0.0 it means dumping another 112K of fluff into our
>>git repo. This might be OK if it were for a decent language's package
>>system, or if the software had lots of users.
>>
>>I think the best course of action is to remove the pump.io module and
>>package from the main nixpkgs collection. Then maybe put it back when
>>it's possible to generate derivations directly from a shrinkwrap.json.
>>
>>
>> Cheers,
>>
>> Rodney
>>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-commits] [NixOS/nixpkgs] 553750: nixos/tests/pump.io: Fix systemd unit config

2016-09-08 Thread Rodney Lorrimar 
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 5537503dec1af5dfa6392b7673420042878d659f
  
https://github.com/NixOS/nixpkgs/commit/5537503dec1af5dfa6392b7673420042878d659f
  Author: Rodney Lorrimar <d...@rodney.id.au>
  Date:   2016-09-08 (Thu, 08 Sep 2016)

  Changed paths:
M nixos/tests/pump.io.nix

  Log Message:
  ---
  nixos/tests/pump.io: Fix systemd unit config

Ref #18209

(cherry picked from commit 3fd603c02f339778c8ea24c2fadacb91185eb1c7)


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

Re: [Nix-dev] Locking issues with Nix

2016-08-17 Thread Rodney Lorrimar 
On Tue, Aug 09 2016, Guillaume Maudoux (Layus) wrote:
> With my current version of nix, I observe the following behaviour after some 
> calls to nix:
> The command hangs forever.
>
>  $ nix-build ...
> these derivations will be built:
>   /nix/store/-.drv
> waiting for locks or build slots...

I was experiencing such problems in June, but can't exactly remember
what I did to fix it. The waiting for build slots message occurred
because the nix-daemon processes were impossible to kill.

I had these messages in my log:

  Jun 07 14:14:16 aurora kernel: INFO: task nix-daemon:8376 blocked for more 
than 120 seconds.

I think it was something that I had mounted because df would also hang
in the same way.

Sorry for the vagueness, hope it gives you a clue.


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

Re: [Nix-dev] Windows updates

2016-08-11 Thread Rodney Lorrimar 
I have to agree that it's awesome. Two amazing examples which come to
mind are:

1. Using nix for reproducible Windows builds within Linux, including a
   derivation which installs Windows from an iso into a VM
   image. (Unfortunately I was never able to try this because I couldn't
   obtain an iso and license key).

2. The NixOS test suite. In nixpkgs/nixos/tests/quake3.nix there is a
   test which actually starts a quake3 server with bots and joins two
   separate players into the game. It checks that the players joined
   successfully and then takes screenshots of players being fragged by
   bots.

So my question is, why play games yourself on Windows when you can
automate it with Nix?
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Building with default.nix

2016-08-11 Thread Rodney Lorrimar 
Le mardi 09 août 2016 à 18:04 +0200, Lancelot SIX a écrit:
> You could have a `shell.nix` file as follows:
> 
> import ./default.nix { sampleproject = { outPath = ""; name = 
> "sampleproject"; } ; }
> 
> This is hacky but with that you will not copy the project tree into
> the nix store when runninx `nix-shell` (this will only be done when
> running `nix-build`). I think this is half way to what you are looking
> for.
> 
> Hope this helps.

Hi,

It does help a little thanks, except in my real project, the shell
derivation depends on the project sources to set up some tools.

I was (ab)using the src.outPath attribute to avoid copying of src into
the nix store. Like this:

  # testScript is a buildInput of the shell derivation
  testScript = mkDerivation {
name = "realproject-test";
src = realproject.outPath + "/scripts/test";
buildCommand = "mkdir -p $out/bin && cp $src $out/bin/test";
  };

I don't mind copying the project sources into the nix store before
starting a nix-shell. In fact it's a good thing, if the shell depends on
project sources.

But I would like to filter the files copied so that it's just
git-tracked files and not random cruft.

I saw a recent commit 39e689e "cleanSource: filter out also nix result
symlinks (#16120)" which seems to address the same issue.


Cheers,

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

Re: [Nix-dev] Locking issues with Nix

2016-08-11 Thread Rodney Lorrimar 
Just to CC nix-dev, I added a comment here:
https://github.com/NixOS/nix/issues/1015#issuecomment-239088681
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Building with default.nix

2016-08-09 Thread Rodney Lorrimar 
Hello nix-dev,

I was wondering, what is the best way to develop a project outside of
nixpkgs? My current method is something like this:

# default.nix
{ sampleproject ? { outPath = ./.; name = "sampleproject"; }
, pkgs ? import  {}
}:
with pkgs.python35Packages;
buildPythonPackage rec {
  name = "sampleproject-${version}";
  version = "1.2.0";
  src = [ sampleproject ];
  propagatedBuildInputs = [ peppercorn ];
};

(Full project example here: https://github.com/rvl/sampleproject)

In many ways it works well, but I'm not entirely happy.

The problem is that my entire work tree (and all the accumulated project
cruft) gets copied into the nix store every time I run nix-build or
nix-shell. This is slow and also prints the scary "may run out of
memory" warning.

Is there a function to load only the tracked files from a git work tree?
Ideally this function would result in same store path if the files are
the same, so nothing need be rebuilt if no sources changed.


Cheers,

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