Re: [Nix-dev] "Package archeology" in nixpkgs

[Wout Mertens]

Don't forget the nix-env -u case which updates based on name (in fact, that
kinda sucks for sub-attributes like python packages, there are lots of
attributes mapping to the same names).

Wout.


On Mon, Sep 1, 2014 at 10:44 PM, Florent Becker  wrote:

>
> On 01/09/2014 11:22, Vladimír Čunát wrote:
>  > I suggest we distribute the database with the channel, similarly
>  > to the command-not-found database.
>
> Can't command-not-found suggest using nix-env -iA rather than nix-env
> -i? That would be one indirection less for that use case, and teach new
> users about nix-env -iA.
>
> --
> Florent
>
>
> ___
> 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] Will there be a systemd replacement at any time inthe future?

[Wout Mertens]

As a sysadmin, I love systemd and journald. If you want to maintain lots of
disparate things and look all over the OS while troubleshooting, good for
you, but systemctl and journalctl make life so much easier. Upstart is a
very poor substitute.

Anyway, systemd is only available on Linux kernels (this will never change)
and that means that NixOS can't be ported to other kernels. Furthermore,
it's still not available out-of-the-box in Docker, so you can't install a
NixOS image in Docker.

It would indeed be nice if systemd were abstracted away, so that
supervisord or other inferior but cross-platform job controllers can be
used instead. Perhaps the "jobs" compatibility API should be extended to
support more systemd features and should be the preferred way to define
services, using services.systemd only when not possible otherwise?

Wout.



On Mon, Sep 1, 2014 at 11:32 AM, Michael Raskin <7c6f4...@mail.ru> wrote:

> >> This post (to this ML) says pretty much what I think about systemd and
> >> why I hate it:
> >>
> >>  http://article.gmane.org/gmane.linux.distributions.nixos/13967
> >
> >I take these things more as a joke. It is even more extreme than to say
> >that KDE or GNOME is eating all desktop apps. To me systemd seems more
> >like a collection of well-defined subprojects.
>
> SystemD explicitly refuses to have stable APIs between components.
>
> If you have to update all at once, these are not subprojects.
>
> >People often complain about not having an alternative, but I've never
> >seen anyone seriously put an effort into adding an alternative into
> >NixOS. It should be easier than in most distros, as we have
> >*declarative* configuration of jobs and other things.
>
> We do not have declarative configuration of jobs in any useful way.
>
> Our declarations are very much tied to systemd. Dependencies are
> expressed in systemd terms — the rewriting was very visible during
> the (not universally welcomed) migration from upstart.
>
>
>
> ___
> 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] Will there be a systemd replacement at any time inthe future?

[Wout Mertens]

On Tue, Sep 2, 2014 at 12:05 PM, Vladimír Čunát  wrote:

> On 09/01/2014 10:59 PM, Wout Mertens wrote:
>
>> Furthermore, it's still not available out-of-the-box in Docker, so you
>> can't install a NixOS image in Docker.
>>
>
> IIRC, at the sprint last week, @offlinehacker claimed he made nixos work
> inside docker. I know no details... there probably still were some caveats.


Yup, it needs extra privileges for now, see
https://github.com/NixOS/nixpkgs/pull/3779

So until Docker mounts cgroups you can't ship people a Docker NixOS image
that they can run on third-party providers. Pretty trivial to run locally
with the correct flags of course.

Zef's Nix on Docker uses supervisord instead:
https://github.com/zefhemel/nix-docker and the systemd shim is
https://github.com/zefhemel/nix-docker/blob/master/nix-docker/modules/shim/systemd.nix

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

Re: [Nix-dev] NixOS on Azure?

[Wout Mertens]

... And is anybody working on making NixOps work with Azure?

Wout.
On Sep 6, 2014 5:46 AM, "Shea Levy"  wrote:

> How is the initial connection managed? Does Azure provide a console, or
> some interface to provide the VM with an SSH public key, or some such?
>
> On Fri, Sep 05, 2014 at 11:03:34PM +, Ross Gardler (MS OPEN TECH)
> wrote:
> > That's correct Azure images are VHD's. I've not tried the route you
> propose, so can't promise it will work. Certainly worth a try though.
> >
> > Sent from my Windows Phone
> > 
> > From: Shea Levy
> > Sent: ‎9/‎5/‎2014 3:58 PM
> > To: Ross Gardler (MS OPEN TECH)
> > Cc: nix-dev@lists.science.uu.nl
> > Subject: Re: [Nix-dev] NixOS on Azure?
> >
> > Hi Ross,
> >
> > Am I reading [1] correctly that Azure VMs are started from VHDs? If so,
> > we already have a function for creating virutalbox images that converts
> > a raw image containing a base NixOS system to VDI using qemu-img, so it
> > should be straightforward to tweak that to create a VHD instead.
> >
> > [1]:
> http://azure.microsoft.com/en-us/documentation/articles/virtual-machines-linux-create-upload-vhd/
> >
> > ~Shea
> >
> > On Fri, Sep 05, 2014 at 09:32:58PM +, Ross Gardler (MS OPEN TECH)
> wrote:
> > > I see that NixOS has images available for some of the popular clouds,
> but not for Azure. I'd love to see a NixOS image on VM Depot<
> http://vmdepot.msopentech.com/>. VM Depot is a community managed
> repository of virtual machines for Azure. We have something like 8
> different Linux distros and around 1700 images built on those distros
> (ranging from developer stacks through to end user applications).
> > >
> > > The first step to getting folks to publish NixOS based images is to
> have a base distribution of NixOS available and, preferably, updated every
> time there is an official release of NixOS. Is anyone here interested in
> creating and upload an image to VM Depot? I'm happy to help guide the
> process.
> > >
> > > Some common questions for the curious:
> > >
> > >
> > > 1)  Does it cost anything to store an image on VM Depot? No - all
> storage costs are paid by Microsoft Open Technologies, Inc (my employer)
> > >
> > > 2)  Does it cost anything to publish an image on VM Depot?
> Probably not - You will need an Azure subscription to temporarily store the
> image and there will be bandwidth charges for the initial copy. However,
> there are mechanisms by which we can ensure open source projects have
> sufficient Azure credits to do this without receiving a bill. Create a free
> Windows Azure trial subscription<
> http://www.windowsazure.com/en-us/pricing/free-trial/?WT.mc_id=AA4C1C935>
> to get started straight away (one month, $200 credit)
> > >
> > > 3)  Are there an restrictions on what can be uploaded to VM Depot?
> - Short answer - if its open source then no there are no restrictions. Long
> answer is in the Terms of Use http://vmdepot.msopentech.com/ToU.htm
> > >
> > > 4)  Why would I want to upload an image to VM Depot? It is easy
> for people to deploy a VM from VM Depot to Azure. This means it is easy for
> people to experiment with your project. More people experimenting means
> more users, more users means more potential contributors to the project and
> more potential customers for those employing contributors.
> > >
> > > 5)  How do I get started creating a new VM based on an existing
> distribution? See
> http://msopentech.com/blog/2014/05/14/deploy-customize-freebsd-virtual-machine-image-microsoft-azure/
> for a description of the general process (need not be FreeBSD as the
> starting image, the process is the same for any of the other images
> available)
> > >
> > > 6)  How do I get started creating a new base distribution VM?
> http://azure.microsoft.com/en-us/documentation/articles/virtual-machines-linux-tutorial/
> > >
> > > 7)  Who can I contact for assistance? Ross Gardler -
> ross.gard...@microsoft.com
> > >
> > > Microsoft Open Technologies, Inc.
> > > A subsidiary of Microsoft Corporation
> > > MS Open Tech is hiring! Ask me for
> details if anyone you know is interested (http://aka.ms/msopentechjobs)
> > >
> >
> > > ___
> > > 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] chromium widevine CDM

[Wout Mertens]

Circumstantial evidence : my netflix started working lots better on Mac,
because it switched to HTML5 playing. I indeed have the widevine plugin
now.

Wout.
On Sep 15, 2014 3:36 PM, "Mathijs Kwik"  wrote:

> Hi all,
>
> Recently, netflix enabled support for the chrome browser, running on
> linux. This means it should now be possible to watch netflix without
> silverlight in pure HTML5 video. This became possible because w3c's
> controversial EME (encrypted media extensions) which enables netflix to
> enforce DRM schemes.
>
> Chrome 37 and higher have full support for EME, but EME is only an
> interface which plugs into the actual DRM component. The key component
> for this scheme is called "widevine CDM", which is also used by youtube
> for some content. It turns out that the widevine technology was acquired
> by google and also used for android and chromeOS video streaming.
>
> This CDM component is part of the official chrome distribution, but from
> googling a bit I found it should have been part of chromium by default
> as well now. I checked our stable, beta and dev releases, but
> chrome://components does not show it.
>
> I suspect we need to (optionally) enable extra flags during building,
> but I'm not familiar with the build process. Can someone please give me
> some pointers? it appears there is a
> "third_party/widevine/cdm/widevine_cdm.gyp" file in our sources, so that
> should probably be included somehow.
>
> Thanks,
> Mathijs
>
> ___
> 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] fixed-output derivation that *also* depend on (some of) its inputs?

[Wout Mertens]

Isn't the whole point of the fixed-output derivations that the means of
getting there doesn't matter? So if you change the build script but leave
the output hash the same, you're basically saying that the build script
will generate the same output.

I think what you want is to remove a build product from the store when you
change the build scripts?

As for this use case, handbrake also downloads a bunch of things as part of
the build and I made the expression just patch that away, moving all the
extra building and patches into other expressions.

Another approach might be to use recursive Nix (building new nix
expressions as part of a nix build), although I'm not sure what the state
of that is.

Wout.

On Sun, Sep 21, 2014 at 6:37 PM, Bjørn Forsman 
wrote:

> On 21 September 2014 08:15, Vladimír Čunát  wrote:
> > On 09/20/2014 09:55 PM, Bjørn Forsman wrote:
> >>
> >> Since fetchurl (via the nixos tarball mirror) downloads the same old
> >> file (even though it creates a new store path), the result outputHash
> >> is the same as before. So evaluation doesn't stop but continues on
> >> with old/wrong data.
> >
> >
> > If fetchurl *did* download any other data, then it would fail while
> checking
> > the hash. That was my point. Nixos tarball mirror may be different and
> > download the same content, but in any case that doesn't change the plain
> > fact of the first sentence of this paragraph.
> >
> > I think we all agree on how fetchurl works, but I still have no idea what
> > you desire. I may be an exception, but I don't see what could be done
> > "between" the current fixed-output and standard derivations. Either you
> do
> > know what exactly the output should look like and then it doesn't really
> > matter how you arrive at it, or you don't know it and then you have a
> > standard derivation.
>
> I'll try to explain the issue with an example. Given the following
> expression:
>
>
> with (import  { });
>
> stdenv.mkDerivation rec {
>   name = "foo-0.0";
>
>   outputHashAlgo = "sha256";
>   outputHash = "0sldaa6dd6dsfm1c7f8z9i32dfhn53aw1kyrlid1naa7hb6biy4v";
>   outputHashMode = "recursive";
>
>   buildCommand = ''
> mkdir -p "$out"
> echo hello >"$out/file"
>   '';
> }
>
>
> Build it. Then change the "echo hello >$out/file" to "echo foobar
> >$out/file". The output will clearly change, but nix has cached the
> result and will not do a rebuild. That's bad!
>
> (You may at this point wonder, why use fixed-output derivation at all?
> It's because the buildCommand, as is the case when packaging grails
> apps, will download dependencies from the internet, so a standard
> derivation will fail.)
>
> I can work around this "caching" this by adding some hackery:
>
> stdenv.mkDerivation rec {
>   extraHash = builtins.hashString "sha256" (buildCommand);
>   name = "foo-${extraHash}-0.0";
>
> This results in a derivation that gets rebuilt/checked whenever
> buildCommand changes. This is what I want.
>
> But this solution feels very hackish. So my question is whether it's
> possible to tell nix that certain derivation inputs affect the output,
> so that when the inputs change, nix has to rebuild / re-check the
> result.
>
> It seems that when using fixed-output derivations, only the "name"
> attribute matters. I think there are use cases (like the example
> above) that requires other derivation inputs to be considered
> important enough to do a rebuild.
>
> Vladimir, does it make sense to you now?
>
> 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] Zero Hydra Failures (ZHF) project for NixOS

[Wout Mertens]

So what is the status? I want to help because I think there's a huge
difference between 0 and 1. If we have 0 failures, hopefully we'll try
harder to keep it that way.

Anyway I had a look at the latest evaluation of trunk-combined and it says
there are 1359 still failing...
http://hydra.nixos.org/eval/1152983#tabs-still-fail

How can the non-free/marked broken/wrong platform evaluation failures be
ignored?

Wout.

On Mon, Sep 22, 2014 at 12:25 PM, Florian Friesdorf 
wrote:

>
> An awesome job! Thank you to everybody involved!
>
> An that "awesome" is with the real meaning of the word in mind! (see
> also TED talk on "Let's put the awe back in awesome")
>
> On Fri, Sep 19 2014, Domen Kožar wrote:
> > Hi all,
> >
> > during NixOS sprint in Ljubljana I joined the effort to get build
> failures
> > down to 0 for NixOS.
> >
> > We're current at 135 failing builds (down from 2500 before the sprint)
> for
> > nixos-combined job.
> >
> > To see last failing builds, check:
> > http://hydra.nixos.org/eval/1152694#tabs-still-fail
> >
> > I'll try to get those down to ~0 during the weekend, I'd like to
> encourage
> > anyone willing to fix one or two builds to join in to achieve this
> > milestone after a long period of time.
> >
> > Rock on!
> >
> > Domen
> > ___
> > nix-dev mailing list
> > nix-dev@lists.science.uu.nl
> > http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
> --
> Florian Friesdorf 
>   GPG FPR: 7A13 5EEE 1421 9FC2 108D  BAAF 38F8 99A3 0C45 F083
> Jabber/XMPP: f...@chaoflow.net
> IRC: chaoflow on freenode,ircnet,blafasel,OFTC
>
> ___
> 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] Grub2 install error on latest unstable channel

[Wout Mertens]

Does `nixos-rebuild build-vm-with-bootloader` work? If so it would be just
your system/partition layout?

On Mon, Sep 22, 2014 at 10:45 PM, Bjørn Forsman 
wrote:

> Hi all,
>
> After the long awaited unstable channel update (yay!), I unfortunately
> get this grub2 install error:
>
> $ sudo nixos-rebuild switch
> building Nix...
> building the system configuration...
> updating GRUB 2 menu...
> installing the GRUB 2 boot loader on /dev/disk/by-label/nixos-ssd...
> Installing for i386-pc platform.
>
> /nix/store/wkmf1mhwkjspdr1myhyalgyc7882q1k7-grub-2.02-git-1de3a4/sbin/grub-install:
> warning: File system `ext2' doesn't support embedding.
>
> /nix/store/wkmf1mhwkjspdr1myhyalgyc7882q1k7-grub-2.02-git-1de3a4/sbin/grub-install:
> warning: Embedding is not possible.  GRUB can only be installed in
> this setup by using blocklists.  However, blocklists are UNRELIABLE
> and their use is discouraged..
>
> /nix/store/wkmf1mhwkjspdr1myhyalgyc7882q1k7-grub-2.02-git-1de3a4/sbin/grub-install:
> error: will not proceed with blocklists.
> /nix/store/pmashz5671fadjfyxaxf6r0bcz5839m4-install-grub.pl:
> installation of GRUB on /dev/disk/by-label/nixos-ssd failed
> warning: error(s) occured while switching to the new configuration
>
> Disk /dev/disk/by-label/nixos-ssd doesn't have ext2, it has ext4.
>
> There are ~300 commits between unstable and git HEAD, but a quick
> search didn't reveal any grub related changes in that set.
>
> For the record, the channel is at commit
> 74f6be0e5fa5d4393e3ce4cd5efcd63b9cc1ba96.
>
> 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] Grub2 install error on latest unstable channel

[Wout Mertens]

Or this one, which adds blkid:
https://github.com/NixOS/nixpkgs/commit/36614ff3e290a9330dd8e29bdc6cc38ede1e7001
?

On Tue, Sep 23, 2014 at 9:45 AM, Domen Kožar  wrote:

> Possible cause:
> https://github.com/NixOS/nixpkgs/commit/f73f7ccc6e0b17d08d2ef689b76755769d3663b4
>
> On Tue, Sep 23, 2014 at 9:01 AM, Bjørn Forsman 
> wrote:
>
>> On 23 September 2014 08:32, Bjørn Forsman 
>> wrote:
>> > On 23 September 2014 08:13, Bjørn Forsman 
>> wrote:
>> >> On 22 September 2014 23:21, Wout Mertens 
>> wrote:
>> >>> Does `nixos-rebuild build-vm-with-bootloader` work? If so it would be
>> just
>> >>> your system/partition layout?
>> >>
>> >> $ nixos-rebuild build-vm-with-bootloader
>> > [snip log output with errors]
>> >
>> > I went back to previous channel (commit
>> > 41cd2d870ab7dc76913ba1cc2dc21e313732b4f1). That worked:
>> [...]
>>
>> So the old channel had
>>
>> updating GRUB 2 menu...
>> installing the GRUB 2 boot loader on /dev/vda...
>> [success]
>>
>>
>> But the new channel has
>>
>> updating GRUB 2 menu...
>> Failed to get blkid info for /nix/store on store at
>> /nix/store/pmashz5671fadjfyxaxf6r0bcz5839m4-install-grub.pl line 160.
>> [fail]
>>
>>
>> I was at first thinking that the issue was a grub version update, but
>> now I wonder whether its a change in nixos instead. Why does it use
>> blkid for /nix/store? I don't know this code, but the log looks a bit
>> odd.
>>
>> 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] Grub2 install error on latest unstable channel

[Wout Mertens]

Worthy of an issue tagging @wkennington in any case :-)

Wout.
On Sep 23, 2014 12:02 PM, "Wout Mertens"  wrote:

> Or this one, which adds blkid:
> https://github.com/NixOS/nixpkgs/commit/36614ff3e290a9330dd8e29bdc6cc38ede1e7001
> ?
>
> On Tue, Sep 23, 2014 at 9:45 AM, Domen Kožar  wrote:
>
>> Possible cause:
>> https://github.com/NixOS/nixpkgs/commit/f73f7ccc6e0b17d08d2ef689b76755769d3663b4
>>
>> On Tue, Sep 23, 2014 at 9:01 AM, Bjørn Forsman 
>> wrote:
>>
>>> On 23 September 2014 08:32, Bjørn Forsman 
>>> wrote:
>>> > On 23 September 2014 08:13, Bjørn Forsman 
>>> wrote:
>>> >> On 22 September 2014 23:21, Wout Mertens 
>>> wrote:
>>> >>> Does `nixos-rebuild build-vm-with-bootloader` work? If so it would
>>> be just
>>> >>> your system/partition layout?
>>> >>
>>> >> $ nixos-rebuild build-vm-with-bootloader
>>> > [snip log output with errors]
>>> >
>>> > I went back to previous channel (commit
>>> > 41cd2d870ab7dc76913ba1cc2dc21e313732b4f1). That worked:
>>> [...]
>>>
>>> So the old channel had
>>>
>>> updating GRUB 2 menu...
>>> installing the GRUB 2 boot loader on /dev/vda...
>>> [success]
>>>
>>>
>>> But the new channel has
>>>
>>> updating GRUB 2 menu...
>>> Failed to get blkid info for /nix/store on store at
>>> /nix/store/pmashz5671fadjfyxaxf6r0bcz5839m4-install-grub.pl line 160.
>>> [fail]
>>>
>>>
>>> I was at first thinking that the issue was a grub version update, but
>>> now I wonder whether its a change in nixos instead. Why does it use
>>> blkid for /nix/store? I don't know this code, but the log looks a bit
>>> odd.
>>>
>>> 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] nix-1.7 on armv6l-linux

[Wout Mertens]

I've stared at it wistfully but didn't get around to it yet :)

Can you please add --show-trace so we can see how the failure happens?

Basically, you're in this bit of code:
https://github.com/NixOS/nixpkgs/blob/3a33731e5468b52c887154192d2b970e8bbf04f8/nixos/modules/installer/tools/nixos-rebuild.sh#L144-L168

and the unsupported message is because it doesn't have a hardcoded binary
path.

Wout.

On Thu, Sep 25, 2014 at 1:13 PM, Tim Barbour  wrote:

> Starting from the installation image on the Wiki, I managed to get my
> Raspberry Pi Model B up-to-date WRT nixos-13.10 . I then changed the
> channel
> to nixos-14.04, updated the channel, and ran "nixos-rebuild build",
> resulting
> in the following output:
>
> building Nix...
> error: user-thrown exception: the package ‘nix-1.7’ in «unknown-file» is
> not supported on ‘armv6l-linux’
> (use `--show-trace' to show detailed location information)
> error: user-thrown exception: the package ‘nix-1.8pre3718_51485dc’ in
> «unknown-file» is not supported on ‘armv6l-linux’
> (use `--show-trace' to show detailed location information)
> error: user-thrown exception: the package ‘nix-1.8pre3718_51485dc’ in
> «unknown-file» is not supported on ‘armv6l-linux’
> (use `--show-trace' to show detailed location information)
>
> which seems to be saying that nix no longer runs on armv6l-linux from 1.7
> onwards.
>
> Has anyone else tried running nixos-14.04 on ARM ?
>
> Tim
> ---
> GPG public key available at:
>  http://phasechangeit.com/~trb/gpg-key  or
>  http://subkeys.pgp.net:11371
>
> ___
> 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] Security channel proposal

[Wout Mertens]

It sounds like a necessary evil.

Another option would be to make Hydra super fast... What has been explored
to optimize compile speeds? Using distcc, ccache, SSD, elastic scaling?

What if we had a security build fund that we could use to briefly run 500
machines to complete security builds? Would that allow 2-hour security
rollouts?

Wout.

On Thu, Sep 25, 2014 at 10:19 AM, Luca Bruno  wrote:

> My proposal is to have an hydra security channel independent of nixpkgs.
>
> SAMPLE USAGE
>
> nix-channel --add
> http://hydra.nixos.org/jobset/nixos/security/channel/latest
>
> The channel will provide a  to be imported by the
> users in their configuration.nix.
>
> The nixos-sec/module.nix will add the relevant security updates[1].
>
> WRITING SECURITY UPDATES
>
> It must be ensured that the fixed software has the same ABI/API of the
> one getting replaced, so that the security updates can work
> independently of nixpkgs/nixos channel updates.
>
> To achieve this, the derivation version should be parsed and checked
> against the new version.
> Also if the version of the software being replaced is higher than fixed
> version, then the replace must not happen.
> A couple of utility functions should suffice in writing such security
> updates.
>
> In general, I think it's better to use overrideDerivation + src +
> patches, so that if the user ever customized compilation flags or
> anything else, the security update will be as least invasive as possible.
>
> Best regards,
>
> [1] https://nixos.org/wiki/Security_Updates
>
> ___
> 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] Security channel proposal

[Wout Mertens]

On Thu, Sep 25, 2014 at 2:41 PM, Michael Raskin <7c6f4...@mail.ru> wrote:

> >It sounds like a necessary evil.
> >
> >Another option would be to make Hydra super fast... What has been explored
> >to optimize compile speeds? Using distcc, ccache, SSD, elastic scaling?
> >
> >What if we had a security build fund that we could use to briefly run 500
> >machines to complete security builds? Would that allow 2-hour security
> >rollouts?
>
> I bet against our package set being buildable in 2 hours — because of
> time-critical path likely hitting some non-parallelizable package.
>

I think most large projects can be compiled via distcc, which means that
all you need is parallel make.

Libreoffice build is inherently a single-machine task, so to speed it
> up you need something like two octocore CPUs in the box.
>

Point in case:
https://wiki.documentfoundation.org/Development/BuildingOnLinux#distcc_.2F_Icecream
. Building with "icecream" defaults to 10 parallel builds.

Also, with ccache the original build time of 1.5 hours (no java/epm) is
reduced to 10 minutes on subsequent runs.


> With such a goal, we would need to recheck all the dependency paths and
>
optimise the bottlenecks.
>

Sounds good :)

Another option is to have a jobset which builds only a "server" subset of
NixPkgs, and which has higher priority than the trunk builds. I don't know
of many servers that need libreoffice installed...

You can have multiple binary buildsets right?

Maybe making dependency replacement work reliably (symlinking into
> a special directory and referring to this directory?) is more feasible…
>

Can you elaborate?

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

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

[Wout Mertens]

Am I correct when thinking there are currently still 104+4 jobs failing?
http://hydra.nixos.org/eval/1153186#tabs-still-fail

Here's a strange one: kde-telepathy is failing since January, and
apparently the problem is part of this patch range:
https://github.com/NixOS/nixpkgs/compare/0b499fb96350636ccb4be1c1416a8ac8a22eef63...ddf5841d74a6037197d0f8aa24a2f3ef9b6de1ba
but I don't see anything that would impact that. Odd. Is anybody even using
that?

Wout.


On Mon, Sep 22, 2014 at 2:13 PM, Wout Mertens 
wrote:

> So what is the status? I want to help because I think there's a huge
> difference between 0 and 1. If we have 0 failures, hopefully we'll try
> harder to keep it that way.
>
> Anyway I had a look at the latest evaluation of trunk-combined and it says
> there are 1359 still failing...
> http://hydra.nixos.org/eval/1152983#tabs-still-fail
>
> How can the non-free/marked broken/wrong platform evaluation failures be
> ignored?
>
> Wout.
>
> On Mon, Sep 22, 2014 at 12:25 PM, Florian Friesdorf 
> wrote:
>
>>
>> An awesome job! Thank you to everybody involved!
>>
>> An that "awesome" is with the real meaning of the word in mind! (see
>> also TED talk on "Let's put the awe back in awesome")
>>
>> On Fri, Sep 19 2014, Domen Kožar wrote:
>> > Hi all,
>> >
>> > during NixOS sprint in Ljubljana I joined the effort to get build
>> failures
>> > down to 0 for NixOS.
>> >
>> > We're current at 135 failing builds (down from 2500 before the sprint)
>> for
>> > nixos-combined job.
>> >
>> > To see last failing builds, check:
>> > http://hydra.nixos.org/eval/1152694#tabs-still-fail
>> >
>> > I'll try to get those down to ~0 during the weekend, I'd like to
>> encourage
>> > anyone willing to fix one or two builds to join in to achieve this
>> > milestone after a long period of time.
>> >
>> > Rock on!
>> >
>> > Domen
>> > ___
>> > nix-dev mailing list
>> > nix-dev@lists.science.uu.nl
>> > http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>> --
>> Florian Friesdorf 
>>   GPG FPR: 7A13 5EEE 1421 9FC2 108D  BAAF 38F8 99A3 0C45 F083
>> Jabber/XMPP: f...@chaoflow.net
>> IRC: chaoflow on freenode,ircnet,blafasel,OFTC
>>
>> ___
>> 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] Security channel proposal

[Wout Mertens]

On Thu, Sep 25, 2014 at 6:33 PM, Michael Raskin <7c6f4...@mail.ru> wrote:

> >> I bet against our package set being buildable in 2 hours — because of
> >> time-critical path likely hitting some non-parallelizable package.
> >>
> >
> >I think most large projects can be compiled via distcc, which means that
> >all you need is parallel make.
>
> WebKitGTK… (there is a comment about failure to make it work with
> parallel build)
>

... https://trac.webkit.org/wiki/WebKitGTK/SpeedUpBuild#distcc

>Libreoffice build is inherently a single-machine task, so to speed it
> >> up you need something like two octocore CPUs in the box.
> >>
> >
> >Point in case:
> >
> https://wiki.documentfoundation.org/Development/BuildingOnLinux#distcc_.2F_Icecream
> >. Building with "icecream" defaults to 10 parallel builds.
> >
> >Also, with ccache the original build time of 1.5 hours (no java/epm) is
> >reduced to 10 minutes on subsequent runs.
>
> How would ccache cache be managed for that? How it would work with
> rented instances being network-distant from each other?
>

Perhaps with persistent block storage that gets re-attached when an
instance is spun up, or by using a central NFS server:
https://ccache.samba.org/manual.html#_sharing_a_cache

>> With such a goal, we would need to recheck all the dependency paths and
> >optimise the bottlenecks.
> >Sounds good :)
>
> We have too little manpower for timely processing of pull requests.
> I think that starting a huge project should be done with full knowledge
> that it can fail just because it needs too much energy.
>

I would start by autogenerating sensible metrics, which could then lead to
incremental improvements as people tackle packages one by one. For example,
perhaps the total number of dependencies (all depths) multiplied by the
compile time of the package.


> >Maybe making dependency replacement work reliably (symlinking into
> >> a special directory and referring to this directory?) is more feasible…
> >
> >Can you elaborate?
>
> One of the bruteforce ways is just to declare «we need reliable global
> dependency rewriting». In this case we could just have a symlink for
> every package ever used as dependency so a replacement would mean
> destructively changing this symlink.
>
> I.e. you depend on /nix/store/aaa-bash, there is a symlink
> /nix/store/aab-bash to /nix/store/aaa-bash, and the builder sees just
> /nix/store/aab-bash.


Perhaps this could be done by nix-store instead, just provide a list of
replacement packages and it will move the original packages away and
symlink the replacements in their place. We could also prototype this with
a pretty simple script.

So almost what you're saying, except that the /nix/store/aaa-bash gets
moved to /nix/store/OLD-aaa-bash and /nix/store/aaa-bash becomes a symlink
to aab-bash. No pre-determining of dependency rewrite targets.

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

Re: [Nix-dev] Making Hydra super fast (was: Security channel proposal)

[Wout Mertens]

On Sep 25, 2014 8:19 PM, "Peter Simons"  wrote:
>
> Hi Wout,
>
>  > Another option would be to make Hydra super fast... What has been
>  > explored to optimize compile speeds? Using distcc, ccache, SSD,
>  > elastic scaling?
>
> Hydra is appears slow because "hydra-evaluator" is single-threaded. A
> round-trip evaluating all jobsets on hydra.nixos.org takes almost a day.
If
> a commit comes in 10 minutes after 'master' was evaluated, then it takes
~24
> hours before the first build with that commit even *starts*. Once the
> evaluator has put pending builds into the queue, however, you'll find that
> the build slaves are super fast, actually. The throughput is great, but
the
> latency sucks.

Hmmm, I'm not sure I understand. Are you saying that build slaves are going
idle because of build scheduling?

> The other factor is that only a handful of people have administrator
> privileges on the machines that run those builds, and those people are
> volunteers with jobs, families, and a life. We've seen that 'master' can
be
> stuck for several days because of trivial system issues (disk space,
> anyone?), but none of the people who could do something about it have time
> to actually do it.

I hereby volunteer.

>  > What if we had a security build fund that we could use to briefly run
500
>  > machines to complete security builds? Would that allow 2-hour security
>  > rollouts?
>
> If we're looking only at Linux/x86_64, then 3-5 fast machines could easily
> build all important packages in 'master' in approximately two hours. In
> fact, hydra.nixos.org could do probably do that, too. The problem isn't
the
> build slaves -- the problem is the server that drives them.
>
> To improve the situation, we could:
>
>  (1) Hack hydra-evaluator to be super efficient.
>
>  (2) Rent some machine with lots of disk space, lots of memory, and a good
>  Internet connection to build Nixpkgs 'master', 'release-14.04', but
>  nothing else. Then have a team of 5-10 volunteers administer that
>  machine to guarantee responsiveness.

Sounds good...

> If we'd have some kind of "emergency response fund" that would allow us to
> span build slaves in EC2, it would help matters greatly, too, but only if
> there is someone who can quickly re-configure the main server to take
> advantages of those slaves. Personally, I could easily spawn half a dozen
> build slaves in EC2 and donate them to nixos.org for a day or two, but
then
> I'd have no way to configure hydra.nixos.org to use them!

Sounds like a great problem to solve with NixOps!

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

Re: [Nix-dev] Security channel proposal

[Wout Mertens]

Very true, but isn't the stable branch supposed to do exactly that? Only
upgrade things for security reasons or harmless bugfixes? If we're not
doing that, I think we should have clearer guidelines for updating stable.

Wout.


On Thu, Sep 25, 2014 at 8:00 PM, Domen Kožar  wrote:

> Note that from business perspective server admin usually wants to do
> following two things:
>
> 1) to be notified if any of software packages has a security vuln
> 2) to take automated/manual actions to upgrade ONLY those packages and not
> bump and versions
>
> Having faster hydra doesn't solve 2)
>
> Domen
>
> On Thu, Sep 25, 2014 at 7:07 PM, Wout Mertens 
> wrote:
>
>> On Thu, Sep 25, 2014 at 6:33 PM, Michael Raskin <7c6f4...@mail.ru> wrote:
>>
>>> >> I bet against our package set being buildable in 2 hours — because of
>>> >> time-critical path likely hitting some non-parallelizable package.
>>> >>
>>> >
>>> >I think most large projects can be compiled via distcc, which means that
>>> >all you need is parallel make.
>>>
>>> WebKitGTK… (there is a comment about failure to make it work with
>>> parallel build)
>>>
>>
>> ... https://trac.webkit.org/wiki/WebKitGTK/SpeedUpBuild#distcc
>>
>> >Libreoffice build is inherently a single-machine task, so to speed it
>>> >> up you need something like two octocore CPUs in the box.
>>> >>
>>> >
>>> >Point in case:
>>> >
>>> https://wiki.documentfoundation.org/Development/BuildingOnLinux#distcc_.2F_Icecream
>>> >. Building with "icecream" defaults to 10 parallel builds.
>>> >
>>> >Also, with ccache the original build time of 1.5 hours (no java/epm) is
>>> >reduced to 10 minutes on subsequent runs.
>>>
>>> How would ccache cache be managed for that? How it would work with
>>> rented instances being network-distant from each other?
>>>
>>
>> Perhaps with persistent block storage that gets re-attached when an
>> instance is spun up, or by using a central NFS server:
>> https://ccache.samba.org/manual.html#_sharing_a_cache
>>
>> >> With such a goal, we would need to recheck all the dependency paths and
>>> >optimise the bottlenecks.
>>> >Sounds good :)
>>>
>>> We have too little manpower for timely processing of pull requests.
>>> I think that starting a huge project should be done with full knowledge
>>> that it can fail just because it needs too much energy.
>>>
>>
>> I would start by autogenerating sensible metrics, which could then lead
>> to incremental improvements as people tackle packages one by one. For
>> example, perhaps the total number of dependencies (all depths) multiplied
>> by the compile time of the package.
>>
>>
>>> >Maybe making dependency replacement work reliably (symlinking into
>>> >> a special directory and referring to this directory?) is more
>>> feasible…
>>> >
>>> >Can you elaborate?
>>>
>>> One of the bruteforce ways is just to declare «we need reliable global
>>> dependency rewriting». In this case we could just have a symlink for
>>> every package ever used as dependency so a replacement would mean
>>> destructively changing this symlink.
>>>
>>> I.e. you depend on /nix/store/aaa-bash, there is a symlink
>>> /nix/store/aab-bash to /nix/store/aaa-bash, and the builder sees just
>>> /nix/store/aab-bash.
>>
>>
>> Perhaps this could be done by nix-store instead, just provide a list of
>> replacement packages and it will move the original packages away and
>> symlink the replacements in their place. We could also prototype this with
>> a pretty simple script.
>>
>> So almost what you're saying, except that the /nix/store/aaa-bash gets
>> moved to /nix/store/OLD-aaa-bash and /nix/store/aaa-bash becomes a symlink
>> to aab-bash. No pre-determining of dependency rewrite targets.
>>
>> Wout.
>>
>> ___
>> 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] Grub2 install error on latest unstable channel

[Wout Mertens]

On Sep 28, 2014 3:20 PM, "Vladimír Čunát"  wrote:
>
> Hi.
>
>
> On 09/28/2014 01:59 PM, Bjørn Forsman wrote:
>>
>> On 28 September 2014 13:44, Bjørn Forsman 
wrote:
>> [...]
>>>
>>> For the last 1-2 years I've had boot.loader.grub.device =
>>> "/dev/disk/by-label/240gb" in my configuration.nix.
>>
>>
>> ...but I probably never installed grub with that setting!
>
>
> AFAIK labels are for partitions, not for disks.

... But it would be cool to be able to say "install on the boot
sector/record of the disk containing the partition x"

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

Re: [Nix-dev] Announcing nix-exec

[Wout Mertens]

Hi Shea,

so this allows you to interact with Nix in C++, wrapped as a Nix expression?

I'm just trying to wrap my head around this, what would be the general
approach to using this in e.g. Hydra?

Thanks,

Wout.


On Sun, Sep 28, 2014 at 9:28 PM, Shea Levy  wrote:

> Hi all,
>
> I've just added [1] nix-exec to nixpkgs. It provides a way to define and
> execute programs written in nix, for programs that need to interact with
> the nix store or expression language. Please see the home page [2] for
> more details.
>
> Please note that this was a quick project, and that there are sure to be
> bugs, inefficiencies, and lackluster documentation. I've only had time
> so far to test one trivial example! So please open issues if something
> isn't working right.
>
> Happy hacking!
>
> ~Shea
>
> [1]:
> https://github.com/NixOS/nixpkgs/commit/d34cd13a317dd0df5af9f3a67ad22e9ea8f9e505
> [2]: https://github.com/shlevy/nix-exec
> ___
> 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 "small" channel

[Wout Mertens]

Just to let you know I'm doing a happy dance right now :-)

Great stuff!

Wout.
On Sep 30, 2014 2:27 AM, "Eelco Dolstra" 
wrote:

> Hi,
>
> Since last week there is a new NixOS channel:
>
>   https://nixos.org/channels/nixos-14.04-small
>
> This is a variant of the regular NixOS 14.04 channel mainly intended for
> servers
> that need fast security updates. It differs from the regular 14.04 channel
> in
> the following ways:
>
> * It builds way, way fewer packages. In particular, there is no desktop
> stuff,
> and no gazillion Python/Perl/Haskel/... packages.
>
> * It has fewer release-critical tests. For instance, it doesn't require
> any of
> the X11 tests to succeed.
>
> * It only builds x86_64 binaries.
>
> These properties mean that the channel can update in about 2-3 hours after
> a Git
> commit that causes a full rebuild, rather than several days. The downside
> is
> that nixos-rebuild may need to build more stuff from source than with the
> regular channel.
>
> To switch an existing system to this channel:
>
>   $ nix-channel --add https://nixos.org/channels/nixos-14.04-small nixos
>   $ nixos-rebuild switch --upgrade
>
> The channel currently builds a fairly arbitrary set of packages. These are
> defined here:
>
>
> https://github.com/NixOS/nixpkgs/blob/release-14.04/nixos/release-small.nix
>
> Feel free to add/suggest additional packages.
>
> The Hydra jobset is:
>
>   http://hydra.nixos.org/jobset/nixos/release-14.04-small
>
> and the status of the release-critical jobs is here:
>
>
> http://hydra.nixos.org/job/nixos/release-14.04-small/tested#tabs-constituents
>
> --
> Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
> ___
> 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] Moving some of the NixOS setup to nixpkgs

[Wout Mertens]

Hi all,

TL;DR: I'd like to discuss the empty space between declarative NixOS
systems and imperative nix-env user profiles.


As we all know, nixpkgs provides compiled packages and NixOS ties them
together with environment variables, configuration files and systemd
services.

This dichotomy causes a bit of a problem for user environments, especially
on nixpkgs installs outside NixOS.

Examples are the environment variables TZDIR, CURL_CA_BUNDLE,
OPENSSL_X509_CERT_FILE and others, which are in place for NixOS users but
not for nixpkgs users. Without these, glibc and curl don't work 100% right.
Plain nixpkgs installs should have these set in the user environment
somehow.

Another issue, is that configuration files are only generated for NixOS
services. So if you as a user want to use nginx on an unprivileged port for
development, you need to generate the configuration by hand instead of just
specifying a port and getting a wrapper.

One more related topic is declarative user environments. You can do it [1],
but it's a bit of a hidden feature and not very straightforward.

So I'm hoping that we can come up with a system where:

   - configuration wrappers are in nixpkgs, and NixOS modules use those.
   - multiple configurations of a package become multiple wrappers with
   user-definable names
   - environment variables like TERMINFO are declared in nixpkgs instead of
   NixOS modules and synthesized into the user environment instead of via NixOS
   - declarative user environments are made as easy as possible. Perhaps it
   should be the default and nix-env only edits the declaration.

Thoughts please!

Wout.

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

Re: [Nix-dev] NixOS "small" channel

[Wout Mertens]

Hi Eelco,

Can we also have a small channel for unstable?

Most of its build products will be reused by the regular jobs, so it
shouldn't take away too many resources from regular builds, right?

Wout.


On Wed, Oct 1, 2014 at 9:00 AM, Luca Bruno  wrote:

> On 01/10/2014 03:29, Anderson Torres wrote:
> > Yes! t is cool! :)
> >
> > But, how about the other channels? I use the nixos-unstable here, can
> > I mix both, small and unstable, in my local machine?
> I also use unstable for the server because I need some changes that are
> only in unstable.
>
> ___
> 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] Moving binaries from sbin/ to bin/?

[Wout Mertens]

I'm all for it, +1.

Wout.

On Thu, Oct 2, 2014 at 7:04 PM, Bjørn Forsman 
wrote:

> Hi,
>
> Does anyone mind if we (slowly) move binaries from $out/sbin to $out/bin?
>
> Arguments for doing it:
>
> 1) The sbin vs bin distinction is an historic relic from the past. It
> makes little sense on NixOS. (Even a normal (LSB-like) distro like
> ArchLinux has already made the sbin -> bin switch).
>
> 2) It's annoying to have this distinction when writing nix
> expressions, having to figure out which of the two directories is the
> correct one for *this* package.
>
> 3) I just found my second sbin/bin bug caused by sbin being treated as
> a second class citizen in nixpkgs. I noticed that our standard builder
> will not add packages' sbin/ directory to PATH. (The first issue was
> from a long time ago, when sbin wasn't added to PATH by the profile.sh
> script (maybe wrong name) when on a non-NixOS distro.)
>
> 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] Nix OS installation problems - Where's the hard drive?

[Wout Mertens]

What does dmesg say, and what is in /proc/partitions?

Also, what kind of hard disk do you have, simple SATA?

Wout.
On Oct 3, 2014 5:14 AM, "Joseph Joe"  wrote:

> I'm trying to install Nix OS onto my computer. My computer's optical drive
> is broken, so I tried installing using a live usb. But when I boot from a
> live usb, the only recognized harddrive is the usb. So, when I enter the
> command "fdisk -l", the usb is shown to be mounted on
> /dev/sda and there are no other entries.
>
> On the other hand, I was able to install Ubuntu with no problems and
> reformat the harddrive. I can partition and modify the harddrive fine in
> Ubuntu.
>
> I tried making uefi and legacy boot live usbs for Nix OS, and both have
> the same problem.
>
> Any suggestions and help would be well appreciated
>
> -- Joseph Joe
>
> ___
> 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] Popularizing Nixpkgs/Nix/NixOS among FLOSS (Free/Libre and Open Source Software) developers

[Wout Mertens]

Pretty sure this will happen automatically once nixpkgs is more
user-friendly.

Imagine that for example the Discourse team could, instead of distributing
a VM, say "install nix and run nix-env -i discourse", which would install
the ruby environment and the required services on any Unix.

Right now, you can't do that, because ruby on nixpkgs isn't quite there,
and several environment variables are required, and we don't have
nixpkgs-level services.

It's totally doable, just not in place right now.
And it would rock.

Wout.
On Oct 4, 2014 3:37 AM, "Anderson Torres" 
wrote:

> Hello, Nixers!
>
> I was thinking on it some days ago. How about popularize NixOS among
> FLOSS software developers?
>
> It is very common among FLOSS developers to point out precompiled
> packages or some similar facilities for the most famous operating
> systems and distros, like Ubuntu/Debian/Fedora mirrors, Slackware
> unofficial slackbuilds, AUR Archlinux, Gentoo overlays, the famous
> *BSD freshports/pkgsrc...
>
> Why not to contact some of them we are packaging and ask them to cite
> us out? It would be a good idea in many sights:
>
> - We would become more famous, which would attract more hackers to our
> projects;
>
> - We would suggest bugfixes on various softwares, namely those full of
> hackings on Nixpkgs. The Nixpkgs approach is a bit different from
> those of other distros/OSes and it helps to find some obscure bugs,
> mainly the lack of a serious dependency control and some tacit
> assumptions (like ldconfig, absolute paths, undocumented features,
> etc.);
>
> - Our suggestions would be a valuable benefit from all other package
> managers - after all, we are suggesting bugfixes on serious,
> insidious, hard-to-find packaging bugs.
>
> - We can serve as an indirect buildfarm for most of FLOSS world, with
> our Hydra servers. Well, I don't know if our Hydra server is really
> prepared for a so hard and huge task, but it would be even improved
> by donations from great companies (we would be famous now, remember?
> :D )
>
>
> What about this, guys?
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Nix OS installation problems - Where's the hard drive?

[Wout Mertens]

Hi,

No, the live USB doesn't store changes I'm afraid. What you can do is put
the Ubuntu kernel on the liveUSB, and boot using that instead of the
regular one. That should work, I don't think there are any extra-special
kernel features that NixOS needs.

Then you can install NixOS on your HD, but you need the kernel to have the
SAS support.

To change the Linux config on NixOS, you need to edit configuration.nix:
http://nixos.org/nixos/manual/#sec-kernel-config
Just put "CONFIG_SCSI_SAS_ATA y" in there.

In the mean time, also open an issue requesting the kernel to have that
configuration by default.

Wout.

On Sun, Oct 5, 2014 at 3:02 AM, Joseph Joe  wrote:

> Would I be able to recompile the kernel while booting from the NixOS
> live-usb and would these changes be permanent on the live-usb?
>
> Would I just type in these commands (src:
> http://www.linux.com/learn/tutorials/305766-recompile-your-kernel-for-a-perfect-fit
> )?
>
> cd /usr/src/linux
> make clean
> make
> make modules_install
> make install
> reboot
>
> Then, will the appropriate kernel option be set so that my hard drive will
> be detected?
>
> Joseph Joe
>
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] NILFS2, NixOS, nixpart and Blivet

[Wout Mertens]

FWIW, btrfs and ZFS also do non destructive writes, they're Copy on Write.

As a bonus you get unlimited instant snapshots and lots of other wonderful
things.

I prefer btrfs as it has more of a desktop focus and feature set as well as
being in the kernel, but ZFS is more mature.

Wout.
On Oct 5, 2014 11:39 AM, "Nicolas Pierron" 
wrote:

> On Tue, Sep 30, 2014 at 1:08 PM, Tim Barbour  wrote:
> > NILFS2 is a log-structured filesystem which is now in the Linux kernel
> source
> > tree, and supported by GRUB2. It should appeal to NixOS users because it
> > avoids destructive update ("changing" a file produces a new version of
> the
> > file).
> >
> > I have installed NixOS with all filesystems on NILFS2, but encountered
> some
> > problems along the way.
>
> Looking at the details of NILFS2, I saw that it does a linear search
> within directories.  This is far from ideal for the /nix/store as this
> directory is HUGE.  This might have a noticeable cost at the start-up
> of a computer / programs.
>
> --
> Nicolas Pierron
> http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
> ___
> 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] NILFS2, NixOS, nixpart and Blivet

[Wout Mertens]

On Mon, Oct 6, 2014 at 8:04 AM, Tim Barbour  wrote:

> One nice property of NILFS is that every write results in a new checkpoint,
> which makes it very cheap to check whether a filesystem has been modified
> (other than via low-level disk-editing).
>

On btrfs you can look at the generation:
http://www.tummy.com/blogs/2010/11/01/fun-with-btrfs-what-files-have-changed/

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

Re: [Nix-dev] Failure trying to build node package

[Wout Mertens]

Hi Nikolay,

this is a long-known problem with nixpkgs, some packages depend on
environment variables and these don't get set automatically.

To make https work, do `nix-env -i cacert` and then do `export
GIT_SSL_CAINFO=$HOME/.nix-profile/etc/ca-bundle.crt`. git clone should now
work.

We're currently thinking about how to solve these types of problems, see
the thread this month.

Wout.

On Mon, Oct 6, 2014 at 2:46 AM, Nikolay Amiantov  wrote:

> Hello,
> Writing this to nix-dev mailing list since this looks like
> NixOS-specific problem (I can't reproduce it on Arch- or SuSE-running
> machines).
> I'm trying to make a package "parsoid" for Nix, running NixOS and having
> basically no experience in node or js. I've tried to add it to
> node-packages.json and run npm2nix, but it could not get a "pegjs"
> dependency of it. Apparently, it uses forked version of it hosted on
> github, and npm2nix can't get the package. I've tried to clone parsoid
> and run "npm install" manually to see the problem and got this:
>
> npm ERR! git clone https://github.com/arlolra/pegjs Cloning into bare
> repository
> '/home/shlomo/.npm/_git-remotes/https-github-com-arlolra-pegjs-0488b4b2'...
> npm ERR! git clone https://github.com/arlolra/pegjs fatal: unable to
> access 'https://github.com/arlolra/pegjs/': SSL certificate problem:
> unable to get local issuer certificate
> npm ERR! Error: Command failed: Cloning into bare repository
> '/home/shlomo/.npm/_git-remotes/https-github-com-arlolra-pegjs-0488b4b2'...
> npm ERR! fatal: unable to access 'https://github.com/arlolra/pegjs/':
> SSL certificate problem: unable to get local issuer certificate
> npm ERR!
> npm ERR! at ChildProcess.exithandler (child_process.js:648:15)
> npm ERR! at ChildProcess.emit (events.js:98:17)
> npm ERR! at maybeClose (child_process.js:756:16)
> npm ERR! at Socket. (child_process.js:969:11)
> npm ERR! at Socket.emit (events.js:95:17)
> npm ERR! at Pipe.close (net.js:465:12)
> npm ERR! If you need help, you may report this *entire* log,
> npm ERR! including the npm and node versions, at:
> npm ERR! 
>
> I've tried to switch between latest version in "master" and one from
> unstable channels -- no change. There are some mentions of this problem
> on the Internet -- people get advices to update npm[1], but the "master"
> version is the latest, apparently. I don't work behind a proxy, too, and
> "git clone" of this repository (git clone
> https://github.com/arlolra/pegjs/ -b startOffset) works okay. Any ideas?
>
> [1]: https://github.com/npm/npm/issues/3624
>
> Nikolay.
> ___
> 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] Failure trying to build node package

[Wout Mertens]

On Mon, Oct 6, 2014 at 12:18 PM, Nikolay Amiantov  wrote:

>  On 10/06/2014 10:26 AM, Wout Mertens wrote:
>
>  To make https work, do `nix-env -i cacert` and then do `export
> GIT_SSL_CAINFO=$HOME/.nix-profile/etc/ca-bundle.crt`. git clone should now
> work.
>
> Unfortunately, this does not help -- maybe I've misunderstood something?
> Also, "git clone" worked before this. and $GIT_SSL_CAINFO pointed to valid
> path "/etc/ssl/certs/ca-bundle.crt".
>

Ok, weird. Try also setting OPENSSL_X509_CERT_FILE to that file?


> parsoid git:(master) ✗ ls $GIT_SSL_CAINFO
> /home/shlomo/.nix-profile/etc/ca-bundle.crt
> parsoid git:(master) ✗ npm --version
> 2.1.3
> parsoid git:(master) ✗ npm install
> npm ERR! git clone https://github.com/arlolra/pegjs Cloning into bare
> repository
> '/home/shlomo/.npm/_git-remotes/https-github-com-arlolra-pegjs-0488b4b2'...
> npm ERR! git clone https://github.com/arlolra/pegjs warning: templates
> not found /home/shlomo/.npm/_git_remotes/_templates
> npm ERR! git clone https://github.com/arlolra/pegjs fatal: unable to
> access 'https://github.com/arlolra/pegjs/': SSL certificate problem:
> unable to get local issuer certificate
>

So this error means that it can't verify the certificate. Normally, with
GIT_SSL_CAINFO it should be able to find it :-/ Perhaps npm removes the
environment variable?

parsoid git:(master) ✗ git clone https://github.com/arlolra/pegjs/ -b
> startOffset
> Cloning into 'pegjs'...
>

I see that you can clone it yourself, can you try under `nix-shell -p git
--pure` as well?

Note that if you use npm2nix, you should use nix to get the modules, not
npm. See also the work Sander is doing at
https://github.com/svanderburg/npm2nix/tree/reengineering , you might want
to use that version instead.


> We're currently thinking about how to solve these types of problems, see
> the thread this month.
>
> I'm only starting to understand Nix and make contributions, but isn't
> "makeWrapper" a solution?
>

Yes, that's one way and the other is to set user environment variables.
Either way though we'll have to move some settings from /nixos to /pkgs.

However, how do you handle openssl? It's a library so you can't use a shell
wrapper and it needs OPENSSL_X509_CERT_FILE. Should that go into user
environment, into the wrapper for all programs that depend on openssl, or
should we create a wrapper library that loads the library with the correct
environment set (hmm interesting idea but still requires rebuilding things
that depend on it)?

Another interesting one is TZDIR, which is required for glibc to tell
timezones correctly. How do you handle that? You'd have to set it on all
programs that use glibc and in fact even on everything else on the off
chance that there's some library being loaded that uses glibc. So then it
would be better off being set in the user environment but then if you
upgrade the time zone data, the user has to log out for everything to get
the new data. So then you might be even better off pointing it to some path
on disk that has the correct data, like $HOME/.nix-profile/etc/tzdata. But
all users share the same data, so you'd be better off pointing it somewhere
global like /usr/share/zoneinfo, and hardcoding that path in glibc, which
is what all other distros do. On NixOS it's /etc/zoneinfo because there's
no /usr but that means that either on NixOS the TZDIR environment variable
needs to be set for all processes, or glibc needs a different hardcoded
path and nixpkgs installations need to set TZDIR, or glibc for NixOS is
different from glibc for nixpkgs.

Maybe I'm overthinking this :)

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

Re: [Nix-dev] Reengineered npm2nix: call for feedback

[Wout Mertens]

Finally got around to testing this (on Darwin):

   - warn: was a bit confused when the `*nix-build -iA build*` didn't work
   in the git clone until I figured out I wasn't on the reengineered branch ;-)
   - wtf: I was working in a project with a pre-existing node_modules, and
   it was picking up things from there. So I did `*mv node_modules{,.foo}*`,
   and it *_still_* was picking up things from there. Then I did `*mv
   node_modules.foo wtf; chmod 0 wtf*` and it *_*still*_* was picking
   things from there. Huh? I ended up removing it but I'm still wondering what
   happened.
   - warn: I removed my old impure node install, ~/.npm and ~/.npmrc
   because they were interfering with npm2nix. After that things went fine.
   - bug: I noticed that it's asking the registry the same things a few
   times? In my case e.g.
   http://registry.npmjs.org/rimraf/%3E=2.2.0-0%20%3C2.3.0-0 comes back
   several times.
   - rfe: Would be nice if the registry requests were asynchronous, maybe 3
   at a time?
   - rfe: I'm not so happy with it overwriting default.nix... My use case
   is a project that uses grunt and some other things, so I want to have a
   default.nix that has all that defined for running nix-shell, and that means
   default.nix should not be overwritten...
   - rfe: Would be nice if default.nix included an environment definition
   to build (basically what nix-shell -A build does). That way there's a gc
   root to the result
   - notsureifbug: I can't build phantomjs because it can't find the ini
   module, fsevents because it can't find the NanNew definition in v8,
   node-[jpeg-tran-bin pngquant-bin optipng-bin gifsicle] because they can't
   find the stat-mode module. Problems with Darwin or module resolution in
   npm2nix?

For the rest, I <3 these changes, great work! +1 for pulling this into
npm2nix.

Wout.


On Fri, Oct 3, 2014 at 12:06 PM, Domen Kožar  wrote:

> Fantastic README, thanks for the hard work Sander!
>
> On Wed, Oct 1, 2014 at 10:40 AM, Sander van der Burg <
> svanderb...@gmail.com> wrote:
>
>> I haven't implemented any checks so far, but that could be improved. The
>> version number that you specified is actually not a valid semver version
>> specification. A version number should consist of 3 components. Also, I
>> could check for semver validity as well.
>>
>>
>> On Tue, Sep 30, 2014 at 8:55 PM, Paul Colomiets 
>> wrote:
>>
>>> Hi,
>>>
>>> On Tue, Sep 30, 2014 at 1:13 PM, Sander van der Burg
>>>  wrote:
>>> > Hopefully, you can also try npm2nix on your projects to find out
>>> whether
>>> > there any additional issues. :)
>>> >
>>>
>>> If package.json doesn't contains "name" or "version" npm2nix, the
>>> build fails with the following:
>>>
>>> error: `buildNodePackage' at /tmp/react/node-env.nix:33:5 called
>>> without required argument `version', at /tmp/react/registry.nix:5:27
>>>
>>> It would be nicer, if npm2nix fails when generating nix files.
>>>
>>> After I've filled both name and version I've got the following error:
>>>
>>> > nix-build -A build
>>> these derivations will be built:
>>>   /nix/store/6g9vk21ag4rzjl13dnqnq3nabb1hgas0-node-reacttest-0.1.drv
>>> building path(s)
>>> `/nix/store/aksz62alq8903cnp88iv0z36n0lrybjh-node-reacttest-0.1'
>>> building /nix/store/aksz62alq8903cnp88iv0z36n0lrybjh-node-reacttest-0.1
>>> unpacking sources
>>> unpacking source archive
>>> /nix/store/d394a7821m6sn02ymhvfa13c7dac2fiq-react
>>> source root is react
>>> patching sources
>>> configuring
>>> no configure script, doing nothing
>>> building
>>> installing
>>> npm ERR! install Couldn't read dependencies
>>> npm ERR! Error: Invalid version: "0.1"
>>> npm ERR! at Object.module.exports.fixVersionField
>>>
>>> (/nix/store/ih3sbklf4ncxgs84pdi34hq0lk8lrfwg-nodejs-0.10.32/lib/node_modules/npm/node_modules/read-package-json/node_modules/normalize-p$
>>> ckage-data/lib/fixer.js:183:13)
>>> npm ERR! at
>>>
>>> /nix/store/ih3sbklf4ncxgs84pdi34hq0lk8lrfwg-nodejs-0.10.32/lib/node_modules/npm/node_modules/read-package-json/node_modules/normalize-package-data/lib/normalize.js:30:38
>>> npm ERR! at Array.forEach (native)
>>> npm ERR! at normalize
>>>
>>> (/nix/store/ih3sbklf4ncxgs84pdi34hq0lk8lrfwg-nodejs-0.10.32/lib/node_modules/npm/node_modules/read-package-json/node_modules/normalize-package-data/lib/normalize.js$
>>> 29:15)
>>> npm ERR! at final
>>>
>>> (/nix/store/ih3sbklf4ncxgs84pdi34hq0lk8lrfwg-nodejs-0.10.32/lib/node_modules/npm/node_modules/read-package-json/read-json.js:342:33)
>>> npm ERR! at then
>>>
>>> (/nix/store/ih3sbklf4ncxgs84pdi34hq0lk8lrfwg-nodejs-0.10.32/lib/node_modules/npm/node_modules/read-package-json/read-json.js:126:33)
>>> npm ERR! at
>>>
>>> /nix/store/ih3sbklf4ncxgs84pdi34hq0lk8lrfwg-nodejs-0.10.32/lib/node_modules/npm/node_modules/read-package-json/read-json.js:316:48
>>> npm ERR! at evalmachine.:207:20
>>> npm ERR! at OpenReq.Req.done
>>>
>>> (/nix/store/ih3sbklf4ncxgs84pdi34hq0lk8lrfwg-nodejs-0.10.32/lib/node_modules/npm/node_mo

Re: [Nix-dev] Reengineered npm2nix: call for feedback

[Wout Mertens]

Hi sander,

phantomjs is solved, I used --linkdependencies which makes it break :)
Actually, since nix-store allows hardlinking and --linkdependencies doesn't
always work, it might be better to remove the option or at least explain
the type of errors to expect ("module not found").

node-fsevents still doesn't compile though:

building path(s)
`/nix/store/i24rrrjmmsb0pwijpr74gb8vnf61aszx-node-fsevents-0.3.0'
building /nix/store/i24rrrjmmsb0pwijpr74gb8vnf61aszx-node-fsevents-0.3.0
unpacking sources
unpacking source archive
/nix/store/5g00476f06kw0flgaarpwlxggi6rijzd-fsevents-0.3.0.tgz
source root is package
patching sources
configuring
no configure script, doing nothing
building
installing
npm WARN package.json fsevents@0.3.0 bugs.url field must be a string url.
Deleted.
npm WARN package.json fsevents@0.3.0 Normalized value of bugs field is an
empty object. Deleted.
npm WARN package.json fsevents@0.3.0 homepage field must start with a
protocol.

> fsevents@0.3.0 install
/nix/store/i24rrrjmmsb0pwijpr74gb8vnf61aszx-node-fsevents-0.3.0/lib/node_modules/fsevents
> node-gyp rebuild

make: Entering directory
`/nix/store/i24rrrjmmsb0pwijpr74gb8vnf61aszx-node-fsevents-0.3.0/lib/node_modules/fsevents/build'
building Release/obj.target/fse/fsevents.o
  CXX(target) Release/obj.target/fse/fsevents.o
In file included from ../fsevents.cc:86:0:
../src/constants.cc: In function 'v8::Local Constants()':
../src/constants.cc:10:113: error: no matching function for call to
'NanNew()'
   object->Set(NanNew("kFSEventStreamEventFlagNone"),
NanNew(kFSEventStreamEventFlagNone));

 ^
../src/constants.cc:10:113: note: candidates are:
In file included from ../fsevents.cc:6:0:
../node_modules/nan/nan.h:1032:27: note: template v8::Local
NanNew()
   NAN_INLINE v8::Local NanNew() {
   ^
../node_modules/nan/nan.h:1032:27: note:   template argument
deduction/substitution failed:
In file included from ../fsevents.cc:86:0:
../src/constants.cc:10:113: note:   candidate expects 0 arguments, 1
provided
   object->Set(NanNew("kFSEventStreamEventFlagNone"),
NanNew(kFSEventStreamEventFlagNone));

 ^
In file included from ../fsevents.cc:6:0:
../node_modules/nan/nan.h:1037:27: note: template v8::Local
NanNew(v8::Handle)
   NAN_INLINE v8::Local NanNew(v8::Handle arg) {
   ^
[...]

Wout.


On Mon, Oct 6, 2014 at 11:35 PM, Sander van der Burg 
wrote:

> Hi Wout,
>
> Thanks for the feedback. Regarding some of your issues:
>
> - I'm not sure why you're having these weird issues, but if you have a
> node_modules/ folder in your working directory then it's copied into the
> build environment and it's actually used for deployment. This is because I
> also want to support packages having bundledDependencies. These kinds of
> packages also have stuff in their node_modules/ folder and I'm not allowed
> to change these to mimic NPM's behaviour. Instead, I should use them.
> - Yes ~/.npmrc is used, but that's because I use npm's package fetcher
> that seems to require it
> - About downloading: I could indeed optimize the download process a bit by
> running multiple of them at the same time. Also, if I encounter the same
> dependency a second time, still a request is made. In the future I might
> optimize this a bit. On the other hand, it should also not break anything
> so it should not be too problematic.
> - About overwriting default.nix: You can specify the following
> command-line parameter to npm2nix: --composition otherdefault.nix to have
> it named differently (see: README.md).
> - What do you mean by: 'environment definition'?
> - I haven't tried phantomjs yet, but I will have a look at it tomorrow.
> Moreover, I don't have Mac machine at home (since I don't want to buy one
> :) ), but I do have one in the office.
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Nix OS installation problems - Where's the hard drive?

[Wout Mertens]

On Tue, Oct 7, 2014 at 4:49 AM, Joseph Joe  wrote:

> I am still a bit confused. I added the following lines to
> /etc/nixos/configuration.nix
>
> nixpkgs.config.packageOverrides = pkgs:
>   { linux_3_4 = pkgs.linux_3_4.override {
>   extraConfig =
> ''
>   CONFIG_SCSI_SAS_ATA y
> '';
> };
>   };
>
> Actually this will not work unless you're using linux_3_4 which I think
you're not. The better way is what Alexander linked,

 nixpkgs.config.packageOverrides = pkgs: {
   stdenv = pkgs.stdenv // {
 platform = pkgs.stdenv.platform // {
   kernelExtraConfig = "CONFIG_SCSI_SAS_ATA y" ;
 };
   };
 };

(I didn't test this)


> Then I saved the file and entered the command
>
> # nixos-rebuild switch
>

Like Alexander said, that doesn't activate the new kernel until when you
reboot.


> This doesn't work because I am inside the live-usb. But, I can make a
> custom image in the live-boot with this changed configuration file. This
> image will have the configuration I want. Is that correct?
>

No, the live boot doesn't use the normal boot setup, not sure if
nixos-rebuild did anything there.


> Also, how would I put the Ubuntu kernel onto the liveUSB?
>

IIRC, the liveUSB is simply a FAT32 filesystem with kernel and squashed
root filesystem, so you'd copy the ubuntu kernel on it as well and convince
the boot loader to use it. Anyway, you might have problems with providing
modules.

Here's two other approaches:

   - Take an empty USB stick and install NixOS on that from the liveUSB,
   with the kernelconfig as above. Then boot from that and install nixos on
   your harddisk.
   - Install nixos in-place from your current Linux using the techniques
   discussed in https://github.com/NixOS/nixpkgs/issues/2079 , namely
   install nix as root (or multiuser) on your current linux, then build nixos
   into /nixos and boot using /nixos as the root directory. There's no script
   that does that for you yet though.

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

Re: [Nix-dev] Anyone care to review my post on the Nix expression language?

[Wout Mertens]

Hi James,

great reading, I learned a few things! (like that let is a recursive
definition, doh :) )

Nix does support the / operator, but it needs spaces or it will be
recognized as a path:
 $ nix-instantiate --eval --expr '4/3'
/Users/wmertens/4/3
 $ nix-instantiate --eval --expr '6 / 3'
2

https://github.com/NixOS/nix/blob/b6809608cc467925db44b1eb435095c37e433255/src/libexpr/parser.y#L347

Wout.

PS: (You know that the default-values example is still marked TODO, right?)



On Wed, Oct 8, 2014 at 11:31 AM, Ellis Whitehead 
wrote:

> Hi James.  For what it's worth: I haven't finished it yet, but I've
> enjoyed the reading so far.
>
> On Wed, Oct 8, 2014 at 12:21 AM, James Harrison Fisher
>  wrote:
> > Hi all,
> >
> > I’ve written up what turned out to be a quite extensive post on the Nix
> expression language:
> >
> > https://medium.com/@MrJamesFisher/nix-by-example-a0063a1a4c55
> >
> > I was hoping that someone with more knowledge than me could read it and
> comment on inaccuracies. I’m sure there will be some, since I’m learning
> while writing.
> >
> > Any and all comments appreciated!
> >
> > Best,
> >
> > James
> > ___
> > 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] Failure trying to build node package

[Wout Mertens]

On Mon, Oct 6, 2014 at 3:52 PM, Nikolay Amiantov  wrote:

>
> On 10/06/2014 03:36 PM, Wout Mertens wrote:
>
>> Ok, weird. Try also setting OPENSSL_X509_CERT_FILE to that file?
>>
> OPENSSL_X509_CERT_FILE was originally set to same path as GIT_SSL_CAINFO.
> Setting it to /home/... did no effect.
>
>> So this error means that it can't verify the certificate. Normally, with
>> GIT_SSL_CAINFO it should be able to find it :-/ Perhaps npm removes the
>> environment variable?
>>
> A quick grep showed that at least it doesn't fiddle with these variables
> at least, though it can clean the environment completely. It would be
> strange, though -- it then would need to set this variables, and grep found
> nothing.
>
>> I see that you can clone it yourself, can you try under `nix-shell -p git
>> --pure` as well?
>>
> Can't verify the certificate. Setting GIT_SSL_CAINFO helps.


Solution: => https://github.com/npm/npm/pull/6442

Also, git should have this wrapped.


> However, how do you handle openssl? It's a library so you can't use a
>> shell wrapper and it needs OPENSSL_X509_CERT_FILE. Should that go into user
>> environment, into the wrapper for all programs that depend on openssl, or
>> should we create a wrapper library that loads the library with the correct
>> environment set (hmm interesting idea but still requires rebuilding things
>> that depend on it)?
>>
>

> To tell the truth, I've started thinking about it after sending a reply.
> When we use nix stand-alone, do we require user to load some kind of
> environment? I've arrived to the last option (wrapper libraries, I've even
> done something like that), but I haven't thought of rebuilding problem.
> What's the problem with containing it within user environment?


Yes, the user has to source ~/.nix-profile/etc/profile.d/nix.sh. This adds
the user environment to the path. It doesn't include the environment
variables that NixOS defines.

If you contain it in the user environment, the environment variables are
fixed at shell-load-time. In NixOS this could be the start of your desktop
session, on bare nixpkgs it is more likely to just be your terminal.

If the settings need to change, the user needs to logout.

If you use wrapper scripts and libraries, the settings are changed at
runtime, so if you install a new wrapper, new invocations will use the new
settings. However new wrappers mean new inputs and thus rebuilding, which
is exactly why tzdata is not a defined input of glibc but only available
through the environment.

Do we support "different tzdatas" and "different certfiles" on the system?
>
>
Different tzdata doesn't make much sense IMHO, but different certfiles
does, because people don't all trust the same certificates.


> If not, then I would use "$HOME/.nix-profile/etc/tzdata", which would be
>> a symlink to the real tzdata. That would work on NixOS and other
>> distributions as well. I just had an idea of using that to store some kind
>> of "environment", which could be read by LD_PRELOADed or dynamically linked
>> extra library (which may avoid rebuild, then), or nix-shell, for example.
>> This would solve the problem with certificates. Advantages of the first
>> solution is that we have no need to set the environment before running any
>> executable, but I don't like this approach for the need of load some extra
>> library that would use __constructor -- that looks "hacky" for me.
>
>
I don't like LD_PRELOAD at all, it doesn't work on static binaries for
example. A wrapper library that dl_open()s the wrapped library after
changing its environment is better, but not sure if changing processes'
environment variables while they're running is a good idea.

Basically, we strive for compile-time binding of all inputs. This means
that for any change we might have to rebuild the entire system.
As a first optimizing approximation, we create wrappers instead of
hardcoding configuration files.

I noticed that the nix.sh environment script now sets the SSL_CERT_FILE
environment variable. Perhaps there are so few cases that they can all be
hardcoded there. And then git (which has a wrapper anyway) can use that
variable to set its own GIT_SSL_CAINFO.

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

Re: [Nix-dev] nix on compute cluster?

[Wout Mertens]

I think you could do this. You would set it up so the nix server does the
compiles and the grid runs distcc. See the wiki, the raspberry pi page has
explanations about distcc.

Note that only one node can write to nix store at the same time due to the
db.

Another option is to have private nix stores on all nodes but nfs mount all
of them under the remote stores directory. That way nix-store will fetch
missing packages from the remotes and store them locally. At least, that's
my understanding.

As for the Intel compiler, that could be a challenge, but right now we have
several gcc versions and clang, so it's not impossible. You can decide on a
per-package basis which compiler to use.

Not sure how mpi would influence state, can you elaborate?

The rest is totally doable.

Wout.
(on phone, sorry for brevity)
On Oct 10, 2014 1:34 PM, "Andreas Herrmann"  wrote:

> Hi,
>
> How would you go about bringing the benefits of Nix to the users of a
> compute cluster?
>
> Assume the following cluster: A login node, a file-system node, and a
> number of compute nodes. All nodes run on a recent CentOS and are fairly
> homogeneous. The fs node holds all user data and some common libraries. Its
> storage is nfs mounted on all other nodes.
>
> Users ssh into the login node, write and compile some code, then they use
> the Sun Grid engine (sge) to submit compute jobs, and once these are
> finished they copy the results on their workstations and are happy.
>
> There are subgroups of users with fairly exotic software requirements.
> These are not available in any package repositories, and the cluster admin
> doesn't have the time to install and maintain them. So, currently, most of
> these users just compile everything themselves in their home-directory,
> which is a huge waste of time, and storage space.
>
> I would like to suggest Nix to the admin as a way to let these
> user-subgroups manage their own packages, but that in a well organized
> manner, that avoids redundant work, and storage. But, I'm not sure how
> exactly that should work.
>
> There are a few constraints:
>
>   1. Unfortunately, NixOS/nixops is not an option. This will have to work
> with the currently installed cluster OS.
>   2. Compilation should not put too much load on the login node. Ideally,
> build jobs would be referred to the compute nodes.
>   3. Build jobs on the compute nodes should be managed by the sge.
>   4. (Some) users should be allowed to initiate builds, and use their own
> overloads of packages, and extra packages.
>   5. Some impurity is necessary. Be it for things that are hard to package
> (e.g. intel compiler), or for global state (mpi jobs).
>
> My question to you: Do you think this is possible to achieve (within a
> reasonable time-frame), and how would you do it?
>
> Here's what I have in mind so far (please feel free to take it apart if
> you think there is a better way):
>
> Have a nix-store on the file-server, nfs mount that on all nodes (cached).
> The login node runs the nix-daemon. Builds are deferred to the grid-engine
> (how?) which are executed on the compute nodes, and store the results on
> the nfs mounted nix-store. Users would use `nix-env` on the login node to
> install software into their profile. This profile should be visible on all
> nodes, so that jobs can use those libraries and tools in the nix-profile.
> Things like myEnvFun should allow running jobs in different software
> environments simultaneously.
>
> Best,
>
> Andreas
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] nix on compute cluster?

[Wout Mertens]

On Fri, Oct 10, 2014 at 4:34 PM, Andreas Herrmann  wrote:

> Thank you for the detailed answer.
>
> On Friday 10 October 2014 15:32:52 Wout Mertens wrote:
> > I think you could do this. You would set it up so the nix server does the
> > compiles and the grid runs distcc. See the wiki, the raspberry pi page
> has
> > explanations about distcc.
> Oh, I didn't know that this worked outside of NixOS. I just can't find any
> details on how to integrate distcc with sge. Do you have any experience
> with that?
>

No sorry, but I'd just install distcc as a daemon on all nodes or else use
sge for the distribution somehow... pretend that they're super long running
batch jobs...


> > Note that only one node can write to nix store at the same time due to
> the
> > db.
> That's interesting. The multi-user nix manual says that you can have
> multiple build users on one machine. Why does that work on one machine, but
> not spread over several machines? I would assume that you need to connect
> to some kind of db daemon anyway?
>

it's because of sqlite, it is safe on a single machine but not on NFS...

> Another option is to have private nix stores on all nodes but nfs mount
> all
> > of them under the remote stores directory. That way nix-store will fetch
> > missing packages from the remotes and store them locally. At least,
> that's
> > my understanding.
> I don't think I understand this. By private, do you mean one per user? And
> how do we mount all of them under one directory, do you mean some layered
> fs?
>

No I mean one per node, so on the local disk. 50GB should be ok I think, or
a few GB if that's hard but then do nix-collect-garbage often.


> > As for the Intel compiler, that could be a challenge, but right now we
> have
> > several gcc versions and clang, so it's not impossible. You can decide
> on a
> > per-package basis which compiler to use.
> Yes, my main concern are things like license keys, or - even worse -
> license servers. I don't know how to approach these things in nix. As long
> as you can mix your nix environment with an external environment this is
> not an issue. So, as a simple example, you could use nix to manage your
> version of boost, but use an intel compiler that is installed outside of
> nix for user code.
>

so that's a bit harder. If you need a license connection and for the rest
the build is stateless, you can make that work I think. You'd probably need
to cheat with a userhook for stdenv to get the license connection info in
there though.

> Not sure how mpi would influence state, can you elaborate?
> I meant this on a per job basis. In the case of mpi jobs the sge will
> decide which nodes your job will be distributed over. This information will
> be passed by a mixture of config files and environment variables. Hence,
> such jobs would not work inside a pure nix-shell, because the environment
> needs to be passed through. I don't think it's a big issue. Just something
> to keep in mind.
>

more userhooking :) See
https://nixos.org/wiki/Raspberry_Pi#Implementing_distcc

Cheers,

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

Re: [Nix-dev] Nix OS installation problems - Where's the hard drive?

[Wout Mertens]

Hmmm, maybe it's missing other required kernel parameters?

http://cateee.net/lkddb/web-lkddb/SCSI_SAS_ATA.html seems to suggest you
also need to set CONFIG_SCSI_SAS_LIBSAS. I don't know how to run the kernel
configurator on nixos :(

As part of the install, it downloads the nixpkgs expressions to /nix/store:

$ ls /nix/store/*/nixpkgs/nixos/release.nix
/nix/store/5mpw0lr921jswgx6ilgb0587q1vlac73-user-environment/nixpkgs/nixos/release.nix
/nix/store/p3wrav40j6gxgpnmi75s69jsdwfsc0v6-nixpkgs-14.10pre50084.b360955/nixpkgs/nixos/release.nix
/nix/store/psnp5nnxb2v1prsznvj1rrm3md5q515j-user-environment/nixpkgs/nixos/release.nix
/nix/store/sf36k00idxxvgm2rx8yff5lmnmln75jk-nixpkgs-14.10pre50188.0b23b5b/nixpkgs/nixos/release.nix

So you need to pick one of those as your NIX_PATH.

Wout.

On Fri, Oct 10, 2014 at 5:34 PM, Joseph Joe  wrote:

> I also have a working NixOS on a laptop now (The live-usb recognized
> this harddrive).
>
> I added the kernelConfig parameter in my configuration.nix file
> (attached), but
> there are build errors. Specifically, after running nixos-rebuild
> switch, it ends with the following output:
>
> GOT:
> GOT: #
> GOT: # configuration written to .config
> GOT: #
> building config
> GOT: make: Leaving directory
> `/tmp/nix-build-linux-config-3.12.28.drv-0/linux-3.12.28'
> unused option: CONFIG_SCSI_SAS_ATA
> builder for `/nix/store/0xynni7sbs8ck8p7cri356ryn3dfif
> qp-linux-config-3.12.28.drv'
> failed with exit code 255
> cannot build derivation
> `/nix/store/5fl9127mvpvjswhlsj02lzvs121ha98m-linux-3.12.28.drv': 1
> dependencies couldn't be built
> cannot build derivation
> `/nix/store/niq6zlss38cqyg28mkqx42d214kfm2vh-nixos-14.04.519.b9bde98.drv':
> 1 dependencies couldn't be built
> error: build of
> `/nix/store/niq6zlss38cqyg28mkqx42d214kfm2vh-nixos-14.04.519.b9bde98.drv'
> failed
>
> Is there an error in my configuration file?
>
> Also, for creating an iso out of a NixOS configuration, I need to run
> these commands:
>
>  (https://nixos.org/wiki/Creating_a_NixOS_live_CD)
> export NIX_PATH=$NIXREPOS
> nix-build -A iso_graphical.x86_64-linux $NIXREPOS/nixos/release.nix
>
> But, there is no file release.nix on my computer.
>
>
> ___
> 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] Seg fault on Arch

[Wout Mertens]

Unset your LD_LIBRARY_PATH and vote for
https://github.com/NixOS/nix/pull/366 .

Wout.

On Oct 13, 2014 6:42 PM, "Richard Wallace" 
wrote:

> Hey all,
>
> All of a sudden I'm seeing seg faults with any nix-* commands.  Probably
> due to some Arch package upgrade.  I tried reinstalling nix but that fails
> with a seg fault too.  Anyone else seeing the same and figured out a fix?
>
> Thanks,
> Rich
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Nix OS installation problems - Where's the hard drive?

[Wout Mertens]

Hi Joseph Joe,

It seems your kernel configuration didn't make it into your image.

This is where the configuration is read into the evaluation:
https://github.com/NixOS/nixpkgs/blob/master/nixos/default.nix#L1

So it either reads the file pointed to by $NIXOS_CONFIG or it gets
nixos-config from the NIX_PATH.

=> NIXOS_CONFIG=$PWD/myconfig.nix nix-build ""
-A iso_graphical.x86_64-linux

Wout.

On Tue, Oct 14, 2014 at 5:29 AM, Joseph Joe  wrote:

> David, the command
>
> $ nix-build "" -A iso_graphical.x86_64-linux
>
> worked and created an iso. I made a live usb with it, but the problem
> persists. Upon booting, the only available hard drive is the usb.
>
> So, the iso did not use the system configuration.nix file.
>
> Alexander, could you elaborate on what I'd need to copy and change to
> embed these kernel changes? I tried to add the same lines of code (...
> SCSI_SAS_ATA y) into release.nix, but got an error saying that
> release.nix is part of a read only file system.
>
> On Sat, Oct 11, 2014 at 1:10 AM, David Guibert 
> wrote:
> >
> > Hi,
> >
> > On Sat, Oct 11, 2014 at 8:20 AM, Joseph Joe  wrote:
> > > I now would like to create an image file from the configuration.
> > >
> > > I issued the command:
> > > $ export NIX_PATH=$NIXREPOS
> >
> > check both variables
> > $ echo $NIX_PATH
> > /nix/var/nix/profiles/per-user/root/channels/nixos
> >
> > You could also set it to your working directory of nixpkgs.
> >
> > > But, the command:
> > > $ nix-build -A iso_graphical.x86_64-linux $NIXREPOS/nixos/release.nix
> >
> > Do build an ISO, you could use
> >
> > $ nix-build "" -A iso_graphical.x86_64-linux
> >
> > "" will be substituted by the path of nixpkgs by looking up
> > inside $NIX_PATH.
> > --
> > Regards, David
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Nix OS installation problems - Where's the hard drive?

[Wout Mertens]

Argh that's wrong, it's not reading default.nix but release.nix which
doesn't let you specify a config. Thinking about that.

On Tue, Oct 14, 2014 at 9:54 AM, Wout Mertens 
wrote:

> Hi Joseph Joe,
>
> It seems your kernel configuration didn't make it into your image.
>
> This is where the configuration is read into the evaluation:
> https://github.com/NixOS/nixpkgs/blob/master/nixos/default.nix#L1
>
> So it either reads the file pointed to by $NIXOS_CONFIG or it gets
> nixos-config from the NIX_PATH.
>
> => NIXOS_CONFIG=$PWD/myconfig.nix nix-build ""
> -A iso_graphical.x86_64-linux
>
> Wout.
>
> On Tue, Oct 14, 2014 at 5:29 AM, Joseph Joe  wrote:
>
>> David, the command
>>
>> $ nix-build "" -A iso_graphical.x86_64-linux
>>
>> worked and created an iso. I made a live usb with it, but the problem
>> persists. Upon booting, the only available hard drive is the usb.
>>
>> So, the iso did not use the system configuration.nix file.
>>
>> Alexander, could you elaborate on what I'd need to copy and change to
>> embed these kernel changes? I tried to add the same lines of code (...
>> SCSI_SAS_ATA y) into release.nix, but got an error saying that
>> release.nix is part of a read only file system.
>>
>> On Sat, Oct 11, 2014 at 1:10 AM, David Guibert 
>> wrote:
>> >
>> > Hi,
>> >
>> > On Sat, Oct 11, 2014 at 8:20 AM, Joseph Joe  wrote:
>> > > I now would like to create an image file from the configuration.
>> > >
>> > > I issued the command:
>> > > $ export NIX_PATH=$NIXREPOS
>> >
>> > check both variables
>> > $ echo $NIX_PATH
>> > /nix/var/nix/profiles/per-user/root/channels/nixos
>> >
>> > You could also set it to your working directory of nixpkgs.
>> >
>> > > But, the command:
>> > > $ nix-build -A iso_graphical.x86_64-linux $NIXREPOS/nixos/release.nix
>> >
>> > Do build an ISO, you could use
>> >
>> > $ nix-build "" -A iso_graphical.x86_64-linux
>> >
>> > "" will be substituted by the path of nixpkgs by looking up
>> > inside $NIX_PATH.
>> > --
>> > Regards, David
>>
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Nix OS installation problems - Where's the hard drive?

[Wout Mertens]

Ok, I propose that on your working Nix install:

   1. you fork (github) and clone nixpkgs
   2. do a nix-channel --update (use unstable channel) and checkout the
   revision it's at (see the last bit of the downloaded file)
   3. you edit the file pkgs/os-specific/linux/kernel/common-config.nix to
   insert the SCSI_SAS_ATA y line at line 62
   4. you run: nix-build ./nixos/release.nix -A iso_graphical.x86_64-linux
   (or iso_minimal.x86_64-linux if you want it faster)
   5. test the result
   6. if it works, commit your change and do a PR :)


Wout.


On Tue, Oct 14, 2014 at 10:09 AM, Wout Mertens 
wrote:

> Argh that's wrong, it's not reading default.nix but release.nix which
> doesn't let you specify a config. Thinking about that.
>
> On Tue, Oct 14, 2014 at 9:54 AM, Wout Mertens 
> wrote:
>
>> Hi Joseph Joe,
>>
>> It seems your kernel configuration didn't make it into your image.
>>
>> This is where the configuration is read into the evaluation:
>> https://github.com/NixOS/nixpkgs/blob/master/nixos/default.nix#L1
>>
>> So it either reads the file pointed to by $NIXOS_CONFIG or it gets
>> nixos-config from the NIX_PATH.
>>
>> => NIXOS_CONFIG=$PWD/myconfig.nix nix-build ""
>> -A iso_graphical.x86_64-linux
>>
>> Wout.
>>
>> On Tue, Oct 14, 2014 at 5:29 AM, Joseph Joe  wrote:
>>
>>> David, the command
>>>
>>> $ nix-build "" -A iso_graphical.x86_64-linux
>>>
>>> worked and created an iso. I made a live usb with it, but the problem
>>> persists. Upon booting, the only available hard drive is the usb.
>>>
>>> So, the iso did not use the system configuration.nix file.
>>>
>>> Alexander, could you elaborate on what I'd need to copy and change to
>>> embed these kernel changes? I tried to add the same lines of code (...
>>> SCSI_SAS_ATA y) into release.nix, but got an error saying that
>>> release.nix is part of a read only file system.
>>>
>>> On Sat, Oct 11, 2014 at 1:10 AM, David Guibert 
>>> wrote:
>>> >
>>> > Hi,
>>> >
>>> > On Sat, Oct 11, 2014 at 8:20 AM, Joseph Joe  wrote:
>>> > > I now would like to create an image file from the configuration.
>>> > >
>>> > > I issued the command:
>>> > > $ export NIX_PATH=$NIXREPOS
>>> >
>>> > check both variables
>>> > $ echo $NIX_PATH
>>> > /nix/var/nix/profiles/per-user/root/channels/nixos
>>> >
>>> > You could also set it to your working directory of nixpkgs.
>>> >
>>> > > But, the command:
>>> > > $ nix-build -A iso_graphical.x86_64-linux $NIXREPOS/nixos/release.nix
>>> >
>>> > Do build an ISO, you could use
>>> >
>>> > $ nix-build "" -A iso_graphical.x86_64-linux
>>> >
>>> > "" will be substituted by the path of nixpkgs by looking up
>>> > inside $NIX_PATH.
>>> > --
>>> > Regards, David
>>>
>>
>>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

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

[Wout Mertens]

Sounds good, we have travis in place that can do the check for small
changes (x64 only) and the staging branch that serves as inbound.

Too bad github doesn't make it easy to move a PR to another branch... We
should all ask for that feature.

On Sat, Oct 25, 2014, 17:46 Nicolas Pierron 
wrote:

> We have 2 solution, either we stop the regressions when a pull request
> (PR) is made, or we stop it when the fire is in.  The fireman role is
> hard to keep, and we should be verifying as much as possible at the PR
> time.  Also, if we want to avoid firemans, we probably want to forbid
> pushing patches to the repository without having made a pull request
> at first.  Which means, no more massive updates without checks.
>
> One other way, is to have an "inbound", and a "nightly" branch.  Every
> day, we merge in "nightly", the last green-build  of the "inbound"
> branch which got tested by Hydra.  This way we do not have a strict
> policy for pushing to "inbound".  The only policy being that nobody
> merge into "inbound" if it is broken.  This is the model used by
> Mozilla.
>
>
> On Fri, Oct 24, 2014 at 12:31 PM, Vladimír Čunát  wrote:
> > On 10/23/2014 08:29 PM, Domen Kožar wrote:
> >>
> >> I'm +1 on this one. Hydra evaluates nixpkgs very fast.
> >>
> >> I'm only worried if the email is per build, not per jobset evaluation.
> >> Is that the case?
> >
> >
> > I don't think it's per-build. I'd expect one e-mail per evaluation to all
> > who committed in-between.
> >
> > The merged PR: https://github.com/NixOS/hydra/pull/126
> >
> >
> > Vladimir
> >
> >
> >
> > ___
> > nix-dev mailing list
> > nix-dev@lists.science.uu.nl
> > http://lists.science.uu.nl/mailman/listinfo/nix-dev
> >
>
>
>
> --
> Nicolas Pierron
> http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
> ___
> 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] Please "star" the nixpkgs repo

[Wout Mertens]

I just noticed that https://github.com/NixOS/nixpkgs has more forks than
stars.
Stars are a merit indicator on github - more stars means more popular, more
eyeballs, more users etc.

So I think we should all be making sure we starred
https://github.com/NixOS/nixpkgs .

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

Re: [Nix-dev] NixOS Live CD (Graphic) Boot Failure

[Wout Mertens]

So did you try switching/reseating the cable? Perhaps put the drive on a
different port? It does seem to be hardware from search results.

It could be that Linux exercises the disk differently from Windows...

Of course it is odd that the Linux mint one works. It would be interesting
to see which kernel options are enabled vs on nixos...

On Mon, Nov 3, 2014, 14:21 J. Brian Kelley  wrote:

> Well, I used Windows to check the S.M.A.R.T. and all is good. Besides if
> there were a connection problem, Windows 7 would be at best capriciously
> unstable and other distros / live-cds would have disk access problems.
>
> The unstable Nov 1 NixOS has the exact same problem and I even repeated
> this with the i686 version although I believe my Core 2 Duo 7200 belongs
> to the x86-64 class (if only barely).
>
> One of my problems is not knowing how to stop things scrolling off the
> screen. (It should be noted that I had the sequence of the eternally
> repeated error message triplet wrong - the exception is first, then the
> irq-stat and last the SError.) The errors present immediately after the
> nixos login prompt is displayed.
>
> Best to have full disclosure on the drive. It is a Seagate
> ST2000DX001-1CM164 with 2 TB (really 1.8) capacity and 64 MB cache, but
> it is also a hybrid with an 8 GB nand flash front end.
>
> Rearranging the deck chairs (partitions) with the gparted live-cd so
> that the extended partition reaches the end of the drive made no
> difference (although the Windows system 'feels' faster, which may simply
> be a placebo effect).
>
> What more can I do? It seems pointless to attempt a NixOS install using
> the Linux Mint live-cd as sooner or later, the NixOS build will have to
> be booted and most likely will contain the same problem.
>
> Thanks for your interest.
>
> On 2014-11-02 23:37, Raahul Kumar wrote:
> > Use  smartctl, and check that the hard drive cable is properly seated.
> > That seems to have fixed the same issue for previous people who had
> > this problem
> >
> > https://bbs.archlinux.org/viewtopic.php?id=129401
> > https://bbs.archlinux.org/viewtopic.php?id=135306
> >
> > If the hard drive is fine, the download the newest Nixos from here
> >
> > https://nixos.org/releases/nixos/unstable/nixos-14.11pre51857.788a77d/
> >
> > Burn it to a dvd or usb stick and retry. Are you in business now
> >
> > Aloha,
> > RK.
> >
>
> ___
> 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 Live CD (Graphic) Boot Failure

[Wout Mertens]

How does SSH influence your system not booting? I'm not sure I understand...

>From what I can tell the error happens in the kernel which points to the
kernel configuration as a possible source of problems... Can you figure out
what the kernel configuration of the linux mint livecd is?
http://stackoverflow.com/questions/14958192/getting-config-from-linux-kernel-image

On Mon Nov 03 2014 at 9:42:33 PM J. Brian Kelley  wrote:

>  Following up, I came across this:
>
> https://github.com/NixOS/nixpkgs/issues/4748
>
> Could this be related to my problem?
>
>
>  Forwarded Message   Subject: Re: [Nix-dev] NixOS Live CD
> (Graphic) Boot Failure  Date: Mon, 03 Nov 2014 11:26:33 -0500  From: J.
> Brian KelleyTo: Wout Mertens
>  , Raahul Kumar
>CC: nix-dev
>  
>
>
> I agree that the problem is hardware related, but I cannot see any
> indication that the drive / controller is malfunctioning. Remember that
> I have just run the gparted live-cd (Debian) against the drive for hours
> rearranging the "deck chairs". NixOS is the only distro I have tried
> that is malfunctioning in this area.
>
> I suspect that this is an "enumeration" (is that a general or
> Windows-specific term?) problem which is unique to whatever approach the
> NixOS packagers have selected to use. If so, the question is how to
> identify it.
>
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] NixOS Live CD (Graphic) Boot Failure

[Wout Mertens]

Can you try the modprobe configs that was suggested?

Opening an issue won't help, we can't reproduce and we're the same guys :-)

On Tue, Nov 4, 2014, 20:17 J. Brian Kelley  wrote:

> As a last attempt, I burned the minimal ISO and tried booting it.
>
> Exactly the same result - goes nicely until it shows the login prompt
> whereupon the error message triplets start (doesn't even newline down
> from the prompt so the first error message is offset somewhat).
>
> Seems a bit strange that they start at the point that a keyboard input
> is required - could the fact that the keyboard is PS/2 connected be a
> factor?
>
> I'm really grasping at straws - do I submit a bug report that simply
> says install iso(s) don't work?
>
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Travis false-positives

[Wout Mertens]

Isn't travis a special case for the dynamic cache? It only runs 2 jobs at
most and only when a PR comes in or a commit is done. Basically it's an
extension of Hydra except that it builds PRs and doesn't save build
products...
Seems to me that it is fine for it to use the dynamic binary cache...

On Sun Nov 02 2014 at 1:38:56 PM Luca Bruno  wrote:

> I can try re-enable my hydra trunk-combined for this. Only x86-64, is that
> fine?
>
> On Sun, Nov 2, 2014 at 11:24 AM, Georges Dubus 
> wrote:
>
>> Hello
>>
>> I'm the one who set up travis. I usually monitor the pull requests for
>> false positives, but I've missed this one. It is now fixed.
>>
>> The travis hook is there:
>> https://github.com/NixOS/nixpkgs/blob/master/maintainers/scripts/travis-nox-review-pr.sh,
>> and it uses nox-review, which can be found there:
>> https://github.com/madjar/nox. I think of it more as proof of concept of
>> what CI on the pull requests can bring us than a final testing workflow.
>> When NixOS dominates the world, we'll have enough servers to run something
>> like that on Hydra.
>>
>> Which brings be to the second point: Hydra's dynamic cache. I didn't know
>> it wasn't supposed to be used, so I though it might be a good way to avoid
>> recompiling stuff on travis (and risk reaching the time limit). If that's a
>> problem, I'll remove stop using this cache for Travis, and if that's a
>> problem for Travis, i'll try to find another solution (I might be able to
>> run a build bot on some servers of mine).
>>
>> However, I was under the impression that "http://hydra.nixos.org/nar";
>> was the recommended cache for anyone running on the master branch of
>> nixpkgs. If that's the case, shouldn't we find a way to make it less
>> stressing?
>>
>>
>> --
>> Georges
>>
>> 2014-11-01 20:25 GMT+01:00 Vladimír Čunát :
>>
>>> Hi, speaking of travis...
>>> The logs suggest that it fetches from Hydra's dynamic cache (
>>> http://hydra.nixos.org/nar/*). Wasn't that supposed to be too stressing
>>> for everyday usage? Or am I missing something?
>>>
>>> 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
>>
>>
>
>
> --
> www.debian.org - The Universal Operating System
>  ___
> 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] Travis false-positives

[Wout Mertens]

How about putting a caching proxy like Squid in front so the nars are
cached?

I'd be happy to set it up for you if you don't have time...

On Wed, Nov 5, 2014, 09:56 Rob Vermaas  wrote:

> Hi,
>
>
>> Isn't travis a special case for the dynamic cache? It only runs 2 jobs at
>> most and only when a PR comes in or a commit is done. Basically it's an
>> extension of Hydra except that it builds PRs and doesn't save build
>> products...
>> Seems to me that it is fine for it to use the dynamic binary cache...
>>
>
> Indeed. The amount of pulls from hydra.nixos.org from Travis is pretty
> limited, so it is ok to use for this. We just don't want a large group of
> people using it continuously, as the binary cache of hydra.nixos.org only
> generates nars on-the-fly, and it has no caching of these nars, so they put
> a significant load on the main Hydra machine, which is already under heavy
> CPU and IO pressure.
>
> Cheers,
> Rob
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] configurations repository

[Wout Mertens]

On one hand this is better than on a wiki because it stays up to date.
On the other hand it's kind of weird to give other people write access to
your own configurations...

I also found https://nixos.org/wiki/Real_World_NixOS_Dotfiles , maybe that
would be enough, just mention it in the readme and give it a prominent
place on the wiki main page?

Wout.

On Wed, Nov 5, 2014, 11:06 Cillian de Róiste 
wrote:

> On Tue, Nov 4, 2014 at 11:20 PM, Michael Raskin <7c6f4...@mail.ru> wrote:
> >>That's awesome idea. But I think we have to add lots of comments to this
> >>examples (that help a lot while using live code). Or maybe just provide
> >>some ideal configs with comments and other without them.
> >
> > I think we need to throw some live configs like we had in SVN:
> > https://nixos.org/websvn/nix/configurations/trunk/
> >
> > and then 1) there is an incentive to commit real configs when people ask
> > questions, 2) we can add some ideal configs, maybe in a tutorial/
> > subdirectory.
>
> +1
>
> I have learned (and borrowed) a lot from your configs in particular
> Michael. Having some ideal configs would also be great. It should even
> be pretty easy to add generic configurations which would be equivalent
> to task specific distros that could simply be added to imports e.g. a
> high security config or a pro-audio workstation config. Of course, the
> ability to mix and match these in NixOS would be far superior to
> running a separate distro for each task.
>
>
>
> --
> NixOS: The Purely Functional Linux Distribution
> http://nixos.org
> ___
> 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] Travis false-positives

[Wout Mertens]

On Wed Nov 05 2014 at 4:04:40 PM Eelco Dolstra 
wrote:

> Hi,
>
> On 05/11/14 12:02, Wout Mertens wrote:
>
> > How about putting a caching proxy like Squid in front so the nars are
> cached?
>
> There already is an Apache reverse proxy in front of it. Since mod_proxy
> supports caching, it's probably not hard to enable it (though Hydra may
> need to
> provide the right HTTP headers for cacheability).


Probably no headers are necessary. Here's the best setup document I could
find:
https://confluence.atlassian.com/display/DOC/Configuring+Apache+to+Cache+Static+Content+via+mod_disk_cache

The htcacheclean cron job is pretty important :)

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

Re: [Nix-dev] nix-multi-user installation script

[Wout Mertens]

On Tue Oct 28 2014 at 10:15:03 PM Andreas Herrmann 
wrote:


> in the past two weeks or so I have been experimenting with Nix multi-user
> mode. My goal was to be able to reliably install Nix in multi-user mode on
> a CentOS 6.5 machine. The result of this was a bash script which pretty
> much automates the whole process [1]. The script is still a bit rough
> around the edges, but I got it working repeatedly and reliably on fresh
> CentOS 6.5 installations.
>

Yey!


> I would like to ask you guys to have a look at this script and tell me
> what you think of it. Do you think it could be valuable to add something
> like this as an automated installer to the official Nix distribution
> similar to the one for single-user mode?
>

Definitely, although I think it would be best to have it as script to run
after one already installed Nix. That way, existing installs can just be
converted.

I'm taking a look at the script for Debian.

I did come up with a few specific questions during the course of this:
>

>  * The nix-daemon is not daemonizing itself. Why is that?
> On debian this is not a problem thanks to `start-stop-daemon`. On
> CentOS I ended up writing a wrapper script.
>

Self-daemonizing daemons are not so wonderful. It's nicer to have a
watchdog daemon doing the background running and logging, and it makes the
program a little simpler.

Besides, you can daemonize anything from the shell simply by closing stdin
and running in the background:

$ run_as_daemon >$LOGFILE 2>&1 <&- & echo $! > $PIDFILE

The shell does the right thing, disassociating the child when it exits etc.

 * The chroot build feature seems to require a statically linked bash.
> Compiling this (plus some dependencies) can take quite some time. Do
> you think a static bash would be a
> viable addition to `nixpkgs`?
>

Not really - you just need to make sure all the libraries are in the
chroot. I would think that it just works on Linux, where everything is
linked only to /nix/store (unless the build got tainted). On Darwin the
stdenv isn't pure yet but even then the required libraries can be copied.

Note that the chroot isn't really required to build things and in its
current form it slows down builds. See
https://github.com/NixOS/nix/issues/179 .

 * Is there a way to add globally visible package overrides but still use
> the nix-channel?
>

Absolutely, that's what packageOverrides in the nixpkgs configuration is
for. If a binary build is available, it will be used, otherwise you'll do
the build locally.


>  * Would it be possible to make a non-root user the admin of a multi-user
> nix installation?
> I.e. a user who can can do `nix-channel --update`. Or does this
> explicitely require root?
>

A multi-user installation basically means that every build is done by
nix-daemon. If you don't use build users, then nix-daemon doesn't need to
fork as different users and doesn't need root (but needs write permissions
to /nix). Anyone that has access to the nix-daemon socket can order builds.

Cheers,

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

Re: [Nix-dev] nix-multi-user installation script

[Wout Mertens]

Aha so from
https://github.com/NixOS/nixpkgs/blob/f079cd1721cd50d188f3c32387a074bf00afb34d/nixos/modules/services/misc/nix-daemon.nix#L29-L32

(incidentally, I'd love it if somehow that was generated before running the
rest of a nixos-rebuild, so nix options take hold before building)

On Thu Nov 06 2014 at 2:41:54 PM Peter Simons  wrote:

> Hi Wout,
>
>  >> The chroot build feature seems to require a statically linked bash.
>  >
>  > Not really - you just need to make sure all the libraries are in the
>  > chroot. I would think that it just works on Linux, where everything is
>  > linked only to /nix/store (unless the build got tainted).
>
> it "just works" on NixOS, because the system auto-generates an appropriate
> /etc/nix/nix.conf file that includes all bits required by "bash" into the
> chroot environment. For example:
>
>  | build-chroot-dirs = /bin/sh=/nix/store/j9z5...-bash-4.2-p51/bin/bash
> /nix/store/ghvr...-linux-headers-3.7.1 /nix/store/i11d...-glibc-2.19
> /nix/store/j9z5...-bash-4.2-p51
>
> On other Linux systems, this needs to be configured manually.
>
> I hope this helps,
> Peter
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Installing in $HOME and datadir

[Wout Mertens]

So is proot much slower than native? I suppose it also depends on the
kernel version.

On Thu Nov 06 2014 at 11:11:11 AM Pjotr Prins 
wrote:

> On Sat, Oct 11, 2014 at 12:41:40PM +0300, Paul Colomiets wrote:
> > Hm, that's nice. But given the PRoot works using ptrace, it's probably
> > very slow, right?
>
> I have bootstrapped Nix using Proot. To get native performance for
> installed software I use that to build packages from source in a new
> STORE. Documented here:
>
>   https://nixos.org/wiki/How_to_install_nix_in_home_%28on_
> another_distribution%29#Building_native_packages
>
> This works great when you have no root (on older setups).
>
> Pj.
> ___
> 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 in $HOME and datadir

[Wout Mertens]

Afaict proot is the most complete...

On Thu, Nov 6, 2014, 16:09 Luca Bruno  wrote:

> On 06/11/2014 16:05, Pjotr Prins wrote:
> > On Thu, Nov 06, 2014 at 02:39:47PM +0000, Wout Mertens wrote:
> >>So is proot much slower than native? I suppose it also depends on the
> >>kernel version.
> > It is slower because it intercepts a number of system calls and
> > rewrites paths and permissions on the fly. It really depends on your
> > application whether you will notice it. If you have lot's of IO you
> > may be better off without.
> >
> > It is incredibly cool that I can download, install and run nix
> > binaries without having root on a system.
> Did anybody try fakeroot and fakechroot? Those are used by debian for
> building packages. Maybe they don't cover a lot of cases though.
> ___
> 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] In Docker We Trust? Containerization, Security and Trust Models | Guardtime

[Wout Mertens]

Interesting, this blog says that signing stuff is pointless and instead you
should use a blockchain.

Does anybody know of open source projects that do that?

http://guardtime.com/blog/in-docker-we-trust-containerization-security-and-trust-models

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

Re: [Nix-dev] clang-based stdenv for OSX Yosemite

[Wout Mertens]

So on a fresh 10.10 with XCode 6.1 the joelteon master branch can't build
things like Python. The error is below, I presume it is because the
downloaded clang depends on libraries that aren't available. Should I just
rebuild the world without binary cache?

configure:3947: checking whether the C compiler works

configure:3969: clang
-I/nix/store/0vxclyfimw81d5a42z5awxmkvl3zgl1x-zlib-1.2.8/include
-I/nix/store/0x4dqky1g3jvwvadcw51najjj0a6ibiq-bzip2-1.0.6/include
-I/nix/store/0zma7049nw3mwq8aik183i2mbpgw2426-xz-5.0.5/include
-I/nix/store/i49hpms5d8j0cg2izjxnzyl9b02s508j-gdbm-1.11/include
-I/nix/store/z1sh0nlnwlv0yma6c91m55fq9zr9d9fa-sqlite-3.8.7/include
-I/nix/store/igmjzlrkczlzggaplyi3makxfm9iqvkg-db-5.3.28/include
-I/nix/store/m8gw7ggzdny8p2w9dik9f481pmjwmpma-readline-6.3p08/include
-I/nix/store/fc688jhpqkbjxhn8xnksswpv5szcvdxg-ncurses-5.9/include
-I/nix/store/89zxnpdrhv2z9lffhhmjac52dspqqpi4-openssl-1.0.1j/include
-I/nix/store/rah8sp90y0aml9495av4w6ls3y7vjdnj-tcl-8.5.15/include
-I/nix/store/7yhp7w16wnq206x4qih2fzfkkbm7s558-tk-8.5.15/include
-I/nix/store/kpfyi3q82iblsnb663ybksnas5g09x3q-libX11-1.6.2/include
-I/nix/store/wxv9vgqi60dhxm33q10lh0wx8p8l1glk-xproto-7.0.26/include
-L/nix/store/0vxclyfimw81d5a42z5awxmkvl3zgl1x-zlib-1.2.8/lib
-L/nix/store/0x4dqky1g3jvwvadcw51najjj0a6ibiq-bzip2-1.0.6/lib
-L/nix/store/0zma7049nw3mwq8aik183i2mbpgw2426-xz-5.0.5/lib
-L/nix/store/i49hpms5d8j0cg2izjxnzyl9b02s508j-gdbm-1.11/lib
-L/nix/store/z1sh0nlnwlv0yma6c91m55fq9zr9d9fa-sqlite-3.8.7/lib
-L/nix/store/igmjzlrkczlzggaplyi3makxfm9iqvkg-db-5.3.28/lib
-L/nix/store/m8gw7ggzdny8p2w9dik9f481pmjwmpma-readline-6.3p08/lib
-L/nix/store/fc688jhpqkbjxhn8xnksswpv5szcvdxg-ncurses-5.9/lib
-L/nix/store/89zxnpdrhv2z9lffhhmjac52dspqqpi4-openssl-1.0.1j/lib
-L/nix/store/rah8sp90y0aml9495av4w6ls3y7vjdnj-tcl-8.5.15/lib
-L/nix/store/7yhp7w16wnq206x4qih2fzfkkbm7s558-tk-8.5.15/lib
-L/nix/store/kpfyi3q82iblsnb663ybksnas5g09x3q-libX11-1.6.2/lib
-L/nix/store/wxv9vgqi60dhxm33q10lh0wx8p8l1glk-xproto-7.0.26/lib conftest.c
-lncurses >&5

ld: library not found for -lcrt1.10.6.o

clang-3.5: error: linker command failed with exit code 1 (use -v to see
invocation)

On Fri Nov 07 2014 at 6:23:57 PM Eric Seidel  wrote:

> Alfredo Di Napoli  writes:
>
> > Thank you so much guys for your stoic effort!
> > For the nix newbies like me, could you please expand upon
> > "If you would like to use our branch you should add hydra.joelt.io to
> your
> > binary caches."
>
> You want to set the binary-caches option in nix.conf, e.g.
>
>   binary-caches = http://cache.nixos.org http://hydra.joelt.io
>
> I think nix looks for /etc/nix/nix.conf by default, but this is
> configurable via the NIX_CONF_DIR environment variable.
>
> Eric
> ___
> 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] Postgis issues

[Wout Mertens]

Does the postgis 1.5.8 package include the postgis.control file? If so,
there must be an issue with the code handling the postgres extraPlugins. If
not, fix the postgis package :)

On Tue Nov 18 2014 at 1:40:48 PM  wrote:

> Hi All,
>
> New to Nix, I can't figure out where i'm going wrong with postgis. Known
> issue building 1_5_1 so i'm skipping to 1_5_8 using `callPackage`.
>
> Configured as follows:
>
>services.postgresql = {
>  enable = true;
>  package = pkgs.postgresql;
>  extraPlugins = [ (pkgs.callPackage
> /path/to/nixpkgs/pkgs/development/libraries/postgis {}).v_1_5_8 ];
>};
>
> Rebuilding OS works fine. Postgis appears to install (I can see
> postgis-1.5.so), but i'm missing `postgis.control` and presumably one
> extra step?
>
> 'CREATE EXTENSION postgis; ERROR:  could not open extension control file
> "/nix/store/[...]-postgresql-and-plugins-9.2.9/share/
> extension/postgis.control"'
>
> Greatly appreciate any tips on how to debug this.
>
> 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

[Nix-dev] Make wrappers be binaries instead of shell scripts?

[Wout Mertens]

Hi all,

I'm wondering if it wouldn't be better to make the application wrapper
scripts generated by makeWrapper be binaries that do the environment
massaging and config in binary code before exec() ing the wrapped program.

The advantages would be that the wrapper itself loads very fast since all
the shell init and shell parsing is skipped. You also get precise control
over the execv() call or other desired factors.

The disadvantages are that you can't read what a wrapper does and the
wrapper file is bigger (about 4KB in my tests for a simple execv()).

Thoughts?

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

Re: [Nix-dev] Nix stand at FOSDEM15

[Wout Mertens]

I'm requesting a table, we'll see if we get in.

How about USB sticks with the Nix logo and a liveUSB? Anybody have
experience getting those?

Wout.

On Wed Nov 19 2014 at 9:05:09 AM Rok Garbas  wrote:

> i'll be there as well and can help if you want.
> maybe print new set of t-shirts? :)
>
> On Wed, Nov 19, 2014 at 12:28 AM, Domen Kožar  wrote:
> > If you manage to apply in time, I'm willing to help out!
> >
> > Domen
> >
> > On Wed, Nov 19, 2014 at 12:01 AM, Nathan Bijnens 
> wrote:
> >>
> >> Does anyone have plans to host a Nix stand at Fosdem? The deadline for
> >> submission is November 20.
> >>
> >> https://fosdem.org/2015/news/2014-09-19-call-for-
> participation-part-two/
> >>
> >> I would be happy to help.
> >>
> >> Nathan
> >> ---
> >> nat...@nathan.gs | nathan.gs | @nathan_gs | linkedin.com/in/nbijnens
> >>
> >> ___
> >> 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
> >
>
>
>
> --
> Rok Garbas
> http://www.garbas.si
> r...@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] Setting proxy environmental variables

[Wout Mertens]

Hi,

see https://github.com/NixOS/nixpkgs/pull/5058 for the work being done for
this. In the mean time, can't you set http_proxy environment variables
before running nixos-rebuild?

Wout.

On Fri Nov 21 2014 at 3:26:43 PM masterdeZign 
wrote:

> Hello!
>
> I am new to NixOs, but the question which interests me seems not to be
> discussed yet.
> My workstation has access to Internet via proxy. I have exported
> environmental variables http_proxy and https_proxy, however running
> nix-env -i wget fails accessing cache.nixos.org and subsequently,
> tarballs.nixos.org. I suspect it's due to the fact the build users do
> not share the environmental variables with my current user.
>
> Looking around the manual, I have found nix.proxy configuration
> string. I have ended up with a /etc/nixos/configuration.nix like that:
>
> { config, pkgs, ... }:
>
> {
>   imports = [ 
> 
>];
>
>  nix.proxy = "proxy-host.com:3128";
>
> }
>
> However nixos-rebuild switch fails in the same way as nix-env -i:
>
> building Nix...
> building the system configuration...
> download-from-binary-cache.pl: still waiting for
> ‘http://cache.nixos.org/nix-cache-info’ after 5 seconds...
> download-from-binary-cache.pl: could not download
> ‘http://cache.nixos.org/nix-cache-info’ (Curl error 7)
> these derivations will be built:
>   /nix/store/17s184bdsmnqa0vpwxmyj58i3a2n8flz-dbus-conf.drv
>   /nix/store/2jwpim2m9f4yhi1ds0rqqcl6h623v0b5-stdenv.drv
>   /nix/store/3xbm6viqjdpznhxxxqpsirlfjz0b64lw-bzip2.drv
> ...
>   /nix/store/zw9nnsyygzz72j5b3j5zw4bknzkcbcdf-docbook-5.0.zip.drv
> building path(s) `/nix/store/4fxls0b5l7c3kdd8idbzr6cp823iip37-bzip2'
> downloading http://tarballs.nixos.org/stdenv-linux/i686/r24519/bzip2
> into /nix/store/4fxls0b5l7c3kdd8idbzr6cp823iip37-bzip2
>   % Total% Received % Xferd  Average Speed   TimeTime Time
> Current
>  Dload  Upload   Total   SpentLeft
> Speed
>   0 00 00 0  0  0 --:--:--  0:02:07 --:--:--
>
>
>
> Thank you in advance.
> ___
> 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] Banana Pi => Need ARM NixOS image

[Wout Mertens]

I just ordered a Banana Pi (much more capable Raspberry Pi descendant, see
http://www.aliexpress.com/snapshot/6367127900.html).
Did anybody put NixOS on it yet?

It's supposed to be Raspberry Pi compatible, so I can probably just use
https://nixos.org/wiki/Raspberry_Pi. If anybody did something more recent
 I'd like to know.

Also, is the cross-compilation stuff working to a point where the Pi image
could be built elsewhere? Any pointers?

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

Re: [Nix-dev] NixOps, managing virtual hardware and network

[Wout Mertens]

Hi Sergey,

yup, NixOps fits the bill, but I'm not sure what you mean with being bound
to the host's physical adapter.
When you deploy virtualboxes with NixOps it gives the VM 2 interfaces: One
host-local and one on vboxnet0. If you want a different setup you'll have
to tweak nixops here:
https://github.com/NixOS/nixops/blob/41cf9ed862c13a4171c77e3494f9b7ca59a8adc0/nixops/backends/virtualbox.py#L363-L369

(if you do, make it configurable and send a PR please :-) )

As for specifying configuration of host and vboxen in one go, NixOps
doesn't do that. It only runs virtualboxes on localhost.
You can write a systemd service that starts the nixops network if you
like...

Another approach is to create a bunch of VMs manually and add them as
"None" type hosts to NixOps, then NixOps will just use them as-is.

Good luck!

Wout.

On Wed Nov 26 2014 at 2:42:06 PM Sergey Mironov  wrote:

> Hi, List! Please, help me to decide what deployment tools (NixOps?) to
> use for the
> following task:
>
> I'd like to build a test server for testing a hardware NAT device. The
> server
> should be a Host machine hosting 2-4 Virtual machines. Every Virtual
> machine
> should have 2 ethernet adapters: first one should be bound to Host's
> physical
> adapter (the network traffic emulator), the second  one should be connected
> to the internal virtual network (the management interface).
>
> The exact set of software deployed onto Virtual machines depends on
> particular
> test scenario, but it typically includes some http, ftp, voice, video
> broadcasting
> servers and clients.
>
> Does NixOps have required functionality to fit into this task? Does it
> allow
> specifying configuration for the Host and it's guest machines in one
> expression (I assume VirtualBox to be a virtualization container)?
> What about tweaking VirtualBox hardware?
>
> Should I consider looking at other deployment tools?
>
> Thanks in advance,
> Sergey
> ___
> 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] Setting proxy environmental variables

[Wout Mertens]

Ok, try this:


   - configure nix.proxy like it should be in /etc/nixos/configuration.nix
   - build the new nix.conf: sudo nix-build '' -A
   config.environment.etc.\"nix/nix.conf\".source
   - overwrite nix.conf: sudo mv result /etc/nix/nix.conf
   - sudo nixos-rebuild => should work now with the proxy settings

Wout.

On Thu Nov 27 2014 at 2:13:03 PM masterdeZign 
wrote:

> > You should only need to do a
> >
> > 4) nix-build -A system "" --option use-binary-caches false
>
> This step seems to require root privileges, because of "error: Nix
> database directory `/nix/var/nix/db' is not writable: Permission
> denied".
>
> However, it is not a problem. I use sudo -E or sudo su + export the
> http_proxy and https_proxy variables. But the problem persists,
> because curl does not download anything.
> ___
> 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] Setting proxy environmental variables

[Wout Mertens]

On Thu Nov 27 2014 at 10:29:14 PM Edward Tjörnhammar  wrote:

> On Thu, Nov 27, 2014 at 06:19:47PM +0000, Wout Mertens wrote:
> >Ok, try this:
> >
> >  * configure nix.proxy like it should be in
> /etc/nixos/configuration.nix
> >  * build the new nix.conf:A sudo nix-build '' -A
> >config.environment.etc.\"nix/nix.conf\".source
> >  * overwrite nix.conf: sudo mv result /etc/nix/nix.conf
> >  * sudo nixos-rebuild => should work now with the proxy settings
>
> Will that work? "man nix.conf|grep proxy;echo $?" (nix-1.8pre3903_b0c5c2a)
>
>
Argh, you're right, nix.proxy determines the environment variables for
nix-daemon, there's no proxy setting in the nix configuration file :-(

So while this will set build options that are defined in the nixos config,
it doesn't help with proxying.

So it's back to not doing the build with nix-daemon, but as root with the
proper proxy variables set. Just sudo -s, set the variables and do a
nixos-rebuild.

Another option would be to set up iptables to send all http traffic through
a transparent proxy but that's probably silly :-D.

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

Re: [Nix-dev] Setting proxy environmental variables

[Wout Mertens]

g port
> 80: Connection timed out
> builder for `/nix/store/3xbm6viqjdpznhxxxqpsirlfjz0b64lw-bzip2.drv'
> failed with exit code 7
> cannot build derivation
> `/nix/store/4rpjapixwak8p84pbkfk8ypvvznaspc9-bootstrap-tools.drv': 1
> dependencies couldn't be built
> cannot build derivation
> `/nix/store/cylvmknh3p1jhxrnymv21nja59wbcrnc-gnumake-3.82.drv': 1
> dependencies couldn't be built
> cannot build derivation
> `/nix/store/2jwpim2m9f4yhi1ds0rqqcl6h623v0b5-stdenv.drv': 1
> dependencies couldn't be built
> cannot build derivation
> `/nix/store/620imla2a843rsjb64iixihy489pns10-nixos-14.04.572.2b0cacc.drv':
> 1 dependencies couldn't be built
> error: build of
> `/nix/store/620imla2a843rsjb64iixihy489pns10-nixos-14.04.572.2b0cacc.drv'
> failed
>
>
>
> 2014-11-27 23:05 GMT+01:00, Edward Tjörnhammar :
> > On Thu, Nov 27, 2014 at 09:57:29PM +, Wout Mertens wrote:
> >>On Thu Nov 27 2014 at 10:29:14 PM Edward TjAP:rnhammar  >
> >>wrote:
> >>
> >>  On Thu, Nov 27, 2014 at 06:19:47PM +, Wout Mertens wrote:
> >>  >A  A  Ok, try this:
> >>  >
> >>  >A  A  A  * configure nix.proxy like it should be in
> >>  /etc/nixos/configuration.nix
> >>  >A  A  A  * build the new nix.conf:A sudo nix-build
> ''
> >> -A
> >>  >A  A  A  A  config.environment.etc.\"nix/nix.conf\".source
> >>  >A  A  A  * overwrite nix.conf: sudo mv result /etc/nix/nix.conf
> >>  >A  A  A  * sudo nixos-rebuild => should work now with the proxy
> >>  settings
> >>
> >>  Will that work? "man nix.conf|grep proxy;echo $?"
> >>  (nix-1.8pre3903_b0c5c2a)
> >>
> >>Argh, you're right, nix.proxy determines the environment variables
> for
> >>nix-daemon, there's no proxy setting in the nix configuration file
> :-(
> >>So while this will set build options that are defined in the nixos
> >> config,
> >>it doesn't help with proxying.
> >>So it's back to not doing the build with nix-daemon, but as root with
> >> the
> >>proper proxy variables set. Just sudo -s, set the variables and do a
> >>nixos-rebuild.
> >>Another option would be to set up iptables to send all http traffic
> >>through a transparent proxy but that's probably silly :-D.
> >
> > Hurr? the localhost privoxy would forward to the intended http_proxy
> > via its config but that would still imply an activation right?
> >
> >>Wout.
> >
>
>
> --
> Best regards,
> Bogdan Penkovskyi
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] [Ann] Sublime Text/TextMate/Atom syntax highlighter

[Wout Mertens]

Hey all,

I made a highlighter for Sublime Text, which uses the TextMate format. Atom
also seems to use it, as does github.

Trying to get it in github via
https://github.com/NixOS/nixpkgs/issues/5109 and as a Sublime Text package
named Nix .

The highlighter is pedantic; if something doesn't match Nix grammar it will
mark it illegal.

Unfortunately it cannot implement the real Nix language because the
regex-based highlighter is not a real parser with proper states.
It seems to render nixpkgs ok though as well as the tests directory in the
Nix source.

Please try it out and let me know if something doesn't render right for
you, or if things should be marked differently.

Source at https://github.com/wmertens/sublime-nix. Comments and ways to
incorporate in other editors welcome.

Cheers,

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

Re: [Nix-dev] force nix-build without binary caches?

[Wout Mertens]

It only keeps folders if the build failed. If you want to debug the build
process, use "nix-shell '' -A qscintilla" and go through the build
phases (unpackPhase, cd dir, patchPhase, configurePhase, buildPhase,
installPhase).

See also
http://lethalman.blogspot.com/2014/08/nix-pill-10-developing-with-nix-shell.html

Wout.

On Mon Dec 01 2014 at 11:52:34 AM Daniel Hlynskyi 
wrote:

> No, not everything is working. -K option didn't trigger. Here are last
> lines of build log
>
> building install_features
>  install -m 644 -p
> /tmp/nix-build-qscintilla-2.8.3.drv-0/QScintilla-gpl-2.8.3/Qt4Qt5/features/qscintilla2.prf
> /nix/store/kycs9akg1h70wjm0p4cg9cc384ccrfy7-qscintilla-2.8.3/share/qt/mkspecs/features//
> glibPreFixupPhase
> post-installation fixup
> patching ELF executables and libraries in
> /nix/store/kycs9akg1h70wjm0p4cg9cc384ccrfy7-qscintilla-2.8.3
>
> /nix/store/kycs9akg1h70wjm0p4cg9cc384ccrfy7-qscintilla-2.8.3/libs/libqscintilla2.so.11.2.0
> gzipping man pages in
> /nix/store/kycs9akg1h70wjm0p4cg9cc384ccrfy7-qscintilla-2.8.3
> patching script interpreter paths in
> /nix/store/kycs9akg1h70wjm0p4cg9cc384ccrfy7-qscintilla-2.8.3
> /nix/store/kycs9akg1h70wjm0p4cg9cc384ccrfy7-qscintilla-2.8.3
>
> But folder /tmp/nix-build-qscintilla-2.8.3.drv-0/ is deleted:
>
> [danbst@master:/tmp/scibuild]$ ls -la /tmp/
> total 8
> drwxrwxrwt 12 root   root 260 Dec  1 11:45 .
> drwxr-xr-x 20 root   root4096 Nov 20 09:19 ..
> drwxr-xr-x  2 danbst nogroup   80 Nov 27 23:22 build
> drwx--  2 danbst nogroup   60 Nov 27 20:45 .esd-1000
> drwx--  2 root   root  40 Nov 27 20:45 kde-root
> drwx--  2 root   root  40 Nov 27 20:45 ksocket-root
> drwx--  2 danbst nogroup   80 Nov 27 20:45
> .org.chromium.Chromium.hPGm8S
> drwx--  2 danbst nogroup   80 Nov 27 20:55
> .org.chromium.Chromium.owFjjQ
> drwxr-xr-x  2 danbst nogroup   60 Dec  1 11:45 scibuild
> drwx--  3 root   root  60 Nov 27 20:45
> systemd-private-a17a7cbc51c64ee6bc6717082ade3db4-rtkit-daemon.service-vxwynA
> drwx--  3 danbst nogroup   60 Nov 30 13:39 .wine-1000
> -r--r--r--  1 root   root  11 Nov 27 20:45 .X0-lock
> drwxrwxrwt  2 root   root  60 Nov 27 20:45 .X11-unix
>
> 2014-12-01 11:47 GMT+01:00 Daniel Hlynskyi :
>
>> thanks, now it works. Am I right, if I have Qt-4.8.6 (build dependency of
>> qscintilla) already installed, than I don't need to
>> recompile it when --option binary-caches "" is used for qscintilla?
>>
>> 2014-12-01 11:34 GMT+01:00 Domen Kožar :
>>
>>> $ rm result
>>> $ nix-store --delete /nix/store/kycs9akg1h70wjm0p4cg9cc384ccrf
>>> y7-qscintilla-2.8.3
>>> $ nix-build '' -K -A qscintilla --option build-use-substitutes
>>> false
>>>
>>> On Mon, Dec 1, 2014 at 11:32 AM, Daniel Hlynskyi >> > wrote:
>>>
 Thanks guys, but that doesn't help

 [danbst@master:/tmp/scibuild]$ nix-build '' -K -A qscintilla
 --option build-use-substitutes false
 /nix/store/kycs9akg1h70wjm0p4cg9cc384ccrfy7-qscintilla-2.8.3

 [danbst@master:/tmp/scibuild]$ nix-build '' -K -A qscintilla
 --option binary-caches ""
 /nix/store/kycs9akg1h70wjm0p4cg9cc384ccrfy7-qscintilla-2.8.3

 [danbst@master:/tmp/scibuild]$

 I have 'gc-keep-outputs = true' option enabled. Can this be a problem?

 2014-12-01 11:29 GMT+01:00 Rob Vermaas :

> Or use (taken from 'man nix.conf'):
>
>build-use-substitutes
>If set to true (default), Nix will use binary substitutes
> if available. This option can be disabled to force
>building from source.
>
> E.g. nix-build --option build-use-substitutes false
>
> Cheers,
> Rob
>
>
> On Mon, Dec 1, 2014 at 11:21 AM, Domen Kožar  wrote:
>
>> nix-build --option binary-caches ""
>>
>> On Mon, Dec 1, 2014 at 11:08 AM, Daniel Hlynskyi <
>> abcz2.upr...@gmail.com> wrote:
>>
>>> hi, I'm trying to use -K option for nix-build, but it doesn't
>>> generate unpacked directory in /tmp, it simply finds it somewhere in 
>>> cache
>>> (or binary cache.nixos.org or hydra.nixos.org). How to force it to
>>> build without using cache and generated /tmp/nix-build-* directory?
>>>
>>> [danbst@master:/tmp/scibuild]$ nix-build '' -K -A
>>> qscintilla
>>> /nix/store/kycs9akg1h70wjm0p4cg9cc384ccrfy7-qscintilla-2.8.3
>>> [danbst@master:/tmp/scibuild]$
>>>
>>> ___
>>> 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
>>
>>
>
>
> --
> Rob Vermaas
>
> [email] rob.verm...@gmail.com
>


>>>
>>
> ___
> nix-dev mailing list
> nix-dev@l

Re: [Nix-dev] Setting proxy environmental variables

[Wout Mertens]

em-path.drv
> >> >   /nix/store/c99n136y9dx4z285qfyx4aqf12k195vd-system-units.drv
> >> >   /nix/store/cspa2c9c0kby10mw3nq9idi8zz7ypp4d-unit.drv
> >> >   /nix/store/cylvmknh3p1jhxrnymv21nja59wbcrnc-gnumake-3.82.drv
> >> >   /nix/store/d0yipl9v6ns0zcw0p12xmvg4hk06yvhd-nixos-help.drv
> >> >   /nix/store/fa9y9ggnmh3v87lxd70z5fkarfyic47m-options-db.xml.drv
> >> >   /nix/store/g05fymn0lxdvsqnhi6v1m2ij75qndvcz-etc.drv
> >> >   /nix/store/g1qviwli7p010nmlz5v5zalw64m97a
> v0-patchelf-0.8.tar.bz2.drv
> >> >   /nix/store/h287h1vivkryxylyvphas1gm9hiqay2w-unit.drv
> >> >   /nix/store/h8sn7dyxq64mbm2m26iqj6qrca2y6vyq-patchelf-0.8.drv
> >> >   /nix/store/hmskflrz24v3nv6040vamhfd96393cj1-set-environment.drv
> >> >   /nix/store/ix00ag1yjl92ij971z31d7005bj431ky-make-3.82.tar.bz2.drv
> >> >   /nix/store/kslwq77fn8qym4yahsnq80jswwmpfagy-stage-2-init.sh.drv
> >> >   /nix/store/lcwasq8y8acznl22j3b9qv0jm0hapmhm-etc-file.drv
> >> >
> >> > /nix/store/n0rx86w84d7ypxdm8dxg78vzjklrjmzr-bootstrap-tools.cpio.bz2.
> drv
> >> >   /nix/store/n6k4h4xzq661y9s22hkhnylh7p3a5q
> dh-docbook-xsl-ns-1.78.1.drv
> >> >
> >> > /nix/store/nfr35npdy61y1199a3aaqp4adnl5yd
> mn-nixos-14.04.572.2b0cacc.drv
> >> >   /nix/store/nrfqb6wcrv3b794qphw712ixa1yvb41j-gcc-wrapper-4.8.3.drv
> >> >   /nix/store/nzsk41hjg1pilqwyip3aawwfq7411axl-mirrors-list.drv
> >> >
> >> > /nix/store/p0p44vjxgigbkgmsny41v1jwbkn12q
> 5h-docbook-xsl-ns-1.78.1.tar.bz2.drv
> >> >   /nix/store/pcfghxqsxgs1aymmafv11cv7sfgyq0c6-curl.bz2.drv
> >> >   /nix/store/pnfj7ap89ixvpv2ya92lwyrh6kyfldpf-binutils-2.23.1.drv
> >> >   /nix/store/qd8dmn1yfkfjh5znfcbvzvcgqfjiizc3-cpio.drv
> >> >   /nix/store/qqyyxjc8f3dpdar237irfqyryvfxqf1f-mirrors-list.drv
> >> >   /nix/store/rc7v654jii6vd1jr035k2hqlpfkawapq-stdenv-linux-boot.drv
> >> >   /nix/store/rksxaabzs75gmxl4fpdxc2ah9j46gy
> p2-bootstrap-gcc-wrapper.drv
> >> >
> >> > /nix/store/vfy9fbdm4jrr195daldvkj2962bgc1
> br-binutils-2.23.1.tar.bz2.drv
> >> >   /nix/store/vz8irn1xypr8d6klm8mal9mjgjgczs4a-sh.drv
> >> >   /nix/store/w0yk4b4aymnq21kc04ckmcsvqa3z5dy8-system-crontab.drv
> >> >   /nix/store/x8akf7qph415rnkzk12cxi2hiwdd6451-stdenv-linux-boot.drv
> >> >   /nix/store/xc9md7ymg7zrg3fawlhivlxdyis65l46-docbook5-5.0.drv
> >> >   /nix/store/xjaak96z1z4ncl2s7wby1f7iisjyia25-stdenv-linux-boot.drv
> >> >   /nix/store/xpqxb348f5bvpzjq3793n21ppvrsxrxz-nixos-manual.drv
> >> >   /nix/store/zw9nnsyygzz72j5b3j5zw4bknzkcbcdf-docbook-5.0.zip.drv
> >> > building path(s) `/nix/store/4fxls0b5l7c3kdd8idbzr6cp823iip37-bzip2'
> >> > downloading http://tarballs.nixos.org/stdenv-linux/i686/r24519/bzip2
> >> > into /nix/store/4fxls0b5l7c3kdd8idbzr6cp823iip37-bzip2
> >> >   % Total% Received % Xferd  Average Speed   TimeTime Time
> >> > Current
> >> >  Dload  Upload   Total   SpentLeft
> >> > Speed
> >> >   0 00 00     0  0  0 --:--:--  0:04:58
> >> > --:--:-- 0curl: (7) Failed to connect to tarballs.nixos.org port
> >
> > This output indicates that nix-build doesn't pick up the http_proxy
> > variable. If you would've misspelt the proxy host you would've seen
> > that hostname in the error instead. There might be something going on
> > but unfortunately I cannot reproduce it.
> >
> >> > 80: Connection timed out
> >> > builder for `/nix/store/3xbm6viqjdpznhxxxqpsirlfjz0b64lw-bzip2.drv'
> >> > failed with exit code 7
> >> > cannot build derivation
> >> > `/nix/store/4rpjapixwak8p84pbkfk8ypvvznaspc9-bootstrap-tools.drv': 1
> >> > dependencies couldn't be built
> >> > cannot build derivation
> >> > `/nix/store/cylvmknh3p1jhxrnymv21nja59wbcrnc-gnumake-3.82.drv': 1
> >> > dependencies couldn't be built
> >> > cannot build derivation
> >> > `/nix/store/2jwpim2m9f4yhi1ds0rqqcl6h623v0b5-stdenv.drv': 1
> >> > dependencies couldn't be built
> >> > cannot build derivation
> >> > `/nix/store/620imla2a843rsjb64iixihy489pns10-nixos-14.04.572.2b0cacc.
> drv':
> >> > 1 dependencies couldn't be built
> >> > error: build of
> >> > `/nix/store/620imla2a843rsjb64iixihy489pns10-nixos-14.04.572.2b0cacc.
> drv'
> >> > failed
> &

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

[Wout Mertens]

http://www.iheartubuntu.com/2014/01/virtualbox-vd-error-verrfilenotfound.html?m=1

Maybe...

Wout.

On Fri, Dec 5, 2014, 07:28 Bas van Dijk  wrote:

> Hello,
>
> I'm trying to deploy a nixops network where myMachine should be
> deployed to a virtualbox VM:
>
>   deployment.targetEnv = "virtualbox";
>
> However I'm getting the following error:
>
> $ nixops deploy -d my-network -I ..
> myMachine> creating VirtualBox VM...
> myMachine> Virtual machine
> 'nixops-e299e202-7c41-11e4-9674-08002734fdef-myMachine' is created and
> registered.
> myMachine> UUID: 67f7f03a-114e-41ef-8927-9e3983ff8bba
> myMachine> Settings file: '/home/bas.van.dijk/VirtualBox
> VMs/nixops-e299e202-7c41-11e4-9674-08002734fdef-myMachine/
> nixops-e299e202-7c41-11e4-9674-08002734fdef-myMachine.vbox'
> myMachine> creating disk ‘disk1’...
> myMachine> these derivations will be built:
> myMachine>   /nix/store/c5jny1wz14wlaimbfrmmmvz0z9iysq
> h7-virtualbox-nixops-13.10.35433.4721802.vdi.drv
> myMachine> building path(s)
> `/nix/store/24i6jbkg83pdndf6w6z9axmp9v2scwrp-virtualbox-nixops-13.10.
> 35433.4721802.vdi'
> myMachine> building
> /nix/store/24i6jbkg83pdndf6w6z9axmp9v2scwrp-virtualbox-nixops-13.10.
> 35433.4721802.vdi
> myMachine>
> myMachine> 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
> myMachine> Clone hard disk created in format 'VDI'. UUID:
> 58fff3fc-0057-4b91-ac2a-d5e7f330cd99
> myMachine> attaching disk ‘disk1’...
> myMachine> VBoxManage: error: Could not launch a process for the
> machine 'nixops-e299e202-7c41-11e4-9674-08002734fdef-myMachine'
> (VERR_FILE_NOT_FOUND)
> myMachine> VBoxManage: error: Details: code VBOX_E_IPRT_ERROR
> (0x80bb0005), component Machine, interface IMachine, callee
> nsISupports
> myMachine> VBoxManage: error: Context: "LaunchVMProcess(a->session,
> sessionType.raw(), env.raw(), progress.asOutParam())" at line 592 of
> file VBoxManageMisc.cpp
> error: command ‘['VBoxManage', 'startvm',
> u'nixops-e299e202-7c41-11e4-9674-08002734fdef-myMachine']’ failed on
> machine ‘myMachine’ (exit code 1
>
> Note that the -I .. points to a nixpkgs with a recent checkout of
> nixpkgs master.
>
> Any idea what I'm doing wrong?
>
> Cheers,
>
> Bas
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] NixOps, managing virtual hardware and network

[Wout Mertens]

Looks good! I added two comments.

I think you should open a PR for further discussion with the nixOps devs.

Wout.

On Mon Dec 08 2014 at 11:34:57 AM Sergey Mironov  wrote:

> 2014-12-01 16:30 GMT+04:00 Wout Mertens :
> > You'll have to create bridged networks in Virtualbox, one for each
> > interface. Then you assign them to each VM.
> >
> > I'd just make an extra interface configurable and give your VMs a third
> > interface. The other two are used for internet access and connecting from
> > the host.
> >
> > To connect to a virtualbox host with nixops, just do "nixops ssh  > name>"
> >
> > Wout.
> >
>
> Hi Wout! I've finished the minimal setup I need using the design you
> have suggested. The modifications allow virtual machines to
> effectively 'monopolize' certain Host's adapters. I don't see any
> notable interference between Host's and Guest's networking stacks.
>
> The branch located at
>
>   https://github.com/grwlf/nixops/tree/vb-bridged-interface
>
> contains the following modifications:
> 1) deployment.virtualbox.hostBridgedInterface  - accepts host's
> interface name to be bridged with interface #3 of a particular virtual
> machine
> 2) deployment.virtualbox.guestBridgedMac - accepts MAC address of the
> guest's adapter #3.
>
> I think I should test the setup more closely before merge. For now I
> will be glad to receive any comments (choice of names for parameters,
> etc).
>
> Thanks,
> Sergey
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Using ccache without changing stdenv hash?

[Wout Mertens]

Hi all,

there is some support for ccache in the tree but nothing in the way of
documentation. I gave it a shot, see
https://github.com/NixOS/nixpkgs/issues/2387#issuecomment-66215017, and it
seems to work however it also changes the hash of stdenv.

Is there a way to change stdenv so that ccache can be turned on or off
without causing rebuilds?

I'm convinced that this would be a major boon for Hydra, which probably
spends a lot of time compiling the same C/C++ files with the same
preprocessed output. Likewise for developing expressions.

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

Re: [Nix-dev] Using ccache without changing stdenv hash?

[Wout Mertens]

I don't follow. It's a cache, so it always returns the same output for a
given set of inputs (compiler version, source files, preprocessor
settings). Its presence should be undetectable.

The only impurity is that time taken to compile is dependent on previous
compiles, no?

However, it is still useful for development but not if using it means
rebuilding the world on your laptop... So I'd like to at least offer the
option for development.

Wout.

On Tue Dec 09 2014 at 6:32:04 PM Shea Levy  wrote:

> ccache is impure and thus should not be used for hydra.
>
> On Dec 9, 2014, at 5:28 PM, Wout Mertens  wrote:
>
> Hi all,
>
> there is some support for ccache in the tree but nothing in the way of
> documentation. I gave it a shot, see
> https://github.com/NixOS/nixpkgs/issues/2387#issuecomment-66215017, and
> it seems to work however it also changes the hash of stdenv.
>
> Is there a way to change stdenv so that ccache can be turned on or off
> without causing rebuilds?
>
> I'm convinced that this would be a major boon for Hydra, which probably
> spends a lot of time compiling the same C/C++ files with the same
> preprocessed output. Likewise for developing expressions.
>
> Wout.
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Using ccache without changing stdenv hash?

[Wout Mertens]

You can configure the hashing ccache uses to determine if the compiler
changed. For developing a bootstrap, you might just use the compiler
version, but for regular use you'd use the full path of the binary so it
includes the nix hash. See compiler_check at
http://ccache.samba.org/manual.html#_configuration_settings.

Other than that, ccache uses all the inputs to the compiler to determine
the cache hash.

Indeed, ccache needs to write to a shared cache so that could be poisoned.
An option would be to run ccache setuid as someone else so that the
poisoning can only be done by compiling a malicious payload in a way that
the input hash clashes.

On Tue Dec 09 2014 at 6:59:50 PM Shea Levy  wrote:

> Also, presumably builds will have to have write access to the cache, which
> means a malicious build can break things for other builds.
>
> On Dec 9, 2014, at 5:57 PM, Wout Mertens  wrote:
>
> I don't follow. It's a cache, so it always returns the same output for a
> given set of inputs (compiler version, source files, preprocessor
> settings). Its presence should be undetectable.
>
> The only impurity is that time taken to compile is dependent on previous
> compiles, no?
>
> However, it is still useful for development but not if using it means
> rebuilding the world on your laptop... So I'd like to at least offer the
> option for development.
>
> Wout.
>
> On Tue Dec 09 2014 at 6:32:04 PM Shea Levy  wrote:
>
>> ccache is impure and thus should not be used for hydra.
>>
>> On Dec 9, 2014, at 5:28 PM, Wout Mertens  wrote:
>>
>> Hi all,
>>
>> there is some support for ccache in the tree but nothing in the way of
>> documentation. I gave it a shot, see
>> https://github.com/NixOS/nixpkgs/issues/2387#issuecomment-66215017, and
>> it seems to work however it also changes the hash of stdenv.
>>
>> Is there a way to change stdenv so that ccache can be turned on or off
>> without causing rebuilds?
>>
>> I'm convinced that this would be a major boon for Hydra, which probably
>> spends a lot of time compiling the same C/C++ files with the same
>> preprocessed output. Likewise for developing expressions.
>>
>> Wout.
>>
>> ___
>> 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] Chromium not working with pulseaudio

[Wout Mertens]

That's weird: at
https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/all-packages.nix#L9221
it says


chromium = callPackage ../applications/networking/browsers/chromium {
channel = "stable"; pulseSupport = config.pulseaudio or true;
enablePepperFlash = config.chromium.enablePepperFlash or false;
enableWideVine = config.chromium.enableWideVine or false; hiDPISupport =
config.chromium.hiDPISupport or false; };

How can pulseSupport be false?

Confused,

Wout.

On Thu Dec 11 2014 at 10:52:40 AM Jessica Taylor <
jessica.liu.tay...@gmail.com> wrote:

> nixos-version: 14.04.591.aa61c12 (Baboon)
>
> Your fix worked, Georges.  Thanks!
>
> On Thu, Dec 11, 2014 at 12:23 AM, Georges Dubus  
> wrote:
>
> Hello
>>
>> Looking into nixpkgs (
>> https://github.com/NixOS/nixpkgs/blob/4124a0bd9c900ec4b481cae8786cae44f93bad41/pkgs/top-level/all-packages.nix#L9195),
>> it looks like the pulseaudio config attribute should not be inside the
>> chromium set, but in nixpkgs.config itself.
>>
>> Georges
>>
>> Georges Dubus
>>
>> 2014-12-11 9:13 GMT+01:00 Domen Kožar :
>>
>>> Hi Jessica,
>>>
>>> could you paste `nixos-version` output?
>>>
>>> Domen
>>>
>>> On Thu, Dec 11, 2014 at 2:03 AM, Jessica Taylor <
>>> jessica.liu.tay...@gmail.com> wrote:
>>>
 Hello.  I recently installed NixOS and found that most things worked,
 but I'm having a problem with audio.

 When Chromium should play a sound (such as with HTML5 video or Gmail),
 no sound plays, and Chromium is not listed as an application in 
 pavucontrol.

 I have pulseaudio enabled:

 > hardware.pulseaudio.enable = true;

 Firefox can play sounds just fine (and appears in pavucontrol), so it
 appears to be a Chromium-specific issue.

 I have Chromium explicitly configured to be compiled with pulseaudio
 support (which I think is already the default):

 > nixpkgs.config = {
 >   ...
 >   chromium = {
 > enablePepperFlash = true;
 > enablePepperPDF = true;
 > pulseaudio = true;
 >   };
 > };

 I tried following the directions in
 http://article.gmane.org/gmane.linux.distributions.nixos/12117/match=chromium,
 but this didn't help.

 Thanks,
 Jessica Taylor


 ___
 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] BootDevice Not Found

[Wout Mertens]

No ideas, in your place I'd consider switching to UEFI...

On Wed, Dec 17, 2014, 12:38 AM Dejan Lukan 
wrote:

> Hello all,
>
> Recently I've installed NixOS on my new HP Ultrabook 850 Laptop, but I
> cannot boot into the system. Whenever I restart the
> livecd NixOS distribution, I get the following error message:
>
>   BootDevice Not Found
>   Please install an operating system on your hard disk.
>   Hard Disk - (3F0)
>
> But if I boot from CD and choose "Boot from hard drive", the Grub from
> original hard drive opens, which verifies that the bootloader
> is present on the /dev/sda. I'm relatively sure it's a BIOS problem, but I
> have a hard time figuring what could be wrong. I've disabled
> the RAID (and use AHCI) and the legacy booting mode is selected (not
> UEFI). Therefore grub1 should work fine as is installed on /dev/sda.
>
> Relevant part of the configuration.nix is presented below:
>
>
>   boot.loader.grub.enable = true;
>   boot.loader.grub.version = 1;
>   boot.loader.grub.device = "/dev/sda";
>   boot.initrd.luks.devices = [ { name = "system"; device = "/dev/sda2";
> preLVM = true; } ];
>   boot.initrd.luks.cryptoModules = ["aes" "sha256" "sha1" "cbc"];
>
>
> Any ideas about the error message. I guess it has something to do with
> BIOS, which can't look at the MBR of the hard drive
> in order to discover the Grub boot loader.
>
> Please provide any comments that might shed some light onto this problem.
>
>
>
>
> ___
> 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] rsyncd: breaking configuration change

[Wout Mertens]

Hi all,

if you use rsyncd, note that https://github.com/NixOS/nixpkgs/pull/5254
changes the configuration so that samba and rsyncd can now share the same
exports list.

This breaks the current rsyncd configuration.

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

Re: [Nix-dev] Nix stand at FOSDEM15

[Wout Mertens]

Still no news about the tables at Fosdem... Should we prod them to show our
interest?

On Wed Nov 19 2014 at 11:16:11 AM Wout Mertens 
wrote:

> I'm requesting a table, we'll see if we get in.
>
> How about USB sticks with the Nix logo and a liveUSB? Anybody have
> experience getting those?
>
> Wout.
>
> On Wed Nov 19 2014 at 9:05:09 AM Rok Garbas  wrote:
>
>> i'll be there as well and can help if you want.
>> maybe print new set of t-shirts? :)
>>
>> On Wed, Nov 19, 2014 at 12:28 AM, Domen Kožar  wrote:
>> > If you manage to apply in time, I'm willing to help out!
>> >
>> > Domen
>> >
>> > On Wed, Nov 19, 2014 at 12:01 AM, Nathan Bijnens 
>> wrote:
>> >>
>> >> Does anyone have plans to host a Nix stand at Fosdem? The deadline for
>> >> submission is November 20.
>> >>
>> >> https://fosdem.org/2015/news/2014-09-19-call-for-participati
>> on-part-two/
>> >>
>> >> I would be happy to help.
>> >>
>> >> Nathan
>> >> ---
>> >> nat...@nathan.gs | nathan.gs | @nathan_gs | linkedin.com/in/nbijnens
>> >>
>> >> ___
>> >> 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
>> >
>>
>>
>>
>> --
>> Rok Garbas
>> http://www.garbas.si
>> r...@garbas.si
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Breaking changes log

[Wout Mertens]

Would it be nice if we kept a file with breaking changes?

That way, nixos-rebuild should be able to list the breaking changes between
the current version of the channel and the last time the system was built.

We'd also have the full list of breakage for release notes.

Thoughts? What would such a log look like?

Cheers,

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

Re: [Nix-dev] Breaking changes log

[Wout Mertens]

Nice though it seems a bit complex. Not sure if it's over-engineered or
just what's needed.

Also interesting:
*"There have been complaints regarding the comprehensibility of some
upgrade notices and news items in the past. This is understandable — not
every Gentoo developer speaks English as a first language. However, for the
sake of clarity, professionalism and avoiding making us look like prats, it
is important that any language problems be corrected before inflicting a
news item upon end users.*

*Thus, at least 72 hours before a proposed news item is committed, it must
be posted to the gentoo-dev mailing list and Cc:ed to p...@gentoo.org
 (exceptions may be made in exceptional circumstances). Any
complaints — for example regarding wording, clarity or accuracy — must be
addressed before the news item goes live."*



Wout.


On Wed Dec 17 2014 at 2:45:31 PM Oliver Charles 
wrote:

> One thing I really like is Gentoo's "news" feature - which seems to be
> discussed in detail at http://wiki.gentoo.org/wiki/GLEP:42. Maybe
> something like that is what you're envisioning?
>
> -- ocharles
>
> On Wed, Dec 17, 2014 at 1:27 PM, Wout Mertens 
> wrote:
>
>> Would it be nice if we kept a file with breaking changes?
>>
>> That way, nixos-rebuild should be able to list the breaking changes
>> between the current version of the channel and the last time the system was
>> built.
>>
>> We'd also have the full list of breakage for release notes.
>>
>> Thoughts? What would such a log look like?
>>
>> Cheers,
>>
>> Wout.
>>
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Nix stand at FOSDEM15: ACCEPTED!

[Wout Mertens]

Alright, we got accepted :-)

Any volunteers to help with the stand? Basically you'd need to chat to the
folks and show them how awesome everything is. At the same time selling
swag is nice.

Anybody up to buying some Nix USB sticks?
http://www.aliexpress.com/wholesale?SearchText=usb+stick+logo
If we get 100 it should be very doable to flash them while at FOSDEM...

Wout.

On Wed Dec 17 2014 at 8:57:15 AM Mikey Ariel  wrote:

> Considering that they haven't announced anything yet, I have a feeling
> that the jury is still out on that one..
>
> On Wed, Dec 17, 2014 at 7:52 AM, Wout Mertens 
> wrote:
>>
>> Still no news about the tables at Fosdem... Should we prod them to show
>> our interest?
>>
>>
>> On Wed Nov 19 2014 at 11:16:11 AM Wout Mertens 
>> wrote:
>>
>>> I'm requesting a table, we'll see if we get in.
>>>
>>> How about USB sticks with the Nix logo and a liveUSB? Anybody have
>>> experience getting those?
>>>
>>> Wout.
>>>
>>> On Wed Nov 19 2014 at 9:05:09 AM Rok Garbas  wrote:
>>>
>>>> i'll be there as well and can help if you want.
>>>> maybe print new set of t-shirts? :)
>>>>
>>>> On Wed, Nov 19, 2014 at 12:28 AM, Domen Kožar  wrote:
>>>> > If you manage to apply in time, I'm willing to help out!
>>>> >
>>>> > Domen
>>>> >
>>>> > On Wed, Nov 19, 2014 at 12:01 AM, Nathan Bijnens 
>>>> wrote:
>>>> >>
>>>> >> Does anyone have plans to host a Nix stand at Fosdem? The deadline
>>>> for
>>>> >> submission is November 20.
>>>> >>
>>>> >> https://fosdem.org/2015/news/2014-09-19-call-for-participati
>>>> on-part-two/
>>>> >>
>>>> >> I would be happy to help.
>>>> >>
>>>> >> Nathan
>>>> >> ---
>>>> >> nat...@nathan.gs | nathan.gs | @nathan_gs | linkedin.com/in/nbijnens
>>>> >>
>>>> >> ___
>>>> >> 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
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> Rok Garbas
>>>> http://www.garbas.si
>>>> r...@garbas.si
>>>> ___
>>>> nix-dev mailing list
>>>> nix-dev@lists.science.uu.nl
>>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>>>
>>>
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] FOSDEM planning Hangout

[Wout Mertens]

Hi all,

We got a table at FOSDEM so we'll need volunteers to man the table and we
need to think about what we'll show/do. Swag sales would be nice too.

If you'd like to help with the planning, please fill out the doodle :
http://doodle.com/br47eeidzgrangqm

Cheers,

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

Re: [Nix-dev] Breaking changes log

[Wout Mertens]

As a summary answer to all the answers, I think we should adopt a change
log as described at http://keepachangelog.com/

Why?

   - It's an attempt at a standard with features that make it somewhat
   machine-parseable (we could write a test for it)
   - It's MarkDown format so human-readable and writeable, and github
   formats it nicely. See
   https://github.com/olivierlacan/keep-a-changelog/blob/gh-pages/CHANGELOG.md
   for an example result.
   - => Its diffs should also be human readable and a unified diff between
   two versions gives you changes you care about. E.g.
   
https://github.com/olivierlacan/keep-a-changelog/commit/0417b6b4e824f459de3ad57c8ba7d4ea0967329c
   - It's mostly insert-only so hopefully it won't result in PRs merge
   conflicts and PRs can include their changes
   - Very free-form so we can later add special tags that would allow
   showing only messages relevant to the installed packages
   - We would only need the one file, each branch has its own history and
   CHANGELOG.md file
   - See http://keepachangelog.com/ for a bunch of FAQs.

Example (off the top of my head):

# Change Log
All notable changes to NixPkgs will be documented in this file.

## [Unstable][unstable]
### Changed
- Bash completion is now on by default
- [BREAKING] config.services.rsyncd exports attributes changed, now
they share the same format as sambad

## [14.04] - 2014-04-30
### Security
- Bash security fixes
- OpenSSL Heartbleed fix

[unstable]: https://github.com/NixOS/nixpkgs/compare/release-14.04...HEAD
[14.04]: https://github.com/NixOS/nixpkgs/compare/release-13.10...release-14.04


We probably don't want to include a line for each changed package, do we?

Thoughts?

Wout.

PS: Hakisho, I top-post because Google makes me do it :)

On Thu Dec 18 2014 at 11:29:04 AM Hakisho Nukama  wrote:

> On Wed, Dec 17, 2014 at 3:09 PM, Mateusz Kowalczyk
>  wrote:
> > On 12/17/2014 01:55 PM, Wout Mertens wrote:
> >> Nice though it seems a bit complex. Not sure if it's over-engineered or
> >> just what's needed.
> >>
> >> Also interesting:
> >> *"There have been complaints regarding the comprehensibility of some
> >> upgrade notices and news items in the past. This is understandable — not
> >> every Gentoo developer speaks English as a first language. However, for
> the
> >> sake of clarity, professionalism and avoiding making us look like
> prats, it
> >> is important that any language problems be corrected before inflicting a
> >> news item upon end users.*
> >>
> >> *Thus, at least 72 hours before a proposed news item is committed, it
> must
> >> be posted to the gentoo-dev mailing list and Cc:ed to p...@gentoo.org
> >>  (exceptions may be made in exceptional circumstances).
> Any
> >> complaints — for example regarding wording, clarity or accuracy — must
> be
> >> addressed before the news item goes live."*
> >>
> >> 
> >>
> >> Wout.
> >>
> >
> > This is just administrative mongering, no need to adopt it fully. I
> > agree that either some kind of news system should be in place: currently
> > I think the only thing we have going is putting ‘trace’ somewhere and
> > hoping the user catches it.
> >
> > In any case, I think calling it ‘news’ is misled: in Gentoo news are
> > used for longer term things, say distro moving off from Ruby 1.x for
> > it's default or whatever. But maybe that's what OP wants.
> >
> > Personally I want to be able to emit a message from a package such as
> > ‘XYZ flags have changed, you need to do such and such thing’ or ‘extra
> > user interaction is needed to get this package to work, put this thing
> > in such and such directory under $HOME’. Gentoo's portage does this,
> > such things print during the package build (not always applicable) and
> > at the end of the builds. I can see multiple problems here in that
> > unlike with Gentoo, we often fetch multiple different versions of same
> > software as various dependencies, the user is rarely directly using it
> > all. I don't know how to deal with this properly. Maybe it's just a bad
> > idea for nix.
> >
>
> Maybe add all notable changes into a 'release-notes' [0]
> for the unstable branch.
> And merge unstable-entries that have not been nullified at release time
> into the release-notes of the upcoming release.
>
> [0] https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/
> manual/release-notes/rl-unstable.xml
>
> Best Regards,
> Hakisho Nukama
>
> P.S.: 'm not aware, if this is a top or bottom posting list, now I'm
> in between. ;)
>
> >> On Wed 

[Nix-dev] Invitation: FOSDEM Planning @ Sat Jan 10, 2015 1pm - 2pm (Wout Mertens)

[Wout Mertens]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20150110T12Z
DTEND:20150110T13Z
DTSTAMP:20141218T162403Z
ORGANIZER;CN=Wout Mertens:mailto:wout.mert...@gmail.com
UID:48v00n6pkmmhabikkidtu1f...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=nix-dev@lists.science.uu.nl;X-NUM-GUESTS=0:mailto:nix-...@lists.sci
 ence.uu.nl
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=Wout Mertens;X-NUM-GUESTS=0:mailto:wout.mert...@gmail.com
X-GOOGLE-HANGOUT:https://plus.google.com/hangouts/_/calendar/d291dC5tZXJ0ZW
 5zQGdtYWlsLmNvbQ.48v00n6pkmmhabikkidtu1fjes
CLASS:PUBLIC
CREATED:20141218T162403Z
DESCRIPTION:We will discuss FOSDEM:\n- How to handle the table schedule\n- 
 Swag\n- Demos to prepare\n- Stuff!\nView your event at https://www.google.c
 om/calendar/event?action=VIEW&eid=NDh2MDBuNnBrbW1oYWJpa2tpZHR1MWZqZXMgbml4L
 WRldkBsaXN0cy5zY2llbmNlLnV1Lm5s&tok=MjIjd291dC5tZXJ0ZW5zQGdtYWlsLmNvbWRhOGM
 2NWM3OWFmZWU1NGY0YzJlYWY5OGIyYzNmZDdhMWE4OTdkNDA&ctz=Europe/Brussels&hl=en.
LAST-MODIFIED:20141218T162403Z
LOCATION:
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:FOSDEM Planning
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


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

Re: [Nix-dev] Invitation: FOSDEM Planning @ Sat Jan 10, 2015 1pm - 2pm (Wout Mertens)

[Wout Mertens]

Oh boy... pointy clicky interfaces are not my forte apparently :-/ Fixing
and sending update.

On Fri Dec 19 2014 at 11:23:20 AM Domen Kožar  wrote:

> Shouldn't that be 20th December (tomorrow)?
>
> On Thu, Dec 18, 2014 at 5:24 PM, Wout Mertens 
> wrote:
>>
>> more details »
>> <https://www.google.com/calendar/event?action=VIEW&eid=NDh2MDBuNnBrbW1oYWJpa2tpZHR1MWZqZXMgbml4LWRldkBsaXN0cy5zY2llbmNlLnV1Lm5s&tok=MjIjd291dC5tZXJ0ZW5zQGdtYWlsLmNvbWRhOGM2NWM3OWFmZWU1NGY0YzJlYWY5OGIyYzNmZDdhMWE4OTdkNDA&ctz=Europe/Brussels&hl=en>
>> FOSDEM Planning
>> We will discuss FOSDEM:
>> - How to handle the table schedule
>> - Swag
>> - Demos to prepare
>> - Stuff!
>> *When*
>> Sat Jan 10, 2015 1pm – 2pm Brussels
>> *Video call*
>> Join video call
>> <https://plus.google.com/hangouts/_/calendar/d291dC5tZXJ0ZW5zQGdtYWlsLmNvbQ.48v00n6pkmmhabikkidtu1fjes>
>> *Calendar*
>> Wout Mertens
>> *Who*
>> •
>> Wout Mertens - organizer
>> •
>> nix-dev@lists.science.uu.nl
>>
>> Going?   *Yes
>> <https://www.google.com/calendar/event?action=RESPOND&eid=NDh2MDBuNnBrbW1oYWJpa2tpZHR1MWZqZXMgbml4LWRldkBsaXN0cy5zY2llbmNlLnV1Lm5s&rst=1&tok=MjIjd291dC5tZXJ0ZW5zQGdtYWlsLmNvbWRhOGM2NWM3OWFmZWU1NGY0YzJlYWY5OGIyYzNmZDdhMWE4OTdkNDA&ctz=Europe/Brussels&hl=en>
>> - Maybe
>> <https://www.google.com/calendar/event?action=RESPOND&eid=NDh2MDBuNnBrbW1oYWJpa2tpZHR1MWZqZXMgbml4LWRldkBsaXN0cy5zY2llbmNlLnV1Lm5s&rst=3&tok=MjIjd291dC5tZXJ0ZW5zQGdtYWlsLmNvbWRhOGM2NWM3OWFmZWU1NGY0YzJlYWY5OGIyYzNmZDdhMWE4OTdkNDA&ctz=Europe/Brussels&hl=en>
>> - No
>> <https://www.google.com/calendar/event?action=RESPOND&eid=NDh2MDBuNnBrbW1oYWJpa2tpZHR1MWZqZXMgbml4LWRldkBsaXN0cy5zY2llbmNlLnV1Lm5s&rst=2&tok=MjIjd291dC5tZXJ0ZW5zQGdtYWlsLmNvbWRhOGM2NWM3OWFmZWU1NGY0YzJlYWY5OGIyYzNmZDdhMWE4OTdkNDA&ctz=Europe/Brussels&hl=en>*
>> more options »
>> <https://www.google.com/calendar/event?action=VIEW&eid=NDh2MDBuNnBrbW1oYWJpa2tpZHR1MWZqZXMgbml4LWRldkBsaXN0cy5zY2llbmNlLnV1Lm5s&tok=MjIjd291dC5tZXJ0ZW5zQGdtYWlsLmNvbWRhOGM2NWM3OWFmZWU1NGY0YzJlYWY5OGIyYzNmZDdhMWE4OTdkNDA&ctz=Europe/Brussels&hl=en>
>>
>> Invitation from Google Calendar <https://www.google.com/calendar/>
>>
>> You are receiving this courtesy email at the account
>> nix-dev@lists.science.uu.nl because you are an attendee of this event.
>>
>> To stop receiving future updates for this event, decline this event.
>> Alternatively you can sign up for a Google account at
>> https://www.google.com/calendar/ and control your notification settings
>> for your entire calendar.
>>
>> ___
>> 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] Breaking changes log

[Wout Mertens]

On Fri Dec 19 2014 at 3:02:34 PM Eelco Dolstra 
wrote:

> On 18/12/14 17:18, Wout Mertens wrote:
>
> > As a summary answer to all the answers, I think we should adopt a change
> log as
> > described at http://keepachangelog.com/
>
> We already have a place to document breaking changes, namely the NixOS
> release
> notes in nixos/doc/manual/release-notes. I'm not in favour of having
> multiple,
> out-of-sync locations to keep this info.
>

Right, but those are not very human-readable nor is there any attempt to
make them machine-parseable (for displaying diffs from nixos-rebuild and
tests).

So I think it would be nice if we had CHANGELOG.md in the project root and
the release notes section of the manual gets built from that automatically.
That's also a more visible place for them, raising awareness amongst users
and devs alike, win-win.

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

Re: [Nix-dev] Breaking changes log

[Wout Mertens]

stewart, the breaking changes are configuration definitions for the
unstable master branch, those can change I hope :)

On Fri Dec 19 2014 at 3:44:19 PM stewart mackenzie 
wrote:

> This might sound a bit off-base, but could we please consider not
> introducing feature breaking functionality to stable APIs? I've found
> the ZeroMQ development methdology to be quite helpful on the subject:
> http://rfc.zeromq.org/spec:16
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Breaking changes log

[Wout Mertens]

Mikey, well given Eelco's comment it seems best to generate a CHANGELOG.md
from the XML file, but then I wonder if we should have one at all (apart
from the nice location).

The goals would be:

   - Allow programmatic extraction of important changes between the current
   nixos system and the one that will be activated
   - Presenting those in a readable way
   - Automatically having a list of changes for when the next release hits.

So we'd need an XML grammar with the types of things we'd want to say...

Wout.

On Fri Dec 19 2014 at 3:22:10 PM Mikey Ariel  wrote:

> Maybe we can think of a way to single-source (as in port the source
> changes into two outputs, the .md file and the release notes)?
>
> I'll be happy to help if I can :-)
>
>
>
> > On 19 Dec 2014, at 15:15, Eelco Dolstra 
> wrote:
> >
> > Hi,
> >
> >> On 19/12/14 15:10, Wout Mertens wrote:
> >>
> >>We already have a place to document breaking changes, namely the
> NixOS release
> >>notes in nixos/doc/manual/release-__notes. I'm not in favour of
> having multiple,
> >>out-of-sync locations to keep this info.
> >>
> >>
> >> Right, but those are not very human-readable nor is there any attempt
> to make
> >> them machine-parseable (for displaying diffs from nixos-rebuild and
> tests).
> >
> > It's probably a lot easier and well-defined to generate something from
> XML than
> > from some poorly specified, ad-hoc Markdown-like language.
> >
> > --
> > Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
> > ___
> > 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] FOSDEM: meeting notes

[Wout Mertens]

Hi all,

here's the findings of our call about FOSDEM (which happens in Brussels
during the Jan 31 weekend, free entrance, come if you can):

We have a table at FOSDEM, which is meant to show off the project to people
that walk through the hallway. Here's what that looks like:
https://wiki.documentfoundation.org/File:Fosdem2013-booth.jpeg

We need *volunteers* to man the table, gear for the table, a presentation
and swag.

* Table:
We will need two monitors and something to drive them.

   - One would be playing a presentation (to be made by somebody, or is
   there a nice one already?) explaining Nix
   - One is for showing interested people how NixOS works. This would be
   done by a table host who is typically behind the table so it's nice to have
   a mirrored screen

Great extras: Banners, flyers, swag, nerdy things, 3D-printed items, ...

* Swag:
It would be great if we have swag to give away/sell.
If we can give e.g. USB sticks away, we could have a contest with a few
prize drawings (have them fill out a google form with some questions about
NixOS that they would have to look up), or we could give stuff to people
that do a PR.

Please see https://nixos.org/wiki/FOSDEM_2015 for a complete overview and
to register as a volunteer.

Feel free to improve the Wiki page of course, or reply here.

Thanks!

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

Re: [Nix-dev] Breaking changes log

[Wout Mertens]

Ok, new proposal: Whenever you make a change that does any of these:

   - Breaks backwards compatibility with existing user state (e.g. db
   versions etc)
   - Changes type of options
   - Changes semantics of options
   - Removes existing options

you should include a description of the change in the release-notes.xml.

After a few of those we can figure out a template that works, and we can
see about letting nixos-rebuild parse the diff.

Wout.

On Fri Dec 19 2014 at 3:15:59 PM Eelco Dolstra 
wrote:

> Hi,
>
> On 19/12/14 15:10, Wout Mertens wrote:
>
> > We already have a place to document breaking changes, namely the
> NixOS release
> > notes in nixos/doc/manual/release-__notes. I'm not in favour of
> having multiple,
> > out-of-sync locations to keep this info.
> >
> >
> > Right, but those are not very human-readable nor is there any attempt to
> make
> > them machine-parseable (for displaying diffs from nixos-rebuild and
> tests).
>
> It's probably a lot easier and well-defined to generate something from XML
> than
> from some poorly specified, ad-hoc Markdown-like language.
>
> --
> Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] NixOS 14.12 released

[Wout Mertens]

Woohoo!

Thanks for everyone's hard work and Domen especially!

Now I wonder if you shouldn't have made it 15.01 so it would seem all shiny
and new :-D

On Wed, Dec 31, 2014, 10:29 Domen Kožar  wrote:

> Hi all,
>
> community is proud to announce another NixOS stable release  "Caterpillar"
> 14.12.
>
> The release brings many improvements including Nix 1.8 and many packages
> updates. 11972 commits were pushed by 310 contributors since the last
> release (14.04).
>
> ISOs, VirtualBox images and EC2 AMIs can be downloaded from:
>
> http://nixos.org/nixos/download.html
>
> Fresh installation can be done by following Installation chapter in the
> manual:
>
>
> http://hydra.nixos.org/build/18399157/download/2/nixos/sec-installation.html
>
> Upgrade existing NixOS machines:
>
> $ nix-channel --add https://nixos.org/channels/nixos-14.12 nixos
> $ nixos-rebuild switch --upgrade
>
> Report any issues to the bug tracker on
> https://github.com/NixOS/nixos/issues
>
> Thank you all for being involved!
>
> 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] VMware Guest Tools

[Wout Mertens]

Hi Brandon,

Sounds like you'll have to patch the script so it doesn't expect bash to
live at /bin.

On Thu, Jan 1, 2015, 02:37 Brandon Martin  wrote:

> Hey everyone,
>
> New NixOS user here. I have installed NixOS on my MacBook with VMware
> Fusion. I want to install the guest tools but am not sure how. I tried
> following the directions here https://wiki.archlinux.org/
> index.php/Installing_Arch_Linux_in_VMware#Official_VMware_Tools, but when
> trying to run the perl script it asks for the path for each program it uses
> in the script (depmod, more, rmmod, etc...). Then errors with a /bin/bash
> no file error (don't have the exact error right now). How should I be
> handling this?
>
> Thanks!
>
> --
> Brandon Martin
> ___
> 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] Travis builds for master are broken, I'm mystified

[Wout Mertens]

This is the first breakage:
https://travis-ci.org/NixOS/nixpkgs/builds/45113418

The problem seems to be that stdenv.glibc does not exist on travis.

However, checking out that commit seems to give no problems:

$ git checkout 1c8783f
$ nix-instantiate --eval . -A openarena.installPhase
"mkdir -pv $out/bin\ncd $out\nunzip $src\n\nif [ \"x86_64-linux\" ==
\"x86_64-linux\" ]; then\n  patchelf --set-interpreter
/nix/store/la5imi1602jxhpds9675n2n2d0683lbq-glibc-2.20/lib/ld-linux*.so.?
$out/openarena-$version/openarena.x86_64\n  makeWrapper
\"$out/openarena-$version/openarena.x86_64\" \"$out/bin/openarena\" \\\n
 --prefix LD_LIBRARY_PATH :
\"/nix/store/d2p2wqvbbypk0b4i4n4jycjlwqa269qf-SDL-1.2.15/lib:/nix/store/7y7yqg21kb7x529j72qggnghz5y1z11h-libogg-1.3.2/lib:/nix/store/8piqvi5pa88djjmjky6bpqh316sjj9na-libvorbis-1.3.4/lib\"\nelse\n
 patchelf --set-interpreter
/nix/store/la5imi1602jxhpds9675n2n2d0683lbq-glibc-2.20/lib/ld-linux*.so.?
$out/openarena-$version/openarena.i386\n  makeWrapper
\"$out/openarena-$version/openarena.i386\" \"$out/bin/openarena\" \\\n
 --prefix LD_LIBRARY_PATH :
\"/nix/store/d2p2wqvbbypk0b4i4n4jycjlwqa269qf-SDL-1.2.15/lib:/nix/store/7y7yqg21kb7x529j72qggnghz5y1z11h-libogg-1.3.2/lib:/nix/store/8piqvi5pa88djjmjky6bpqh316sjj9na-libvorbis-1.3.4/lib\"\nfi\n"

Any ideas?

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

Re: [Nix-dev] Travis builds for master are broken, I'm mystified

[Wout Mertens]

So the workaround might be to define a null glibc in Darwin but that
doesn't explain why it suddenly started evaluating. There was a staging
merge between the successful Travis build of the PR and the failed build of
the merge:
https://github.com/NixOS/nixpkgs/commit/3a2478605d66b73f598f3b1b930e87fa87785113
but I don't see anything special...

On Fri, Jan 2, 2015, 10:16 Vladimír Čunát  wrote:

> On 01/01/2015 10:13 PM, Georges Dubus wrote:
> > The problem is that, even though the expression is not meant to work on
> > darwin, it is still evaluated there.
>
> Yes, I'm also puzzled by that. There's no glibc in darwin's stdenv
> (darwin has a different libc). It seems like some laziness change or
> something, as openarena only has linuxes in meta.platforms.
>
> IIRC, when I put ``assert stdenv.isLinux;`` on the second line, the
> problem disappeared and some other similar error in another package took
> its place. However, putting those assertions on many places just seems
> wrong, as we have meta.platforms.
>
> 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

Re: [Nix-dev] Request for comments: pinky-promise determinism

[Wout Mertens]

Another use-case: providing the same input hash, based only on version, for
gcc and cross-gcc on another platform. Ditto for ccache and distcc.

On Fri, Jan 2, 2015, 14:56 Shea Levy  wrote:

> For dirty dirty hacks, you can set __noChroot = true and get access to the
> network.
>
> On Jan 2, 2015, at 1:09 PM, Georges Dubus  wrote:
>
> Hello everyone
>
> I would like to propose compromise in the purity rules of non-fixed-output
> derivations, and hear what you think about it.
>
> # Rationale
>
> There are a few situations where derivations play the role of fixed-output
> derivation, but the hash of their output is not fixed. Some examples:
> - fetchgit derivations when the .git must be kept. The .git directory is
> incredibly hard to make deterministic, as this require tweaking with
> implementation details: purging any commit that might have been downloaded
> from the server, that may have no link with the reference we are using.
> - cargo, the package manager for the rust language, uses git to download
> its database, and to check it is up-to-date. The same problem as with
> fetchgit arise, with the increased trouble that we are now tweaking the
> implementation detail of an implementation detail.
>
> However, we can trust that, even though the .git is not binary identical
> in each situation, the result of the git commands we could use in the
> packaging task is always the same.
>
> # Proposition
>
> I propose a new kind of derivation that would be identical to the current
> non-fixed-output derivation, but without any restriction on its access to
> the outside world.
>
> The documentation should state that this kind of derivation is dangerous,
> and should only be used when a trustworthy tool is used (since the tool is
> trusted to be deterministic in its behaviour).
>
> This new derivation could be used for dirty hacks, but this should be
> discouraged by the documentation, and never accepted inside nixpkgs.
>
> # Conclusion
>
> The inclusion of this new kind of derivation would allow a satisfying
> implementation of leaveDotGit for fetchgit, one that does not rely on
> complex tricks[1], and allow me to implement cargo support without relying
> on non-future-proof internals tweaking.
>
> However, this would be at the cost of including a new kind of derivation
> that is much less satisfying, and that could, if misused, come back to bite
> us.
>
>
> I'd love to hear what you think about it.
>
>
> [1]
> https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/fetchgit/nix-prefetch-git#L198
>
>
> --
> Georges Dubus
>  ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] FOSDEM planning Hangout

[Wout Mertens]

Actually, I will be giving a talk at cfgmgmtcamp <http://cfgmgmtcamp.eu/>
(which is right after FOSDEM in Ghent) on Monday at 14:40 titled "NixOS:
Your next favorite server OS" :-D

cfgmgmtcamp is also free and focuses only on configuration management, and
I assume it gets more traffic from work-related visitors.

It will be teeming with puppeteers, chefs and blacksmiths (Ansible), so it
will be a tough sell, but I'll try to give them a good overview.

Wout.

On Sun Jan 04 2015 at 10:28:56 PM Domen Kožar  wrote:

> Don't think anyone is giving a talk this year.
>
> On Sun, Dec 28, 2014 at 9:26 PM, Charles Strahan <
> charles.c.stra...@gmail.com> wrote:
>
>> Is anyone planning on giving a talk? If so, who?
>>
>> On Wed, Dec 17, 2014 at 1:47 PM, Wout Mertens 
>> wrote:
>>
>>> Hi all,
>>>
>>> We got a table at FOSDEM so we'll need volunteers to man the table and
>>> we need to think about what we'll show/do. Swag sales would be nice too.
>>>
>>> If you'd like to help with the planning, please fill out the doodle :
>>> http://doodle.com/br47eeidzgrangqm
>>>
>>> Cheers,
>>>
>>> Wout.
>>>
>>> ___
>>> 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] hydra.nixos.org stopped scheduling jobs

[Wout Mertens]

3.6TB, yikes! Is there a way for us to see what's in the store, like a
mysql dump? Would be interesting to data-mine the dependencies and sizes
etc.

On Mon Jan 05 2015 at 6:28:38 PM aszlig  wrote:

> On Mon, Jan 05, 2015 at 05:03:04PM +0100, Vladim??r ??un??t wrote:
> > Btrfs does no deduplication (by itself at least). Per-file compression
> > should help a little, but I'd expect no huge savings.
>
> I beg to differ, accidentally (forgot to actually enable periodic GC)
> had a 6.4 TB large Nix store on a 3 TB disk array, so it seems that the
> Nix store (or at least the one on my Hydra) compresses well enough.
>
> But what actually is going to be for the worse is that you can't reason
> anymore about how much disk space will be available on a btrfs volume.
>
> a!
> --
> aszlig
> Universal dilettante
> ___
> 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 over PXE

[Wout Mertens]

The last I heard about this was
https://github.com/NixOS/nixpkgs/issues/2100#issuecomment-66155966

On Tue Jan 13 2015 at 5:08:08 AM Thomas Bereknyei 
wrote:

> What is the latest with serving NixOS over PXE?
>
> If this needs work, I can work to put together a sane configuration.
>
> -Tom
> ___
> 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] Funding Hydra Development

[Wout Mertens]

Sure, but who or what gets the money? Will it fund more build systems or
will the money go to a recreation of Hydra in a more popular language? Not
sure if throwing money at the Hydra codebase will speed up compiles (apart
from setting it up to use ccache).

On Wed Jan 21 2015 at 4:57:15 PM stewart mackenzie 
wrote:

> Dear all,
>
> A recent thread regarding contributors brought up a point about
> throwing a stack of money at further devlopment and refinement of
> Hydra.
>
> Wouldn't it be nice to:
> - be able to do as they do in the OpenBSD world by living on master.
> When things break the fix comes in quick. No hanging around for days.
> Releases are a by product of the world of sw distribution on CDs and DVDs.
>
> - (most importantly) Create a distributed community wide Hydra that
> disseminates binaries over something like named data networking.
>
> Might we create an indiegogo campaign? I know NixOS gets limelight on
> sites likes hackernews, so I suspect the campaign could well be a
> success.
>
> What is your opinion?
>
> Kind regards
> Stewart
> ___
> 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] Funding Hydra Development

[Wout Mertens]

nixos@home would be impossible to secure until derivations are bit-for-bit
identical on multiple builds. Then you could do something like, have 1000
builders, and if 501 builders get the same output hash for a derivation, it
gets accepted on the public ledger of input/output hashes. Grow the
builders as the popularity of NixOS grows. You need to subvert a majority
of builders to subvert the binaries.

...but we don't have bit-identical builds... yet.
On Thu Jan 22 2015 at 3:46:48 AM stewart mackenzie 
wrote:

> Forgive me, this is my fault for not being clear enough.
>
> Yes I too would feel uncomfortable about a nixos@home setup unless of
> course it includes some kind of blockchain. Even then it would be too
> expensive to run.
> ___
> 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