From ludovic.courtes at inria.fr Thu Mar 3 16:54:35 2011 From: ludovic.courtes at inria.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Thu, 03 Mar 2011 16:54:35 +0100 Subject: [Nix-dev] How do parallel builds scale? Message-ID: <87fwr4ryh0.fsf@gnu.org> Hello! As part of Hubble, I ran a series of package build time measurements using Nixpkgs with ?enableParallelBuild = true? on a 32-core machine of a cluster at INRIA. I recompiled ~800 derivations of Nixpkgs, with ?build-cores? in [1..32]. The results are summarized here: http://hubble.gforge.inria.fr/parallel-builds.html Per-package details are at: http://hubble.gforge.inria.fr/parallel-build-details.html In short, package build scale very poorly, and more than half of the packages didn?t scale beyond 2. The ?build? phase itself scales better, but for half of the packages the speedup is lower than 4. Thanks, Ludo?. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110303/2881300a/attachment.bin From marco-oweber at gmx.de Thu Mar 3 18:05:08 2011 From: marco-oweber at gmx.de (Marc Weber) Date: Thu, 03 Mar 2011 17:05:08 +0000 Subject: [Nix-dev] How do parallel builds scale? In-Reply-To: <87fwr4ryh0.fsf@gnu.org> References: <87fwr4ryh0.fsf@gnu.org> Message-ID: <1299171468-sup-2970@localhost.localdomain> Hi ludo, I've seen your post (autoconf mailinglist) asking about how to scale configure scripts. I don't think there is an easy way. :( Maybe using cmake could be an option. More interesting: Have you also numbers about whether some of those builds failed due to -jX ? That was one of the main arguments against a feature like enableParallelBuilding in the past (?). And discussion stopped at exactly this point. I've seen an internal make failure for some packages ocassionally. Eg ruby19: INTERNAL: Exiting with 6 jobserver tokens available; should be 4! > The build phase itself scales better, but for half of the packages the > speedup is lower than 4. Many projects (eg HaXe or terraview) just don't care enough about it for whatever reason. I've had another idea in mind: Building up a database listing the resources a build takes (both IO and CPU). Then it would be possible to calculate an estimated wait time for rebuilds - or maybe it would be possible to optimize the order of builds or such. I don't care enough to work on it right now. Marc Weber From viriketo at gmail.com Thu Mar 3 20:06:48 2011 From: viriketo at gmail.com (=?iso-8859-1?Q?Llu=EDs?= Batlle i Rossell) Date: Thu, 3 Mar 2011 20:06:48 +0100 Subject: [Nix-dev] hashed mirrors Message-ID: <20110303190647.GW32257@vicerveza.homeunix.net> Hello, today nixos.org is down, connection attempts by curl get hanged. There is something in the mirrors-list named "hashedMirrors", that I finally managed to bypass with something like this: NIX_HASHED_MIRRORS=blabla nix-build -A mypackage ... Otherwise, it all hanged in a curl call that tried to get something from nixos.org/tarballs/... What is this?! From marco-oweber at gmx.de Thu Mar 3 21:49:13 2011 From: marco-oweber at gmx.de (Marc Weber) Date: Thu, 03 Mar 2011 20:49:13 +0000 Subject: [Nix-dev] How do parallel builds scale? In-Reply-To: <1299171468-sup-2970@localhost.localdomain> References: <87fwr4ryh0.fsf@gnu.org> <1299171468-sup-2970@localhost.localdomain> Message-ID: <1299184759-sup-6214@localhost.localdomain> Looking at some graphics: http://hubble.gforge.inria.fr/parallel-builds.html You plot "number of packages" against "speedup" without saying which packages you've used. Without that info the plots are useless. I mean I don't know whether the first 10 packages are python packages only and I don't know whether the 20 packages contain the first 10. IMHO you should publish either enough data so that your results could be verified or nothing. By changing the formatting a very little bit you can make the table http://hubble.gforge.inria.fr/parallel-build-details.html much more readable. Its confusing that the first row has configure, build, check but the following only have configure,build. Without asking Firefox to highlight cells I was not able to read anything. its because "2m 18s" is displayed using two rows. You can enhance this easily by forcing col width ensuring that no line breaks occur or use white-space: nowrap; or such. Thanks Marc Weber From simons at cryp.to Thu Mar 3 22:51:56 2011 From: simons at cryp.to (Peter Simons) Date: Thu, 03 Mar 2011 22:51:56 +0100 Subject: [Nix-dev] Re: How do parallel builds scale? References: <87fwr4ryh0.fsf@gnu.org> Message-ID: <877hcfan43.fsf@write-only.cryp.to> Hi Ludovic, > http://hubble.gforge.inria.fr/parallel-builds.html > http://hubble.gforge.inria.fr/parallel-build-details.html these results are very interesting -- thank you for sharing that data. > In short, package build scale very poorly, and more than half of the > packages didn?t scale beyond 2. The majority of open source software is built with Automake, and Automake is not particularly good at utilizing several cores. The most significant problem is that the common setting SUBDIRS = foo bar causes these two directories to be built *sequentially*. Automake won't even try to build 'bar' unless 'foo' is complete. There are historical reasons for that behavior, of course, but it's a really bad choice as far as parallel building is concerned. A build system that is superior in that regard is Boost.Jam, and indeed your numbers show that the Boost libraries benefit a *lot* from having several cores available. Take care, Peter From viriketo at gmail.com Thu Mar 3 23:00:58 2011 From: viriketo at gmail.com (=?iso-8859-1?Q?Llu=EDs?= Batlle i Rossell) Date: Thu, 3 Mar 2011 23:00:58 +0100 Subject: [Nix-dev] Re: How do parallel builds scale? In-Reply-To: <877hcfan43.fsf@write-only.cryp.to> References: <87fwr4ryh0.fsf@gnu.org> <877hcfan43.fsf@write-only.cryp.to> Message-ID: <20110303220056.GZ32257@vicerveza.homeunix.net> On Thu, Mar 03, 2011 at 10:51:56PM +0100, Peter Simons wrote: > A build system that is superior in that regard is Boost.Jam, and indeed > your numbers show that the Boost libraries benefit a *lot* from having > several cores available. For what I remember, jam takes almost 2GB of RAM to prepare the boost build. :) It requires some big system to build boost, mostly because of jam. In any case, I never used jam beyond building boost. From ludo at gnu.org Thu Mar 3 23:31:31 2011 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Thu, 03 Mar 2011 23:31:31 +0100 Subject: [Nix-dev] Re: How do parallel builds scale? References: <87fwr4ryh0.fsf@gnu.org> <1299171468-sup-2970@localhost.localdomain> Message-ID: <87ei6nx2d8.fsf@gnu.org> Hi Marc, Marc Weber writes: > More interesting: Have you also numbers about whether some of those > builds failed due to -jX ? Sort of. If you look at the plots at , you?ll see that the total number of packages in the ?-j32? curve is slightly lower than that of ?-j2?. It?s less than 10% off the top of my head, but I haven?t looked in detail. > I've had another idea in mind: Building up a database listing the > resources a build takes (both IO and CPU). Then it would be possible to > calculate an estimated wait time for rebuilds - or maybe it would be > possible to optimize the order of builds or such. That?s the idea: . :-) Thanks, Ludo?. From ludovic.courtes at inria.fr Thu Mar 3 23:34:09 2011 From: ludovic.courtes at inria.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Thu, 03 Mar 2011 23:34:09 +0100 Subject: [Nix-dev] Re: How do parallel builds scale? References: <87fwr4ryh0.fsf@gnu.org> <1299171468-sup-2970@localhost.localdomain> <1299184759-sup-6214@localhost.localdomain> Message-ID: <8762rzx28u.fsf@gnu.org> Marc Weber writes: > Looking at some graphics: > http://hubble.gforge.inria.fr/parallel-builds.html > > You plot "number of packages" against "speedup" > without saying which packages you've used. It?s all the packages that have been built, i.e., all those listed at (or a subset thereof, as indicated.) > Without asking Firefox to highlight cells I was not able to read > anything. its because "2m 18s" is displayed using two rows. > You can enhance this easily by forcing col width ensuring that no line > breaks occur or use white-space: nowrap; or such. Hmm right. Thanks, Ludo?. From ludovic.courtes at inria.fr Thu Mar 3 23:36:02 2011 From: ludovic.courtes at inria.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Thu, 03 Mar 2011 23:36:02 +0100 Subject: [Nix-dev] Re: How do parallel builds scale? References: <87fwr4ryh0.fsf@gnu.org> <877hcfan43.fsf@write-only.cryp.to> Message-ID: <87sjv3vnl9.fsf@gnu.org> Hi Peter, Peter Simons writes: > The majority of open source software is built with Automake, and Automake > is not particularly good at utilizing several cores. The most significant > problem is that the common setting > > SUBDIRS = foo bar > > causes these two directories to be built *sequentially*. True, but Automake does allow for non-recursive makefiles, too (info "(automake) Alternative"). Some projects (admittedly not the majority) pay attention to avoiding recursive makefiles. Thanks, Ludo?. From marco-oweber at gmx.de Thu Mar 3 23:49:10 2011 From: marco-oweber at gmx.de (Marc Weber) Date: Thu, 03 Mar 2011 22:49:10 +0000 Subject: [Nix-dev] Re: How do parallel builds scale? In-Reply-To: <8762rzx28u.fsf@gnu.org> References: <87fwr4ryh0.fsf@gnu.org> <1299171468-sup-2970@localhost.localdomain> <1299184759-sup-6214@localhost.localdomain> <8762rzx28u.fsf@gnu.org> Message-ID: <1299192287-sup-5338@localhost.localdomain> Excerpts from ludovic.courtes's message of Thu Mar 03 22:34:09 +0000 2011: > Marc Weber writes: > > > Looking at some graphics: > > http://hubble.gforge.inria.fr/parallel-builds.html > > > > You plot "number of packages" against "speedup" > > without saying which packages you've used. > > It\xe2\x80\x99s all the packages that have been built, i.e., all those listed at > (or a subset > thereof, as indicated.) That "as indicated" is what I haven't found. From plots I see that you've build 7 [1] packages. Now your listed is sorted alphabetically starting by 0) average (special package?) 1) 4store 2) GConf 3) ImageMagick ... so may I conclude that 1,2,3 are elements of the first subset ?! [1]: figure: the "Scalability of the ?check? phase." let's me assume that the lowest blue * is at "number of packages" 7. Sorry, I still don't get it. Marc Weber From marco-oweber at gmx.de Fri Mar 4 02:06:53 2011 From: marco-oweber at gmx.de (Marc Weber) Date: Fri, 04 Mar 2011 01:06:53 +0000 Subject: [Nix-dev] Re: How do parallel builds scale? In-Reply-To: <1299192287-sup-5338@localhost.localdomain> References: <87fwr4ryh0.fsf@gnu.org> <1299171468-sup-2970@localhost.localdomain> <1299184759-sup-6214@localhost.localdomain> <8762rzx28u.fsf@gnu.org> <1299192287-sup-5338@localhost.localdomain> Message-ID: <1299200563-sup-6023@localhost.localdomain> If you need more speed you could run the check phase separately Example: foo would refer to the build foo.checked would refer to the checked version which depends on all map (x: x.checked) (foo.buildInputs foo.propagatedBuildInputs) Final consumers (nixos rebuild or user envs) should depend on the .checked versions then. Then depending packages can start building while check phases are still run.. Probably there are not enough check phases justifying the effort yet. Marc Weber From urkud+nix at ya.ru Fri Mar 4 07:24:24 2011 From: urkud+nix at ya.ru (Yury G. Kudryashov) Date: Fri, 04 Mar 2011 09:24:24 +0300 Subject: [Nix-dev] Re: Re: [Nix-commits] SVN commit: nix - r26057 - in nixpkgs/trunk/pkgs: desktops/kde-4.5 desktops/kde-4.5/support/strigi desktops/kde-4.6 desktops/kde-4.6/support/strigi development/libraries/strigi top-level References: <20110222115449.E1F99108C048@mx3.tudelft.nl> <4D6797F0.3040309@tudelft.nl> <4D679B86.5040908@tudelft.nl> Message-ID: Eelco Dolstra wrote: > Hi, > > On 02/25/2011 01:05 PM, Yury G. Kudryashov wrote: > >>> On 02/22/2011 12:54 PM, Yury G. Kudryashov wrote: >>> >>>> Log: >>>> Move strigi outside of kde-4.x >>> >>> I get an evaluation error in the iso_graphical job (and others) because >>> of this change: >> How can I evaluate this test locally? I need trace... >> I can't find where something requests kde4.strigi. > > I see it's referenced in > nixos/modules/services/x11/desktop-managers/kde4.nix. Sorry for a long silence. This was fixed by Karn Kallio in rev26061. From e.dolstra at tudelft.nl Fri Mar 4 11:52:46 2011 From: e.dolstra at tudelft.nl (Eelco Dolstra) Date: Fri, 04 Mar 2011 11:52:46 +0100 Subject: [Nix-dev] Re: [Nix-commits] SVN commit: nix - r26152 - in nixpkgs/trunk/pkgs/development/python-modules: pyqt python-sip In-Reply-To: <20110304094829.B255A108C06D@mx3.tudelft.nl> References: <20110304094829.B255A108C06D@mx3.tudelft.nl> Message-ID: <4D70C47E.7030209@tudelft.nl> Hi, On 03/04/2011 10:48 AM, Llu?s Batlle wrote: > Author: viric > Date: Fri Mar 4 09:48:29 2011 > New Revision: 26152 > URL: https://svn.nixos.org/websvn/nix/?rev=26152&sc=1 > > Log: > Updating pyqt and sip because the 'src' there mentioned is not at the urls anymore. This change breaks KDE, see http://hydra.nixos.org/build/946260 -- Eelco Dolstra | http://www.st.ewi.tudelft.nl/~dolstra/ From viriketo at gmail.com Fri Mar 4 13:13:12 2011 From: viriketo at gmail.com (=?iso-8859-1?Q?Llu=EDs?= Batlle i Rossell) Date: Fri, 4 Mar 2011 13:13:12 +0100 Subject: [Nix-dev] Re: [Nix-commits] SVN commit: nix - r26152 - in nixpkgs/trunk/pkgs/development/python-modules: pyqt python-sip In-Reply-To: <4D70C47E.7030209@tudelft.nl> References: <20110304094829.B255A108C06D@mx3.tudelft.nl> <4D70C47E.7030209@tudelft.nl> Message-ID: <20110304121310.GB32257@vicerveza.homeunix.net> On Fri, Mar 04, 2011 at 11:52:46AM +0100, Eelco Dolstra wrote: > Hi, > > On 03/04/2011 10:48 AM, Llu?s Batlle wrote: > > >Author: viric > >Date: Fri Mar 4 09:48:29 2011 > >New Revision: 26152 > >URL: https://svn.nixos.org/websvn/nix/?rev=26152&sc=1 > > > >Log: > >Updating pyqt and sip because the 'src' there mentioned is not at the urls anymore. > > This change breaks KDE, see http://hydra.nixos.org/build/946260 Grrr I can only look at it later today. From ben.franksen at online.de Fri Mar 4 16:18:30 2011 From: ben.franksen at online.de (Benjamin Franksen) Date: Fri, 04 Mar 2011 16:18:30 +0100 Subject: [Nix-dev] environment.systemPackages Message-ID: I tried to adapt the example for environment.systemPackages in the NixOS manual, but nixos-rebuild complains that pkgs is not defined. This is what I tried: nixos# cat /etc/nixos/configuration.nix { boot.initrd.kernelModules = [ "ata_piix" ]; boot.kernelModules = [ ]; boot.loader.grub.device = "/dev/sda"; fileSystems = [ { device = "/dev/sda1"; mountPoint = "/"; fsType = "ext3"; } ]; environment.systemPackages = [ pkgs.zsh ]; nix.maxJobs = 1; services.ntp.servers = [ "charm.acc.bessy.de" ]; services.xserver.videoDriver = "vesa"; services.xserver.enable = true; services.xserver.desktopManager.kde4.enable = true; services.xserver.displayManager.kdm.enable = true; services.xserver.autorun = true; services.xserver.desktopManager.default = "kde4"; services.xserver.windowManager.xmonad.enable = true; } How can I make the pkgs variable visible here? Cheers Ben From e.dolstra at tudelft.nl Fri Mar 4 16:20:51 2011 From: e.dolstra at tudelft.nl (Eelco Dolstra) Date: Fri, 04 Mar 2011 16:20:51 +0100 Subject: [Nix-dev] environment.systemPackages In-Reply-To: References: Message-ID: <4D710353.6050601@tudelft.nl> Hi, On 03/04/2011 04:18 PM, Benjamin Franksen wrote: > How can I make the pkgs variable visible here? Add the following line to the top of the file: { pkgs, ... }: Lots of examples of configurations can be found here: https://svn.nixos.org/repos/nix/configurations/trunk/ -- Eelco Dolstra | http://www.st.ewi.tudelft.nl/~dolstra/ From benjamin.franksen at helmholtz-berlin.de Fri Mar 4 16:24:34 2011 From: benjamin.franksen at helmholtz-berlin.de (Benjamin Franksen) Date: Fri, 04 Mar 2011 16:24:34 +0100 Subject: [Nix-dev] environment.systemPackages Message-ID: [Sorry if this is a duplicated post, I previously sent the same message with a wrong identity] I tried to adapt the example for environment.systemPackages in the NixOS manual, but nixos-rebuild complains that pkgs is not defined. This is what I tried: nixos# cat /etc/nixos/configuration.nix { boot.initrd.kernelModules = [ "ata_piix" ]; boot.kernelModules = [ ]; boot.loader.grub.device = "/dev/sda"; fileSystems = [ { device = "/dev/sda1"; mountPoint = "/"; fsType = "ext3"; } ]; environment.systemPackages = [ pkgs.zsh ]; nix.maxJobs = 1; services.ntp.servers = [ "charm.acc.bessy.de" ]; services.xserver.videoDriver = "vesa"; services.xserver.enable = true; services.xserver.desktopManager.kde4.enable = true; services.xserver.displayManager.kdm.enable = true; services.xserver.autorun = true; services.xserver.desktopManager.default = "kde4"; services.xserver.windowManager.xmonad.enable = true; } How can I make the pkgs variable visible here? Cheers Ben From benjamin.franksen at helmholtz-berlin.de Fri Mar 4 16:34:24 2011 From: benjamin.franksen at helmholtz-berlin.de (Benjamin Franksen) Date: Fri, 04 Mar 2011 16:34:24 +0100 Subject: [Nix-dev] Re: environment.systemPackages References: <4D710353.6050601@tudelft.nl> Message-ID: Eelco Dolstra wrote: >> How can I make the pkgs variable visible here? > > Add the following line to the top of the file: > > { pkgs, ... }: > > Lots of examples of configurations can be found here: > https://svn.nixos.org/repos/nix/configurations/trunk/ Thanks. I looked at these examples and saw such a line but, well... I just didn't think this could work. I mean, with this addition /etc/nixos/configuration.nix becomes a function, right? Is there a special trick that makes nixos interpret the code as either a function or a plain value? Please forgive my beginner's confusion, I have some problems groking the nix language (the only functional languages I know are all statically typed). Cheers Ben From e.dolstra at tudelft.nl Fri Mar 4 16:55:44 2011 From: e.dolstra at tudelft.nl (Eelco Dolstra) Date: Fri, 04 Mar 2011 16:55:44 +0100 Subject: [Nix-dev] Re: environment.systemPackages In-Reply-To: References: <4D710353.6050601@tudelft.nl> Message-ID: <4D710B80.3030202@tudelft.nl> Hi, On 03/04/2011 04:34 PM, Benjamin Franksen wrote: > Eelco Dolstra wrote: >>> How can I make the pkgs variable visible here? >> >> Add the following line to the top of the file: >> >> { pkgs, ... }: >> >> Lots of examples of configurations can be found here: >> https://svn.nixos.org/repos/nix/configurations/trunk/ > > Thanks. I looked at these examples and saw such a line but, well... I just > didn't think this could work. I mean, with this addition > /etc/nixos/configuration.nix becomes a function, right? Is there a special > trick that makes nixos interpret the code as either a function or a plain > value? Yes, there is, which is rather ugly :-) Basically modules are called by doing if builtins.isFunction module then module { ... args ... } else module But this is really for backwards compatibility. It's best to always write modules as functions. > Please forgive my beginner's confusion, I have some problems groking the nix > language (the only functional languages I know are all statically typed). Indeed we can get away with this only because we don't have static typing. -- Eelco Dolstra | http://www.st.ewi.tudelft.nl/~dolstra/ From marco-oweber at gmx.de Fri Mar 4 16:56:50 2011 From: marco-oweber at gmx.de (Marc Weber) Date: Fri, 04 Mar 2011 15:56:50 +0000 Subject: [Nix-dev] environment.systemPackages In-Reply-To: References: Message-ID: <1299254063-sup-4126@localhost.localdomain> You should have seen a warning. configuration.nix has changed: old (in the past configuration.nix was not a function): { } and pkgs was passed to many options. However this was changed: new: { pkgs, config, ...} : { } Then pkgs is defined. If you still have trouble post again Marc Weber From benjamin.franksen at helmholtz-berlin.de Fri Mar 4 18:07:23 2011 From: benjamin.franksen at helmholtz-berlin.de (Benjamin Franksen) Date: Fri, 04 Mar 2011 18:07:23 +0100 Subject: [Nix-dev] Re: environment.systemPackages References: <4D710353.6050601@tudelft.nl> <4D710B80.3030202@tudelft.nl> Message-ID: Eelco Dolstra wrote: >> Thanks. I looked at these examples and saw such a line but, well... I >> just didn't think this could work. I mean, with this addition >> /etc/nixos/configuration.nix becomes a function, right? Is there a >> special trick that makes nixos interpret the code as either a function or >> a plain value? > > Yes, there is, which is rather ugly :-) Basically modules are called by > doing > > if builtins.isFunction module > then module { ... args ... } > else module > > But this is really for backwards compatibility. It's best to always > write modules as functions. > >> Please forgive my beginner's confusion, I have some problems groking the >> nix language (the only functional languages I know are all statically >> typed). > > Indeed we can get away with this only because we don't have static typing. Ah, okay, everything is clear now. I suggest to adapt the example NixOS configuration in the manual ("Example 1.2. NixOS configuration") to the new function style, then. Cheers Ben From marco-oweber at gmx.de Fri Mar 4 21:16:50 2011 From: marco-oweber at gmx.de (Marc Weber) Date: Fri, 04 Mar 2011 20:16:50 +0000 Subject: [Nix-dev] announce: preliminary version of nixpkgs-python-overlay Message-ID: <1299269250-sup-2807@localhost.localdomain> Basic idea: dump data from pypi package index. Make Nix read the dump creating derivations on the fly: Example: devEnv = pythonEnv26 { name = "libs-coding-style"; # p = { pylint = ["<" "2.0" ]; } force pylint version being less # than 2.0 names = [ "pylint" "pyflakes" ]; }; In a similar way you could make it create dependencies for other packages such as gimp or inkscape .. If you install this you'll get a script which you can use this way: bin/python-env-libs-coding-style bash then NIX_PYTHON_SITES is defined and the package are put in $PATH so that you can run pyflake and pylint from commandline. Package dependencies is taken care of if the constraints are correct. The solver will fail if two packages choose different versions of the same package. Then you can choose either version by using a constraint as shown above. I haven't done too much testing yet and there are still some problems to solve such as find out which python package works with what python version. Ping back if you're interested in testing packages etc. Desigs is very similar to the python-ruby-overlay I announced earlier doing the same for rubyforge. repos: http://gitorious.org/nixpkgs-python-overlay -> nixpkgs-python-overlay-dump (script dumping pypi) -> nixpgks-python-overlay-packages (a dump I made for you which will be updated by cron job once a week soon) -> nixpgks-pyhton-overlay (the nix code doing all the stuff) The code is based on the arbitrary-strings-as-names patch and maybe some more things I put into my nix/nixos repositories (branches nix2/marc and nix2/nix-python-sites) So it won't work with current trunk. The purpose of the dump is to abstract away the tedious task of getting source tarballs and creating derivations. So only the manual nixpkgs specific adjustments have to take place. (hopefully). Marc Weber From tierpluspluslists at gmail.com Fri Mar 4 21:52:52 2011 From: tierpluspluslists at gmail.com (Karn Kallio) Date: Fri, 4 Mar 2011 16:22:52 -0430 Subject: [Nix-dev] missing glib 2.28 Message-ID: <201103041622.53114.tierpluspluslists@gmail.com> a new version of glib is in all-packages.nix: glib_2_28 = callPackage ../development/libraries/glib/2.28.x.nix {} but the corresponding 2.28.x.nix is missing ... nix-env reports error: getting status of `/etc/nixos/nixpkgs/pkgs/development/libraries/glib/2.28.x.nix': No such file or directory From urkud+nix at ya.ru Sat Mar 5 13:16:16 2011 From: urkud+nix at ya.ru (Yury G. Kudryashov) Date: Sat, 05 Mar 2011 15:16:16 +0300 Subject: [Nix-dev] Re: environment.systemPackages References: Message-ID: Benjamin Franksen wrote: > services.ntp.servers = [ "charm.acc.bessy.de" ]; > > services.xserver.videoDriver = "vesa"; > services.xserver.enable = true; > services.xserver.desktopManager.kde4.enable = true; > services.xserver.displayManager.kdm.enable = true; > services.xserver.autorun = true; > services.xserver.desktopManager.default = "kde4"; > services.xserver.windowManager.xmonad.enable = true; Use services = { ntp.servers = ...; xserver = { ...; }; } instead. AFAIR, it is illegal to have a.b = ...; a.c = ...; in nix. From marco-oweber at gmx.de Sat Mar 5 13:33:20 2011 From: marco-oweber at gmx.de (Marc Weber) Date: Sat, 05 Mar 2011 12:33:20 +0000 Subject: [Nix-dev] Re: environment.systemPackages In-Reply-To: References: Message-ID: <1299328298-sup-8180@localhost.localdomain> > instead. AFAIR, it is illegal to have a.b = ...; a.c = ...; in nix. Maybe this used to be the case. My Nix can parse it: { a.b = "ath"; a.c = "foobar"; } yields { a = { b = "ath"; c = "foobar"; }; } I'm too lazy too lookup when the change (if so) took place. Marc Weber From ludo at gnu.org Sat Mar 5 15:23:29 2011 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Sat, 05 Mar 2011 15:23:29 +0100 Subject: [Nix-dev] Re: environment.systemPackages References: <4D710353.6050601@tudelft.nl> <4D710B80.3030202@tudelft.nl> Message-ID: <87d3m5bq8u.fsf@gnu.org> Hi, Eelco Dolstra writes: > On 03/04/2011 04:34 PM, Benjamin Franksen wrote: >> Please forgive my beginner's confusion, I have some problems groking the nix >> language (the only functional languages I know are all statically typed). > > Indeed we can get away with this only because we don't have static typing. With dynamic typing the situation would be better with an extensible type system. Disjoint types could be defined for all the kinds of objects that are manipulated, rather than using attribute sets and strings for everything. This would significantly improve error reporting, for instance. The delusion of DSLs... Thanks, Ludo?. From vcunat at gmail.com Sat Mar 5 18:47:51 2011 From: vcunat at gmail.com (=?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?=) Date: Sat, 5 Mar 2011 18:47:51 +0100 Subject: [Nix-dev] Re: How do parallel builds scale? In-Reply-To: <1299200563-sup-6023@localhost.localdomain> References: <87fwr4ryh0.fsf@gnu.org> <1299171468-sup-2970@localhost.localdomain> <1299184759-sup-6214@localhost.localdomain> <8762rzx28u.fsf@gnu.org> <1299192287-sup-5338@localhost.localdomain> <1299200563-sup-6023@localhost.localdomain> Message-ID: On 4 March 2011 02:06, Marc Weber wrote: > If you need more speed you could run the check phase separately Certainly, especially extensive check phases on critical paths (if there are any) are better to be separated. By the way, do you know how much hydra waits because of waiting for dependencies? I think it shouldn't be too difficult to always find something else to build on hydra, but e. g. for package maintainers it's certainly good to be able to build more in parallel as they usually have less packages to build. > ?foo would refer to the build > ?foo.checked would refer to the checked version which depends on all > ? ? ?map (x: x.checked) (foo.buildInputs foo.propagatedBuildInputs) Yes, but here is IMO a small problem that the checked and unchecked versions are build separately. Sharing them probably wouldn't be so easy in nix. A similar that occurred to me several times are debugging builds. In many distributions the packages are built with -ggdb flag and then the binaries are stripped, adding a link to the debugging symbols. The symbols can then be installed separately (e. g. in the moment the application crashes). It would be nice to have something like this, but it probably isn't relevant now, with the number of users NixOS has. > Probably there are not enough check phases justifying the effort yet. I feel that we should utilize automatic testing as much as possible. This can make NixOS so much more reliable, detecting for example typos in scripts that only affect little used features. I wonder if other distros only use upstream test or they have some other, too. Using stats from hydra, nix could one day estimate the build time automatically. I don't see this as a priority now, as the usual users are IMHO going to prefer binaries from hydra in most cases. Vlada From marco-oweber at gmx.de Sat Mar 5 21:09:11 2011 From: marco-oweber at gmx.de (Marc Weber) Date: Sat, 05 Mar 2011 20:09:11 +0000 Subject: [Nix-dev] Re: How do parallel builds scale? In-Reply-To: References: <87fwr4ryh0.fsf@gnu.org> <1299171468-sup-2970@localhost.localdomain> <1299184759-sup-6214@localhost.localdomain> <8762rzx28u.fsf@gnu.org> <1299192287-sup-5338@localhost.localdomain> <1299200563-sup-6023@localhost.localdomain> Message-ID: <1299355537-sup-9012@localhost.localdomain> > By the way, do you know how much hydra waits because of waiting for > dependencies? I think it shouldn't be too difficult to always find > something else to build on hydra, but e. g. for package maintainers Its not about keeping Hydra busy. Its about being able to deliver patched versions fast if there is a use case (eg security patches) In production systems it may matter whether you're able to deploy much faster. However using faster / more machines would have more effect than separating check phases ? Currently its not most important to me. > Using stats from hydra, nix could one day estimate the build time > automatically. I don't see this as a priority now, as the usual users > are IMHO going to prefer binaries from hydra in most cases. If you use sources hydra uses you're fine. If you use a patched nixpgks .. Marc Weber From shea at shealevy.com Sun Mar 6 16:09:56 2011 From: shea at shealevy.com (Shea Levy) Date: Sun, 06 Mar 2011 10:09:56 -0500 Subject: [Nix-dev] fbcondecor-0.9.6-2.6.37 patch for nixpkgs Message-ID: <4D73A3C4.1070506@shealevy.com> Hi all, I've updated my local copy of nixpkgs to use the now-available fbcondecor patch when compiling Linux 2.6.37. I'm compiling now and will report back later if there are any problems in the resulting system. Cheers, Shea Levy -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fbcondecor-2.6.37.patch Url: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110306/14dbc61a/attachment.pl From shea at shealevy.com Mon Mar 7 02:16:24 2011 From: shea at shealevy.com (Shea Levy) Date: Sun, 06 Mar 2011 20:16:24 -0500 Subject: [Nix-dev] Typo in NixOS Installation Manual Section 1.1.4 Message-ID: <4D7431E8.5040009@shealevy.com> Hi all, I've attached a patch that fixes section 1.1.4 of the NixOS manual to point to the nixpkgs svn repo instead of the nixos repo. Cheers, Shea Levy -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fix-manual-1.1.4.patch Url: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110306/e3beffe9/attachment.pl From shea at shealevy.com Mon Mar 7 05:08:23 2011 From: shea at shealevy.com (Shea Levy) Date: Sun, 06 Mar 2011 23:08:23 -0500 Subject: [Nix-dev] efibootmgr: A Linux user-space application to modify the Intel Extensible Firmware Interface (EFI) Boot Manager Message-ID: <4D745A37.7020205@shealevy.com> Hi all, I've written a nix expression for efibootmgr, a tool which allows you to modify some of the nvram variables used by EFI and UEFI systems to manage the boot process. efibootmgr should compile on non-{U,}EFI systems, but since the tool relies on the information exported by the efivars kernel module, which in turn requires that the kernel be booted in {U,}EFI mode, it's useless unless you have a {U,}EFI system. Cheers, Shea Levy -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: efibootmgr.patch Url: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110306/7c8f18db/attachment.pl From shea at shealevy.com Mon Mar 7 05:14:24 2011 From: shea at shealevy.com (Shea Levy) Date: Sun, 06 Mar 2011 23:14:24 -0500 Subject: [Nix-dev] fbcondecor-0.9.6-2.6.37 patch for nixpkgs In-Reply-To: <4D73A3C4.1070506@shealevy.com> References: <4D73A3C4.1070506@shealevy.com> Message-ID: <4D745BA0.1080608@shealevy.com> Quick follow-up on this: The resulting system works fine, but I'm not seeing a splash background for my terminals. This may be due to my system booting through UEFI, so I'm currently compiling on a VM using traditional BIOS booting to see if the splash backgrounds show up. Cheers, Shea Levy On 3/6/11 10:09 AM, Shea Levy wrote: > Hi all, > > I've updated my local copy of nixpkgs to use the now-available > fbcondecor patch when compiling Linux 2.6.37. I'm compiling now and > will report back later if there are any problems in the resulting system. > > Cheers, > Shea Levy > > > _______________________________________________ > nix-dev mailing list > nix-dev at cs.uu.nl > https://mail.cs.uu.nl/mailman/listinfo/nix-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110306/73e63ae3/attachment.html From e.dolstra at tudelft.nl Mon Mar 7 09:14:39 2011 From: e.dolstra at tudelft.nl (Eelco Dolstra) Date: Mon, 07 Mar 2011 09:14:39 +0100 Subject: [Nix-dev] Re: [Nix-commits] SVN commit: nix - r26174 - nixos/trunk/modules/services/misc In-Reply-To: <20110306153906.02A47CC320@mx4.tudelft.nl> References: <20110306153906.02A47CC320@mx4.tudelft.nl> Message-ID: <4D7493EF.5000100@tudelft.nl> Hi, On 03/06/2011 04:39 PM, Michael Raskin wrote: > Author: raskin > Date: Sun Mar 6 15:39:05 2011 > New Revision: 26174 > URL: https://svn.nixos.org/websvn/nix/?rev=26174&sc=1 > > Log: > Adding a possibility to add more paths to chroots used by nix-daemons. The use-case is building the latest version from repository with very large checkouts. That way you do not get extra copy in store every time you rebuild, and you can implement a saner version checking than checksumming all the data While I don't object to the option in principle, I think this use case is misguided. If you want to make a copy of something in /var/dist without having it copied to the store, just do fetchurl { url = file:///var/dist/...; sha256 = "..."; } For quick and dirty hacking, you can also set this derivation attribute: __noChroot = true; -- Eelco Dolstra | http://www.st.ewi.tudelft.nl/~dolstra/ From shea at shealevy.com Mon Mar 7 09:27:56 2011 From: shea at shealevy.com (Shea Levy) Date: Mon, 07 Mar 2011 03:27:56 -0500 Subject: [Nix-dev] fbcondecor-0.9.6-2.6.37 patch for nixpkgs In-Reply-To: <4D745BA0.1080608@shealevy.com> References: <4D73A3C4.1070506@shealevy.com> <4D745BA0.1080608@shealevy.com> Message-ID: <4D74970C.7050004@shealevy.com> The splash background works in the virtual machine running 2.6.37.1 with the fbcondecor patch. On 3/6/11 11:14 PM, Shea Levy wrote: > Quick follow-up on this: The resulting system works fine, but I'm not > seeing a splash background for my terminals. This may be due to my > system booting through UEFI, so I'm currently compiling on a VM using > traditional BIOS booting to see if the splash backgrounds show up. > > Cheers, > Shea Levy > > On 3/6/11 10:09 AM, Shea Levy wrote: >> Hi all, >> >> I've updated my local copy of nixpkgs to use the now-available >> fbcondecor patch when compiling Linux 2.6.37. I'm compiling now and >> will report back later if there are any problems in the resulting >> system. >> >> Cheers, >> Shea Levy >> >> >> _______________________________________________ >> nix-dev mailing list >> nix-dev at cs.uu.nl >> https://mail.cs.uu.nl/mailman/listinfo/nix-dev > > > _______________________________________________ > nix-dev mailing list > nix-dev at cs.uu.nl > https://mail.cs.uu.nl/mailman/listinfo/nix-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110307/bd35df4a/attachment.html From 7c6f434c at mail.ru Mon Mar 7 10:51:40 2011 From: 7c6f434c at mail.ru (Michael Raskin) Date: Mon, 07 Mar 2011 12:51:40 +0300 Subject: [Nix-dev] Re: [Nix-commits] SVN commit: nix - r26174 - nixos/trunk/modules/services/misc In-Reply-To: <4D7493EF.5000100@tudelft.nl> References: <4D7493EF.5000100@tudelft.nl> Message-ID: >> Log: >> Adding a possibility to add more paths to chroots used by nix-daemons. The use-case is building the latest version from repository with very large checkouts. That way you do not get extra copy in store every time you rebuild, and you can implement a saner version checking than checksumming all the data > >While I don't object to the option in principle, I think this use case >is misguided. If you want to make a copy of something in /var/dist >without having it copied to the store, just do > > fetchurl { > url = file:///var/dist/...; > sha256 = "..."; > } I have an entire directory, and it is updated fequently, so if you modified the option to a form you can tolerate, I will keep using it. Thanks for the advice (both this one and in IRC). >For quick and dirty hacking, you can also set this derivation attribute: > > __noChroot = true; I wanted something less dirty, if possible From shea at shealevy.com Tue Mar 8 05:26:03 2011 From: shea at shealevy.com (Shea Levy) Date: Mon, 07 Mar 2011 23:26:03 -0500 Subject: [Nix-dev] Typo in Nixpkgs Manual Section Section 3.4.4 Message-ID: <4D75AFDB.4050604@shealevy.com> Hi all, This patch fixes a typo in section 3.4.4 of the Nixpkgs manual. The section is about the configure phase, but it currently reads "The default unpackPhase runs...". Cheers, Shea Levy || -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110307/7b4e532d/attachment.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fix-manual-3.4.4.patch Url: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110307/7b4e532d/attachment.pl From vcunat at gmail.com Tue Mar 8 21:50:01 2011 From: vcunat at gmail.com (=?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?=) Date: Tue, 8 Mar 2011 21:50:01 +0100 Subject: [Nix-dev] missing glib 2.28 In-Reply-To: <201103041622.53114.tierpluspluslists@gmail.com> References: <201103041622.53114.tierpluspluslists@gmail.com> Message-ID: Hi. On 4 March 2011 21:52, Karn Kallio wrote: > glib_2_28 = callPackage ../development/libraries/glib/2.28.x.nix {} > but the corresponding 2.28.x.nix is missing ... nix-env reports I've got the file (in svn trunk). And 'nix-env -iA glib_2_28 --dry-run' works fine. Vlada From shea at shealevy.com Tue Mar 8 22:05:59 2011 From: shea at shealevy.com (Shea Levy) Date: Tue, 08 Mar 2011 16:05:59 -0500 Subject: [Nix-dev] Grub2 For EFI-based Systems Message-ID: <4D769A37.6050606@shealevy.com> Hi all, This patch provides a nixpkg called grub2efi that results in a grub2 targeted at systems that use a UEFI for booting. Additionally, fetchbzr is updated with a leaveDotBzr parameter, which is set to false by default for compatibility with nix-prefetch-bzr (without this patch, the checksum generated by nix-prefetch-bzr only works with fetchbzr if nix-prefetch-bzr was run with $NIX_PREFETCH_BZR_LEAVE_DOT_BZR set to 1). This changes the behaviour of fetchbzr for any packages which currently use it (if any), but I think leaving out the .bzr directories is a saner default. I'll run a check on nixpkgs this evening to see if any packages use it and update all of them to set leaveDotBzr to true. Work left to do on this: * Support targeting 64-bit UEFI architectures booting a 32-bit kernel, and vice-versa. Any resources on any cross-compilation tools in nixpkgs would be greatly appreciated. * Provide a clean, clear error message for those trying to target UEFIs with architectures other than i386 and x86_64, which are the only architectures that grub2 currently supports. I know elilo supports ia64, and I don't know of any UEFI systems for any other architectures. * Make sure all the scripts installed have any nix-specific modifications made beyond just patching shebangs. In particular, I know for sure that grub-install is interpreted by #!${bash}/bin/sh and runs `which efibootmgr`, which results in a warning that there is no which command. * Write (or update existing) NixOS modules to allow for as much automation of using grub2 for UEFI booting as possible for NixOS systems. Ideally this would include a UEFI-bootable livecd so that the UEFI boot manager can be informed of the bootloader location during initial installation. * Find a way to get the 1.99~rc1 release without requiring bazaar, autogen, autoconf, and automake. There is a tarball on ftp://alpha.gnu.org/gnu/grub/, but it has a ~ in the name, which makes fetchurl choke. Storing the tarball with a changed name in the nixpkgs repo seems overkill considering how few people will use this package, but storing it elsewhere on an official nix ftp server might make sense. * Get rid of a noisy error message in the output from fetchbzr. By default, bzr tries to keep a log in $HOME/.bzr.log, so fetchbzr complains about a missing /homeless-shelter/.bzr.log. We could just send stderr to /dev/null for the bzr checkout, but I'll look to see if there's a way to run bazaar without a log, or if there's a better place to keep the log. Cheers, Shea Levy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110308/5a74c85b/attachment.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: grub2efi.patch Url: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110308/5a74c85b/attachment.pl From ludo at gnu.org Tue Mar 8 23:07:13 2011 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Tue, 08 Mar 2011 23:07:13 +0100 Subject: [Nix-dev] Re: Grub2 For EFI-based Systems References: <4D769A37.6050606@shealevy.com> Message-ID: <871v2he06m.fsf@gnu.org> Hello! Thanks for the patch. Shea Levy writes: > This patch provides a nixpkg called grub2efi that results in a grub2 > targeted at systems that use a UEFI for booting. In principle Nixpkgs should only refer to release tarballs, so as to let upstream do its work. For GRUB, we could upgrade to 1.99~rc1, or just wait for 1.99, which will provide what you want. How would that work for you? Thanks, Ludo?. From shea at shealevy.com Tue Mar 8 23:14:56 2011 From: shea at shealevy.com (Shea Levy) Date: Tue, 08 Mar 2011 17:14:56 -0500 Subject: [Nix-dev] Re: Grub2 For EFI-based Systems In-Reply-To: <871v2he06m.fsf@gnu.org> References: <4D769A37.6050606@shealevy.com> <871v2he06m.fsf@gnu.org> Message-ID: <4D76AA60.8080206@shealevy.com> On 3/8/11 5:07 PM, Ludovic Court?s wrote: > Hello! > > Thanks for the patch. > > Shea Levy writes: > >> This patch provides a nixpkg called grub2efi that results in a grub2 >> targeted at systems that use a UEFI for booting. > In principle Nixpkgs should only refer to release tarballs, so as to let > upstream do its work. > > For GRUB, we could upgrade to 1.99~rc1, or just wait for 1.99, which > will provide what you want. How would that work for you? > > Thanks, > Ludo?. > > _______________________________________________ > nix-dev mailing list > nix-dev at cs.uu.nl > https://mail.cs.uu.nl/mailman/listinfo/nix-dev Hi Ludovic, The specific revision this patch points to is the 1.99~rc1 release. Using the tarball would be preferable, but as I said fetchurl chokes on a tarball with a ~ in its name. Obviously a full release would be preferable to a release candidate, but 1.98 does not support efi booting. I'd prefer not to have my personal ftp server referenced in a nixpkg, but if someone wants to host ftp://alpha.gnu.org/gnu/grub/grub-1.99~rc1.tar.gz with a different name somewhere I'll update my nix expression accordingly. Cheers, Shea Levy From shea at shealevy.com Tue Mar 8 23:16:35 2011 From: shea at shealevy.com (Shea Levy) Date: Tue, 08 Mar 2011 17:16:35 -0500 Subject: [Nix-dev] Re: Grub2 For EFI-based Systems In-Reply-To: <871v2he06m.fsf@gnu.org> References: <4D769A37.6050606@shealevy.com> <871v2he06m.fsf@gnu.org> Message-ID: <4D76AAC3.9070400@shealevy.com> On 3/8/11 5:07 PM, Ludovic Court?s wrote: > Hello! > > Thanks for the patch. > > Shea Levy writes: > >> This patch provides a nixpkg called grub2efi that results in a grub2 >> targeted at systems that use a UEFI for booting. > In principle Nixpkgs should only refer to release tarballs, so as to let > upstream do its work. > I'm a bit confused about this. Why do tools like fetchbzr exist if this is the case? > For GRUB, we could upgrade to 1.99~rc1, or just wait for 1.99, which > will provide what you want. How would that work for you? > > Thanks, > Ludo?. > > _______________________________________________ > nix-dev mailing list > nix-dev at cs.uu.nl > https://mail.cs.uu.nl/mailman/listinfo/nix-dev From ludo at gnu.org Tue Mar 8 23:20:05 2011 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Tue, 08 Mar 2011 23:20:05 +0100 Subject: [Nix-dev] Re: Grub2 For EFI-based Systems References: <4D769A37.6050606@shealevy.com> <871v2he06m.fsf@gnu.org> <4D76AA60.8080206@shealevy.com> Message-ID: <87wrk9cl0q.fsf@gnu.org> Hi, Shea Levy writes: > The specific revision this patch points to is the 1.99~rc1 > release. Using the tarball would be preferable, but as I said fetchurl > chokes on a tarball with a ~ in its name. This can be worked around: src = fetchurl { url = ... name = "grub-1.99rc1"; # get rid of `~' }; HTH, Ludo?. From shea at shealevy.com Tue Mar 8 23:21:32 2011 From: shea at shealevy.com (Shea Levy) Date: Tue, 08 Mar 2011 17:21:32 -0500 Subject: [Nix-dev] Re: Grub2 For EFI-based Systems In-Reply-To: <871v2he06m.fsf@gnu.org> References: <4D769A37.6050606@shealevy.com> <871v2he06m.fsf@gnu.org> Message-ID: <4D76ABEC.60403@shealevy.com> Sorry for the repeated replies, one last thing: On 3/8/11 5:07 PM, Ludovic Court?s wrote: > Hello! > > Thanks for the patch. > > Shea Levy writes: > >> This patch provides a nixpkg called grub2efi that results in a grub2 >> targeted at systems that use a UEFI for booting. > In principle Nixpkgs should only refer to release tarballs, so as to let > upstream do its work. > > For GRUB, we could upgrade to 1.99~rc1 In case there's any confusion, this patch doesn't affect the normal grub2 package, that still points to 1.98. > , or just wait for 1.99, which > will provide what you want. How would that work for you? > > Thanks, > Ludo?. > > _______________________________________________ > nix-dev mailing list > nix-dev at cs.uu.nl > https://mail.cs.uu.nl/mailman/listinfo/nix-dev From shea at shealevy.com Tue Mar 8 23:31:24 2011 From: shea at shealevy.com (Shea Levy) Date: Tue, 08 Mar 2011 17:31:24 -0500 Subject: [Nix-dev] Re: Grub2 For EFI-based Systems In-Reply-To: <87wrk9cl0q.fsf@gnu.org> References: <4D769A37.6050606@shealevy.com> <871v2he06m.fsf@gnu.org> <4D76AA60.8080206@shealevy.com> <87wrk9cl0q.fsf@gnu.org> Message-ID: <4D76AE3C.8020600@shealevy.com> On 3/8/11 5:20 PM, Ludovic Court?s wrote: > Hi, > > Shea Levy writes: > >> The specific revision this patch points to is the 1.99~rc1 >> release. Using the tarball would be preferable, but as I said fetchurl >> chokes on a tarball with a ~ in its name. > This can be worked around: > > src = fetchurl { > url = ... > name = "grub-1.99rc1"; # get rid of `~' > }; > > HTH, > Ludo?. > > _______________________________________________ > nix-dev mailing list > nix-dev at cs.uu.nl > https://mail.cs.uu.nl/mailman/listinfo/nix-dev Great, that's just what I needed. Attached is an updated patch. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: grub2efi.patch Url: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110308/797f6594/attachment.pl From ludo at gnu.org Wed Mar 9 00:27:41 2011 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Wed, 09 Mar 2011 00:27:41 +0100 Subject: [Nix-dev] Re: Grub2 For EFI-based Systems References: <4D769A37.6050606@shealevy.com> <871v2he06m.fsf@gnu.org> <4D76AA60.8080206@shealevy.com> <87wrk9cl0q.fsf@gnu.org> <4D76AE3C.8020600@shealevy.com> Message-ID: <87sjuxchw2.fsf@gnu.org> Hi Shea, I ended up committing two patches: one that updates GRUB 1.99, and one that adds optional UEFI support. Let me know what you think. Thanks, Ludo?. From shea at shealevy.com Wed Mar 9 00:44:31 2011 From: shea at shealevy.com (Shea Levy) Date: Tue, 08 Mar 2011 18:44:31 -0500 Subject: [Nix-dev] Re: Grub2 For EFI-based Systems In-Reply-To: <87sjuxchw2.fsf@gnu.org> References: <4D769A37.6050606@shealevy.com> <871v2he06m.fsf@gnu.org> <4D76AA60.8080206@shealevy.com> <87wrk9cl0q.fsf@gnu.org> <4D76AE3C.8020600@shealevy.com> <87sjuxchw2.fsf@gnu.org> Message-ID: <4D76BF5F.5080904@shealevy.com> On 3/8/11 6:27 PM, Ludovic Court?s wrote: > Hi Shea, > > I ended up committing two patches: one that updates GRUB 1.99, and one > that adds optional UEFI support. Let me know what you think. > > Thanks, > Ludo?. > > _______________________________________________ > nix-dev mailing list > nix-dev at cs.uu.nl > https://mail.cs.uu.nl/mailman/listinfo/nix-dev It looks good. Eventually I'd like to see arch as a function parameter, but that will be easy enough once I figure out how to get cross-compiling to work. It's certainly much neater than my attempt :) Cheers, Shea From shea at shealevy.com Wed Mar 9 00:49:05 2011 From: shea at shealevy.com (Shea Levy) Date: Tue, 08 Mar 2011 18:49:05 -0500 Subject: [Nix-dev] Re: [Nix-commits] Hydra job nixpkgs:trunk:tarball build 956810: Failed with non-zero exit code In-Reply-To: <201103082343.p28NhNmX004734@proliant.st.ewi.tudelft.nl> References: <201103082343.p28NhNmX004734@proliant.st.ewi.tudelft.nl> Message-ID: <4D76C071.9010508@shealevy.com> On 3/8/11 6:43 PM, Hydra Build Daemon wrote: > Hi, > > This is to let you know that Hydra build 956810 of job nixpkgs:trunk:tarball has changed from 'Success' to 'Failed with non-zero exit code'. > > Complete build information can be found on this page: http://hydra.nixos.org/build/956810 > > The last 50 lines of the build log are shown at the bottom of this email. > > A summary of the build information follows: > > Build ID: | 956810 > Nix name: | nixpkgs-tarball-0pre26216 > Short description: | Build of a source distribution from a checkout > Maintainer(s): | Nix Committers > System: | x86_64-linux > Derivation store path: | /nix/store/gsvvysd4f2d4j46v5y8kh2xzw4f89h93-nixpkgs-tarball-0pre26216.drv > Output store path: | /nix/store/0jb2pyqkvdm7c8vq6fs3d7mckhvhjhqy-nixpkgs-tarball-0pre26216 > Time added: | 2011-03-09 00:43:22 > Build started: | 2011-03-09 00:42:29 > Build finished: | 2011-03-09 00:43:22 > Duration: | 53s > > The build inputs were: > > Name | Type | Value > ----------------+---------+---------------------------------------------------- > nixpkgs | svn | https://svn.nixos.org/repos/nix/nixpkgs/trunk:26216 > officialRelease | boolean | false > > Regards, > > The Hydra build daemon. > > --- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > error: while evaluating the builtin function `derivationStrict': > while instantiating the derivation named `grub-efi-1.99rc1' at `/tmp/nix-build-gsvvysd4f2d4j46v5y8kh2xzw4f89h93-nixpkgs-tarball-0pre26216.drv-0/nixpkgs-r26216/pkgs/tools/misc/grub/1.9x.nix:14:3': > while evaluating the derivation attribute `configureFlags' at `/tmp/nix-build-gsvvysd4f2d4j46v5y8kh2xzw4f89h93-nixpkgs-tarball-0pre26216.drv-0/nixpkgs-r26216/pkgs/tools/misc/grub/1.9x.nix:50:3': > while evaluating the builtin function `abort': > evaluation aborted with the following error message: `unsupported EFI firmware architecture' > > build time elapsed: 0m0.021s 0m0.013s 0m22.151s 0m3.521s > builder for `/nix/store/gsvvysd4f2d4j46v5y8kh2xzw4f89h93-nixpkgs-tarball-0pre26216.drv' failed with exit code 1 > error: build of `/nix/store/gsvvysd4f2d4j46v5y8kh2xzw4f89h93-nixpkgs-tarball-0pre26216.drv' failed > _______________________________________________ > nix-commits mailing list > nix-commits at cs.uu.nl > http://mail.cs.uu.nl/mailman/listinfo/nix-commits This can be fixed by adding another else if for EFIsupport == false. Why is the derivation evaluated strictly, though? From shea at shealevy.com Wed Mar 9 00:53:07 2011 From: shea at shealevy.com (Shea Levy) Date: Tue, 08 Mar 2011 18:53:07 -0500 Subject: [Nix-dev] Re: [Nix-commits] Hydra job nixpkgs:trunk:tarball build 956810: Failed with non-zero exit code In-Reply-To: <4D76C071.9010508@shealevy.com> References: <201103082343.p28NhNmX004734@proliant.st.ewi.tudelft.nl> <4D76C071.9010508@shealevy.com> Message-ID: <4D76C163.3060400@shealevy.com> On 3/8/11 6:49 PM, Shea Levy wrote: > On 3/8/11 6:43 PM, Hydra Build Daemon wrote: >> Hi, >> >> This is to let you know that Hydra build 956810 of job >> nixpkgs:trunk:tarball has changed from 'Success' to 'Failed with >> non-zero exit code'. >> >> Complete build information can be found on this page: >> http://hydra.nixos.org/build/956810 >> >> The last 50 lines of the build log are shown at the bottom of this >> email. >> >> A summary of the build information follows: >> >> Build ID: | 956810 >> Nix name: | nixpkgs-tarball-0pre26216 >> Short description: | Build of a source distribution from a checkout >> Maintainer(s): | Nix Committers >> System: | x86_64-linux >> Derivation store path: | >> /nix/store/gsvvysd4f2d4j46v5y8kh2xzw4f89h93-nixpkgs-tarball-0pre26216.drv >> Output store path: | >> /nix/store/0jb2pyqkvdm7c8vq6fs3d7mckhvhjhqy-nixpkgs-tarball-0pre26216 >> Time added: | 2011-03-09 00:43:22 >> Build started: | 2011-03-09 00:42:29 >> Build finished: | 2011-03-09 00:43:22 >> Duration: | 53s >> >> The build inputs were: >> >> Name | Type | Value >> ----------------+---------+---------------------------------------------------- >> >> nixpkgs | svn | >> https://svn.nixos.org/repos/nix/nixpkgs/trunk:26216 >> officialRelease | boolean | false >> >> Regards, >> >> The Hydra build daemon. >> >> --- >> >> >> > drvPath="/nix/store/fx44z706mf45hbalavnykwi2239k94qa-graphviz-2.22.2.drv" >> name="graphviz-2.22.2" system="powerpc-linux"> >> >> >> >> > drvPath="/nix/store/xf10x3r8fx86y5c41g1irz5xzsw2jglr-grass-6.4.0RC6.drv" >> name="grass-6.4.0RC6" system="powerpc-linux"> >> >> > value="http://grass.itc.it/index.php" /> >> >> >> >> >> > drvPath="/nix/store/03890cb5dx7q5f1ql7468xq35nmgfxj3-groff-1.20.1.drv" name="groff-1.20.1" >> system="powerpc-linux"> >> >> > value="http://www.gnu.org/software/groff/" /> >> >> >> >> > drvPath="/nix/store/f1c7r3rq6ii7wrkw9cq47wyd0l6shhci-groovy-1.7.1.drv" name="groovy-1.7.1" >> system="powerpc-linux"> >> >> > value="http://groovy.codehaus.org/" /> >> >> > drvPath="/nix/store/pvrr14k4hwv1iq6m4dq1scgfkw8v2rh4-grub-0.97-patch-1.10.drv" >> name="grub-0.97-patch-1.10" system="i686-linux"> >> >> > drvPath="/nix/store/sy92qpfl74362c1kvw02mpprdwn3hpnj-grub-1.99rc1.drv" name="grub-1.99rc1" >> system="powerpc-linux"> >> >> > value="http://www.gnu.org/software/grub/" /> >> >> >> >> >> >> >> >> >> >> >> >> >> >> error: while evaluating the builtin function `derivationStrict': >> while instantiating the derivation named `grub-efi-1.99rc1' at >> `/tmp/nix-build-gsvvysd4f2d4j46v5y8kh2xzw4f89h93-nixpkgs-tarball-0pre26216.drv-0/nixpkgs-r26216/pkgs/tools/misc/grub/1.9x.nix:14:3': >> while evaluating the derivation attribute `configureFlags' at >> `/tmp/nix-build-gsvvysd4f2d4j46v5y8kh2xzw4f89h93-nixpkgs-tarball-0pre26216.drv-0/nixpkgs-r26216/pkgs/tools/misc/grub/1.9x.nix:50:3': >> while evaluating the builtin function `abort': >> evaluation aborted with the following error message: `unsupported EFI >> firmware architecture' >> >> build time elapsed: 0m0.021s 0m0.013s 0m22.151s 0m3.521s >> builder for >> `/nix/store/gsvvysd4f2d4j46v5y8kh2xzw4f89h93-nixpkgs-tarball-0pre26216.drv' >> failed with exit code 1 >> error: build of >> `/nix/store/gsvvysd4f2d4j46v5y8kh2xzw4f89h93-nixpkgs-tarball-0pre26216.drv' >> failed >> _______________________________________________ >> nix-commits mailing list >> nix-commits at cs.uu.nl >> http://mail.cs.uu.nl/mailman/listinfo/nix-commits > This can be fixed by adding another else if for EFIsupport == false. > Why is the derivation evaluated strictly, though? > _______________________________________________ > nix-dev mailing list > nix-dev at cs.uu.nl > https://mail.cs.uu.nl/mailman/listinfo/nix-dev Actually, Hydra claims this is an x86_64-linux system. I just compiled this on my x86_64-linux system, so this seems strange. From shea at shealevy.com Wed Mar 9 20:02:48 2011 From: shea at shealevy.com (Shea Levy) Date: Wed, 09 Mar 2011 14:02:48 -0500 Subject: [Nix-dev] Re: [Nix-commits] SVN commit: nix - r26239 - nixpkgs/trunk/pkgs/tools/misc/grub In-Reply-To: <20110309185810.09434108C01E@mx3.tudelft.nl> References: <20110309185810.09434108C01E@mx3.tudelft.nl> Message-ID: <4D77CED8.8070904@shealevy.com> On 3/9/11 1:58 PM, Karn Kallio wrote: > Author: kkallio > Date: Wed Mar 9 18:58:09 2011 > New Revision: 26239 > URL: https://svn.nixos.org/websvn/nix/?rev=26239&sc=1 > > Log: > Fix grub error "cp cannot stat .... unicode.pf2 > -- change postPatch hook to prePatch (postPatch is not run with empty patchset) > -- make the share/grub directory and copy unicode.pf2 there > > Modified: > nixpkgs/trunk/pkgs/tools/misc/grub/1.9x.nix > > Modified: nixpkgs/trunk/pkgs/tools/misc/grub/1.9x.nix > ============================================================================== > --- nixpkgs/trunk/pkgs/tools/misc/grub/1.9x.nix Wed Mar 9 17:13:29 2011 (r26238) > +++ nixpkgs/trunk/pkgs/tools/misc/grub/1.9x.nix Wed Mar 9 18:58:09 2011 (r26239) > @@ -41,12 +41,17 @@ > -e's/qemu-system-i386/qemu-system-x86_64 -nodefaults/g' > ''; > > - postPatch = > + prePatch = > '' gunzip< "${unifont_bdf}"> "unifont.bdf" > sed -i "configure" \ > -e "s|/usr/src/unifont.bdf|$PWD/unifont.bdf|g" > ''; > > + postInstall = '' > + ensureDir ./share/grub > + cp ./unicode.pf2 ./share/grub/ > + ''; > + > configureFlags = > let arch = if stdenv.system == "i686-linux" then "i386" > else if stdenv.system == "x86_64-linux" then "x86_64" > _______________________________________________ > nix-commits mailing list > nix-commits at cs.uu.nl > http://mail.cs.uu.nl/mailman/listinfo/nix-commits FYI, the postInstall is not necessary. Just changing postPatch to prePatch puts unicode.pf2 in the right place. From tierpluspluslists at gmail.com Wed Mar 9 20:04:49 2011 From: tierpluspluslists at gmail.com (Karn Kallio) Date: Wed, 9 Mar 2011 14:34:49 -0430 Subject: [Nix-dev] nixos-rebuild fails on updating GRUB 2 menu Message-ID: <201103091434.50098.tierpluspluslists@gmail.com> Hello, The new grub2 expression caused nixos-rebuild to fail with the error updating GRUB 2 menu... cp: cannot stat `/nix/store/mhh92zbvhd6jrf09phqis1c4kp1ji89n- grub-1.99rc1/share/grub/unicode.pf2': No such file or directory SVN commit r26239 is a quick patch to the GRUB expression to make nixos- rebuild work again; but perhaps a GRUB expert could look this over. From shea at shealevy.com Wed Mar 9 20:06:44 2011 From: shea at shealevy.com (Shea Levy) Date: Wed, 09 Mar 2011 14:06:44 -0500 Subject: [Nix-dev] Re: [Nix-commits] SVN commit: nix - r26239 - nixpkgs/trunk/pkgs/tools/misc/grub In-Reply-To: <4D77CED8.8070904@shealevy.com> References: <20110309185810.09434108C01E@mx3.tudelft.nl> <4D77CED8.8070904@shealevy.com> Message-ID: <4D77CFC4.5080200@shealevy.com> On 3/9/11 2:02 PM, Shea Levy wrote: > On 3/9/11 1:58 PM, Karn Kallio wrote: >> Author: kkallio >> Date: Wed Mar 9 18:58:09 2011 >> New Revision: 26239 >> URL: https://svn.nixos.org/websvn/nix/?rev=26239&sc=1 >> >> Log: >> Fix grub error "cp cannot stat .... unicode.pf2 >> -- change postPatch hook to prePatch (postPatch is not run with empty >> patchset) >> -- make the share/grub directory and copy unicode.pf2 there >> >> Modified: >> nixpkgs/trunk/pkgs/tools/misc/grub/1.9x.nix >> >> Modified: nixpkgs/trunk/pkgs/tools/misc/grub/1.9x.nix >> ============================================================================== >> >> --- nixpkgs/trunk/pkgs/tools/misc/grub/1.9x.nix Wed Mar 9 >> 17:13:29 2011 (r26238) >> +++ nixpkgs/trunk/pkgs/tools/misc/grub/1.9x.nix Wed Mar 9 >> 18:58:09 2011 (r26239) >> @@ -41,12 +41,17 @@ >> -e's/qemu-system-i386/qemu-system-x86_64 -nodefaults/g' >> ''; >> >> - postPatch = >> + prePatch = >> '' gunzip< "${unifont_bdf}"> "unifont.bdf" >> sed -i "configure" \ >> -e "s|/usr/src/unifont.bdf|$PWD/unifont.bdf|g" >> ''; >> >> + postInstall = '' >> + ensureDir ./share/grub >> + cp ./unicode.pf2 ./share/grub/ >> + ''; >> + >> configureFlags = >> let arch = if stdenv.system == "i686-linux" then "i386" >> else if stdenv.system == "x86_64-linux" then "x86_64" >> _______________________________________________ >> nix-commits mailing list >> nix-commits at cs.uu.nl >> http://mail.cs.uu.nl/mailman/listinfo/nix-commits > > FYI, the postInstall is not necessary. Just changing postPatch to > prePatch puts unicode.pf2 in the right place. > _______________________________________________ > nix-dev mailing list > nix-dev at cs.uu.nl > https://mail.cs.uu.nl/mailman/listinfo/nix-dev In fact, I'm not sure how the postInstall is useful at all, considering that there is no $out/unicode.pf2 and this cp is run after make install. From shea at shealevy.com Wed Mar 9 20:12:47 2011 From: shea at shealevy.com (Shea Levy) Date: Wed, 09 Mar 2011 14:12:47 -0500 Subject: [Nix-dev] nixos-rebuild fails on updating GRUB 2 menu In-Reply-To: <201103091434.50098.tierpluspluslists@gmail.com> References: <201103091434.50098.tierpluspluslists@gmail.com> Message-ID: <4D77D12F.6030503@shealevy.com> On 3/9/11 2:04 PM, Karn Kallio wrote: > Hello, > > The new grub2 expression caused nixos-rebuild to fail with the error > updating GRUB 2 menu... > cp: cannot stat `/nix/store/mhh92zbvhd6jrf09phqis1c4kp1ji89n- > grub-1.99rc1/share/grub/unicode.pf2': No such file or directory > > > SVN commit r26239 is a quick patch to the GRUB expression to make nixos- > rebuild work again; but perhaps a GRUB expert could look this over. > > _______________________________________________ > nix-dev mailing list > nix-dev at cs.uu.nl > https://mail.cs.uu.nl/mailman/listinfo/nix-dev Hi Karn, What does the postInstall you added do? I changed postPatch to prePatch on my local copy without the postInstall and $out/share/grub/unicode.pf2 was there. Cheers, Shea Levy From tierpluspluslists at gmail.com Wed Mar 9 20:20:40 2011 From: tierpluspluslists at gmail.com (Karn Kallio) Date: Wed, 9 Mar 2011 14:50:40 -0430 Subject: [Nix-dev] nixos-rebuild fails on updating GRUB 2 menu In-Reply-To: <4D77D12F.6030503@shealevy.com> References: <201103091434.50098.tierpluspluslists@gmail.com> <4D77D12F.6030503@shealevy.com> Message-ID: <201103091450.41227.tierpluspluslists@gmail.com> > On 3/9/11 2:04 PM, Karn Kallio wrote: > > Hello, > > > > The new grub2 expression caused nixos-rebuild to fail with the error > > updating GRUB 2 menu... > > cp: cannot stat `/nix/store/mhh92zbvhd6jrf09phqis1c4kp1ji89n- > > grub-1.99rc1/share/grub/unicode.pf2': No such file or directory > > > > > > SVN commit r26239 is a quick patch to the GRUB expression to make nixos- > > rebuild work again; but perhaps a GRUB expert could look this over. > > > > _______________________________________________ > > nix-dev mailing list > > nix-dev at cs.uu.nl > > https://mail.cs.uu.nl/mailman/listinfo/nix-dev > > Hi Karn, > > What does the postInstall you added do? I changed postPatch to prePatch > on my local copy without the postInstall and $out/share/grub/unicode.pf2 > was there. > > Cheers, > Shea Levy I included the postInstall based on the error message and the postPatch instructions ... I did not test without the postInstall since the nixos- rebuild went ok From tierpluspluslists at gmail.com Wed Mar 9 20:51:56 2011 From: tierpluspluslists at gmail.com (Karn Kallio) Date: Wed, 9 Mar 2011 15:21:56 -0430 Subject: [Nix-dev] nixos-rebuild fails on updating GRUB 2 menu In-Reply-To: <201103091450.41227.tierpluspluslists@gmail.com> References: <201103091434.50098.tierpluspluslists@gmail.com> <4D77D12F.6030503@shealevy.com> <201103091450.41227.tierpluspluslists@gmail.com> Message-ID: <201103091521.56974.tierpluspluslists@gmail.com> > > > Hello, > > > > > > The new grub2 expression caused nixos-rebuild to fail with the error > > > updating GRUB 2 menu... > > > cp: cannot stat `/nix/store/mhh92zbvhd6jrf09phqis1c4kp1ji89n- > > > grub-1.99rc1/share/grub/unicode.pf2': No such file or directory > > > > > > > > > SVN commit r26239 is a quick patch to the GRUB expression to make > > > nixos- rebuild work again; but perhaps a GRUB expert could look this > > > over. > > > > > > _______________________________________________ > > > nix-dev mailing list > > > nix-dev at cs.uu.nl > > > https://mail.cs.uu.nl/mailman/listinfo/nix-dev > > > > Hi Karn, > > > > What does the postInstall you added do? I changed postPatch to prePatch > > on my local copy without the postInstall and $out/share/grub/unicode.pf2 > > was there. > > > > Cheers, > > Shea Levy > > I included the postInstall based on the error message and the postPatch > instructions ... I did not test without the postInstall since the nixos- > rebuild went ok Hello Shea, The postInstall has been removed ( as you point out, it was unnecessary and did not even do anything ). Thanks for the review! From ludo at gnu.org Wed Mar 9 23:40:11 2011 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Wed, 09 Mar 2011 23:40:11 +0100 Subject: [Nix-dev] Hydra, nix-prefetch-git, and TopGit Message-ID: <87wrk7apf8.fsf@gnu.org> Hello! I?m trying to see how to apply the recipe at from within a Git clone produced by Hydra. A plain ?git clone? doesn?t fetch objects references by the TopGit-managed branches, so ?tg remote --populate? is really needed. However, ?tg remote --populate? wants to fetch data from the network, which is not possible from within a Nix build chroot. I thought we could make ?nix-prefetch-git? (the script Hydra uses to clone repositories) somehow fetch the TopGit branches automatically when it sees ?refs/top-bases?, but I don?t know exactly how to make it so, nor whether it would even work. IOW, I?m open to all sorts of suggestions. :-) Thoughts? Thanks, Ludo?. From viriketo at gmail.com Wed Mar 9 23:52:29 2011 From: viriketo at gmail.com (=?iso-8859-1?Q?Llu=EDs?= Batlle i Rossell) Date: Wed, 9 Mar 2011 23:52:29 +0100 Subject: [Nix-dev] Hydra, nix-prefetch-git, and TopGit In-Reply-To: <87wrk7apf8.fsf@gnu.org> References: <87wrk7apf8.fsf@gnu.org> Message-ID: <20110309225227.GV32257@vicerveza.homeunix.net> On Wed, Mar 09, 2011 at 11:40:11PM +0100, Ludovic Court?s wrote: > Hello! > > I?m trying to see how to apply the recipe at > from > within a Git clone produced by Hydra. > > A plain ?git clone? doesn?t fetch objects references by the > TopGit-managed branches, so ?tg remote --populate? is really needed. > However, ?tg remote --populate? wants to fetch data from the network, > which is not possible from within a Nix build chroot. Also 'git clone' uses the network, but it produces a fixed output derivation, which fits your case also. Can't you use that same aproach? From marco-oweber at gmx.de Wed Mar 9 23:59:10 2011 From: marco-oweber at gmx.de (Marc Weber) Date: Wed, 09 Mar 2011 22:59:10 +0000 Subject: [Nix-dev] Hydra, nix-prefetch-git, and TopGit In-Reply-To: <87wrk7apf8.fsf@gnu.org> References: <87wrk7apf8.fsf@gnu.org> Message-ID: <1299710733-sup-6550@localhost.localdomain> It should be sufficient to checkout the branch you want. Its not important whether the branch is a topic branch or not unless you want tg update to work. However I don't think that Hydra should run tg update. It should be you doing this manually pushing the result somewhere (?) details: TopGit topic branches have an additional refs/top-bases/$NAME branch marking the commit against which to diff when exporting a patch. You can think of it being the "merge" of all dependencies listed in .topdeps --populate adds local branches for all branches because those local branches are usually referred to in .topdeps files. You could change this and replace "dep" by "origin/dep" instead - however this would require all users to use the same remote location name. So without --populate you only miss the ability to run tg update successfully AFAIK. So if Hydra should run tg update then you have to use --populate. Don't think its a good idea doing so in a builder though. Marc Weber From marco-oweber at gmx.de Thu Mar 10 00:04:21 2011 From: marco-oweber at gmx.de (Marc Weber) Date: Wed, 09 Mar 2011 23:04:21 +0000 Subject: [Nix-dev] Hydra - future - community Message-ID: <1299711577-sup-4478@localhost.localdomain> What is the long time goal? Have one hydra building the world - asking users to share costs [1]? (Maybe put it on an Amazon cloud and wait for the world to join?) We all know that NixOS/nixpgks is one of the best (if not the best) way to distribute packages today. Still I'd like to see some statements about its future and goals. Ask companies to setup their own Hydras if their nixpkgs start deviating too much from SVN trunk? Marc Weber [1] maybe its possible to calculate build and "hosting" resources for users and share them by users. From nicolas.b.pierron at gmail.com Thu Mar 10 10:33:51 2011 From: nicolas.b.pierron at gmail.com (Nicolas Pierron) Date: Thu, 10 Mar 2011 10:33:51 +0100 Subject: [Nix-dev] Re: Hydra, nix-prefetch-git, and TopGit In-Reply-To: <87wrk7apf8.fsf@gnu.org> References: <87wrk7apf8.fsf@gnu.org> Message-ID: 2011/3/9 Ludovic Court?s : > I thought we could make ?nix-prefetch-git? (the script Hydra uses to > clone repositories) somehow fetch the TopGit branches automatically when > it sees ?refs/top-bases?, but I don?t know exactly how to make it so, > nor whether it would even work. nix-prefect-git only download&checkout one commit at a specific refs/sha1 when this is possible. What you seems to want is to automatically build all branches matching refs/top-bases/* with Hydra. What you can do is use "git ls-remote" to list all branches you are interested in, and then add job in hydra for each of the references returned. git init; git remote add origin $url; git ls-remote origin 'refs/top-bases/*'; By the way, I would be highly interested by such feature in Hydra because some git projects have branches which are waiting for merge approval, and our current autonomous build system does not watch for such branches. -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ From ludo at gnu.org Thu Mar 10 12:02:34 2011 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Thu, 10 Mar 2011 12:02:34 +0100 Subject: [Nix-dev] Hydra, nix-prefetch-git, and TopGit In-Reply-To: <20110309225227.GV32257@vicerveza.homeunix.net> (=?iso-8859-1?Q?=22Llu=EDs?= Batlle i Rossell"'s message of "Wed, 9 Mar 2011 23:52:29 +0100") References: <87wrk7apf8.fsf@gnu.org> <20110309225227.GV32257@vicerveza.homeunix.net> Message-ID: <87d3lzw851.fsf@gnu.org> Hello, Llu?s Batlle i Rossell writes: > On Wed, Mar 09, 2011 at 11:40:11PM +0100, Ludovic Court?s wrote: >> Hello! >> >> I?m trying to see how to apply the recipe at >> from >> within a Git clone produced by Hydra. >> >> A plain ?git clone? doesn?t fetch objects references by the >> TopGit-managed branches, so ?tg remote --populate? is really needed. >> However, ?tg remote --populate? wants to fetch data from the network, >> which is not possible from within a Nix build chroot. > > Also 'git clone' uses the network, but it produces a fixed output derivation, > which fits your case also. Can't you use that same aproach? In Hydra ?git clone? is done by Hydra itself, not through Nix, because you typically want the latest revision of a given branch. Thanks, Ludo?. From ludo at gnu.org Thu Mar 10 12:13:32 2011 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Thu, 10 Mar 2011 12:13:32 +0100 Subject: [Nix-dev] Hydra, nix-prefetch-git, and TopGit In-Reply-To: <878vwncoug.fsf@kepler.schwinge.homeip.net> (Thomas Schwinge's message of "Thu, 10 Mar 2011 10:21:59 +0100") References: <87wrk7apf8.fsf@gnu.org> <1299710733-sup-6550@localhost.localdomain> <878vwncoug.fsf@kepler.schwinge.homeip.net> Message-ID: <87k4g7ut2b.fsf@gnu.org> Hi, Thomas Schwinge writes: > On Wed, 09 Mar 2011 22:59:10 +0000, Marc Weber wrote: >> It should be sufficient to checkout the branch you want. Its not >> important whether the branch is a topic branch or not unless you want tg >> update to work. > > That is correct. And I suppose you want the branch > tschwinge/Roger_Whittaker. Hmm, OK. Will that allow me to run ?tg patch?? Besides, since r22783, Hydra keeps a local clone and calls ?git pull? on that instead of cloning again, which fails on this repo/branch (see ): You asked me to pull without telling me which branch you want to merge with, and 'branch.master.merge' in your configuration file does not tell me, either. Please specify which branch you want to use on the command line and try again (e.g. 'git pull '). See git-pull(1) for details. It it because this repo doesn?t have a ?master? branch or something? I?ve never seen it elsewhere. Thanks, Ludo?. From thomas at schwinge.name Thu Mar 10 10:21:59 2011 From: thomas at schwinge.name (Thomas Schwinge) Date: Thu, 10 Mar 2011 10:21:59 +0100 Subject: [Nix-dev] Hydra, nix-prefetch-git, and TopGit In-Reply-To: <1299710733-sup-6550@localhost.localdomain> References: <87wrk7apf8.fsf@gnu.org> <1299710733-sup-6550@localhost.localdomain> Message-ID: <878vwncoug.fsf@kepler.schwinge.homeip.net> Hallo! On Wed, 09 Mar 2011 22:59:10 +0000, Marc Weber wrote: > It should be sufficient to checkout the branch you want. Its not > important whether the branch is a topic branch or not unless you want tg > update to work. That is correct. And I suppose you want the branch tschwinge/Roger_Whittaker. > However I don't think that Hydra should run tg update. > It should be you doing this manually pushing the result somewhere (?) Ack. > details: Correct -- and may I ask, are you one of the (apparently) few who is still using TopGit? There isn't much / any development any more; but is there something else to use instead? So far, I only know about some ideas / design sketches of Uwe Kleine-K?nig's ?berGit, Thomas Koch's TNT (TNT is not TopGit). Gr??e, Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110310/6f3877cc/attachment.bin From ludo at gnu.org Thu Mar 10 16:13:39 2011 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Thu, 10 Mar 2011 16:13:39 +0100 Subject: [Nix-dev] Re: Hydra - future - community References: <1299711577-sup-4478@localhost.localdomain> Message-ID: <87zkp3t3do.fsf@gnu.org> Hello! I think Hydra as a continuous integration tool is worth keeping alive because its use of Nix, along with the nice features it offers and its nice user interface make it relevant. All it needs is a bit of polishing and documentation so that it?s actually installable by people who don?t work at TUD. ;-) If Hydra were to remain a nixos.org-only piece of software, then I?d be a bit concerned about its future. Thanks, Ludo?. From ludo at gnu.org Thu Mar 10 16:16:25 2011 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Thu, 10 Mar 2011 16:16:25 +0100 Subject: [Nix-dev] Re: Hydra, nix-prefetch-git, and TopGit In-Reply-To: <87k4g7ut2b.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?= =?iso-8859-1?Q?=22's?= message of "Thu, 10 Mar 2011 12:13:32 +0100") References: <87wrk7apf8.fsf@gnu.org> <1299710733-sup-6550@localhost.localdomain> <878vwncoug.fsf@kepler.schwinge.homeip.net> <87k4g7ut2b.fsf@gnu.org> Message-ID: <87tyfbt392.fsf@gnu.org> Hi, ludo at gnu.org (Ludovic Court?s) writes: > Besides, since r22783, Hydra keeps a local clone and calls ?git pull? on > that instead of cloning again, which fails on this repo/branch (see > ): > > You asked me to pull without telling me which branch you > want to merge with, and 'branch.master.merge' in > your configuration file does not tell me, either. Please > specify which branch you want to use on the command line and > try again (e.g. 'git pull '). > See git-pull(1) for details. Vladim?r ?un?t rightfully noted that ?git pull? works well provided the repository was cloned with ?git clone -b tschwinge/Roger_Whittaker?, so I pushed this change: https://svn.nixos.org/websvn/nix/?rev=26259&sc=1 Thanks! Ludo?. From vcunat at gmail.com Thu Mar 10 16:55:51 2011 From: vcunat at gmail.com (=?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?=) Date: Thu, 10 Mar 2011 16:55:51 +0100 Subject: [Nix-dev] Re: [Nix-commits] Hydra job nixpkgs:trunk:tarball build 956810: Failed with non-zero exit code In-Reply-To: References: <201103082343.p28NhNmX004734@proliant.st.ewi.tudelft.nl> <4D76C071.9010508@shealevy.com> <4D76C163.3060400@shealevy.com> Message-ID: Hi. On 9 March 2011 00:53, Shea Levy wrote: > Actually, Hydra claims this is an x86_64-linux system. I just compiled this > on my x86_64-linux system, so this seems strange. Is your output hash the same? I don't know details, but hydra caches failures in some way and doesn't attempt to rebuild the failed jobs. Vlada From vcunat at gmail.com Thu Mar 10 16:59:14 2011 From: vcunat at gmail.com (=?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?=) Date: Thu, 10 Mar 2011 16:59:14 +0100 Subject: [Nix-dev] Re: Hydra, nix-prefetch-git, and TopGit In-Reply-To: <87tyfbt392.fsf@gnu.org> References: <87wrk7apf8.fsf@gnu.org> <1299710733-sup-6550@localhost.localdomain> <878vwncoug.fsf@kepler.schwinge.homeip.net> <87k4g7ut2b.fsf@gnu.org> <87tyfbt392.fsf@gnu.org> Message-ID: Hi. 2011/3/10 Ludovic Court?s : > Vladim?r ?un?t rightfully noted that ?git pull? works well provided ... I meant to send the message to the whole list, but GMail replies by default to the individuals only and I forgot to change it. Vlada From marco-oweber at gmx.de Thu Mar 10 19:18:39 2011 From: marco-oweber at gmx.de (Marc Weber) Date: Thu, 10 Mar 2011 18:18:39 +0000 Subject: [Nix-dev] Hydra, nix-prefetch-git, and TopGit In-Reply-To: <878vwncoug.fsf@kepler.schwinge.homeip.net> References: <87wrk7apf8.fsf@gnu.org> <1299710733-sup-6550@localhost.localdomain> <878vwncoug.fsf@kepler.schwinge.homeip.net> Message-ID: <1299778625-sup-884@localhost.localdomain> Excerpts from Thomas Schwinge's message of Thu Mar 10 09:21:59 +0000 2011: > Correct -- and may I ask, are you one of the (apparently) few who is > still using TopGit? There isn't much / any development any more; but > is I know. Uwe Klein K stopped using it at all. But I'm not aware of him talking about a replacement. Mercurial is no option because you can't drop branches easily And I love gits remote feature so much. I contributed the tg push feature. At that point I wished a scripting language would have been used. It works for me so why change or bother about missing upstream? I hope it won't break too soon though. Marc Weber From ludo at gnu.org Fri Mar 11 10:22:33 2011 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Fri, 11 Mar 2011 10:22:33 +0100 Subject: [Nix-dev] Re: Hydra, nix-prefetch-git, and TopGit In-Reply-To: (Nicolas Pierron's message of "Thu, 10 Mar 2011 10:33:51 +0100") References: <87wrk7apf8.fsf@gnu.org> Message-ID: <871v2eovty.fsf@gnu.org> Hi Nicolas, Nicolas Pierron writes: > 2011/3/9 Ludovic Court?s : >> I thought we could make ?nix-prefetch-git? (the script Hydra uses to >> clone repositories) somehow fetch the TopGit branches automatically when >> it sees ?refs/top-bases?, but I don?t know exactly how to make it so, >> nor whether it would even work. > > nix-prefect-git only download&checkout one commit at a specific > refs/sha1 when this is possible. What you seems to want is to > automatically build all branches matching refs/top-bases/* with Hydra. > What you can do is use "git ls-remote" to list all branches you are > interested in, and then add job in hydra for each of the references > returned. > > git init; > git remote add origin $url; > git ls-remote origin 'refs/top-bases/*'; I?m thinking of changing ?nix-prefect-git? like this: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-patch Size: 446 bytes Desc: not available Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110311/31c5992c/attachment.bin -------------- next part -------------- What do you think? TopGit would have to be installed on Hydra. Thanks, Ludo?. From urkud+nix at ya.ru Fri Mar 11 12:42:52 2011 From: urkud+nix at ya.ru (Yury G. Kudryashov) Date: Fri, 11 Mar 2011 14:42:52 +0300 Subject: [Nix-dev] Re: Hydra, nix-prefetch-git, and TopGit References: <87wrk7apf8.fsf@gnu.org> <871v2eovty.fsf@gnu.org> Message-ID: Ludovic Court?s wrote: > Hi Nicolas, > > Nicolas Pierron writes: > >> 2011/3/9 Ludovic Court?s : >>> I thought we could make ?nix-prefetch-git? (the script Hydra uses to >>> clone repositories) somehow fetch the TopGit branches automatically when >>> it sees ?refs/top-bases?, but I don?t know exactly how to make it so, >>> nor whether it would even work. >> >> nix-prefect-git only download&checkout one commit at a specific >> refs/sha1 when this is possible. What you seems to want is to >> automatically build all branches matching refs/top-bases/* with Hydra. >> What you can do is use "git ls-remote" to list all branches you are >> interested in, and then add job in hydra for each of the references >> returned. >> >> git init; >> git remote add origin $url; >> git ls-remote origin 'refs/top-bases/*'; > > I?m thinking of changing ?nix-prefect-git? like this: I don't like that # nix-prefetch-git some_url and fetchgit { url = some_url } result in different directories. I propose to rename nix-prefetch-git to hydra-fetch-git, and write nix-prefetch-git that does *exactly the same thing* as fetchgit does. From urkud+nix at ya.ru Fri Mar 11 13:44:26 2011 From: urkud+nix at ya.ru (Yury G. Kudryashov) Date: Fri, 11 Mar 2011 15:44:26 +0300 Subject: [Nix-dev] Re: Hydra, nix-prefetch-git, and TopGit References: <87wrk7apf8.fsf@gnu.org> <871v2eovty.fsf@gnu.org> Message-ID: Yury G. Kudryashov wrote: >> I?m thinking of changing ?nix-prefect-git? like this: > I don't like that > # nix-prefetch-git some_url > and > fetchgit { > url = some_url > } > > result in different directories. I propose to rename nix-prefetch-git to > hydra-fetch-git, and write nix-prefetch-git that does *exactly the same > thing* as fetchgit does. I meant, rename current nix-prefetch-git (that prefetches submodules etc.) to some other name, and write new "stupid" nix-prefetch-git. From shea at shealevy.com Fri Mar 11 16:00:50 2011 From: shea at shealevy.com (Shea Levy) Date: Fri, 11 Mar 2011 10:00:50 -0500 Subject: [Nix-dev] Re: [Nix-commits] SVN commit: nix - r26279 - in nixos/trunk: lib modules/tasks In-Reply-To: <20110311145011.5B6B62B803C@mx2.tudelft.nl> References: <20110311145011.5B6B62B803C@mx2.tudelft.nl> Message-ID: <4D7A3922.70605@shealevy.com> On 3/11/11 9:50 AM, Eelco Dolstra wrote: > Author: eelco > Date: Fri Mar 11 14:50:11 2011 > New Revision: 26279 > URL: https://svn.nixos.org/websvn/nix/?rev=26279&sc=1 > > Log: > * Use "ip" instead of "ifconfig" for setting up network interfaces, > since the latter is rather deprecated and has been unmaintained > since 2001. Note that "ip" doesn't know about classful addressing, > so you can no longer get away with not specifying the subnet mask > for explicitly configured interfaces. So if you had > > networking.interfaces = > [ { name = "eth0"; ipAddress = "192.168.1.1"; } ]; > > this should be changed to > > networking.interfaces = > [ { name = "eth0"; > ipAddress = "192.168.1.1"; > subnetMask = "255.255.255.0"; > } > ]; > > otherwise you end up with a subnet mask of 255.255.255.255. > > Modified: > nixos/trunk/lib/build-vms.nix > nixos/trunk/modules/tasks/network-interfaces.nix > > Modified: nixos/trunk/lib/build-vms.nix > ============================================================================== > --- nixos/trunk/lib/build-vms.nix Fri Mar 11 13:59:01 2011 (r26278) > +++ nixos/trunk/lib/build-vms.nix Fri Mar 11 14:50:11 2011 (r26279) > @@ -51,6 +51,7 @@ > lib.flip map interfacesNumbered ({ first, second }: > { name = "eth${toString second}"; > ipAddress = "192.168.${toString first}.${toString m.second}"; > + subnetMask = "255.255.255.0"; > } > ); > in > > Modified: nixos/trunk/modules/tasks/network-interfaces.nix > ============================================================================== > --- nixos/trunk/modules/tasks/network-interfaces.nix Fri Mar 11 13:59:01 2011 (r26278) > +++ nixos/trunk/modules/tasks/network-interfaces.nix Fri Mar 11 14:50:11 2011 (r26279) > @@ -4,12 +4,8 @@ > > let > > - inherit (pkgs) nettools; > - > cfg = config.networking; > > - ifconfig = "${nettools}/sbin/ifconfig"; > - > in > > { > @@ -166,33 +162,28 @@ > > preStart = > '' > - ${pkgs.lib.concatMapStrings (i: > - if i.macAddress != "" then > - '' > - echo "Configuring interface ${i.name}..." > - ${ifconfig} "${i.name}" down || true > - ${ifconfig} "${i.name}" hw ether "${i.macAddress}" || true > + ${flip concatMapStrings cfg.interfaces (i: > + optionalString (i.macAddress != "") > '' > - else "") cfg.interfaces > + echo "Setting MAC address of ${i.name} to ${i.macAddress}..." > + ip link set "${i.name}" address "${i.macAddress}" || true > + '') > } > > for i in $(cd /sys/class/net&& ls -d *); do > echo "Bringing up network device $i..." > - ${ifconfig} $i up || true > + ip link set "$i" up || true > done > > # Configure the manually specified interfaces. > - ${pkgs.lib.concatMapStrings (i: > - if i.ipAddress != "" then > + ${flip concatMapStrings cfg.interfaces (i: > + optionalString (i.ipAddress != "") > '' > echo "Configuring interface ${i.name}..." > - extraFlags= > - if test -n "${i.subnetMask}"; then > - extraFlags="$extraFlags netmask ${i.subnetMask}" > - fi > - ${ifconfig} "${i.name}" "${i.ipAddress}" $extraFlags || true > - '' > - else "") cfg.interfaces} > + ip addr add "${i.ipAddress}""${optionalString (i.subnetMask != "") ("/" + i.subnetMask)}" \ > + dev "${i.name}" || true > + '') > + } > > # Set the nameservers. > if test -n "${toString cfg.nameservers}"; then > @@ -206,9 +197,9 @@ > fi > > # Set the default gateway. > - if test -n "${cfg.defaultGateway}"; then > - ${nettools}/sbin/route add default gw "${cfg.defaultGateway}" || true > - fi > + ${optionalString (cfg.defaultGateway != "") '' > + ip route add default via "${cfg.defaultGateway}" || true > + ''} > > # Run any user-specified commands. > ${pkgs.stdenv.shell} ${pkgs.writeText "local-net-cmds" cfg.localCommands} || true > @@ -218,14 +209,6 @@ > initctl emit -n ip-up > ''} > ''; > - > - postStop = > - '' > - #for i in $(cd /sys/class/net&& ls -d *); do > - # echo "Taking down network device $i..." > - # ${ifconfig} $i down || true > - #done > - ''; > }; > > # Set the host name in the activation script. Don't clear it if > _______________________________________________ > nix-commits mailing list > nix-commits at cs.uu.nl > http://mail.cs.uu.nl/mailman/listinfo/nix-commits Have you checked if wicid works with this change? It was a while back, but I remember having trouble running wicid on a system that used iproute2 instead of net-tools (something to do with hard-wired calls to ifconfig IIRC). From e.dolstra at tudelft.nl Fri Mar 11 16:05:55 2011 From: e.dolstra at tudelft.nl (Eelco Dolstra) Date: Fri, 11 Mar 2011 16:05:55 +0100 Subject: [Nix-dev] Re: [Nix-commits] SVN commit: nix - r26279 - in nixos/trunk: lib modules/tasks In-Reply-To: <4D7A3922.70605@shealevy.com> References: <20110311145011.5B6B62B803C@mx2.tudelft.nl> <4D7A3922.70605@shealevy.com> Message-ID: <4D7A3A53.7040505@tudelft.nl> Hi, On 03/11/2011 04:00 PM, Shea Levy wrote: > Have you checked if wicid works with this change? It was a while back, but I > remember having trouble running wicid on a system that used iproute2 instead of > net-tools (something to do with hard-wired calls to ifconfig IIRC). I haven't tested wicd yet, but ifconfig is still available in $PATH. So I assume it still works. -- Eelco Dolstra | http://www.st.ewi.tudelft.nl/~dolstra/ From ludo at gnu.org Fri Mar 11 16:14:31 2011 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Fri, 11 Mar 2011 16:14:31 +0100 Subject: [Nix-dev] Re: Hydra, nix-prefetch-git, and TopGit References: <87wrk7apf8.fsf@gnu.org> <871v2eovty.fsf@gnu.org> Message-ID: <87zkp1wuy0.fsf@gnu.org> Hi Yury, "Yury G. Kudryashov" writes: > Yury G. Kudryashov wrote: > >>> I?m thinking of changing ?nix-prefect-git? like this: >> I don't like that >> # nix-prefetch-git some_url >> and >> fetchgit { >> url = some_url >> } >> >> result in different directories. I propose to rename nix-prefetch-git to >> hydra-fetch-git, and write nix-prefetch-git that does *exactly the same >> thing* as fetchgit does. > I meant, rename current nix-prefetch-git (that prefetches submodules etc.) > to some other name, and write new "stupid" nix-prefetch-git. Makes sense, but that?s the topic of another discussion. ;-) Ludo?. From S.vanderBurg at tudelft.nl Fri Mar 11 17:04:25 2011 From: S.vanderBurg at tudelft.nl (Sander van der Burg - EWI) Date: Fri, 11 Mar 2011 17:04:25 +0100 Subject: [Nix-dev] RE: [Nix-commits] SVN commit: nix - r26280 -nixos/trunk/modules/virtualisation References: <20110311145936.79677108C02F@mx3.tudelft.nl> Message-ID: <8A23E531C514ED43B1B469040352E7BA129568@SRV503.tudelft.net> Good thing. I believe ifconfig is deprecated a long time ago and it's use should be avoided. -----Original Message----- From: nix-commits-bounces at cs.uu.nl on behalf of Eelco Dolstra Sent: Fri 3/11/2011 3:59 PM To: nix-commits at cs.uu.nl Subject: [Nix-commits] SVN commit: nix - r26280 -nixos/trunk/modules/virtualisation Author: eelco Date: Fri Mar 11 14:59:36 2011 New Revision: 26280 URL: https://svn.nixos.org/websvn/nix/?rev=26280&sc=1 Log: * Replace ifconfig by ip in the initrd of VM tests. Modified: nixos/trunk/modules/virtualisation/qemu-vm.nix Modified: nixos/trunk/modules/virtualisation/qemu-vm.nix ============================================================================== --- nixos/trunk/modules/virtualisation/qemu-vm.nix Fri Mar 11 14:50:11 2011 (r26279) +++ nixos/trunk/modules/virtualisation/qemu-vm.nix Fri Mar 11 14:59:36 2011 (r26280) @@ -247,14 +247,16 @@ # We need mke2fs in the initrd. cp ${pkgs.e2fsprogs}/sbin/mke2fs $out/bin - # And `ifconfig'. - cp ${pkgs.nettools}/sbin/ifconfig $out/bin + # And `ip' (which needs libresolv.so). + cp ${pkgs.iproute}/sbin/ip $out/bin + cp ${pkgs.glibc}/lib/libresolv.so.* $out/lib ''; boot.initrd.postDeviceCommands = '' # Set up networking. Needed for CIFS mounting. - ifconfig eth0 up 10.0.2.15 + ip link set eth0 up + ip addr add 10.0.2.15/24 dev eth0 # If the disk image appears to be empty, run mke2fs to # initialise. _______________________________________________ nix-commits mailing list nix-commits at cs.uu.nl http://mail.cs.uu.nl/mailman/listinfo/nix-commits -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110311/e300c4d4/attachment.html From marco-oweber at gmx.de Mon Mar 14 02:25:35 2011 From: marco-oweber at gmx.de (Marc Weber) Date: Mon, 14 Mar 2011 02:25:35 +0100 Subject: [Nix-dev] [PATCH] nix2/debug Message-ID: <1300065935-9198-1-git-send-email-marco-oweber@gmx.de> patch hepling debugging nix code failures. If you get got X but Y expected this patch will make nix print what X exactly is using XML dump. Signed-off-by: Marc Weber --- src/libexpr/eval.cc | 40 +++++++++++++++++++++---------- src/libexpr/eval.hh | 2 + src/libmain/shared.cc | 3 ++ src/libstore/globals.cc | 1 + src/libstore/globals.hh | 6 ++++- src/nix-instantiate/nix-instantiate.cc | 3 ++ 6 files changed, 41 insertions(+), 14 deletions(-) diff --git a/src/libexpr/eval.cc b/src/libexpr/eval.cc index 949f45e..ce710ba 100644 --- a/src/libexpr/eval.cc +++ b/src/libexpr/eval.cc @@ -5,6 +5,7 @@ #include "store-api.hh" #include "derivations.hh" #include "globals.hh" +#include "value-to-xml.hh" #include #include @@ -202,6 +203,18 @@ void EvalState::addConstant(const string & name, Value & v) } +string EvalState::showTypeOrXml(Value &v){ + if (xmldebugCorcionFailure){ + // make running this code intsead optional + std::ostringstream out; + PathSet context; + printValueAsXML(*this, true, false, v, out, context); + return out.str(); // don't know whether this is safe ! + } else { + return showType(v); + } +} + void EvalState::addPrimOp(const string & name, unsigned int arity, PrimOpFun primOp) { @@ -490,7 +503,7 @@ bool EvalState::evalBool(Env & env, Expr * e) Value v; eval(env, e, v); if (v.type != tBool) - throwTypeError("value is %1% while a Boolean was expected", showType(v)); + throwTypeError("value is %1% while a Boolean was expected", showTypeOrXml(v)); return v.boolean; } @@ -499,7 +512,7 @@ void EvalState::evalAttrs(Env & env, Expr * e, Value & v) { eval(env, e, v); if (v.type != tAttrs) - throwTypeError("value is %1% while an attribute set was expected", showType(v)); + throwTypeError("value is %1% while an attribute set was expected", showTypeOrXml(v)); } @@ -721,7 +734,7 @@ void EvalState::callFunction(Value & fun, Value & arg, Value & v) if (fun.type != tLambda) throwTypeError("attempt to call something which is neither a function nor a primop (built-in operation) but %1%", - showType(fun)); + showTypeOrXml(fun)); unsigned int size = (fun.lambda.fun->arg.empty() ? 0 : 1) + @@ -989,7 +1002,7 @@ int EvalState::forceInt(Value & v) { forceValue(v); if (v.type != tInt) - throwTypeError("value is %1% while an integer was expected", showType(v)); + throwTypeError("value is %1% while an integer was expected", showTypeOrXml(v)); return v.integer; } @@ -998,7 +1011,7 @@ bool EvalState::forceBool(Value & v) { forceValue(v); if (v.type != tBool) - throwTypeError("value is %1% while a Boolean was expected", showType(v)); + throwTypeError("value is %1% while a Boolean was expected", showTypeOrXml(v)); return v.boolean; } @@ -1007,15 +1020,16 @@ void EvalState::forceAttrs(Value & v) { forceValue(v); if (v.type != tAttrs) - throwTypeError("value is %1% while an attribute set was expected", showType(v)); + throwTypeError("value is %1% while an attribute set was expected", showTypeOrXml(v)); } void EvalState::forceList(Value & v) { forceValue(v); - if (v.type != tList) - throwTypeError("value is %1% while a list was expected", showType(v)); + if (v.type != tList){ + throwTypeError("value is %1% while a list was expected", showTypeOrXml(v)); + } } @@ -1023,7 +1037,7 @@ void EvalState::forceFunction(Value & v) { forceValue(v); if (v.type != tLambda && v.type != tPrimOp && v.type != tPrimOpApp) - throwTypeError("value is %1% while a function was expected", showType(v)); + throwTypeError("value is %1% while a function was expected", showTypeOrXml(v)); } @@ -1031,7 +1045,7 @@ string EvalState::forceString(Value & v) { forceValue(v); if (v.type != tString) - throwTypeError("value is %1% while a string was expected", showType(v)); + throwTypeError("value is %1% while a string was expected", showTypeOrXml(v)); return string(v.string.s); } @@ -1109,7 +1123,7 @@ string EvalState::coerceToString(Value & v, PathSet & context, if (v.type == tAttrs) { Bindings::iterator i = v.attrs->find(sOutPath); if (i == v.attrs->end()) - throwTypeError("cannot coerce an attribute set (except a derivation) to a string"); + throwTypeError("cannot coerce an attribute set: %1% (except a derivation) to a string", showTypeOrXml(v)); return coerceToString(*i->value, context, coerceMore, copyToStore); } @@ -1136,7 +1150,7 @@ string EvalState::coerceToString(Value & v, PathSet & context, } } - throwTypeError("cannot coerce %1% to a string", showType(v)); + throwTypeError("cannot coerce %1% to a string", showTypeOrXml(v)); } @@ -1210,7 +1224,7 @@ bool EvalState::eqValues(Value & v1, Value & v2) return false; default: - throwEvalError("cannot compare %1% with %2%", showType(v1), showType(v2)); + throwEvalError("cannot compare %1% with %2%", showTypeOrXml(v1), showTypeOrXml(v2)); } } diff --git a/src/libexpr/eval.hh b/src/libexpr/eval.hh index 7453ac1..52bda5b 100644 --- a/src/libexpr/eval.hh +++ b/src/libexpr/eval.hh @@ -294,6 +294,8 @@ private: void addPrimOp(const string & name, unsigned int arity, PrimOpFun primOp); + string showTypeOrXml(Value &v); + Value * lookupVar(Env * env, const VarRef & var); friend class ExprVar; diff --git a/src/libmain/shared.cc b/src/libmain/shared.cc index 3110c94..41c1463 100644 --- a/src/libmain/shared.cc +++ b/src/libmain/shared.cc @@ -241,6 +241,9 @@ static void initAndRun(int argc, char * * argv) useBuildHook = false; else if (arg == "--show-trace") showTrace = true; + else if (arg == "--xml-debug-coercion-failure") { + xmldebugCorcionFailure = true; + } else if (arg == "--option") { ++i; if (i == args.end()) throw UsageError("`--option' requires two arguments"); string name = *i; diff --git a/src/libstore/globals.cc b/src/libstore/globals.cc index 7069d10..aa90d46 100644 --- a/src/libstore/globals.cc +++ b/src/libstore/globals.cc @@ -24,6 +24,7 @@ Verbosity buildVerbosity = lvlError; unsigned int maxBuildJobs = 1; unsigned int buildCores = 1; bool readOnlyMode = false; +bool xmldebugCorcionFailure = false; string thisSystem = "unset"; time_t maxSilentTime = 0; Paths substituters; diff --git a/src/libstore/globals.hh b/src/libstore/globals.hh index a74a741..f5893bb 100644 --- a/src/libstore/globals.hh +++ b/src/libstore/globals.hh @@ -110,7 +110,11 @@ void overrideSetting(const string & name, const Strings & value); void reloadSettings(); - +/* if set to true this prints the type which nix tried to coerce to a non matching type + * printing the xml can lead to infinite recursions etc.. So this is for + * debugging your Nix code only + */ +extern bool xmldebugCorcionFailure; } diff --git a/src/nix-instantiate/nix-instantiate.cc b/src/nix-instantiate/nix-instantiate.cc index 3d3b643..9e2652c 100644 --- a/src/nix-instantiate/nix-instantiate.cc +++ b/src/nix-instantiate/nix-instantiate.cc @@ -97,6 +97,9 @@ void run(Strings args) readOnlyMode = true; evalOnly = true; } + else if (arg == "--xml-debug-coercion-failure") { + xmldebugCorcionFailure = true; + } else if (arg == "--parse-only") { readOnlyMode = true; parseOnly = evalOnly = true; -- 1.6.6.2 From marco-oweber at gmx.de Mon Mar 14 09:22:38 2011 From: marco-oweber at gmx.de (Marc Weber) Date: Mon, 14 Mar 2011 08:22:38 +0000 Subject: [Nix-dev] Fwd: nix-commits Digest, Vol 44, Issue 33 Message-ID: <1300090658-sup-4558@nixos> stripped from commit messages: > Log: > Hakyll needs time >= 1.2 > Author: andres > Log: > Upgraded Hakyll to 2.4.3. > I know, that's not the latest version, but Hakyll-3 is rather > different from Hakyll-2 and the upgrade would require more work. ... Pushed a commit making hack-nix build it. You should really give it a try - even though the design is not what you would have done. It still gets the job done perfectly. Thanks for adding new ghc recently! Yours Marc Weber From olexiyb at gmail.com Mon Mar 14 15:11:29 2011 From: olexiyb at gmail.com (Olexiy Buyanskyy) Date: Mon, 14 Mar 2011 10:11:29 -0400 Subject: [Nix-dev] contribute patches and support of AIX platform Message-ID: Hi, I am curious is bug tracking reviewed by anybody? I have submitted two bugs http://yellowgrass.org/issue/Nix/207 http://yellowgrass.org/issue/Nix/215 And did not get any reply from anybody. I am currently working on ProofOfConcept of using nix as package management system (initially on AIX) for my company that works for Lowes's (www.lowes.com) I was able to compile and run tests. I have some issues to parse whole tree of nixpkgs (coredump issue) I also added http://wiki.nixos.org/wiki/Compile_Nix_on_AIX If I will successful with POC several developers would be assigned to work on that project. Where should I submit issues: mailing list or bug tracking? Does anybody have experience to run nix on AIX? -- Olexiy Buyanskyy From shea at shealevy.com Mon Mar 14 20:20:33 2011 From: shea at shealevy.com (Shea Levy) Date: Mon, 14 Mar 2011 15:20:33 -0400 Subject: [Nix-dev] [***SPAM***] GPT fdisk: A Partitioning Tool for GPT disks Message-ID: <4D7E6A81.7090202@shealevy.com> Hi all, Attached is an expression for gdisk (http://www.rodsbooks.com/gdisk/). It provides tools for formatting GPT drives using an interface similar to that of fdisk. Cheers, Shea Levy -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: gptfdisk.patch Url: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110314/cc0c604f/attachment.pl From marco-oweber at gmx.de Mon Mar 14 22:13:30 2011 From: marco-oweber at gmx.de (Marc Weber) Date: Mon, 14 Mar 2011 21:13:30 +0000 Subject: [Nix-dev] contribute patches and support of AIX platform In-Reply-To: References: Message-ID: <1300137029-sup-811@nixos> I personally don't pay too much attention to the bug tracker. So also pasting to the mailinglist is probably a good idea. About aix not having gnu make: Would having a cmake build system help? I worte a partial support and someone else did so as well recently. Both implementations would need some additional love. But if it helps .. Or do you happen to know whether automake can recreate a makefile which can be run by your system? Probably this is all you have to do ? (guessing blindly) This is my opinion only - and I only maintain two small patches for Nix myself. Marc Weber From viriketo at gmail.com Mon Mar 14 22:14:01 2011 From: viriketo at gmail.com (=?iso-8859-1?Q?Llu=EDs?= Batlle i Rossell) Date: Mon, 14 Mar 2011 22:14:01 +0100 Subject: [Nix-dev] [***SPAM***] GPT fdisk: A Partitioning Tool for GPT disks In-Reply-To: <4D7E6A81.7090202@shealevy.com> References: <4D7E6A81.7090202@shealevy.com> Message-ID: <20110314211359.GK32257@vicerveza.homeunix.net> On Mon, Mar 14, 2011 at 03:20:33PM -0400, Shea Levy wrote: > Hi all, > > Attached is an expression for gdisk > (http://www.rodsbooks.com/gdisk/). It provides tools for formatting > GPT drives using an interface similar to that of fdisk. I committed it. It built fine. Thank you! From viriketo at gmail.com Mon Mar 14 22:26:37 2011 From: viriketo at gmail.com (=?iso-8859-1?Q?Llu=EDs?= Batlle i Rossell) Date: Mon, 14 Mar 2011 22:26:37 +0100 Subject: [Nix-dev] contribute patches and support of AIX platform In-Reply-To: References: Message-ID: <20110314212636.GL32257@vicerveza.homeunix.net> On Mon, Mar 14, 2011 at 10:11:29AM -0400, Olexiy Buyanskyy wrote: > Hi, > > I am curious is bug tracking reviewed by anybody? > I have submitted two bugs > > http://yellowgrass.org/issue/Nix/207 > http://yellowgrass.org/issue/Nix/215 > At that time the issue addition was not emailed anywhere, but now it is. It should be easier to catch them there now. I think the yellowgrass tracker works more as a reminder for 'things to do', than any place to discuss about issues found. But that's just my impression, and those who started using it may clarify their intention. :) I don't know much automake/autoconf, and I'm not sure if your information is enough to update nix for your system. So I think that if you could provide a patch that worked for you, and does not break non-AIX, it would be accepted quickly. > I was able to compile and run tests. I have some issues to parse whole > tree of nixpkgs (coredump issue) Nix used to have a big stack footprint, and maybe still does. You could check this. Nix also uses the libgc, that may not be stable on AIX (with whatever processor you use there). I don't know if it can be compiled without libgc nowadays, but for sure you could try an older release that did not involve libgc at all. Regards, Llu?s. > Where should I submit issues: mailing list or bug tracking? If you expect any discussion beyond "note that some day I'd like you to fix this", I think the mailing list will work better. > Does anybody have experience to run nix on AIX? zero. Regards, Llu?s. From olexiyb at gmail.com Tue Mar 15 14:04:00 2011 From: olexiyb at gmail.com (Olexiy Buyanskyy) Date: Tue, 15 Mar 2011 09:04:00 -0400 Subject: [Nix-dev] contribute patches and support of AIX platform In-Reply-To: <20110314212636.GL32257@vicerveza.homeunix.net> References: <20110314212636.GL32257@vicerveza.homeunix.net> Message-ID: Llu?s, 2011/3/14 Llu?s Batlle i Rossell : > On Mon, Mar 14, 2011 at 10:11:29AM -0400, Olexiy Buyanskyy wrote: >> Hi, >> >> I am curious is bug tracking reviewed by anybody? >> I have submitted two bugs >> >> http://yellowgrass.org/issue/Nix/207 >> http://yellowgrass.org/issue/Nix/215 >> > At that time the issue addition was not emailed anywhere, but now it is. It > should be easier to catch them there now. I think the yellowgrass tracker works > more as a reminder for 'things to do', than any place to discuss about issues > found. But that's just my impression, and those who started using it may > clarify their intention. :) Can some one just confirm that http://yellowgrass.org/issue/Nix/215 is really issue? So I will prepare patch. > > I don't know much automake/autoconf, and I'm not sure if your information is > enough to update nix for your system. So I think that if you could provide a > patch that worked for you, and does not break non-AIX, it would be accepted > quickly. I have attached patch to fix small test issue here http://yellowgrass.org/issue/Nix/207 > >> I was able to compile and run tests. I have some issues to parse whole >> tree of nixpkgs (coredump issue) > > Nix used to have a big stack footprint, and maybe still does. You could check > this. I think you were right about gcc stability. I have used gcc 3.4.2 instead and now get error: St9bad_alloc. I think this is because of compilation difference between gcc 3.4.2 and gcc 4.2. I suspect that gcc 3.4.2 by default use -qlanglvl=newexcp, but gcc 4.2 does not. I also found that nix-env eats a lot of data segment memory with default ulimit -d 131072 it able to process 2824 nix files when I set ulimit -d unlimited it able to process 3908 nix files This does not have any sense to me. bad_alloc should be thrown if no dynamic memory, but I have max memory size (kbytes, -m) unlimited virtual memory (kbytes, -v) unlimited Going to investigate more From shea at shealevy.com Tue Mar 15 17:03:41 2011 From: shea at shealevy.com (Shea Levy) Date: Tue, 15 Mar 2011 12:03:41 -0400 Subject: [Nix-dev] Re: [Nix-commits] SVN commit: nix - r26304 - in nixpkgs/trunk/pkgs: lib tools/system/gptfdisk top-level In-Reply-To: <20110314211336.3FBE3108C013@mx3.tudelft.nl> References: <20110314211336.3FBE3108C013@mx3.tudelft.nl> Message-ID: <4D7F8DDD.9080006@shealevy.com> On 3/14/11 5:13 PM, Llu?s Batlle wrote: > Author: viric > Date: Mon Mar 14 21:13:35 2011 > New Revision: 26304 > URL: https://svn.nixos.org/websvn/nix/?rev=26304&sc=1 > > Log: > Adding gptfdisk (patch by Shea Levy). > I add him in the maintainers list. > I changed slightly the indentation of the expressions. > > Added: > nixpkgs/trunk/pkgs/tools/system/gptfdisk/ > nixpkgs/trunk/pkgs/tools/system/gptfdisk/default.nix > Modified: > nixpkgs/trunk/pkgs/lib/maintainers.nix > nixpkgs/trunk/pkgs/top-level/all-packages.nix > > Modified: nixpkgs/trunk/pkgs/lib/maintainers.nix > ============================================================================== > --- nixpkgs/trunk/pkgs/lib/maintainers.nix Mon Mar 14 18:26:46 2011 (r26303) > +++ nixpkgs/trunk/pkgs/lib/maintainers.nix Mon Mar 14 21:13:35 2011 (r26304) > @@ -21,6 +21,7 @@ > raskin = "Michael Raskin<7c6f434c at mail.ru>"; > roconnor = "Russell O'Connor"; > sander = "Sander van der Burg"; > + shlevy = "Shea Levy"; > simons = "Peter Simons"; > thammers = "Tobias Hammerschmidt"; > urkud = "Yury G. Kudryashov"; > > Added: nixpkgs/trunk/pkgs/tools/system/gptfdisk/default.nix > ============================================================================== > --- /dev/null 00:00:00 1970 (empty, because file is newly added) > +++ nixpkgs/trunk/pkgs/tools/system/gptfdisk/default.nix Mon Mar 14 21:13:35 2011 (r26304) > @@ -0,0 +1,31 @@ > +{ fetchurl, stdenv, libuuid, popt }: > + > +stdenv.mkDerivation rec { > + name = "gptfdisk-0.7.0"; > + > + src = fetchurl { > + url = "http://www.rodsbooks.com/gdisk/${name}.tgz"; > + sha256 = "1912l01pj7wcaj2fp06yl6m893c52qh2qy0bkx33k6iq2k747zrf"; > + }; > + > + buildInputs = [ libuuid popt ]; > + > + installPhase = '' > + ensureDir $out/bin > + ensureDir $out/share/man/man8 > + install -v -m755 gdisk sgdisk fixparts $out/bin > + install -v -m644 gdisk.8 sgdisk.8 fixparts.8 \ > + $out/share/man/man8 > + ''; > + > + meta = { > + description = "A set of text-mode partitioning tools for Globally Unique Identifier (GUID) Partition Table (GPT) disks"; > + > + license = "GPLv2"; > + > + homepage = http://www.rodsbooks.com/gdisk/; > + > + maintainers = stdenv.lib.maintainers.shlevy; > + platforms = stdenv.lib.platforms.linux; > + }; > +} > > Modified: nixpkgs/trunk/pkgs/top-level/all-packages.nix > ============================================================================== > --- nixpkgs/trunk/pkgs/top-level/all-packages.nix Mon Mar 14 18:26:46 2011 (r26303) > +++ nixpkgs/trunk/pkgs/top-level/all-packages.nix Mon Mar 14 21:13:35 2011 (r26304) > @@ -726,6 +726,8 @@ > > gource = callPackage ../tools/misc/gource { }; > > + gptfdisk = callPackage ../tools/system/gptfdisk { }; > + > graphviz = callPackage ../tools/graphics/graphviz { > inherit (gtkLibs) pango; > }; > _______________________________________________ > nix-commits mailing list > nix-commits at cs.uu.nl > http://mail.cs.uu.nl/mailman/listinfo/nix-commits Whoops, these binaries should really go into $out/sbin, not $out/bin. Patch attached. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: gptfdisk-sbin.patch Url: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110315/1bf11fd5/attachment.pl From olexiyb at gmail.com Tue Mar 15 18:26:54 2011 From: olexiyb at gmail.com (Olexiy Buyanskyy) Date: Tue, 15 Mar 2011 13:26:54 -0400 Subject: [Nix-dev] error with nixpkgs_ustable tarball and channel Message-ID: Hi, I have followed instructions on http://nixos.org/nixpkgs/download.html $ nix-channel --add \ http://nixos.org/releases/nixpkgs/channels/nixpkgs-unstable $ nix-channel --update $ nix-env -qa '*' error: opening file `/home/s0998ob2/.nix-defexpr/channels/-2/pkgs/applications/networking/browsers/mozilla-plugins/flashplayer-9/default.nix': No such file or directory I also tried to download http://hydra.nixos.org/job/nixpkgs/trunk/tarball/latest and got the same error. I see file pkgs/applications/networking/browsers/mozilla-plugins/flashplayer-9/default.ni missing 'x' I found workaround with svn checkout, but I think this is good to fix. -- Olexiy Buyanskyy From viriketo at gmail.com Tue Mar 15 18:38:30 2011 From: viriketo at gmail.com (=?iso-8859-1?Q?Llu=EDs?= Batlle i Rossell) Date: Tue, 15 Mar 2011 18:38:30 +0100 Subject: [Nix-dev] error with nixpkgs_ustable tarball and channel In-Reply-To: References: Message-ID: <20110315173829.GM32257@vicerveza.homeunix.net> On Tue, Mar 15, 2011 at 01:26:54PM -0400, Olexiy Buyanskyy wrote: > Hi, > I see file pkgs/applications/networking/browsers/mozilla-plugins/flashplayer-9/default.ni > missing 'x' I just tried: $ curl http://nixos.org/releases/nixpkgs/channels/nixpkgs-unstable/nixexprs.tar.bz2 | bunzip2 | tar tv | grep flash -rw-r--r-- nixbld/nixbld 914 1970-01-01 01:00 nixpkgs-0.14pre26329/pkgs/applications/networking/browsers/mozilla-plugins/flashplayer-9/default.nix It has the x. Maybe it is some peculiarity of AIX tar? From olexiyb at gmail.com Tue Mar 15 21:31:09 2011 From: olexiyb at gmail.com (Olexiy Buyanskyy) Date: Tue, 15 Mar 2011 16:31:09 -0400 Subject: [Nix-dev] contribute patches and support of AIX platform In-Reply-To: References: <20110314212636.GL32257@vicerveza.homeunix.net> Message-ID: All, On Tue, Mar 15, 2011 at 9:04 AM, Olexiy Buyanskyy wrote: > Llu?s, > > 2011/3/14 Llu?s Batlle i Rossell : >> On Mon, Mar 14, 2011 at 10:11:29AM -0400, Olexiy Buyanskyy wrote: >> >> I don't know much automake/autoconf, and I'm not sure if your information is >> enough to update nix for your system. So I think that if you could provide a >> patch that worked for you, and does not break non-AIX, it would be accepted >> quickly. > I have attached patch to fix small test issue here > http://yellowgrass.org/issue/Nix/207 > >> >>> I was able to compile and run tests. I have some issues to parse whole >>> tree of nixpkgs (coredump issue) >> >> Nix used to have a big stack footprint, and maybe still does. You could check >> this. > I think you were right about gcc stability. I have used gcc 3.4.2 > instead and now get > error: St9bad_alloc. I think this is because of compilation difference > between gcc 3.4.2 and gcc 4.2. > I suspect that gcc 3.4.2 by default use -qlanglvl=newexcp, but gcc 4.2 does not. > > I also found that nix-env eats a lot of data segment memory > with default ulimit -d 131072 it able to process 2824 nix files > when I set ulimit -d unlimited it able to process 3908 nix files > > This does not have any sense to me. bad_alloc should be thrown if no > dynamic memory, but I have > max memory size ? ? ? (kbytes, -m) unlimited > virtual memory ? ? ? ?(kbytes, -v) unlimited > Going to investigate more > I found solution here http://publib.boulder.ibm.com/tividd/td/ITAME/GC32-0846-00/en_US/HTML/am39_perftune11.htm I had to set to complete nix-env execution without std::bad_alloc export LDR_CNTRL=MAXDATA=0x2000000 This means nix-env requires at least 512Mb to parse all nix files And I also see really bad performance $ time nix-env -qaf nixpkgs '*' real 2m3.254s user 0m35.016s sys 0m0.306s My box is not very slow: Number Of Processors: 1 Processor Clock Speed: 2097 MHz -- Olexiy From marco-oweber at gmx.de Tue Mar 15 21:39:59 2011 From: marco-oweber at gmx.de (Marc Weber) Date: Tue, 15 Mar 2011 20:39:59 +0000 Subject: [Nix-dev] contribute patches and support of AIX platform In-Reply-To: References: <20110314212636.GL32257@vicerveza.homeunix.net> Message-ID: <1300221525-sup-5421@nixos> Excerpts from Olexiy Buyanskyy's message of Tue Mar 15 20:31:09 +0000 2011: I found solution here > http://publib.boulder.ibm.com/tividd/td/ITAME/GC32-0846-00/en_US/HTML/am39_perftune11.htm > I had to set to complete nix-env execution without std::bad_alloc > export LDR_CNTRL=MAXDATA=0x2000000 > This means nix-env requires at least 512Mb to parse all nix files You can prevent it from sourcing all by using the -A path flag. Eg nix-env -iA xorg.xserver. See wiki article "how to find .." Marc Weber From olexiyb at gmail.com Tue Mar 15 22:23:59 2011 From: olexiyb at gmail.com (Olexiy Buyanskyy) Date: Tue, 15 Mar 2011 17:23:59 -0400 Subject: [Nix-dev] error with nixpkgs_ustable tarball and channel In-Reply-To: <20110315173829.GM32257@vicerveza.homeunix.net> References: <20110315173829.GM32257@vicerveza.homeunix.net> Message-ID: Hi, 2011/3/15 Llu?s Batlle i Rossell : > On Tue, Mar 15, 2011 at 01:26:54PM -0400, Olexiy Buyanskyy wrote: >> Hi, >> I see file pkgs/applications/networking/browsers/mozilla-plugins/flashplayer-9/default.ni >> missing 'x' > > I just tried: > $ curl http://nixos.org/releases/nixpkgs/channels/nixpkgs-unstable/nixexprs.tar.bz2 | bunzip2 | tar tv | grep flash > -rw-r--r-- nixbld/nixbld ? ?914 1970-01-01 01:00 > nixpkgs-0.14pre26329/pkgs/applications/networking/browsers/mozilla-plugins/flashplayer-9/default.nix > > It has the x. > > Maybe it is some peculiarity of AIX You were right about this. I had some ancient version of tar tar-1.13-4 After installation of tar-1.26-1 it works now. I will document this as requirement for nix here http://wiki.nixos.org/wiki/Compile_Nix_on_AIX -- Olexiy From shea at shealevy.com Wed Mar 16 03:46:25 2011 From: shea at shealevy.com (Shea Levy) Date: Tue, 15 Mar 2011 22:46:25 -0400 Subject: [Nix-dev] firefox40Pkgs.firefox build failure. Message-ID: <4D802481.5080506@shealevy.com> Hi all, I just added firefox40Pkgs.firefox to my environment.x11Packages, and nixos-rebuild switch failed with "undefined variable `p'". The full trace and my configuration.nix can be found here . I've not had a chance to step through the trace yet, but if I figure out the problem I'll report back. Cheers, Shea Levy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110315/e397dce2/attachment.html From marco-oweber at gmx.de Wed Mar 16 04:01:35 2011 From: marco-oweber at gmx.de (Marc Weber) Date: Wed, 16 Mar 2011 03:01:35 +0000 Subject: [Nix-dev] firefox40Pkgs.firefox build failure. In-Reply-To: <4D802481.5080506@shealevy.com> References: <4D802481.5080506@shealevy.com> Message-ID: <1300244289-sup-6355@nixos> Excerpts from Shea Levy's message of Wed Mar 16 02:46:25 +0000 2011: > the trace yet, but if I figure out the problem I'll report back. Which revision? -r 26267 builds here (after updating sources), but I don't know how to run it cause xul is not configured correctly. It fails on startup. Maybe someone just knows what has to be done? Marc Weber From shea at shealevy.com Wed Mar 16 04:03:14 2011 From: shea at shealevy.com (Shea Levy) Date: Tue, 15 Mar 2011 23:03:14 -0400 Subject: [Nix-dev] firefox40Pkgs.firefox build failure. In-Reply-To: <1300244289-sup-6355@nixos> References: <4D802481.5080506@shealevy.com> <1300244289-sup-6355@nixos> Message-ID: <4D802872.7020603@shealevy.com> On 3/15/11 11:01 PM, Marc Weber wrote: > Excerpts from Shea Levy's message of Wed Mar 16 02:46:25 +0000 2011: >> the trace yet, but if I figure out the problem I'll report back. > Which revision? > > -r 26267 builds here (after updating sources), but I don't know how to > run it cause xul is not configured correctly. It fails on startup. Maybe > someone just knows what has to be done? > > Marc Weber > _______________________________________________ > nix-dev mailing list > nix-dev at cs.uu.nl > https://mail.cs.uu.nl/mailman/listinfo/nix-dev Revision 26337 for nixos and nixpkgs. From marco-oweber at gmx.de Wed Mar 16 04:31:56 2011 From: marco-oweber at gmx.de (Marc Weber) Date: Wed, 16 Mar 2011 03:31:56 +0000 Subject: [Nix-dev] commit review (ludo, Karn, eelco) Message-ID: <1300245409-sup-8118@nixos> 1) ludo 2) Karn 3) eelco 1) Author: ludo Modified: nixpkgs/trunk/pkgs/build-support/fetchgit/nix-prefetch-git ============================================================================== --- nixpkgs/trunk/pkgs/build-support/fetchgit/nix-prefetch-git Mon Mar 14 21:13:35 2011 (r26304) +++ nixpkgs/trunk/pkgs/build-support/fetchgit/nix-prefetch-git Mon Mar 14 22:00:20 2011 (r26305) @@ -120,6 +120,17 @@ # Checkout linked sources. init_submodules; + if [ -f .topdeps ]; then + if tg help 2>&1 > /dev/null + then + echo "populating TopGit branches..." + tg remote --populate origin + else + echo "WARNING: would populate TopGit branches but TopGit is not available" >&2 + echo "WARNING: install TopGit to fix the problem" >&2 + fi + fi + cd $top; } I've trouble with the wording "problem". The topic branches are fetched as remotes anyway. top-git is only important if you want to run tg update. However doing so will create local hashes which do not exist on a remote server thus its useless. So not using top-git is not a "problem". The real question is: should nix-prefetch-git populate local branches for all remote branches automatically? It looks to me like you tried doing that. Your comments suggest that you should install top-git because otherwise something doesn't work which is not the case. Without git you can still git checkout origin/NAME etc. 2) Update flapjax compiler Let me show you how to use hack-nix because you can do this automatically by nix-repository-manager 1 . --update flapjax and be done. 3) merge failure (xorg-updates) - firefox40Pkgs = let p = (applyGlobalOverrides (x : {cairo = x.cairo_1_10_0;})); - in p.callPackage - ../applications/networking/browsers/firefox/4.0.nix { + firefox40Pkgs = callPackage ../applications/networking/browsers/firefox/4.0.nix { inherit (p.gtkLibs) gtk pango; inherit (p.gnome) libIDL; }; Source is broken anyway and the result doesn't run (?) See other thread. So its not very important ? Thanks for doing it. With some luck I can get rid of the proprietary ATI driver now. I'll try and provide feedback soon. Marc Weber From shea at shealevy.com Wed Mar 16 04:36:54 2011 From: shea at shealevy.com (Shea Levy) Date: Tue, 15 Mar 2011 23:36:54 -0400 Subject: [Nix-dev] commit review (ludo, Karn, eelco) In-Reply-To: <1300245409-sup-8118@nixos> References: <1300245409-sup-8118@nixos> Message-ID: <4D803056.4070501@shealevy.com> On 3/15/11 11:31 PM, Marc Weber wrote: > 3) eelco > > 3) merge failure (xorg-updates) > > - firefox40Pkgs = let p = (applyGlobalOverrides (x : {cairo = x.cairo_1_10_0;})); > - in p.callPackage > - ../applications/networking/browsers/firefox/4.0.nix { > + firefox40Pkgs = callPackage ../applications/networking/browsers/firefox/4.0.nix { > inherit (p.gtkLibs) gtk pango; > inherit (p.gnome) libIDL; > }; > This pinpoints the source of my problem in the previous thread. Removing the p. and seeing what happens. From marco-oweber at gmx.de Wed Mar 16 04:52:04 2011 From: marco-oweber at gmx.de (Marc Weber) Date: Wed, 16 Mar 2011 03:52:04 +0000 Subject: [Nix-dev] firefox40Pkgs.firefox build failure. In-Reply-To: <4D802872.7020603@shealevy.com> References: <4D802481.5080506@shealevy.com> <1300244289-sup-6355@nixos> <4D802872.7020603@shealevy.com> Message-ID: <1300246336-sup-7918@nixos> Excerpts from Shea Levy's message of Wed Mar 16 03:03:14 +0000 2011: > On 3/15/11 11:01 PM, Marc Weber wrote: > > Excerpts from Shea Levy's message of Wed Mar 16 02:46:25 +0000 2011: > >> the trace yet, but if I figure out the problem I'll report back. > > Which revision? > > > > -r 26267 builds here (after updating sources), but I don't know how to > > run it cause xul is not configured correctly. It fails on startup. Maybe > > someone just knows what has to be done? See my short patch review. Eelco missed this small detail when merging the x-udpates branch. Apply the reverse patch of what I quoted and you're done .. except that the source is gone. beta was 12 some days ago: rec { - firefoxVersion = "4.0b7"; + firefoxVersion = "4.0b12"; - xulVersion = "2.0b7"; # this attribute is used by other packages + xulVersion = "2.0b12"; # this attribute is used by other packages src = fetchurl { url = "http://releases.mozilla.org/pub/mozilla.org/firefox/releases/${firefoxVersion}/source/firefox-${firefoxVersion}.sour - sha256 = "02cc466a92af828ff3bc563d4515bd98064cf5f136b5871e072b9408fb4db128"; + sha256 = "99e7f17d62d92d37aee850bdf7dfdc8572254e4b6c3c8b8f51143df06f2a04d9"; }; Good luck. Marc Weber From shea at shealevy.com Wed Mar 16 04:54:25 2011 From: shea at shealevy.com (Shea Levy) Date: Tue, 15 Mar 2011 23:54:25 -0400 Subject: [Nix-dev] firefox40Pkgs.firefox build failure. In-Reply-To: <1300246336-sup-7918@nixos> References: <4D802481.5080506@shealevy.com> <1300244289-sup-6355@nixos> <4D802872.7020603@shealevy.com> <1300246336-sup-7918@nixos> Message-ID: <4D803471.6020700@shealevy.com> On 3/15/11 11:52 PM, Marc Weber wrote: > Excerpts from Shea Levy's message of Wed Mar 16 03:03:14 +0000 2011: >> On 3/15/11 11:01 PM, Marc Weber wrote: >>> Excerpts from Shea Levy's message of Wed Mar 16 02:46:25 +0000 2011: >>>> the trace yet, but if I figure out the problem I'll report back. >>> Which revision? >>> >>> -r 26267 builds here (after updating sources), but I don't know how to >>> run it cause xul is not configured correctly. It fails on startup. Maybe >>> someone just knows what has to be done? > See my short patch review. Eelco missed this small detail when > merging the x-udpates branch. > > Apply the reverse patch of what I quoted and you're done .. except that > the source is gone. > > beta was 12 some days ago: > > rec { > > - firefoxVersion = "4.0b7"; > + firefoxVersion = "4.0b12"; > > - xulVersion = "2.0b7"; # this attribute is used by other packages > + xulVersion = "2.0b12"; # this attribute is used by other packages > > > src = fetchurl { > url = "http://releases.mozilla.org/pub/mozilla.org/firefox/releases/${firefoxVersion}/source/firefox-${firefoxVersion}.sour > - sha256 = "02cc466a92af828ff3bc563d4515bd98064cf5f136b5871e072b9408fb4db128"; > + sha256 = "99e7f17d62d92d37aee850bdf7dfdc8572254e4b6c3c8b8f51143df06f2a04d9"; > }; > > Good luck. > Marc Weber > _______________________________________________ > nix-dev mailing list > nix-dev at cs.uu.nl > https://mail.cs.uu.nl/mailman/listinfo/nix-dev Actually, the 4.0b12 directory is gone and now there's a 4.0rc1 directory as of March 10. From shea at shealevy.com Wed Mar 16 05:19:29 2011 From: shea at shealevy.com (Shea Levy) Date: Wed, 16 Mar 2011 00:19:29 -0400 Subject: [Nix-dev] firefox40Pkgs.firefox build failure. In-Reply-To: <4D803471.6020700@shealevy.com> References: <4D802481.5080506@shealevy.com> <1300244289-sup-6355@nixos> <4D802872.7020603@shealevy.com> <1300246336-sup-7918@nixos> <4D803471.6020700@shealevy.com> Message-ID: <4D803A51.5040606@shealevy.com> On 3/15/11 11:54 PM, Shea Levy wrote: > On 3/15/11 11:52 PM, Marc Weber wrote: >> Excerpts from Shea Levy's message of Wed Mar 16 03:03:14 +0000 2011: >>> On 3/15/11 11:01 PM, Marc Weber wrote: >>>> Excerpts from Shea Levy's message of Wed Mar 16 02:46:25 +0000 2011: >>>>> the trace yet, but if I figure out the problem I'll report back. >>>> Which revision? >>>> >>>> -r 26267 builds here (after updating sources), but I don't know how to >>>> run it cause xul is not configured correctly. It fails on startup. >>>> Maybe >>>> someone just knows what has to be done? >> See my short patch review. Eelco missed this small detail when >> merging the x-udpates branch. >> >> Apply the reverse patch of what I quoted and you're done .. except that >> the source is gone. >> >> beta was 12 some days ago: >> >> rec { >> >> - firefoxVersion = "4.0b7"; >> + firefoxVersion = "4.0b12"; >> >> - xulVersion = "2.0b7"; # this attribute is used by other packages >> + xulVersion = "2.0b12"; # this attribute is used by other packages >> >> >> src = fetchurl { >> url = >> "http://releases.mozilla.org/pub/mozilla.org/firefox/releases/${firefoxVersion}/source/firefox-${firefoxVersion}.sour >> - sha256 = >> "02cc466a92af828ff3bc563d4515bd98064cf5f136b5871e072b9408fb4db128"; >> + sha256 = >> "99e7f17d62d92d37aee850bdf7dfdc8572254e4b6c3c8b8f51143df06f2a04d9"; >> }; >> >> Good luck. >> Marc Weber >> _______________________________________________ >> nix-dev mailing list >> nix-dev at cs.uu.nl >> https://mail.cs.uu.nl/mailman/listinfo/nix-dev > > Actually, the 4.0b12 directory is gone and now there's a 4.0rc1 > directory as of March 10. > _______________________________________________ > nix-dev mailing list > nix-dev at cs.uu.nl > https://mail.cs.uu.nl/mailman/listinfo/nix-dev Ok, I've updated to 4.0rc1, which required updating NSPR to 4.8.7. Building now, will report with results. From e.dolstra at tudelft.nl Wed Mar 16 10:22:56 2011 From: e.dolstra at tudelft.nl (Eelco Dolstra) Date: Wed, 16 Mar 2011 10:22:56 +0100 Subject: [Nix-dev] x-updates branch merged Message-ID: <4D808170.9030404@tudelft.nl> Hi all, As you may have noticed I've merged the Nixpkgs x-updates branch into the trunk. It provides X11R7.6 (with various updates, including xorg-server 1.9.4), Mesa 7.10.1, GTK+ 2.24.3 and other X11-related updates. Please report any problems you encounter here. -- Eelco Dolstra | http://www.st.ewi.tudelft.nl/~dolstra/ From viriketo at gmail.com Wed Mar 16 11:49:31 2011 From: viriketo at gmail.com (=?iso-8859-1?Q?Llu=EDs?= Batlle i Rossell) Date: Wed, 16 Mar 2011 11:49:31 +0100 Subject: [Nix-dev] contribute patches and support of AIX platform In-Reply-To: References: <20110314212636.GL32257@vicerveza.homeunix.net> Message-ID: <20110316104929.GQ32257@vicerveza.homeunix.net> On Tue, Mar 15, 2011 at 04:31:09PM -0400, Olexiy Buyanskyy wrote: > All, > > On Tue, Mar 15, 2011 at 9:04 AM, Olexiy Buyanskyy wrote: > I found solution here > http://publib.boulder.ibm.com/tividd/td/ITAME/GC32-0846-00/en_US/HTML/am39_perftune11.htm > I had to set to complete nix-env execution without std::bad_alloc > export LDR_CNTRL=MAXDATA=0x2000000 > This means nix-env requires at least 512Mb to parse all nix files > And I also see really bad performance > $ time nix-env -qaf nixpkgs '*' > real 2m3.254s > user 0m35.016s > sys 0m0.306s With those user/sys times, it looks like your machine is swapping a lot (using disk pages), or your filesystem delivers the file contents very slow. What about the amount of RAM dedicated to the nix-env process? Enough? What do you think that time consumption comes from? Eelco Dolstra once reported in the mailing list the evaluation times of some recent nix release, but I can't find it. For my system: 1st run) real 0m37.702s user 0m1.416s sys 0m0.515s 2nd run) (filesystem cache playing a heavier role) real 0m2.093s user 0m1.270s sys 0m0.340s It may also happen that libgc or libgcc or libstdc++ (exceptions specially) are not very well tuned for your system. That's for linux. Maybe the nixpkgs evaluation in your system is very different, but I don't think so. So, an interesting problem to solve. :) Regards, Llu?s. From olexiyb at gmail.com Wed Mar 16 13:00:44 2011 From: olexiyb at gmail.com (Olexiy Buyanskyy) Date: Wed, 16 Mar 2011 08:00:44 -0400 Subject: [Nix-dev] contribute patches and support of AIX platform In-Reply-To: <20110316104929.GQ32257@vicerveza.homeunix.net> References: <20110314212636.GL32257@vicerveza.homeunix.net> <20110316104929.GQ32257@vicerveza.homeunix.net> Message-ID: Hi, 2011/3/16 Llu?s Batlle i Rossell : > On Tue, Mar 15, 2011 at 04:31:09PM -0400, Olexiy Buyanskyy wrote: >> All, >> >> On Tue, Mar 15, 2011 at 9:04 AM, Olexiy Buyanskyy wrote: >> I found solution here >> http://publib.boulder.ibm.com/tividd/td/ITAME/GC32-0846-00/en_US/HTML/am39_perftune11.htm >> I had to set to complete nix-env execution without std::bad_alloc >> export LDR_CNTRL=MAXDATA=0x2000000 >> This means nix-env requires at least 512Mb to parse all nix files >> And I also see really bad performance >> $ time nix-env -qaf nixpkgs '*' >> real ? ?2m3.254s >> user ? ?0m35.016s >> sys ? ? 0m0.306s > > With those user/sys times, it looks like your machine is swapping a lot (using > disk pages), or your filesystem delivers the file contents very slow. What about > the amount of RAM dedicated to the nix-env process? Enough? > > What do you think that time consumption comes from? > > Eelco Dolstra once reported in the mailing list the evaluation times of some > recent nix release, but I can't find it. For my system: > > 1st run) > real ? ?0m37.702s > user ? ?0m1.416s > sys ? ? 0m0.515s > > 2nd run) ?(filesystem cache playing a heavier role) > real ? ?0m2.093s > user ? ?0m1.270s > sys ? ? 0m0.340s > > It may also happen that libgc or libgcc or libstdc++ (exceptions specially) are > not very well tuned for your system. > > That's for linux. Maybe the nixpkgs evaluation in your system is very different, > but I don't think so. So, an interesting problem to solve. :) I have run under valgrind (callgrind) and see that 95% of time was spend in cloneAttrs(). I am using the latest stable release nix-0.16 But interesting thing I do not see this function anymore in SVN trunk. Was this performance issue already addressed? -- Olexiy From e.dolstra at tudelft.nl Wed Mar 16 13:34:34 2011 From: e.dolstra at tudelft.nl (Eelco Dolstra) Date: Wed, 16 Mar 2011 13:34:34 +0100 Subject: [Nix-dev] contribute patches and support of AIX platform In-Reply-To: References: <20110314212636.GL32257@vicerveza.homeunix.net> <20110316104929.GQ32257@vicerveza.homeunix.net> Message-ID: <4D80AE5A.8040205@tudelft.nl> Hi, On 03/16/2011 01:00 PM, Olexiy Buyanskyy wrote: >> That's for linux. Maybe the nixpkgs evaluation in your system is very different, >> but I don't think so. So, an interesting problem to solve. :) > I have run under valgrind (callgrind) and see that 95% of time was > spend in cloneAttrs(). I am using the latest stable release nix-0.16 > But interesting thing I do not see this function anymore in SVN trunk. You should definitely try the latest Nix 1.0 prerelease (http://hydra.nixos.org/view/nix/trunk/latest). Among other improvements, it has a garbage collector that should reduce memory usage, provided you build with --enable-gc. -- Eelco Dolstra | http://www.st.ewi.tudelft.nl/~dolstra/ From ludo at gnu.org Wed Mar 16 16:04:16 2011 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Wed, 16 Mar 2011 16:04:16 +0100 Subject: [Nix-dev] nix-prefetch-git & TopGit References: <1300245409-sup-8118@nixos> Message-ID: <87oc5b6r9r.fsf@gnu.org> Hi Marc, Thanks for your review! Marc Weber writes: > Modified: nixpkgs/trunk/pkgs/build-support/fetchgit/nix-prefetch-git > ============================================================================== > --- nixpkgs/trunk/pkgs/build-support/fetchgit/nix-prefetch-git Mon Mar 14 21:13:35 2011 (r26304) > +++ nixpkgs/trunk/pkgs/build-support/fetchgit/nix-prefetch-git Mon Mar 14 22:00:20 2011 (r26305) > @@ -120,6 +120,17 @@ > # Checkout linked sources. > init_submodules; > > + if [ -f .topdeps ]; then > + if tg help 2>&1 > /dev/null > + then > + echo "populating TopGit branches..." > + tg remote --populate origin > + else > + echo "WARNING: would populate TopGit branches but TopGit is not available" >&2 > + echo "WARNING: install TopGit to fix the problem" >&2 > + fi > + fi > + > cd $top; > } > > I've trouble with the wording "problem". > > The topic branches are fetched as remotes anyway. Hmm, I don?t think so. Again, as discussed in the other thread, my use case is this: http://www.bddebian.com:8888/~hurd-web/source_repositories/glibc/ I swear that ?tg remote --populate? /must/ be performed, otherwise you can run any ?tg? command. > So not using top-git is not a "problem". Agreed, that?s why the script prints a warning instead of bailing out. > The real question is: should nix-prefetch-git populate local branches > for all remote branches automatically? > It looks to me like you tried doing that. Yes. Admittedly, turning nix-prefetch-git into a kitchen sink (like I did) isn?t ideal. However, I can?t think of any other way for my use case (hence my call for suggestions in <87wrk7apf8.fsf at gnu.org>.) > Your comments suggest that you should install top-git because otherwise > something doesn't work which is not the case. What wording would you suggest? Thanks, Ludo?. From ludo at gnu.org Wed Mar 16 16:11:18 2011 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Wed, 16 Mar 2011 16:11:18 +0100 Subject: [Nix-dev] Re: nix-prefetch-git & TopGit References: <1300245409-sup-8118@nixos> <87oc5b6r9r.fsf@gnu.org> Message-ID: <87k4fz6qy1.fsf@gnu.org> ludo at gnu.org (Ludovic Court?s) writes: > I swear that ?tg remote --populate? /must/ be performed, otherwise you > can run any ?tg? command. Err, s/can/cannot/. Ludo'. From marco-oweber at gmx.de Wed Mar 16 19:59:08 2011 From: marco-oweber at gmx.de (Marc Weber) Date: Wed, 16 Mar 2011 18:59:08 +0000 Subject: [Nix-dev] nix-prefetch-git & TopGit In-Reply-To: <87oc5b6r9r.fsf@gnu.org> References: <1300245409-sup-8118@nixos> <87oc5b6r9r.fsf@gnu.org> Message-ID: <1300301450-sup-8194@nixos> Excerpts from ludo's message of Wed Mar 16 15:04:16 +0000 2011: > I swear that \xe2\x80\x98tg remote --populate\xe2\x80\x99 /must/ be performed, otherwise you > can run any 'tg' command. s/can/can't/ ? We agree on this. Explain why you have to run any tg command, please. Which one do you want to run? Pointing to repo is not enough to make me understand your problem. What makes your use case different from git checkout -tb {,origin/}NAME NAME can be t/foo > What wording would you suggest? Simply dropping the word "problem" would be ok. I don't use the command so I don't too much. However it may lead to wrong impressions when users who don't know topgit at all read it. I'd like to understand why you have to use topgit commands at all. Because if you do so you'll create new hashes which will not be on remote servers. I've changed it to this in my local branches: else - echo "WARNING: would populate TopGit branches but TopGit is not available" >&2 - echo "WARNING: install TopGit to fix the problem" >&2 + # TODO: is this useful at all? Should for each remote branch a local branch be created? + echo "If you had installed TopGit I would have populated local topic branches" >&2 fi However the key point is understanding what you want to do and why you have to run top-git commands yourself. My understanding of nix-prefetch-* commands is that they should print a hash only which you can copy paste .. If we are at it: Can't we make it even smarter outputting full src = fetchurl { .. } code rewriting urls by mirrors? Marc Weber From olexiyb at gmail.com Wed Mar 16 22:33:06 2011 From: olexiyb at gmail.com (Olexiy Buyanskyy) Date: Wed, 16 Mar 2011 17:33:06 -0400 Subject: [Nix-dev] nix trunk coredumps on AIX. Where is --enable-static-nix option? Message-ID: Hi, I have issues to run the latest trunk version of nix-env on AIX. I think this is related to missing support of --enable-static-nix option. I see this was removed after merge of SQLite branch. I am not 100% why this coredump happening, but I just know that --enable-static-nix helped for me to get rid of those difficult to explain coredumps. I also took snapshot of sources before SQLLite branch merge and was able to compile and pass all tests. -- Olexiy Buyanskyy From Giulio.Eulisse at cern.ch Wed Mar 16 23:08:23 2011 From: Giulio.Eulisse at cern.ch (Giulio Eulisse) Date: Wed, 16 Mar 2011 23:08:23 +0100 Subject: [Nix-dev] [PATCH 0/2] Series short description Message-ID: <20110316220416.6285.31592.stgit@rowlf.local> I was trying to get nix HEAD build on macosx (mostly because I want to try out disnix), however it seems that there are a few issues. First of all the current ./bootstrap.sh does not seem to be compatible with the autoconf tools shipped on macosx, which I fixed using the first patch. Then it looks like the logic for the --enable-gc requires pkg-config, even if the garbage collector is not enabled. I fixed this by using the pkg-config command directly rather than the `PKG_CHECK_MODULES` macro, see the second patch. Done this it turns out that the bison which ships on macosx (v2.3) does not support the `%code requires` preamble statement which is used in parser.y (looks like %code requires was introduced in v2.3*b*). This goes beyond my ability to fix. Does anyone have any idea how to get it to work? Ciao, Giulio PS: notice I did build 0.16 without any problems, but it looks like such a version does not work with properly with the current nixpkgs trunk. --- Giulio Eulisse (2): Get bootstrap.sh work on macosx. Do not require pkg-config to be installed. Makefile.am | 1 + bootstrap.sh | 7 ++++++- configure.ac | 14 +++++++++----- 3 files changed, 16 insertions(+), 6 deletions(-) -- From Giulio.Eulisse at cern.ch Wed Mar 16 23:08:44 2011 From: Giulio.Eulisse at cern.ch (Giulio Eulisse) Date: Wed, 16 Mar 2011 23:08:44 +0100 Subject: [Nix-dev] [PATCH 2/2] Do not require pkg-config to be installed. In-Reply-To: <20110316220416.6285.31592.stgit@rowlf.local> References: <20110316220416.6285.31592.stgit@rowlf.local> Message-ID: <20110316220844.6285.80537.stgit@rowlf.local> --- configure.ac | 11 +++++++---- 1 files changed, 7 insertions(+), 4 deletions(-) -------------- next part -------------- diff --git a/configure.ac b/configure.ac index 11382ab..cd3072d 100644 --- a/configure.ac +++ b/configure.ac @@ -266,12 +266,15 @@ AC_SUBST(sqlite_bin) # Whether to use the Boehm garbage collector. AC_ARG_ENABLE(gc, AC_HELP_STRING([--enable-gc], [enable garbage collection in the Nix expression evaluator (requires Boehm GC)]), - gc=$enableval, gc=) -if test -n "$gc"; then - PKG_CHECK_MODULES([BDW_GC], [bdw-gc]) - CXXFLAGS="$BDW_GC_CFLAGS $CXXFLAGS" + [ gc=yes]) +if test "$gc" = yes; then + CXXFLAGS="`pkg-config --cflags bdw-gc` $CXXFLAGS" + BDW_GC_LIBS="`pkg-config --libs bdw-gc`" AC_DEFINE(HAVE_BOEHMGC, 1, [Whether to use the Boehm garbage collector.]) +else + BDW_GC_LIBS="" fi +AC_SUBST(BDW_GC_LIBS) AC_ARG_ENABLE(init-state, AC_HELP_STRING([--disable-init-state], From Giulio.Eulisse at cern.ch Wed Mar 16 23:08:33 2011 From: Giulio.Eulisse at cern.ch (Giulio Eulisse) Date: Wed, 16 Mar 2011 23:08:33 +0100 Subject: [Nix-dev] [PATCH 1/2] Get bootstrap.sh work on macosx. In-Reply-To: <20110316220416.6285.31592.stgit@rowlf.local> References: <20110316220416.6285.31592.stgit@rowlf.local> Message-ID: <20110316220833.6285.85523.stgit@rowlf.local> --- Makefile.am | 1 + bootstrap.sh | 7 ++++++- configure.ac | 3 ++- 3 files changed, 9 insertions(+), 2 deletions(-) -------------- next part -------------- diff --git a/Makefile.am b/Makefile.am index cb1a321..a056fce 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1,6 +1,7 @@ SUBDIRS = externals src scripts corepkgs doc misc tests EXTRA_DIST = substitute.mk nix.spec nix.spec.in bootstrap.sh \ nix.conf.example NEWS version +ACLOCAL_AMFLAGS = -I m4 pkginclude_HEADERS = config.h diff --git a/bootstrap.sh b/bootstrap.sh index 2547f5d..4fca88b 100755 --- a/bootstrap.sh +++ b/bootstrap.sh @@ -1,7 +1,12 @@ #! /bin/sh -e rm -f aclocal.m4 mkdir -p config -libtoolize --copy +if which glibtoolize >/dev/null +then + glibtoolize --copy +else + libtoolize --copy +fi aclocal autoheader automake --add-missing --copy diff --git a/configure.ac b/configure.ac index deb011d..11382ab 100644 --- a/configure.ac +++ b/configure.ac @@ -1,6 +1,7 @@ -AC_INIT(nix, m4_esyscmd([echo -n $(cat ./version)$VERSION_SUFFIX])) +AC_INIT(nix, m4_esyscmd([echo $(cat ./version)$VERSION_SUFFIX\\c])) AC_CONFIG_SRCDIR(README) AC_CONFIG_AUX_DIR(config) +AC_CONFIG_MACRO_DIR([m4]) AM_INIT_AUTOMAKE([dist-bzip2 foreign]) AC_DEFINE_UNQUOTED(NIX_VERSION, ["$VERSION"], [Nix version.]) From S.vanderBurg at tudelft.nl Wed Mar 16 23:14:27 2011 From: S.vanderBurg at tudelft.nl (Sander van der Burg - EWI) Date: Wed, 16 Mar 2011 23:14:27 +0100 Subject: [Nix-dev] /srv directory for storing site-specifc data served by the system Message-ID: <8A23E531C514ED43B1B469040352E7BA12956E@SRV503.tudelft.net> Hi all, I'm currently taking a look at the Filesystem Hierarchy Standard (http://www.pathname.com/fhs). Not that I want NixOS to adopt it completely (because we simply can't), but to have a look behind the rationale of some design decisions. Usually one of the big criticisms I receive about NixOS is that we don't comply with the FHS and I'd like to see what parts are useful for NixOS and which parts aren't (and to form an opinion why we choose to deviate and how we can achieve similar goals differently). One thing I noticed is that the FHS describes a /srv directory (on page 15, section 3.16), for storing site-specific data of services. The directory structure is unspecified but you can structure it like: /srv/www (for webserver files) /srv/ftp (for anonymous FTP files) /srv/subversion (containing subversion repositories) and you can also have even deeper hierarchies, e.g. /srv/www/domain-a /srv/www/domain-b When I was still doing Linux from Scratch I also used this directory, but in NixOS I put everything in /var or some other unknown location. I find it very convenient to use /srv. What do you think about the /srv directory? -- Sander -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110316/b9f2156e/attachment.html From viriketo at gmail.com Wed Mar 16 23:24:30 2011 From: viriketo at gmail.com (=?iso-8859-1?Q?Llu=EDs?= Batlle i Rossell) Date: Wed, 16 Mar 2011 23:24:30 +0100 Subject: [Nix-dev] /srv directory for storing site-specifc data served by the system In-Reply-To: <8A23E531C514ED43B1B469040352E7BA12956E@SRV503.tudelft.net> References: <8A23E531C514ED43B1B469040352E7BA12956E@SRV503.tudelft.net> Message-ID: <20110316222428.GS32257@vicerveza.homeunix.net> On Wed, Mar 16, 2011 at 11:14:27PM +0100, Sander van der Burg wrote: > Hi all, > When I was still doing Linux from Scratch I also used this directory, but in NixOS I put everything in /var or some other unknown location. I find it very convenient to use /srv. What do you think about the /srv directory? If it is about nixos expecting things at /srv (web content, svn repositories, ...), fine for me. If it is about nixos putting things there (as with etc), I don't like it that much. What do you have in mind of that? Regards, Llu?s From marco-oweber at gmx.de Wed Mar 16 23:28:19 2011 From: marco-oweber at gmx.de (Marc Weber) Date: Wed, 16 Mar 2011 22:28:19 +0000 Subject: [Nix-dev] /srv directory for storing site-specifc data served by the system In-Reply-To: <8A23E531C514ED43B1B469040352E7BA12956E@SRV503.tudelft.net> References: <8A23E531C514ED43B1B469040352E7BA12956E@SRV503.tudelft.net> Message-ID: <1300314362-sup-1637@nixos> Looks like this could be written down as Wiki article to remind everybody. I'm fine with changing paths. Looking forward to your summary. Marc Weber From olexiyb at gmail.com Thu Mar 17 01:49:40 2011 From: olexiyb at gmail.com (Olexiy Buyanskyy) Date: Wed, 16 Mar 2011 20:49:40 -0400 Subject: [Nix-dev] Re: nix trunk coredumps on AIX. Where is --enable-static-nix option? In-Reply-To: References: Message-ID: Hi, On Wed, Mar 16, 2011 at 5:33 PM, Olexiy Buyanskyy wrote: > Hi, > > I have issues to run the latest trunk version of nix-env on AIX. > I think this is related to missing support of --enable-static-nix option. > I see this was removed after merge of SQLite branch. > I am not 100% why this coredump happening, but I just know that > --enable-static-nix helped for me to get rid of those difficult to > explain coredumps. > I also took snapshot of sources before SQLLite branch merge and was > able to compile and pass all tests. I added back in configure LDFLAGS="-all-static $LDFLAGS" and all 31 tests passed. I think we need to return --enable-static-nix option. I suspect that this option was created for cygwin originally. -- Olexiy Buyanskyy From ludo at gnu.org Thu Mar 17 16:36:24 2011 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Thu, 17 Mar 2011 16:36:24 +0100 Subject: [Nix-dev] Re: nix-prefetch-git & TopGit References: <1300245409-sup-8118@nixos> <87oc5b6r9r.fsf@gnu.org> <1300301450-sup-8194@nixos> Message-ID: <87wrjxwyh3.fsf@gnu.org> Hi Marc, Marc Weber writes: > else > - echo "WARNING: would populate TopGit branches but TopGit is not available" >&2 > - echo "WARNING: install TopGit to fix the problem" >&2 > + # TODO: is this useful at all? Should for each remote branch a local branch be created? > + echo "If you had installed TopGit I would have populated local topic branches" >&2 > fi I find ?would populate TopGit branches? equivalent to ?I would have populated local topic branches?... Ludo?. From marco-oweber at gmx.de Fri Mar 18 00:44:08 2011 From: marco-oweber at gmx.de (Marc Weber) Date: Thu, 17 Mar 2011 23:44:08 +0000 Subject: [Nix-dev] Re: nix-prefetch-git & TopGit In-Reply-To: <87wrjxwyh3.fsf@gnu.org> References: <1300245409-sup-8118@nixos> <87oc5b6r9r.fsf@gnu.org> <1300301450-sup-8194@nixos> <87wrjxwyh3.fsf@gnu.org> Message-ID: <1300405359-sup-2433@nixos> You've missed the real question: Why do you want to populate top-git branches? If you want this should local branches be populate always? Marc Weber From ludo at gnu.org Fri Mar 18 11:20:25 2011 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Fri, 18 Mar 2011 11:20:25 +0100 Subject: [Nix-dev] Re: nix-prefetch-git & TopGit References: <1300245409-sup-8118@nixos> <87oc5b6r9r.fsf@gnu.org> <1300301450-sup-8194@nixos> <87wrjxwyh3.fsf@gnu.org> <1300405359-sup-2433@nixos> Message-ID: <874o70pw5y.fsf@gnu.org> Marc Weber writes: > You've missed the real question: > Why do you want to populate top-git branches? Please see <87wrk7apf8.fsf at gnu.org>. Ludo?. From marco-oweber at gmx.de Fri Mar 18 11:35:52 2011 From: marco-oweber at gmx.de (Marc Weber) Date: Fri, 18 Mar 2011 10:35:52 +0000 Subject: [Nix-dev] Re: nix-prefetch-git & TopGit In-Reply-To: <874o70pw5y.fsf@gnu.org> References: <1300245409-sup-8118@nixos> <87oc5b6r9r.fsf@gnu.org> <1300301450-sup-8194@nixos> <87wrjxwyh3.fsf@gnu.org> <1300405359-sup-2433@nixos> <874o70pw5y.fsf@gnu.org> Message-ID: <1300444500-sup-2609@nixos> Excerpts from ludo's message of Fri Mar 18 10:20:25 +0000 2011: > Please see <87wrk7apf8.fsf at gnu.org>. Please see ? I'm not smart enough to get this pointer. Marc Weber From ludo at gnu.org Fri Mar 18 12:52:28 2011 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Fri, 18 Mar 2011 12:52:28 +0100 Subject: [Nix-dev] Re: nix-prefetch-git & TopGit References: <1300245409-sup-8118@nixos> <87oc5b6r9r.fsf@gnu.org> <1300301450-sup-8194@nixos> <87wrjxwyh3.fsf@gnu.org> <1300405359-sup-2433@nixos> <874o70pw5y.fsf@gnu.org> <1300444500-sup-2609@nixos> Message-ID: <87mxksodc3.fsf@gnu.org> Marc Weber writes: > Excerpts from ludo's message of Fri Mar 18 10:20:25 +0000 2011: >> Please see <87wrk7apf8.fsf at gnu.org>. > Please see ? It?s a message ID. You can try instead. Thanks, Ludo?. From marco-oweber at gmx.de Fri Mar 18 13:50:33 2011 From: marco-oweber at gmx.de (Marc Weber) Date: Fri, 18 Mar 2011 12:50:33 +0000 Subject: [Nix-dev] Re: nix-prefetch-git & TopGit In-Reply-To: <87mxksodc3.fsf@gnu.org> References: <1300245409-sup-8118@nixos> <87oc5b6r9r.fsf@gnu.org> <1300301450-sup-8194@nixos> <87wrjxwyh3.fsf@gnu.org> <1300405359-sup-2433@nixos> <874o70pw5y.fsf@gnu.org> <1300444500-sup-2609@nixos> <87mxksodc3.fsf@gnu.org> Message-ID: <1300451696-sup-5383@nixos> Excerpts from ludo's message of Fri Mar 18 11:52:28 +0000 2011: > It\xe2\x80\x99s a message ID. You can try > instead. I don't know what you're doing here. And I'm not willing to spend many minutes on looking it up. You talked about tg patch. And you talked about git not fetching objects. The last statement is wrong. All the branches are there after running fetch but prefixed by remote/. If its the case that you don't understand either: git fetch remote or what remote vs local branches are you should look it up. tg patch probably won't work unless using tg remote --populate. In that case I was waiting for a simple explanation such as: "I'd like to make hydra publish a patch which is the result of exporting a topgit branch". which would not have taken much time but which would have made your purpose easy to understand. If that's a case I'm lacking knowledge about how hydra manages incremental updates. Then I should shut up. If you talk about "failures you haven't seen before" you could copy paste the important lines. Getting many mb raw logs of 7 builds takes too long here. I'm not interested anymore. So we should close this thread. Marc Weber From shea at shealevy.com Fri Mar 18 17:18:05 2011 From: shea at shealevy.com (Shea Levy) Date: Fri, 18 Mar 2011 12:18:05 -0400 Subject: [Nix-dev] fbcondecor-0.9.6-2.6.37 patch for nixpkgs In-Reply-To: <4D74970C.7050004@shealevy.com> References: <4D73A3C4.1070506@shealevy.com> <4D745BA0.1080608@shealevy.com> <4D74970C.7050004@shealevy.com> Message-ID: <4D8385BD.2000904@shealevy.com> On 3/7/11 3:27 AM, Shea Levy wrote: > The splash background works in the virtual machine running 2.6.37.1 > with the fbcondecor patch. > > On 3/6/11 11:14 PM, Shea Levy wrote: >> Quick follow-up on this: The resulting system works fine, but I'm not >> seeing a splash background for my terminals. This may be due to my >> system booting through UEFI, so I'm currently compiling on a VM using >> traditional BIOS booting to see if the splash backgrounds show up. >> >> Cheers, >> Shea Levy >> >> On 3/6/11 10:09 AM, Shea Levy wrote: >>> Hi all, >>> >>> I've updated my local copy of nixpkgs to use the now-available >>> fbcondecor patch when compiling Linux 2.6.37. I'm compiling now and >>> will report back later if there are any problems in the resulting >>> system. >>> >>> Cheers, >>> Shea Levy >>> >>> >>> _______________________________________________ >>> nix-dev mailing list >>> nix-dev at cs.uu.nl >>> https://mail.cs.uu.nl/mailman/listinfo/nix-dev >> >> >> _______________________________________________ >> nix-dev mailing list >> nix-dev at cs.uu.nl >> https://mail.cs.uu.nl/mailman/listinfo/nix-dev > Resubmitting the patch. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110318/74941cc1/attachment.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fbcondecor-2.6.37.patch Url: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110318/74941cc1/attachment.pl From shea at shealevy.com Fri Mar 18 18:43:55 2011 From: shea at shealevy.com (Shea Levy) Date: Fri, 18 Mar 2011 13:43:55 -0400 Subject: [Nix-dev] Get depmod to Work Message-ID: <4D8399DB.7000104@shealevy.com> Currently, running `depmod` on a standard Nixos system will fail with: Could not open /nix/store/...-kernel-modules/lib/modules2.6.XX.XX/modules.dep.temp for writing: No such file or directory. That is, depmod is not putting a required directory separator between modules and 2.6.XX.XX. This results because bashrc.sh creates an /etc/bashrc that sets $MODULE_DIR to /nix/store/...-kernel-modules/lib/modules and module-dir.patch for module-init-tools simply concatenates $MODULE_DIR with the kernel version to get the directory name. This could be fixed by fixing bashrc.sh or by fixing module-dir.patch; I don't have time to go into the C right now but I've attached a patch that fixes bashrc.sh. Cheers, Shea Levy -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fix-depmod.patch Url: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110318/cc3664df/attachment.pl From e.dolstra at tudelft.nl Fri Mar 18 19:13:14 2011 From: e.dolstra at tudelft.nl (Eelco Dolstra) Date: Fri, 18 Mar 2011 19:13:14 +0100 Subject: [Nix-dev] Get depmod to Work In-Reply-To: <4D8399DB.7000104@shealevy.com> References: <4D8399DB.7000104@shealevy.com> Message-ID: <4D83A0BA.2040805@tudelft.nl> Hi, On 03/18/2011 06:43 PM, Shea Levy wrote: > Currently, running `depmod` on a standard Nixos system will fail with: > > Could not open > /nix/store/...-kernel-modules/lib/modules2.6.XX.XX/modules.dep.temp for > writing: No such file or directory. You're not supposed to run "depmod" outside of the builder of kernel-modules because it's impure (it ends up overwriting the depmod files generated by the builder). Note that kernel-modules' builder does put a / at the end of $MODULE_DIR: https://svn.nixos.org/repos/nix/nixpkgs/trunk/pkgs/os-specific/linux/module-init-tools/aggregator.nix If you want to add additional modules to the kernel configuration, you should add them to the boot.extraModulePackages option and run "nixos-rebuild switch". -- Eelco Dolstra | http://www.st.ewi.tudelft.nl/~dolstra/ From shea at shealevy.com Fri Mar 18 19:18:12 2011 From: shea at shealevy.com (Shea Levy) Date: Fri, 18 Mar 2011 14:18:12 -0400 Subject: [Nix-dev] Get depmod to Work In-Reply-To: <4D83A0BA.2040805@tudelft.nl> References: <4D8399DB.7000104@shealevy.com> <4D83A0BA.2040805@tudelft.nl> Message-ID: <4D83A1E4.9020506@shealevy.com> On 3/18/11 2:13 PM, Eelco Dolstra wrote: > Hi, > > On 03/18/2011 06:43 PM, Shea Levy wrote: > >> Currently, running `depmod` on a standard Nixos system will fail with: >> >> Could not open >> /nix/store/...-kernel-modules/lib/modules2.6.XX.XX/modules.dep.temp for >> writing: No such file or directory. > > You're not supposed to run "depmod" outside of the builder of > kernel-modules because it's impure (it ends up overwriting the depmod > files generated by the builder). > > Note that kernel-modules' builder does put a / at the end of $MODULE_DIR: > > > https://svn.nixos.org/repos/nix/nixpkgs/trunk/pkgs/os-specific/linux/module-init-tools/aggregator.nix > > > If you want to add additional modules to the kernel configuration, you > should add them to the boot.extraModulePackages option and run > "nixos-rebuild switch". > Perhaps it's wrong to run it outside of the builder, but shouldn't it still work, or at least fail with a more graceful error message? From shea at shealevy.com Sat Mar 19 17:00:19 2011 From: shea at shealevy.com (Shea Levy) Date: Sat, 19 Mar 2011 12:00:19 -0400 Subject: [Nix-dev] AUFS 2.1 for 2.6.37 Message-ID: <4D84D313.3050403@shealevy.com> Hi all, Attached is a nixpkgs patch (aufs2.1-2.6.37.patch) to add aufs2.1 and aufs2.1-utils to Linux 2.6.37 and a nixos patch (aufs2.1-nixos-test.patch) I used to test it. Some notes: * My motivation for this patch is that kernels < 2.6.36 contain an e1000e that does not support the ethernet card that is part of the chipset for the second-generation Core-i Intel CPUs, so in order to have a more useful livecd I needed to get aufs working with a newer kernel, and 2.6.37 is the latest kernel with an official aufs release. * All sources are downloaded with fetchgit. This is because the aufs upstream doesn't provide release tarballs, they just add a tag to their git tree for an official release. * The make target for the aufs2.1 headers uses a Makefile in the kernel build directory that requires that unifdef be in the scripts/ subdirectory of the build directory. The way I've dealt with this here is by adding "make $makeFlags -C scripts unifdef" to the postBuild in the kernel builder. Since the builder is used by all kernel versions, this will require rebuilding every kernel and kernel-dependent package if the patch is accepted, so one alternative I thought of would be to create a fake kernel build directory where everything is symlinked to the real build directory except scripts/, which is first copied and then make unifdef is run before building aufs2.1. If that more complicated solution is preferred, or if anyone has ideas for another one, I can do that and submit a new patch. * The nixpkgs patch contains my previously-submitted fbcondecor patch, for two reasons: 1. I wanted to create a livecd that is as close as possible to current livecds except it uses 2.6.37, so I wanted ttyBackgrounds enabled which requires fbcondecor 2. A patch that contains just the aufs2.1 changes and not the fbcondecor patch would cause a conflict in the linux_2_6_37 definition in all-packages.nix. In particular, if such a patch were applied first and then the fbcondecor patch were applied, then patch will see fuzz and erroneously update linux_2_6_38 to use fbcondecor. I have not tested what would happen if the fbcondecor patch were applied first, but I suspect a similar problem would occur (linux_2_6_38 would be erroneously updated to use aufs2.1). As a result, if this patch is accepted the previous fbcondecor patch should NOT be applied. If the previous fbcondecor patch is applied before this is accepted, I will upload a new patch that doesn't have these issues. If a patch that includes aufs2.1 but has nothing fbcondecor related is desired, let me know and I'll submit it. * The patch was tested by building a livecd ISO that uses it, then running the ISO from within virtualbox and installing aufs2.1-util from within the livecd environment. * The livecd was built using installation-cd-minimal.nix, with two changes to the Nixos tree: 1. boot.kernelPackages = pkgs.linuxPackages_2_6_37 was added to profiles/minimal.nix 2. config.boot.kernelPackages.aufs2 was changed to config.boot.kernelPackages.aufs2_1 in iso-image.nix I would have preferred to keep all changes within profiles/minimal.nix, but I couldn't figure out how to override iso-image.nix's definition of boot.extraModulePackages. Livecds that use an older kernel can't be built with this iso-image.nix, since we don't have aufs2.1 for them (just aufs2). If someone can point me to how I can override things set in iso-image.nix, I'd appreciate it. Cheers, Shea Levy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110319/07b622b1/attachment.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: aufs2.1-2.6.37.patch Url: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110319/07b622b1/attachment.pl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: aufs2.1-nixos-test.patch Url: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110319/07b622b1/attachment-0001.pl From shea at shealevy.com Sat Mar 19 21:51:23 2011 From: shea at shealevy.com (Shea Levy) Date: Sat, 19 Mar 2011 16:51:23 -0400 Subject: [Nix-dev] AUFS 2.1 for 2.6.37 In-Reply-To: <4D84D313.3050403@shealevy.com> References: <4D84D313.3050403@shealevy.com> Message-ID: <4D85174B.2090704@shealevy.com> On 3/19/11 12:00 PM, Shea Levy wrote: > Hi all, > > Attached is a nixpkgs patch (aufs2.1-2.6.37.patch) to add aufs2.1 and > aufs2.1-utils to Linux 2.6.37 and a nixos patch > (aufs2.1-nixos-test.patch) I used to test it. Some notes: > > * My motivation for this patch is that kernels < 2.6.36 contain an > e1000e that does not support the ethernet card that is part of > the chipset for the second-generation Core-i Intel CPUs, so in > order to have a more useful livecd I needed to get aufs working > with a newer kernel, and 2.6.37 is the latest kernel with an > official aufs release. > * All sources are downloaded with fetchgit. This is because the > aufs upstream doesn't provide release tarballs, they just add a > tag to their git tree for an official release. > * The make target for the aufs2.1 headers uses a Makefile in the > kernel build directory that requires that unifdef be in the > scripts/ subdirectory of the build directory. The way I've dealt > with this here is by adding "make $makeFlags -C scripts unifdef" > to the postBuild in the kernel builder. Since the builder is > used by all kernel versions, this will require rebuilding every > kernel and kernel-dependent package if the patch is accepted, so > one alternative I thought of would be to create a fake kernel > build directory where everything is symlinked to the real build > directory except scripts/, which is first copied and then make > unifdef is run before building aufs2.1. If that more complicated > solution is preferred, or if anyone has ideas for another one, I > can do that and submit a new patch. > * The nixpkgs patch contains my previously-submitted fbcondecor > patch, for two reasons: > 1. I wanted to create a livecd that is as close as possible > to current livecds except it uses 2.6.37, so I wanted > ttyBackgrounds enabled which requires fbcondecor > 2. A patch that contains just the aufs2.1 changes and not the > fbcondecor patch would cause a conflict in the > linux_2_6_37 definition in all-packages.nix. In > particular, if such a patch were applied first and then > the fbcondecor patch were applied, then patch will see > fuzz and erroneously update linux_2_6_38 to use > fbcondecor. I have not tested what would happen if the > fbcondecor patch were applied first, but I suspect a > similar problem would occur (linux_2_6_38 would be > erroneously updated to use aufs2.1). > As a result, if this patch is accepted the previous fbcondecor > patch should NOT be applied. If the previous fbcondecor patch is > applied before this is accepted, I will upload a new patch that > doesn't have these issues. If a patch that includes aufs2.1 but > has nothing fbcondecor related is desired, let me know and I'll > submit it. > * The patch was tested by building a livecd ISO that uses it, then > running the ISO from within virtualbox and installing > aufs2.1-util from within the livecd environment. > * The livecd was built using installation-cd-minimal.nix, with two > changes to the Nixos tree: > 1. boot.kernelPackages = pkgs.linuxPackages_2_6_37 was added > to profiles/minimal.nix > 2. config.boot.kernelPackages.aufs2 was changed to > config.boot.kernelPackages.aufs2_1 in iso-image.nix > I would have preferred to keep all changes within > profiles/minimal.nix, but I couldn't figure out how to override > iso-image.nix's definition of boot.extraModulePackages. Livecds > that use an older kernel can't be built with this iso-image.nix, > since we don't have aufs2.1 for them (just aufs2). If someone > can point me to how I can override things set in iso-image.nix, > I'd appreciate it. > > Cheers, > Shea Levy > > > _______________________________________________ > nix-dev mailing list > nix-dev at cs.uu.nl > https://mail.cs.uu.nl/mailman/listinfo/nix-dev I see fbcondecor has been committed, so here's an updated aufs2.1 patch with no conflicts. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110319/99994704/attachment.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: aufs2.1-2.6.37.patch Url: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110319/99994704/attachment.pl From shea at shealevy.com Tue Mar 22 00:03:28 2011 From: shea at shealevy.com (Shea Levy) Date: Mon, 21 Mar 2011 19:03:28 -0400 Subject: [Nix-dev] Re: efibootmgr: A Linux user-space application to modify the Intel Extensible Firmware Interface (EFI) Boot Manager In-Reply-To: <4D745A37.7020205@shealevy.com> References: <4D745A37.7020205@shealevy.com> Message-ID: <4D87D940.500@shealevy.com> On 3/6/11 11:08 PM, Shea Levy wrote: > Hi all, > > I've written a nix expression for efibootmgr, a tool which allows you > to modify some of the nvram variables used by EFI and UEFI systems to > manage the boot process. efibootmgr should compile on non-{U,}EFI > systems, but since the tool relies on the information exported by the > efivars kernel module, which in turn requires that the kernel be > booted in {U,}EFI mode, it's useless unless you have a {U,}EFI system. > > Cheers, > Shea Levy Resubmitting a slightly cleaner patch for this. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: efibootmgr.patch Url: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110321/59a7c6be/attachment.pl From viriketo at gmail.com Tue Mar 22 09:35:25 2011 From: viriketo at gmail.com (=?iso-8859-1?Q?Llu=EDs?= Batlle i Rossell) Date: Tue, 22 Mar 2011 09:35:25 +0100 Subject: [Nix-dev] Re: efibootmgr: A Linux user-space application to modify the Intel Extensible Firmware Interface (EFI) Boot Manager In-Reply-To: <4D87D940.500@shealevy.com> References: <4D745A37.7020205@shealevy.com> <4D87D940.500@shealevy.com> Message-ID: <20110322083521.GT25277@vicerveza.homeunix.net> On Mon, Mar 21, 2011 at 07:03:28PM -0400, Shea Levy wrote: > On 3/6/11 11:08 PM, Shea Levy wrote: > >Hi all, > > > >I've written a nix expression for efibootmgr, a tool which allows > >you to modify some of the nvram variables used by EFI and UEFI > >systems to manage the boot process. efibootmgr should compile on > >non-{U,}EFI systems, but since the tool relies on the information > >exported by the efivars kernel module, which in turn requires that > >the kernel be booted in {U,}EFI mode, it's useless unless you have > >a {U,}EFI system. Committed! From maggesi at math.unifi.it Tue Mar 22 12:17:46 2011 From: maggesi at math.unifi.it (Marco Maggesi) Date: Tue, 22 Mar 2011 12:17:46 +0100 Subject: [Nix-dev] The latest development release of Nix Message-ID: <18300501-6272-474B-8E0F-0003E661AD21@math.unifi.it> Hi, the link to "The latest development release of Nix" (http://hydra.nixos.org/view/nix/trunk/latest ) found in the download page of Nix (http://nixos.org/nix/download.html) seems to be broken. Also I have a question about this. Should these sources be the same as the svn trunk? (Or perhaps the latest version of the trunk that compiles?) M. From maggesi at math.unifi.it Tue Mar 22 12:28:37 2011 From: maggesi at math.unifi.it (Marco Maggesi) Date: Tue, 22 Mar 2011 12:28:37 +0100 Subject: [Nix-dev] Nagios Message-ID: Hi, I have some NixOS machines that I would like to monitor with Nagios. Does anybody have a simple Nagios client configuration for NixOS that I can use as a starting point? What exactly the configuration services.nagios.enable = true provides? A Nagios monitoring server or client? (I'm new to Nagios, so perhaps I don't fully understand its behavior.) Thanks, M. From e.dolstra at tudelft.nl Tue Mar 22 13:31:15 2011 From: e.dolstra at tudelft.nl (Eelco Dolstra) Date: Tue, 22 Mar 2011 13:31:15 +0100 Subject: [Nix-dev] The latest development release of Nix In-Reply-To: <18300501-6272-474B-8E0F-0003E661AD21@math.unifi.it> References: <18300501-6272-474B-8E0F-0003E661AD21@math.unifi.it> Message-ID: <4D889693.2040005@tudelft.nl> Hi, On 03/22/2011 12:17 PM, Marco Maggesi wrote: > the link to "The latest development release of Nix" > (http://hydra.nixos.org/view/nix/trunk/latest) > found in the download page of Nix (http://nixos.org/nix/download.html) seems to > be broken. Yes, it seems that the "view" feature in Hydra (which is supposed to link through to the latest successful version) is extremely slow. We'll look into it. Here is a faster link: http://hydra.nixos.org/jobset/nix/trunk/jobstatus > Also I have a question about this. Should these sources be the same as the svn > trunk? Yes. -- Eelco Dolstra | http://www.st.ewi.tudelft.nl/~dolstra/ From e.dolstra at tudelft.nl Tue Mar 22 13:36:00 2011 From: e.dolstra at tudelft.nl (Eelco Dolstra) Date: Tue, 22 Mar 2011 13:36:00 +0100 Subject: [Nix-dev] Nagios In-Reply-To: References: Message-ID: <4D8897B0.1060203@tudelft.nl> Hi, On 03/22/2011 12:28 PM, Marco Maggesi wrote: > I have some NixOS machines that I would like to monitor with Nagios. > Does anybody have a simple Nagios client configuration for NixOS that I can use > as a starting point? I used it briefly, a long time ago, which is presumably when I added the NixOS module. But I've since switched to Zabbix, which does a lot more with a lot less configuration effort. (The Zabbix instance for the Hydra buildfarm is public: http://buildfarm.st.ewi.tudelft.nl/zabbix/screens.php) > What exactly the configuration > > services.nagios.enable = true > > provides? A Nagios monitoring server or client? That would be the Nagios "server". You then need to write checks to actually monitor other machines. -- Eelco Dolstra | http://www.st.ewi.tudelft.nl/~dolstra/ From rickard.nilsson at telia.com Tue Mar 22 16:50:18 2011 From: rickard.nilsson at telia.com (Rickard Nilsson) Date: Tue, 22 Mar 2011 16:50:18 +0100 Subject: [Nix-dev] NixOS with NFS-root Message-ID: <6d8eace62894dffb58fba5fa2d6cb6a5@mail.webofnilsson.com> Hi, Is anyone running NixOS with the root partition on NFS, booting from PXE? I want to replicate my current diskless Linux-setup in NixOS, is it possible? I am prepared to work to make it happen, but I'd appreciate any pointers I can get. I should say that I haven't yet set up any NixOS installation, I'm just investigating the possibilities. Best regards, Rickard Nilsson From e.dolstra at tudelft.nl Tue Mar 22 17:16:55 2011 From: e.dolstra at tudelft.nl (Eelco Dolstra) Date: Tue, 22 Mar 2011 17:16:55 +0100 Subject: [Nix-dev] NixOS with NFS-root In-Reply-To: <6d8eace62894dffb58fba5fa2d6cb6a5@mail.webofnilsson.com> References: <6d8eace62894dffb58fba5fa2d6cb6a5@mail.webofnilsson.com> Message-ID: <4D88CB77.5080503@tudelft.nl> Hi, On 03/22/2011 04:50 PM, Rickard Nilsson wrote: > Is anyone running NixOS with the root partition on NFS, booting from PXE? Not as far as I know. > I want > to replicate my current diskless Linux-setup in NixOS, is it possible? I am > prepared to work to make it happen, but I'd appreciate any pointers I can get. The main issue is to add networking and NFS support to the initrd. This requires adding the necessary kernel modules to the initrd (boot.initrd.availableKernelModules) and adding some code to initialise networking. We already do this in this module: https://svn.nixos.org/repos/nix/nixos/trunk/modules/virtualisation/qemu-vm.nix (in boot.initrd.postDeviceCommands) to set up networking to boot from a CIFS share. Then setting fileSystems to something like [ { mountPoint = "/"; device = "server:/foo"; fsType = "nfs"; } ] should suffice to do the actual mounting. Maybe portmap is needed in the initrd as well. -- Eelco Dolstra | http://www.st.ewi.tudelft.nl/~dolstra/ From viriketo at gmail.com Tue Mar 22 19:51:50 2011 From: viriketo at gmail.com (=?iso-8859-1?Q?Llu=EDs?= Batlle i Rossell) Date: Tue, 22 Mar 2011 19:51:50 +0100 Subject: [Nix-dev] NixOS with NFS-root In-Reply-To: <6d8eace62894dffb58fba5fa2d6cb6a5@mail.webofnilsson.com> References: <6d8eace62894dffb58fba5fa2d6cb6a5@mail.webofnilsson.com> Message-ID: <20110322185121.GU25277@vicerveza.homeunix.net> On Tue, Mar 22, 2011 at 04:50:18PM +0100, Rickard Nilsson wrote: > Hi, > > Is anyone running NixOS with the root partition on NFS, booting from > PXE? I want to replicate my current diskless Linux-setup in NixOS, > is it possible? I am prepared to work to make it happen, but I'd > appreciate any pointers I can get. I've been using it, but not using PXE. I booted fullong2f and sheevaplug systems that way. That was quite a manual configuration though. I took the kernel I wanted, and I'm not sure if I used any initrd or not. I think I had a kernel with all I needed in it (nfs root support included) With the generationsDir 'bootloader' module, and the proper configuration on the server, you should be able to set up that. In fact, there are some images in hydra ('systemTarball') that should boot fine through NFS root, as that is what I wrote them for. Regards, Llu?s. From ludo at gnu.org Wed Mar 23 09:56:18 2011 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Wed, 23 Mar 2011 09:56:18 +0100 Subject: [Nix-dev] `hydra_eval_job' shouldn't require optional arguments Message-ID: <87tyeurz9p.fsf@gnu.org> Hi, [I tried to report it through YellowGrass but the Captcha stuff keeps telling me "text entered did not match text in image".] Consider this: { optional ? null }: { bar = "yes"; } and: $ hydra_eval_jobs $PWD/t.nix warning: `--gc-roots-dir' not specified I would expect `hydra_eval_jobs' to use the default value of `optional' instead of returning an error. Thanks, Ludo'. From shea at shealevy.com Wed Mar 23 18:36:10 2011 From: shea at shealevy.com (Shea Levy) Date: Wed, 23 Mar 2011 13:36:10 -0400 Subject: [Nix-dev] SVN Commit Access Message-ID: <4D8A2F8A.9050106@shealevy.com> Hi all, Is there any process for gaining commit rights to the Nix repos? I expect to be hacking on the project (especially nixpkgs ) fairly regularly and would like to eventually reach the point where I can submit my changes directly rather than sending in a patch. Cheers, Shea Levy From nix-dev at beauregardfam.org Thu Mar 24 04:34:51 2011 From: nix-dev at beauregardfam.org (Daniel J Beauregard) Date: Wed, 23 Mar 2011 21:34:51 -0600 Subject: [Nix-dev] noob q: Best practice for test packages Message-ID: <20110324033451.GD5571@philemon.homenet.beau> Hi, I am a noob to NixOS and have had some plesant experiences so far. I am looking forward to creeating my first package. In the Nixpkgs manual, it says to add a call to the new package in pkgs/top-level/all-packages.nix. That sounds a bit intrusive - I don't want to mess around with /etc/nixos/nixpkgs on my system because it is updated by the nix-channel uitility and such. I have been looking for a way to incorporate my own test packages from a separate directory and add it to ~/.nix-defexpr, but I don't know how to pass stdenv as an input without incorporating into the main all-packages.nix. Is my goal achievable? Am I missing something? Many Thanks, Daniel From urkud+nix at ya.ru Thu Mar 24 06:34:04 2011 From: urkud+nix at ya.ru (Yury G. Kudryashov) Date: Thu, 24 Mar 2011 08:34:04 +0300 Subject: [Nix-dev] Re: noob q: Best practice for test packages References: <20110324033451.GD5571@philemon.homenet.beau> Message-ID: Daniel J Beauregard wrote: > Hi, > > I am a noob to NixOS and have had some plesant experiences so far. I am > looking forward to creeating my first package. In the Nixpkgs manual, it > says to add a call to the new package in pkgs/top-level/all-packages.nix. > That sounds a bit intrusive - I don't want to mess around with > /etc/nixos/nixpkgs on my system because it is updated by the nix-channel > uitility and such. > > I have been looking for a way to incorporate my own test packages from a > separate directory and add it to ~/.nix-defexpr, but I don't know how to > pass stdenv as an input without incorporating into the main > all-packages.nix. Is my goal achievable? Am I missing something? Look at /etc/nixos/nixpkgs/maintainers/scripts/nix-call-package by Michael Raskin. Typical usage nix-call-package ./default.nix. There are some optional arguments (look at the source). From vcunat at gmail.com Thu Mar 24 12:34:51 2011 From: vcunat at gmail.com (=?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?=) Date: Thu, 24 Mar 2011 12:34:51 +0100 Subject: [Nix-dev] Various patches Message-ID: Hi everyone, I'm sending some patches to nixpkgs that I'm using. They're also available as branches on http://mawercer.de:7000/?p=nixpkgs;a=shortlog;h=refs/heads/vlada/mercurial (for example). Please, review them and eventually apply/merge into (svn) trunk. The patches include descriptions; if a different format is needed, tell me (these is what "tg patch" gives). I'm sorry I've got to use an unofficial mirror but svn just doesn't support any way of maintaining a set of patches on top of the trunk (AFAIK). People with svn commit access don't need this so they probably don't realize it fully. Another problem is that I've seen patches in this mailing-list that *never get any sort of reply*. If everyone had some kind of personal branch directory (like the referred vlada/*), it would also be easier to merge or modify more complex patches and they couldn't get lost. For example, with topgit everyone could easily use any combination of other's patches even before they're finished/approved and merged into the trunk (topgit also handles interdependent topics). Vlada -------------- next part -------------- A non-text attachment was scrubbed... Name: pthread-man-pages.patch Type: application/octet-stream Size: 1070 bytes Desc: not available Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110324/1e086670/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: man-pages-posix.patch Type: application/octet-stream Size: 1675 bytes Desc: not available Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110324/1e086670/attachment-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: mercurial.patch Type: application/octet-stream Size: 1423 bytes Desc: not available Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110324/1e086670/attachment-0002.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: grip.patch Type: application/octet-stream Size: 1218 bytes Desc: not available Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110324/1e086670/attachment-0003.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: vim.patch Type: application/octet-stream Size: 2744 bytes Desc: not available Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110324/1e086670/attachment-0004.obj From e.dolstra at tudelft.nl Thu Mar 24 12:50:46 2011 From: e.dolstra at tudelft.nl (Eelco Dolstra) Date: Thu, 24 Mar 2011 12:50:46 +0100 Subject: [Nix-dev] Re: [Nix-commits] SVN commit: nix - r26489 - nixpkgs/trunk/pkgs/top-level In-Reply-To: <20110324114903.3CDFDCC147@mx4.tudelft.nl> References: <20110324114903.3CDFDCC147@mx4.tudelft.nl> Message-ID: <4D8B3016.3090309@tudelft.nl> Hi, On 03/24/2011 12:49 PM, Peter Simons wrote: > Author: simons > Date: Thu Mar 24 11:49:02 2011 > New Revision: 26489 > URL: https://svn.nixos.org/websvn/nix/?rev=26489&sc=1 > > Log: > man-pages-posix: renamed attribute for consistency with other man page sets Actually, I changed the name to posix_man_pages to be consistent with the coding conventions. So the other attributes should be changed :-) -- Eelco Dolstra | http://www.st.ewi.tudelft.nl/~dolstra/ From e.dolstra at tudelft.nl Thu Mar 24 12:53:20 2011 From: e.dolstra at tudelft.nl (Eelco Dolstra) Date: Thu, 24 Mar 2011 12:53:20 +0100 Subject: [Nix-dev] Various patches In-Reply-To: References: Message-ID: <4D8B30B0.3090409@tudelft.nl> Hi, On 03/24/2011 12:34 PM, Vladim?r ?un?t wrote: > I'm sending some patches to nixpkgs that I'm using. They're also > available as branches on > http://mawercer.de:7000/?p=nixpkgs;a=shortlog;h=refs/heads/vlada/mercurial > (for example). > > Please, review them and eventually apply/merge into (svn) trunk. The > patches include descriptions; if a different format is needed, tell me > (these is what "tg patch" gives). Thanks. I've applied the mercurial and manpage patches. -- Eelco Dolstra | http://www.st.ewi.tudelft.nl/~dolstra/ From marco-oweber at gmx.de Thu Mar 24 13:04:58 2011 From: marco-oweber at gmx.de (Marc Weber) Date: Thu, 24 Mar 2011 13:04:58 +0100 Subject: [Nix-dev] Various patches In-Reply-To: References: Message-ID: <1300968069-sup-9538@nixos> About Vim: Also consider contributing to http://github.com/MarcWeber/vim-addon-nix About mercurial: My marc-next branch contains full mercurial support including most extensions. Eg my config.nix file: mercurial = { atticSupport = true; guiSupport = true; pbranchSupport = true; hgsubversionSupport = true; mqSupport = true; histeditSupport = true; hgextconvertSupport = true; collapseSupport = true; record = true; }; Marc Weber From shea at shealevy.com Fri Mar 25 03:17:33 2011 From: shea at shealevy.com (Shea Levy) Date: Thu, 24 Mar 2011 22:17:33 -0400 Subject: [Nix-dev] Typo in Nixpkgs Manual Section Section 3.4.4 In-Reply-To: <4D75AFDB.4050604@shealevy.com> References: <4D75AFDB.4050604@shealevy.com> Message-ID: <4D8BFB3D.2040808@shealevy.com> Resubmitting this patch. On 03/07/2011 11:26 PM, Shea Levy wrote: > Hi all, > > This patch fixes a typo in section 3.4.4 of the Nixpkgs manual. The > section is about the configure phase, but it currently reads "The > default unpackPhase runs...". > > Cheers, > Shea Levy > || > > > _______________________________________________ > nix-dev mailing list > nix-dev at cs.uu.nl > https://mail.cs.uu.nl/mailman/listinfo/nix-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110324/d971f44d/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: fix-manual-3.4.4.patch Type: text/x-patch Size: 494 bytes Desc: not available Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110324/d971f44d/attachment.bin From roconnor at theorem.ca Fri Mar 25 03:15:28 2011 From: roconnor at theorem.ca (roconnor at theorem.ca) Date: Thu, 24 Mar 2011 22:15:28 -0400 (EDT) Subject: [Nix-dev] Boost and Locale issues Message-ID: I've almost completed a package for bitcoin, but I'm having a locale issue $ result/bin/bitcoin terminate called after throwing an instance of 'std::runtime_error' what(): locale::facet::_S_create_c_locale name not valid Aborted However the programs run correctly in an environment where LANG=C or LC_ALL=C. I *think* this is a boost related issue. I can probably work around this by wrapping the executable to set the environment beforehand, but I'd rather fix the actual problem rather than hiding it. This might mean patching boost? Anyhow, I know next to nothing about locale issues and absolutely nothing about how locale issues interact with NixOS. Any tips? viric claims that freecad has the same problem. -- Russell O'Connor ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.'' From shea at shealevy.com Fri Mar 25 03:26:44 2011 From: shea at shealevy.com (Shea Levy) Date: Thu, 24 Mar 2011 22:26:44 -0400 Subject: [Nix-dev] Typo in NixOS Manual Section 1.2.7 Message-ID: <4D8BFD64.4060708@shealevy.com> Hi all, NixOS manual section 1.2.7 currently says "The text editors *nano* and *vim* are available" in the livecd environment, but vim isn't available, vi is. This patch fixes this. Cheers, Shea Levy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110324/9ef3134d/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: nixos-install-doc-1.2.7.patch Type: text/x-patch Size: 658 bytes Desc: not available Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110324/9ef3134d/attachment.bin From urkud+nix at ya.ru Fri Mar 25 07:35:37 2011 From: urkud+nix at ya.ru (Yury G. Kudryashov) Date: Fri, 25 Mar 2011 09:35:37 +0300 Subject: [Nix-dev] Re: Boost and Locale issues References: Message-ID: roconnor at theorem.ca wrote: > I've almost completed a package for bitcoin, but I'm having a locale issue > > $ result/bin/bitcoin > terminate called after throwing an instance of 'std::runtime_error' > what(): locale::facet::_S_create_c_locale name not valid > Aborted > > However the programs run correctly in an environment where LANG=C or > LC_ALL=C. > > I *think* this is a boost related issue. No, locale::facet is general C++, not boost-specific. AFAIR, last time I had such problem switching to stdenv-updates helped but I'm not sure. From kaposi.ambrus at gmail.com Fri Mar 25 08:30:50 2011 From: kaposi.ambrus at gmail.com (Ambrus Kaposi) Date: Fri, 25 Mar 2011 08:30:50 +0100 Subject: [Nix-dev] Re: Boost and Locale issues In-Reply-To: References: Message-ID: > No, locale::facet is general C++, not boost-specific. AFAIR, last time I had > such problem switching to stdenv-updates helped but I'm not sure. I have the same problem with encfs wich also uses boost. stdenv-updates didn't help: /etc/nixos/nixpkgs/pkgs/tools/filesystems/encfs/default.nix $ encfs terminate called after throwing an instance of 'std::runtime_error' what(): locale::facet::_S_create_c_locale name not valid Aborted From rob.vermaas at gmail.com Fri Mar 25 08:40:57 2011 From: rob.vermaas at gmail.com (Rob Vermaas) Date: Fri, 25 Mar 2011 08:40:57 +0100 Subject: [Nix-dev] Re: Boost and Locale issues In-Reply-To: References: Message-ID: Sounds like a known bug in boost: https://svn.boost.org/trac/boost/ticket/4688 On Fri, Mar 25, 2011 at 08:30, Ambrus Kaposi wrote: > > No, locale::facet is general C++, not boost-specific. AFAIR, last time I > had > > such problem switching to stdenv-updates helped but I'm not sure. > > I have the same problem with encfs wich also uses boost. > stdenv-updates didn't help: > > /etc/nixos/nixpkgs/pkgs/tools/filesystems/encfs/default.nix > > $ encfs > terminate called after throwing an instance of 'std::runtime_error' > what(): locale::facet::_S_create_c_locale name not valid > Aborted > _______________________________________________ > nix-dev mailing list > nix-dev at cs.uu.nl > https://mail.cs.uu.nl/mailman/listinfo/nix-dev > -- Rob Vermaas [email] rob.vermaas at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110325/cf9015c7/attachment.html From viriketo at gmail.com Fri Mar 25 10:31:15 2011 From: viriketo at gmail.com (=?iso-8859-1?Q?Llu=EDs?= Batlle i Rossell) Date: Fri, 25 Mar 2011 10:31:15 +0100 Subject: [Nix-dev] Boost and Locale issues In-Reply-To: References: Message-ID: <20110325093112.GG25277@vicerveza.homeunix.net> On Thu, Mar 24, 2011 at 10:15:28PM -0400, roconnor at theorem.ca wrote: > I've almost completed a package for bitcoin, but I'm having a locale issue > > $ result/bin/bitcoin > terminate called after throwing an instance of 'std::runtime_error' > what(): locale::facet::_S_create_c_locale name not valid > Aborted > > However the programs run correctly in an environment where LANG=C or > LC_ALL=C. > > I *think* this is a boost related issue. > > I can probably work around this by wrapping the executable to set > the environment beforehand, but I'd rather fix the actual problem > rather than hiding it. This might mean patching boost? > > Anyhow, I know next to nothing about locale issues and absolutely > nothing about how locale issues interact with NixOS. Any tips? The glibc offers two kind of filesystem places for locale information. Raw locale files (text files, difficult to process, with somehow higher load time) and the locale archive (some kind of binary compiled archive, different for each glibc and even architecture, I imagine). In NixOS we only have the 2nd kind of file. Both kinds of locale storage should be totally transparent through the glibc API, but maybe Boost wants to do something 'beyond' the glibc API, and thus fails. Or maybe our patches for the archive to work do not cover completely the glibc locale API, and we see a sympthom of this only through boost. So, we have the issue open; I've even not done an 'strace -e open'; if someone can bring some light on this (maybe through mentioning simple programs using the boost locale API), it would be great. > viric claims that freecad has the same problem. Right. I start it with LANG=C. Regards, Llu?s. From rickard.nilsson at telia.com Fri Mar 25 13:23:32 2011 From: rickard.nilsson at telia.com (Rickard Nilsson) Date: Fri, 25 Mar 2011 13:23:32 +0100 Subject: [Nix-dev] nuke-refs Message-ID: <1a91c997343f7e298b599a40a687f368@mail.webofnilsson.com> Hi, I'm trying to build the nixos ISO with: nix-build nixos/release.nix -A iso_minimal I've got a recent nix trunk build installed, and I've added prebuilt binaries with nix-pull. However, I get the following error: /nix/store/rk9jl8rzqr7ynmaaz0qdy8j9r5hkb56f-stdenv-linux/setup: line 864: nuke-refs: command not found What is nuke-refs, and why is it not found? Regards, Rickard Nilsson From e.dolstra at tudelft.nl Fri Mar 25 13:32:43 2011 From: e.dolstra at tudelft.nl (Eelco Dolstra) Date: Fri, 25 Mar 2011 13:32:43 +0100 Subject: [Nix-dev] nuke-refs In-Reply-To: <1a91c997343f7e298b599a40a687f368@mail.webofnilsson.com> References: <1a91c997343f7e298b599a40a687f368@mail.webofnilsson.com> Message-ID: <4D8C8B6B.2080003@tudelft.nl> Hi, On 03/25/2011 01:23 PM, Rickard Nilsson wrote: > I'm trying to build the nixos ISO with: > > nix-build nixos/release.nix -A iso_minimal > > I've got a recent nix trunk build installed, and I've added prebuilt binaries > with nix-pull. However, I get the following error: > > /nix/store/rk9jl8rzqr7ynmaaz0qdy8j9r5hkb56f-stdenv-linux/setup: line 864: > nuke-refs: command not found In what derivation does this happen? > What is nuke-refs, and why is it not found? It's used in the generation of the initrd to prevent unwanted dependencies from being pulled in (for instance, it would be bad to get a complete copy of Glibc in the initrd). However, the derivations that need nuke-refs have the nukeReferences package in their buildInputs, so I don't know why this should fail. -- Eelco Dolstra | http://www.st.ewi.tudelft.nl/~dolstra/ From shea at shealevy.com Fri Mar 25 13:58:50 2011 From: shea at shealevy.com (Shea Levy) Date: Fri, 25 Mar 2011 08:58:50 -0400 Subject: [Nix-dev] GPT Fdisk 7.1 Message-ID: <4D8C918A.4050007@shealevy.com> Hi all, This patch bumps gptfdisk to version 7.1. Cheers, Shea Levy -------------- next part -------------- A non-text attachment was scrubbed... Name: gptfdisk-0.7.1.patch Type: text/x-patch Size: 864 bytes Desc: not available Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110325/4f8ebd0b/attachment.bin From shea at shealevy.com Fri Mar 25 14:01:47 2011 From: shea at shealevy.com (Shea Levy) Date: Fri, 25 Mar 2011 09:01:47 -0400 Subject: [Nix-dev] GPT Fdisk 7.1 In-Reply-To: <4D8C918A.4050007@shealevy.com> References: <4D8C918A.4050007@shealevy.com> Message-ID: <4D8C923B.4020000@shealevy.com> Whoops, there was an unnecessary space in that last one, resubmitting. On 03/25/2011 08:58 AM, Shea Levy wrote: > Hi all, > > This patch bumps gptfdisk to version 7.1. > > Cheers, > Shea Levy > > > _______________________________________________ > nix-dev mailing list > nix-dev at cs.uu.nl > https://mail.cs.uu.nl/mailman/listinfo/nix-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110325/6c491e6c/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: gptfdisk-0.7.1.patch Type: text/x-patch Size: 862 bytes Desc: not available Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110325/6c491e6c/attachment.bin From rickard.nilsson at telia.com Fri Mar 25 15:09:00 2011 From: rickard.nilsson at telia.com (Rickard Nilsson) Date: Fri, 25 Mar 2011 15:09:00 +0100 Subject: [Nix-dev] nuke-refs In-Reply-To: <4D8C8B6B.2080003@tudelft.nl> References: <1a91c997343f7e298b599a40a687f368@mail.webofnilsson.com> <4D8C8B6B.2080003@tudelft.nl> Message-ID: On Fri, 25 Mar 2011 13:32:43 +0100, Eelco Dolstra wrote: > Hi, > > On 03/25/2011 01:23 PM, Rickard Nilsson wrote: > >> I'm trying to build the nixos ISO with: >> >> nix-build nixos/release.nix -A iso_minimal >> >> I've got a recent nix trunk build installed, and I've added prebuilt >> binaries >> with nix-pull. However, I get the following error: >> >> /nix/store/rk9jl8rzqr7ynmaaz0qdy8j9r5hkb56f-stdenv-linux/setup: line >> 864: >> nuke-refs: command not found > > In what derivation does this happen? This is a bit more of the log: `/nix/store/sdiqv7h0m4q4rshxmhqdgpxhgxw1m7wd-bash-4.1-p2/bin/bash' -> `/nix/store/mbyd6656z4bj5bfbkyfif3pgd764r7dy-extra-utils/bin/bash' `/nix/store/mbyd6656z4bj5bfbkyfif3pgd764r7dy-extra-utils/bin/sh' -> `bash' `/nix/store/l5hgjwg2rap368c4zxc0w0r2s5irjvpw-module-init-tools-3.4/sbin/modprobe' -> `/nix/store/mbyd6656z4bj5bfbkyfif3pgd764r7dy-extra-utils/bin/modprobe.real' /nix/store/rk9jl8rzqr7ynmaaz0qdy8j9r5hkb56f-stdenv-linux/setup: line 864: nuke-refs: command not found builder for `/nix/store/bbzwn4p1p4ykcjmpklvm7mz3xi5vqjqh-extra-utils.drv' failed with exit code 127 cannot build derivation `/nix/store/b5vqd1z55giiay2lnh6xvy5in1w2ywhy-initrd.drv': 1 dependencies couldn't be built cannot build derivation `/nix/store/7w8bwsdgh0k945v2iglbnx7v73cwpaqd-iso9660-image.drv': 1 dependencies couldn't be built cannot build derivation `/nix/store/i83nypxax2lhs3qrazl685nv8khf3rz9-nixos-iso-0.1pre1234.drv': 1 dependencies couldn't be built error: build of `/nix/store/i83nypxax2lhs3qrazl685nv8khf3rz9-nixos-iso-0.1pre1234.drv' failed >> What is nuke-refs, and why is it not found? > > It's used in the generation of the initrd to prevent unwanted > dependencies from being pulled in (for instance, it would be bad to > get a complete copy of Glibc in the initrd). However, the > derivations > that need nuke-refs have the nukeReferences package in their > buildInputs, so I don't know why this should fail. From viriketo at gmail.com Fri Mar 25 15:26:20 2011 From: viriketo at gmail.com (=?iso-8859-1?Q?Llu=EDs?= Batlle i Rossell) Date: Fri, 25 Mar 2011 15:26:20 +0100 Subject: [Nix-dev] nuke-refs In-Reply-To: <1a91c997343f7e298b599a40a687f368@mail.webofnilsson.com> References: <1a91c997343f7e298b599a40a687f368@mail.webofnilsson.com> Message-ID: <20110325142618.GJ25277@vicerveza.homeunix.net> On Fri, Mar 25, 2011 at 01:23:32PM +0100, Rickard Nilsson wrote: > Hi, > > I'm trying to build the nixos ISO with: > > nix-build nixos/release.nix -A iso_minimal > > I've got a recent nix trunk build installed, and I've added prebuilt > binaries with nix-pull. However, I get the following error: > > /nix/store/rk9jl8rzqr7ynmaaz0qdy8j9r5hkb56f-stdenv-linux/setup: > line 864: nuke-refs: command not found > > What is nuke-refs, and why is it not found? Here goes my bet... I think some scripts assume /bin/sh is bash. Maybe your /bin/sh is not bash, and that is not understanding a bash declaration of nuke-refs? From roconnor at theorem.ca Fri Mar 25 19:06:58 2011 From: roconnor at theorem.ca (roconnor at theorem.ca) Date: Fri, 25 Mar 2011 14:06:58 -0400 (EDT) Subject: [Nix-dev] Re: Boost and Locale issues In-Reply-To: References: Message-ID: I've applied the patch given in that boost ticket and now bitcoin runs without setting any environment variables. Shall I go ahead and commit this update to the boost package? On Fri, 25 Mar 2011, Rob Vermaas wrote: > Sounds like a known bug in boost: https://svn.boost.org/trac/boost/ticket/4688 > > On Fri, Mar 25, 2011 at 08:30, Ambrus Kaposi wrote: > > No, locale::facet is general C++, not boost-specific. AFAIR, last time I had > > such problem switching to stdenv-updates helped but I'm not sure. > > I have the same problem with encfs wich also uses boost. > stdenv-updates didn't help: > > /etc/nixos/nixpkgs/pkgs/tools/filesystems/encfs/default.nix > > $ encfs > terminate called after throwing an instance of 'std::runtime_error' > ?what(): ?locale::facet::_S_create_c_locale name not valid > Aborted > _______________________________________________ > nix-dev mailing list > nix-dev at cs.uu.nl > https://mail.cs.uu.nl/mailman/listinfo/nix-dev > > > > > -- > Rob Vermaas > > [email] rob.vermaas at gmail.com > > -- Russell O'Connor ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.'' From simons at cryp.to Fri Mar 25 21:44:22 2011 From: simons at cryp.to (Peter Simons) Date: Fri, 25 Mar 2011 21:44:22 +0100 Subject: [Nix-dev] Re: Boost and Locale issues References: Message-ID: <87lj03j5g9.fsf@write-only.cryp.to> Hi Rob, > Shall I go ahead and commit this update to the boost package? as far as I'm concerned, yes, please do! Thanks a lot for taking care of this problem. Take care, Peter From shea at shealevy.com Sun Mar 27 15:36:37 2011 From: shea at shealevy.com (Shea Levy) Date: Sun, 27 Mar 2011 09:36:37 -0400 Subject: [Nix-dev] AUFS 2.1 for 2.6.37 Message-ID: <4D8F3D65.2090403@shealevy.com> Resubmitting this patch with notes. Attached is a nixpkgs patch (aufs2.1-2.6.37.patch) to add aufs2.1 and aufs2.1-utils to Linux 2.6.37 and a nixos patch (aufs2.1-nixos-test.patch) I used to test it. Some notes: * My motivation for this patch is that kernels < 2.6.36 contain an e1000e that does not support the ethernet card that is part of the chipset for the second-generation Core-i Intel CPUs, so in order to have a more useful livecd I needed to get aufs working with a newer kernel, and 2.6.37 is the latest kernel with an official aufs release. * All sources are downloaded with fetchgit. This is because the aufs upstream doesn't provide release tarballs, they just add a tag to their git tree for an official release. * The make target for the aufs2.1 headers uses a Makefile in the kernel build directory that requires that unifdef be in the scripts/ subdirectory of the build directory. The way I've dealt with this here is by adding "make $makeFlags -C scripts unifdef" to the postBuild in the kernel builder. Since the builder is used by all kernel versions, this will require rebuilding every kernel and kernel-dependent package if the patch is accepted, so one alternative I thought of would be to create a fake kernel build directory where everything is symlinked to the real build directory except scripts/, which is first copied and then make unifdef is run before building aufs2.1. If that more complicated solution is preferred, or if anyone has ideas for another one, I can do that and submit a new patch. * The patch was tested by building a livecd ISO that uses it, then running the ISO from within virtualbox and installing aufs2.1-util from within the livecd environment. * The livecd was built using installation-cd-minimal.nix, with two changes to the Nixos tree: 1. boot.kernelPackages = pkgs.linuxPackages_2_6_37 was added to profiles/minimal.nix 2. config.boot.kernelPackages.aufs2 was changed to config.boot.kernelPackages.aufs2_1 in iso-image.nix I would have preferred to keep all changes within profiles/minimal.nix, but I couldn't figure out how to override iso-image.nix's definition of boot.extraModulePackages. Livecds that use an older kernel can't be built with this iso-image.nix, since we don't have aufs2.1 for them (just aufs2). If someone can point me to how I can override things set in iso-image.nix, I'd appreciate it. Cheers, Shea Levy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110327/3609a8fe/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: aufs2.1-2.6.37.patch Type: text/x-patch Size: 17179 bytes Desc: not available Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110327/3609a8fe/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: aufs2.1-nixos-test.patch Type: text/x-patch Size: 957 bytes Desc: not available Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110327/3609a8fe/attachment-0001.bin From viriketo at gmail.com Sun Mar 27 16:02:23 2011 From: viriketo at gmail.com (=?iso-8859-1?Q?Llu=EDs?= Batlle i Rossell) Date: Sun, 27 Mar 2011 16:02:23 +0200 Subject: [Nix-dev] AUFS 2.1 for 2.6.37 In-Reply-To: <4D8F3D65.2090403@shealevy.com> References: <4D8F3D65.2090403@shealevy.com> Message-ID: <20110327135756.GB6333@vicerveza.homeunix.net> On Sun, Mar 27, 2011 at 09:36:37AM -0400, Shea Levy wrote: > Resubmitting this patch with notes. > * The make target for the aufs2.1 headers uses a Makefile in the > kernel build directory that requires that unifdef be in the > scripts/ subdirectory of the build directory. The way I've dealt > with this here is by adding "make $makeFlags -C scripts unifdef" > to the postBuild in the kernel builder. Since the builder is used > by all kernel versions, this will require rebuilding every kernel > and kernel-dependent package if the patch is accepted, so one > alternative I thought of would be to create a fake kernel build > directory where everything is symlinked to the real build > directory except scripts/, which is first copied and then make > unifdef is run before building aufs2.1. If that more complicated > solution is preferred, or if anyone has ideas for another one, I > can do that and submit a new patch. Sorry, but I prefer to ask before trying to understand this 'make -C scripts unifdef' alone. Does really this single change in the kernel builder makes the $out path have anything different (have the unifdef script, in this case)? It looks as if it would only build unifdef, but not install it. And isn't unifdef always built when building the kernel target? Regards, Llu?s. From viriketo at gmail.com Sun Mar 27 16:03:07 2011 From: viriketo at gmail.com (=?iso-8859-1?Q?Llu=EDs?= Batlle i Rossell) Date: Sun, 27 Mar 2011 16:03:07 +0200 Subject: [Nix-dev] GPT Fdisk 7.1 In-Reply-To: <4D8C923B.4020000@shealevy.com> References: <4D8C918A.4050007@shealevy.com> <4D8C923B.4020000@shealevy.com> Message-ID: <20110327140306.GC6333@vicerveza.homeunix.net> On Fri, Mar 25, 2011 at 09:01:47AM -0400, Shea Levy wrote: > Whoops, there was an unnecessary space in that last one, resubmitting. > On 03/25/2011 08:58 AM, Shea Levy wrote: > >Hi all, > > > >This patch bumps gptfdisk to version 7.1. Committed. Thank you! From shea at shealevy.com Sun Mar 27 16:14:24 2011 From: shea at shealevy.com (Shea Levy) Date: Sun, 27 Mar 2011 10:14:24 -0400 Subject: [Nix-dev] AUFS 2.1 for 2.6.37 In-Reply-To: <20110327135756.GB6333@vicerveza.homeunix.net> References: <4D8F3D65.2090403@shealevy.com> <20110327135756.GB6333@vicerveza.homeunix.net> Message-ID: <4D8F4640.8090009@shealevy.com> On 03/27/2011 10:02 AM, Llu?s Batlle i Rossell wrote: > On Sun, Mar 27, 2011 at 09:36:37AM -0400, Shea Levy wrote: >> Resubmitting this patch with notes. >> * The make target for the aufs2.1 headers uses a Makefile in the >> kernel build directory that requires that unifdef be in the >> scripts/ subdirectory of the build directory. The way I've dealt >> with this here is by adding "make $makeFlags -C scripts unifdef" >> to the postBuild in the kernel builder. Since the builder is used >> by all kernel versions, this will require rebuilding every kernel >> and kernel-dependent package if the patch is accepted, so one >> alternative I thought of would be to create a fake kernel build >> directory where everything is symlinked to the real build >> directory except scripts/, which is first copied and then make >> unifdef is run before building aufs2.1. If that more complicated >> solution is preferred, or if anyone has ideas for another one, I >> can do that and submit a new patch. > Sorry, but I prefer to ask before trying to understand this 'make -C scripts > unifdef' alone. > > Does really this single change in the kernel builder makes the $out path have > anything different (have the unifdef script, in this case)? It looks as if it > would only build unifdef, but not install it. And isn't unifdef always built > when building the kernel target? > > Regards, > Llu?s. Llu?s, make -C scripts unifdef compiles the unifdef application in the scripts/ directory, and when Nix copies over the build tree to $out/lib/modules/$version/build for kernel modules to reference, it copies over all of scripts/ except the .o files. I can't speak for other kernel versions, but at the least for 2.6.37.1 unifdef is not built by default. If you look at the Makefile in scripts, unifdef is listed under a comment saying that the following programs are only built on-demand. ~Shea From rickard.nilsson at telia.com Mon Mar 28 13:35:17 2011 From: rickard.nilsson at telia.com (Rickard Nilsson) Date: Mon, 28 Mar 2011 13:35:17 +0200 Subject: [Nix-dev] nuke-refs In-Reply-To: <20110325142618.GJ25277@vicerveza.homeunix.net> References: <1a91c997343f7e298b599a40a687f368@mail.webofnilsson.com> <20110325142618.GJ25277@vicerveza.homeunix.net> Message-ID: <50c3b7aa03cac3e24a0abaf0a27f9d34@mail.webofnilsson.com> On Fri, 25 Mar 2011 15:26:20 +0100, Llu?s Batlle i Rossell wrote: > On Fri, Mar 25, 2011 at 01:23:32PM +0100, Rickard Nilsson wrote: >> Hi, >> >> I'm trying to build the nixos ISO with: >> >> nix-build nixos/release.nix -A iso_minimal >> >> I've got a recent nix trunk build installed, and I've added prebuilt >> binaries with nix-pull. However, I get the following error: >> >> /nix/store/rk9jl8rzqr7ynmaaz0qdy8j9r5hkb56f-stdenv-linux/setup: >> line 864: nuke-refs: command not found >> >> What is nuke-refs, and why is it not found? > > Here goes my bet... I think some scripts assume /bin/sh is bash. > Maybe your > /bin/sh is not bash, and that is not understanding a bash declaration > of nuke-refs? No, my /bin/sh is bash, so that can't be it. / Rickard From shea at shealevy.com Mon Mar 28 13:36:43 2011 From: shea at shealevy.com (Shea Levy) Date: Mon, 28 Mar 2011 07:36:43 -0400 Subject: [Nix-dev] GCC 4.6.0 Message-ID: <4D9072CB.9030102@shealevy.com> Hi all, Attached is a patch to add GCC 4.6.0 to nixpkgs. Notes: * I first ran svn cp pkgs/development/compilers/gcc-4.5 pkgs/development/compilers/gcc-4.6, which will be necessary to apply the patch. * GCC 4.6.0 now requires ppl 0.11 for graphite optimizations, so I bumped that. o GCC 4.5 will build against ppl 0.11. I have not checked GCC 4.4, the first release supporting Graphite. o I had to change a hard-coded version check in CLooG-PPL's configure; this was recommended by some Gentoo devs and all of its tests passed against the new ppl. * I updated update-gcc.sh to work with GnuPG 2.x, which is the default if you just nix-env -i gnupg. It will still work with GnuPG 1.x. * $out/libexec/gcc/*/* contains a static library liblto_plugin.la, so the loop to take bootstrap-tools out of the RPATHs of the resulting binaries fails with "Not an ELF binary". I added an if statement to the loop to fix this. * I successfully built gcc46, gfortran46, and gcj46. I have not tested that the resulting binaries work. * I have not tested gcc46_realCross, as I don't know how cross-compiling on Nix works yet and do not have time to look into it right now. * gnat46 failed when I tried to build it by copying gnat45 and changing the gcc version to 4.6.0. I removed that from this patch, as I do not have time to debug that right now. * There's a space missing between grub2 and grub2_efi that's been really bothering me. Cheers, Shea Levy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110328/ac31a8cd/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: gcc-4.6.patch Type: text/x-patch Size: 7600 bytes Desc: not available Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110328/ac31a8cd/attachment.bin From ludo at gnu.org Mon Mar 28 14:23:32 2011 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Mon, 28 Mar 2011 14:23:32 +0200 Subject: [Nix-dev] Re: GCC 4.6.0 References: <4D9072CB.9030102@shealevy.com> Message-ID: <87bp0vtovv.fsf@gnu.org> Hi Shea, Excellent, thanks for the patch! Looks good to me. A few notes: Shea Levy writes: > * GCC 4.6.0 now requires ppl 0.11 for graphite optimizations, so I > bumped that. > o GCC 4.5 will build against ppl 0.11. I have not checked GCC > 4.4, the first release supporting Graphite. > o I had to change a hard-coded version check in CLooG-PPL's > configure; this was recommended by some Gentoo devs and all > of its tests passed against the new ppl. Could you change the patch to make it work in ?trunk? without requiring a complete rebuild? This way we could already use 4.6 with ?trunk?, even if stdenv still uses 4.5. To that end, you need to svn cp ppl/{default.nix,0.11.nix} and use the latter for 4.6, while keeping the former for 4.5. Same for CLooG-PPL. > * I updated update-gcc.sh to work with GnuPG 2.x, which is the > default if you just nix-env -i gnupg. It will still work with > GnuPG 1.x. OK. I modified ?update-gcc.sh? in the ?stdenv-updates? branch, but that should be OK. Thanks! Ludo?. From marco-oweber at gmx.de Mon Mar 28 17:20:54 2011 From: marco-oweber at gmx.de (Marc Weber) Date: Mon, 28 Mar 2011 17:20:54 +0200 Subject: [Nix-dev] [***SPAM***] [PATCH] fix adobeReader by adding gdk_pixbuf to libPath Message-ID: <1301325654-2823-1-git-send-email-marco-oweber@gmx.de> --- pkgs/applications/misc/adobe-reader/default.nix | 10 ++++++++-- pkgs/top-level/all-packages.nix | 2 +- 2 files changed, 9 insertions(+), 3 deletions(-) diff --git a/pkgs/applications/misc/adobe-reader/default.nix b/pkgs/applications/misc/adobe-reader/default.nix index 24d01da..cc05328 100644 --- a/pkgs/applications/misc/adobe-reader/default.nix +++ b/pkgs/applications/misc/adobe-reader/default.nix @@ -1,4 +1,4 @@ -{ stdenv, fetchurl, libX11, cups, glib, pango, atk, gtk, zlib, libxml2 }: +{ stdenv, fetchurl, libX11, cups, zlib, libxml2, gtkLibs }: assert stdenv.system == "i686-linux"; @@ -17,7 +17,13 @@ stdenv.mkDerivation { # versions. libPath = stdenv.lib.makeLibraryPath - [ stdenv.gcc.gcc libX11 glib pango atk gtk zlib libxml2 cups ]; + [ stdenv.gcc.gcc libX11 zlib libxml2 cups + gtkLibs.pango + gtkLibs.atk + gtkLibs.gtk + gtkLibs.glib + gtkLibs.gdk_pixbuf + ]; meta = { description = "Adobe Reader, a viewer for PDF documents"; diff --git a/pkgs/top-level/all-packages.nix b/pkgs/top-level/all-packages.nix index 9d70c53..be80fbf 100644 --- a/pkgs/top-level/all-packages.nix +++ b/pkgs/top-level/all-packages.nix @@ -5584,7 +5584,7 @@ let }; adobeReader = callPackage_i686 ../applications/misc/adobe-reader { - inherit (pkgsi686Linux.gtkLibs) glib pango atk gtk; + gtkLibs = pkgsi686Linux.gtkLibs; }; akunambol = newScope pkgs.kde4 ../applications/networking/sync/akunambol { }; -- 1.6.6.2 From ludo at gnu.org Mon Mar 28 17:33:34 2011 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Mon, 28 Mar 2011 17:33:34 +0200 Subject: [Nix-dev] NixOS module assertions Message-ID: <87bp0vs1ip.fsf@gnu.org> Hello, Currently setting ?boot.kernelPackages = linuxPackages_2_6_34;? results in the oh-so-clear error message below: value is null while an attribute set was expected The reason is that ?linuxPackages_2_6_34? doesn?t have the fbcondecor patch, and thus ?kernelPackages.splashutils? is null. ?tty-backgrounds.nix? then references ?splashutils?, hence the error. There?s an assertion in ?tty-backgrounds.nix?, which checks whether ?splashutils? is null. However, that assertion is apparently not checked by the time ?splashutils? is referenced in ?preStart? and ?postStop?. Why is that? How should we work around it? Thanks, Ludo?. From e.dolstra at tudelft.nl Mon Mar 28 17:46:33 2011 From: e.dolstra at tudelft.nl (Eelco Dolstra) Date: Mon, 28 Mar 2011 17:46:33 +0200 Subject: [Nix-dev] [***SPAM***] [PATCH] fix adobeReader by adding gdk_pixbuf to libPath In-Reply-To: <1301325654-2823-1-git-send-email-marco-oweber@gmx.de> References: <1301325654-2823-1-git-send-email-marco-oweber@gmx.de> Message-ID: <4D90AD59.9060007@tudelft.nl> Hi, On 03/28/2011 05:20 PM, Marc Weber wrote: > pkgs/applications/misc/adobe-reader/default.nix | 10 ++++++++-- > pkgs/top-level/all-packages.nix | 2 +- Thanks, applied. -- Eelco Dolstra | http://www.st.ewi.tudelft.nl/~dolstra/ From nicolas.b.pierron at gmail.com Tue Mar 29 11:11:11 2011 From: nicolas.b.pierron at gmail.com (Nicolas Pierron) Date: Tue, 29 Mar 2011 11:11:11 +0200 Subject: [Nix-dev] NixOS module assertions In-Reply-To: <87bp0vs1ip.fsf@gnu.org> References: <87bp0vs1ip.fsf@gnu.org> Message-ID: Hi, On Mon, Mar 28, 2011 at 17:33, Ludovic Court?s wrote: > Currently setting ?boot.kernelPackages = linuxPackages_2_6_34;? results > in the oh-so-clear error message below: > > value is null while an attribute set was expected > > The reason is that ?linuxPackages_2_6_34? doesn?t have the fbcondecor > patch, and thus ?kernelPackages.splashutils? is null. > ?tty-backgrounds.nix? then references ?splashutils?, hence the error. Thanks for finding this issue. > There?s an assertion in ?tty-backgrounds.nix?, which checks whether > ?splashutils? is null. However, that assertion is apparently not > checked by the time ?splashutils? is referenced in ?preStart? and > ?postStop?. > > Why is that? How should we work around it? We should not work around it. the "assertions" option is lazy as all options used in NixOS, which means if you don't evaluate it it won't break. This is not nice and I understand that you want to work around it. I think, when assertions option has been added we forgot to think about the list of option impacted by the assertion. Taking the tty-background.nix as an example: config = mkIf config.services.ttyBackgrounds.enable { assertions = singleton { assertion = kernelPackages.splashutils != null; message = "The kernelPackages does not provide splashutils, as required by ttyBackgrounds. " + "Either provide kernelPackages with splashutils, or disable ttyBackgrounds."; }; services.ttyBackgrounds.specificThemes = singleton { ... }; environment.etc = singleton { ... }; jobs.ttyBackgrounds = { ... }; }; illustrate that the assertion does not touch the value of the configuration, but the assertion is handled later while serializing the environment (which is hacky) which may not be related. So the assertion should be applied to all options which may be impacted if the assertion is not verified. In the tty-background.nix file, we already have a similar construct, which is the mkIf property. Thus, the solution to our problem is to provide a similar property which handle assertions ;) This would be less hacky and would avoid such errors in the future. config = mkIf config.services.ttyBackgrounds.enable ( mkAssert kernelPackages.splashutils != null " The kernelPackages does not provide splashutils, as required by ttyBackgrounds. Either provide kernelPackages with splashutils, or disable ttyBackgrounds. " { services.ttyBackgrounds.specificThemes = singleton { ... }; environment.etc = singleton { ... }; jobs.ttyBackgrounds = { ... }; }); We can remark that an mkAssert property will act identically as the mkIf property, thus we can write the mkAssert property as: mkAssert = assertion: message: content: mkIf (if assertion then true else throw "\nFailed assertion: ${message}") content; The only disadvantage is that you won't see multiple assertions failing at once. On the other side, you will always see when an assertion is failing and this implementation is cleaner. -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ From marco-oweber at gmx.de Tue Mar 29 11:42:24 2011 From: marco-oweber at gmx.de (Marc Weber) Date: Tue, 29 Mar 2011 11:42:24 +0200 Subject: [Nix-dev] NixOS module assertions In-Reply-To: <87bp0vs1ip.fsf@gnu.org> References: <87bp0vs1ip.fsf@gnu.org> Message-ID: <1301391421-sup-7106@nixos> Excerpts from ludo's message of Mon Mar 28 17:33:34 +0200 2011: > Why is that? How should we work around it? In order to reproduce your problem having a configuration.nix file would be benefical. I get the assertion only when setting kernelPackages and enabling ttyBackgrounds. I'd vote for moving the code checking the assertions (assertions.nix) # This option is evaluated always. Thus the assertions are checked as well. hacky! environment.systemPackages = if [] == failed then [] else throw "\nFailed assertions:\n${concatStringsSep "\n" (map (x: "- ${x}") failed)}"; to eval-config.nix to ensure its evaluated first eg by adding this untested code which surrounds the old config = by a let .. in catching the case that assertion messages are present: # Optionally check wether all config values have corresponding # option declarations. config = let cfg = let doCheck = optionDefinitions.environment.checkConfigurationOptions; in assert doCheck -> pkgs.lib.checkModule "" systemModule; systemModule.config; failed = map (x: x.message) (filter (x: !x.assertion) cfg.assertions); in if failed == [] then cfg else throw "\nFailed assertions:\n${concatStringsSep "\n" (map (x: "- ${x}") failed)}" Marc Weber From ludo at gnu.org Tue Mar 29 16:16:33 2011 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Tue, 29 Mar 2011 16:16:33 +0200 Subject: [Nix-dev] Re: NixOS module assertions References: <87bp0vs1ip.fsf@gnu.org> Message-ID: <87mxkeovum.fsf@gnu.org> Hi Nicolas, Thanks for your quick response. Nicolas Pierron writes: > Thus, the solution to our problem is to provide a similar property > which handle assertions ;) This would be less hacky and would avoid > such errors in the future. > > config = > mkIf config.services.ttyBackgrounds.enable ( > mkAssert kernelPackages.splashutils != null " So we?d have to use ?mkAssert? in many modules, or maybe in all modules, right? Do you plan to make the change? :-) Thanks, Ludo?. From nicolas.b.pierron at gmail.com Tue Mar 29 16:28:19 2011 From: nicolas.b.pierron at gmail.com (Nicolas Pierron) Date: Tue, 29 Mar 2011 16:28:19 +0200 Subject: [Nix-dev] Re: NixOS module assertions In-Reply-To: <87mxkeovum.fsf@gnu.org> References: <87bp0vs1ip.fsf@gnu.org> <87mxkeovum.fsf@gnu.org> Message-ID: On Tue, Mar 29, 2011 at 16:16, Ludovic Court?s wrote: > Hi Nicolas, > > Thanks for your quick response. > > Nicolas Pierron writes: > >> ?Thus, the solution to our problem is to provide a similar property >> which handle assertions ;) ?This would be less hacky and would avoid >> such errors in the future. >> >> ?config = >> ? mkIf config.services.ttyBackgrounds.enable ( >> ? mkAssert kernelPackages.splashutils != null " > > So we?d have to use ?mkAssert? in many modules, or maybe in all modules, > right? Yes, > Do you plan to make the change? ?:-) they are already committed locally, still have to push them. -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ From marco-oweber at gmx.de Tue Mar 29 16:46:51 2011 From: marco-oweber at gmx.de (Marc Weber) Date: Tue, 29 Mar 2011 16:46:51 +0200 Subject: [Nix-dev] NixOS module assertions In-Reply-To: References: <87bp0vs1ip.fsf@gnu.org> Message-ID: <1301409926-sup-2185@nixos> Excerpts from Nicolas Pierron's message of Tue Mar 29 11:11:11 +0200 2011: > The only disadvantage is that you won't see multiple assertions > failing at once. > On the other side, you will always see when an > assertion is failing and this implementation is cleaner. Would you mind comparing your solution briefly with what I suggested: force evaluation of assertions when returning the config? I prefer seeing all failures at once rather than many iterative try / fail / fix cycles. Marc Weber From e.dolstra at tudelft.nl Tue Mar 29 17:01:14 2011 From: e.dolstra at tudelft.nl (Eelco Dolstra) Date: Tue, 29 Mar 2011 17:01:14 +0200 Subject: [Nix-dev] NixOS module assertions In-Reply-To: <1301409926-sup-2185@nixos> References: <87bp0vs1ip.fsf@gnu.org> <1301409926-sup-2185@nixos> Message-ID: <4D91F43A.9010300@tudelft.nl> Hi, On 03/29/2011 04:46 PM, Marc Weber wrote: > Excerpts from Nicolas Pierron's message of Tue Mar 29 11:11:11 +0200 2011: >> The only disadvantage is that you won't see multiple assertions >> failing at once. > >> On the other side, you will always see when an >> assertion is failing and this implementation is cleaner. > Would you mind comparing your solution briefly with what I suggested: > force evaluation of assertions when returning the config? > > I prefer seeing all failures at once rather than many iterative try / > fail / fix cycles. How many assertion failures do you typically see? I rarely get them. -- Eelco Dolstra | http://www.st.ewi.tudelft.nl/~dolstra/ From marco-oweber at gmx.de Tue Mar 29 17:27:20 2011 From: marco-oweber at gmx.de (Marc Weber) Date: Tue, 29 Mar 2011 17:27:20 +0200 Subject: [Nix-dev] NixOS module assertions In-Reply-To: <4D91F43A.9010300@tudelft.nl> References: <87bp0vs1ip.fsf@gnu.org> <1301409926-sup-2185@nixos> <4D91F43A.9010300@tudelft.nl> Message-ID: <1301412268-sup-7787@nixos> Excerpts from Eelco Dolstra's message of Tue Mar 29 17:01:14 +0200 2011: > How many assertion failures do you typically see? I rarely get them. I don't see them often. But NixOS is very young. More configurations will be added in the future. I agree that its debatable. How much overhead does the alternative solution cost? Well - go for it. I know where to change it when getting annoyed in the future. Marc Weber From nicolas.b.pierron at gmail.com Tue Mar 29 18:09:29 2011 From: nicolas.b.pierron at gmail.com (Nicolas Pierron) Date: Tue, 29 Mar 2011 18:09:29 +0200 Subject: [Nix-dev] NixOS module assertions In-Reply-To: <1301391421-sup-7106@nixos> References: <87bp0vs1ip.fsf@gnu.org> <1301391421-sup-7106@nixos> Message-ID: On Tue, Mar 29, 2011 at 11:42, Marc Weber wrote: > Excerpts from ludo's message of Mon Mar 28 17:33:34 +0200 2011: >> Why is that? ?How should we work around it? > > In order to reproduce your problem having a configuration.nix file would > be benefical. I get the assertion only when setting kernelPackages and > enabling ttyBackgrounds. > > I'd vote for moving the code checking the assertions (assertions.nix) > > ?# This option is evaluated always. Thus the assertions are checked as well. hacky! > ?environment.systemPackages = > ? ?if [] == failed then [] > ? ?else throw "\nFailed assertions:\n${concatStringsSep "\n" (map (x: "- ${x}") failed)}"; > > > to eval-config.nix to ensure its evaluated first eg by adding this untested > code which surrounds the old config = by a let .. in catching the case that > assertion messages are present: > > ?# Optionally check wether all config values have corresponding > ?# option declarations. > ?config = > ? ?let cfg = > ? ? ? ?let doCheck = optionDefinitions.environment.checkConfigurationOptions; in > ? ? ? ?assert doCheck -> pkgs.lib.checkModule "" systemModule; > ? ? ? ?systemModule.config; > ? ? ? ?failed = map (x: x.message) (filter (x: !x.assertion) cfg.assertions); > ? ?in if failed == [] then cfg > ? ? ? else throw "\nFailed assertions:\n${concatStringsSep "\n" (map (x: "- ${x}") failed)}" The problem I see here is that you cannot focus on small subset of your configuration if one assertion is failing unless you disable each module. The problem is raised when you may want to check for option values while trying to understand why you've got an error message (including the assertions). I would prefer to use properties for assertions (mkAssert), so an assertion made on an unused option has no effect. -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ From marco-oweber at gmx.de Tue Mar 29 18:25:36 2011 From: marco-oweber at gmx.de (Marc Weber) Date: Tue, 29 Mar 2011 18:25:36 +0200 Subject: [Nix-dev] NixOS module assertions In-Reply-To: <1301415432-sup-6139@nixos> References: <87bp0vs1ip.fsf@gnu.org> <1301391421-sup-7106@nixos> <1301415432-sup-6139@nixos> Message-ID: <1301415902-sup-6213@nixos> Excerpts from Nicolas Pierron's message of Tue Mar 29 18:09:29 +0200 2011: > The problem I see here is that you cannot focus on small subset of > your configuration if one assertion is failing unless you disable each > module. > The problem is raised when you may want to check for option values > while trying to understand why you've got an error message (including > the assertions). I don't know what you mean by "check for option values". The assertion message should be unique. By grepping for it it should be easy to understand the cause of trouble. That would be my way to cope with such failures.. Is this the difference: my solution: assertions always fire your solution: assertions only fire when a "guarded" expression is used? I see the point. However I don't think its important because assertions are usually guarded by mkIfs or the like. Thus they are only checked when a module is enabled. > I would prefer to use properties for assertions (mkAssert), so an > assertion made on an unused option has no effect. I already said that I'm fine with your solution. You know this code much better than I do. Marc Weber From ludo at gnu.org Tue Mar 29 22:31:12 2011 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Tue, 29 Mar 2011 22:31:12 +0200 Subject: [Nix-dev] Re: NixOS module assertions In-Reply-To: (Nicolas Pierron's message of "Tue, 29 Mar 2011 16:28:19 +0200") References: <87bp0vs1ip.fsf@gnu.org> <87mxkeovum.fsf@gnu.org> Message-ID: <87bp0tekj3.fsf@gnu.org> Nicolas Pierron writes: > On Tue, Mar 29, 2011 at 16:16, Ludovic Court?s wrote: [...] >> Do you plan to make the change? ?:-) > > they are already committed locally, still have to push them. Excellent, thank you! Ludo?. From shea at shealevy.com Wed Mar 30 02:58:28 2011 From: shea at shealevy.com (Shea Levy) Date: Tue, 29 Mar 2011 20:58:28 -0400 Subject: [Nix-dev] Re: GCC 4.6.0 In-Reply-To: <87bp0vtovv.fsf@gnu.org> References: <4D9072CB.9030102@shealevy.com> <87bp0vtovv.fsf@gnu.org> Message-ID: <4D928034.6020100@shealevy.com> Resubmitting GCC 4.6.0, with several changes. The notes in my original mail can be ignored, this email is complete and self-contained (notes in rough order of the files in the patch): * To apply this patch, the following three svn cp's are necessary: o svn cp pkgs/development/libraries/ppl/{default,0.11}.nix o svn cp pkgs/development/libraries/cloog{-ppl,} o svn cp pkgs/development/compilers/gcc-4.{5,6} * GCC 4.6.0 requires ppl of at least version 0.11 for Graphite optimizations * GCC 4.6.0 can use any of three versions of CLooG for Graphite optimizations: cloog-ppl (the legacy CLooG based on PPL), cloog-parma (the new CLooG based on PPL), and cloog (the new CLooG based on ISL). While cloog-ppl is still the default, cloog (called cloog-isl by GCC) is preferred. Only one of the three cloogs can be used. * update-gcc.sh has been updated to work with gpg2, the name of the binary provided by the GnuPG in nixpkgs. Those with the old gpg binary can still run the script. * GCC 4.6.0 puts at least one static library in $out/libexec/gcc/*/*, so trying to remove bootstrap-tools from its RPATH causes the builder to fail. This is fixed by moving a variable assignment into an if statement. * libquadmath is "a recent addition" in "the list of libraries to disable in the course of... a [static-only] bootstrap" of GCC, see http://gcc.gnu.org/ml/gcc/2011-03/msg00465.html * There is a space missing between grub2 and grub2_efi in all-packages.nix (not related to GCC, but noticed in the course of this work) * gcc46, gcj46, and gfortran46 build successfully with a simple nix-build on my x86_64 system * After temporarily changing the default cross-GCC to gcc46_realCross, xbursttools built successfully on my x86_64 system, which involved building gcc-4.6.0-mipsel-unknown-linux-stage-static, one test of gcc46_realCross * gnat46 did not build on my system. There was a strange error with the linker not treating libiberty/pic/libiberty.a as position-independent code, despite the fact that it was compiled with -fpic and readelf lists relocation tables for it. See http://gcc.gnu.org/ml/gcc-help/2011-03/msg00352.html for a discussion of the issue; I will be submitting a bug report to upstream and will report back with any responses. In http://gcc.gnu.org/ml/gcc-help/2011-03/msg00370.html it was suggested that it may be a problem with our GCC 4.5.1. Cheers, Shea Levy On 03/28/2011 08:23 AM, Ludovic Court?s wrote: > Hi Shea, > > Excellent, thanks for the patch! Looks good to me. > > A few notes: > > Shea Levy writes: > >> * GCC 4.6.0 now requires ppl 0.11 for graphite optimizations, so I >> bumped that. >> o GCC 4.5 will build against ppl 0.11. I have not checked GCC >> 4.4, the first release supporting Graphite. >> o I had to change a hard-coded version check in CLooG-PPL's >> configure; this was recommended by some Gentoo devs and all >> of its tests passed against the new ppl. > Could you change the patch to make it work in ?trunk? without requiring > a complete rebuild? This way we could already use 4.6 with ?trunk?, > even if stdenv still uses 4.5. > > To that end, you need to svn cp ppl/{default.nix,0.11.nix} and use the > latter for 4.6, while keeping the former for 4.5. Same for CLooG-PPL. > >> * I updated update-gcc.sh to work with GnuPG 2.x, which is the >> default if you just nix-env -i gnupg. It will still work with >> GnuPG 1.x. > OK. I modified ?update-gcc.sh? in the ?stdenv-updates? branch, but that > should be OK. > > Thanks! > > Ludo?. > > _______________________________________________ > nix-dev mailing list > nix-dev at cs.uu.nl > https://mail.cs.uu.nl/mailman/listinfo/nix-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110329/def547fd/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: gcc-4.6.patch Type: text/x-patch Size: 14215 bytes Desc: not available Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110329/def547fd/attachment.bin From shea at shealevy.com Wed Mar 30 03:50:23 2011 From: shea at shealevy.com (Shea Levy) Date: Tue, 29 Mar 2011 21:50:23 -0400 Subject: [Nix-dev] AUFS 2.1 Kernel Feature Message-ID: <4D928C5F.20404@shealevy.com> Hi all, This patch adds a "features.aufs2_1" to the aufs-2.1 patch for Linux 2.6.37 to prevent aufs2_1 and aufs2_1_util from being options for kernels without an aufs 2.1 patch. There were several Hydra build failures as a result of attempting to build aufs2.1 against older kernels. Cheers, Shea Levy -------------- next part -------------- A non-text attachment was scrubbed... Name: aufs2.1-feature.patch Type: text/x-patch Size: 1386 bytes Desc: not available Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110329/5a9440c6/attachment.bin From rickard.nilsson at telia.com Wed Mar 30 15:40:27 2011 From: rickard.nilsson at telia.com (Rickard Nilsson) Date: Wed, 30 Mar 2011 15:40:27 +0200 Subject: [Nix-dev] nuke-refs In-Reply-To: <1a91c997343f7e298b599a40a687f368@mail.webofnilsson.com> References: <1a91c997343f7e298b599a40a687f368@mail.webofnilsson.com> Message-ID: Hi, I have still not resolved this issue. I can install nuke-references with nix-env without problems, but something is preventing the builder to find the program. This makes me wonder, how is the $PATH set up for the builder process? I use a builder group with ten builder users in it. The builders has no shell (/bin/false) and no home (/var/empty). But how is nuke-refs (and other binaries that is built as dependencies) added to the path for these users? Maybe I have some error in my setup, but I don't know where to start looking. Regards, Rickard Nilsson On Fri, 25 Mar 2011 13:23:32 +0100, Rickard Nilsson wrote: > Hi, > > I'm trying to build the nixos ISO with: > > nix-build nixos/release.nix -A iso_minimal > > I've got a recent nix trunk build installed, and I've added prebuilt > binaries with nix-pull. However, I get the following error: > > /nix/store/rk9jl8rzqr7ynmaaz0qdy8j9r5hkb56f-stdenv-linux/setup: > line 864: nuke-refs: command not found > > What is nuke-refs, and why is it not found? > > > Regards, > Rickard Nilsson > _______________________________________________ > nix-dev mailing list > nix-dev at cs.uu.nl > https://mail.cs.uu.nl/mailman/listinfo/nix-dev From urkud+nix at ya.ru Wed Mar 30 18:25:06 2011 From: urkud+nix at ya.ru (Yury G. Kudryashov) Date: Wed, 30 Mar 2011 20:25:06 +0400 Subject: [Nix-dev] Re: nuke-refs References: <1a91c997343f7e298b599a40a687f368@mail.webofnilsson.com> Message-ID: Rickard Nilsson wrote: > Hi, > > I have still not resolved this issue. I can install nuke-references > with nix-env without problems, but something is preventing the builder > to find the program. > > This makes me wonder, how is the $PATH set up for the builder process? > I use a builder group with ten builder users in it. The builders has no > shell (/bin/false) and no home (/var/empty). But how is nuke-refs (and > other binaries that is built as dependencies) added to the path for > these users? Maybe I have some error in my setup, but I don't know where > to start looking. PATH is made from buildInputs every time, see /etc/nixos/nixpkgs/pkgs/stdenv/generic/setup.sh From miglanz at gmail.com Thu Mar 31 00:25:24 2011 From: miglanz at gmail.com (Kamil Klimkiewicz) Date: Thu, 31 Mar 2011 00:25:24 +0200 Subject: [Nix-dev] [disnix] per-host configuration file generation Message-ID: <20110331002524.52ba5bd2.miGlanz@gmail.com> Hi guys, I found out about Nix/NixOS/Disnix a couple of days ago, by accident. I have to say it's a great piece of software. It was a little tricky to grasp the whole expression language (especially given I last used any functional language 5+ years ago) at first, but now I think I'm slowly getting used to it. Anyway, I have one question about disnix. I'm trying to use it for deployment of Django application (together with all dependent services - PostgreSQL, pgpool, nginx, gunicorn WSGI server, etc.). The whole thing will sit on Ubuntu server(s) - for various reasons. Everything looks great so far. But I got into a little problem. Let's say I have a nginx service that sits on single machine and django/gunicorn/pgpool service that sits on a couple of machines. How would you go about providing configuration file for pgpool service that depends on the machine this service is running on? Let's say I want the pgpool service to use different ports on particular servers. My current ideas are: - Generate configuration files for each machine in advance using pgpool service Nix expression - I simply store files named pgpool-machine1.conf, pgpool-machine2.conf, etc. in the pgpool's nix store. This has one major drawback - whenever I change configuration for single machine I have to distribute the service to all pgpool machines and possibly it will restart pgpool services on all machines. - Generate configuration files in service activation script - this doesn't look too nix-y in my opinion. - Create separate "subservice" for each machine. How would you resolve this issue? What I have in mind is some kind of map that takes a service generator function and a list of machines, but I don't see a way to make it work. Any ideas? -- Best regards, Kamil Klimkiewicz From S.vanderBurg at tudelft.nl Thu Mar 31 13:29:20 2011 From: S.vanderBurg at tudelft.nl (Sander van der Burg - EWI) Date: Thu, 31 Mar 2011 13:29:20 +0200 Subject: [Nix-dev] [disnix] per-host configuration file generation References: <20110331002524.52ba5bd2.miGlanz@gmail.com> Message-ID: <8A23E531C514ED43B1B469040352E7BA129576@SRV503.tudelft.net> Hi Kamil, Good to hear that you have discovered our tooling :) If I understand everything correctly, you want to "tune" services to have host specific settings, right? In most examples I have used for Disnix, services are relocatable and are built/configured only using properties of their intra-dependencies and inter-dependencies. If a service needs machine specific settings (e.g. a port number), you basically have to create a tuned variant, configured for that particular machine. I have encountered a similar issue in the Disnix TCP proxy example. To tune services for a particular host, you can write a Disnix expression like this: {stdenv}: {port}: {hello_world_server}: let makeFlags = "PREFIX=$out srcPort=${toString port} destHostname=${hello_world_server.target.hostname} destPort=${toString (hello_world_server.port)}"; in stdenv.mkDerivation { name = "disnix-tcp-proxy"; src = ../../../services/disnix-tcp-proxy; buildPhase = "make ${makeFlags}"; installPhase = "make ${makeFlags} install"; } Basically, this expression takes 3 arguments. The first argument are its intra-dependencies (similar to ordinary Disnix expressions, the second argument is a port-number (which is configured in the services model), the third argument are the inter-dependencies. As you can see, the value of the port number is configurable, and in the stdenv.mkDerivation function (which builds the service) the makeFlags argument is used to pass the port value to make. In the services.nix model, the port number is provided and configured: {system, distribution, pkgs}: let customPkgs = import ../top-level/all-packages.nix { inherit system pkgs; }; in rec { hello_world_server = rec { name = "hello_world_server"; pkg = customPkgs.hello_world_server { inherit port; }; # calling the previous expression with desired 'port' argument port = 5000; # This is the TCP port where we want to run the service on type = "wrapper"; }; ... } You may wonder why we put this 'port' attribute in the services model? This makes it possible to retrieve those values through inter-dependency arguments. So for instance, if you have a service which has an inter-dependency on the hello_world_server and you want to know the port number on which it is running you can fetch this property directly through inter-dependency arguments: {stdenv, inetutils}: {hello_world_server}: # Refers to the hello_world_service defined in services.nix let makeFlags = "PREFIX=$out helloWorldHostname=${hello_world_server.target.hostname} helloWorldPort=${toString (hello_world_server.port)} inetutils=${inetutils}"; # Configured the client to use the port number of the server. in stdenv.mkDerivation { name = "hello-world-client"; src = ../../../services/hello-world-client; buildPhase = "make ${makeFlags}"; installPhase = "make ${makeFlags} install"; } The expression above shows the Disnix expression of the hello world client. This expression fetches the 'port' attribute from the hello_world_server inter-dependency argument. In the body the client is configured to use to port value of the server. I hope this explanation clarifies some things a bit. You can obtain the source code and Nix expressions from the example I have given from Disnix download page, or through Subversion: https://svn.nixos.org/repos/nix/disnix/examples/disnix-proxy-example/trunk -----Original Message----- From: nix-dev-bounces at cs.uu.nl on behalf of Kamil Klimkiewicz Sent: Thu 3/31/2011 12:25 AM To: nix-dev at cs.uu.nl Subject: [Nix-dev] [disnix] per-host configuration file generation Hi guys, I found out about Nix/NixOS/Disnix a couple of days ago, by accident. I have to say it's a great piece of software. It was a little tricky to grasp the whole expression language (especially given I last used any functional language 5+ years ago) at first, but now I think I'm slowly getting used to it. Anyway, I have one question about disnix. I'm trying to use it for deployment of Django application (together with all dependent services - PostgreSQL, pgpool, nginx, gunicorn WSGI server, etc.). The whole thing will sit on Ubuntu server(s) - for various reasons. Everything looks great so far. But I got into a little problem. Let's say I have a nginx service that sits on single machine and django/gunicorn/pgpool service that sits on a couple of machines. How would you go about providing configuration file for pgpool service that depends on the machine this service is running on? Let's say I want the pgpool service to use different ports on particular servers. My current ideas are: - Generate configuration files for each machine in advance using pgpool service Nix expression - I simply store files named pgpool-machine1.conf, pgpool-machine2.conf, etc. in the pgpool's nix store. This has one major drawback - whenever I change configuration for single machine I have to distribute the service to all pgpool machines and possibly it will restart pgpool services on all machines. - Generate configuration files in service activation script - this doesn't look too nix-y in my opinion. - Create separate "subservice" for each machine. How would you resolve this issue? What I have in mind is some kind of map that takes a service generator function and a list of machines, but I don't see a way to make it work. Any ideas? -- Best regards, Kamil Klimkiewicz _______________________________________________ nix-dev mailing list nix-dev at cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110331/45345e2d/attachment.html From vcunat at gmail.com Thu Mar 31 21:41:36 2011 From: vcunat at gmail.com (=?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?=) Date: Thu, 31 Mar 2011 21:41:36 +0200 Subject: [Nix-dev] Re: Various patches In-Reply-To: References: Message-ID: Hello nixers, I'm sending some more patches. To Eelco: thanks for applying some of the previous set. Yesterday I spent a lot of time upgrading hakyll to 3.*, due to many transitive dependencies needing upgrade. I'm sending the resulting patch which also removes haskell's bytestring and network-bytestring packages (which are unused and packaged with GHC for years). Please, review and eventually apply the patch. I also upgraded Xfce packages to the newest 4.8.* versions. I already use the new versions but I'll need to polish the expressions, do more testing and resolve a menu problem. I'll send the patch afterward. If someone wants to test now, it can be found on http://mawercer.de:7000/?p=nixpkgs;a=shortlog;h=refs/heads/vlada/xfce That brings me to the reason I started using git for nixpkgs in the first place: some of the patches I sent a week ago got *no reply* whatsoever... fortunately TopGit handles this much better than svn, so I don't really mind. The problem is that in this manner our versions are going to diverge a bit which is not good and it is needless as long as noone objects to the patches. I don't think I'm the only one with patches that don't get to trunk just because noone cares about them (for example, marc has IMO a lot of such patches). Vlada -------------- next part -------------- A non-text attachment was scrubbed... Name: hakyll.patch Type: application/octet-stream Size: 20154 bytes Desc: not available Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110331/39c29c25/attachment.obj From marco-oweber at gmx.de Thu Mar 31 23:24:53 2011 From: marco-oweber at gmx.de (Marc Weber) Date: Thu, 31 Mar 2011 23:24:53 +0200 Subject: [Nix-dev] Re: Various patches In-Reply-To: References: Message-ID: <1301606177-sup-4746@nixos> Hi Vlada, Excerpts from Vladim?r ?un?t's message of Thu Mar 31 21:41:36 +0200 2011: > Yesterday I spent a lot of time upgrading hakyll to 3.*, due to many > transitive dependencies needing upgrade. :-( You should not have spend time on it. Use hack-nix. All this manually stuff is done by nixpgks-haskell-overlay for you. These are the steps I have to do to get it: a) add it to cabals bulid-deps b) run hack-nix --build-env (wait some minutes) c) source resulting shell script I've talked to Andres Loeh and tried explaining how hack-nix works. The result was that he would prefer a different system which does not yet exist. There are reasons why hack-nix is the way it is. And since Eelco rewrote the evaluator speed is acceptable as well. Marc Weber