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

2015-04-02 Thread Ertugrul Söylemez
> > The last time I tried to switch, Nix started to build everything
> > from source, including GHC, even with the options described in the
> > Haskell NG thread.
>
> what architecture do you use? Is it i686-linux by any chance? I'm
> asking because Hydra isn't building binaries for that platform at the
> moment.
>
> You should always get binaries of GHC itself, though. Those are part
> of the standard "nixos-unstable" channel.

It's x86_64 using the unstable channel.  Since it has been a while I
will just retry with the original instructions and see what happens.
I'll report my result here.

Thanks!


Greets,
Ertugrul


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


Re: [Nix-dev] What's wrong with "staging"?

2015-04-02 Thread Peter Simons
Hi Domen,

 > Maybe. How much though?

right now, nixos:trunk-combined uses 2.24% of the available shares. If
we'd like to dedicate 10% instead, then we'd have to assign 7284 shares.
This should give the job a huge boost, while still leaving a lot of
bandwidth for the rest.

Best regards,
Peter

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


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

2015-04-02 Thread member MP2E
Speaking as someone that has been bitten by the non-deterministic package
IDs many times, I'm fully in favor of switching over to GHC 7.10.1 and
removing the old infrastructure. If there's anything I can do to help the
transition, let me know

On Thu, Apr 2, 2015 at 4:51 PM, Peter Simons  wrote:

> Hi Ertugrul,
>
>  > The last time I tried to switch, Nix started to build everything from
>  > source, including GHC, even with the options described in the Haskell
>  > NG thread.
>
> what architecture do you use? Is it i686-linux by any chance? I'm asking
> because Hydra isn't building binaries for that platform at the moment.
>
> You should always get binaries of GHC itself, though. Those are part of
> the standard "nixos-unstable" channel.
>
> 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] Use GHC 7.10.1 as default Haskell compiler in nixpkgs

2015-04-02 Thread Peter Simons
Hi Ertugrul,

 > The last time I tried to switch, Nix started to build everything from
 > source, including GHC, even with the options described in the Haskell
 > NG thread.

what architecture do you use? Is it i686-linux by any chance? I'm asking
because Hydra isn't building binaries for that platform at the moment.

You should always get binaries of GHC itself, though. Those are part of
the standard "nixos-unstable" channel.

Best regards,
Peter

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


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

2015-04-02 Thread Ertugrul Söylemez
> If you haven't migrated to Haskell NG yet ... now would be a good time
> to do it. (I'm looking at you, Agda.)

I'm currently forced to work on a rather weak machine, so building from
source is prohibitively expensive.

Is there a very short summary of how to do it and still get binary
packages?  The last time I tried to switch, Nix started to build
everything from source, including GHC, even with the options described
in the Haskell NG thread.


Greets,
Ertugrul


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


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

2015-04-02 Thread Peter Simons
Hi guys,

I believe that we should switch our default compiler to GHC 7.10.1
within the next three or four weeks -- assuming that no major bug is
discovered in that compiler. It is true that this update will break some
packages, but GHC versions prior to 7.10.x are a disaster for
distributions like us because they generate non-deterministic library
IDs. This means that two builds running in identical environments can
produce outputs that differ and that break binary compatibility when
linked by other libraries. This is a nightmare for systems like Hydra,
and I've just had to rebuild all our Haskell packages [1] for the
umpteenth time because of that bug. GHC 7.10.1 is supposed to fix that
issue, so I'd say let's go for it.

Those of you who don't want to update can stick to GHC 7.8.4, of course,
it's just that Hydra will no longer provide binaries for that version
after the switch.

Also, I'd like to remove all code related to the old Haskell package set
from Nixpkgs shortly after the switch, to make sure that obsolete code
won't make it into the next release branch. If you haven't migrated to
Haskell NG yet ... now would be a good time to do it. (I'm looking at
you, Agda.)

How do you guys feels about that approach? Any concerns? Other
suggestions?

Best regards,
Peter


[1] 
https://github.com/NixOS/nixpkgs/commit/945269a48fa8b91024e18a72b485797eeca308ee

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


Re: [Nix-dev] About gettext and expat

2015-04-02 Thread Daniel Peebles
Could we just have a couple of derivations? One gettext that depends on expat 
that gtk can use, and one minimal one for the common case?



> On Apr 2, 2015, at 12:27, Luca Bruno  wrote:
> 
> Gettext is currently depending only on libc. Gettext is an input to gcc,
> so that's a very important dependency. However gtk 3.16 now requires
> gettext to process xml files like glade files, and that requires xml
> support via expat.
> Gettext is currently compiled so that it finds expat with dlopen, but
> you know that means putting evil LD_LIBRARY_PATH I'd like to avoid.
> 
> Anybody knows any drawbacks about making gettext depend on expat? If
> not, I'm going to do the change for gettext 0.19 in the staging branch
> during the next days.
> 
> Best regards,
> ___
> 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] What's wrong with "staging"?

2015-04-02 Thread Domen Kožar
Maybe. How much though?

On Thu, Apr 2, 2015 at 9:36 PM, Peter Simons  wrote:

> Hi Domen,
>
>  > I'm cancelling staging until nixos-combined catches up and updates the
>  > channel. We have too many other jobset going in the way that have way
>  > lower priority (we had up to 100k builds scheduled few days ago..)
>
> maybe we should increase the number of shares allotted to nixos-combined?
>
> 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] What's wrong with "staging"?

2015-04-02 Thread Peter Simons
Hi Domen,

 > I'm cancelling staging until nixos-combined catches up and updates the
 > channel. We have too many other jobset going in the way that have way
 > lower priority (we had up to 100k builds scheduled few days ago..)

maybe we should increase the number of shares allotted to nixos-combined?

Best regards,
Peter

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


Re: [Nix-dev] What's wrong with "staging"?

2015-04-02 Thread Domen Kožar
I'm cancelling staging until nixos-combined catches up and updates the
channel. We have too many other jobset going in the way that have way lower
priority (we had up to 100k builds scheduled few days ago..)

Once nixos-combined updates the channel, I'll restart staging (hopefully
today?)

Domen

On Thu, Apr 2, 2015 at 8:56 PM, Peter Simons  wrote:

> http://hydra.nixos.org/jobset/nixpkgs/staging shows 25,000 aborted build
> jobs. Is that state intentional in any way? Or can I (or someone else)
> restart those builds?
>
> 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] Let's switch the default shell in Nixpks / NixOS to csh

2015-04-02 Thread Lukas Epple
Hello,

I think we should replace the shell and systemd by emacs or a common lisp 
implementation.

Kind regards,

Lukas



> Am 02.04.2015 um 00:26 schrieb Peter Simons :
> 
> Hi guys,
> 
> the default builder in Nixpkgs (and pretty much all other shell code in all 
> our
> packages) assumes that it's interpreted by "bash". Now, we've had a lot of
> trouble with "bash" recently:
> 
> - crazy security vulnerabilities;
> 
> - auto completion is slow, gives unexpected results, or doesn't work at all;
> 
> - /bin/sh is not "bash" on many non-NixOS host systems; and
> 
> - many of other problems.
> 
> This makes me wonder whether maybe we should switch all shell scripting in
> Nixpkgs to "csh"? Wouldn't that solve a lot of problems? I've heard experts 
> say
> that "csh" is generally considered superior for scripting tasks because of its
> more intuitive syntax.
> 
> Now, the only minor obstacle is to transition the existing package base from
> "bash" to "csh". That wouldn't be difficult to accomplish, though. There's
> probably a bash2csh converter available somewhere that we could use.
> 
> Of course, for consistency's sake we'd have to make "csh" the only supported
> user shell for accounts on NixOS machines too. We don't want our users messing
> with other shells. All that diversity will just make our lives harder as
> developers. These people will drive us crazy with bug reports on Github,
> complaining about how they freaky "bash" environment no longer works with
> "nix-shell" etc., and that's just going to be a maintenance nightmare. It's
> probably better to decide once and for all that Nix supports only "csh" and
> move on to other, more important things.
> 
> Anyway, let me know that you think. Shall I prepare a pull request?
> 
> 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] What's wrong with "staging"?

2015-04-02 Thread Peter Simons
http://hydra.nixos.org/jobset/nixpkgs/staging shows 25,000 aborted build
jobs. Is that state intentional in any way? Or can I (or someone else)
restart those builds?

Peter

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


[Nix-dev] What am I doing wrong with ssh-substitutor-hosts?

2015-04-02 Thread Jeffrey David Johnson
I've got two computers with nixos, and I can ssh between them without a
password.  But if I do a nixos-rebuild with `--option ssh-substitutor-hosts
` they still just download everything from cache.nixos.org.  I think
I have the sshServe set up in my configuration.nix:

# nixServeKeys are loaded from another file keys.nix,
# and are all the same ones used for regular ssh access
nix.sshServe = { enable = true; keys = nixServeKeys; };

Is there a setting I'm missing somewhere?
Jeff
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


[Nix-dev] About gettext and expat

2015-04-02 Thread Luca Bruno
Gettext is currently depending only on libc. Gettext is an input to gcc,
so that's a very important dependency. However gtk 3.16 now requires
gettext to process xml files like glade files, and that requires xml
support via expat.
Gettext is currently compiled so that it finds expat with dlopen, but
you know that means putting evil LD_LIBRARY_PATH I'd like to avoid.

Anybody knows any drawbacks about making gettext depend on expat? If
not, I'm going to do the change for gettext 0.19 in the staging branch
during the next days.

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