[Nix-dev] Fwd: Installing wireless drivers
Probably, you have made a mistake in the configuration.nix. Here is my config which enables wicd, please re-check your layout. https://github.com/grwlf/nixpkgs/blob/local/machines/samsung-np900x3c.nix And here is another config, this time containing NetworkManager https://github.com/grwlf/nixpkgs/blob/local/machines/samsung-np900x3c-v2.nix Hope, they help. Regards, Sergey 2014-04-01 5:39 GMT+04:00 Raahul Kumar raahul.ku...@gmail.com: I have Sergey, unfortunatley nixos is saying it doesn't recognize those options. error: user-thrown exception: The option `wicd' defined in `/etc/nixos/configuration.nix' does not exist. (use `--show-trace' to show detailed location information) building the system configuration... error: The option `wicd' defined in `/etc/nixos/configuration.nix' does not exist. Looks like all the options have changed. So how do I setup using NetworkMangager? On Mon, Mar 31, 2014 at 9:27 PM, Sergey Mironov grr...@gmail.com wrote: Hi. Have you checked this wiki? https://nixos.org/wiki/WICD By the way, NetworkManager or KDE's equivalent may be a better choice for managing wireless networks. Wicd worked for me too, but it looks abandoned by it's developers. Regards, Sergey 2014-03-31 10:10 GMT+04:00 Raahul Kumar raahul.ku...@gmail.com: Hi guys, i've recently switched to a wireless configuration. Where can I download the WICD and other wireless packages? I'm on 64bit nixos. And after downloading, how do I install them? I do have a windows laptop to download packages with. Aloha, RK. ___ 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] Installing threadscope doesn't work
Hi,
I tried installing threadscope and got a nice error message, containing
many reports about ambiguous occurrences.
The relevant part of my config is (I played with commenting out different
permutations):
environment = {
systemPackages = with pkgs; [
(haskellPackages.ghcWithPackages (self : [
self.haskellPlatform
self.ghc
self.alex
self.happy
self.threadscope
self.zlib
]))
};
The output of nixos-rebuild is in bug.txt
Have a nice day :)
ikervagyok
# nixos-rebuild switch
building Nix...
building the system configuration...
these derivations will be built:
/nix/store/7ms6hkbgf7mxi4n47m5acrrjhbkgjxr0-system-crontab.drv
/nix/store/aqdg1k1jfzp6lp2gw928xq5j2b25jlbp-etc.drv
/nix/store/dgxq0qvsmdqmpn4myysbmpsdhx7nkqql-haskell-env-ghc-7.6.3.drv
/nix/store/dl4slacqws27csfqjcjyfg8zzwvwjijg-nixos-14.04pre40468.562f937.drv
/nix/store/miqi9bikqzwcrddx4brg3n7g25bww701-threadscope-0.2.2.drv
/nix/store/qcc7ijxkkz2amv5qbjfvr62vc3kwly4v-dbus-conf.drv
/nix/store/xyryqgh900wplim6r6rz8f1594pprp7r-system-path.drv
building path(s) `/nix/store/ww2l7ldi41zl3a818cxss23ak2v95wpr-threadscope-0.2.2'
[pbuilding /nix/store/ww2l7ldi41zl3a818cxss23ak2v95wpr-threadscope-0.2.2
[punpacking sources
[3punpacking source archive
/nix/store/llhf1xahlv0vw50yjnrbd6gv64hyybq7-threadscope-0.2.2.tar.gz
[qsource root is threadscope-0.2.2
[q[ppatching sources
[q[pconfiguring
[1 of 1] Compiling Main ( Setup.hs, Setup.o )
Linking Setup ...
configure flags: --enable-split-objs --disable-library-profiling
--disable-shared --enable-library-vanilla --disable-executable-dynamic
--enable-tests --ghc-options=-rtsopts
Configuring threadscope-0.2.2...
Dependency array -any: using array-0.4.0.1
Dependency base =4.0 5: using base-4.6.0.1
Dependency binary -any: using binary-0.5.1.1
Dependency cairo -any: using cairo-0.12.5.3
Dependency containers =0.2 0.6: using containers-0.5.0.0
Dependency deepseq =1.1: using deepseq-1.3.0.1
Dependency filepath -any: using filepath-1.3.0.1
Dependency ghc-events =0.4.2: using ghc-events-0.4.2.0
Dependency glib -any: using glib-0.12.5.3
Dependency gtk =0.12: using gtk-0.12.5.6
Dependency mtl -any: using mtl-2.1.2
Dependency pango -any: using pango-0.12.5.3
Dependency time =1.1: using time-1.4.0.1
Dependency unix =2.3 2.7: using unix-2.6.0.1
Using Cabal-1.16.0 compiled by ghc-7.6
Using compiler: ghc-7.6.3
Using install prefix:
/nix/store/ww2l7ldi41zl3a818cxss23ak2v95wpr-threadscope-0.2.2
Binaries installed in:
/nix/store/ww2l7ldi41zl3a818cxss23ak2v95wpr-threadscope-0.2.2/bin
Libraries installed in:
/nix/store/ww2l7ldi41zl3a818cxss23ak2v95wpr-threadscope-0.2.2/lib/ghc-7.6.3/threadscope-0.2.2
Private binaries installed in:
/nix/store/ww2l7ldi41zl3a818cxss23ak2v95wpr-threadscope-0.2.2/libexec
Data files installed in:
/nix/store/ww2l7ldi41zl3a818cxss23ak2v95wpr-threadscope-0.2.2/share/threadscope-0.2.2
Documentation installed in:
/nix/store/ww2l7ldi41zl3a818cxss23ak2v95wpr-threadscope-0.2.2/share/doc/threadscope-0.2.2
No alex found
Using ar found on system at:
/nix/store/dyb8q2dx4dnbxpajf9inycjh49mabmdy-binutils-2.23.1/bin/ar
No c2hs found
No cpphs found
No ffihugs found
Using gcc version 4.8.2 found on system at:
/nix/store/gl3rwzkmlhls3msdphrj6f9r6992dnaw-gcc-wrapper-4.8.2/bin/gcc
Using ghc version 7.6.3 found on system at:
/nix/store/hz2h1zcmpywp9f30wdq48mbp91pd11wh-ghc-7.6.3-wrapper/bin/ghc
Using ghc-pkg version 7.6.3 found on system at:
/nix/store/hz2h1zcmpywp9f30wdq48mbp91pd11wh-ghc-7.6.3-wrapper/bin/ghc-pkg
No greencard found
Using haddock version 2.13.2 found on system at:
/nix/store/43fvxiwmnim44rw6qxzcybl91pdd0q8c-ghc-7.6.3/bin/haddock
No happy found
No hmake found
Using hpc version 0.6 found on system at:
/nix/store/hz2h1zcmpywp9f30wdq48mbp91pd11wh-ghc-7.6.3-wrapper/bin/hpc
Using hsc2hs version 0.67 found on system at:
/nix/store/hz2h1zcmpywp9f30wdq48mbp91pd11wh-ghc-7.6.3-wrapper/bin/hsc2hs
No hscolour found
No hugs found
No jhc found
Using ld found on system at:
/nix/store/gl3rwzkmlhls3msdphrj6f9r6992dnaw-gcc-wrapper-4.8.2/bin/ld
No lhc found
No lhc-pkg found
No nhc98 found
Using pkg-config version 0.23 found on system at:
/nix/store/n6757dx6nmp8vf4pwb5cm92yixiyxzwd-pkg-config-0.23/bin/pkg-config
Using ranlib found on system at:
/nix/store/dyb8q2dx4dnbxpajf9inycjh49mabmdy-binutils-2.23.1/bin/ranlib
Using strip found on system at:
/nix/store/dyb8q2dx4dnbxpajf9inycjh49mabmdy-binutils-2.23.1/bin/strip
Using tar found on system at:
/nix/store/zsl05mbb69s38bbyi9nfff6vyry9m8jm-gnutar-1.27.1/bin/tar
No uhc found
[q[pbuilding
Building threadscope-0.2.2...
Preprocessing executable 'threadscope' for threadscope-0.2.2...
[ 1 of 35] Compiling Events.TestEvents ( Events/TestEvents.hs,
dist/build/threadscope/threadscope-tmp/Events/TestEvents.o )
[ 2 of 35] Compiling GUI.ViewerColours ( GUI/ViewerColours.hs,
dist/build/threadscope/threadscope-tmp/GUI/ViewerColours.o )
[ 3 of 35] Compiling GUI.Timeline.CairoDrawing ( GUI/Timeline/CairoDrawing.hs,
[Nix-dev] NiJS package manager
Hello Nixers, After a year of hard work, I proudly want to present you NiJS: the asynchronous package manager. In NiJS, you can use the more popular, innovating and future proof JavaScript language to specify package build specifications while still having most of the useful goodies that Nix has. Furthermore, because it's asynchronous and I/O events are non-blocking, it's also very fast and highly scalable. More info: http://sandervanderburg.blogspot.com/2014/04/asynchronous-package-management-with.html Best, Sander ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NiJS package manager
http://sandervanderburg.blogspot.com/2014/04/asynchronous-package-management-with.html I have discovered that the Nix expression language is complicated and difficult to learn. Like Haskell, it has a solid theoretical foundation and powerful features (such as laziness), but it's too hard to learn by developers without an academic background. What is this based on? Which is the async problem you were faced by using Nix? Thus which problem are you going to solve ? I personally have use cases in mind such as querying a server knowing about all ruby/python/haskell/perl/your-language-X packages - so that we don't need to distribute 50.000 package descriptions (rubyforge case) or similar. But anyway: We have 3 solutions for describing packages: nix, guix, nixjs Thus eventually its time to think about which information could be shared. Who would join a software version documentation project allowing people to upload the most recent version of my software is X, and it requires Z, FOO, BAR ? Then some nix, nijs, guix packages could be derived automatically (like haskell, ruby, xorg, .. packages). And all the other package systems such as debian could benefit eventually, too. Thoughts? Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NiJS package manager
On Tue, Apr 01, 2014 at 10:52:10AM +, Marc Weber wrote: Thus eventually its time to think about which information could be shared. Who would join a software version documentation project allowing people to upload the most recent version of my software is X, and it requires Z, FOO, BAR ? Lots of people. Lots of languages do this already. People don't have a problem with adding gemfiles, pom.xmls, rebar.configs, package.jsons and so on in their code repos (along with the more traditional autotools). I would certainly be keen to see a switch from a central nixpkgs repo to a system whereby the nix expression comes with the package itself. Yes, lots of details to figure out there, but I think it's preferable for a number of reasons. Then, obviously, there are central servers where this data is held. The interesting thing about the language-specific packaging is that it makes assumptions that the only thing you're allowed to specified is other items within the language eco-system. The language platform/RTS is your only interface with the computer, so, for example, you don't see a rebar.config demanding a particular version of libfoobarbaz (though there's inevitably some bleed when you get to FFIs). I'm guessing that the mechanical let's attempt to translate $language-specific-deps-file into nix has been tried and found wanting? I can see there's the node-packages-generated.nix, and others, but is that approach appropriate to all such languages? Matthew ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NiJS package manager
http://sandervanderburg.blogspot.com/2014/04/asynchronous-package-management-with.html I have discovered that the Nix expression language is complicated and difficult to learn. Like Haskell, it has a solid theoretical foundation and powerful features (such as laziness), but it's too hard to learn by developers without an academic background. I entirely disagree with this. From my perspective, Nix is a great language which covers the simple cases simply. I've been building an OpenVPN+VNC server (the equivalent of Terminal Services in the Windows world) with Nix, with no prior experience of either Nix or functional programming past the more functional bits of Python. It's been remarkably easy to define my own extensible services and extend packages when I need to, and I've had no problem doing so. Perhaps more complicated use cases are significantly more complicated to implement, but I'm not sure optimizing for them at the expense of the simplicity of Nix is a good idea. Part of what attracted me to NixOS in the first place was the simplicity of configuring it. But anyway: We have 3 solutions for describing packages: nix, guix, nixjs Thus eventually its time to think about which information could be shared. Who would join a software version documentation project allowing people to upload the most recent version of my software is X, and it requires Z, FOO, BAR ? Then some nix, nijs, guix packages could be derived automatically (like haskell, ruby, xorg, .. packages). And all the other package systems such as debian could benefit eventually, too. I would prefer that we simply work on making these interoperable. That is, define an API - packages can include each other, have things like mkDerivation, etc - build a library that implements that API, and allow languages to plug into that library. You would then be able to write in whichever language you chose, and include expressions from other languages. The system could even automatically build the runtime for whichever languages I use. Then, Disnix could be written in NiJS, and some packages I want could be written in Guix, some interesting library could be written in something else entirely, but I could write my configuration in Nix. Shell ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] chromium fails to build
Bjørn Forsman bjorn.fors...@gmail.com writes: Hi all, Does anyone know what's up with the failing chromium build? I reverted the upgrade for file locally. This fixes chromium. http://hydra.nixos.org/build/9819641/nixlog/1/tail-reload Build error: building /nix/store/9xzfnd38zpxcl840024220a6wi0kzsw6-chromium-33.0.1750.152 unpacking sources unpacking source archive /nix/store/qbmp81w0fvjsp8ibk9gw89k2al6873as-chromium-source-33.0.1750.152 source root is chromium-source-33.0.1750.152 patching sources configuring Updating projects from gyp files... gyp: Call to '../build/linux/python_arch.sh /usr/lib/libpython2.6.so.1.0' returned exit status 1. while trying to load /tmp/nix-build-chromium-33.0.1750.152.drv-0/chromium-source-33.0.1750.152/build/all.gyp builder for `/nix/store/101sh751v91zfws8k9gjcz4z2rqqp111-chromium-33.0.1750.152.drv' failed with exit code 1 error: build of `/nix/store/101sh751v91zfws8k9gjcz4z2rqqp111-chromium-33.0.1750.152.drv' failed The changes that (supposedly) caused it to break look quite irrelevant: https://github.com/NixOS/nixpkgs/compare/c814dab2eeb97c15f4a309e69435988fc3e65c6a...58857096fb679848730892d3f939be471e185cd1 Best regards, Bjørn Forsman ___ 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] NiJS package manager
Hi Sander! Sander van der Burg - EWI s.vanderb...@tudelft.nl skribis: After a year of hard work, I proudly want to present you NiJS: the asynchronous package manager. In NiJS, you can use the more popular, innovating and future proof JavaScript language to specify package build specifications while still having most of the useful goodies that Nix has. I’m glad to see a synergy around JavaScript! https://lists.gnu.org/archive/html/guix-devel/2014-04/msg0.html I imagine we can share efforts between both projects? Ludo’. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NiJS package manager
I would certainly be keen to see a switch from a central nixpkgs repo to a system whereby the nix expression comes with the package itself. Yes, lots of details to figure out there, but I think it's preferable for a number of reasons. Then, obviously, there are central servers where this data is held. I've been experimenting with nix to improve inhouse software buidability. The idea is to hame something.nix in source tree which is nothing more than single top level mkDerivation call with src = ./.. All inhouse dependencies are simple submodules and their expressions are imported using relative paths and then listed in buildInputs. The fact that dependencies are not some identification strings with optional versions like in deb or rpm, but whole derivation is Nix killer feature. So together with in tree .nix files it makes it unnecessary to maintain separate registry of packages, dependency locking is done implicitly (from Nix point of view) by git submodules. That means onybody can jump into the code, hack in any incompatible way and push it without worrying that it can break somebody's code. And as a bonus, there is zero time to setup dev environment, any newcomer just checks out project, runs ./dev-shell which first installs nix from git.io/nix-install.sh and then runs nix-shell on something.nix. And that is it. All compilers, libraries, headers, test data files and whatever else is needed is ready with no additional effort of maintaining docker/vargrant/whatever VMs just to do development. To assure rebuildability in the future, whole nixpgs is submodulled too. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NiJS package manager
Hi, On 01/04/14 12:11, Sander van der Burg - EWI wrote: After a year of hard work, I proudly want to present you NiJS: the asynchronous package manager. In NiJS, you can use the more popular, innovating and future proof JavaScript language to specify package build specifications while still having most of the useful goodies that Nix has. Furthermore, because it's asynchronous and I/O events are non-blocking, it's also very fast and highly scalable. Great stuff, this will finally enable truly massive, web-scale package management. I've long felt that the lack of non-blocking I/O and callbacks in the Nix language has really held us back. -- Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NiJS package manager
Awesome! The fact that Guix can generate EMCAScript, also make it robust and future proof. I also think we can reach even a bigger audience if we join efforts, so we should definitely look into it! From: nix-dev-boun...@lists.science.uu.nl [nix-dev-boun...@lists.science.uu.nl] on behalf of Ludovic Courtès [l...@gnu.org] Sent: Tuesday, April 01, 2014 1:58 PM To: nix-dev@lists.science.uu.nl Subject: Re: [Nix-dev] NiJS package manager Hi Sander! Sander van der Burg - EWI s.vanderb...@tudelft.nl skribis: After a year of hard work, I proudly want to present you NiJS: the asynchronous package manager. In NiJS, you can use the more popular, innovating and future proof JavaScript language to specify package build specifications while still having most of the useful goodies that Nix has. I’m glad to see a synergy around JavaScript! https://lists.gnu.org/archive/html/guix-devel/2014-04/msg0.html I imagine we can share efforts between both projects? Ludo’. ___ 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] NiJS package manager
I think this is the wrong way to go. The bootstrap size for JavaScript is huge with nodejs depending on the world. Nix is relatively small which is nice. It's far from optimal though. Haskell is also huge, but there are a few languages with tiny footprints. I suggest we look at ash or maybe zsh. I think keeping the core as small as possible is worth the extra verbosity of using a strict language. My 2 cents. Alexander On Apr 1, 2014 12:11 PM, Sander van der Burg - EWI s.vanderb...@tudelft.nl wrote: Hello Nixers, After a year of hard work, I proudly want to present you NiJS: the asynchronous package manager. In NiJS, you can use the more popular, innovating and future proof JavaScript language to specify package build specifications while still having most of the useful goodies that Nix has. Furthermore, because it's asynchronous and I/O events are non-blocking, it's also very fast and highly scalable. More info: http://sandervanderburg.blogspot.com/2014/04/asynchronous-package-management-with.html Best, Sander ___ 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] NiJS package manager
On Tue, Apr 1, 2014 at 6:18 AM, Shell Turner cam.t...@gmail.com wrote: http://sandervanderburg.blogspot.com/2014/04/asynchronous-package-management-with.html I have discovered that the Nix expression language is complicated and difficult to learn. Like Haskell, it has a solid theoretical foundation and powerful features (such as laziness), but it's too hard to learn by developers without an academic background. I entirely disagree with this. From my perspective, Nix is a great language which covers the simple cases simply. Me too. Ditching Nix would be a disaster for the NixOS ecosystem. Here's why: 1) It's a lot of work. The NixOS has some momentum, and a decision to deprecate Nix and rewrite everything in NiJS would stall that momentum. Lots of effort would go into reimplementing stuff that already works fine, and dealing with interoperability problems between legacy Nix expressions and newly-written NiJS code. During the transition period, it would create confusion for newbies and cause the whole system to be more difficult to understand, even for experts. 2) The main barrier to adoption isn't Nix syntax anyway. It's inertia. NixOs is fighting over 40 years of tradition in the Unix community. There have been pitched battles about whether /usr should be mounted read-only, whether 3rd-party software should go in /usr/local or /opt/local, and whether binaries run by other processes should be in /usr/bin or /usr/libexec. For people steeped in the details of the Linux Filesystem Hierarchy Standard, something like the nix store is completely alien. Every time Nix comes up in a public forum (Reddit, Hacker News, mailing lists) there's a hundred comments that boil down to you don't understand how packaging works. For every person who's thrilled by the idea of a purely-functional package manager, there's a thousand who think apt-get is so easy! and can't even imagine that something better is possible. Switching to Javascript as the packaging language won't solve any of those problems. 3) Asynchronous programming is hard. Sure, there are a lot of Javascript programmers out there, who will have some experience with callbacks. For everybody else, callbacks are a pain in the ass. They make it hard to reason about flow control, which makes everything else harder, especially error handling and debugging. Javascript may be more mainstream than Nix, but for a lot of people, it won't be easier to learn. 4) Switching to node may attract Javascript programmers, but it will repel people in other communities. If Nix comes to be seen as a Node thing it will cause people to ignore it just because they're using some other language. It might even cause people to start making clones for their languages--think Rubix and PyNix--so they integrate better with their ecosystem. (See, for example, Make, Rake, Grunt and Fabric.) Because it's a domain-specific language, Nix expressions don't have to come down on one side or the other in the language wars and can play nicely with everybody. 5) Switching from Nix to NiSJ goes against trend. Node is popular, sure, but it doesn't completely dominate programming the way Java did in the 90s, and it never will. There's probably still some growth left in the Node ecosystem, but not orders of magnitude more. On the other hand, functional languages have their best years ahead of them. Clojure, Erlang, Scala and Haskell are all growing steadily, and functional languages are seen as the future, even if they're not dominant today. The cool kids have switched from Ruby to Node in the last few years, but it won't be too many years before they switch to something else, and it's likely to be a functional language. 6) As languages go, Nix is actually quite practical and approachable. There's no compile step, and no type system to form initial barriers to entry. Nix files tend to be short and consist mostly of attribute sets, which have a very obvious syntax. It's easy to copy-and-modify a nix expression if you only need to make minor tweaks. This is exactly the kind of approachability and simple-to-get-started feel that made PHP so popular, but Nix has much more elegant underpinnings. So please, keep the faith! Nix is solid. There's no need to switch to something else. Colin ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] chromium fails to build
On Tue, Apr 01, 2014 at 01:21:04PM +0200, Mathijs Kwik wrote: I reverted the upgrade for file locally. This fixes chromium. should be fixed in 1ae4db3a80b7cd35bb9ea17464893b56664b17f9 and 51e449aabbc922faa00dc7b5cbd0f106eba7f928 and chromium now doesn't depend on file anymore. a! -- aszlig signature.asc Description: Digital signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NiJS package manager
Excerpts from Matthew Sackman's message of Tue Apr 01 11:12:32 + 2014: I'm guessing that the mechanical let's attempt to translate $language-specific-deps-file into nix has been tried and found wanting? I can see there's the node-packages-generated.nix, and others, but is that approach appropriate to all such languages? @Matthew: I think python in the past has had an option to determine the depedencies at runtime. ruby solves this by having different gem specs for different targets (JVM, ruby, operating system) Haskell has a very complicated configuration system called cabal which allows conditional descriptions such as: flag is_windows executable foo dependencies: if is_windows: lib-a else lib-b We should not be against a new option, we should think harder about collaborating so that all targets will work - which one is the best fit for use cases - future might tell. guile - ecma script: The difference is that guile has to compile everything to JS. AFAIK what Sander suggested is having the js interpreter only read some of all .js files - just enough to compile some packages (like nix does). Anyway - if Eelco decides on switching - I'd like to remind that less important policies might not be important at all :) Do we have any idea how much time nix spends on blocking IO ? I guess this would be interesting to know .. I know there is some benchmarking code .. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NiJS package manager
On Tue, Apr 01, 2014 at 04:42:50PM +, Marc Weber wrote: We should not be against a new option, we should think harder about collaborating so that all targets will work - which one is the best fit for use cases - future might tell. Indeed. One of the things that seems (at least to me) wrong about the let's download npmjs.org and convert everything to nix (ahead of time) approach is that it still requires every developer who is not working on open source code to write nix expressions for their own project which likely duplicate the dependency infomation held in their project's language-specific format. So, developer is working on some ruby project, and like all good ruby devs, is using rvm and bundler, and will already have a gemfile and a gemfile.lock. Now they want to deploy this with nix. Even if there are nix expressions for all of rubygems.org in nix, the dev still has to convert their own gemfile.lock to nix. But let us not forget that these language-specific dependency files tend to be pretty declarative (or, to put it another way: this is hard enough already, so let's ignore all the systems that aren't declarative). Surely we can write some nix expressions or extensions that can take in these existing language-specific files and dynamically (and perhaps dynamically and recursively - maybe Shea Levy's work on recursive nix would help here) turn these requirments into satisfyable nix expressions. This way there would be no requirement for our dev to do anything, there would be no preprocessing, and all sorts of people might get their projects deployed and working on nix without even realising that it's happening. Matthew ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] chromium fails to build
On 1 April 2014 18:01, aszlig asz...@redmoonstudios.org wrote: On Tue, Apr 01, 2014 at 01:21:04PM +0200, Mathijs Kwik wrote: I reverted the upgrade for file locally. This fixes chromium. should be fixed in 1ae4db3a80b7cd35bb9ea17464893b56664b17f9 and 51e449aabbc922faa00dc7b5cbd0f106eba7f928 and chromium now doesn't depend on file anymore. Thanks! I find it weird that the new file could break chromium like that... Anyway, glad you fixed it! ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NiJS package manager
Please think the other way round: - most linux distributions (exceptions LFS I know about) want to install packages Some packages (such as gnome) have dependency information, but only encoded in configure scripts or READMEs. Rubyforge and PyPi (don't know what's current in python community) do have some limited readable information. At least my nixpkgs-ruby-overlay is based on it. Thus maybe there is a way to convert dependency information rather than duplicating the work. Even omitting dependency information' - just knowing about the latest stable version - would make it easier to keep nixpkgs/NiJS/guix up to date IMHO. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NiJS package manager
Hi! Interesting project, but I mostly agree with Colin: asynchronous
programming is hard and in my opinion wouldn't become a 'killer
feature'. More, I am sure there are concepts in functional languages
which will overcome the callback-passing approach of JavaScript. I
think, Haskell's continuation monad is one of such concepts since it
allows writing code with callbacks in a plain imperative manner.
From the other side, Nix language has some uniq features which I found
to be very strong.
First one is recursive records which allows us to 'tie the knot' so
easily. Various `callPackage' functions use it and it is easy to
define new custom versions for different needs.
The second one is ' ' ... ' ' (string notation sugar) with
anti-quotations. I don't know other languages supporting this thing
(Haskell is close with it's Template Haskell facilities) and I now
think it is a must have thing for a package management language. I use
this notation here and there for writing safer shell scripts and even
for in-nix C programming. The example [at the end of the letter] may
looks too complicated but it works flawlessly in Nix. In contrast, I
think JavaScript wouldn't give me enough flexibility to allow such
style.
Regards,
Sergey
--
let
mount = ${busybox}/bin/mount;
data_partition = rec {
name = Data;
device = /dev/sda3;
mountpoint = /mnt/${name};
};
# Shell script snippet
with_mounted_partition = p: fn : ''
${mount} ${p.mountpoint}
( ${fn p.mountpoint} )
ret=$?
${umount} ${p.mountpoint}
(exit $ret)
'';
# A 'safer' shell script
installation_script = writeText install.sh ''
#!${shell}
#.. a larger script ...
${with_mounted_partition data_partition (mp: ''
cp bzImage ${mp}/kernel/bzImage
'')}
#.. continue larger script ..
'';
in
makeIsoImage {
buildCommand = ''
cp ${installation_script} $out
'';
}
2014-04-01 14:11 GMT+04:00 Sander van der Burg - EWI s.vanderb...@tudelft.nl:
Hello Nixers,
After a year of hard work, I proudly want to present you NiJS: the
asynchronous package manager.
In NiJS, you can use the more popular, innovating and future proof
JavaScript language to specify package build specifications while still
having most of the useful goodies that Nix has.
Furthermore, because it's asynchronous and I/O events are non-blocking, it's
also very fast and highly scalable.
More info:
http://sandervanderburg.blogspot.com/2014/04/asynchronous-package-management-with.html
Best,
Sander
___
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] NiJS package manager
OK, april 1st?
2014-04-01 23:11 GMT+04:00 Sergey Mironov grr...@gmail.com:
Hi! Interesting project, but I mostly agree with Colin: asynchronous
programming is hard and in my opinion wouldn't become a 'killer
feature'. More, I am sure there are concepts in functional languages
which will overcome the callback-passing approach of JavaScript. I
think, Haskell's continuation monad is one of such concepts since it
allows writing code with callbacks in a plain imperative manner.
From the other side, Nix language has some uniq features which I found
to be very strong.
First one is recursive records which allows us to 'tie the knot' so
easily. Various `callPackage' functions use it and it is easy to
define new custom versions for different needs.
The second one is ' ' ... ' ' (string notation sugar) with
anti-quotations. I don't know other languages supporting this thing
(Haskell is close with it's Template Haskell facilities) and I now
think it is a must have thing for a package management language. I use
this notation here and there for writing safer shell scripts and even
for in-nix C programming. The example [at the end of the letter] may
looks too complicated but it works flawlessly in Nix. In contrast, I
think JavaScript wouldn't give me enough flexibility to allow such
style.
Regards,
Sergey
--
let
mount = ${busybox}/bin/mount;
data_partition = rec {
name = Data;
device = /dev/sda3;
mountpoint = /mnt/${name};
};
# Shell script snippet
with_mounted_partition = p: fn : ''
${mount} ${p.mountpoint}
( ${fn p.mountpoint} )
ret=$?
${umount} ${p.mountpoint}
(exit $ret)
'';
# A 'safer' shell script
installation_script = writeText install.sh ''
#!${shell}
#.. a larger script ...
${with_mounted_partition data_partition (mp: ''
cp bzImage ${mp}/kernel/bzImage
'')}
#.. continue larger script ..
'';
in
makeIsoImage {
buildCommand = ''
cp ${installation_script} $out
'';
}
2014-04-01 14:11 GMT+04:00 Sander van der Burg - EWI
s.vanderb...@tudelft.nl:
Hello Nixers,
After a year of hard work, I proudly want to present you NiJS: the
asynchronous package manager.
In NiJS, you can use the more popular, innovating and future proof
JavaScript language to specify package build specifications while still
having most of the useful goodies that Nix has.
Furthermore, because it's asynchronous and I/O events are non-blocking, it's
also very fast and highly scalable.
More info:
http://sandervanderburg.blogspot.com/2014/04/asynchronous-package-management-with.html
Best,
Sander
___
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] NiJS package manager
Guys, Wasn't this replace Nix with JavaScript in a community of folks who love purity, lazyness and high-level languages post an April's fools? Check the date! Or am I mistaken and is this a serious proposal? Confused, Gergely On Tue, 1 Apr 2014 10:43:15 -0500, Colin Putney co...@wiresong.com writes: On Tue, Apr 1, 2014 at 6:18 AM, Shell Turner cam.t...@gmail.com wrote: http://sandervanderburg.blogspot.com/2014/04/asynchronous-package-management- with.html I have discovered that the Nix expression language is complicated and difficult to learn. Like Haskell, it has a solid theoretical foundation and powerful features (such as laziness), but it's too hard to learn by developers without an academic background. I entirely disagree with this. From my perspective, Nix is a great language which covers the simple cases simply. Me too. Ditching Nix would be a disaster for the NixOS ecosystem. Here's why: 1) It's a lot of work. The NixOS has some momentum, and a decision to deprecate Nix and rewrite everything in NiJS would stall that momentum. Lots of effort would go into reimplementing stuff that already works fine, and dealing with interoperability problems between legacy Nix expressions and newly-written NiJS code. During the transition period, it would create confusion for newbies and cause the whole system to be more difficult to understand, even for experts. 2) The main barrier to adoption isn't Nix syntax anyway. It's inertia. NixOs is fighting over 40 years of tradition in the Unix community. There have been pitched battles about whether /usr should be mounted read-only, whether 3rd-party software should go in /usr/local or /opt/local, and whether binaries run by other processes should be in /usr/bin or /usr/libexec. For people steeped in the details of the Linux Filesystem Hierarchy Standard, something like the nix store is completely alien. Every time Nix comes up in a public forum (Reddit, Hacker News, mailing lists) there's a hundred comments that boil down to you don't understand how packaging works. For every person who's thrilled by the idea of a purely-functional package manager, there's a thousand who think apt-get is so easy! and can't even imagine that something better is possible. Switching to Javascript as the packaging language won't solve any of those problems. 3) Asynchronous programming is hard. Sure, there are a lot of Javascript programmers out there, who will have some experience with callbacks. For everybody else, callbacks are a pain in the ass. They make it hard to reason about flow control, which makes everything else harder, especially error handling and debugging. Javascript may be more mainstream than Nix, but for a lot of people, it won't be easier to learn. 4) Switching to node may attract Javascript programmers, but it will repel people in other communities. If Nix comes to be seen as a Node thing it will cause people to ignore it just because they're using some other language. It might even cause people to start making clones for their languages—think Rubix and PyNix—so they integrate better with their ecosystem. (See, for example, Make, Rake, Grunt and Fabric.) Because it's a domain-specific language, Nix expressions don't have to come down on one side or the other in the language wars and can play nicely with everybody. 5) Switching from Nix to NiSJ goes against trend. Node is popular, sure, but it doesn't completely dominate programming the way Java did in the 90s, and it never will. There's probably still some growth left in the Node ecosystem, but not orders of magnitude more. On the other hand, functional languages have their best years ahead of them. Clojure, Erlang, Scala and Haskell are all growing steadily, and functional languages are seen as the future, even if they're not dominant today. The cool kids have switched from Ruby to Node in the last few years, but it won't be too many years before they switch to something else, and it's likely to be a functional language. 6) As languages go, Nix is actually quite practical and approachable. There's no compile step, and no type system to form initial barriers to entry. Nix files tend to be short and consist mostly of attribute sets, which have a very obvious syntax. It's easy to copy-and-modify a nix expression if you only need to make minor tweaks. This is exactly the kind of approachability and simple-to-get-started feel that made PHP so popular, but Nix has much more elegant underpinnings. So please, keep the faith! Nix is solid. There's no need to switch to something else. Colin ___ 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
Re: [Nix-dev] NiJS package manager
Hello everbody, It seems that my blog post caused quite a bit of discussion, which I really appreciate! I have decided to update my blog post with some additional notes based on the discussion: http://sandervanderburg.blogspot.com/2014/04/asynchronous-package-management-with.html From: nix-dev-boun...@lists.science.uu.nl [nix-dev-boun...@lists.science.uu.nl] on behalf of Gergely Risko [gerg...@risko.hu] Sent: Tuesday, April 01, 2014 9:19 PM To: nix-dev@lists.science.uu.nl Subject: Re: [Nix-dev] NiJS package manager Guys, Wasn't this replace Nix with JavaScript in a community of folks who love purity, lazyness and high-level languages post an April's fools? Check the date! Or am I mistaken and is this a serious proposal? Confused, Gergely On Tue, 1 Apr 2014 10:43:15 -0500, Colin Putney co...@wiresong.com writes: On Tue, Apr 1, 2014 at 6:18 AM, Shell Turner cam.t...@gmail.com wrote: http://sandervanderburg.blogspot.com/2014/04/asynchronous-package-management- with.html I have discovered that the Nix expression language is complicated and difficult to learn. Like Haskell, it has a solid theoretical foundation and powerful features (such as laziness), but it's too hard to learn by developers without an academic background. I entirely disagree with this. From my perspective, Nix is a great language which covers the simple cases simply. Me too. Ditching Nix would be a disaster for the NixOS ecosystem. Here's why: 1) It's a lot of work. The NixOS has some momentum, and a decision to deprecate Nix and rewrite everything in NiJS would stall that momentum. Lots of effort would go into reimplementing stuff that already works fine, and dealing with interoperability problems between legacy Nix expressions and newly-written NiJS code. During the transition period, it would create confusion for newbies and cause the whole system to be more difficult to understand, even for experts. 2) The main barrier to adoption isn't Nix syntax anyway. It's inertia. NixOs is fighting over 40 years of tradition in the Unix community. There have been pitched battles about whether /usr should be mounted read-only, whether 3rd-party software should go in /usr/local or /opt/local, and whether binaries run by other processes should be in /usr/bin or /usr/libexec. For people steeped in the details of the Linux Filesystem Hierarchy Standard, something like the nix store is completely alien. Every time Nix comes up in a public forum (Reddit, Hacker News, mailing lists) there's a hundred comments that boil down to you don't understand how packaging works. For every person who's thrilled by the idea of a purely-functional package manager, there's a thousand who think apt-get is so easy! and can't even imagine that something better is possible. Switching to Javascript as the packaging language won't solve any of those problems. 3) Asynchronous programming is hard. Sure, there are a lot of Javascript programmers out there, who will have some experience with callbacks. For everybody else, callbacks are a pain in the ass. They make it hard to reason about flow control, which makes everything else harder, especially error handling and debugging. Javascript may be more mainstream than Nix, but for a lot of people, it won't be easier to learn. 4) Switching to node may attract Javascript programmers, but it will repel people in other communities. If Nix comes to be seen as a Node thing it will cause people to ignore it just because they're using some other language. It might even cause people to start making clones for their languages—think Rubix and PyNix—so they integrate better with their ecosystem. (See, for example, Make, Rake, Grunt and Fabric.) Because it's a domain-specific language, Nix expressions don't have to come down on one side or the other in the language wars and can play nicely with everybody. 5) Switching from Nix to NiSJ goes against trend. Node is popular, sure, but it doesn't completely dominate programming the way Java did in the 90s, and it never will. There's probably still some growth left in the Node ecosystem, but not orders of magnitude more. On the other hand, functional languages have their best years ahead of them. Clojure, Erlang, Scala and Haskell are all growing steadily, and functional languages are seen as the future, even if they're not dominant today. The cool kids have switched from Ruby to Node in the last few years, but it won't be too many years before they switch to something else, and it's likely to be a functional language. 6) As languages go, Nix is actually quite practical and approachable. There's no compile step, and no type system to form initial barriers to entry. Nix files tend to be short and consist mostly of attribute sets, which have a very obvious syntax. It's easy to copy-and-modify a nix expression if you only
[Nix-dev] pkg-config: update and avoid patching?
Hi there, I was just trying to track down problems I have compiling some source under NixOS, and it seems as pkg-config is causing some trouble. That's why I wanted to bring up issue #292 again: Broken pkg-config patch for Requires.private Are there any plans to integrate a newer version of pkg-config and to avoid patching it? Many thanks, Thomas ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] oraclejdk7 dependencies in nixpkgs (commit: 5d6fdd8abbb576357844701b9cbffed033099128)
Gergely Risko gerg...@risko.hu writes: Benno, can you please clarify how do you know that ffmpeg_0_6 is a dependency and normal ffmpeg (0.10 currently) won't fit? +1, IIRC ffmpeg_0_10 should be fine (see PR #1636) ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] pkg-config: update and avoid patching?
Hi. On 04/02/2014 02:43 AM, Thomas Strobel wrote: That's why I wanted to bring up issue #292 again: Broken pkg-config patch for Requires.private I think it's better to discuss it in the issue directly; it's even open. Are there any plans to integrate a newer version of pkg-config and to avoid patching it? I don't think there are any plans yet. IMO some kind of that patch is very useful (with nix), porting it isn't easy, and I know of no issues with our current pkgconfig. Vlada smime.p7s Description: S/MIME Cryptographic Signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
