[Nix-commits] SVN commit: nix - r28915 - in nixpkgs/trunk/pkgs: servers/squid tools/networking/tftp-hpa top-level

2011-08-30 Thread Michael Raskin 
Author: raskin
Date: Tue Aug 30 07:02:01 2011
New Revision: 28915
URL: https://svn.nixos.org/websvn/nix/?rev=28915&sc=1

Log:
Adding TFTP-HPA

Added:
   nixpkgs/trunk/pkgs/tools/networking/tftp-hpa/
   nixpkgs/trunk/pkgs/tools/networking/tftp-hpa/default.nix
Modified:
   nixpkgs/trunk/pkgs/servers/squid/squids.nix
   nixpkgs/trunk/pkgs/top-level/all-packages.nix

Modified: nixpkgs/trunk/pkgs/servers/squid/squids.nix
==
--- nixpkgs/trunk/pkgs/servers/squid/squids.nix Tue Aug 30 05:51:49 2011
(r28914)
+++ nixpkgs/trunk/pkgs/servers/squid/squids.nix Tue Aug 30 07:02:01 2011
(r28915)
@@ -2,13 +2,13 @@
 let edf = composableDerivation.edf; in
 rec {
   squid30 = composableDerivation.composableDerivation {} {
-name = "squid-3.0-stable5";
+name = "squid-3.0-stable26";
 
 buildInputs = [perl];
 
 src = args.fetchurl {
-  url = 
http://www.squid-cache.org/Versions/v3/3.0/squid-3.0.STABLE5.tar.bz2;
-  sha256 = "1m4ccpjw30q9vwsycmgg9dmhly0mpznvxrch6f7dxgfzpjp26l7w";
+  url = 
http://www.squid-cache.org/Versions/v3/3.0/squid-3.0.STABLE26.tar.bz2;
+  sha256 = 
"3e54ae3ad09870203862f0856c7d0cca16a85f62d5012085009003ee3d5467b4";
 };
 
 configureFlags = ["--enable-ipv6"];
@@ -21,22 +21,25 @@
 
   };
 
-  squid3Beta = squid30.merge {
-name = "squid-3.1-beta";
+  squid31 = squid30.merge {
+name = "squid-3.1.15";
 src = args.fetchurl {
-  url = http://www.squid-cache.org/Versions/v3/3.1/squid-3.1.0.16.tar.bz2;
-  sha256 = "0pjz8dj04146hgdlfh0hbwdsdahsicdkafj5z9nkghbjavj1x5ny";
+  url = http://www.squid-cache.org/Versions/v3/3.1/squid-3.1.15.tar.bz2;
+  sha256 = 
"1300f44dd4783697bacc262a7a9b32dbc9f550367fe82b70262864fdff715a35";
 };
 configureFlags = ["--enable-ipv6"];
   };
 
-  squid3Head = squid3Beta.merge {
-name = "squid-3.1-HEAD";
+  squid32Beta = squid30.merge {
+name = "squid-3.2.0.11";
 src = args.fetchurl {
-  url = 
http://www.squid-cache.org/Versions/v3/3.1/squid-3.1.0.3-20081221.tar.bz2;
-  md5 = "345b50251dcc369e1be992d0a4a4c801";
+  url = http://www.squid-cache.org/Versions/v3/3.2/squid-3.2.0.11.tar.bz2;
+  sha256 = 
"aa5b9a85e1a90c4adb591c3e796c3fdfb166d8d2c814165d70692636321f69ae";
 };
+configureFlags = ["--enable-ipv6"];
+buildInputs = [openldap pam db4 cyrus_sasl libcap expat libxml2
+  libtool openssl];
   };
 
-  latest = squid3Beta;
+  latest = squid32Beta;
 }

Added: nixpkgs/trunk/pkgs/tools/networking/tftp-hpa/default.nix
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ nixpkgs/trunk/pkgs/tools/networking/tftp-hpa/default.nixTue Aug 30 
07:02:01 2011(r28915)
@@ -0,0 +1,48 @@
+x@{builderDefsPackage
+  , tcp_wrappers
+  , ...}:
+builderDefsPackage
+(a :  
+let 
+  helperArgNames = ["stdenv" "fetchurl" "builderDefsPackage"] ++ 
+[];
+
+  buildInputs = map (n: builtins.getAttr n x)
+(builtins.attrNames (builtins.removeAttrs x helperArgNames));
+  sourceInfo = rec {
+baseName="tftp-hpa";
+version="5.1";
+name="${baseName}-${version}";
+url="mirror://kernel/software/network/tftp/${name}.tar.bz2";
+hash="0k72s0c7wm4fyb6lqfypdkcy6rimanr49slimx8p0di69w394gzx";
+  };
+in
+rec {
+  src = a.fetchurl {
+url = sourceInfo.url;
+sha256 = sourceInfo.hash;
+  };
+
+  inherit (sourceInfo) name version;
+  inherit buildInputs;
+
+  /* doConfigure should be removed if not needed */
+  phaseNames = ["doConfigure" "doMakeInstall"];
+  
+  meta = {
+description = "TFTP tools - a lot of fixes on top of BSD TFTP";
+maintainers = with a.lib.maintainers;
+[
+  raskin
+];
+platforms = with a.lib.platforms;
+  linux;
+license = a.lib.licenses.bsd3;
+  };
+  passthru = {
+updateInfo = {
+  downloadPage = "http://www.kernel.org/pub/software/network/tftp/";;
+};
+  };
+}) x
+

Modified: nixpkgs/trunk/pkgs/top-level/all-packages.nix
==
--- nixpkgs/trunk/pkgs/top-level/all-packages.nix   Tue Aug 30 05:51:49 
2011(r28914)
+++ nixpkgs/trunk/pkgs/top-level/all-packages.nix   Tue Aug 30 07:02:01 
2011(r28915)
@@ -1422,6 +1422,8 @@
 
   htmlTidy = callPackage ../tools/text/html-tidy { };
 
+  tftp_hpa = callPackage ../tools/networking/tftp-hpa {};
+
   tigervnc = callPackage ../tools/admin/tigervnc {
 fontDirectories = [ xorg.fontadobe75dpi xorg.fontmiscmisc 
xorg.fontcursormisc
   xorg.fontbhlucidatypewriter75dpi ];
@@ -1566,6 +1568,8 @@
 
   xsel = callPackage ../tools/misc/xsel { };
 
+  xtreemfs = callPackage ../tools/filesystems/xtreemfs {};
+
   zdelta = callPackage ../tools/compression/zdelta { };
 
   zile = callPackage ../applications/editors/zile { };
@@ -4920,9 +4924,11 @@
   sipwitch = callPackage ../servers/sip/sipwitch

[Nix-commits] SVN commit: nix - r28916 - in hydra-config/gnu/trunk: mpc mpfr

2011-08-30 Thread Ludovic Courtès 
Author: ludo
Date: Tue Aug 30 08:16:37 2011
New Revision: 28916
URL: https://svn.nixos.org/websvn/nix/?rev=28916&sc=1

Log:
MPC/MPFR: Define $GMP_CHECK_RANDOMIZE for tests.

Modified:
   hydra-config/gnu/trunk/mpc/release.nix
   hydra-config/gnu/trunk/mpfr/release.nix

Modified: hydra-config/gnu/trunk/mpc/release.nix
==
--- hydra-config/gnu/trunk/mpc/release.nix  Tue Aug 30 07:02:01 2011
(r28915)
+++ hydra-config/gnu/trunk/mpc/release.nix  Tue Aug 30 08:16:37 2011
(r28916)
@@ -41,6 +41,8 @@
 "Andreas Enge "
   ];
   };
+
+  preCheck = "export GMP_CHECK_RANDOMIZE=true";
 in
   import ../gnu-jobs.nix {
 name = "mpc";
@@ -64,8 +66,9 @@
 [ "--enable-static" "--disable-shared" ];
 
 buildInputs = [ gmp mpfr ];
+inherit preCheck;
   };
-  coverage = pkgs: { buildInputs = [ gmp mpfr ]; };
+  coverage = pkgs: { buildInputs = [ gmp mpfr ]; inherit preCheck; };
   xbuild_gnu = pkgs: { buildInputs = [ gmp_xgnu mpfr_xgnu ]; };
 };
   }

Modified: hydra-config/gnu/trunk/mpfr/release.nix
==
--- hydra-config/gnu/trunk/mpfr/release.nix Tue Aug 30 07:02:01 2011
(r28915)
+++ hydra-config/gnu/trunk/mpfr/release.nix Tue Aug 30 08:16:37 2011
(r28916)
@@ -41,6 +41,8 @@
  [ "Paul Zimmermann " ];
   };
 
+  preCheck = "export GMP_CHECK_RANDOMIZE=true";
+
   # The minimum required GMP version.
   old_gmp = pkgs:
 import ../gmp/4.3.2.nix {
@@ -64,8 +66,8 @@
   patches = [ ./ck-version-info.patch ];
 };
 
-build = pkgs: { buildInputs = [ gmp ]; };
-coverage = pkgs: { buildInputs = [ gmp ]; };
+build = pkgs: { buildInputs = [ gmp ]; inherit preCheck; };
+coverage = pkgs: { buildInputs = [ gmp ]; inherit preCheck; };
 xbuild_gnu = pkgs: { buildInputs = [ gmp_xgnu ]; };
   };
 };
@@ -89,5 +91,6 @@
   src = tarball;
   buildInputs = [ (old_gmp pkgs) ];
   inherit (build) name meta succeedOnFailure keepBuildDirectory;
+  inherit preCheck;
 });
}
___
nix-commits mailing list
nix-comm...@cs.uu.nl
http://mail.cs.uu.nl/mailman/listinfo/nix-commits

Re: [Nix-dev] Re: What about introducing security.packages?

2011-08-30 Thread Evgeny Egorochkin 
On Saturday 20 August 2011 19:10:59 Marc Weber wrote:
> Hi Yury,
> 
> > > What exactly are you trying to do?
> > 
> > My goal is to avoid the situation when someone adds a package to
> > dbus.packages but not to udev.packages.
> 
> Probably you're right that in most cases the defaults shipping with
> packages get the job done (much more likely than omitting those rules).
> 
> first)
>   What about
> 
>   pkg = mkDerivation {
> 
> meta.provides = { # using attrs if there is ever need for some
>   # configuration you can add it easily. Also
>   # patching attrs is easier than adding/dropping
>   # items from lists?
>   udevrules = true;
>   dbussetup = true;
> }
>   }
> 
>   Then overwriting those setting is even easier.
> 
>   Then we could introduce udev.packagesAutoAdd = true which picks
>   packages from environment.systemPackages automatically based on the
>   provides attr setting and it would be "opt-in" which some people will
>   prefer.

Looks great to me. Alows both auto mode like regular distros do, and an easy 
to manage whitelist/blacklist for the control freaks among us.

-- 
Evgeny
___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] We are on Hackage

2011-08-30 Thread Peter Simons 
Hi guys,

the Hackage site shows for every package which versions of that
package are available in which distribution, and NixOS is now part
of the distributions that are being tracked. For example:

  http://hackage.haskell.org/package/pandoc

Take care,
Peter

___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev

[Nix-commits] SVN commit: nix - r28917 - in nixpkgs/trunk/pkgs: development/libraries/haskell/HaXml top-level

2011-08-30 Thread Peter Simons 
Author: simons
Date: Tue Aug 30 08:55:14 2011
New Revision: 28917
URL: https://svn.nixos.org/websvn/nix/?rev=28917&sc=1

Log:
Dropped obsolete versions of haskell-HaXml.

Added:
   nixpkgs/trunk/pkgs/development/libraries/haskell/HaXml/default.nix
  - copied, changed from r28915, 
nixpkgs/trunk/pkgs/development/libraries/haskell/HaXml/1.22.5.nix
Deleted:
   nixpkgs/trunk/pkgs/development/libraries/haskell/HaXml/1.13.3.nix
   nixpkgs/trunk/pkgs/development/libraries/haskell/HaXml/1.20.2.nix
   nixpkgs/trunk/pkgs/development/libraries/haskell/HaXml/1.22.3.nix
   nixpkgs/trunk/pkgs/development/libraries/haskell/HaXml/1.22.5.nix
Modified:
   nixpkgs/trunk/pkgs/top-level/haskell-packages.nix

Copied and modified: 
nixpkgs/trunk/pkgs/development/libraries/haskell/HaXml/default.nix (from 
r28915, nixpkgs/trunk/pkgs/development/libraries/haskell/HaXml/1.22.5.nix)
==

Modified: nixpkgs/trunk/pkgs/top-level/haskell-packages.nix
==
--- nixpkgs/trunk/pkgs/top-level/haskell-packages.nix   Tue Aug 30 08:16:37 
2011(r28916)
+++ nixpkgs/trunk/pkgs/top-level/haskell-packages.nix   Tue Aug 30 08:55:14 
2011(r28917)
@@ -693,18 +693,11 @@
 
   hackageDb = callPackage ../development/libraries/haskell/hackage-db {};
 
-  haxr = callPackage ../development/libraries/haskell/haxr {
-HaXml = self.HaXml_1_22_5;
-  };
+  haxr = callPackage ../development/libraries/haskell/haxr {};
+
   haxr_th = callPackage ../development/libraries/haskell/haxr-th {};
 
-  HaXml_1_13_3 = callPackage ../development/libraries/haskell/HaXml/1.13.3.nix 
{};
-  HaXml_1_20_2 = callPackage ../development/libraries/haskell/HaXml/1.20.2.nix 
{};
-  HaXml_1_22_5 = callPackage ../development/libraries/haskell/HaXml/1.22.5.nix 
{};
-  HaXml113 = self.HaXml_1_13_3;
-  HaXml120 = self.HaXml_1_20_2;
-  HaXml122 = self.HaXml_1_22_5;
-  HaXml= self.HaXml120;
+  HaXml = callPackage ../development/libraries/haskell/HaXml {};
 
   HDBC = callPackage ../development/libraries/haskell/HDBC/HDBC.nix {};
 
___
nix-commits mailing list
nix-comm...@cs.uu.nl
http://mail.cs.uu.nl/mailman/listinfo/nix-commits

Re: [Nix-dev] We are on Hackage

2011-08-30 Thread Eelco Dolstra 

Hi,

On 08/30/2011 10:44 AM, Peter Simons wrote:


the Hackage site shows for every package which versions of that
package are available in which distribution, and NixOS is now part
of the distributions that are being tracked. For example:

   http://hackage.haskell.org/package/pandoc


Nice :-)

--
Eelco Dolstra | http://www.st.ewi.tudelft.nl/~dolstra/
___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev

[Nix-commits] SVN commit: nix - r28918 - nixpkgs/trunk/pkgs/development/libraries/haskell/SHA

2011-08-30 Thread Peter Simons 
Author: simons
Date: Tue Aug 30 09:17:22 2011
New Revision: 28918
URL: https://svn.nixos.org/websvn/nix/?rev=28918&sc=1

Log:
haskell-SHA: updated to version 1.5.0.0

Modified:
   nixpkgs/trunk/pkgs/development/libraries/haskell/SHA/default.nix

Modified: nixpkgs/trunk/pkgs/development/libraries/haskell/SHA/default.nix
==
--- nixpkgs/trunk/pkgs/development/libraries/haskell/SHA/default.nixTue Aug 
30 08:55:14 2011(r28917)
+++ nixpkgs/trunk/pkgs/development/libraries/haskell/SHA/default.nixTue Aug 
30 09:17:22 2011(r28918)
@@ -2,8 +2,8 @@
 
 cabal.mkDerivation (self: {
   pname = "SHA";
-  version = "1.4.1.3";
-  sha256 = "1sx68mvzb2y3dq9hk769fzp8vw4jf4hk5v45i0a9a8b31imlicf0";
+  version = "1.5.0.0";
+  sha256 = "12sz1dblmpiy8bg45fwndp1g9gf7494vqqbvbd1hwr5qzyfwyqck";
   isLibrary = true;
   isExecutable = true;
   buildDepends = [ binary ];
___
nix-commits mailing list
nix-comm...@cs.uu.nl
http://mail.cs.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] SVN commit: nix - r28919 - nixpkgs/trunk/pkgs/development/libraries/haskell/largeword

2011-08-30 Thread Peter Simons 
Author: simons
Date: Tue Aug 30 09:17:26 2011
New Revision: 28919
URL: https://svn.nixos.org/websvn/nix/?rev=28919&sc=1

Log:
haskell-largeword: updated to version 1.0.1

Modified:
   nixpkgs/trunk/pkgs/development/libraries/haskell/largeword/default.nix

Modified: nixpkgs/trunk/pkgs/development/libraries/haskell/largeword/default.nix
==
--- nixpkgs/trunk/pkgs/development/libraries/haskell/largeword/default.nix  
Tue Aug 30 09:17:22 2011(r28918)
+++ nixpkgs/trunk/pkgs/development/libraries/haskell/largeword/default.nix  
Tue Aug 30 09:17:26 2011(r28919)
@@ -2,8 +2,8 @@
 
 cabal.mkDerivation (self: {
   pname = "largeword";
-  version = "1.0.0";
-  sha256 = "1122isizlx807zv26j0sx71iw39nn3sja6mr2pf4sd456m1vmx8r";
+  version = "1.0.1";
+  sha256 = "0kkkck220wap3ad2k6461ylhshiqbizv0qh35i2325fhqx892gyr";
   meta = {
 homepage = "http://trac.haskell.org/largeword/wiki";;
 description = "Provides Word128, Word192 and Word256 and a way of 
producing other large words if required";
___
nix-commits mailing list
nix-comm...@cs.uu.nl
http://mail.cs.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] SVN commit: nix - r28920 - nixpkgs/trunk/pkgs/development/libraries/haskell/pool

2011-08-30 Thread Peter Simons 
Author: simons
Date: Tue Aug 30 09:17:30 2011
New Revision: 28920
URL: https://svn.nixos.org/websvn/nix/?rev=28920&sc=1

Log:
haskell-pool: updated to version 0.1.1

Modified:
   nixpkgs/trunk/pkgs/development/libraries/haskell/pool/default.nix

Modified: nixpkgs/trunk/pkgs/development/libraries/haskell/pool/default.nix
==
--- nixpkgs/trunk/pkgs/development/libraries/haskell/pool/default.nix   Tue Aug 
30 09:17:26 2011(r28919)
+++ nixpkgs/trunk/pkgs/development/libraries/haskell/pool/default.nix   Tue Aug 
30 09:17:30 2011(r28920)
@@ -2,11 +2,11 @@
 
 cabal.mkDerivation (self: {
   pname = "pool";
-  version = "0.1.0.4";
-  sha256 = "11jsls81njkwhn48xdyrqydhr4yz82g7a6pji80ckplkdyycgx6p";
+  version = "0.1.1";
+  sha256 = "0h498pi7048m4cida10s28dp9f8c2ig3m4s9chwrfw3yiyai926l";
   buildDepends = [ monadControl transformers ];
   meta = {
-homepage = "http://github.com/snoyberg/pool";;
+homepage = "http://www.yesodweb.com/book/persistent";;
 description = "Thread-safe resource pools";
 license = self.stdenv.lib.licenses.bsd3;
 platforms = self.ghc.meta.platforms;
___
nix-commits mailing list
nix-comm...@cs.uu.nl
http://mail.cs.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] SVN commit: nix - r28921 - nixpkgs/trunk/pkgs/development/libraries/haskell/random-fu

2011-08-30 Thread Peter Simons 
Author: simons
Date: Tue Aug 30 09:17:34 2011
New Revision: 28921
URL: https://svn.nixos.org/websvn/nix/?rev=28921&sc=1

Log:
haskell-random-fu: updated to version 0.2.1.0

Modified:
   nixpkgs/trunk/pkgs/development/libraries/haskell/random-fu/default.nix

Modified: nixpkgs/trunk/pkgs/development/libraries/haskell/random-fu/default.nix
==
--- nixpkgs/trunk/pkgs/development/libraries/haskell/random-fu/default.nix  
Tue Aug 30 09:17:30 2011(r28920)
+++ nixpkgs/trunk/pkgs/development/libraries/haskell/random-fu/default.nix  
Tue Aug 30 09:17:34 2011(r28921)
@@ -4,8 +4,8 @@
 
 cabal.mkDerivation (self: {
   pname = "random-fu";
-  version = "0.2";
-  sha256 = "1w5bqhhh07xr377whgfbzn57p77j8ng5nmy2rx8qnqyw8smlkxzm";
+  version = "0.2.1.0";
+  sha256 = "0jm91xjrlzj25f3giiv2ka5r8bn1ircj56d5lpqixi7c7r9dc804";
   buildDepends = [
 erf gamma monadLoops mtl randomShuffle randomSource rvar syb
 transformers vector
___
nix-commits mailing list
nix-comm...@cs.uu.nl
http://mail.cs.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] SVN commit: nix - r28922 - nixpkgs/trunk/pkgs/development/libraries/haskell/warp

2011-08-30 Thread Peter Simons 
Author: simons
Date: Tue Aug 30 09:17:38 2011
New Revision: 28922
URL: https://svn.nixos.org/websvn/nix/?rev=28922&sc=1

Log:
haskell-warp: updated to version 0.4.4

Modified:
   nixpkgs/trunk/pkgs/development/libraries/haskell/warp/default.nix

Modified: nixpkgs/trunk/pkgs/development/libraries/haskell/warp/default.nix
==
--- nixpkgs/trunk/pkgs/development/libraries/haskell/warp/default.nix   Tue Aug 
30 09:17:34 2011(r28921)
+++ nixpkgs/trunk/pkgs/development/libraries/haskell/warp/default.nix   Tue Aug 
30 09:17:38 2011(r28922)
@@ -5,8 +5,8 @@
 
 cabal.mkDerivation (self: {
   pname = "warp";
-  version = "0.4.3.1";
-  sha256 = "19cj4jhl647gyy6nl3x2vi6v4g0y9q3w5a5lxvvfnfwgmcqnq3lk";
+  version = "0.4.4";
+  sha256 = "1mlwny6pfgngpqb4lh6v373m98agf275mbl2p6mxxfh1581fz863";
   buildDepends = [
 blazeBuilder blazeBuilderEnumerator caseInsensitive enumerator
 httpTypes network simpleSendfile transformers unixCompat wai
___
nix-commits mailing list
nix-comm...@cs.uu.nl
http://mail.cs.uu.nl/mailman/listinfo/nix-commits

Re: [Nix-dev] We are on Hackage

2011-08-30 Thread Marco Maggesi 
Thank you guys for the nice work you are doing for the deployment of Haskell 
tools with Nix.
NixOS is going to be the ideal platform for Haskell developers!

Marco


On Aug 30, 2011, at 10:44 AM, Peter Simons wrote:

> Hi guys,
> 
> the Hackage site shows for every package which versions of that
> package are available in which distribution, and NixOS is now part
> of the distributions that are being tracked. For example:
> 
>  http://hackage.haskell.org/package/pandoc
> 
> Take care,
> Peter
> 
> ___
> nix-dev mailing list
> nix-dev@cs.uu.nl
> https://mail.cs.uu.nl/mailman/listinfo/nix-dev

___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev

[Nix-commits] SVN commit: nix - r28923 - nixpkgs/trunk/pkgs/top-level

2011-08-30 Thread Peter Simons 
Author: simons
Date: Tue Aug 30 09:49:04 2011
New Revision: 28923
URL: https://svn.nixos.org/websvn/nix/?rev=28923&sc=1

Log:
Updated the default version of haskell-text to 0.11.1.5.

A growing number of packages don't build with the old version. I was
reluctant to make that change because Haskell Platform 2011.2.0.1 says
that text 0.11.0.6 ought to be used, but then HP says we shouldn't be
using GHC 7.0.4 either, yet we do. Anyway, upgrading the text library
caused no problems: all packages just built fine, so there you go.

Modified:
   nixpkgs/trunk/pkgs/top-level/haskell-packages.nix

Modified: nixpkgs/trunk/pkgs/top-level/haskell-packages.nix
==
--- nixpkgs/trunk/pkgs/top-level/haskell-packages.nix   Tue Aug 30 09:17:38 
2011(r28922)
+++ nixpkgs/trunk/pkgs/top-level/haskell-packages.nix   Tue Aug 30 09:49:04 
2011(r28923)
@@ -193,6 +193,7 @@
 self : self.haskellPlatformArgs_2011_2_0_1 self // {
   haskellPlatform = self.haskellPlatform_2011_2_0_1;
   mtl1 = self.mtl_1_1_1_1;
+  text = self.text_0_11_1_5;
 };
 
   haskellPlatform_2011_2_0_1 =
@@ -525,9 +526,7 @@
 
   dotgen = callPackage ../development/libraries/haskell/dotgen {};
 
-  doubleConversion = callPackage 
../development/libraries/haskell/double-conversion {
-text = self.text_0_11_1_5;
-  };
+  doubleConversion = callPackage 
../development/libraries/haskell/double-conversion {};
 
   editline = callPackage ../development/libraries/haskell/editline {
 inherit (pkgs) libedit;
@@ -1168,7 +1167,7 @@
   text_0_11_0_5 = callPackage 
../development/libraries/haskell/text/0.11.0.5.nix {};
   text_0_11_0_6 = callPackage 
../development/libraries/haskell/text/0.11.0.6.nix {};
   text_0_11_1_5 = callPackage 
../development/libraries/haskell/text/0.11.1.5.nix {};
-  text = self.text_0_11_0_5;
+  text = self.text_0_11_1_5;
 
   thLift = callPackage ../development/libraries/haskell/th-lift {};
 
___
nix-commits mailing list
nix-comm...@cs.uu.nl
http://mail.cs.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] SVN commit: nix - r28924 - nixpkgs/trunk/pkgs/development/libraries/haskell/aeson

2011-08-30 Thread Peter Simons 
Author: simons
Date: Tue Aug 30 09:49:08 2011
New Revision: 28924
URL: https://svn.nixos.org/websvn/nix/?rev=28924&sc=1

Log:
haskell-aeson: updated to version 0.3.2.11

Modified:
   nixpkgs/trunk/pkgs/development/libraries/haskell/aeson/default.nix

Modified: nixpkgs/trunk/pkgs/development/libraries/haskell/aeson/default.nix
==
--- nixpkgs/trunk/pkgs/development/libraries/haskell/aeson/default.nix  Tue Aug 
30 09:49:04 2011(r28923)
+++ nixpkgs/trunk/pkgs/development/libraries/haskell/aeson/default.nix  Tue Aug 
30 09:49:08 2011(r28924)
@@ -4,8 +4,8 @@
 
 cabal.mkDerivation (self: {
   pname = "aeson";
-  version = "0.3.2.9";
-  sha256 = "1qaajk797zpickw4ik5lc03wnmxkrcmv3zik7n1bjqx6h37h0zqw";
+  version = "0.3.2.11";
+  sha256 = "0cvavxb3bm5kz491wrx5az5scvddndw2rh45snhj1xn0flr1c2n7";
   buildDepends = [
 attoparsec blazeBuilder blazeTextual deepseq hashable mtl syb text
 time unorderedContainers vector
___
nix-commits mailing list
nix-comm...@cs.uu.nl
http://mail.cs.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] SVN commit: nix - r28925 - nixpkgs/trunk/pkgs/development/libraries/haskell/blaze-textual

2011-08-30 Thread Peter Simons 
Author: simons
Date: Tue Aug 30 09:49:12 2011
New Revision: 28925
URL: https://svn.nixos.org/websvn/nix/?rev=28925&sc=1

Log:
haskell-blaze-textual: updated to version 0.2.0.4

Modified:
   nixpkgs/trunk/pkgs/development/libraries/haskell/blaze-textual/default.nix

Modified: 
nixpkgs/trunk/pkgs/development/libraries/haskell/blaze-textual/default.nix
==
--- nixpkgs/trunk/pkgs/development/libraries/haskell/blaze-textual/default.nix  
Tue Aug 30 09:49:08 2011(r28924)
+++ nixpkgs/trunk/pkgs/development/libraries/haskell/blaze-textual/default.nix  
Tue Aug 30 09:49:12 2011(r28925)
@@ -1,10 +1,10 @@
-{ cabal, blazeBuilder, text, time, vector }:
+{ cabal, blazeBuilder, doubleConversion, text, time, vector }:
 
 cabal.mkDerivation (self: {
   pname = "blaze-textual";
-  version = "0.1.0.0";
-  sha256 = "0ql25b0r4xbshqsjfndl7glq0hp2ncxb3h5zd541vsqrqrf8y4gk";
-  buildDepends = [ blazeBuilder text time vector ];
+  version = "0.2.0.4";
+  sha256 = "0bifxyzm35xvlqry06iv6pqgx1d33jnrvpmn4wnydkyg1r7q3k9v";
+  buildDepends = [ blazeBuilder doubleConversion text time vector ];
   meta = {
 homepage = "http://github.com/mailrank/blaze-textual";;
 description = "Fast rendering of common datatypes";
___
nix-commits mailing list
nix-comm...@cs.uu.nl
http://mail.cs.uu.nl/mailman/listinfo/nix-commits

[Nix-dev] Re: [Nix-commits] SVN commit: nix - r28912 - in nixpkgs/trunk/pkgs: applications/misc/get_iplayer top-level

2011-08-30 Thread Ludovic Courtès 
Hi Rob!

Rob Vermaas  skribis:

> Author: rob
> Date: Tue Aug 30 00:14:16 2011
> New Revision: 28912
> URL: https://svn.nixos.org/websvn/nix/?rev=28912&sc=1
>
> Log:
> add get_iplayer 2.80

[...]

> +{stdenv, fetchurl, flvstreamer, ffmpeg, makeWrapper, perl}:
> +
> +stdenv.mkDerivation {
> +  name = "get_iplayer-2.80";

I think the convention is to use hyphens, even if the upstream package
uses a different convention.

> +  installPhase = '' 
> +ensureDir $out/bin
> +cp get_iplayer $out/bin
> +wrapProgram $out/bin/get_iplayer --suffix PATH 
> ${ffmpeg}/bin:${flvstreamer}/bin
> +  '';  

Can you explicitly add meta.license = "unfree"?

Likewise, could you add a meta.description and meta.homepage because the
name is not very descriptive.  ;-)

Thanks,
Ludo’.
___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Re: [Nix-commits] SVN commit: nix - r28912 - in nixpkgs/trunk/pkgs: applications/misc/get_iplayer top-level

2011-08-30 Thread Rob Vermaas 
Hi Ludo,

>> +  name = "get_iplayer-2.80";
>
> I think the convention is to use hyphens, even if the upstream package
> uses a different convention.

We have no such convention for the name attribute as fas as i know.

> Can you explicitly add meta.license = "unfree"?

I was lazy (actually, am always). Will add it this afternoon.

> Likewise, could you add a meta.description and meta.homepage because the
> name is not very descriptive.  ;-)

The name is very descriptive if you know what BBC iPlayer is ;-)

-- 
Rob Vermaas

[email] rob.verm...@gmail.com
___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Re: [Nix-commits] SVN commit: nix - r28912 - in nixpkgs/trunk/pkgs: applications/misc/get_iplayer top-level

2011-08-30 Thread Ludovic Courtès 
Hey,

>>> +  name = "get_iplayer-2.80";
>>
>> I think the convention is to use hyphens, even if the upstream package
>> uses a different convention.
>
> We have no such convention for the name attribute as fas as i know.

Right...  but maybe we should add one?  ;-)

Ludo’.
___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Re: [Nix-commits] SVN commit: nix - r28912 - in nixpkgs/trunk/pkgs: applications/misc/get_iplayer top-level

2011-08-30 Thread Rob Vermaas 
Hi,

 +  name = "get_iplayer-2.80";
>>>
>>> I think the convention is to use hyphens, even if the upstream package
>>> uses a different convention.
>>
>> We have no such convention for the name attribute as fas as i know.
>
> Right...  but maybe we should add one?  ;-)

Should we? I have no opinion in this matter... :-)

-- 
Rob Vermaas

[email] rob.verm...@gmail.com
___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Re: new possible movement to git (?)

2011-08-30 Thread Lluís Batlle 
Hello,

2011/8/30 Peter Simons :
>  > Yeah, it would be nice if git had information in commits about which
>  > branch the commit was initially performed on. This seems like a
>  > really simple feature, not sure why it doesn't exist.
>
> personally, I don't see why that information is relevant. Branch names
> are a local affair in Git. It's quite possible for two repositories to
> track the same content using completely different branch names. So why
> bother recording the name if it doesn't have any significance outside of
> the repository? Other DVCS make a lot of fuss about branch names, like
> monotone, but I don't see any gain in a distributed project.

I'm very used to having branches and their names tracked by the VCS as
part of the history. That's why I prefer approaches of fossil, svn,
monotone, etc. over git. Otherwise, only the commit log may provide
some context information about the circumstances of the change. So, I
like having named branches tracked by the VCS, instead of simply
having a big graph of file changes with commit logs with no additional
information.

And as for live public branches, as Raskin pointed out, the git
(linux) people tend to simply stand a new repository for that specific
purpose somewhere

I'm also quite against of the possibility of rebasing, as it can
easily make invalid assertions people may want to write in their logs,
like "I've tested the feature and it works". Then there is the
untracked editing of commits, and all that related to history
rewriting to the taste of the publisher, instead of keeping track of
events in their context along time.
___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Re: new possible movement to git (?)

2011-08-30 Thread Peter Simons 
Hi Shea,

 >> The whole notion of having a "stdenv-updates" branch in the first
 >> place is obsolete in Git. Instead, we would have many small topic
 >> branches for specific features.
 >
 > But stdenv-updates isn't meant as a really big topic branch. It's
 > meant as a place for changes that will require rebuilding the system,
 > so we can minimize the number of times we require that. How does git
 > help with that?

Suppose that I modify GNU Make, for example, then that change ought to
go into stdenv-updates. At the same time, you modify glibc, and that
change goes into stdenv-updates, too. But those two changes are
orthogonal. They don't depend on each other. So why should they be
checked into the same branch? There is no conceptual reason to do that.
Rather, there is a practical reason, namely the fact that creating two
new branches for those two changes -- a.k.a. topic branches -- would be
unfeasible with SVN.

When using Git, that restriction no longer exists. I can create a branch
stdenv/gnu-make, and you can create a branch stdenv/glibc, and Hydra
could build both of them (in fact, Hydra would probably build all
stdenv/* branches). In that scenario, other users are free to merge the
contents of either branch into their personal "master"; they can choose
whether they want to have the latest gnu make or the latest glibc or
both. When both changes are checked into one monolithic stdenv-updates
branch, however, doing that is not so easy.

Eventually, you decide that the new glibc is stable, and then you run
"git merge stdenv-updates" on whatever happens to be your equivalent of
the official master branch, and then you push the changeset upstream,
which effectively makes them "stable" for everyone. The merge commit
would even record the fact that you worked on a topic branch prior to
that, and the history of that branch would become visible in "master",
too.

The workflow is not completely different from what we are doing now, but
the granularity is much higher. There isn't just one stdenv-updates
branch. Rather, there are many of them.

Basically, all branches except "master" are considered unstable, i.e.
work in progress. When they have become stable, though, then they are
pushed into the master branch.

Take care,
Peter

___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Re: Updating stdenv on Darwin

2011-08-30 Thread Ludovic Courtès 
Hello!

l...@gnu.org (Ludovic Courtès) skribis:

> l...@gnu.org (Ludovic Courtès) skribis:
>
>> Thus I’d like to commit this patch and take this opportunity to update
>> Apple’s GCC fork as well.
>
> I did that in the ‘darwin-updates’ branch and apparently there’s no new
> breakage on the package sample I looked at:
>
>   http://hydra.nixos.org/jobset/nixpkgs/darwin-updates/with-status
>
> If there are no objections I’ll merge it to ‘trunk’ next week.

That week turned out to last more than a month, but I’ve now merged it.

Thanks,
Ludo’.

___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev

[Nix-commits] SVN commit: nix - r28926 - in nixpkgs/trunk: . pkgs/applications/graphics/xscreensaver pkgs/applications/misc/xneur pkgs/applications/networking/browsers/icecat-4 pkgs/applications/netwo

2011-08-30 Thread Ludovic Courtès 
Author: ludo
Date: Tue Aug 30 13:08:33 2011
New Revision: 28926
URL: https://svn.nixos.org/websvn/nix/?rev=28926&sc=1

Log:
Merge from the `darwin-updates' branch.

Modified:
   nixpkgs/trunk/   (props changed)
   nixpkgs/trunk/pkgs/applications/graphics/xscreensaver/default.nix   (props 
changed)
   nixpkgs/trunk/pkgs/applications/misc/xneur/0.8.nix   (props changed)
   nixpkgs/trunk/pkgs/applications/networking/browsers/icecat-4/   (props 
changed)
   
nixpkgs/trunk/pkgs/applications/networking/browsers/mozilla-plugins/flashplayer-10/
   (props changed)
   nixpkgs/trunk/pkgs/build-support/gcc-wrapper/   (props changed)
   nixpkgs/trunk/pkgs/build-support/release/debian-build.nix   (props changed)
   nixpkgs/trunk/pkgs/build-support/release/nix-build.nix   (props changed)
   nixpkgs/trunk/pkgs/build-support/release/rpm-build.nix   (props changed)
   nixpkgs/trunk/pkgs/build-support/release/source-tarball.nix   (props changed)
   nixpkgs/trunk/pkgs/desktops/kde-4.5/support/shared-desktop-ontologies/   
(props changed)
   nixpkgs/trunk/pkgs/development/compilers/gcc-apple64/default.nix
   nixpkgs/trunk/pkgs/development/compilers/ghc/6.10.1.nix   (props changed)
   nixpkgs/trunk/pkgs/development/compilers/ghc/6.10.2.nix   (props changed)
   nixpkgs/trunk/pkgs/development/compilers/ghc/6.8.2.nix   (props changed)
   nixpkgs/trunk/pkgs/development/compilers/ghc/6.8.3.nix   (props changed)
   nixpkgs/trunk/pkgs/development/libraries/aterm/2.8.nix   (props changed)
   nixpkgs/trunk/pkgs/development/libraries/fltk/fltk11.nix   (props changed)
   nixpkgs/trunk/pkgs/development/libraries/glibc-2.9/   (props changed)
   nixpkgs/trunk/pkgs/development/libraries/goocanvas/   (props changed)
   nixpkgs/trunk/pkgs/development/libraries/pcre/default.nix   (props changed)
   nixpkgs/trunk/pkgs/development/libraries/readline/readline6.nix   (props 
changed)
   nixpkgs/trunk/pkgs/development/tools/misc/autoconf/2.13.nix   (props changed)
   nixpkgs/trunk/pkgs/development/tools/misc/gnum4/default.nix   (props changed)
   nixpkgs/trunk/pkgs/misc/tex/pgf/1.x.nix   (props changed)
   nixpkgs/trunk/pkgs/misc/tex/pgf/2.x.nix   (props changed)
   nixpkgs/trunk/pkgs/os-specific/linux/atheros/r3867.nix   (props changed)
   nixpkgs/trunk/pkgs/os-specific/linux/kernel-headers/2.6.28.nix   (props 
changed)
   nixpkgs/trunk/pkgs/os-specific/linux/kernel-headers/2.6.32.nix   (props 
changed)
   nixpkgs/trunk/pkgs/os-specific/linux/kernel/generic.nix   (props changed)
   nixpkgs/trunk/pkgs/os-specific/linux/kernel/linux-2.6.25.nix   (props 
changed)
   nixpkgs/trunk/pkgs/os-specific/linux/kernel/linux-2.6.27.nix   (props 
changed)
   nixpkgs/trunk/pkgs/os-specific/linux/kernel/linux-2.6.28.nix   (props 
changed)
   nixpkgs/trunk/pkgs/os-specific/linux/kernel/linux-2.6.29.nix   (props 
changed)
   nixpkgs/trunk/pkgs/os-specific/linux/kernel/linux-2.6.32-xen.nix   (props 
changed)
   nixpkgs/trunk/pkgs/os-specific/linux/kernel/linux-2.6.32.nix   (props 
changed)
   nixpkgs/trunk/pkgs/os-specific/linux/kernel/linux-2.6.33.nix   (props 
changed)
   nixpkgs/trunk/pkgs/os-specific/linux/kqemu/1.4.0pre1.nix   (props changed)
   nixpkgs/trunk/pkgs/os-specific/linux/qemu-kvm/default.nix   (props changed)
   nixpkgs/trunk/pkgs/os-specific/linux/util-linux-ng/   (props changed)
   nixpkgs/trunk/pkgs/servers/mail/dovecot/1.1.1.nix   (props changed)
   nixpkgs/trunk/pkgs/shells/bash/default.nix   (props changed)
   nixpkgs/trunk/pkgs/stdenv/generic/setup.sh   (props changed)
   nixpkgs/trunk/pkgs/stdenv/linux/make-bootstrap-tools.nix   (props changed)
   nixpkgs/trunk/pkgs/tools/networking/wget/default.nix   (props changed)

Modified: nixpkgs/trunk/pkgs/development/compilers/gcc-apple64/default.nix
==
--- nixpkgs/trunk/pkgs/development/compilers/gcc-apple64/default.nixTue Aug 
30 09:49:12 2011(r28925)
+++ nixpkgs/trunk/pkgs/development/compilers/gcc-apple64/default.nixTue Aug 
30 13:08:33 2011(r28926)
@@ -8,23 +8,29 @@
 assert stdenv.isDarwin;
 assert langF77 -> gmp != null;
 
+let
+  version  = "4.2.1";   # Upstream GCC version, from `gcc/BASE-VER'.
+  revision = "5666.3";  # Apple's fork revision number.
+in
 stdenv.mkDerivation ({
-  name = "gcc-4.2.1-apple-5646";
+  name = "gcc-apple-${version}.${revision}";
+
   builder = ./builder.sh;
-  src = 
+
+  src =
 stdenv.lib.optional /*langC*/ true (fetchurl {
-  url = http://www.opensource.apple.com/tarballs/gcc/gcc-5646.tar.gz;
-  sha256 = "13jghyb098104kfym96iwwdvbj6snnws2c92h48lbd4fmyf1iv24";
+  url = 
"http://www.opensource.apple.com/tarballs/gcc/gcc-${revision}.tar.gz";;
+  sha256 = "0nq1szgqx9ryh1qsn5n6yd55gpvf56wr8f7w1jzabb8idlvz8ikc";
 }) ++
 stdenv.lib.optional langCC (fetchurl {
   url = 
http://www.opensource.apple.com/tarballs/libstdcxx/libstdcxx-39.tar.gz ;
-  sha256 = "1fy6j41rhxdsm19sib9wygjl5l54g8pm13c6y5x13f40mavw1mma";
+  sha256 = 
"ccf4cf432c1427

[Nix-commits] SVN commit: nix - r28927 - nixpkgs/trunk/pkgs/os-specific/linux/kernel

2011-08-30 Thread Shea Levy 
Author: shlevy
Date: Tue Aug 30 13:25:11 2011
New Revision: 28927
URL: https://svn.nixos.org/websvn/nix/?rev=28927&sc=1

Log:
linux-3.0.nix: Bump to 3.0.4

Modified:
   nixpkgs/trunk/pkgs/os-specific/linux/kernel/linux-3.0.nix

Modified: nixpkgs/trunk/pkgs/os-specific/linux/kernel/linux-3.0.nix
==
--- nixpkgs/trunk/pkgs/os-specific/linux/kernel/linux-3.0.nix   Tue Aug 30 
13:08:33 2011(r28926)
+++ nixpkgs/trunk/pkgs/os-specific/linux/kernel/linux-3.0.nix   Tue Aug 30 
13:25:11 2011(r28927)
@@ -199,11 +199,11 @@
 import ./generic.nix (
 
   rec {
-version = "3.0.3";
+version = "3.0.4";
   
 src = fetchurl {
   url = "mirror://kernel/linux/kernel/v3.x/linux-${version}.tar.bz2";
-  sha256 = "1237i7a4r7a7p24ylx7wv8k34ni17lxg849xjyv54px84kbkb85n";
+  sha256 = "1vypjcdii75h5f4zsw9lm8wzxd5ix0mk5p94c96hxv828mqqkmhk";
 };
 
 config = configWithPlatform stdenv.platform;
___
nix-commits mailing list
nix-comm...@cs.uu.nl
http://mail.cs.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] SVN commit: nix - r28928 - nixpkgs/trunk/pkgs/os-specific/linux/kernel

2011-08-30 Thread Shea Levy 
Author: shlevy
Date: Tue Aug 30 13:25:23 2011
New Revision: 28928
URL: https://svn.nixos.org/websvn/nix/?rev=28928&sc=1

Log:
linux-3.1: Bump to rc4

Modified:
   nixpkgs/trunk/pkgs/os-specific/linux/kernel/linux-3.1.nix

Modified: nixpkgs/trunk/pkgs/os-specific/linux/kernel/linux-3.1.nix
==
--- nixpkgs/trunk/pkgs/os-specific/linux/kernel/linux-3.1.nix   Tue Aug 30 
13:25:11 2011(r28927)
+++ nixpkgs/trunk/pkgs/os-specific/linux/kernel/linux-3.1.nix   Tue Aug 30 
13:25:23 2011(r28928)
@@ -199,13 +199,13 @@
 import ./generic.nix (
 
   rec {
-version = "3.1-rc3";
+version = "3.1-rc4";
 
-modDirVersion = "3.1.0-rc3";
+modDirVersion = "3.1.0-rc4";
   
 src = fetchurl {
   url = 
"mirror://kernel/linux/kernel/v3.x/testing/linux-${version}.tar.bz2";
-  sha256 = "0ky6pawracgc27m0d4mq71f87yiwbp90k5aqn8qh5bdfq3ml84i6";
+  sha256 = "1inb4iyj9r7lk68bw1mznxk726n3cxcbylqnb62ycisi1z2gxwjw";
 };
 
 config = configWithPlatform stdenv.platform;
___
nix-commits mailing list
nix-comm...@cs.uu.nl
http://mail.cs.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] SVN commit: nix - r28929 - nixpkgs/trunk/pkgs/development/compilers/gcc-apple64

2011-08-30 Thread Shea Levy 
Author: shlevy
Date: Tue Aug 30 13:46:05 2011
New Revision: 28929
URL: https://svn.nixos.org/websvn/nix/?rev=28929&sc=1

Log:
gcc-apple64: Enable Objective C

darwin-updates was just merged, so I'm taking the liberty of messing with 
darwin's stdenv

Modified:
   nixpkgs/trunk/pkgs/development/compilers/gcc-apple64/builder.sh
   nixpkgs/trunk/pkgs/development/compilers/gcc-apple64/default.nix

Modified: nixpkgs/trunk/pkgs/development/compilers/gcc-apple64/builder.sh
==
--- nixpkgs/trunk/pkgs/development/compilers/gcc-apple64/builder.sh Tue Aug 
30 13:25:23 2011(r28928)
+++ nixpkgs/trunk/pkgs/development/compilers/gcc-apple64/builder.sh Tue Aug 
30 13:46:05 2011(r28929)
@@ -61,6 +61,9 @@
 if test -n "$langF77"; then
 langs="$langs,f95"
 fi
+if test -n "$langObjC"; then
+langs="$langs,objc"
+fi
 
 # Perform the build in a different directory.
 mkdir ../build

Modified: nixpkgs/trunk/pkgs/development/compilers/gcc-apple64/default.nix
==
--- nixpkgs/trunk/pkgs/development/compilers/gcc-apple64/default.nixTue Aug 
30 13:25:23 2011(r28928)
+++ nixpkgs/trunk/pkgs/development/compilers/gcc-apple64/default.nixTue Aug 
30 13:46:05 2011(r28929)
@@ -1,5 +1,5 @@
 { stdenv, fetchurl, noSysDirs
-, langC ? true, langCC ? true, langF77 ? false
+, langC ? true, langCC ? true, langObjC ? true, langF77 ? false
 , profiledCompiler ? false
 , gmp ? null, mpfr ? null, bison ? null, flex ? null
 }:
@@ -34,5 +34,5 @@
   patches =
 [./pass-cxxcpp.patch ]
 ++ (if noSysDirs then [./no-sys-dirs.patch] else []);
-  inherit noSysDirs langC langCC langF77 profiledCompiler;
+  inherit noSysDirs langC langCC langF77 langObjC profiledCompiler;
 } // (if langF77 then {buildInputs = [gmp mpfr bison flex];} else {}))
___
nix-commits mailing list
nix-comm...@cs.uu.nl
http://mail.cs.uu.nl/mailman/listinfo/nix-commits

[Nix-dev] Re: new possible movement to git (?)

2011-08-30 Thread Michael Raskin 
<1e1d23499a69570914f03bc0a196953a.squir...@webmail.shealevy.com>
<87ei034yse@write-only.cryp.to>
<5833f9f3-bf70-4cae-9ad2-489170ad5...@email.android.com>)
Mime-Version: 1.0
Content-type: text/plain; charset="UTF-8"

> > But stdenv-updates isn't meant as a really big topic branch. It's
> > meant as a place for changes that will require rebuilding the system,
> > so we can minimize the number of times we require that. How does git
> > help with that?
>
>Suppose that I modify GNU Make, for example, then that change ought to
>go into stdenv-updates. At the same time, you modify glibc, and that
>change goes into stdenv-updates, too. But those two changes are
>orthogonal. They don't depend on each other. So why should they be
>checked into the same branch? There is no conceptual reason to do that.
>Rather, there is a practical reason, namely the fact that creating two
>new branches for those two changes -- a.k.a. topic branches -- would be
>unfeasible with SVN.

If it were, creating stdenv-updates per se would be infeasible.

>When using Git, that restriction no longer exists. I can create a branch
>stdenv/gnu-make, and you can create a branch stdenv/glibc, and Hydra
>could build both of them (in fact, Hydra would probably build all
>stdenv/* branches). In that scenario, other users are free to merge the

No. The space required could grow too fast. It was stated many times 
that Hydra jobsets will only be created by people running Hydra.

>contents of either branch into their personal "master"; they can choose
>whether they want to have the latest gnu make or the latest glibc or
>both. When both changes are checked into one monolithic stdenv-updates
>branch, however, doing that is not so easy.

The problem is a packaging problem, not version-management one. If you
update Make, a lot of packages break. If you update glibc, a lot of 
packages break. Some packages break only when you update both at once
(nobody knows how they manage this). 

Also, you want to minimize big rebuilds. 

Note how stdenv-updates really goes: we update _many_ things at once,
and then fix the bugs that show up with all the latest things. If we 
create small topic branches, we have a large risk of spending duplicated
effort fixing many things on many topic branches, then merging some of 
the topic branches together and fixing more things that depend on
combinations of versions, finding out the old fixes make things worse,
and so on. 

>Eventually, you decide that the new glibc is stable, and then you run
>"git merge stdenv-updates" on whatever happens to be your equivalent of
>the official master branch, and then you push the changeset upstream,
>which effectively makes them "stable" for everyone. The merge commit
>would even record the fact that you worked on a topic branch prior to
>that, and the history of that branch would become visible in "master",
>too.

Right, and the "make" change keeps hanging. So we are worse off than 
now, because we get two stdenv rebuilds.

>The workflow is not completely different from what we are doing now, but
>the granularity is much higher. There isn't just one stdenv-updates
>branch. Rather, there are many of them.

Any update will require lots of fixes. So, it is better to have one
stdenv branch, not ten 50%-broken branches.

And by the way, having all glibc-update branches called the same even
keeps the problem with Git history.

>Basically, all branches except "master" are considered unstable, i.e.
>work in progress. When they have become stable, though, then they are
>pushed into the master branch.

For packaging, notion of stable cannot be preserved across merges with
any kind of confidence..



___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Re: new possible movement to git (?)

2011-08-30 Thread shea 
Hi Peter,

I don't think this accurately reflects the reasons we use stdenv-updates.
We don't put it all in the same branch because more fine-grained branching
is expensive, we put it all in the same branch because we want the
eventual merge of the changes to happen at the same time. We will still
have that requirement for the public nixpkgs repo if we switch to git.

~Shea

> Hi Shea,
>
>  >> The whole notion of having a "stdenv-updates" branch in the first
>  >> place is obsolete in Git. Instead, we would have many small topic
>  >> branches for specific features.
>  >
>  > But stdenv-updates isn't meant as a really big topic branch. It's
>  > meant as a place for changes that will require rebuilding the system,
>  > so we can minimize the number of times we require that. How does git
>  > help with that?
>
> Suppose that I modify GNU Make, for example, then that change ought to
> go into stdenv-updates. At the same time, you modify glibc, and that
> change goes into stdenv-updates, too. But those two changes are
> orthogonal. They don't depend on each other. So why should they be
> checked into the same branch? There is no conceptual reason to do that.
> Rather, there is a practical reason, namely the fact that creating two
> new branches for those two changes -- a.k.a. topic branches -- would be
> unfeasible with SVN.
>
> When using Git, that restriction no longer exists. I can create a branch
> stdenv/gnu-make, and you can create a branch stdenv/glibc, and Hydra
> could build both of them (in fact, Hydra would probably build all
> stdenv/* branches). In that scenario, other users are free to merge the
> contents of either branch into their personal "master"; they can choose
> whether they want to have the latest gnu make or the latest glibc or
> both. When both changes are checked into one monolithic stdenv-updates
> branch, however, doing that is not so easy.
>
> Eventually, you decide that the new glibc is stable, and then you run
> "git merge stdenv-updates" on whatever happens to be your equivalent of
> the official master branch, and then you push the changeset upstream,
> which effectively makes them "stable" for everyone. The merge commit
> would even record the fact that you worked on a topic branch prior to
> that, and the history of that branch would become visible in "master",
> too.
>
> The workflow is not completely different from what we are doing now, but
> the granularity is much higher. There isn't just one stdenv-updates
> branch. Rather, there are many of them.
>
> Basically, all branches except "master" are considered unstable, i.e.
> work in progress. When they have become stable, though, then they are
> pushed into the master branch.
>
> Take care,
> Peter
>
> ___
> nix-dev mailing list
> nix-dev@cs.uu.nl
> https://mail.cs.uu.nl/mailman/listinfo/nix-dev
>


___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Re: Updating stdenv on Darwin

2011-08-30 Thread shea 
> Hello!
>
> l...@gnu.org (Ludovic Courtès) skribis:
>
>> l...@gnu.org (Ludovic Courtès) skribis:
>>
>>> Thus I’d like to commit this patch and take this opportunity to
>>> update
>>> Apple’s GCC fork as well.
>>
>> I did that in the ‘darwin-updates’ branch and apparently there’s
>> no new
>> breakage on the package sample I looked at:
>>
>>   http://hydra.nixos.org/jobset/nixpkgs/darwin-updates/with-status
>>
>> If there are no objections I’ll merge it to ‘trunk’ next week.
>
> That week turned out to last more than a month, but I’ve now merged it.
>
> Thanks,
> Ludo’.
>
> ___
> nix-dev mailing list
> nix-dev@cs.uu.nl
> https://mail.cs.uu.nl/mailman/listinfo/nix-dev
>

Hi Ludo,

I'm working on modifying the darwin stdenv in such a way that it
ultimately won't depend on any xcode tools. Can I use the darwin-updates
branch for this?

Also, do you know the rationale for using the Apple gcc fork instead of
vanilla GNU gcc on darwin?

Thanks,
Shea

___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Re: [Nix-commits] SVN commit: nix - r28912 - in nixpkgs/trunk/pkgs: applications/misc/get_iplayer top-level

2011-08-30 Thread Yury G. Kudryashov 
Ludovic Courtès wrote:

> Hi Rob!
> 
>> +  installPhase = ''
>> +ensureDir $out/bin
>> +cp get_iplayer $out/bin
I'd prefer 'cp -v' or 'install' here.
-- 
Yury G. Kudryashov,
mailto: ur...@mccme.ru

___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Re: new possible movement to git (?)

2011-08-30 Thread Peter Simons 
Hi Shea,

 > I don't think this accurately reflects the reasons we use
 > stdenv-updates. We don't put it all in the same branch because more
 > fine-grained branching is expensive, we put it all in the same branch
 > because we want the eventual merge of the changes to happen at the
 > same time.

exactly who is "we"? Please speak for yourself. I, for one, do not want
unrelated changes to be merged in one commit, because that habit breaks
extremely useful tools such as "git bisect".

Besides, having many different stdenv/* topic branches does not imply
that each of them must be merged into master separately. You *can* merge
them all at once, of course, if you want to. It just so happens that I
wouldn't want to do that because the practice violates elementary
principles software engineering.

Take care,
Peter

___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Re: new possible movement to git (?)

2011-08-30 Thread shea 
> Hi Shea,
>
>  > I don't think this accurately reflects the reasons we use
>  > stdenv-updates. We don't put it all in the same branch because more
>  > fine-grained branching is expensive, we put it all in the same branch
>  > because we want the eventual merge of the changes to happen at the
>  > same time.
>
> exactly who is "we"? Please speak for yourself. I, for one, do not want
> unrelated changes to be merged in one commit, because that habit breaks
> extremely useful tools such as "git bisect".
>
> Besides, having many different stdenv/* topic branches does not imply
> that each of them must be merged into master separately. You *can* merge
> them all at once, of course, if you want to. It just so happens that I
> wouldn't want to do that because the practice violates elementary
> principles software engineering.
>

Do you see why there are benefits, if not from a developer's perspective,
from an end-user perspective and from hydra's perspective to having
changes to stdenv be infrequent and more inclusive than is appropriate for
a generic feature branch?

>
> Take care,
> Peter
>
> ___
> nix-dev mailing list
> nix-dev@cs.uu.nl
> https://mail.cs.uu.nl/mailman/listinfo/nix-dev
>


___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Re: new possible movement to git (?)

2011-08-30 Thread Peter Simons 
Hi Michael,

 >> Eventually, you decide that the new glibc is stable, and then you
 >> run "git merge stdenv/glibc" on whatever happens to be your
 >> equivalent of the official master branch, and then you push the
 >> changeset upstream, which effectively makes them "stable" for
 >> everyone.
 >
 > Right, and the "make" change keeps hanging. So we are worse off than
 > now, because we get two stdenv rebuilds.

actually, it's exactly the opposite. We are better off because we have
significantly reduced the amount of inference between changes to GNU
Make and changes to GNU libc.

When the glibc update has been pushed, those changes become "stable" or
"official" or however you want to call it, meaning that those changes
are going to be propagated into all active stdenv/* topic branches,
where the people working on those branches can address problems the
glibc update might cause locally. If all these changes were to occur in
a single branch, then those changes would constantly interfere with each
other, causing lots and lots of unnecessary re-builds and making
everyone's live much harder.

Take care,
Peter

___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Re: new possible movement to git (?)

2011-08-30 Thread Peter Simons 
Hi Shea,

 > Do you see why there are benefits [...] to having changes to stdenv
 > be infrequent and more inclusive than is appropriate for a generic
 > feature branch?

of course, I totally agree with that. Stdenv should be changed only when
there is a good technical reason to do so. For example, it's one thing
to have the latest version of GNU Make available in nixpkgs, but it's
another quite thing to put it into stdenv ... or bootstrap-tools. :-)

Take care,
Peter

___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Re: new possible movement to git (?)

2011-08-30 Thread shea 
> Hi Shea,
>
>  > Do you see why there are benefits [...] to having changes to stdenv
>  > be infrequent and more inclusive than is appropriate for a generic
>  > feature branch?
>
> of course, I totally agree with that. Stdenv should be changed only when
> there is a good technical reason to do so. For example, it's one thing
> to have the latest version of GNU Make available in nixpkgs, but it's
> another quite thing to put it into stdenv ... or bootstrap-tools. :-)
>

Ok, so when we have updated Make and gcc and glibc and all of that in
nixpkgs, and we want to test it all together and give hydra something to
build before we actually update stdenv to use the new tools, why not use a
branch specifically made for this purpose?

~Shea

>
> Take care,
> Peter
>
> ___
> nix-dev mailing list
> nix-dev@cs.uu.nl
> https://mail.cs.uu.nl/mailman/listinfo/nix-dev
>


___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev

[***SPAM***] [Nix-dev] Re: new possible movement to git (?)

2011-08-30 Thread Michael Raskin 
<1e1d23499a69570914f03bc0a196953a.squir...@webmail.shealevy.com>
<87ei034yse@write-only.cryp.to>
<5833f9f3-bf70-4cae-9ad2-489170ad5...@email.android.com>
<87ei03aw6p@write-only.cryp.to>
<894aedf1c3c6d28c2272e35ab266d932.squir...@webmail.shealevy.com>)
Mime-Version: 1.0
Content-type: text/plain; charset="UTF-8"

> > I don't think this accurately reflects the reasons we use
> > stdenv-updates. We don't put it all in the same branch because more
> > fine-grained branching is expensive, we put it all in the same branch
> > because we want the eventual merge of the changes to happen at the
> > same time.
>
>exactly who is "we"? Please speak for yourself. I, for one, do not want
>unrelated changes to be merged in one commit, because that habit breaks
>extremely useful tools such as "git bisect".

One commit and one branch are different things. 

>Besides, having many different stdenv/* topic branches does not imply
>that each of them must be merged into master separately. You *can* merge
>them all at once, of course, if you want to. It just so happens that I
>wouldn't want to do that because the practice violates elementary
>principles software engineering.

The problem is that actually merging them one-by-one is costly. Trunk
should receive one rebuild. And it is established practice to reduce
the count of stdenv rebuilds.

Also, there is little happening in NixPkgs that should be classified as
software engineering. Everything non-trivial in packaging is about 
finding out upstream quirks. 

To run NixOS, I need maximum amount of packages in stdenv-updates to be
non-broken. Tracking what is broken where across five topic branches is
insanity even without second-guessing what will start working on merge.



___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev

[Nix-commits] SVN commit: nix - r28930 - hydra-config/gnu/trunk/mpfr

2011-08-30 Thread Ludovic Courtès 
Author: ludo
Date: Tue Aug 30 14:47:34 2011
New Revision: 28930
URL: https://svn.nixos.org/websvn/nix/?rev=28930&sc=1

Log:
MPFR: Build with Valgrind.

Modified:
   hydra-config/gnu/trunk/mpfr/release.nix

Modified: hydra-config/gnu/trunk/mpfr/release.nix
==
--- hydra-config/gnu/trunk/mpfr/release.nix Tue Aug 30 13:46:05 2011
(r28929)
+++ hydra-config/gnu/trunk/mpfr/release.nix Tue Aug 30 14:47:34 2011
(r28930)
@@ -41,6 +41,9 @@
  [ "Paul Zimmermann " ];
   };
 
+  configureFlags = pkgs:
+pkgs.lib.optional pkgs.stdenv.isLinux [ "--enable-valgrind" ];
+
   preCheck = "export GMP_CHECK_RANDOMIZE=true";
 
   # The minimum required GMP version.
@@ -66,7 +69,12 @@
   patches = [ ./ck-version-info.patch ];
 };
 
-build = pkgs: { buildInputs = [ gmp ]; inherit preCheck; };
+build = pkgs: {
+  buildInputs = [ pkgs.valgrind gmp ];
+  configureFlags = (configureFlags pkgs);
+  inherit preCheck;
+};
+
 coverage = pkgs: { buildInputs = [ gmp ]; inherit preCheck; };
 xbuild_gnu = pkgs: { buildInputs = [ gmp_xgnu ]; };
   };
___
nix-commits mailing list
nix-comm...@cs.uu.nl
http://mail.cs.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] SVN commit: nix - r28931 - hydra-config/gnu/trunk/mpc

2011-08-30 Thread Ludovic Courtès 
Author: ludo
Date: Tue Aug 30 14:55:32 2011
New Revision: 28931
URL: https://svn.nixos.org/websvn/nix/?rev=28931&sc=1

Log:
MPC: Build with Valgrind.

Modified:
   hydra-config/gnu/trunk/mpc/release.nix

Modified: hydra-config/gnu/trunk/mpc/release.nix
==
--- hydra-config/gnu/trunk/mpc/release.nix  Tue Aug 30 14:47:34 2011
(r28930)
+++ hydra-config/gnu/trunk/mpc/release.nix  Tue Aug 30 14:55:32 2011
(r28931)
@@ -62,10 +62,15 @@
   build = pkgs: {
 configureFlags =
   # On Cygwin GMP is compiled statically, so build MPC statically.
-  pkgs.stdenv.lib.optionals pkgs.stdenv.isCygwin
-[ "--enable-static" "--disable-shared" ];
+  (pkgs.stdenv.lib.optionals pkgs.stdenv.isCygwin
+[ "--enable-static" "--disable-shared" ])
+
+  # Build with Valgrind on GNU/Linux.
+  ++ (pkgs.lib.optional pkgs.stdenv.isLinux "--enable-valgrind-tests");
+
+buildInputs = [ gmp mpfr ]
+  ++ (pkgs.lib.optional pkgs.stdenv.isLinux pkgs.valgrind);
 
-buildInputs = [ gmp mpfr ];
 inherit preCheck;
   };
   coverage = pkgs: { buildInputs = [ gmp mpfr ]; inherit preCheck; };
___
nix-commits mailing list
nix-comm...@cs.uu.nl
http://mail.cs.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] SVN commit: nix - r28932 - hydra-config/gnu/trunk/mpfr

2011-08-30 Thread Ludovic Courtès 
Author: ludo
Date: Tue Aug 30 14:55:36 2011
New Revision: 28932
URL: https://svn.nixos.org/websvn/nix/?rev=28932&sc=1

Log:
MPFR: Depend on Valgrind only on GNU/Linux.

Modified:
   hydra-config/gnu/trunk/mpfr/release.nix

Modified: hydra-config/gnu/trunk/mpfr/release.nix
==
--- hydra-config/gnu/trunk/mpfr/release.nix Tue Aug 30 14:55:32 2011
(r28931)
+++ hydra-config/gnu/trunk/mpfr/release.nix Tue Aug 30 14:55:36 2011
(r28932)
@@ -70,7 +70,9 @@
 };
 
 build = pkgs: {
-  buildInputs = [ pkgs.valgrind gmp ];
+  buildInputs = [ gmp ]
+++ (pkgs.lib.optional pkgs.stdenv.isLinux pkgs.valgrind);
+
   configureFlags = (configureFlags pkgs);
   inherit preCheck;
 };
___
nix-commits mailing list
nix-comm...@cs.uu.nl
http://mail.cs.uu.nl/mailman/listinfo/nix-commits

[Nix-dev] Re: new possible movement to git (?)

2011-08-30 Thread Michael Raskin 

)
Mime-Version: 1.0
Content-type: text/plain; charset="UTF-8"

> >> Eventually, you decide that the new glibc is stable, and then you
> >> run "git merge stdenv/glibc" on whatever happens to be your
> >> equivalent of the official master branch, and then you push the
> >> changeset upstream, which effectively makes them "stable" for
> >> everyone.
> >
> > Right, and the "make" change keeps hanging. So we are worse off than
> > now, because we get two stdenv rebuilds.
>
>actually, it's exactly the opposite. We are better off because we have
>significantly reduced the amount of inference between changes to GNU
>Make and changes to GNU libc.
>
>When the glibc update has been pushed, those changes become "stable" or
>"official" or however you want to call it, meaning that those changes
>are going to be propagated into all active stdenv/* topic branches,
>where the people working on those branches can address problems the
>glibc update might cause locally. If all these changes were to occur in
>a single branch, then those changes would constantly interfere with each
>other, causing lots and lots of unnecessary re-builds and making
>everyone's live much harder.

"Everyone" is using trunk on the computers which they expect to work.

So two stdenv rebuilds where one would work is an annoyance.

The changes from glibc and from make would interfere once. We would 
rebuild make, then learn to build glibc with new make (we have to do
this anyway), then make and glibc are quite likely not to change. 

Solutions to many problems with updates often include updating the 
offending packages to get upstream fixes. Your way supposes trying to 
build them with just new glibc, and then trying to build them with new
glibc and make. It doesn't look like this approach would reduce 
rebuilds.

And, by the way, if updating a package to a new-and-shiny version which
boasts "fixed problems with fresh glibc" also requires fresh gcc, won't
it lead either to consiously breaking trunk or to making glibc-updates 
branch closer to stdenv-updates anyway? Updating GNU TLS to 3.0 seems to
make need GTK+-3.0 packages for glib-networking to work. It is just a
fresh example...



___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Re: Updating stdenv on Darwin

2011-08-30 Thread Ludovic Courtès 
Hi Shea,

s...@shealevy.com skribis:

> I'm working on modifying the darwin stdenv in such a way that it
> ultimately won't depend on any xcode tools. Can I use the darwin-updates
> branch for this?

Sure (I will no longer use it myself.)

> Also, do you know the rationale for using the Apple gcc fork instead of
> vanilla GNU gcc on darwin?

I believe GCC (the real one) would not actually work on Darwin, but I
can’t tell for sure.  I’ve been trying to get 4.6 compiled there, but I
see there’s still something wrong with libelf builds.

Anyway, I wholly support this endeavor.  Assuming GCC becomes available
on Darwin, I think it still makes sense to have Apple’s GCC around for
those doing portability testing on Hydra (Apple’s fork has a wealth of
unique bugs, spiced up with subtle incompatibilities, which makes it an
interesting test platform.)

Thanks,
Ludo’.

___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Re: We are on Hackage

2011-08-30 Thread Ludovic Courtès 
Hi!

Peter Simons  skribis:

> the Hackage site shows for every package which versions of that
> package are available in which distribution, and NixOS is now part
> of the distributions that are being tracked. For example:
>
>   http://hackage.haskell.org/package/pandoc

Out of curiosity, how does Hackage get that info?

Thanks,
Ludo’.

___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Re: new possible movement to git (?)

2011-08-30 Thread Peter Simons 
Hi Shea,

 > [We] have updated Make and gcc and glibc and all of that in nixpkgs,
 > and we want to test it all together and give hydra something to build
 > before we actually update stdenv to use the new tools, why not use a
 > branch specifically made for this purpose?

sure, I guess that's exactly what we are going to do.

Now, suppose we have updates of make, glibc, and gcc. The updates to
glibc and gcc work just fine, but the update to make breaks half of all
our builds. Do you think we should defer the updates to glibc and gcc
until all failures caused by the new make have been fixed? Or do you
think we might want to update glibc and gcc in 'master', and continue to
work on the make issue independently?

Take care,
Peter

___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Re: new possible movement to git (?)

2011-08-30 Thread Ludovic Courtès 
Hi!

Eelco Dolstra  skribis:

> So it would be nice if we had a more stable tree that users can update
> from safely.  For example, we could have these Nixpkgs/NixOS
> trees/branches:
>
> - An "unstable" tree which receives developer commits.  It might be in
> a broken state, so end users shouldn't use it.  Hydra continuously
> builds it.  Of course, complicated changes should be done in a feature
> tree/branch and pulled in when they're done.
>
> - A "tested" tree that automatically gets updated from the "unstable"
> tree when some set of Nixpkgs and NixOS tests succeed *and* the
> Nixpkgs channel is up to date.  This tree should be fairly safe to
> use.
>
> - A "stable" tree that gets updated manually and conservatively (e.g.,
> only security or stability updates).
>
> Does this sound reasonable?

Sounds like a great idea.

Automatic migration from ‘unstable’ to ‘tested’ may be tricky to
implement, but it would be really nice (this reminds me of ‘tla-pqm’, an
automatic patch queue manager [0].)

[...]

> Random point: should the NixOS and Nixpkgs trees be in the same
> repository?  I think so, since it allows them to be updated
> atomically, which is important given that Nixpkgs and NixOS changes
> are often related.

Agreed.

Thanks,
Ludo’.

[0] http://wiki.bazaar.canonical.com/PatchQueueManager

___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Re: new possible movement to git (?)

2011-08-30 Thread Peter Simons 
Hi Michael,

 > Two stdenv rebuilds where one would work is an annoyance.
 >
 > [...]
 >
 > Your way supposes trying to build them with just new glibc, and then
 > trying to build them with new glibc and make. It doesn't look like
 > this approach would reduce rebuilds.
 >
 > [...]

my impression is that we approach the question at hand using different
priorities. You seem to be concerned mostly with Hydra, i.e. you argue
that policies should be designed so that Hydra is happy, whereas I am
concerned with people, i.e. I argue for policies that simplify
development -- even if this means that Hydra has to perform builds that
could theoretically have been avoided.

Under those circumstances, I don't see how we could agree, so I suggest
we agree to disagree.

Take care,
Peter

___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Re: We are on Hackage

2011-08-30 Thread Peter Simons 
Hi Ludovic,

 > Out of curiosity, how does Hackage get that info?

Hackage regularly retrieves the package list from:

  http://cryp.to/haskell-in-nixpkgs.txt

That list is automatically generated by the utility found here:

  https://github.com/haskell4nix/package-list

Take care,
Peter

___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Re: new possible movement to git (?)

2011-08-30 Thread Michael Raskin 
<87ei03aw6p@write-only.cryp.to>
)
Mime-Version: 1.0
Content-type: text/plain; charset="UTF-8"

> > Two stdenv rebuilds where one would work is an annoyance.

> > Your way supposes trying to build them with just new glibc, and then
> > trying to build them with new glibc and make. It doesn't look like
> > this approach would reduce rebuilds.

>my impression is that we approach the question at hand using different
>priorities. You seem to be concerned mostly with Hydra, i.e. you argue
>that policies should be designed so that Hydra is happy, whereas I am
>concerned with people, i.e. I argue for policies that simplify
>development -- even if this means that Hydra has to perform builds that
>could theoretically have been avoided.

Well, I'd say that I care more about people using Nix, because usually
I use way more packages than dependencies of any given package (which 
I would rebuild while developing a package). Also, not everything I use
is built by Hydra...

Also, looks like state of the affairs in the parts of Nixpkgs we work on
is too different.

I could look for some examples where updating sanely meant simply 
updating everything first and sorting things out later; there obviously
are some updates where knowing whether new glibc or new gcc breaks the
build helps. I guess getting any numbers would be hard.

>Under those circumstances, I don't see how we could agree, so I suggest
>we agree to disagree.

Well, I am even more unconvinced - based on my experience with updates,
I would prefer stdenv-updates to be unified branch even for the process
of fixing the packages. Because easy things are just done and hard 
things are - in my experience with packaging - usually easy to trace 
back to single dependency and hard to fix anyway.

But you are right, it's not likely that we could find any new arguments.



___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Re: NixOS has a non-conforming value for _CS_PATH. Do we care?

2011-08-30 Thread shea 
> Hi Shea,
>
> Shea Levy  skribis:
>
>> glibc hard-codes confstr(_CS_PATH, ...) to be /bin:/usr/bin, which
>> obviously on NixOS cannot "be used as a value of the /PATH/
>> environment variable that accesses all of the standard utilities of
>> IEEE Std 1003.1-2001", rendering NixOS non-conforming with POSIX as
>> far as I can tell. Does anyone care about this? Does anyone have any
>> way to fix this without hard-coding paths to, e.g., coreutils in
>> glibc?
>
> I think we should patch libc’s sysdeps/unix/confstr.h to use
> "/var/run/current-system/sw/bin" as its value.  This path allows access
> to “all of the standard utilities”, as POSIX puts it.
>
> WDYT?
>
> Ludo’.
>

For now, I think it's the best solution. I'd prefer a static solution and
one that will work on non-Nixos systems, but neither goal seems readily
achievable given current tools.

Once multiple outputs are working, however, I think we can have a better
solution. The general idea (using only coreutils as an example) is to
first build glibc with _CS_PATH hard-coded to the coreutils used to build
glibc, then have a two-output build that first consists of copying over
the first glibc, rewriting that glibc's self-referential hashes to point
to the new output, building coreutils with the new glibc, then rewriting
the new glibc's hashes pointing to the old coreutils to point to the new
coreutils. There are several complexities with this (for example, the
bootstrap coreutils will have to have the same name as the final coreutils
so only the hash has to be overwritten), but I don't think they're
insurmountable and the end result would be something like:
/nix/store/hash-posix-coreutils and /nix/store/otherhash-posix-glibc,
where each has hard-coded references to the other. I've been thinking
about this for a while and obviously don't have any working example code
to illustrate the idea, so please let me know if the explanation was
confusing. If it wasn't confusing, what do you think as a long-term
solution? With the right amount of bootstrapping, we can use this
technique not only to have a correct _CS_PATH but also to get rid of all
the hard-codes to /bin/sh and instead hard-code to a store output. In
general, the technique can be used to solve most (all?) cyclic runtime
dependencies without dynamic lookups like $PATH.

Cheers,
Shea

___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Re: new possible movement to git (?)

2011-08-30 Thread Lluís Batlle i Rossell 
On Tue, Aug 30, 2011 at 08:12:33PM +0400, Michael Raskin wrote:
> >Under those circumstances, I don't see how we could agree, so I suggest
> >we agree to disagree.
> 
> Well, I am even more unconvinced - based on my experience with updates,
> I would prefer stdenv-updates to be unified branch even for the process
> of fixing the packages. Because easy things are just done and hard 
> things are - in my experience with packaging - usually easy to trace 
> back to single dependency and hard to fix anyway.

I think I'm with Michael about having stdenv-updates. I like the current process
of updating stdenv pieces, and at some point, decide on stabilisation, freeze
updates, and fix any problems there may be. Before stabilisation, we may have
some packages (or even platforms) not working, but still a big part working for
others to play with stdenv.

This does not mean that people may want to branch from stdenv-updates to fix or
update some pieces, but I'd have hydra busy building only stdenv-updates, for
example. Just to have a single point where people caring about stdenv can take a
look and see the status, and what can be done.
___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Re: new possible movement to git (?)

2011-08-30 Thread Peter Simons 
Hi Lluís,

 > I would have Hydra build only stdenv-updates.

in that case, I am glad that this decision is not up to you. Based
on , I have faith that the
people who do make those kind of decisions don't agree with your
point of view.

Take care,
Peter

___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Re: new possible movement to git (?)

2011-08-30 Thread Lluís Batlle i Rossell 
On Tue, Aug 30, 2011 at 07:34:36PM +0200, Peter Simons wrote:
> Hi Lluís,
> 
>  > I would have Hydra build only stdenv-updates.
> 
> in that case, I am glad that this decision is not up to you. Based
> on , I have faith that the
> people who do make those kind of decisions don't agree with your
> point of view.

Ah, well, I wrote too short what I meant.

I mean that I think hydra would be most useful to us if it does not bother
building constantly short-lived branches.
___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev

[Nix-commits] SVN commit: nix - r28933 - nixpkgs/trunk/pkgs/tools/filesystems/dosfstools

2011-08-30 Thread Eelco Dolstra 
Author: eelco
Date: Tue Aug 30 18:25:07 2011
New Revision: 28933
URL: https://svn.nixos.org/websvn/nix/?rev=28933&sc=1

Log:
* dosfstools updated to 3.0.11.

Modified:
   nixpkgs/trunk/pkgs/tools/filesystems/dosfstools/default.nix

Modified: nixpkgs/trunk/pkgs/tools/filesystems/dosfstools/default.nix
==
--- nixpkgs/trunk/pkgs/tools/filesystems/dosfstools/default.nix Tue Aug 30 
14:55:36 2011(r28932)
+++ nixpkgs/trunk/pkgs/tools/filesystems/dosfstools/default.nix Tue Aug 30 
18:25:07 2011(r28933)
@@ -1,11 +1,11 @@
 { stdenv, fetchurl }:
 
 stdenv.mkDerivation rec {
-  name = "dosfstools-3.0.9";
+  name = "dosfstools-3.0.11";
 
   src = fetchurl {
 url = "http://www.daniel-baumann.ch/software/dosfstools/${name}.tar.bz2";;
-sha256 = "13s5s0hvhmn7r4ppqmw8nqgdm5v5vc6r5j44kn87wl5cmrpnfqrz";
+sha256 = "1a6rzjy82f6579ywaln33g1wc7k8gbgjdss9q2q8daplac7pmcll";
   };
 
   makeFlags = "PREFIX=$(out)";
___
nix-commits mailing list
nix-comm...@cs.uu.nl
http://mail.cs.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] SVN commit: nix - r28934 - nixos/trunk/modules/tasks

2011-08-30 Thread Eelco Dolstra 
Author: eelco
Date: Tue Aug 30 18:25:54 2011
New Revision: 28934
URL: https://svn.nixos.org/websvn/nix/?rev=28934&sc=1

Log:
* Add fsck.vfat etc. to the default install.  Useful for USB sticks
  and stuff like that.

Modified:
   nixos/trunk/modules/tasks/filesystems.nix

Modified: nixos/trunk/modules/tasks/filesystems.nix
==
--- nixos/trunk/modules/tasks/filesystems.nix   Tue Aug 30 18:25:07 2011
(r28933)
+++ nixos/trunk/modules/tasks/filesystems.nix   Tue Aug 30 18:25:54 2011
(r28934)
@@ -5,7 +5,7 @@
 let
 
   # Packages that provide fsck backends.
-  fsPackages = [ pkgs.e2fsprogs pkgs.reiserfsprogs ];
+  fsPackages = [ pkgs.e2fsprogs pkgs.reiserfsprogs pkgs.dosfstools ];
 
 in
 
___
nix-commits mailing list
nix-comm...@cs.uu.nl
http://mail.cs.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] SVN commit: nix - r28935 - nixpkgs/trunk/pkgs/top-level

2011-08-30 Thread Rob Vermaas 
Author: rob
Date: Tue Aug 30 19:50:36 2011
New Revision: 28935
URL: https://svn.nixos.org/websvn/nix/?rev=28935&sc=1

Log:
add enum-0.4.4

Modified:
   nixpkgs/trunk/pkgs/top-level/python-packages.nix

Modified: nixpkgs/trunk/pkgs/top-level/python-packages.nix
==
--- nixpkgs/trunk/pkgs/top-level/python-packages.nixTue Aug 30 18:25:54 
2011(r28934)
+++ nixpkgs/trunk/pkgs/top-level/python-packages.nixTue Aug 30 19:50:36 
2011(r28935)
@@ -373,6 +373,25 @@
   };
 
 
+  enum = buildPythonPackage rec {
+name = "enum-0.4.4";
+
+src = fetchurl {
+  url = "http://pypi.python.org/packages/source/e/enum/${name}.tar.gz";;
+  md5 = "ce75c7c3c86741175a84456cc5bd531e";
+};
+
+buildInputs = [ ];
+
+propagatedBuildInputs = [ ];
+
+meta = {
+  homepage = http://pypi.python.org/pypi/enum/;
+  description = "Robust enumerated type support in Python.";
+};
+  };
+
+
   eventlet = buildPythonPackage rec {
 name = "eventlet-0.9.16";
 
___
nix-commits mailing list
nix-comm...@cs.uu.nl
http://mail.cs.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] SVN commit: nix - r28936 - nixpkgs/trunk/pkgs/top-level

2011-08-30 Thread Rob Vermaas 
Author: rob
Date: Tue Aug 30 19:57:29 2011
New Revision: 28936
URL: https://svn.nixos.org/websvn/nix/?rev=28936&sc=1

Log:
add protobuf based on the default version in nixpkgs

Modified:
   nixpkgs/trunk/pkgs/top-level/python-packages.nix

Modified: nixpkgs/trunk/pkgs/top-level/python-packages.nix
==
--- nixpkgs/trunk/pkgs/top-level/python-packages.nixTue Aug 30 19:50:36 
2011(r28935)
+++ nixpkgs/trunk/pkgs/top-level/python-packages.nixTue Aug 30 19:57:29 
2011(r28936)
@@ -1180,6 +1180,19 @@
   };
 
 
+  protobuf = buildPythonPackage rec {
+inherit (pkgs.protobuf) name src;
+
+propagatedBuildInputs = [pkgs.protobuf];
+sourceRoot = "${name}/python";
+
+meta = {
+  description = "Protocol Buffers are Google's data interchange format.";
+  homepage = http://code.google.com/p/protobuf/;
+};
+  };
+
+
   psycopg2 = buildPythonPackage rec {
 name = "psycopg2-2.0.13";
 
___
nix-commits mailing list
nix-comm...@cs.uu.nl
http://mail.cs.uu.nl/mailman/listinfo/nix-commits

[Nix-dev] maxima broken (was: SVN commit: nix - r28845 - nixpkgs/trunk/pkgs/development/compilers/sbcl)

2011-08-30 Thread Peter Simons 
Hi Michael,

 > Update SBCL

it appears that SBCL update broke Maxima. When I run it on Linux/x86_64,
the result is this:

  fatal error encountered in SBCL pid 31679(tid 140737354098432):
  can't load .core for different runtime, sorry

I guessed that maybe the wrapper script used by Maxima is broken in some
way, so I figured out the appropriate command line and ran it directly,
but the result is the same:

  /nix/store/jylnl3mk4idzyw5zb78maprwsyxynv83-sbcl-1.0.51/bin/sbcl \
--core \

/nix/store/22gcg82x0787anzpaz0mjryaba5n1lag-maxima-5.25.0/lib/maxima/5.25.0/binary-sbcl/maxima.core
 \
--noinform --end-runtime-options --eval '(cl-user::run)' \
--end-toplevel-options
  fatal error encountered in SBCL pid 540(tid 140737354098432):
  can't load .core for different runtime, sorry

My lisp-fu is very weak, and I am at a loss how to debug let alone fix
this issue. Do you have any idea what might be causing this failure?

Note that the Maxima build itself worked fine:

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

So I assume that the problem lies in the way SBCL is called?

Take care,
Peter

___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Re: NixOS has a non-conforming value for _CS_PATH. Do we care?

2011-08-30 Thread Ludovic Courtès 
Hi,

>> I think we should patch libc’s sysdeps/unix/confstr.h to use
>> "/var/run/current-system/sw/bin" as its value.  This path allows access
>> to “all of the standard utilities”, as POSIX puts it.

[...]

> For now, I think it's the best solution. I'd prefer a static solution and
> one that will work on non-Nixos systems,

By definition, systems on which GNU libc is built off Nixpkgs are called
“NixOS”, so there’s nothing to worry about here.  :-)

> Once multiple outputs are working,

[...]

Woow, this seems really over-engineered to me;
/var/run/current-system/sw/bin is really the right location on NixOS.

Thanks,
Ludo’.
___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] maxima broken (was: SVN commit: nix - r28845 -nixpkgs/trunk/pkgs/development/compilers/sbcl)

2011-08-30 Thread Michael Raskin 
>  fatal error encountered in SBCL pid 31679(tid 140737354098432):
>  can't load .core for different runtime, sorry

Looks like this version of Maxima has a prepared core file for SBCL 1.0.50
and is trying to load it in 1.0.51. 

>I guessed that maybe the wrapper script used by Maxima is broken in some
>way, so I figured out the appropriate command line and ran it directly,
>but the result is the same:
>
>  /nix/store/jylnl3mk4idzyw5zb78maprwsyxynv83-sbcl-1.0.51/bin/sbcl \
>--core \
>
> /nix/store/22gcg82x0787anzpaz0mjryaba5n1lag-maxima-5.25.0/lib/maxima/5.25.0/binary-sbcl/maxima.core
>  \
>--noinform --end-runtime-options --eval '(cl-user::run)' \
>--end-toplevel-options
>  fatal error encountered in SBCL pid 540(tid 140737354098432):
>  can't load .core for different runtime, sorry

Hm, very strange.

I have the same Maxima hash, and it works...

Even more, I run the same expanded command and it still works

>My lisp-fu is very weak, and I am at a loss how to debug let alone fix
>this issue. Do you have any idea what might be causing this failure?

>Note that the Maxima build itself worked fine:
>
>  http://hydra.nixos.org/build/1283060

Fresh Maxima does work for me on x86-64 arch. 

>So I assume that the problem lies in the way SBCL is called?

Could you please search 1[.]0[.]..[.]nixos in the core file?

I wonder what version it is for and how it got built..



___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Re: maxima broken

2011-08-30 Thread Peter Simons 
Hi Michael,

 > Hm, very strange. I have the same Maxima hash, and it works...

duh, this is very strange, indeed. I just un-installed maxima from my
profile, ran the garbage collector, and then re-installed it from
scratch. Now, it works!

I'm not sure how to explain this phenomenon.

Anyway, thank you for the quick response.

Take care,
Peter

___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Re: NixOS has a non-conforming value for _CS_PATH. Do we care?

2011-08-30 Thread Yury G. Kudryashov 
Ludovic Courtès wrote:

> Hi,
> 
>> Once multiple outputs are working,
> 
> [...]
> 
> Woow, this seems really over-engineered to me;
> /var/run/current-system/sw/bin is really the right location on NixOS.
Then 'nix on traditional Linux' will have a non-conforming value of 
_CS_PATH.

If we do hardcode /var/run/current-system/sw in many places, I do not 
understand why it is better than /usr.
-- 
Yury G. Kudryashov,
mailto: ur...@mccme.ru

___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Re: NixOS has a non-conforming value for _CS_PATH. Do we care?

2011-08-30 Thread Lluís Batlle i Rossell 
On Tue, Aug 30, 2011 at 11:38:39PM +0200, Ludovic Courtès wrote:
> Hi,
> 
> >> I think we should patch libc’s sysdeps/unix/confstr.h to use
> >> "/var/run/current-system/sw/bin" as its value.  This path allows access
> >> to “all of the standard utilities”, as POSIX puts it.
> 
> [...]
> 
> > For now, I think it's the best solution. I'd prefer a static solution and
> > one that will work on non-Nixos systems,
> 
> By definition, systems on which GNU libc is built off Nixpkgs are called
> “NixOS”, so there’s nothing to worry about here.  :-)

Any GNU/Linux that used nixpkgs would be using the GNU libc in nixpkgs, and not
'their'. We use the 'pure' stdenvLinux in any GNU/Linux (for the supported
platforms).
___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev