Re: [Nix-dev] Nix 1.2 released
Hi Eelco, great work! Eelco Dolstra writes: > * Nix no longer sets the immutable bit on files in the Nix store. Instead, > the recommended way to guard the Nix store against accidental modification > on Linux is to make it a read-only bind mount, like this: > > $ mount --bind /nix/store /nix/store > $ mount -o remount,ro,bind /nix/store > > Nix will automatically make /nix/store writable as needed (using a private > mount namespace) to allow modifications. Where would be the correct place to put these commands? > * Basic Nix expression evaluation profiling: setting the environment > variable > NIX_COUNT_CALLS to 1 will cause Nix to print how many times each primop or > function was executed. > > * New primops: concatLists, elem, elemAt and filter. The elem library function evaluates all list elements instead of returning "true" after finding a matching element. How does the builtin elem function behave? regards florian -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgp4kOQno8V2Q.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] Nix 1.2 released
Eelco Dolstra writes: > Hi, > > On 12/12/12 17:15, Shea Levy wrote: > >>>> The elem library function evaluates all list elements instead of >>>> returning "true" after finding a matching element. >>> Sure about that? This seems lazy enough: >>> >>>elem = >>> builtins.elem or >>> (x: list: fold (a: bs: x == a || bs) false list); >>> >> Shouldn't the bs come first? i.e. (a: bs: bs || x == a)? > > Not if you want to check from left to right. Sorry, but I'm not getting it yet. What I understand: list = [0, 0, 1, 2, 3]; x = 1; elem x list -> a: 3, x == a: false, bs: false -> a: 2, x == a: false; bs: false -> a: 1, x == a: true; bs: false -> a: 0, x == a: false; bs: true -> a: 0, x == a: false; bs: true Probably missing something very basic. For completeness sake, fold from lib/lists: fold = if builtins ? elemAt then op: nul: list: let len = length list; fold' = n: if n == len then nul else op (builtins.elemAt list n) (fold' (add n 1)); in fold' 0 else op: nul: let fold' = list: if list == [] then nul else op (head list) (fold' (tail list)); in fold'; The following would not evaluate all, I'd currently claim: elem' = x: list: if list == [] then false else head list == x || elem' x (tail list); -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgp8iF8aNwDVe.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] Nix 1.2 released
Andres Loeh writes: > Why don't you just try it? > > $ echo 'let lib = import ; in lib.elem 1 > [1 2 (throw "boo")]' | nix-instantiate --eval-only - > true > $ echo 'let lib = import ; in lib.elem 2 > [1 2 (throw "boo")]' | nix-instantiate --eval-only - > true > $ echo 'let lib = import ; in lib.elem 3 > [1 2 (throw "boo")]' | nix-instantiate --eval-only - > error: user-thrown exception: boo > > Seems lazy to me. Thanks Andres and Shea for the explanations. At this point I definitely get that elem is lazy. I'm a bit confused about the direction fold(right) is working, but will play with it a bit before asking further questions. thanks again! -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgp2uPlrfbVpz.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] python rework
Hi, over the last year we were on and off working on python pureness and general improvements. This work (the python-merge[1] branch) has been merged now! A special thank you to Cillian de Roiste, Rok Garbas, Joachim Schiele, Peter Simons, Shea Levy, and everybody who helped making this possible! For more information please check the pull request[2]. In addition to python-merge[1] we used a branch with information for hydra not meant to enter master. It is now available as python-backup [3] and will disappear once nothing unmerged/useful is left in it. The python branch[4] is continued to be build by hydra[5]. In contrast to the old one, it will not contain any commits not meant to end up in master. I cleaned it up and it is now based on the current nixos channel[6]. If you have branches based on it, rebasing onto python-merge[1] or master should be easy. Next on the agenda is: - how are pth files processed, i.e. how and where do python wrappers find their modules - distribute instead of setuptools - enable more tests - nixos test modules to install subsets of python packages and run tests with multiple modules installed Please let us know what you think, especially if things don't work anymore for you! florian [1] https://github.com/chaoflow/nixpkgs/tree/python-merge [2] https://github.com/NixOS/nixpkgs/pull/206 [3] https://github.com/chaoflow/nixpkgs/tree/python-backup [4] https://github.com/chaoflow/nixpkgs/tree/python [5] http://hydra.nixos.org/jobset/nixpkgs/python-rework [6] https://github.com/chaoflow/nixpkgs/tree/channel-nixos -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpgHaXN6n1la.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] python26 fails to build
Hi, in the python branch I made a slight change to python2.6 about man page naming, turns out python2.6 can't be build, probably for a while / ever? http://hydra.nixos.org/build/3565721 It looks for "/usr/include/netinet/in.h" and I don't see why that should have ever succeeded, except hydra having used an impure environment for the last successful build (http://hydra.nixos.org/build/3372587). Does somebody see what I'm missing? regards florian -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpBEsmDOaKfU.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] nix-env terminal
Lluís Batlle i Rossell writes: > nixpkgs uses a modified 'gnu make', that outputs some garbled code annoying > also > in xterm (it duplicates the last character of some command lines). > > The purpose of that is for the hydra build farm to get a nice 'tree' from a > build log, like here: > http://hydra.nixos.org/build/2494797/log > (..) From hydra: + unpacking sources patching sources + configuring + building + installing + post-installation fixup Couldn't we scan for specific lines, make them even more specific by prepending "phase: " or "PHASE: " and fold everything in between? Why do we need a patch to 'gnu make' to achieve folding? -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpCQherBnB0p.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] localizing firefox
Sergey Mironov writes: > Hello! I'm working on a mom-friendly NixOS :) Great, me too. I'd like to get as much application configuration out of the user home and in form of defaults set via configuration.nix. Might be a stupid idea. How far are you? Do you have already some configuration to share? > Does anybody have an experience of localizing Firefox's (Nightly's) > UI? Maybe local *nix patches or howto links? Sorry, no. -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpSoSspzVf6E.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] bsd-games-2.17: monop
Christopher Howard writes: > On my system, the bsd-games-2.17 package installed an essential data > file for the monop game to ~/.nix-profile/share/games/monop-cards.pck. > However, the monop game dies trying to get this file from > /usr/share/games/monop-cards.pck. Is this an issue I need to drop in the > bug tracker, or is it something I have done wrong? I fixed this (https://github.com/NixOS/nixpkgs/issues/251) and also set the varlibdir to ".". Games should therefore create there score file in the directory they are started from. For beret we solved it the same way and it feels most flexible. Open for better ideas. thx for reporting! -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpQiqgGAmHL0.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] reproducable systems at a (much) later point / archive.org
Hi, nix is able to exactly reproduce a build, given: - a set of expressions (described by a git repository and a git revision) - that all sources are available - the build env is pure (including the hardware) Scenario 1: Backup -- Currently, to be sure that my system with all profiles' generations is properly backed up, I need to backup the complete store. It would be great if the store and the all profiles' generations could be restored From less. I imagine a list of packages per profile generation and the git revision of expressions being used to build each package. Given we would solve that, we still have the problem, that sources disappear like "intellinuxwireless.org" as Mathijs Kwik recently experienced[1]. He proposes that nix falls back to a "last-resort mirror". I like that idea. Scenario 2: Showing grand children how software looked in the old days -- It would be great to know that given there is electricity and given there is something that can emulate nowadays hardware and given there is something like the internet, that I always will be able to install whatever I can install now. The only problem I currently see with that are again the "dead sources". Wouldn't it be for that, nix would be the perfect tool to archive software. Solution Given that nix would support a "last-resort mirror" and given we could convince some instution (e.g. archive.org) to provide such a mirror, the world would be always able to exactly reproduce software installations and we could show our / somebody's grandchildren how we kept ourselves entertained. Thoughts? regards florian [1] http://permalink.gmane.org/gmane.linux.distributions.nixos/10045 -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpLtz04ed5zW.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] git and ERROR: ld.so: object '/lib/liblm.so' from LD_PRELOA
% git push ERROR: ld.so: object '/lib/liblm.so' from LD_PRELOAD cannot be preloaded: ignored. git from recent channel. Known issue? Thoughts? -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpb33T8vOhTw.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] python26 fails to build
Florian Friesdorf writes: > Hi, > > in the python branch I made a slight change to python2.6 about man page > naming, turns out python2.6 can't be build, probably for a while / ever? > > http://hydra.nixos.org/build/3565721 > > It looks for "/usr/include/netinet/in.h" and I don't see why that should > have ever succeeded, except hydra having used an impure environment for > the last successful build (http://hydra.nixos.org/build/3372587). I still do not understand how the python 2.6 could have been successfully built except if the build environment was impure. For systems with stdenv.gcc.libc I fixed the problem with: https://github.com/NixOS/nixpkgs/commit/a37cabdbb7ad9adaf9f6da226e6ed2ec74813961 For other systems I don't know what to do. regards florian -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpvUkQgaSDml.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] reproducable systems at a (much) later point / archive.org
Bjørn Forsman writes: > On 9 January 2013 07:38, Florian Friesdorf wrote: > [...] >> Thoughts? > > I really like it. I think supporting additional source mirrors is a > must-have feature :-) > > I have a long term plan to use NixOS for all my systems: desktop, > server and embedded. Same here :) > For embedded it is especially important to be > able to rebuild the exact same system, maybe years later. This > requires a local copy of all sources and a completely offline build. > > Here is my idea for nix[1]: > > * have a mirror on nixos.org where all sources hydra downloads are > put. (Whether this mirror is checked before or after the upstream URL > is irrelevant to me.) hydra already does that. All fetched sources are put into the store. They are later removed by garbage collection. This can be configured. However, we (currently) do not have the disk space to pull this off. > * add a config option for users to provide an URL for their own > private mirror. If emtpy, nothing happens. If non-empty, nix tries > this mirror first (to speed up build). The mirror option should handle > file:// URLs as well as ftp://, http:// etc. There is NIX_OTHER_STORES (see e.g. man nix-env). If nix finds a source in other stores it will copy it from there. > * a config option to make nix error out if the private mirror doesn't > contain all sources needed for a build. Or, by any means, check that > you have a mirror of all sources needed for a build. I think this is the same as saying "please realise all fixed output derivations" (see Michael Raskin on "going offline") > * a config option that, if non-empty, is an URL for nix to store all > sources it downloads. This could be set to the private mirror URL so > that the mirror builds itself. The local store is doing that, (see man nix.conf the *-keep-* variable). The sources of a derivation are outputs of that derivation. But as they are not linked into profiles they would normally get garbage collected. -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpT24Z5q4GIq.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] bsd-games-2.17: monop
Lluís Batlle i Rossell writes: > On Tue, Jan 08, 2013 at 11:02:17PM -0900, Christopher Howard wrote: >> On 01/08/2013 10:53 PM, Christopher Howard wrote: >> > >> > In this particular case, I think it would be wiser to put variable data >> > into $out/var/games (presuming there is no technical reason this can be >> > done). The bsd-games configuration commentary states: >> > >> >> Then again... I only started using Nix 2 days ago, and I am not clear on >> the ramifications of picking $out/var/games. Presumably that would be >> that each change in the profile would clear the scores, which is not >> good, or adjusting the scores would "damage" the state of the profile, >> which does not sound good. >> >> Perhaps just sticking with /var/games would be best. > > The /nix/store is not writeable. I'm also for /var/games. For completeness: on IRC we came to the conclusion that somewhere in $HOME/.local would be best. Sharing score files could be achieved by symlinking them. However, I fail to tell bsd-games to lookup $HOME during runtime and lack the time to further investigate at the moment. It would be easier to use a fixed path (without env var lookup), but we should use one normal users on non-nixos systems have write access to. -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpJYN7di4D4L.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] Providing more explicit nix installation instructions
Hi Ellis, Ellis Whitehead writes: > (..) > Sometimes things have worked out, sometimes they haven't. Usually, > the documentation lacks a bit of explicit (sometimes vital) detail. > Since I'll probably go through this processes occasionally in the > future, I'd be willing to add my findings to the wiki or the > documentation, if this would be of interest? I think this would be great! > Perhaps to start with: I wanted to install it on a Ubuntu 12.10 system > from a user account, and noticed something weird: > > # Try to install the .deb > $ sudo dpkg -i ~/Downloads/nix_1.3-1_amd64.deb > # There were missing dependencies, so install them as follows: > $ sudo apt-get update > $ sudo apt-get install -f > > # Now this is the problem: > $ sudo nix-channel --add http://nixos.org/channels/nixpkgs-unstable > > That created the file $HOME/.nix-channels in my USER home, but with > owner root. Obviously not the correct behavior. The following `sudo > nix-channel --update` failed (sorry, don't have the error message > anymore). Any suggestions for a better way to do this? sudo -H (see man sudo) > To get around the problem, I did something like the following: > $ sudo rm ~/.nix-channels > $ source /etc/profile.d/nix.sh > > The last command created ~/.nix-channels with the proper ownership and > contents. I suppose it knew which channel to put in .nix-channels > because of the first invocation of `nix-channel -add`? Should I have > sourced nix.sh before calling `sudo nix-channel` the first time? > > Anyhow, after that, the following command *was* successful, and I > could subsequently install software. > $ sudo nix-channel --update For a discussion about that see: http://www.mail-archive.com/nix-dev@lists.science.uu.nl/msg07638.html regards florian -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpTZs8sr2KY_.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] pull request with couple of python fixes ready
Hi, a pull request with a couple of python fixes (see description) is ready to be merged: https://github.com/NixOS/nixpkgs/pull/258 It diffs nicely against the latest merge from master: % git clone git://github.com/NixOS/nixpkgs % cd nixpkgs % git remote add chaoflow git://github.com/chaoflow/nixpkgs % git co -bt python chaoflow/python % git cherry -v d3e54e0 ... % git diff d3e54e0.. ... Please, those interested in python, take a look and either feedback/merge. thx -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpoVX443bZwG.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] chromiumDev logs missing from hydra
Hi, I wanted to look at broken chromiumDev build: http://hydra.nixos.org/job/nixpkgs/trunk/chromiumDev but its logs are not available: http://hydra.nixos.org/build/3756070/nixlog/1/raw http://hydra.nixos.org/build/3759653/nixlog/1/raw How can that happen? regards florian -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpC08SW2bMpM.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] SSP (-fstack-protector-all) in nixos?
Hi, current chromiumBeta fails to compile with error[1]: out/Release/obj.host/libvpx_obj_int_extract/third_party/libvpx/source/libvpx/build/make/obj_int_extract.o: In function `parse_elf': obj_int_extract.c:(.text.parse_elf+0x1f): undefined reference to `__stack_chk_guard' obj_int_extract.c:(.text.parse_elf+0x31c): undefined reference to `__stack_chk_guard' As far as I understand that is related to the stack smashing protection. I found some IRC discussion and talk about disabling that. In general it sounds like something I'd want on my system and I'd work for to get. What is needed to get SSP in nixos? How can we get chromium to build? regards florian [1] http://hydra.nixos.org/build/3806642/nixlog/1/raw -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpSQxhXQzNeh.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] GNU Guix 0.1 released (alpha)
Ludovic Courtès writes: > ;; Announcement. -*- scheme -*- > > (define guix > (package > (name "guix") > (version "0.1") ; first alpha release > (source > (origin > (method url-fetch) > (uri "ftp://alpha.gnu.org/gnu/guix/guix-0.1.tar.gz";) > (signature "ftp://alpha.gnu.org/gnu/guix/guix-0.1.tar.gz.sig";) > (sha256 > "350286bcf37a4035244cdddfe7bd62e79bcd08db0ed35b48e1444302dfc52005"))) > (license gpl3+) > (home-page "http://www.gnu.org/software/guix/";) > (synopsis "Functional package management for GNU") > (description > "GNU Guix is a functional package manager and associated free > software distribution of the GNU system. > (..) > See the ROADMAP and TODO files for future directions. Building the > distribution is a cooperative effort, and you are invited to join!"))) I like the ROADMAP/TODO and could imagine joining the effort. What are your thoughts on generating nix expressions from guix expressions for the purpose of package definition? -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpRSEMBCMuQb.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] GNU Guix 0.1 released (alpha)
Ludovic Courtès writes: > Florian Friesdorf skribis: >> What are your thoughts on generating nix expressions from guix >> expressions for the purpose of package definition? > > Do you mean the opposite–generating Guix expressions from Nix? I actually meant guix -> nix, as guix being within a full language, I had gut feeling this direction might be preferable, see also below. I'd rather maintain packages in one (E)DSL, than two. > If so, there’s the guix-import program, which works like this: > > guix-import /path/to/nixpkgs attribute > > It spits out a basic Guix package definition. By “basic”, I mean that > only trivial things are converted; Bash snippets added in > ‘configurePhase’, ‘preCheck’, etc. are just ignored. I don't see us writing bash -> guix tranformations... Ludovic Courtès writes: > A nice thing is that Scheme can be used both on the “host” side (as a > replacement of the Nix language), and on the build side (a nice > replacement of Bash...). > > Philosophically, I’m also interested in making a free software, and a > “GNU” distro. +1 > Marc Weber skribis: >> - in which way you're going to utilize the new "power" of scheme first >> applying to what problems? > > On the build side, it nicely replaces Bash, and also Coreutils, > Findutils, sed, and cURL. :-) Do you have ideas how these replacements could be used if generating nix expressions from guix expressions? > On the host side, it facilitates the implementation of new tools. For > instance, listing the available packages, searching them, using l10n’d > package descriptions, etc. is easy and fast. The auto-updater that’s in > the works, based on Nixpkgs’s gnupdate, is going to be both easier to > implement and faster (no need to parse several MiBs of a low-level XML > representation!). sounds great! > Guix provides access to several levels of API: store RPCs, low-level > derivations, Scheme derivations, and high-level package descriptions. > That opens up a wide range of possibilities, I think. Again, this is > the typical advantage of using a single language. +1 > There’s also a clearer separation of concerns: for instance, > env. vars. are not abused as arguments to the ‘derivation’ primitive. > >> - how exactly you reuse existing "nix*" software. You should describe >> this. > > It reuses the daemon, and thus libstore, as described in ‘README’. I take that nix and guix nicely cooperatively use "/nix/store/" though it's rather unlikely that the two would actually create the same output. Would it be feasible to depend on nixpkgs from within guix packages? Would it be feasible to do it the other way round? >> - what would be the advantages of your system - eg will you keep the >> lazy feature? If you build 150 packages its not a big problem. > > Of course it’s lazy, it doesn’t try to build every package as soon as > you fire it. :-) > > More details can be found in the manual, ‘README’, and in my GHM talk > linked from the web site. > > Hope this clarifies things! Helped me a lot! thx! -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgp_A_EAloIwM.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] GNU Guix 0.1 released (alpha)
Florian Friesdorf writes: >> There’s also a clearer separation of concerns: for instance, >> env. vars. are not abused as arguments to the ‘derivation’ primitive. >> >>> - how exactly you reuse existing "nix*" software. You should describe >>> this. >> >> It reuses the daemon, and thus libstore, as described in ‘README’. > > I take that nix and guix nicely cooperatively use "/nix/store/" though > it's rather unlikely that the two would actually create the same output. > > Would it be feasible to depend on nixpkgs from within guix packages? > Would it be feasible to do it the other way round? It is possible to use nixpkgs within guix, see guix README. -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpctrU54wgKV.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] [NixOS/nixpkgs] 8f0ea2: pythonPackages: default to python's maintainers an...
Hi Peter, Peter Simons writes: > Hi Florian, > > > pythonPackages: default to python's maintainers and platforms > > I am happy to care for the Python interpreter, but I don't want to be > notified of build errors for every single Python package out there that > doesn't explicitly set 'meta.maintainers' (which is the majority). It > appears that this change has that effect, though. I'm sorry for that and corrected it. regards florian -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpAtag_rIAO2.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] "svn-revision" empty / nixos channel as branch?
Hi, so far "svn-revision" was giving the nixos and nixpkgs SHA forming the channel. With the latest update, this file is empty: % cat /nix/var/nix/profiles/per-user/root/channels-22-link/nixos/nixos/svn-revision 4042_e201da3-ff461b0 % cat /nix/var/nix/profiles/per-user/root/channels-23-link/nixos/nixos/svn-revision 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. 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? regards florian -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgp5EbQHqZKrz.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] [NixOS/nixpkgs] 8f0ea2: pythonPackages: default to python's maintainers an...
Eelco Dolstra writes: > Hi, > > On 20/01/13 16:35, Peter Simons wrote: > >> > pythonPackages: default to python's maintainers and platforms >> >> I am happy to care for the Python interpreter, but I don't want to be >> notified of build errors for every single Python package out there that >> doesn't explicitly set 'meta.maintainers' (which is the majority). It >> appears that this change has that effect, though. > > I'll add that setting meta.platforms globally is probably not a good idea > because it will just add a lot of broken packages to the Hydra jobset. You > shouldn't set meta.platforms for a package unless you expect the package to > build on those platforms or are willing to fix them if they don't. It's my intention to fix packages / explicityly set platforms for packages that can't be fixed. -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgplN0UrzKIi6.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] "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 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 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 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 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
Re: [Nix-dev] Providing more explicit nix installation instructions
Vladimír Čunát writes: >>> # Now this is the problem: >>> $ sudo nix-channel --add http://nixos.org/channels/nixpkgs-unstable >>> >>> That created the file $HOME/.nix-channels in my USER home, but with >>> owner root. Obviously not the correct behavior. The following `sudo >>> nix-channel --update` failed (sorry, don't have the error message >>> anymore). Any suggestions for a better way to do this? >> >> sudo -H (see man sudo) > > I believe nix-channel --add is supposed to be run *without* sudo anyway > (it only sets up ~/.nix* stuff AFAIK). If you add the channel as a user, it will be added to your home directory and you need to run `sudo nixos-rebuild ...`. If you add it as root with `sudo nix-channel ...` it's going to be added to your user's home and you need to run `sudo nixos-rebuild ...`, too. If you add it with `sudo -H nix-channel...`, it will be added to root's home and you need to run `sudo -H nixos-rebuild...`. I'm not sure about security implications, but it feels like one should do both with `-H`. -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpo2HkwOANl2.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] python interpreter: interactive editing
Shea Levy writes: > Hello, > > For interactive usage, you want to install pythonFull (nix-env -iA > nixpkgs.pythonFull). That has readline support etc. That, and you might want to take a look at some environments I use to see what's possible: https://github.com/chaoflow/skel/blob/master/.nixpkgs/config.nix We are in the process of documenting it. > On 01/30/2013 03:10 PM, Christopher Howard wrote: >> Hi. I used nix to install python-2.7.3 on an older Linux system using >> Nix. Overall, seems to work fine, except one quirk: the python >> interpreter doesn't allow interactive editing or history substitution >> (i.e., readline style). But the python-2.7.3 documents suggests it has >> this functionality. Does anyone know if this is something that is >> optionally compiled into Python, or does a setting have to be changed >> somewhere, or...? I tend to live in the interpreter of whatever >> language I am using, so it is an important issue to me. >> ___ >> 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 -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpN7dKJ_KIDG.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] Problems booting
Rommel Martinez writes: >1. Dear everyone, > >I fetched >http://nixos.org/releases/nixos/latest-iso-graphical-x86_64-linux, >which, at the time of download, pointed >to nixos-graphical-0.2pre4454_979117b-789154b-x86_64-linux.iso. I wanted to >install it from a USB flash drive, so I followed the methods described at >http://nixos.org/wiki/Installing_NixOS_from_a_USB_stick. > >However, none of them worked. With the second method (syslinux), I only >got a blinking cursor, then it went on to proceed to the next boot device. >With the first method, the following message appeared on the screen: The third method (unetbootin) usually works for me. Have you tried that? -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpS6nQm3y6EC.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] luatex
% luatex test.tex ... This is a summary of all `failed' messages: `luatex -ini -jobname=luatex -progname=luatex luatex.ini' failed warning: kpathsea: mktexfmt output `This is LuaTeX, Version beta-0.70.2-2012122207 (TeX Live 2012) (INITEX) restricted \write18 enabled. (/nix/store/pqv310f2sbp6xvip56z9iqgknh8s1snf-TeXLive-linkdir/texmf-dist/tex/pla in/config/luatex.ini ! I can't find file `luatexiniconfig.tex'. l.6 \input luatexiniconfig.tex Any ideas? -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpIxq0ZI1ug9.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] Suggest package to install
Bjørn Forsman writes: > sudo mkdir -p /var/lib/nixos Take care with `sudo` for more complex commands than `mkdir`, I developed a habit of nearly always using `sudo -H` if not `sudo -i`. Except if you know why you would need "plain" `sudo` you should consider aliasing sudo to `sudo -i`. -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgp2vLZbVsOSF.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] cyrus-sasl on OS X tries to install to /Library
Hi, cyrus-sasl 2.1.26 (in contrast to 2.1.25) builds successfully on OS X, but tries to install into system directories (/Library/Frameworks/SASL2.framework) http://hydra.nixos.org/build/4378938/nixlog/1 Any suggestions how to fix this? regards florian -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgp_yrlrfmLz2.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] chromium update
Hi aszlig, your chromium update script decided to switch Beta to -lite, and the URL for Dev is returning 404. I fail to understand what's going on, do you? regards florian -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpuv4nWzpm1P.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] chromium update
Florian Friesdorf writes: > Hi aszlig, > > your chromium update script decided to switch Beta to -lite, and the URL > for Dev is returning 404. > > I fail to understand what's going on, do you? and: building out/Release/obj.target/third_party/npapi/npapi.stamp TOUCH out/Release/obj.target/ppapi/ppapi_c.stamp TOUCH out/Release/obj.target/third_party/npapi/npapi.stamp building out/Release/obj.target/third_party/mesa/mesa_headers.stamp TOUCH out/Release/obj.target/third_party/mesa/mesa_headers.stamp make: *** No rule to make target `out/Release/obj.target/v8_base/v8/src/accessors.o', needed by `out/Release/obj.target/v8/tools/gyp/libv8_base.a'. Stop. make: *** Waiting for unfinished jobs builder for `/nix/store/3gjch0fzd4fx7c3svab7rpl5j2kc595j-chromium-26.0.1410.40.drv' failed with exit code 2 error: build of `/nix/store/3gjch0fzd4fx7c3svab7rpl5j2kc595j-chromium-26.0.1410.40.drv' failed -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgp9uwtvjeluy.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] wpa_supplicant on install image fails for me
Hi, % cp /mnt/etc/wpa_supplicant.conf /etc % wpa_supplicant -Dnl80211 -iwlp2s0 -c/etc/wpa_supplicant -d > wpa.debug.log wpa_supplicant on the installer disc fails to establish a connection, disassociating repeatedly with reason 3 (see attached log). The exact same config works on my normal system. Installer uses some 3.2 kernel, my system 3.7.10. Network controller: 02:00.0 Network controller: Intel Corporation Centrino Ultimate-N 6300 (rev 35) Subsystem: Intel Corporation Centrino Ultimate-N 6300 3x3 AGN Flags: bus master, fast devsel, latency 0, IRQ 43 Memory at f240 (64-bit, non-prefetchable) [size=8K] Capabilities: Kernel driver in use: iwlwifi Known issue? Is there a reason to keep the old 3.2 kernel for the installer? florian wpa.debug.log Description: Binary data -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpmkRZXct5Ss.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] cannot start worker (unexpected end-of-file)
Lluís Batlle i Rossell writes: > On Mon, Mar 25, 2013 at 01:29:26PM +0100, Eelco Dolstra wrote: >> Hi, >> >> On 18/03/13 22:51, Lluís Batlle i Rossell wrote: >> >> > The trouble happens because "nixos-rebuild boot" will use your nix 1.5 to >> > communicate with your nix 1.2 daemon. >> > >> > When I see there is a nix update, I usually prefer to use "nixos-rebuild >> > boot >> > --no-build-nix", so the store doesn't get updated to a new version. >> > >> > If the store gets updated to a new db version, and the following nixos >> > build >> > fails, you end up in your state: the next nixos-rebuild run won't >> > understand >> > the store. >> >> FWIW, nixos-rebuild tries hard to prevent this situation. It only uses the >> new >> Nix for evaluation, not for accessing the store; the old daemon is used for >> that. So the schema should not be upgraded. > > Right, but I remember in my case (and maybe others') it deadlocked, I stopped > the > daemon, and then 'tried' to rebuild nixos. :) I was in the same situation. Could upgrading nix be one action, where a new system generation with a new nix is created? On top of that you can then upgrade the system. Or the other way round as you suggested. Having nix and system upgrade in one action calls for trouble. -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgp8OC6mG0MLU.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] git-annex assistant
Hi Peter, I see you packaged git-annex and it's configure without assistent and/or webapp. I tried just enabling them, but it would need yesod and co. <1.2. These however seem not be packaged. Do you know more? Any idea what to do? thanks florian -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpbME1E2JLR5.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] git-annex assistant
Hi Peter, Peter Simons writes: > The following message is a courtesy copy of an article > that has been posted to gmane.linux.distributions.nixos as well. > > Hi Florian, > > > I see you packaged git-annex and it's configure without assistent > > and/or webapp. > > right, I disabled the web-related parts of the build a while after Yesod > 1.2 came out. I wanted that update because other packages (like hledger) > stopped working with Yesod 1.1, and packaging both Yesod 1.1 and 1.2 is > way too much effort. So I gave up git-annex assistant in order to go > forward. > > > Any idea what to do? > > I believe the only thing one can do is to e-mail Joey Hess and politely > ask him to update git-annex to Yesod 1.2. I've tried that, but it seems > like he hasn't had time to work on the issue so far. It looks like he meanwhile supports building with yesod-1.2 (b44c978). I know nothing about our haskell packaging. Could we easily include a git version of git-annex to help him debugging it further with yesod-1.2? At least for me that would make things easier than working with a manual checkout and setup. regards florian -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgp2C2MuhsLLM.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] [Nix-commits] [NixOS/nixos] f09da4: wip: trackpoint.nix
Accidentally pushed a branch, deleted it again and set up a remote tracking branch to prevent it in the future. Florian Friesdorf writes: > Branch: refs/heads/rebase/personal > Home: https://github.com/NixOS/nixos > Commit: f09da4030ae0595672cbe9215d767f403a1af285 > > https://github.com/NixOS/nixos/commit/f09da4030ae0595672cbe9215d767f403a1af285 > Author: Florian Friesdorf > Date: 2013-06-04 (Tue, 04 Jun 2013) > > Changed paths: > M modules/module-list.nix > A modules/tasks/trackpoint.nix > > Log Message: > --- > wip: trackpoint.nix > > > Commit: 325106af878446c78330cf144247295c58729fd9 > > https://github.com/NixOS/nixos/commit/325106af878446c78330cf144247295c58729fd9 > Author: Florian Friesdorf > Date: 2013-06-04 (Tue, 04 Jun 2013) > > Changed paths: > M modules/services/mail/postfix.nix > > Log Message: > --- > wip: postfix suid > > > Commit: 62eb9b10b3ee0c661cc72660e1598fcb44f0c330 > > https://github.com/NixOS/nixos/commit/62eb9b10b3ee0c661cc72660e1598fcb44f0c330 > Author: Florian Friesdorf > Date: 2013-06-12 (Wed, 12 Jun 2013) > > Changed paths: > M maintainers/scripts/ec2/create-ebs-amis.py > M maintainers/scripts/ec2/create-s3-amis.sh > M modules/installer/tools/nixos-rebuild.sh > M modules/services/networking/openvpn.nix > M modules/services/security/tor.nix > M modules/services/torrent/transmission.nix > M modules/system/boot/loader/grub/grub.nix > > Log Message: > --- > Merge branch 'channel-nixos' into rebase/personal > > > Commit: 388a9312a03f6abfa573742db77a076cd82444ea > > https://github.com/NixOS/nixos/commit/388a9312a03f6abfa573742db77a076cd82444ea > Author: Florian Friesdorf > Date: 2013-06-18 (Tue, 18 Jun 2013) > > Changed paths: > M lib/test-driver/log2html.xsl > M lib/testing.nix > M modules/installer/cd-dvd/system-tarball.nix > M modules/services/misc/nix-daemon.nix > M modules/services/monitoring/zabbix-server.nix > M modules/services/system/nscd.nix > M modules/services/ttys/agetty.nix > M modules/services/web-servers/apache-httpd/zabbix.nix > M tests/installer.nix > > Log Message: > --- > Merge branch 'channel-nixos' into rebase/personal > > > Commit: c4e8629414b5245e0cbee03d916a71b34b1b9b44 > > https://github.com/NixOS/nixos/commit/c4e8629414b5245e0cbee03d916a71b34b1b9b44 > Author: Florian Friesdorf > Date: 2013-06-20 (Thu, 20 Jun 2013) > > Changed paths: > M doc/manual/options-to-docbook.xsl > M modules/programs/bash/profile.sh > M modules/services/x11/display-managers/lightdm.nix > M modules/services/x11/xserver.nix > > Log Message: > --- > Merge branch 'channel-nixos' into rebase/personal > > > Commit: 1915e8d39df42cc58c74bdf37990c5e941a92c1e > > https://github.com/NixOS/nixos/commit/1915e8d39df42cc58c74bdf37990c5e941a92c1e > Author: Florian Friesdorf > Date: 2013-06-27 (Thu, 27 Jun 2013) > > Changed paths: > M modules/module-list.nix > A modules/services/misc/cgminer.nix > M modules/services/misc/synergy.nix > M modules/services/web-servers/lighttpd/cgit.nix > M modules/services/web-servers/lighttpd/default.nix > M modules/services/web-servers/lighttpd/gitweb.nix > M modules/system/boot/systemd.nix > M modules/tasks/filesystems.nix > M tests/xfce.nix > > Log Message: > --- > Merge branch 'channel-nixos' into rebase/personal > > > Commit: bb0b894f1c0bd7001ec0b39ef4578ecee86f5d0f > > https://github.com/NixOS/nixos/commit/bb0b894f1c0bd7001ec0b39ef4578ecee86f5d0f > Author: Florian Friesdorf > Date: 2013-07-03 (Wed, 03 Jul 2013) > > Changed paths: > R modules/config/fonts.nix > A modules/config/fonts/corefonts.nix > A modules/config/fonts/fontconfig.nix > A modules/config/fonts/fontdir.nix > A modules/config/fonts/fonts.nix > A modules/config/fonts/ghostscript.nix > M modules/config/timezone.nix > A modules/installer/cd-dvd/channel.nix > M modules/installer/cd-dvd/installation-cd-base.nix > M modules/module-list.nix > A modules/profiles/demo.nix > M modules/programs/ssmtp.nix > A modules/services/databases/memcached.nix > A modules/services/databases/redis.nix > M modules/services/misc/disnix.nix > M modules/services/monitoring/dd-agent.nix > M modules/virtualisation/qemu-vm.nix > A modules/virtualisation/virtualbo
[Nix-dev] Zidanca sprint - work in progress
http://titanpad.com/nixos-sprint -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpxAh3bh8bNU.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] chrome
While Chrome is open I sometimes get a lot of these messages, sometimes like really a lot (about 10/s): Sep 24 13:32:04 eve display-manager-start[1737]: GetModeLine - scrn: 0 clock: 74080 Sep 24 13:32:04 eve display-manager-start[1737]: GetModeLine - hdsp: 1440 hbeg: 1464 hend: 1480 httl: 1600 Sep 24 13:32:04 eve display-manager-start[1737]: vdsp: 900 vbeg: 903 vend: 909 vttl: 926 flags: 10 Sep 24 13:32:04 eve display-manager-start[1737]: GetModeLine - scrn: 0 clock: 74080 Sep 24 13:32:04 eve display-manager-start[1737]: GetModeLine - hdsp: 1440 hbeg: 1464 hend: 1480 httl: 1600 Sep 24 13:32:04 eve display-manager-start[1737]: vdsp: 900 vbeg: 903 vend: 909 vttl: 926 flags: 10 Sep 24 13:32:07 eve display-manager-start[1737]: GetModeLine - scrn: 0 clock: 74080 Sep 24 13:32:07 eve display-manager-start[1737]: GetModeLine - hdsp: 1440 hbeg: 1464 hend: 1480 httl: 1600 Sep 24 13:32:07 eve display-manager-start[1737]: vdsp: 900 vbeg: 903 vend: 909 vttl: 926 flags: 10 Sep 24 13:32:07 eve display-manager-start[1737]: GetModeLine - scrn: 0 clock: 74080 Sep 24 13:32:07 eve display-manager-start[1737]: GetModeLine - hdsp: 1440 hbeg: 1464 hend: 1480 httl: 1600 It seems to be independent of whether my laptop (lenovo x201s) is docked and/or an external screen is connected. Any ideas? -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgp_6uuhOGBXt.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] chrome and many GetModeLine calls in log (was: Re: chrome)
sorry for the incomplete subject Florian Friesdorf writes: > While Chrome is open I sometimes get a lot of these messages, sometimes > like really a lot (about 10/s): > > Sep 24 13:32:04 eve display-manager-start[1737]: GetModeLine - scrn: 0 clock: > 74080 > Sep 24 13:32:04 eve display-manager-start[1737]: GetModeLine - hdsp: 1440 > hbeg: 1464 hend: 1480 httl: 1600 > Sep 24 13:32:04 eve display-manager-start[1737]: vdsp: 900 vbeg: 903 vend: > 909 vttl: 926 flags: 10 > Sep 24 13:32:04 eve display-manager-start[1737]: GetModeLine - scrn: 0 clock: > 74080 > Sep 24 13:32:04 eve display-manager-start[1737]: GetModeLine - hdsp: 1440 > hbeg: 1464 hend: 1480 httl: 1600 > Sep 24 13:32:04 eve display-manager-start[1737]: vdsp: 900 vbeg: 903 vend: > 909 vttl: 926 flags: 10 > Sep 24 13:32:07 eve display-manager-start[1737]: GetModeLine - scrn: 0 clock: > 74080 > Sep 24 13:32:07 eve display-manager-start[1737]: GetModeLine - hdsp: 1440 > hbeg: 1464 hend: 1480 httl: 1600 > Sep 24 13:32:07 eve display-manager-start[1737]: vdsp: 900 vbeg: 903 vend: > 909 vttl: 926 flags: 10 > Sep 24 13:32:07 eve display-manager-start[1737]: GetModeLine - scrn: 0 clock: > 74080 > Sep 24 13:32:07 eve display-manager-start[1737]: GetModeLine - hdsp: 1440 > hbeg: 1464 hend: 1480 httl: 1600 > > It seems to be independent of whether my laptop (lenovo x201s) is docked > and/or an external screen is connected. > > Any ideas? > > -- > Florian Friesdorf > GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 > Jabber/XMPP: f...@chaoflow.net > IRC: chaoflow on freenode,ircnet,blafasel,OFTC -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpuE_He9wDD2.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] Powertop NixOS
Hi Tom, nix-env -i powertop sudo powertop For quicker and in general more accurate help: nix-dev@lists.science.uu.nl Thomas Bereknyei writes: > Hi what is the current method of using powertop I would like to start using > it but I'm a little new to nixos. > > I came across your email on a forum posting regarding the kernel. > > Tom -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpRIqcF8HvYS.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] abcde misses cd-paranoia, libcdio 0.92 vs 0.82
libcdio 0.92 lacks cd-paranoia in contrast to 0.82, which is dearly missed by abcde. Does somebody know what's going on? % ls -l /nix/store/95p14wki597rfi40d7cafisppsj8m992-libcdio-0.92/bin total 256K -r-xr-xr-x 2 root root 44885 Jan 1 1970 cdda-player* -r-xr-xr-x 2 root root 25946 Jan 1 1970 cd-drive* -r-xr-xr-x 2 root root 53946 Jan 1 1970 cd-info* -r-xr-xr-x 2 root root 32707 Jan 1 1970 cd-read* -r-xr-xr-x 2 root root 34020 Jan 1 1970 iso-info* -r-xr-xr-x 2 root root 28609 Jan 1 1970 iso-read* -r-xr-xr-x 2 root root 32370 Jan 1 1970 mmc-tool* 1 % ls -l /nix/store/vsyxvqm2xw2ka1lixlrxs2kdqj76dgks-libcdio-0.82/bin total 292K -r-xr-xr-x 2 root root 44713 Jan 1 1970 cdda-player* -r-xr-xr-x 2 root root 25384 Jan 1 1970 cd-drive* -r-xr-xr-x 2 root root 53156 Jan 1 1970 cd-info* -r-xr-xr-x 2 root root 42766 Jan 1 1970 cd-paranoia* -r-xr-xr-x 2 root root 32590 Jan 1 1970 cd-read* -r-xr-xr-x 2 root root 28744 Jan 1 1970 iso-info* -r-xr-xr-x 2 root root 25450 Jan 1 1970 iso-read* -r-xr-xr-x 2 root root 32161 Jan 1 1970 mmc-tool* -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpXOzU2QFSzz.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] abcde misses cd-paranoia, libcdio 0.92 vs 0.82
workaround: https://github.com/NixOS/nixpkgs/commit/9fb8624b94c6db633ebc2baad5de634b5199c97f Florian Friesdorf writes: > libcdio 0.92 lacks cd-paranoia in contrast to 0.82, which is dearly > missed by abcde. Does somebody know what's going on? > > % ls -l /nix/store/95p14wki597rfi40d7cafisppsj8m992-libcdio-0.92/bin > total 256K > -r-xr-xr-x 2 root root 44885 Jan 1 1970 cdda-player* > -r-xr-xr-x 2 root root 25946 Jan 1 1970 cd-drive* > -r-xr-xr-x 2 root root 53946 Jan 1 1970 cd-info* > -r-xr-xr-x 2 root root 32707 Jan 1 1970 cd-read* > -r-xr-xr-x 2 root root 34020 Jan 1 1970 iso-info* > -r-xr-xr-x 2 root root 28609 Jan 1 1970 iso-read* > -r-xr-xr-x 2 root root 32370 Jan 1 1970 mmc-tool* > > 1 % ls -l /nix/store/vsyxvqm2xw2ka1lixlrxs2kdqj76dgks-libcdio-0.82/bin > total 292K > -r-xr-xr-x 2 root root 44713 Jan 1 1970 cdda-player* > -r-xr-xr-x 2 root root 25384 Jan 1 1970 cd-drive* > -r-xr-xr-x 2 root root 53156 Jan 1 1970 cd-info* > -r-xr-xr-x 2 root root 42766 Jan 1 1970 cd-paranoia* > -r-xr-xr-x 2 root root 32590 Jan 1 1970 cd-read* > -r-xr-xr-x 2 root root 28744 Jan 1 1970 iso-info* > -r-xr-xr-x 2 root root 25450 Jan 1 1970 iso-read* > -r-xr-xr-x 2 root root 32161 Jan 1 1970 mmc-tool* > > -- > Florian Friesdorf > GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 > Jabber/XMPP: f...@chaoflow.net > IRC: chaoflow on freenode,ircnet,blafasel,OFTC -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpbywU04tLBO.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] abcde flac: `metaflac': realloc(): invalid next size
% abcde -1 -o flac -a default,cue Grabbing entire CD - tracks: 01 02 03 04 05 06 07 08 09 10 11 abcde: attempting to resume from /home/cfl/abcde.81097d0b.. Tagging track 01 of 01: Just This Moment... *** Error in `metaflac': realloc(): invalid next size: 0x01226a80 *** -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpVAKVY6X68e.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] nixos tests variables and interactive testing
Hi, I'm writing nixos tests for python and fail to find documentation beyond: [6.6. NixOS Tests](http://nixos.org/nixos/manual/#ch-development) What nix variables are available within a testScript and how can I use them? How can I stop a test, get an interactive shell to investigate things and then continue? regards florian -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpXnTkoefJzj.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] nixos tests variables and interactive testing
Florian Friesdorf writes: > Hi, > > I'm writing nixos tests for python and fail to find documentation > beyond: > > [6.6. NixOS Tests](http://nixos.org/nixos/manual/#ch-development) > > What nix variables are available within a testScript and how can I use > them? I figured meanwhile that it is no different from any other nix expression - surprise! > How can I stop a test, get an interactive shell to investigate things > and then continue? This still bothers me. -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgp6TzYBZaRCK.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] nixos tests variables and interactive testing
Florian Friesdorf writes: > Florian Friesdorf writes: >> How can I stop a test, get an interactive shell to investigate things >> and then continue? > > This still bothers me. And if one reads the manually (carefully) it says so right there. -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpfShRF6CVBz.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] nixos tests variables and interactive testing
Florian Friesdorf writes: > Florian Friesdorf writes: >> Florian Friesdorf writes: >>> How can I stop a test, get an interactive shell to investigate things >>> and then continue? It is possible to get an interactive perl prompt. Really nice would be a real shell, with tab completion and things. I assume that something like that could be achieved using ssh. Are there best practices for this? -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgposE8soPHUG.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] Variable interpolation in strings read from files
Hi,
let
a = "Hello world";
in
${./script.pl};
and content of ./script.pl being:
print ${a};
It would be nice if there would be a way to interpolate variables in the
string read from ./script.pl, just like the content would be written
in-place.
For more context:
https://github.com/chaoflow/nixpkgs/blob/f90ad800b7cea03264137327f9f897938602371b/nixos/tests/python.nix#L23
https://github.com/chaoflow/nixpkgs/blob/f90ad800b7cea03264137327f9f897938602371b/nixos/tests/python/preamble.pl
and a workaround:
https://github.com/chaoflow/nixpkgs/blob/fdbf736ccc6e53a0454b2cd52858fc8082df8917/nixos/tests/python.nix#L23
https://github.com/chaoflow/nixpkgs/blob/fdbf736ccc6e53a0454b2cd52858fc8082df8917/nixos/tests/python/preamble.pl
regards
florian
--
Florian Friesdorf
GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083
Jabber/XMPP: f...@chaoflow.net
IRC: chaoflow on freenode,ircnet,blafasel,OFTC
pgpX3AZ0zYj1c.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] Variable interpolation in strings read from files
Upfront, I partly talked non-sense before, so I might have transported a wrong picture. Vladimír Čunát writes: > On 06/22/2014 01:11 PM, Florian Friesdorf wrote: >> It would be nice if there would be a way to interpolate variables in the >> string read from ./script.pl, just like the content would be written >> in-place. > > Usually one can use substituteAll; see qt4 for example. > > It uses a different syntax for what is replaced, but one typically does > need a different syntax if substituting in shell-like files. This is working using "import" and some nix boilerplate in the perl files. https://github.com/chaoflow/nixpkgs/blob/7482884953fcd8d3f29d84b864c53c46728d6910/nixos/tests/python.nix#L23 Now, I'd like to get rid of that nix boilerplate. It feels that a library function doing what substituteAll is doing would be great: testScriptPreamble = interpolate attrset (readFile ./python/preamble.pl); I'm happy to switch to whatever variable markup and also to write that function. Just don't want to go a direction that makes no sense. Any thoughts? -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpkVbJRbawxT.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] Variable interpolation in strings read from files
Vladimír Čunát writes:
> On 06/22/2014 02:55 PM, Florian Friesdorf wrote:
>> Any thoughts?
>
> I *did* mean using the library function substituteAll. (It's not only a
> bash function in stdenv's setup.) It uses practically the syntax you
> propose. See qt4 for example.
qt4 uses pkgs.substituteAll to read a source file, perform substitution
on it and write a target file. It returns the path to the target file.
This works and I get a file with variables substituted, e.g.:
/nix/store/x32hziqm127agl1ipr6sfs7p9j8zdvpm-preamble.pl
Now I try to read this file:
testScriptPreamble = { debug, full, pythonstr }:
let debug_ = if debug then "true" else "";
full_ = if full then "true" else "";
in readFile (pkgs.substituteAll { src = ./python/preamble.pl;
inherit debug_ full_ pythonstr; });
and get:
% nix-build python.nix -A virtualenvPython27Full
error: string `/nix/store/x32hziqm127agl1ipr6sfs7p9j8zdvpm-preamble.pl' cannot
refer to other paths, at /home/cfl/dev/nixos/nixpkgs/nixos/tests/python.nix:26:8
Current full experiment:
https://github.com/chaoflow/nixpkgs/blob/5f2341e96cd48c6d75ca9abf7447cc4b04f04611/nixos/tests/python.nix#L26
Is there a way to get this work with pkgs.substituteAll?
I'm thinking of something like:
testScriptPreamble = { debug, full, pythonstr }:
let attrs = {
debug_ = if debug then "true" else "";
full_ = if full then "true" else "";
inherit pythonstr;
};
in pkgs.lib.substitute attrs (readFile ./python/preamble.pl);
--
Florian Friesdorf
GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083
Jabber/XMPP: f...@chaoflow.net
IRC: chaoflow on freenode,ircnet,blafasel,OFTC
pgpaZWpxUqqtc.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] Variable interpolation in strings read from files
Vladimír Čunát writes: > On 06/22/2014 03:45 PM, Florian Friesdorf wrote: >> Now I try to read this file: > > Ah, sorry, I didn't notice that you used the result as a nix string. > > Switching back and forth between nix (strings) and derivations (files) > is better avoided. The readFile function is only meant for what you have > among the nix source expressions. One probably can do more with > "recursive nix". > > Personally, I would try to do all work from that substituteAll point in > derivations and not through nix strings (i.e. catenate by cat command). I've got a working solution: https://github.com/chaoflow/nixpkgs/blob/2efc8fe32239cccab0e1b89b3c0983a2857dd128/nixos/tests/python.nix#L23 Should I move replaceSubstring and interpolateAtAtVars to lib/strings.nix? Suggestions for better naming? -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpgCPZ4wOU6C.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] pytables, numexpr, and pandas
Hi Andreas and Mateusz,
great work!
Andreas Herrmann writes:
> On 15 June 2014 22:11, Mateusz Kowalczyk wrote:
>> On 06/15/2014 09:09 PM, Andreas Herrmann wrote:
>> > On 15 June 2014 02:28, Mateusz Kowalczyk
>> wrote:
>> >> On 06/14/2014 11:17 PM, Andreas Herrmann wrote:
>> > Okay, it runs on all python versions except pypy. Which is to be
>> expected.
>> > However, the pypy branch seems to be somewhat broken. The build failed at
>> > setuptools long before it reached my package.
Thx for reporting, I'm working on nixos python test suites and made a
note to investigate.
>> > I dug a little deeper and found that the problem was actually rooted in
>> the
>> > hdf5 package. pytables needs it to be built with zlib. I put that in, and
>> > also fixed the szip package. However, both could be called optional
>> > dependencies on hdf5. Do you know, how I can make pytables depend on hdf5
>> > with a certain set of parameters? Or are these things handled through
>> > comments and documentation?
>> >
>> > To be more explicit: say hdf5 has the parameters `{ stdenv, fetchurl,
>> zlib
>> > ? null, szip ? null }`. How can I make pytables depend on hdf5 in such a
>> > way, that it requires `zlib != null`, but doesn't care about `szip`?
>>
>> I can't say for sure but I'd imagine you'd simply override it as usual.
>> Say you have pytables at
>> development/python-modules/pytables.default.nix: your entry to
>> python-modules.nix could look like
>>
>> pytables = callPackage ../development/python-modules/pytables {
>> hdf5 = pkgs.hdf5.override { zlib = pkgs.zlib; };
>> };
The solution looks good to me. However, from a brief look it feels that
one would want the default hdf5 package to be built with szip and
zlib.
What do you think?
In that case you would keep the hdf5 expression as is (so people can
disable), you would not need the override here, and would pass szip and
zlib to hdf5 in all-packages.
Waiting for you comment and/or changes and would then merge.
florian
--
Florian Friesdorf
GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083
Jabber/XMPP: f...@chaoflow.net
IRC: chaoflow on freenode,ircnet,blafasel,OFTC
pgpd_DtDXR4cn.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] szip unfree? (was: Re: pytables, numexpr, and pandas)
Andreas Herrmann writes:
> Well, my reason for not including szip by default was it's license.
>
> Quoting the hdf5-group page [1]:
>
>> Licensing terms
>> The version of Szip distributed with HDF products is free for
>> non-commercial use, which may occur in two sets of circumstances:
>> Non-commercial users may use the Szip software integrated with HDF
>> products to both encode (compress) and decode (uncompress) data. This
>> applies to educational and research applications.
>> Commercial users may use the software to decode any data. Further, they
>> may use the software in internal activities that do not involve or result
>> in the development of an Szip-based software product.
>> Commercial licenses are available for commercial users who wish to
>> distribute an Szip-based software product or engage in commercial uses that
>> are not allowed above. For further licensing information or to view a copy
>> of the Szip copyright statement, see Commercial use terms and the copyright
>> and license notice pertaining to Szip in HDF products.
>
> So, it's a license that requires some thought to figure out if you're
> allowed to use it or not. I thought it would be better not to include it by
> default, so that no one breaks the license unknowingly.
>
> I don't know what the Nix policy generally is, when it comes to licenses.
> Basically, I'm returning the question: Is it okay to include this package
> by default, or not?
I think you were right in not including the support by default.
Further, szip might have to set meta.license = "unfree", so you need to
allow it eg. in ~/.nixpkgs/config.nix.
{
allowUnfree = true;
}
Opinions?
--
Florian Friesdorf
GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083
Jabber/XMPP: f...@chaoflow.net
IRC: chaoflow on freenode,ircnet,blafasel,OFTC
pgpxI6q07YycT.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] szip unfree? (was: Re: pytables, numexpr, and pandas)
szip unfree or not is an issue independent of your pull request. I
merged - thanks a lot!
Florian Friesdorf writes:
> Andreas Herrmann writes:
>> Well, my reason for not including szip by default was it's license.
>>
>> Quoting the hdf5-group page [1]:
>>
>>> Licensing terms
>>> The version of Szip distributed with HDF products is free for
>>> non-commercial use, which may occur in two sets of circumstances:
>>> Non-commercial users may use the Szip software integrated with HDF
>>> products to both encode (compress) and decode (uncompress) data. This
>>> applies to educational and research applications.
>>> Commercial users may use the software to decode any data. Further, they
>>> may use the software in internal activities that do not involve or result
>>> in the development of an Szip-based software product.
>>> Commercial licenses are available for commercial users who wish to
>>> distribute an Szip-based software product or engage in commercial uses that
>>> are not allowed above. For further licensing information or to view a copy
>>> of the Szip copyright statement, see Commercial use terms and the copyright
>>> and license notice pertaining to Szip in HDF products.
>>
>> So, it's a license that requires some thought to figure out if you're
>> allowed to use it or not. I thought it would be better not to include it by
>> default, so that no one breaks the license unknowingly.
>>
>> I don't know what the Nix policy generally is, when it comes to licenses.
>> Basically, I'm returning the question: Is it okay to include this package
>> by default, or not?
>
> I think you were right in not including the support by default.
>
> Further, szip might have to set meta.license = "unfree", so you need to
> allow it eg. in ~/.nixpkgs/config.nix.
>
> {
> allowUnfree = true;
> }
>
> Opinions?
>
> --
> Florian Friesdorf
> GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083
> Jabber/XMPP: f...@chaoflow.net
> IRC: chaoflow on freenode,ircnet,blafasel,OFTC
--
Florian Friesdorf
GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083
Jabber/XMPP: f...@chaoflow.net
IRC: chaoflow on freenode,ircnet,blafasel,OFTC
pgpv0Ih0Utqi5.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] nixlint or nixflakes?
Hi, I would like to see a nixlint/nixflakes to encourage/enforce best practices for nix expressions and work towards a unified style so I don't have to think for myself what looks nicer or what would be the correct way of doing things. Ideally github would signal whether a pull requests passes this check. What do you think? florian -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpb9pWBjOsbH.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] rebuild impact factor
Hi, it would be nice if github would show a "rebuild impact factor"? Opinions/thoughts on the whether and how? florian -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpyALJzokQzN.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] rebuild impact factor
Ludovic Courtès writes: > Florian Friesdorf skribis: > >> it would be nice if github would show a "rebuild impact factor"? > > In the old days, Nicolas Pierron wrote a script that attempted to > compute that factor, maintainers/scripts/rebuild-amount.sh. That would do it, but currently seems broken: % NIXPKGS=. ./maintainers/scripts/rebuild-amount.sh --git master..HEAD Please wait, this may take some minutes ... Number of package to rebuild: _tmp_rebuild-amount-AFxbZ4Gq_.vcs -> .: 0 -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpl3RIcxydfw.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] Variable interpolation in strings read from files
Hi Eelco, Vlada,
thank you for your feedback!
Eelco Dolstra writes:
> On 22/06/14 16:41, Florian Friesdorf wrote:
>
>>> Personally, I would try to do all work from that substituteAll point in
>>> derivations and not through nix strings (i.e. catenate by cat command).
>
> Right. Doing large string rewrites at evaluation time is a bad idea
> because it's slow.
I understand now that with pkgs.substiuteAll I would write a new file
which serves as an input to my expression and would only be updated if
the source file changed in contrast to do the substitution with every
evaluation.
Am I correct that my solution performs about as good as the in-place
testScripts for tests/installer.nix which us ${ } and that as Vlada said
this would be bad within pkgs.* but okish within nixos/tests?
Would caching of function values within nix be an option, so that
caching does not only happen via the store?
>> I've got a working solution:
>> https://github.com/chaoflow/nixpkgs/blob/2efc8fe32239cccab0e1b89b3c0983a2857dd128/nixos/tests/python.nix#L23
>>
>> Should I move replaceSubstring and interpolateAtAtVars to
>> lib/strings.nix?
>
> At first glance, these functions seem pretty slow to me (since they use
> splitString). So it's probably not a good idea to add them to the standard
> library (and I'd prefer removing splitString from there).
They are definitely slow in their current form.
Florian
--
Florian Friesdorf
GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083
Jabber/XMPP: f...@chaoflow.net
IRC: chaoflow on freenode,ircnet,blafasel,OFTC
pgpw179G8PqGF.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] nixos tests: include multiple tests from one nix file
Hi, I'd like soonish to push and include tests for python in master. Do you see problems with the way I am doing this? https://github.com/chaoflow/nixpkgs/commit/75e4ad8f2a81a0517105cc4e8592b74268ebb6d0 Apart from the hardcoded "import tests/python.nix", which I'm going to fix. https://github.com/chaoflow/nixpkgs/commit/75e4ad8f2a81a0517105cc4e8592b74268ebb6d0#diff-831e8d9748240fb23e6734fdc2a6d16eR24 florian -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgplTY_SBmG3J.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] nixos tests: include multiple tests from one nix file
Eelco Dolstra writes: > On 25/06/14 13:34, Florian Friesdorf wrote: >> I'd like soonish to push and include tests for python in master. Do you >> see problems with the way I am doing this? > > Are these actually NixOS tests? Seems to me that Python tests are more > something > to be done in Nixpkgs proper (or maybe in a separate jobset for Python tests). > We don't currently have a tests.* set in the Nixpkgs release.nix, but it would > be good to have one. They test the usage and interaction of python packages installed into a nix profile. Currently, they use the system profile and are therefore NixOS-specific, but could be fixed easily to use any profile. Further, it would be enough to have a profile and an empty directory to run the tests with, the nixos test isolation with qemu seems to be overkill. Does that qualify for a python-tests jobset within nixpkgs? Where to go from here? -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgp9wycPKMFw9.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] nixos tests: include multiple tests from one nix file
Florian Friesdorf writes: > Eelco Dolstra writes: >> On 25/06/14 13:34, Florian Friesdorf wrote: >>> I'd like soonish to push and include tests for python in master. Do you >>> see problems with the way I am doing this? >> >> Are these actually NixOS tests? Seems to me that Python tests are more >> something >> to be done in Nixpkgs proper (or maybe in a separate jobset for Python >> tests). >> We don't currently have a tests.* set in the Nixpkgs release.nix, but it >> would >> be good to have one. > > They test the usage and interaction of python packages installed into a > nix profile. > > Currently, they use the system profile and are therefore NixOS-specific, > but could be fixed easily to use any profile. > > Further, it would be enough to have a profile and an empty directory to > run the tests with, the nixos test isolation with qemu seems to be > overkill. It would be enough and even more comfortable if the test script would just be a (ba)sh script run with -e. I can imagine how to do this based on mkDerivation, but fail yet to see how to create something similar to a profile with the test dependencies installed. Currently, I have tests failing when run with packages from the system profile, but they succeed when reproduced with a "normal" profile. So it seems important how the profile is created. > Does that qualify for a python-tests jobset within nixpkgs? > Where to go from here? -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpWCwFIIzAAr.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] nix-build recurse into attributes
Hi, would it be sane for nix-build to have an option to recurse into attributes so you could for example build all nixos tests like: % nix-build -A tests --recurse nixos/release.nix florian -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpjlPtRYpWBF.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] nix-build recurse into attributes
Florian Friesdorf writes:
> Hi,
>
> would it be sane for nix-build to have an option to recurse into
> attributes so you could for example build all nixos tests like:
>
> % nix-build -A tests --recurse nixos/release.nix
Based on an idea by johnw, using the following snippet allows running
all tests with `-A all`, where are rv is what would be usually returned:
in rv // {
all = fold (name: acc: acc // (mapAttrs' (n: v: nameValuePair (name + "-" +
n) v)
(getAttr name rv)))
{}
(attrNames rv);
}
--
Florian Friesdorf
GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083
Jabber/XMPP: f...@chaoflow.net
IRC: chaoflow on freenode,ircnet,blafasel,OFTC
pgpVREZ86xqe4.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] determining run-time only dependencies from output, recursive nix?
Hi,
Background: python packages can be built to contain easily parsable
runtime dependency information (called requirements from now on).
I'm pondering the idea of a two-stage build:
1. base package with optional build time dependencies:
lxml' = callPackage ({ libxml2, libxslt }: self.build {
distname = "lxml";
version = "3.3.5";
md5 = "88c75f4c73fc8f59c9ebb17495044f2f";
buildInputs = [ libxml2 libxslt ];
}) {};
The base package contains METADATA with requirement information, which
can be directly mapped to an attribute path (taken from a different
package for the sake of simplicity):
% grep Requires
/nix/store/...-ipdb-0.7/lib/python2.7/site-packages/ipdb-0.7.dist-info/METADATA
Requires-Dist: ipython (>=0.10)
2. real package to be installed into profiles, pulling in its requirements
ipdb = buildRealPackage {
basePackage = ipdb'
}
Installing ipdb should result in ipdb' and ipython' to be installed into
the profile.
Do you see ways to achieve this?
Is recursive nix an option / needed?
regards
florian
--
Florian Friesdorf
GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083
Jabber/XMPP: f...@chaoflow.net
IRC: chaoflow on freenode,ircnet,blafasel,OFTC
pgpCbtTcC8tXB.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] Nix users going to EuroPython
Georges Dubus writes: > Hello there > > I know for a fact there's a non-empty intersection between Python and Nix > users, so I guess I won't be the only one going to the EuroPython. > > Domen will be giving a talk[1] which promises to be interesting. > > Is anyone interested in a Nix meetup there, or even a Nix/Python sprint on > the weekend ? +1 > [1] https://ep2014.europython.eu/en/schedule/sessions/37/ -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpH9Or0iZPq7.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] Zero Hydra Failures (ZHF) project
Rok Garbas writes:
> Quoting Paul Colomiets (2014-08-08 15:13:57)
>> On Fri, Aug 8, 2014 at 3:35 PM, Eelco Dolstra
>> wrote:
>> >
>> > Note the huge number of Haskell and Python packages.
>> >
>>
>> For Python many of them doesn't support that version of python.
>> Wouldn't it be nice to declare supported versions inside a package,
>> inside of moving package to various sets. I.e.:
>>
>> declarePythonPackage {
>> supportedPython = [Py33 Py34];
>> name = ...
>> src = ..
>> }
>>
>> What do you think?
>
> with python rework[1] going on, this would be nice also to solve there?
> chaoflow, iElectric any ideas from your side?
The wheels-based system knows a disable flag:
https://github.com/chaoflow/nixpkgs/blob/python/pkgs/development/python-wheels/wheels.nix#L44
I think black-listing python versions means less work than
white-listing. I guess most packages break either because of not
supporting 2.6 anymore or not supporting 3.x, yet. Once we flag that
properly, adding a new python version is unlikely to break a package.
Wit white-listing we would need to add it to every package.
--
Florian Friesdorf
GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083
Jabber/XMPP: f...@chaoflow.net
IRC: chaoflow on freenode,ircnet,blafasel,OFTC
pgpii26zby0ue.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] Zero Hydra Failures (ZHF) project
On the long run python2.6 and the corresponding disable flags will be
gone and packages will support 2.7 and 3.x. I expect disable flags to be
the exception.
Anyway, the work needed is to do the flagging. We are doing this for the
wheels we are working on and I'm also looking at the sprint in Ljubljana
to get that ready to be merge into master.
Luca Bruno writes:
> Not necessarily. Think like platforms.gnu. There may be a
> meta.pythonVersions and a default pythonVersions.default2 and
> pythonVersions.default3 and pythonVersions.all or such. Then adding a new
> major version to all packages is a metter of adding it to the default list.
>
>
> On Fri, Aug 8, 2014 at 5:40 PM, Florian Friesdorf wrote:
>
>>
>> Rok Garbas writes:
>> > Quoting Paul Colomiets (2014-08-08 15:13:57)
>> >> On Fri, Aug 8, 2014 at 3:35 PM, Eelco Dolstra
>> >> wrote:
>> >> >
>> >> > Note the huge number of Haskell and Python packages.
>> >> >
>> >>
>> >> For Python many of them doesn't support that version of python.
>> >> Wouldn't it be nice to declare supported versions inside a package,
>> >> inside of moving package to various sets. I.e.:
>> >>
>> >> declarePythonPackage {
>> >> supportedPython = [Py33 Py34];
>> >> name = ...
>> >> src = ..
>> >> }
>> >>
>> >> What do you think?
>> >
>> > with python rework[1] going on, this would be nice also to solve there?
>> > chaoflow, iElectric any ideas from your side?
>>
>> The wheels-based system knows a disable flag:
>>
>> https://github.com/chaoflow/nixpkgs/blob/python/pkgs/development/python-wheels/wheels.nix#L44
>>
>> I think black-listing python versions means less work than
>> white-listing. I guess most packages break either because of not
>> supporting 2.6 anymore or not supporting 3.x, yet. Once we flag that
>> properly, adding a new python version is unlikely to break a package.
>>
>> Wit white-listing we would need to add it to every package.
>>
>> --
>> Florian Friesdorf
>> GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083
>> Jabber/XMPP: f...@chaoflow.net
>> IRC: chaoflow on freenode,ircnet,blafasel,OFTC
>>
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>>
>
>
> --
> www.debian.org - The Universal Operating System
--
Florian Friesdorf
GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083
Jabber/XMPP: f...@chaoflow.net
IRC: chaoflow on freenode,ircnet,blafasel,OFTC
pgpNw2dZVOQWF.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] Sprint topics
Hi, in preparation for the sprint, please add your topics to the titanpad: https://titanpad.com/7yn7iBQ6n2 For discussion it might be nice to have one reply per topic to this email. see you soon florian -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpeyPeAne9Ar.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] Nixpkgs testing - Re: Sprint topics
Florian Friesdorf writes: > Hi, > > in preparation for the sprint, please add your topics to the titanpad: > > https://titanpad.com/7yn7iBQ6n2 > > For discussion it might be nice to have one reply per topic to this > email. We have per-package tests during checkPhase and installCheckPhase, and NixOS tests using qemu. Eelco Dolstra suggested [tests for nixpkgs](http://thread.gmane.org/gmane.linux.distributions.nixos/13465/focus=13469). To test (python-packaging) in nixpkgs, I propose [nixtest](https://github.com/chaoflow/nixtest/blob/master/nixtest.py#L94), and test library and [tests in nixpkgs](https://github.com/chaoflow/nixpkgs/tree/python/tests), would like to discuss with you and possibly develop further. Key features: - Rerun failed tests from command line as your user, i.e. not via nix-build. This greatly eases debugging, not to speak of making it actually fun. The [nixpkgs testing lib](https://github.com/chaoflow/nixpkgs/blob/python/tests/lib/default.nix#L120) creates a wrapper that creates and runs the test environment. - Python as test language. - [plumbum](http://plumbum.readthedocs.org/en/latest/index.html#user-guide) to construct cli calls. - [click](http://click.pocoo.org/) for a powerful cli of the test runner itself - Use [ipdb](https://github.com/gotcha/ipdb) to debug your tests, a debugger based on [ipython](http://ipython.org/) featuring tab completion among many other nice things Missing: - log messages in xml format suitable for hydra, currently only logged to stdout via python's logging library. - hydra jobset (within nixpkgs release.nix) -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgp4M2kH0Azbc.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] Wheel-based python packaging - Re: Sprint topics
Wheel-based python packaging Key features: - python wheels are not meant to be installed into profiles - instead python.site is used to create sites meant to be installed into profiles. Scripts/entry-points, i.e. stuff in bin/, can be created selectively - python.tool is used to create only scripts to be installed into a profile without potentially colliding libraries For more info see https://github.com/chaoflow/nixpkgs/tree/python/pkgs/development/python-wheels Missing: - per package testing - generation of test/runtime/extra requirements from wheels metadata - discussion of the overall approach Florian Friesdorf writes: > Hi, > > in preparation for the sprint, please add your topics to the titanpad: > > https://titanpad.com/7yn7iBQ6n2 > > For discussion it might be nice to have one reply per topic to this > email. > > see you soon > florian > -- > Florian Friesdorf > GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 > Jabber/XMPP: f...@chaoflow.net > IRC: chaoflow on freenode,ircnet,blafasel,OFTC -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpy0vyy7Hxxy.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] python packages and dependencies
Hi! buildPythonPackage happily fetches all dependency of a package defined in setup.py. The dependencies in there are not necessarily fixed to a specific version. Therefore, it's not guaranteed that one and the same nix expression produces the same derivation. How is this handled? florian -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgp6YMgxqxs6O.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] nix-env vs pkgs.buildEnv
Installing two python-packages that within their derivation both have a site.py works fine, nix-env ignores that file. However, defining an environment using pkgs.buildEnv with the same packages in paths, results in a collision because of site.py. Why do nix-env and pkgs.buildEnv use different builders? How can I teach pkgs.buildEnv to do the right thing, except telling it to ignore the collision. I'd feel better knowing, that it knows how to handle python packages. florian -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgp4O8i7vVaMx.pgp Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-commits] SVN commit: nix - r29427 - nixpkgs/trunk/pkgs/applications/networking/mailreaders/notmuch
Author: chaoflow
Date: Wed Sep 21 20:04:43 2011
New Revision: 29427
URL: https://ssl.nixos.org/websvn/nix/?rev=29427&sc=1
Log:
notmuch-0.8 all tests pass
Modified:
nixpkgs/trunk/pkgs/applications/networking/mailreaders/notmuch/default.nix
Modified:
nixpkgs/trunk/pkgs/applications/networking/mailreaders/notmuch/default.nix
==
--- nixpkgs/trunk/pkgs/applications/networking/mailreaders/notmuch/default.nix
Wed Sep 21 18:48:04 2011(r29426)
+++ nixpkgs/trunk/pkgs/applications/networking/mailreaders/notmuch/default.nix
Wed Sep 21 20:04:43 2011(r29427)
@@ -1,70 +1,75 @@
-{ fetchgit, stdenv, bash, emacs, gdb, git, glib, gmime, gnupg1, pkgconfig,
talloc, xapian }:
+{ fetchurl, stdenv, bash, emacs, gdb, git, glib, gmime, gnupg1, pkgconfig,
talloc, xapian }:
stdenv.mkDerivation rec {
- name = "notmuch-0.6-rc4";
+ name = "notmuch-0.8";
- src = fetchgit {
-url = "git://github.com/chaoflow/notmuch";
-rev = "9f8ef78e0c6b28918f3edda06b59a9e8f9bef8e3";
-sha256 =
"c7c425c10a695ca22dfbdf5fe8e0dcb6a888edc0b3388023e7ff35f69acc0085";
+ src = fetchurl {
+url = "http://notmuchmail.org/releases/${name}.tar.gz";;
+sha256 =
"f40bcdc6447cae9f76d5b4e70ab70d87e4a813cd123b524c1dc3155a3371a949";
};
buildInputs = [ bash emacs gdb git glib gmime gnupg1 pkgconfig talloc xapian
];
# XXX: Make me a loop
patchPhase = ''
-substituteInPlace "test/atomicity" \
- --replace "#!/bin/bash" "#!${bash}/bin/bash"
+# substituteInPlace "test/atomicity" \
+# --replace "#!/usr/bin/env bash" "#!${bash}/bin/bash"
+substituteInPlace "test/aggregate-results.sh" \
+ --replace "#!/usr/bin/env bash" "#!${bash}/bin/bash"
substituteInPlace "test/author-order" \
- --replace "#!/bin/bash" "#!${bash}/bin/bash"
+ --replace "#!/usr/bin/env bash" "#!${bash}/bin/bash"
substituteInPlace "test/basic" \
- --replace "#!/bin/bash" "#!${bash}/bin/bash"
+ --replace "#!/usr/bin/env bash" "#!${bash}/bin/bash"
substituteInPlace "test/crypto" \
- --replace "#!/bin/bash" "#!${bash}/bin/bash"
+ --replace "#!/usr/bin/env bash" "#!${bash}/bin/bash"
substituteInPlace "test/dump-restore" \
- --replace "#!/bin/bash" "#!${bash}/bin/bash"
+ --replace "#!/usr/bin/env bash" "#!${bash}/bin/bash"
substituteInPlace "test/emacs" \
- --replace "#!/bin/bash" "#!${bash}/bin/bash"
+ --replace "#!/usr/bin/env bash" "#!${bash}/bin/bash"
substituteInPlace "test/emacs-large-search-buffer" \
- --replace "#!/bin/bash" "#!${bash}/bin/bash"
+ --replace "#!/usr/bin/env bash" "#!${bash}/bin/bash"
substituteInPlace "test/encoding" \
- --replace "#!/bin/bash" "#!${bash}/bin/bash"
+ --replace "#!/usr/bin/env bash" "#!${bash}/bin/bash"
substituteInPlace "test/from-guessing" \
- --replace "#!/bin/bash" "#!${bash}/bin/bash"
+ --replace "#!/usr/bin/env bash" "#!${bash}/bin/bash"
substituteInPlace "test/json" \
- --replace "#!/bin/bash" "#!${bash}/bin/bash"
+ --replace "#!/usr/bin/env bash" "#!${bash}/bin/bash"
substituteInPlace "test/long-id" \
- --replace "#!/bin/bash" "#!${bash}/bin/bash"
+ --replace "#!/usr/bin/env bash" "#!${bash}/bin/bash"
substituteInPlace "test/maildir-sync" \
- --replace "#!/bin/bash" "#!${bash}/bin/bash"
+ --replace "#!/usr/bin/env bash" "#!${bash}/bin/bash"
substituteInPlace "test/new" \
- --replace "#!/bin/bash" "#!${bash}/bin/bash"
+ --replace "#!/usr/bin/env bash" "#!${bash}/bin/bash"
substituteInPlace "test/notmuch-test" \
- --replace "#!/bin/bash" "#!${bash}/bin/bash"
+ --replace "#!/usr/bin/env bash" "#!${bash}/bin/bash"
substituteInPlace "test/raw" \
- --replace "#!/bin/bash" "#!${bash}/bin/bash"
+ --replace "#!/usr/bin/env bash" "#!${bash}/bin/bash"
substituteInPlace "test/reply" \
- --replace "#!/bin/bash" "#!${bash}/bin/bash"
+ --replace "#!/usr/bin/env bash" "#!${bash}/bin/bash"
substituteInPlace "test/search" \
- --replace "#!/bin/bash" "#!${bash}/bin/bash"
+ --replace "#!/usr/bin/env bash" "#!${bash}/bin/bash"
substituteInPlace "test/search-by-folder" \
- --replace "#!/bin/bash" "#!${bash}/bin/bash"
+ --replace "#!/usr/bin/env bash" "#!${bash}/bin/bash"
substituteInPlace "test/search-insufficient-from-quoting" \
- --replace "#!/bin/bash" "#!${bash}/bin/bash"
+ --replace "#!/usr/bin/env bash" "#!${bash}/bin/bash"
+substituteInPlace "test/search-folder-coherence" \
+ --replace "#!/usr/bin/env bash" "#!${bash}/bin/bash"
substituteInPlace "test/search-output" \
- --replace "#!/bin/bash" "#!${bash}/bin/bash"
+ --replace "#!/usr/bin/env bash" "#!${bash}/bin/bash"
substituteInPlace "test/search-position-overlap-bug" \
- --replace "#!/bin/bash" "#!${bash}/bin/bash"
+ --replace "#!/usr/bin/env bash" "#!${bash
[Nix-commits] SVN commit: nix - r29428 - nixpkgs/trunk/pkgs/top-level
Author: chaoflow
Date: Wed Sep 21 20:05:24 2011
New Revision: 29428
URL: https://ssl.nixos.org/websvn/nix/?rev=29428&sc=1
Log:
ipython also as pythonPackages.ipython
Modified:
nixpkgs/trunk/pkgs/top-level/python-packages.nix
Modified: nixpkgs/trunk/pkgs/top-level/python-packages.nix
==
--- nixpkgs/trunk/pkgs/top-level/python-packages.nixWed Sep 21 20:04:43
2011(r29427)
+++ nixpkgs/trunk/pkgs/top-level/python-packages.nixWed Sep 21 20:05:24
2011(r29428)
@@ -19,6 +19,12 @@
};
+ ipython = import ../shells/ipython {
+inherit (pkgs) stdenv fetchurl;
+inherit buildPythonPackage pythonPackages;
+ };
+
+
wrapPython = pkgs.makeSetupHook
{ deps = pkgs.makeWrapper;
substitutions.libPrefix = python.libPrefix;
___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] SVN commit: nix - r29429 - nixpkgs/trunk/pkgs/tools/networking/iodine
Author: chaoflow
Date: Wed Sep 21 20:05:38 2011
New Revision: 29429
URL: https://ssl.nixos.org/websvn/nix/?rev=29429&sc=1
Log:
iodine-0.6.0-rc1
Modified:
nixpkgs/trunk/pkgs/tools/networking/iodine/default.nix
Modified: nixpkgs/trunk/pkgs/tools/networking/iodine/default.nix
==
--- nixpkgs/trunk/pkgs/tools/networking/iodine/default.nix Wed Sep 21
20:05:24 2011(r29428)
+++ nixpkgs/trunk/pkgs/tools/networking/iodine/default.nix Wed Sep 21
20:05:38 2011(r29429)
@@ -1,11 +1,11 @@
{ stdenv, fetchurl, zlib, nettools }:
stdenv.mkDerivation rec {
- name = "iodine-0.4.1";
+ name = "iodine-0.6.0-rc1";
src = fetchurl {
url = "http://code.kryo.se/iodine/${name}.tar.gz";;
-sha256 = "1d0v6wbrciwd0xi9khrna956v5wy7wy1inllzrn187as358kiiv5";
+sha256 =
"dacf950198b68fd1dae09fe980080155b0c75718f581c08e069eee0c1b6c5e60";
};
buildInputs = [ zlib ];
___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] SVN commit: nix - r29430 - nixpkgs/trunk/pkgs/development/libraries/talloc
Author: chaoflow
Date: Wed Sep 21 23:23:12 2011
New Revision: 29430
URL: https://ssl.nixos.org/websvn/nix/?rev=29430&sc=1
Log:
attempt to fix talloc build on darwin
see: https://bugzilla.samba.org/show_bug.cgi?id=7000
Modified:
nixpkgs/trunk/pkgs/development/libraries/talloc/default.nix
Modified: nixpkgs/trunk/pkgs/development/libraries/talloc/default.nix
==
--- nixpkgs/trunk/pkgs/development/libraries/talloc/default.nix Wed Sep 21
20:05:38 2011(r29429)
+++ nixpkgs/trunk/pkgs/development/libraries/talloc/default.nix Wed Sep 21
23:23:12 2011(r29430)
@@ -10,6 +10,10 @@
configureFlags = "--enable-talloc-compat1 --enable-largefile";
+ patchPhase = if stdenv.isDarwin then ''
+substituteInPlace "Makefile" --replace "SONAMEFLAG = #" "SONAMEFLAG =
-install_name"
+ '' else "";
+
meta = {
description = "talloc is a hierarchical pool based memory allocator with
destructors";
homepage = http://tdb.samba.org/;
___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] SVN commit: nix - r29431 - nixpkgs/trunk/pkgs/development/libraries/talloc
Author: chaoflow Date: Wed Sep 21 23:31:51 2011 New Revision: 29431 URL: https://ssl.nixos.org/websvn/nix/?rev=29431&sc=1 Log: indeed fix talloc build on darwin Modified: nixpkgs/trunk/pkgs/development/libraries/talloc/default.nix Modified: nixpkgs/trunk/pkgs/development/libraries/talloc/default.nix == --- nixpkgs/trunk/pkgs/development/libraries/talloc/default.nix Wed Sep 21 23:23:12 2011(r29430) +++ nixpkgs/trunk/pkgs/development/libraries/talloc/default.nix Wed Sep 21 23:31:51 2011(r29431) @@ -10,7 +10,8 @@ configureFlags = "--enable-talloc-compat1 --enable-largefile"; - patchPhase = if stdenv.isDarwin then '' + # https://bugzilla.samba.org/show_bug.cgi?id=7000 + postConfigure = if stdenv.isDarwin then '' substituteInPlace "Makefile" --replace "SONAMEFLAG = #" "SONAMEFLAG = -install_name" '' else ""; ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] SVN commit: nix - r29447 - nixpkgs/trunk/pkgs/games/scummvm
Author: chaoflow
Date: Fri Sep 23 02:23:05 2011
New Revision: 29447
URL: https://ssl.nixos.org/websvn/nix/?rev=29447&sc=1
Log:
scummvm more deps
Modified:
nixpkgs/trunk/pkgs/games/scummvm/default.nix
Modified: nixpkgs/trunk/pkgs/games/scummvm/default.nix
==
--- nixpkgs/trunk/pkgs/games/scummvm/default.nixFri Sep 23 00:03:21
2011(r29446)
+++ nixpkgs/trunk/pkgs/games/scummvm/default.nixFri Sep 23 02:23:05
2011(r29447)
@@ -1,4 +1,4 @@
-{stdenv, fetchurl, SDL, zlib, mpeg2dec}:
+{ stdenv, fetchurl, SDL, zlib, libmpeg2, libmad, libogg, libvorbis, flac,
alsaLib }:
stdenv.mkDerivation {
name = "scummvm-1.2.1";
@@ -8,7 +8,7 @@
sha256 = "029abzvpz85accwk7x79w255wr83gnkqg3yc5n6ryl28zg00z3j8";
};
- buildInputs = [SDL zlib mpeg2dec];
+ buildInputs = [ SDL zlib libmpeg2 libmad libogg libvorbis flac alsaLib ];
crossAttrs = {
preConfigure = ''
@@ -27,3 +27,4 @@
homepage = http://www.scummvm.org/;
};
}
+
___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits
Re: [Nix-dev] python packages and dependencies
From 21838b4079b6f115dc317922b57c86ba5b66ca2d Mon Sep 17 00:00:00 2001
From: Florian Friesdorf
Date: Fri, 23 Sep 2011 07:31:10 +0200
Subject: [PATCH] wip: pure python dependencies
---
.../development/python-modules/generic/default.nix | 22 ---
1 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/pkgs/development/python-modules/generic/default.nix b/pkgs/development/python-modules/generic/default.nix
index 4614917..e5a9ffc 100644
--- a/pkgs/development/python-modules/generic/default.nix
+++ b/pkgs/development/python-modules/generic/default.nix
@@ -17,14 +17,17 @@
# pollute the user environment.
pythonPath ? []
+ # XXX: always-unzip for the sake of diffing profiles, for debugging right now
, installCommand ?
''
- easy_install --prefix="$out" .
+ easy_install --no-deps --always-unzip --prefix="$out" .
''
, buildPhase ? "true"
-, doCheck ? true
+# python setup.py test otherwise triggers downloads, we also need to
+# forbid that and instead fail if a dep is not available.
+, doCheck ? false
, checkPhase ?
''
@@ -56,6 +59,10 @@ python.stdenv.mkDerivation (attrs // {
export PYTHONPATH="$out/lib/${python.libPrefix}/site-packages:$PYTHONPATH"
${installCommand}
+# no python package is to deliver these, we generate our own .pth files
+find $out -name easy-install.pth | xargs rm -v
+find $out -name 'site.py*' | xargs rm -v
+
${postInstall}
'';
@@ -67,8 +74,15 @@ python.stdenv.mkDerivation (attrs // {
# dependencies in the user environment (since Python modules don't
# have something like an RPATH, so the only way to find the
# dependencies is to have them in the PYTHONPATH variable).
- if test -e $out/nix-support/propagated-build-inputs; then
- ln -s $out/nix-support/propagated-build-inputs $out/nix-support/propagated-user-env-packages
+ if test -e $out/nix-support/propagated-build-native-inputs; then
+ ln -s $out/nix-support/propagated-build-native-inputs $out/nix-support/propagated-user-env-packages
fi
+
+ # create pth file for this distribution
+ sitepackages=$out/lib/${python.libPrefix}/site-packages
+ for x in $sitepackages/*.egg; do
+ filename=`basename $x`
+ echo $filename > $sitepackages/$filename.nix.pth
+ done
'';
})
--
1.7.6
Hi Peter,
On Wed, 21 Sep 2011 22:09:02 +0200, Peter Simons wrote:
> Hi Florian,
>
> > buildPythonPackage happily fetches all dependency of a package defined in
> > setup.py. The dependencies in there are not necessarily fixed to a
> > specific version. Therefore, it's not guaranteed that one and the same
> > nix expression produces the same derivation. How is this handled?
>
> I have noticed that, too, and I'm not about that "feature" either. I assume
> that there is a way (command-line flag) to tell 'distutils' to disable
> network access? Does anyone know how to do that?
Rok Garbas and me are sprinting currently in Arnhem on the Living
Statues Sprint. The attached patch tells easy_install not to install
dependencies, cleans a python package's site-packages and creates an
_nix.pth file for the python package. We get some
interesting behaviour:
Three environments:
config.nix:
{
packageOverrides = pkgs:
{
good1 = pkgs.buildEnv {
name = "good1";
paths = [
pkgs.python27
pkgs.python27Packages.simplejson
];
};
bad = pkgs.buildEnv {
name = "bad";
paths = [
pkgs.defaultStdenv
pkgs.python27
pkgs.python27Packages.simplejson
];
};
good2 = pkgs.buildEnv {
name = "good2";
paths = [
pkgs.zlib
pkgs.python27
pkgs.python27Packages.simplejson
];
};
};
}
The egg in site-packages is loaded without specifying PYTHONPATH:
$ nix-env -p good1 -i good1 && ./good1/bin/python -c 'import sys;import
pprint;pprint.pprint(sys.path); print sys.prefix; import site; print
site.PREFIXES'
installing `good1'
['',
'/tmp/cfl/good1/lib/python27.zip',
'/tmp/cfl/good1/lib/python2.7',
'/tmp/cfl/good1/lib/python2.7/plat-linux2',
'/tmp/cfl/good1/lib/python2.7/lib-tk',
'/tmp/cfl/good1/lib/python2.7/lib-old',
'/tmp/cfl/good1/lib/python2.7/lib-dynload',
'/tmp/cfl/good1/lib/python2.7/site-packages',
'/tmp/cfl/good1/lib/python2.7/site-packages/simplejson-2.1.3-py2.7-linux-x86_64.egg']
/tmp/cfl/good1
['/tmp/cfl/good1', '/tmp/cfl/good1']
The prefix is different and site-packages are not loaded:
$ nix-env -p bad -i bad && ./bad/bin/python -c 'import sys;import
pprint;pprint.pprint(sys.path); p
[Nix-commits] SVN commit: nix - r29462 - in nixpkgs/trunk/pkgs: development/interpreters/python top-level
Author: chaoflow
Date: Fri Sep 23 17:00:13 2011
New Revision: 29462
URL: https://ssl.nixos.org/websvn/nix/?rev=29462&sc=1
Log:
python wrapper that sets PYTHONHOME to the profile it is in
Added:
nixpkgs/trunk/pkgs/development/interpreters/python/pythonhome-wrapper.nix
Modified:
nixpkgs/trunk/pkgs/top-level/all-packages.nix
Added: nixpkgs/trunk/pkgs/development/interpreters/python/pythonhome-wrapper.nix
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ nixpkgs/trunk/pkgs/development/interpreters/python/pythonhome-wrapper.nix
Fri Sep 23 17:00:13 2011(r29462)
@@ -0,0 +1,21 @@
+{ stdenv }:
+
+stdenv.mkDerivation {
+ name = "pythonhome-wrapper";
+
+ unpackPhase = "true";
+ installPhase = ''
+ensureDir $out/bin
+echo '
+#!/bin/sh
+
+BINDIR=`dirname $0`
+PYTHONHOME=`dirname $BINDIR`
+PYTHONHOME=`(cd $PYTHONHOME && pwd)`
+export PYTHONHOME
+
+$BINDIR/python "$@"
+' > $out/bin/py
+chmod +x $out/bin/py
+ '';
+}
Modified: nixpkgs/trunk/pkgs/top-level/all-packages.nix
==
--- nixpkgs/trunk/pkgs/top-level/all-packages.nix Fri Sep 23 16:58:45
2011(r29461)
+++ nixpkgs/trunk/pkgs/top-level/all-packages.nix Fri Sep 23 17:00:13
2011(r29462)
@@ -2585,6 +2585,8 @@
extraLibs = lib.attrValues python.modules;
};
+ pythonhomeWrapper = callPackage
../development/interpreters/python/pythonhome-wrapper.nix { };
+
pyrex = pyrex095;
pyrex095 = callPackage ../development/interpreters/pyrex/0.9.5.nix { };
___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-dev] python application vs python environment
Hi, sorry for failing to express this in less words: As far as I understand: a profile in nix is a derivation. A derivation is build by linking in other derivations. By that installing a python interpreter and additional python modules into a profile results in these being linked from their respective derivations. A python application (eg. offlineimap) installed in a profile is isolated from the python environment that might also be installed there, but uses the built time interpreter directly and PYTHONPATH to find the needed modules in their derivations. On the other hand, if I install python itself and additional modules into a python profile, I would expect this profile to behave like a native python installation or virtualenv environment with additional modules. With the patch I recently posted (Subject: python packages and dependencies) python packages will not clutter their site-packages directory with easy_install.pth and site.py files, but instead for every distribution a .pth file is created that loads it. Given that the python installed into the profile links over pythonX.Y/site.py (buildEnv succeeds, nix-env fails so far) and that python itself is not a symlink (see below), python then finds all packages. If python is not a symlink the sys.prefix and therfore search mechanisms for site-packages works fine. If it is a symlink (happens if there is more than one derivation supplying content for bin/) python will follow it and find itself in its derivation, ending up with sys.prefix pointing to the derivation instead of the profile. By wrapping the python interpreter (see pythonhomeWrapper) and setting PYTHONHOME to the profile, this can be prevented and site-packages are correctly available. Doing the same for virtualenv (not committed yet) enables virtualenv which otherwise complains about mismatching prefixes. This would need to be done for all python shell commands that should be connected with the environment they are installed in (like virtualenv, ipdb, ipython). A profile corresponds to what others call /usr and a python installed there I would expect to feel at home there: -> sys.prefix set to the profile. I think we should have a python executable that feels at home in whatever profile it is used. Patching python itself not to resolve symlinks for finding its prefix, I think is not an option, because that is what python does and what users might expect. Instead we need a python that stops resolving symlinks once it reached its home profile (not continuing into its derivation). A solution would be, not to link python and pythonX.Y from the derivation, but instead to create two wrappers that set the PYTHONHOME and call then the python in the derivation. Do we break something by doing that? How can I influence how a derivation is merged into another derivation? regards -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpBtF3g71b2n.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] python application vs python environment
On Fri, 23 Sep 2011 23:27:40 +0200, Marc Weber wrote: > Excerpts from Florian Friesdorf's message of Fri Sep 23 20:46:12 +0200 2011: > > By wrapping the python interpreter (see pythonhomeWrapper) and setting > > PYTHONHOME to the profile, this can be prevented and site-packages are > > correctly available. > Yes, but it won't work if you want to make configure scripts find > dependencies unless you start building up temporary PYTHONHOME's for > each build. Could you provide an example for what would not work, ie. list of shell commands to type to run into a problem. > The better solution NIX_PYTHON_SITES patch has been implemented by me > and some packages such as pygtk has been patched properly (not for 3.0 > though). Its like PYTHONHOME but supports multiple paths which requires > some packages to be patched because they want to install into that one > HOME. Where is that patch? > Eventually you should consider having a look at my work. Its not > complete, But I'm pretty sure that it has some pretty nice ideas. > For ruby I start building up environments for individual projects: > ... > The system is strong enough to not allow two versions of the same libraries to > be put into the same env. It also resolves dependencies automatically. > You can add version constraints eg force "savon == 3.2". > > Needless to say that those envs also generate tag files for you automatically. You are sketching a "system" that builds environments in contrast to simple nix profiles, which does dependency resolution and creates tag files. This sounds like interesting pieces of functionality. For me personally, it would be great to see them as isolated (mostly independent) patches/applications. I don't want to change nix, but make its tools fulfill my and other python developers needs. So, a resolver I see relevant to generate nix expressions (see other thread currently running). Generation of tag files is something for a development environment. There is the concept of a profile in nix and I feel it important to have a definition of how python behaves in such a profile. If a nix profile is not suitable to generate a working python environment, than we should have documented why not and why we do not intend to fix it and what to use otherwise. I think (for now): that - a python and its modules installed in a profile should be a working python environment, - python development tools (virtualenv, ipdb) installed into it should be using it, - its possible to have multiple python versions in one profile - python applications installed into the profile do not use the python environments of the profile but instead their own PYTHONPATH-isolated one. > > Instead we need a python that stops resolving symlinks once it reached > > its home profile (not continuing into its derivation). > > > > A solution would be, not to link python and pythonX.Y from the > > derivation, but instead to create two wrappers that set the PYTHONHOME > > and call then the python in the derivation. > I have to think about this. I won't have time within the next 8 days or so. > > > How can I influence how a derivation is merged into another derivation? > Not sure what you're referring to here. When nix merges a derivation into a profile, all its files will be linked to the profile. More specifically, if the derivation is the only provider of a directory, the directory will be linked instead of individually linking its contents. If ./bin/python is a symlink, we have currently a problem and PYTHONHOME would be a solution, if python is a real file, we do not have a problem. So instead of symlinking the python executable, nix-env should be instructed to hard-link it - is this possible? regards -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgp7lvD6lcL6b.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] nix store: hardlink vs symlink (was Re: python application vs python environment)
Isolating aspects of the original mail: On Sat, 24 Sep 2011 14:36:20 +0200, Florian Friesdorf wrote: > If ./bin/python is a symlink, we have currently a problem and PYTHONHOME > would be a solution, if python is a real file, we do not have a problem. > > So instead of symlinking the python executable, nix-env should be instructed > to hard-link it - is this possible? Why is nix using symlinks to link files in the nix store? Would switching to hardlinks break something? - symlinks in case of whole directories - hardlinks for individual files -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpWI8UPz99Lr.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] distutils2nix/python4nix
On Sat, 24 Sep 2011 10:38:41 +0400, Michael Raskin <7c6f4...@mail.ru> wrote: > >Before we start writing cabal2nix, perl2nix, X2nix: How should the > >result look like? > >There are 20.000 ruby packages! > >And I personally don't like seeing more and more individual "let me > >update just this package and then that cause I need it right now and I > >don't know what this might break.." There is no choice unless we start > >supporting constraints. > > I am afraid this would mean building a solid general-purpose > data-grinding programming language into Nix. The idea to keep Nix small > seems to be still held, and it will not help us build a constraint > solver. > > We can - as usual - trade HDD space for sanity damage. That way every > version of every package has its preference of versions of all other > packages and we sometimes try to remove obsolete versions. +1 > >In theory I've packaged all of those ruby packages. But do we really > >want to checkout such masses of .nix files to get only 10 packages? > > > >Or would it be much better to query PyPi package database, cpan, .. > >lazily (which would require changing nix?) > > Or not Nix. If you have a way to programmatically generate all these > expressions, it is a no-brainer to find/write a FUSE FS tht will simply > generate the file whenever it is needed. Default checkout will have some > packages voted essential, and everyone can mount overlay and pretend all > rubyforge is there. +1 > The real problem with that solution would be deciding on policy of > keeping checksums. Of course, I could keep checksums locally. That would > give me all local benefits of Nix (I can reproduce whatever I have ever > done - maybe I should copy checksum DB over to be sure, but that seems > acceptable, if suboptimal), but denies global checksum synchronization. > Maybe we could have some online service to use for that database. I'm in favor of checksum synchronization. But for now I would just focus on how to automatically generate nix trees for the various languages. -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgp8p61VVGFAX.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] distutils2nix/python4nix
On Fri, 23 Sep 2011 23:12:14 +0200, Marc Weber wrote: > Excerpts from Peter Simons's message of Fri Sep 23 21:21:16 +0200 2011: > > One issue that you might want to consider is that the "pythonPackages" > > set needs to support several different versions of Python, i.e. the > > python interpreter needs to be an argument to that expression. > > Currently, we cannot build our python packages with Python 3.x, for > > example, which is really a shame. > > And that's the issue: The python packages don't say "I'm tested with > python-2.7". There are some wired automatic conversion tools. > > Before we start writing cabal2nix, perl2nix, X2nix: How should the > result look like? > There are 20.000 ruby packages! > And I personally don't like seeing more and more individual "let me > update just this package and then that cause I need it right now and I > don't know what this might break.." There is no choice unless we start > supporting constraints. > > In theory I've packaged all of those ruby packages. But do we really > want to checkout such masses of .nix files to get only 10 packages? > > Or would it be much better to query PyPi package database, cpan, .. > lazily (which would require changing nix?) I would first create all thix X2nix and Y4nix tools, once we have them we can think about whether and how to use them on-the-fly. Solving constraints would happen in those tools (maybe via a hook) and could be implemented as a generic, language independent solver (in prolog?, as Peter suggested). Or it might be feasible to use a language's own package manager to handle the resolving. But at the time a nix expression is being installed, that resolving has happened already and eg. python setup.py install is not allowed to fetch any dependencies. In any case nix knows how to handle nix expressions, so let's feed it nix expressions and use the magic to create them. > For python there is another issue: You have to run the setup.py file in > most cases to learn about package dependencies. You as a person generating nix expressions currently have to, changes towards a declarative format are ahead. > I already have written kind python 2 nix and its good enough to install > some packages on the fly but still needs much more love. > > If you want to learn about this way (which perfectly work for all ruby > versions) I'll point you to the code and explain how to use it. You were showing me all these tools, but I failed in seeing the currently relevant pieces. As said before, I am not searching an integrated new solution, but pieces to extend/adjust nix. > I personally believe that the final solution should take version > constraints into account so that you can fail early. +1 at the time of nix expression generation > How should this all look in the future (there are vim, emacs, perl, > ruby, python, eclipse, zsh, haxe, java, scala, ... ) packages to package. > And eg for scala, java it almost impossible to keep up to date using the > current manual way. I'm not sure what you mean with "current manual way". As far as I understand Peter uses cabal2nix and haskell4nix to semi-automatically maintain the haskell expressions. cabal2nix generates a nix expression and haskell4nix keeps nix haskell tree up-to-date. You run haskell4nix, check whether things look good, install something, run some tests, and check it in. Maybe Peter can explain in more detail what manual work he currently needs to do and where he sees potential for further automisation. I prefer a "manually" maintained tree over on-the-fly. Having explicit nix expressions allows for somebody/something to test these and building a database of known good sets of packages. If we generate the expressions on-the-fly, we would need a database of checksums in order to know whether the on-the-fly generated expressions are what we want them to be (as brought up by Michael). > It may be possible to tune the tools (sbt, maven, > ..) to use the nix store as cache at least.. > And I'm pretty sure that I've forgotten tons of package solutions (eg > ocaml) > > Thoughts? Are your tools providing the functionality of distutils2nix/python4nix described so far? -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpjVy91dEPD3.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] fetchgit vs tarball creation, privately maintained infrastructure
I messed up Subject and Cc m( Now, with Marc's permission publicly. My original mail: > Hi Marc, > > there are currently several expressions pointing to your server > resulting in 404s. > > Why do you prefer to put sources on your private server instead of > public infrastructure? > > Maybe we can keep the benefits and still profit from assumed higher > availability of public infrastructure. > > regards > florian On Fri, 23 Sep 2011 23:19:55 +0200, Marc Weber wrote: > (..) > I haven't had time to recover. Tell me the target packages and I'll > upload everything required to build them. see the attached file > Why don't I use fetchgit etc? Cause its too slow. My internet is slow. > I need incremental updates. That's why I wrote nix-repository-manager > to serve my needs. To solve that I would rather teach fetchgit to keep a cache of its repositories, instead of creating tarballs. Many things I install via fetchgit, I anyway want to have on my laptop for development. Having one common cache from which fetchgit for nix and you for development can clone. Anyway, I think nix expressions should not depend on anybody's private infrastructure, but instead use public infrastructure. > > Why do you prefer to put sources on your private server instead of > > public infrastructure? > > Maybe we can keep the benefits and still profit from assumed higher > > availability of public infrastructure. > I'm planing to put my stuff on amazon. I can't afford huge build farms. > But being able to launch some nice CPU powered instances on Amazon will > allow to me provide binaries for my branches. I don't think its necessary that you provide your own hosting infrastructure for that. > Currently my tool supports pushing tars by SSH. It should be doable to > make it cope with any public infrastructure. Which one do you suggest? I would not like to see packages use that approach without agreement that we in nix are generating tarballs for things available via git/svn/... I think the approach of caching is more fruitful. If we agree to create tarballs instead of fetching git, there is some good reason for it and those tarballs should be hosted on nix infrastructure, i.e. making it a solution used by every package maintainer. > If you want to join tell me. A lot of my patches did never get any > review. And committing them without "ok" was no good according to ludo > either. That's why I had to fork (also because SVN is too slow for me). I'd happy to review isolated patches implementing functionality I'm interested in. mawercer.de Description: Binary data -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpXdp2Arf1CJ.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] nix store: hardlink vs symlink
On Sat, 24 Sep 2011 16:41:07 +0200, Peter Simons wrote:
> Hi Florian,
>
> > Why is nix using symlinks to link files in the nix store?
> > Would switching to hardlinks break something?
>
> why do you think that hardlinks would be preferable?
Two profiles:
/tmp/cfl/bad: more than one derivation provides ./bin content,
./bin/python is a symlink
/tmp/cfl/good1: only python provides ./bin content, ./bin/python is not
a symlink.
If ./bin/python is a symlink, python will resolve it to find its home
and set sys.prefix accordingly. It ends with the python derivation being
the home (bad):
readlink("/tmp/cfl/bad/bin/python",
"/nix/store/vzpvrymynp4n93bznxha6hadj0ww68vx-python-2.7.1/bin/python", 4096) =
67
readlink("/nix/store/vzpvrymynp4n93bznxha6hadj0ww68vx-python-2.7.1/bin/python",
0x7fff5ec0fa60, 4096) = -1 EINVAL (Invalid argument)
If ./bin/python is not a symlink, the profile python is installed to
becomes the home and therefore sys.prefix (good):
readlink("/tmp/cfl/good1/bin/python", 0x7fff013ffc10, 4096) = -1 EINVAL
(Invalid argument)
I think the profile should be the home in both cases.
Making ./bin/python (and ./bin/pythonX.Y) a real file would solve the
problem.
> It is easy to determine where a symlink points to, but it's expensive to
> determine that for a hardlink. That information is oftentimes relevant,
> though, i.e. when analyzing run-time dependencies between store paths.
As python links in many more files than only ./bin/python and
./bin/pythonX.Y, would it be ok, to not symlink these two files, but
simply copy them or is there some other nix-conformant way to avoid the
symlinks for these two files?
--
Florian Friesdorf
GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083
Jabber/XMPP: f...@chaoflow.net
IRC: chaoflow on freenode,ircnet,blafasel,OFTC
pgpm1wIcfdl43.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] nix store: hardlink vs symlink
On Sat, 24 Sep 2011 08:03:03 -0700, s...@shealevy.com wrote:
> It seems like the problem here is with Python, not nix. Isn't there a way
> to set some env var or command line flag to set sys.prefix manually? Then
> you can create a wrapper script to call the "real" Python with the right
> value.
Setting PYTHONHOME overrides the prefix, pythonhomeWrapper (WIP) does
that.
Having:
pyhome = pkgs.buildEnv {
name = "pyhome";
paths = [
pkgs.defaultStdenv
pkgs.python27
pkgs.python27Packages.simplejson
pkgs.pythonhomeWrapper
];
};
you get an environment where ./bin/py is starting a python with correct
prefix.
I'm in favor of changing the python expressions to replace all relevant
scripts (./bin/python, ./bin/pythonX.Y, maybe more) with wrapped
versions.
Are there reasons against doing so?
> Or patch Python not to follow symlinks like that.
I think we should not change that, because that's what python does and
there might be people using it. Will bring this up on python-dev.
--
Florian Friesdorf
GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083
Jabber/XMPP: f...@chaoflow.net
IRC: chaoflow on freenode,ircnet,blafasel,OFTC
pgpx3ocEO8mCz.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] nix store: hardlink vs symlink
On Sat, 24 Sep 2011 17:15:08 +0200, Peter Simons wrote: > Hi Florian, > > > If ./bin/python is a symlink, python will resolve it to find its home > > and set sys.prefix accordingly. > > it seems to me like Python is behaving perfectly reasonable. The prefix of > Python is at /nix/store/vzpvrymynp4n93bznxha6hadj0ww68vx-python-2.7.1. The > other paths, /tmp/cfl/bad or /tmp/cfl/good1, are not its prefix. > > Why would you want Python to believe that its prefix would be at one of those > paths? The prefix determines where python searches for site-packages. I currently see two ways python is called: Python applications with an isolated environment They call python as: /nix/store/vzpvrymynp4n93bznxha6hadj0ww68vx-python-2.7.1/bin/python the prefix is: /nix/store/vzpvrymynp4n93bznxha6hadj0ww68vx-python-2.7.1 and python will load its empty site-packages in there. Modules needed by the application are made available via PYTHONPATH. Python development ~~ You currently can install python modules into a profile, together with a python interpreter (of the same python version) they can build a python environment. Not meant for running applications, but for example development. For this environment to function properly python needs to treat the profile as its home. virtualenv for example currently breaks because of modules coming from different prefixes. If I install ipdb and ipython into a profile, I'd expect them to see all modules I added to the profile. -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpP9xZBaHkK9.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] [Marc Weber] Re: distutils2nix/python4nix
some mails that accidentally did not make it to the list --- Begin Message --- Excerpts from Florian Friesdorf's message of Sat Sep 24 15:19:06 +0200 2011: > I prefer a "manually" maintained tree over on-the-fly. Having explicit > nix expressions allows for somebody/something to test these and building > a database of known good sets of packages. If we generate the > expressions on-the-fly, we would need a database of checksums in order > to know whether the on-the-fly generated expressions are what we want > them to be (as brought up by Michael). If you mantain them manually you - miss to remove dependencies even if they got dropped unless you regenerate everything - you may run into some cases where dependencies depend on cabal flags or versions of other packages being used. Obviously it doesn't matter much in practise (anymore?) else Peter would have had more issues. - you may start builds which then might fail due to wrong versions being passed (either ghc or library versions). using hack-nix you update the hack-nix cache. You define which C libraries to pass. Everything else should be automatic (dependency resolution etc). Brute force is used. So it only works on "limited package list such as _latest packages_". It fails early. Eg it says "no version of X found but 2.0 required". Current drawback: requires more evaluation time. Colud be fixed by using haskell or C implementation. You can easily construct artificial dependency construct which can not be mapped to what Peter does. However because most other distros have similar limitations it looks like people work hard on avoid such scenarios so it may not matter that much for most common packages. That's a short list. You can overwrite arbitrary cabal flags on the fly which also may lead to many changes in dependencies. hack-nix copes with it - if you generate .nix files it may force you regenerating a new pool of .nix files (worst case). Again: it doesn't seem to happen often enough to care about. Marc Weber --- End Message --- <#secure method=pgpmime mode=sign> -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] [Florian Friesdorf] Re: distutils2nix/python4nix
some mails that accidentally did not make it to the list --- Begin Message --- On Sat, 24 Sep 2011 15:57:52 +0200, Marc Weber wrote: > Excerpts from Florian Friesdorf's message of Sat Sep 24 15:19:06 +0200 2011: > > I prefer a "manually" maintained tree over on-the-fly. Having explicit > > nix expressions allows for somebody/something to test these and building > > a database of known good sets of packages. If we generate the > > expressions on-the-fly, we would need a database of checksums in order > > to know whether the on-the-fly generated expressions are what we want > > them to be (as brought up by Michael). > > If you mantain them manually you > > - miss to remove dependencies even if they got dropped unless you > regenerate everything +1 for regenerate everything, if that's too slow: introduce caching. > - you may run into some cases where dependencies depend on cabal flags > or versions of other packages being used. Obviously it doesn't matter > much in practise (anymore?) else Peter would have had more issues. > > - you may start builds which then might fail due to wrong versions being > passed (either ghc or library versions). > > using hack-nix you update the hack-nix cache. You define which C > libraries to pass. Everything else should be automatic (dependency > resolution etc). Brute force is used. So it only works on "limited > package list such as _latest packages_". > > It fails early. Eg it says "no version of X found but 2.0 required". If you can solve these problems in hack-nix, I do not understand how it would differ from generating nix expressions, instead of doing it on-the-fly. > Current drawback: requires more evaluation time. Colud be fixed by using > haskell or C implementation. > > You can easily construct artificial dependency construct which can not > be mapped to what Peter does. Why not? And are they artificial or is there some package creating this problem? > However because most other distros have similar limitations it looks > like people work hard on avoid such scenarios so it may not matter > that much for most common packages. For me it looks like there are many potential problems and worst case scenarios, but I kind of refuse to cope with them until I experience them. Creating nix expressions automatically feels like the next logical step after "creating nix expressions manually". > That's a short list. You can overwrite arbitrary cabal flags on the fly > which also may lead to many changes in dependencies. hack-nix copes with > it - if you generate .nix files it may force you regenerating a new pool > of .nix files (worst case). Again: it doesn't seem to happen often > enough to care about. But if I understand it correctly, you are creating a "pool" of nix files, which I currently call a "tree" of nix expressions. Why are you opposing (are you?) the idea of distutils2nix/python4nix? Given the following python packages: plone.app.deco-1.2.3 plone.app.deco-1.3.4 plone.app.deco-2.1 plone.app.standardtiles-1.2 plone.app.standardtiles-1.3 I would create: pkgs.pythonXYPackages.plone.app.deco pkgs.pythonXYPackages.plone.app.deco_1 pkgs.pythonXYPackages.plone.app.deco_1_2 pkgs.pythonXYPackages.plone.app.deco_1_2_3 pkgs.pythonXYPackages.plone.app.deco_1_3 pkgs.pythonXYPackages.plone.app.deco_1_3_4 pkgs.pythonXYPackages.plone.app.deco_2 pkgs.pythonXYPackages.plone.app.deco_2_1 pkgs.pythonXYPackages.plone.app.standardtiles pkgs.pythonXYPackages.plone.app.standardtiles_1 pkgs.pythonXYPackages.plone.app.standardtiles_1_2 pkgs.pythonXYPackages.plone.app.standardtiles_1_3 stored as: ./plone/app/deco/default.nix ./plone/app/deco/1/default.nix ./plone/app/deco/1/2/default.nix ./plone/app/deco/1/2/3/default.nix ./plone/app/deco/1/3/default.nix ./plone/app/deco/1/3/4/default.nix ./plone/app/deco/2/default.nix ./plone/app/deco/2/1/default.nix ./plone/app/standardtiles/default.nix ./plone/app/standardtiles/1/default.nix ./plone/app/standardtiles/1/2/default.nix ./plone/app/standardtiles/1/3/default.nix By that you can add to every package any new version and there are attributes that always fulfill requirements like: - plone.app.deco<2 --> ...plone.app.deco_1 - plone.app.deco<1.3 --> ...plone.app.deco_1_2 -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpDpCSE0L9Ln.pgp Description: PGP signature --- End Message --- -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpnei7xPr1OP.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] [Marc Weber] Re: distutils2nix/python4nix
some mails that accidentally did not make it to the list --- Begin Message --- > If you can solve these problems in hack-nix, I do not understand how it > would differ from generating nix expressions, instead of doing it > on-the-fly. http://article.gmane.org/gmane.linux.distributions.nixos/6180/match=sketchy+list See first link given there. That's the "pool" I'm talking about: a nix readable representation of hackage. > Why not? And are they artificial or is there some package creating this > problem? A depends on either - B-1.0 AND C (case I) - or B-2.0(case II) Now TARGET depends on A AND OTHER. If OTHER depends on B-1.0 case I must be chosen, if OTHER depends on B-2.0 case II must be chosen when building A because you should not use B-1.0 and B-2.0 at the same time or bad things can happen. Now A is a dependency of TARGET. And TARGET determines the set of dependencies which must be used by A. That's why generating simple .nix files will not work in such a case. split-base etc in the past was such a case. hack-nix copes with that artificial TARGET case, the ruby and python implementations I wrote only fail with an error telling you that two versions of B are used and that you have to manually choose one to make it work. That's better than nothing. Yes - this also happens for C apps. evince or such once broke. Took quite a while to find out that one dependency was using an overwritten version of a library while another dependency was not. The result was a segfault. I agree that it doesn't happen often. > For me it looks like there are many potential problems and worst case > scenarios, but I kind of refuse to cope with them until I experience > them. Creating nix expressions automatically feels like the next logical > step after "creating nix expressions manually". But if there is such an issue I don't want to start rewriting all of hack-nix.nix - that would take too much of my time. That's why I wrote hack-nix. But I agree that its a working proof concept implementation only. Marc Weber --- End Message --- <#secure method=pgpmime mode=sign> -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] distutils2nix/python4nix
On Sat, 24 Sep 2011 17:13:23 +0200, Marc Weber wrote: > > If you can solve these problems in hack-nix, I do not understand how it > > would differ from generating nix expressions, instead of doing it > > on-the-fly. > http://article.gmane.org/gmane.linux.distributions.nixos/6180/match=sketchy+list > See first link given there. That's the "pool" I'm talking about: a nix > readable representation of hackage. > > > Why not? And are they artificial or is there some package creating this > > problem? > > A depends on either > - B-1.0 AND C (case I) > - or B-2.0(case II) > > Now TARGET depends on A AND OTHER. > If OTHER depends on B-1.0 case I must be chosen, if OTHER depends on B-2.0 > case II must be chosen when building A because you should not use B-1.0 > and B-2.0 at the same time or bad things can happen. > > Now A is a dependency of TARGET. And TARGET determines the set of > dependencies which must be used by A. That's why generating simple .nix > files will not work in such a case. My understanding is, that all (needed) combinations would be created as nix expressions. If you did not install the combination sometime beforehand, then nix is I think the wrong tool by design. The question is more what tools we have to generate expressions for us. If my perception of nix is wrong, please correct me. -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpbVoLOTdJW7.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] nix store: hardlink vs symlink (was Re: python application vs python environment)
On Sat, 24 Sep 2011 21:56:02 +0200, l...@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) wrote: > Hi Florian, > > Florian Friesdorf skribis: > > > Why is nix using symlinks to link files in the nix store? > > Because hard links don’t work across devices. But the links would be just intra-store links, or? Is it a supported setup to have parts of the store on different devices? -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpXQt3pv8vwx.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] distutils2nix/python4nix
On Sat, 24 Sep 2011 23:54:48 +0200, Marc Weber wrote: > (..) > To keep the long story short: I don't believe in generating .nix > expressions scaling very well for the future. But I don't know :) > > > expressions. If you did not install the combination sometime beforehand, > > then nix is I think the wrong tool by design. The question is more what > > tools we have to generate expressions for us. > > So how to use ruby,python,.. or many java maven driven packages on > nixpkgs then? Is the answer: Don't? Or "symlink libraries to /usr/lib > so that standard tools like ruby and python packages find them easier? > I'd like to get rid of this kind of mess. But I don't have the perfect > solution yet. I cannot follow your argument. How is generating nix expressions related to having syminks in /usr/lib? > > If my perception of nix is wrong, please correct me. > You're welcome at "great Nix" facing reald world dynamic managed package > databases of dynamic languages :) > > So yes, its a feeling only that the current way won't scale for the future. > Its > not knowing. I may be wrong. I'm waiting for others proofing me wrong doing > all > the work :) Meanwhile I try to find solutions which work for me minimizing the > time I have to spend to get packages working .. Well then, lean back, let others struggle with generating nix expressions and enjoy the show ;) I'd like to see a discussion on how to generate nix expressions, not on "why what we are currently doing is maybe not going to work out", I guess that was discussed enough in the past. -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpfBJ7DpjBuz.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] nix store: hardlink vs symlink (was Re: python application vs python environment)
On Sun, 25 Sep 2011 22:23:57 +0200, l...@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) wrote: > Florian Friesdorf skribis: > > > On Sat, 24 Sep 2011 21:56:02 +0200, l...@gnu.org (Ludovic > > =?iso-8859-1?Q?Court=E8s?=) wrote: > >> Hi Florian, > >> > >> Florian Friesdorf skribis: > >> > >> > Why is nix using symlinks to link files in the nix store? > >> > >> Because hard links don’t work across devices. > > > > But the links would be just intra-store links, or? > > Sorry, I thought you were referring to why profiles use symlinks to the > store. > > Within a store, using hard links is OK, yes, and ‘nix-store --optimise’ > does exactly that. But I think thats for a different purpose: An expression installs a programm into a derivation. If two of them have the exact same file, nix-store --optimise will hardlink them. If now two derivations are put together into a new derivation, their components will be symlinked and here, as I understand now, hardlinks are not an option because nix uses the symlinks to store information about dependencies. -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpKVEyoShxBE.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] How to set python's module search path (was: nix store: hardlink vs symlink)
Hi Peter,
On Sun, 25 Sep 2011 16:08:35 +0200, Peter Simons wrote:
> Hi Florian,
>
> > The prefix determines where python searches for site-packages. [...]
>
> my impression is that you are not concerned about the use of symlinks
> versus hardlinks, but you're really interested in ways to make Python
> find its extra libraries.
yes
> It looks on first sight as if those two issues are related, but they
> are really not. The proper way to make Python find its extra libraries
> is through use of environment variables, and there are two alternative
> solutions:
>
> > Python applications with an isolated environment
> >
> > They call python as:
> > /nix/store/vzpvrymynp4n93bznxha6hadj0ww68vx-python-2.7.1/bin/python
> >
> > the prefix is:
> > /nix/store/vzpvrymynp4n93bznxha6hadj0ww68vx-python-2.7.1
> >
> > and python will load its empty site-packages in there. Modules needed
> > by the application are made available via PYTHONPATH.
>
> This approach has extremely reliable behavior. It is easy to predict how
> Python is going to have, because the set of available libraries does not
> depend on any external factors, such as the contents of the profile that
> Python happens to be installed in. Suppose I wanted Python to know about
> the Cheetah library, then would configure
>
> {
> pythonCheetah = pkgs.pythonFull.override {
> extraLibs = with pkgs.python27Packages; [ cheetah ];
> };
> };
> }
I was not aware that this is possible. So far I was not able to find
documentation for config.nix.
> in ~/.nixpkgs/config.nix, install
>
> nix-env -p /tmp/foobar -iA pythonCheetah
>
> ..., and I'd be able to run
>
> /tmp/foobar/bin/python -c 'import Cheetah'
>
> just fine. That particular approach allows me to control which libraries
> Python knows, and which libraries Python *doesn't know*, and Python is
> going to behave that way no matter what I other things I do.
I will try this approach for my use cases and report back.
> > Python development
> > ~~
> > You currently can install python modules into a profile, together with a
> > python interpreter (of the same python version) they can build a python
> > environment. Not meant for running applications, but for example
> > development.
> >
> > For this environment to function properly python needs to treat the
> > profile as its home. virtualenv for example currently breaks because of
> > modules coming from different prefixes.
> >
> > If I install ipdb and ipython into a profile, I'd expect them to see
> > all modules I added to the profile.
>
> This approach doesn't work well within Nix, because Nix calls things
> directly from their store path (i.e. there is no "profile"), but it's a
> fine solution for end users who to install things into their home
> profile and just run them without re-configuring their expressions every
> time. The behavior is inherently unpredictable, though. When a certain
> library is installed in the profile, Python is going to know about it.
> When that library is missing, however, Python won't know about it. In
> other words, there are hidden dependencies.
>
> One could argue that PYTHONHOME is not the proper way to accomplish this
> configuration, though. Personally, I'd rather set
>
> export PYTHONPATH=$HOME/.nix-profile/lib/python2.7/site-packages
>
> in my ~/.bashrc or something, but that's a matter of taste.
>
> Anyway, both solutions have their individual strengths and weaknesses,
> and I believe that we should support both.
+1
> The "pythonhomeWrapper" expression seems to be superfluous, though.
> There is no need for two different wrapper scripts, so I'd much rather
> see that functionality incorporated into the existing wrapper.
+1
thanks a lot!
--
Florian Friesdorf
GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083
Jabber/XMPP: f...@chaoflow.net
IRC: chaoflow on freenode,ircnet,blafasel,OFTC
pgpiaqi3cUl1B.pgp
Description: PGP signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-commits] SVN commit: nix - r29805 - nixpkgs/trunk/pkgs/top-level
Author: chaoflow
Date: Thu Oct 13 08:47:49 2011
New Revision: 29805
URL: https://nixos.org/websvn/nix/?rev=29805&sc=1
Log:
linux_2_6_39_powertop
Modified:
nixpkgs/trunk/pkgs/top-level/all-packages.nix
Modified: nixpkgs/trunk/pkgs/top-level/all-packages.nix
==
--- nixpkgs/trunk/pkgs/top-level/all-packages.nix Thu Oct 13 08:21:57
2011(r29804)
+++ nixpkgs/trunk/pkgs/top-level/all-packages.nix Thu Oct 13 08:47:49
2011(r29805)
@@ -5537,6 +5537,7 @@
linux_2_6_38_ati = linux_2_6_38.override { extraConfig="DRM_RADEON_KMS y"; };
+ # Please keep in sync with linux_2_6_39_powertop, except for extraConfig
linux_2_6_39 = makeOverridable (import
../os-specific/linux/kernel/linux-2.6.39.nix) {
inherit fetchurl stdenv perl mktemp module_init_tools ubootChooser;
kernelPatches =
@@ -5547,6 +5548,30 @@
];
};
+ # Please keep in sync with linux_2_6_39, except for extraConfig
+ linux_2_6_39_powertop = makeOverridable (import
../os-specific/linux/kernel/linux-2.6.39.nix) {
+inherit fetchurl stdenv perl mktemp module_init_tools ubootChooser;
+extraConfig = ''
+CPU_FREQ_GOV_ONDEMAND y
+CPU_FREQ_STAT y
+DEBUG_KERNEL y
+HIGH_RES_TIMERS y
+HPET_TIMER y
+NO_HZ y
+PM_ADVANCED_DEBUG y
+PM_RUNTIME y
+SND_AC97_POWER_SAVE y
+TIMER_STATS y
+USB_SUSPEND y
+'';
+kernelPatches =
+ [ #kernelPatches.fbcondecor_2_6_38
+kernelPatches.sec_perm_2_6_24
+kernelPatches.aufs2_1_2_6_39
+#kernelPatches.mips_restart_2_6_36
+ ];
+ };
+
linux_3_0 = makeOverridable (import
../os-specific/linux/kernel/linux-3.0.nix) {
inherit fetchurl stdenv perl mktemp module_init_tools ubootChooser;
kernelPatches =
@@ -5713,6 +5738,7 @@
linuxPackages_2_6_38 = recurseIntoAttrs (linuxPackagesFor linux_2_6_38
pkgs.linuxPackages_2_6_38);
linuxPackages_2_6_38_ati = recurseIntoAttrs (linuxPackagesFor
linux_2_6_38_ati pkgs.linuxPackages_2_6_38);
linuxPackages_2_6_39 = recurseIntoAttrs (linuxPackagesFor linux_2_6_39
pkgs.linuxPackages_2_6_39);
+ linuxPackages_2_6_39_powertop = recurseIntoAttrs (linuxPackagesFor
linux_2_6_39_powertop pkgs.linuxPackages_2_6_39_powertop);
linuxPackages_3_0 = recurseIntoAttrs (linuxPackagesFor linux_3_0
pkgs.linuxPackages_3_0);
linuxPackages_3_1 = recurseIntoAttrs (linuxPackagesFor linux_3_1
pkgs.linuxPackages_3_1);
linuxPackages_nanonote_jz_2_6_34 = recurseIntoAttrs (linuxPackagesFor
linux_nanonote_jz_2_6_34 pkgs.linuxPackages_nanonote_jz_2_6_34);
___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits
