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

[Shea Levy]

On 10/30/2011 12:28 PM, Michael Raskin wrote:
>>>> 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?
>> First built a livecd with nix-build as non-root with NIX_REMOTE unset,
>> then within a VM built a system with nixos-install.
> non-root without NIX_REMOTE? You have a world-writable store?
>

No, I was using a non-typical store (rooted in /mix instead of /nix) 
that I chown'd to my user.

>>>>> 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?"
>>>
>> Ok. I have no problem developing in a branch, I just don't know how I'll
>> know "now I'm finished, time to merge into trunk". But this is
>> orthogonal to the issue of reverting another developer's work with no
>> advance notice or proof of widespread problem.
> Given that re-revert would be cheap, resource-drainers seem to be better
> reverted in general case.
>
> It could be related to security fix in NIX_REMOTE=daemon builds, byt the
> way. Looks like you have an atypical setup in this respect.
>
>

I'll try rebuilding my real configuration and see if I can reproduce.