Re: [Nix-dev] Let's merge 'stdenv-updates-gcc47' into 'stdenv-updates'
Hi Eelco, Well, GCC updates tend to break many packages, so this will delay a stdenv-updates merge even further. I would prefer merging stdenv-updates into master first (to get the latest Glibc, and some other stuff) and do GCC 4.7 after that. could we build the stdenv-updates-gcc47 branch to get some empirical data about the amount of packages that gcc 4.7.x would break? Maybe it's not nearly as bad as you fear? If it turns out that gcc 4.7.x causes lots of trouble, then we should defer that update, of course. I just don't expect that to be an issue, because I've been using the stdenv-updates-gcc47 branch locally on my machine for a while, and it works fine here. Others have reported the same finding. Take care, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Bundling nix-expressions with source code
Hi,
I would like to bundle nix-expressions with some of my self-developed
programs, and just let nixpkgs (or some custom-nixpkgs) use the
nix-expression from the source when building the program. Is this a wise
thing to do? Is it even possible?
A pseudo-example:
nixpkgs:
...
myprog_src = fetchgit { ... };
myprog = callPackage ${myprog_src}/default.nix { };
...
default.nix:
{ stdenv, foo, bar }:
stdenv.mkDerivation = {
src = ./;
buildInputs = [ foo bar ];
}
Obviously, the above example does not work. But can something similar,
that actually works, be written in nix? Or must one always separate the
package definition (nix mkDerivation expression) and the source?
Best regards,
Rickard Nilsson
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Bundling nix-expressions with source code
Excerpts from Rickard Nilsson's message of Tue Jan 22 13:05:09 +0100 2013:
I would like to bundle nix-expressions with some of my self-developed
programs, and just let nixpkgs (or some custom-nixpkgs) use the
nix-expression from the source when building the program. Is this a wise
thing to do? Is it even possible?
Why not?
You can always build using external files like this:
let pkgs = import /etc/nixos/nixpkgs {};
in {
pkgs.mkDerivation {
./your-source-whatsoever
}
}
The only issue if you have multiple packages depending on each other.
Usually whatever works is good :)
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Bundling nix-expressions with source code
Hi,
On 22/01/13 13:05, Rickard Nilsson wrote:
I would like to bundle nix-expressions with some of my self-developed
programs, and just let nixpkgs (or some custom-nixpkgs) use the
nix-expression from the source when building the program. Is this a wise
thing to do? Is it even possible?
It's possible but unfortunately not a good idea. Doing this:
myprog_src = fetchgit { ... };
myprog = callPackage ${myprog_src}/default.nix { };
in Nixpkgs means that an operation like nix-env -qa '*' will need to build
myprog_src first, which won't work because query operations open the Nix store
in read-only mode.
OTOH, if you just want to use Nixpkgs inside another project, like Marc said,
you can just do something like:
with import nixpkgs {};
stdenv.mkDerivation {
name = my-pkg;
src = ./.;
buildInputs = [ qt4 ... ];
};
Obviously, the above example does not work.
It actually does work in some cases, e.g. nix-build -A myprog should work.
--
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] Systemd branch merged
Hi Eelco, thank you very much for all the effort you've put into migrating NixOS to systemd. It is very much appreciated. Take care, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] svn-revision empty / nixos channel as branch?
revisions are back: /nix/var/nix/profiles/per-user/root/channels/nixos/nixos/svn-revision nixos revision: 64ffca1 nixpkgs revision: 8eef699 Vladimír Čunát vcu...@gmail.com writes: On 01/21/2013 05:12 AM, Florian Friesdorf wrote: I'm using the file to maintain branches channel-nixos of nixos and nixpkgs, so I can develop new features based on a supposedly more stable base. Oh, I'm using parts of those scripts as well. I was thinking of parsing http://hydra.nixos.org/jobset/nixpkgs/trunk instead (which would be more bandwidth-efficient), but your solution was easier. Also a nice idea! Am I correct, that the channel would be trunk-combined? http://hydra.nixos.org/jobset/nixos/trunk-combined Now as the channel only consists of nix expressions, no Manifest files anymore, wouldn't it be sane to maintain it as a repository? One repo with nixos and nixpkgs as submodules? Or probably better: nixpkgs as submodule of nixos? It might be useful to be able to have one commit change both nixos and nixpkgs. Dependencies between the repos aren't too frequent, but still I think they should be seen somehow. nixpkgs is independent of nixos, nixos needs nixpkgs. % du -sh dev/nixos/nixos 17M dev/nixos/nixos % du -sh dev/nixos/nixpkgs 152Mdev/nixos/nixpkgs I think the size at least is not an argument for separate repositories. Having separate repositories, it would be great to register the revision of nixpkgs being used for nixos. Registering nixpkgs as a submodule for nixos would achieve exactly that. However, there would be quite some commits just for upgrading the submodule - I'm not sure how useful that is. On the other hand for hydra to publish what versions have been successfully built together is definitely useful, but she does that already. Having to download 3.5MB for every channel update, while I only miss the information what revisions to use, is as you say not bandwith efficient. The hydra channel could be a git repository with two submodules (nixpkgs, nixos) and hydra updates these in the master branch for every attempted combined build. For every successful combined build it moves the tested branch forward. -- Florian Friesdorf f...@chaoflow.net GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgp8MxfWWYYRD.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] Systemd branch merged
Peter Simons sim...@cryp.to writes: Hi Eelco, thank you very much for all the effort you've put into migrating NixOS to systemd. It is very much appreciated. I second that! And one less argument for a couple of friends for why to stick with archlinux :) -- Florian Friesdorf f...@chaoflow.net GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpGxe_ynE_hZ.pgp Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
