[Nix-dev] [Nix-commits] SVN commit: nix - r30127 - innixos/trunk/modules:config installer/cd-dvdinstaller/generations-dir installer/toolsinstaller/tools/nixos-deploy-networkmisc security services/miscservices/monito...

[Michael Raskin]

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