[Nix-commits] [NixOS/nixpkgs] 35e571: elasticsearch: 5.4.0 -> 5.4.2

[Bas van Dijk]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 35e5719fe9ed67b1502b79616c51fd4211e51599
  
https://github.com/NixOS/nixpkgs/commit/35e5719fe9ed67b1502b79616c51fd4211e51599
  Author: Bas van Dijk <v.dijk@gmail.com>
  Date:   2017-06-26 (Mon, 26 Jun 2017)

  Changed paths:
M pkgs/development/tools/misc/kibana/5.x.nix
M pkgs/misc/logging/beats/default.nix
M pkgs/servers/search/elasticsearch/5.x.nix
M pkgs/tools/misc/logstash/5.x.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  elasticsearch: 5.4.0 -> 5.4.2


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

Re: [Nix-dev] How to build a Haskell binding to a C++ library (OpenCV) on OS X

[Bas van Dijk]

Thanks Vincent, you are spot on!

I went with the following change:

https://github.com/LumiGuide/haskell-opencv/commit/6b78bc4c431d693b0bc828cc86708882a26f777c

Bas

On 19 June 2017 at 17:00, Vincent Laporte  wrote:

> Hi,
>
> Notice that if you replace the two occurrences of ‘g++’ by ‘clang++’ in
> the file ‘opencv/Setup.hs’, then ‘nix-build’ succeeds.
>
> This issue might be reported upstream: they apparently need a configure
> step to select the correct name of the C++ compiler.
>
> The following patch also appears to make ‘nix-build’ work.
>
> Regards,
> --
> Vincent.
>
> ```
> diff --git a/opencv/Setup.hs b/opencv/Setup.hs
> index 031daa1..3c92176 100644
> --- a/opencv/Setup.hs
> +++ b/opencv/Setup.hs
> @@ -3,6 +3,6 @@ import System.Environment ( getArgs )
>
>  main = do
>  args <- getArgs
> -let args' | "configure" `elem` args = args ++ ["--with-gcc","g++",
> "--with-ld","g++"]
> +let args' | "configure" `elem` args = args
>| otherwise   = args
>  defaultMainArgs args'
> diff --git a/opencv/opencv.nix b/opencv/opencv.nix
> index a28674c..80ed995 100644
> --- a/opencv/opencv.nix
> +++ b/opencv/opencv.nix
> @@ -103,8 +103,8 @@ mkDerivation ({
>libraryPkgconfigDepends = [ opencv3 ];
>
>configureFlags =
> -[ "--with-gcc=g++"
> -  "--with-ld=g++"
> +[ "--with-gcc=${stdenv.cc}/bin/c++"
> +  "--with-ld=${stdenv.cc}/bin/c++"
>  ];
>
>hardeningDisable = [ "bindnow" ];
> ```
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] How to build a Haskell binding to a C++ library (OpenCV) on OS X

[Bas van Dijk]

I forgot to mention that the following does work:

  git clone https://github.com/LumiGuide/haskell-opencv.git
  cd opencv
  nix-shell
  cabal configure -v
  cabal build

In this case cabal is using the g++ from /usr/bin instead of the one from
the nix store since I'm using an impure nix-shell:

  Using gcc version 4.2.1 given by user at: /usr/bin/g++

Bas

On 18 June 2017 at 21:47, Bas van Dijk <v.dijk@gmail.com> wrote:

> Good evening,
>
> I'm trying to build our Haskell binding to the OpenCV C++ library on OS X.
> The following commands should do the job:
>
>   git clone https://github.com/LumiGuide/haskell-opencv.git
>   cd opencv
>   nix-build
>
> Unfortunately it fails during the configure phase with:
>
>   Setup: Cannot find the program 'gcc'.
>   User-specified path 'g++' does not refer
>   to an executable and the program is not on the system path.
>
> If I add gcc to the build dependencies of opencv/opencv.nix using:
>
>   buildDepends = [ gcc ];
>
> and invoke nix-build again I get a different error:
>
>   Setup: Missing dependencies on foreign libraries:
>   * Missing C libraries: stdc++, opencv_stitching, opencv_superres,
>   opencv_videostab, opencv_aruco, opencv_bgsegm, opencv_bioinspired,
>   opencv_ccalib, opencv_dpm, opencv_freetype, opencv_fuzzy,
>   opencv_line_descriptor, opencv_optflow, opencv_reg, opencv_saliency,
>   opencv_stereo, opencv_structured_light,
> opencv_phase_unwrapping, opencv_rgbd,
>   opencv_surface_matching, opencv_tracking, opencv_datasets, opencv_text,
>   opencv_face, opencv_plot, opencv_dnn, opencv_xfeatures2d, opencv_shape,
>   opencv_video, opencv_ximgproc, opencv_calib3d, opencv_features2d,
>   opencv_flann, opencv_xobjdetect, opencv_objdetect, opencv_ml,
> opencv_xphoto,
>   opencv_highgui, opencv_videoio, opencv_imgcodecs, opencv_photo,
>   opencv_imgproc, opencv_core
>   This problem can usually be solved by installing the system packages that
>   provide these libraries (you may need the "-dev" versions). If the
> libraries
>   are already installed but in a non-standard location then you can use the
>   flags --extra-include-dirs= and --extra-lib-dirs= to specify where they
> are.
>
> Any ideas how to get this working?
>
> Regards,
>
> Bas
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] How to build a Haskell binding to a C++ library (OpenCV) on OS X

[Bas van Dijk]

Good evening,

I'm trying to build our Haskell binding to the OpenCV C++ library on OS X.
The following commands should do the job:

  git clone https://github.com/LumiGuide/haskell-opencv.git
  cd opencv
  nix-build

Unfortunately it fails during the configure phase with:

  Setup: Cannot find the program 'gcc'.
  User-specified path 'g++' does not refer
  to an executable and the program is not on the system path.

If I add gcc to the build dependencies of opencv/opencv.nix using:

  buildDepends = [ gcc ];

and invoke nix-build again I get a different error:

  Setup: Missing dependencies on foreign libraries:
  * Missing C libraries: stdc++, opencv_stitching, opencv_superres,
  opencv_videostab, opencv_aruco, opencv_bgsegm, opencv_bioinspired,
  opencv_ccalib, opencv_dpm, opencv_freetype, opencv_fuzzy,
  opencv_line_descriptor, opencv_optflow, opencv_reg, opencv_saliency,
  opencv_stereo, opencv_structured_light,
opencv_phase_unwrapping, opencv_rgbd,
  opencv_surface_matching, opencv_tracking, opencv_datasets, opencv_text,
  opencv_face, opencv_plot, opencv_dnn, opencv_xfeatures2d, opencv_shape,
  opencv_video, opencv_ximgproc, opencv_calib3d, opencv_features2d,
  opencv_flann, opencv_xobjdetect, opencv_objdetect, opencv_ml,
opencv_xphoto,
  opencv_highgui, opencv_videoio, opencv_imgcodecs, opencv_photo,
  opencv_imgproc, opencv_core
  This problem can usually be solved by installing the system packages that
  provide these libraries (you may need the "-dev" versions). If the
libraries
  are already installed but in a non-standard location then you can use the
  flags --extra-include-dirs= and --extra-lib-dirs= to specify where they
are.

Any ideas how to get this working?

Regards,

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

[Nix-commits] [NixOS/nixpkgs] 2444ea: ELK: update kibana and the elastic beats to 5.4 (#...

[Bas van Dijk]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 2444eab485ed6631fea02577b0d21c808405fd5e
  
https://github.com/NixOS/nixpkgs/commit/2444eab485ed6631fea02577b0d21c808405fd5e
  Author: Bas van Dijk <v.dijk@gmail.com>
  Date:   2017-06-13 (Tue, 13 Jun 2017)

  Changed paths:
M nixos/modules/services/logging/logstash.nix
M nixos/modules/services/search/kibana.nix
A nixos/tests/elk.nix
R nixos/tests/logstash.nix
A pkgs/development/tools/misc/kibana/5.x.nix
A pkgs/misc/logging/beats/default.nix
R pkgs/misc/logging/filebeat/default.nix
R pkgs/misc/logging/heartbeat/default.nix
R pkgs/misc/logging/metricbeat/default.nix
R pkgs/misc/logging/packetbeat/default.nix
M pkgs/servers/search/elasticsearch/5.x.nix
A pkgs/tools/misc/logstash/5.x.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  ELK: update kibana and the elastic beats to 5.4 (#26252)

* Add kibana5 and logstash5
* Upgrade the elastic beats to 5.4
* Make sure all elastic products use the same version
  (see elk5Version)
* Add a test for the ELK stack


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

Re: [Nix-dev] logstash-5.4.0 ruby issue

[Bas van Dijk]

FYI: I fixed the issue.

On 30 May 2017 at 20:56, Bas van Dijk <v.dijk@gmail.com> wrote:

> Hi Nixers, are there any Ruby devs on this list who can help me package
> logstash-5.4.0. See:
>
>   https://github.com/NixOS/nixpkgs/pull/26252
>
> Reproducing the issue is as easy as checking out the elk5 branch of
>
>   g...@github.com:LumiGuide/nixpkgs.git
>
> and running:
>
>   nix-build nixos/tests/elk.nix.
>
> Thanks,
>
> Bas
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] logstash-5.4.0 ruby issue

[Bas van Dijk]

Hi Nixers, are there any Ruby devs on this list who can help me package
logstash-5.4.0. See:

  https://github.com/NixOS/nixpkgs/pull/26252

Reproducing the issue is as easy as checking out the elk5 branch of

  g...@github.com:LumiGuide/nixpkgs.git

and running:

  nix-build nixos/tests/elk.nix.

Thanks,

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

Re: [Nix-dev] why has each revision / generation not a own configuration.nix

[Bas van Dijk]

Op 16 mei 2017 18:43 schreef "zimbatm" :

How do you find back which git revision was used to produce a given NixOS
profile?

At LumiGuide I use the following module for that:

{ config, lib, ... }:

with lib;

{
  options.system = {
lumiRevision = mkOption {
  internal = true;
  type = types.str;
  default = lib.commitIdFromGitRepo ;
  description = ''
The git revision of the lumi repository that was used to
configure this machine.
  '';
};
  };
  config = {
environment.etc."lumi-revision".text = config.system.lumiRevision;

system.nixosLabel = "nixos-" + config.system.nixosVersion
  + "_lumi-" + config.system.lumiRevision;
  };
}


On Sat, 13 May 2017, 14:34 Profpatsch,  wrote:

> On 17-05-13 12:25pm, Layus wrote:
> > On 13/05/17 12:14, Leo Gaspard wrote:
> > See the previous ML discussion on that topic where we proposed to keep it
> > opt-in, but with an apt-out config line in the default configuration.nix.
> > This may already be implemented.
>
> The ones who don’t keep their sources under version control
> deserve their eventual fate.
>
> Seriously, copying & pasting default templates around
> is not a good idea.
> I haven’t seen a “default” configuration.nix (whatever that is)
> in more than 1.5 years.
>
> We already have the firewall enabled by default,
> even that has been a major discussion,
> because for everything that is implicit
> you have to remember to turn it off.
>
> --
> Proudly written in Mutt with Vim on NixOS.
> Q: Why is this email five sentences or less?
> A: http://five.sentenc.es
> May take up to five days to read your message. If it’s urgent, call me.
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>

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

[Nix-commits] [NixOS/nixpkgs] 977b32: wordpress: replace the dbPassword option with dbPa...

[Bas van Dijk]

  Branch: refs/heads/release-17.03
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 977b320d5d27d253efedc55a56e96149b6ae1099
  
https://github.com/NixOS/nixpkgs/commit/977b320d5d27d253efedc55a56e96149b6ae1099
  Author: Bas van Dijk <v.dijk@gmail.com>
  Date:   2017-05-05 (Fri, 05 May 2017)

  Changed paths:
M nixos/modules/services/web-servers/apache-httpd/wordpress.nix

  Log Message:
  ---
  wordpress: replace the dbPassword option with dbPasswordFile

We shouldn't force users to store passwords in the world-readable Nix store.


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

[Nix-commits] [NixOS/nixpkgs] 28dc5c: postgresql: fix build on darwin

[Bas van Dijk]

  Branch: refs/heads/release-16.09
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 28dc5c7d221ac0e13b8f5761459829fdf43a223c
  
https://github.com/NixOS/nixpkgs/commit/28dc5c7d221ac0e13b8f5761459829fdf43a223c
  Author: Bas van Dijk <v.dijk@gmail.com>
  Date:   2017-05-03 (Wed, 03 May 2017)

  Changed paths:
M pkgs/servers/sql/postgresql/default.nix

  Log Message:
  ---
  postgresql: fix build on darwin

(cherry picked from commit 1f95524ab5bf7dee448afe646a78712d70c5ca2a)


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

[Nix-commits] [NixOS/nixpkgs] 1c0a0c: wordpress: 4.7.3 -> 4.7.4

[Bas van Dijk]

  Branch: refs/heads/release-17.03
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 1c0a0c027c8cea5ffeea1c074570eff542299acd
  
https://github.com/NixOS/nixpkgs/commit/1c0a0c027c8cea5ffeea1c074570eff542299acd
  Author: Bas van Dijk <v.dijk@gmail.com>
  Date:   2017-04-27 (Thu, 27 Apr 2017)

  Changed paths:
M pkgs/servers/web-apps/wordpress/default.nix

  Log Message:
  ---
  wordpress: 4.7.3 -> 4.7.4

See: https://wordpress.org/news/2017/04/wordpress-4-7-4/
(cherry picked from commit b9371e83e40ee833b25fc8855f003c2cc3508d86)


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

[Nix-commits] [NixOS/nixpkgs] b9371e: wordpress: 4.7.3 -> 4.7.4

[Bas van Dijk]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: b9371e83e40ee833b25fc8855f003c2cc3508d86
  
https://github.com/NixOS/nixpkgs/commit/b9371e83e40ee833b25fc8855f003c2cc3508d86
  Author: Bas van Dijk <v.dijk@gmail.com>
  Date:   2017-04-27 (Thu, 27 Apr 2017)

  Changed paths:
M pkgs/servers/web-apps/wordpress/default.nix

  Log Message:
  ---
  wordpress: 4.7.3 -> 4.7.4

See: https://wordpress.org/news/2017/04/wordpress-4-7-4/


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

Re: [Nix-dev] Failure to boot after hibernate

[Bas van Dijk]

On 24 April 2017 at 12:35, Linus Heckemann  wrote:
> If it's systemd-boot, which it probably is, it does in fact allow
> editing unless you disable it in its config — I think you just press E
> to edit the command line.

I actually disabled that (I believe for security reasons) using:

  boot.loader.systemd-boot.editor = false;

Fortunately I was able to boot my system using a NixOS USB stick,
mount the boot partition and set "editor 1" in
/boot/loader/loader.conf. After that I edited the command line with
"hibernate=no" as Danylo suggested.

Now I'm typing this email on my correctly booted system. Thanks everybody!

Bas

P.S.
Now I just need to figure out how to disable hibernation...
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Failure to boot after hibernate

[Bas van Dijk]

On 24 April 2017 at 12:20, Danylo Hlynskyi <abcz2.upr...@gmail.com> wrote:
> Probably too late, but can you boot with hibernate=no kernel parameter?

Hi Danylo, thanks. Unfortunately I can't edit the kernel parameters.
My system is using the default EFI loader and isn't using grub which
does allow editing the kernel command line.

> In general I found this[1] article great on debugging suspend/hibernate
> issues on Nixos (which I had twice).
>
> [1] https://wiki.ubuntu.com/DebuggingKernelSuspend

Thanks, I will study it.

My plan is to boot from a NixOS USB stick, mount the file systems and
then delete/modify some file that stores the state that determines
whether the system is hibernated or not. Any idea which file is
storing that information?

Bas

> 2017-04-24 2:20 GMT+03:00 Bas van Dijk <v.dijk@gmail.com>:
>>
>> I made a few pictures and a video of the boot process:
>> https://goo.gl/photos/vrAkb5TFmZZ1J9kn9. In the video you can see that
>> after I've input my passphrase the following lines are printed before
>> the blinking cursor appears:
>>
>>   killall: cryptsetup: no process killed
>>   starting device mapper and LVM...
>> 2 logical volume(s) in volume group "MyStorage" now active
>>   _
>>
>> Bas
>>
>>
>> On 24 April 2017 at 00:48, Bas van Dijk <v.dijk@gmail.com> wrote:
>> > Dear list,
>> >
>> > Two weeks ago I installed NixOS natively on my Mac Book Pro (I was
>> > running NixOS in virtualbox before that). It ren well for two weeks
>> > but today I hit a snag.
>> >
>> > I was doing some work when my battery power became too low. Then I
>> > believe my system hibernated (suspended to disk) before it shut down.
>> > Note that I've set:
>> >
>> >   powerManagement.enable = true;
>> >
>> > Now when I boot my system it asks me for the encryption passphrase for
>> > my LUKS drive. After I enter it I see a cursor blinking for a few
>> > seconds before it freezes. After that my system is unresponsive.
>> >
>> > As mentioned I have an encrypted LUKS drive. On top of that I have a
>> > LVM root and swap volume. So what I believe has happened is that my
>> > system saved its memory to the encrypted swap before it shut down. Now
>> > when it boots up it tries to load that memory back in but fails for
>> > some reason. I guess the trouble starts somewhere here:
>> >
>> >
>> > https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/system/boot/stage-1-init.sh#L407
>> >
>> > Note that I have not set: boot.resumeDevice. Also note that I have set:
>> >
>> >   swapDevices = [ { device = "/dev/disk/by-label/swap"; } ];
>> >
>> > Any idea how to fix this?
>> >
>> > Bas
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Failure to boot after hibernate

[Bas van Dijk]

I made a few pictures and a video of the boot process:
https://goo.gl/photos/vrAkb5TFmZZ1J9kn9. In the video you can see that
after I've input my passphrase the following lines are printed before
the blinking cursor appears:

  killall: cryptsetup: no process killed
  starting device mapper and LVM...
2 logical volume(s) in volume group "MyStorage" now active
  _

Bas


On 24 April 2017 at 00:48, Bas van Dijk <v.dijk@gmail.com> wrote:
> Dear list,
>
> Two weeks ago I installed NixOS natively on my Mac Book Pro (I was
> running NixOS in virtualbox before that). It ren well for two weeks
> but today I hit a snag.
>
> I was doing some work when my battery power became too low. Then I
> believe my system hibernated (suspended to disk) before it shut down.
> Note that I've set:
>
>   powerManagement.enable = true;
>
> Now when I boot my system it asks me for the encryption passphrase for
> my LUKS drive. After I enter it I see a cursor blinking for a few
> seconds before it freezes. After that my system is unresponsive.
>
> As mentioned I have an encrypted LUKS drive. On top of that I have a
> LVM root and swap volume. So what I believe has happened is that my
> system saved its memory to the encrypted swap before it shut down. Now
> when it boots up it tries to load that memory back in but fails for
> some reason. I guess the trouble starts somewhere here:
>
>   
> https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/system/boot/stage-1-init.sh#L407
>
> Note that I have not set: boot.resumeDevice. Also note that I have set:
>
>   swapDevices = [ { device = "/dev/disk/by-label/swap"; } ];
>
> Any idea how to fix this?
>
> Bas
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Failure to boot after hibernate

[Bas van Dijk]

Dear list,

Two weeks ago I installed NixOS natively on my Mac Book Pro (I was
running NixOS in virtualbox before that). It ren well for two weeks
but today I hit a snag.

I was doing some work when my battery power became too low. Then I
believe my system hibernated (suspended to disk) before it shut down.
Note that I've set:

  powerManagement.enable = true;

Now when I boot my system it asks me for the encryption passphrase for
my LUKS drive. After I enter it I see a cursor blinking for a few
seconds before it freezes. After that my system is unresponsive.

As mentioned I have an encrypted LUKS drive. On top of that I have a
LVM root and swap volume. So what I believe has happened is that my
system saved its memory to the encrypted swap before it shut down. Now
when it boots up it tries to load that memory back in but fails for
some reason. I guess the trouble starts somewhere here:

  
https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/system/boot/stage-1-init.sh#L407

Note that I have not set: boot.resumeDevice. Also note that I have set:

  swapDevices = [ { device = "/dev/disk/by-label/swap"; } ];

Any idea how to fix this?

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

[Nix-commits] [NixOS/nixpkgs] 01a8de: avahi-daemon: refactored using some abstraction

[Bas van Dijk]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 01a8de97eb2aab98e6e9a7330bf99f4fe4844d2a
  
https://github.com/NixOS/nixpkgs/commit/01a8de97eb2aab98e6e9a7330bf99f4fe4844d2a
  Author: Bas van Dijk <v.dijk@gmail.com>
  Date:   2017-04-09 (Sun, 09 Apr 2017)

  Changed paths:
M nixos/modules/services/networking/avahi-daemon.nix

  Log Message:
  ---
  avahi-daemon: refactored using some abstraction


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

[Nix-commits] [NixOS/nixpkgs] fd8a23: strongswan: 5.5.1 -> 5.5.2

[Bas van Dijk]

  Branch: refs/heads/release-17.03
  Home:   https://github.com/NixOS/nixpkgs
  Commit: fd8a2385985ee647d4af33672eeb920d7fa6db98
  
https://github.com/NixOS/nixpkgs/commit/fd8a2385985ee647d4af33672eeb920d7fa6db98
  Author: Bas van Dijk <v.dijk@gmail.com>
  Date:   2017-04-06 (Thu, 06 Apr 2017)

  Changed paths:
M pkgs/tools/networking/strongswan/default.nix

  Log Message:
  ---
  strongswan: 5.5.1 -> 5.5.2

(cherry picked from commit bd948391e6196fbd4e1e666ddd96393f57cdb214)


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

[Nix-commits] [NixOS/nixpkgs] bd9483: strongswan: 5.5.1 -> 5.5.2

[Bas van Dijk]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: bd948391e6196fbd4e1e666ddd96393f57cdb214
  
https://github.com/NixOS/nixpkgs/commit/bd948391e6196fbd4e1e666ddd96393f57cdb214
  Author: Bas van Dijk <v.dijk@gmail.com>
  Date:   2017-04-06 (Thu, 06 Apr 2017)

  Changed paths:
M pkgs/tools/networking/strongswan/default.nix

  Log Message:
  ---
  strongswan: 5.5.1 -> 5.5.2


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

Re: [Nix-dev] no network virtualbox install

[Bas van Dijk]

Hi Andreas,

You could enable DHCP by turning on:

  networking.useDHCP

If you need to set a static address look into:

  networking.interfaces..ip4

Then after a nixos-rebuild switch your machine should have a network
connection provided that you configured the host the right way.

Bas

Op 4 apr. 2017 21:29 schreef "Andreas Meyer" :

Hello!

I installed a virtualbox using nixos-17.03.889.9626bc7db7-x86_64-linux.ova
but I have no networkconnection.

ifconfig shows the interface is there but
sudo ifconfig enp0s3 10.0.0.2 up has no effect.

:-(

  Andreas

___
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] nixops: how to deploy containers with specified IP addresses

[Bas van Dijk]

Dear list,

I have a nixops deployment configuration where the machines are configured
to run in a container on localhost:

  deployment.targetEnv = "container"

When deploying the configuration a machine gets the IP address 10.233.n.2
where n is the order in which the machines got deployed. Since this happens
in parallel the IP addresses are nondeterministic. I see that this is
happening here:

https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/virtualization/nixos-container/nixos-container.pl#L155

With declarative containers user can specify the address using:

  containers..localAddress

Is there a way to override the computed IP address with a user supplied
address for imperative containers deployed using nixops?

Cheers,

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

Re: [Nix-dev] NixOS 17.03 'Gorilla' Released

[Bas van Dijk]

Great work!

On 31 March 2017 at 16:29, Robin Gloster  wrote:

> Dear community,
>
> I'm proud to announce the 7th NixOS stable release 17.03 named
> "Gorilla".
>
> With over 12479 (last release: 13283) commits from 625 (last release
> 554) contributors the release brings a few highlights:
>
> * Nixpkgs is now extensible through overlays. See the Nixpkgs manual for
>   more information.
>
> * This release is based on Glibc 2.25, GCC 5.4.0 and systemd 232. The
>   default Linux kernel is 4.9 and Nix is at 1.11.8.
>
> * The default desktop environment now is KDE's Plasma 5. KDE 4 has been
>   removed
>
> * The setuid wrapper functionality now supports setting capabilities.
>
> * X.org server uses branch 1.19. Due to ABI incompatibilities,
>   ati_unfree keeps forcing 1.17 and amdgpu-pro starts forcing 1.18.
>
> * Cross compilation has been rewritten. See the nixpkgs manual for
>   details. The most obvious breaking change is that in derivations there
>   is no .nativeDrv nor .crossDrv and are now cross by default, not
>   native.
>
> * The overridePackages function has been rewritten to be replaced by
>   overlays
>
> * Packages in nixpkgs can be marked as insecure through listed
>   vulnerabilities. See the Nixpkgs manual for more information.
>
> There are two open issues currently:
>  * gdm crashes on some hardware, using slim to start gnome works, see
> the github issue for more information:
>https://github.com/NixOS/nixpkgs/issues/24172
>  * Firefox e10s tabs crash, see the github issue for more information:
>https://github.com/NixOS/nixpkgs/issues/24295
>
> See release notes for more information about major changes and updates
> at http://nixos.org/nixos/manual/release-notes.html#sec-release-17.03
>
> ISO and VirtualBox images can be downloaded from:
> http://nixos.org/nixos/download.html
> (Azure BLOBs and EC2 AMIs will follow)
>
> The NixOS manual is at http://nixos.org/nixos/manual/
>
> A 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-17.03 nixos
> $ nixos-rebuild switch --upgrade
>
> Please report issues to our bug tracker:
> https://github.com/NixOS/nixpkgs/issues
>
> The most active contributors for this release were:
> 621 commits: Frederik Rietdijk
> 498 commits: Franz Pletz
> 379 commits: Vladimír Čunát
> 377 commits: Thomas Tuegel
> 324 commits: Joachim Fasting
>
> And of course the regular thank you to Eelco Dolstra for his tireless
> work on NixOS, Nix and all the projects around that. I'd like to thank
> Domen Kožar for his help on getting this release out smoothly and his
> regular work on NixOS, the security team for taking a lot of workload
> off the release manager by always making sure to keep our systems and
> packages secure and also Mayflower for allowing me to work on NixOS a
> lot in working hours.
>
> Also I'd like to start a discussion if we want to start rotating the
> release manager for every release or maybe have two release managers
> each rotating after two releases, so you always have one who has
> managed one release. Any opinions? I'm not opposed to doing it again
> but it needs quite some time I could also spend on other work.
>
> PS: Note that according to our new policy, 16.09 is still supported one
> month by our security team until the end of April.
>
> Cheers,
> Robin
> ___
> 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] NixOps on VServer (update)

[Bas van Dijk]

Are you deploying to a Hetzner VServer by any chance?

If that's the case, you probably want to use the following deployment
configuration:

deployment = {
  targetEnv = "hetzner";
  hetzner = {
mainIPv4 = "X.X.X.X";
robotUser = "";
partitions = ''
  clearpart --all --initlabel --drives=sda
  part swap --recommended --label=swap --fstype=swap --ondisk=sda
  part / --fstype=ext4 --label=root --grow --ondisk=sda
'';
  };
};

Also note that I have the following listed in my Hetzner configurations:

# TODO: These options are only needed when deploying to a
# Hetzner machine for the first time. After the initial deployment these
options
# should be commented. We should report this as a bug of nixops.
# boot.loader.grub.device = "/dev/sda";
# fileSystems."/" = {
#   device = "/dev/disk/by-label/root";
#   fsType = "ext4";
# };

Bas


On 28 March 2017 at 01:21,  wrote:

> Here are more details to my previous message:
>
> I'm getting the following error, when deploying this
> (http://lpaste.net/353990) config to a remote nix machine:
>
> nixops deploy -d network
> building all machine configurations...
> error:
> Failed assertions:
> - The ‘fileSystems’ option does not specify your root file system.
> - You must set the option ‘boot.loader.grub.devices’ or
> 'boot.loader.grub.mirroredBoots' to make the system bootable.
> (use ‘--show-trace’ to show detailed location information)
> error: unable to build all machine configurations
>
> Does anybody have an idea how to fix this?
>
> ___
> 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-commits] [NixOS/nixpkgs] 6f2eca: wordpress: replace the dbPassword option with dbPa...

[Bas van Dijk]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 6f2eca1744b4ca74f456f77a1aa6e5b4ce937793
  
https://github.com/NixOS/nixpkgs/commit/6f2eca1744b4ca74f456f77a1aa6e5b4ce937793
  Author: Bas van Dijk <v.dijk@gmail.com>
  Date:   2017-03-28 (Tue, 28 Mar 2017)

  Changed paths:
M nixos/modules/services/web-servers/apache-httpd/wordpress.nix

  Log Message:
  ---
  wordpress: replace the dbPassword option with dbPasswordFile (#24146)

We shouldn't force users to store passwords in the world-readable Nix store.


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

Re: [Nix-dev] Nix for internal projects and monorepos

[Bas van Dijk]

Hi Daniel,

At LumiGuide we use the following structure for our monorepo:

  https://github.com/LumiGuide/lumi-example

Most of our packages are written in Haskell and these are stored in
the  directory (we have around 50 of them). Each package
contains a default.nix file where the src attribute is set to
`lib.sourceByRegex ./. [...]`. This ensure that only the needed
sources are build and that build artefacts like ./dist don't pollute
the sources. Also note that each Haskell package contains a shell.nix
file which is used when we want to work on a package using:

  make hs-pkgs.lumi-example-hs-pkg.shell

In the resulting shell we can invoke cabal to build the package. Our
emacs editor is configured to also invoke nix-shell to compile the
package:

  (require 'haskell-mode)
  (setq haskell-compile-cabal-build-command
"cd %s && nix-shell --command 'cabal configure --enable-tests &&
cabal build --ghc-option=-ferror-spans'")

We use nixops to deploy to production. We don't call nixops directly
but use the appropriate targets in the Makefile. For example: make
facility-1.deploy.

We have been using this setup for over 2 years and it works well. Let
me know if you have any questions.

Bas

On 24 March 2017 at 21:01, Daniel Peebles  wrote:
> Hi all,
>
> I've been ruminating about the best way to deal with an internal (to a
> company or otherwise private) package set with Nix, especially with a
> monorepo.
>
> My first inclination would be to leave Nix expressions (as default.nix)
> alongside the project source code, and use path references in those
> expressions (e.g., src = ./.;) to actually build the project.
>
> The difficulty arises when you want to deploy this stuff to production.
> Unless you want to ship your entire internal source tree to each box with
> Nix on it (no, I don't in practice want to be building my apps in
> production, and would use a Hydra/binary cache), you're going to want to
> "lift out" the nix hierarchy from your source code hierarchy, replace the
> src links with fixed-output derivations somehow, and ship the whole thing as
> a channel. I don't know of any tooling to do that, or how to do that
> effectively. It seems like it would require some tooling on the Nix side to
> work nicely.
>
> The alternative would be to adopt a more nixpkgs-like approach, and maintain
> a separate tree of packages that point into fixed-output references into the
> actual codebase. That unfortunately means moving the build spec farther away
> from the code it builds, and although it might be necessary in the case of
> nixpkgs (because we don't control all FOSS projects), it seems like we can
> do better.
>
> How do other people tackle this problem? Does anyone maintain a reasonably
> large internal Nix package set?
>
> Thanks,
> Dan
>
>
> ___
> 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] Provide options for storing secrets outside the Nix store

[Bas van Dijk]

Dear module authors, maintainers and contributors,

I would like to bring your attention to:

  https://github.com/NixOS/nixpkgs/issues/24288

The idea is to add a `passwordFile` option for every `password` option so
that users have a choice other than storing secrets inside the
world-readable Nix store.

What do you think about the proposal?

If you agree and want to contribute, please mention in the issue which
module you want to take on. That way we can coordinate the effort.

Happy hacking,

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

Re: [Nix-dev] RFC for RFCs

[Bas van Dijk]

Thanks for the pointer! It looks like that's exactly what I need. Strange
this has been merged into master over a year ago but it hasn't been
released yet. And there have been quite a few releases the last year...

On 21 March 2017 at 09:06, Vladimír Čunát <vcu...@gmail.com> wrote:

> On 03/21/2017 01:35 AM, Bas van Dijk wrote:
> > I would like a RFC on floating-point support in Nix. Unfortunately I
> > don't have time to work on that myself.
>
> For the record, Nix does support floats, though not in any release yet.
> https://github.com/NixOS/nix/pull/762
> (You might've meant some more specific aspects of the float support.)
>
> --Vladimir
>
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] RFC for RFCs

[Bas van Dijk]

Good to see this happen!

I would like a RFC on floating-point support in Nix. Unfortunately I don't
have time to work on that myself.

Bas

On 18 March 2017 at 23:09, zimbatm  wrote:

> RFC 0001 has been merged! The repo still needs to be moved to the NixOS
> org but we're getting there :)
>
> To keep the ball rolling, let me know if you want to try drafting a RFC.
> The whole process is probably still a bit rough and we need to get a couple
> of RFCs trough the process to make it better.
>
> Cheers,
> z
>
> On Thu, 9 Mar 2017 at 17:44 Rok Garbas  wrote:
>
>> I haven't read the latest changes in the RFC, but I welcome any more
>> formal process for major changes.
>>
>> Thank you @zimbatm for pursuing this.
>>
>>
>> > On 09 March 2017 at 13:09 Tomasz Czyż  wrote:
>> >
>> >
>> > Thanks! Great stuff!
>> >
>> > 2017-03-08 21:21 GMT+00:00 zimbatm :
>> >
>> > > The RFC for RFCs is ready for a final round of review. Unless there
>> are
>> > > major objections I would like to move forward with it, with the idea
>> that
>> > > we can always improve the process with further RFCs.
>> > >
>> > > https://github.com/zimbatm/rfcs/pull/1
>> > >
>> > > On Sun, 12 Feb 2017 at 20:17 Maarten Hoogendoorn 
>> > > wrote:
>> > >
>> > >> Also see the notes that Arian took during the BoF session at FOSDEM:
>> > >>
>> > >> We had a very spontaneous NixOS discussion panel at FOSDEM.
>> > >>
>> > >> I took minutes.  I must say they're a bit rushy at times, so add
>> stuff to
>> > >> it
>> > >> you think isn't clear or is lacking in content.  Thanks!
>> > >>
>> > >>
>> > >> http://piratepad.net/1nHg65LMQj
>> > >>
>> > >>
>> > >> 2017-02-12 19:46 GMT+01:00 Thomas Hunger :
>> > >>
>> > >> That would be amazing! I actually have an email sitting in my draft
>> > >> folder proposing Nix Enhancement Proposals (NEPs).
>> > >>
>> > >> IMHO one of the things we aren't very good at is getting larger
>> changes
>> > >> merged or rejected. We attract a lot of smart people because Nix is
>> pretty
>> > >> awesome. These smart people then do substantial work, submit a PR
>> and the
>> > >> PR bitrots. This is highly demotivating.
>> > >>
>> > >> An RFC process would allow us to get to an accept / reject early on,
>> with
>> > >> the expectation that accepted RFCs will be merged when the technical
>> work
>> > >> is done.
>> > >>
>> > >> I'll add more specific comments to your PR.
>> > >>
>> > >> ~
>> > >>
>> > >> On 12 February 2017 at 15:12, zimbatm  wrote:
>> > >>
>> > >> Hi all,
>> > >>
>> > >> we discussed of introducing a RFC process during FOSDEM. The goal is
>> to
>> > >> help discussion for large or controversial changes which typically
>> grind to
>> > >> a halt.
>> > >>
>> > >> Here is an initial proposal based on the one from the Rust community:
>> > >> https://github.com/zimbatm/rfcs/pull/1 . Please let me know what you
>> > >> think.
>> > >>
>> > >> Cheers,
>> > >> z
>> > >>
>> > >> ___
>> > >> 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
>> > >
>> > >
>> >
>> >
>> > --
>> > Tomasz Czyż
>> > ___
>> > nix-dev mailing list
>> > nix-dev@lists.science.uu.nl
>> > http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>> -- Rok Garbas, https://garbas.si
>>
>
> ___
> 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-commits] [NixOS/nixpkgs] 674d8c: wordpress: security upgrade: 4.7.2 -> 4.7.3 & othe...

[Bas van Dijk]

  Branch: refs/heads/release-16.09
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 674d8cf06f297e4337ca2a248b46e10fb85b766d
  
https://github.com/NixOS/nixpkgs/commit/674d8cf06f297e4337ca2a248b46e10fb85b766d
  Author: Bas van Dijk <v.dijk@gmail.com>
  Date:   2017-03-18 (Sat, 18 Mar 2017)

  Changed paths:
M nixos/modules/services/web-servers/apache-httpd/wordpress.nix
M nixos/tests/wordpress.nix
A pkgs/servers/web-apps/wordpress/default.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  wordpress: security upgrade: 4.7.2 -> 4.7.3 & other improvements

* Moved the wordpress sources derivation to the attribute pkgs.wordpress. This
  makes it easier to override.

* Also introduce the `package` option for the wordpress virtual host config 
which
  defaults to pkgs.wordpress.

* Also fixed the test in nixos/tests/wordpress.nix.


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

[Nix-commits] [NixOS/nixpkgs] 308c09: wordpress: security upgrade: 4.7.2 -> 4.7.3 & othe...

[Bas van Dijk]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 308c09d41f309e5055e45c66c07454581945d458
  
https://github.com/NixOS/nixpkgs/commit/308c09d41f309e5055e45c66c07454581945d458
  Author: Bas van Dijk <v.dijk@gmail.com>
  Date:   2017-03-14 (Tue, 14 Mar 2017)

  Changed paths:
M nixos/modules/services/web-servers/apache-httpd/wordpress.nix
M nixos/tests/wordpress.nix
A pkgs/servers/web-apps/wordpress/default.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  wordpress: security upgrade: 4.7.2 -> 4.7.3 & other improvements (#23837)

* Moved the wordpress sources derivation to the attribute pkgs.wordpress. This
  makes it easier to override.

* Also introduce the `package` option for the wordpress virtual host config 
which
  defaults to pkgs.wordpress.

* Also fixed the test in nixos/tests/wordpress.nix.


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

Re: [Nix-dev] Aarch64!

[Bas van Dijk]

Great work!

Would it be possible to also build for armv7 systems?

Bas

On 9 March 2017 at 22:14, Graham Christensen  wrote:

>
> Vladimír's email reminded me I hadn't said anything about aarch64...
> but, many people already know :)
>
> As of yesterday, with the excellent help of Tuomas (Dezgeg) and others,
> plus the generous donation of 96-core Cavium ThunderX machines from
> Packet.net, we now have Nixpkgs unstable building Aarch64 packages!
>
> These should run just fine on Raspberry Pi 3, and of course,
> Packet.net's ThunderX machines.
>
> I added it first to nixpkgs only in order to "smoke test" the deployment
> without interrupting NixOS. I have no objection to moving it over to
> NixOS itself, the machines should be able to run the NixOS tests just
> fine.
>
> Currently, we only have one Aarch64 builder. We can add more, and having
> Hydra building stdenv will make the provisioning process much faster.
>
> Let us all celebrate this big milestone, and push forward to NixOS on
> ARM!
>
> Thank you to Tuomas, nathan7, Eelco, Packet.net, and all the ARM
> contributors for making this possible.
>
> Thank you,
> Graham Christensen
> ___
> 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] Hydra Building PRs

[Bas van Dijk]

On 28 January 2017 at 14:20, Graham Christensen  wrote:

> Packet.net is also one of the only hosting companies I know of which
> rents Cavium ThunderX ARMv8s, and they're very interested in our
> supporting this architecture. Soon, with the help of Dezgeg,
> prs.nix.gsc.io will also building PRs against ARMv8.
>
> After that works, I've spoken with Rob, and it sounds like
> hydra.nixos.org will gain the ability to run ARMv8 builds, too.
>

Hi Graham, what's te status of this project?

I'm currently upgrading some Raspberry Pi 3's s to NixOS-17.03 but the
build of gcc is getting killed by what I expect is the OOM killer (Pi's
only have 1GB of RAM). It would be great to utilise a Cavium ThunderX
machine for this.

Are there any blockers; technology-wise, timewise, fundingwise for this
project to succeed? Do you need help? Maybe I can help.

Regards,

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

Re: [Nix-dev] Cannot run "hydra-create-user" ("no such table: Users")

[Bas van Dijk]

Hi Bjørn,

At LumiGuide I use the following systemd service to setup hydra:

# Create a hydra admin user named "" and copy the GitHub private SSH
# key to hydra's home directory so that it can connect to GitHub to clone
# our repo's.
systemd.services.lumi-hydra-setup = {
wantedBy = [ "multi-user.target" ];
requires = [ "hydra-init.service" "postgresql.service" ];
after = [ "hydra-init.service" "postgresql.service" ];
environment = config.systemd.services.hydra-init.environment;
path = [ config.services.hydra.package ];
script =
let hydraHome = config.users.users.hydra.home;
hydraQueueRunnerHome = config.users.users.hydra-queue-runner.home;
in ''
hydra-create-user  \
--full-name '' \
--email-address 'x...@lumiguide.nl' \
--password '${cfg.Password}' \
--role admin

mkdir -p "${hydraHome}/.ssh"
chmod 700 "${hydraHome}/.ssh"
cp "**" "${hydraHome}/.ssh/id_rsa"
chown -R hydra:hydra "${hydraHome}/.ssh"
chmod 600 "${hydraHome}/.ssh/id_rsa"
mkdir -p "${hydraQueueRunnerHome}/.ssh"
chmod 700 "${hydraQueueRunnerHome}/.ssh"
cp "**" "${hydraQueueRunnerHome}/.ssh/id_rsa"
chown -R hydra-queue-runner:hydra "${hydraQueueRunnerHome}/.ssh"
chmod 600 "${hydraQueueRunnerHome}/.ssh/id_rsa"
'';
serviceConfig = {
Type = "oneshot";
RemainAfterExit = true;
};
}; Note that I set the environment to be the hydra-init environment. With a
bit of luck that's the solution for your problem.

Bas

On 4 March 2017 at 11:59, Bjørn Forsman  wrote:

> Hi all Hydra + Nixpkgs users,
>
> How did you manage to run "hydra-create-user"? It fails for me:
>
>   $ sudo -u hydra hydra-create-user alice --full-name 'Alice Q. User'
> --email-address 'al...@example.org' --password alice --role admin
>   DBIx::Class::Storage::DBI::_prepare_sth(): DBI Exception:
> DBD::SQLite::db prepare_cached failed: no such table: Users at
> /nix/store/2jy4y3nml6qljayqjlrf8mx6rrgj8g4l-hydra-2017-02-03/bin/.
> hydra-create-user-wrapped
> line 56
>
> This is on NixOS 17.03, using the hydra module provided by nixpkgs.
> I've set "services.hydra.enable = true" in configuration.nix,
> activated the configuration and verified that the hydra webUI is up. I
> even have the 'Users' table that "hydra-create-user" says does not
> exist:
>
>   $ sudo psql -U hydra
>   psql (9.5.6)
>   Type "help" for help.
>
>   hydra=> select * from Users;
>username | fullname | emailaddress | password | emailonerror | type
> | publicdashboard
>   --+--+--+--+
> --+--+-
>   (0 rows)
>
> Any suggestions?
>
> Best regards,
> Bjørn Forsman
> ___
> 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] 17.03 beta released

[Bas van Dijk]

Great work. I'm upgrading our LumiGuide systems as we speak.

On 3 March 2017 at 14:19, Robin Gloster  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi,
>
> I'd like to announce NixOS 17.03 "Gorilla" beta in the name of
> community.
>
> The largest changes are:
>
>   - Nixpkgs is now extensible through overlays. See
> https://github.com/NixOS/nixpkgs/pull/21243
>
>   - The setuid wrapper functionality now supports setting
> capabilities.
>
>   - X.org server uses branch 1.19. Due to ABI incompatibilities,
> ati_unfree keeps forcing 1.17
> and amdgpu-pro starts forcing 1.18.
>
>   - PHP now defaults to PHP 7.1
>
>   - Packages in nixpkgs can be marked as insecure through listed
> vulnerabilities.
>
>   - This release is based on Glibc 2.25, GCC 5.4.0, systemd
> 232 and Nix 1.11.7. The default Linux kernel is 4.9.
>
> Please upgrade channels as usual and test:
>
> $ nix-channel --add https://nixos.org/channels/nixos-17.03 nixos
> $ nixos-rebuild switch --upgrade
>
> I'd like to point out a serious bug that you might hit:
>
> - - setuid wrappers with the new setcap wrappers have changed their
>   location. Therefore you might need to login again to use setuid
>   binaries or use "nixos-rebuild boot"
>
> If you'd like to help out, test and check the github bug tracker under
> 17.03 milestone.
>
> As usual, we're working on getting build failures down:
> https://github.com/NixOS/nixpkgs/issues/23253
>
> Final release is slated to be released on March 30th.
>
> The master branch has been bumped to 17.09 which has been given the
> codename "Hummingbird".
>
> Cheers
> Robin
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCAAdFiEEwDW0rUngVuvX12VXXkyDbGMsKIIFAli5bWcACgkQXkyDbGMs
> KIJVQA/+NQHBHPP5HJh2obY+MCrTfrp3SyiXRzcrQCIbofqEFmg/VmKLgIIvkr3W
> 0emONs5glyd63ximKtH7HruxvfLQCV3QLvUF8DNCwVBvbayUmFdIC0YpMjH3StwL
> XS1NaKMzadXHy86kcND1VdjSojC1NywnDE/lFIubQuF5/bqEPvlVtCnTdGiX/jEM
> GmjYBf8zXET5BRK2gpxAiKoW7MMhH5qw36+Y2jngYreghzYvZNHABQ7pOF3gSe+T
> v0VVUNI7ypMjFhalkdb1KJDMblCktPSrELhN9xeY3nWpv3dAo3w7lWx8Ezd8U28z
> MX4kJfL5/qmsO4CM9hNqUZ/u9JWdCxUZNqcHeJCiXP9glbpmE1oBdr7Eaiv5Gjoa
> Fab5w2+n6qP8WcX1gmu+pArVrkzoGERqxB75yuqJpF2TF0ood1hceBtn33bbKxSi
> zwmh6gtVkbooiOPR5PcK7ZIa3Atn1pj+IOwyjWG4emhnGoA2j/sOn0SmKdzfR+U/
> uNwuq+uPMpoZAMZf6R2rOSEco7MOJwb2KnSSJKOp1+5J9PU4od3jkpIaGpSBYdcn
> 6gu15Wgcb4hhsce4yQNsGmRLRtNrgh9+HT1BN8nW6znYgsQrcpfpz1T/D8Ckv8Sz
> AztV2IgBpobjzIc8lIfKlaLD5NU2hEJEGXRCFW+Nc+T136Ubim8=
> =MMKz
> -END PGP SIGNATURE-
> ___
> 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] Explicitly selecting sources for "src" in stdenv.mkDerivation?

[Bas van Dijk]

Note that the regular expression that builtins.match accepts already
supports disjunction using: "a|b". So your example application could be
rewritten using:

  sourceByRegex /tmp/sourcetest [".*hs$|someTestFile"]

suggesting that the list of regexes could be replaced by a single regex:

  sourceByRegex /tmp/sourcetest ".*hs$|someTestFile"

which might also be more efficient since the disjunction will be handled by
the regex engine instead of by the Nix interpreter.

Lists of regexes might be easier to work with though in which case your
function can be written as:

  sourceByRegex = src: regexes: builtins.filterSource (path: type:
  let relPath = lib.removePrefix (toString src + "/") (toString path);
  in builtins.match (concatStringsSep "|" regexes) relPath != null)
src;

I'll leave further discussion for the PR ;)

Bas

On 17 February 2017 at 18:46, Bas van Dijk <v.dijk@gmail.com> wrote:

> Awesome function indeed!
>
> TIL there exists builtins.match and it's not documented in the manual[1].
>
> I would like to switch from my whitelistSource to your sourceByRegex so a
> PR would be much appreciated indeed.
>
> Bas
>
> [1] http://nixos.org/nix/manual/#ssec-builtins
>
> On 17 February 2017 at 11:16, Thomas Hunger <tehun...@gmail.com> wrote:
>
>> Thanks for your replies everyone!
>>
>> Bas - your "toString" helped me over the finishing line. Pretty obvious
>> in hindsight to use toString to force evaluation of src. I adapted your
>> code to this:
>>
>> sourceByRegex = src: regexes: builtins.filterSource (path: type:
>> let relPath = lib.removePrefix (toString src + "/") (toString path);
>> in lib.any (re: builtins.match re relPath != null) regexes)
>>   src;
>>
>> To be used like this:
>>
>> sourceByRegex /tmp/sourcetest [".*hs$", "someTestFile"]
>>
>> And then I have some predefined lists like cabalProject = [".*\.cabal$",
>> ".*\.hs"]
>>
>> ~
>>
>>
>>
>> On 16 February 2017 at 21:58, Bas van Dijk <v.dijk@gmail.com> wrote:
>>
>>> At LumiGuide we're using the following function in our Haskell packages:
>>>
>>>   # Copy everything under src into the Nix store except those paths
>>> that don't
>>>   # have one of the specified allowedPrefixes.
>>>   whitelistSource = src: allowedPrefixes:
>>> builtins.filterSource
>>>   (path: type:
>>> lib.any (allowedPrefix: lib.hasPrefix (toString (src + "/${
>>> allowedPrefix}")) path)
>>> allowedPrefixes)
>>>   src;
>>>
>>> To be used as for example:
>>>
>>>   src = lib.whitelistSource ./. [
>>>   "lumi-central-server.cabal"
>>>   "src"
>>>   "default.conf"
>>> ];
>>>
>>> Bas
>>>
>>> Op 16 feb. 2017 13:14 schreef "Thomas Hunger" <tehun...@gmail.com>:
>>>
>>> Hi,
>>>
>>> I am consistently struggling with the following in nix: I have a
>>> repository and I want to specify derivations for some local sub-projects.
>>> The obvious solution is
>>>
>>>   src = ./subproject-A;
>>>
>>> But that pulls in everything in that directory, including build
>>> artifacts, or random intermediate data files.
>>>
>>> Another solution is
>>>
>>>   src = sourceFilesBySuffices ./subproject-A [".cabal" ".hs"];
>>>
>>> Which works reasonably well but introduces this weird dance where I
>>> suffix files so they can be matched by sourceFilesBySuffices. Mostly I want
>>> to do this:
>>>
>>>   src = [ ./subproject-A/schema.sql ./subproject-A/lib ];
>>>
>>> Or even get all the files checked into git:
>>>
>>>   src = gitFiles ./subproject-A; # does not work
>>>
>>> I was wondering whether any of you have this issue, and if you do: how
>>> do you solve it?
>>>
>>> ~
>>>
>>> (see also https://github.com/NixOS/nix/issues/885)
>>>
>>> ___
>>> 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] Explicitly selecting sources for "src" in stdenv.mkDerivation?

[Bas van Dijk]

Awesome function indeed!

TIL there exists builtins.match and it's not documented in the manual[1].

I would like to switch from my whitelistSource to your sourceByRegex so a
PR would be much appreciated indeed.

Bas

[1] http://nixos.org/nix/manual/#ssec-builtins

On 17 February 2017 at 11:16, Thomas Hunger <tehun...@gmail.com> wrote:

> Thanks for your replies everyone!
>
> Bas - your "toString" helped me over the finishing line. Pretty obvious in
> hindsight to use toString to force evaluation of src. I adapted your code
> to this:
>
> sourceByRegex = src: regexes: builtins.filterSource (path: type:
> let relPath = lib.removePrefix (toString src + "/") (toString path);
> in lib.any (re: builtins.match re relPath != null) regexes)
>   src;
>
> To be used like this:
>
> sourceByRegex /tmp/sourcetest [".*hs$", "someTestFile"]
>
> And then I have some predefined lists like cabalProject = [".*\.cabal$",
> ".*\.hs"]
>
> ~
>
>
>
> On 16 February 2017 at 21:58, Bas van Dijk <v.dijk@gmail.com> wrote:
>
>> At LumiGuide we're using the following function in our Haskell packages:
>>
>>   # Copy everything under src into the Nix store except those paths that
>> don't
>>   # have one of the specified allowedPrefixes.
>>   whitelistSource = src: allowedPrefixes:
>> builtins.filterSource
>>   (path: type:
>> lib.any (allowedPrefix: lib.hasPrefix (toString (src + "/${
>> allowedPrefix}")) path)
>> allowedPrefixes)
>>   src;
>>
>> To be used as for example:
>>
>>   src = lib.whitelistSource ./. [
>>   "lumi-central-server.cabal"
>>   "src"
>>   "default.conf"
>> ];
>>
>> Bas
>>
>> Op 16 feb. 2017 13:14 schreef "Thomas Hunger" <tehun...@gmail.com>:
>>
>> Hi,
>>
>> I am consistently struggling with the following in nix: I have a
>> repository and I want to specify derivations for some local sub-projects.
>> The obvious solution is
>>
>>   src = ./subproject-A;
>>
>> But that pulls in everything in that directory, including build
>> artifacts, or random intermediate data files.
>>
>> Another solution is
>>
>>   src = sourceFilesBySuffices ./subproject-A [".cabal" ".hs"];
>>
>> Which works reasonably well but introduces this weird dance where I
>> suffix files so they can be matched by sourceFilesBySuffices. Mostly I want
>> to do this:
>>
>>   src = [ ./subproject-A/schema.sql ./subproject-A/lib ];
>>
>> Or even get all the files checked into git:
>>
>>   src = gitFiles ./subproject-A; # does not work
>>
>> I was wondering whether any of you have this issue, and if you do: how do
>> you solve it?
>>
>> ~
>>
>> (see also https://github.com/NixOS/nix/issues/885)
>>
>> ___
>> 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] Explicitly selecting sources for "src" in stdenv.mkDerivation?

[Bas van Dijk]

At LumiGuide we're using the following function in our Haskell packages:

  # Copy everything under src into the Nix store except those paths that
don't
  # have one of the specified allowedPrefixes.
  whitelistSource = src: allowedPrefixes:
builtins.filterSource
  (path: type:
lib.any (allowedPrefix: lib.hasPrefix (toString (src + "/${
allowedPrefix}")) path)
allowedPrefixes)
  src;

To be used as for example:

  src = lib.whitelistSource ./. [
  "lumi-central-server.cabal"
  "src"
  "default.conf"
];

Bas

Op 16 feb. 2017 13:14 schreef "Thomas Hunger" :

Hi,

I am consistently struggling with the following in nix: I have a repository
and I want to specify derivations for some local sub-projects. The obvious
solution is

  src = ./subproject-A;

But that pulls in everything in that directory, including build artifacts,
or random intermediate data files.

Another solution is

  src = sourceFilesBySuffices ./subproject-A [".cabal" ".hs"];

Which works reasonably well but introduces this weird dance where I suffix
files so they can be matched by sourceFilesBySuffices. Mostly I want to do
this:

  src = [ ./subproject-A/schema.sql ./subproject-A/lib ];

Or even get all the files checked into git:

  src = gitFiles ./subproject-A; # does not work

I was wondering whether any of you have this issue, and if you do: how do
you solve it?

~

(see also https://github.com/NixOS/nix/issues/885)

___
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] Feedback on workshop material

[Bas van Dijk]

Great recording[1] of your introduction presentation on Nix. It would be
cool to have this or a slightly more polished version permanently in the
middle on the homepage of nixos.org.

Regarding the "Packaging" section, I liked how lethalman introduced[2]
packaging in his legendary Nix Pills series by beginning with the primitive
`derivation` function and building up from that. So I would advise doing
something similar before showing `stdenv.mkDerivation`.

I'm really looking forward to the workshop. See you there!

Bas

[1] https://www.youtube.com/watch?v=WC3ILVKZh7E
[2]
http://lethalman.blogspot.nl/2014/07/nix-pill-6-our-first-derivation.html


On 15 February 2017 at 17:02, Maarten Hoogendoorn 
wrote:

> Dear list,
>
> I'm organizing a Nix workshop in Amsterdam on February 25th and have
> started to create some workshop material for it [1].
>
> Could you provide me with some feedback on the things I plan to cover? [2]
>
> Thanks,
> Maarten
>
> [1] https://github.com/moretea/nix-workshop
> [2] https://github.com/moretea/nix-workshop/blob/master/toc.md
>
> ___
> 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-commits] [NixOS/nixpkgs] 8a9287: haskell: add support for Haskell Program Coverage ...

[Bas van Dijk]

  Branch: refs/heads/staging
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 8a928708b41f90b68cb76b7448a1b5e39ebd82b7
  
https://github.com/NixOS/nixpkgs/commit/8a928708b41f90b68cb76b7448a1b5e39ebd82b7
  Author: Bas van Dijk <v.dijk@gmail.com>
  Date:   2017-02-15 (Wed, 15 Feb 2017)

  Changed paths:
M pkgs/development/haskell-modules/generic-builder.nix
M pkgs/development/haskell-modules/lib.nix

  Log Message:
  ---
  haskell: add support for Haskell Program Coverage (HPC) to the generic builder

A function is added to enable the generation of a HPC report. For example:

  pkgs.haskell.lib.doCoverage drv

will create a HPC report of the Haskell package drv in the directory:

  $out/share/hpc

Closes https://github.com/NixOS/nixpkgs/pull/22797/files.


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

[Nix-dev] nixpkgs > 100k commits

[Bas van Dijk]

Dear all,

FYI the nixpkgs repository[1] just went over 100.000 commits!

Pretty cool to see this much activity.

Bas

[1] https://github.com/NixOS/nixpkgs
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra Building PRs

[Bas van Dijk]

This is just great work!

I'm also very excited about the work on ARM.

I do see one of my PRs failing to evaluate though:

  https://prs.nix.gsc.io/jobset/nixos/pr-22121#tabs-errors

Any idea what is going wrong?

Bas

On 28 January 2017 at 14:20, Graham Christensen  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hello everyone,
>
> A couple weeks ago I created https://prs.nix.gsc.io/, a Hydra server
> which builds every PR. Every PR will exist at
> https://prs.nix.gsc.io/jobset/nixos/pr-PRNUMBER.
>
> It features:
>  - a web-hook, which means:
>  - the moment a PR is created, the jobset is created on this hydra
>  - every time a PR is updated, the jobset is triggered
>  - every time there is a commit to master, the master jobset is
>triggered
>
> Non-feature:
>  - I haven't published the public key to the binary cache, because that
>would be very expensive for me to pay for. I am personally paying for
>the binary cache storage. Please don't use the binary cache results.
>
> The entire system is open source, publicly available at
> https://github.com/grahamc/hydra-prs/.
>
> HOW
> - 
>
> The build infrastructure is _very_ generously donated by Packet.net, who
> lease dedicated bare metal servers by the hour. Right now we have about
> 250 cores across 30 servers.
>
> This is still a trial run, though, so the number of systems we get can
> and will change.
>
> In exchange for this hardware, I've been working to add NixOS support to
> their platform. I'm also wanting to make NixOps have built-in support
> for deploying to their hardware.
>
> FUTURE (SOON)
> - 
>
> Packet.net is also one of the only hosting companies I know of which
> rents Cavium ThunderX ARMv8s, and they're very interested in our
> supporting this architecture. Soon, with the help of Dezgeg,
> prs.nix.gsc.io will also building PRs against ARMv8.
>
> After that works, I've spoken with Rob, and it sounds like
> hydra.nixos.org will gain the ability to run ARMv8 builds, too.
>
> FUTURE (LONGER TERM)
> - 
>
> Ideally, I think everyone would like this to become part of
> hydra.nixos.org, Eelco included.
>
> The current state of the system has a couple of patches to Hydra, plus a
> PHP webserver calling CLI utilities to create and trigger jobsets.
> Having this integrated with hydra properly would be way more ideal.
>
> Interpreting the results is a bit of a open question. Sometimes a PR
> will cause unrelated packages to start passing or failing, which is very
> mysterious. This seems less bad than Travis (which fails with any PR
> bigger than a light breeze...) but will still be confusing for people
> who aren't deeply familiar with Hydra.
>
> Other interesting things we may want to implement is setting build
> statuses on GitHub.com, or a bot that posts comments.
>
> I would be very, very happy if people contributed and improved the
> system.
>
> - --
>
> Thank you,
> Graham Christensen
> -BEGIN PGP SIGNATURE-
>
> iQIcBAEBCAAGBQJYjJqwAAoJEAYSHTZv6UNcZSoP/2pXbxcuetM212X8Rld2BFb1
> 3iNOWN/Kr1PzBSxRyWR/naOt6vA2gs1qv8GpXWCn4QTqlyxTk3QtWY7o9tQ1rJ/K
> rdMct5U8brjrUvOZMNDFhLyrYJSDEhV2YC2GhU4co7xPcGpzQnGi+6YiMLKEi6HV
> wzx34Qoy5MnUp+ZAw8yjf6uTWmS1nsMtisn+tE59pzqeikbhfZ9SLaTtkyCpzTDN
> ZtoAMifjsuTSlxsabmvY1sew3FEEVWhYqczaKU2IklUgAgeVuXVA5/rWQSWVaMc2
> hZOEZTOnvZiGks3hsfNlrI49tb+3Y4kUV2efGmLZULJ/wr00oohabnquXg3rc8NF
> LS//PPpPfQECxr8HOlk93kvW8Lwy8jl51UjdOA01GfdwBmsamTrqpD5qBlJD+Pd2
> KpXhIwtb8ftdpJi/nFq5TNm4XSUMbcztEA6xXN7of2JGaVqLOY/sJ0xuRDbGhuAC
> yd8EdfQvUG6bbm5NGmg0gAstCPi8KqdD0nGBIveSnEomintMP2tbIR6wJ1ah1Sug
> 0mYT+76d/JucxFYQPi5GNGzOfLqyqQwDHB8EGbtJRpW5brR+b5hvSLPZJy5EeDV9
> asn3m7Cjrz3mClnExxIRAEOggmzPmUfFqaUS0mwXOonaEbHLWAtU1+32VRirgKJu
> rAHzDlp/avOCPVDM797z
> =CRhX
> -END PGP SIGNATURE-
> ___
> 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-commits] [NixOS/nixpkgs] f2afe9: opencv-3.1: make ippicv download URL consistent

[Bas van Dijk]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: f2afe922f4bd1e1640226f53847385b6bb45e2f0
  
https://github.com/NixOS/nixpkgs/commit/f2afe922f4bd1e1640226f53847385b6bb45e2f0
  Author: Bas van Dijk <v.dijk@gmail.com>
  Date:   2017-01-23 (Mon, 23 Jan 2017)

  Changed paths:
M pkgs/development/libraries/opencv/3.x.nix

  Log Message:
  ---
  opencv-3.1: make ippicv download URL consistent

with the URL defined in:

  https://github.com/opencv/opencv/blob/3.1.0/3rdparty/ippicv/downloader.cmake


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

[Nix-commits] [NixOS/nixpkgs] 1853f1: opencv-3.1: get ippicv from the nix store

[Bas van Dijk]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 1853f174d11040b3901e4c83d89f2578320a2e42
  
https://github.com/NixOS/nixpkgs/commit/1853f174d11040b3901e4c83d89f2578320a2e42
  Author: Bas van Dijk <v.dijk@gmail.com>
  Date:   2017-01-23 (Mon, 23 Jan 2017)

  Changed paths:
M pkgs/development/libraries/opencv/3.x.nix

  Log Message:
  ---
  opencv-3.1: get ippicv from the nix store

If ippicv can't be found in the directory:

  3rdparty/ippicv/downloads/${platform}-${md5}

it will be downloaded instead. Commit 7fedbe7 accidentally swapped the
md5 with the sha256 causing ippicv to be downloaded each time opencv
gets build. This patch fixes that.


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

[Nix-commits] [NixOS/nixpkgs] f03380: strongswan: enable charon-systemd (#21872)

[Bas van Dijk]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: f0338024b9278b44ff97bc86778d4fd618401df8
  
https://github.com/NixOS/nixpkgs/commit/f0338024b9278b44ff97bc86778d4fd618401df8
  Author: Bas van Dijk <v.dijk@gmail.com>
  Date:   2017-01-14 (Sat, 14 Jan 2017)

  Changed paths:
M pkgs/tools/networking/strongswan/default.nix

  Log Message:
  ---
  strongswan: enable charon-systemd (#21872)

See: https://wiki.strongswan.org/projects/strongswan/wiki/Charon-systemd


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

Re: [Nix-dev] permission problems

[Bas van Dijk]

Hi Stewart,

config.ids.uids.workbench doesn't seem to exist in:

  https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/misc/ids.nix

Why do you assume it's there? Which revision of nixpkgs are you using?

Cheers,

Bas

On 11 January 2017 at 03:54, stewart mackenzie  wrote:

> greetings,
>
> If I enable this:
> https://github.com/fractalide/fractal_workbench/blob/master/
> service.nix#L72
>
> I get
>
> $ sudo nixos-rebuild test -I fractalide=/home/stewart/dev/
> fractalide/fractalide
> [sudo] password for stewart:
> building Nix...
> building the system configuration...
> error: attribute ‘workbench’ missing, at
> /home/stewart/dev/fractalide/fractals/fractal_workbench/service.nix:72:13
> (use ‘--show-trace’ to show detailed location information)
>
> why can't I add` uid = config.ids.uids.workbench;`?
>
> ---
>
> I'm trying to debug a permission problem in that the application
> doesn't have permission to access the database.
>
> kr/sjm
> ___
> 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] Plan for GHC 8.0.2

[Bas van Dijk]

Great, I'm upgrading our systems now.

Thank you for all your efforts. It's much appreciated!

Bas

On 9 January 2017 at 22:43, Peter Simons  wrote:

> Hi folks,
>
>  > I was wondering what your plan is regarding GHC-8.0.2. Will you add
>  > it to the release-16.09 branch once it's released?
>
> the current Git version of "release-16.09" has now the exact same Haskell
> infrastructure as 'master', i.e. it's based on LTS Haskell 7.14 and it
> includes the latest GHC:
>
> $ git describe
> 16.09-806-g2ad30bde82
>
> $ nix-shell -p haskell.compiler.ghc802 --run "ghc --version"
> The Glorious Glasgow Haskell Compilation System, version 8.0.2
>
> $ nix-shell -p stack --run "stack --numeric-version"
> 1.3.2
>
> $ nix-shell -p cabal-install --run "cabal --version"
> cabal-install version 1.24.0.2
> compiled using version 1.24.2.0 of the Cabal library
>
> Enjoy,
> Peter
>
> ___
> 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] Plan for GHC 8.0.2

[Bas van Dijk]

Eelco recently added support for testing for build determinism to hydra:

  https://github.com/NixOS/hydra/commit/8bb36e79bd9e1752c01499971cc511872c706956

Maybe you can use that. You can also test whole jobsets at once:

  https://github.com/NixOS/hydra/commit/f6081668dc5e9974f7e6fae7e74ea27dc1a5b3e7

On 2 January 2017 at 21:17, Ryan Trinkle <ryan.trin...@gmail.com> wrote:
> By the way, I've done some testing - built a reasonably large slew of things
> - but I haven't extensively tested the reproducibility itself.  If anyone
> has suggestions on how to approach that, I'll be happy to do some of that.
>
> On Mon, Jan 2, 2017 at 3:16 PM, Ryan Trinkle <ryan.trin...@gmail.com> wrote:
>>
>> Hi guys,
>>
>> I submitted a pull request here to enable parallel builds for ghc > 8.0.1.
>> Let me know what you think!  I've definitely been looking forward to this
>> for a long time.
>>
>>
>> Best,
>> Ryan
>>
>> On Mon, Jan 2, 2017 at 9:48 AM, Bas van Dijk <v.dijk@gmail.com> wrote:
>>>
>>> Hi Peter, that's good news. Thank you!
>>>
>>> On 2 January 2017 at 10:47, Peter Simons <sim...@nospf.cryp.to> wrote:
>>> > Hi Bas,
>>> >
>>> >  > Peter, I was wondering what your plan is regarding GHC-8.0.2. Will
>>> >  > you add it to the release-16.09 branch [...]?
>>> >
>>> > Yes, I'll add it to the release branch. The 'haskellPackages' set will
>>> > continue to follow the LTS-7.x release, though, so it won't become the
>>> > default compiler.
>>> >
>>> > Best regards,
>>> > Peter
>>> >
>>> > ___
>>> > 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

Re: [Nix-dev] Plan for GHC 8.0.2

[Bas van Dijk]

Hi Peter, that's good news. Thank you!

On 2 January 2017 at 10:47, Peter Simons  wrote:
> Hi Bas,
>
>  > Peter, I was wondering what your plan is regarding GHC-8.0.2. Will
>  > you add it to the release-16.09 branch [...]?
>
> Yes, I'll add it to the release branch. The 'haskellPackages' set will
> continue to follow the LTS-7.x release, though, so it won't become the
> default compiler.
>
> Best regards,
> Peter
>
> ___
> 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] Plan for GHC 8.0.2

[Bas van Dijk]

First of all, happy New Year everybody!

Peter, I was wondering what your plan is regarding GHC-8.0.2. Will you add
it to the release-16.09 branch once it's released or do we have wait for
17.03?

Cheers,

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

[Nix-commits] [NixOS/nixpkgs] 68b737: postgresql: bug fix updates for all versions

[Bas van Dijk]

  Branch: refs/heads/release-16.09
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 68b737555b38297d7e18665b67a1d9003a09b89f
  
https://github.com/NixOS/nixpkgs/commit/68b737555b38297d7e18665b67a1d9003a09b89f
  Author: Bas van Dijk <v.dijk@gmail.com>
  Date:   2016-11-23 (Wed, 23 Nov 2016)

  Changed paths:
M pkgs/servers/sql/postgresql/default.nix

  Log Message:
  ---
  postgresql: bug fix updates for all versions

See https://www.postgresql.org/about/news/1712/

(cherry picked from commit 8c887535ddde0383560d4867957dda194e143193)


  Commit: 18ff275f171ac8d9048aca976a14ab13d55d3ed7
  
https://github.com/NixOS/nixpkgs/commit/18ff275f171ac8d9048aca976a14ab13d55d3ed7
  Author: Bas van Dijk <v.dijk@gmail.com>
  Date:   2016-11-23 (Wed, 23 Nov 2016)

  Changed paths:
M pkgs/servers/sql/postgresql/default.nix
A pkgs/servers/sql/postgresql/hardcode-pgxs-path-96.patch
A pkgs/servers/sql/postgresql/less-is-more-96.patch
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  postgresql: add 9.6.1

(cherry picked from commit 589cc65306229223176010d0b512fd676c491df6)


Compare: https://github.com/NixOS/nixpkgs/compare/6fe0069daa58...18ff275f171a___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

Re: [Nix-dev] Multiple ssh substituter hosts

[Bas van Dijk]

This seems to cover the first part about pushing nars from hydra to s3:


https://github.com/NixOS/hydra/pull/118/commits/7c000713370bbb896e127503e8b0276c65eb76ae

Now I just need to configure my private s3 bucket as a binary cache. Anyone
know how to set that up?

On 21 November 2016 at 02:18, Bas van Dijk <v.dijk@gmail.com> wrote:

> That seems like a good idea.
>
> Ideally my hydra service would upload the nars it builds to a private s3
> bucket. Then my machines need to use this private s3 bucket as a binary
> cache.
>
> Is there any documentation on how to do this?
>
> On 20 November 2016 at 22:34, zimbatm <zimb...@zimbatm.com> wrote:
>
>> It's probably expensive to open all the ssh connections. Depending on
>> your use-case you might be better off uploading all the binaries to a
>> single destination like S3.
>>
>> On Sun, 20 Nov 2016 at 20:16 Bas van Dijk <v.dijk@gmail.com> wrote:
>>
>> I see. Thanks for pointing me to the source.
>>
>> I also see that supporting more hosts is listed as a TODO:
>>
>>   https://github.com/NixOS/nix/blob/master/src/download-via-ss
>> h/download-via-ssh.cc#L18
>>
>> Hopefully that gets implemented some day!
>>
>> Cheers,
>>
>> Bas
>>
>> On 20 November 2016 at 20:13, zimbatm <zimb...@zimbatm.com> wrote:
>>
>> Hi Bas,
>>
>> It looks like it's only taking the first host from the list[1]. I suppose
>> the intention was to provide fallbacks but it didn't get implemented.
>>
>> [1]: https://github.com/NixOS/nix/blob/master/src/download-via-ss
>> h/download-via-ssh.cc#L114
>>
>>
>> On Sun, 20 Nov 2016 at 15:49 Bas van Dijk <v.dijk@gmail.com> wrote:
>>
>> Dear all,
>>
>> Is it possible to have multiple ssh-substituter-hosts, as in:
>>
>>   ssh-substituter-hosts = nix-ssh@host1 nix-ssh@host2
>>
>> The documentation[1] is not entirely clear on that.
>>
>> Bas
>>
>> [1] http://nixos.org/nix/manual/#ssec-ssh-substituter
>> ___
>> 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] Multiple ssh substituter hosts

[Bas van Dijk]

That seems like a good idea.

Ideally my hydra service would upload the nars it builds to a private s3
bucket. Then my machines need to use this private s3 bucket as a binary
cache.

Is there any documentation on how to do this?

On 20 November 2016 at 22:34, zimbatm <zimb...@zimbatm.com> wrote:

> It's probably expensive to open all the ssh connections. Depending on your
> use-case you might be better off uploading all the binaries to a single
> destination like S3.
>
> On Sun, 20 Nov 2016 at 20:16 Bas van Dijk <v.dijk@gmail.com> wrote:
>
> I see. Thanks for pointing me to the source.
>
> I also see that supporting more hosts is listed as a TODO:
>
>   https://github.com/NixOS/nix/blob/master/src/download-via-
> ssh/download-via-ssh.cc#L18
>
> Hopefully that gets implemented some day!
>
> Cheers,
>
> Bas
>
> On 20 November 2016 at 20:13, zimbatm <zimb...@zimbatm.com> wrote:
>
> Hi Bas,
>
> It looks like it's only taking the first host from the list[1]. I suppose
> the intention was to provide fallbacks but it didn't get implemented.
>
> [1]: https://github.com/NixOS/nix/blob/master/src/download-via-
> ssh/download-via-ssh.cc#L114
>
>
> On Sun, 20 Nov 2016 at 15:49 Bas van Dijk <v.dijk@gmail.com> wrote:
>
> Dear all,
>
> Is it possible to have multiple ssh-substituter-hosts, as in:
>
>   ssh-substituter-hosts = nix-ssh@host1 nix-ssh@host2
>
> The documentation[1] is not entirely clear on that.
>
> Bas
>
> [1] http://nixos.org/nix/manual/#ssec-ssh-substituter
> ___
> 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] Multiple ssh substituter hosts

[Bas van Dijk]

I see. Thanks for pointing me to the source.

I also see that supporting more hosts is listed as a TODO:


https://github.com/NixOS/nix/blob/master/src/download-via-ssh/download-via-ssh.cc#L18

Hopefully that gets implemented some day!

Cheers,

Bas

On 20 November 2016 at 20:13, zimbatm <zimb...@zimbatm.com> wrote:

> Hi Bas,
>
> It looks like it's only taking the first host from the list[1]. I suppose
> the intention was to provide fallbacks but it didn't get implemented.
>
> [1]: https://github.com/NixOS/nix/blob/master/src/download-via-
> ssh/download-via-ssh.cc#L114
>
>
> On Sun, 20 Nov 2016 at 15:49 Bas van Dijk <v.dijk@gmail.com> wrote:
>
>> Dear all,
>>
>> Is it possible to have multiple ssh-substituter-hosts, as in:
>>
>>   ssh-substituter-hosts = nix-ssh@host1 nix-ssh@host2
>>
>> The documentation[1] is not entirely clear on that.
>>
>> Bas
>>
>> [1] http://nixos.org/nix/manual/#ssec-ssh-substituter
>> ___
>> 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] Multiple ssh substituter hosts

[Bas van Dijk]

Dear all,

Is it possible to have multiple ssh-substituter-hosts, as in:

  ssh-substituter-hosts = nix-ssh@host1 nix-ssh@host2

The documentation[1] is not entirely clear on that.

Bas

[1] http://nixos.org/nix/manual/#ssec-ssh-substituter
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] NixOS UEFI+LUKS+LVM or UEFI+LUKS+ZFS

[Bas van Dijk]

Your installation steps look very similar to the following how-to I use
when setting up a new system. The most significant difference seems to be
that you're calling mkfs.jfs while I'm calling mkfs.ext4:

# See:
#
# *
https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#LVM_on_LUKS
#
# *
http://nixos.org/nixos/manual/sec-installation.html#sec-uefi-installation
#
#
# gdisk /dev/sda
# o   # create a new empty GUID partition table (GPT)
# Y   # This option deletes all partitions and created a new protective
MBR. Proceed Y/N?
# n   # add a new partition
# # Partition number, default 1
# # First sector
# +512M   # Last sector
# EF00# GUID (EFI System)
# n   # add a new partition
# # Partition number, default 2
# # First sector
# # Last sector
# 8E00# GUID (Linux LVM)
# w   # write table to disk and exit
# Y   # Do you want to proceed Y/N?
#
# cryptsetup luksFormat /dev/sda2
# YES
# 
# 
#
# mkfs.vfat /dev/sda1 -n BOOT
#
# cryptsetup open --type luks /dev/sda2 lvm
# 
#
# # # To activate an existing volume:
# # pvscan
# # vgchange -ay MyStorage
#
# pvcreate /dev/mapper/lvm
#
# vgcreate MyStorage /dev/mapper/lvm
#
# lvcreate -L 16G MyStorage -n swapvol
# lvcreate -l +100%FREE MyStorage -n rootvol
#
# mkfs.ext4 /dev/mapper/MyStorage-rootvol -L root
# mkswap/dev/mapper/MyStorage-swapvol -L swap
#
# swapon /dev/disk/by-label/swap
#
# mount /dev/disk/by-label/root /mnt
#
# mkdir /mnt/boot
#
# mount /dev/disk/by-label/BOOT /mnt/boot
#
# nixos-generate-config --root /mnt
#
# nix-env -i emacs
#
# emacs -nw /mnt/etc/nixos/configuration.nix
# Set:
# boot.loader.grub.device = "/dev/sda";
# boot.initrd.kernelModules = [ "fbcon" ];
#
# services.openssh = {
#   enable = true;
#   permitRootLogin = "yes";
# };
#
# boot.initrd.luks.devices = [
#   { name = "lvm";
# device = "/dev/sda2";
#   }
# ];
#
# nixos-install
# 
# 
#
# reboot


On 27 September 2016 at 21:02, Mark Gardner  wrote:

> I am new to NixOS. I definitely like what I have seen so far. Thank you.
>
> I would like to encrypt the root partition with LUKS upon which LVM or ZFS
> would provide /, swap, /home etc. I used https://nixos.org/wiki/Encrypt
> ed_Root_on_NixOS and
> https://bluishcoder.co.nz/2014/05/14/installing-nixos-with-e
> ncrypted-root-on-thinkpad-w540.html as inspiration in my experiments in
> Vbox. Here is how I set up the disk for the UEFI+LUKS+LVM case:
>
> parted /dev/sda mktable gpt
> sgdisk -n1:1M:+1M   -t1:EF02 -c1:GRUB /dev/sda
> sgdisk -n2:2M:+512M -t2:EF00 -c2:BOOT /dev/sda
> sgdisk -n3:0:0  -t3:8E00 -c3:LUKS /dev/sda
>
> cryptsetup luksFormat /dev/sda3
> cryptsetup luksOpen /dev/sda3 enc-pv
>
> pvcreate /dev/mapper/enc-pv
> vgcreate vg /dev/mapper/enc-pv
> lvcreate -L 1G -n swap vg
> lvcreate -l 1662 -n root vg  # lvcreate -L 40G vg -> 1662 extents
>
> mkfs.msdos -F32 -n BOOT /dev/sda2
> mkfs.jfs -L ROOT /dev/vg/root
> mkswap -L SWAP /dev/vg/swap
>
> mount /dev/vg/root /mnt
> mount /dev/sda2 /mnt/boot
> swapon /dev/vg/swap
>
> Here is my configuration.nix:
> { config, pkgs, ... }:
>
> {
>   imports =
> [ # Include the results of the hardware scan.
>   ./hardware-configuration.nix
> ];
>
>   boot.loader.grub.enable = true;
>   boot.loader.grub.version = 2;
>   boot.loader.grub.device = "/dev/sda";
>   boot.initrd.luks.devices = [
> {
>   name = "luksroot";
>   device = "/dev/sda3";
>   preLVM = true;
> }
>   ];
>
>   networking.hostName = "nixos";
>
>   system.stateVersion = "16.03";
> }
>
> When I rebooted after installation, it seems to hang after prompting for
> the LUKS password. I have searched the mailing list archives and can't find
> anything that indicates where it is going wrong.
>
> Does anyone have a configuration.nix that combines LUKS with LVM? Or with
> ZFS? (Ultimately, I want to use ZFS. I am only using LVM to figure out
> where the problem lies. Apparently the problem is related to LUKS.)
>
> Mark
> --
> Mark Gardner
> --
>
> ___
> 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] NixOps usage survey.

[Bas van Dijk]

If you work in a team, definitely pin your nixpkgs revision.

At LumiGuide we use a variation of the technique outlined in
https://garbas.si/2015/reproducible-development-environments.html.

Bas


On 12 September 2016 at 11:05, Tobias Pflug  wrote:

> If I may just jump in with a question: What I feel uneasy about is to just
> use some channel. Is that what everyone does? I usually pinpoint a specific
> commit so that i know that my deployments are actually deterministic about
> what nixpkgs set is being used.
>
> Am I just being paranoid/impractical? Maybe it is even an anti-pattern
> since I obviously have to manually update then.
>
> Thanks in advance for any input :)
>
> -Tobi
>
> Sent from my iPhone
>
> > On 06 Sep 2016, at 15:06, Игорь Пашев  wrote:
> >
> > I'm using NixOps in production, EC2, Hetzner, VBox with no issues.
> >
> > Of course, commit NixOps state (JSON) in git with git-crypt. And this
> > wrapper for NixOps:
> >
> > #!/usr/bin/env bash
> >
> > set -euo pipefail
> >
> > NIXPKGS=https://github.com/NixOS/nixpkgs-channels/
> archive/nixos-15.09.tar.gz
> > NIXOPS=${NIXOPS:-nixops}
> > export NIX_PATH=nixpkgs="$NIXPKGS":.
> >
> > usage () {
> > cat < > Usage: $0   [nixops options]
> > Examples:
> >  $0 deploy realms/vbox.nix
> >  $0 info realms/vbox.nix
> >  $0 deploy realms/dumpoo.nix --build-only
> >  $0 destroy realms/cats.nix --include slothcat
> > USAGE
> > }
> >
> > fatal () {
> >  echo '** ERROR:' "$@" >&2
> >  usage >&2
> >  exit 1
> > }
> >
> > if [ $# -lt 2 ]; then
> >  fatal "missing agruments."
> > fi
> >
> > CMD="$1"; shift
> > REALM_NIX="$1"; shift
> >
> > case "$REALM_NIX" in
> >  *realms/*.nix) REALM=$(basename "$REALM_NIX" .nix);;
> >  *) fatal "invalid realm spec: $REALM_NIX";;
> > esac
> >
> > cd "$(dirname "$0")"
> >
> > state="secrets/nixops-${REALM}.json"
> > db=$(mktemp -u "secrets/tmp.${REALM}.XX.nixops")
> >
> > trap 'save' EXIT
> >
> > save() {
> >  if [ -f "$db" ]; then
> >"$NIXOPS" export -s "${db}" > "${state}.tmp"
> >mv "${state}.tmp" "${state}"
> >rm -f "$db"*
> >  fi
> > }
> >
> > create() {
> >  "$NIXOPS" create -s "$db" -d "$REALM" ""
> > }
> >
> > case "$CMD" in
> >  create)
> >[ ! -f "$state" ] || fatal "\`$state' already exists."
> >create
> >;;
> >  *)
> >[ -f "$state" ] || fatal "\`$state' does not exists."
> >"$NIXOPS" import -s "${db}" < "$state"
> >"$NIXOPS" "$CMD" -s "$db" -d "$REALM" "$@"
> >;;
> > esac
> >
> >
> >
> > And makefile for development with vbox;
> >
> > REALM = cats
> > override STATE = secrets/nixops-vbox-$(REALM).json
> >
> > build: $(STATE)
> >./let deploy realms/vbox-$(REALM).nix --build-only
> >
> > destroy:
> >./let $@ realms/vbox-$(REALM).nix --confirm
> >
> > info deploy check send-keys start stop reboot: $(STATE)
> >./let $@ realms/vbox-$(REALM).nix
> >
> > $(STATE):
> >./let create realms/vbox-$(REALM).nix
> >
> > 2016-09-05 19:01 GMT+03:00 Aloïs Cochard :
> >> Hi all,
> >>
> >> We are experimenting with NixOps and we are having great success. We do
> plan
> >> to use it for our development infrastructure, and it seems to be very
> >> promising.
> >>
> >> In the light of applying the same technology on our production stack,
> I'm
> >> curious to know how NixOps is used "for real"? Do you use it in
> production?
> >>
> >> Do you have some success story to share?
> >>
> >> Would love to know more about how it is used, the size of clusters, ...
> >>
> >> Thanks in advance!
> >>
> >> --
> >> Λ\oïs
> >> http://twitter.com/aloiscochard
> >> http://github.com/aloiscochard
> >>
> >> ___
> >> 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

Re: [Nix-dev] NixOps usage survey.

[Bas van Dijk]

Hi Aloïs,

We use nixops at LumiGuide to deploy to our network of image analysis
servers that power our bicycle detection and guidance systems[1]. I
recently gave a talk[2] at ZuriHac and MuniHac that contained a few slides
on our usage of nixops.

A few machines in our network are at Hetzner ('hetzner' backend) and the
rest are real physical machines managed by ourselves ('none' backend).

Some tips:

1) nixops stores state so if in order for my colleagues to share that state
I commit the state.nixops file to revision control and pass it to every
nixops invocation with the `-s state.nixops` option.

2) Do make sure that when you commit your state.nixops file to revision
control you encrypt it because it contains private SSH keys! I'm using
git-crypt for that.

3) If you create your network using something like:

  nixops create -s state.nixops -d my-net \
my-net.nix my-net-hardware.nix

it will have the problem that the path to the Nix expressions stored in the
state will be absolute:

  nixops info -s state.nixops | grep 'Nix expressions'
  Nix expressions: /home/bas.van.dijk/engineering/my-net/my-net.nix
/home/bas.van.dijk/engineering/my-net/my-net-hardware.nix

This will hurt when you share that state with your colleagues who will very
likely have their Nix expressions stored at a different path. To solve it
you want to make the paths relative to your NIX_PATH using something like:

  nixops create -s state.nixops -d my-net \
'' ''

4) Note that I separate the logical configuration from the physical
configuration. This allows me to take the logical configuration and combine
it with a virtual hardware configuration which is useful for testing.

5) I use a Makefile that has targets for all the common nixops invocations.
The Makefile also sets some useful environment variables like:

  export NIX_PATH:=nixpkgs=$(shell nix-build --no-out-link
./nixpkgs.nix):lumi=$(shell pwd)

  export HETZNER_ROBOT_PASS=$(shell cat secrets/HETZNER_ROBOT_PASS)
  export HETZNER_ROBOT_USER=

Note that 'lumi' points to the root of our LumiGuide repository. This
allows us to use  in Nix expressions where 'some-path' will
be relative to the repository.

I can recommend nixops very much!

Cheers,

Bas

[1]
https://bicycledutch.wordpress.com/2015/06/09/bicycle-parking-guidance-system-in-utrecht/
[2] https://www.youtube.com/watch?v=IKznN_TYjZk

On 5 September 2016 at 18:01, Aloïs Cochard  wrote:

> Hi all,
>
> We are experimenting with NixOps and we are having great success. We do
> plan to use it for our development infrastructure, and it seems to be very
> promising.
>
> In the light of applying the same technology on our production stack, I'm
> curious to know how NixOps is used "for real"? Do you use it in production?
>
> Do you have some success story to share?
>
> Would love to know more about how it is used, the size of clusters, ...
>
> Thanks in advance!
>
> --
> *Λ\oïs*
> http://twitter.com/aloiscochard
> http://github.com/aloiscochard
>
> ___
> 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] Announcing nix-buffer, nix-shell for emacs

[Bas van Dijk]

That seems useful. Thanks for sharing!

Bas

On 5 September 2016 at 18:10, Shea Levy <s...@shealevy.com> wrote:

> Sure! In my .emacs, I have:
>
> > (defun nix-buffer-find-file-hook ()
> >   (when (not (file-remote-p (buffer-file-name)))
> > (nix-buffer)))
> > (add-hook 'find-file-hook 'nix-buffer-find-file-hook)
>
> I have coq 8.5pl1 installed in my configuration.nix, but I have a coq
> project that requires 8.4pl6, so I have in that project's root directory
> dir-locals.nix:
>
> > let pkgs = import  {}; in
> >   pkgs.nixBufferBuilders.withPackages [ pkgs.coq ]
>
> (note that this relies on a recent nixpkgs commit[1]). Then whenever I
> open a .v file in the project, ProofGeneral uses coq 8.4 rather than
> 8.5.
>
> If I wanted, my dir-locals.nix could take a 'root' argument, which would
> point to the file I opened.
>
> ~Shea
>
> [1]: https://github.com/NixOS/nixpkgs/commit/
> 05c132486d8cfae600bbfe8c9ac5d799b298afed
>
> Bas van Dijk <v.dijk@gmail.com> writes:
>
> > Hi Shea,
> >
> > As a Nix and Emacs user this looks very interesting. I didn't know about
> > Buffer-Local Variables before.
> >
> > Can you share some applications of nix-buffer / how you are using it?
> >
> > Thanks!
> >
> > Bas
> >
> > On 5 September 2016 at 08:06, Shea Levy <s...@shealevy.com> wrote:
> >
> >> Hi all,
> >>
> >> I've just pushed the initial version of nix-buffer[1], and opened a PR
> >> for adding it to melpa[2]. The description of the 'nix-buffer-enter'
> >> command this library defines:
> >>
> >> > Set up the buffer according to the directory-local nix expression.
> >> >
> >> > Looks for dir-locals.nix upward from the current directory.  If found,
> >> > builds the derivation defined there with the 'root' arg set to the
> >> > current buffer file name or directory and evaluates the resulting
> >> > elisp if safe to do so.
> >> >
> >> > Because in practice dir-locals.nix will always want to do things that
> >> > are unsafe in dir-locals.el (e.g. append to 'exec-path'), we don't
> >> > reuse that mechanism and instead just load the file as elisp.  Because
> >> > this allows arbitrary code execution, the first time we're asked to
> >> > load a particular store path we query the user to verify if it's safe
> >> > to load beforehand.
> >> >
> >> > The Lisp code generated by dir-locals.nix should limit itself to
> >> > modifying buffer-local variables, but there is no actual enforcement
> >> > of this.  'setq-local' is your friend.
> >>
> >> It may be useful to advise the 'normal-mode' function to call
> >> 'nix-buffer-enter' beforehand for local files, so that all visited files
> >> have their environments set up before modes are loaded.
> >>
> >> Note that this is my first elisp package, so feedback definitely
> >> welcome!
> >>
> >> In addition to the elisp work mentioned in the TODO[3], it would be
> >> useful to add some functions to nixpkgs to build elisp files,
> >> especially:
> >>
> >> * A function taking a derivation and building an elisp file that sets up
> >>   the buffer environment analogous to the build environment specified by
> >>   that derivation
> >> * A function taking a list of packages and building an elisp file that
> >>   sets up the buffer environment with all of those packages available
> >>   (in PATH, in the emacs load path, etc.).
> >>
> >> Happy hacking!
> >>
> >> ~Shea
> >>
> >> [1]: https://github.com/shlevy/nix-buffer/tree/v1.0
> >> [2]: https://github.com/melpa/melpa/pull/4204
> >> [3]: https://github.com/shlevy/nix-buffer/blob/v1.0/TODO.md
> >>
> >> ___
> >> 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] Announcing nix-buffer, nix-shell for emacs

[Bas van Dijk]

Hi Shea,

As a Nix and Emacs user this looks very interesting. I didn't know about
Buffer-Local Variables before.

Can you share some applications of nix-buffer / how you are using it?

Thanks!

Bas

On 5 September 2016 at 08:06, Shea Levy  wrote:

> Hi all,
>
> I've just pushed the initial version of nix-buffer[1], and opened a PR
> for adding it to melpa[2]. The description of the 'nix-buffer-enter'
> command this library defines:
>
> > Set up the buffer according to the directory-local nix expression.
> >
> > Looks for dir-locals.nix upward from the current directory.  If found,
> > builds the derivation defined there with the 'root' arg set to the
> > current buffer file name or directory and evaluates the resulting
> > elisp if safe to do so.
> >
> > Because in practice dir-locals.nix will always want to do things that
> > are unsafe in dir-locals.el (e.g. append to 'exec-path'), we don't
> > reuse that mechanism and instead just load the file as elisp.  Because
> > this allows arbitrary code execution, the first time we're asked to
> > load a particular store path we query the user to verify if it's safe
> > to load beforehand.
> >
> > The Lisp code generated by dir-locals.nix should limit itself to
> > modifying buffer-local variables, but there is no actual enforcement
> > of this.  'setq-local' is your friend.
>
> It may be useful to advise the 'normal-mode' function to call
> 'nix-buffer-enter' beforehand for local files, so that all visited files
> have their environments set up before modes are loaded.
>
> Note that this is my first elisp package, so feedback definitely
> welcome!
>
> In addition to the elisp work mentioned in the TODO[3], it would be
> useful to add some functions to nixpkgs to build elisp files,
> especially:
>
> * A function taking a derivation and building an elisp file that sets up
>   the buffer environment analogous to the build environment specified by
>   that derivation
> * A function taking a list of packages and building an elisp file that
>   sets up the buffer environment with all of those packages available
>   (in PATH, in the emacs load path, etc.).
>
> Happy hacking!
>
> ~Shea
>
> [1]: https://github.com/shlevy/nix-buffer/tree/v1.0
> [2]: https://github.com/melpa/melpa/pull/4204
> [3]: https://github.com/shlevy/nix-buffer/blob/v1.0/TODO.md
>
> ___
> 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] Hardening flags enabled by default

[Bas van Dijk]

Thank you very much. Can't wait to deploy this to our LumiGuide
workstations and production servers. Great work!

16.09 is looking to be an exciting release, just like 16.03 was!

Cheers,

Bas

On 22 August 2016 at 13:31, Franz Pletz  wrote:

> Hi,
>
> yesterday the hardening-stdenv branch was merged to staging and is
> slated to hit master soon. Here is the pull requests with lots of
> comments: https://github.com/NixOS/nixpkgs/pull/12895
>
> This is a work globin and myself did for the last 6 months. We have
> been running that branch on our laptops and on production servers for
> months now and fixed many compilation and runtime errors in the
> process. We think it is ready now and should be included in he upcoming
> 16.09 release.
>
> For background information and how to fix your packages if they fail
> now (i.e. runtime errors we didn't catch), we have written documentation
> that is available in the nixpkgs manual:
>
>   https://hydra.nixos.org/build/38504599/download/1/nixpkgs/
> manual.html#sec-hardening-in-nixpkgs
>
> If you package new software and encounter unexpected compiler errors,
> chances are you hit some problem with a hardening flag. In the manual
> you will find the compiler errors we have encountered most of the time
> for every hardening flag.
>
> Should you encounter problems or have any other issues with the
> hardening flags, please open an issue in the nixpkgs repo and ping
> @globin and @fpletz. We have to fix those before 16.09. ;)
>
> Cheers,
> Franz
>
> ___
> 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] Building with default.nix

[Bas van Dijk]

Indeed, I use the following function in my projects:

  # Copy everything under src into the Nix store except
  # those paths that don't have one of the specified
  # allowedPrefixes.
  whitelistSource = src: allowedPrefixes:
builtins.filterSource
  (path: type:
lib.any (allowedPrefix: lib.hasPrefix
   (toString (src + "/${allowedPrefix}"))
   path
) allowedPrefixes
  ) src;

In my Haskell projects I use it like:

 src = whitelistSource ./. [
  "my-project.cabal"
  "src"
];

All other non-essential files like "dist", ".ghci", etc. are automatically
filtered out.

Bas

On 11 August 2016 at 18:50, Daniel Barlow  wrote:

> Have you considered using builtins.filterSource ?  I usually do something
> like this:
>
> let sourceFilesOnly = path: type:
> (lib.hasPrefix "var" (toString path)) ||
> (lib.hasPrefix "target" (toString path)) ;
> in stdenv.mkDerivation {
> src = builtins.filterSource sourceFilesOnly ./.;
> # ...
>
> It's not as tight as "git tracked files only" but works well enough for
> e.g. Clojure projects where I can reasonably get build artefacts to go into
> target/ so at least I'm not copying huge jar files into the store.
> Likewise in a Ruby project I'd exclude vendor/bundle the same way
>
> Any use?
>
> -dan
>
> --
> d...@telent.net
> http://ww.telent.net
>
> ___
> 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] Amsterdam Nix meetup

[Bas van Dijk]

Thanks for setting this up!

I just joined and wouldn't mind giving a talk about our network of NixOS
machines that we (LumiGuide) deployed[1] across Dutch bicycle parking
facilities (including deployments in Amsterdam).

Cheers,

Bas

[1]
https://bicycledutch.wordpress.com/2015/06/09/bicycle-parking-guidance-system-in-utrecht/

On 29 June 2016 at 11:42, Maarten Hoogendoorn  wrote:

> Hi felllow nixers,
>
> I've started a Amsterdam Nix meetup [1] and plan to speak a bit more at
> other meetups about nix. If you're interested in attending and/or speaking
> at this meetup!, please register (or send an email to me).
>
> [1] http://www.meetup.com/Amsterdam-Nix-Meetup/
>
> ___
> 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 string as path to eg. builtins.readFile

[Bas van Dijk]

On 19 June 2016 at 15:58, 4levels <4lev...@gmail.com> wrote:
> builtins.readFile "./keys/${name}"

Hi Erik, try this:

  builtins.readFile (./keys + "/${name}")
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Raspberry-Pi NixOS

[Bas van Dijk]

I'm also really interested in getting NixOS to run on Raspberry-Pi 2/3. At
LumiGuide we have many Raspberry Pi's deployed in the field running Debian.
It would be great to replace that with NixOS like all our other machines.
Op 15 jun. 2016 2:01 p.m. schreef "Matthias Beyer" :

> Hi viric,
> Hi dezgeg,
>
> I just found the wiki page on nixos on the raspberry[0], where you two are
> referenced as creators.
>
> May I ask whether this is still present? I plan on buying a Raspberry Pi
> model
> B, 3rd generation and build a small handheld linux terminal (see [1]) with
> it,
> but I really want to run nixos on it and be able to deploy software for it
> from
> my other devices (mainly because of recompilation times - or are there a
> nixpkgs
> substitutes for ARM available?).
>
> So my question is basically: Is this article still relevant to the current
> situation, as the article is almost one year old?
>
> Of course I will document my experience and share it with the NixOS
> community
> after I created the device.
>
> [0]: https://nixos.org/wiki/Raspberry_Pi_2
> [1]:
> http://makezine.com/projects/build-raspberry-pi-powered-linux-laptop-that-fits-your-pocket/
>
> --
> Mit freundlichen Grüßen,
> Kind regards,
> Matthias Beyer
>
> Proudly sent with mutt.
> Happily signed with gnupg.
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Haskell Development and Deployment Strategies (was: Stackage Support Will Be Discontinued)

[Bas van Dijk]

Just as a point of reference, in my job at LumiGuide I'm in camp 4: "I want
total control over my entire package set."

* We run a high-profile production system consisting of multiple NixOS
machines deployed using nixops to physical machines across the Netherlands
and to machines on Hetzner. I also consider our NixOS development
workstations to be part of the system. The configuration of all machines is
defined by a single repository.

* In that repository we set our nixpkgs to our own fork of nixpkgs which
basically tracks the latest release (currently
https://github.com/NixOS/nixpkgs-channels/tree/nixos-16.03) and adds a few
of our own commits on top. We use a variation of Rok Garbas's
 "Reproducable development environments" trick [1].

* Every 3 weeks or so I run a script which:
  1. shows me the git log between our revision of nixpkgs and the latest
upstream
  2. set our revision of nixpkgs to the latest upstream with our own
commits rebased on top of it
  3. push that to a special "staging" branch.

* We run our own hydra CI server which starts building the staging branch.
When it builds successfully I merge staging into master and update all our
machines (including our development workstations).

* We also extend and override nixpkgs using its packageOverrides
functionality. The following is the Haskell part of our override function:

  super:
  let self = super.pkgs;
  haskellOverrides = import ./haskell super;
  in rec {
haskellPackages =
  super.haskellPackages.override haskellOverrides;
haskell = super.haskell // {
  packages = super.haskell.packages // {
ghcjs  =
  super.haskell.packages.ghcjs.override
haskellOverrides;
  };
};
profiledHaskellPackages =
  super.haskellPackages.override {
overrides = self: super: {
  mkDerivation = args:
super.mkDerivation (args // {
  enableLibraryProfiling = true;
});
} // haskellOverrides.overrides self super;
  };
...
  }

* The Haskell overrides function defined in ./haskell/default.nix adds all
our LumiGuide specific Haskell packages and overrides some existing
packages to newer versions:

  pkgs :
  {
overrides = self : super :
  let hsLibsFromDir = dir :
pkgs.lib.genAttrs
  (builtins.attrNames (builtins.readDir dir))
  (name : self.callPackage
(dir + "/${name}") {});
  inhsLibsFromDir ./.
 // hsLibsFromDir ../../hs-libs
 // hsLibsFromDir ../../hs-js-libs;
  }

* Note that we aren't using the lts package set. I'm not sure if we
should...

I just want to provide this as a datapoint of one actual use of the Haskell
infrastructure of nixpkgs.

Regards,

Bas

[1] https://garbas.si/2015/reproducible-development-environments.html)

On 10 June 2016 at 13:23, Peter Simons  wrote:

> Fellow Haskell Hackers,
>
> Nix gives you great freedom to choose how to develop and deploy your
> Haskell software. That's good, but at the same time that flexibility can
> be confusing and feel like a burden. Therefore, I'd like to shed some
> light on this issue and discuss different types of strategies and their
> respective pros and cons. Which strategy is best for you depends on what
> you would like to achieve:
>
>   1. I want the latest version of every package as quickly as possible
>  because I love it when build attempts result in hundreds of
>  compiler errors that I can fix.
>
>   2. I want my Haskell packages to be up-to-date, but I also want my
>  builds to be reliable. I don't mind fixing the occasional build
>  error, but I mean, like, *occasionally*.
>
>   3. I want my Haskell package set to be rock solid. I don't want any
>  updates unless there is a major security issue or a severe bug that
>  threatens the integrity of my system.
>
>   4. I want total control over my entire package set.
>
> Now, let's go through the options those types of users have.
>
> If you favor features over stability as in (1), then you should develop
> with 'cabal-install', really. Nixpkgs might be useful for installing
> your favorite development tools like GHC, cabal, stack, alex, happy,
> Emacs, vi, etc., but installing bleeding-edge Haskell libraries via Nix
> is not a use-case we try to fulfill. If you absolutely *want* bleeding
> edge libraries in Nix, then you'll have to define those builds yourself
> with cabal2nix. The Nixpkgs user manual [1] explains how to do this.
>
> Users who want a balance of features and stability as in (2) should base
> their efforts on haskell.packages.lts, which will become haskellPackages
> after the imminent re-organization. That package set is continuously
> tested on hydra.nixos.org (or rather: it will be soon) and therefore
> tends to compile successfully on all platforms. It receives point
> updates that fix bugs and security issues, yet package APIs don't change
> so updates are unlikely 

Re: [Nix-dev] NixOps - merge config files

[Bas van Dijk]

On 9 June 2016 at 08:54, 4levels <4lev...@gmail.com> wrote:
> ...
> I've modified my nixops deploy to have keys.nix loaded after the servers.nix 
> and platforms.nix files, but I keep getting errors like "the attribute 
> password does not exist"

What's the output of: 'nixops info' for your deployment?

> The underlying reason is that I'm using git-crypt to encrypt the 
> platforms.nix file, but this makes it impossible to work with branches (or 
> git logs) etc. as the whole file is encrypted and git cannot merge binary 
> files (it simply replaces them).

I'm also using git-crypt to secure my secrets. I would suggest not
encrypting the full nix expression but just the actual secret like:

  {
services.symfony.platforms.database.password = builtins.readFile
./secrets/database-password;
...
  }

then encrypt everything under ./secrets.

Regards,

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

Re: [Nix-dev] How to set up your own Hydra server (video tutorial)

[Bas van Dijk]

Great video Peter!

I learned a few things I didn't know yet about hydra and immediately
applied them to our private hydra.lumi.guide.

Thank you.

Bas

On 16 February 2016 at 10:10, Peter Simons  wrote:

> Hi folks,
>
> as promised before [1], my presentation from the January NixOS Meet-up
> in Berlin is now available on Youtube:
>
> https://www.youtube.com/watch?v=RXV0Y5Bn-QQ
>
> The video is provides a tutorial how to configure your own Hydra server.
> There is a bunch of configuration files at
>
> https://github.com/peti/hydra-tutorial
>
> that you can feed to Nixops to deploy a distributed build farm using
> virtual machines running on your desktop or laptop, but obviously the
> setup works fine in anyone's configuration.nix file on real hardware,
> too.
>
> Please know that I am by no means an expert on Hydra and there are a lot
> of topics that the presentation doesn't cover! It's probably good enough
> to get you started using Hydra for continuous integration for populating
> your personal binary cache, but questions like release management or how
> to set up your distribution channel aren't covered.
>
> Anyway, if you have questions about the subject, please feel free to ask
> in this thread or, if you prefer, in the comment section of the Youtube
> video.
>
> Best regards,
> Peter
>
>
> [1] http://lists.science.uu.nl/pipermail/nix-dev/2016-January/019271.html
>
> ___
> 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] My Hydra can't send mail

[Bas van Dijk]

Thanks Eelco and Peter!

I went with the solution from Peter because I had problems in the past
with programs using ssmtp instead of postfix.

Cheers,

Bas

On 5 January 2016 at 13:09, Peter Simons  wrote:
> Eelco Dolstra writes:
>
>  > You probably need to change the line
>  >
>  >   path = [ pkgs.nettools pkgs.ssmtp ];
>  >
>  > in the Hydra module to
>  >
>  >   path = [ pkgs.nettools pkgs.postfix ];
>  >
>  > or something like that. Or maybe add the sendmail setuid wrapper to the 
> path.
>
> personally, I've found it useful to re-direct all users of ssmtp to
> Postfix by including the following override in my configuration.nix
> file:
>
>   nixpkgs.config = {
> packageOverrides = pkgs: {
>   ssmtp = pkgs.stdenv.mkDerivation {
> name = "sendmail-setuid-wrapper-0";
> buildCommand = ''
>   mkdir -p $out/sbin
>   echo  >$out/sbin/sendmail "#! $SHELL"
>   echo >>$out/sbin/sendmail 'exec /var/setuid-wrappers/sendmail "$@"'
>   chmod +x $out/sbin/sendmail
> '';
>   };
> };
>   };
>
> That certainly works fine on hydra.cryp.to.
>
> I hope this helps,
> Peter
>
> ___
> 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] My Hydra can't send mail

[Bas van Dijk]

I recently deployed my own Hydra server but I think it has a problem
sending mail because I see the following in the journal:

  hydra-queue-runner[24341]:
Hydra::Plugin::EmailNotification=HASH(0x4f4b1e8)->
  buildFinished: error when closing pipe to sendmail:
  hydra-queue-runner[24341]: sendmail: Cannot open mailhub:25
  sSMTP[21796]: Cannot open mailhub:25
  sSMTP[21796]: Unable to locate mailhub
  sSMTP[21796]: /etc/ssmtp/ssmtp.conf not found

For full logs see: http://www.mpaste.com/p/cNwe

Do note that I have a postfix service running on that machine:

  services.postfix.enable = true;

And services.postfix.setSendmail is kept to the default of true which
means that the sendmail in the PATH is postfix's sendmail.

How can I let hydra use postfix's sendmail properly?

Cheers,

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

Re: [Nix-dev] Building Haskell Package with Tests and Data Files.

[Bas van Dijk]

Why didn't I think of that...

Thanks Peter!

On 22 December 2015 at 21:32, Peter Simons  wrote:
> Hi Bas,
>
>  > I have a Haskell library that contains a test-suite. The test
>  > requires a data file of the package. When building the package with
>  > nix-build the test is run but fails because the path to the data file
>  > is wrong.
>
> "cabal test" executes test suites with the current working directory set
> to the top-level directory of your source code, i.e. the same place
> where the "myLib.cabal" file is. Therefore, your test code can refer to
> the data file reliably as "data/Lenna.png".
>
> If you ever want to release that project on Hackage, make sure to
> add an attribute like
>
>   extra-source-files: data/*
>
> in your Cabal file, otherwise those data files will not be included in
> the generated release tarball. If you're fine with those files being
> *installed*, then the attribute
>
>   data-files: data/*
>
> is preferable, of course.
>
> Best regards,
> Peter
>
> ___
> 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] Non-Garbage-Collected Development Environments

[Bas van Dijk]

Hi Aristid,

That's exactly what I need, thanks!

It would be nice to get this documented.

Cheers,

Bas

On 22 December 2015 at 17:55, Aristid Breitkreuz <arist...@gmail.com> wrote:
> nix-shell supports --add-root. The command should be something like this:
>
> nix-shell --indirect --add-root shell/deps
>
> (You should have a / in there to put all dependencies into a single
> directory, as it generates foo-1, foo-2... files.)
>
> Bas van Dijk <v.dijk@gmail.com> schrieb am Di., 22. Dez. 2015 um 17:01
> Uhr:
>>
>> Thanks Tomasz! I didn't know about gc-keep-outputs. I'll try it out.
>>
>> On 20 December 2015 at 18:51, Tomasz Kontusz <tomasz.kont...@gmail.com>
>> wrote:
>> > I think the nix-instantiate trick will only stop the GC if you have
>> > "gc-keep-outputs = true" in nix.conf.
>> >
>> > On 20.12.2015 18:16, Bas van Dijk wrote:
>> >> Hello,
>> >>
>> >> At LumiGuide we're working on several projects. Each project has its
>> >> own attribute. To work on a project we can use nix-shell to enter a
>> >> development environment for that project like:
>> >>
>> >>nix-shell -A myProject
>> >>
>> >> The problem is that once in a while our engineers need to garbage
>> >> collect their systems. When they run nix-collect-garbage some or all
>> >> of the dependencies of myProject might get collected. How can I
>> >> prevent this from happening?
>> >>
>> >> I tried using the approach described in the wiki [1]. We can register
>> >> myProject.drv as a garbage collector root:
>> >>
>> >>$ nix-instantiate -A myProject \
>> >>--indirect --add-root $PWD/myProject.drv
>> >>
>> >> Then we can enter the environment using:
>> >>
>> >>$ nix-shell $PWD/myProject.drv
>> >>
>> >> However, this doesn't prevent the dependencies from being collected
>> >> since myProject.drv only depends on the .drv files of the
>> >> dependencies, i.e. not the actual realized store paths.
>> >>
>> >> I think myEnvFun might be the solution but the wiki mentions it's
>> >> deprecated. Does anybody know what I should use instead?
>> >>
>> >> Cheers,
>> >>
>> >> Bas
>> >>
>> >> [1] https://nixos.org/wiki/Development_Environments
>> >> ___
>> >> 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

Re: [Nix-dev] Non-Garbage-Collected Development Environments

[Bas van Dijk]

Thanks Tomasz! I didn't know about gc-keep-outputs. I'll try it out.

On 20 December 2015 at 18:51, Tomasz Kontusz <tomasz.kont...@gmail.com> wrote:
> I think the nix-instantiate trick will only stop the GC if you have
> "gc-keep-outputs = true" in nix.conf.
>
> On 20.12.2015 18:16, Bas van Dijk wrote:
>> Hello,
>>
>> At LumiGuide we're working on several projects. Each project has its
>> own attribute. To work on a project we can use nix-shell to enter a
>> development environment for that project like:
>>
>>nix-shell -A myProject
>>
>> The problem is that once in a while our engineers need to garbage
>> collect their systems. When they run nix-collect-garbage some or all
>> of the dependencies of myProject might get collected. How can I
>> prevent this from happening?
>>
>> I tried using the approach described in the wiki [1]. We can register
>> myProject.drv as a garbage collector root:
>>
>>$ nix-instantiate -A myProject \
>>--indirect --add-root $PWD/myProject.drv
>>
>> Then we can enter the environment using:
>>
>>$ nix-shell $PWD/myProject.drv
>>
>> However, this doesn't prevent the dependencies from being collected
>> since myProject.drv only depends on the .drv files of the
>> dependencies, i.e. not the actual realized store paths.
>>
>> I think myEnvFun might be the solution but the wiki mentions it's
>> deprecated. Does anybody know what I should use instead?
>>
>> Cheers,
>>
>> Bas
>>
>> [1] https://nixos.org/wiki/Development_Environments
>> ___
>> 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] Building Haskell Package with Tests and Data Files.

[Bas van Dijk]

Hello,

I have a Haskell library that contains a test-suite. The test requires
a data file of the package. When building the package with nix-build
the test is run but fails because the path to the data file is wrong.
The following miminal project shows the problem:

  https://github.com/basvandijk/hs-test-failure-nix

Is there some way of building this package and succesfully running the
test suite using nix-build?

Cheers,

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

[Nix-dev] Non-Garbage-Collected Development Environments

[Bas van Dijk]

Hello,

At LumiGuide we're working on several projects. Each project has its
own attribute. To work on a project we can use nix-shell to enter a
development environment for that project like:

  nix-shell -A myProject

The problem is that once in a while our engineers need to garbage
collect their systems. When they run nix-collect-garbage some or all
of the dependencies of myProject might get collected. How can I
prevent this from happening?

I tried using the approach described in the wiki [1]. We can register
myProject.drv as a garbage collector root:

  $ nix-instantiate -A myProject \
  --indirect --add-root $PWD/myProject.drv

Then we can enter the environment using:

  $ nix-shell $PWD/myProject.drv

However, this doesn't prevent the dependencies from being collected
since myProject.drv only depends on the .drv files of the
dependencies, i.e. not the actual realized store paths.

I think myEnvFun might be the solution but the wiki mentions it's
deprecated. Does anybody know what I should use instead?

Cheers,

Bas

[1] https://nixos.org/wiki/Development_Environments
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] readFile applied to a path with a variable

[Bas van Dijk]

On 17 October 2015 at 20:21,   wrote:
> ./foo + "/${name}/bar" would also work

I like that even better, thanks.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] readFile applied to a path with a variable

[Bas van Dijk]

Thanks guys.

I got it to work with the following (note that name is actually a string):

  readFile (./foo + ("/" + name) + /bar)

I couldn't postfix ./foo with a slash because that gave a parse error
on +. The parentheses around ("/" + name) were also essential.

On 16 October 2015 at 16:54, Bryan Gardiner <b...@khumba.net> wrote:
> Not on Nix right now but I believe this also works:
>
> readFile (./foo + name + /bar)
>
> - Bryan
>
> On Fri, 16 Oct 2015 11:36:22 +0100
> Thomas Hunger <tehun...@gmail.com> wrote:
>
>> Do you need toPath?
>>
>> lib.readFile "./foo/${name}/bar"
>>
>> seems to work for me.
>>
>> On 16 October 2015 at 11:10, Bas van Dijk <v.dijk@gmail.com> wrote:
>>
>> > Hello,
>> >
>> > In a Nix expression I would like to read a file where the file path is
>> > based on a variable. So I would like to do something like this:
>> >
>> >   with builtins;
>> >   readFile (toPath ("./foo/" + name + "/bar"))
>> >
>> > Unfortunately this doesn't work since toPath expects a string which
>> > represents an absolute path.
>> >
>> > Is there any other way to do this?
>> >
>> > Cheers,
>> >
>> > Bas
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] readFile applied to a path with a variable

[Bas van Dijk]

Hello,

In a Nix expression I would like to read a file where the file path is
based on a variable. So I would like to do something like this:

  with builtins;
  readFile (toPath ("./foo/" + name + "/bar"))

Unfortunately this doesn't work since toPath expects a string which
represents an absolute path.

Is there any other way to do this?

Cheers,

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

Re: [Nix-dev] Possible bug in ssh key module

[Bas van Dijk]

On 11 May 2015 at 04:45, Anand Patil anand.prabhakar.pa...@gmail.com wrote:
 Hi everyone,


 Just wanted to point out a small possible bug in NixOS version
 15.05pre61966.75ebc3c (Dingo). I noticed that when I add an
 authorizedKeys option to my user like so:

 openssh.authorizedKeys.keys = [ ssh-rsa stuff ];

 the contents of /etc/ssh/authorized_keys.d/anand look like

 ssh-rsa
 stuff

 with a newline after the ssh-rsa,

Hi Anand,

The implementation looks correct. It only adds newlines between the keys:

https://github.com/NixOS/nixpkgs/blob/75ebc3cf1dc1365be5a05018fc8e5409c66025cb/nixos/modules/services/networking/ssh/sshd.nix#L55

Are you sure your string doesn't contain a newline? Maybe your text
editor added a newline when it wrapped the string.

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

Re: [Nix-dev] Failed to add route because network is unreachable

[Bas van Dijk]

On 28 April 2015 at 09:16, Kirill Elagin kirela...@gmail.com wrote:
 It would be nice if you showed us the output of `ip route` at the point
 where `ip route add` fails.
 Also `ip route get 136.243.17.1` might give some hints.

# ip route show
default via 136.243.17.1 dev eth0
136.243.17.0/26 via 136.243.17.1 dev eth0
172.16.48.16/28 dev eth0  proto kernel  scope link  src 172.16.48.17

# ip route get 136.243.17.1
136.243.17.1 via 136.243.17.1 dev eth0  src 136.243.17.41
cache

 It totally looks like the gateway you are trying to use is unreachable.

Indeed that's how I also understand the error message. The only thing
I don't understand is what unreachable means exactly. I can ping the
gateway just fine and I can reach hosts on the internet (meaning the
gateway is correctly routing my packages). Maybe it means my Linux
kernel doesn't allow sending packets to the gateway with a destination
in the private range 10.180.0.0/24 or with the private source address
172.16.48.17.

 To be honest, I have no idea what does the `mainIPv4  = 136.243.17.41;` line
 do, but feels like it doesn’t configure the routes (or even the address)
 properly.

Nixops will add the mainIPv4 address (136.243.17.41/26) to
networking.interfaces.eth0.ip4 after which the nixos networking module
configures the interface. Nixops will also add the surprising route:

ip -4 route change '136.243.17.0/26' via '136.243.17.1' dev 'eth0'

which is needed because in the Hetzner network it's required to route
all traffic (including traffic to my own subnet) to the gateway. (See:
http://wiki.hetzner.de/index.php/Netzkonfiguration_Debian/en)

Anyway, I'm glad I found a work-around by manually adding the route
without the gateway option.

Cheers,

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

Re: [Nix-dev] Failed to add route because network is unreachable

[Bas van Dijk]

I just discovered that I can successfully manually add the route if I
Ieave of the via gateway option:

# ip route add  10.180.0.0/24 src 172.16.48.17 dev eth0

After this I can successfully ping hosts on the other side of the VPN!

I'll just settle with adding this to my local networking commands:

networking.localCommands = ''
   ip route add 10.180.0.0/24 src 172.16.48.17 dev eth0 || true
'';

I do wonder though, why adding that route with a via gateway
option gives the aforementioned error.

Cheers,

Bas

On 27 April 2015 at 15:58, Bas van Dijk v.dijk@gmail.com wrote:
 Dear Nixers,

 I've a slightly off-topic question but since I know there are some
 excellent Unix networking experts on this list I hope to get a pointer
 in the right direction.

 After some changes in my networking setup (I added an IP address to my
 eth0 interface) my strongswan VPN service fails to add a route to my
 routing table (it used to work before):

 installing route: 10.180.0.0/24 via 136.243.17.1 src 172.16.48.17 dev eth0
 received netlink error: Network is unreachable (101)

 If I manually try to add the route I get the same error message:

 # ip route add  10.180.0.0/24 via 136.243.17.1 src 172.16.48.17 dev eth0
 RTNETLINK answers: Network is unreachable

 I've asked[1] the same question on the strongswan mailing list but
 haven't found a solution yet.

 My network settings are fairly simple (note I'm deploying my machine
 using nixops to Hetzner):

   deployment = {
 targetEnv = hetzner;
 hetzner = {
   mainIPv4  = 136.243.17.41;
   ...
 };
   };

   networking = {
 enableIPv6 = false;
 useDHCP = false;

 interfaces.eth0.ip4 = [
   { address = 136.243.25.125; prefixLength = 32; }
   { address = 136.243.25.108; prefixLength = 32; }
   { address = 172.16.48.17;   prefixLength = 28; }
 ];

 firewall = {
   enable= true;
   allowPing = true;
   allowedTCPPorts = [ ... ];
 }
   };

 Any idea why I can't add that route?

 Regards,

 Bas

 [1] https://lists.strongswan.org/pipermail/users/2015-April/007935.html
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Failed to add route because network is unreachable

[Bas van Dijk]

Dear Nixers,

I've a slightly off-topic question but since I know there are some
excellent Unix networking experts on this list I hope to get a pointer
in the right direction.

After some changes in my networking setup (I added an IP address to my
eth0 interface) my strongswan VPN service fails to add a route to my
routing table (it used to work before):

installing route: 10.180.0.0/24 via 136.243.17.1 src 172.16.48.17 dev eth0
received netlink error: Network is unreachable (101)

If I manually try to add the route I get the same error message:

# ip route add  10.180.0.0/24 via 136.243.17.1 src 172.16.48.17 dev eth0
RTNETLINK answers: Network is unreachable

I've asked[1] the same question on the strongswan mailing list but
haven't found a solution yet.

My network settings are fairly simple (note I'm deploying my machine
using nixops to Hetzner):

  deployment = {
targetEnv = hetzner;
hetzner = {
  mainIPv4  = 136.243.17.41;
  ...
};
  };

  networking = {
enableIPv6 = false;
useDHCP = false;

interfaces.eth0.ip4 = [
  { address = 136.243.25.125; prefixLength = 32; }
  { address = 136.243.25.108; prefixLength = 32; }
  { address = 172.16.48.17;   prefixLength = 28; }
];

firewall = {
  enable= true;
  allowPing = true;
  allowedTCPPorts = [ ... ];
}
  };

Any idea why I can't add that route?

Regards,

Bas

[1] https://lists.strongswan.org/pipermail/users/2015-April/007935.html
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Infinite recursion encountered after updating nixpkgs

[Bas van Dijk]

After updating nixpkgs nixops encounters an infinite recursion on most commands.

See: https://github.com/NixOS/nixops/issues/281 for details.

What's the best way to debug this?

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

Re: [Nix-dev] strongSwan problem

[Bas van Dijk]

I did report it here:

https://github.com/NixOS/nixpkgs/issues/5492#issuecomment-74257683

On 14 February 2015 at 11:03, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk wrote:
 On 02/10/2015 04:22 PM, Bas van Dijk wrote:
 I was wondering if somebody here has experience with strongSwan on NixOS.

 I'm having a problem connecting to a gateway as I described in the
 following mail to the strongSwan mailinglist:

 https://lists.strongswan.org/pipermail/users/2015-February/007422.html

 Cheers,

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


 From the e-mail:

I solved the no netkey IPsec stack detected errors. It turned out
 that the NixOS strongSwan conf

 I actually hit this before while attempting to use strongSwan myself.
 Maybe we should file an issue…

 --
 Mateusz K.
 ___
 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] strongSwan problem

[Bas van Dijk]

I was wondering if somebody here has experience with strongSwan on NixOS.

I'm having a problem connecting to a gateway as I described in the
following mail to the strongSwan mailinglist:

https://lists.strongswan.org/pipermail/users/2015-February/007422.html

Cheers,

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

[Nix-dev] Nixops: Unable to start SSH connection to Hetzner server

[Bas van Dijk]

Hello Nixers,

I would like to deploy NixOS to a Hetzner machine using nixops but I'm
running into a SSH connection issue described here:

https://github.com/NixOS/nixops/issues/258

Any idea what I'm doing wrong? Are Hetzner deployments still supported
in nixops?

Cheers,

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

[Nix-dev] nixops based virtualbox machine fails to deploy due to VERR_FILE_NOT_FOUND

[Bas van Dijk]

Hello,

I'm trying to deploy a nixops network where myMachine should be
deployed to a virtualbox VM:

  deployment.targetEnv = virtualbox;

However I'm getting the following error:

$ nixops deploy -d my-network -I ..
myMachine creating VirtualBox VM...
myMachine Virtual machine
'nixops-e299e202-7c41-11e4-9674-08002734fdef-myMachine' is created and
registered.
myMachine UUID: 67f7f03a-114e-41ef-8927-9e3983ff8bba
myMachine Settings file: '/home/bas.van.dijk/VirtualBox
VMs/nixops-e299e202-7c41-11e4-9674-08002734fdef-myMachine/nixops-e299e202-7c41-11e4-9674-08002734fdef-myMachine.vbox'
myMachine creating disk ‘disk1’...
myMachine these derivations will be built:
myMachine   
/nix/store/c5jny1wz14wlaimbfrmmmvz0z9iysqh7-virtualbox-nixops-13.10.35433.4721802.vdi.drv
myMachine building path(s)
`/nix/store/24i6jbkg83pdndf6w6z9axmp9v2scwrp-virtualbox-nixops-13.10.35433.4721802.vdi'
myMachine building
/nix/store/24i6jbkg83pdndf6w6z9axmp9v2scwrp-virtualbox-nixops-13.10.35433.4721802.vdi
myMachine
myMachine 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
myMachine Clone hard disk created in format 'VDI'. UUID:
58fff3fc-0057-4b91-ac2a-d5e7f330cd99
myMachine attaching disk ‘disk1’...
myMachine VBoxManage: error: Could not launch a process for the
machine 'nixops-e299e202-7c41-11e4-9674-08002734fdef-myMachine'
(VERR_FILE_NOT_FOUND)
myMachine VBoxManage: error: Details: code VBOX_E_IPRT_ERROR
(0x80bb0005), component Machine, interface IMachine, callee
nsISupports
myMachine VBoxManage: error: Context: LaunchVMProcess(a-session,
sessionType.raw(), env.raw(), progress.asOutParam()) at line 592 of
file VBoxManageMisc.cpp
error: command ‘['VBoxManage', 'startvm',
u'nixops-e299e202-7c41-11e4-9674-08002734fdef-myMachine']’ failed on
machine ‘myMachine’ (exit code 1

Note that the -I .. points to a nixpkgs with a recent checkout of
nixpkgs master.

Any idea what I'm doing wrong?

Cheers,

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

Re: [Nix-dev] Integration of Haste packages

[Bas van Dijk]

Hi Ryan,

Thanks for your efforts to get ghcjs integrated. I would like to try
out your fork by building a little ghcjs-based project. I generated
the following foo.nix file based on my cabal file using cabal2nix:

{ cabal, aeson, baseUnicodeSymbols, dataDefault, text
, unorderedContainers
, ghcjsJquery
}:

cabal.mkDerivation (self: {
  pname = foo;
  version = 0.0.1;
  src = ./.;
  isLibrary = false;
  isExecutable = true;
  buildDepends = [
aeson baseUnicodeSymbols dataDefault  text
unorderedContainers
ghcjsJquery
  ];
  meta = {
license = self.stdenv.lib.licenses.unfree;
platforms = self.ghc.meta.platforms;
  };
})

Now I would like to write a default.nix which will build this package
using ghcjs.

How should I go about doing that?

Any pointers are appreciated. Thanks!

Bas

On 25 September 2014 23:21, Ryan Trinkle ryan.trin...@gmail.com wrote:
 Hi Thomas,

 I recently got ghcjs integrated, so it may be helpful to take a look at my
 patches.  They're available at https://github.com/ryantrinkle/nixpkgs and
 are making their way upstream thanks to the efforts of Charles Strahan
 (https://github.com/cstrahan).


 Ryan

 On Thu, Sep 25, 2014 at 5:16 PM, Thomas Strobel ts...@cam.ac.uk wrote:

 Hi!

 I'm thinking of working on the integration of Haste packages into NixOS
 on the weekend. I want to hook onto the package management of Haskell,
 and adapt it for Haste.

 Now, I wanted to ask if someone already started to work on that or had
 any ideas or thoughts about it. If so, it would be nice if you would let
 me know about it.


 Many thanks,
 Thomas
 ___
 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

Re: [Nix-dev] FOSDEM: any plans for Saturday evening?

[Bas van Dijk]

On 27 Jan 2014 14:28, Cillian de Róiste cillian.deroi...@gmail.com
wrote:
 The talks should be finished by 19:00 so why don't we meet up at the main
infodesk shortly afterwards and take it from there?:

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

Re: [Nix-dev] FOSDEM: any plans for Saturday evening?

[Bas van Dijk]

That would be really nice! Count me in.

Bas

On 22 January 2014 13:50, Cillian de Róiste cillian.deroi...@gmail.com wrote:
 Hi,

 Since there will be quite a few NixOS and Guix folks at FOSDEM it would be
 great to meet up. Is there some interest in arranging dinner / drinks on
 Saturday evening?

 Cheers,
 Cillian

 ___
 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] nix-channel issue

[Bas van Dijk]

Hi Ambrus and Peter,

It works when I execute it as root or with sudo -E.

Thanks for your help!

Bas



On 17 January 2014 18:56, Peter Simons sim...@cryp.to wrote:
 Hi Bas,

   $ sudo nix-channel --update nixos

 does it make a difference if you use sudo -l or sudo -E instead?

 Take care,
 Peter

 ___
 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] nix-channel issue

[Bas van Dijk]

I get the following error while updating my nixos channel:

$ sudo nix-channel --update nixos
/run/current-system/sw/bin/nix-channel: unable to check
`https://nixos.org/channels/nixos-unstable'

Is this still the proper way to update or should I use something else?

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

[Nix-dev] NixOS AMI

[Bas van Dijk]

Hello,

I would like to try out NixOS on EC2. Are there any official NixOS
AMI's that I can trust?

Regards,

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

Re: [Nix-dev] NixOS AMI

[Bas van Dijk]

On 4 August 2013 16:29, Eelco Dolstra eelco.dols...@logicblox.com wrote:
 Yes.  The most recent AMIs are listed here: ...

Thanks Eelco!

I'm starting my NixOS adventure.

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