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. _______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
