[Nix-dev] haskell: eval "$checkPhase" fails until nix-shell is re-entered
Hi, When hacking on Haskell projects with tests, the tests ofter depend on the project itself: that is, test-suite blocks will have itself in dependencies. This works fine with cabal and such. However, if I run: eval "$configurePhase" && eval "$buildPhase" && eval "$checkPhase" in Haddock which does this, I get: In-place registering haddock-2.15.0... Preprocessing executable 'haddock' for haddock-2.15.0... [1 of 1] Compiling Main ( driver/Main.hs, dist/build/haddock/haddock-tmp/Main.dyn_o ) Linking dist/build/haddock/haddock ... Preprocessing test suite 'html-test' for haddock-2.15.0... [1 of 1] Compiling Main ( html-test/run.lhs, dist/build/html-test/html-test-tmp/Main.dyn_o ) Linking dist/build/html-test/html-test ... Preprocessing test suite 'latex-test' for haddock-2.15.0... [1 of 1] Compiling Main ( latex-test/run.lhs, dist/build/latex-test/latex-test-tmp/Main.dyn_o ) Linking dist/build/latex-test/latex-test ... Running 2 test suites... Test suite html-test: RUNNING... Haddock version 2.15.0, (c) Simon Marlow 2006 Ported to use the GHC API by David Waern 2006-2008 7.9.20140624 Haddock version: GHC version: html-test: user error (Use of GHC's environment variable GHC_PACKAGE_PATH is incompatible with Cabal. Use the flag --package-db to specify a package database (it can be used multiple times).) Test suite html-test: FAIL Test suite logged to: dist/test/haddock-2.15.0-html-test.log Test suite latex-test: RUNNING... Haddock version 2.15.0, (c) Simon Marlow 2006 Ported to use the GHC API by David Waern 2006-2008 7.9.20140624 Haddock version: GHC version: latex-test: user error (Use of GHC's environment variable GHC_PACKAGE_PATH is incompatible with Cabal. Use the flag --package-db to specify a package database (it can be used multiple times).) Test suite latex-test: FAIL Test suite logged to: dist/test/haddock-2.15.0-latex-test.log 0 of 2 test suites (0 of 2 test cases) passed. Now if I quit out of the nix-shell and re-enter: [nix-shell:~/programming/haddock]$ exit [shana@lenalee:~/programming/haddock]$ nix-shell --pure [nix-shell:~/programming/haddock]$ eval "$checkPhase" Running 2 test suites... Test suite html-test: RUNNING... Test suite html-test: PASS Test suite logged to: dist/test/haddock-2.15.0-html-test.log Test suite latex-test: RUNNING... Test suite latex-test: PASS Test suite logged to: dist/test/haddock-2.15.0-latex-test.log 2 of 2 test suites (2 of 2 test cases) passed. Needless to say, this is really annoying during development and if any tools rely on test output then those can't work either. Looking at nixpkgs, it seems that the packages that do this kind of testing (Haddock, Yi) have tests disabled by default even though I know the tests for both those projects pass. It seems like someone disabled the tests in favour of finding out what actually needs to happen… Does anyone have any insight on how to get this to work properly? It seems that this should be fixed on nix/nixpkgs side. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Dropping into existing nix-shell session
Hi, The way I work with Haskell is this: * set up default.nix in project directory * run nix-shell --pure to pull in all dependencies * optionally manually run cabal build in case some CPP and symbol generation needs to happen (I'd like to know the proper way here but that's for another thread) * once I'm ready, open one of the files in the project in emacs * evaluate (setq haskell-program-name "nix-shell --pure --command ghci") * use the C-c C-l combo to start GHCi and work with the loaded file My problem is that whenever I press C-c C-l again to reload the file after I've made some changes, it seems to re-invoke nix-shell or something. [shana@lenalee:~]$ df | grep /dev/sdb1 /dev/sdb151475068 394676689369576 81% / -- reload here [shana@lenalee:~]$ df | grep /dev/sdb1 /dev/sdb151475068 394676849369560 81% / That is every time I reload, more disk space gets eaten. This is a real problem when hacking on larger projects, I had previously eaten through 6GB+ of space before I ran out of memory on /. Does anyone know of a proper way to invoke GHCi without effectively restarting the shell? Am I barking up the wrong tree perhaps and should be taking it to emacs haskell-mode guys? I suppose the question I'm asking is ‘is there a way to drop into an existing nix-shell session?’. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Staging branch
> Eelco Dolstra writes: > I've set up a Nixpkgs/NixOS branch named "staging", intended to bunch > changes that cause rebuilds/redownloads of many packages (such as stdenv > changes). The idea is that this branch can be merged into master > periodically (e.g. every few weeks). Thank you, Eelco, this helps my overall workflow considerably. I like to keep up-to-date with master often so I can test/push small changes, but since really testing a change means updating with --leq, a large destabilizing change to stdenv can wipe out my ability to test the small stuff for a day or more. John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How to install ruby gems?
> Mateusz Kowalczyk writes: > Did you manage to figure anything out? There's a Ruby program that I'd like > to package and use but I have no idea where to even start: I'm definitely > not a Ruby user! Here's what the gemspec file shows in case it's relevant: I think we need a way to do rubyPackages, the way that we have for perl and python. Any Nix+ruby users willing to do that work? John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] cabal.mkDerivation and cabal flags
Thank you Peter. I think it is useful since snap-server has cmd args which one can enable or disable https. On Tue, Jun 24, 2014 at 8:29 PM, Peter Simons wrote: > Hi Aycan, > > > Is it possible to provide cabal flags within a derivation? > > you can set "-fFLAG" in configureFlags to enable the flag during the > build. If this flag is useful in general, then please add it to > > https://github.com/NixOS/cabal2nix/blob/master/src/Cabal2Nix/Flags.hs > > and file a pull request. > > Best regards, > Peter > > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > -- http://www.google.com/profiles/iricanaycan ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Staging branch
Hi Vladimír, > In my experience, it's typically tricky to judge whether a mass-rebuild > change is potentially destabilizing without a full hydra rebuild. I suppose that this stabilization process would take place in a feature branch (that has its own Hydra job). Then, after the change is considered stable, it's merge into "staging". > I often get many failures on Hydra that aren't trivial to fix. Often > it's darwin problems, which is a chapter for itself, but problems on > my platform common as well. There are different degrees of "stable". A change that breaks 99% of all packages is probably a tad too unstable. A change that works fine with 99% of all packages, however, is fine to merge IMHO. Packages *will* break when we add new features, and that is okay. Everyone who follows "master" must know the risks (and preferably contribute to fix the damage once it's detected). Best regards, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] cabal.mkDerivation and cabal flags
Hi Aycan, > Is it possible to provide cabal flags within a derivation? you can set "-fFLAG" in configureFlags to enable the flag during the build. If this flag is useful in general, then please add it to https://github.com/NixOS/cabal2nix/blob/master/src/Cabal2Nix/Flags.hs and file a pull request. Best regards, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] [PATCH Nix] Flush substituter output upon ‘\r’
Hi,
Please use reply-to-all.
Eelco Dolstra skribis:
> On 17/06/14 17:50, Ludovic Courtès wrote:
>
>> The patch below changes the store so that it flushes what it reads from
>> the substituter’s stderr when it encounters either a newline or a
>> carriage return.
>>
>> The intent is to allow substituters to provide some kind of progress
>> report, where the status is updated by means of a ‘\r’.
>
> What kind of progress report do you mean, and why wouldn't '\n' work for that?
Progress reports:
0%\r
1%\r
2%\r
>> As a side effect, this patch removes the “substituter-name: ” prefix on
>> the lines that are printed. It can be reinstated if deemed appropriate.
>
> Please do, without it there is no indication where the error came from.
Here it is.
Thanks,
Ludo’.
diff --git a/src/libstore/local-store.cc b/src/libstore/local-store.cc
index 1293a6e..079972c 100644
--- a/src/libstore/local-store.cc
+++ b/src/libstore/local-store.cc
@@ -1141,8 +1141,10 @@ string LocalStore::getLineFromSubstituter(RunningSubstituter & run)
if (n == 0) throw EndOfFile(format("substituter `%1%' died unexpectedly") % run.program);
err.append(buf, n);
string::size_type p;
-while ((p = err.find('\n')) != string::npos) {
-printMsg(lvlError, run.program + ": " + string(err, 0, p));
+while (((p = err.find('\n')) != string::npos)
+ || ((p = err.find('\r')) != string::npos)) {
+ string thing(err, 0, p + 1);
+ writeToStderr(run.program + ": " + thing);
err = string(err, p + 1);
}
}
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] [PATCH Nix] Flush substituter output upon ‘\r’
Hi, On 17/06/14 17:50, Ludovic Courtès wrote: > The patch below changes the store so that it flushes what it reads from > the substituter’s stderr when it encounters either a newline or a > carriage return. > > The intent is to allow substituters to provide some kind of progress > report, where the status is updated by means of a ‘\r’. What kind of progress report do you mean, and why wouldn't '\n' work for that? > As a side effect, this patch removes the “substituter-name: ” prefix on > the lines that are printed. It can be reinstated if deemed appropriate. Please do, without it there is no indication where the error came from. -- Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Staging branch
On 06/24/2014 02:39 PM, Eelco Dolstra wrote: > The main rule for staging is that it should always be mergeable into master. > So > it should not be used for testing/developing potentially destabilising > features > (e.g. updating GCC to 4.9, or a new X.org release). In my experience, it's typically tricky to judge whether a mass-rebuild change is potentially destabilizing without a full hydra rebuild. When testing new changes, I rebuild what I use frequently, and run on that. It consists of parts of KDE, gtk3 stuff, xfce, some haskell stuff... and even if all these build and run without any problem, I often get many failures on Hydra that aren't trivial to fix. Often it's darwin problems, which is a chapter for itself, but problems on my platform common as well. BTW, currently I'm in the process of stabilizing builds against updated freetype (2.4.x -> 2.5.x, x-updates branch), as the header locations have moved, cmake detection is bogus in this, etc. (e.g. php has problems building, but there are more) Well, we will see. Vlada ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Staging branch
Hi, On 24/06/14 14:46, Luca Bruno wrote: > For example, something like this should go in staging? > https://github.com/NixOS/nixpkgs/pull/3053 Right, that's a perfect candidate for staging. > That you know, is it possible to choose the branch when merging from github? You can specify a target branch when creating a pull request. -- Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Staging branch
On 24/06/2014 14:39, Eelco Dolstra wrote: > Hi, > > I've set up a Nixpkgs/NixOS branch named "staging", intended to bunch changes > that cause rebuilds/redownloads of many packages (such as stdenv changes). The > idea is that this branch can be merged into master periodically (e.g. every > few > weeks). > > The main rule for staging is that it should always be mergeable into master. > So > it should not be used for testing/developing potentially destabilising > features > (e.g. updating GCC to 4.9, or a new X.org release). These should instead go > into > their own feature branches, which can be merged into staging when they are > deemed sufficiently stable. > > The Hydra jobset is here: > > http://hydra.nixos.org/jobset/nixos/staging > For example, something like this should go in staging? https://github.com/NixOS/nixpkgs/pull/3053 That you know, is it possible to choose the branch when merging from github? ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Staging branch
Hi, I've set up a Nixpkgs/NixOS branch named "staging", intended to bunch changes that cause rebuilds/redownloads of many packages (such as stdenv changes). The idea is that this branch can be merged into master periodically (e.g. every few weeks). The main rule for staging is that it should always be mergeable into master. So it should not be used for testing/developing potentially destabilising features (e.g. updating GCC to 4.9, or a new X.org release). These should instead go into their own feature branches, which can be merged into staging when they are deemed sufficiently stable. The Hydra jobset is here: http://hydra.nixos.org/jobset/nixos/staging -- Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] 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] rebuild impact factor
On Tue, Jun 24, 2014 at 10:01 AM, Ludovic Courtès wrote: > 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. I never noticed this script before (it looks very useful!), but I've been following the manual steps listed on https://nixos.org/wiki/Contributing#How_to_verify_that_you_didn.27t_break_a_dependency_or_the_evaluation_by_accident_.3F as a sanity check, which includes a step to rebuild everything affected by the change. I guess it would be a bit lame, but we could use Travis to calculate the amount of rebuilds required. I discussed the possibility of using monitor.nixos.org to calculate this for pull requests with Evgeny (phreedom) on IRC before, but he felt it would be too expensive, and (IIRC) a bit out of scope for the monitor project (which I have been missing greatly for the past number of weeks, I hope it gets well soon!). Cheers, Cillian -- NixOS: The Purely Functional Linux Distribution http://nixos.org ___ 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
On 06/22/2014 04:41 PM, Florian Friesdorf wrote: > Should I move replaceSubstring and interpolateAtAtVars to > lib/strings.nix? Oh, I forgot to reply. Basically my view is that of Eelco. The problem is that these things are run every time you try to install something (transitively) depending on it. Therefore it isn't fit for regular usage (especially in heavily used packages), although it's probably fine for separated tests, which is this case if I skim it correctly. Vlada ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] cabal.mkDerivation and cabal flags
Unfortunately cabal2nix doesn't support flags. I'm going to take a look at hack-nix. On Tue, Jun 24, 2014 at 12:18 PM, Marc Weber wrote: > The problem with flags is that dependencies might change. No idea how > cabal2nix handles this. Maybe you have to rerun it with flag info. > > The alternative is using hack-nix which creates the dependency > information on the fly anyway - but the database might be a little bit > outdated. > > Thus have a look at cabal2nix and hacknix. If you want to give the > latter a try let me know. > > Marc Weber > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > -- http://www.google.com/profiles/iricanaycan ___ 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)
Dear Florian, dear Mateusz,
On 23 June 2014 22:58, Florian Friesdorf wrote:
> szip unfree or not is an issue independent of your pull request. I
> merged - thanks a lot!
Thanks, I'm glad I could add something.
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?
Yes, I think that would be appropriate.
One note, the hdf5 package in all-packages.nix had szip enable by
> default. You need to pass szip = null. See my latest commit to master.
Okay, thanks, I didn't know that.
On 23 June 2014 23:56, Mateusz Kowalczyk wrote:
> Some packages use an if expression for license field. For example:
>
> license = if hdf5 == null then licenses.unfree else licenses.whatever
>
> I don't know whether that's encouraged but it is a way to do it.
No, I don't think this is the right approach in this case. As far as I
know, a dependency does not propagate it's license to the software that
depends on it. That being said, if you want to use szip together with hdf5,
you will have to fulfull both licenses' requirements.
The hdf5 library itself has a license that I would call free. It permits
redistribution in source, or binary form, with or without modification,
basically only requiring that the original copyright notice and license is
shipped along with it [1].
Tables is licensed under a BSD license [2]. I think that one is generally
accepted as a free license.
Only szip has an unfree license, because it doesn't allow for commercial
use [3]. But whether you build hdf5 with or without szip doesn't change the
license of hdf5, or tables.
Best,
Andreas
[1]: http://www.hdfgroup.org/HDF5/doc/Copyright.html
[2]: http://www.pytables.org/moin/FAQ#WhatarePyTables.27licensingterms.3F
[3]: http://www.hdfgroup.org/doc_resource/SZIP/Commercial_szip.html
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] cabal.mkDerivation and cabal flags
The problem with flags is that dependencies might change. No idea how cabal2nix handles this. Maybe you have to rerun it with flag info. The alternative is using hack-nix which creates the dependency information on the fly anyway - but the database might be a little bit outdated. Thus have a look at cabal2nix and hacknix. If you want to give the latter a try let me know. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] cabal.mkDerivation and cabal flags
Hi, Is it possible to provide cabal flags within a derivation? Specifically I need to define a derivation which depends on snapServer built with HOpenSSL (manually I do `cabal install -fopenssl snap-server`)? Regards, -- http://www.google.com/profiles/iricanaycan ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NixOps, MachineDefinition and MachineState
Hi, On 22/06/14 22:46, Michael R wrote: > Looking over and working on NixOps. Can someone tell me what is the rule of > thumb what belongs in MachineDefinition and what belongs in MachineState. In general, everything in the definition will have a corresponding attribute in the state, where the former denotes the desired value and the latter is the actual value of the item. > For example, in virtualbox backend, memorySize is only in the definition and > is > never "stored?" in MachineState. That's essentially a bug/limitation, because it means NixOps won't detect when you change the memory size in the specification and re-run "nixops deploy". So we may want to add a memory_size attribute to the state. -- Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] nixlint or nixflakes?
Hi, On 23/06/14 23:37, Florian Friesdorf wrote: > 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. A while back I created nixpkgs-lint, which mostly checks package names and meta attributes. (It can be installed via "nix-env -i nixpkgs-lint".) It doesn't check syntactic style though. -- Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Variable interpolation in strings read from files
Hi, 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'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). -- Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] rebuild impact factor
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. Ludo’. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
