[Nix-dev] FOSDEM: any plans for Saturday evening?
Hi, Since there will be quite a few NixOS and Guix folks at FOSDEM it would be great to meet up. Is there some interest in arranging dinner / drinks on Saturday evening? Cheers, Cillian ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] FOSDEM: any plans for Saturday evening?
Count me in. On Wed, Jan 22, 2014 at 1:50 PM, Cillian de Róiste cillian.deroi...@gmail.com wrote: Hi, Since there will be quite a few NixOS and Guix folks at FOSDEM it would be great to meet up. Is there some interest in arranging dinner / drinks on Saturday evening? Cheers, Cillian ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] FOSDEM: any plans for Saturday evening?
Cillian de Róiste cillian.deroi...@gmail.com writes: Hi, Since there will be quite a few NixOS and Guix folks at FOSDEM it would be great to meet up. Is there some interest in arranging dinner / drinks on Saturday evening? I'd love this! Just out of interest, which of us will be going? - ocharles ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] hydra admins: please take care of i686 GHC out of memory issues
Hi guys, I am confused. According to [1] we've had a working GHC build for Linux/i686 in evaluations 8394199 and 8396207 -- immediately after the stdenv-updates merge. Then Hydra ran a third build, [2], and that ended up being a cached failure. Yet, there were no failed builds since the stdenv merger! How is that possible? Am I missing something? Take care, Peter [1] http://hydra.nixos.org/job/nixpkgs/trunk/haskellPackages.ghc.i686-linux [2] http://hydra.nixos.org/build/8427824 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] New problem with nixops and virtualbox
Hi, after an update (nixos-13.10 and nixops 1.2) and a complete cleanup (including rm -rf ~/.nixops ~/.VirtualBox ~/Virtualbox\ VMs) I get the following error during deployment: $ nixops deploy webserver creating VirtualBox VM... webserver VBoxManage: error: Guest OS type 'Linux_64' is invalid webserver VBoxManage: error: Details: code VBOX_E_OBJECT_NOT_FOUND (0x80bb0001), component VirtualBox, interface IVirtualBox, callee nsISupports webserver VBoxManage: error: Context: CreateMachine(bstrSettingsFile.raw(), bstrName.raw(), ComSafeArrayAsInParam(groups), bstrOsTypeId.raw(), createFlags.raw(), machine.asOutParam()) at line 277 of file VBoxManageMisc.cpp error: command ‘['VBoxManage', 'createvm', '--name', 'nixops-b3edfc80-8367-11e3-8b40-d792b12c0a28-webserver', '--ostype', 'Linux_64', '--register']’ failed on machine ‘webserver’ (exit code 1 $ uname -a Linux o0dom0 3.4.76 #1-NixOS SMP Fri Jan 17 20:16:26 UTC 2014 x86_64 GNU/Linux As always, all suggestions are welcome, Marco ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] New problem with nixops and virtualbox
Hm, this seems to be related to this change: https://github.com/NixOS/nixops/commit/e6dfd68cab8a283308cba122d2923faf3c4f05df. I pushed a change to nixops to fix this. Cheers, Rob On Wed, Jan 22, 2014 at 2:35 PM, Marco Maggesi magg...@math.unifi.it wrote: Hi, after an update (nixos-13.10 and nixops 1.2) and a complete cleanup (including rm -rf ~/.nixops ~/.VirtualBox ~/Virtualbox\ VMs) I get the following error during deployment: $ nixops deploy webserver creating VirtualBox VM... webserver VBoxManage: error: Guest OS type 'Linux_64' is invalid webserver VBoxManage: error: Details: code VBOX_E_OBJECT_NOT_FOUND (0x80bb0001), component VirtualBox, interface IVirtualBox, callee nsISupports webserver VBoxManage: error: Context: CreateMachine(bstrSettingsFile.raw(), bstrName.raw(), ComSafeArrayAsInParam(groups), bstrOsTypeId.raw(), createFlags.raw(), machine.asOutParam()) at line 277 of file VBoxManageMisc.cpp error: command ‘['VBoxManage', 'createvm', '--name', 'nixops-b3edfc80-8367-11e3-8b40-d792b12c0a28-webserver', '--ostype', 'Linux_64', '--register']’ failed on machine ‘webserver’ (exit code 1 $ uname -a Linux o0dom0 3.4.76 #1-NixOS SMP Fri Jan 17 20:16:26 UTC 2014 x86_64 GNU/Linux As always, all suggestions are welcome, Marco ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev -- Rob Vermaas [email] rob.verm...@gmail.com ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] hydra admins: please take care of i686 GHC out of memory issues
Hi, I'm just guessing here, but: - there are packages, that depend on GHC, e.g. git-annex: http://hydra.nixos.org/build/8421542 - this is the same evaluation, but the build number is smaller. So what I think is happening: - there is package X that build depends on GHC, - when package X is built, then GHC is built (and fails), - every next GHC try is cached failure (git-annex, ghc-wrapper, etc.). I don't know how to derive X via the hydra webinterface, but maybe it's easy for admins with SQL access, I really have no idea. And my guess is that once we find package X, that will contain the real (non-cached) build for GHC in this evaluation. If you check the hash of the GHC that is trying to be built, then you will see that it is actually changing between the success-failure transition, so this would really be a new one compared to the ones from 21st January. And about the failures: I've been thinking about this for the last 2-3 days and probably we're just being fooled by randomness. Before the stdenv merge, we thought that trunk is failing and stdenv is not, but actually if you review history, we have 3 different (with different hash, so not just cached) GHC build tries on trunk, all failed. But there are also failed ones on the stdenv trunk, circa 1/2 of the cases. So having 3 failes in a row is only p=1/8. Now that stdenv is merged, 2 builds are good and then the third one is broken. This can easily be all just random from a random source with 1/2 chance. I wanted to actually get some statistically significant evidence this by setting up my local build machine where I can build 10-20 times, but didn't get to it yet. Maybe with different settings: lot of parallelism (-j16), then with none (-j1), etc. In the meantime can we please disable any parallelism during build for i686 (so no -j passing to any stage of the compiler) and try like that? Maybe we're just somehow hitting the 4G one process address space limit with threads or something. Also, would it too much of a waste of hydra resources to try 10 consecutive builds for _absolutely the same derivation_ and gather failure/success ratios? Thanks, Gergely On Wed, 22 Jan 2014 13:59:17 +0100, Peter Simons sim...@cryp.to writes: Hi guys, I am confused. According to [1] we've had a working GHC build for Linux/i686 in evaluations 8394199 and 8396207 -- immediately after the stdenv-updates merge. Then Hydra ran a third build, [2], and that ended up being a cached failure. Yet, there were no failed builds since the stdenv merger! How is that possible? Am I missing something? Take care, Peter [1] http://hydra.nixos.org/job/nixpkgs/trunk/haskellPackages.ghc.i686-linux [2] http://hydra.nixos.org/build/8427824 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
