>On 10/30/2011 11:46 AM, Michael Raskin wrote: >>> On 10/30/2011 11:19 AM, Peter Simons wrote: >>>> Author: simons >>>> Date: Sun Oct 30 15:19:58 2011 >>>> New Revision: 30127 >>>> URL: https://nixos.org/websvn/nix/?rev=30127&sc=1 >>>> >>>> Log: >>>> Reverting revisions 30103-30106: "always set >>>> nixpkgs.config.{state,store}Dir", etc. >>>> >>>> After the change from revision 30103, nixos-rebuild suddenly consumed >>>> freaky amounts of memory. I had to abort the process after it had >>>> allocated well in excess of 30GB(!) of RAM. I'm not sure what is causing >>>> this behavior, but undoing that assignment fixes the problem. The other >>>> two commits needed to be revoked, too, because they depend on 30103. >>>> >>> Hi Peter, >>> >>> In the future, can you please bring up an issue like this on the mailing >>> list before just reverting another developer's work? I'm more than happy >>> to work with you to get that problem resolved while getting what I need, >>> but straight up removing my work without even giving me a chance to fix >>> it is inappropriate. >>> >>> Thanks, >>> Shea >> "Eat 30GB" seems close enough to "broken".. Given that the earlier >> revisions are trivially accessible, reverting revisions that break >> trunk usability seems a reasonable thing. >> >I agree, but it's not obvious that the problem is due to a bug in my >work, and no one else has seen this problem (and I've used this code on >my tiny netbook with 4 g total ram+swap), so at least some confirmation >that others see this issue would be nice.
To both Peter and Shea: was the build performed as root? Was it performed via nixos-rebuild? Was NIX_REMOTE set? >> It seems that for most people the evaluation result doesn't change, >> so unlike stdenv-updates branch, a branch for these changes would be >> cheap to merge. >> >True, but as you said things shouldn't change for anyone else and I'm >testing on my machine and not seeing these problems, so how should I >determine when the branch is ready to merge? Each stage of changes is in >and of itself useful to me, it's not like only the end result will be, >and with these changes I can already install my system. Future changes >will be added as I find problems, so I could be out of sync with trunk >indefinitely. Merging from trunk is often a good idea. After a merge from trunk, it could be a good idea to ping the latest complainers with a question "Does this work now?" _______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
