[Nix-commits] [NixOS/nixpkgs] b96283: gi-webkit2: fix gi-javascriptcore dependency

[Ryan Trinkle]

  Branch: refs/heads/release-17.03
  Home:   https://github.com/NixOS/nixpkgs
  Commit: b9628313300b7c9e4cc88b91b7c98dfe3cfd9fc4
  
https://github.com/NixOS/nixpkgs/commit/b9628313300b7c9e4cc88b91b7c98dfe3cfd9fc4
  Author: Ryan Trinkle 
  Date:   2017-05-10 (Wed, 10 May 2017)

  Changed paths:
M pkgs/development/haskell-modules/configuration-nix.nix

  Log Message:
  ---
  gi-webkit2: fix gi-javascriptcore dependency

(cherry picked from commit 1927361e44bdc181678ce7604aa429fd26bd66a5)


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

Re: [Nix-dev] [Help] Accidentally removed configuration.nix

[Ryan Trinkle]

Yep, I'm adopting that, too!

On Mon, Apr 10, 2017 at 4:04 PM, Layus  wrote:

> On 10/04/17 19:41, Vince wrote:
>
> Benjamin Herr   schreef op 10 april 2017
> 19:17:44 CEST:
>>
>> I've been putting
>>
>> environment.etc = {
>> nixos-orig.source = ./.;
>> };
>>
>> into my configuration.nix and for my still fairly trivial but at least
>> somewhat moduralized config it seems to work out all right.
>>
>>
>> On Thu, 2017-04-06 at 18:12 +0200, Guillaume Maudoux (Layus) wrote:
>>>
>>>  Hi,
>>>
>>>  system.copySystemConfiguration is far from perfect. As soon as you
>>>  modularize your config, you will miss all the other files.
>>>
>>>  If you want a correct system.copySystemConfiguration, you really
>>>  need
>>>  https://github.com/NixOS/nix/pull/709.
>>>  It allows you to snapshot all the sources of a nix derivation, not
>>>  just
>>>  one file.
>>>
>>>  I tested it back then, and it worked pretty well.
>>>
>>>  -- Layus.
>>>
>>>
>>>  On 06/04/17 17:46, ni...@vince.lol wrote:
>>>
  No I don't have `system.copySystemConfiguration=true` set :-(
  Luckily I documented my recent efforts in some gists.
  I managed to install NixOS on ZFS here:
  https://gist.github.com/awesomefireduck/c763e168a62a0ef559a1fb94732
  61459
  And my (yet untested) attempt at PCI passthrough here:
  https://gist.github.com/awesomefireduck/1be07805081a4d7a51c527e452b
  87b26
  There is still some missing, but nothing I can't handle, I guess.
  This is a great time to enable my ZFS snapshots... :-/

  Does anyone know why `system.copySystemConfiguration` is set to
  false
  by default? It seems like it would be better to default this to
  true,
  right?
  Or at least have this listed in the generated config?
  (`nixos-generate-config`)

  Anyway, I'll be okay, thanks folks!!

  Sincerely,
  Vince
  On Thursday, April 6, 2017 4:58 PM, Sergiu Ivanov
wrote:
>
>
>  Hi Vince,
>
>  Thus quoth  ni...@vince.lol  at 14:12 on Thu, Apr 06 2017:
>>
>>
>>  I acidentally removed my /etc/nixos/configuration.nix is there
>>  any way
>>  I can get it back?
>
>
>
>  Citing directly from:
>
>   http://stackoverflow.com/questions/28603773/recover-accidentally
>  -deleted-configuration-nix-file
>
>
>   '''
>   system.copySystemConfiguration
>
>   If enabled, copies the NixOS configuration file $NIXOS_CONFIG
>  (usually
>   /etc/nixos/configuration.nix) to the system store path.
>
>   Type:"boolean"
>
>   Default:false
>
>   Declared by:    level.nix>
>   '''
>
>  Do you happen to have this option set to true?
>
>  /me goes and sets it to true on his system
>
>  --
>  Sergiu



  --

  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
>>>
>> What does that do, exactly? The entry at http://nixos.org/nixos/
> options.html#environment.etc.%3Cname?%3E.source is somewhat lacking... I
> made a PR at https://github.com/NixOS/nixpkgs/pull/24707 . If some of you
> could check it out and give me some feedback that’d be great :-) cheers,
> Vince
>
> It defines ./. as the content to be copied into /etc/nixos-orig. This
> means that everything in the same directory as the file where this is
> defined will be copied to the store and made available in /etc/nixos-orig.
> Be careful not to secret files and private keys potentially located there,
> as nixos-rebuild often runs as root and will happily copy them to the store.
>
> -- Layus.
>
> ___
> 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] [Help] Accidentally removed configuration.nix

[Ryan Trinkle]

Jeaye,

I totally agree!  One really interesting approach to this that I've seen is
the 'pass' password manager, which can automatically handle the use of git
for passwords.  I wonder if it would be feasible to do this for nixos as
well, so that beginners (who might not be familiar with git) would
automatically be doing "the right" (or at least "a reasonable") thing
without needing to learn about it.


Ryan

On Sun, Apr 9, 2017 at 11:10 PM, Jeaye  wrote:

> On Thu, Apr 06, 2017 at 04:12:03PM +0200, ni...@vince.lol wrote:
> > Hi all,
> >
> > I acidentally removed my /etc/nixos/configuration.nix is there any way I
> can
> > get it back?
> >
> > Sincerely,
> > Vince
>
> I know you've sorted this out now, but I think it's worthwhile to mention
> that one of the benefits of having a text-based, declarative configuration
> for your OS is that you can very easily track it in git. NixOS will handle
> reverts for you, on an OS level, and git can handle them for you on a
> configuration level.
>
> If you don't want to host the configurations publicly, on Github or
> similar, you could do so privately, on Bitbucket or similar.
>
> Best of luck.
>
> ___
> 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] [Help] Accidentally removed configuration.nix

[Ryan Trinkle]

Layus,

That does sound fantastic!  Do you think that PR has a reasonable chance of
landing in the near future?


Ryan

On Thu, Apr 6, 2017 at 12:12 PM, Guillaume Maudoux (Layus) <
layus...@gmail.com> wrote:

> Hi,
>
> system.copySystemConfiguration is far from perfect. As soon as you
> modularize your config, you will miss all the other files.
>
> If you want a correct system.copySystemConfiguration, you really need
> https://github.com/NixOS/nix/pull/709.
> It allows you to snapshot all the sources of a nix derivation, not just
> one file.
>
> I tested it back then, and it worked pretty well.
>
> -- Layus.
>
> On 06/04/17 17:46, ni...@vince.lol wrote:
>
> No I don't have `system.copySystemConfiguration=true` set :-(
> Luckily I documented my recent efforts in some gists.
> I managed to install NixOS on ZFS here: https://gist.github.com/
> awesomefireduck/c763e168a62a0ef559a1fb9473261459
> And my (yet untested) attempt at PCI passthrough here:
> https://gist.github.com/awesomefireduck/1be07805081a4d7a51c527e452b87b26
> There is still some missing, but nothing I can't handle, I guess.
> This is a great time to enable my ZFS snapshots... :-/
>
> Does anyone know why `system.copySystemConfiguration` is set to false by
> default? It seems like it would be better to default this to true, right?
> Or at least have this listed in the generated config?
> (`nixos-generate-config`)
>
> Anyway, I'll be okay, thanks folks!!
>
> Sincerely,
> Vince
>
> On Thursday, April 6, 2017 4:58 PM, Sergiu Ivanov 
>  wrote:
>
>
>
> Hi Vince,
>
> Thus quoth  ni...@vince.lol  at 14:12 on Thu, Apr 06 2017:
>
>
> I acidentally removed my /etc/nixos/configuration.nix is there any way
> I can get it back?
>
>
> Citing directly from:
>
>  http://stackoverflow.com/questions/28603773/recover-accidentally-deleted-
> configuration-nix-file
>
>  '''
>  system.copySystemConfiguration
>
>  If enabled, copies the NixOS configuration file $NIXOS_CONFIG (usually
>  /etc/nixos/configuration.nix) to the system store path.
>
>  Type:"boolean"
>
>  Default:false
>
>  Declared by:  
>  '''
>
> Do you happen to have this option set to true?
>
>
> /me goes and sets it to true on his system
>
> --
> Sergiu
>
>
>
> ___
> nix-dev mailing 
> listnix-...@lists.science.uu.nlhttp://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] [Help] Accidentally removed configuration.nix

[Ryan Trinkle]

Hi Vince,

I do happen to know why it's set to false by default!  I sent a PR to
change it to true a while back, and got some good explanations for why
that's a bad idea here: https://github.com/NixOS/nixpkgs/pull/16922

However, I'm now wondering if it might make sense to add
"system.copySystemConfiguration" to nixos-generate-config's default output;
I added a comment to that PR explaining the idea.


Best,
Ryan

On Thu, Apr 6, 2017 at 11:46 AM,  wrote:

> No I don't have `system.copySystemConfiguration=true` set :-(
> Luckily I documented my recent efforts in some gists.
> I managed to install NixOS on ZFS here: https://gist.github.com/
> awesomefireduck/c763e168a62a0ef559a1fb9473261459
> And my (yet untested) attempt at PCI passthrough here:
> https://gist.github.com/awesomefireduck/1be07805081a4d7a51c527e452b87b26
> There is still some missing, but nothing I can't handle, I guess.
> This is a great time to enable my ZFS snapshots... :-/
>
> Does anyone know why `system.copySystemConfiguration` is set to false by
> default? It seems like it would be better to default this to true, right?
> Or at least have this listed in the generated config?
> (`nixos-generate-config`)
>
> Anyway, I'll be okay, thanks folks!!
>
> Sincerely,
> Vince
>
> On Thursday, April 6, 2017 4:58 PM, Sergiu Ivanov 
> wrote:
>
>
>
> Hi Vince,
>
> Thus quoth  ni...@vince.lol  at 14:12 on Thu, Apr 06 2017:
>
>
> I acidentally removed my /etc/nixos/configuration.nix is there any way
> I can get it back?
>
>
> Citing directly from:
>
>  http://stackoverflow.com/questions/28603773/recover-accidentally-deleted-
> configuration-nix-file
>
>  '''
>  system.copySystemConfiguration
>
>  If enabled, copies the NixOS configuration file $NIXOS_CONFIG (usually
>  /etc/nixos/configuration.nix) to the system store path.
>
>  Type:"boolean"
>
>  Default:false
>
>  Declared by:  
>  '''
>
> Do you happen to have this option set to true?
>
>
> /me goes and sets it to true on his system
>
> --
> Sergiu
>
>
> ___
> 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 for internal projects and monorepos

[Ryan Trinkle]

We (Obsidian Systems) use nix-copy-closure to push the binaries to each
deploy target, update the system profile reference, and then call the
activation script.  So, our target servers never need to evaluate nix code
during a deployment.  My understanding is that nixops does things in a
similar way.

On Fri, Mar 24, 2017 at 4:01 PM, Daniel Peebles 
wrote:

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

Re: [Nix-dev] nixpkgs > 100k commits

[Ryan Trinkle]

Well, there appears to be at least some interest in making it available for
mac/linux (see sanoursa's comment at
https://github.com/Microsoft/GVFS/issues/4).

On Sat, Feb 4, 2017 at 9:40 AM, Matthias Beyer 
wrote:

> On 05-02-2017 01:23:31, Roger Qiu wrote:
> > Awesome! Although if it ever becomes an issue, we could look into GVFS
> (git
> > virtual filesystem) released by Microsoft.
>
> Not sure if troll ...
>
> --
> Mit freundlichen Grüßen,
> Kind regards,
> Matthias Beyer
>
> Consider switching to free software.
> It adds value to your life.
> https://www.gnu.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] Arch is dropping i686. Should we?

[Ryan Trinkle]

I provide i686 binaries for users of reflex-platform, a nix-based
environment for developing GUI applications in Haskell.  I have only a few
confirmed users of i686, but since their machines are correspondingly older
and less powerful than most of my other users', the benefit of nix's binary
caching is especially pronounced.  Building the reflex-platform ecosystem
from scratch takes about 6 hours on a fast, modern machine, so outdated
machines (especially if they are RAM-limited, as most 32-bit systems are)
is, nearly unworkable.

On the other hand, I don't know anything about the cost of supporting i686,
so if cutting it makes sense to others and enables nixpkgs as a whole to
move faster, I certainly won't complain.

On Thu, Jan 26, 2017 at 10:31 AM, Profpatsch  wrote:

> On 17-01-26 08:37am, Graham Christensen wrote:
> > One person on IRC said they think they may have used it once. Does
> > anyone on this list use NixOS on i686? anyone on this list know anyone
> > using NixOS on i686?
>
> I’m using it for one old machine running the audio server
> of our hackerspace.
>
> --
> Proudly written in Mutt with Vim on NixOS.
> Q: Why is this email five sentences or less?
> A: http://five.sentenc.es
> May take up to five days to read your message. If it’s urgent, call me.
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Plan for GHC 8.0.2

[Ryan Trinkle]

Ah, well this is a bit tricky: GHC 8.0.2's build determinism isn't
bit-for-bit, just ABI determinism.  I think build-repeat would still fail.

On Mon, Jan 2, 2017 at 5:56 PM, Bas van Dijk  wrote:

> Eelco recently added support for testing for build determinism to hydra:
>
>   https://github.com/NixOS/hydra/commit/8bb36e79bd9e1752c01499971cc511
> 872c706956
>
> Maybe you can use that. You can also test whole jobsets at once:
>
>   https://github.com/NixOS/hydra/commit/f6081668dc5e9974f7e6fae7e74ea2
> 7dc1a5b3e7
>
> On 2 January 2017 at 21:17, Ryan Trinkle  wrote:
> > By the way, I've done some testing - built a reasonably large slew of
> things
> > - but I haven't extensively tested the reproducibility itself.  If anyone
> > has suggestions on how to approach that, I'll be happy to do some of
> that.
> >
> > On Mon, Jan 2, 2017 at 3:16 PM, Ryan Trinkle 
> wrote:
> >>
> >> Hi guys,
> >>
> >> I submitted a pull request here to enable parallel builds for ghc >
> 8.0.1.
> >> Let me know what you think!  I've definitely been looking forward to
> this
> >> for a long time.
> >>
> >>
> >> Best,
> >> Ryan
> >>
> >> On Mon, Jan 2, 2017 at 9:48 AM, Bas van Dijk 
> wrote:
> >>>
> >>> Hi Peter, that's good news. Thank you!
> >>>
> >>> On 2 January 2017 at 10:47, Peter Simons  wrote:
> >>> > Hi Bas,
> >>> >
> >>> >  > Peter, I was wondering what your plan is regarding GHC-8.0.2. Will
> >>> >  > you add it to the release-16.09 branch [...]?
> >>> >
> >>> > Yes, I'll add it to the release branch. The 'haskellPackages' set
> will
> >>> > continue to follow the LTS-7.x release, though, so it won't become
> the
> >>> > default compiler.
> >>> >
> >>> > Best regards,
> >>> > Peter
> >>> >
> >>> > ___
> >>> > nix-dev mailing list
> >>> > nix-dev@lists.science.uu.nl
> >>> > http://lists.science.uu.nl/mailman/listinfo/nix-dev
> >>> ___
> >>> nix-dev mailing list
> >>> nix-dev@lists.science.uu.nl
> >>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
> >>
> >>
> >
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Plan for GHC 8.0.2

[Ryan Trinkle]

By the way, I've done some testing - built a reasonably large slew of
things - but I haven't extensively tested the reproducibility itself.  If
anyone has suggestions on how to approach that, I'll be happy to do some of
that.

On Mon, Jan 2, 2017 at 3:16 PM, Ryan Trinkle  wrote:

> Hi guys,
>
> I submitted a pull request here
> <https://github.com/NixOS/nixpkgs/pull/21595> to enable parallel builds
> for ghc > 8.0.1.  Let me know what you think!  I've definitely been looking
> forward to this for a long time.
>
>
> Best,
> Ryan
>
> On Mon, Jan 2, 2017 at 9:48 AM, Bas van Dijk  wrote:
>
>> Hi Peter, that's good news. Thank you!
>>
>> On 2 January 2017 at 10:47, Peter Simons  wrote:
>> > Hi Bas,
>> >
>> >  > Peter, I was wondering what your plan is regarding GHC-8.0.2. Will
>> >  > you add it to the release-16.09 branch [...]?
>> >
>> > Yes, I'll add it to the release branch. The 'haskellPackages' set will
>> > continue to follow the LTS-7.x release, though, so it won't become the
>> > default compiler.
>> >
>> > Best regards,
>> > Peter
>> >
>> > ___
>> > nix-dev mailing list
>> > nix-dev@lists.science.uu.nl
>> > http://lists.science.uu.nl/mailman/listinfo/nix-dev
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Plan for GHC 8.0.2

[Ryan Trinkle]

Hi guys,

I submitted a pull request here
 to enable parallel builds for
ghc > 8.0.1.  Let me know what you think!  I've definitely been looking
forward to this for a long time.


Best,
Ryan

On Mon, Jan 2, 2017 at 9:48 AM, Bas van Dijk  wrote:

> Hi Peter, that's good news. Thank you!
>
> On 2 January 2017 at 10:47, Peter Simons  wrote:
> > Hi Bas,
> >
> >  > Peter, I was wondering what your plan is regarding GHC-8.0.2. Will
> >  > you add it to the release-16.09 branch [...]?
> >
> > Yes, I'll add it to the release branch. The 'haskellPackages' set will
> > continue to follow the LTS-7.x release, though, so it won't become the
> > default compiler.
> >
> > Best regards,
> > Peter
> >
> > ___
> > nix-dev mailing list
> > nix-dev@lists.science.uu.nl
> > http://lists.science.uu.nl/mailman/listinfo/nix-dev
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] List of companies using NixOS

[Ryan Trinkle]

My company, Obsidian Systems (https://obsidian.systems/), does consulting
in Haskell and Nix/NixOS.

On Sun, Nov 20, 2016 at 1:55 PM, zimbatm  wrote:

> Hi all,
>
> I am collecting a list of companies that are using NixOS. The idea is to
> encourage adoption by validation.
>
> The list is over here:
> https://www.reddit.com/r/NixOS/comments/5dz8fp/list_of_
> companies_using_nixos/
>
> If you don't feel like posting on Reddit just post here and I'll add them
> over there.
>
> Cheers,
> z
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Building ghcjs-dom

[Ryan Trinkle]

Hi Rodney,

You could take a look at
https://github.com/reflex-frp/reflex-platform/blob/develop/default.nix .  I
didn't realize upstream wasn't building, but I always keep reflex-platform
building (and with binary caches available, see
https://github.com/reflex-frp/reflex-platform/blob/develop/notes/NixOS.md
).  If there's anything in there that can be reused upstream, please feel
free to take the code you need, and I'll help move things upstream however
I can.


Best,
Ryan

On Tue, Nov 1, 2016 at 5:10 AM, Rodney Lorrimar  wrote:

> Hello List,
>
> I would really like this package to build:
>
>   nix-build -A pkgs.haskell.packages.ghcjs.ghcjs-dom
>
> I found that the layout upstream has changed, so updated the overrides
> accordingly (see patch below).
>
> My current problem is that it won't build without Cabal >= 1.24.
>
> If I use (addBuildTool super.ghcjs-dom-jsffi [ self.cabal-install ]),
> then it builds Cabal 1.24 as javascript, which is not quite what I want.
>
> Does anyone know how I could make it build?
>
>
> Cheers,
>
> Rodney
>
>
> ---
>  pkgs/development/haskell-modules/configuration-ghcjs.nix | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/pkgs/development/haskell-modules/configuration-ghcjs.nix
> b/pkgs/development/haskell-modules/configuration-ghcjs.nix
> index c97296c..e56d7eb 100644
> --- a/pkgs/development/haskell-modules/configuration-ghcjs.nix
> +++ b/pkgs/development/haskell-modules/configuration-ghcjs.nix
> @@ -88,12 +88,16 @@ self: super:
>   }) {};
>
>ghcjs-dom = overrideCabal super.ghcjs-dom (drv: {
> -libraryHaskellDepends = [ self.ghcjs-base ] ++
> +libraryHaskellDepends = [ self.ghcjs-base self.ghcjs-dom-jsffi ] ++
>removeLibraryHaskellDepends [
> -"glib" "gtk" "gtk3" "webkitgtk" "webkitgtk3"
> +"ghcjs-dom-jsaddle" "ghcjs-dom-webkit"
>] drv.libraryHaskellDepends;
>});
>
> +  ghcjs-dom-jsffi = overrideCabal super.ghcjs-dom-jsffi (drv: {
> +libraryHaskellDepends = [ self.ghcjs-base self.text ];
> +  });
> +
>ghc-paths = overrideCabal super.ghc-paths (drv: {
>  patches = [ ./patches/ghc-paths-nix-ghcjs.patch ];
>});
> --
> 2.10.1
> ___
> 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] Internet Issue

[Ryan Trinkle]

I've encountered this sort of thing once before, and the culprit was
dnsmasq getting into some loop where it flooded the network with requests
for the same domain over and over.

On Fri, Sep 23, 2016 at 11:51 AM, Tomasz Czyż  wrote:

> whireshark is your friend
>
> 2016-09-23 16:46 GMT+01:00 Taeer Bar-Yam :
>
>> It *seems* as though my computer is breaking the internet for other
>> people. Sometimes at home the internet cuts out (not the wifi, that still
>> connects; but webpages do not load on anyone's computers). This also
>> happens at my friend's house, but not the on-campus wifi network. It
>> appears to only happen when I am there and try to connect to the internet,
>> but it doesn't always happen when I try to connect to the internet.
>>
>> Is it possible that my computer is responsible? What would be causing
>> that?
>>
>> I am using NixOS 16.03 stable and my internet setup is:
>> ```
>> networking.hostName = "rebel";
>> networking.networkmanager.enable = true;
>> ```
>> and I'm using ```nmtui connect``` to connect to the wifi network
>>
>> let me know if there's any other relevant information I should send.
>>
>>  --Taeer
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>
>
>
> --
> Tomasz Czyż
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] zlib, iconv, bzip2, et. al.

[Ryan Trinkle]

Have you tried installing those libraries with `nix-env -i`?  You may need
to add some stuff to your environment to make the linker find them, but
that should put them in your ~/.nix-profile/lib.

On Wed, Sep 7, 2016 at 7:18 AM, Thomas Bereknyei  wrote:

> Ryan,
>
> Thia happens in my normal zsh shell. Cabal will complain about a missing
> library, but I can fix that by going to 'nix-shell -p libiconv'. Stack
> interacting with nix changes things so it sometimes works, I dont have a
> clear example.  Stack setup or even try-reflex has given me this sort of
> issue. I resorted to adding addBuildDepends to a bunch of packages in
> try-reflex's defsault.nix, but somehow i don't think anyone else is doing
> that. My normal shell just never seems to have the libraries in scope and
> no amount of nix-env seems to work. It's as if I'm not getting the -dev
> versions.
>
>  Tom
>
>> -----
>>
>> Message: 1
>> Date: Tue, 6 Sep 2016 16:50:58 -0400
>> From: Ryan Trinkle 
>> To: Thomas Bereknyei 
>> Cc: nix-dev 
>> Subject: Re: [Nix-dev] zlib, iconv, bzip2, et. al.
>> Message-ID:
>> > mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Can you provide the command line you're using to get into the nix shell?
>> My understanding was that this kind of thing should be handled
>> automatically, but apparently that's not always the case.
>>
>> On Tue, Sep 6, 2016 at 8:23 AM, Thomas Bereknyei 
>> wrote:
>>
>> > I often have a problem where a library is not available during
>> > compilation, usually Haskell. The standard answer is to start
>> 'nix-shell -p
>> > zlib' and proceed. Is there a way to have them in my standard
>> environment?
>> > This occurs both on OSX and NixOS even when i have those packages
>> installed
>> > (either via nixos-rebuild or nix-env). I am also using zsh.
>> >
>> > Tom
>> >
>> >
>>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] zlib, iconv, bzip2, et. al.

[Ryan Trinkle]

Can you provide the command line you're using to get into the nix shell?
My understanding was that this kind of thing should be handled
automatically, but apparently that's not always the case.

On Tue, Sep 6, 2016 at 8:23 AM, Thomas Bereknyei  wrote:

> I often have a problem where a library is not available during
> compilation, usually Haskell. The standard answer is to start 'nix-shell -p
> zlib' and proceed. Is there a way to have them in my standard environment?
> This occurs both on OSX and NixOS even when i have those packages installed
> (either via nixos-rebuild or nix-env). I am also using zsh.
>
> 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

[Nix-commits] [NixOS/nixpkgs] bf6fda: ghcjs: work around haskell/cabal#3494

[Ryan Trinkle]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: bf6fdae0f26546d96d08a51f623f910c2a0efa18
  
https://github.com/NixOS/nixpkgs/commit/bf6fdae0f26546d96d08a51f623f910c2a0efa18
  Author: Ryan Trinkle 
  Date:   2016-07-27 (Wed, 27 Jul 2016)

  Changed paths:
M pkgs/development/compilers/ghcjs/default.nix

  Log Message:
  ---
  ghcjs: work around haskell/cabal#3494

See also NixOS/nixpkgs#16144


  Commit: 92d21f11153faa7ce314e50fd8679820e95d855b
  
https://github.com/NixOS/nixpkgs/commit/92d21f11153faa7ce314e50fd8679820e95d855b
  Author: Ryan Trinkle 
  Date:   2016-07-27 (Wed, 27 Jul 2016)

  Changed paths:
M pkgs/development/compilers/ghcjs/default.nix

  Log Message:
  ---
  Merge pull request #17314 from ryantrinkle/ghcjs-cabal-3494

ghcjs: work around haskell/cabal#3494


Compare: https://github.com/NixOS/nixpkgs/compare/103805dec584...92d21f11153f___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] c56499: ghcjs: refactor stage2 handling

[Ryan Trinkle]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: c564997ba0372147a2b0f376073fdfdd37306152
  
https://github.com/NixOS/nixpkgs/commit/c564997ba0372147a2b0f376073fdfdd37306152
  Author: Ryan Trinkle 
  Date:   2016-07-26 (Tue, 26 Jul 2016)

  Changed paths:
M pkgs/development/compilers/ghcjs/default.nix
A pkgs/development/compilers/ghcjs/gen-stage2.rb
A pkgs/development/compilers/ghcjs/stage2.nix
M pkgs/development/haskell-modules/configuration-ghcjs.nix
R pkgs/development/haskell-modules/ghcjs/gen-stage2.rb
R pkgs/development/haskell-modules/ghcjs/stage2.nix

  Log Message:
  ---
  ghcjs: refactor stage2 handling

Previously, the stage2 information was stored in haskell-modules, and imported 
directly from there.  However, the correct stage2 information is determined by 
the version of ghcjs-boot repository.  This commit makes the stage2 information 
part of the ghcjs derivation, which improves organization and makes it possible 
to override stage2 when overriding ghcjs.


  Commit: 0905aea14e6dc6462288de63858d27158831b7bc
  
https://github.com/NixOS/nixpkgs/commit/0905aea14e6dc6462288de63858d27158831b7bc
  Author: Ryan Trinkle 
  Date:   2016-07-27 (Wed, 27 Jul 2016)

  Changed paths:
M pkgs/development/compilers/ghcjs/default.nix
A pkgs/development/compilers/ghcjs/gen-stage2.rb
A pkgs/development/compilers/ghcjs/stage2.nix
M pkgs/development/haskell-modules/configuration-ghcjs.nix
R pkgs/development/haskell-modules/ghcjs/gen-stage2.rb
R pkgs/development/haskell-modules/ghcjs/stage2.nix

  Log Message:
  ---
  Merge pull request #17276 from ryantrinkle/ghcjs-8.0-support

ghcjs: refactor stage2 handling


Compare: https://github.com/NixOS/nixpkgs/compare/86393cfc205c...0905aea14e6d___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 2bae6b: ghc8 | config: ghcjs-prim: init at 0.1.0.0

[Ryan Trinkle]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 2bae6b673782edb18bc322213d7fc0a43c14c9b1
  
https://github.com/NixOS/nixpkgs/commit/2bae6b673782edb18bc322213d7fc0a43c14c9b1
  Author: Ryan Trinkle 
  Date:   2016-05-10 (Tue, 10 May 2016)

  Changed paths:
M pkgs/development/haskell-modules/configuration-ghc-8.0.x.nix

  Log Message:
  ---
  ghc8 | config: ghcjs-prim: init at 0.1.0.0


  Commit: e3417b0f71b7062e9ac7cf11611363e3bcd93c5c
  
https://github.com/NixOS/nixpkgs/commit/e3417b0f71b7062e9ac7cf11611363e3bcd93c5c
  Author: Ryan Trinkle 
  Date:   2016-05-10 (Tue, 10 May 2016)

  Changed paths:
M pkgs/development/haskell-modules/configuration-ghc-8.0.x.nix

  Log Message:
  ---
  Merge pull request #15375 from ryantrinkle/ghc8-ghcjs-prim

ghc8 | config: ghcjs-prim: init at 0.1.0.0


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

Re: [Nix-dev] NixON initiative

[Ryan Trinkle]

It seems like it might be a good idea to ensure that the output of
nix-prefetch-git can always be fed into fetchgit via builtins.fromJSON.  To
move things a bit closer to that, I submitted
https://github.com/NixOS/nixpkgs/pull/14111 .  It would be great if zimbatm
and anyone else who's interested could take a look at that and let me know
what they think.


Ryan

On Sat, Mar 19, 2016 at 6:50 PM, Ryan Trinkle 
wrote:

> Hi everyone,
>
> These are great changes, but I would like to note that having a stable
> machine-readable output format for nix-prefetch-git would be very helpful.
> I frequently use that command in scripts, and the recent changes have
> caused some breakage.  Of course, Nix makes that breakage pretty easy to
> deal with, which is very nice!
>
>
> Regards,
> Ryan
>
> On Thu, Mar 3, 2016 at 7:39 PM, Shea Levy  wrote:
>
>> On 2016-03-03 19:34, Profpatsch wrote:
>> > On 16-02-28 04:44pm, zimbatm wrote:
>> >> So something like that ? https://github.com/NixOS/nixpkgs/pull/13552
>> >> And then we would convert all of our tooling to output JSON ?
>> >
>> > As long as nixexprs embedded in the JSON are *not* evaluated in any
>> > way,
>> > we are fine.
>> >
>> > Think of
>> >
>> > {
>> >   "hello" = "{ foo = (abort \"ops\"); }"
>> > }
>> >
>> > And no, please noone think this is a good idea and we should support
>> > that.
>>
>> Nope, the JSON parsing builtin just treats everything as plain old
>> data.
>> ___
>> 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] NixON initiative

[Ryan Trinkle]

Hi everyone,

These are great changes, but I would like to note that having a stable
machine-readable output format for nix-prefetch-git would be very helpful.
I frequently use that command in scripts, and the recent changes have
caused some breakage.  Of course, Nix makes that breakage pretty easy to
deal with, which is very nice!


Regards,
Ryan

On Thu, Mar 3, 2016 at 7:39 PM, Shea Levy  wrote:

> On 2016-03-03 19:34, Profpatsch wrote:
> > On 16-02-28 04:44pm, zimbatm wrote:
> >> So something like that ? https://github.com/NixOS/nixpkgs/pull/13552
> >> And then we would convert all of our tooling to output JSON ?
> >
> > As long as nixexprs embedded in the JSON are *not* evaluated in any
> > way,
> > we are fine.
> >
> > Think of
> >
> > {
> >   "hello" = "{ foo = (abort \"ops\"); }"
> > }
> >
> > And no, please noone think this is a good idea and we should support
> > that.
>
> Nope, the JSON parsing builtin just treats everything as plain old
> data.
> ___
> 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] Feature request: replace the Darwin stdenv with the pure Darwin stdenv

[Ryan Trinkle]

This looks fantastic.  The pure-darwin work has been critical to getting my
originally-linux-based toolchain working properly on mac, and I'm glad to
see it continuing to move forward like this.  Thanks very much to pikajude,
copumpkin, and all the others who have contributed to this work.


Ryan

On Wed, Sep 30, 2015 at 3:48 PM, Jude  wrote:

> Hi all, pikajude here, maintainer of the pure-darwin stdenv in nixpkgs.
>
> Over the past few days in ##nix-darwin, I've discovered that the impure
> Darwin stdenv on master is broken for nearly everyone due to Xcode 7's
> introduction of `.tbd` files for library stubs; see
> https://forums.developer.apple.com/thread/4572.
>
> As far as I have been able to investigate, .tbd compatibility is an Xcode
> 7-exclusive feature, and I'm not sure whether the changes required to use
> them are open-source yet. There is a temporary fix to downgrade to Xcode
> 6.4, but that will obviously only work for a limited time. For people who
> do use Xcode, I don’t want to restrict them to an older version because our
> nixpkgs stdenv completely fails at what it is intended to do.
>
> This continues the precedent of OSX updates breaking parts of nixpkgs
> without warning.
>
> pure-darwin mitigates this problem because the entire compiler toolchain
> and environment (save a symlink to libSystem, which won't be changing
> anytime soon) is in the Nix store. If I can get approval, I would love to
> replace the current Darwin stdenv with the pure one, because it would allow
> us to upgrade our toolchain on our own terms, as well as work nicely
> alongside any Xcode version a user would care to install.
>
> I would also like to merge the pure stdenv because it will result in us
> getting Hydra builds for it, which is the main roadblock that turns people
> off of using pure-darwin. Having Hydra build the pure stdenv also gives us
> an easy way to see which packages are broken on pure-darwin.
>
> Answers to some common questions:
>
> Q: Does pure-darwin fix the missing -lgcc_s.10.5 problem?
> A: Yes. In the Xcode update, libgcc_s.10.5.dylib was changed from a
> symlink to /usr/lib/libSystem.dylib to a text-based library stub that
> (AFAIK) only Xcode 7 can currently use. In pure-darwin, libgcc_s is still a
> symlink, so ld will understand it just fine.
>
> Q: Will pure-darwin break anything for me?
> A: Right now, probably. I’ve been largely the only pure-darwin maintainer
> for a few months, and my time and ability to fix packages are limited. I
> welcome you to try the pure-darwin stdenv to see if there are any broken
> packages. Over the next few days I will be working on building every
> package that claims to be Darwin-compatible, in order to weed out the
> remaining errors. Most fixes are trivial. About half of the broken packages
> I encounter just need to have libiconv added as a build input.
>
> If breakages concern you, you can use the “replaceStdenv” feature of your
> nixpkgs config to revert to the old stdenv for as long as necessary.
> Packages built with either stdenv will coexist peacefully.
>
> Q: Do I have to turn on the build sandbox to use pure-darwin?
> A: Not if you don’t want to. The sandbox is just an extra layer of
> security to make sure that the outside world isn’t polluting our builds,
> but it certainly isn’t mandatory. Even without the sandbox, your compiler
> will still be using its own toolchain, which means that Xcode updates will
> not break it.
>
> Q: How do I turn on the build sandbox?
> A: Add "build-use-chroot = true” to your /etc/nix/nix.conf. The sandbox is
> not enabled by default.
>
> Q: Anything else I need to know?
> A: In nix-1.10, the sandbox is very imperfect and will cause a lot of
> false negatives. This causes building polyml and Haskell packages to fail,
> among a few other things.
>
> Nix pull request #562 (https://github.com/NixOS/nix/pull/562) addresses
> these problems. If you intend to make heavy usage of the sandbox feature,
> you should definitely use the checkout of nix in that pull request until it
> gets merged into master.
>
> Again, if you’re worried about the sandbox breaking builds, feel free to
> disable it.
>
> Please let me know if you have other questions.
>
> Jude
>
> PS: Sorry for double-post! I sent an email from my old address, which is
> now stuck in the moderation queue.
>
> ___
> 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] i686 Builds?

[Ryan Trinkle]

I encountered an i686 user just the other day!  I don't use it personally,
but having solid support in Nix was fantastic, especially because older,
32-bit machines tend to be slower, which makes Nix's binary caching
functionality even more important.

On Mon, May 11, 2015 at 6:36 PM, Shea Levy  wrote:

> Hi all,
>
> Do we still have users running 32-bit machines? It would reduce the load on
> hydra significantly if we could drop support for i686, though of course if
> people are still relying on it we shouldn't make the change yet.
>
> ~Shea
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Depending on a service from inside an expression?

[Ryan Trinkle]

It's possible to run postgres with just a unix domain socket for
communication, and no network access. Then, you can point your tests at
that self-contained postgres environment.  Would that work for your
situation?

On Mon, Apr 27, 2015 at 8:52 PM, Mateusz Kowalczyk 
wrote:

> Hi,
>
> There is a project that as part of its tests has to create a postgresql
> database which means that the postgres server needs to be running.
>
> Is there an easy way to achieve this? How does one go about testing such
> packages to begin with?
>
> --
> Mateusz K.
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Gratuitous generations

[Ryan Trinkle]

Ah, I didn't know about that option!  That sounds good; where does it copy
it to, though?  It isn't clear to me from the docs.

On Tue, Mar 31, 2015 at 8:02 AM,  wrote:

> On Monday, March 30, 2015 16:16:36 Ryan Trinkle wrote:
> > Ah, great point!  This line worked perfectly for me:
> >
> > environment.etc."nixos/current/configuration.nix".text =
> builtins.readFile
> > ./configuration.nix;
>
> I have been using this option: system.copySystemConfiguration = true;
>
> Placing the current config "closer" to /etc/nixos/configuration.nix makes
> it
> easier to run diff against the active profile. copySystemConfiguration's
> location
> makes it easier to dig older profiles. Maybe it's a good idea to use both
> locations?
>
> > On Mon, Mar 30, 2015 at 4:10 PM, Michael Raskin <7c6f4...@mail.ru>
> wrote:
> > > >On Mon, Mar 30, 2015 at 9:47 PM, Ryan Trinkle  >
> > >
> > > wrote:
> > > >> On a somewhat related note, is there any way to see the exact
> > > >> configuration.nix for a particular generation?  It would be great
> to be
> > >
> > > able
> > >
> > > >> to diff generations against each other (e.g.: to figure out whether
> a
> > > >> channel update caused a problem or whether it was my own change).
> > > >
> > > >You are not the first one to request this feature.
> > > >They are a few issues in the way, but I will open an issue and do it
> > > >as soon as I am done with the httpd rewrite.
> > >
> > > In the meantime just adding /etc/ entry that is a copy of
> > > /etc/nixos/configuration.nix should work…
>
> ___
> 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] Gratuitous generations

[Ryan Trinkle]

Ah, great point!  This line worked perfectly for me:

environment.etc."nixos/current/configuration.nix".text = builtins.readFile
./configuration.nix;


On Mon, Mar 30, 2015 at 4:10 PM, Michael Raskin <7c6f4...@mail.ru> wrote:

> >On Mon, Mar 30, 2015 at 9:47 PM, Ryan Trinkle 
> wrote:
> >> On a somewhat related note, is there any way to see the exact
> >> configuration.nix for a particular generation?  It would be great to be
> able
> >> to diff generations against each other (e.g.: to figure out whether a
> >> channel update caused a problem or whether it was my own change).
> >
> >You are not the first one to request this feature.
> >They are a few issues in the way, but I will open an issue and do it
> >as soon as I am done with the httpd rewrite.
>
> In the meantime just adding /etc/ entry that is a copy of
> /etc/nixos/configuration.nix should work…
>
>
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Gratuitous generations

[Ryan Trinkle]

That sounds awesome; thanks!

On Mon, Mar 30, 2015 at 3:51 PM, Nicolas Pierron <
nicolas.b.pier...@gmail.com> wrote:

> Hi Ryan,
>
> On Mon, Mar 30, 2015 at 9:47 PM, Ryan Trinkle 
> wrote:
> > On a somewhat related note, is there any way to see the exact
> > configuration.nix for a particular generation?  It would be great to be
> able
> > to diff generations against each other (e.g.: to figure out whether a
> > channel update caused a problem or whether it was my own change).
>
> You are not the first one to request this feature.
> They are a few issues in the way, but I will open an issue and do it
> as soon as I am done with the httpd rewrite.
>
> --
> 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

Re: [Nix-dev] Gratuitous generations

[Ryan Trinkle]

On a somewhat related note, is there any way to see the exact
configuration.nix for a particular generation?  It would be great to be
able to diff generations against each other (e.g.: to figure out whether a
channel update caused a problem or whether it was my own change).


Ryan

On Mon, Mar 30, 2015 at 1:32 PM, Christian Theune 
wrote:

> Hi,
>
> > On 30 Mar 2015, at 15:07, Eelco Dolstra 
> wrote:
> >
> > The reason is to ensure that "nixos-rebuild switch; nixos-rebuild
> rollback"
> > always rolls back to the configuration just before the switch, not to
> some
> > earlier configuration. If "nixos-rebuild switch" is a logical no-op,
> then the
> > rollback should do nothing, too.
> >
> > Note that generations are cheap (they're just symlinks), but we should
> probably
> > filter redundant generations from the GRUB boot menu.
>
> Thanks for the explanation: that was exactly one of the things I noticed
> getting polluted. So, I understand that generations are cheap as technical
> resources but as we’ve seen they may have some mental over head in some
> places. Especially if you can’t see that they changed something - listings
> then quickly become meaningless if you’re trying to build a convergent
> system that wants to consider rebuilds to be not only cheap when nothing
> happens but abundant and with no ill effects to the user. :)
>
> My personal choice would also be that listing generations would show me
> those that actually changed something.
>
> > We could add an option to suppress creating a new generation if nothing
> has changed.
>
> Sounds like an idea to start working on this. If your main concern is to
> avoid accidentally breaking the switch/rollback semantics while providing
> this then maybe at some point the option could be dropped.
>
> Mulling over this: I’m not sure what the clear expectation is on the
> switch/rollback scenario when nothing is changing. Knowing that rolback
> always gets me to the point prior to the last switch (independently whether
> something was changed or not) is a simple rule (which is good). I can also
> see that rollback fixes the last change. This would require users to
> understand when a rebuild introduced a change or not. This would require an
> additional concept to be present, the overhead of that is currently unclear
> to me.
>
> Time for experimentation, I think. :)
>
> As I’m just getting warm with the code base: would you care to give me a
> pointer where I should start staring at some code that this option would be
> relevant at?
>
> Another thought how this could be approached: let rebuild create new
> generations, but offer a cleaning tool that cleans up generations that
> didn’t do anything. However, that would likely require keeping the original
> version and maybe the newest that is a clone (to avoid active system
> breakage). I think I’d personally prefer avoiding to generate superfluous
> generations.
>
> Cheers,
> Christian
>
> —
> Christian Theune · c...@flyingcircus.io · +49 345 219401 0
> Flying Circus Internet Operations GmbH · http://flyingcircus.io
> Forsterstraße 29 · 06112 Halle (Saale) · Deutschland
> HR Stendal HRB 21169 · Geschäftsführer: Christian. Theune, Christian.
> Zagrodnick
>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] State database in nixops

[Ryan Trinkle]

At skedge.me, we've recently switched over to nixops for all deployments,
so we've run into this issue as well.  We're moving towards the shared
machine approach, but it's not completely satisfying, because it creates a
single point of failure.

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

On Sat, Feb 21, 2015 at 3:52 PM, Domen Kožar  wrote:

> Best way is to have a shared machine to deploy from.
>
> Another option would be to create a web interface for nixops.
>
> On Fri, Feb 20, 2015 at 7:05 AM, Thomas Hunger  wrote:
>
>> Hi,
>>
>> I've been a happy user of nixops for my own projects for a while. It
>> works fine as a single user tool but we found it to be tricky to use with
>> multiple developers, or even just a CI system that calls nixops deploy.
>>
>> One issue we had is absolute paths in the state. I.e. if I "nixops
>> export" my state and then import and use it on e.g. the jenkins account I
>> need to adjust the absolute paths.
>>
>> Another issue we have is that checking a sqlite database into git isn't
>> great for reviews.
>>
>> We have a semi-working system now where jenkins calls "nixops deploy -s
>> /var/common-state/project.sqlite ..." on our deploy server, and we have
>> local copies of that state for emergency deploys.
>>
>> First: How are other people solving collaboration on nixops state?
>>
>> Secondly: Is there any interest in extending nixops to have a text (e.g.
>> protobuf-ascii) state file with relative paths that could be checked into
>> git? There are a few unclear design choices, e.g. what to do with ec2
>> backups. But for our purposes it would be better to use AWSs list of
>> volumes as the source-of-truth for backups (e.g. by adding more tags).
>>
>> best,
>> Tom
>>
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Haskell Platform, anyone?

[Ryan Trinkle]

I never use the Haskell Platform with nix, because nixpkgs.haskellPackages
is already a curated package set that always seems to work together.
Perhaps people transitioning projects to nix from other platforms would get
some benefit out of having access to the Platform as such, but in my
context (several moderately large commercial projects), it doesn't come up.

On Fri, Nov 7, 2014 at 2:11 PM, Peter Simons  wrote:

> Hi guys,
>
> Haskell Platform 2014.2.0.0 has been released a while ago, and I can't
> help noticing that no-one seems to be in a hurry to add that to Nixpkgs.
> Apparently, there not much of a demand for Haskell Platform in Nix?
>
> This makes me wonder about the old HP releases that we still have:
> 2009.2.0.2, 2010.1.0.0, 2010.2.0.0, 2011.2.0.0, 2011.2.0.1, 2011.4.0.0,
> 2012.2.0.0, 2012.4.0.0, and 2013.2.0.0.
>
> All of those builds were pretty much non-functional until recently
> because none of them actually installed a compiler into the user
> profile, but no-one noticed that for a period of several months.
>
> Having those old versions around forces us to keep ancient versions of
> many HP member packages like HTTP, mtl, vector, etc., too, and that adds
> a bit of complexity to Nixpkgs. Since no-one seems to *use* that stuff,
> I'm tempted to say that we should drop support for Haskell Platform
> altogether and to throw out all these ancient package versions in the
> process.
>
> How do others feel about that? Do you desperately want to be able to
> install Haskell Platform 2010.2.0.0 any time soon?
>
> Best regards,
> Peter
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] XMonad and Taffybar on nixos

[Ryan Trinkle]

The easiest way I've found to do (possibly complex) dependencies for xmonad
is to add a default.nix to my ~/.xmonad directory and then add this
keybinding to xmonad:

((mod4Mask, xK_q), spawn "cd ~/.xmonad ; nix-shell --pure --command 'ghc
--make xmonad.hs -i -ilib -fforce-recomp -v0 -o xmonad-x86_64-linux' &&
xmonad --restart")

It's a bit of a hack, but it's been working very reliably for me, and lets
me add whatever I need to the xmonad environment.


Ryan

On Tue, Oct 28, 2014 at 7:46 PM, Richard Wallace <
rwall...@thewallacepack.net> wrote:

> Hello,
>
> Is anyone using xmonad and taffybar on nixos?  I'm trying to, but I'm
> running into an issue with xmonad not being able to find modules provided
> by taffybar.
>
> Trying compile xmonad results in "Could not find module:
> System.Taffybar.Hooks.PagerHints"
>
> I set up xmonad as described on the NixOS Xmonad wiki page.  I installed
> taffybar using environment.systemPackages in my configuration.nix.  Any
> idea what I am missing?
>
> 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] Integration of Haste packages

[Ryan Trinkle]

Hi Thomas,

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


Ryan

On Thu, Sep 25, 2014 at 5:16 PM, Thomas Strobel  wrote:

> Hi!
>
> I'm thinking of working on the integration of Haste packages into NixOS
> on the weekend. I want to hook onto the package management of Haskell,
> and adapt it for Haste.
>
> Now, I wanted to ask if someone already started to work on that or had
> any ideas or thoughts about it. If so, it would be nice if you would let
> me know about it.
>
>
> Many thanks,
> Thomas
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Job Opening - Nix/Haskell devops

[Ryan Trinkle]

Hi everyone,

skedge.me, is looking for a full-time devops engineer to build a system for
automating infrastructure tasks with Haskell, NixOS, and Amazon Web
Services.  We're a small, rapidly-growing startup, and infrastructure
automation is a critical to our continued growth.  Our clients include Bed
Bath & Beyond and cosmetics retailer Sephora.  Our office is in midtown
Manhattan; if you're in NYC, that's a plus, but we're also open to remote
work.

If you're interested, please send me an email at r...@skedge.me, or reply
to this message with any general questions or comments.


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