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

2014-11-03 Thread Daniel Peebles
Anyone interested in this project should join ##nix-darwin on
freenode. There's still lots to do!

On Mon, Nov 3, 2014 at 9:31 PM, Joel  wrote:
> Daniel Peebles, John Wiegley, Eric Seidel, and myself have been working on a
> clang-based stdenv for OSX for the past few weeks. It is fully functional
> now and you can find it at https://github.com/joelteon/nixpkgs. It’s being
> continuously built on my Hydra instance at https://hydra.joelt.io/. If you
> would like to use our branch you should add hydra.joelt.io to your binary
> caches. To my knowledge this is the only nixpkgs fork that works with
> Yosemite.
>
> Daniel is also working on a 100% pure stdenv (which involves building
> Apple’s open source libc), but that’s still in the works.
>
> There are a few notable changes besides the obvious change in compiler. We
> are willing to revert these before merging into NixOS upstream, since
> they’re pretty major:
>
> * stdenv.gcc has been renamed to stdenv.cc. In the process we fixed a few
> bugs where packages incorrectly referred to gcc instead of the stdenv’s
> compiler. However, this does result in totally rebuilding the Linux stdenv
> as well, since the generic setup script now expects a $cc variable instead
> of a $gcc variable.
> * Instead of using the string “gcc” or “${stdenv.gcc}/bin/gcc”, we now use
> `stdenv.progname` (and `stdenv.prognamexx`).
>
> We had a few motivations for this effort. I’d been considering using clang
> as my stdenv’s main compiler ever since I found out that some of the
> packages I hold dear (such as vim and phantomjs) need to be built with
> Apple’s ported GCC 4.2.1. Aside from my philosophical objection to this,
> Yosemite’s developer previews were unable to compile GCC at all (at least
> for the first 3). I think it’s possible to compile GCC on Yosemite GM, but
> I’m no longer inclined to try as this branch now uses Apple’s officially
> supported compiler.
>
> We’d welcome your input and also your help; there’s still a lot left to do.
>
> ___
> 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] clang-based stdenv for OSX Yosemite

2014-11-03 Thread Joel
Daniel Peebles, John Wiegley, Eric Seidel, and myself have been working on a 
clang-based stdenv for OSX for the past few weeks. It is fully functional now 
and you can find it at https://github.com/joelteon/nixpkgs 
. It’s being continuously built on my 
Hydra instance at https://hydra.joelt.io/ . If you 
would like to use our branch you should add hydra.joelt.io to your binary 
caches. To my knowledge this is the only nixpkgs fork that works with Yosemite.

Daniel is also working on a 100% pure stdenv (which involves building Apple’s 
open source libc), but that’s still in the works.

There are a few notable changes besides the obvious change in compiler. We are 
willing to revert these before merging into NixOS upstream, since they’re 
pretty major:

* stdenv.gcc has been renamed to stdenv.cc . In the process 
we fixed a few bugs where packages incorrectly referred to gcc instead of the 
stdenv’s compiler. However, this does result in totally rebuilding the Linux 
stdenv as well, since the generic setup script now expects a $cc variable 
instead of a $gcc variable.
* Instead of using the string “gcc” or “${stdenv.gcc}/bin/gcc”, we now use 
`stdenv.progname` (and `stdenv.prognamexx`).

We had a few motivations for this effort. I’d been considering using clang as 
my stdenv’s main compiler ever since I found out that some of the packages I 
hold dear (such as vim and phantomjs) need to be built with Apple’s ported GCC 
4.2.1. Aside from my philosophical objection to this, Yosemite’s developer 
previews were unable to compile GCC at all (at least for the first 3). I think 
it’s possible to compile GCC on Yosemite GM, but I’m no longer inclined to try 
as this branch now uses Apple’s officially supported compiler.

We’d welcome your input and also your help; there’s still a lot left to do.___
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

2014-11-03 Thread Tobias Geerinckx-Rice
On 3 November 2014 21:49, Wout Mertens  wrote:
>
> How does SSH influence your system not booting? I'm not sure I understand...

Heh. I think I can answer that.

If OP's hybrid solid-state drive is like mine, it calls itself a
"SSHD". A needlessly confusing red herring that is entirely unrelated
to sshd, the remote shell service.

Regards,

T G-R
___
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

2014-11-03 Thread 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

2014-11-03 Thread J. Brian Kelley

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 Kelley 
To: 	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

2014-11-03 Thread J. Brian Kelley
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.


On 2014-11-03 10:13, Wout Mertens wrote:
> 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...

___
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

2014-11-03 Thread 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

2014-11-03 Thread J. Brian Kelley
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


Re: [Nix-dev] ghc-mod depends on Wayland

2014-11-03 Thread Andreas Herrmann
Thanks for pointing this out. I agree, I think a build-time dependency on 
emacs-nox, and no run-time dependency on emacs would be a great solution.

Best, Andreas


On Monday 03 November 2014 11:26:12 Peter Simons wrote:
> Please see https://github.com/NixOS/nixpkgs/issues/4561.
> 
> 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] ghc-mod depends on Wayland

2014-11-03 Thread Peter Simons
Please see https://github.com/NixOS/nixpkgs/issues/4561.

Peter

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


Re: [Nix-dev] ghc-mod depends on Wayland

2014-11-03 Thread Mathijs Kwik
ghc-mod should not have a runtime dependency on emacs at all.

At build-time, emacs-nox sounds fine indeed.



Andreas Herrmann  writes:

> Hello everyone,
>
> Recently, I tried to install the ghc-mod package. I was surprised to
> see that nix-env intended to install a _large_ amount of dependencies
> down to quite unexpected ones such as Wayland.
>
> I dug into the dependency tree:
>
> nix-store -qR --tree $(nix-instantiate -A haskellPackages.ghcMod 
> '')
>
> 
> /nix/store/0b7bmyslyidn7iq7bcmxzgxqa0wcd786-haskell-ghc-mod-ghc7.8.3-5.1.1.0-shared.drv
> +---/nix/store/gzgrizf2xw537hnnbycbnpbxzrwddxjw-emacs-24.4.drv
> |   +---/nix/store/lp9z54f5snvrdnvlih815m28lxb5080l-librsvg-2.36.4.drv
> |   |   +---/nix/store/l89khlm6piiilivpnx618w13cfqqj223-cairo-1.12.16.drv
> |   |   |   
> +---/nix/store/ib90dbdwvijmv44v7ij7ghs1md5nfrf2-mesa-noglu-10.2.6.drv
> |   |   |   |   
> +---/nix/store/gl09hmxv11fvsz2dkr6s6i5xsbvp2c55-wayland-1.6.0.drv
>
>
> As it turns out this comes from Emacs and the problem is fixed with a simple 
> package override:
>
> { pkgs }: {
>   packageOverrides = self: with pkgs; {
> emacs = self.emacs.override { withX = false; withGTK = false; };
>   }
> }
>
>
> However, I'm wondering if this really is the intended default behavior for 
> that package. Wouldn't it be better to have ghc-mod depend on a nox-emacs by 
> default?
>
> 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


[Nix-dev] ghc-mod depends on Wayland

2014-11-03 Thread Andreas Herrmann
Hello everyone,

Recently, I tried to install the ghc-mod package. I was surprised to see that 
nix-env intended to install a _large_ amount of dependencies down to quite 
unexpected ones such as Wayland.

I dug into the dependency tree:

nix-store -qR --tree $(nix-instantiate -A haskellPackages.ghcMod 
'')


/nix/store/0b7bmyslyidn7iq7bcmxzgxqa0wcd786-haskell-ghc-mod-ghc7.8.3-5.1.1.0-shared.drv
+---/nix/store/gzgrizf2xw537hnnbycbnpbxzrwddxjw-emacs-24.4.drv
|   +---/nix/store/lp9z54f5snvrdnvlih815m28lxb5080l-librsvg-2.36.4.drv
|   |   +---/nix/store/l89khlm6piiilivpnx618w13cfqqj223-cairo-1.12.16.drv
|   |   |   
+---/nix/store/ib90dbdwvijmv44v7ij7ghs1md5nfrf2-mesa-noglu-10.2.6.drv
|   |   |   |   
+---/nix/store/gl09hmxv11fvsz2dkr6s6i5xsbvp2c55-wayland-1.6.0.drv


As it turns out this comes from Emacs and the problem is fixed with a simple 
package override:

{ pkgs }: {
  packageOverrides = self: with pkgs; {
emacs = self.emacs.override { withX = false; withGTK = false; };
  }
}


However, I'm wondering if this really is the intended default behavior for that 
package. Wouldn't it be better to have ghc-mod depend on a nox-emacs by default?

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