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

[Thomas Strobel]

)


  Commit: 17f6e7bfdebe1bd327cb1a9851382ad21989751e
  
https://github.com/NixOS/nixpkgs/commit/17f6e7bfdebe1bd327cb1a9851382ad21989751e
  Author: Eelco Dolstra 
  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

Re: [Nix-dev] Notes and ideas about the Nix-UI proposal

[Thomas Strobel]

It is on its way: https://github.com/NixOS/nixpkgs/pull/9250 :)

On 01/24/2016 05:46 AM, Taeer Bar-Yam wrote:
> +1 on the user-level configuration.nix.
>
> Could we also use this to bring dotfiles into the nix fold?
>
> I'm not sure what the current system for dotfile management is, but my 
> impression is it is close to nonexistant. It would be nice to add this to the 
> nix way of managing things. A user-level configuration file seems like *a* 
> right way to do this.
>--Taeer
>> On Jan 23, 2016, at 1:42 PM, zimbatm  wrote:
>>
>> I keep seeing this transaction argument but what is the use-case for it ?
>>
>> For complex scenarios I think it would be best to have a user-equivalent of 
>> the /etc/nixos/configuration.nix file and a `nix switch` command to apply 
>> the changes in a transactional manner. Then `nix install` and friends might 
>> be implemented in terms of amending the user's configuration.nix or related 
>> file and then run `nix switch`. That way it's easy to synchronize the 
>> profile between computers. `nix install` might even gain a `--no-switch` 
>> flag to just manipulate that list.
>>
>>
>> On Sat, 23 Jan 2016 at 18:03 Matthias Beyer > > wrote:
>> So `nix do nix` would do nothing?
>>
>> (Joke for the germans)
>>
>> I like the idea of having `nix do`.
>>
>> On 23-01-2016 17:11:15, Oliver Charles wrote:
>>> `nix do`? :)
>>>
>>> On Sat, Jan 23, 2016 at 4:59 PM Matthias Beyer >> >
>>> wrote:
>>>
 Hi,

 On 23-01-2016 17:39:09, Christian Theune wrote:
>
> I like the direction where this is going a lot. A big +1 from my side.

 Same here.

>
> As a suggestion to the transactional behaviour, I’d like to avoid
 unnecessary shell quoting. How about “+” instead of “;"? I could imagine
 another non-colliding operator from the nix language, but “;” as a
 statement separator is going to be confusing because bash already uses it
 for almost the same thing.
>

 I want to second this! Especially because "\" is kinda hard to type on
 german
 keyboards (two strokes and a weird location of both keys, ergonomically).
 "+"
 sounds much better.

 What would be nice is a "repl"-like thing where you can do this:

  nix transaction
  > install firefox
  > uninstall chromium
  > commit  ## or maybe ctrl-D
  [nix] transaction about to be committed... doing things now

 (ofc, the `nix install firefox $sep uninstall chromium` variant should be
 available as well)

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

>>
>> --
>> 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
>
>
>
>
> ___
> 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.
> >
> > PS: Alternatively, 

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  <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] 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.
> >
> > PS: Alternatively, 

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

Re: [Nix-dev] Automatic download option for "requireFile"

[Thomas Strobel]

Hi,

On 02/23/2015 02:08 PM, Eelco Dolstra wrote:
> Hi,
>
> On 22/02/15 19:51, Vladimír Čunát wrote:
>
>> On 02/22/2015 11:26 AM, Tomasz Kontusz wrote:
>>> Talking about laws: are there any guidelines about what software can go
>>> into nixpkgs/can be distributed by hydra?
>>> I know many distributions try to somehow separate the software illegal
>>> in USA (mostly DRM-related/patented stuff).
>> Basically anything is accepted in nixpkgs, even non-redistributable stuff as 
>> you
>> see (why else requireFile). 
> FWIW, I'm fairly strongly against inclusion of any package that cannot be
> installed automatically, i.e., anything that uses requireFile. The reason 
> being
> that if a package shows up in "nix-env -qa", then "nix-env -i " 
> should
> Just Work.
>
> There are some unfortunate historic exceptions (like the Oracle JDK) but we
> should try not to proliferate them.
>
> We probably also shouldn't include packages that require obtaining a license 
> key
> or something similar. I.e. packages should be usable by everybody.
>


So, how should we deal with software that can be downloaded "freely",
but where the user has to accept a certain license?
Is the nixpkgs option "config.allowUnfree = true;" meant exactly for
that cases? I mean, should nix-env just go ahead and
download whatever can be downloaded legally by accepting a particular
license when "allowUnfree" is set to true?
Or, should there be an extra option in nixpkgs config for every license
or user agreement of a software? Like in the case of
Oracle JDK, e.g., "config.license.oraclejdk.accept=true;"?

Concerning Oracle JDK, as far as I understand, "fetchurl" would need
some changes to download the Oracle JDK directly.
How to accept the user license in the download request is described in
[1], and I would be happy integrate an appropriate
function into "fetchurl", or to write a download program specifically
for Oracle JDK, if that is preferred.

As long as it is only a technical issue that, e.g., Oracle JDK cannot be
downloaded automatically, and not a legal one, I'm happy
to work on it.

[1]
https://www.digitalocean.com/community/tutorials/how-to-manually-install-oracle-java-on-a-debian-or-ubuntu-vps

___
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

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

[Thomas Strobel]

Thanks! I found the corresponding commit:

# first bad commit: [dbbd849ce847ea797eaf0110da5e695ad227fc63] openssl:
1.0.1j -> 1.0.1k

I just can't see how that commit is breaking my system... but apparently
it does. Any idea?


On 02/03/2015 01:47 PM, Domen Kožar wrote:
> Best to use "git bisect" :)
>
> On Tue, Feb 3, 2015 at 12:10 PM, Thomas Strobel  wrote:
>
>> 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
>>

___
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

[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] Multiple instances - detecting resource collisions - nixos module system question

[Thomas Strobel]

On 01/14/2015 11:17 PM, Marc Weber wrote:
> If you use multiple apaches/nginx/mysql/postgresql/whatever instances
> its likely to miss adjusting the port or whatsoever. Therefore I'd like
> to implement a simple "resource tracking" module which fails if a
> resource such as tcp/ip port or socket or such gets used multiple times.
>
> It should look like this: http://dpaste.com/10RKJSQ
>
>
> A test like this:
>resources.tcp-ports."80" = {};
>
> causes:
>   The option `resources.tcp-ports.80.allowCollisions' defined in 
> `/etc/nixos/nixpkgs/nixos/modules/misc/resources.nix' does not exist.
>
> which I don't get because the dpaste sets a default value for
> allowCollisions.
>
> Thus does anybody just spot what I'm doing wrong?
>
> If we are at it: Eelco Dolstra proposed "services.mysql.services" or
> such. What about services.mysqls ? We could deprecade services.mysql
> then and ask users to switch slowly. No naming collisions. Naming is
> short and could be adopted to other services.
>
> Marc Weber
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev

I think you're pushing into a very interesting direction!

So do I understand it correctly that you want to define a framework
which checks whether the port assignments for individual services are
consistent? So the port numbers are still kept in the service definitions?

I'm wondering whether it is possible to go the other way and to
centralize the port definitions and to forward the assignments to the
individual services? I think of something where I can see in one place
which service is attached to which interface, here e.g. localhost, the
external interface, an interface secured through IPsec or maybe services
run behind tor:

attach.localhost = {
   http = service.apache.privatePorts;
   "8080" = service.myPrivateProxy {config = 1};
   "8081" = service.myPrivateProxy {config = 2};
   "8082" = service.myPrivateProxy {config = 3};
};

attach.external = {
  http = services.apache.publicPorts;
  smtp = services.postfix;
  DEFAULT = services.dns;
  ...
};

attach.ipsec = {
  ipsec_configuration = {...};
  services = {
imap = services.cyrus;
  };
};

attach.tor = {
  tor_configuration = {...};
  services = {
 I_am_here = services.somethingHidden;
  };
};

Services would only start if all necessary ports are assigned through an
attach statement. Firewall rules could be automatically set through the
attach framework, as suggested by Moritz. Moving a service e.g. from a
private to a public interface would then be achieved by just attaching
it to a different interface. Service parameters could be overwritten to
define multiple instances of a service, like for myPrivateProxy in the
example. I would also classify ports of services into e.g. public or
private ports, like for apache in the example. That would allow to
easily expose the public ports on a public interface and have the
private ones e.g. only accessible through localhost or maybe IPsec.
Maybe it's also possible to have default ports defined within a service
definition, and then attach a service using its default ports, e.g.
somehow like for dns in the example.

What do you think? It's just an idea that I wanted to share.

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

 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 
> 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
>> >>> 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"  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=157508191&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/cl
>>
>> > /ostg.clktrk [10] mailto:
>> e...@lists.sourceforge.net
>> [11]
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
>> [12]
>> mailto:enlightenment-
>>
>> > .net/lists/listinfo
>> t-devel
>>
>> 

[Nix-dev] Schedule for NixOS sprint?

[Thomas Strobel]

Hi!

I wanted to ask what people intend to work on during the NixOS sprint
end of August? Is there a particular schedule for it?
I'm thinking about signing up for it, but before I would be happy to
have a few more information about what is going to happen and what I
could help working on.

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

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]

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

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

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  <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//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--wrapper/lib/ghc-/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//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
>

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//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--wrapper/lib/ghc-/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//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  {};
>   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  <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  <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
>
>   

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

[Nix-dev] Problems logging into Hydra's web service

[Thomas Strobel]

Hi,

I'm trying to install Hydra (git HEAD) on nixos with an unstable-channel
following the configuration in
https://nixos.org/wiki/Installing_hydra_as_nixos_module , followed by
hydra-init and then hydra-create-user to create an admin. It installs as
expected, and the services are started via systemd as well.

However, I'm unable to log into Hydra's web service. The debug messages
show: "Unable to locate user matching user info provided in realm:
dbic".
Manually checking /var/lib/hydra/hydra.sqlite shows the user though.

Interestingly though, if I don't start hydra via systemd but run
hydra-server manually, then I'm able to log into hydra's web service.

Does anyone happen to know how I could resolve this issue to get hydra
working with systemd?


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