Re: [Nix-dev] gcc has stopped working on Mac OS X Mavericks
Alfredo Di Napoli alfredo.dinap...@gmail.com writes: Hello nixers, I think I'm having a very similar problem here which I do not have enough nix knowledge to debug. I have reinstalled nix-1.7 doing this (as suggested from the nix website): curl https://nixos.org/nix/install | sh So far so good. But when I try to install ANYTHING, (e.g. hello), this is what I get: installing `hello-2.9' these derivations will be built: /nix/store/al6xyibqncn9aicmkffr0n90xgxnfrm4-hello-2.9.drv building path(s) `/nix/store/71gijbvnnish0gvrci13qpsqxhqwnqvq-hello-2.9' building /nix/store/71gijbvnnish0gvrci13qpsqxhqwnqvq-hello-2.9 unpacking sources unpacking source archive /nix/store/xdilnlzvvsf7r33gs4vy9jq2bmazlc0j-hello-2.9.tar.gz source root is hello-2.9 patching sources configuring configure flags: --disable-dependency-tracking --prefix=/nix/store/71gijbvnnish0gvrci13qpsqxhqwnqvq-hello-2.9 checking for a BSD-compatible install... /nix/store/rc94la2h0pwkshbgmd7kz5nhklkdqyr2-coreutils-8.21/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /nix/store/rc94la2h0pwkshbgmd7kz5nhklkdqyr2-coreutils-8.21/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking for gcc... gcc checking whether the C compiler works... no configure: error: in `/private/var/folders/js/cv_q5mqd6_g76353vq_n4nqcgn/T/nix-build-hello-2.9.drv-0/hello-2.9': configure: error: C compiler cannot create executables See `config.log' for more details builder for `/nix/store/al6xyibqncn9aicmkffr0n90xgxnfrm4-hello-2.9.drv' failed with exit code 77 error: build of `/nix/store/al6xyibqncn9aicmkffr0n90xgxnfrm4-hello-2.9.drv' failed -- Which makes me suspect the error is very similar. Likewise, my xcrun thinks I'm on 10.10. Yep, that's it. Do what John Wiegley says, change the SDKROOT line in pkgs/stdenv/nix/default.nix to have this export SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk ... instead of the call to xcrun, then try again. -- Regards, Mike ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] system wide .vimrc / managing plugins the nix way - proposal and implementation
Now that that it does make sense to think about moving your .vim config into nix space it also makes sense to package most commonly used plugins. Thus if you think a plugin is missing in vimPlugins send me a private mail and I'll try to include it using the vimp-pi = nix export when creating the pull request. If you're using VAM you can create a list of plugins in use by :echo keys(g:vim_addon_manager.activated_plugins) Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Zero Hydra Failures (ZHF) project for NixOS
On Sat, Oct 25, 2014 at 05:45:34PM +0200, Nicolas Pierron wrote: We have 2 solution, either we stop the regressions when a pull request (PR) is made, or we stop it when the fire is in. The fireman role is hard to keep, and we should be verifying as much as possible at the PR time. Also, if we want to avoid firemans, we probably want to forbid pushing patches to the repository without having made a pull request at first. Which means, no more massive updates without checks. Just being completely honest here, I will be less likely to contribute things I don't need urgently if I have to open a PR and wait even after testing locally. One other way, is to have an inbound, and a nightly branch. Every day, we merge in nightly, the last green-build of the inbound branch which got tested by Hydra. This way we do not have a strict policy for pushing to inbound. The only policy being that nobody merge into inbound if it is broken. This is the model used by Mozilla. On Fri, Oct 24, 2014 at 12:31 PM, Vladimír Čunát vcu...@gmail.com wrote: On 10/23/2014 08:29 PM, Domen Kožar wrote: I'm +1 on this one. Hydra evaluates nixpkgs very fast. I'm only worried if the email is per build, not per jobset evaluation. Is that the case? I don't think it's per-build. I'd expect one e-mail per evaluation to all who committed in-between. The merged PR: https://github.com/NixOS/hydra/pull/126 Vladimir ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ 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
[Nix-dev] Tmux-1.9a fails to build in Yosemite
Hello Nixers, installing tmux-1.9a (latest) on a fresh Yosemite machine fails with: gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../compat -I../include -I../include -DTINYTEST_LOCAL -D_THREAD_SAFE -g -O2 -Wall -fno-strict-aliasing -Wno-deprecated-declarations -D_THREAD_SAFE -c -o regress-tinytest.o `test -f 'tinytest.c' || echo './'`tinytest.c In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/vproc.h:14:0, from tinytest.c:48: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/xpc/base.h:64:20: error: missing binary operator before token ( #if __has_extension(attribute_unavailable_with_message) ^ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/xpc/base.h:81:18: error: missing binary operator before token ( #if __has_feature(objc_arc) ^ tinytest.c: In function '_testcase_run_forked': tinytest.c:174:25: warning: ignoring return value of 'vproc_transaction_begin', declared with attribute warn_unused_result [-Wunused-result] vproc_transaction_begin(0); ^ make[3]: *** [regress-tinytest.o] Error 1 make[3]: Leaving directory `/private/var/folders/wy/0k1vvnwj6bq91h4wfkv95110gn/T/nix-build-libevent-2.0.21.drv-0/libevent-2.0.21-stable/test' make[2]: *** [all] Error 2 make[2]: Leaving directory `/private/var/folders/wy/0k1vvnwj6bq91h4wfkv95110gn/T/nix-build-libevent-2.0.21.drv-0/libevent-2.0.21-stable/test' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/private/var/folders/wy/0k1vvnwj6bq91h4wfkv95110gn/T/nix-build-libevent-2.0.21.drv-0/libevent-2.0.21-stable' make: *** [all] Error 2 builder for ‘/nix/store/b1nrbr5599ri4b496007la75zfm3vb4v-libevent-2.0.21.drv’ failed with exit code 2 cannot build derivation ‘/nix/store/g1swc97nqnvb4ydapfbw9jd7098gpcac-tmux-1.9a.drv’: 1 dependencies couldn't be built error: build of ‘/nix/store/g1swc97nqnvb4ydapfbw9jd7098gpcac-tmux-1.9a.drv’ failed Who is to blame, Apple or the tmux source code? (from a quick glance seems the former) Thanks! Alfredo ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] system wide .vimrc / managing plugins the nix way - proposal and implementation
I wrote that on github, but will copy-paste here: 1) We have to remove the old code from vim/configurable.nix (I mean the part of plugins loading https://github.com/NixOS/nixpkgs/blob/15bb4c20e614ed6835c59c7c9101ee59eacbe473/pkgs/applications/editors/vim/configurable.nix#L7 ) 2) Maybe it's a good idea to move `misc/vim-plugins` to `editors/vim/vim-plugins`? 3) After all of this all write the wiki page about vim in nixos, ok? 4) And I thing we have to rename `dependencies` to smth like `runtimeDependencies` and make them the same type as `buildInputs`, not the list of strings. So change in `vimrc` the conversion of deps to strings for vam, but in nixos make checking the existence of them. There will be more magic. -- Sincerely, Arseniy Seroka ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] system wide .vimrc / managing plugins the nix way - proposal and implementation
4) And I thin[*k*] we have to rename `dependencies` to smth like `runtimeDependencies` and make them the same type as `buildInputs`, not the Well runtimeDependencies could be executable tools. That dependencies attr only lists vim plugin names. We could flag derivations to be a vim plugin and traverse the dependenciy tree (runtime/build dependencies), but that would be more work (cpu wise) probably. I notice that we can do the same for pathogen: install all dependencies, thus the interface changed slightly to pathogen.pluginNames = [...]; and vim.pluginDictionaries = [..]; and vim-addon-nix will also install all depnedencies. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] gcc has stopped working on Mac OS X Mavericks
Alfredo Di Napoli alfredo.dinap...@gmail.com writes: On the silver lining, nix-1.7 works out of the box on Yosemite :) How is that possible? What are you doing to make it work? There's a major effort underway right now by Joel Taylor and Dan Peebles to get a stdenv working for Yosemite... John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] gcc has stopped working on Mac OS X Mavericks
Hi John, I swear, I did nothing! Just installed Nix, xcode and all its additional CLI components, in this order! Happy to help dissecting my machine to gather additional insights :) Alfredo Sent from my iPad On 27/ott/2014, at 17:07, John Wiegley jo...@newartisans.com wrote: Alfredo Di Napoli alfredo.dinap...@gmail.com writes: On the silver lining, nix-1.7 works out of the box on Yosemite :) How is that possible? What are you doing to make it work? There's a major effort underway right now by Joel Taylor and Dan Peebles to get a stdenv working for Yosemite... John ___ 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] Zero Hydra Failures (ZHF) project for NixOS
On Sat, Oct 25, 2014 at 05:45:34PM +0200, Nicolas Pierron wrote: We have 2 solution, either we stop the regressions when a pull request (PR) is made, or we stop it when the fire is in. The fireman role is hard to keep, and we should be verifying as much as possible at the PR time. Also, if we want to avoid firemans, we probably want to forbid pushing patches to the repository without having made a pull request at first. Which means, no more massive updates without checks. Just being completely honest here, I will be less likely to contribute things I don't need urgently if I have to open a PR and wait even after testing locally. And let's be honest even further: we need to go ahead quickly, our value is not in making mistakes rarely, it is in the ease of fixing them. We are not yet in the state where freezing it and maintaining stability is a good idea. I am afraid that the only good thing that can come from the quest for stability would be a well-tested way to support overlays. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Zero Hydra Failures (ZHF) project for NixOS
I think the following steps could be done without too much damage: - IRC bot that reports build failures for a range of commits once nixos-combined jobset is done - email to commiters that broke the the build (with a range of commits and list of builds failed) - nixos channel updates only when there are zero failures on jobset (this would mean reverts will happen often - and I believe that's the correct way to go instead of blocking people and punishing good testers) - encouragement of nox-review wip use. This will bulid also all reverse-dependencies (good old Gentoo times) - ease of bisecting failures (for 99% of use cases this could be a range of commits done for jobset with test script respecting exit code of nix-build) - it could be even done as a separate service or part of hydra or just a copy/paste command for local testing All that being said, there are still number of false positives that will drive people crazy. Mostly due to networking issues and transient failures in build systems (mostly during testing phase). We should address them one by one and reduce hard unpurities. I've already done so as part of ZHF, but much more work is needed. On Mon, Oct 27, 2014 at 7:33 PM, Michael Raskin 7c6f4...@mail.ru wrote: On Sat, Oct 25, 2014 at 05:45:34PM +0200, Nicolas Pierron wrote: We have 2 solution, either we stop the regressions when a pull request (PR) is made, or we stop it when the fire is in. The fireman role is hard to keep, and we should be verifying as much as possible at the PR time. Also, if we want to avoid firemans, we probably want to forbid pushing patches to the repository without having made a pull request at first. Which means, no more massive updates without checks. Just being completely honest here, I will be less likely to contribute things I don't need urgently if I have to open a PR and wait even after testing locally. And let's be honest even further: we need to go ahead quickly, our value is not in making mistakes rarely, it is in the ease of fixing them. We are not yet in the state where freezing it and maintaining stability is a good idea. I am afraid that the only good thing that can come from the quest for stability would be a well-tested way to support overlays. ___ 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] Zero Hydra Failures (ZHF) project for NixOS
- IRC bot that reports build failures for a range of commits once nixos-combined jobset is done Would be nice - email to commiters that broke the the build (with a range of commits and list of builds failed) Would be nice - nixos channel updates only when there are zero failures on jobset (this would mean reverts will happen often - and I believe that's the correct way to go instead of blocking people and punishing good testers) Back to the good old times of any failure blocking channel update, m-m-m. But we now have binary cache, so that doesn't matter that much. Can we also have a branch where bot would push the zero-failure channel commits, but no one else can push? - encouragement of nox-review wip use. This will bulid also all reverse-dependencies (good old Gentoo times) - ease of bisecting failures (for 99% of use cases this could be a range of commits done for jobset with test script respecting exit code of nix-build) - it could be even done as a separate service or part of hydra or just a copy/paste command for local testing I hope there would be bisect-wide failure caching (most of the time you simply need to find the first commit that changed anything at all in the build). All that being said, there are still number of false positives that will drive people crazy. Mostly due to networking issues and transient failures in build systems (mostly during testing phase). We should address them one by one and reduce hard unpurities. I've already done so as part of ZHF, but much more work is needed. Well, I think giving long-time committers minimal access to Hydra jobs (restarting failures as transient), that could already be a step forward. I am not sure whether it is possible to give out GC forcing rights without creating madness… ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] gcc has stopped working on Mac OS X Mavericks
Hi, just want to link this discussion to a related issue: https://github.com/NixOS/nix/issues/382 The symptoms seems to be that 10.9 + XCode 5.1 and 10.10 + XCode 6.1 work fine, but 10.9 + XCode 6.1 shows the hickups described in this thread. I am very new to nix, so I am not sure I can contribute a more permanent fix for this ... Cheers, Rene Am 27.10.2014 um 18:56 schrieb Alfredo Di Napoli alfredo.dinap...@gmail.com: Hi John, I swear, I did nothing! Just installed Nix, xcode and all its additional CLI components, in this order! Happy to help dissecting my machine to gather additional insights :) Alfredo Sent from my iPad On 27/ott/2014, at 17:07, John Wiegley jo...@newartisans.com wrote: Alfredo Di Napoli alfredo.dinap...@gmail.com writes: On the silver lining, nix-1.7 works out of the box on Yosemite :) How is that possible? What are you doing to make it work? There's a major effort underway right now by Joel Taylor and Dan Peebles to get a stdenv working for Yosemite... John ___ 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 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Arduino users
Hi, Does anyone know why the nixpkgs expression for ino pulls in minicom instead of picocom? ino serial only looks for picocom. Best regards, Bjørn Forsman ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
