Re: [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/
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=30127sc=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?
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [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/
On 10/30/2011 12:03 PM, Michael Raskin wrote:
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=30127sc=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?
First built a livecd with nix-build as non-root with NIX_REMOTE unset,
then within a VM built a system with nixos-install.
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.
~Shea
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [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/
Hi Michael, Was the build performed as root? Yes. Was it performed via nixos-rebuild? nixos-rebuild dry-run Was NIX_REMOTE set? No, or rather, it's set to an empty string. I hope this helps. Take care, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [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/
Shea: I feel your pain. That's one of the reasons why I forked - cause people revert patches (which feel randomly to authors) without even trying to discuss an issue enough so that its impossible to fix the issue causing the revert. This may lead to depression. Happened to me trying to implement the num-cores patch. Peter: you should talk about the nix version you used, architecture and your configuration.nix (unless its top secret). If Peter had taken care he would have tried providing as much info required to reproduce your info - and he would have waited a couple of hours asking you to resolve the issue. That you've been very responsive seems obvious to me. Which info is required? - configuration.nix - nix revision - architecture - (and as M.R noted NIX_REMOTE setting) Also reverting 3 patches because a one line patch is said to cause this issue ... can be done - but in the end its going to produce a lot of noise nobody wants to read in commit logs (sorry - my 2 cents). M.R already noted that its easy to get back the old revision - So let me add: Its easy to checkout the old revision until the issue is resolved which should be done as fast as possible. So Peter sending to the mailinglist should have made enough people be aware of the issue - and should have been enough for a couple of hours (maybe up to 24h). I don't expect that many people updating their systems every couple of hours. So the impact on the community would not have been that big if trunk was broken for some hours. That's why there are mailinglists and chat rooms. Anyway - why do people feel that strong about trunk? Is it because they have important systems which must run all day ? Such as spawning emergency systems on amazon? Then it should be them maintaining a stable branch - because that's the only way to ensure that their systems keep working - them depending on trunk would be insane anyway. And such a stable branch can be defined stable by all test cases pass. That would make lot's of sense - if something breaks another test case should eventually be added. BTW: Should we revert all patches on the git kernel tree because BTRFS broke (causing the system to hang and become slower ?). Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
