Re: [Nix-dev] Terminus console font

[Dmitry Malikov]

And what is the value of ${pkg} variable there?
On 09/09/2014 05:58 AM, 宋文武 wrote:
> "M. P. Ashton"  writes:
>
>> On Sun, Sep 7, 2014, at 02:20 PM, Dmitry Malikov wrote:
>>> Good day.
>>>
>>> I'm not a huge fan of X server, that why I'm spending my time inside a
>>> tty and virtual terminals. Default fonts that NixOS offers are not
>>> perfectly suite my eyes that why I'm looking for a way to use terminus
>>> font there.
>>>
>>> I.e. in Gentoo OS there is a `consoleFont` variable which could be set
>>> to "ter-116n" value to get terminus in Xless console. I'm trying to do
>>> the same via setting `i18n.consoleFont = "ter-116n"`([1]) , but it do
>>> nothing.
>>>
>>> Also as you see `pkgs.terminus_font` is added to the `fonts.fonts`
>>> statement, that why I'm assuming terminus font is installed in my system.
>>>
>>> have you guys achieved it? What am I doing wrong?
>> What works for me is the line:
>>
>> i18n.consoleFont = "Lat2-Terminus16";
>>
> Something like this works for me:
>
> i18n.consoleFont = "${pkg.terminus}/share/consolefonts/ter-i16n.pcf.gz";
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev

-- 
Best regards,
dmitry malikov
!

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

Re: [Nix-dev] Terminus console font

[宋文武]

"M. P. Ashton"  writes:

> On Sun, Sep 7, 2014, at 02:20 PM, Dmitry Malikov wrote:
>> Good day.
>> 
>> I'm not a huge fan of X server, that why I'm spending my time inside a 
>> tty and virtual terminals. Default fonts that NixOS offers are not 
>> perfectly suite my eyes that why I'm looking for a way to use terminus 
>> font there.
>> 
>> I.e. in Gentoo OS there is a `consoleFont` variable which could be set 
>> to "ter-116n" value to get terminus in Xless console. I'm trying to do 
>> the same via setting `i18n.consoleFont = "ter-116n"`([1]) , but it do 
>> nothing.
>> 
>> Also as you see `pkgs.terminus_font` is added to the `fonts.fonts` 
>> statement, that why I'm assuming terminus font is installed in my system.
>> 
>> have you guys achieved it? What am I doing wrong?
>
> What works for me is the line:
>
> i18n.consoleFont = "Lat2-Terminus16";
>

Something like this works for me:

i18n.consoleFont = "${pkg.terminus}/share/consolefonts/ter-i16n.pcf.gz";

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

Re: [Nix-dev] Developing with older packages

[Luca Bruno]

Haven't found a cool slogan for nixos yet :P

On Mon, Sep 8, 2014 at 11:23 PM, Vladimír Čunát  wrote:

> On 09/08/2014 10:27 PM, Luca Bruno wrote:
>
>> www.debian.org  - The Universal Operating System
>>
>
> You should update your footer ;-)
>
>
>
> ___
> 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

Re: [Nix-dev] Developing with older packages

[Vladimír Čunát]

On 09/08/2014 10:27 PM, Luca Bruno wrote:

www.debian.org  - The Universal Operating System


You should update your footer ;-)




smime.p7s
Description: S/MIME Cryptographic Signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Developing with older packages

[Luca Bruno]

What about just copying the old .nix from old nixpkgs commits?

On Mon, Sep 8, 2014 at 8:08 PM, Richard Wallace  wrote:

> On Mon, Sep 8, 2014 at 9:03 AM, Mateusz Kowalczyk  > wrote:
>
>> On 09/08/2014 04:56 PM, Richard Wallace wrote:
>> > Hello,
>> >
>> > I'm using nix-shell to setup a Haskell environment for development.  On
>> a
>> > project I ran into a problem recently, and I'm curious if there is a
>> > common/preferred way of solving it.
>> >
>> > The problem I ran into is that the project depends on the mongoDB 1.5
>> > package.  The API changed drastically in 2.0 and we're not ready to
>> > undertake the upgrade yet.  I think I can handle this by creating a
>> nixpkgs
>> > directory in the project, putting a mongoDB/default.nix file in there
>> that
>> > is setup for the version we need, then override it in our shell.nix file
>> > like this:
>> >
>> > let
>> >
>> >pkgs = import  {};
>> >
>> >haskellPackages = pkgs.haskellPackages.override {
>> >
>> >  extension = self: super: {
>> >mongoDB = self.callPackage nixpkgs/mongoDB {};
>> >ourkidsclass = self.callPackage ./. {};
>> >
>> >  };
>> >
>> >};
>> >
>> > Is this a reasonable approach? Is there a better way?
>> >
>> > Thanks,
>> > Rich
>> >
>> >
>> >
>> > ___
>> > nix-dev mailing list
>> > nix-dev@lists.science.uu.nl
>> > http://lists.science.uu.nl/mailman/listinfo/nix-dev
>> >
>>
>> This looks as good of a solution as any other one could come up with. Is
>> there something you're dissatisfied with that you would like to have in
>> a ‘better’ solution?
>>
>>
> Well, the mongoDB package isn't the only one that I want to get a specific
> version of.  We originally built it with a sandbox and used `cabal freeze`
> to make sure everyone is using the same versions.  So there are a number of
> such packages and I was hoping for something a bit more automated.  Perhaps
> I can script something to make it a bit easier to maintain.
>
> Rich
>
>
>
>> --
>> 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
>
>


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

Re: [Nix-dev] Developing with older packages

[Vladimír Čunát]

On 09/08/2014 08:08 PM, Richard Wallace wrote:

Well, the mongoDB package isn't the only one that I want to get a
specific version of.  We originally built it with a sandbox and used
`cabal freeze` to make sure everyone is using the same versions.  So
there are a number of such packages and I was hoping for something a bit
more automated.  Perhaps I can script something to make it a bit easier
to maintain.


(CC @peti, as the thread concerns versioning of haskell packages in 
nixpkgs.)


You can use cabal2nix to generate the .nix file for a specific package 
version.



Vladimir




smime.p7s
Description: S/MIME Cryptographic Signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Developing with older packages

[Vladimír Čunát]

On 09/08/2014 08:12 PM, Richard Wallace wrote:

One thing that surprised me about nix when I started using it is that
there isn't a way to say, "I need package X with version Y".  Instead,
you have to resort to having multiple definitions of the package with
different package names for different versions.  This seems a bit hacky
to me.


When you change version, you have to change the download hash, and often 
also some other things like dependencies or patches. As many things may 
be different, having a special attribute name is a flexible convention.


In nixpkgs we do not maintain old versions unless there is a good reason 
to do so. For those cases, the language offers many ways of sharing code 
among multiple versions, although some of those techniques were disputed 
a lot and disapproved.



Vladimir




smime.p7s
Description: S/MIME Cryptographic Signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Developing with older packages

[Richard Wallace]

On Mon, Sep 8, 2014 at 9:04 AM, Vladimír Čunát  wrote:

> Hi.
>
> On 09/08/2014 05:56 PM, Richard Wallace wrote:
>
>> The API changed drastically in 2.0 and we're not ready to undertake the
>> upgrade yet.
>>
>
> That sounds like it makes sense to keep mongoDB_1_5 in nixpkgs, at least
> for some time. More people may experience the same issue. (It seems
> simplified by the fact that I see no package that depends on mongoDB.)
>
>
One thing that surprised me about nix when I started using it is that there
isn't a way to say, "I need package X with version Y".  Instead, you have
to resort to having multiple definitions of the package with different
package names for different versions.  This seems a bit hacky to me.  As
mentioned in a separate reply, I expect to have several such packages and
being able to specify it that way would make things much easier.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Developing with older packages

[Richard Wallace]

On Mon, Sep 8, 2014 at 9:03 AM, Mateusz Kowalczyk 
wrote:

> On 09/08/2014 04:56 PM, Richard Wallace wrote:
> > Hello,
> >
> > I'm using nix-shell to setup a Haskell environment for development.  On a
> > project I ran into a problem recently, and I'm curious if there is a
> > common/preferred way of solving it.
> >
> > The problem I ran into is that the project depends on the mongoDB 1.5
> > package.  The API changed drastically in 2.0 and we're not ready to
> > undertake the upgrade yet.  I think I can handle this by creating a
> nixpkgs
> > directory in the project, putting a mongoDB/default.nix file in there
> that
> > is setup for the version we need, then override it in our shell.nix file
> > like this:
> >
> > let
> >
> >pkgs = import  {};
> >
> >haskellPackages = pkgs.haskellPackages.override {
> >
> >  extension = self: super: {
> >mongoDB = self.callPackage nixpkgs/mongoDB {};
> >ourkidsclass = self.callPackage ./. {};
> >
> >  };
> >
> >};
> >
> > Is this a reasonable approach? Is there a better way?
> >
> > Thanks,
> > Rich
> >
> >
> >
> > ___
> > nix-dev mailing list
> > nix-dev@lists.science.uu.nl
> > http://lists.science.uu.nl/mailman/listinfo/nix-dev
> >
>
> This looks as good of a solution as any other one could come up with. Is
> there something you're dissatisfied with that you would like to have in
> a ‘better’ solution?
>
>
Well, the mongoDB package isn't the only one that I want to get a specific
version of.  We originally built it with a sandbox and used `cabal freeze`
to make sure everyone is using the same versions.  So there are a number of
such packages and I was hoping for something a bit more automated.  Perhaps
I can script something to make it a bit easier to maintain.

Rich



> --
> 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] PAGER="less -R"

[Marc Weber]

Fed upstream: https://github.com/greenrd/topgit/issues/36
Thanks for tv @ irc for helping.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Default to GNOME 3.12

[Luca Bruno]

* GNOME 3.10 life *

In the staging branch I've changed gnome3 to be 3.12 by default,
including the nixos test. I haven't tested the change locally except for
a few packages.
GNOME 3.10 is still sticking around as gnome3_10.
In case any program fails to build or run, we can fallback to gnome3_10
for that package.
Once everything seems ok we can merge into master and update the release
notes.

We'll drop GNOME 3.10 once all programs are ported to GNOME 3.12.

* GNOME 3.14 *

GNOME 3.14.0 is scheduled for release[1] in Sep 22-24, while 3.14.1 in
Oct 13-15. Hope my connection will grant me to download something in
this period, hope to have a better connection in October.
In any case I will try packaging all gnome 3.14.0 again. In general
there shouldn't be any problem, except for gdm which is tricky and full
of patches.

For having GNOME 3.14 in nixos stable, it depends on the timing between
GNOME  3.14 release and the new nixos stable release. Also depends on
how much we're able to test GNOME 3.14 by the time.

* Telepathy framework *

The telepathy team as usual kindly notify[2] packagers about the best
versions to be used with GNOME. If something does not work in this
regard, we can try packaging those exact versions in gnome3_14.

Also, since in nixos we have an option to remove packages that are
installed by default[3] in GNOME, in order to improve the user
experience I'm thinking of installing telepathy-gabble (for XMPP
protocols) by default when enabling GNOME.

Best regards,

[1] https://wiki.gnome.org/ThreePointThirteen
[2]
https://mail.gnome.org/archives/distributor-list/2014-August/msg2.html
[3] http://nixos.org/nixos/manual/#opt-environment.gnome3.excludePackages
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Developing with older packages

[Vladimír Čunát]

Hi.

On 09/08/2014 05:56 PM, Richard Wallace wrote:

The API changed drastically in 2.0 and we're not ready to undertake the
upgrade yet.


That sounds like it makes sense to keep mongoDB_1_5 in nixpkgs, at least 
for some time. More people may experience the same issue. (It seems 
simplified by the fact that I see no package that depends on mongoDB.)


Vladimir




smime.p7s
Description: S/MIME Cryptographic Signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Developing with older packages

[Mateusz Kowalczyk]

On 09/08/2014 04:56 PM, Richard Wallace wrote:
> Hello,
> 
> I'm using nix-shell to setup a Haskell environment for development.  On a
> project I ran into a problem recently, and I'm curious if there is a
> common/preferred way of solving it.
> 
> The problem I ran into is that the project depends on the mongoDB 1.5
> package.  The API changed drastically in 2.0 and we're not ready to
> undertake the upgrade yet.  I think I can handle this by creating a nixpkgs
> directory in the project, putting a mongoDB/default.nix file in there that
> is setup for the version we need, then override it in our shell.nix file
> like this:
> 
> let
> 
>pkgs = import  {};
> 
>haskellPackages = pkgs.haskellPackages.override {
> 
>  extension = self: super: {
>mongoDB = self.callPackage nixpkgs/mongoDB {};
>ourkidsclass = self.callPackage ./. {};
> 
>  };
> 
>};
> 
> Is this a reasonable approach? Is there a better way?
> 
> Thanks,
> Rich
> 
> 
> 
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
> 

This looks as good of a solution as any other one could come up with. Is
there something you're dissatisfied with that you would like to have in
a ‘better’ solution?

-- 
Mateusz K.
___
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?

[Ross Gardler (MS OPEN TECH)]

I'm not sure if you mean the initial connection for the end user (i.e. someone 
deploying from your image) or for your preparation of the image. 

If you mean the end user then the user provides either an SSH key or a password 
when the deploy the image. This is handled by either the Azure portal or the 
cross platform CLI we provide.

If you mean for the preparation then you use the credentials you set up in 
preparing the image and then deprovision the image, which removes all keys 
(amongst other things) and provides the hooks for the Azure portal/CLI to add 
in a new set of keys.

Both processes are documented in 
http://msopentech.com/blog/2014/05/14/deploy-customize-freebsd-virtual-machine-image-microsoft-azure/
 (which is about FreeBSD but the process is the same for Linux).

Ross

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)

-Original Message-
From: Shea Levy [mailto:s...@shealevy.com] 
Sent: Friday, September 5, 2014 8:46 PM
To: Ross Gardler (MS OPEN TECH)
Cc: nix-dev@lists.science.uu.nl
Subject: Re: [Nix-dev] NixOS on Azure?

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-machin
> es-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. 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
> >  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.microso

[Nix-dev] Developing with older packages

[Richard Wallace]

Hello,

I'm using nix-shell to setup a Haskell environment for development.  On a
project I ran into a problem recently, and I'm curious if there is a
common/preferred way of solving it.

The problem I ran into is that the project depends on the mongoDB 1.5
package.  The API changed drastically in 2.0 and we're not ready to
undertake the upgrade yet.  I think I can handle this by creating a nixpkgs
directory in the project, putting a mongoDB/default.nix file in there that
is setup for the version we need, then override it in our shell.nix file
like this:

let

   pkgs = import  {};

   haskellPackages = pkgs.haskellPackages.override {

 extension = self: super: {
   mongoDB = self.callPackage nixpkgs/mongoDB {};
   ourkidsclass = self.callPackage ./. {};

 };

   };

Is this a reasonable approach? Is there a better way?

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

Re: [Nix-dev] PAGER="less -R"

[Vladimír Čunát]

On 09/08/2014 11:56 AM, Marc Weber wrote:

topgit has an issue with that:


What issue do you mean. Either I don't get you or I can't reproduce it.

Vladimir




smime.p7s
Description: S/MIME Cryptographic Signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] haskell: overriding mtl/any builtin

[Mateusz Kowalczyk]

On 09/08/2014 07:36 AM, Peter Simons wrote:
> Hi Mateusz,
> 
>  > Notably if I specify mtl = mtl_2_2_1; then it complains that it needs
>  > transformers == 0.4 but there seems to be no clues in nixpkgs as to how
>  > to achieve this. Currently mtl = 2.2.1 for HEAD but I know it should
>  > work with 7.8.3
> 
> transformers is a core library in GHC 7.8.3. We cannot override that
> package, because it's shipped with the compiler and other core libraries
> are linked against that version.
> 
> Best regards,
> Peter
> 
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
> 

Right, yes, it is, yet somehow there are packages around on Hackage
which do depend on mtl-2.2.1 and by proxy on transformers-0.4, which do
compile with GHC 7.8.3. This must be somehow achieved one way or another
and currently with nix(pkgs) we can not accommodate for those packages.
Recent release of JuicyPixels is a good example, we had to ask upstream
to relax the bound a bit so that we could use it but just relaxing the
bound is not always possible. I expect more and more packages to start
using the new mtl over time.

I found myself yesterday in need of hacking a bit on a project which
happened to actually need mtl-2.2.1 and I just could not do it with
7.8.3 whereas that's exactly what the original developer was using. My
hack there was to comment out the 2.2.1 imports and manually stick
undefined everywhere but that's obviously not acceptable for any actual
work.

The only other way I could think of would be to use the (outdated) GHC
‘HEAD’ version from nixpkgs which would not help me because it was to
try and chase down a bug appearing with 7.8.3.

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

Re: [Nix-dev] GHC pointed at the wrong package

[Mateusz Kowalczyk]

On 09/07/2014 10:10 PM, Rickard Nilsson wrote:
> On 08/23/2014 03:15 PM, Mateusz Kowalczyk wrote:
>> On 08/23/2014 01:29 PM, Peter Simons wrote:
>>> Hi Mateusz,
>>>
>>>   > There are problems in package regex-tdfa-1.2.0:
>>>   >   dependency "parsec-3.1.5-ca5ed8f175b69e1a085cfeaf3b95f424" doesn't 
>>> exist
>>>   > There are problems in package regex-tdfa-rc-1.1.8.3:
>>>   >   dependency "parsec-3.1.5-ca5ed8f175b69e1a085cfeaf3b95f424" doesn't 
>>> exist
>>>
>>> the process that generates those IDs in GHC is non-deterministic. Two
>>> people can compile the same library with the same version of GHC on the
>>> same type of machine yet end up with two distinct IDs. It doesn't happen
>>> often, but it does happen.
>>>
>>> I'd recommend running
>>>
>>>   $ nix-store --delete /nix/store/*-haskell-parsec-ghc7.8.3-3.1.5-shared
>>>
>>> on all your machines. Then the next build will download these packages
>>> from Hydra, and you'll have a consistent build again. Note that you may
>>> have to remove packages from your active profiles to make that deletion
>>> process succeed.
>>>
>>> I hope this helps,
>>> Peter
>>>
>>
>> It's very unfortunate to hear about the package ID stuff. Is there a bug
>> open?
> 
> There is https://ghc.haskell.org/trac/ghc/ticket/4012

There has actually been a patch to that bug about a day before I asked
so the situation for the simple case may improve.

> Actually, since we started building Haskell packages in parallel 
> (https://github.com/NixOS/nixpkgs/commit/817c0e41443a5176baf6dd9b422878fdccecd266),
>  
> this problem might have got more common (but I have no real evidence for 
> that).
> 
> You can reproduce this by building the haskell http-client package with 
> "--cores 4" (non-parallel makes the problem go away). Each build (with 
> the exact same dependencies, and hence exact same nix hash) produces a 
> package with different package-id (in package-conf.d). It is not only 
> the package-id that differs, but the ABI differs, which could make 
> linking fail. Look at this:
> 
> $ nm -g 
> pkg-1/lib/ghc-7.8.3/http-client-0.3.8.1/libHShttp-client-0.3.8.1.a > hc-1-nm
> 
> $ nm -g 
> pkg-2/lib/ghc-7.8.3/http-client-0.3.8.1/libHShttp-client-0.3.8.1.a > hc-2-nm
> 
> $ diff hc-1-nm hc-2-nm | tail -n 10
> 8775,8776c8775,8776
> <  U 
> httpzmclientzm0zi3zi8zi1_NetworkziHTTPziClientziTypes_zdLrfy8a_closure
> <  D 
> httpzmclientzm0zi3zi8zi1_NetworkziHTTPziClientziTypes_zdLrfy9a1_closure
> ---
>  >  U 
> httpzmclientzm0zi3zi8zi1_NetworkziHTTPziClientziTypes_zdLrfxPa_closure
>  >  D 
> httpzmclientzm0zi3zi8zi1_NetworkziHTTPziClientziTypes_zdLrfxQa1_closure
> 8780c8780
> <  D 
> httpzmclientzm0zi3zi8zi1_NetworkziHTTPziClientziTypes_zdLrfy8a_closure
> ---
>  >  D 
> httpzmclientzm0zi3zi8zi1_NetworkziHTTPziClientziTypes_zdLrfxPa_closure

As pointed out on the Trac ticket, non-determinism in presence of
parallelism is a known problem, so there's your evidence.

> I really don't know how this could be worked around in Nix. Of course, 
> the problem is not very common, since you would have to build one 
> package locally, then fetch a package built somewhere else that depends 
> on your local package, and finally build a third package that depends on 
> that fetched package. But in a build cluster things like that certainly 
> do happen.

I think making Haskell packages only build on a single core again would
be a start.

For me that problem is common: my Hydra builds Haskell packages from
nixpkgs HEAD and uses official Hydra and peti's Hydra as binary caches.
Further, my own-use computer uses official Hydra, my Hydra and peti's
Hydra as caches + I often build packages locally when packaging stuff
for nixpkgs master or when I need some patches from there. It's fairly
easy to see that it's easy for the problem to come up here. In fact my
Hydra right now suffers from the same thing and weirdly it's actually,
again, something to do with pandoc/parsec packages.

Right from my Hydra:

package pandoc-1.13.1 is broken due to missing package
pandoc-types-1.12.4.1-917a8ba6e10664f3ab958ef027071e98

My options when this happens is to either:

1. manually drop in and try to remove broken packages

2. garbage collect everything

3. wait for a big rebuild which will cause these to be rebuild/refetched

Today 3. is actually happening so hopefully it comes out without any
bogus errors but ideally this should never happen. If building each
package on single core makes it more likely to produce non-broken
packages then I think it should be the default until it can be patched
upstream.

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


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

[Nix-dev] Fwd: GHC pointed at the wrong package

[Benno Fünfstück]

Seems I forgot to send this email to the list ...
--
Benno

-- Forwarded message --
From: Benno Fünfstück 
Date: 2014-08-24 20:00 GMT+02:00
Subject: Re: [Nix-dev] GHC pointed at the wrong package
To: Mateusz Kowalczyk 


Yes, GHC bug #4012 [https://ghc.haskell.org/trac/ghc/ticket/4012] is about
this issue.

You can use `nix-store --repair-path ` to re-download a
specific store path from hydra.

--
Benno


2014-08-23 15:15 GMT+02:00 Mateusz Kowalczyk :

> On 08/23/2014 01:29 PM, Peter Simons wrote:
> > Hi Mateusz,
> >
> >  > There are problems in package regex-tdfa-1.2.0:
> >  >   dependency "parsec-3.1.5-ca5ed8f175b69e1a085cfeaf3b95f424" doesn't
> exist
> >  > There are problems in package regex-tdfa-rc-1.1.8.3:
> >  >   dependency "parsec-3.1.5-ca5ed8f175b69e1a085cfeaf3b95f424" doesn't
> exist
> >
> > the process that generates those IDs in GHC is non-deterministic. Two
> > people can compile the same library with the same version of GHC on the
> > same type of machine yet end up with two distinct IDs. It doesn't happen
> > often, but it does happen.
> >
> > I'd recommend running
> >
> >  $ nix-store --delete /nix/store/*-haskell-parsec-ghc7.8.3-3.1.5-shared
> >
> > on all your machines. Then the next build will download these packages
> > from Hydra, and you'll have a consistent build again. Note that you may
> > have to remove packages from your active profiles to make that deletion
> > process succeed.
> >
> > I hope this helps,
> > Peter
> >
>
> It's very unfortunate to hear about the package ID stuff. Is there a bug
> open?
>
> I managed to resolve the issue by getting rid of my parsec package as
> you advised. Unluckily it was depended on all the way from
> xmonad-extras. In the end I was able to remove -extras from my system as
> my config only needs -contrib, reboot, garbage collect and it works. I
> fear if this ever hits something xmonad directly depends on because I'll
> have to get rid of my WM to fix the issue…
>
> Perhaps a --force-overwrite flag should be created in nix-store as long
> as two hashes match?
>
> Thanks for help!
>
> --
> 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] automatically mount vboxsf

[Andreas Herrmann]

Dear Luca,

On Monday 08 September 2014 10:57:31 Luca Bruno wrote:
>>   system.fsPackages = [
>> config.boot.kernelPackages.virtualboxGuestAdditions
>>   ];
> I suggest you to use services.virtualbox.enable = true.
Doesn't nixops set this by default when the deployment is "virtualbox"?
At least, I haven't manually set this service to enabled before, but the guest 
additions were installed anyway. For instance, I was able to manually mount the 
vboxsf volume once the machine had booted.

I had the feeling, that the package just wasn't there, yet when the system 
tried to automatically mount the vboxsf volume at boot-time. So, adding it to 
fsPackages should somehow make sure that the package is available at boot-time. 
Or am I wrong here?

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

[Nix-dev] PAGER="less -R"

[Marc Weber]

topgit has an issue with that:
https://github.com/greenrd/topgit/blob/master/tg.sh#L462

TG_PAGER gets defined some lines above ${FOO-xxx) means but word if FOO
isn't defined (thanks to Lethalman, I failed finding that in the man
page.

Is the best way to fix this by dropping quotes? Does anybody know how
PAGER ist most commonly used?

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

Re: [Nix-dev] DevOps sprint at gocept/FlyingCircus

[Rok Garbas]

i think i'll be only able to come for fri/sat maybe i can come for later on
thu but not 100%.


--
Rok Garbas - http://www.garbas.si
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] automatically mount vboxsf

[Luca Bruno]

> Additionally, I had to add the vbox guest additions into the scope:
>
>   system.fsPackages = [
> config.boot.kernelPackages.virtualboxGuestAdditions
>   ];
I suggest you to use services.virtualbox.enable = true.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] automatically mount vboxsf

[Andreas Herrmann]

Hi Nicolas,

On Saturday 06 September 2014 20:25:43 Nicolas Pierron wrote:
> Have you tried listing it as an entry of the fileSystem of the vm, such as:
> 
> fileSystems."/host_home" = {
>   fsType = "vboxsf";
>   device = "hostHome";
> };
Thanks for the hint. I got it working with the following config:

  fileSystems."/host_home" = {
fsType = "vboxsf";
device = "hostHome";
options = "ro";  # If you want it read-only
noCheck = true;  # fsck would be pointless.
  };

Additionally, I had to add the vbox guest additions into the scope:

  system.fsPackages = [
config.boot.kernelPackages.virtualboxGuestAdditions
  ];

Best,

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

[Nix-dev] NixOS on MacBook: how to enable sudden motion sensor?

[Alexey Muranov]

Hello,

could you tell me please how to make sure in NixOS on a MacBook that the sudden 
motion sensor and the relevant disk protection are enabled?

It seems that i need applesmc module for this, but i couldn't find how to 
install it in NixOS.

Thanks,

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