[Nix-dev] Announcing New Ruby Support
Hello all,
I'm pleased to announce that the Pleasant Ruby PR has landed on master. The
new
feature - bundlerEnv - allows one to package Ruby applications with Bundler.
To use the new system, first create (or copy over) a Gemfile describing the
required gems.
Next, create a Gemfile.lock by running `bundler package --no-install` in the
containing directory (this also creates two folders - vendor and .bundle -
which you'll want to delete before committing).
Now, you'll need to dump the lockfile as a Nix expression. To do so, use
Bundix
in the target directory:
$(nix-build '' -A bundix)/bin/bundix
That will drop a gemset.nix file in your current directory, which describes
the
sources for all of the gems and their respective SHAs.
Finally, you'll need to use bundlerEnv to build the gems. The following
example
is how we package the sup mail reader:
{ stdenv, lib, bundlerEnv, gpgme, ruby, ncurses, writeText, zlib, xapian
, pkgconfig, which }:
bundlerEnv {
name = "sup-0.20.0";
inherit ruby;
gemfile = ./Gemfile;
lockfile = ./Gemfile.lock;
gemset = ./gemset.nix;
# This is implicit:
#
# gemConfig = defaultGemConfig;
#
# You could just as well do the following:
#
# gemConfig.ncursesw = spec: {
# buildInputs = [ ncurses ];
# buildFlags = [
# "--with-cflags=-I${ncurses}/include"
# "--with-ldflags=-L${ncurses}/lib"
# ];
# };
#
# Where `spec` is the attributes of the corresponding gem,
# in case you wanted to make something predicated on version,
# for example.
#
# See default-gem-config.nix for more examples.
meta = with lib; {
description = "A curses threads-with-tags style email client";
homepage= http://supmua.org;
license = with licenses; gpl2;
maintainers = with maintainers; [ cstrahan lovek323 ];
platforms = platforms.unix;
};
}
And that's all there is to it!
Enjoy,
-Charles
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Funding Hydra Development
Forgive me, this is my fault for not being clear enough. Yes I too would feel uncomfortable about a nixos@home setup unless of course it includes some kind of blockchain. Even then it would be too expensive to run. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Funding Hydra Development
Ah, if the set of trusted people is a relatively small group of people someone like Eelco has met in person, then I'm much happier. When I first saw the suggestion, I was imagining some sort of seti@home kind of thing. Thanks, James On 21 January 2015 at 18:30, stewart mackenzie wrote: > I also refer to the use of Content Centric Networking (CCN) or Named > Data Networking (NDN) to disseminate binaries. > Please note, CCN builds security into the TCP/IP overlay protocol. > > So a binary is automatically signed by a "trusted" NixOS maintainer > whom is also running a private hydra node. > > Typically in these types of situations when a web of trust is formed, > one attends meetings > bringing along some kind of official identification. > One shows the identification to other nixers and then hands over the public > key. > The list of trusted keys is then signed by a globally trusted member - > eelco comes to mind. > This key list can be disseminated via CCN to all other hydra nodes and > Nix/NixOS nodes. > > When a Nix node wants a package it asks its CCN library. > If the binary (which has been signed by a trusted maintainer) is not > in the CCN's local Least Recently Used buffer, > it floods the request to other Nix/NixOS + Hydra nodes. That binary is > then copied leaving a breadcrumb trail > through the graph. Any future close proximity requests for that > package will then find it quicker somewhere > an the breadcrumb trail. > > I believe this article gets to the root of my argument regarding > living on master: > homing-on-code.blogspot.hk/2015/01/code-rot-openbsd.html (read the > "OpenBSD" section) > > Kind regards > Stewart > > On Thu, Jan 22, 2015 at 9:51 AM, James Cook wrote: >> On 21 January 2015 at 17:25, stewart mackenzie wrote: >>> James you execute code that wasn't written on your machine all the >>> time. What difference is there between not tursting the code writer vs >>> code compiler? >>> >>> Use a web of trust certificate system of course. >>> >>> Anyway if we could find away to live on master I think we'll get more >>> momentum. >> >> (Did you mean to reply-all? Feel free to include my response too if you did.) >> >> Using a web of trust or something like that partly mitigates the >> problem. I am still worried, though. >> >> Code committed to open source projects can be reviewed later. If >> someone submits a malicious binary, how will anyone ever know? So my >> bar for trusting binaries is much higher than my bar for trusting >> source from a popular open source project. >> >> I agree that it would be nice to live on master. I agree with >> Alexander that it would be nice to have a ballpark figure for what is >> needed. Maybe this can just be solved with donations of money. >> >> James ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Funding Hydra Development
I also refer to the use of Content Centric Networking (CCN) or Named Data Networking (NDN) to disseminate binaries. Please note, CCN builds security into the TCP/IP overlay protocol. So a binary is automatically signed by a "trusted" NixOS maintainer whom is also running a private hydra node. Typically in these types of situations when a web of trust is formed, one attends meetings bringing along some kind of official identification. One shows the identification to other nixers and then hands over the public key. The list of trusted keys is then signed by a globally trusted member - eelco comes to mind. This key list can be disseminated via CCN to all other hydra nodes and Nix/NixOS nodes. When a Nix node wants a package it asks its CCN library. If the binary (which has been signed by a trusted maintainer) is not in the CCN's local Least Recently Used buffer, it floods the request to other Nix/NixOS + Hydra nodes. That binary is then copied leaving a breadcrumb trail through the graph. Any future close proximity requests for that package will then find it quicker somewhere an the breadcrumb trail. I believe this article gets to the root of my argument regarding living on master: homing-on-code.blogspot.hk/2015/01/code-rot-openbsd.html (read the "OpenBSD" section) Kind regards Stewart On Thu, Jan 22, 2015 at 9:51 AM, James Cook wrote: > On 21 January 2015 at 17:25, stewart mackenzie wrote: >> James you execute code that wasn't written on your machine all the >> time. What difference is there between not tursting the code writer vs >> code compiler? >> >> Use a web of trust certificate system of course. >> >> Anyway if we could find away to live on master I think we'll get more >> momentum. > > (Did you mean to reply-all? Feel free to include my response too if you did.) > > Using a web of trust or something like that partly mitigates the > problem. I am still worried, though. > > Code committed to open source projects can be reviewed later. If > someone submits a malicious binary, how will anyone ever know? So my > bar for trusting binaries is much higher than my bar for trusting > source from a popular open source project. > > I agree that it would be nice to live on master. I agree with > Alexander that it would be nice to have a ballpark figure for what is > needed. Maybe this can just be solved with donations of money. > > James ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] environment.allowedLicenses ?
Another thing to do in the same spirit is to run Linux libre kernel, as an extreme test case: http://www.fsfla.org/ikiwiki/selibre/linux-libre/ 2015-01-21 18:46 GMT-02:00 Matthias Beyer : > I just opened a PR for this: > > https://github.com/NixOS/nixpkgs/pull/5892 > > Please review calmly (I'm a nix-newbie) and tell me what to improve > and what you think about it. > > I will add appropriate documentation in the PR + in the wiki if you > guys like this. > > On 21-01-2015 21:35:49, Domen Kožar wrote: >>Well, that function could be looking at license strings and allowing such >>packages with very little code. Could be a NixOS module setting indeed. > > -- > Mit freundlichen Grüßen, > Kind regards, > Matthias Beyer > > Proudly sent with mutt. > Happily signed with gnupg. > > ___ > 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] Funding Hydra Development
On 21 January 2015 at 14:10, Moritz Ulrich wrote: > Vladimír Čunát writes: > >> On 01/21/2015 10:32 PM, Wout Mertens wrote: >>> Not sure if throwing money at the Hydra codebase will speed up compiles >>> (apart from setting it up to use ccache). >> >> I understood that rather as having more build power at Hydra.nixos.org > > The other suggestion is quite nice too - I'd be glad to provide *some* > of the power of my Homeserver to a shared hydra instance. > > An approach like this would cause other issues though: Slow servers, low > bandwidth, etc. Distributed computing is just hard. What about security? I wouldn't use binaries from a hydra cluster that's open to anyone on the Internet to contribute to, because unless I misunderstand, that means everyone has the opportunity to substitute malicious binaries. James ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Funding Hydra Development
On Wed, Jan 21, 2015 at 10:34 PM, Vladimír Čunát wrote: > On 01/21/2015 10:32 PM, Wout Mertens wrote: > >> Not sure if throwing money at the Hydra codebase will speed up compiles >> (apart from setting it up to use ccache). >> > > I understood that rather as having more build power at Hydra.nixos.org > > It would be useful to have a ballpark figure wrt what is needed. A good start would be to update https://nixos.org/wiki/Hydra with the specs of the current machines, and list them all. I see builds on rackspace-[1-4] which are not listed for example. Alexander ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Funding Hydra Development
Vladimír Čunát writes: > On 01/21/2015 10:32 PM, Wout Mertens wrote: >> Not sure if throwing money at the Hydra codebase will speed up compiles >> (apart from setting it up to use ccache). > > I understood that rather as having more build power at Hydra.nixos.org The other suggestion is quite nice too - I'd be glad to provide *some* of the power of my Homeserver to a shared hydra instance. An approach like this would cause other issues though: Slow servers, low bandwidth, etc. Distributed computing is just hard. > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev -- signature.asc Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Funding Hydra Development
On 01/21/2015 10:32 PM, Wout Mertens wrote: Not sure if throwing money at the Hydra codebase will speed up compiles (apart from setting it up to use ccache). I understood that rather as having more build power at Hydra.nixos.org 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
Re: [Nix-dev] Funding Hydra Development
Sure, but who or what gets the money? Will it fund more build systems or will the money go to a recreation of Hydra in a more popular language? Not sure if throwing money at the Hydra codebase will speed up compiles (apart from setting it up to use ccache). On Wed Jan 21 2015 at 4:57:15 PM stewart mackenzie wrote: > Dear all, > > A recent thread regarding contributors brought up a point about > throwing a stack of money at further devlopment and refinement of > Hydra. > > Wouldn't it be nice to: > - be able to do as they do in the OpenBSD world by living on master. > When things break the fix comes in quick. No hanging around for days. > Releases are a by product of the world of sw distribution on CDs and DVDs. > > - (most importantly) Create a distributed community wide Hydra that > disseminates binaries over something like named data networking. > > Might we create an indiegogo campaign? I know NixOS gets limelight on > sites likes hackernews, so I suspect the campaign could well be a > success. > > What is your opinion? > > Kind regards > Stewart > ___ > 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] environment.allowedLicenses ?
I just opened a PR for this: https://github.com/NixOS/nixpkgs/pull/5892 Please review calmly (I'm a nix-newbie) and tell me what to improve and what you think about it. I will add appropriate documentation in the PR + in the wiki if you guys like this. On 21-01-2015 21:35:49, Domen Kožar wrote: >Well, that function could be looking at license strings and allowing such >packages with very little code. Could be a NixOS module setting indeed. -- Mit freundlichen Grüßen, Kind regards, Matthias Beyer Proudly sent with mutt. Happily signed with gnupg. pgp1nSzE7vq1u.pgp Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] environment.allowedLicenses ?
Well, that function could be looking at license strings and allowing such packages with very little code. Could be a NixOS module setting indeed. On Wed, Jan 21, 2015 at 9:25 PM, Matthias Beyer wrote: > On 21-01-2015 21:21:04, Domen Kožar wrote: > >We have a way to do that already, but it's not > >documented:A https://github.com/NixOS/nixpkgs/issues/4389 > >If someone would document it, that would rock :-) > > Just found that in the code. > > I don't think this is actually the same. With this feature (which is > good, no question!) you can allow _single packages_. With my idea you > would be able to allow a set of packages by the predicate "has > licenses XYZ". > > I think both things are ... maybe not entirely orthogonal to each > other, but maybe a bit! > > -- > Mit freundlichen Grüßen, > Kind regards, > Matthias Beyer > > Proudly sent with mutt. > Happily signed with gnupg. > ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] environment.allowedLicenses ?
On 21-01-2015 21:21:04, Domen Kožar wrote: >We have a way to do that already, but it's not >documented:A https://github.com/NixOS/nixpkgs/issues/4389 >If someone would document it, that would rock :-) Just found that in the code. I don't think this is actually the same. With this feature (which is good, no question!) you can allow _single packages_. With my idea you would be able to allow a set of packages by the predicate "has licenses XYZ". I think both things are ... maybe not entirely orthogonal to each other, but maybe a bit! -- Mit freundlichen Grüßen, Kind regards, Matthias Beyer Proudly sent with mutt. Happily signed with gnupg. pgpVoc5mMdcjp.pgp Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] environment.allowedLicenses ?
We have a way to do that already, but it's not documented: https://github.com/NixOS/nixpkgs/issues/4389 If someone would document it, that would rock :-) On Wed, Jan 21, 2015 at 9:16 PM, Shea Levy wrote: > My only interest in this is ensuring that there’s a single switch to be > able to say “install whatever I ask for”, in general though this sounds > like a good idea. > > > On Jan 21, 2015, at 8:15 PM, Matthias Beyer > wrote: > > > > On 21-01-2015 21:08:14, Jascha Geerds wrote: > >> Hi, > >> > >> On Wed, Jan 21, 2015, at 20:56, Matthias Beyer wrote: > >>> Is this possible with Nix(OS)? If yes, would you guys like such a > >>> feature? > >>> If yes,... maybe I can implement it (with enough guidance, though)... > >> > >> Yes, I think this should be possible in Nix & NixOS. Pretty good idea! > > > > I'd like to hear some more opinions on that and if it is a feature you > > guys want, I'd happily implement this in my semester break which > > starts in about three and a half weeks! > > > > I guess I should be able to get it working in my two weeks of semester > > break, but I guess I would need some guidance, as already said! > > > > -- > > Mit freundlichen Grüßen, > > Kind regards, > > Matthias Beyer > > > > Proudly sent with mutt. > > Happily signed with gnupg. > > ___ > > 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
Re: [Nix-dev] environment.allowedLicenses ?
My only interest in this is ensuring that there’s a single switch to be able to say “install whatever I ask for”, in general though this sounds like a good idea. > On Jan 21, 2015, at 8:15 PM, Matthias Beyer wrote: > > On 21-01-2015 21:08:14, Jascha Geerds wrote: >> Hi, >> >> On Wed, Jan 21, 2015, at 20:56, Matthias Beyer wrote: >>> Is this possible with Nix(OS)? If yes, would you guys like such a >>> feature? >>> If yes,... maybe I can implement it (with enough guidance, though)... >> >> Yes, I think this should be possible in Nix & NixOS. Pretty good idea! > > I'd like to hear some more opinions on that and if it is a feature you > guys want, I'd happily implement this in my semester break which > starts in about three and a half weeks! > > I guess I should be able to get it working in my two weeks of semester > break, but I guess I would need some guidance, as already said! > > -- > Mit freundlichen Grüßen, > Kind regards, > Matthias Beyer > > Proudly sent with mutt. > Happily signed with gnupg. > ___ > 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] environment.allowedLicenses ?
On 21-01-2015 21:08:14, Jascha Geerds wrote: > Hi, > > On Wed, Jan 21, 2015, at 20:56, Matthias Beyer wrote: > > Is this possible with Nix(OS)? If yes, would you guys like such a > > feature? > > If yes,... maybe I can implement it (with enough guidance, though)... > > Yes, I think this should be possible in Nix & NixOS. Pretty good idea! I'd like to hear some more opinions on that and if it is a feature you guys want, I'd happily implement this in my semester break which starts in about three and a half weeks! I guess I should be able to get it working in my two weeks of semester break, but I guess I would need some guidance, as already said! -- Mit freundlichen Grüßen, Kind regards, Matthias Beyer Proudly sent with mutt. Happily signed with gnupg. pgpZg41C_nB3T.pgp Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] environment.allowedLicenses ?
Hi, On Wed, Jan 21, 2015, at 20:56, Matthias Beyer wrote: > Is this possible with Nix(OS)? If yes, would you guys like such a > feature? > If yes,... maybe I can implement it (with enough guidance, though)... Yes, I think this should be possible in Nix & NixOS. Pretty good idea! -- Jascha Geerds j...@ekby.de ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] environment.allowedLicenses ?
Hi, today I heard that in Gentoo one has the ability to specify licenses which are okay for the system and licenses which are "blacklisted" and packages with that licenses shouldn't be installed. Despite this is true for Gentoo or not, this would be a really cool feature for NixOS and I think a lot of people (a lot of GNU people, actually) would be attracted by this feature! Is this possible with Nix(OS)? If yes, would you guys like such a feature? If yes,... maybe I can implement it (with enough guidance, though)... -- Mit freundlichen Grüßen, Kind regards, Matthias Beyer Proudly sent with mutt. Happily signed with gnupg. pgpKCrB4Rc0S0.pgp Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Funding Hydra Development
Dear all, A recent thread regarding contributors brought up a point about throwing a stack of money at further devlopment and refinement of Hydra. Wouldn't it be nice to: - be able to do as they do in the OpenBSD world by living on master. When things break the fix comes in quick. No hanging around for days. Releases are a by product of the world of sw distribution on CDs and DVDs. - (most importantly) Create a distributed community wide Hydra that disseminates binaries over something like named data networking. Might we create an indiegogo campaign? I know NixOS gets limelight on sites likes hackernews, so I suspect the campaign could well be a success. What is your opinion? Kind regards Stewart ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Ghc-mod and the new cabal-1.22
Also, it seems that ghc-mod in emacs got distinctively slower (it uses now seconds to update the buffer after saving). Could this be connected to the change? (I'll ask later to the ghc-mod guys if they know about this problem, I'd just like to know if this happened to anyone before). 2015-01-21 15:53 GMT+01:00 Carlo Nucera : > Wow, I didn't know it was a possibility, thanks! In that way, > however, I lose the possibility to do `cabal repl` or `cabal build` > because of > >> cabal repl > cabal: You need to re-run the 'configure' command. The version of > Cabal being used has changed (was Cabal-1.18.1.5, now Cabal-1.22.0.0). > > I tried: >> cabal repl --cabal-lib-version=1.18.1.5 > cabal: unrecognized 'repl' option `--cabal-lib-version=1.18.1.5' > > Is there a way to fix that, too? > > Best regards > Carlo > > 2015-01-20 16:59 GMT+01:00 Peter Simons : >> Hi Carlo, >> >> > It seems that ghc-mod can work with cabal-1.22 only if we have >> > ghc-7.10. >> > >> > https://github.com/kazu-yamamoto/ghc-mod/issues/417 >> > https://github.com/kazu-yamamoto/ghc-mod/issues/429 >> > >> > So I decided to lookup for possible solution. >> >> how about "cabal configure --cabal-lib-version=1.18.1.5"? That should >> work fine with GHC 7.8.4. >> >> Best regards, >> Peter >> >> ___ >> 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] Ghc-mod and the new cabal-1.22
Wow, I didn't know it was a possibility, thanks! In that way, however, I lose the possibility to do `cabal repl` or `cabal build` because of > cabal repl cabal: You need to re-run the 'configure' command. The version of Cabal being used has changed (was Cabal-1.18.1.5, now Cabal-1.22.0.0). I tried: > cabal repl --cabal-lib-version=1.18.1.5 cabal: unrecognized 'repl' option `--cabal-lib-version=1.18.1.5' Is there a way to fix that, too? Best regards Carlo 2015-01-20 16:59 GMT+01:00 Peter Simons : > Hi Carlo, > > > It seems that ghc-mod can work with cabal-1.22 only if we have > > ghc-7.10. > > > > https://github.com/kazu-yamamoto/ghc-mod/issues/417 > > https://github.com/kazu-yamamoto/ghc-mod/issues/429 > > > > So I decided to lookup for possible solution. > > how about "cabal configure --cabal-lib-version=1.18.1.5"? That should > work fine with GHC 7.8.4. > > Best regards, > Peter > > ___ > 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] parallel make (was: Again: Why don't these people havecommit access)
On 01/21/2015 01:17 AM, Marc Weber wrote: I think we have a documentation issue. There should be flag such as: parallelBuildingPossible = "yes/sometimes/no"; Yeah, well, I personally leave ``enableParallelBuilding = false;`` if I find it could fail. We could just e.g. have a more aggressive option that would use parallel make unless ``enableParallelBuilding = false;``. Vladimir 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
