[Nix-commits] [NixOS/nixpkgs] d1ed24: iso_graphical: fix warning about Plasma 5 desktop ...

[Thomas Strobel]

hor: Eelco Dolstra <edols...@gmail.com>
  Date:   2017-03-06 (Mon, 06 Mar 2017)

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

  Log Message:
  ---
  Fix incorrect $NIX_BUILD_HOOK on Nix 1.12

(cherry picked from commit 3070c887987e9c24a72a5b7b18db29ebe1ed6d4c)


  Commit: 17f6e7bfdebe1bd327cb1a9851382ad21989751e
  
https://github.com/NixOS/nixpkgs/commit/17f6e7bfdebe1bd327cb1a9851382ad21989751e
  Author: Eelco Dolstra <edols...@gmail.com>
  Date:   2017-03-06 (Mon, 06 Mar 2017)

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

  Log Message:
  ---
  nix-daemon: Remove a bunch of unnecessary environment variables

(cherry picked from commit 3971876585eb0829a8fc2732c547743544fa706f)


  Commit: ad24ba30d3dbd463d6b1295830b86a5e67a00a68
  
https://github.com/NixOS/nixpkgs/commit/ad24ba30d3dbd463d6b1295830b86a5e67a00a68
  Author: Thomas Strobel 
<4ZKTUB6TEP74PYJOPWIR013S2AV29YUBW5F9ZH2F4D5UMJUJ6S@hash.domains>
  Date:   2017-03-06 (Mon, 06 Mar 2017)

  Changed paths:
M nixos/modules/virtualisation/qemu-vm.nix

  Log Message:
  ---
  fix: "nixos-rebuild build-vm-with-bootloader"

(cherry picked from commit 0a8d9779c5b3bce15b252bb0f31c94744107ecf6)


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

[Nix-commits] [NixOS/nixpkgs] b9a7aa: improve: modules/virtualisation/qemu-vm.nix

[Thomas Strobel]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: b9a7aacef71671bdeffdc7c4f21e3b25cb3d4a5a
  
https://github.com/NixOS/nixpkgs/commit/b9a7aacef71671bdeffdc7c4f21e3b25cb3d4a5a
  Author: Thomas Strobel 
<4ZKTUB6TEP74PYJOPWIR013S2AV29YUBW5F9ZH2F4D5UMJUJ6S@hash.domains>
  Date:   2017-03-04 (Sat, 04 Mar 2017)

  Changed paths:
M nixos/modules/virtualisation/qemu-vm.nix

  Log Message:
  ---
  improve: modules/virtualisation/qemu-vm.nix

disk image for qemu VM with bootloader:
* remove redundant command
* improve readability
* improve execution speed
* make output more reproducible


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

[Nix-commits] [NixOS/nixpkgs] 0a8d97: fix: "nixos-rebuild build-vm-with-bootloader"

[Thomas Strobel]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 0a8d9779c5b3bce15b252bb0f31c94744107ecf6
  
https://github.com/NixOS/nixpkgs/commit/0a8d9779c5b3bce15b252bb0f31c94744107ecf6
  Author: Thomas Strobel 
<4ZKTUB6TEP74PYJOPWIR013S2AV29YUBW5F9ZH2F4D5UMJUJ6S@hash.domains>
  Date:   2017-03-03 (Fri, 03 Mar 2017)

  Changed paths:
M nixos/modules/virtualisation/qemu-vm.nix

  Log Message:
  ---
  fix: "nixos-rebuild build-vm-with-bootloader"


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

[Nix-commits] [NixOS/nixpkgs] eb073e: moneyplex: fix: add download link

[Thomas Strobel]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: eb073e9cd9c0a8b8d6f7f1901def14afc89341e3
  
https://github.com/NixOS/nixpkgs/commit/eb073e9cd9c0a8b8d6f7f1901def14afc89341e3
  Author: Thomas Strobel 
<4ZKTUB6TEP74PYJOPWIR013S2AV29YUBW5F9ZH2F4D5UMJUJ6S@hash.domains>
  Date:   2017-02-27 (Mon, 27 Feb 2017)

  Changed paths:
M pkgs/applications/office/moneyplex/default.nix

  Log Message:
  ---
  moneyplex: fix: add download link


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

[Nix-commits] [NixOS/nixpkgs] 136c24: init: moneyplex at 16.0.22424

[Thomas Strobel]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 136c249e0ba8890c71216373d79274b78e167d06
  
https://github.com/NixOS/nixpkgs/commit/136c249e0ba8890c71216373d79274b78e167d06
  Author: Thomas Strobel 
<4ZKTUB6TEP74PYJOPWIR013S2AV29YUBW5F9ZH2F4D5UMJUJ6S@hash.domains>
  Date:   2017-02-27 (Mon, 27 Feb 2017)

  Changed paths:
A pkgs/applications/office/moneyplex/default.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  init: moneyplex at 16.0.22424


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

Re: [Nix-dev] new tool: nixos-typecheck

[Thomas Strobel]

On 03/04/2016 01:50 AM, Profpatsch wrote:
> On 16-02-29 03:16am, Hash Domains wrote:
>> What do you think?
>
> Tried to test it on my local nixpkgs, but can’t get it working.
>
> nixpkgs> nixos-typecheck printUnspecified ./nixos
> error: attribute ‘typechecker’ in selection path 
> ‘typechecker.printUnspecified’ not found
>
> Happens also with --help, so it’s probably a bug in the implementation.
>

Does the following command work: "nixos-typecheck printUnspecified -I 
nixpkgs=/path/to/nixpkgs/from/PR/13607" ?
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] new tool: nixos-typecheck

[Thomas Strobel]

Hi!

There is the new tool "nixos-typecheck" available in NixOS (currently in 
master only) that is meant help us to keep the options of our nixos 
module system well defined. In particular, "nixos-typecheck" can check 
whether a type attribute is defined for the options of the module 
system, and whether the default and example attributes are extended by 
defaultText and literalExample where appropriate.

Defining the type attribute and defaultText and literalExample is 
especially important for automatically generating a well specified 
documentation of the nixos modules system, and to build enhanced tools 
like NixUI. So I think it would be great if we could get all the options 
that "nixos-typecheck" currently reports as "unspecified" typed for our 
next release 16.09.

What do you think?

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

Re: [Nix-dev] NixOS 16.03 branch-off time in 10 days

[Thomas Strobel]

Hi,

what about branching off 16.03 by merging the closure-size branch, and 
then taking the commit just before the merge as 16.03? That way it would 
force us to really take the closure-size branch in.

Just a thought.

Thomas


On 02/18/2016 08:25 PM, Domen Kožar wrote:
> Hi all,
>
> it's that time of the year when it's time to talk about new NixOS release.
> According to our somewhat-documented release process at
> https://github.com/NixOS/nixpkgs/issues/4442, I'd like to branch off 16.03
> on 28.2. (Sunday).
>
> When the branch is made, everyone is encouraged to test and bugfix the
> release. No major bumps or other backwards-incompatible changes should be
> made.
>
> Let me know if you think something is blocking the branch-off. The way I
> see it, closure-size (https://github.com/NixOS/nixpkgs/pull/7701) won't
> make it into this release and I wouldn't risk merging it a month before the
> release. Big +1 from me for merging it after the branch off.
>
> Domen
>
>
>
> ___
> 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 User Profile (NixUP)

[Thomas Strobel]

Hi!

I'm very happy to say that a new version of NixUP is available for 
testing. You can find the latest version at [1]. Please read 
NIXUP_README.md for help on how to test NixUP.


What is Nix User Profile (NixUP)? NixUP is a declarative configuration 
for the user environment. It is an equivalent to the NixOS configuration 
method that is based around 'nixos-rebuild' and 
'/etc/nixos/configuration.nix'. NixUP provides a module system for 
configuring the user environment and is intended as a replacement for 
the imperative 'nix-env' commands. NixUP allows to, e.g., install 
packages, manage user defined services and to manage resources.


NixUP consists of a new program, called 'nixup' and a declarative 
configuration rooted at '$XDG_CONFIG_HOME/nixup/profile.nix' (e.g. 
~/.config/nixup/profile.nix). Basically, the workflow for managing the 
NixUP user profile is the same as how the NixOS system configuration is 
being managed. The 'profile.nix' is edited by the user, and then turned 
into an active environment through 'nixup'.

The important commands for using 'nixup' are:

nixup build
   -- Builds a user profile. By default the profile is defined
  in $XDG_CONFIG_HOME/nixup/profile.nix.

nixup login
   -- Builds a user profile that will be activated on the next login.
  That is similar to nixos-rebuild boot.

nixup switch
   -- Builds a user profile and immediately switches to it.

nixup edit
   -- Opens an editor with the current configuration.


NixUP also brings an small program that helps to install and to remove 
software packages. If 'config.imperativeNix.enable=true' is set in the 
'profile.nix' configuration, then a program 'nix-package' becomes 
available that manages a list of packages to be installed into the user 
environment. By default the list is maintained at 
'$XDG_CONFIG_HOME/nixup/packages.nix', from where the list is read by a 
module of the NixUP system.

The commands for using 'nix-package' are:

nix-package install hello

nix-package remove hello

Note that the packages are not pinned at a particular version but are 
linked to the currently active nixpkgs channel. A way to pin a package 
will be provided later.


Besides managing software packages, NixUP also provides a way to manage 
user controlled services. NixUP allows to define services for 'systemd 
--user', similarly to how NixOS allows to define services for 'systemd'. 
That means that the feature of managing services within NixUP is bound 
very tightly to 'systemd', and will not be available on other platforms 
like OSX or Windows.


The last interesting feature of NixUP is that is allows to manage 
resources. That means, it allows to define files in 'profile.nix' that 
are then linked into the $HOME directory of a user, or into any 
sub-directory of $HOME. The necessary sub-directories and links are 
created as needed, and automatically removed when the 'profile.nix' 
changes. Automatically created sub-directories are removed if they are 
empty after all links have been removed. So NixUP has a built-in way for 
managing, e.g., dot-files.


The plan is now to test NixUP and hopefully merge NixUP into NixOS. The 
next step then will then be to extend NixOS and NixUP so that the same 
configuration can be written into the NixOS user declaration of 
'configuration.nix' and into the user's NixUP 'profile.nix'. After that, 
we could generalize the NixOS modules of those services that could also 
run as user services and make them available for both NixOS and NixUP. 
In the long run, NixUP should be developed into an extensive collection 
of user modules that allow to declaratively configure and manage user 
applications and user services.


Please let me know what you think, and please try to test NixUP! :)


Best regards,
Thomas


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

Re: [Nix-dev] Remote Installation

[Thomas Strobel]

Maybe that helps: https://nixos.org/wiki/Creating_a_NixOS_live_CD

On 11/06/2015 07:26 PM, Thomas Strobel wrote:
> I guess you won't get around building your own ISO. Maybe have a look at
> 'nixos/modules/installer/cd-dvd/installation-cd-minimal.nix', and at how
> it is used. It could be a starting point for creating your own image.
> The source code is your friend, and not Google, I'm afraid. ;)
>
>
> On 11/06/2015 05:51 PM, Alex Brandt wrote:
>> On Friday, November 06, 2015 15:51:46 Roger Qiu wrote:
>>> Try using Packer. You can take the liveCD ISO, and repack it as an image
>>> with SSH enabled on boot.
>>
>> So there is no way to do it without rolling my own livecd like I asked about?
>>
>> Thanks,
>>
>>
>>
>> ___
>> 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] Remote Installation

[Thomas Strobel]

I guess you won't get around building your own ISO. Maybe have a look at 
'nixos/modules/installer/cd-dvd/installation-cd-minimal.nix', and at how 
it is used. It could be a starting point for creating your own image. 
The source code is your friend, and not Google, I'm afraid. ;)


On 11/06/2015 05:51 PM, Alex Brandt wrote:
> On Friday, November 06, 2015 15:51:46 Roger Qiu wrote:
>> Try using Packer. You can take the liveCD ISO, and repack it as an image
>> with SSH enabled on boot.
>
> So there is no way to do it without rolling my own livecd like I asked about?
>
> Thanks,
>
>
>
> ___
> 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] A few new options related to networking

[Thomas Strobel]

Hi!

Recently, NixOS got a few new options for configuring the networking.
Here are a few examples to introduce the new options:

# Define several WLAN interfaces for one physical WLAN device.
networking.wlanInterfaces = {
  "wlan-station0" = {
device = "wlp6s0";
  };
  "wlan-ap0" = {
device = "wlp6s0";
  };
  "wlan-monitor0" = {
type = "monitor";
device = "wlp6s0";
  };
};

# Create an Open vSwitch.
networking.vswitches = {
  "vswitch0" = {
interfaces = [ "wlan-station0" ];
  };
};

# Define and configure per-device supplicant services.
networking.supplicant = {
  "wlan-station0" = {
configFile.path = "/etc/wpa_supplicant.conf";
userControlled.enable = true;
bridge = "vswitch0";
extraConf = "p2p_disabled=1";
  };
};


Have a look at the modules for all new options and their descriptions.

Please be careful when using the new options. You're probably just
testing them :) Feedback is very welcome!


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

Re: [Nix-dev] I want nice things (apache compression)

[Thomas Strobel]

It always somehow hurts me when contributions to NixOS are refused or
just left abandoned somewhere in the mailing list or on github. The
great power of NixOS is that it can be fully programmed and so NixOS
should be able to handle almost all contributions by design. While one
has to write blog posts or wiki articles when trying to share knowledge
about how to set up software systems on other Linux distributions, for
NixOS one can write a module that contains all that information in
potentially one option flag. I don't see anything like that in any other
Linux distribution or any other Linux software management system, and I
could imagine that it will help the NixOS user base to grow rapidly.

But maybe we could improve the way how to organize all the contributions.

What I would like to discuss is whether it makes sense to divide the
whole set of modules into a NixOS core set that only contains essential
modules like, e.g. network and hardware management as well as user and
service management modules, and into a NixOS lib (nixlib) set that
contains modules for the actual services. Furthermore, one could maybe
subdivide nixlib into a stable, testing and unstable section where
modules are grouped according to their maturity and their generality. So
for example, a general Nginx configuration that defines the systemd
service and exposes hooks into the Nginx configuration file would go
into the stable section, and a more specific module like, e.g., to use
Nginx as reverse proxy could start in unstable and then move up if there
is enough interest.

The advantage could be to have a central repository where modules are
collected and to maybe take load off the core developers at the same
time. They are doing an amazing job in growing and improving NixOS, but
it's probably asking for too much when wanting them to discuss all
their decisions.

Maybe it would help if the most demanded developers were only
responsible for managing NixOS core and for maybe guiding the
development of nixlib?

For nixlib unstable I think nothing replaces the willingness of an
author to take on responsibility for the changes and to just merge the
contributions. Personally, I'd rather prefer a good portion of broken
and rapidly changing modules in unstable over a constantly growing
number of open pull requests. I find it almost always easier to have a
broken module that I can adapt then having to start from scratch.

Maybe that's something worth trying once the new release is out? What
do you think?


Thomas


On 09/12/2015 12:53 PM, Domen Kožar wrote:
> Reverting controversial commits is how we've been dealing with such
> disagreements and you're encouraged to open a PR for discussion.
> 
> I think there should be a line where options are too specific based on
> particular usage. 
> 
> That said, NixOS has the unique opportunity to take a big step forward
> providing sane defaults while giving a simple flag switch to, for
> example, best TLS configuration settings.
> 
> The main problem going that path is, there will be a lot of bikeshedding
> as these configuration options are never perfect (again, due to
> different applications).
> 
> I think there are good arguments on both sides and we have to figure out
> which policy works best for everyone.
> 
> Given the flexability NixOS modules provide, it should be possible to
> separate basic settings from advanced usage.
> 
> PS: Similar change for nginx: https://github.com/NixOS/nixpkgs/pull/9693
> 
> Domen
> 
> On Sat, Sep 12, 2015 at 11:39 AM, Joachim Schiele  > wrote:
> 
> compression is really important and i would like to have this as a nix
> option as well! but eelco might be right as this should be a per vhost
> option but i'm not sure about that.
> 
> +1
> 
> On 12.09.2015 11:05, Wout Mertens wrote:
> > Hi all,
> >
> > see 
> https://github.com/NixOS/nixpkgs/commit/9d82f7e53e66e5594b0c8b82f6c415a0a386b580
> which
> > reverts a site-wide optional compression feature I added. The discussion
> > and lack of answering can be found
> > at https://github..com/NixOS/nixpkgs/pull/9407#issuecomment-134523359
> > .
> >
> > IMHO, configuring Apache is annoying and not easy to get right, so I
> > would love to have an enableCompression flag. Data point: nixos.org 
> 
> >  doesn't use compression, for no good reason.
> >
> > I'm not happy that the commit got reverted without answering my
> > question, but that's what happens in a benevolent dictatorship I guess.
> >
> > So I would like to know what would be an acceptable configuration. I'm
> > guessing:
> >
> >   * Configurable site-wide and per virtualhost
> >   * Only compress known-compressible files: html, css, json, svg,
> txt, md
> >
> > Right?
> >
> > Wout.
> >
> > 

Re: [Nix-dev] I want nice things (apache compression)

[Thomas Strobel]

It always somehow hurts me when contributions to NixOS are refused or
just left abandoned somewhere in the mailing list or on github. The
great power of NixOS is that it can be fully programmed and so NixOS
should be able to handle almost all contributions by design. While one
has to write blog posts or wiki articles when trying to share knowledge
about how to set up software systems on other Linux distributions, for
NixOS one can write a module that contains all that information in
potentially one option flag. I don't see anything like that in any other
Linux distribution or any other Linux software management system, and I
could imagine that it will help the NixOS user base to grow rapidly.

But maybe we could improve the way how to organize all the contributions.

What I would like to discuss is whether it makes sense to divide the
whole set of modules into a NixOS core set that only contains essential
modules like, e.g. network and hardware management as well as user and
service management modules, and into a NixOS lib (nixlib) set that
contains modules for the actual services. Furthermore, one could maybe
subdivide nixlib into a stable, testing and unstable section where
modules are grouped according to their maturity and their generality. So
for example, a general Nginx configuration that defines the systemd
service and exposes hooks into the Nginx configuration file would go
into the stable section, and a more specific module like, e.g., to use
Nginx as reverse proxy could start in unstable and then move up if there
is enough interest.

The advantage could be to have a central repository where modules are
collected and to maybe take load off the core developers at the same
time. They are doing an amazing job in growing and improving NixOS, but
it's probably asking for too much when wanting them to discuss all
their decisions.

Maybe it would help if the most demanded developers were only
responsible for managing NixOS core and for maybe guiding the
development of nixlib?

For nixlib unstable I think nothing replaces the willingness of an
author to take on responsibility for the changes and to just merge the
contributions. Personally, I'd rather prefer a good portion of broken
and rapidly changing modules in unstable over a constantly growing
number of open pull requests. I find it almost always easier to have a
broken module that I can adapt then having to start from scratch.

Maybe that's something worth trying once the new release is out? What
do you think?


Thomas


On 09/12/2015 12:53 PM, Domen Kožar wrote:
> Reverting controversial commits is how we've been dealing with such
> disagreements and you're encouraged to open a PR for discussion.
> 
> I think there should be a line where options are too specific based on
> particular usage. 
> 
> That said, NixOS has the unique opportunity to take a big step forward
> providing sane defaults while giving a simple flag switch to, for
> example, best TLS configuration settings.
> 
> The main problem going that path is, there will be a lot of bikeshedding
> as these configuration options are never perfect (again, due to
> different applications).
> 
> I think there are good arguments on both sides and we have to figure out
> which policy works best for everyone.
> 
> Given the flexability NixOS modules provide, it should be possible to
> separate basic settings from advanced usage.
> 
> PS: Similar change for nginx: https://github.com/NixOS/nixpkgs/pull/9693
> 
> Domen
> 
> On Sat, Sep 12, 2015 at 11:39 AM, Joachim Schiele  > wrote:
> 
> compression is really important and i would like to have this as a nix
> option as well! but eelco might be right as this should be a per vhost
> option but i'm not sure about that.
> 
> +1
> 
> On 12.09.2015 11:05, Wout Mertens wrote:
> > Hi all,
> >
> > see 
> https://github.com/NixOS/nixpkgs/commit/9d82f7e53e66e5594b0c8b82f6c415a0a386b580
> which
> > reverts a site-wide optional compression feature I added. The discussion
> > and lack of answering can be found
> > at https://github..com/NixOS/nixpkgs/pull/9407#issuecomment-134523359
> > .
> >
> > IMHO, configuring Apache is annoying and not easy to get right, so I
> > would love to have an enableCompression flag. Data point: nixos.org 
> 
> >  doesn't use compression, for no good reason.
> >
> > I'm not happy that the commit got reverted without answering my
> > question, but that's what happens in a benevolent dictatorship I guess.
> >
> > So I would like to know what would be an acceptable configuration. I'm
> > guessing:
> >
> >   * Configurable site-wide and per virtualhost
> >   * Only compress known-compressible files: html, css, json, svg,
> txt, md
> >
> > Right?
> >
> > Wout.
> >
> > 

Re: [Nix-dev] Pkgs with unstable links

[Thomas Strobel]

time :)

On 09/12/2015 01:00 PM, Domen Kožar wrote:
> I've opened an issue two years ago on
> nixpkgs: https://github.com/NixOS/nixpkgs/issues/970
>
> Those packages should be mirrored to tarballs.nixos.org
> <http://tarballs.nixos.org>.
>
> What's missing for that to happen?
>
> On Sat, Sep 12, 2015 at 11:27 AM, Thomas Strobel <ts...@cam.ac.uk
> <mailto:ts...@cam.ac.uk>> wrote:
>
>
> On 09/12/2015 12:42 AM, Peter Simons wrote:
> > Hi,
> >
> >  > I would like to ask if we can create repo on github
> (nixos/foobar)
> >  > and upload there such pkgs? Or even are there some free
> fileservers
> >  > where we can store such things? That's a pretty tedious
> problem and
> >  > indeed we need to solve it.
> >
> > And while we're at it, we should also mirror all of rPackages
> somewhere,
> > because these people frequently modify their release archives
> in-place,
> > breaking hundreds of our builds in the process. :-(
> >
> > Peter
>
> I'm looking into ways how to extend the mirroring that is already done
> at tarballs.nixos.org <http://tarballs.nixos.org>. The plan is to
> mirror everything that any nixpkgs
> package references. Maybe that solves those problems as well. In the
> long run I could imagine to place the mirrored files into something
> like, e.g., IPFS (nixos.go14Packages.ipfs). As far as I know IPFS
> might
> get a S3 back-end with its next release, so maybe the nix cache
> could be
> provided over IPFS as well. Just sharing my thoughts here...
>
> Thomas
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl <mailto:nix-dev@lists.science.uu.nl>
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>

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

Re: [Nix-dev] Pkgs with unstable links

[Thomas Strobel]

On 09/12/2015 12:42 AM, Peter Simons wrote:
> Hi,
>
>  > I would like to ask if we can create repo on github (nixos/foobar)
>  > and upload there such pkgs? Or even are there some free fileservers
>  > where we can store such things? That's a pretty tedious problem and
>  > indeed we need to solve it.
>
> And while we're at it, we should also mirror all of rPackages somewhere,
> because these people frequently modify their release archives in-place,
> breaking hundreds of our builds in the process. :-(
>
> Peter

I'm looking into ways how to extend the mirroring that is already done
at tarballs.nixos.org. The plan is to mirror everything that any nixpkgs
package references. Maybe that solves those problems as well. In the
long run I could imagine to place the mirrored files into something
like, e.g., IPFS (nixos.go14Packages.ipfs). As far as I know IPFS might
get a S3 back-end with its next release, so maybe the nix cache could be
provided over IPFS as well. Just sharing my thoughts here...

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

Re: [Nix-dev] npm2nix issue: github:metaraine/semver-utils is not a valid repository name

[Thomas Strobel]

Hi,

I'm having the same problem. Is there any update on it?

Thanks,
Thomas


On 08/13/2015 03:19 AM, Tinker wrote:
> Hi
>
> I have some problems with the npm2nix command:
> npm2nix node-packages.json node-packages-generated.nix
>
> I get the following error (more or less, logs are a bit messy):
>
> ...
> fatal: remote error:
>   github:metaraine/semver-utils is not a valid repository name
>   Email supp...@github.com for help
> ...
> Error during fetch: Error fetching
> git://github.com/github:metaraine/semver-utils.git#86ea225 from git:
> git clone exited with non-zero status code 128
>
> (I have git version 2.3.2 installed)
>
> Any ideas?
>
> I've been searching a bit how the script ends up fetching that github
> url but couldn't really figure it out.
>
> If I clone it manually:
> git clone git://github.com/github:metaraine/semver-utils.git
> -> does not work
> git clone git://github.com/github/metaraine/semver-utils.git
> -> works (replaced colon between github and metaraine)
>
> However, where does github:metaraine come from? Found one references
> to it on github:
> https://github.com/tjunnone/npm-check-updates/blob/8ae377706a956724ab42b28b1ffd5ea33dfdebcc/package.json
>
> FYI
>
> git diff node-packages.json
> diff --git a/pkgs/top-level/node-packages.json
> b/pkgs/top-level/node-packages.json
> index 11fd19a..97a9eab 100644
> --- a/pkgs/top-level/node-packages.json
> +++ b/pkgs/top-level/node-packages.json
> @@ -118,6 +118,7 @@
>  , "browserify"
>  , "uglify-js"
>  , "less"
> +, "less-plugin-clean-css"
>  , "mocha-phantomjs"
>  , "phantomjs"
>  , "sinon"
>
> Thanks!
> ___
> 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] Automatic download option for requireFile

[Thomas Strobel]

Hi,

On 02/24/2015 10:37 PM, Nicolas Pierron wrote:
 On Tue, Feb 24, 2015 at 12:20 PM, Vladimír Čunát vcu...@gmail.com wrote:
 On 02/24/2015 12:02 PM, Harald van Dijk wrote:
 If you just want to _use_ the software, not modify it, not re-distribute
 it, then for a whole lot of packages, you do not have to accept the
 license.
 I meant that in any case you're required to conform to the license terms
 (whether that means some act of accepting it or not).
 Which raise a good point, what does allowUnfree = true; means.
 Does that mean that you read the licenses of all software, and that
 you do *agree with all* of them?

 Should we do something like allowLicenses = [ pkgs.licenses.adobeEULA
 ]; instead?


Just to follow up part of the cause of the discussion, Oracle JDKs 7/8
download with fetchurl now, [1].

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

[Nix-dev] Automatic download option for requireFile

[Thomas Strobel]

Hi,

I intend to add an automatic download option for software packages where
the user needs to accept a special license, like for example oraclejdk.
At the moment the nixpkgs build tool points to a specific download page,
and the users have to download the package themselves.
I would like to add the possibility to accept the package specific
license in the general nixpkgs config, e.g., with
config.license.oraclejdk.accept=true; in the user's nixpkgs
configuration, and then have the build tool downloading the package
directly.

Before I go ahead and implement it, what do you think about it?


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

[Nix-dev] 'bumblebee' nvidia gpu switching

[Thomas Strobel]

Hi,

I'm having problems enabling the 'bumblebee' nvidia gpu switching service.
I've appended a test case which does not work for me in the current
unstable channel.
Is somebody else seeing the same problem? Any advice or hint how to
resolve the issue would be very welcome :)

Cheers,
Thomas


configuration.nix:

{ config, pkgs, ... }:
{
  hardware.bumblebee.enable = true;

  nixpkgs.config.allowUnfree = true;
  boot.loader.grub.enable = false;
  fileSystems./ = { device = /dev/null; };
  swapDevices =[];
}


test build with:
  NIXOS_CONFIG=`pwd`/configuration.nix nixos-rebuild build
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] 'bumblebee' nvidia gpu switching

[Thomas Strobel]

Update: The configuration below was working with nixpkgs commit
f8bd5bb401e7c47b66b4cf44b150707824a5f41d , from Tue Jan 6.

Is there a way to automatically figure out which change broke my
configuration?

Many thanks,
Thomas


On 02/03/2015 09:43 AM, Thomas Strobel wrote:
 Hi,

 I'm having problems enabling the 'bumblebee' nvidia gpu switching service.
 I've appended a test case which does not work for me in the current
 unstable channel.
 Is somebody else seeing the same problem? Any advice or hint how to
 resolve the issue would be very welcome :)

 Cheers,
 Thomas


 configuration.nix:
 { config, pkgs, ... }:
 {
   hardware.bumblebee.enable = true;

   nixpkgs.config.allowUnfree = true;
   boot.loader.grub.enable = false;
   fileSystems./ = { device = /dev/null; };
   swapDevices =[];
 }
 

 test build with:
   NIXOS_CONFIG=`pwd`/configuration.nix nixos-rebuild build
 ___
 nix-dev mailing list
 nix-dev@lists.science.uu.nl
 http://lists.science.uu.nl/mailman/listinfo/nix-dev



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

Re: [Nix-dev] NixOS as dom0 for Xen

[Thomas Strobel]

Just to follow it up, Xen has been upgraded to 4.4.1. So far only the
nix package of Xen was updated, the nixos modules related to Xen will
follow.

I've also started to bring Xenserver (XCP) to NixOS [1]. The necessary
packages should compile already. The nixos modules will follow. Any help
to integrate the Xenserver tools into NixOS is very welcome.

I'm also interested in bringing Qubes to NixOS, or the other way round.
If anyone has suggestions or interest, please let me know.

Best regards
Thomas

[1] https://github.com/NixOS/nixpkgs/pull/5529
[2] https://wiki.qubes-os.org/

On 12/20/2014 09:37 PM, Thomas Strobel wrote:
 Hi!

 I plan to use NixOS as dom0 for Xen. There is an old, deactivated nixos
 module available that I thought of using. But before I go ahead, I just
 wanted to ask why dom0 support for Xen was dropped in NixOS? Anything
 that I should keep in mind when trying to reestablish dom0 support?

 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] NixOS as dom0 for Xen

[Thomas Strobel]

Hi!

I plan to use NixOS as dom0 for Xen. There is an old, deactivated nixos
module available that I thought of using. But before I go ahead, I just
wanted to ask why dom0 support for Xen was dropped in NixOS? Anything
that I should keep in mind when trying to reestablish dom0 support?

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

Re: [Nix-dev] Zero Hydra Failures (ZHF) project for NixOS

[Thomas Strobel]

Wow! Amazing!! :) Thanks for all the effort! Thomas

On 10/23/2014 06:57 PM, Domen Kožar wrote:
 We're pretty much done getting failures to zero:
 http://hydra.nixos.org/jobset/nixos/trunk-combined

 Now it's *only* about keeping it that way ;-)

 On Thu, Oct 9, 2014 at 5:28 PM, Domen Kožar do...@dev.si wrote:

 Last two packages and a test:

 - linuxPackages_latest.netatop http://hydra.nixos.org/build/15631911
 (probably needs to be patched to work with kernel 3.17)
 - linuxPackages_latest.batman_adv http://hydra.nixos.org/build/15631653
 (errors because of -Wall)
 - nixos.tests.installer.rebuildCD.i686-linux (no idea)

 See http://hydra.nixos.org/eval/1154473#tabs-still-fail (rest of the
 tests are transient)

 On Mon, Sep 29, 2014 at 1:52 PM, Mateusz Kowalczyk 
 fuuze...@fuuzetsu.co.uk wrote:

 On 09/29/2014 12:35 PM, Domen Kožar wrote:
 On Mon, Sep 29, 2014 at 1:31 PM, Mateusz Kowalczyk 
 fuuze...@fuuzetsu.co.uk
 wrote:

 On 09/29/2014 12:19 PM, Domen Kožar wrote:
 Current status (4 more packages need fixing and one test!):
 http://hydra.nixos.org/eval/1153558?full=1#tabs-still-fail

 - lots of transient errors in curl downloads, restarting doesn't
 always
 help:

 * http://hydra.nixos.org/build/14918849
 * http://hydra.nixos.org/build/14894358
 * http://hydra.nixos.org/build/14915515
 * http://hydra.nixos.org/build/14915523
 * pypy (32bit)

 Observation: all on i686-linux (might be machine specific or
 platform?)
 - bittorrent test needs a new tracker package to pass again (any
 heroes?)
 - cmplayer http://hydra.nixos.org/build/14858343 (
 https://github.com/NixOS/nixpkgs/issues/4220)

 - haskellPackages.esqueleto.i686-linux,
 Seems like a network failure


 http://hydra.nixos.org/build/14839807/nixlhttps://github.com/toastdriven/pysolr/pull/112og/1/raw
 http://hydra.nixos.org/build/14839807/nixlog/1/raw

 Restarted



 First failure
 http://hydra.nixos.org/build/14711328

 2.0.1 used to compile file so it seems we have just been unlucky with
 network since 2.0.2 bump

 haskellPackages.lzmaEnumerator.i686-linux (any heroes to disable those
 two?)

 lzma issue at
 https://github.com/alphaHeavy/lzma-enumerator/issues/2

 Could we disable it for i686-linux until that's fixed?
 We should mark the package as broken on i686 but I don't know the
 ‘proper’ way to do it, I was scorned the last time I changed platforms
 by hand[1] so you'll have to wait for peti to do it or explain the
 proper way. Notably, we need to not build it at all on i686 rather than
 disabling tests because the package will behave badly if used on those
 systems.


 - telepathy.call_ui (WIP
 https://github.com/NixOS/nixpkgs/pull/4265#issuecomment-56857712)

 So seems it's all WIP/issue open/network except bittorrent which
 genuinely fails. Seems pypy stuff is what's inflating the number to
 hundreds.


 cmplayer, telepathy and bittorrent test need attention, yes.

 [1]:

 https://github.com/Fuuzetsu/nixpkgs/commit/ea5be72b39067282626ccb275972b6582c1678da

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

[Nix-dev] Integration of Haste packages

[Thomas Strobel]

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

Re: [Nix-dev] [E-devel] Looking for someone to take over the Bodhi Linux Project

[Thomas Strobel]

Hi Jeff,

thank you very much for putting so much time and effort into Bodhi! I
think it is an amazingly styled, really great project! I loved it! :)

Now, I don't know if you know about NixOS [1], but it's another awesome
project out there! It is an Linux based OS which has a declarative
approach to configuration and package management. That is, you define
your configuration in a short file, and NixOS builds e.g. for your
laptop, desktop pc or your server. With (almost) the same configuration
file it can also generate a CD/DVD image or a VirtualBox appliance---all
for free without any additional effort [2]. The catch is that one has to
get familiar with the declarative concept of NixOS, but there is a very
friendly and helpful community around it, and in my opinion one's
personal benefits of learning about NixOS are worth the effort anyway.
E19 is already ported to NixOS [3].

If you could imagine that NixOS and its infrastructure would help you to
achieve your goals that you have with Bodhi with less effort, I would be
very happy to help you to port Bodhi over to NixOS---as far as possible.

Btw, NixOS is generally a very interesting project to look at for any
software developer! When working in a team, it ensures that every
developer has the same working environment, that is the same tools and
libraries. It allows one to have several versions of the same software
installed at the same time. It has atomic system upgrades and allows to
roll back in case something doesn't work with the new configuration. So
NixOS might be worth a look from the Enlightenment developers as well! ;)

Best wishes,

  Thomas


[1] http://nixos.org/
[2] http://nixos.org/nixos/manual/#sec-building-cd
[3] https://github.com/NixOS/nixpkgs/pull/4101



On 09/17/2014 08:39 AM, Jeff Hoogland wrote:
 A lot of my build process is scripted. You still have to download sources
 though and baby sit the compile for error messages between dependencies
 though - it is more time consuming than just pressing go.

 https://github.com/JeffHoogland/bodhibuildscripts

 On Wed, Sep 17, 2014 at 1:33 AM, Jonathan Aquilina jaquil...@eagleeyet.net
 wrote:


 I have an idea on how you can automate alot of this stuff. Why not
 setup if you dont have scripts already for the below process and run
 them in lxc containers on the server?

 ---
 Regards,
 Jonathan
 Aquilina
 Founder Eagle Eye T

 On 2014-09-17 08:30, Jeff Hoogland wrote:


 More people splitting up work is always ideal. I'm hosting a Google
 hangout
 with some folks on Thursday at 10am CST (that will also be
 archived)
 showing the (likely very poor) processes I currently use for
 building
 software updates for Bodhi as well as preparing ISO images
 for
 distribution. In all honesty if we can find folks who want to take
 over
 these duties I can still spare enough time to help manage things.
 Just
 tired of spending my spare time watching terminals compile other
 people's
 work instead of working on my own.

 Seems to be enough
 interest in Bodhi that it can hopefully survive without
 me continuing
 to do all the grunt work like I have for the last few years
 now.


 On Wed, Sep 17, 2014 at 12:59 AM, Jonathan Aquilina
 jaquil...@eagleeyet.net
 wrote:
 @Jeff I was discussing in
 the channel that maybe if there are enough people to keep bodhi going we
 really dont need someone at the top so to speak. It was also discussed
 setting up a foundation, but the problem is where would it be based? ---
 Regards, Jonathan Aquilina Founder Eagle Eye T On 2014-09-17 01:57,
 Carsten Haitzler wrote:
 On Tue, 16 Sep
 2014 14:24:33 -0400
 Rbt. Y-Lee y...@bodhilinux.com [1] said:
 Just
 a quick
 FYI I have been considering taking over your Bodhi tasks. It is just a
 matter of me finding the time to do it with my new job and life. as much
 as possible. have package builds eg of efl automated (from git - just
 select a tag to select
 :5px; border-left:#1010ff 2px solid;
 margin-left:5
 %general as possible with as few modifications. so
 file lists do:


 Links:
 --
 [1] mailto:y...@bodhilinux.com
 [2]
 http://jeffhoogland.blogspot.com/
 [3]
 mailto:enlightenment-de...@lists.sourceforge.net
 [4]
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 [5]
 mailto:ras...@rasterman.com
 [6]

 http://pubads.g.doubleclick.net/gampad/clk?id=157508191amp;iu=/4140/ostg.clktrk
 [7]
 mailto:enlightenment-de...@lists.sourceforge.net
 [8]
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 [9]
 mailto:jeffhoogl...@linux.com
 [10]
 http://pubads.g.doubleclick.net/gampad/cldiv

 gt;nbsp;/ostg.clktrknbsp;[10]nbsp;mailto:
 /dive...@lists.sourceforge.net
 [11]

 http://pubads.g.doubleclick.net/gampad/clk?id=157508191amp;iu=/4140/ostg.clktrk
 [12]
 mailto:enlightenment-div

 gt;nbsp;.net/lists/listinfo
 /divt-devel

 --
 Want excitement?
 Manually upgrade your production database.
 When you want reliability, choose Perforce
 

Re: [Nix-dev] E18

[Thomas Strobel]

Sure! I run it by adding the following into my /etc/nixos/configuration.nix:

imports = [ path/to/e18 ];

config = {
  services.xserver.displayManager.slim.enable = true;
  services.xserver.desktopManager.e18.enable = true;
  services.xserver.desktopManager.xterm.enable = false;
};

The integration into the display managers is very basic so far, but I
hope that helps!
Thomas


On 08/04/2014 01:18 AM, Anderson Torres wrote:
 Can I test it? :)

 2014-08-03 18:33 GMT-03:00 Thomas Strobel ts...@cam.ac.uk:
 Hi,

 I've packed Enlightenment E18, and I just wanted to share it. It might
 need some review before pushing it online, especially the functions
 provided in the module.nix configuration.

 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

Re: [Nix-dev] Vim setup for Haskell

[Thomas Strobel]

Thanks for describing your setup!

The idea behind 'hvim' is to have a single package which installs vim
with some stuff that is helpful for Haskell development, without having
to understand how nixos or vimrc work.
Especially it should allow to distribute adjusted or modified programs
and plugins which work together nicely.
E.g. I tried to wrap hdevtools so that it finds the installed Haskell
packages automatically, and maybe ghc-mod needs some adjustments as well.

I know about your vim-addon-manager project and your maintained
collection of vim plugins for nix**. I think it would be great if the
vim plugins that are used in hvim could be integrated into
pkgs/misc/vim-plugins/default.nix. That would allow to simplify what
I've tried to achieve within install.sh


Best wishes,
Thomas


On 08/04/2014 05:06 AM, Marc Weber wrote:
 I personally use nixpkgs-haskell-overlay
 and vim-addon-haskell which can run cabal.

 The nixpkgs-haskell-overlay implementation is prototype implementation
 (see wiki) and can tag haskell sources (using hasktags).
 You then source an env var which sets an environment var pointing to tag
 files.

 There are alternative solutions, too

 Marc Weber
 ___
 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] E18

[Thomas Strobel]

Ouch! Thanks a lot for pointing that out. I'm very sorry for not
checking thoroughly enough before bothering you with my local modifications.


On 08/04/2014 10:35 AM, Luca Bruno wrote:
 e18 is already in nixpkgs.


 On Mon, Aug 4, 2014 at 8:32 AM, Thomas Strobel ts...@cam.ac.uk wrote:

 Sure! I run it by adding the following into my
 /etc/nixos/configuration.nix:

 imports = [ path/to/e18 ];

 config = {
   services.xserver.displayManager.slim.enable = true;
   services.xserver.desktopManager.e18.enable = true;
   services.xserver.desktopManager.xterm.enable = false;
 };

 The integration into the display managers is very basic so far, but I
 hope that helps!
 Thomas


 On 08/04/2014 01:18 AM, Anderson Torres wrote:
 Can I test it? :)

 2014-08-03 18:33 GMT-03:00 Thomas Strobel ts...@cam.ac.uk:
 Hi,

 I've packed Enlightenment E18, and I just wanted to share it. It might
 need some review before pushing it online, especially the functions
 provided in the module.nix configuration.

 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

[Nix-dev] povray.nix

[Thomas Strobel]

Hi,

I've attached a nix description for an updated version of povray. Maybe
someone wants to put it online?

Best wishes,
Thomas
{stdenv, fetchgit, autoconf, automake, boost149, zlib, libpng, libjpeg, 
libtiff}:

let boost = boost149; in
stdenv.mkDerivation {
  name = povray-3.7;

  src = fetchgit {
url = https://github.com/POV-Ray/povray.git;;
rev = 39ce8a24e50651904010dda15872d63be15d7c37;
sha256 = 0d56631d9daacb8967ed359025f56acf0bd505d1d9e752859e8ff8656ae72d20;
  };


  buildInputs = [ autoconf automake boost zlib libpng libjpeg libtiff ];

  # the installPhase wants to put files into $HOME. I let it put the files
  # to $TMPDIR, so they don't get into the $out
  postPatch = '' cd unix
 ./prebuild.sh
 cd ..
 sed -i -e 's/^povconfuser.*/povconfuser=$(TMPDIR)\/povray/' 
Makefile.{am,in}
 sed -i -e 's/^povuser.*/povuser=$(TMPDIR)\/.povray/' 
Makefile.{am,in}
 sed -i -e 's/^povowner.*/povowner=nobody/' Makefile.{am,in}
 sed -i -e 's/^povgroup.*/povgroup=nogroup/' Makefile.{am,in}
   '';

  configureFlags = COMPILED_BY='nix' --with-boost-libdir=${boost}/lib 
--with-boost-includedir=${boost}/include;

  preInstall = ''
mkdir $TMP/bin
for i in chown chgrp; do
  echo '#!/bin/sh'  $TMP/bin/$i
  chmod +x $TMP/bin/$i
  PATH=$TMP/bin:$PATH
done
  '';
  
  meta = {
homepage = http://www.povray.org/;
description = Persistence of Vision Raytracer;
license = free;
  };
}
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] fityk.nix, xylib.nix and wxGTK_3.0.1.nix

[Thomas Strobel]

Hi,

please find attached the .nix files for building fityk
(http://fityk.nieto.pl/). Hope it helps.

Best wishes,
Thomas
{ stdenv, fetchurl, boost, zlib, bzip2 }:

let
  name= xylib;
  version = 1.3;
in
stdenv.mkDerivation {
  name = ${name}-${version};

  src = fetchurl {
url = 
https://github.com/wojdyr/xylib/releases/download/v${version}/${name}-${version}.tar.bz2;;
sha256 = 09j426qjbg3damch1hfw16j992kn2hj8gs4lpvqgfqdw61kvqivh;
  };

  buildInputs = [boost zlib bzip2 ];

  meta = {
description = xylib is a portable library for reading files that contain 
x-y data from powder diffraction, spectroscopy and other experimental methods.;
license = LGPL;
homepage = http://xylib.sourceforge.net/;
platforms = stdenv.lib.platforms.linux;
  };
}
{ stdenv, fetchurl, pkgconfig, gtk, libXinerama, libSM, libXxf86vm, 
xf86vidmodeproto
, gstreamer, gst_plugins_base, GConf, setfile
, withMesa ? true, mesa ? null, compat24 ? false, compat26 ? true, unicode ? 
true,
}:

assert withMesa - mesa != null;

with stdenv.lib;

let
  version = 3.0.1;
in
stdenv.mkDerivation {
  name = wxwidgets-${version};

  src = fetchurl {
url = mirror://sourceforge/wxwindows/wxWidgets-${version}.tar.bz2;
sha256 = 1xf5s8cnq6xr0r6l0y9cn1pjg961xbycl4afhjrqzbsnxiwinrxx;
  };

  buildInputs =
[ gtk libXinerama libSM libXxf86vm xf86vidmodeproto gstreamer
  gst_plugins_base GConf ]
++ optional withMesa mesa
++ optional stdenv.isDarwin setfile;

  nativeBuildInputs = [ pkgconfig ];

  configureFlags =
[ --enable-gtk2 --disable-precomp-headers --enable-mediactrl
  (if compat24 then --enable-compat24 else --disable-compat24)
  (if compat26 then --enable-compat26 else --disable-compat26) ]
++ optional unicode --enable-unicode
++ optional withMesa --with-opengl
++ optionals stdenv.isDarwin
  # allow building on 64-bit
  [ --with-cocoa --enable-universal-binaries ];

  SEARCH_LIB = optionalString withMesa ${mesa}/lib;

  preConfigure = 
substituteInPlace configure --replace 'SEARCH_INCLUDE=' 
'DUMMY_SEARCH_INCLUDE='
substituteInPlace configure --replace 'SEARCH_LIB=' 'DUMMY_SEARCH_LIB='
substituteInPlace configure --replace /usr /no-such-path
   + optionalString stdenv.isDarwin ''
substituteInPlace configure --replace \
  'ac_cv_prog_SETFILE=/Developer/Tools/SetFile' \
  'ac_cv_prog_SETFILE=${setfile}/bin/SetFile'
  '';

  postInstall = 
(cd $out/include  ln -s wx-*/* .)
  ;

  passthru = {inherit gtk compat24 compat26 unicode;};

  enableParallelBuilding = true;
}
{ stdenv, fetchurl, wxGTK301, boost, lua, zlib, bzip2, xylib, readline, gnuplot 
}:

let
  name= fityk;
  version = 1.2.9;
in
stdenv.mkDerivation {
  name = ${name}-${version};

  src = fetchurl {
url = 
https://github.com/wojdyr/fityk/releases/download/v${version}/${name}-${version}.tar.bz2;;
sha256 = 1gl938nd2jyya8b3gzbagm1jab2mkc9zvr6zsg5d0vkfdqlk0pv1;
  };

  buildInputs = [wxGTK301 boost lua zlib bzip2 xylib readline gnuplot ];

  meta = {
description = Fityk -- curve fitting and peak fitting software;
license = GPL2;
homepage = http://fityk.nieto.pl/;
platforms = stdenv.lib.platforms.linux;
  };
}
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] thermald.nix

[Thomas Strobel]

Hi,

maybe someone interested in pushing the .nix file for thermald online?
It's maybe not the latest version, and the systemd integration is quite
basic, but it works. It might benefit from a change in the kernel's
default configuration, though.

Best wishes,
Thomas
{ stdenv, fetchurl, unzip, autoconf, automake, libtool, pkgconfig, dbus_libs, 
dbus_glib, libxml2 }:

let
  version = next;
in

stdenv.mkDerivation rec {
  name = thermald-${version};
  src = fetchurl {
url = 
https://github.com/01org/thermal_daemon/archive/thermal_daemon_next.zip;;
sha256 = 0rk2l1s1ar60j9hxbrhji8zmv730pzv2ysjamv0qvbynlhi4xzjp;
  };
  buildInputs = [ unzip autoconf automake libtool pkgconfig dbus_libs dbus_glib 
libxml2 ];

  patchPhase = ''sed -e 's/upstartconfdir = \/etc\/init/upstartconfdir = 
$(out)\/etc\/init/' -i data/Makefile.am'';

  preConfigure = ''
   export 
PKG_CONFIG_PATH=${dbus_libs}/lib/pkgconfig:$PKG_CONFIG_PATH
   ./autogen.sh #--prefix=$out
 '';

  configureFlags = [
--sysconfdir=$(out)/etc --localstatedir=/var
--with-dbus-sys-dir=$(out)/etc/dbus-1/system.d
--with-systemdsystemunitdir=$(out)/etc/systemd/system
];

  preInstall = sysconfdir=$out/etc;


  meta = {
description = Thermal Daemon;
longDescription = ''
 Thermal Daemon
'';
homepage = https://01.org/linux-thermal-daemon;
license = stdenv.lib.licenses.gpl2;
  };
}
{ config, lib, pkgs, ... }:

with lib;

let
  cfg = config.services.thermald;

in {

  ## interface

  options = { 

services.thermald = { 

  enable = mkOption {
default = false;
description = ''
  Whether to enable thermald, the temperature management daemon.
''; 
  };  

};  

  };  


  ## implementation

  config = mkIf cfg.enable {

systemd.services.thermald = {
  description = Thermal Daemon Service;
  wantedBy = [ multi-user.target ];
  script = exec ${pkgs.thermald}/sbin/thermald --no-daemon --dbus-enable;
};

  };

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

[Nix-dev] E18

[Thomas Strobel]

Hi,

I've packed Enlightenment E18, and I just wanted to share it. It might
need some review before pushing it online, especially the functions
provided in the module.nix configuration.

Many thanks,
Thomas


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

[Nix-dev] Vim setup for Haskell

[Thomas Strobel]

Hi,

I've tried to pack/integrate VIM with plugins/programs that help with
Haskell development. I would be very thankful for feedback and help with
integrating it properly into NIX-OS.

Many thanks,
Thomas


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

Re: [Nix-dev] Hdevtools does not find installed modules

[Thomas Strobel]

Philip, thank you so much for your help and your detailed description,
it is very much appreciated! Having your example to compare it with how
the standard environment includes the search paths helped me a lot in
understanding how everything is supposed to work.

The custom environment---using ghcWithPackages---that you're suggesting
seems to be using the exported environment variables to find the
packages' information.

In the default environment ghc instead relies on the script 
'/nix/store/m9f..-ghc-get-packages.sh' to collect all packages'
information. It can be called with the ghc's version number.

The reason why ghc-mod works in the default environment is because it is
wrapped to call the ghc-get-packages.sh script as well. I'll try to
patch hdevtools the same way to make it work. I'll probably only have to
change the script's output from '-package-db xxx' to '-g-package-db=xxx'
to make it compatible with hdevtools.

Thanks again!
Thomas


On 06/19/2014 10:34 PM, Philip Carlsen wrote:
 tl;dr; To answer your questions: the contents of my ghc installed ghc
 wrapper is listed below, and no, your installed packages should not
 show up in the same nix-store location as your ghc (unless you use
 shell environments like in my previous mail).

 So, I guess it comes down to which method you use to deploy ghc and
 haskell packages on your machine. It sunds to me like your process is
 something along the lines of:

 $ nix-env -i cabal-install
 $ cabal install hdevtools ...

 I think I tried something like that in the beginning, but switched to
 using per-project environments due to both the poor integration with
 ad-hoc cabal installs and of course the benefits of isolated
 dependency tracking (though arguably that could be achieved using
 cabal-dev or cabal sandbox).

 When using a dedicated project shell environment, ghc is wrapped
 differently:

 % which ghc
 /nix/store/lvb..nz-haskell-env-ghc-7.6.3/bin/ghc

 % cat $(which ghc)
 #! /nix/store/fp...v9sq-bash-4.2-p45/bin/bash -e
 export NIX_GHC=/nix/store/lvb..nz-haskell-env-ghc-7.6.3/bin/ghc
 export NIX_GHCPKG=/nix/store/lvb..nz-haskell-env-ghc-7.6.3/bin/ghc-pkg
 export
 NIX_GHC_DOCDIR=/nix/store/lvb..nz-haskell-env-ghc-7.6.3/share/doc/ghc/html
 export
 NIX_GHC_LIBDIR=/nix/store/lvb..nz-haskell-env-ghc-7.6.3/lib/ghc-7.6.3
 exec /nix/store/b9sgl-ghc-7.6.3/bin/ghc -B$NIX_GHC_LIBDIR
 ${extraFlagsArray[@]} $@

 When thinking about it, it might just be enough to just

 export NIX_GHC_LIBDIR=~/.ghc-7.6.3/packages.conf.d
 (or whatever now the correct path to the cabal user (or sandbox)
 package database is..)


 Now, if you've used nix-env to install your haskell dependencies and
 tools you might not be as lucky as in the first case, as the package
 database resides in ~/.nix-profile/ and is spread over multiple files
 (one per cabal package) due to the read-only nature of the nix-store,
 and the GHC api used to list the available packages (as it appears to
 hdevtools) needs to be specifically instructed to consider each of
 these files (this may be what the ghc-get-packages.sh script in your
 ghc wrapper actually does, but that may just be speculation on my part)

 I hope I've given you some leads to proceed :-)


 2014-06-19 12:26 GMT+02:00 Thomas Strobel ts...@cam.ac.uk
 mailto:ts...@cam.ac.uk:

 Hi,

 thanks for your help, Thomas and Philip, but I would have two
 further questions.

 - What should be exported in /nix/store/current-ghc-hash/bin/ghc
 ? My ghc wrapper only looks like:
 '''
 #! /nix/store/...--bash-4.2-p45/bin/bash -e
 exec /nix/store/...-ghc-7.6.3/bin/ghc
 $(/nix/store/...-ghc-get-packages.sh 7.6.3 $(dirname $0))
 ${extraFlagsArray[@]}
 $@
 '''

 -
 '/nix/store/...ghc-version-wrapper/lib/ghc-version/package.conf.d'
 seems to contain only configurations for a few standard modules.
 Should all packages which are installed on my system show up in there?


 Again, many thanks!
 Thomas



 On 06/18/2014 02:45 PM, Philip Carlsen wrote:
 IIRC, issuing:

 $(grep export /nix/store/your-current-ghc-hash/bin/ghc)

 (or maybe ~/.nix-profile/bin/ghc will work as well if you have
 your haskell tools in your home profile)

 in your working shell sets NIX-specific environment variables
 that the ghc api uses to locate the package database by sourcing
 the wrapper code around ghc. Actually, hdevtools should probably
 just be wrapped similarly itself, though I think there might be
 some problems with that (not that I remember right now).

 I'm using hdevtools myself, and if this is insufficient to get it
 working I might be forgetting some part of my setup.

 Now, for haskell development in general I can recommend making
 shell environments per haskell project you develop using the
 myEnvFun (see https://nixos.org/wiki/Howto_develop_software_on_nixos)
 I have a file with something along the lines of:

 A general dev

Re: [Nix-dev] Hdevtools does not find installed modules

[Thomas Strobel]

Hi,

thanks for your help, Thomas and Philip, but I would have two further
questions.

- What should be exported in /nix/store/current-ghc-hash/bin/ghc ? My
ghc wrapper only looks like:
'''
#! /nix/store/...--bash-4.2-p45/bin/bash -e
exec /nix/store/...-ghc-7.6.3/bin/ghc
$(/nix/store/...-ghc-get-packages.sh 7.6.3 $(dirname $0))
${extraFlagsArray[@]}
$@
'''

- '/nix/store/...ghc-version-wrapper/lib/ghc-version/package.conf.d'
seems to contain only configurations for a few standard modules. Should
all packages which are installed on my system show up in there?


Again, many thanks!
Thomas


On 06/18/2014 02:45 PM, Philip Carlsen wrote:
 IIRC, issuing:

 $(grep export /nix/store/your-current-ghc-hash/bin/ghc)

 (or maybe ~/.nix-profile/bin/ghc will work as well if you have your
 haskell tools in your home profile)

 in your working shell sets NIX-specific environment variables that the
 ghc api uses to locate the package database by sourcing the wrapper
 code around ghc. Actually, hdevtools should probably just be wrapped
 similarly itself, though I think there might be some problems with
 that (not that I remember right now).

 I'm using hdevtools myself, and if this is insufficient to get it
 working I might be forgetting some part of my setup.

 Now, for haskell development in general I can recommend making shell
 environments per haskell project you develop using the myEnvFun (see
 https://nixos.org/wiki/Howto_develop_software_on_nixos)
 I have a file with something along the lines of:

 A general dev-env.nix:
 -

 # This nix environment contains all the tools used in the process of
 developing
 # Because each package has its own dependencies, this file provides a
 function
 # for creating environments, rather than a concrete environment.
 # envName :: String -- The suffix of the name of the resulting
 environment.
 # hsEnvDeps :: HsPkgs - [CabalNix] -- the dependencies of the package
 being
 #   developed in this environment.
 { envName, hsEnvDeps } :
 let
   pkgs = import nixpkgs {};
   hsEnv = pkgs.haskellPackages.ghcWithPackagesOld (hsPkgs : ([
 hsPkgs.hlint
 hsPkgs.hdevtools
 hsPkgs.hasktags
 ] ++ (hsEnvDeps hsPkgs)));
 in
   pkgs.myEnvFun {
 name = envName;
 buildInputs = with pkgs; [
   binutils
   coreutils
   ctags
   vimHugeX
   zsh
   hsEnv
   ];
 shell = ${pkgs.zsh.outPath}/bin/zsh;
 extraCmds = ''
   $(grep export ${hsEnv.outPath}/bin/ghc)
 '';
 }

 ...And a project-env.nix file for each project:
 ---
 let
   envFun= import ./dev-env.nix;
   projectCabal = import ./cabal.nix;
 in
   envFun {
 envName   = myproject;
 hsEnvDeps = hsPkgs :
  (let
deriv = hsPkgs.callPackage projectCabal (rec {
  # satisfy dependencies not in hsPkgs by adding them here.
  });
  in deriv.nativeBuildInputs ++ deriv.propagatedNativeBuildInputs);
 }

 And 'cabal.nix' being the file output by the cabal2nix tool applied to
 your cabal file.

 Then just issuing

 $ nix-build project-env.nix
 $ ./result/bin/load-env-myproject

 gives you a completely selfcontained, replicatable development
 environment where everything is wired to the same package database.
 (Except for the vim plugins for hdevtools, syntastic etc, which I have
 yet to figure out how to include in my nix expression. So for the time
 being these should be installed separately in ~/.vim)


 2014-06-18 11:11 GMT+02:00 Thomas Strobel ts...@cam.ac.uk
 mailto:ts...@cam.ac.uk:

 Hi!

 I've got a question for those using Haskell under NixOS. I'm trying to
 use hdevtools to check my Haskell source file, but hdevtools does not
 find any modules. ghc-pkg does, as does ghc-mod. From what I have read
 it might be necessary to set some environment variables.
 Can someone maybe give me an example of how to use hdevtools under
 NixOS?

 Many thanks in advance,
 Thomas
 ___
 nix-dev mailing list
 nix-dev@lists.science.uu.nl mailto:nix-dev@lists.science.uu.nl
 http://lists.science.uu.nl/mailman/listinfo/nix-dev



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

[Nix-dev] Hdevtools does not find installed modules

[Thomas Strobel]

Hi!

I've got a question for those using Haskell under NixOS. I'm trying to
use hdevtools to check my Haskell source file, but hdevtools does not
find any modules. ghc-pkg does, as does ghc-mod. From what I have read
it might be necessary to set some environment variables.
Can someone maybe give me an example of how to use hdevtools under NixOS?

Many thanks in advance,
Thomas
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] hydra's nix-expression works in nix-shell, but fails with nix-build

[Thomas Strobel]

Thanks, I added --pure to nix-shell, but the result didn't change. The
only difference in the environment variables which are set for nix-build
and nix-shell is that nix-build contains the following:

declare -x NIX_ENFORCE_PURITY=1
declare -x NIX_INDENT_MAKE=1
declare -x TZ=UTC

In nix-build libtoolize misses the following actions:

libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'

and therefore autoreconf fails with

configure.ac:10: error: required file './ltmain.sh' not found
autoreconf: automake failed with exit status: 1


Is it NIX_ENFORCE_PURITY which is causing that difference? If so what
would you recommend me to do?


Many thanks for your help!
Thomas



On 06/15/2014 05:42 AM, Kirill Elagin wrote:
 Have you tried it with `nix-shell --pure`?


 --
 Кирилл Елагин


 On Sun, Jun 15, 2014 at 5:01 AM, Thomas Strobel ts...@cam.ac.uk
 mailto:ts...@cam.ac.uk wrote:

 Hi!

 I'm trying to write a nix-expression for current hydra, see below. It
 works within nix-shell, but fails with nix-build, both on 14.04.
 Could someone maybe help me with that, please?

 Many thanks,
 Thomas



 hydra.nix
 

 { stdenv, fetchgit, pkgs }:
 with pkgs;
 let
   nixpkgs = pkgs;
   version = 0.17;

   nix = pkgs.nixUnstable;

   perlDeps = pkgs.buildEnv {
 name = hydra-perl-deps;
 paths = with perlPackages;
   [ ModulePluggable
 CatalystAuthenticationStoreDBIxClass
 CatalystDispatchTypeRegex
 CatalystPluginAccessLog
 CatalystPluginAuthorizationRoles
 CatalystPluginCaptcha
 CatalystPluginSessionStateCookie
 CatalystPluginSessionStoreFastMmap
 CatalystPluginStackTrace
 CatalystPluginUnicodeEncoding
 CatalystTraitForRequestProxyBase
 CatalystViewDownload
 CatalystViewJSON
 CatalystViewTT
 CatalystXScriptServerStarman
 CatalystActionREST
 CryptRandPasswd
 DBDPg
 DBDSQLite
 DataDump
 DateTime
 DigestSHA1
 EmailSender
 FileSlurp
 LWP
 LWPProtocolHttps
 IOCompress
 IPCRun
 JSONXS
 PadWalker
 CatalystDevel
 Readonly
 SetScalar
 SQLSplitStatement
 Starman
 SysHostnameLong
 TestMore
 TextDiff
 TextTable
 XMLSimple
 NetAmazonS3
 nix git
   ];
   };
 in

 stdenv.mkDerivation rec {
   name = hydra-${version};

   src = fetchgit {
 url = https://github.com/NixOS/hydra.git;;
 rev = 91f895b3d660560e40278b1c4e8c50172f3ac065;
 sha256 =
 71954b6a3f6037b75698f6c7262cf0f97442bb5af8c5d31e543479ae8eee8f7a;
   };


   preConfigure = ''
 # TeX needs a writable font cache.
 export VARTEXFONTS=$TMPDIR/texfonts

 addToSearchPath PATH $(pwd)/src/script
 addToSearchPath PATH $(pwd)/src/c
 addToSearchPath PERL5LIB $(pwd)/src/lib

 ./bootstrap
 '';

   configureFlags = [--with-nix=${nix}
 --with-docbook-xsl=${docbook_xsl}/xml/xsl/docbook ];

   buildInputs =
 [ makeWrapper libtool unzip nukeReferences pkgconfig boehmgc
 sqlite
   gitAndTools.topGit mercurial darcs subversion bazaar openssl
 bzip2
   guile perlDeps perl
   autoconf automake libtool libxslt dblatex tetex
 ];

   hydraPath = lib.makeSearchPath bin (
 [ libxslt sqlite subversion openssh nix coreutils findutils
   gzip bzip2 lzma gnutar unzip git gitAndTools.topGit mercurial
 darcs gnused graphviz bazaar
 ] ++ lib.optionals stdenv.isLinux [ rpm dpkg cdrkit ] );

   preCheck = ''
 patchShebangs .
 export LOGNAME=${LOGNAME:-foo}
   '';

   postInstall = ''
 mkdir -p $out/nix-support
 nuke-refs $out/share/doc/hydra/manual/manual.pdf

 for i in $out/bin/*; do
 wrapProgram $i \
 --prefix PERL5LIB ':' $out/libexec/hydra/lib:$PERL5LIB \
 --prefix PATH ':' $out/bin:$hydraPath \
 --set HYDRA_RELEASE ${version} \
 --set HYDRA_HOME $out/libexec/hydra \
 --set NIX_RELEASE ${nix.name http://nix.name}
 done
   ''; # */

   meta.description = Build of Hydra on ${system};
   passthru.perlDeps = perlDeps;
 }
 ___
 nix-dev mailing list
 nix-dev@lists.science.uu.nl mailto:nix-dev@lists.science.uu.nl
 http://lists.science.uu.nl/mailman/listinfo/nix-dev



___
nix-dev

[Nix-dev] hydra's nix-expression works in nix-shell, but fails with nix-build

[Thomas Strobel]

Hi!

I'm trying to write a nix-expression for current hydra, see below. It
works within nix-shell, but fails with nix-build, both on 14.04.
Could someone maybe help me with that, please?

Many thanks,
Thomas



hydra.nix


{ stdenv, fetchgit, pkgs }:
with pkgs;
let
  nixpkgs = pkgs;
  version = 0.17;

  nix = pkgs.nixUnstable;

  perlDeps = pkgs.buildEnv {
name = hydra-perl-deps;
paths = with perlPackages;
  [ ModulePluggable
CatalystAuthenticationStoreDBIxClass
CatalystDispatchTypeRegex
CatalystPluginAccessLog
CatalystPluginAuthorizationRoles
CatalystPluginCaptcha
CatalystPluginSessionStateCookie
CatalystPluginSessionStoreFastMmap
CatalystPluginStackTrace
CatalystPluginUnicodeEncoding
CatalystTraitForRequestProxyBase
CatalystViewDownload
CatalystViewJSON
CatalystViewTT
CatalystXScriptServerStarman
CatalystActionREST
CryptRandPasswd
DBDPg
DBDSQLite
DataDump
DateTime
DigestSHA1
EmailSender
FileSlurp
LWP
LWPProtocolHttps
IOCompress
IPCRun
JSONXS
PadWalker
CatalystDevel
Readonly
SetScalar
SQLSplitStatement
Starman
SysHostnameLong
TestMore
TextDiff
TextTable
XMLSimple
NetAmazonS3
nix git
  ];
  };
in

stdenv.mkDerivation rec {
  name = hydra-${version};

  src = fetchgit {
url = https://github.com/NixOS/hydra.git;;
rev = 91f895b3d660560e40278b1c4e8c50172f3ac065;
sha256 =
71954b6a3f6037b75698f6c7262cf0f97442bb5af8c5d31e543479ae8eee8f7a;
  };


  preConfigure = ''
# TeX needs a writable font cache.
export VARTEXFONTS=$TMPDIR/texfonts

addToSearchPath PATH $(pwd)/src/script
addToSearchPath PATH $(pwd)/src/c
addToSearchPath PERL5LIB $(pwd)/src/lib

./bootstrap
'';

  configureFlags = [--with-nix=${nix}
--with-docbook-xsl=${docbook_xsl}/xml/xsl/docbook ];

  buildInputs =
[ makeWrapper libtool unzip nukeReferences pkgconfig boehmgc sqlite
  gitAndTools.topGit mercurial darcs subversion bazaar openssl bzip2
  guile perlDeps perl
  autoconf automake libtool libxslt dblatex tetex
];

  hydraPath = lib.makeSearchPath bin (
[ libxslt sqlite subversion openssh nix coreutils findutils
  gzip bzip2 lzma gnutar unzip git gitAndTools.topGit mercurial
darcs gnused graphviz bazaar
] ++ lib.optionals stdenv.isLinux [ rpm dpkg cdrkit ] );

  preCheck = ''
patchShebangs .
export LOGNAME=${LOGNAME:-foo}
  '';

  postInstall = ''
mkdir -p $out/nix-support
nuke-refs $out/share/doc/hydra/manual/manual.pdf

for i in $out/bin/*; do
wrapProgram $i \
--prefix PERL5LIB ':' $out/libexec/hydra/lib:$PERL5LIB \
--prefix PATH ':' $out/bin:$hydraPath \
--set HYDRA_RELEASE ${version} \
--set HYDRA_HOME $out/libexec/hydra \
--set NIX_RELEASE ${nix.name}
done
  ''; # */

  meta.description = Build of Hydra on ${system};
  passthru.perlDeps = perlDeps;
}
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Openssl and fast security updates

[Thomas Strobel]

On 06/06/2014 07:59 AM, Ertugrul Söylemez wrote:
 On Thu, 05 Jun 2014 23:39:34 +0200
 Vladimír Čunát vcu...@gmail.com wrote:

 Hydra has and uses priorities. Anyway, building OpenSSL itself is very 
 quick, but rebuilding all that (transitively) depends on it is worse. 
 And there are CVE fixes for stdenv stuff sometimes (glibc)...
 Yes, and the basic idea is that you could have high priority packages like 
 OpenSSL, OpenVPN and nginx.  Whenever Hydra sees a job of higher priority it 
 starts doing it (potentially aborting whatever it is currently doing).  Once 
 all jobs of the same priority are done, it runs the tests of the same 
 priority and updates the channel.  Then it goes to the next highest priority. 
  That way security updates won't take longer than necessary.

 When we use priorities generously we could avoid a lot of delay even in less 
 critical cases.


 Greets,
 Ertugrul


So you would provide a separate channel then which is updated
incrementally, and the original channel is updated once all packages are
being built?

Does the nix package manager allow to measure how many packages it would
have to build for a system's current configuration and for how many
packages there would be binary package available? If so, it would help
to decide whether to wait for Hydra to build the needed packages, or
when to start building the remaining locally.

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

[Nix-dev] Error on creating hoogle database (permission denied)

[Thomas Strobel]

Hi!

I was trying to create a hoogle database with 'hoogle data', but there
is no way to specify where to write the database to. So I get the
following error:
''
hoogle:
/nix/store/jl9j7s3s69q8l1imr9caxbxfc4cpg2g9-haskell-hoogle-ghc7.6.3-4.2.32/share/hoogle-4.2.32/databases:
createDirectory: permission denied (Read-only file system)
''

Any help or suggestions would be welcome :)


Many thanks,

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

[Nix-dev] Binary cache for local hydra server

[Thomas Strobel]

Hi there!

I want to set up a binary cache for my locally running hydra and I would
be very thankful for some suggestions how to do that.
The binary cache should provide what http://cache.nixos.org provides for
http://hydra.nixos.org, that is it should work as a fast way to serve
the nix-packages build by hydra.

Looking through the configurations for delft/lucifer I found that it is
executing a local script mirror-nixos-stable.sh in a service and I
assume that script transfers the built nix packages to the binary cache.
Can anyone tell me more about the magic that that script is doing?
Also, what would be the best server to use as binary cache? E.g. what is
being used for cache.nixos.org? Or anything else I should/could consider
or think about?


In advance, many thanks for your help!

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

Re: [Nix-dev] Problems installing NixOS with btrfs from a USB stick

[Thomas Strobel]

Thank you very much for looking into it and fixing it so quickly!

On Tue, 2014-04-15 at 08:52 +0200, Wout Mertens wrote:
 I fixed it by stracing mkfs. btrfs and creating a symlink to /.
 Basically it gets confused by the bind mounts and looks for root at
 the original location. 
 So just strace -eopen mkfs... and look for enoent. 
 On phone, sorry for lack of details. 
 
 On Apr 13, 2014 12:41 PM, Alexei Robyn sha...@shados.net wrote:
 Hello,
 
 If you're talking about the can't determine mount status
 of /dev/...
 issue, this is a bug with mkfs.btrfs. See
 http://lists.science.uu.nl/pipermail/nix-dev/2012-December/010237.html
 
 - Alexei
 
 On Sun, Apr 13, 2014, at 07:49 PM, Cillian de Róiste wrote:
  Hi!
 
  On Sun, Apr 13, 2014 at 11:05 AM, Thomas Strobel
 ts...@cam.ac.uk wrote:
   Hi there,
  
   I was running into problems when trying to install NixOS
 with btrfs from
   a USB stick. I downloaded the current .iso and used
 unetbootin to create
   a bootable USB drive from it.
  
   Unfortunately, the resulting installation environment did
 not allow to
   use mkfs.btrfs as it could not decide on the mounting
 status of my
   partition. It seemed as if unetbootin prepared the system
 in a way that
   prevented mkfs.btrfs from working.
  
   Did anyone else experience that problem?
  
   If so, then my question is if the .iso files could be
 changed in a way
   that allows to prepare the USB stick with a simple
 dd-command, e.g. like
   Debian or GRML ISOs do, and that keeps mkft.btrfs working?
 
  You could try installing syslinux and using isohybrid to
 create a
  hybrid bootable image which you can dd onto a USB stick:
 
  isohybrid filename.iso
 
 
 
 http://www.syslinux.org/wiki/index.php/Doc/isolinux#HYBRID_CD-ROM.2FHARD_DISK_MODE
 
  I'm not sure if that will help with the btrfs issue, but it
 would be
  good to know if it worked.
 
  Good luck!
  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


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

[Nix-dev] Problems installing NixOS with btrfs from a USB stick

[Thomas Strobel]

Hi there,

I was running into problems when trying to install NixOS with btrfs from
a USB stick. I downloaded the current .iso and used unetbootin to create
a bootable USB drive from it.

Unfortunately, the resulting installation environment did not allow to
use mkfs.btrfs as it could not decide on the mounting status of my
partition. It seemed as if unetbootin prepared the system in a way that
prevented mkfs.btrfs from working.

Did anyone else experience that problem?

If so, then my question is if the .iso files could be changed in a way
that allows to prepare the USB stick with a simple dd-command, e.g. like
Debian or GRML ISOs do, and that keeps mkft.btrfs working?


Many thanks,

  Thomas

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

[Nix-dev] pkg-config: update and avoid patching?

[Thomas Strobel]

Hi there,

I was just trying to track down problems I have compiling some source
under NixOS, and it seems as pkg-config is causing some trouble.

That's why I wanted to bring up issue #292 again:
Broken pkg-config patch for Requires.private

Are there any plans to integrate a newer version of pkg-config and to
avoid patching 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] pkg-config: update and avoid patching?

[Thomas Strobel]

Hi there,

I was just trying to track down problems I have compiling some source
under NixOS, and it seems as pkg-config is causing some trouble.

That's why I wanted to bring up issue #292 again:
Broken pkg-config patch for Requires.private

Are there any plans to integrate a newer version of pkg-config and to
avoid patching it?

Many thanks,

  Thomas


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