[Nix-commits] SVN commit: nix - r29478 - in nixpkgs/branches/libpng15: . pkgs/applications/graphics/xscreensaver pkgs/applications/misc/xneur pkgs/applications/networking/browsers/icecat-4 pkgs/applic
Author: urkud
Date: Sun Sep 25 03:41:03 2011
New Revision: 29478
URL: https://ssl.nixos.org/websvn/nix/?rev=29478&sc=1
Log:
Merge allegro update from trunk (using svn merge)
Modified:
nixpkgs/branches/libpng15/ (props changed)
nixpkgs/branches/libpng15/pkgs/applications/graphics/xscreensaver/default.nix
(props changed)
nixpkgs/branches/libpng15/pkgs/applications/misc/xneur/0.8.nix (props
changed)
nixpkgs/branches/libpng15/pkgs/applications/networking/browsers/icecat-4/
(props changed)
nixpkgs/branches/libpng15/pkgs/applications/networking/browsers/mozilla-plugins/flashplayer-10/
(props changed)
nixpkgs/branches/libpng15/pkgs/build-support/gcc-wrapper/ (props changed)
nixpkgs/branches/libpng15/pkgs/build-support/release/debian-build.nix
(props changed)
nixpkgs/branches/libpng15/pkgs/build-support/release/nix-build.nix (props
changed)
nixpkgs/branches/libpng15/pkgs/build-support/release/rpm-build.nix (props
changed)
nixpkgs/branches/libpng15/pkgs/build-support/release/source-tarball.nix
(props changed)
nixpkgs/branches/libpng15/pkgs/desktops/kde-4.5/support/shared-desktop-ontologies/
(props changed)
nixpkgs/branches/libpng15/pkgs/development/compilers/ghc/6.10.1.nix (props
changed)
nixpkgs/branches/libpng15/pkgs/development/compilers/ghc/6.10.2.nix (props
changed)
nixpkgs/branches/libpng15/pkgs/development/compilers/ghc/6.8.2.nix (props
changed)
nixpkgs/branches/libpng15/pkgs/development/compilers/ghc/6.8.3.nix (props
changed)
nixpkgs/branches/libpng15/pkgs/development/libraries/allegro/default.nix
nixpkgs/branches/libpng15/pkgs/development/libraries/aterm/2.8.nix (props
changed)
nixpkgs/branches/libpng15/pkgs/development/libraries/fltk/fltk11.nix
(props changed)
nixpkgs/branches/libpng15/pkgs/development/libraries/glibc-2.9/ (props
changed)
nixpkgs/branches/libpng15/pkgs/development/libraries/goocanvas/ (props
changed)
nixpkgs/branches/libpng15/pkgs/development/libraries/pcre/default.nix
(props changed)
nixpkgs/branches/libpng15/pkgs/development/libraries/readline/readline6.nix
(props changed)
nixpkgs/branches/libpng15/pkgs/development/tools/misc/autoconf/2.13.nix
(props changed)
nixpkgs/branches/libpng15/pkgs/development/tools/misc/gnum4/default.nix
(props changed)
nixpkgs/branches/libpng15/pkgs/misc/tex/pgf/1.x.nix (props changed)
nixpkgs/branches/libpng15/pkgs/misc/tex/pgf/2.x.nix (props changed)
nixpkgs/branches/libpng15/pkgs/os-specific/linux/atheros/r3867.nix (props
changed)
nixpkgs/branches/libpng15/pkgs/os-specific/linux/kernel-headers/2.6.28.nix
(props changed)
nixpkgs/branches/libpng15/pkgs/os-specific/linux/kernel-headers/2.6.32.nix
(props changed)
nixpkgs/branches/libpng15/pkgs/os-specific/linux/kernel/generic.nix (props
changed)
nixpkgs/branches/libpng15/pkgs/os-specific/linux/kernel/linux-2.6.25.nix
(props changed)
nixpkgs/branches/libpng15/pkgs/os-specific/linux/kernel/linux-2.6.27.nix
(props changed)
nixpkgs/branches/libpng15/pkgs/os-specific/linux/kernel/linux-2.6.28.nix
(props changed)
nixpkgs/branches/libpng15/pkgs/os-specific/linux/kernel/linux-2.6.29.nix
(props changed)
nixpkgs/branches/libpng15/pkgs/os-specific/linux/kernel/linux-2.6.32-xen.nix
(props changed)
nixpkgs/branches/libpng15/pkgs/os-specific/linux/kernel/linux-2.6.32.nix
(props changed)
nixpkgs/branches/libpng15/pkgs/os-specific/linux/kernel/linux-2.6.33.nix
(props changed)
nixpkgs/branches/libpng15/pkgs/os-specific/linux/kqemu/1.4.0pre1.nix
(props changed)
nixpkgs/branches/libpng15/pkgs/os-specific/linux/qemu-kvm/default.nix
(props changed)
nixpkgs/branches/libpng15/pkgs/os-specific/linux/util-linux-ng/ (props
changed)
nixpkgs/branches/libpng15/pkgs/servers/mail/dovecot/1.1.1.nix (props
changed)
nixpkgs/branches/libpng15/pkgs/shells/bash/default.nix (props changed)
nixpkgs/branches/libpng15/pkgs/stdenv/generic/setup.sh (props changed)
nixpkgs/branches/libpng15/pkgs/stdenv/linux/make-bootstrap-tools.nix
(props changed)
nixpkgs/branches/libpng15/pkgs/tools/networking/wget/default.nix (props
changed)
Modified:
nixpkgs/branches/libpng15/pkgs/development/libraries/allegro/default.nix
==
--- nixpkgs/branches/libpng15/pkgs/development/libraries/allegro/default.nix
Sun Sep 25 03:39:23 2011(r29477)
+++ nixpkgs/branches/libpng15/pkgs/development/libraries/allegro/default.nix
Sun Sep 25 03:41:03 2011(r29478)
@@ -13,11 +13,11 @@
(builtins.attrNames (builtins.removeAttrs x helperArgNames));
sourceInfo = rec {
baseName="allegro";
-version="4.4.0.1";
+version="4.4.2";
name="${baseName}-${version}";
project="alleg";
-
url="mirror://sourceforge/project/${project}/${baseName}/${version}/${name}.tar.gz";
-hash="0qgkmazr07lmnbj6h6yk10vmcm15gafc
[Nix-commits] SVN commit: nix - r29477 - nixpkgs/trunk/pkgs/development/libraries/allegro
Author: urkud
Date: Sun Sep 25 03:39:23 2011
New Revision: 29477
URL: https://ssl.nixos.org/websvn/nix/?rev=29477&sc=1
Log:
allegro-4.4.2; compiles against libpng-1.5.4
Modified:
nixpkgs/trunk/pkgs/development/libraries/allegro/default.nix
Modified: nixpkgs/trunk/pkgs/development/libraries/allegro/default.nix
==
--- nixpkgs/trunk/pkgs/development/libraries/allegro/default.nixSat Sep
24 20:47:47 2011(r29476)
+++ nixpkgs/trunk/pkgs/development/libraries/allegro/default.nixSun Sep
25 03:39:23 2011(r29477)
@@ -13,11 +13,11 @@
(builtins.attrNames (builtins.removeAttrs x helperArgNames));
sourceInfo = rec {
baseName="allegro";
-version="4.4.0.1";
+version="4.4.2";
name="${baseName}-${version}";
project="alleg";
-
url="mirror://sourceforge/project/${project}/${baseName}/${version}/${name}.tar.gz";
-hash="0qgkmazr07lmnbj6h6yk10vmcm15gafcwy5jn7xpwy7bahzraiz0";
+url="mirror://sourceforge/project/${project}/${name}.tar.gz";
+hash="1p0ghkmpc4kwij1z9rzxfv7adnpy4ayi0ifahlns1bdzgmbyf88v";
};
in
rec {
___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits
Re: [Nix-dev] distutils2nix/python4nix
Excerpts from Florian Friesdorf's message of Sun Sep 25 01:12:06 +0200 2011: > I'd like to see a discussion on how to generate nix expressions, not on > "why what we are currently doing is maybe not going to work out", I > guess that was discussed enough in the past. Don't get me wrong, please: "not working out" and "not scaling well" is a difference! I know that generating .nix expression will work. But I would not enjoy dozens of people committing their version of package collections - one having a flag set to true, the next to false etc. Eg cabal2nix *is* hardcoding flags in its Haskell code. It was recommended recently. How do you efficiently test different flag combinations for whatever reason (eg cause you're a maintainer?) I don't say it doesn't work: You could create many cabal2nix branches each having a different setting. You could also add command line options to cabal2nix. then you still need many nixpkgs branches? How to use many nixpkgs branches in nixos rebuild? .. (Yes, it can be done.) If you start moving those flags into .nix files you will get different sets of dependencies. Then you either can make the "dependency list" generic as well - or you can pass more dependencies (and wait for ghc building them) then required trusting cabal to only pick those required. So yes, it will work. But it may not be perfect but good enough for most use cases. This applies to Haskell only. In Ruby and Python dependencies are simpler. You don't have trees of choices. You're still likely to run into runtime errors like "X requires version 2.0 or greater, but 1.8 found" unless you check version constraints which is not done when generating .nix files individually. And that's the kind of "late failure" I love most :) But you're right. I'll shut up (unless being asked) and watch .. I'm pretty sure that you know python better than I do - so go ahead and get your job done. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] distutils2nix/python4nix
On Sat, 24 Sep 2011 23:54:48 +0200, Marc Weber wrote: > (..) > To keep the long story short: I don't believe in generating .nix > expressions scaling very well for the future. But I don't know :) > > > expressions. If you did not install the combination sometime beforehand, > > then nix is I think the wrong tool by design. The question is more what > > tools we have to generate expressions for us. > > So how to use ruby,python,.. or many java maven driven packages on > nixpkgs then? Is the answer: Don't? Or "symlink libraries to /usr/lib > so that standard tools like ruby and python packages find them easier? > I'd like to get rid of this kind of mess. But I don't have the perfect > solution yet. I cannot follow your argument. How is generating nix expressions related to having syminks in /usr/lib? > > If my perception of nix is wrong, please correct me. > You're welcome at "great Nix" facing reald world dynamic managed package > databases of dynamic languages :) > > So yes, its a feeling only that the current way won't scale for the future. > Its > not knowing. I may be wrong. I'm waiting for others proofing me wrong doing > all > the work :) Meanwhile I try to find solutions which work for me minimizing the > time I have to spend to get packages working .. Well then, lean back, let others struggle with generating nix expressions and enjoy the show ;) I'd like to see a discussion on how to generate nix expressions, not on "why what we are currently doing is maybe not going to work out", I guess that was discussed enough in the past. -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpfBJ7DpjBuz.pgp Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Problems getting started with nix
Dear nix developers, After reading http://fixingscientificsoftwaredistribution.blogspot.com/ (a blog on wich some people try to get ideas and experiences for a new scientific software distribution possibly based on nix) I got interested in what nix really was so I tried to install and run it as described on: http://hydra.nixos.org/build/565033/download/1/manual/#chap-quick-start But doing that I got some errors. I tried to work around them but did not succeed in that. I pasted relevant parts of the terminal session on: http://pastebin.com/xeSYBHyn Not I got around the problems of `nix-channel --update` by doing `sudo nix-channel --update` but later on I get similar acces problems. I installed nix as root just as suggested in the quick start. I did not supply the --prefix and --with-store-dir=path to make install. And I'm running OS X 10.6.8 and the nix version is nix-0.16 Thanks in advance, Maarten Derickx ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] nix store: hardlink vs symlink (was Re: python application vs python environment)
Excerpts from Florian Friesdorf's message of Sat Sep 24 23:38:42 +0200 2011: > But the links would be just intra-store links, or? Is it a supported > setup to have parts of the store on different devices? Some tests in nixos mount a writable filesystem over a readonly store. It would be hard to mount some /nix/store/* paths only. Usually you put /nix/store or /nix on its own filesystem or partition .. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] distutils2nix/python4nix
> My understanding is, that all (needed) combinations would be created as nix
You get to the point: Do you want to read expressions someone else needs
and are shipped with nixpkgs? What if 1000 users start using nixpkgs?
Good luck reviewing 500 .nix file collections doing almost the same.
What if you want to install something in nixos?
Do you always want to generate .nix files before starting?
I don't. From nixpgks-ruby-overlay/hack-nix I know that 70% of the packages
just work
without tweaking.
Eg the last tweak I did was adding:
psych = { buildInputs = [ pkgs.libyaml ]; };
to tell a ruby library about nixpkgs's C implementation of yaml.
Then psych installed fine. I only update the global pool occasionally.
Never the individual package.
To keep the long story short: I don't believe in generating .nix
expressions scaling very well for the future. But I don't know :)
> expressions. If you did not install the combination sometime beforehand,
> then nix is I think the wrong tool by design. The question is more what
> tools we have to generate expressions for us.
So how to use ruby,python,.. or many java maven driven packages on
nixpkgs then? Is the answer: Don't? Or "symlink libraries to /usr/lib
so that standard tools like ruby and python packages find them easier?
I'd like to get rid of this kind of mess. But I don't have the perfect
solution yet.
> If my perception of nix is wrong, please correct me.
You're welcome at "great Nix" facing reald world dynamic managed package
databases of dynamic languages :)
So yes, its a feeling only that the current way won't scale for the future. Its
not knowing. I may be wrong. I'm waiting for others proofing me wrong doing all
the work :) Meanwhile I try to find solutions which work for me minimizing the
time I have to spend to get packages working ..
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] nix store: hardlink vs symlink (was Re: python application vs python environment)
On Sat, 24 Sep 2011 21:56:02 +0200, l...@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) wrote: > Hi Florian, > > Florian Friesdorf skribis: > > > Why is nix using symlinks to link files in the nix store? > > Because hard links don’t work across devices. But the links would be just intra-store links, or? Is it a supported setup to have parts of the store on different devices? -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpXQt3pv8vwx.pgp 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] distutils2nix/python4nix
On Sat, 24 Sep 2011 17:13:23 +0200, Marc Weber wrote: > > If you can solve these problems in hack-nix, I do not understand how it > > would differ from generating nix expressions, instead of doing it > > on-the-fly. > http://article.gmane.org/gmane.linux.distributions.nixos/6180/match=sketchy+list > See first link given there. That's the "pool" I'm talking about: a nix > readable representation of hackage. > > > Why not? And are they artificial or is there some package creating this > > problem? > > A depends on either > - B-1.0 AND C (case I) > - or B-2.0(case II) > > Now TARGET depends on A AND OTHER. > If OTHER depends on B-1.0 case I must be chosen, if OTHER depends on B-2.0 > case II must be chosen when building A because you should not use B-1.0 > and B-2.0 at the same time or bad things can happen. > > Now A is a dependency of TARGET. And TARGET determines the set of > dependencies which must be used by A. That's why generating simple .nix > files will not work in such a case. My understanding is, that all (needed) combinations would be created as nix expressions. If you did not install the combination sometime beforehand, then nix is I think the wrong tool by design. The question is more what tools we have to generate expressions for us. If my perception of nix is wrong, please correct me. -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpbVoLOTdJW7.pgp Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] [Marc Weber] Re: distutils2nix/python4nix
some mails that accidentally did not make it to the list --- Begin Message --- > If you can solve these problems in hack-nix, I do not understand how it > would differ from generating nix expressions, instead of doing it > on-the-fly. http://article.gmane.org/gmane.linux.distributions.nixos/6180/match=sketchy+list See first link given there. That's the "pool" I'm talking about: a nix readable representation of hackage. > Why not? And are they artificial or is there some package creating this > problem? A depends on either - B-1.0 AND C (case I) - or B-2.0(case II) Now TARGET depends on A AND OTHER. If OTHER depends on B-1.0 case I must be chosen, if OTHER depends on B-2.0 case II must be chosen when building A because you should not use B-1.0 and B-2.0 at the same time or bad things can happen. Now A is a dependency of TARGET. And TARGET determines the set of dependencies which must be used by A. That's why generating simple .nix files will not work in such a case. split-base etc in the past was such a case. hack-nix copes with that artificial TARGET case, the ruby and python implementations I wrote only fail with an error telling you that two versions of B are used and that you have to manually choose one to make it work. That's better than nothing. Yes - this also happens for C apps. evince or such once broke. Took quite a while to find out that one dependency was using an overwritten version of a library while another dependency was not. The result was a segfault. I agree that it doesn't happen often. > For me it looks like there are many potential problems and worst case > scenarios, but I kind of refuse to cope with them until I experience > them. Creating nix expressions automatically feels like the next logical > step after "creating nix expressions manually". But if there is such an issue I don't want to start rewriting all of hack-nix.nix - that would take too much of my time. That's why I wrote hack-nix. But I agree that its a working proof concept implementation only. Marc Weber --- End Message --- <#secure method=pgpmime mode=sign> -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] [Florian Friesdorf] Re: distutils2nix/python4nix
some mails that accidentally did not make it to the list --- Begin Message --- On Sat, 24 Sep 2011 15:57:52 +0200, Marc Weber wrote: > Excerpts from Florian Friesdorf's message of Sat Sep 24 15:19:06 +0200 2011: > > I prefer a "manually" maintained tree over on-the-fly. Having explicit > > nix expressions allows for somebody/something to test these and building > > a database of known good sets of packages. If we generate the > > expressions on-the-fly, we would need a database of checksums in order > > to know whether the on-the-fly generated expressions are what we want > > them to be (as brought up by Michael). > > If you mantain them manually you > > - miss to remove dependencies even if they got dropped unless you > regenerate everything +1 for regenerate everything, if that's too slow: introduce caching. > - you may run into some cases where dependencies depend on cabal flags > or versions of other packages being used. Obviously it doesn't matter > much in practise (anymore?) else Peter would have had more issues. > > - you may start builds which then might fail due to wrong versions being > passed (either ghc or library versions). > > using hack-nix you update the hack-nix cache. You define which C > libraries to pass. Everything else should be automatic (dependency > resolution etc). Brute force is used. So it only works on "limited > package list such as _latest packages_". > > It fails early. Eg it says "no version of X found but 2.0 required". If you can solve these problems in hack-nix, I do not understand how it would differ from generating nix expressions, instead of doing it on-the-fly. > Current drawback: requires more evaluation time. Colud be fixed by using > haskell or C implementation. > > You can easily construct artificial dependency construct which can not > be mapped to what Peter does. Why not? And are they artificial or is there some package creating this problem? > However because most other distros have similar limitations it looks > like people work hard on avoid such scenarios so it may not matter > that much for most common packages. For me it looks like there are many potential problems and worst case scenarios, but I kind of refuse to cope with them until I experience them. Creating nix expressions automatically feels like the next logical step after "creating nix expressions manually". > That's a short list. You can overwrite arbitrary cabal flags on the fly > which also may lead to many changes in dependencies. hack-nix copes with > it - if you generate .nix files it may force you regenerating a new pool > of .nix files (worst case). Again: it doesn't seem to happen often > enough to care about. But if I understand it correctly, you are creating a "pool" of nix files, which I currently call a "tree" of nix expressions. Why are you opposing (are you?) the idea of distutils2nix/python4nix? Given the following python packages: plone.app.deco-1.2.3 plone.app.deco-1.3.4 plone.app.deco-2.1 plone.app.standardtiles-1.2 plone.app.standardtiles-1.3 I would create: pkgs.pythonXYPackages.plone.app.deco pkgs.pythonXYPackages.plone.app.deco_1 pkgs.pythonXYPackages.plone.app.deco_1_2 pkgs.pythonXYPackages.plone.app.deco_1_2_3 pkgs.pythonXYPackages.plone.app.deco_1_3 pkgs.pythonXYPackages.plone.app.deco_1_3_4 pkgs.pythonXYPackages.plone.app.deco_2 pkgs.pythonXYPackages.plone.app.deco_2_1 pkgs.pythonXYPackages.plone.app.standardtiles pkgs.pythonXYPackages.plone.app.standardtiles_1 pkgs.pythonXYPackages.plone.app.standardtiles_1_2 pkgs.pythonXYPackages.plone.app.standardtiles_1_3 stored as: ./plone/app/deco/default.nix ./plone/app/deco/1/default.nix ./plone/app/deco/1/2/default.nix ./plone/app/deco/1/2/3/default.nix ./plone/app/deco/1/3/default.nix ./plone/app/deco/1/3/4/default.nix ./plone/app/deco/2/default.nix ./plone/app/deco/2/1/default.nix ./plone/app/standardtiles/default.nix ./plone/app/standardtiles/1/default.nix ./plone/app/standardtiles/1/2/default.nix ./plone/app/standardtiles/1/3/default.nix By that you can add to every package any new version and there are attributes that always fulfill requirements like: - plone.app.deco<2 --> ...plone.app.deco_1 - plone.app.deco<1.3 --> ...plone.app.deco_1_2 -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpDpCSE0L9Ln.pgp Description: PGP signature --- End Message --- -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpnei7xPr1OP.pgp Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] [Marc Weber] Re: distutils2nix/python4nix
some mails that accidentally did not make it to the list --- Begin Message --- Excerpts from Florian Friesdorf's message of Sat Sep 24 15:19:06 +0200 2011: > I prefer a "manually" maintained tree over on-the-fly. Having explicit > nix expressions allows for somebody/something to test these and building > a database of known good sets of packages. If we generate the > expressions on-the-fly, we would need a database of checksums in order > to know whether the on-the-fly generated expressions are what we want > them to be (as brought up by Michael). If you mantain them manually you - miss to remove dependencies even if they got dropped unless you regenerate everything - you may run into some cases where dependencies depend on cabal flags or versions of other packages being used. Obviously it doesn't matter much in practise (anymore?) else Peter would have had more issues. - you may start builds which then might fail due to wrong versions being passed (either ghc or library versions). using hack-nix you update the hack-nix cache. You define which C libraries to pass. Everything else should be automatic (dependency resolution etc). Brute force is used. So it only works on "limited package list such as _latest packages_". It fails early. Eg it says "no version of X found but 2.0 required". Current drawback: requires more evaluation time. Colud be fixed by using haskell or C implementation. You can easily construct artificial dependency construct which can not be mapped to what Peter does. However because most other distros have similar limitations it looks like people work hard on avoid such scenarios so it may not matter that much for most common packages. That's a short list. You can overwrite arbitrary cabal flags on the fly which also may lead to many changes in dependencies. hack-nix copes with it - if you generate .nix files it may force you regenerating a new pool of .nix files (worst case). Again: it doesn't seem to happen often enough to care about. Marc Weber --- End Message --- <#secure method=pgpmime mode=sign> -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-commits] SVN commit: nix - r29476 - in nixpkgs/branches/libpng15: . pkgs/applications/graphics/xscreensaver pkgs/applications/misc/xneur pkgs/applications/networking/browsers/icecat-4 pkgs/applic
Author: urkud Date: Sat Sep 24 20:47:47 2011 New Revision: 29476 URL: https://ssl.nixos.org/websvn/nix/?rev=29476&sc=1 Log: merge with trunk ignoring trunk change Modified: nixpkgs/branches/libpng15/ (props changed) nixpkgs/branches/libpng15/pkgs/applications/graphics/xscreensaver/default.nix (props changed) nixpkgs/branches/libpng15/pkgs/applications/misc/xneur/0.8.nix (props changed) nixpkgs/branches/libpng15/pkgs/applications/networking/browsers/icecat-4/ (props changed) nixpkgs/branches/libpng15/pkgs/applications/networking/browsers/mozilla-plugins/flashplayer-10/ (props changed) nixpkgs/branches/libpng15/pkgs/build-support/gcc-wrapper/ (props changed) nixpkgs/branches/libpng15/pkgs/build-support/release/debian-build.nix (props changed) nixpkgs/branches/libpng15/pkgs/build-support/release/nix-build.nix (props changed) nixpkgs/branches/libpng15/pkgs/build-support/release/rpm-build.nix (props changed) nixpkgs/branches/libpng15/pkgs/build-support/release/source-tarball.nix (props changed) nixpkgs/branches/libpng15/pkgs/desktops/kde-4.5/support/shared-desktop-ontologies/ (props changed) nixpkgs/branches/libpng15/pkgs/development/compilers/ghc/6.10.1.nix (props changed) nixpkgs/branches/libpng15/pkgs/development/compilers/ghc/6.10.2.nix (props changed) nixpkgs/branches/libpng15/pkgs/development/compilers/ghc/6.8.2.nix (props changed) nixpkgs/branches/libpng15/pkgs/development/compilers/ghc/6.8.3.nix (props changed) nixpkgs/branches/libpng15/pkgs/development/libraries/aterm/2.8.nix (props changed) nixpkgs/branches/libpng15/pkgs/development/libraries/fltk/fltk11.nix (props changed) nixpkgs/branches/libpng15/pkgs/development/libraries/glibc-2.9/ (props changed) nixpkgs/branches/libpng15/pkgs/development/libraries/goocanvas/ (props changed) nixpkgs/branches/libpng15/pkgs/development/libraries/pcre/default.nix (props changed) nixpkgs/branches/libpng15/pkgs/development/libraries/readline/readline6.nix (props changed) nixpkgs/branches/libpng15/pkgs/development/tools/misc/autoconf/2.13.nix (props changed) nixpkgs/branches/libpng15/pkgs/development/tools/misc/gnum4/default.nix (props changed) nixpkgs/branches/libpng15/pkgs/misc/tex/pgf/1.x.nix (props changed) nixpkgs/branches/libpng15/pkgs/misc/tex/pgf/2.x.nix (props changed) nixpkgs/branches/libpng15/pkgs/os-specific/linux/atheros/r3867.nix (props changed) nixpkgs/branches/libpng15/pkgs/os-specific/linux/kernel-headers/2.6.28.nix (props changed) nixpkgs/branches/libpng15/pkgs/os-specific/linux/kernel-headers/2.6.32.nix (props changed) nixpkgs/branches/libpng15/pkgs/os-specific/linux/kernel/generic.nix (props changed) nixpkgs/branches/libpng15/pkgs/os-specific/linux/kernel/linux-2.6.25.nix (props changed) nixpkgs/branches/libpng15/pkgs/os-specific/linux/kernel/linux-2.6.27.nix (props changed) nixpkgs/branches/libpng15/pkgs/os-specific/linux/kernel/linux-2.6.28.nix (props changed) nixpkgs/branches/libpng15/pkgs/os-specific/linux/kernel/linux-2.6.29.nix (props changed) nixpkgs/branches/libpng15/pkgs/os-specific/linux/kernel/linux-2.6.32-xen.nix (props changed) nixpkgs/branches/libpng15/pkgs/os-specific/linux/kernel/linux-2.6.32.nix (props changed) nixpkgs/branches/libpng15/pkgs/os-specific/linux/kernel/linux-2.6.33.nix (props changed) nixpkgs/branches/libpng15/pkgs/os-specific/linux/kqemu/1.4.0pre1.nix (props changed) nixpkgs/branches/libpng15/pkgs/os-specific/linux/qemu-kvm/default.nix (props changed) nixpkgs/branches/libpng15/pkgs/os-specific/linux/util-linux-ng/ (props changed) nixpkgs/branches/libpng15/pkgs/servers/mail/dovecot/1.1.1.nix (props changed) nixpkgs/branches/libpng15/pkgs/shells/bash/default.nix (props changed) nixpkgs/branches/libpng15/pkgs/stdenv/generic/setup.sh (props changed) nixpkgs/branches/libpng15/pkgs/stdenv/linux/make-bootstrap-tools.nix (props changed) nixpkgs/branches/libpng15/pkgs/tools/networking/wget/default.nix (props changed) ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] SVN commit: nix - r29474 - nixpkgs/trunk/pkgs/development/libraries/libpng
Author: urkud
Date: Sat Sep 24 20:44:11 2011
New Revision: 29474
URL: https://ssl.nixos.org/websvn/nix/?rev=29474&sc=1
Log:
Add a notice about libpng branch
Modified:
nixpkgs/trunk/pkgs/development/libraries/libpng/default.nix
Modified: nixpkgs/trunk/pkgs/development/libraries/libpng/default.nix
==
--- nixpkgs/trunk/pkgs/development/libraries/libpng/default.nix Sat Sep 24
20:40:58 2011(r29473)
+++ nixpkgs/trunk/pkgs/development/libraries/libpng/default.nix Sat Sep 24
20:44:11 2011(r29474)
@@ -2,6 +2,7 @@
assert zlib != null;
+# If you want to upgrade libpng, look at libpng15 branch
stdenv.mkDerivation rec {
name = "libpng-1.2.46";
___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] SVN commit: nix - r29473 - nixpkgs/trunk/pkgs/development/libraries/opencv
Author: urkud
Date: Sat Sep 24 20:40:58 2011
New Revision: 29473
URL: https://ssl.nixos.org/websvn/nix/?rev=29473&sc=1
Log:
opencv-2.3.1a
* pkgconfig and cmake are buildNativeInputs
* drop xineLib dependency. It was not used anyway.
Modified:
nixpkgs/trunk/pkgs/development/libraries/opencv/default.nix
Modified: nixpkgs/trunk/pkgs/development/libraries/opencv/default.nix
==
--- nixpkgs/trunk/pkgs/development/libraries/opencv/default.nix Sat Sep 24
13:30:31 2011(r29472)
+++ nixpkgs/trunk/pkgs/development/libraries/opencv/default.nix Sat Sep 24
20:40:58 2011(r29473)
@@ -1,16 +1,19 @@
-{ stdenv, fetchurl, cmake, gtk, glib, libjpeg, libpng, libtiff, jasper,
ffmpeg, pkgconfig,
- xineLib, gstreamer }:
+{ stdenv, fetchurl, cmake, gtk, libjpeg, libpng, libtiff, jasper, ffmpeg
+, pkgconfig, gstreamer }:
+
+let v = "2.3.1a"; in
stdenv.mkDerivation rec {
- name = "opencv-2.3.0";
+ name = "opencv-${v}";
src = fetchurl {
-url = "mirror://sourceforge/opencvlibrary/OpenCV-2.3.0.tar.bz2";
-sha256 = "02wl56a87if84brrhd4wq59linyhbxx30ykh4cjwzw37yw7zzgxw";
+url = "mirror://sourceforge/opencvlibrary/OpenCV-${v}.tar.bz2";
+sha256 = "0325s7pa2npcw2gc06pr6q5ik4xdyf08rvkfc0myn10w20lzb8m9";
};
- buildInputs = [ cmake gtk glib libjpeg libpng libtiff jasper ffmpeg pkgconfig
-xineLib gstreamer ];
+ buildInputs = [ gtk libjpeg libpng libtiff jasper ffmpeg gstreamer ];
+
+ buildNativeInputs = [ cmake pkgconfig ];
enableParallelBuilding = true;
___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits
nix-dev@lists.science.uu.nl
Hi! It seems that distributing some packages via hydra violates their licenses (e.g., if we distribute a package linked both to gpl and non-gpl-compatible libraries). Gentoo has 'bindist' use flag to mark whether the binary packages will be distributed in binary form. What about introducing some variable (say, nixpkgs.config.isBuildfarm) to mark that the result of the build is available to download? Then packages can assert !isBuildfarm; In the ideal world we should have some license manager that automatically calculates the license of each package but it does not seem trivial to implement... -- Yury G. Kudryashov, mailto: ur...@mccme.ru ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] nix store: hardlink vs symlink (was Re: python application vs python environment)
Hi Florian, Florian Friesdorf skribis: > Why is nix using symlinks to link files in the nix store? Because hard links don’t work across devices. Ludo’. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] nix store: hardlink vs symlink
Hi Florian, > If ./bin/python is a symlink, python will resolve it to find its home > and set sys.prefix accordingly. it seems to me like Python is behaving perfectly reasonable. The prefix of Python is at /nix/store/vzpvrymynp4n93bznxha6hadj0ww68vx-python-2.7.1. The other paths, /tmp/cfl/bad or /tmp/cfl/good1, are not its prefix. Why would you want Python to believe that its prefix would be at one of those paths? Take care, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] nix store: hardlink vs symlink
On Sat, 24 Sep 2011 17:15:08 +0200, Peter Simons wrote: > Hi Florian, > > > If ./bin/python is a symlink, python will resolve it to find its home > > and set sys.prefix accordingly. > > it seems to me like Python is behaving perfectly reasonable. The prefix of > Python is at /nix/store/vzpvrymynp4n93bznxha6hadj0ww68vx-python-2.7.1. The > other paths, /tmp/cfl/bad or /tmp/cfl/good1, are not its prefix. > > Why would you want Python to believe that its prefix would be at one of those > paths? The prefix determines where python searches for site-packages. I currently see two ways python is called: Python applications with an isolated environment They call python as: /nix/store/vzpvrymynp4n93bznxha6hadj0ww68vx-python-2.7.1/bin/python the prefix is: /nix/store/vzpvrymynp4n93bznxha6hadj0ww68vx-python-2.7.1 and python will load its empty site-packages in there. Modules needed by the application are made available via PYTHONPATH. Python development ~~ You currently can install python modules into a profile, together with a python interpreter (of the same python version) they can build a python environment. Not meant for running applications, but for example development. For this environment to function properly python needs to treat the profile as its home. virtualenv for example currently breaks because of modules coming from different prefixes. If I install ipdb and ipython into a profile, I'd expect them to see all modules I added to the profile. -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpP9xZBaHkK9.pgp 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] nix store: hardlink vs symlink
On Sat, 24 Sep 2011 08:03:03 -0700, s...@shealevy.com wrote:
> It seems like the problem here is with Python, not nix. Isn't there a way
> to set some env var or command line flag to set sys.prefix manually? Then
> you can create a wrapper script to call the "real" Python with the right
> value.
Setting PYTHONHOME overrides the prefix, pythonhomeWrapper (WIP) does
that.
Having:
pyhome = pkgs.buildEnv {
name = "pyhome";
paths = [
pkgs.defaultStdenv
pkgs.python27
pkgs.python27Packages.simplejson
pkgs.pythonhomeWrapper
];
};
you get an environment where ./bin/py is starting a python with correct
prefix.
I'm in favor of changing the python expressions to replace all relevant
scripts (./bin/python, ./bin/pythonX.Y, maybe more) with wrapped
versions.
Are there reasons against doing so?
> Or patch Python not to follow symlinks like that.
I think we should not change that, because that's what python does and
there might be people using it. Will bring this up on python-dev.
--
Florian Friesdorf
GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083
Jabber/XMPP: f...@chaoflow.net
IRC: chaoflow on freenode,ircnet,blafasel,OFTC
pgpx3ocEO8mCz.pgp
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] nix store: hardlink vs symlink
It seems like the problem here is with Python, not nix. Isn't there a way
to set some env var or command line flag to set sys.prefix manually? Then
you can create a wrapper script to call the "real" Python with the right
value. Or patch Python not to follow symlinks like that.
> On Sat, 24 Sep 2011 16:41:07 +0200, Peter Simons wrote:
>> Hi Florian,
>>
>> > Why is nix using symlinks to link files in the nix store?
>> > Would switching to hardlinks break something?
>>
>> why do you think that hardlinks would be preferable?
>
> Two profiles:
> /tmp/cfl/bad: more than one derivation provides ./bin content,
> ./bin/python is a symlink
>
> /tmp/cfl/good1: only python provides ./bin content, ./bin/python is not
> a symlink.
>
> If ./bin/python is a symlink, python will resolve it to find its home
> and set sys.prefix accordingly. It ends with the python derivation being
> the home (bad):
> readlink("/tmp/cfl/bad/bin/python",
> "/nix/store/vzpvrymynp4n93bznxha6hadj0ww68vx-python-2.7.1/bin/python",
> 4096) = 67
> readlink("/nix/store/vzpvrymynp4n93bznxha6hadj0ww68vx-python-2.7.1/bin/python",
> 0x7fff5ec0fa60, 4096) = -1 EINVAL (Invalid argument)
>
>
> If ./bin/python is not a symlink, the profile python is installed to
> becomes the home and therefore sys.prefix (good):
> readlink("/tmp/cfl/good1/bin/python", 0x7fff013ffc10, 4096) = -1 EINVAL
> (Invalid argument)
>
>
> I think the profile should be the home in both cases.
>
> Making ./bin/python (and ./bin/pythonX.Y) a real file would solve the
> problem.
>
>> It is easy to determine where a symlink points to, but it's expensive to
>> determine that for a hardlink. That information is oftentimes relevant,
>> though, i.e. when analyzing run-time dependencies between store paths.
>
> As python links in many more files than only ./bin/python and
> ./bin/pythonX.Y, would it be ok, to not symlink these two files, but
> simply copy them or is there some other nix-conformant way to avoid the
> symlinks for these two files?
>
> --
> Florian Friesdorf
> GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083
> Jabber/XMPP: f...@chaoflow.net
> IRC: chaoflow on freenode,ircnet,blafasel,OFTC
> ___
> 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 store: hardlink vs symlink
On Sat, 24 Sep 2011 16:41:07 +0200, Peter Simons wrote:
> Hi Florian,
>
> > Why is nix using symlinks to link files in the nix store?
> > Would switching to hardlinks break something?
>
> why do you think that hardlinks would be preferable?
Two profiles:
/tmp/cfl/bad: more than one derivation provides ./bin content,
./bin/python is a symlink
/tmp/cfl/good1: only python provides ./bin content, ./bin/python is not
a symlink.
If ./bin/python is a symlink, python will resolve it to find its home
and set sys.prefix accordingly. It ends with the python derivation being
the home (bad):
readlink("/tmp/cfl/bad/bin/python",
"/nix/store/vzpvrymynp4n93bznxha6hadj0ww68vx-python-2.7.1/bin/python", 4096) =
67
readlink("/nix/store/vzpvrymynp4n93bznxha6hadj0ww68vx-python-2.7.1/bin/python",
0x7fff5ec0fa60, 4096) = -1 EINVAL (Invalid argument)
If ./bin/python is not a symlink, the profile python is installed to
becomes the home and therefore sys.prefix (good):
readlink("/tmp/cfl/good1/bin/python", 0x7fff013ffc10, 4096) = -1 EINVAL
(Invalid argument)
I think the profile should be the home in both cases.
Making ./bin/python (and ./bin/pythonX.Y) a real file would solve the
problem.
> It is easy to determine where a symlink points to, but it's expensive to
> determine that for a hardlink. That information is oftentimes relevant,
> though, i.e. when analyzing run-time dependencies between store paths.
As python links in many more files than only ./bin/python and
./bin/pythonX.Y, would it be ok, to not symlink these two files, but
simply copy them or is there some other nix-conformant way to avoid the
symlinks for these two files?
--
Florian Friesdorf
GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083
Jabber/XMPP: f...@chaoflow.net
IRC: chaoflow on freenode,ircnet,blafasel,OFTC
pgpm1wIcfdl43.pgp
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] nix store: hardlink vs symlink
Hi Florian, > Why is nix using symlinks to link files in the nix store? > Would switching to hardlinks break something? why do you think that hardlinks would be preferable? It is easy to determine where a symlink points to, but it's expensive to determine that for a hardlink. That information is oftentimes relevant, though, i.e. when analyzing run-time dependencies between store paths. Take care, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] nix store: hardlink vs symlink (was Re: python application vs python environment)
>From my understanding (which may be terribly incorrect), hard links would cause two problems during the hash-scanning phase of a nix build: 1. At least as of Eelco's thesis, we were ignoring hard links in the canonicalization of store paths. That means that after a build, any hard-linked files will no longer be linked 2. Even if we did keep track of hard links during canonicalization, it would be fairly difficult if not impossible to resolve runtime dependencies. Nix would need to find the inode of the hard link and scan all store outputs for files with that inode, and if it finds more than one it will probably have to consider them all runtime dependencies of the current output, unless there's a way to determine which file was the earliest of a set of hard links. The canonicalization of symlinks, on the other hand, contains the path pointed to so hash scanning finds the runtime dependencies fine. ~Shea > > Isolating aspects of the original mail: > > On Sat, 24 Sep 2011 14:36:20 +0200, Florian Friesdorf > wrote: >> If ./bin/python is a symlink, we have currently a problem and PYTHONHOME >> would be a solution, if python is a real file, we do not have a problem. >> >> So instead of symlinking the python executable, nix-env should be >> instructed >> to hard-link it - is this possible? > > Why is nix using symlinks to link files in the nix store? > Would switching to hardlinks break something? > > - symlinks in case of whole directories > - hardlinks for individual files > > -- > Florian Friesdorf > GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 > Jabber/XMPP: f...@chaoflow.net > IRC: chaoflow on freenode,ircnet,blafasel,OFTC > ___ > 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] fetchgit vs tarball creation, privately maintained infrastructure
I messed up Subject and Cc m( Now, with Marc's permission publicly. My original mail: > Hi Marc, > > there are currently several expressions pointing to your server > resulting in 404s. > > Why do you prefer to put sources on your private server instead of > public infrastructure? > > Maybe we can keep the benefits and still profit from assumed higher > availability of public infrastructure. > > regards > florian On Fri, 23 Sep 2011 23:19:55 +0200, Marc Weber wrote: > (..) > I haven't had time to recover. Tell me the target packages and I'll > upload everything required to build them. see the attached file > Why don't I use fetchgit etc? Cause its too slow. My internet is slow. > I need incremental updates. That's why I wrote nix-repository-manager > to serve my needs. To solve that I would rather teach fetchgit to keep a cache of its repositories, instead of creating tarballs. Many things I install via fetchgit, I anyway want to have on my laptop for development. Having one common cache from which fetchgit for nix and you for development can clone. Anyway, I think nix expressions should not depend on anybody's private infrastructure, but instead use public infrastructure. > > Why do you prefer to put sources on your private server instead of > > public infrastructure? > > Maybe we can keep the benefits and still profit from assumed higher > > availability of public infrastructure. > I'm planing to put my stuff on amazon. I can't afford huge build farms. > But being able to launch some nice CPU powered instances on Amazon will > allow to me provide binaries for my branches. I don't think its necessary that you provide your own hosting infrastructure for that. > Currently my tool supports pushing tars by SSH. It should be doable to > make it cope with any public infrastructure. Which one do you suggest? I would not like to see packages use that approach without agreement that we in nix are generating tarballs for things available via git/svn/... I think the approach of caching is more fruitful. If we agree to create tarballs instead of fetching git, there is some good reason for it and those tarballs should be hosted on nix infrastructure, i.e. making it a solution used by every package maintainer. > If you want to join tell me. A lot of my patches did never get any > review. And committing them without "ok" was no good according to ludo > either. That's why I had to fork (also because SVN is too slow for me). I'd happy to review isolated patches implementing functionality I'm interested in. mawercer.de Description: Binary data -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpXdp2Arf1CJ.pgp Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-commits] SVN commit: nix - r29472 - configurations/trunk/tud
Author: eelco
Date: Sat Sep 24 13:30:31 2011
New Revision: 29472
URL: https://ssl.nixos.org/websvn/nix/?rev=29472&sc=1
Log:
Modified:
configurations/trunk/tud/wendy.nix
Modified: configurations/trunk/tud/wendy.nix
==
--- configurations/trunk/tud/wendy.nix Sat Sep 24 12:46:24 2011(r29471)
+++ configurations/trunk/tud/wendy.nix Sat Sep 24 13:30:31 2011(r29472)
@@ -16,7 +16,7 @@
{ name = "mturk-webserver-production";
startOn = "started network-interfaces";
exec = ''
-${pkgs.su}/bin/su - mturk -c 'MTURK_STATE=/home/mturk/state-production
WEBINTERFACE_HOME=/home/mturk/icse-2012/src/WebInterface exec
/home/mturk/icse-2012/src/WebInterface/script/webinterface_server.pl >>
/home/mturk/state-production/webserver.log 2>&1'
+${pkgs.su}/bin/su - mturk -c 'MTURK_STATE=/home/mturk/state-production
WEBINTERFACE_HOME=/home/mturk/icse-2012/src/WebInterface
WEBINTERFACE_CONFIG=/home/mturk/icse-2012/src/WebInterface/webinterface-production.conf
exec /home/mturk/icse-2012/src/WebInterface/script/webinterface_server.pl >>
/home/mturk/state-production/webserver.log 2>&1'
'';
};
@@ -24,7 +24,7 @@
{ name = "mturk-webserver-sandbox";
startOn = "started network-interfaces";
exec = ''
-${pkgs.su}/bin/su - mturk -c
'WEBINTERFACE_HOME=/home/mturk/icse-2012/src/WebInterface exec
/home/mturk/icse-2012/src/WebInterface/script/webinterface_server.pl -p 3001 >>
/home/mturk/state-sandbox/webserver.log 2>&1'
+${pkgs.su}/bin/su - mturk -c
'WEBINTERFACE_HOME=/home/mturk/icse-2012/src/WebInterface
WEBINTERFACE_CONFIG=/home/mturk/icse-2012/src/WebInterface/webinterface-sandbox.conf
exec /home/mturk/icse-2012/src/WebInterface/script/webinterface_server.pl -p
3001 >> /home/mturk/state-sandbox/webserver.log 2>&1'
'';
};
___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits
Re: [Nix-dev] distutils2nix/python4nix
On Fri, 23 Sep 2011 23:12:14 +0200, Marc Weber wrote: > Excerpts from Peter Simons's message of Fri Sep 23 21:21:16 +0200 2011: > > One issue that you might want to consider is that the "pythonPackages" > > set needs to support several different versions of Python, i.e. the > > python interpreter needs to be an argument to that expression. > > Currently, we cannot build our python packages with Python 3.x, for > > example, which is really a shame. > > And that's the issue: The python packages don't say "I'm tested with > python-2.7". There are some wired automatic conversion tools. > > Before we start writing cabal2nix, perl2nix, X2nix: How should the > result look like? > There are 20.000 ruby packages! > And I personally don't like seeing more and more individual "let me > update just this package and then that cause I need it right now and I > don't know what this might break.." There is no choice unless we start > supporting constraints. > > In theory I've packaged all of those ruby packages. But do we really > want to checkout such masses of .nix files to get only 10 packages? > > Or would it be much better to query PyPi package database, cpan, .. > lazily (which would require changing nix?) I would first create all thix X2nix and Y4nix tools, once we have them we can think about whether and how to use them on-the-fly. Solving constraints would happen in those tools (maybe via a hook) and could be implemented as a generic, language independent solver (in prolog?, as Peter suggested). Or it might be feasible to use a language's own package manager to handle the resolving. But at the time a nix expression is being installed, that resolving has happened already and eg. python setup.py install is not allowed to fetch any dependencies. In any case nix knows how to handle nix expressions, so let's feed it nix expressions and use the magic to create them. > For python there is another issue: You have to run the setup.py file in > most cases to learn about package dependencies. You as a person generating nix expressions currently have to, changes towards a declarative format are ahead. > I already have written kind python 2 nix and its good enough to install > some packages on the fly but still needs much more love. > > If you want to learn about this way (which perfectly work for all ruby > versions) I'll point you to the code and explain how to use it. You were showing me all these tools, but I failed in seeing the currently relevant pieces. As said before, I am not searching an integrated new solution, but pieces to extend/adjust nix. > I personally believe that the final solution should take version > constraints into account so that you can fail early. +1 at the time of nix expression generation > How should this all look in the future (there are vim, emacs, perl, > ruby, python, eclipse, zsh, haxe, java, scala, ... ) packages to package. > And eg for scala, java it almost impossible to keep up to date using the > current manual way. I'm not sure what you mean with "current manual way". As far as I understand Peter uses cabal2nix and haskell4nix to semi-automatically maintain the haskell expressions. cabal2nix generates a nix expression and haskell4nix keeps nix haskell tree up-to-date. You run haskell4nix, check whether things look good, install something, run some tests, and check it in. Maybe Peter can explain in more detail what manual work he currently needs to do and where he sees potential for further automisation. I prefer a "manually" maintained tree over on-the-fly. Having explicit nix expressions allows for somebody/something to test these and building a database of known good sets of packages. If we generate the expressions on-the-fly, we would need a database of checksums in order to know whether the on-the-fly generated expressions are what we want them to be (as brought up by Michael). > It may be possible to tune the tools (sbt, maven, > ..) to use the nix store as cache at least.. > And I'm pretty sure that I've forgotten tons of package solutions (eg > ocaml) > > Thoughts? Are your tools providing the functionality of distutils2nix/python4nix described so far? -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpjVy91dEPD3.pgp 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] nix store: hardlink vs symlink (was Re: python application vs python environment)
> - hardlinks for individual files Isn't there a permission issue? As user you should not be allowed to change hardlinked files - but you want to delet theme (because you want to be allowed to remove ~/.nix-profile). Isn't that the reason why you need to be root to create hardlinks? You're right everything is in /nix/store thus readonly. Think about hard link limits: nix-store --optimize does already hardlink files. What happens if you run into max link count reached problems? (Don't know exactly. I think its several thausand hardlinks for each file depending on fs). So at least you should ensure that you don't run into problems here. Mlrc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] distutils2nix/python4nix
On Sat, 24 Sep 2011 10:38:41 +0400, Michael Raskin <7c6f4...@mail.ru> wrote: > >Before we start writing cabal2nix, perl2nix, X2nix: How should the > >result look like? > >There are 20.000 ruby packages! > >And I personally don't like seeing more and more individual "let me > >update just this package and then that cause I need it right now and I > >don't know what this might break.." There is no choice unless we start > >supporting constraints. > > I am afraid this would mean building a solid general-purpose > data-grinding programming language into Nix. The idea to keep Nix small > seems to be still held, and it will not help us build a constraint > solver. > > We can - as usual - trade HDD space for sanity damage. That way every > version of every package has its preference of versions of all other > packages and we sometimes try to remove obsolete versions. +1 > >In theory I've packaged all of those ruby packages. But do we really > >want to checkout such masses of .nix files to get only 10 packages? > > > >Or would it be much better to query PyPi package database, cpan, .. > >lazily (which would require changing nix?) > > Or not Nix. If you have a way to programmatically generate all these > expressions, it is a no-brainer to find/write a FUSE FS tht will simply > generate the file whenever it is needed. Default checkout will have some > packages voted essential, and everyone can mount overlay and pretend all > rubyforge is there. +1 > The real problem with that solution would be deciding on policy of > keeping checksums. Of course, I could keep checksums locally. That would > give me all local benefits of Nix (I can reproduce whatever I have ever > done - maybe I should copy checksum DB over to be sure, but that seems > acceptable, if suboptimal), but denies global checksum synchronization. > Maybe we could have some online service to use for that database. I'm in favor of checksum synchronization. But for now I would just focus on how to automatically generate nix trees for the various languages. -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgp8p61VVGFAX.pgp Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-commits] SVN commit: nix - r29471 - nixpkgs/trunk/pkgs/tools/networking/p2p/rtorrent
Author: simons
Date: Sat Sep 24 12:46:24 2011
New Revision: 29471
URL: https://ssl.nixos.org/websvn/nix/?rev=29471&sc=1
Log:
rtorrent: install man page manually (the upstream makefile is broken)
Modified:
nixpkgs/trunk/pkgs/tools/networking/p2p/rtorrent/default.nix
Modified: nixpkgs/trunk/pkgs/tools/networking/p2p/rtorrent/default.nix
==
--- nixpkgs/trunk/pkgs/tools/networking/p2p/rtorrent/default.nixSat Sep
24 09:14:21 2011(r29470)
+++ nixpkgs/trunk/pkgs/tools/networking/p2p/rtorrent/default.nixSat Sep
24 12:46:24 2011(r29471)
@@ -14,6 +14,8 @@
buildInputs = [ libtorrent ncurses pkgconfig libsigcxx curl zlib openssl ];
+ postInstall = "install -D -m 444 doc/rtorrent.1
$out/share/man/man1/rtorrent.1";
+
meta = {
homepage = "http://libtorrent.rakshasa.no/";;
description = "An ncurses client for libtorrent, ideal for use with screen
or dtach";
___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-dev] nix store: hardlink vs symlink (was Re: python application vs python environment)
Isolating aspects of the original mail: On Sat, 24 Sep 2011 14:36:20 +0200, Florian Friesdorf wrote: > If ./bin/python is a symlink, we have currently a problem and PYTHONHOME > would be a solution, if python is a real file, we do not have a problem. > > So instead of symlinking the python executable, nix-env should be instructed > to hard-link it - is this possible? Why is nix using symlinks to link files in the nix store? Would switching to hardlinks break something? - symlinks in case of whole directories - hardlinks for individual files -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpWI8UPz99Lr.pgp 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] python application vs python environment
On Fri, 23 Sep 2011 23:27:40 +0200, Marc Weber wrote: > Excerpts from Florian Friesdorf's message of Fri Sep 23 20:46:12 +0200 2011: > > By wrapping the python interpreter (see pythonhomeWrapper) and setting > > PYTHONHOME to the profile, this can be prevented and site-packages are > > correctly available. > Yes, but it won't work if you want to make configure scripts find > dependencies unless you start building up temporary PYTHONHOME's for > each build. Could you provide an example for what would not work, ie. list of shell commands to type to run into a problem. > The better solution NIX_PYTHON_SITES patch has been implemented by me > and some packages such as pygtk has been patched properly (not for 3.0 > though). Its like PYTHONHOME but supports multiple paths which requires > some packages to be patched because they want to install into that one > HOME. Where is that patch? > Eventually you should consider having a look at my work. Its not > complete, But I'm pretty sure that it has some pretty nice ideas. > For ruby I start building up environments for individual projects: > ... > The system is strong enough to not allow two versions of the same libraries to > be put into the same env. It also resolves dependencies automatically. > You can add version constraints eg force "savon == 3.2". > > Needless to say that those envs also generate tag files for you automatically. You are sketching a "system" that builds environments in contrast to simple nix profiles, which does dependency resolution and creates tag files. This sounds like interesting pieces of functionality. For me personally, it would be great to see them as isolated (mostly independent) patches/applications. I don't want to change nix, but make its tools fulfill my and other python developers needs. So, a resolver I see relevant to generate nix expressions (see other thread currently running). Generation of tag files is something for a development environment. There is the concept of a profile in nix and I feel it important to have a definition of how python behaves in such a profile. If a nix profile is not suitable to generate a working python environment, than we should have documented why not and why we do not intend to fix it and what to use otherwise. I think (for now): that - a python and its modules installed in a profile should be a working python environment, - python development tools (virtualenv, ipdb) installed into it should be using it, - its possible to have multiple python versions in one profile - python applications installed into the profile do not use the python environments of the profile but instead their own PYTHONPATH-isolated one. > > Instead we need a python that stops resolving symlinks once it reached > > its home profile (not continuing into its derivation). > > > > A solution would be, not to link python and pythonX.Y from the > > derivation, but instead to create two wrappers that set the PYTHONHOME > > and call then the python in the derivation. > I have to think about this. I won't have time within the next 8 days or so. > > > How can I influence how a derivation is merged into another derivation? > Not sure what you're referring to here. When nix merges a derivation into a profile, all its files will be linked to the profile. More specifically, if the derivation is the only provider of a directory, the directory will be linked instead of individually linking its contents. If ./bin/python is a symlink, we have currently a problem and PYTHONHOME would be a solution, if python is a real file, we do not have a problem. So instead of symlinking the python executable, nix-env should be instructed to hard-link it - is this possible? regards -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgp7lvD6lcL6b.pgp 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] distutils2nix/python4nix
FUSE ? :-) Funny idea. Maybe not that bad. Passing args would be a funny. import 'create derivation providing ruby packgaes foo=2.00, xy>8.2 .nix'; > The real problem with that solution would be deciding on policy of > keeping checksums. Of course, I could keep checksums locally. That would > give me all local benefits of Nix (I can reproduce whatever I have ever > done - maybe I should copy checksum DB over to be sure, but that seems > acceptable, if suboptimal), but denies global checksum synchronization. > Maybe we could have some online service to use for that database. You're totally right about this. The point is: We don't have man power to maintain everything. That's why I'm thinking about reusing the existing organisation of packgae database (cpan,..). But they all have a dynamic component: "Query db, fetch, be done". Thus if we could reuse the result of the querying (which could be dumped to store) we could build up derivations on the fly and eventually reuse existing solving found in existing packages solutions like cpan, ruby, scala, java, el-get, .. However it would also generate tons of issues: - you don't know the graph of derivations to be build in advance - could cause loops (creating derivations forever if not limited) - hash mess (you've already mentioned) - you need --refresh flag or such because its you deciding on getting fresh dump from pypi,cpan,... - you start trusting foreign sources (those package databases) But at least this would allow us to make eclipse package plugins as nix derivations, same for vim, emacs, cpan, .. It would be a mess, I agree. But better than what we have now? I can imagine some setup.py scripts changing list of dependencies dynamically depending on what has been installed (probably a bad habit, but doable) > Try installing, catch dependency problems, install dependencies, > retry installing. > Will work better for Python than for Common Lisp, because there > is only one setup.py per package. Exactly - don't know about Common Lisp. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-commits] SVN commit: nix - r29469 - nixpkgs/branches/stdenv-updates/pkgs/shells/bash
Author: simons
Date: Sat Sep 24 08:06:47 2011
New Revision: 29469
URL: https://ssl.nixos.org/websvn/nix/?rev=29469&sc=1
Log:
pkgs/shells/bash/default.nix: don't install bash completion in non-interactive
mode
This patch removes the kludge introduced in trunk to avoid a stdenv rebuild.
Modified:
nixpkgs/branches/stdenv-updates/pkgs/shells/bash/default.nix
Modified: nixpkgs/branches/stdenv-updates/pkgs/shells/bash/default.nix
==
--- nixpkgs/branches/stdenv-updates/pkgs/shells/bash/default.nixSat Sep
24 08:04:47 2011(r29468)
+++ nixpkgs/branches/stdenv-updates/pkgs/shells/bash/default.nixSat Sep
24 08:06:47 2011(r29469)
@@ -51,15 +51,7 @@
postInstall = ''
# Add an `sh' -> `bash' symlink.
ln -s bash "$out/bin/sh"
-
- '' + (if interactive then "" else ''
-# Install the completion examples.
-ensureDir "$out/etc"
-cp -v "examples/complete/bash_completion" "$out/etc"
-
-ensureDir "$out/etc/bash_completion.d"
-cp -v "examples/complete/complete.gnu-longopt" "$out/etc/bash_completion.d"
- '');
+ '';
meta = {
homepage = http://www.gnu.org/software/bash/;
___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] SVN commit: nix - r29468 - in nixpkgs/branches/stdenv-updates: . pkgs/applications/graphics/xscreensaver pkgs/applications/misc/xneur pkgs/applications/networking/browsers/icecat-4 pkgs/
Author: simons Date: Sat Sep 24 08:04:47 2011 New Revision: 29468 URL: https://ssl.nixos.org/websvn/nix/?rev=29468&sc=1 Log: sync with trunk Added: nixpkgs/branches/stdenv-updates/pkgs/development/interpreters/python/pythonhome-wrapper.nix - copied unchanged from r29467, nixpkgs/trunk/pkgs/development/interpreters/python/pythonhome-wrapper.nix nixpkgs/branches/stdenv-updates/pkgs/development/libraries/haskell/derp/ - copied from r29467, nixpkgs/trunk/pkgs/development/libraries/haskell/derp/ Replaced: nixpkgs/branches/stdenv-updates/pkgs/development/libraries/haskell/derp/default.nix - copied unchanged from r29467, nixpkgs/trunk/pkgs/development/libraries/haskell/derp/default.nix Modified: nixpkgs/branches/stdenv-updates/ (props changed) nixpkgs/branches/stdenv-updates/pkgs/applications/graphics/xscreensaver/default.nix (props changed) nixpkgs/branches/stdenv-updates/pkgs/applications/misc/xneur/0.8.nix (props changed) nixpkgs/branches/stdenv-updates/pkgs/applications/networking/browsers/icecat-4/ (props changed) nixpkgs/branches/stdenv-updates/pkgs/applications/networking/browsers/mozilla-plugins/flashplayer-10/ (props changed) nixpkgs/branches/stdenv-updates/pkgs/build-support/gcc-wrapper/ (props changed) nixpkgs/branches/stdenv-updates/pkgs/build-support/release/debian-build.nix (props changed) nixpkgs/branches/stdenv-updates/pkgs/build-support/release/nix-build.nix (props changed) nixpkgs/branches/stdenv-updates/pkgs/build-support/release/rpm-build.nix (props changed) nixpkgs/branches/stdenv-updates/pkgs/build-support/release/source-tarball.nix (props changed) nixpkgs/branches/stdenv-updates/pkgs/desktops/kde-4.5/support/shared-desktop-ontologies/ (props changed) nixpkgs/branches/stdenv-updates/pkgs/development/compilers/ghc/6.10.1.nix (props changed) nixpkgs/branches/stdenv-updates/pkgs/development/compilers/ghc/6.10.2.nix (props changed) nixpkgs/branches/stdenv-updates/pkgs/development/compilers/ghc/6.8.2.nix (props changed) nixpkgs/branches/stdenv-updates/pkgs/development/compilers/ghc/6.8.3.nix (props changed) nixpkgs/branches/stdenv-updates/pkgs/development/libraries/aterm/2.8.nix (props changed) nixpkgs/branches/stdenv-updates/pkgs/development/libraries/fltk/fltk11.nix (props changed) nixpkgs/branches/stdenv-updates/pkgs/development/libraries/glibc-2.9/ (props changed) nixpkgs/branches/stdenv-updates/pkgs/development/libraries/goocanvas/ (props changed) nixpkgs/branches/stdenv-updates/pkgs/development/libraries/haskell/NumInstances/default.nix nixpkgs/branches/stdenv-updates/pkgs/development/libraries/pcre/default.nix (props changed) nixpkgs/branches/stdenv-updates/pkgs/development/libraries/readline/readline6.nix (props changed) nixpkgs/branches/stdenv-updates/pkgs/development/tools/haskell/uuagc/cabal.nix nixpkgs/branches/stdenv-updates/pkgs/development/tools/misc/autoconf/2.13.nix (props changed) nixpkgs/branches/stdenv-updates/pkgs/development/tools/misc/gnum4/default.nix (props changed) nixpkgs/branches/stdenv-updates/pkgs/misc/tex/pgf/1.x.nix (props changed) nixpkgs/branches/stdenv-updates/pkgs/misc/tex/pgf/2.x.nix (props changed) nixpkgs/branches/stdenv-updates/pkgs/os-specific/linux/atheros/r3867.nix (props changed) nixpkgs/branches/stdenv-updates/pkgs/os-specific/linux/kernel-headers/2.6.28.nix (props changed) nixpkgs/branches/stdenv-updates/pkgs/os-specific/linux/kernel-headers/2.6.32.nix (props changed) nixpkgs/branches/stdenv-updates/pkgs/os-specific/linux/kernel/generic.nix (props changed) nixpkgs/branches/stdenv-updates/pkgs/os-specific/linux/kernel/linux-2.6.25.nix (props changed) nixpkgs/branches/stdenv-updates/pkgs/os-specific/linux/kernel/linux-2.6.27.nix (props changed) nixpkgs/branches/stdenv-updates/pkgs/os-specific/linux/kernel/linux-2.6.28.nix (props changed) nixpkgs/branches/stdenv-updates/pkgs/os-specific/linux/kernel/linux-2.6.29.nix (props changed) nixpkgs/branches/stdenv-updates/pkgs/os-specific/linux/kernel/linux-2.6.32-xen.nix (props changed) nixpkgs/branches/stdenv-updates/pkgs/os-specific/linux/kernel/linux-2.6.32.nix (props changed) nixpkgs/branches/stdenv-updates/pkgs/os-specific/linux/kernel/linux-2.6.33.nix (props changed) nixpkgs/branches/stdenv-updates/pkgs/os-specific/linux/kernel/linux-3.1.nix nixpkgs/branches/stdenv-updates/pkgs/os-specific/linux/kqemu/1.4.0pre1.nix (props changed) nixpkgs/branches/stdenv-updates/pkgs/os-specific/linux/qemu-kvm/default.nix (props changed) nixpkgs/branches/stdenv-updates/pkgs/os-specific/linux/util-linux-ng/ (props changed) nixpkgs/branches/stdenv-updates/pkgs/servers/mail/dovecot/1.1.1.nix (props changed) nixpkgs/branches/stdenv-updates/pkgs/shells/bash/default.nix (contents, props changed) nixpkgs/branches/stdenv-updates
[Nix-commits] SVN commit: nix - r29467 - nixpkgs/trunk/pkgs/shells/bash
Author: simons
Date: Sat Sep 24 07:58:19 2011
New Revision: 29467
URL: https://ssl.nixos.org/websvn/nix/?rev=29467&sc=1
Log:
pkgs/shells/bash/default.nix: revert my earlier revision 29244
Including the bash-completion package in bash itself sounded like a good idea
at the time, but it wasn't. After having actually integrated completion support
into NixOS, it has become obvious that this property isn't required at all.
Keeping bash-completion separate from bash works just fine. Anyone who wants
completion support can just install that package.
Modified:
nixpkgs/trunk/pkgs/shells/bash/default.nix
Modified: nixpkgs/trunk/pkgs/shells/bash/default.nix
==
--- nixpkgs/trunk/pkgs/shells/bash/default.nix Sat Sep 24 07:27:07 2011
(r29466)
+++ nixpkgs/trunk/pkgs/shells/bash/default.nix Sat Sep 24 07:58:19 2011
(r29467)
@@ -1,4 +1,4 @@
-{stdenv, fetchurl, readline ? null, interactive ? false, texinfo ? null,
bison, bashCompletion ? null}:
+{ stdenv, fetchurl, readline ? null, interactive ? false, texinfo ? null,
bison }:
assert interactive -> readline != null;
@@ -52,10 +52,7 @@
# Add an `sh' -> `bash' symlink.
ln -s bash "$out/bin/sh"
- '' + (if interactive && bashCompletion != null then ''
-ensureDir "$out/etc"
-echo >"$out/etc/bash_completion" '.
"${bashCompletion}/etc/bash_completion"'
- '' else ''
+ '' + (if interactive then "" else ''
# Install the completion examples.
ensureDir "$out/etc"
cp -v "examples/complete/bash_completion" "$out/etc"
___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] SVN commit: nix - r29466 - nixpkgs/trunk/pkgs/development/tools/haskell/uuagc
Author: simons
Date: Sat Sep 24 07:27:07 2011
New Revision: 29466
URL: https://ssl.nixos.org/websvn/nix/?rev=29466&sc=1
Log:
haskell-uuagc-cabal: updated to version 1.0.0.7
Modified:
nixpkgs/trunk/pkgs/development/tools/haskell/uuagc/cabal.nix
Modified: nixpkgs/trunk/pkgs/development/tools/haskell/uuagc/cabal.nix
==
--- nixpkgs/trunk/pkgs/development/tools/haskell/uuagc/cabal.nixSat Sep
24 02:49:04 2011(r29465)
+++ nixpkgs/trunk/pkgs/development/tools/haskell/uuagc/cabal.nixSat Sep
24 07:27:07 2011(r29466)
@@ -2,8 +2,8 @@
cabal.mkDerivation (self: {
pname = "uuagc-cabal";
- version = "1.0.0.6";
- sha256 = "1ij84n2pjhqyz10vsa9qxk4k227wg1c96rq5sylvcwdkzciww81d";
+ version = "1.0.0.7";
+ sha256 = "1ciypx0rrisjbwx8fc9bzkkv975646951ibqpvbxipxzvv5npy9y";
buildDepends = [ mtl uulib ];
meta = {
homepage = "http://www.cs.uu.nl/wiki/HUT/WebHome";;
___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits
