[Nix-dev] nix-build -A builds everything

[Dieter Vekeman]

Hi

I’m trying to create a nix package (for the odoo suite 
https://github.com/odoo/odoo/tree/8.0).

I checked out nixpkgs
created a folder in pkgs/applications/networking/odoo

This is what I have so far
# cat ./pkgs/applications/networking/odoo/default.nix
{ stdenv, fetchurl, buildPythonPackage, pythonPackages }:

buildPythonPackage {
  name = "odoo-8.0.0";
  namePrefix = "";

  src = fetchurl {
url = "https://github.com/odoo/odoo/archive/8.0.0.zip;;
sha256 = "dee5ca67cd314c389fe3fb924c1fc6ba84a913b60956bd0308344e9c0e0cb751";
  };

  propagatedBuildInputs = [ ];

  # Testing fails.
  doCheck = false;

  meta = {
description = "Odoo ERP / CRM business suite";
homepage = https://www.odoo.com;
license = stdenv.lib.licenses.agpl3;
  };
}

When I run
nix-build -A odoo

It seems to start building everything from source, is that normal?

I don’t know what kind of info is required but here are a few things
# nix-channel --list
nixpkgs https://nixos.org/channels/nixpkgs-unstable
nixos https://nixos.org/channels/nixos-14.12

# echo $NIX_PATH
/nix/var/nix/profiles/per-user/root/channels/nixos:nixpkgs=/etc/nixos/nixpkgs:nixos-config=/etc/nixos/configuration.nix

/etc/nixos/nixpkgs points to /src/nixpkgs where I have my clone of nixpkgs

# nix-build -A odoo
these derivations will be built:
  /nix/store/4f93r775pgxccqiw2y999bhz84irqdi5-xz-5.2.2.drv
…
  /nix/store/rpa6hx6wi0l40w6q21ia6g8nd655h2hr-gcc-4.9.3.drv
  /nix/store/a1618x2806slj88gyxc944v0xhc84j6f-gcc-wrapper-4.9.3.drv
  /nix/store/i811yml1yxa6grhhx1glld79fs7j5vc2-stdenv-linux-boot.drv
… etc.

Thanks!

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

[Nix-dev] some documentation for the Genode port

[Emery]

For anyone confused by the demo I gave at the conference, I threw together a 
little 
follow up. I'll try and push more info as I have it at the link below.

http://ehmry.github.io/

Emery


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

[Nix-dev] Locale issues with Nix shell (and GHC) on OSX

[Yves Parès]

Hi,
When compiling within a *pure* nix shell with GHC, I get the following
warning:
Warning: unable to set locale to UTF-8 encoding; GHC may fail with 'invalid
character'

and indeed depending on the haskell packages I use, I may get build errors
due to this. (I build with stack, not directly with GHC)
On Ubuntu, this was fixed by adding the package glibcLocales to my
buildInputs.
But on OSX, glibcLocales is just null, and I can't find if there exists an
equivalent to it, or another way to fix the warning (without switching to a*
non pure* shell, which is not okay for ensuring my build environment is
reproducible).

Has someone got extra information?
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] nix-build -A builds everything

[Guillaume Maudoux (Layus)]

Hi,

The problem is that you build odoo within the nixpkgs defined by the
master branch.
As the master branch defines derivations more recent than the ones
installed, it needs to instantiate them.
But these derivations are so new that even hydra did not build them yet,
so you have no binary support for these.

To get binary support, you should develop on a branch based on the same
commit as you current channel.
See
https://nixos.org/wiki/Create_and_debug_nix_packages#Tracking_upstream_changes_and_avoiding_extra_rebuilding
for extra details and  step-by-step commands.

Does it answer your question or did I miss the point ?

Le 17/11/15 00:03, Dieter Vekeman a écrit :
> Hi
>
> I’m trying to create a nix package (for the odoo suite 
> https://github.com/odoo/odoo/tree/8.0).
>
> I checked out nixpkgs
> created a folder in pkgs/applications/networking/odoo
>
> This is what I have so far
> # cat ./pkgs/applications/networking/odoo/default.nix
> { stdenv, fetchurl, buildPythonPackage, pythonPackages }:
>
> buildPythonPackage {
>   name = "odoo-8.0.0";
>   namePrefix = "";
>
>   src = fetchurl {
> url = "https://github.com/odoo/odoo/archive/8.0.0.zip;;
> sha256 = 
> "dee5ca67cd314c389fe3fb924c1fc6ba84a913b60956bd0308344e9c0e0cb751";
>   };
>
>   propagatedBuildInputs = [ ];
>
>   # Testing fails.
>   doCheck = false;
>
>   meta = {
> description = "Odoo ERP / CRM business suite";
> homepage = https://www.odoo.com;
> license = stdenv.lib.licenses.agpl3;
>   };
> }
>
> When I run
> nix-build -A odoo
>
> It seems to start building everything from source, is that normal?
>
> I don’t know what kind of info is required but here are a few things
> # nix-channel --list
> nixpkgs https://nixos.org/channels/nixpkgs-unstable
> nixos https://nixos.org/channels/nixos-14.12
>
> # echo $NIX_PATH
> /nix/var/nix/profiles/per-user/root/channels/nixos:nixpkgs=/etc/nixos/nixpkgs:nixos-config=/etc/nixos/configuration.nix
>
> /etc/nixos/nixpkgs points to /src/nixpkgs where I have my clone of nixpkgs
>
> # nix-build -A odoo
> these derivations will be built:
>   /nix/store/4f93r775pgxccqiw2y999bhz84irqdi5-xz-5.2.2.drv
> …
>   /nix/store/rpa6hx6wi0l40w6q21ia6g8nd655h2hr-gcc-4.9.3.drv
>   /nix/store/a1618x2806slj88gyxc944v0xhc84j6f-gcc-wrapper-4.9.3.drv
>   /nix/store/i811yml1yxa6grhhx1glld79fs7j5vc2-stdenv-linux-boot.drv
> … etc.
>
> Thanks!
>
> ___
> 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] TexLive wiki page

[Vladimír Čunát]

On 11/18/2015 02:44 PM, Matthias Beyer wrote:
> So you would like to see more blog posts, more tutorials and more
> stuff like that?

I believe we actually do have a considerable amount of blog posts and
the like. The point is IMHO to review, polish them, "make official" by
putting into one of the manuals, and *maintain* them (have you ever
heard of anyone keeping a blog post up-to-date over long term?).

Yes, it's more work and perhaps less fun, I'm afraid, but it's much more
useful.


As for keeping docs "close to source", we can easily do something like a
comment in nixpkgs, so some editors could even jump easily to it
# docs are in ../../doc/my-package.xml
It could also be done the other way, i.e. we might move the files out of
doc/ closer to what they document and include them from doc/manual.xml,
but it might be more complicated to do and it would IMO require a wider
discussion.


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] [PATCH] pulseaudio: Add support for package configuration files.

[Vladimír Čunát]

On 11/18/2015 12:08 PM, Jookia wrote:
> I wonder if there's any review tools that support a github
> bridge that someone could set up. It doesn't look like it from first glance.

I've seen the command-line tool, but I almost haven't used it yet.
$ hub --help
[...]
GitHub Commands:
   pull-request   Open a pull request on GitHub
   fork   Make a fork of a remote repository on GitHub and add
as remote
   create Create this repository on GitHub and add GitHub as origin
   browse Open a GitHub page in the default browser
   compareOpen a compare page on GitHub
   releaseList or create releases (beta)
   issue  List or create issues (beta)
   ci-status  Show the CI status of a commit


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] [RFC] Generating documentation from nixpkgs (markdown files) with pandoc (Was: Real documentation, aka "Let's kill the wiki")

[Colin Putney]

On Wed, Nov 18, 2015 at 9:51 AM, Domen Kožar  wrote:

> I've once experimented and ported nixpkgs manual to
> http://static.domenkozar.com/nixpkgs-manual-sphinx-exp/
>

Wow, that looks great! This kind of thing is much nicer than the docs
currently on the web site. With everything in one page it's hard to find,
link to and search for specific sections that have the information you
want. This solves that problem nicely.


> But there doesn't seem to be of a much interest to make documentation more
> approachable (something we did with github for code)
>

 Isn't this thread an expression of interest?

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

Re: [Nix-dev] [RFC] Generating documentation from nixpkgs (markdown files) with pandoc (Was: Real documentation, aka "Let's kill the wiki")

[Domen Kožar]

After the discussion at https://github.com/NixOS/nixpkgs/issues/1960 I've
lost hope to reach a consensus.

I'll maintain Python related documentation in restructured text separately
from nixpkgs manual since the docbook tooling we have is a real disaster.

I hope that doesn't discourage others to try :)

On Thu, Nov 19, 2015 at 6:55 PM, Colin Putney  wrote:

>
>
> On Wed, Nov 18, 2015 at 9:51 AM, Domen Kožar  wrote:
>
>> I've once experimented and ported nixpkgs manual to
>> http://static.domenkozar.com/nixpkgs-manual-sphinx-exp/
>>
>
> Wow, that looks great! This kind of thing is much nicer than the docs
> currently on the web site. With everything in one page it's hard to find,
> link to and search for specific sections that have the information you
> want. This solves that problem nicely.
>
>
>> But there doesn't seem to be of a much interest to make documentation
>> more approachable (something we did with github for code)
>>
>
>  Isn't this thread an expression of interest?
>
> Colin
>
> ___
> 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] [ANN] Paket2Nix

[Luca Bruno]

Hi thanks for your contribution. Any reason why you didn't use the existing
dotnetPackages infrastructure?

On Fri, Nov 20, 2015 at 12:51 AM, Karsten Gebbert  wrote:

> Hi all,
>
> I would like to announce Paket2Nix, a simple way to get started with
> packaging
> .NET projects for the nix ecosystem. Please find the code and a tiny
> how-to on
> its Github project page, at
>
>https://github.com/krgn/Paket2Nix
>
> It might still have a few kinks, so please file issues and/or feature
> requests. I am aware that the nix-expressions it produces are (too)
> verbose, but
> I wanted to get it in an acceptable shape and out there before I dive
> deeper
> into that area. So, feedback very much welcome!
>
>
> Best,
>
> Karsten
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>



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

Re: [Nix-dev] Locale issues with Nix shell (and GHC) on OSX

[zimbatm]

Sorry, I don't know how to help you further. I also don't know why
glibcLocales should be linux-only.

On Thu, 19 Nov 2015 at 12:30 Yves Parès  wrote:

> I actually need Unicode, this is why setting LANG=C is a problem.
>
> 2015-11-19 13:27 GMT+01:00 zimbatm :
>
>> Did you check your environment variables ? I suppose that LANG and
>> friends are set to en_US.UTF-8. You could try to add the locales packages
>> to your shell.nix or change LANG, LC_ALL to "C". If you don't need Unicode
>> that might be easier.
>>
>> On Thu, 19 Nov 2015 10:44 Yves Parès  wrote:
>>
>>> Hi,
>>> When compiling within a *pure* nix shell with GHC, I get the following
>>> warning:
>>> Warning: unable to set locale to UTF-8 encoding; GHC may fail with
>>> 'invalid character'
>>>
>>> and indeed depending on the haskell packages I use, I may get build
>>> errors due to this. (I build with stack, not directly with GHC)
>>> On Ubuntu, this was fixed by adding the package glibcLocales to my
>>> buildInputs.
>>> But on OSX, glibcLocales is just null, and I can't find if there exists
>>> an equivalent to it, or another way to fix the warning (without switching
>>> to a* non pure* shell, which is not okay for ensuring my build
>>> environment is reproducible).
>>>
>>> Has someone got extra information?
>>> ___
>>> 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] Locale issues with Nix shell (and GHC) on OSX

[Vladimír Čunát]

On 11/19/2015 09:35 PM, zimbatm wrote:
> I also don't know why glibcLocales should be linux-only.

I think glibcLocales only makes sense if you use glibc, which is not the
case on darwin. (The glibcLocales format even changes between some
versions incompatibly.)

Darwin libc surely has its own way of providing locale data, but I don't
know that platform at all.


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

[Nix-dev] nixpkgs Dependencies Availability Test

[Martin Vahi]

Is about 300MiB in size due to a clone of the

https://github.com/NixOS/nixpkgs

and resides at

http://technology.softf1.com/nix/2015/2015_11_19_NixOS_nixpkgs_download_test_by_martin_vahi_at_softf1_com.tar.bz2

sha256:
f05cf8bb85527a14f22adf0e2b3a7fa56f63461b7580620e4d54204c4d2db1ba

The idea is roughly:

git clone https://github.com/NixOS/nixpkgs
cd nixpkgs
find . -name '*.nix' > list_of_nixfiles.txt

and then each of the nix-files is searched for
pairs of fetch-url's and hash values and a gigantic
bash-script is generated that contains lines of calls
to the nix-prefetch-url

---a--demo--excerpt--start---
nix-prefetch-url --type sha256
http://bits.xensource.com/oss-xen/release/4.5.1/xen-4.5.1.tar.gz
0w8kbqy7zixacrpbk3yj51xx7b3f6l8ghsg3551w8ym6zka13336 ;
nix-prefetch-url --type sha256 sourceInfo.url sourceInfo.hash ;
nix-prefetch-url --type sha256
http://download.belastingdienst.nl/belastingdienst/apps/linux/ib2007_linux.tar.gz
13p3gv086jn95wvmfygdmk9qjn0qxqdv7pp0v5pmw6i5hp8rmjxf ;
---a--demo--excerpt--end---

I executed the gigantic bash script and my conclusion
is that many up-stream packages, their files, are offline
or their hashes do not match, specially those of the

https://www.npmjs.com/

In those circumstances it is absolutely no wonder
that there are various build problems. I propose that
in addition to "stable" and "unstable" packages
would be classified as "Nix-contained" and
"up-stream-dependent".

The "Nix-contained" packages would
be buildable without downloading anything from any
server other than the Nix project servers and
various caches. I believe that package specific,
up-stream dependent, package upgrade tools might be
bundled with the "Nix-contained" packages, so that
when the up-stream servers come online, the
package upgrade could be _manually_ made and
the "Nix-contained" set of packages is supplemented
with a new version of the package without removing
the old version.

Currently it seems to me that the
up-stream dependent package build scripts
try to do 2 in one: build a Nix package and
upgrade its dependencies. In the case of the
"Nix-contained" packages the package building
would work without downloading anything from
upstream and all testing and experimentation
that is related to the upgrade of the dependencies
of a "Nix-contained" package, would be carried out
by the package maintainer at a time, when he/she
has the time to work on the package, not
whenever the package is being automatically built.


Thank You for reading my letter and
I hope to receive criticism that
tells that I'm missing/omitting
a lot of important issues or have
otherwise come up with a spectacular blunder. :-D

Regards,
martin.v...@softf1.com

P.S. The "manual" upgrade of dependencies
will probably be a requirement even due to
computational limitations and security
requirements. Formal verification might
take a lot of CPU-power and it might not
be optimal to run that every time a
package is built.



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

Re: [Nix-dev] Hamburg NixOS Meetup

[Pascal Wittmann]

On 11/18/2015 09:48 PM, Alexander Flatter wrote:
> I'm in!

Thanks for your feedback :-)

I have created a meetup at

http://www.meetup.com/Hamburg-NixOS-Meetup

Feel free to join!



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

Re: [Nix-dev] Hamburg NixOS Meetup

[Pascal Wittmann]

On 11/18/2015 08:14 PM, Hajo Möller wrote:
> Sure, let's do this.
> How about meeting irregularly for good coffee and a snack around midday?

Midday will likely collide with my working time. I would rather pick
evenings, but of course this also depends on the location.



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

Re: [Nix-dev] [PATCH] pulseaudio: Add support for package configuration files.

[Jookia]

On Thu, Nov 19, 2015 at 09:59:09AM +0100, Vladimír Čunát wrote:
> On 11/18/2015 12:08 PM, Jookia wrote:
> > I wonder if there's any review tools that support a github
> > bridge that someone could set up. It doesn't look like it from first glance.

> I've seen the command-line tool, but I almost haven't used it yet.
> $ hub --help
> [...]

> Vladimir

hub is pretty good, but I'm not sure if you can sign up or verify emails through
it. I've used hub in the past to contribute to projects, but the problem is that
there's a block for joining using only free software.

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

Re: [Nix-dev] Publish All of Hackage

[zimbatm]

Are haskell libraries useful other than at compile time ?

Nix doesn't do dependency resolution in regards to version matching and I
don't think that we will ever have a unified hackage where all the latest
versions work together. Tools like cabal2nix seem essential in that regard.

If we where to only package applications, provide cabal2nix and friends and
include common overrides for things that cabal doesn't describe like C
libraries I think that it would be already very good.

On Thu, 19 Nov 2015 11:14 Peter Simons  wrote:

> The Problem
> ---
>
> Users of Nixpkgs want to build Haskell packages that have no recent
> release, i.e. the software's authors have not updated their code to deal
> with modern versions of the respective build dependencies. The required
> old versions, however, may not be available in Nixpkgs, and then the
> build cannot succeed. At that point, we recommend our users to add the
> missing package versions themselves [1] through the override mechanism
> in ~/.nixpkgs/config.nix. That approach works fine, but it's challenging
> for new users and it's certainly inconvenient.
>
> The Situation Today
> ---
>
> We publish 11,216 package versions out of 62,354 available ones, i.e.
> 18% of Hackage. We select packages for distribution using the following
> criteria:
>
> 1. the latest version of every package (9,058 builds),
>
> 2. old versions required by LTS Haskell (2,137 builds), and
>
> 3. old versions manually configured in the "extra-packages" field of
>configuration-hackage2nix.yaml [2] (21 builds).
>
> The resulting hackage-packages.nix [3] file is ~8.3 MByte large.
>
> Now, we could simply publish all of Hackage, i.e. all 62,354 available
> builds. That would certainly make the lives of many Haskell hackers
> easier, but unfortunately the resulting hackage-packages.nix file would
> require 52 MByte of space. Furthermore, simple benchmarks suggest that
> nix-instantiate needs a whopping 4 seconds to instantiate a
> "ghcWithPackages" environment from the new database where instantiating
> the same environment used to take 0.45 seconds before --- a performance
> drop by a factor of 8.
>
> Possible Improvements
> -
>
> We could continue to publish the "small" hackage-packages.nix database
> by default, but generate an additional large database that we'd store in
> a separate location. We would then add support for an option to
> ~/.nixpkgs/config.nix users could set to opt in to using the large
> database if they want to. That way, Haskell users would have an option
> to get all of Hackage without causing a performance drop for everyone
> else.
>
> One issue is that checking that ~50MB file into Nixpkgs might be a bad
> idea, because it sets a dangerous precedent. Arguably, if we check all
> of Hackage into Nixpkgs, then we cannot reasonably say *no* to someone
> who wants to check all of CPAN into Nixpkgs too, and before we know it
> our Git repository triples in size. So it might be wise to put the full
> Hackage variant of hackage-packages.nix into a separate repository that
> we fetch via "builtins.fetchurl" if the corresponding option is enabled.
>
> An altogether different approach is to improve our tools like cabal2nix
> to make it convenient to add old versions from Hackage into a local
> Nixpkgs instance, i.e. by extending the program to generate builds for
> all missing versions to complete the transitive closure of the requested
> build so that users don't have to run it a dozen times because multiple
> old versions are missing. Conceivably, we could also provide tools that
> manage ~/.nixpkgs/config.nix, which might be a good idea independent of
> these Haskell-specific issues.
>
>
> [1]:
> http://nixos.org/nixpkgs/manual/#how-to-create-nix-builds-for-your-own-private-haskell-packages
> [2]:
> https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/haskell-modules/configuration-hackage2nix.yaml
> [3]:
> https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/haskell-modules/hackage-packages.nix
>
> ___
> 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-dev] private NixOS modules

[Rok Garbas]

i think musnix is a nice example how to do this:

https://github.com/musnix/musnix


Quoting Sergey Mironov (2015-11-18 10:45:54)
> Oh, Thanks. I really should re-read the manual :)
> 
> Sergey
> 
> 2015-11-18 12:16 GMT+03:00 Nicolas Pierron :
> > Hi Sergey,
> >
> > We have a some documenation in the NixOS Manual [1] which explains how
> > to do that.  To make it short, your configuration.nix file should have
> > an import attribute which is a list of additional modules that you
> > want to include.
> > So if you file configuration.nix looks something like (a), you want to
> > convert it to something similar to (b)
> >
> > ** (a):
> > {
> >   services.openssh.enable = true = …;
> >   …
> > }
> >
> > ** (b):
> >
> > {
> >   imports = [ ./custom-service.nix ];
> >   services.openssh.enable = true = …;
> >   …
> > }
> >
> > [1] http://nixos.org/nixos/manual/index.html#sec-modularity
> >
> > On Wed, Nov 18, 2015 at 8:14 AM, Sergey Mironov  wrote:
> >> Nicolas, I didn't know about NIXOS_EXTRA_MODULE_PATH, thanks.
> >> Could you explain other possible solution in a bit more details? How
> >> can we include modified module list in configuration.nix?
> >>
> >> Regards,
> >> Sergey
> >>
> >> 2015-11-17 17:43 GMT+03:00 Nicolas Pierron :
> >>> Hi Sergey,
> >>>
> >>> I think you can set the NIXOS_EXTRA_MODULE_PATH [1] environment
> >>> variable to achieve that.
> >>> Otherwise, you can change your configuration.nix file to always
> >>> include your new module list, and to include your own real-config.nix
> >>>
> >>> [1] 
> >>> https://github.com/NixOS/nixpkgs/blob/master/nixos/lib/eval-config.nix#L30
> >>>
> >>>
> >>> On Tue, Nov 17, 2015 at 2:04 PM, Sergey Mironov  wrote:
>  Hi. I'd like to write a couple of NixOS modules which probably don't
>  look meaningful for large audience. Normally, we keep modules in
>  nixpkgs/nixos/modules directory and list them in module-list.nix file.
>  In my case, I'd like to put module in a private place (which is my git
>  repo which keeps nixpkgs as a Git submodule). Is it possible to
>  'include' them in the public list to make them accessible from
>  per-system.nix files?
> 
>  As a result, I'd like to be able to write in configuration.nix
>  something like the following:
> 
>  services.my-custom-service = {
>    enable = true;
>    ...
>  }
> 
>  without including expression for my-custom-service in the public tree.
> 
>  Regards,
>  Sergey
>  ___
>  nix-dev mailing list
>  nix-dev@lists.science.uu.nl
>  http://lists.science.uu.nl/mailman/listinfo/nix-dev
> >>>
> >>>
> >>>
> >>> --
> >>> Nicolas Pierron
> >>> http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
> >
> >
> >
> > --
> > 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


--
Rok Garbas - http://www.garbas.si


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

[Nix-dev] Publish All of Hackage

[Peter Simons]

The Problem
---

Users of Nixpkgs want to build Haskell packages that have no recent
release, i.e. the software's authors have not updated their code to deal
with modern versions of the respective build dependencies. The required
old versions, however, may not be available in Nixpkgs, and then the
build cannot succeed. At that point, we recommend our users to add the
missing package versions themselves [1] through the override mechanism
in ~/.nixpkgs/config.nix. That approach works fine, but it's challenging
for new users and it's certainly inconvenient.

The Situation Today
---

We publish 11,216 package versions out of 62,354 available ones, i.e.
18% of Hackage. We select packages for distribution using the following
criteria:

1. the latest version of every package (9,058 builds),

2. old versions required by LTS Haskell (2,137 builds), and

3. old versions manually configured in the "extra-packages" field of
   configuration-hackage2nix.yaml [2] (21 builds).

The resulting hackage-packages.nix [3] file is ~8.3 MByte large.

Now, we could simply publish all of Hackage, i.e. all 62,354 available
builds. That would certainly make the lives of many Haskell hackers
easier, but unfortunately the resulting hackage-packages.nix file would
require 52 MByte of space. Furthermore, simple benchmarks suggest that
nix-instantiate needs a whopping 4 seconds to instantiate a
"ghcWithPackages" environment from the new database where instantiating
the same environment used to take 0.45 seconds before --- a performance
drop by a factor of 8.

Possible Improvements
-

We could continue to publish the "small" hackage-packages.nix database
by default, but generate an additional large database that we'd store in
a separate location. We would then add support for an option to
~/.nixpkgs/config.nix users could set to opt in to using the large
database if they want to. That way, Haskell users would have an option
to get all of Hackage without causing a performance drop for everyone
else.

One issue is that checking that ~50MB file into Nixpkgs might be a bad
idea, because it sets a dangerous precedent. Arguably, if we check all
of Hackage into Nixpkgs, then we cannot reasonably say *no* to someone
who wants to check all of CPAN into Nixpkgs too, and before we know it
our Git repository triples in size. So it might be wise to put the full
Hackage variant of hackage-packages.nix into a separate repository that
we fetch via "builtins.fetchurl" if the corresponding option is enabled.

An altogether different approach is to improve our tools like cabal2nix
to make it convenient to add old versions from Hackage into a local
Nixpkgs instance, i.e. by extending the program to generate builds for
all missing versions to complete the transitive closure of the requested
build so that users don't have to run it a dozen times because multiple
old versions are missing. Conceivably, we could also provide tools that
manage ~/.nixpkgs/config.nix, which might be a good idea independent of
these Haskell-specific issues.


[1]: 
http://nixos.org/nixpkgs/manual/#how-to-create-nix-builds-for-your-own-private-haskell-packages
[2]: 
https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/haskell-modules/configuration-hackage2nix.yaml
[3]: 
https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/haskell-modules/hackage-packages.nix

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

Re: [Nix-dev] Locale issues with Nix shell (and GHC) on OSX

[zimbatm]

Did you check your environment variables ? I suppose that LANG and friends
are set to en_US.UTF-8. You could try to add the locales packages to your
shell.nix or change LANG, LC_ALL to "C". If you don't need Unicode that
might be easier.

On Thu, 19 Nov 2015 10:44 Yves Parès  wrote:

> Hi,
> When compiling within a *pure* nix shell with GHC, I get the following
> warning:
> Warning: unable to set locale to UTF-8 encoding; GHC may fail with
> 'invalid character'
>
> and indeed depending on the haskell packages I use, I may get build errors
> due to this. (I build with stack, not directly with GHC)
> On Ubuntu, this was fixed by adding the package glibcLocales to my
> buildInputs.
> But on OSX, glibcLocales is just null, and I can't find if there exists an
> equivalent to it, or another way to fix the warning (without switching to a*
> non pure* shell, which is not okay for ensuring my build environment is
> reproducible).
>
> Has someone got extra information?
> ___
> 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] Locale issues with Nix shell (and GHC) on OSX

[Yves Parès]

I actually need Unicode, this is why setting LANG=C is a problem.

2015-11-19 13:27 GMT+01:00 zimbatm :

> Did you check your environment variables ? I suppose that LANG and friends
> are set to en_US.UTF-8. You could try to add the locales packages to your
> shell.nix or change LANG, LC_ALL to "C". If you don't need Unicode that
> might be easier.
>
> On Thu, 19 Nov 2015 10:44 Yves Parès  wrote:
>
>> Hi,
>> When compiling within a *pure* nix shell with GHC, I get the following
>> warning:
>> Warning: unable to set locale to UTF-8 encoding; GHC may fail with
>> 'invalid character'
>>
>> and indeed depending on the haskell packages I use, I may get build
>> errors due to this. (I build with stack, not directly with GHC)
>> On Ubuntu, this was fixed by adding the package glibcLocales to my
>> buildInputs.
>> But on OSX, glibcLocales is just null, and I can't find if there exists
>> an equivalent to it, or another way to fix the warning (without switching
>> to a* non pure* shell, which is not okay for ensuring my build
>> environment is reproducible).
>>
>> Has someone got extra information?
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra.nixos.org problems

[Eelco Dolstra]

Hi,

On 17/11/15 17:05, Vladimír Čunát wrote:

> We're getting lots of Hydra errors saying:
> Aborted: cannot connect to ‘root@kenny’: Connection closed by 131.180.119.71
> 
> It seems to be killing lots of builds randomly.

Hm, we're losing more and more physical build machines. I think I should visit
the datacenter soon to get them back up :-)

> Incidentally, it might be nice if the fact that one build slave is
> unreachable wouldn't lead to the jobs being aborted. They could be
> retried, perhaps getting lucky to be assigned to a working machine.

They are in fact retried up to 5 times. The build you linked to is a failure
propagated from this one:

  http://hydra.nixos.org/build/27817621

which shows 5 failed attempts. All failures appear to be due to the disk full on
the main machine.

-- 
Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] nix-build -A builds everything

[Guillaume Maudoux (Layus)]

Hi,

Neat trick.

Am I right however to say that this does not work if your own channel is
not up to date.
Nothing forces branch channels/nixos-unstable on
github.com/NixOS/nixpkgs-channels to point at the same revision as the
one in /nix/var/nix/profiles/per-user/root/channels/nixos/svn-revision.

As for me, I update my tag on the current channel revision after each
update, and branch/rebase on top of it.

I will update the wiki to reference the manual.

Le 19/11/15 15:50, Eelco Dolstra a écrit :
> Hi,
>
> On 19/11/15 11:46, Guillaume Maudoux (Layus) wrote:
>
>> To get binary support, you should develop on a branch based on the same
>> commit as you current channel.
>> See
>> https://nixos.org/wiki/Create_and_debug_nix_packages#Tracking_upstream_changes_and_avoiding_extra_rebuilding
>> for extra details and  step-by-step commands.
> There is an easier way than described on the wiki, namely by using the
> nixpkgs-channels repository, which contains branches corresponding to the
> current channel contents.
>
> For instance, to create a branch named "local" based on the latest
> nixos-unstable channel:
>
> $ git remote add channels git://github.com/NixOS/nixpkgs-channels.git
> $ git remote update channels
> $ git checkout -b local channels/nixos-unstable
>
> and to update it:
>
> $ git remote update channels
> $ git merge channels/nixos-unstable # or "git rebase"
>
> See http://nixos.org/nixos/manual/index.html#sec-getting-sources for more 
> info.
>

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

Re: [Nix-dev] nix-build -A builds everything

[Eelco Dolstra]

Hi,

On 19/11/15 16:10, Guillaume Maudoux (Layus) wrote:

> Neat trick.
> 
> Am I right however to say that this does not work if your own channel is
> not up to date.

It does work (in that you always get binaries from the cache), but it might
download more stuff than if you match your current NixOS version (since in that
case you can expect some stuff to already be present in your Nix store).

-- 
Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] [ANN] Paket2Nix

[Karsten Gebbert]

Luca Bruno  writes:

> Hi thanks for your contribution. Any reason why you didn't use the existing
> dotnetPackages infrastructure?

Yes :)

1) When I started, I did not have a good-enough insight into what there is
already, though that has somewhat changed now. I have an open issue to integrate
parts of the existing code into Paket2Nix.

2) I chose a different strategy for making sure the project finds its
dependencies, namely by linking them into the places referenced in the project
XMLs. The current approach involves creating pkg-config files for each library,
and extensively patching the project files (which, incidentally, I still had to
do as well to turn off Paket itself).

3) I'm currently bouncing ideas back and forth in my mind how to create a
workflow that will simplify all of this. An approach I find appealing could be
to create composed environments where mono is packaged with all specified
libraries via a composed Global Assembly Cache. Then the workflow could become
similar to that of Haskell's, where we'd compose mono (or the coreclr) with the
packages we need. This requires an automated approach to bringing in NuGet deps,
which is definitely possible.


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

Re: [Nix-dev] Real documentation, aka "Let's kill the wiki"

[Profpatsch]

On 15-11-19 02:56am, Roger Qiu wrote:
> Can the manual be made as a gitbook with the chapters fleshed out better
> and made more user friendly? One  part of the manual can be very fact
> based, another part can be story based. Kind of like the difference between
> documentation vs api documentation vs tutorials. I often find myself across
> 3 to 4 different blog posts, the arch and gentoo wiki, the nixos manual,
> the wiki and github issues because the up to date relevant information is
> everywhere.

May I humbly suggest http://stevelosh.com/blog/2013/09/teach-dont-tell/ as
a general documentation writing template?

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

Re: [Nix-dev] nix-build -A builds everything

[Eelco Dolstra]

Hi,

On 19/11/15 11:46, Guillaume Maudoux (Layus) wrote:

> To get binary support, you should develop on a branch based on the same
> commit as you current channel.
> See
> https://nixos.org/wiki/Create_and_debug_nix_packages#Tracking_upstream_changes_and_avoiding_extra_rebuilding
> for extra details and  step-by-step commands.

There is an easier way than described on the wiki, namely by using the
nixpkgs-channels repository, which contains branches corresponding to the
current channel contents.

For instance, to create a branch named "local" based on the latest
nixos-unstable channel:

$ git remote add channels git://github.com/NixOS/nixpkgs-channels.git
$ git remote update channels
$ git checkout -b local channels/nixos-unstable

and to update it:

$ git remote update channels
$ git merge channels/nixos-unstable # or "git rebase"

See http://nixos.org/nixos/manual/index.html#sec-getting-sources for more info.

-- 
Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev