[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...

Michael Raskin 7c6f434c at mail.ru
Sun Oct 30 17:28:17 CET 2011


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

>>>> 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.





More information about the nix-dev mailing list