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