Re: [Nix-dev] Google Summer of Code 2017

[Thomas Hunger]

Hi Anderson,

Please do! Just submit a PR and I'll give you push permissions. The more
ideas we have the better.

~

On 28 March 2017 at 18:48, Anderson Torres 
wrote:

> No problems, guys! Just keep calm and carry on! We gained another year
> to rally efforts on a GSOC 2018!
>
> Thomas, can I add my ideas to your Github repo?
>
> 2017-03-15 12:33 GMT-03:00 Oliver Charles :
> > On Wed, Mar 15, 2017 at 12:47 PM Domen Kožar  wrote:
> >>
> >> We aren't participating in GSOC 2017, because I missed the submission
> >> deadline.
> >>
> >>
> >> That being said, I know people will be disappointed by this. I'm sorry,
> >> I have no excuses really. I was overworked at that time and totally
> forgot
> >> to watch the dates.
> >>
> >> I already applied us two times, I hope I'll gather the energy to try
> again
> >> next year.
> >> But since I screwed up this year, someone else can take over if wanted,
> >> I understand not to be trusted :)
> >
> >
> > As Thomas said, no hard feelings - this is not your fault! There's always
> > next year :)
> >
> > - ocharles
> ___
> 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] Google Summer of Code 2017

[Thomas Hunger]

I don't believe in individual failure. We should try to put a system in
place to avoid this next time.

A related issue is that GHC didn't get in either because they didn't have a
good page with potential projects.

I propose:

* Several of us put the next deadline into our calendar (probably beginning
of Feb, so I used 31st of January 2018). I just did so.
* We collect ideas for next year already. I have created:
https://github.com/teh/gsoc/blob/master/2018/projects.md - please send PRs
and I'll give you commit bits.

~



On 15 March 2017 at 12:46, Domen Kožar  wrote:

> We aren't participating in GSOC 2017, because I missed the submission
> deadline.
>
>
> That being said, I know people will be disappointed by this. I'm sorry,
> I have no excuses really. I was overworked at that time and totally forgot
> to watch the dates.
>
> I already applied us two times, I hope I'll gather the energy to try again
> next year.
> But since I screwed up this year, someone else can take over if wanted,
> I understand not to be trusted :)
>
> Domen
>
> On Mon, Mar 13, 2017 at 6:23 PM, Anderson Torres <
> torres.anderson...@gmail.com> wrote:
>
>> 2017-01-08 18:40 GMT-02:00 Profpatsch :
>> > On 17-01-04 09:42pm, Vladimír Čunát wrote:
>> >> On 01/04/2017 08:51 PM, Peter Simons wrote:
>> >> > Another very important topic that needs to be addressed in Nix /
>> Hydra
>> >> > is the question of how to deal with code that wants to import build
>> >> > products into the ongoing evaluation. [...]
>> >>
>> >> That feels rather vague topic ATM.  My experience is that this kind of
>> >> "figure it out how to..." tasks isn't very suitable for similar
>> "project
>> >> proposals" like for GSoC.  Still, if we could converge on some more
>> >> concrete plan beforehand, maybe the actual implementation would make a
>> >> good topic...
>>
>> I would suggest three big fat proposals:
>>
>> 1 - The most flamewar-igniting one: getting rid of systemd dependency!
>> It would be very nice if the init system was selectable, with a sane
>> default (as openrc).
>> It would be hard as hell to port certain software as Gnome stack, but
>> I think it can be solved.
>>
>> 2 - Another for the even more courageous would be run a Nixos+kNetBSD
>> (or kFreeBSD), as in Debian. It would be the definitive test for
>> portability and independence of Nix model.
>>
>> 3 - Another set of defaults for the stdenv, as musl+clang.
>>
>> >
>> > Sounds more like a task for a master’s thesis (or adventurous
>> > bachelor’s thesis) to me.
>> >
>> > --
>> > Proudly written in Mutt with Vim on NixOS.
>> > Q: Why is this email five sentences or less?
>> > A: http://five.sentenc.es
>> > May take up to five days to read your message. If it’s urgent, call me.
>> > ___
>> > nix-dev mailing list
>> > nix-dev@lists.science.uu.nl
>> > http://lists.science.uu.nl/mailman/listinfo/nix-dev
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] nixos-container networking

[Thomas Hunger]

Would it be possible to add an assert if there are any restrictions on the
naming? I don't know enough about this to be of much help though.

On 14 March 2017 at 06:01, Danylo Hlynskyi  wrote:

> Strange, I have lot's of containers with "-" and experience no problems.
> But maybe you've exceeded by accident limit 13 symbols per container name?
>
> Also, last time I tried "veth" networking, I was struggling from
> https://github.com/NixOS/nixpkgs/issues/16330. My container experience
> was awful when I tried container renames. That's why I've already switched
> to bridged networking
>
> ---
>
> BTW, I highly recommend patch to switch-to-configuration.pl
> 
> from https://github.com/NixOS/nixpkgs/pull/3021/commits/
> 6e36619b277f78ece1bb81b79b5651897e46a2bf
>
> It isn't clear from commit message, but it does the following: makes
> declarative containers truly reloadable (when you change
> container config, it activates new configuration for container). The
> culprit is *it should be* default behavior, because of
>
> 1. https://github.com/NixOS/nixpkgs/blob/master/nixos/
> modules/virtualisation/containers.nix#L225-L230
> 2. https://github.com/NixOS/nixpkgs/blob/master/nixos/
> modules/virtualisation/containers.nix#L676
>
> I'd like to PR this, but got no time to test properly other parts of Nixos.
>
> 2017-03-14 4:42 GMT+02:00 Tomasz Czyż :
>
>> Michael, Ian, thank you for your answers.
>>
>> Looks like my problem was with the container name. I tried bunch of
>> different setups which didn't work and I discovered that when I'm using "-"
>> in container name it doesn't work (I had impression that worked one or two
>> times when I started machine from scratch, but most of the time didn't).
>>
>> After I removed "-" from the name, looks like private network is working
>> (I can access private IP of container) so I don't need NAT actually.
>>
>> Tom
>>
>> 2017-03-13 23:54 GMT+00:00 Ian-Woo Kim :
>>
>>> I've recently made nixos-container port forwarding easier (both
>>> imperative and declarative) and it's now merged into master.
>>>
>>> https://github.com/NixOS/nixpkgs/pull/20869
>>>
>>> Hope that this helps.
>>>
>>> Ian
>>>
>>> On Sun, Mar 12, 2017 at 7:52 PM, Michael Walker 
>>> wrote:
>>> > Tomasz,
>>> >
>>> > I have declarative container networking set up and working on a VPS,
>>> > but I wrote most of the configuration as I was learning things, so it
>>> > may not be the best way.
>>> >
>>> > Here's the configuration.nix for the VPS:
>>> > https://github.com/barrucadu/nixfiles/blob/master/hosts/innsmouth.nix
>>> > Each container has a config file here:
>>> > https://github.com/barrucadu/nixfiles/tree/master/containers
>>> >
>>> > Containers have ports forwarded to them via NAT; each container is
>>> > running a web server on port 80 with the host reverse-proxying via
>>> > nginx; the host also does https and letsencrypt for all the proxied
>>> > containers.
>>> >
>>> > At the top of the innsmouth.nix file, I have a "containerSpecs" record
>>> > which has all the details for each container. The relevant bits of the
>>> > config are:
>>> >
>>> > 1. Set up the networking and NAT:
>>> >
>>> > networking.nat.enable = true;
>>> > networking.nat.internalInterfaces = ["ve-+"];
>>> > networking.nat.externalInterface = "enp0s4";
>>> >
>>> > 2. Forward ports to containers:
>>> >
>>> > networking.nat.forwardPorts = concatMap
>>> > ( {num, ports, ...}:
>>> > map (p: { sourcePort = p; destination =
>>> > "192.168.255.${toString num}:${toString p}"; }) ports
>>> > ) containerSpecs';
>>> >
>>> > 3. Define all the containers:
>>> >
>>> > containers = mapAttrs
>>> > (_: {num, config, ...}:
>>> > { autoStart = true
>>> > ; privateNetwork = true
>>> > ; hostAddress = "192.168.254.${toString num}"
>>> > ; localAddress = "192.168.255.${toString num}"
>>> > ; config = config
>>> > ; }
>>> > ) containerSpecs;
>>> >
>>> > 4. Reverse-proxy HTTPS to HTTP in each container, manage letsencrypt
>>> > certificates, and forward HTTP to HTTPS.
>>> >
>>> > This is a little complex as I have a fairly custom nginx config (see
>>> > the services/nginx.nix file in the repository), but the
>>> > reverse-proxying is fairly straightfoward. Here is the generated
>>> > nginx.conf: https://misc.barrucadu.co.uk/nginx.txt
>>> >
>>> > On 13 March 2017 at 02:12, Tomasz Czyż  wrote:
>>> >> Hey,
>>> >>
>>> >> could anyone using nixos-container (declarative style) share how you
>>> setup
>>> >> networking?
>>> >>
>>> >> I'm trying to setup few containers with private network and http
>>> proxy at
>>> >> the front. Each container potentially could run application on port
>>> 80 and I
>>> >> would like to expose them through proxy.
>>> >>
>>> >> I 

Re: [Nix-dev] NixOS 17.03 Beta, 16.09 Security Support Timeline

[Thomas Hunger]

Hi Graham,

I tried reproducing the nixos-rebuild switch issue for setuid wrappers
without success: Can you point me to an issue, or give a hint for what you
mean by "break setuid binaries"? I'd like to fix this but don't yet
understand what's going on.

~

On 5 March 2017 at 15:25, Graham Christensen  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
> Hello,
>
> In my most recent roundup email, I included information about 17.03,
> 16.09, and the security support timeline. It was somewhat buried in the
> otherwise very standard message, so I'm sending just that information.
>
> NixOS 17.03 has entered Beta. This means we now have 3 versions of NixOS
> being developed:
>
>  - 16.09 (stable)
>  - 17.03 (beta)
>  - unstable
>
> 17.03 will become stable at the end of March.
>
> Due to the size of the NixOS community and the available resources we
> have, we typically only support one stable version of NixOS at a time.
>
> In order to ease the transition, I have decided to continue providing
> security patches to the 16.09 channel for one month after 17.03 is
> released, ending on May 3rd, 2017.
>
> You can switch from 16.09 to 17.03-beta via:
>
> $ sudo nix-channel --add https://nixos.org/channels/nixos-17.03 nixos
> $ sudo nix-channel --update
> $ sudo nixos-rebuild boot
> $ reboot
>
> Note: Don't use nixos-rebuild switch. The path to setuid wrappers has
> changed, and using switch will break setuid binaries (like sudo, ping,
> etc.) until you reboot.
>
> Thank you very much,
> Graham Christensen
> NixOS Security Team
> https://github.com/nixos/security
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCAAdFiEEP+htk0GpxXspt+y6BhIdNm/pQ1wFAli8LdAACgkQBhIdNm/p
> Q1ygjA//U16fikL8uHxAjh4vM26U5rsztpXjDcMSMIv5wWi7omWWnwQ0b9nf/WPH
> Tzh/nPA5L+DMrYBardPWF3PEriuuCW2oCBLhQpVIuYSl1vUmEL6R+GlBmHw6yD+G
> DWFuxrJWwQLxNAjSrMwP0bID3ZYtFyQQZKvsrzpFSh+ThCu1tkvOUt8A9t43SBIJ
> a0TTF6zFPez4GDrn7W702m4PMN0PEe0dyIg/UfpjmwEaxzgM8gZKcx/FLPh4IkVs
> WN0RoPavLb5UhBeHGoV7kXWohJ26Wx4R8/5rX2kEQWl+5dP2fHuhGs6oEtRC5EHx
> hiQmcwR+BCsQIZ6SzzveO2wOESiejjZnVuzqKoJ85NFfP39PRJqWD/GgHCsKCzwb
> YQX8U5zKVmHNr0pbjtYFmkmyfMNisvJ217L1X758BylOSwMcaKCxPOxfO/A/Lra5
> 3MMRJQDs983sBuqBen4INPPcn/43GwwpMwlhxVdutCP9iyiH87hRSoX/Vf9l6fNa
> vui2N00t8tn/biQKC0bFGBr5IPQiPmxBIVXRCP/Wiju+9vX5LUtk8y7pTr3lvkvr
> M30W0/Q+1XK1IkTLsDDyvuG6NHqek5peIA7K4SKi5w6jI8quzdCqYkflGrgbXQOV
> tyEEmmV8BMVPrpo7pmOQgHCh5ZlCU46hbqmHJxOjI2AJomwfLQo=
> =eVJJ
> -END PGP SIGNATURE-
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Explicitly selecting sources for "src" in stdenv.mkDerivation?

[Thomas Hunger]

Thanks for your replies everyone!

Bas - your "toString" helped me over the finishing line. Pretty obvious in
hindsight to use toString to force evaluation of src. I adapted your code
to this:

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

To be used like this:

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

And then I have some predefined lists like cabalProject = [".*\.cabal$",
".*\.hs"]

~



On 16 February 2017 at 21:58, Bas van Dijk <v.dijk@gmail.com> wrote:

> At LumiGuide we're using the following function in our Haskell packages:
>
>   # Copy everything under src into the Nix store except those paths that
> don't
>   # have one of the specified allowedPrefixes.
>   whitelistSource = src: allowedPrefixes:
> builtins.filterSource
>   (path: type:
> lib.any (allowedPrefix: lib.hasPrefix (toString (src + "/${
> allowedPrefix}")) path)
> allowedPrefixes)
>   src;
>
> To be used as for example:
>
>   src = lib.whitelistSource ./. [
>   "lumi-central-server.cabal"
>   "src"
>   "default.conf"
> ];
>
> Bas
>
> Op 16 feb. 2017 13:14 schreef "Thomas Hunger" <tehun...@gmail.com>:
>
> Hi,
>
> I am consistently struggling with the following in nix: I have a
> repository and I want to specify derivations for some local sub-projects.
> The obvious solution is
>
>   src = ./subproject-A;
>
> But that pulls in everything in that directory, including build artifacts,
> or random intermediate data files.
>
> Another solution is
>
>   src = sourceFilesBySuffices ./subproject-A [".cabal" ".hs"];
>
> Which works reasonably well but introduces this weird dance where I suffix
> files so they can be matched by sourceFilesBySuffices. Mostly I want to do
> this:
>
>   src = [ ./subproject-A/schema.sql ./subproject-A/lib ];
>
> Or even get all the files checked into git:
>
>   src = gitFiles ./subproject-A; # does not work
>
> I was wondering whether any of you have this issue, and if you do: how do
> you solve it?
>
> ~
>
> (see also https://github.com/NixOS/nix/issues/885)
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Explicitly selecting sources for "src" in stdenv.mkDerivation?

[Thomas Hunger]

Hi,

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

  src = ./subproject-A;

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

Another solution is

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

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

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

Or even get all the files checked into git:

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

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

~

(see also https://github.com/NixOS/nix/issues/885)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Which option replaces security.setuidOwners?

[Thomas Hunger]

There are some docs here:
https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/security/wrappers/default.nix#L111

Though I agree that we should probably also add something to the manual
about how to elevate privileges in NixOS.

~

On 14 February 2017 at 22:12, Tomasz Czyż  wrote:

> Actually, very strange that such a huge change has no documentation
> changes at all.
>
> Good thing is, there were some tests :)
>
> 2017-02-14 22:07 GMT+00:00 Bjørn Forsman :
>
>> On 14 February 2017 at 23:04, Bjørn Forsman 
>> wrote:
>> > On 14 February 2017 at 22:51, Domen Kožar  wrote:
>> >> We need to use renames for backwards compatibility then :)
>> >
>> > A rename implies same signature under different namespace (AFAICS).
>> > This is not the case here, because the option types are different.
>> >
>> > I've got a local change that is about to be pushed:
>> >
>> > +(mkRemovedOptionModule [ "security" "setuidOwners" ] "Use
>> > security.wrappers instead")
>> > +(mkRemovedOptionModule [ "security" "setuidPrograms" ] "Use
>> > security.wrappers instead")
>> >
>> > (I also do some other fixups that was wrt. new security.wrapper to
>> > make my NixOS build.)
>>
>> I created PR: https://github.com/NixOS/nixpkgs/pull/22806
>>
>> Best regards,
>> Bjørn Forsman
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>
>
>
> --
> Tomasz Czyż
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Which option replaces security.setuidOwners?

[Thomas Hunger]

Hi,

The option is now called `wrappers`. You can look at e.g. [1] for how to
update the code (more complex examples can be found in that same diff). The
assert is a great idea!

~

[1]
https://github.com/NixOS/nixpkgs/pull/16654/files#diff-
83d20e45a7ca489ef290ee1ee57543c7L28

(forgot reply all)

On 14 February 2017 at 20:20, Bjørn Forsman  wrote:

> Hi all,
>
> Now that security.setuiOwners is removed in master branch, which
> option replaces it?
>
> This is what users are faced with currently:
>
> $ nixos-rebuild build -I nixpkgs=.
> building Nix...
> error: The option `security.setuidOwners' defined in
> `/etc/nixos/config/base-small.nix' does not exist.
> (use ‘--show-trace’ to show detailed location information)
> error: The option `security.setuidOwners' defined in
> `/etc/nixos/config/base-small.nix' does not exist.
> (use ‘--show-trace’ to show detailed location information)
> building the system configuration...
> error: The option `security.setuidOwners' defined in
> `/etc/nixos/config/base-small.nix' does not exist.
> (use ‘--show-trace’ to show detailed location information)
>
> $ git grep setuidOwners
> (nothing)
>
> I think we need an assert here telling which option to use instead.
>
> Best regards,
> Bjørn Forsman
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] RFC for RFCs

[Thomas Hunger]

That would be amazing! I actually have an email sitting in my draft folder
proposing Nix Enhancement Proposals (NEPs).

IMHO one of the things we aren't very good at is getting larger changes
merged or rejected. We attract a lot of smart people because Nix is pretty
awesome. These smart people then do substantial work, submit a PR and the
PR bitrots. This is highly demotivating.

An RFC process would allow us to get to an accept / reject early on, with
the expectation that accepted RFCs will be merged when the technical work
is done.

I'll add more specific comments to your PR.

~

On 12 February 2017 at 15:12, zimbatm  wrote:

> Hi all,
>
> we discussed of introducing a RFC process during FOSDEM. The goal is to
> help discussion for large or controversial changes which typically grind to
> a halt.
>
> Here is an initial proposal based on the one from the Rust community:
> https://github.com/zimbatm/rfcs/pull/1 . Please let me know what you
> think.
>
> Cheers,
> z
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Shutting down prs.nix.gsc.io

[Thomas Hunger]

Expensive data transfer out from EC2 is the reason I added digital ocean
support to nixops. Our company fits into a few TB / month, but for more we
could use e.g. kimsufi which has 100Mbit / second unmetered for £20-30 /
month. Their servers also usually come with 2TB or more spinning disks
which would be good for fitting build outputs.

On 1 February 2017 at 12:38, Graham Christensen  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
> Hey everyone, :)
>
> I am touched by your offers to contribute to help pay for it. I am so
> thrilled to be part of a community that takes care of its own. It
> reminds me of this talk: https://www.youtube.com/watch?v=Xe1TZaElTAs.
>
> However, please instead take your generosity and perhaps donate to the
> NixOS Foundation: https://nixos.org/nixos/foundation.html or another
> worthy cause (up to you to know what that means.)
>
> Here is exactly how much the experiment cost:
>
> Usage Type| Usage   |  Price| Total
> 
> S3 PUT Requests   | 2,066,983   | $0.005/1,000  | $ 10.33
> S3 GET Requests   | 4,812,149   | $0.004/10,000 | $  1.92
> S3 Timed Storage  |   603 GB-Mo | $0.023/GB-mo  | $ 13.87
> Data Transfer In  | 1,907.028 GB| $0/GB | $  0.00
> Data Transfer Out | 3,698.464 GB| $0.090/GB | $332.86
> - -
>   $358.98
>
> Thank you so much,
> Graham Christensen
> -BEGIN PGP SIGNATURE-
>
> iQIcBAEBCAAGBQJYkdbAAAoJEAYSHTZv6UNcTcgP/38I07FjuexTkTIaRnzMawsN
> My6+IfWWzv+MToaiYLLaj5gMXplrHIuzdUVxq0LXAxqLDQdMbw3txuUai4gglFGS
> gWss7/3yYEyws0viT0OmWixq3+bDs57bAyC2k6LPt4QzxgFiLeAk1fyk7e2t1n6S
> 3GOj7HW000kjK7caxqTsKMORrk1WsQ6i1R+XupwJw8NU+0mFvVM/C6B3d5w8lP2S
> B9x0EcSV63rUh4IAio7EqU99KoJcLmc/HaE9uq4zYTFMhzcV1imV4bj9s+Qq6MQf
> 7amIu5br7ntBwTWDzdGmiMLbIbSI5IB4hzfDOedkavpWfwfj7EBR9j4cK9PHbo0+
> PoGR2x10wma6Sa0DrDgmRZx8WJypMXGYbgGZQCxr04wlYMh/hl7z9IhPZ8Z37GXx
> ote01hRdS82hfWgRIagkBJG9L5MnVqS5WNLHmo4tg2sf7ADPJoXUz7MO/zaGx2Dh
> dKzPDAA+cLOwcWI+rIoQTOIWTlskyjbJpymoNbhm1MZhqsGK4i+MLwFrDla8k6nh
> uhWg8lCAwWEJ3QqGRdeW3Pp2+d9KAIAN5QLFRFmW8s8fmLxLdbo2bPr/sw7NSTdk
> p7ZMJhC6K8bJkCleSxxGSsDvX5icokL0ZaaXVlZcyeZo8/ODQCBfxbC6M57uSrig
> qhsZ2InUPjQGTJZeozOb
> =Iu/C
> -END PGP SIGNATURE-
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] systemd dependencies for a network service

[Thomas Hunger]

Hi Azul,

Would running after dhcpcd.service work?

~

On 14 January 2017 at 16:57, Azul  wrote:

> I have a systemd vpn service that is wantedBy 'network.target', and runs
> after 'network-interfaces.target'.
>
> However the service fails to start properly (it does start but not in a
> useful way), as it requires DNS resolution to work and that doesn't seem to
> be the case after 'network-interfaces.target' is complete.
>
> Scratching my head to find out which of the systemd services provides that
> functionality, or if I will have to write a simple service that probes and
> waits for dns resolution and use that for my 'after=' systemd property.
>
> ___
> 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] Typing nix − funding campaign

[Thomas Hunger]

Hi,

For my own curiosity: Is your adviser's work online somewhere?

~

On 12 January 2017 at 17:17, Théophane Hufschmitt 
wrote:

> Thu 12 Jan 17 − 15:31, Peter Simons(sim...@nospf.cryp.to) a écrit:
> > Hi Théophane,
> >
> >  > https://www.gofundme.com/typing-nix
> >
> > I see that you plan to spend approx. 2 months (a third of the entire
> > project's time) on developing a parser for Nix. Why do you feel that
> > this is necessary, considering that there is a parser for Nix already?
> >
> > The notion of working with a separate implementation worries me because
> > I see the danger that your efforts are going to exist in a parallel
> > universe which won't be possible to merge back into Nix proper.
> >
> > Or, to put it differently, does your project even have the goal of
> > providing a working implementation for Nix? Or is it more about
> > exploring the design space for type systems that Nix could potentially
> > use?
> >
> > Best regards,
> > Peter
>
> Hi Peter,
>
> The two months are not just for formalizing the syntax and writing the
> parser, but also (and mostly) for bibliography.
>
> I agree with your concerns about the separate implementation.
> The reason for this is related to your third paragraph. The inference
> algorithm that is going to be used is no trivial at all to implement,
> and my advisor already has done a lot of work on this that could be
> reused, but written in OCaml, and we agreed that writing and
> maintaining a parser it was far easier than reimplementing what he
> already had done, and that it would be too hard to ship a usable
> product in a few month without using it.
>
> Regarding the goal of the project, it will be focused on providing a
> working implementation for nix (although that will of course first
> require exploring the possibilities for a type system for nix). There
> is enough theorical work to come up with something usable (and useful)
> for a langaige such as nix.
>
> --
> Théophane Hufschmitt
>
> Thu 12 Jan 17 − 15:31, Peter Simons(sim...@nospf.cryp.to) a écrit:
> > Hi Théophane,
> >
> > > https://www.gofundme.com/typing-nix
> >
> > I see that you plan to spend approx. 2 months (a third of the entire
> > project's time) on developing a parser for Nix. Why do you feel that
> > this is necessary, considering that there is a parser for Nix already?
> >
> > The notion of working with a separate implementation worries me because
> > I see the danger that your efforts are going to exist in a parallel
> > universe which won't be possible to merge back into Nix proper.
> >
> > Or, to put it differently, does your project even have the goal of
> > providing a working implementation for Nix? Or is it more about
> > exploring the design space for type systems that Nix could potentially
> > use?
> >
> > Best regards,
> > Peter
>
> Hi Peter,
>
> The two months are not just for formalizing the syntax and writing the
> parser, but also (and mostly) for bibliography.
>
> I agree with your concerns about the separate implementation.
> The reason for this is related to your third paragraph. The inference
> algorithm that is going to be used is no trivial at all to implement,
> and my advisor already has done a lot of work on this that could be
> reused, but written in OCaml, and we agreed that writing and
> maintaining a parser it was far easier than reimplementing what he
> already had done, and that it would be too hard to ship a usable
> product in a few month without using it.
>
> Regarding the goal of the project, it will be focused on providing a
> working implementation for nix (although that will of course first
> require exploring the possibilities for a type system for nix). There
> is enough theorical work to come up with something usable (and useful)
> for a langaige such as nix.
>
> --
> Théophane Hufschmitt
>
> ___
> 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] Typing nix − funding campaign

[Thomas Hunger]

Hi,

Many thanks for giving this a shot, it's exciting! I donated some money and
I hope we'll get this rolling soon.

I have a few questions:

* Is the plan to merge this into the current nix c++ code base? If so: Do
you have some buy-in from the nix maintainers?
* If it's an external tool: would it compile to untyped nix, like e.g. flow
and TypeScript do?

~



On 12 January 2017 at 13:13, Théophane Hufschmitt 
wrote:

> Hi,
>
> I am Théophane Hufschmitt, a french master degree CS student, and I
> wish to start a six month length internship on giving nix a type
> system.
>
> Numtide offered to fund a part of the internship, but we still need
> some help for me to be able to start it.
>
> The goal of the internship is to design (and implement) a type system
> for nix in order to be able to statically get some guaranties about
> the well-foundness of the nixpkgs repo (or any nix expression), in
> complement to hydra or travis tests which may let some inconsistencies
> pass − especially on nixos module system which is way harder to test.
>
> Providing nix with a proper type system is a long running issue (see
> https://github.com/NixOS/nix/issues/14), and I think a huge
> opportunity for nix to improve its awesomeness.
>
> The crowdfunding campaign (and a slightly more detailled description of
> the project) is open at https://www.gofundme.com/typing-nix, and you
> are all invited to donate.
>
> Of course, I'll be happy to answer any question, by mail or on
> irc/matrix (I am regnat[m] on freenode).
>
> --
> Théophane Hufschmitt
>
> ___
> 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 17.03 release manager is Robin Gloster

[Thomas Hunger]

Amazing! Thanks Robin for taking that on.


On 10 January 2017 at 16:52, Domen Kožar  wrote:

> Hi all,
>
> I'm happy to announce Robin (https://github.com/globin) will be release
> manager starting with NixOS 17.03.
>
> He has been contributing to Nix ecosystem for over two years. I've met him
> personally at mayflower NixOS meetup and I'm sure he'll take release
> management to the next step.
>
> Please congratulate him, this is huge effort for him towards NixOS
> community!
>
> 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] Nixos vps

[Thomas Hunger]

@Jörg - do you have a link to the kexec based installer?

On 14 December 2016 at 15:00, Jörg Thalheim  wrote:

> I recently made some good experience with kexec based installer.
>
> They can run basically run on every Linux out there.
>
>
> On 2016-12-14 01:06, Jeaye wrote:
> > I've been running a NixOS droplet on DigitalOcean, via nixos-in-place[1]
> for about a year. The process for getting it on there is janky, but it's
> smooth sailing afterward.
> >
> > 1: https://github.com/jeaye/nixos-in-place
> >
> > On Mon, Dec 12, 2016 at 02:30:07PM +0100, Alexandre Peyroux wrote:
> >> Anyone tried on a scaleway instance?
> >>
> >> 2016-12-12 13:48 GMT+01:00 Profpatsch :
> >>
> >>> On 16-12-12 12:42pm, Azul wrote:
>  works on a 2GB 3quid/month OVH kvm instance, only had to rename eth to
> >>> ens3
>  uname -a
>  Linux vps353091 4.4.36 #1-NixOS SMP Fri Dec 2 08:09:18 UTC 2016 x86_64
>  GNU/Linux
> 
>  nice one chaps
> >>> Very cool!
> >>>
> >>> --
> >>> Proudly written in Mutt with Vim on NixOS.
> >>> Q: Why is this email five sentences or less?
> >>> A: http://five.sentenc.es
> >>> May take up to five days to read your message. If it’s urgent, call me.
> >>> ___
> >>> nix-dev mailing list
> >>> nix-dev@lists.science.uu.nl
> >>> 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 mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Nixos vps

[Thomas Hunger]

I tested various mechanisms and cloud providers over the last few weeks.
All providers I tested worked, although I often got less CPU than
advertised . Some combinations didn't work, e.g. I can't boot grsecurity
kernels on EC2. I'm sure the latter is possible, I just didn't have time to
investigate.

For installation I found nixos-infect [1] to be the best solution. It uses
obadz' undocumented NIXOS_LUSTRATE feature [2].

~

[1]
https://github.com/elitak/nixos-infect/blob/master/nixos-infect

[2]
https://github.com/NixOS/nixpkgs/pull/17784

On 12 December 2016 at 09:47, Kamil Chmielewski  wrote:

> I have done basic NixOps deploy support for CloudSigma:
> * https://github.com/kamilchm/nixpkgs/commit/
> a64c343cd4baa07fea1bcac422a4eaa9fb2f86d9
> * https://github.com/kamilchm/nixops/commit/c2ec202f6b9a1bd488fa27abf3c218
> 241b37b5d5
>
> But it's just a PoC.
>
> Best regards,
> Kamil
>
> 2016-12-12 10:31 GMT+01:00 Nathan Bijnens :
>
>> I have used Vultr, but you first need to create an image, see:
>> https://www.vultr.com/docs/install-nixos-on-vultr
>>
>> You can also use NixOS on Azure and Amazon AWS, ideally using NixOps...
>>
>> Best regards,
>>   Nathan
>>
>>
>> On Mon, Dec 12, 2016 at 9:37 AM Azul  wrote:
>>
>> Hey there,
>>
>> I use a set of really cheap OVH vps for a number of clustered apps
>> (consul, zookeeper and other stuff), however since OVH do not provide a
>> nixos KVM image I have deployed those on other OSs.
>> Now I would like to move those apps to nixos and just have one single set
>> of code to maintain, for that I just need some cheap vps provider providing
>> nixos instances.
>>
>> What is out there that you have used ?
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>>
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] NixOS Security Team

[Thomas Hunger]

+1 to all - thanks for putting in the effort & energy!

On 7 December 2016 at 11:52, Graham Christensen  wrote:

> Rob Vermaas  writes:
>
> >
> > I am fine with any of the nominees mentioned. But I am sure there
> > might be others that are willing and able to help (as mentioned, e.g.
> > nbp), we should make sure we are open to accepting help of such
> > people, and make sure they do not feel left out.
> >
>
> Yes indeed! I thought about nbp, but noted that he didn't specifically
> mention interest in that thread. That is also why I didn't suggest
> vcunat and others.
>
> If someone is interested, please do speak up!
>
> Graham
> ___
> 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] Distributing files between machines in a nixops deployment

[Thomas Hunger]

Key distribution in NixOps is a bit weak but there is:
https://nixos.org/nixops/manual/#opt-deployment.keys

>From your description you might also be interested in setting up a CA to
sign your user keys instead. E.g. [1] or [2]

~

[1]
https://www.digitalocean.com/community/tutorials/how-to-create-an-ssh-ca-to-validate-hosts-and-clients-with-ubuntu

[2]
https://blog-habets-se.blogspot.de/2011/07/openssh-certificates.html



On 19 November 2016 at 17:23, Marius Bergmann  wrote:

> You did not attach a link to your mail, but I guess you mean
> https://blog.wearewizards.io/how-to-use-nixops-in-a-team ?
>
>
> On 2016-11-19 18:08, Maarten Hoogendoorn wrote:
> > I'm not pretending to be a NixOps expert, but I think the approach of
> > generating the secret in the "deployment" machine is good enough.
> > You could store the private key encrypted in a git repository. Have you
> > seen this [1] blog post? It describes how to do this in a team.
> >
> > Best regards,
> > Maarten
> >
> >
> > 2016-11-19 12:50 GMT+01:00 Marius Bergmann  > >:
> >
> > On 2016-11-19 12:46, Arnold Krille wrote:
> > > On Sat, 19 Nov 2016 12:10:59 +0100 Marius Bergmann  > >
> > > wrote:
> > >> Is it possible to declare the distribution of a file (in my case
> > a ssh
> > >> server/client public key) to different machines in a nixops
> > >> deployment?
> > >>
> > >> I want to create a client keypair on one machine and then
> authorize
> > >> the public part on several other machines in the deployment. Those
> > >> other machines' public server keys should also be added to the
> > >> known_hosts of the machine logging into them.
> > >>
> > >> I know I could create all the keypairs on the machine running
> nixops
> > >> and send both the public as well as the private keys over the
> > >> network, but I would like to find out if there's a way around it.
> > >
> > > I think this is one of the things you don't do/want with
> Nix/NixOps as
> > > this is essentially self-modifying deployment. Which makes the
> > > deployment non-deterministic and unreproducible in the strict
> sense.
> > > With deployment-/configuration-management systems that have a
> central
> > > node and database, like chef and puppet can have, you can do such
> > > things. For Nix this is counter-intuitive.
> > >
> > > - Arnold
> >
> > Do you have a recommendation on how to handle my use case then? In
> > practice, I need this to allow the backup user to log into the
> machines
> > being backed up. Would you use a central location for all the key
> pairs?
> > ___
> > 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] Python: getting rid of PYTHONPATH in Nixpkgs

[Thomas Hunger]

I played with `withPackages` and it's rather nice. The only problem I had
was "collision between A and B" style errors. Is there any plan to allow
for collisions?

On 2 November 2016 at 06:05, Dmitry Kalinkin 
wrote:

>
> > On 01 Nov 2016, at 11:56, Freddy Rietdijk 
> wrote:
> >
> >
> > > To solve 2) you could also make a wrapper that combines selected
> outputs of the multiple output package without python itself. I think, this
> is what texlive does. That way all the burden of wrapping will be limited
> only to the multiple output packages.
> >
> > I'm not sure whether I understand what you mean. What kind of wrapper do
> you mean? What does it wrap, and what does it set? The problem with the
> multiple outputs is that when you would add each to PYTHONPATH, the extra
> outputs won't be importable unless the 'main' output is first. I don't see
> how that can be solved. One that sets PYTHONPATH? Or some kind of package
> I had in mind a simple ```combine [blah.foo blah.bar]``` that would
> produce a derivation with symlinks to both $foo/lib/python2.7/blah/foo and
> $foo/lib/python2.7/blah/bar, so multiple outputs are combined back and can
> be importable with the current envHook setting the PYTHONPATH. This is
> similar to the current python wrapper that additionally throws in the
> python interpreter itself along with wrapper to set PYTHONHOME.
> >
> > > As for the first point, I couldn’t very well understand what the
> problem is. Are you talking about conflict between instances of a package
> that were built against different version of the python? Then shouldn’t
> `--prefix` override the incompatible version, since, as you said, order
> matters?
> >
> > Example with discussion: https://github.com/NixOS/nixpkgs/pull/17749
> >
> >
> > On Tue, Nov 1, 2016 at 4:12 PM, Dmitry Kalinkin <
> dmitry.kalin...@gmail.com> wrote:
> >
> > > On 01 Nov 2016, at 06:22, Freddy Rietdijk 
> wrote:
> > >
> > > Hi,
> > >
> > > Currently we use PYTHONPATH a lot in Nixpkgs to let applications and
> the interpreter find Python modules. This typically works fine, but there
> are problems with this method and so I would like to get rid of it and use
> only `python.withPackages` which uses `python.buildEnv`.
> > >
> > > The two main issues with the use of PYTHONPATH:
> > >   • Before we used `--prefix $PYTHONPATH`, but this would leak
> PYTHONPATH into subprocesses, which is especially problematic when both
> parent and child depend on Python but of different versions.  `--set
> $PYTHONPATH` would solve that issue, but that makes it impossible to add
> other (impure) paths, which is an important feature. This also breaks
> alternative shells like `ipython`. This issue is currently solved by
> extending `sys.path` in the Python applications.
> > >   • Limits the use of multiple outputs. When moving a module of a
> package into a separate output it becomes problematic to load this again,
> since just adding the module to PYTHONPATH typically doesn't work because
> the order matters. While Python modules are typically small, and build
> fast, rebuilding can take a lot of time in cases like `matplotlib` which
> supports multiple backends and is depended on by quite some packages.
> > > A method that is more reliable is building an environment with
> symbolic links to all the modules, and wrapping the applications with a
> wrapper that sets PYTHONHOME. This is exactly what `python.buildEnv` does,
> and it solves both 1) and 2).
> > >
> > > `PYTHONPATH` is mainly constructed with the Python interpreter
> setupHook. It is used in `buildPythonPackage` for building the package, and
> after installing it is extended so the tests can run. Furthermore,
> `PYTHONPATH` is set by the `setupHook` when using `nix-shell` like
> `nix-shell -p pythonPackages.numpy`.
> > >
> > > I think we can get rid of the setupHook. For the building we can
> create an env. This would be able to support multiple outputs as inputs,
> but will be more expensive than setting PYTHONPATH. For the tests we do add
> the newly constructed package to PYTHONPATH; there's no way around it and
> it doesn't cause any problems either.
> > >
> > > The biggest impact will be on how `nix-shell` is used. It won't be
> possible anymore to use it as shown before, instead `nix-shell -p
> 'python.withPackages(ps:[ps.numpy])'` would have to be used. While it is
> possible to keep the setupHook (or use it as a shellHook) it will be
> unreliable in the case of multiple outputs.
> > >
> > > What do you think about this change? Do you see any problems with it?
> Any other suggestions?
> > >
> > > Freddy
> > > ___
> > > nix-dev mailing list
> > > nix-dev@lists.science.uu.nl
> > > http://lists.science.uu.nl/mailman/listinfo/nix-dev
> >
> > Hi,
> >
> > I’m far from being an expert in python, but here are my thoughts:
> >
> > To solve 2) you could also make a wrapper 

Re: [Nix-dev] Python: getting rid of PYTHONPATH in Nixpkgs

[Thomas Hunger]

I'm +1 on this because I encountered lots of problems with PYTHONPATH,
especially for programs that have their own module loading logic (e.g.
gunicorn, some Django code).

I don't know what new problems this change will introduce (other than what
you mentioned) but since this is closer to how virtualenv works I suspect
it'll be manageable.

~

On 1 November 2016 at 10:22, Freddy Rietdijk 
wrote:

> Hi,
>
> Currently we use PYTHONPATH
>  a lot in
> Nixpkgs to let applications and the interpreter find Python modules. This
> typically works fine, but there are problems with this method and so I
> would like to get rid of it and use only `python.withPackages` which uses
> `python.buildEnv`.
>
> The two main issues with the use of PYTHONPATH:
>
>1. Before we used `--prefix $PYTHONPATH`, but this would leak
>PYTHONPATH into subprocesses, which is especially problematic when both
>parent and child depend on Python but of different versions.  `--set
>$PYTHONPATH` would solve that issue, but that makes it impossible to add
>other (impure) paths, which is an important feature. This also breaks
>alternative shells like `ipython`. This issue is currently solved by
>extending `sys.path` in the Python applications.
>2. Limits the use of multiple outputs. When moving a module of a
>package into a separate output it becomes problematic to load this again,
>since just adding the module to PYTHONPATH typically doesn't work because
>the order matters. While Python modules are typically small, and build
>fast, rebuilding can take a lot of time in cases like `matplotlib` which
>supports multiple backends and is depended on by quite some packages.
>
> A method that is more reliable is building an environment with symbolic
> links to all the modules, and wrapping the applications with a wrapper that
> sets PYTHONHOME
> . This is
> exactly what `python.buildEnv` does, and it solves both 1) and 2).
>
> `PYTHONPATH` is mainly constructed with the Python interpreter setupHook.
> It is used in `buildPythonPackage` for building the package, and after
> installing it is extended so the tests can run. Furthermore, `PYTHONPATH`
> is set by the `setupHook` when using `nix-shell` like `nix-shell -p
> pythonPackages.numpy`.
>
> I think we can get rid of the setupHook. For the building we can create an
> env. This would be able to support multiple outputs as inputs, but will be
> more expensive than setting PYTHONPATH. For the tests we do add the newly
> constructed package to PYTHONPATH; there's no way around it and it doesn't
> cause any problems either.
>
> The biggest impact will be on how `nix-shell` is used. It won't be
> possible anymore to use it as shown before, instead `nix-shell -p
> 'python.withPackages(ps:[ps.numpy])'` would have to be used. While it is
> possible to keep the setupHook (or use it as a shellHook) it will be
> unreliable in the case of multiple outputs.
>
> What do you think about this change? Do you see any problems with it? Any
> other suggestions?
>
> Freddy
>
> ___
> 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] Limiting access to only maintained packages and ensuring core packages are maintained

[Thomas Hunger]

I'm mostly worried about leaning that I need to fix a package that I'm
maintaining. I care about fixing bugs and purging unmaintaned packages, but
most of the time I don't even see the report, or I know it's broken in
hydra until I test again locally.

Do you have any ideas around getting word out to maintainers sooner?

On 2 September 2016 at 21:22, Shea Levy  wrote:

> Hi all,
>
> I think a few changes might improve package stability a bit:
>
> 1. Add a nixpkgs config setting to throw an error on packages with no
>meta.maintainers
> 2. Work to reach a point where a significant subset of nixpkgs (say,
>release-small) is allowed on this list.
> 3. Remove maintainers after X weeks without reply on issues they're
>tagged in about packages they maintain
> 4. (Optional) Separate out maintainers by system
>
> Thoughts on these?
>
> ~Shea
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hardening flags enabled by default

[Thomas Hunger]

Thank you so much! I've been running a staging server on this branch for a
few weeks and all of the issues I had were addressed in your branch before
I had time to flag them.

This is really fantastic work not just for my servers but also for my
ability to argue that NixOS has a story for security.

Lastly I also think that it's an amazing testament to the leverage Nix
provides that a small group of dedicated people can harden so many packages
with a few months of work (not downplaying the work involved!).

~

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

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

Re: [Nix-dev] Add new binaryRunCheck phase to stdenv?

[Thomas Hunger]

Yea! I think another difference would be that installCheckPhase usually
comes from upstream, and binaryRunChecks would be nix-specific.

On 19 June 2016 at 12:32, zimbatm <zimb...@zimbatm.com> wrote:

> Hi,
>
> So a bit like the installCheckPhase but with more structure?
>
> On Sun, 19 Jun 2016, 12:10 Thomas Hunger, <tehun...@gmail.com> wrote:
>
>> Hi,
>>
>> One problem I encounter not very often, but often enough to be annoyed by
>> it is that binaries build successfully but don't actually run due to some
>> missing run time dependency ( template, LD_PRELOAD, a dependency that
>> should have been in propagatedBuildInputs, ..)
>>
>> We have a "Tested execution of all binary files" entry in our PR
>> templates - how about we formalize it with an optional extra build step in
>> [1]?
>>
>> It could look like this:
>>
>>   binaryRunChecks = [
>> { run = "bin/totem --help"; prefix = "Usage:\n  totem [OPTION…]"; }
>>   ];
>>
>>   binaryRunChecks = [
>> { run = "bin/ipython --help"; prefix = "=\n
>> IPython\n="; }
>> ...
>>   ];
>>
>> The idea is that checking a prefix of the output is almost always good
>> enough to know whether a program can be run.
>>
>> I think this is pretty easy technically but does require a full rebuild.
>>
>> What do you think?
>>
>> ~
>>
>> [1]
>>
>> https://github.com/NixOS/nixpkgs/blob/master/pkgs/stdenv/generic/setup.sh#L823
>>
>> ___
>> 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] Add new binaryRunCheck phase to stdenv?

[Thomas Hunger]

Hi,

One problem I encounter not very often, but often enough to be annoyed by
it is that binaries build successfully but don't actually run due to some
missing run time dependency ( template, LD_PRELOAD, a dependency that
should have been in propagatedBuildInputs, ..)

We have a "Tested execution of all binary files" entry in our PR templates
- how about we formalize it with an optional extra build step in [1]?

It could look like this:

  binaryRunChecks = [
{ run = "bin/totem --help"; prefix = "Usage:\n  totem [OPTION…]"; }
  ];

  binaryRunChecks = [
{ run = "bin/ipython --help"; prefix = "=\n
IPython\n="; }
...
  ];

The idea is that checking a prefix of the output is almost always good
enough to know whether a program can be run.

I think this is pretty easy technically but does require a full rebuild.

What do you think?

~

[1]
https://github.com/NixOS/nixpkgs/blob/master/pkgs/stdenv/generic/setup.sh#L823
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] haskell structure for all of nixpkgs

[Thomas Hunger]

> You are right, the „multiple releases“ approach clogs the repository. In
general it would be a lot more favourable if we didn’t have to check in
these thousands of package descriptions but could generate them from hackage

IMO an advantage of checking package metadata into git is that we notice
upstream changes. E.g. GitHub used to re-package their zips all the time
causing hash changes which we noticed.

In the case of GitHub this was annoying (they fixed it) but in the more
general case I find the additional hash check very useful because it's one
less thing I have to worry about.

Not sure how to fix the nixpkgs repository size though if we check in
hundreds of MB of package metadata.


On 27 April 2016 at 10:59, Profpatsch  wrote:

> On 16-04-25 03:15pm, Eric Merritt wrote:
> > I think these strongly win out, at at least for the Erlang/Beam world.
> The downside is that grepping the
> > nixpkgs repository (my default way to search for a package) doesn't work
> nearly as well.
>
> You are right, the „multiple releases“ approach clogs the repository.
> In general it would be a lot more favourable if we didn’t have to check
> in these thousands of package descriptions but could generate them
> from hackage (or stackage) description files (aka don’t check in generated
> files).
> Has the drawback, that it is not locally possible to see what’s available
> without a generation step first. Generating nixexprs and then using them
> is still an unsolved problem, since it puts realizations inside the
> evaluation
> phase, see https://github.com/NixOS/nix/issues/13 (notice the issue
> number).
>
> Apart from that the gist of the Haskell infrastructure is how it handles
> overriding, which is entirely unrelated to the grepping issue.
>
> > My suspicion is that, if you wanted to go this route generally, you
> would need to improve the tooling
> > around searching for packages/expressions.
>
> There’s already nix-repl. Improve that one step further and you can have
> dynamic exploration, maybe with a search and editor completion.
>
>
> --
> Proudly written in Mutt with Vim on NixOS.
> Q: Why is this email five sentences or less?
> A: http://five.sentenc.es
> May take up to five days to read your message. If it’s urgent, call me.
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> 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] Second London Nix meetup on 3rd of May 2016

[Thomas Hunger]

Hi,

Simone and I are organizing a second Nix meetup to celebrate the release of
16.03. You can sign up at [1]. We're looking for speakers that would be
interested in talking for 20-30 minutes, either this time or in future
meetups. We do have a backup-talk for this time though!

We're also trying a new format: a brief talk followed by a hands-on
workshop. If you have a package or module you'd like to update, fix or add
to Nix please bring your idea along and we'll split into groups to work on
that.

See you there!
~

[1]
https://skillsmatter.com/meetups/7926-london-nixos-user-group
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Question on package signing and security?

[Thomas Hunger]

The manual has some info:

https://nixos.org/nix/manual/#operation-generate-binary-cache-key

It's a fairly straight forward private / public signing scheme.

There's an example on how to verify integrity in the manual as well:

https://nixos.org/nix/manual/#examples-23

~

On 28 March 2016 at 13:17, Matthias Beyer  wrote:

> Hi,
>
> How is package signing this done by nix and how does it work for
> nixpkgs/nixos?
> I'm searching for resources on this because of my bachelors thesis and I'm
> not
> quite sure nix already does signing and the like.
>
> So all the "big" package managers (apt, yum, pacman,...) do some gpg foo
> to sign
> packages. How does this work in a nix context? Do we sign packages? Does
> nix
> verify signatures? Do we sign expressions?
>
> Is there any literature out there? I'm starting reading Eelcos papers now,
> maybe
> I can find something in there...
>
> (The context I'm asking this in is for traceability and auditability, my
> thesis
> focuses on Agent based intrusion detection systems and how they do software
> installations.)
>
> --
> Mit freundlichen Grüßen,
> Kind regards,
> Matthias Beyer
>
> Proudly sent with mutt.
> Happily signed with gnupg.
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] NixOS 16.03 channel available for testing

[Thomas Hunger]

Hm, those images don't boot. I think I picked up the wrong version of
nixpkgs from the environment despite following [1] pretty
meticulously. Apologies if you already tried them.


[1]
https://nixos.org/wiki/NixOS_on_Amazon_EC2

On 8 March 2016 at 18:37, Thomas Hunger <tehun...@gmail.com> wrote:
> I created some ec2 AMIs for testing:
>
> latest commit: 440e2a757a3e8b8e50e931e339c18c0f0ac54e9b
> channel: 16.03-beta
>
> ami-fdb50d8e in eu-west-1
> ami-23d6324c in eu-central-1
> ami-ca4144a0 in us-east-1
> ami-fd46359d in us-west-1
> ami-ab3ad5cb in us-west-2
> ami-4a438b29 in ap-southeast-1
> ami-64f5d407 in ap-southeast-2
>
> (Don't rely on those for production. I will delete them after the
> official images have been released.)
>
> On 7 March 2016 at 12:36, Domen Kožar <do...@dev.si> wrote:
>> Hi all,
>>
>> 16.03 release channel has been generated, so you're all welcome to test and
>> report any issues:
>>
>> $ nix-channel --add https://nixos.org/channels/nixos-16.03 nixos
>> $ nixos-rebuild switch --upgrade
>>
>> 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] NixOS 16.03 channel available for testing

[Thomas Hunger]

I created some ec2 AMIs for testing:

latest commit: 440e2a757a3e8b8e50e931e339c18c0f0ac54e9b
channel: 16.03-beta

ami-fdb50d8e in eu-west-1
ami-23d6324c in eu-central-1
ami-ca4144a0 in us-east-1
ami-fd46359d in us-west-1
ami-ab3ad5cb in us-west-2
ami-4a438b29 in ap-southeast-1
ami-64f5d407 in ap-southeast-2

(Don't rely on those for production. I will delete them after the
official images have been released.)

On 7 March 2016 at 12:36, Domen Kožar  wrote:
> Hi all,
>
> 16.03 release channel has been generated, so you're all welcome to test and
> report any issues:
>
> $ nix-channel --add https://nixos.org/channels/nixos-16.03 nixos
> $ nixos-rebuild switch --upgrade
>
> 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] yet another npm2nix reengineering attempt

[Thomas Hunger]

Thanks Sander for trying again!

As a data point: We've had too many issues with integrating NPM and nix
more tightly so we've given up and run [1] in combination with shrink-wrap.
I think there may be value in pushing the "resolved" fields from the
npm-shrinkwrap.json file into nix but trying to reproduce the ever-changing
behaviour of the NPM resolver didn't seem like a good time investment to me.

[1]
{ pkgs, stdenv, git, nodejs-5_x }:
#  Notes:
#  * This still caches in HOME, can't find out how to disable so we
#store in a temporary directory which is cleaned up after the build.
#  * This connects NPM to the internet which is sad but
#packaging NPM for nix is even sadder :(
stdenv.mkDerivation {
  name = "proppyweb-frontend-node_modules";
  src = builtins.filterSource (path: type: baseNameOf path ==
"package.json") ../frontend;
  phases = "unpackPhase installPhase";
  buildInputs = [ nodejs-5_x git ];
  installPhase = ''
mkdir ./npm-home
mkdir -p $out
export HOME=$(readlink -f ./npm-home)  # For .npm/cache. Will be
discarded.
cp ./package.json $out/
cd $out
npm install
  '';
}


On 2 March 2016 at 01:11, Colin Putney  wrote:

>
>
> On Tue, Mar 1, 2016 at 6:42 AM, Sander van der Burg  > wrote:
>
>
>> So as you may see: it is all quite annoying and painful. :(
>>
>
> I'm starting to think that it's pointless to try to make it all work
> automatically. At some point it's so compatible with npm that it replicates
> all of npm's quirks and bugs and you might as well use npm directly,
> because you're not enjoying any of the advantages of nix anymore.
>
> What I've been trying to do is import dependency information from npm, but
> make it easier to customize so that you can work around the quirks of
> specific npm packages with less pain. I'm using the npm2nix in nixpkgs, but
> ignoring the default.nix it generates, and building custom derivations from
> the registry. It's still pretty painful when the generated registry doesn't
> work, but I have managed to get things to work the nix way.
>
> Colin
>
>
>
> ___
> 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] Fwd: Wiki is dead

[Thomas Hunger]

Thanks Rok!

I've given this a try [1] for the zero-build-failures entry and my
experience so far was:

1/ How do I actually build docbook?
  => copy doc/default.nix and adjust
2/ nix-build is rebuilding GHC 7.8 and 7.10 (for pandoc I think).
  => Wait 2h.
3/ GHC build fails [2]
4/ We're not using standard docbook but preprocess with XSLT so references
on the internet don't actually work.

While I think the docbook format itself is fine for describing the content
the process isn't. IMO it must be reasonably simple to contribute or fix an
entry.

Would you be opposed to a directory full of markdown files for now? Those
can be pandoc-ed into almost anything later without too much formatting
loss IIUC?

~

[1]
https://github.com/teh/nixpkgs/commit/a29e27820f3ea1d101c544241a80354237b39b89

[2]
/nix/store/9vp1v2s43s92z05jm0ywnqxiq16rh5q9-ghc-7.10.3/lib/ghc-7.10.3/bin/ghc-pkg:
error while loading shared libraries:
libHSterminfo-0.4.0.1-6iVf4EBnOgfIaaOCLRs8jl-ghc7.10.3.so: cannot open
shared object file: No such file or directory


On 21 February 2016 at 21:27, Rok Garbas  wrote:

> Hi all,
>
> As some already seen I create tickets for each page in wiki (more or
> less) each wiki page.
> All are assigned to "Move the wiki!"[1] milestone, so we can track the
> progress.
>
> Because of the quantity of content that needs to be migrated, and most
> importantly reviewed, we must move with small steps since one-evening
> migration away from current wiki is not possible.
>
> Next step is triaging and getting everybody involved to produce best
> documentation we can. I'm hoping that migration of the wiki will be
> done in a month (or sooner). Current status is we have 180 open
> tickets, I will keep the mailing list updated on the status of the
> migration on bi-weekly basis.
>
> Few things that some already asked me:
>  - we are not moving away from docbook format at this stage (we need
> to fix one thing at the time)
>  - contributions via PR's is just another form of a wiki, which fits
> into our current workflow and removes
>  - there will be more documents then just manual (tutorial, cookbooks,
> getting started, ...) but conversation about this started some in
> another tread so lets continue conversation there.
>
> Important to know is that nothing will happen over night, but we must
> keep improving our documentation. I have no doubt that in one year it
> will be much easier to learn/use/play with Nix/NixOS.
>
>
> [1] https://github.com/NixOS/nixpkgs/milestones/Move%20the%20wiki!
>
> --
> Rok Garbas - https://garbas.si
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Fwd: Wiki is dead

[Thomas Hunger]

I'm tool agnostic but +1 on having a cookbook in git for the
review-workflow (avoids wiki spam). I have a number of snippets (how to
remove gc roots, haskell profiling, how to use ihaskell properly, many
more) but no good place to put them.

I've started a git-book thing [1] a while back to collect these but didn't
get very far. I'd much rather contribute to a common, low-barrier-to-entry
repository than rolling my own.

In my experience just providing the structure will eventually attract
content because adding a small snippet is the path of least resistance for
each individual contributor. Maybe we could add a banner "This is how you
add a snippet" and buttons "File a bug that this is wrong / outdated" to
each snippet?

Rok - I know it's not free software but maybe it's worth setting up a
google docs spreadsheet for coordinating the migration once we've settled
on a tool? I will contribute.

~

[1]
https://github.com/WeAreWizards/nixbyexample

On 20 February 2016 at 12:06, Freddy Rietdijk 
wrote:

> I agree with Vladimir that we already have the infrastructure, the Nixpkgs
> repository.
>
> What is needed is a clearer way where to put certain documentation and a
> lower barrier for contributing. In `Redesign of documentation` I came with
> a proposal of how to structure the documentation. A wiki has a low barrier
> for contributing, however, it also has many disadvantages, which you would
> not have if we use, say, the Nixpkgs repository.
>
> A big barrier, in my opinion and I'm pretty sure also in that of others,
> is the current format of the Nixpkgs manual. I can understand why docbook
> is used, and I think it should be used for say the Nix manual, but for a
> User's Guide to which many of us would/should contribute, the barrier is
> just too high.
>
> On the branch https://github.com/FRidh/nixpkgs/tree/usersguide I
> implemented the proposed redesign.
> The documentation is split into two documents, the User's Guide, and the
> Contributor's Guide. The User's Guide is divided into three parts:
>
>- Introduction
>- Reference
>- Cookbook
>
> There have been several proposals already for tools/implementations
> (Matthias' Jekyll implementation, Domens Sphinx docs) . Here I chose to go
> also for the Sphinx documentation generator. It allows you to write
> RestructuredText. With a small plugin, which I enabled, you can also
> include CommonMark/Markdown. Nix highlighting is supported.
> The result can be found at http://nixpkgs.readthedocs.org/en/latest/ .
> It's mostly empty still.
>
> Now this is only a proposal, and I'm open to other ways. But I really
> think we should do something about the current state of the docs, in both
> content and lowering the barrier. ReStructuredText/Markdown obviously
> doesn't have as much possibilities as Docbook but what matters eventually
> is whether it is enough, and I think it will be, at least for now.
>
>
> On Sat, Feb 20, 2016 at 12:30 PM, Vladimír Čunát  wrote:
>
>> On 02/20/2016 12:52 AM, zimbatm wrote:
>> > It's a great staging area for content where people can edit without
>> > asking for permission. [...]
>>
>> What are the advantages in comparison to standard pull requests with
>> discussion underneath? We already have lots of infrastructure advantages
>> in there, such as merging changes at once with documentation for them,
>> auto-mention bot, etc.
>>
>>
>>
>> ___
>> 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] Installing CA certificates

[Thomas Hunger]

Hi Adam,

Can you make the TLS call work with a command line tool like openssl? I'm
not 100% sure but I think that Chrome might use a different set of trusted
certs (based on the Mozilla ones) [1].

~

[1]
https://www.chromium.org/Home/chromium-security/root-ca-policy

On 18 February 2016 at 13:53, Adam Russell  wrote:

> Hello Nix-Dev,
>
> I'm trying to understand how to install CA certificates in NixOS.
>
> If I visit my work's webmail in Chromium, I get an indicator that my
> connection is not private. Clicking the padlock icon in the address bar,
> then the "Certificate information" link in the Connection tab, going to the
> "Details" tab, and clicking "Export" allows me to download a certificate.
>
> The text in this export is what I am supposed to put in the array in
> `security.pki.certificates` option of `/etc/nixos/configuration.nix`,
> correct? Am I missing something?
>
> The documentation I am using is at:
> https://github.com/NixOS/nixpkgs/blob/6e6a96d42cf56cfcd042bbeab89e37f442f0cfcc/nixos/modules/security/ca.nix#L39-L45
>
> Does the text above the equal signs have any significance ("NixOS.org" in
> the example), or is it just a comment?
>
> Thanks,
> -Adam
>
> ___
> 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] problem with automounted ntfs partitions

[Thomas Hunger]

Hi Mate,

Can you try

nix-env -iA nixos.ntfs3g

instead?

On 16 February 2016 at 07:10, Máté Kovács  wrote:

> Hi all,
>
> The problem I'm trying to solve is that automounted ntfs partitions are
> read-only.
>
> For example, `mount | column -t` lists
> /dev/sdb1   on  /run/media/mate/adata   type  ntfs
>  
> (ro,nosuid,nodev,relatime,uid=1000,gid=100,fmask=0177,dmask=077,nls=utf8,errors=continue,mft_zone_multiplier=1,uhelper=udisks2)
> after I connect my external HDD.
>
> I read somewhere that the problem is likely a lack of ntfs-3g, so I'm
> trying to install that, unfortunately without much success.
>
> What's strange is that `nix-env -qaP | grep -i ntfs` lists
> nixos.ntfs3g
>  ntfs-3g-2015.3.14
> yet `nix-env -i ntfs3g` insists on showing
> error: selector ‘ntfs3g’ matches no derivations
>
> What am I doing wrong?
> How do I install ntfs-3g? Is that even what I need to do here?
>
> Thanks,
> Mate
>
>
>
> ___
> 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 Hunger]

Would anyone be interested in collecting some data on how people are using
nix? I had a look though my bash history and I can see myself doing the
following a lot (using ipython as an example).

man nix-store
nix-shell -p pythonPackages.ipython ...
nix-env -qaP | grep -i ipython | grep noteb
[reinstalling to update]

The most common mistake I make is:

nix-env -iA pythonPackages.ipython
error: attribute ‘pythonPackages’ in selection path
‘pythonPackages.ipython’ not found
(should be nix-env -iA nixpkgs.pythonPackages.ipython)


Based on my one sample point I'd make the following decisions:

* "nixpkgs" is implied when installing
* search is AND-ed like in "apt-cache search ...", i.e. "nix search virtual
box" only shows packages that contain both virtual and box
* install is declarative by default


I think a questionnaire would have to be semi-qualitative with questions
like:
1) Which documentation do you check most often?
2) What's your most common mistake?
3) ... other ideas?

~



On 24 January 2016 at 10:09, Thomas Strobel <
4ZKTUB6TEP74PYJOPWIR013S2AV29YUBW5F9ZH2F4D5UMJUJ6S@hash.domains> wrote:

> 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 <
> 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 <
> 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] Fundraiser?

[Thomas Hunger]

There's the foundation https://nixos.org/nixos/foundation.html which would
be a great structure to collect and direct money.

Eelco - I'm not sure where to look so I couldn't find anything about the
foundation's activity. Do you keep meeting notes somewhere online?

best,
Tom



On 7 December 2015 at 15:10, Bjørn Forsman  wrote:

> Hi all,
>
> I've been a Nix/NixOS user for a few years now. While some parts of
> NixOS are moving forward rather quickly (awesome!), some of the Nix
> tooling is improving painfully slow (IMHO). I was wondering if any
> core devs have considered starting a fundraiser to possibly work
> full-time on some issues?
>
> Some things I'd really like to see happen (and support financially):
>
> * Better UI. I think there are many GitHub issues about this already,
> but I really like what's being pointed out here:
> https://github.com/NixOS/nix/issues/684#issuecomment-154502504.
>
> * Better support for Nix as a 3rd party package solution. Be able to
> build a distro agnostic package on a Nix system and deploy it
> (trivially) to other systems (that may not even have Nix).
>
> Best regards,
> Bjørn Forsman
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Why does my system rebuild rustc and cargo?

[Thomas Hunger]

Hi Matthias,

Can you expand a bit on what "all the time" means? After a nix-channel
--update? When you install it with nix-env? Maybe when you reference rustc
in a nix-shell?

best,
Tom

On 20 November 2015 at 15:01, Matthias Beyer  wrote:

> Hi,
>
> my system wants to rebuild rustc and cargo all the time, I am on
> unstable with one patch added to rebuild neovim with the appropriate
> libvterm (261791992c05f6b98175558a71f0c4a1a01c04eb).
>
> But that patch is not related to rustc or cargo at all, so... I don't
> know what I'm doing wrong.
>
> --
> Mit freundlichen Grüßen,
> Kind regards,
> Matthias Beyer
>
> Proudly sent with mutt.
> Happily signed with gnupg.
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] nixos inside lxc container on non-NixOS host

[Thomas Hunger]

Not quite what you said but this works for me for rkt [1]. For using nspawn
I think you'd need the full /nix/store on the non-nix system.

~

[1]
https://gist.github.com/teh/f3d8532bfef8fb25fe1f

On 24 October 2015 at 18:52, Tomas Hlavaty  wrote:

> Actually, description of any way to run NixOS inside a container on
> non-NixOS host would be great, e.g. using systemd-nspawn instead of
> lxc.
> ___
> 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] Guarantee Consistent Builds and Obsolete overrideScope

[Thomas Hunger]

I got confused by the reference to "Use Function Application To Escape
Override Hell"

It's [1] which got stuck in my spam folder.

[1]
http://lists.science.uu.nl/pipermail/nix-dev/2015-October/018380.html

On 15 October 2015 at 19:52, Peter Simons  wrote:

> The Problem
> ---
>
> A lot of effort goes into curated package sets like Stackage, but even
> so we can compile only ~50% of the packages available from Hackage. It
> appears to be the nature of the game: when lens 2.x comes out with a
> fundamentally new API, then some packages will adopt the new version and
> others won't. A consistent package set must chose on which side of the
> fence it wants to live. Either those packages that depend on lens 1.x
> compile or those that depend on 2.x compile --- but not both.
>
> Now, Nix is not limited to one particular version of lens --- we can
> have both versions available at the same time. But it's difficult to
> take advantage of that feature, because once you start mixing lens 1.x
> and 2.x in the same package set, you risk inconsistent builds, i.e.
> builds where some part of the dependency tree refers to lens 1.x and
> another part refers to lens 2.x. It's a bad idea to try and link those
> two trees together into one executable; we are fortunate that Cabal
> detects this error during the configure phase and aborts the build!
>
> We need a mechanism that can mix multiple package versions within a
> package set, but that also guarantees consistency for every single
> build. We hoped overrideScope would be that mechanism, but somehow it
> hasn't quite lived up to the promise, mostly because it is hard to
> understand.
>
> The Situation Today
> ---
>
> Consider an executable package foobar that depends on the libraries foo
> and bar, each of which depends on lens. The corresponding definitions in
> hackage-packages.nix --- stripped down to the relevant bits --- look as
> follows:
>
> "lens" = ... lens version 1.x ...;
> "lens_2_0" = ... lens version 2.x ...;
>
> "foo" = callPackage
> ({ mkDerivation, lens }:
> mkDerivation {
>   pname = "foo";
>   libraryHaskellDepends = [lens];
> }) {};
>
> "bar" = callPackage
> ({ mkDerivation, lens }:
> mkDerivation {
>   pname = "bar";
>   libraryHaskellDepends = [lens];
> }) {};
>
> "foobar" = callPackage
> ({ mkDerivation, lens }:
> mkDerivation {
>   pname = "foobar"; [...]
>   libraryHaskellDepends = [foo bar];
> }) {};
>
> Let's assume that foo won't compile in that setup because it requires
> lens version 2.x. We can remedy that by adding an override to
> configuration-common.nix that says:
>
> foo = super.foo.override { lens = self.lens_2_0; };
>
> That change fixes the build of foo, but foobar remains broken, because
> now it pulls in both lens 1.x and 2.x simultaneously through its
> dependencies. If bar works only with lens 1.x, then there is nothing we
> can do: the version constraints conflict and we cannot compile foobar.
> If bar *does* support lens 2.x, however, then we can just switch it to
> the newer version with:
>
> bar = super.bar.override { lens = self.lens_2_0; };
>
> Now we can compile foobar! Unfortunately, that change may break other
> builds. There is a reason why lens 1.x is our default choice. If any
> other package depends on bar as well as lens 1.x (directly or
> indirectly), then it will no longer compile after that change.
>
> We can avoid that side-effect by localizing the override to foobar:
>
> foobar = super.foobar.override {
>   bar = self.bar.override { lens = self.lens_2_0; };
> };
>
> That approach allows us to compile foobar, while still leaving the
> default version of bar at lens 1.x, like most of our packages require.
> Overriding build inputs this way works fine, and we have used this
> technique for many years to fix builds that require non-default versions
> to compile. The downside of these nested overrides is that the tend to
> become freaky complicated if a package needs overriding that is
> sufficiently deep in the dependency tree. The GHC 7.8.4 package set, for
> example, needed many such overrides because its default version of mtl
> was stuck at version 2.1.x all the while large parts of Hackage had
> moved on to mtl 2.2.x. Since mtl is a rather fundamental package, we had
> nested overrides 3-4 levels deep that were highly repetitious, too. It
> was a mess.
>
> Haskell NG improved on that situation by adding overrideScope. That
> function changes the package set ("scope") in which Nix evaluates a
> build expression. The override
>
> foobar = super.foobar.overrideScope (self: super: { lens =
> self.lens_2_0; });
>
> creates a new temporary package set, replaces lens with lens_2_0 in it,
> and then evaluates foobar. The callPackage function picks up the
> re-written lens attribute, which means that there's no 

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

[Thomas Hunger]

Do you need toPath?

lib.readFile "./foo/${name}/bar"

seems to work for me.

On 16 October 2015 at 11:10, Bas van Dijk  wrote:

> Hello,
>
> In a Nix expression I would like to read a file where the file path is
> based on a variable. So I would like to do something like this:
>
>   with builtins;
>   readFile (toPath ("./foo/" + name + "/bar"))
>
> Unfortunately this doesn't work since toPath expects a string which
> represents an absolute path.
>
> Is there any other way to do this?
>
> Cheers,
>
> Bas
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Providing Debian, Arch etc. packages counterproductive?

[Thomas Hunger]

Hi Alaistair,

Thanks for doing that change! We've tried your package on a fresh install
and it doesn't add the channel or
`$HOME/.nix-profile/etc/profile.d/nix.sh`. After we've added those manually
we ran into the locale bug in [1]. Are you getting that bug as well? And if
so, did you manage to work around that?

~

[1]
https://github.com/NixOS/nix/issues/599

On 23 September 2015 at 10:15, Alastair Pharo <asp...@gmail.com> wrote:

> Hi Thomas,
>
> I’m the author of this script by the way. I didn’t say that before.
>
> The bulk of the work that it does is in the install file which is not easy
> to view from the AUR website, so I’m not sure if you saw it. Here
> <https://aur.archlinux.org/cgit/aur.git/tree/nix-multiuser.install?h=nix-multiuser>
> is a link to it in the git repo viewer. It’s still a very simple script;
> it’s mostly just doing what is described on the wiki for Debian:
>
>1. create users
>2. make a skeleton /nix folder
>3. display a message telling the user how to enable the daemon.
>
> It wasn’t doing (2) properly until a few minutes ago; previously it was
> failing if /nix/store didn’t exist. As you will see, the installer is
> basically just a shell script that gets run as root when the package is
> installed, so if there is a more official version of this process, it would
> probably be quite easy to include it there.
>
> Cheers,
>
> Alastair
>
> On 23 September 2015 18:02, Thomas Hunger wrote:
>
> Alastair,
>
> Looking at [1] it looks like the only thing that package does is setting an
> env variable - how did you get your /nix tree started? Maybe we could
> extend nix-multiuser to execute your /nix steps on start?
>
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Providing Debian, Arch etc. packages counterproductive?

[Thomas Hunger]

Alastair,

Looking at [1] it looks like the only thing that package does is setting an
env variable - how did you get your /nix tree started? Maybe we could
extend nix-multiuser to execute your /nix steps on start?

~

[1]
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=nix-multiuser

On 23 September 2015 at 01:10, Alastair Pharo  wrote:

> Just thought I’d point out that on Arch Linux we have the nix-multiuser
> package  that pretty
> much takes care of the multiuser setup.
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Providing Debian, Arch etc. packages counterproductive?

[Thomas Hunger]

The deb can be inspected with "dpkg -c". It contains all the nix-*
commands, man pages, some perl, headers and some basic nix library
functions. What's missing is a postinst script that setting up the things
according to [1] (probably needs updating).

On reflection platform specific packages would be useful to work around
issues like [2] which one of my friends hit today. And as Vladimir says for
the multi-user setup with the daemon. I'm not sure I have the energy to go
around and fix all the packages but maybe debian and arch would be a good
start.

~

[1]
https://nixos.org/wiki/Installing_Nix_on_Debian

[2]
https://github.com/NixOS/nix/issues/599


On 22 September 2015 at 22:31, Vladimír Čunát  wrote:

> On 09/22/2015 10:03 PM, zimbatm wrote:
> > On the other end, it would be nice if installing nix was just a
> > matter of running `curl -L
> > https://nixos.org/nix-current/$(uname)-$(arch).tar.bz2 | tar xa -C
> > /nix && ln -s /nix/bin/nix-env /usr/local/bin` and then setup the
> > profile.
>
> I think the nix daemon complicates things a bit, as you need to plug it
> into the host OS services.
>
> Vladimir
>
>
> ___
> 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] Providing Debian, Arch etc. packages counterproductive?

[Thomas Hunger]

Hi,

Slight ramble ahead.

I've managed to get several people to try Nix after constantly raving about
it and all but one had a bad experience. The reason AFAICT is that they
first check for nix in their default package tool (apt-get, pacman, ...).
These packages install nix-*  binaries but they don't help with the single
or multi-user /nix setup. So the first thing they see is "error: creating
directory ‘/nix’: Permission denied".

I can think of two solutions 1) make the packages set up nix correctly so
nix-env is usable out of the box and 2) Remove all custom packages and tell
people to use the installer script.

I know 2 is quite radical but to me it seems preferable to leaving people
who aren't necessarily great unix admins googling for an error with no
solution on the first results page.

~


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

Re: [Nix-dev] nixpkgs haskell system got into inconsistent state broken

[Thomas Hunger]

It's possible you hit the infamous non-deterministic package hash
generation [1] for which Peter collected data recently [2]. AFAICT the only
solution is to remove and rebuild or refetch all haskell packages.

This bug has high priority for GHC 8 so I hope it'll eventually go away.



[1]
https://ghc.haskell.org/trac/ghc/ticket/4012

[2]
http://lists.science.uu.nl/pipermail/nix-dev/2015-June/017405.html

On 21 September 2015 at 10:41, Miguel Negrão <
miguel.negrao-li...@friendlyvirus.org> wrote:

> Hi
>
> This week I encountered a situation where when I tried to build one of my
> own packages which was working fine before, it would fail claiming that
> every single Haskell package it needed was missing:
>
> http://pastebin.com/agqw9dn2
> http://pastebin.com/Vyqc5U3e
>
> I had not changed anything or installed anything in nix for quite a while,
> the only thing I can think that could have caused this was that my
> filesystem had died (btrfs) and I had to restore from backup the whole of
> /.
> I have not used binary cache to build any of the haskell packages, they
> were
> built from source.
>
> Is it possible that the restore of / via rsync could have caused this ?
>
> In the meantime I had did a rm -r /nix and installed everything again and
> my
> system is working again, exactly as before this issue (I had everything
> specified in my config.nix), which is a testament to how easy it is to
> rebuild a system with nix if you have a declarative description of your
> packages.
>
> Thanks,
> Miguel
>
> ___
> 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] Where would I put the bootstrapping guide?

[Thomas Hunger]

Hi Jookia,

Do you have your guide somewhere public? Maybe on github, pastebin, a blog
or so?

It'd be a shame to lose this information!

~

On 29 April 2015 at 12:09, Joachim Schiele j...@lastlog.de wrote:

 On 29.04.2015 04:25, Jookia wrote:
  Hello!
 
  Recently I've bootstrapped NixOS on to a new ARM platform from an
  existing Debian install on the same platform. I figured this is useful
  knowledge so I've written up some documentation which I'm in the process
  of convert to Docbook. It's kind of a tutorial but expects users to
  modify commands.

 oh nice, which platform?

  The guide includes how to install Nix, the NixOS installer and finally
  NixOS on a system such as Debian. It's three sections long and intended
  for development and porting NixOS to new platforms.
 
  I originally wrote it for inclusion in the Wiki but I'm barred from it
  as I use Tor, so I'm beginning to wonder if there's a place for it in
  the official documentation around the installation section. The
  obviously place would be in the installer section but it focuses on
  using a CD.
 
  Any suggestions? I'd really love to make it easier to install NixOS when
  there isn't already an installer image.

 you could also write docbook syntax offline and then upload your stuff
 using a git-pull request. a good place would probably be the nixos
 documentation.


 ___
 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] Switch to GHC 7.10.1 is imminent

[Thomas Hunger]

+1 as well. I repeatedly ran into the issue where GHC package hashes
changed which IIUC is fixed in 7.10. Can't wait to start testing.

On 18 April 2015 at 19:11, John Wiegley jo...@newartisans.com wrote:

  Aycan iRiCAN iricanay...@gmail.com writes:

  I am -1 on this. Since some of the packages which I depend doesn't
 compile
  with ghc 7.10 yet, they need upstream fixes (hans, http-streams,
  rank1dynamic, jmacro and a few more). Could you please suspend the merge
 for
  one more week? OTOH, I can still use haskell-ng.packages.ghc784 if nobody
  supports my idea.

 Since 'master' is the branch for development, I'm +1 on this even though it
 will be disruptive for a while, because it's not going into any release
 channels.  I realize some of us actually use 'master' as our distribution
 channel, but the Nix project shouldn't be impeded by that use.

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

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

Re: [Nix-dev] Use GHC 7.10.1 as default Haskell compiler in nixpkgs

[Thomas Hunger]

I think

https://github.com/fpco/stackage/issues/378#issuecomment-82971435

is the bug to follow. But stackage is only a relatively small subset of
hackage so I don't know how bad the impact of 7.10 on full hackage is.


On 27 March 2015 at 17:19, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk
wrote:

 On 03/27/2015 05:12 PM, Michael Alan Dorman wrote:
  My understanding is that there may be a number of pkgs that fail to
  build, for admittedly minor reasons. This is from the Stackage
  maintainer, who presumably has a high level perspective on this.
 
  Mike
 

 Where are you seeing this? The only info I can find on this is from the
 RC stages.


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

Re: [Nix-dev] Question about organising dependencies not in core nixpkgs?

[Thomas Hunger]

Hi,

Thanks. That was a lot to read and understand. I think my favourite
solution would be Shea's recursive-derivations branch.

Without that we're trying two different ways for keeping our dependencies
in the external repository:

1) Create a build.nix and use a custom builder instead of e.g.
buildPythonPackage.
2) Have a custom import builder which unpacks a source and throws away
everything other than .nix files. We can then import from that custom
builder (basically [1]).

Not sure which one we'll keep long term.

~

[1]
https://gist.github.com/teh/ad22d636e7cb3c4d89ee


On 18 March 2015 at 16:11, Shea Levy s...@shealevy.com wrote:

 See https://github.com/NixOS/nix/pull/213. The comment chain is long, but
 it’s important to read up to
 https://github.com/NixOS/nix/pull/213#issuecomment-43674771.

 ~Shea

 On Mar 18, 2015, at 12:02 PM, Thomas Hunger tehun...@gmail.com wrote:

 Apologies, here's the rest of my email:

 .. but I could not find anything that looks like evaluate at build time
 - is that code somewhere public?

 Thanks,
 Tom

 [1]
 https://github.com/shlevy/nix


 On 18 March 2015 at 16:01, Thomas Hunger tehun...@gmail.com wrote:

 Hi Shea,

 I checked your github version of nix [1]


 [1]


 On 18 March 2015 at 14:39, Shea Levy s...@shealevy.com wrote:

 You can already do this. “import foo” will build any derivations that
 “foo” depends on at evaluation time.

 Note though that really “build at evaluation time” is for several
 reasons inferior to “evaluate at build time”, i.e. recursive nix. I have an
 implementation for that but it doesn’t look like it will be accepted.

 ~Shea

 On Mar 18, 2015, at 8:36 AM, Kirill Elagin kirela...@gmail.com wrote:

 I’d say there is a more general problem.

 Imagine, that one day [in a far far away future] people start shipping
 derivations in `default.nix` in their sources (I guess people who develop
 on NixOS/with nixpkgs already do this as they have the file for their build
 environment anyway, so why not commit it). And then we have two copies of
 derivations: in the source repository and in `nixpkgs`.

 So it really looks like having something like `fetchDerivation(…url…)`
 would be handy. This function should fetch the source, unpack it, extract
 `default.nix` and use it as derivation to build the already fetched source.
 This way the `nixpkgs` repository itself is not required for packages that
 have this kind of information shipped and other projects can depend
 directly on the urls of repos. Then nixpkgs could be thought as a database
 of “well-known” packages with their urls.

 On Wed, Mar 18, 2015 at 2:53 PM Luca Bruno lethalma...@gmail.com
 wrote:

 On 18/03/2015 12:37, Thomas Hunger wrote:
  Thanks.
 
  That would require having the shell.nix library locally already
  AFAICT. To rephrase slightly. Ideally I'd like to be able to do:
 
  myLibrary = fetchurl { ... };
  extraDepends = import ${myLibrary}/depends.nix;
  buildDepends = [ ... ] ++ extraDepends;
 
  Does that make sense?
 I understand that, but I think the best fit of nix usage is having all
 the nix expressions in the same repository, instead of spreading nix
 files on every repository. That is, what's nixpkgs is doing.

 So I would create a repo of all nix files, which fetch sources from your
 other repos.
 ___
 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] Question about organising dependencies not in core nixpkgs?

[Thomas Hunger]

Hi,

I usually include a shell.nix file in my libraries for development. If I
have a dependency not in core nixpkgs then I add a local mkDerivation using
let pkg = ... in {} to shell.nix (e.g. [1]).

If I now want to use my library in another context, say nixops, I have to
duplicate the shell.nix content because I cannot import from a project I'm
depending on.

I considered having a separate repository of nix expressions that is used
for shell.nix as well as nixops but that makes it hard to release a
standalone libraries on github.

Is this a problem other people experience? If so: how do you solve this?

Thanks  best,
Tom


[1]
let
  flask-oidc = pythonPackages.buildPythonPackage rec {
name = flask-oidc-0.1.2;
 [...]
   };
in
buildPythonPackage { ... }
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Question about organising dependencies not in core nixpkgs?

[Thomas Hunger]

Thanks.

That would require having the shell.nix library locally already AFAICT. To
rephrase slightly. Ideally I'd like to be able to do:

myLibrary = fetchurl { ... };
extraDepends = import ${myLibrary}/depends.nix;
buildDepends = [ ... ] ++ extraDepends;

Does that make sense?

~

On 18 March 2015 at 10:31, Luca Bruno lethalma...@gmail.com wrote:

 On 18/03/2015 11:26, Thomas Hunger wrote:
  Hi,
 
  I usually include a shell.nix file in my libraries for development. If
  I have a dependency not in core nixpkgs then I add a local
  mkDerivation using let pkg = ... in {} to shell.nix (e.g. [1]).
 
  If I now want to use my library in another context, say nixops, I have
  to duplicate the shell.nix content because I cannot import from a
  project I'm depending on.
 
  I considered having a separate repository of nix expressions that is
  used for shell.nix as well as nixops but that makes it hard to release
  a standalone libraries on github.
 Then make nixops import stuff from your shell.nix ?
 ___
 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] Question about organising dependencies not in core nixpkgs?

[Thomas Hunger]

Hi Shea,

I checked your github version of nix [1]


[1]


On 18 March 2015 at 14:39, Shea Levy s...@shealevy.com wrote:

 You can already do this. “import foo” will build any derivations that
 “foo” depends on at evaluation time.

 Note though that really “build at evaluation time” is for several reasons
 inferior to “evaluate at build time”, i.e. recursive nix. I have an
 implementation for that but it doesn’t look like it will be accepted.

 ~Shea

 On Mar 18, 2015, at 8:36 AM, Kirill Elagin kirela...@gmail.com wrote:

 I’d say there is a more general problem.

 Imagine, that one day [in a far far away future] people start shipping
 derivations in `default.nix` in their sources (I guess people who develop
 on NixOS/with nixpkgs already do this as they have the file for their build
 environment anyway, so why not commit it). And then we have two copies of
 derivations: in the source repository and in `nixpkgs`.

 So it really looks like having something like `fetchDerivation(…url…)`
 would be handy. This function should fetch the source, unpack it, extract
 `default.nix` and use it as derivation to build the already fetched source.
 This way the `nixpkgs` repository itself is not required for packages that
 have this kind of information shipped and other projects can depend
 directly on the urls of repos. Then nixpkgs could be thought as a database
 of “well-known” packages with their urls.

 On Wed, Mar 18, 2015 at 2:53 PM Luca Bruno lethalma...@gmail.com wrote:

 On 18/03/2015 12:37, Thomas Hunger wrote:
  Thanks.
 
  That would require having the shell.nix library locally already
  AFAICT. To rephrase slightly. Ideally I'd like to be able to do:
 
  myLibrary = fetchurl { ... };
  extraDepends = import ${myLibrary}/depends.nix;
  buildDepends = [ ... ] ++ extraDepends;
 
  Does that make sense?
 I understand that, but I think the best fit of nix usage is having all
 the nix expressions in the same repository, instead of spreading nix
 files on every repository. That is, what's nixpkgs is doing.

 So I would create a repo of all nix files, which fetch sources from your
 other repos.
 ___
 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] Question about organising dependencies not in core nixpkgs?

[Thomas Hunger]

Apologies, here's the rest of my email:

.. but I could not find anything that looks like evaluate at build time -
is that code somewhere public?

Thanks,
Tom

[1]
https://github.com/shlevy/nix


On 18 March 2015 at 16:01, Thomas Hunger tehun...@gmail.com wrote:

 Hi Shea,

 I checked your github version of nix [1]


 [1]


 On 18 March 2015 at 14:39, Shea Levy s...@shealevy.com wrote:

 You can already do this. “import foo” will build any derivations that
 “foo” depends on at evaluation time.

 Note though that really “build at evaluation time” is for several reasons
 inferior to “evaluate at build time”, i.e. recursive nix. I have an
 implementation for that but it doesn’t look like it will be accepted.

 ~Shea

 On Mar 18, 2015, at 8:36 AM, Kirill Elagin kirela...@gmail.com wrote:

 I’d say there is a more general problem.

 Imagine, that one day [in a far far away future] people start shipping
 derivations in `default.nix` in their sources (I guess people who develop
 on NixOS/with nixpkgs already do this as they have the file for their build
 environment anyway, so why not commit it). And then we have two copies of
 derivations: in the source repository and in `nixpkgs`.

 So it really looks like having something like `fetchDerivation(…url…)`
 would be handy. This function should fetch the source, unpack it, extract
 `default.nix` and use it as derivation to build the already fetched source.
 This way the `nixpkgs` repository itself is not required for packages that
 have this kind of information shipped and other projects can depend
 directly on the urls of repos. Then nixpkgs could be thought as a database
 of “well-known” packages with their urls.

 On Wed, Mar 18, 2015 at 2:53 PM Luca Bruno lethalma...@gmail.com wrote:

 On 18/03/2015 12:37, Thomas Hunger wrote:
  Thanks.
 
  That would require having the shell.nix library locally already
  AFAICT. To rephrase slightly. Ideally I'd like to be able to do:
 
  myLibrary = fetchurl { ... };
  extraDepends = import ${myLibrary}/depends.nix;
  buildDepends = [ ... ] ++ extraDepends;
 
  Does that make sense?
 I understand that, but I think the best fit of nix usage is having all
 the nix expressions in the same repository, instead of spreading nix
 files on every repository. That is, what's nixpkgs is doing.

 So I would create a repo of all nix files, which fetch sources from your
 other repos.
 ___
 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] State database in nixops

[Thomas Hunger]

 Could you expand on this a bit? I've been using nixops for a while, but
 only recently set up a Hydra server to run tests automatically. I'm now
 considering doing automated deployments out of hydra, but not quite sure
 how that should work. It would be simple to have a hydra job that runs
 nixops deploy but having a build with external side-effects like that
 seems problematic.


We're running Jenkins for historical reasons. Jenkins allows executing
arbitrary shell scripts after a successful build / test. We run the tests
on Jenkins in the same nix-shell environment that we're using for
development.
Jenkins uses an exceedingly terrible XML config format but the files can be
generated which allows us to set up projects via nixops. Jenkins also has
some hooks and can e.g. be pinged by github to trigger a build.

We briefly looked at Hydra but could not figure out how to configure it via
files (it looks like a point-and-click interface backed by a database).
Also, because we have a working system switching is very low priority for
us. There are some other open source CI systems like travis and drone which
we know of but haven't yet investigated.

Even though it's very off-topic I'd definitely be interested in reading
more about how other companies are using nixops!

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

Re: [Nix-dev] State database in nixops

[Thomas Hunger]

 What I'd like much better is an option to use an external database; then I
 could use a replicated cluster or something like that to eliminate the
 single point of failure.  The last thing I want is my ops team being locked
 out of nixops during an emergency.


nixops accesses the .nix config file via an absolute path stored in the
sqlite database  (nixExprs). An external database doesn't help unless we
remove that absolute path restriction somehow and also distribute the
nixExprs file to every machine that might run nixops.

I'm not too fond of a central (potentially replicated) DB because it comes
with its own set of problems like permission management, requiring
bootstrapping (where to store the nixops state for the database server?)
etc.

We'd be interested in 1) an audit trail, 2) no single point of failure, 3)
light infrastructure.

On top of the 3 points I mentioned above we'd also be interested in
avoiding storing ephemeral state like ec2.backups and configsPath.

I think keeping state in a text file in git could achieve the above
requirements but I'm also sure that there are many other good ways to solve
this.

@Domen: In our experience deploying from a shared machine doesn't work well
[1].

best,
Tom

[1]
Long-ish:
E.g. we have an always-online server with all our SSH and Amazon
credentials on it. We're using instance IAM roles so it's not all bad.
Also, who's deploying to that server?
To deploy we SSH into that server, pull the latest git version and then
call nixops. If there is an issue with the config we fix it locally, push
to git, pull on server, deploy. That's a bit tiresome.
We also have a CI server which deploys for us, but that's not the same
server as the common one we use for manual deploys (which are unfortunately
necessary on occasion). So we have two copies of the state which has
already caused some problems.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] State database in nixops

[Thomas Hunger]

Hi,

I've been a happy user of nixops for my own projects for a while. It works
fine as a single user tool but we found it to be tricky to use with
multiple developers, or even just a CI system that calls nixops deploy.

One issue we had is absolute paths in the state. I.e. if I nixops export
my state and then import and use it on e.g. the jenkins account I need to
adjust the absolute paths.

Another issue we have is that checking a sqlite database into git isn't
great for reviews.

We have a semi-working system now where jenkins calls nixops deploy -s
/var/common-state/project.sqlite ... on our deploy server, and we have
local copies of that state for emergency deploys.

First: How are other people solving collaboration on nixops state?

Secondly: Is there any interest in extending nixops to have a text (e.g.
protobuf-ascii) state file with relative paths that could be checked into
git? There are a few unclear design choices, e.g. what to do with ec2
backups. But for our purposes it would be better to use AWSs list of
volumes as the source-of-truth for backups (e.g. by adding more tags).

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

Re: [Nix-dev] setting environment values.

[Thomas Hunger]

Hi,

There is makeWrapper [1] which wraps your binary in a shell script that
sets some variables before execution. See e.g. [2] for how apache maven
uses it to set JAVA_HOME.

Is that what you are looking for?

~


[1]
https://nixos.org/wiki/Nix_Runtime_Environment_Wrapper

[2]
https://github.com/NixOS/nixpkgs/blob/72e76a18c122ec657fd6825764be79db8d73b3ce/pkgs/development/tools/build-managers/apache-maven/builder.sh#L8

On 27 January 2015 at 18:48, Tim Sears t...@timsears.com wrote:

 I am writing a nix expression to port some libraries from another distro.

 The libraries have slightly non-standard locations so I would typically
 add some line to my .bashrc file like

 export SOMEVAR=somestring
 export SOMEPATH=/opt/path/to/libs
 export LD_LIBRARY_PATH=$SOMEPATH:$LD_LIBRARY_PATH.

 What is the nix way of doing this? I can set SOMEVAR=somestring in the
 derivation expression, and it appears in my environment after executing
 nix-shell, but SOMEPATH should look like $out/path/to/libs and I am not
 sure how/where to set that.

 Suggestions appreciated.
 -Tim

 ___
 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] A Journey into our brand-new Haskell infrastructure: Part II

[Thomas Hunger]

Thanks, that's super useful!

One more question: How would I get older versions of certain packages (e.g.
I need optparse-applicative 0.10 for elm-make) into hackage-packages.nix?

~

On 11 January 2015 at 19:41, Peter Simons sim...@cryp.to wrote:

 The topic of today's posting is: Fixing Build Failures!


 I know all about Cabal builds. How can I override a Nix build environment?
 --

   Every Haskell expression expects an argument called mkDerivation -- the
   function that builds the derivation from the build description. You can
   modify the environment of a build foo by replacing mkDerivation with a
   version that applies some function f to the expression first:

   | foo.override (args: args // {
   |   mkDerivation = expr: args.mkDerivation (expr // f expr);
   | })

   All Haskell configuration modules import the 'lib' library
   
 https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/haskell-modules/lib.nix
 
   that defines a bunch of neat little helper functions on top of this basic
   mechanism. Just check out out the configuration-XYZ.nix files to see some
   examples of how these functions are used.


 My build fails with the following dependencies are missing!
 --

   The most common build error is that the configure phase complains about
   missing dependencies. http://hydra.cryp.to/build/354149/nixlog/1/raw,
 for
   example, reporting these packages as missing:

   | Configuring AbortT-transformers-1.0.1...
   | Setup: At least the following dependencies are missing:
   | QuickCheck =2.4  2.6,
   | test-framework ==0.6.*,
   | test-framework-hunit ==0.2.*,
   | test-framework-quickcheck2 ==0.2.*

   Missing means that these libraries are available in the build
 environment,
   but the build isn't happy about their versions. Usually, the Cabal files
   specifies upper bounds that our versions exceed, i.e. our packages are
 *too
   new*.

   Now, the big question is whether those upper bounds are justified or
 whether
   they exist solely because upstream hasn't updated the Cabal file
 recently? An
   easy to test this is to add a jailbreak and to run the build again:
   
 https://github.com/peti/nixpkgs/commit/0dd413458ef1a5c05e64bee2462de2edfe0fe620
 ,
   If it succeeds now, then this fact should be communicated upstream:
   https://github.com/gcross/AbortT-transformers/issues/1. If you commit
 the
   override afterwards, then please include a reference to the upstream
 ticket
   in a comment, or at least add a brief comment explaining briefly why that
   jailbreak was added!

   A trickier case was reported on the nix-dev mailing list in
   http://permalink.gmane.org/gmane.linux.distributions.nixos/15526:

   | Configuring cabal-test-quickcheck-0.1.2...
   | Setup: At least the following dependencies are missing:
   | Cabal ==1.20.*

   First of all, let's check which Cabal version we have during the build:

   | $ nix-shell 'nixpkgs' -A haskellngPackages.cabal-test-quickcheck.env
 --command ghc-pkg list Cabal
   |
 /nix/store/a3dj9sjg5lh9wxl90lj4shp9s3brlscd-ghc-7.8.4/lib/ghc-7.8.4/package.conf.d
   |   Cabal-1.18.1.5

   'Cabal' is available, indeed, but our version doesn't meet the ==1.20.*
   constraint specified by 'cabal-test-quickcheck'. Curiously enough, the
   package's Cabal file imposes the following constraints on the library:

   | library
   |   [...]
   |   build-depends:
   | Cabal  = 1.16.0   1.21,

   This is strange, right? Our Cabal library fits into that range! It turns
 out
   that there is a test suite -- which we enable by default --, and that
 says:

   | test-suite example
   |   [...]
   |   build-depends:
   | Cabal  = 1.20   1.21,

   The test suite imposes a narrower constraint than the library itself. An
 easy
   way out of this situation is to just disable the testing phase:
 constraint:
   
 https://github.com/NixOS/nixpkgs/commit/7fa32aecd183f4fcede821a2b0c60a925c0e2ef5
 .

   Similarly, libraries may imposes additional restrictions when certain
   optional features are enabled during the build, i.e. features controlled
 by a
   Cabal flag. The aeson library uses this mechanism to choose between
 time
   versions before and after 1.5:

   | if flag(old-locale)
   |   build-depends: time  1.5, old-locale
   | else
   |   build-depends: time = 1.5

   We have '-fold-locale' hard-coded for that build in hackage-packages.nix
 (for
   reasons that will be addressed in a later installment), so aeson wouldn't
   build with ghc-7.9.x, because that compiler ships time 1.5.0.1. The
 solution
   in this case is to disable the old-locale for the the 7.9.x branch:
   
 https://github.com/NixOS/nixpkgs/blob/2ff8d1940f0986b572760edf1923539687f41ac8/pkgs/development/haskell-modules/configuration-ghc-7.9.x.nix#L52
 .


 I tried jailbreak, but that broke the build even more than before!
 

Re: [Nix-dev] A Journey into the Haskell NG infrastructure: Part I

[Thomas Hunger]

This is really cool!

I changed my sandbox code to look like the following. Is that how it's
intended to be used?

{ haskellngPackages ? (import nixpkgs {}).haskellngPackages,
  pkgs ? (import nixpkgs {}).pkgs }:
let
env = haskellngPackages.ghcWithPackages (p: [
  p.text
  p.mtl
  p.transformers
  p.warp
  p.cabal-install
]);
in
pkgs.myEnvFun {
  name = hello-world-wide-web;
  buildInputs = [ env ];
}


On 9 January 2015 at 15:46, Peter Simons sim...@cryp.to wrote:

 Dear Haskellers `intersect` Nixers,

 this is the first installment of a series of postings to describe technical
 aspects of the re-factored Haskell infrastructure. When this is all done, I
 intend to use these articles to create some kind of *gasp* user
 documentation
 for the Nixpkgs manual. So I encourage everyone to point out of omissions
 and
 technical errors, or to ask for clarification if something is vague or
 misleading. I've chosen an FAQ-style approach because I felt that this is
 easiest for me to write. Hopefully this translates into the document being
 easy
 to read, too! Here we go ...

 Why should I care about this new infrastructure?
 --

   The new code will break evaluation of any Haskell-related configuration
 you
   may have in ~/.nixpkgs/config.nix or /etc/nixos/configuration.nix.

   Privately generated cabal2nix expressions will cease to compile.

   Installations that rely on ghc-wrapper finding GHC libraries
 automatically in
   your ~/.nix-profile are obsolete. If you use this approach, you won't be
 able
   to update your profile anymore.


 Duh, I don't want that!
 ---

   You can stick to the established 'haskellPackages' set, if you prefer.
 The
   new code exists separately in 'haskellngPackages', and it's invisible to
   nix-env -i package-name and nix-env -u. If you don't make a
 conscious
   effort to switch, you won't see any of it.


 So I'll never have to update if I don't want to?
 

   My guess is that 'haskellPackages' and 'haskellngPackages' will co-exist
 for
   a while. Personally, I switched to Haskell NG, though, and I won't
 maintain
   any packages in the old hierarchy anymore. I suppose other contributors
 will
   do the same thing. Once you've converted your setup to
 'haskellngPackages',
   there's no reason to look back, really.

   In other words, you don't have to convert your setup *right now*, but at
 some
   point in the future you will probably have to.


 Is it difficult to migrate to Haskell NG?
 -

   Users of 'ghcWithPackages' can easily switch back and forth between both
   package sets. Your ~/.nixpkgs/config.nix file probably defines an
 attribute
   like this one:

   | {
   |   packageOverrides = super: let self = super.pkgs; in
   |   {
   | haskellEnv = self.haskellPackages.ghcWithPackages (p: with p; [
   |   async attoparsec caseInsensitive fgl GLUT GLURaw haskellSrc
   | ]);
   |   };
   | }

   Change this definition as follows to switch to Haskell NG:

   | {
   |   provideOldHaskellAttributeNames = true;
   |
   |   packageOverrides = super: let self = super.pkgs; in
   |   {
   | haskellEnv = self.haskellngPackages.ghcWithPackages (p: with p; [
   |   async attoparsec caseInsensitive fgl GLUT GLURaw haskellSrc
   | ]);
   |   };
   | }

   There are only two differences: the ng bit in the name of the package
 set,
   and the new 'provideOldHaskellAttributeNames' config attribute. (Note
 that
   this lives at the top level of ~/.nixpkgs/config.nix -- not inside of
   'packageOverrides'.)

   Users of the ghc-wrapper have to make a greater effort, I'm afraid,
 because
   ghc-wrapper no longer exists in the NG code. You'll have to switch to
   'ghcWithPackages' first. You may find this article helpful for the
 process:
   http://permalink.gmane.org/gmane.linux.distributions.nixos/15161.


 What does 'provideOldHaskellAttributeNames' do?
 ---

   The package 'cabal-install' has the attribute 'cabalInstall' in the old
   package set. In the new one, however, the attribute is now called
   'cabal-install' -- just like the package. provideOldHaskellAttributeNames
   enables a compatibility layer that defins the old camel-case style names
 on
   top of the new ones. This allows you to use the same configuration for
 both
   the new and old package sets.

   Once you feel ready to migrate permanently to NG code, you can switch the
   compatibility layer off, to ensure that all your definition use the new
 names
   consistently.


 Why is the ghc-wrapper gone?
 

   ghc-wrapper's underlying promise is that you can install a random Haskell
   package into your Nix profile, and GHC will pick it up from there
   automatically. Now, this worked reasonably well for many packages, but
 for
   may other packages it didn't work, and 

Re: [Nix-dev] A Journey into the Haskell NG infrastructure: Part I

[Thomas Hunger]

One thing that'd be useful is documenting how
pkgs/development/haskell-modules/hackage-packages.nix is regenerated and
how to fix common issues.

E.g. disabling tests done by overriding a package in
haskell-modules/configuration-common.nix. But I don't understand how to
retain a specific version of a package (e.g. you have time_1_5_0_1 in
there, how did you do that?).

~

On 9 January 2015 at 18:11, Peter Simons sim...@cryp.to wrote:

 Hi Thomas,

   I changed my sandbox code to look like the following. Is that how it's
   intended to be used?

 yes, exactly. That's a very nice example. You can put that definition into
 a
 file, say shell.nix, and run

   $ nix-shell --pure shell.nix

 to obtain an interactive environment that contains the compiler defined
 above.

 If you want to go all out, you can also add a shellHook attribute to make
 nix-shell define the magic environment variables that tell the 'ghc-paths'
 package how to use your environment. For example:

  | { pkgs ? (import nixpkgs {}).pkgs }:
  |
  | let
  |
  |   env = pkgs.haskellngPackages.ghcWithPackages (p: with p; [
  | text mtl transformers warp cabal-install
  |   ]);
  |
  | in
  |
  | pkgs.stdenv.mkDerivation {
  |   name = hello-world-wide-web;
  |   buildInputs = [ env ];
  |   shellHook = ''
  | export NIX_GHC=${env}/bin/ghc
  | export NIX_GHCPKG=${env}/bin/ghc-pkg
  | export NIX_GHC_DOCDIR=${env}/share/doc/ghc/html
  | export NIX_GHC_LIBDIR=$( $NIX_GHC --print-libdir )
  |   '';
  | }

 Best regards,
 Peter

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

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

Re: [Nix-dev] Ejabberd Options

[Thomas Hunger]

I also found this introduction useful:
https://medium.com/@MrJamesFisher/nix-by-example-a0063a1a4c55

On 16 December 2014 at 10:25, stewart mackenzie setor...@gmail.com wrote:

 On Tue, Dec 16, 2014 at 6:04 PM, Luca Bruno lethalma...@gmail.com wrote:
  The best you can do is reading the nix manual, and reading code and
  playing with nix in general, not through hydra where it takes time to
  test things.

 github.com/nixos/nixpkgs is the first frequency ranked tile on my
 firefox landing screen

  For example, don't use hydra, but use nix-build directly so that it's
  faster to trial  error.

 Yes I use this almost exclusively.

  Also hang around the irc channel of nixos, and hear people and how they
  solve their problems.

 auto login :)
 ___
 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