[Nix-commits] [NixOS/nixpkgs] b424c4: sxiv: Add support for custom config
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: b424c4346568701789b70604b40c389c9d535b1d https://github.com/NixOS/nixpkgs/commit/b424c4346568701789b70604b40c389c9d535b1d Author: Johannes Frankenau <johan...@frankenau.net> Date: 2017-07-03 (Mon, 03 Jul 2017) Changed paths: M pkgs/applications/graphics/sxiv/default.nix Log Message: --- sxiv: Add support for custom config Commit: c31d21c9b1b81cf78e08a85d298d3f09ddc7c0ae https://github.com/NixOS/nixpkgs/commit/c31d21c9b1b81cf78e08a85d298d3f09ddc7c0ae Author: Mateusz Kowalczyk <fuuze...@fuuzetsu.co.uk> Date: 2017-07-03 (Mon, 03 Jul 2017) Changed paths: M pkgs/applications/graphics/sxiv/default.nix Log Message: --- Merge pull request #27090 from jfrankenau/config-sxiv sxiv: Add support for custom config Compare: https://github.com/NixOS/nixpkgs/compare/91e8a6a9ff72...c31d21c9b1b8___ nix-commits mailing list nix-comm...@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 819f99: jenkins: 2.63 -> 2.64
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 819f990feab189b8ac3f5a2f95b5eb4f76cd0895 https://github.com/NixOS/nixpkgs/commit/819f990feab189b8ac3f5a2f95b5eb4f76cd0895 Author: Mateusz Kowalczyk <fuuze...@fuuzetsu.co.uk> Date: 2017-06-06 (Tue, 06 Jun 2017) Changed paths: M pkgs/development/tools/continuous-integration/jenkins/default.nix Log Message: --- jenkins: 2.63 -> 2.64 ___ nix-commits mailing list nix-comm...@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 045515: jenkins: 2.62 -> 2.63
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 045515a54a25a30e98b4c1f8f7945473930be2dc https://github.com/NixOS/nixpkgs/commit/045515a54a25a30e98b4c1f8f7945473930be2dc Author: Mateusz Kowalczyk <fuuze...@fuuzetsu.co.uk> Date: 2017-06-03 (Sat, 03 Jun 2017) Changed paths: M pkgs/development/tools/continuous-integration/jenkins/default.nix Log Message: --- jenkins: 2.62 -> 2.63 ___ nix-commits mailing list nix-comm...@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 668556: Revert "datadog: Properly use configured package."
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 668556331b78b67ca3278a6d7a33af9c6a392c7a https://github.com/NixOS/nixpkgs/commit/668556331b78b67ca3278a6d7a33af9c6a392c7a Author: Mateusz Kowalczyk <fuuze...@fuuzetsu.co.uk> Date: 2017-06-03 (Sat, 03 Jun 2017) Changed paths: M nixos/modules/services/monitoring/dd-agent/dd-agent.nix M pkgs/tools/networking/dd-agent/default.nix Log Message: --- Revert "datadog: Properly use configured package." This reverts commit 50f53da9eff3e7a1686ff439b341ada5bd63ddcd. Commit: dcf171bc79c99ef1326136b5eb49fd81525d6ec5 https://github.com/NixOS/nixpkgs/commit/dcf171bc79c99ef1326136b5eb49fd81525d6ec5 Author: Mateusz Kowalczyk <fuuze...@fuuzetsu.co.uk> Date: 2017-06-03 (Sat, 03 Jun 2017) Changed paths: A nixos/modules/services/monitoring/dd-agent/dd-agent-defaults.nix M nixos/modules/services/monitoring/dd-agent/dd-agent.nix A nixos/modules/services/monitoring/dd-agent/update-dd-agent-defaults M pkgs/tools/networking/dd-agent/default.nix Log Message: --- Revert "dd-agent: 5.11.2 -> 5.13.2 + service rework" This reverts commit af096c8bff1e534be9c69f50eed13e6b48427d0e. Compare: https://github.com/NixOS/nixpkgs/compare/de0d0da1fdb3...dcf171bc79c9___ nix-commits mailing list nix-comm...@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 50f53d: datadog: Properly use configured package.
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 50f53da9eff3e7a1686ff439b341ada5bd63ddcd https://github.com/NixOS/nixpkgs/commit/50f53da9eff3e7a1686ff439b341ada5bd63ddcd Author: Mateusz Kowalczyk <fuuze...@fuuzetsu.co.uk> Date: 2017-06-02 (Fri, 02 Jun 2017) Changed paths: M nixos/modules/services/monitoring/dd-agent/dd-agent.nix M pkgs/tools/networking/dd-agent/default.nix Log Message: --- datadog: Properly use configured package. ___ nix-commits mailing list nix-comm...@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] af096c: dd-agent: 5.11.2 -> 5.13.2 + service rework
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: af096c8bff1e534be9c69f50eed13e6b48427d0e https://github.com/NixOS/nixpkgs/commit/af096c8bff1e534be9c69f50eed13e6b48427d0e Author: Mateusz Kowalczyk <fuuze...@fuuzetsu.co.uk> Date: 2017-06-01 (Thu, 01 Jun 2017) Changed paths: R nixos/modules/services/monitoring/dd-agent/dd-agent-defaults.nix M nixos/modules/services/monitoring/dd-agent/dd-agent.nix R nixos/modules/services/monitoring/dd-agent/update-dd-agent-defaults M pkgs/tools/networking/dd-agent/default.nix Log Message: --- dd-agent: 5.11.2 -> 5.13.2 + service rework ___ nix-commits mailing list nix-comm...@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] c14bf4: irrlicht: link to X11 libs explicitly
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: c14bf4f2b19d64e2cc4ed70fa2bc4f08b4328745 https://github.com/NixOS/nixpkgs/commit/c14bf4f2b19d64e2cc4ed70fa2bc4f08b4328745 Author: Linus Heckemann <g...@sphalerite.org> Date: 2017-05-29 (Mon, 29 May 2017) Changed paths: M pkgs/development/libraries/irrlicht/default.nix Log Message: --- irrlicht: link to X11 libs explicitly This allows applications that require irrlicht to depend on the X libraries implicitly rather than explicitly. Commit: 427f5bcba127f78bb2fabd6b9f625e752229acf3 https://github.com/NixOS/nixpkgs/commit/427f5bcba127f78bb2fabd6b9f625e752229acf3 Author: Mateusz Kowalczyk <fuuze...@fuuzetsu.co.uk> Date: 2017-06-01 (Thu, 01 Jun 2017) Changed paths: M pkgs/development/libraries/irrlicht/default.nix Log Message: --- Merge pull request #26265 from lheckemann/irrlicht-libs irrlicht: link to X11 libs explicitly Compare: https://github.com/NixOS/nixpkgs/compare/120275fd6e6c...427f5bcba127___ nix-commits mailing list nix-comm...@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 809186: SystemdJournal2Gelf.service: new service
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 80918692e1d865e75cb2286705d392f12829f728 https://github.com/NixOS/nixpkgs/commit/80918692e1d865e75cb2286705d392f12829f728 Author: Mateusz Kowalczyk <fuuze...@fuuzetsu.co.uk> Date: 2017-05-25 (Thu, 25 May 2017) Changed paths: M nixos/modules/module-list.nix A nixos/modules/services/logging/SystemdJournal2Gelf.nix Log Message: --- SystemdJournal2Gelf.service: new service ___ nix-commits mailing list nix-comm...@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] a7e861: jenkins: 2.56 -> 2.61
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: a7e861a0588659b1e05502a1cf94de98aeec582d https://github.com/NixOS/nixpkgs/commit/a7e861a0588659b1e05502a1cf94de98aeec582d Author: Mateusz Kowalczyk <fuuze...@fuuzetsu.co.uk> Date: 2017-05-20 (Sat, 20 May 2017) Changed paths: M pkgs/development/tools/continuous-integration/jenkins/default.nix Log Message: --- jenkins: 2.56 -> 2.61 Commit: ef8553ba03fa16be6a3b7542971cf25fc7721ca1 https://github.com/NixOS/nixpkgs/commit/ef8553ba03fa16be6a3b7542971cf25fc7721ca1 Author: Mateusz Kowalczyk <fuuze...@fuuzetsu.co.uk> Date: 2017-05-20 (Sat, 20 May 2017) Changed paths: M pkgs/top-level/python-packages.nix Log Message: --- pythonPackages.python-jenkins: 0.4.11 -> 0.4.14 Commit: a2c900dc879f71a658a5f17d9d83f9e79b25787d https://github.com/NixOS/nixpkgs/commit/a2c900dc879f71a658a5f17d9d83f9e79b25787d Author: Mateusz Kowalczyk <fuuze...@fuuzetsu.co.uk> Date: 2017-05-20 (Sat, 20 May 2017) Changed paths: M nixos/modules/virtualisation/google-compute-image.nix Log Message: --- GCE-service: Update fetch-ssh-keys API usage Commit: 8c0b08d1a43560121eedb19a6c5b157f1faadf96 https://github.com/NixOS/nixpkgs/commit/8c0b08d1a43560121eedb19a6c5b157f1faadf96 Author: Mateusz Kowalczyk <fuuze...@fuuzetsu.co.uk> Date: 2017-05-20 (Sat, 20 May 2017) Changed paths: M pkgs/top-level/python-packages.nix Log Message: --- pythonPackages.jenkins-job-builder: 1.6.1 -> 2.0.0.0b2 Commit: 41ea71a3475174daba0708dae2b365c2dd6f5d30 https://github.com/NixOS/nixpkgs/commit/41ea71a3475174daba0708dae2b365c2dd6f5d30 Author: Mateusz Kowalczyk <fuuze...@fuuzetsu.co.uk> Date: 2017-05-20 (Sat, 20 May 2017) Changed paths: M nixos/modules/services/continuous-integration/jenkins/default.nix Log Message: --- jenkins service: add declarative plugin support Compare: https://github.com/NixOS/nixpkgs/compare/a42c54057ffa...41ea71a34751___ nix-commits mailing list nix-comm...@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-commits
Re: [Nix-dev] Typing nix − funding campaign
On 03/28/2017 10:45 AM, Théophane Hufschmitt wrote: > Hi everyone, > > My internship has now started, and I'll try to post regular updates on > https://typing-nix.regnat.ovh/ as promised. So if you're interested, > just follow the rss :) > >> -- >> Théophane Hufschmitt > Hi, I'm sure you've answered this ad nauseum before but I wonder how you're going to type sets? They are bread-and-butter in nixpkgs. Presumably they will be typed on their fields with the standard subtyping, like anonymous records. Secondly, I wonder about the motivation for the typing of `if` with intersections. It seems counter-intuitive to have it in the type-system. Why not provide an explicit union type as part of some standard library? I would have thought that most people expect `if` to have `Bool -> a -> a -> a` type. Error messages suffer because it becomes unclear whether the caller to `if` is expecting wrong type or the `if` is providing wrong type. I don't think that sort of `if` usage is common in nixpkgs (at least not so common to justify weird typing as opposed to just fixing the uses which in turn could be detected if we don't have this typing rule). If stuff like this is already written somewhere, let me know and I'll RTFM. [1]: https://typing-nix.regnat.ovh/posts/lets-type-nix.html -- Mateusz K. ___ 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 on staging and master
On 07/01/2015 01:01 PM, Luca Bruno wrote: Hello dear nixers, our first and latest ZHF run was very successful. We were able to drop hydra failures from 6000+ failures to almost zero failures! [1] Because the next NixOS stable release will hopefully happen the next month, I'd like to focus on getting the number of failures low again, prioritizing staging for the few next days, and then on master. == Current staging == the latest staging evaluation on hydra is going to have more than 3000 failures [2], compared to about 2500 of trunk [3]. This is mostly due to the fact that staging has seen a great change: failures of build hooks are not ignored anymore. Hence most of those new failures are easily fixable, like a mkdir $out/bin to be changed to mkdir -p $out/bin, or something like that. I invite everyone to contribute to ZHF on staging, well not going to zero, but at least fix packages that previously built (even wrongly) on master without this change. If you find a package that is hard to fix, probably it's not a breakage due to this change. == Future master == Also, once staging will be merged in master, I invite everyone to fix all the failures on hydra in order to release a better new NixOS stable release. Best regards, Note: the ZHF page is a little outdated, will try to update it in the next days, unless someone else does before me. [1] https://nixos.org/wiki/Zero_Hydra_Failures [2] http://hydra.nixos.org/jobset/nixpkgs/staging [3] http://hydra.nixos.org/jobset/nixpkgs/trunk There are many packages that are failing on darwin, some of them with me listed as maintainer. Is there a darwin machine with nix setup that nixpkgs contributors could ssh into to try and debug those packages? -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] No more multi-threaded builds for Haskell libraries
On 06/06/2015 12:53 PM, Peter Simons wrote: Fellow Nix'ers, friendly supporters of the cause from all over the world have run a few thousand Haskell builds in the name of learning more about the effects of our favorite GHC bug [2]. It's fair to say that the CPU cycles invested into this endeavor have been well spent. Here are the results. In our current Nixpkgs setup [3], GHC 7.10.1 generates a correct library ID in 85% of all builds: |+-+--| | builds | correct |% | |+-+--| | 3205 |2727 | 85.1 | |+-+--| The meaning of correct is vague, of course, because we don't know what makes a library ID correct and what not. Therefore, we assume the ID generated by the majority of builds to be correct for the purposes of this experiment. So, a more accurate way of phrasing the result is that 15% of all builds generate an ID other than the one produced by the remaining 85% of the builds. Further investigation suggests that the severity of the divergence depends on the library GHC compiles: |---++-+---| | package | builds | correct | % | |---++-+---| | mtl-2.2.1 |700 | 700 | 100.0 | | text-1.2.0.4 | 1655 |1585 | 95.8 | | aeson-0.8.1.0 |850 | 442 | 52.0 | |---++-+---| mtl is a relatively simple library code-wise, and we've had no diverging IDs for that package at all. The text and aeson libraries are of a different caliber, however. aeson in particular has so many different IDs that it's becoming hard to decide which one we should treat as the correct one! Those aeson builds provides an important insight into the nature of the problem. The following table shows the number of distinct library IDs assigned to aeson per build machine: |---++-| | machine | builds | ids | |---++-| | abbradar.net |100 | 78 | | leroy.geek.nz |100 | 78 | | mango.local |100 | 71 | | work.cryp.to | 50 | 34 | | mobile.cryp.to| 25 | 20 | | mono.rycee.net| 25 | 17 | | archachatina.mtlaa.gebner.org |100 | 1 | | c-cube.bennofs| 25 | 1 | | jude.bio | 25 | 1 | | lin.wiwaxia.se|100 | 1 | | m-nix.wiwaxia.se |100 | 1 | | phreedom |100 | 1 | |---++-| Some machines are all over the place and others generate the same ID every time they compile. It turns out the difference between those machines is the ability to do multi-threaded Haskell builds, i.e. machines that use more than one CPU core appear far more likely to generate diverging library IDs than those compiling the package with one CPU core only. To verify that hypothesis, I've run another set of tests (on a machine with 8 cores but) with multi-threaded Haskell builds disabled. The result is quite clear: |---+--++-+-| | package | system | builds | correct | % | |---+--++-+-| | aeson-0.8.1.0 | x86_64-linux | 1500 |1500 | 100 | | text-1.2.0.4 | x86_64-linux |500 | 500 | 100 | |---+--++-+-| I've thus committed [4] to disable multi-threading in all Haskell library builds. Executables are still compiled utilizing more than one core per Nix build, though. Let's hope the number of broken builds we observe because of this bug henceforth goes down noticeably. The data files used to compute those numbers are available at [1]. Thanks to everyone who contributed to the effort! I believe it's been worthwhile. Let's do this again some time, i.e. when 7.10.2 comes out. :-) A shame but clearly a necessity… Seeing as 7.10.2 is scheduled to come out soon ( 2 weeks), I don't expect a different result unfortunately. Best regards, Peter [1] https://github.com/peti/ghc-library-id-bug [2] https://ghc.haskell.org/trac/ghc/ticket/4012 [3] https://github.com/NixOS/nixpkgs-channels/commit/f93a8ee1105f4cc3770ce339a8c1a4acea3b2fb6 [4] https://github.com/NixOS/nixpkgs/commit/7e04b7319c54bf0a4c0b6b55caca80a3b7434a87 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Nix loves Haskell: the video
On 05/22/2015 10:38 PM, Peter Simons wrote: Hi folks, Rok Garbas kindly organized a NixOS meetup in Berlin the other day [1], and I used the occasion to talk about Haskell NG. The presentation was advertised as: We'll look at how Nix can replace cabal-install in your development workflow to bring you the power of Hackage without the headaches this normally implies. The talk is aimed at beginners and assumes little prior knowledge of Nix or Haskell. Rok recorded the talk and made the video available here: https://www.youtube.com/watch?v=BsBhi_r-OeE You'll find the slides at [2] and all sample code snippets are available at [3]. I hope you'll find this useful! Best regards, Peter [1] http://www.meetup.com/Berlin-NixOS-Meetup/events/222109058/ [2] http://cryp.to/nixos-meetup-3-slides.pdf [3] https://github.com/NixOS/cabal2nix/blob/master/doc/nixos-meetup-3-slides.md ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev Interesting. Shame the recording cut off at the questions. I didn't know you could nix-env -qaP haskellPackages to display the ng package set: we just had a person ask about that in #nixos yesterday! I think it would be worthwhile to cross-post this to haskell-café. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Depending on a service from inside an expression?
Hi, There is a project that as part of its tests has to create a postgresql database which means that the postgres server needs to be running. Is there an easy way to achieve this? How does one go about testing such packages to begin with? -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Using the NixOS Hydra module leads to infinite recursion
On 04/20/2015 12:24 PM, Eelco Dolstra wrote:
Hi,
On 19/04/15 01:20, Mateusz Kowalczyk wrote:
For a while now I've been binding hydra = fetchgit… and then require = [
${hydra}/hydra-module.nix ] later down the file and using the module
options that way. This worked fine but now I get infinite recursion when
I try it. Does anyone know what changed and/or how to fix it?
This is probably due to the changes in
https://github.com/NixOS/nixpkgs/pull/6794. Basically, you can't use anything
from pkgs (such as fetchgit) on the spine of module evaluation (since
pkgs
itself is the result from module system evaluation, hence the infinite
recursion). See https://github.com/NixOS/nixpkgs/issues/7354.
A possible workaround might be to do:
hydra = (import nixpkgs {}).fetchgit { ... };
That way you're not depending on the pkgs module argument.
This works, thank you.
--
Mateusz K.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Switch to GHC 7.10.1 is imminent
On 04/18/2015 08:08 PM, Thomas Hunger wrote: +1 as well. I repeatedly ran into the issue where GHC package hashes changed which IIUC is fixed in 7.10. Can't wait to start testing. Well, I wouldn't say fixed. It's better at least. There are still chances that you'll get different package ID such as in case reported to me recently. Check GHC Trac 4012 for details. And by the way, +1 from me as well FWIW. On 18 April 2015 at 19:11, John Wiegley jo...@newartisans.com wrote: Aycan iRiCAN iricanay...@gmail.com writes: I am -1 on this. Since some of the packages which I depend doesn't compile with ghc 7.10 yet, they need upstream fixes (hans, http-streams, rank1dynamic, jmacro and a few more). Could you please suspend the merge for one more week? OTOH, I can still use haskell-ng.packages.ghc784 if nobody supports my idea. Since 'master' is the branch for development, I'm +1 on this even though it will be disruptive for a while, because it's not going into any release channels. I realize some of us actually use 'master' as our distribution channel, but the Nix project shouldn't be impeded by that use. John -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Using the NixOS Hydra module leads to infinite recursion
Hi,
For a while now I've been binding hydra = fetchgit… and then require = [
${hydra}/hydra-module.nix ] later down the file and using the module
options that way. This worked fine but now I get infinite recursion when
I try it. Does anyone know what changed and/or how to fix it?
[root@yuuki:~]# nixos-rebuild dry-run -I 'nixpkgs=/root/nixpkgs' -I
'nixos=/root/nixpkgs/nixos' --show-trace
building the system configuration...
error: while evaluating the attribute ‘config.system.build.toplevel’ at
/root/nixpkgs/nixos/lib/eval-config.nix:50:5:
while evaluating the attribute ‘config’ at
/root/nixpkgs/lib/modules.nix:82:25:
while evaluating ‘yieldConfig’ at /root/nixpkgs/lib/modules.nix:69:29,
called from /root/nixpkgs/lib/modules.nix:68:16:
while evaluating ‘mergeModules’ at
/root/nixpkgs/lib/modules.nix:160:26, called from
/root/nixpkgs/lib/modules.nix:59:17:
while evaluating ‘mergeModules'’ at
/root/nixpkgs/lib/modules.nix:164:36, called from
/root/nixpkgs/lib/modules.nix:161:5:
while evaluating ‘concatMap’ at /root/nixpkgs/lib/lists.nix:54:18,
called from /root/nixpkgs/lib/modules.nix:200:9:
while evaluating ‘fold’ at /root/nixpkgs/lib/lists.nix:20:19, called
from /root/nixpkgs/lib/modules.nix:59:38:
while evaluating ‘fold'’ at /root/nixpkgs/lib/lists.nix:23:15, called
from /root/nixpkgs/lib/lists.nix:27:8:
while evaluating ‘closeModules’ at
/root/nixpkgs/lib/modules.nix:86:27, called from
/root/nixpkgs/lib/modules.nix:54:16:
while evaluating anonymous function at
/root/nixpkgs/lib/modules.nix:88:49, called from
/root/nixpkgs/lib/lists.nix:49:19:
infinite recursion encountered
--
Mateusz K.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] HaskellNG and taffybar
On 02/24/2015 05:14 PM, Benno Fünfstück wrote: Nixpkgs contains a patched ghc-paths package that allows you to specify the path to ghc at runtime using the NIX_GHC environment variable. This didn't end up working well and dyre's master instead just runs GHC from PATH which also is not great. There is now a patch in nixpkgs that makes dyre itself look in NIX_GHC just like XMonad does and I have made a simple wrapper for Yi which uses this and it works great. I'll be replacing yiCustom that's currently in nixpkgs with new one later today. Luke Clifton ltclif...@gmail.com schrieb am Di., 24. Feb. 2015 03:12: This is also a problem with the Yi editor which also uses Dyre. On 24 February 2015 at 04:18, Kirill Elagin kirela...@gmail.com wrote: Well, the author of the issue I pointed out is correct in saying that they use Dyre which in turn uses ghc-paths. I checked ghc-paths and I believe what they do is store the path to GHC _they were compiled with_. So errr... Looks like we are stuck in a loop. I guess your best bet is to patch Dyre not to use ghc-paths. On Mon Feb 23 2015 at 23:59:51 Arseniy Seroka ars.ser...@gmail.com wrote: 2015-02-23 22:55 GMT+03:00 Kirill Elagin kirela...@gmail.com: Does XMonad work in your case? Can you import `System.Taffybar` in `ghci`? Yes, xmonad works and I can import `System.Taffybar` in ghci. Might it be that, unlike XMonad, they do something more complicated to invoke GHC? I didn’t check the source, but looks like they do. Are you running this on a non-NixOS distro? In that case, the issue https://github.com/simonmar/ghc-paths/issues/4 probably explains what’s going I'm using Nixos. That's what they are doing. [1] [1] https://github.com/travitch/taffybar/blob/master/src/ System/Taffybar.hs#L204 -- Sincerely, Arseniy Seroka -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Use GHC 7.10.1 as default Haskell compiler in nixpkgs
On 04/03/2015 04:31 PM, Mateusz Kowalczyk wrote: On 04/02/2015 11:21 PM, Peter Simons wrote: Hi guys, I believe that we should switch our default compiler to GHC 7.10.1 within the next three or four weeks -- assuming that no major bug is discovered in that compiler. It is true that this update will break some packages, but GHC versions prior to 7.10.x are a disaster for distributions like us because they generate non-deterministic library IDs. This means that two builds running in identical environments can produce outputs that differ and that break binary compatibility when linked by other libraries. This is a nightmare for systems like Hydra, and I've just had to rebuild all our Haskell packages [1] for the umpteenth time because of that bug. GHC 7.10.1 is supposed to fix that issue, so I'd say let's go for it. If not fix, it should be much better at least. If someone hits the problem with 7.10, let me know. Those of you who don't want to update can stick to GHC 7.8.4, of course, it's just that Hydra will no longer provide binaries for that version after the switch. Also, I'd like to remove all code related to the old Haskell package set from Nixpkgs shortly after the switch, to make sure that obsolete code won't make it into the next release branch. If you haven't migrated to Haskell NG yet ... now would be a good time to do it. (I'm looking at you, Agda.) I can update the Agda stuff today. How do you guys feels about that approach? Any concerns? Other suggestions? Best regards, Peter [1] https://github.com/NixOS/nixpkgs/commit/945269a48fa8b91024e18a72b485797eeca308ee ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev …or, well, I would have but the Hackage-available Agda version has the cpphs version issue but from what I can tell, here are the steps to migrate Agda over to haskell-ng: in all-packages.nix change inherits and references to haskellngPackages (AgdaStdlib package). For the ‘agda’ builder, just change the Agda arg to use haskellngPackages.Agda. Then for cleanup, move out the expression for AgdaStdlib to libraries/agda. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Use GHC 7.10.1 as default Haskell compiler in nixpkgs
On 04/02/2015 11:21 PM, Peter Simons wrote: Hi guys, I believe that we should switch our default compiler to GHC 7.10.1 within the next three or four weeks -- assuming that no major bug is discovered in that compiler. It is true that this update will break some packages, but GHC versions prior to 7.10.x are a disaster for distributions like us because they generate non-deterministic library IDs. This means that two builds running in identical environments can produce outputs that differ and that break binary compatibility when linked by other libraries. This is a nightmare for systems like Hydra, and I've just had to rebuild all our Haskell packages [1] for the umpteenth time because of that bug. GHC 7.10.1 is supposed to fix that issue, so I'd say let's go for it. If not fix, it should be much better at least. If someone hits the problem with 7.10, let me know. Those of you who don't want to update can stick to GHC 7.8.4, of course, it's just that Hydra will no longer provide binaries for that version after the switch. Also, I'd like to remove all code related to the old Haskell package set from Nixpkgs shortly after the switch, to make sure that obsolete code won't make it into the next release branch. If you haven't migrated to Haskell NG yet ... now would be a good time to do it. (I'm looking at you, Agda.) I can update the Agda stuff today. How do you guys feels about that approach? Any concerns? Other suggestions? Best regards, Peter [1] https://github.com/NixOS/nixpkgs/commit/945269a48fa8b91024e18a72b485797eeca308ee ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Use GHC 7.10.1 as default Haskell compiler in nixpkgs
On 03/27/2015 04:21 PM, Shea Levy wrote: IMO (and this is not limited to Haskell) we should either always use the latest or, if the latest tends to provide a significantly different experience than the previous version, not have a default at all and require users to request a specific version. We do this for mysql in NixOS for example. On Mar 27, 2015, at 12:17 PM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk wrote: Hi, GHC 7.10.1 was officially released this morning. I wonder what the stance is to switching over to it as a default. If I remember correctly, we switched do 7.8.x very quickly when that came out. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev Right, but at the same time we want binary caches. By ‘default’ I mean mostly ‘the one that Hydra builds all the Haskell packages with’. I have no doubt that we'd do this for multiple versions if the resources allowed but Hydra is bogged down as it is. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Use GHC 7.10.1 as default Haskell compiler in nixpkgs
On 03/27/2015 05:12 PM, Michael Alan Dorman wrote: My understanding is that there may be a number of pkgs that fail to build, for admittedly minor reasons. This is from the Stackage maintainer, who presumably has a high level perspective on this. Mike Where are you seeing this? The only info I can find on this is from the RC stages. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Use GHC 7.10.1 as default Haskell compiler in nixpkgs
Hi, GHC 7.10.1 was officially released this morning. I wonder what the stance is to switching over to it as a default. If I remember correctly, we switched do 7.8.x very quickly when that came out. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] nix-env -i ruby installs bundler, not ruby
On 03/09/2015 04:58 PM, Bjørn Forsman wrote: Hi all, I'm on the stable 14.12 branch and decided to install ruby: $ ruby The program ‘ruby’ is currently not installed. You can install it by typing: nix-env -i ruby But what I get from running nix-env -i ruby is not ruby, it's bundler! Here is a the snippet that shows the issue: $ nix-env -qaP | grep ruby nixos.pkgs.ruby ruby-1.9.3-p547 nixos.pkgs.bundler ruby-1.9.3-p547-bundler-1.7.9 Any rubyists that can fix the naming scheme so installation by name works as expected? - Bjørn ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev Just use -iA, such naming issues are precisely why just -i is not sane and that is on top of how inefficient it is. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Will Haskell-ng and hackage2nix allow building *any* versions of deps?
On 02/25/2015 03:01 AM, Anthony Cowley wrote: This almost certainly isn't ready for release, but I'd like to avoid duplicating efforts if other people want to work on it... Here is cabbage https://github.com/acowley/cabbage It is a tool for doing the obvious thing: use the cabal solver to find a build plan, then build the specific version of each package, and then link them into the sandbox in the current directory. As I said, this script has every warning tape and flashing light imaginable attached to it. I've used it to install ghc-mod, pandoc, hakyll, a bunch of web things like amazonka, and my Frames package with all its demos (involving Chart, diagrams, JuicyPixels, and who knows what else). There are missing pieces outlined in the Tasks list at the end of the Org file that is the source code for the script. I would more than welcome contributions as this is how I would like to use Nix with Cabal, and getting help from like-minded folks would be a big boost! Anthony While interesting, I feel it is doing too much and using the wrong tooling at least for me. I have the power of nix-shell, I don't want to be using ‘cabal sandbox’ on top of it, that very much goes against all the benefits of using nix-shell to begin with. I don't call ‘cabal’ manually pretty much ever unless it's ‘cabal update’ though I know of cases where you still might prefer cabal repl over ghci, something I hopefully won't have to deal with. I think a simpler solution from the user experience perspective is if we can do something like ‘hackage2nix myproject.cabal’ which runs through the cabal solver and then spits out hackage-packages.nix with only the stuff that is needed with versions that are needed. We can now happily use this package set in our shell.nix or whatever just like we do today with manually written package sets. If it can do that then everything else works just like it does today already which is a good thing ;). If I want to do this today then I nix-build a package, see what version in complains about, add the package to the project's set and repeat until physically ill. On Tue, Feb 24, 2015 at 5:38 PM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk wrote: On 02/22/2015 12:04 PM, Peter Simons wrote: Hi Cody, haskellngPackages doesn't seem to have all versions of all dependencies... I'm not sure what you mean by all versions of all dependencies. Dependencies of what exactly? The way I understand the term, dependency has meaning only as a relationship between two packages, i.e. transformers is a dependency of mtl. I'm not sure how to apply that interpretation to your question? If you're asking why hackage-packages.nix doesn't contain every single version of every package registered on Hackage, then the answer is because that would be a database containing well over 50,000 packages, the vast majority of which no-one will ever care about (nor will they ever compile). So it seems pointless to distribute all that stuff as part of Nixpkgs. Best regards, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev A related question: is there a way to generate a package list containing exactly the versions of dependencies we require? Say we have a package with cabal file A == 1.0 B 2.0 C 0.5 but the latest Hackage has versions lower and higher c and that's what is in nixpkgs. I found myself wishing that there was an easy to just say ‘give me a set of packages that's valid from cabal's point of view’ rather than what we currently tend to do which is ‘include latest versions of everything, jailbreak and hope it works’ which is fine for nixpkgs but subpar if we just want that one project working but it requires specific versions of dependencies. -- Mateusz K. ___ 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 -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Will Haskell-ng and hackage2nix allow building *any* versions of deps?
On 02/22/2015 12:04 PM, Peter Simons wrote: Hi Cody, haskellngPackages doesn't seem to have all versions of all dependencies... I'm not sure what you mean by all versions of all dependencies. Dependencies of what exactly? The way I understand the term, dependency has meaning only as a relationship between two packages, i.e. transformers is a dependency of mtl. I'm not sure how to apply that interpretation to your question? If you're asking why hackage-packages.nix doesn't contain every single version of every package registered on Hackage, then the answer is because that would be a database containing well over 50,000 packages, the vast majority of which no-one will ever care about (nor will they ever compile). So it seems pointless to distribute all that stuff as part of Nixpkgs. Best regards, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev A related question: is there a way to generate a package list containing exactly the versions of dependencies we require? Say we have a package with cabal file A == 1.0 B 2.0 C 0.5 but the latest Hackage has versions lower and higher c and that's what is in nixpkgs. I found myself wishing that there was an easy to just say ‘give me a set of packages that's valid from cabal's point of view’ rather than what we currently tend to do which is ‘include latest versions of everything, jailbreak and hope it works’ which is fine for nixpkgs but subpar if we just want that one project working but it requires specific versions of dependencies. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] strongSwan problem
On 02/10/2015 04:22 PM, Bas van Dijk wrote: I was wondering if somebody here has experience with strongSwan on NixOS. I'm having a problem connecting to a gateway as I described in the following mail to the strongSwan mailinglist: https://lists.strongswan.org/pipermail/users/2015-February/007422.html Cheers, Bas ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev From the e-mail: I solved the no netkey IPsec stack detected errors. It turned out that the NixOS strongSwan conf I actually hit this before while attempting to use strongSwan myself. Maybe we should file an issue… -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] [Haskell NG] Equivalent of the old eval $configurePhase eval $buildPhase eval $checkPhase ?
On 01/23/2015 07:57 AM, Peter Simons wrote: Hi Mateusz, Does http://permalink.gmane.org/gmane.linux.distributions.nixos/15524 help? Yes though it seems that we now need to update two files when making any changes: default.nix so that we can callPackage it in overrides and such (for example if it's a private package) and shell.nix so that we can enter sane environment. I'm not sure what you mean. The number of files that you have to change to accomplish non-standard behavior should not be different from what it fwas before, i.e. the use of nix-shell certainly shouldn't have gotten more complicated than it was. Could you please elaborate a little how you've used nix-shell before and why that particular use-case won't now work anymore? Previously we could simply cabal2nix into default.nix and from shell.nix callPackage ./. in simple case or add any extra shell-only settings in there. Now it seems that if I add a dependency I need to regenerate both files which is not fun if we have written any customisation. Am I wrong? Previously, you generated a default.nix file with cabal2nix and ran that from a hand-written shell.nix file. Why do you think that this use-case is no longer possible? What exactly do you mean by re-generating both files? I merely meant that a ‘simple’ callPackage did not work (dependency problems) but Richard Wallace set it straight for me now: adding .env pretty much let's me use my old setup. So that part is solved. Another downside is that manual use of Setup won't inherit flags specified in the expression: we manually have to --enable-testsuite whereas eval $configurePhase would do that for use when doCheck = true;. It never occurred to me to configure interactive builds with the same flags Nixpkgs uses, because the default builder sets options that I wouldn't want (--prefix=$out) while leaving out flags that I would want (--ghc-option=-j). If you think this is important, then we can define a shell variable in the interactive environment, say $configureFlags, that you can pass to ./Setup or cabal during the configure phase. Would you like that? That sounds useful. Note that you can always use the old-style nix-shell approach and run the default builder, i.e.: $ cabal get haddock $ cd haddock-2.15.0.2 $ nix-shell --pure ~/.nix-defexpr -A haskellngPackages.haddock $ runHook setupCompilerEnvironmentPhase runHook jailbreakPhase runHook compileBuildDriverPhase $ eval $configurePhase eval $buildPhase eval $checkPhase We could also add the runHook setupCompilerEnvironmentPhase ... bit to the nix-shell variable in the build environment so that these commands are run automatically when you enter the interactive environment. Does that sound useful? This also sounds useful. I think this solves all my ‘problems’ for now. Thank you for all your work! I hope this helps, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] [Haskell NG] Equivalent of the old eval $configurePhase eval $buildPhase eval $checkPhase ?
On 01/22/2015 05:52 PM, Mateusz Kowalczyk wrote:
Hi,
Before haskell-ng my workflow to check that everything is OK in a
package was to nix-shell and run the above commands. I could also
rebuild and run tests again that way but apparently that no longer
works: even Setup file is no longer compiled. ‘genericBuild’ only works
for installations which is not what I'm after.
What's the new in-shell workflow?
It was suggested that I should ghc --make Setup and Setup
configure/build/test but for expression given at the bottom, it fails:
[nix-shell:~/programming/haddock]$ ./Setup configure
Configuring haddock-2.16.0...
Setup: At least the following dependencies are missing:
haddock-api ==2.16.0
but nix-building the package works fine.
Expr:
[nix-shell:~/programming/haddock]$ cat default.nix
{ mkDerivation, base, Cabal, directory, filepath, haddock-api
, process, stdenv
}:
mkDerivation {
pname = haddock;
version = 2.16.0;
src = /home/shana/programming/haddock;
isLibrary = false;
isExecutable = true;
buildDepends = [ base haddock-api ];
testDepends = [ base Cabal directory filepath process ];
preCheck = unset GHC_PACKAGE_PATH;
homepage = http://www.haskell.org/haddock/;;
description = A documentation-generation tool for Haskell libraries;
license = stdenv.lib.licenses.bsd3;
maintainers = with stdenv.lib.maintainers; [ fuuzetsu ];
}
--
Mateusz K.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] [Haskell NG] Equivalent of the old eval $configurePhase eval $buildPhase eval $checkPhase ?
On 01/22/2015 09:54 PM, Peter Simons wrote: Hi Mateusz, What's the new in-shell workflow? Does http://permalink.gmane.org/gmane.linux.distributions.nixos/15524 help? Best regards, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev Yes though it seems that we now need to update two files when making any changes: default.nix so that we can callPackage it in overrides and such (for example if it's a private package) and shell.nix so that we can enter sane environment. Previously we could simply cabal2nix into default.nix and from shell.nix callPackage ./. in simple case or add any extra shell-only settings in there. Now it seems that if I add a dependency I need to regenerate both files which is not fun if we have written any customisation. Am I wrong? Nevetheless, I got on fine once I figured out I need a fancier shell.nix such as one cabal2nix gave me. Another downside is that manual use of Setup won't inherit flags specified in the expression: we manually have to --enable-testsuite whereas eval $configurePhase would do that for use when doCheck = true;. So overall it seems to me that there is a bit more manual work involved though things seem nicer in general so far. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] [Haskell NG] Equivalent of the old eval $configurePhase eval $buildPhase eval $checkPhase ?
Hi, Before haskell-ng my workflow to check that everything is OK in a package was to nix-shell and run the above commands. I could also rebuild and run tests again that way but apparently that no longer works: even Setup file is no longer compiled. ‘genericBuild’ only works for installations which is not what I'm after. What's the new in-shell workflow? -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] A Journey into the Haskell NG infrastructure: Part I
On 01/09/2015 10:27 PM, Thomas Hunger wrote:
One thing that'd be useful is documenting how
pkgs/development/haskell-modules/hackage-packages.nix is regenerated and
how to fix common issues.
E.g. disabling tests done by overriding a package in
haskell-modules/configuration-common.nix. But I don't understand how to
retain a specific version of a package (e.g. you have time_1_5_0_1 in
there, how did you do that?).
~
I second the request for a few words of how the nixpkgs collaborators
should now work with adding/fixing/updating/retaining the Haskell
package set. In the past it was cabal2nix the package, stick it in
libraries and add to haskell-packages.nix . What is it now?
On 9 January 2015 at 18:11, Peter Simons sim...@cryp.to wrote:
Hi Thomas,
I changed my sandbox code to look like the following. Is that how it's
intended to be used?
yes, exactly. That's a very nice example. You can put that definition into
a
file, say shell.nix, and run
$ nix-shell --pure shell.nix
to obtain an interactive environment that contains the compiler defined
above.
If you want to go all out, you can also add a shellHook attribute to make
nix-shell define the magic environment variables that tell the 'ghc-paths'
package how to use your environment. For example:
| { pkgs ? (import nixpkgs {}).pkgs }:
|
| let
|
| env = pkgs.haskellngPackages.ghcWithPackages (p: with p; [
| text mtl transformers warp cabal-install
| ]);
|
| in
|
| pkgs.stdenv.mkDerivation {
| name = hello-world-wide-web;
| buildInputs = [ env ];
| shellHook = ''
| export NIX_GHC=${env}/bin/ghc
| export NIX_GHCPKG=${env}/bin/ghc-pkg
| export NIX_GHC_DOCDIR=${env}/share/doc/ghc/html
| export NIX_GHC_LIBDIR=$( $NIX_GHC --print-libdir )
| '';
| }
Best regards,
Peter
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
--
Mateusz K.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Nix as an Erlang Package Manager
On 12/31/2014 02:29 AM, Eric des Courtis wrote: It seems many people on the Erlang mailing list have been contemplating using Nix as the official Erlang package manager. I think it's an interesting idea worth exploring. Could someone from the Nix team jump in and take a look? Perhaps make some suggestions? http://erlang.org/pipermail/erlang-questions/2014-December/082119.html (Thread root) http://erlang.org/pipermail/erlang-questions/2014-December/082270.html (Comments from Joe Armstrong one of the designers of the Erlang programming language) Eric The server is down for those URLs so I'll just pipe in in here: I think using nix as a package manager for Erlang or another language is a great idea. I package Agda stuff in nixpkgs (though there is not a lot of libraries available around) and Agda does not have a package manager. It works out fine IMHO and I certainly prefer to please one package manager/build system than two. There is of course an advantage that language-specific systems have over things like nix: nix is effectively a self-contained system, it will grab all the build dependencies like GCC itself while things like Haskell's cabal c do nothing but Haskell and make the user fulfill system dependencies by hand or alternatively use Haskell from their system's package manager. Most people already have GCC so questions like ‘why do I have to get it again’ might arise. I guess it just depends whether Erlang folk is ready to accept that they will be incurring the weight of a second, full-fledged package manager on their system. Of course my hopes as nix advocate is that they will embrace it and maybe even make it their main one after a while ;). -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Help with ghc errors after nix-channel --update
On 12/06/2014 05:29 PM, Carlo Nucera wrote: Hi Peter I added this snippet to my ~/.nix-packages/config.nix ghcTestEnv = self.haskellPackages_ghc783.ghcWithPackages (p: with p; [ mtl ]); and ran: $ nix-env -p /tmp/haskell -iA ghcTestEnv $ /tmp/haskell/bin/ghci Prelude import Control.Monad.State.Lazy These commands worked well. However, when adding abcnotation, it complains rightfully that it doesn't know what we are talking about: error: undefined variable `abcnotation' at /home/carlo/settings/nix-local/config.nix:34:5 this happens probably because I wrote the nix expression for abcnotation, and it's not yet present in the channel. What would be the right way to add an expression made by me in this setup? Generally speaking, ghc-wrapper is fundamentally broken and many discerning Nix hackers gave up using it entirely a long time ago (precisely because of the kind of trouble that you seem to be having). More generally, I'd like a configuration in which I'm able to: 1) install packages from nixos-unstable, 2) from a nixpkgs local repo, 3) from expressions mantained by me 4) using ghc-mod and similar in emacs Regrettably, I really don't know how to set up such a thing. Before I copied the configuration I'm using (from Fuuzetsu), I was using a function like ghcWithPackages similar to the one you proposed, but I was unable to integrate that with things packaged by me (and so I switched). I never use nix-env -i for Haskell stuff, it just does not end well. Can you point me towards some dotFiles that obtaining what I'm searching for with the ghcWithPackages function? Best regards, Carlo My personal advice is to purge everything Haskell related from nix-env and start using nix-shell/nix-build only. Maybe you have done so already, I have not finished reading all the replies yet. 2014-12-06 18:04 GMT+01:00 Peter Simons sim...@cryp.to: Hi Carlo, ghc-pkg check is full of errors I don't think that ghc-pkg check ever succeeded in any ghc-wrapper based installation. packages I installed no longer load in ghci There is no obvious explanation for the errors you've described. As random suggestion how you might obtain some additional insight, you could add ghcTestEnv = self.haskellPackages_ghc783.ghcWithPackages (p: with p; [ mtl ]); to your ~/.nix-pkgs/config.nix and then run: $ nix-env -p /tmp/haskell -iA ghcTestEnv $ /tmp/haskell/ghci Prelude import Control.Monad.State.Lazy Does that succeed? If it does, you try adding 'abcnotation', too, to see whether that makes a difference. Generally speaking, ghc-wrapper is fundamentally broken and many discerning Nix hackers gave up using it entirely a long time ago (precisely because of the kind of trouble that you seem to be having). Best regards, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Breaking changes log
On 12/17/2014 01:55 PM, Wout Mertens wrote: Nice though it seems a bit complex. Not sure if it's over-engineered or just what's needed. Also interesting: *There have been complaints regarding the comprehensibility of some upgrade notices and news items in the past. This is understandable — not every Gentoo developer speaks English as a first language. However, for the sake of clarity, professionalism and avoiding making us look like prats, it is important that any language problems be corrected before inflicting a news item upon end users.* *Thus, at least 72 hours before a proposed news item is committed, it must be posted to the gentoo-dev mailing list and Cc:ed to p...@gentoo.org p...@gentoo.org (exceptions may be made in exceptional circumstances). Any complaints — for example regarding wording, clarity or accuracy — must be addressed before the news item goes live.* shudder Wout. This is just administrative mongering, no need to adopt it fully. I agree that either some kind of news system should be in place: currently I think the only thing we have going is putting ‘trace’ somewhere and hoping the user catches it. In any case, I think calling it ‘news’ is misled: in Gentoo news are used for longer term things, say distro moving off from Ruby 1.x for it's default or whatever. But maybe that's what OP wants. Personally I want to be able to emit a message from a package such as ‘XYZ flags have changed, you need to do such and such thing’ or ‘extra user interaction is needed to get this package to work, put this thing in such and such directory under $HOME’. Gentoo's portage does this, such things print during the package build (not always applicable) and at the end of the builds. I can see multiple problems here in that unlike with Gentoo, we often fetch multiple different versions of same software as various dependencies, the user is rarely directly using it all. I don't know how to deal with this properly. Maybe it's just a bad idea for nix. On Wed Dec 17 2014 at 2:45:31 PM Oliver Charles ol...@ocharles.org.uk wrote: One thing I really like is Gentoo's news feature - which seems to be discussed in detail at http://wiki.gentoo.org/wiki/GLEP:42. Maybe something like that is what you're envisioning? -- ocharles On Wed, Dec 17, 2014 at 1:27 PM, Wout Mertens wout.mert...@gmail.com wrote: Would it be nice if we kept a file with breaking changes? That way, nixos-rebuild should be able to list the breaking changes between the current version of the channel and the last time the system was built. We'd also have the full list of breakage for release notes. Thoughts? What would such a log look like? Cheers, Wout. ___ 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 -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Our Haskell setup no longer works with GHC HEAD/soon 7.10
Hi,
If you build the existing (outdated) GHC HEAD expression from nixpkgs
then you'll find that GHC itself works fine. The problem is that it no
longer works for packages. If we try to build any package with recent
GHC, we'll encounter something like:
…
[17 of 17] Compiling Main ( HsColour.hs,
dist/build/HsColour/HsColour-tmp/Main.o )
HsColour.hs:71:1: Warning: Tab character
Linking dist/build/HsColour/HsColour ...
Running Haddock for hscolour-1.20.3...
Preprocessing library hscolour-1.20.3...
haddock: internal error: ./package.cache: openBinaryFile: does not exist
(No such file or directory)
builder for
`/nix/store/l25ci5b58i6jrfg8pgsdgx6didmwdrns-haskell-hscolour-ghcHEAD-1.20.3.drv'
failed with exit code 1
error: build of
`/nix/store/l25ci5b58i6jrfg8pgsdgx6didmwdrns-haskell-hscolour-ghcHEAD-1.20.3.drv'
failed
/run/current-system/sw/bin/nix-shell: failed to build all dependencies
The above is for hscolourBootstrap which is pretty much always going to
be built first. I'm also using an actually recent GHC checkout I got
manually. If you're doing that then you'll need
libraries/integer-gmp2_CONFIGURE_OPTS +=
--configure-option=--with-gmp-libraries=${gmp}/lib
libraries/integer-gmp2_CONFIGURE_OPTS +=
--configure-option=--with-gmp-includes=${gmp}/include
in buildMK now. I can update the expression in nixpkgs upon request: the
current version will produce slightly different error.
In any case, this is a problem for us (Haskell users) because this is
probably how GHC 7.10 will come out: in fact I am hitting this when
trying to use it for some Haddock merges to push 7.10 RC forwards… It
was suggested to me that perhaps the used Cabal library version is too
old or cabal-install was built with too old version but AFAICT we don't
use cabal-install and the used Cabal is that from GHC tree.
My time is unfortunately very limited this month so I am writing here in
case someone wants to jump in and start figuring this out. If it's not
figured out now then it will potentially slow down the GHC 7.10 adoption
in nixpkgs.
--
Mateusz K.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Our Haskell setup no longer works with GHC HEAD/soon 7.10
On 12/11/2014 10:36 AM, Mateusz Kowalczyk wrote:
Hi,
If you build the existing (outdated) GHC HEAD expression from nixpkgs
then you'll find that GHC itself works fine. The problem is that it no
longer works for packages. If we try to build any package with recent
GHC, we'll encounter something like:
…
[17 of 17] Compiling Main ( HsColour.hs,
dist/build/HsColour/HsColour-tmp/Main.o )
HsColour.hs:71:1: Warning: Tab character
Linking dist/build/HsColour/HsColour ...
Running Haddock for hscolour-1.20.3...
Preprocessing library hscolour-1.20.3...
haddock: internal error: ./package.cache: openBinaryFile: does not exist
(No such file or directory)
builder for
`/nix/store/l25ci5b58i6jrfg8pgsdgx6didmwdrns-haskell-hscolour-ghcHEAD-1.20.3.drv'
failed with exit code 1
error: build of
`/nix/store/l25ci5b58i6jrfg8pgsdgx6didmwdrns-haskell-hscolour-ghcHEAD-1.20.3.drv'
failed
/run/current-system/sw/bin/nix-shell: failed to build all dependencies
The above is for hscolourBootstrap which is pretty much always going to
be built first. I'm also using an actually recent GHC checkout I got
manually. If you're doing that then you'll need
libraries/integer-gmp2_CONFIGURE_OPTS +=
--configure-option=--with-gmp-libraries=${gmp}/lib
libraries/integer-gmp2_CONFIGURE_OPTS +=
--configure-option=--with-gmp-includes=${gmp}/include
in buildMK now. I can update the expression in nixpkgs upon request: the
current version will produce slightly different error.
In any case, this is a problem for us (Haskell users) because this is
probably how GHC 7.10 will come out: in fact I am hitting this when
trying to use it for some Haddock merges to push 7.10 RC forwards… It
was suggested to me that perhaps the used Cabal library version is too
old or cabal-install was built with too old version but AFAICT we don't
use cabal-install and the used Cabal is that from GHC tree.
My time is unfortunately very limited this month so I am writing here in
case someone wants to jump in and start figuring this out. If it's not
figured out now then it will potentially slow down the GHC 7.10 adoption
in nixpkgs.
Oh, one more thing I forgot to say: there *are* big cabal changes
happening from 7.8.3 to 7.10.x so it's not like this is due to some
weird bug somewhere; rather, we need to adapt to the new way things are
done and investigating what this involves is precisely what needs
figuring out ;)
--
Mateusz K.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] My new email signature
On 11/17/2014 11:45 PM, Luca Bruno wrote: Does it look good on your email clients? :) ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev Thunderbird http://fuuzetsu.co.uk/images/1416303666.png -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Make wrappers be binaries instead of shell scripts?
On 11/18/2014 01:32 PM, Wout Mertens wrote: Hi all, I'm wondering if it wouldn't be better to make the application wrapper scripts generated by makeWrapper be binaries that do the environment massaging and config in binary code before exec() ing the wrapped program. The advantages would be that the wrapper itself loads very fast since all the shell init and shell parsing is skipped. You also get precise control over the execv() call or other desired factors. The disadvantages are that you can't read what a wrapper does and the wrapper file is bigger (about 4KB in my tests for a simple execv()). Thoughts? Wout. As long as it's optional: debugging wrappers does happen and if it's binary then there's no hope. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Terminfo issues with haskell 'vty' package nix-shell
On 11/13/2014 04:20 PM, Michael Jones wrote:
Hi,
I hope this is the right list. I'm very new to nix and trying to get a set
up working on Ubuntu 14.04 for a small haskell project I have. I use
rxvt-unicode as a shell which generally seems to work fine but when I run
`nix-shell` in a directly with the following `default.nix` file:
{ haskellPackages ? (import nixpkgs {}).haskellPackages }:
let
inherit (haskellPackages);
in
with haskellPackages; cabal.mkDerivation (self: {
pname = jump;
version = 0.0.0;
src = ./.;
buildDepends = with haskellPackages; [ vty ];
buildTools = with haskellPackages; [ cabalInstall ];
})
I get the following error when running `tput`:
[nix-shell:~/root/projects/jump]$ tput setaf 7
tput: unknown terminal rxvt-unicode
I'm afraid I'm sufficiently clueless that I don't know how to deal with
this. I'm guessing that the terminfo information for nix's bash needs to be
in another folder and that the haskell 'vty' package's dependency on
ncurses might be confusing things. Does anyone have any recommendations on
how to investigate this further? I love the idea of nix and I'd like to get
past this.
My rxvt-unicode is from Ubuntu rather than a nix install. I did try to
install it from nix using the recommendation from
http://nixos.org/nixos/packages.html but I get:
$ nix-env -iA nixos.pkgs.rxvt_unicode
error: attribute ‘nixos’ in selection path ‘nixos.pkgs.rxvt_unicode’ not
found
Any further help would also be appreciated :)
Cheers,
Michael
I always deal with this just be using TERM=xterm in nix-shell in front
of the commands I need this. Hack but I haven't had problems yet.
--
Mateusz K.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] GHC Panic with basic Yesod project under Nix
On 11/14/2014 09:40 PM, Michael Jones wrote:
Hi,
Not sure where to send this so thought I'd try here to see if anyone has
the same trouble. I'm new to nix and new to Yesod and trying to build the
default Yesod project with 'yesod devel' in a new shell.
My steps are:
1. Create a new directory with default.nix:
{ haskellPackages ? (import nixpkgs {}).haskellPackages }:
let inherit (haskellPackages);
in with haskellPackages; cabal.mkDerivation (self: {
pname = cal;
version = 0.0.1;
src = ./.;
buildDepends = with haskellPackages; [
yesod yesodStatic yesodTest
yesodBin
hjsmin persistentSqlite hspec
];
buildTools = with haskellPackages; [ cabalInstall ];
})
2. Run 'nix-shell'
3. Run 'yesod init' fill in project-name
4. 'cd project-name'
5. 'yesod devel'
Fails with:
Yesod devel server. Press ENTER to quit
Resolving dependencies...
Configuring tmp-0.0.0...
Forcing recompile for ./Foundation.hs because of config/routes
Forcing recompile for ./Foundation.hs because of messages/en.msg
Forcing recompile for ./Foundation.hs because of
templates/default-layout-wrapper.hamlet
Forcing recompile for ./Foundation.hs because of
templates/default-layout.hamlet
Forcing recompile for ./Handler/Home.hs because of templates/homepage.hamlet
Forcing recompile for ./Handler/Home.hs because of templates/homepage.julius
Forcing recompile for ./Handler/Home.hs because of templates/homepage.lucius
Rebuilding application... (using cabal)
ghc: panic! (the 'impossible' happened)
(GHC version 7.8.3 for x86_64-unknown-linux):
Loading temp shared object failed:
/run/user/1000/ghc11470_0/ghc11470_25.so: failed to map segment from shared
object: Operation not permitted
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Is anyone in a position to offer advice? I've run:
nix-channel --update
as well to hopefully get the latest?
Any help would be much appreciated,
Michael
I believe abraddar on IRC uses Yesod successfully, it may be worthwhile
to ping him.
In general I think that error means that something has gone pretty badly
and it's an error from ld rather than GHC.
I wonder if ‘eval $configurePhase’ before ‘yesod devel’ would help.
Likewise, I wonder whether ‘eval $buildPhase’ would work: it may at
least help to narrow down where things are going wrong.
If you can increase verbosity from Yesod output then it should help
debugging too.
For all of this, please run in nix-shell --pure.
--
Mateusz K.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Haskell Platform, anyone?
On 11/07/2014 07:11 PM, Peter Simons wrote: Hi guys, Haskell Platform 2014.2.0.0 has been released a while ago, and I can't help noticing that no-one seems to be in a hurry to add that to Nixpkgs. Apparently, there not much of a demand for Haskell Platform in Nix? This makes me wonder about the old HP releases that we still have: 2009.2.0.2, 2010.1.0.0, 2010.2.0.0, 2011.2.0.0, 2011.2.0.1, 2011.4.0.0, 2012.2.0.0, 2012.4.0.0, and 2013.2.0.0. All of those builds were pretty much non-functional until recently because none of them actually installed a compiler into the user profile, but no-one noticed that for a period of several months. Having those old versions around forces us to keep ancient versions of many HP member packages like HTTP, mtl, vector, etc., too, and that adds a bit of complexity to Nixpkgs. Since no-one seems to *use* that stuff, I'm tempted to say that we should drop support for Haskell Platform altogether and to throw out all these ancient package versions in the process. How do others feel about that? Do you desperately want to be able to install Haskell Platform 2010.2.0.0 any time soon? Best regards, Peter I think the only reason why anyone using nix would want HP is to make sure their program compiles using it. I think HP 2014 is just not popular enough yet to be targeted. There's always Travis CI and whatnot for double-checking I guess. We probably could just drop it: if someone wants to still use it, they can revive it from git and/or pin the versions themselves. I do think it might be worthwhile to provide HP 2014 eventually, but only ‘in spirit’: pin library versions as they appear in the HP rather than trying to build their official package. Maybe that's what's done already for older versions, I haven't checked. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] configurations repository
On 11/04/2014 09:13 PM, Arseniy Seroka wrote: That's awesome idea. But I think we have to add lots of comments to this examples (that help a lot while using live code). Or maybe just provide some ideal configs with comments and other without them. It's impossible to tell what you're replying to, especially as you ar top-posting. On 4 November 2014 23:07:04 nix-dev-requ...@lists.science.uu.nl wrote: Send nix-dev mailing list submissions to nix-dev@lists.science.uu.nl To subscribe or unsubscribe via the World Wide Web, visit http://lists.science.uu.nl/mailman/listinfo/nix-dev or, via email, send a message with subject or body 'help' to nix-dev-requ...@lists.science.uu.nl You can reach the person managing the list at nix-dev-ow...@lists.science.uu.nl When replying, please edit your Subject line so it is more specific than Re: Contents of nix-dev digest... Today's Topics: 1. Hydra failure types and Nix support (Michael Raskin) 2. [***SPAM***] configurations repository (Michael Raskin) 3. Fwd: Re: NixOS Live CD (Graphic) Boot Failure (J. Brian Kelley) 4. Re: Fwd: Re: NixOS Live CD (Graphic) Boot Failure (Vladim?r ?un?t) 5. Re: NixOS Live CD (Graphic) Boot Failure (J. Brian Kelley) 6. Re: NixOS Live CD (Graphic) Boot Failure (Wout Mertens) 7. Re: deploying nix-built software to non-nix linux systems (Paul Colomiets) -- Message: 1 Date: Tue, 04 Nov 2014 18:35:06 +0300 From: Michael Raskin 7c6f4...@mail.ru Subject: [Nix-dev] Hydra failure types and Nix support To: nix-dev@lists.science.uu.nl Message-ID: e1xlg1e-0004dp-8t.7c6f434c-mail...@smtp26.mail.ru Content-Type: text/plain; charset=UTF-8 16596922 mda_lv2.i686-linux 16591197 mongodb.x86_64-linux 16599836 qbittorrent.i686-linux 16599870 qbittorrent.x86_64-linux 16590792 syslogng_incubator.i686-linux 16604362 syslogng_incubator.x86_64-linux Of these I think that all failures except mongo are transient, and mongo has just declared that 10GiB /tmp/ is too small ? rebuilding with a larger /tmp/ to check. 1. Hydra seems to merge ?new failures? and ?still failing? in the same tab. It may be what we want, but is it intended to call the tab ?still failing?? 2. Apparently real failures end with ?builder failed with code ??. Should the failures without that line be marked in a different way? And yes, mda_lv2, qbittorrent and syslogng_incubator can be restarted? -- Message: 2 Date: Tue, 04 Nov 2014 19:00:31 +0300 From: Michael Raskin 7c6f4...@mail.ru Subject: [Nix-dev] [***SPAM***] configurations repository To: nix-dev@lists.science.uu.nl Message-ID: e1xlgqf-0004cc-qs.7c6f434c-mail...@smtp45.i.mail.ru Content-Type: text/plain; charset=UTF-8 Previously we had configurations repository in SVN. I even continued to update my configuration there long after Git migration. Its useful function was that I could easily give a link like ?see viric's configuration?. I don't think comprehensiveness is that important for such a repository, but as we currently have 50 committers, if half of use commits some of our configurations, it would again be a useful collection of examples of live Nix use. Should we create it (with the same permissions as NixPkgs, probably)? I always consider such live documentation a good thing for initial evaluation of a language? -- Message: 3 Date: Tue, 04 Nov 2014 12:26:32 -0500 From: J. Brian Kelley j...@teksavvy.com Subject: [Nix-dev] Fwd: Re: NixOS Live CD (Graphic) Boot Failure To: Wout Mertens wout.mert...@gmail.com Cc: nix-dev nix-dev@lists.science.uu.nl Message-ID: 54590c48.1000...@teksavvy.com Content-Type: text/plain; charset=utf-8; format=flowed Well, I reinstalled Linux Mint 17 (went smoothly) and sadly there is no /proc/config.gz . Is there any means to direct the screen output to my usb flash drive? Or at least stop it scrolling until I have had a chance to read things? Is there possibly a debug option that can be invoked? -- Message: 4 Date: Tue, 04 Nov 2014 18:35:16 +0100 From: Vladim?r ?un?t vcu...@gmail.com Subject: Re: [Nix-dev] Fwd: Re: NixOS Live CD (Graphic) Boot Failure To: nix-dev@lists.science.uu.nl Message-ID: 54590e54.5020...@gmail.com Content-Type: text/plain; charset=utf-8 On 11/04/2014 06:26 PM, J. Brian Kelley wrote: Well, I reinstalled Linux Mint 17 (went smoothly) and sadly there is no /proc/config.gz . sudo modprobe configs may be needed to access that file. Vladimir -- next part -- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3251 bytes Desc: S/MIME Cryptographic Signature Url :
[Nix-dev] Limiting number of Hydra jobs
Hi, My Hydra runs or rather limited box, both memory and CPU wise so I'd like to limit the number of jobs it runs. I have nix.maxJobs = 1; set but Hydra does not seem to care: even right now it's running 4 jobs at once (2 for i686 and 2 for x86). I have dealt with it for a longer while but I am getting tired of unresponsive box for hours. What setting should I set so that it will only ever run specified number of total jobs? Thanks -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NixOS Live CD (Graphic) Boot Failure
On 11/02/2014 05:10 PM, Luca Bruno wrote:
There's no web interface for nixos installations, if that's what you asked
for.
Pretty sure he just means that he won't be able to make the install
without referring to the web for help.
On Sun, Nov 2, 2014 at 5:46 PM, J. Brian Kelley j...@teksavvy.com wrote:
To start, my hardware is:
Mainboard - Asrock 4Core1600Twins-P35
CPU - Intel Core2 Duo E7200
No IDE disks ( and IDE controller is disabled in Bios)
1 Sata Drive (MBR formatted)
1 Sata Burner
1 Floppy
1 Pci-e display adapter AMD HD6850
This ancient relic does seem to give many live-cd distros the
heebie-jeebies. So far, the only one that has not required some
intervention is Linux Mint.
NixOS is my latest foray.
First, putting the live-cd on a usb stick seems to create problems
(whether I use UNetBootin or LiLi V2.8.30), so I burned a DVD.
Booting from the DVD starts out well, gets by the Grub loader and
reaches the point where the screen resolution is switched. A bit past
that I get the following three messages:
ata1: irq-stat 0x0040, connection status changed
ata1: SError { DevExch }
ata1: exception Emask 0x10 SAct 0x0 SErr 0x4000 action 0xe frozen
These then repeat - FOREVER.
Obviously, I am a total NOOB and a Windows 7 user. As such, it is
paramount that my Windows system remains (almost) untouched, with the
only change being an addition to the Windows 7 bootloader selection,
pointing to the Grub2 bootloader on my /boot partition. (Thanks to
EasyBCD.)
So, if there is not an obvious fix for the error loop, could someone
point me to instructions as how to use the Linux Mint live-cd (in all
its KDE glory) to create a bootable NixOS Graphic system with Web access?
The CPU precludes a 64-bit virtualization approach and I cannot envision
trying a terminal-only install without Web access to lead me step by
step through the process.
Any input greatly appreciated.
___
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
--
Mateusz K.
___
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 for NixOS
On 10/27/2014 06:59 PM, Michael Raskin wrote: - IRC bot that reports build failures for a range of commits once nixos-combined jobset is done Would be nice - email to commiters that broke the the build (with a range of commits and list of builds failed) Would be nice - nixos channel updates only when there are zero failures on jobset (this would mean reverts will happen often - and I believe that's the correct way to go instead of blocking people and punishing good testers) Back to the good old times of any failure blocking channel update, m-m-m. But we now have binary cache, so that doesn't matter that much. I have to say that I am somewhat wary of this approach: not getting a channel update because a random package failed seems like an overkill: we'll have to wait each time until a privileged person comes on and restarts the build and/or wait for a commit causing rebuild. I don't think a user will care that a package they'll never use hasn't succeeded. It'd be cool if it was possible to do ‘given my package list in configuration.nix, use the latest commit where all these packages succeed’ on NixOS. Can we also have a branch where bot would push the zero-failure channel commits, but no one else can push? - encouragement of nox-review wip use. This will bulid also all reverse-dependencies (good old Gentoo times) - ease of bisecting failures (for 99% of use cases this could be a range of commits done for jobset with test script respecting exit code of nix-build) - it could be even done as a separate service or part of hydra or just a copy/paste command for local testing I hope there would be bisect-wide failure caching (most of the time you simply need to find the first commit that changed anything at all in the build). All that being said, there are still number of false positives that will drive people crazy. Mostly due to networking issues and transient failures in build systems (mostly during testing phase). We should address them one by one and reduce hard unpurities. I've already done so as part of ZHF, but much more work is needed. Well, I think giving long-time committers minimal access to Hydra jobs (restarting failures as transient), that could already be a step forward. I am not sure whether it is possible to give out GC forcing rights without creating madness… ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] A few questions about Arm support and NixOS on a Chrome-book
On 10/25/2014 03:58 PM, James Haigh wrote: Hello, I also wish to install NixOS on ARM hardware. I have a series 3 Samsung ARM Exynos 5 Chromebook which I bought specifically for being an ARM-powered Linux laptop. However, though it comes with ‘Linux’, Chrome OS is absolutely terrible and as a result it has just been sitting collecting dust since I bought it nearly 2 years ago. Clearly Chrome OS isn't the full GNU+Linux so I want to install NixOS on it instead. The Chromebook isn't the only device that I wish to install NixOS on though; I also want to install it on a BeagleBone Black, a PandaBoard ES, and, if possible, a Raspberry Pi. The R'Pi isn't so important because it's pretty old now and is ARMv6 which apparently isn't so well supported. The BeagleBone Black and the PandaBoard ES are both open hardware platforms that I intend to use a lot. I will use BeagleBone Blacks for various electronics projects; the PandaBoard ES will be used as a desktop PC. In fact, I don't intend to buy new x86 hardware ever again. I'm also going to be increasingly keen to avoid buying new hardware that isn't open. Another platform that I'd like to see support for is Novena; with the success of the Novena project so far, it's clear that they're going to be centre-stage in the open hardware scene next year. And that's another ARM-powered platform. So yeah, having good support for the ARM Chromebooks and other ARM devices would be much appreciated. Best regards, James Haigh. As you probably know, if you don't want to compile stuff yourself (because your hardware is limited), someone else has to. For x86, Hydra does that job. But there's no ARM box for Hydra and I don't think there will be one any time soon: if you're asking whether we (nix people) can support ARM and by support you also mean binary caches, then probably not any time soon. You'd have to find an ARM machine strong enough to build nixpkgs, even if only sometimes. I believe machines of that power are very expensive. I might be wrong. Or maybe you know someone who would be happy to donate such a monster ;) So I think a better thing to do here would be to try and use nix on one of your ARM machines and complain if something doesn't work. I see no fundamental issue with trying to support ARM as long as this support only extends to ‘our tools run on ARM’ rather than ‘we have binary caches for ARM’. If better ARM support is desired, some ARM users will have to step up and start doing the work I think. I'll second vcunat here, I think the general practice by those that do run nix on their RPi c is to cross-compile. There's a wiki page at https://nixos.org/wiki/Raspberry_Pi you might find useful in general. On 25/10/14 14:40, Vladimír Čunát wrote: Hi. On 10/25/2014 09:51 AM, Liam Daly wrote: Is it possible/viable/desirable to enable Arm builds on Hydra [...] Hydra has no arm hardware ATM. And without continuous integration there, I expect many things won't work out of the box. AFAIK people cross-compile stuff for arm on their PCs. CC: Viric has probably most experience with that. Vladimir ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev On 25/10/14 08:51, Liam Daly wrote: Hey, firstly great work with everything! I use nix on my main computer with Gentoo but I've come into possession of a Samsung arm Chromebook. I really want to put Nix on it but I have a few questions first, What's the support like for Arm like at the moment? Is it possible/viable/desirable to enable Arm builds on Hydra as the chromebook has a terrible processor and how big is a NixOS installation (Eg. X, a web browser, Emacs and several programming languages) ? The reason for the last question is that Chrome-books have a limited hard drive and from what I've seen some Nix Closures are quite large. If the install is quite large is there any way to put some of the programs on a portable hard drive but not to require it? For example, have all the important programs stored on the Chrome-book but put extra Nix programs (In my case games or other large unimportant programs) on the hard-drive. Thank you and sorry if any of my questions were bad. ___ 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 -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Upstream nix expressions
On 10/23/2014 03:49 PM, Michael Raskin wrote: If this thing would be supported, this would give us a good reason to push our nix expressions upstream. This would have at least 2 good impacts: - a growing awareness of nix - a nice way for all developers to build their package - Ease of integration of Nix-related tools thatt already come with default.nix into NixPkgs… ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev I think https://github.com/NixOS/nix/pull/213 would allow for just that but unfortunately it doesn't seem that it will be revived any time soon. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Our policy for upgrading haskellPackages
On 10/15/2014 08:27 PM, John Wiegley wrote: This message is a follow-on to a discuss Peter and I were having on GitHub, since I believe it is of more general interest: Peter Simons writes: Generally speaking, the two goals 1. have recent versions of all major Haskell packages and 2. all Haskell packages should compile are contradictory. The 2.6.x version of network has been out there since Tue Sep 2 18:14:36 UTC 2014, i.e. for more than 1,5 months. Since 2.5.x and 2.6.x have incompatible APIs, many package authors don't bother supporting the old version: they update their packages to compile against 2.6.x and never look back. Now, in that situation, we must switch to 2.6.x eventually, because network 2.5.x cannot compile many available updates. At the same time, the switch to 2.6.x breaks the packages of all those people who didn't update their libraries. So what are we supposed to do? Forgo the available updates to keep a stable system or update at the cost of breaking packages that are sort-of unmaintained? I try to keep as many packages building as possible, and getting those ~200 updates into master was a major effort for me, i.e. I worked on those commits several hours per day for the better part of a week. Even with all that effort spent, however, I cannot remedy the fundamental conflict of interest between a system that's up-to-date and a system that's stable. At some point, I just push whatever I have come up with and I rely on other people, like yourself, to help finding the best balance between those two contradictory goals. Hi Peter, First, let me state how much I appreciate the contribution you're making to nixpkgs. Its support of Haskell is superb, and that is in large part due to your time and effort. My hope is to support you as best I can, and not to criticize your efforts in any way. You are exactly right that we have a tension between those two goals. I can think of two things that might be done to remedy this, and perhaps make updates to master more smooth: 1. We keep a dedicated branch, haskell-updates, to which only your Hackage updates get pushed, or fixes to those updates. I will personally pull and rebuild this branch every day on my machine, just as I presently rebuild master nearly every day -- compiling more than 2,000 packages that I keep locally updated through --leq. I (and hopefully others) will help to discover which packages can be fixed by inserting references to older packages, which requires patches, and which must truly be marked as broken until the maintainer of that package can be contacted. Further, I'll help you to maintain a list of outstanding broken packages, and see what can be done to make sure this list decreases over time. This already exists, in part: the haskell-updates job at [1]. I say in part because it: 1. Only builds for x86_64 (so the recent vector failure was not caught) 2. It doesn't make clear what packages were marked as broken. 3. Once it builds, it goes into master (usually) without any further review: partially a good thing because we get updates fast. So I think a better plan would be instead to have a separate branch (not haskell-updates) which contains only Haskell updates that result in some packages getting broken. Everything else just goes into master (through haskell-updates or whatever) as it is doing today. Say, keep the changes in this pending-broken branch for two days behind master: any interested party has a chance to jump in and say ‘oh, I know how to make this update not break anything’ or ‘I'll take care of specifying proper versions for these packages’. Obviously what would go onto this branch is at updaters discretion: no point delaying update of really popular package because one really unpopular package breaks. This approach of only putting up breaking updates for public review is, I feel, a better solution than requiring every Haskell update to wait in a branch for a day or two for no particular reason. 2. The second option is to create a new haskellPackages set, called 'stackage'. The Stackage maintainers already do a lot of the work implied by #1, ensuring that every package within the Stackage set can build together. Further, they only upgrade a package once they've either created a patch, or worked with upstream to update the package. Of course, the downside to this is: - less frequent updates of packages - a smaller available package set - life-draining maintenance of a mostly parallel package set The upside being that all patching/curating work is done for us, likely for as long as FP Complete keeps funding people to maintain Stackage. This should be pretty easy to maintain on nix side as we should be able to hackage4nix/cabal2nix all of hackage and have it Just Work™. Personally I'd like to see it go
Re: [Nix-dev] Broken ghc for OS X on cache.nixos.org
On 10/16/2014 09:53 PM, Richard Wallace wrote: Hello all, In an effort to get our team to start using nix, I've setup a project of ours to be built with nix. One obstacle I've run into is that most of the team (pretty much everyone except me) is using OS X, so I've been trying to overcome the OS X ghc being broken in the nix cache [1]. I've gone ahead and built a new ghc binary on OS X and created a cache containing it and other Haskell packages. I thought everything was going great until I tried to actually use it by running $ nix-shell shell.nix --option binary-caches http://mycache --command 'cabal configure --enable-tests' I myself often wonder how to get nix to DWIM when it comes to binary caches. Does nix-build --option binary-caches … do what you want? Maybe nix-shell just ignores it… This still downloads the ghc package from http://cache.nixos.org, which is what I'm trying to avoid. I used wireshark to see what is going on, and it appears that my cache is never checked, nix just goes and starts downloading from cache.nixos.org. My guess is that this is because of the MANIFEST from the nixpkgs-unstable channel. Is that correct? If so, how can I override that? You could try doing a manual nix-pull of your manifest. I do it to a local machine like so: nix-pull http://yuuki:3000/jobset/nixpkgs/trunk/channel/latest/MANIFEST Thanks, Rich PS It would be great if this weren't a problem. I was told this issue should be getting resolved soon since there is a new OS X build box and that I just needed to wait a few days. Any idea when a fixed ghc for OS X package will appear on cache.nixos.org? The update announcement was on the 9th and the unstable is currently on the commit from the 14th so I would have thought if it was fixed then it would be in the cache already. I think however than Haskell stuff on darwin was switched off so perhaps it just needs to be turned on again. You should ask around on #2689 about what's going on in that area. [1] https://github.com/NixOS/nixpkgs/issues/2689 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Firefox
On 10/12/2014 09:03 AM, Catonano wrote: Hello, why is firefox-with-plugins not available as a binary ? me@my-machine ~$ nix-env -qas | grep firefox --S firefox-32.0.3 --S firefox-bin-32.0.3 --- firefox-with-plugins-13.0.1 --- firefox-with-plugins-32.0.3 and what's the difference between firefox and firefox-with-plugins ? I can't find firefox-with-plugins in the nixpkgs repository ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev Also use -P with -qa for saner output. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Mac build machine upgraded
On 10/09/2014 05:15 PM, John Wiegley wrote: Eelco Dolstra eelco.dols...@logicblox.com writes: FYI: The Mac machine in the hydra.nixos.org build farm has been upgraded to OS X 10.9.5 (was 10.6.x). Xcode has been upgraded to 6.0.1. And there was much rejoicing!!! John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev For those uninitiated, does this fix the Haddock on OSX thing? -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Channel update knocks my box offline
On 09/23/2014 07:02 AM, Mateusz Kowalczyk wrote: Most recent nixos-unstable channel move knocks my box offline somehow. I can reach my local network but nothing on the outside. My network config[1] is pretty simple. I noticed this few days ago when I tried to switch to master but had no time at that moment to pursue. Considering this and the Grub problem in the other thread, were the tests switched off for this channel move or something? Apparently --rollback felt the need to kill my X session too ;( [1]: https://github.com/Fuuzetsu/nix-project-defaults/blob/master/nixos-config/configuration.nix#L73 With some help on IRC, the mystery was solved. The default route was not being set so after switch I had to manually run ‘systemctl restart network-setup’, which the switch should have done itself. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NILFS2, NixOS, nixpart and Blivet
On 09/30/2014 12:08 PM, Tim Barbour wrote: NILFS2 is a log-structured filesystem which is now in the Linux kernel source tree, and supported by GRUB2. It should appeal to NixOS users because it avoids destructive update (changing a file produces a new version of the file). I have installed NixOS with all filesystems on NILFS2, but encountered some problems along the way. The most serious problem is that NILFS2 needs to update /etc/mtab when mounting a filesystem, so that it can store information about the nilfs_cleanerd process associated with the mounted filesystem. If it cannot write to /etc/mtab, it does not start nilfs_cleanerd, and thus does not do garbage collection. In NixOS, /etc/mtab is just a symlink to /proc/mounts. I have worked around this manually so far, by replacing the symlink with a copy of /proc/mounts, then remounting all the NILFS2 filesystems. I am not sure how to resolve this properly. It is possible to mount using the '-n' option, but then NILFS2 will not start nilfs_cleanerd; it can be started later, but that requires writing to /etc/mtab. Perhaps the right way would be to mount using '-n', then start nilfs_cleanerd separately, but care would be necessary to make sure that nilfs_cleanerd is started exactly once (per filesystem), and shutdown appropriately at unmount. Another problem is that nixpart does not work with NILFS2, because Blivet does not support it. I modified Blivet (0.41) to support NILFS2, but the NixOS Blivet packages use a very old version (0.17-1), so I cannot easily test my change against the latest version of Blivet. I have back-ported it to 0.17-1, and used that to setup partitions and filesystems for the above NixOS installation. I noticed one problem: it did not label any of the volumes, not even swap, even though I specified labels. I suspect this is a deficiency of Blivet 0.17-1, and imagine it is already fixed in Blivet 0.41 . I considered updating the NixOS Blivet package(s), but they do some tricky-looking processing on the source code, and I doubt that I could update that properly for the current source code. If the maintainer could update the Blivet packages, then I would test my patch against the current Blivet, and send it to the upstream maintainers. I attach a tarball with patches for Blivet (note that the 0.41 patch is untested). Tim --- GPG public key available at: http://phasechangeit.com/~trb/gpg-key or http://subkeys.pgp.net:11371 Looks to me that all the scary-looking block in the blivet package does is replace hardcoded paths with paths to the nix-store that nix provides it with, a common practice. I think if you build and try to run the newer version in chroot, it should quickly become apparent what new changes have to be made for 0.41. If someone doesn't step up then I think you might actually be the most qualified person to do the update. Notably there's no listed maintainer for the blivet package. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Dealing with self-updating packages
On 09/19/2014 07:42 PM, Russell O'Connor wrote: Dear nixers, I'm working on packaging gsutil https://developers.google.com/storage/docs/gsutil. This software comes with a feature that it can update itself by downloading the latest version and replacing itself in place. Obviously this isn't going to work, and indeed when I force an update it fails with: $ gsutil update -f Checking for software update... This command will update to the 4.6 version of gsutil at /nix/store/4p33in0gqspwv2f4w2q0fq03cvj1iq9c-gsutil-4.6/share/gsutil Proceed? [y/N] y Copying gs://pub/gsutil.tar.gz... Downloading file://gsutil.tar.gz:2.1 MB/2.1 MB Downloading file://gsutil.tar.gz:2.1 MB/2.1 MB OSError: Read-only file system. My question is, how do you guys generally deal with this sort of software? I was thinking of creating a patch that will disable the update functionality. I would try to keep the notification of newer versions are available, but instead direct the user to update their nix-channel and/or notify the maintainer to update the version in nixpkgs. Thanks. I believe the general idea is to not do anything about it and trust the users to not try to update. It seems less hassle than patching it out and I haven't seen anyone complain yet. I would only bother patching stuff out iff the software relied on being to update itself and you could not ask it to do so. I'd also give upstream a good earful first. PS: Your e-mail only came through today. -- Mateusz K. ___ 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 for NixOS
On 09/29/2014 12:19 PM, Domen Kožar wrote: Current status (4 more packages need fixing and one test!): http://hydra.nixos.org/eval/1153558?full=1#tabs-still-fail - lots of transient errors in curl downloads, restarting doesn't always help: * http://hydra.nixos.org/build/14918849 * http://hydra.nixos.org/build/14894358 * http://hydra.nixos.org/build/14915515 * http://hydra.nixos.org/build/14915523 * pypy (32bit) Observation: all on i686-linux (might be machine specific or platform?) - bittorrent test needs a new tracker package to pass again (any heroes?) - cmplayer http://hydra.nixos.org/build/14858343 ( https://github.com/NixOS/nixpkgs/issues/4220) - haskellPackages.esqueleto.i686-linux, Seems like a network failure http://hydra.nixos.org/build/14839807/nixlog/1/raw First failure http://hydra.nixos.org/build/14711328 2.0.1 used to compile file so it seems we have just been unlucky with network since 2.0.2 bump haskellPackages.lzmaEnumerator.i686-linux (any heroes to disable those two?) lzma issue at https://github.com/alphaHeavy/lzma-enumerator/issues/2 - telepathy.call_ui (WIP https://github.com/NixOS/nixpkgs/pull/4265#issuecomment-56857712) So seems it's all WIP/issue open/network except bittorrent which genuinely fails. Seems pypy stuff is what's inflating the number to hundreds. -- Mateusz K. ___ 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 for NixOS
On 09/29/2014 12:35 PM, Domen Kožar wrote: On Mon, Sep 29, 2014 at 1:31 PM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk wrote: On 09/29/2014 12:19 PM, Domen Kožar wrote: Current status (4 more packages need fixing and one test!): http://hydra.nixos.org/eval/1153558?full=1#tabs-still-fail - lots of transient errors in curl downloads, restarting doesn't always help: * http://hydra.nixos.org/build/14918849 * http://hydra.nixos.org/build/14894358 * http://hydra.nixos.org/build/14915515 * http://hydra.nixos.org/build/14915523 * pypy (32bit) Observation: all on i686-linux (might be machine specific or platform?) - bittorrent test needs a new tracker package to pass again (any heroes?) - cmplayer http://hydra.nixos.org/build/14858343 ( https://github.com/NixOS/nixpkgs/issues/4220) - haskellPackages.esqueleto.i686-linux, Seems like a network failure http://hydra.nixos.org/build/14839807/nixlhttps://github.com/toastdriven/pysolr/pull/112og/1/raw http://hydra.nixos.org/build/14839807/nixlog/1/raw Restarted First failure http://hydra.nixos.org/build/14711328 2.0.1 used to compile file so it seems we have just been unlucky with network since 2.0.2 bump haskellPackages.lzmaEnumerator.i686-linux (any heroes to disable those two?) lzma issue at https://github.com/alphaHeavy/lzma-enumerator/issues/2 Could we disable it for i686-linux until that's fixed? We should mark the package as broken on i686 but I don't know the ‘proper’ way to do it, I was scorned the last time I changed platforms by hand[1] so you'll have to wait for peti to do it or explain the proper way. Notably, we need to not build it at all on i686 rather than disabling tests because the package will behave badly if used on those systems. - telepathy.call_ui (WIP https://github.com/NixOS/nixpkgs/pull/4265#issuecomment-56857712) So seems it's all WIP/issue open/network except bittorrent which genuinely fails. Seems pypy stuff is what's inflating the number to hundreds. cmplayer, telepathy and bittorrent test need attention, yes. [1]: https://github.com/Fuuzetsu/nixpkgs/commit/ea5be72b39067282626ccb275972b6582c1678da -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] GHC Not picking up installed packages
On 09/24/2014 11:47 PM, emil.rang...@chas.se wrote: follow up: ghci -v reported that the bytestring package was unusable somehow, so the packages that didn't show up where just those that depended on bytestring. :) Deleting random haskell storepaths in my nix-store and then rebuilding fixed everything. No idea what caused this in the first place unfortunately. On 2014-09-24 7:49, emil.rang...@chas.se wrote: Since updating to latest unstable half a day ago I can't make ghc recognise any installed packages anymore. I've tried both installing imperatively with nix-env -iA etc as well as putting (haskellPackages.ghcWithPackages (self : [ self.xmonad self.xmonadContrib ... )) In configuration.nix and also a default.nix with a cabal.mkDerivation and list packages as buildDepends and using nix-shell. In all cases the packages installs just fine, It downloads or builds some new store paths but when I try import XMonad (as an example, I can't get any package to work) in ghci it says the package doesn't exist. Any help in solving this would be greatly appreciated. Thanks /Emil ___ 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 You're probably hitting broken package IDs. You can find more info by searching list archives. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Channel update knocks my box offline
Most recent nixos-unstable channel move knocks my box offline somehow. I can reach my local network but nothing on the outside. My network config[1] is pretty simple. I noticed this few days ago when I tried to switch to master but had no time at that moment to pursue. Considering this and the Grub problem in the other thread, were the tests switched off for this channel move or something? Apparently --rollback felt the need to kill my X session too ;( [1]: https://github.com/Fuuzetsu/nix-project-defaults/blob/master/nixos-config/configuration.nix#L73 -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] systemd failed in locating swap
On 09/23/2014 08:13 AM, Dmitry Malikov wrote: Hi. Trying to `nixos-rebuild switch` and got something strange. [snip] You should say what commit/channel you're at and when was the last time it worked fine, it'd certainly make things easier. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Channel update knocks my box offline
On 09/23/2014 01:47 PM, Vladimír Čunát wrote: On 09/23/2014 08:02 AM, Mateusz Kowalczyk wrote: Apparently --rollback felt the need to kill my X session too ;( Was it xfce? My experience is that xfce4-session quits when dbus is restarted, which happens whenever dbus gets changed on --switch. Vladimir No, I run no DM with just XMonad. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Channel update knocks my box offline
On 09/23/2014 08:46 PM, Mateusz Kowalczyk wrote: On 09/23/2014 01:47 PM, Vladimír Čunát wrote: On 09/23/2014 08:02 AM, Mateusz Kowalczyk wrote: Apparently --rollback felt the need to kill my X session too ;( Was it xfce? My experience is that xfce4-session quits when dbus is restarted, which happens whenever dbus gets changed on --switch. Vladimir No, I run no DM with just XMonad. s/DM/DE/ -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Channel update knocks my box offline
On 09/23/2014 11:47 PM, Corey O'Connor wrote: The closest I've seen to rollback killing the X session is caused by logind failing to start. In which case I delete everything under /tmp and reboot. IIRC logind complains about connecting to a socket. -Corey O'Connor coreyocon...@gmail.com http://corebotllc.com/ Perhaps, but ideally I'd like to get back on the issue in the OP, my networking working on next switch is a bit more important to me than X restarting on a rollback ;P -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] a lot of staging changes from me, shout if I broke something! :)
On 09/14/2014 09:37 PM, Gergely Risko wrote: Hello, I've pushed some stdenv changes to staging. [snip] - having a glibc that actually includes libgcc_s.so, making pthread_cancel work without package specific hacks. Cool, dealing with libgcc_s.so wasted too many hours of my life. These are not committed to staging, I'll propose them as a PR for review once we know that nothing is broken so far by the previous changes. Thanks, Gergely -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] pyenchant: new package
On 09/13/2014 12:33 PM, Vladimír Čunát wrote: Nick: do you want to become a maintainer of all these newly added packages? It means that you would be getting e-mail when a package changes status (success/failure), and you would be expected to try to keep them working. On 09/13/2014 11:13 AM, Luca Bruno wrote: Out of curiosity, is anybody reviewing your patches in the mailing list? We usually use github. I did review and push the previous set of three patches. But I must admit github is slightly more comfortable. Vladimir GitHub has a pretty shitty terms of service which is why these patches are being sent over e-mail. Maybe we could hook up a simple bot that takes the patches from the mailing list and opens PRs but I don't know if the effort is worth it. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] pyenchant: new package
On 09/13/2014 06:49 PM, Vladimír Čunát wrote: On 09/13/2014 07:48 PM, Mateusz Kowalczyk wrote: GitHub has a pretty shitty terms of service which is why these patches are being sent over e-mail. which is probably* Can you point me to some explanation why they're shitty? Vladimir Apparently, upon (re-)reading the ToS, I can't! They either changed their license since I last checked (quite a while ago) or I managed to delude myself somehow… It seems their clause about them being able to change the license at any time is gone and now they will notify you (after which you automatically agree). Of course there is still the problem of GitHub not being responsive to feature requests (we still can't delete issues and it took YEARS to be able to lock them) and its service all the way up to its web frontend being proprietary code. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Newbie experiences with NixOS
On 09/09/2014 06:24 PM, Gergö Barany wrote:
Hi everyone,
this is a long mail about some of the issues I ran into when I recently
tried to install NixOS 14.04 on my home machine (which is mostly for fun
and some software development, but not a server). I ended up not using NixOS
for various reasons; I'm trying to give useful feedback, and I hope I will
succeed in not making this read like a rant full of complaints and demands.
Feedback is always good, I will try to answer what I personally can but
I am certainly not speaking on behalf of the project.
I'm happy to file bug reports for some of the issues mentioned below, but
I'm not always sure what project to file them on. Should every one of the
problems with configuration.nix/nixos-rebuild be reported against nixpkgs,
even if might not actually concern a package definition?
Nearly all common bugs should be filed under nixpkgs and if that's not
the right repository, someone can redirect you. Other notably
repositories one might file bugs against is the ‘nix’ repository for
bugs with implementation/feature requests and ‘hydra’ repository for
bugs with the build bot. In general, ‘nixpkgs’ is a very good bet.
My background, briefly: I've been using Linux for about 15 years now, on
various distributions. I know much of what I need for system administration,
but I hate actually having to tweak system stuff. I know various pure and
impure functional and logic programming languages, but the Nix language is a
mystery to me...
So, here goes. First some very minor comments on the website and the manual,
then more serious issues I ran into when trying (and failing) to install
some packages I wanted.
Website and the manual:
- I found it confusing that the manual talks about adding users imperatively
and imperative package management very early on. Not a problem, I'm just
wondering why it does this in the middle of explaining how to set up a
nice *declarative* system.
- I found it puzzling that the package channel is to be set imperatively on
the command line rather than in the configuration file. This breaks the
nice property of the entire configuration being in one or more config
files.
- In the manual, it would be nice to have Appendix B avaiable as a single
HTML page separate from the rest of the manual. (Told you these were
minor comments.) That would make full-text search for some options easier.
- The installation live CD comes with Konqueror as its web browser. The
JavaScript of the package browser at http://nixos.org/nixos/packages.html
does not work in Konqueror! Did not work for me at least, and there is no
fallback to a simpler search page.
(I guess I should file this as a bug?)
Yes, it does seem like you should file this as a bug. ‘nixpkgs’ is a
good bet. Other manual improvements should be filed as issues there as
well because that's where the manual lives.
Configuration:
- I haven't gone very deep here, but if I add a user in configuration.nix
and do nixos-rebuild, and then modify the configuration to add extraGroups
(such as wheel) for that user and run nixos-rebuild --switch again, then
the extra group setting just seems to be ignored; the user is not added to
the group.
(Would it be OK to file this as a bug against nixpkgs? If not, what github
project should it be?)
You need users.mutableUsers = true; here. I think this should be clearly
stated in the manual because it's a common question.
Package installation:
- ghc. I didn't care about the exact version, just hoped that a
meta-package named ghc would work. Here's a complete config file I
tried:
{ config, pkgs, ... }:
{
imports = [ ./hardware-configuration.nix ];
boot.loader.grub.enable = true;
boot.loader.grub.version = 2;
boot.loader.grub.device = /dev/sda;
services.xserver.enable = true;
services.xserver.displayManager.kdm.enable = true;
services.xserver.desktopManager.kde4.enable = true;
environment.systemPackages = with pkgs; [
wget vim
ghc
];
}
When running nixos-rebuild build on this, it failed with:
error: cannot coerce a set to a string, at
/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/lib/types.nix:98:79
Needless to say, I never touched that file. If I recall correctly,
specifying a *concrete* ghc package name did work. Using a generic name
imperatively worked: nix-env -i ghc selects a derivation automagically and
installs it.
The error message sucks but if you have some experience (which as you
say, you don't) it's simple to guess what's going on. There are two
things to answer here.
1. ‘nix-env -i ghc’ worked because ‘-i’ resolves by package name, not an
attribute name. It more-or-less makes a rough guess at what you mean by
‘ghc’. Using the attirbute names in preferable because it's not
ambiguous. Notably, systemPackages and just about everything except
‘nix-env -i’ uses these attribute names. You can
Re: [Nix-dev] Newbie experiences with NixOS
On 09/09/2014 07:16 PM, Mateusz Kowalczyk wrote: On 09/09/2014 06:24 PM, Gergö Barany wrote: Hi everyone, this is a long mail about some of the issues I ran into when I recently tried to install NixOS 14.04 on my home machine (which is mostly for fun and some software development, but not a server). I ended up not using NixOS for various reasons; I'm trying to give useful feedback, and I hope I will succeed in not making this read like a rant full of complaints and demands. [snip] I'll open issues about Clementine and swt but I ask you to open issues about the documentation things. Actually, Domen is right about the Clementine thing and I see that the URL for ‘swt’ is already changed in nixpkgs master so only documentation bugs remain. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] GHC pointed at the wrong package
On 09/07/2014 10:10 PM, Rickard Nilsson wrote:
On 08/23/2014 03:15 PM, Mateusz Kowalczyk wrote:
On 08/23/2014 01:29 PM, Peter Simons wrote:
Hi Mateusz,
There are problems in package regex-tdfa-1.2.0:
dependency parsec-3.1.5-ca5ed8f175b69e1a085cfeaf3b95f424 doesn't
exist
There are problems in package regex-tdfa-rc-1.1.8.3:
dependency parsec-3.1.5-ca5ed8f175b69e1a085cfeaf3b95f424 doesn't
exist
the process that generates those IDs in GHC is non-deterministic. Two
people can compile the same library with the same version of GHC on the
same type of machine yet end up with two distinct IDs. It doesn't happen
often, but it does happen.
I'd recommend running
$ nix-store --delete /nix/store/*-haskell-parsec-ghc7.8.3-3.1.5-shared
on all your machines. Then the next build will download these packages
from Hydra, and you'll have a consistent build again. Note that you may
have to remove packages from your active profiles to make that deletion
process succeed.
I hope this helps,
Peter
It's very unfortunate to hear about the package ID stuff. Is there a bug
open?
There is https://ghc.haskell.org/trac/ghc/ticket/4012
There has actually been a patch to that bug about a day before I asked
so the situation for the simple case may improve.
Actually, since we started building Haskell packages in parallel
(https://github.com/NixOS/nixpkgs/commit/817c0e41443a5176baf6dd9b422878fdccecd266),
this problem might have got more common (but I have no real evidence for
that).
You can reproduce this by building the haskell http-client package with
--cores 4 (non-parallel makes the problem go away). Each build (with
the exact same dependencies, and hence exact same nix hash) produces a
package with different package-id (in package-conf.d). It is not only
the package-id that differs, but the ABI differs, which could make
linking fail. Look at this:
$ nm -g
pkg-1/lib/ghc-7.8.3/http-client-0.3.8.1/libHShttp-client-0.3.8.1.a hc-1-nm
$ nm -g
pkg-2/lib/ghc-7.8.3/http-client-0.3.8.1/libHShttp-client-0.3.8.1.a hc-2-nm
$ diff hc-1-nm hc-2-nm | tail -n 10
8775,8776c8775,8776
U
httpzmclientzm0zi3zi8zi1_NetworkziHTTPziClientziTypes_zdLrfy8a_closure
D
httpzmclientzm0zi3zi8zi1_NetworkziHTTPziClientziTypes_zdLrfy9a1_closure
---
U
httpzmclientzm0zi3zi8zi1_NetworkziHTTPziClientziTypes_zdLrfxPa_closure
D
httpzmclientzm0zi3zi8zi1_NetworkziHTTPziClientziTypes_zdLrfxQa1_closure
8780c8780
D
httpzmclientzm0zi3zi8zi1_NetworkziHTTPziClientziTypes_zdLrfy8a_closure
---
D
httpzmclientzm0zi3zi8zi1_NetworkziHTTPziClientziTypes_zdLrfxPa_closure
As pointed out on the Trac ticket, non-determinism in presence of
parallelism is a known problem, so there's your evidence.
I really don't know how this could be worked around in Nix. Of course,
the problem is not very common, since you would have to build one
package locally, then fetch a package built somewhere else that depends
on your local package, and finally build a third package that depends on
that fetched package. But in a build cluster things like that certainly
do happen.
I think making Haskell packages only build on a single core again would
be a start.
For me that problem is common: my Hydra builds Haskell packages from
nixpkgs HEAD and uses official Hydra and peti's Hydra as binary caches.
Further, my own-use computer uses official Hydra, my Hydra and peti's
Hydra as caches + I often build packages locally when packaging stuff
for nixpkgs master or when I need some patches from there. It's fairly
easy to see that it's easy for the problem to come up here. In fact my
Hydra right now suffers from the same thing and weirdly it's actually,
again, something to do with pandoc/parsec packages.
Right from my Hydra:
package pandoc-1.13.1 is broken due to missing package
pandoc-types-1.12.4.1-917a8ba6e10664f3ab958ef027071e98
My options when this happens is to either:
1. manually drop in and try to remove broken packages
2. garbage collect everything
3. wait for a big rebuild which will cause these to be rebuild/refetched
Today 3. is actually happening so hopefully it comes out without any
bogus errors but ideally this should never happen. If building each
package on single core makes it more likely to produce non-broken
packages then I think it should be the default until it can be patched
upstream.
/ Rickard
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
--
Mateusz K.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] haskell: overriding mtl/any builtin
On 09/08/2014 07:36 AM, Peter Simons wrote: Hi Mateusz, Notably if I specify mtl = mtl_2_2_1; then it complains that it needs transformers == 0.4 but there seems to be no clues in nixpkgs as to how to achieve this. Currently mtl = 2.2.1 for HEAD but I know it should work with 7.8.3 transformers is a core library in GHC 7.8.3. We cannot override that package, because it's shipped with the compiler and other core libraries are linked against that version. Best regards, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev Right, yes, it is, yet somehow there are packages around on Hackage which do depend on mtl-2.2.1 and by proxy on transformers-0.4, which do compile with GHC 7.8.3. This must be somehow achieved one way or another and currently with nix(pkgs) we can not accommodate for those packages. Recent release of JuicyPixels is a good example, we had to ask upstream to relax the bound a bit so that we could use it but just relaxing the bound is not always possible. I expect more and more packages to start using the new mtl over time. I found myself yesterday in need of hacking a bit on a project which happened to actually need mtl-2.2.1 and I just could not do it with 7.8.3 whereas that's exactly what the original developer was using. My hack there was to comment out the 2.2.1 imports and manually stick undefined everywhere but that's obviously not acceptable for any actual work. The only other way I could think of would be to use the (outdated) GHC ‘HEAD’ version from nixpkgs which would not help me because it was to try and chase down a bug appearing with 7.8.3. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Developing with older packages
On 09/08/2014 04:56 PM, Richard Wallace wrote:
Hello,
I'm using nix-shell to setup a Haskell environment for development. On a
project I ran into a problem recently, and I'm curious if there is a
common/preferred way of solving it.
The problem I ran into is that the project depends on the mongoDB 1.5
package. The API changed drastically in 2.0 and we're not ready to
undertake the upgrade yet. I think I can handle this by creating a nixpkgs
directory in the project, putting a mongoDB/default.nix file in there that
is setup for the version we need, then override it in our shell.nix file
like this:
let
pkgs = import nixpkgs {};
haskellPackages = pkgs.haskellPackages.override {
extension = self: super: {
mongoDB = self.callPackage nixpkgs/mongoDB {};
ourkidsclass = self.callPackage ./. {};
};
};
Is this a reasonable approach? Is there a better way?
Thanks,
Rich
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
This looks as good of a solution as any other one could come up with. Is
there something you're dissatisfied with that you would like to have in
a ‘better’ solution?
--
Mateusz K.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] haskell: overriding mtl/any builtin
On 09/07/2014 10:57 AM, Mateusz Kowalczyk wrote: On 09/07/2014 10:15 AM, Marc Weber wrote: mtl choosing versions Which is the target package you want to use/work on? Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev In this case =mtl-2.2.1 but I'd like to know the solution in general. As long as we could ‘cabal install whatever’ on a regular distro, I'd like to know how to achieve the same thing with nix. Notably if I specify mtl = mtl_2_2_1; then it complains that it needs transformers == 0.4 but there seems to be no clues in nixpkgs as to how to achieve this. Currently mtl = 2.2.1 for HEAD but I know it should work with 7.8.3 -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] haskell: overriding mtl/any builtin
Hi, GHC ships with a bunch of libraries that are exposed. How can we override those so that the compilation still succeeds and we don't end up with two versions in scope? A sample use-case is using things which depend on ‘mtl’ 2.1.2. Usually I try to work with upstream to make the bound more flexible but this is suboptimal. In this case the problem is with the Haskell ‘cgi’ package which needs mtl 2.2.1: they had fixed up some failures for 7.8.3 so that it could compile but we fail at the configure stage. Normally a user would just cabal-install mtl so how do we adapt? Assume jailbreak doesn't work. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] About merge vs non-merge
On 09/02/2014 05:51 PM, Luca Bruno wrote: Somebody does not like merges because it makes the history less clean. However, just today, I encountered a case where the merge was needed for a revert. The good thing about the green merge button is that: 1) It retains a message about the PR. So you have information if you need to do a revert. 2) If it's a multi-commit PR, you may need to revert multiple commits. Without merge this information is lost. For manual merges, yes it's very inconvenient. In theory one should either: 1) Edit every commit message saying that it was part of a given PR 2) or create a local branch mirroring the requester branch In both cases it's annoying. However for anti-merge people, it may make the history less clean for you, but the lose of information is not worth it in my opinion. So I please everyone, if you can choose to have a merge commit, please keep it. Best regards, ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev There is no anti-merge sentiment, there's a ‘don't have 1:1 commit to merge message ratio’. If it's a multi-commit PR that shouldn't be squashed into one, sure, keep your merge message. If it's a single commit PR, in 95% of cases the merge message is just noise. If you're after the PR for a commit without merge message, simply put in the author's name on the PR page with is:pr filter. I don't want to hide merge messages because they *can* be useful as you say, the problem is that there number of actually useful merge messages is small, not to mention they are hidden behind all the green-button merges. I'm not sure what the purpose of this thread is. Is it to incite people to use the green button? Is it to ask them to manually merge smarter? -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Some staging regressions
On 09/02/2014 01:04 PM, Eelco Dolstra wrote: Hi, On 02/09/14 12:32, Vladimír Čunát wrote: Also pypy tests timeouted on i686-linux... There is also a Qt 5 build failure on i686-linux: http://hydra.nixos.org/build/13929055 It fails because it doesn't pass -lpq to build the PostgreSQL binding. Turns out this is due to this line: !contains(LIBS, .*pq.*):LIBS += -lpq so -lpq is only added if LIBS doesn't contain the string pq. And of course, in this particular build, the path to PostgreSQL is /nix/store/h5ym9*pq*4fjkv7d4fxzs1qbb601xyl9gk-postgresql-9.2.9 :-) I don't know whether to laugh or cry… -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Failed to execute login command
On 09/02/2014 09:44 PM, Luca Bruno wrote: It happened to me a couple of times after big nixos-rebuild. It may happened that some X drivers were updated. On Tue, Sep 2, 2014 at 10:33 PM, Bjørn Forsman bjorn.fors...@gmail.com wrote: Hi, Since about a month now, whenever I do nixos-rebuild switch (after also updating channel sources) I'm being kicked out of the desktop environment and cannot login graphically unless I reboot (maybe there is a way to recover, but haven't yet bothered to investigate that further). When this happens, I get the message Failed to execute login command (or something similar) in the middle of the screen in a graphical big font. After a second or two I see a text console (ctrl-alt-f1?) and then back to the Failed to execute login command. Anyone else getting these? The problem fixes itself by rebooting. But it's very annoying. I'm running nixos unstable with gnome3.12 and lightdm login manager. Best regards, Bjørn Forsman ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev My personal experience with drivers being updated (say, along with the kernel) is that X keeps running but if I try to restart it then it won't work unless I reboot which is understandable considering they are now linked against new kernel. Perhaps a similar thing is happening here, big driver update. I think you should say what your DE/DM is, I thought those never get restarted by default. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Keeping nixpkgs up to date
On 08/31/2014 03:43 PM, Chris Double wrote: Speed of processing pull requests for new packages is an issue. Anything that can be done to reduce this would be helpful. It's demotivating as a contributor to do what seems to be a simple package update of a minor version and have the pull request take weeks. When I first started using NixOS the tor package was way out of date so I updated it. That went pretty quickly. 3 months ago I did a pull request to update to a recent tor minor release on unstable. This went through ok. I waited a couple of weeks for testing then did a pull request to get it in 14.04; https://github.com/NixOS/nixpkgs/pull/3136 Updating Tor on 14.04 to version 0.2.4.22 and Tor Browser to 3.6.2. This has been sitting for two months. Since then a newer version of Tor and Tor Browser has come out so it's already out of date. I haven't bothered trying to do a pull request to update to the new version as there seems no point given that processing pull requests must be overloaded. I can see this only getting worse as more people do pull requests for package updates. New packages are no doubt worse since it takes more analysis of the pull request for someone to approve it. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev I think the problem here is slightly different. It is not that processing PRs is slow in general, processing PRs that are to go into 14.04 is slow. The problem is that it seems there are very few people that have the confidence to merge into the stable branch so if Eelco doesn't do it, it just rots away. Perhaps we simply need more people designated to review PRs against stable? -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Keeping nixpkgs up to date
On 08/29/2014 10:04 AM, Vladimír Čunát wrote: On 08/27/2014 04:35 PM, Mateusz Kowalczyk wrote: What do you think? I think something like this is inevitable with the ever-growing number of packages and users or we end up with the situation like we have today, with thousands of outdated packages without maintainers or with inactive/busy maintainers listed. I think the main problem is that the total amount of energy spent on maintaining packages is low, and I don't see how the grouping will help it. Also, the commitment of being maintainer of a group of packages seems significantly larger than for a single package. The change may rather dissuade people from becoming a maintainer at all, as they may be only interested in a few particular packages and not e.g. in all games we have. Vladimir Actually I think people are much more inclined to sit down and spend a few minutes sometimes updating a package or two from their group rather than putting their own name down specifically on a package and then having the sole burden of updating it themselves. I also think it makes people feel ‘I'm in a group of people doing similar so I can always seek help from them’ as opposed to ‘I'm on my own to figure it out when this breaks’. In general it means that technically one is ‘in charge’ of more packages per-person but it's much easier to try to recruit under the ‘come and help out sometimes with these packages’ angle as opposed to ‘go and become maintainer of those packages and they will be your responsibility’. Even if that's not the case, this doesn't remove the existing system, people are free to only put down their name on individual packages. I'm simply aiming at more organisation. We really have a lot of packages that need some entity to maintain them and it's easier to track a handful of entities for activity than thousands of individual packages. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] how to get a hydra / github branch?
On 08/28/2014 05:56 AM, Gergely Risko wrote: Hi, I'm doing some compile time optimizations on the stdenv closures. For example GCC 4.8 doesn't use PPL anymore, so that can be removed altogether. But I would like to have a nixos/nixpkgs branch where I can commit my changes and a hydra build running on my branch, so I can see if I cause some overall damage by accident. I promise to not abuse this and commit hourly just for testing :) Can this be arranged? Who should I ask? Is there some procedure in place already on how to ask for this? Thanks, Gergely ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev While I can't say yes/no because I'm not in charge here, you could host your own Hydra which would allow you immediate feedback when you push on top of what already exists. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Keeping nixpkgs up to date
Hi, Some weeks ago the nixpkgs monitor[1] started to work again and the numbers there are worrying. I inline the numbers at the bottom. Now, there are 2000+ outdated packages with maintainers listed and 1000 outdated without maintainers at all (and the 1600 whose status we don't know). Even if somehow half of these are false-positives (which they aren't), that's still a huge number. It is difficult to try to make a dent in that number as an individual and we don't have that many people actively maintaining the things they are listed under. I'd like to propose a system like Gentoo's, the herd system. Basically we split up packages up by categories and assign maintainer group to each category. For example, we might have something like Haskell packages – Haskell maintainer group games – games maintainer group Python packages – Python maintainer group emulators – … … and so on. We then recruit/encourage people to join the groups they are interested in. This means that rather than a single person maintaining some packages and being single point of failure, we now have multiple people maintaining a larger pool of packages. It is then easy to ask questions like ‘what games are outdated?’. Of course this can be implemented alongside the existing system of listed individual maintainers. It also gives us the benefit of being able to look at each group and say ‘oh, games don't have any maintainers, we should look for some people to do that’ which is currently very difficult. It's also much easier to ensure the groups remain active as opposed to having to chase down each individual maintainer listed on each package. At the beginning it will simply transform the problem of ‘we need to find maintainers for 2000 packages’ to ‘we need to find maintainers for 10 groups’. Groups can then simply use the monitor to see which packages become outdated with hopes that someone in the group makes the update. What do you think? I think something like this is inevitable with the ever-growing number of packages and users or we end up with the situation like we have today, with thousands of outdated packages without maintainers or with inactive/busy maintainers listed. The changes required would be to categorise packages we have (easy, simply go by how nixpkgs is organised), assign a group (an e-mail address, perhaps a mailing list or something) to each and go through each expression to add the respective group's e-mail. Thanks! Current numbers: Packages # Potentially vulnerable 234 Unmaintained not covered 1691 Outdated unmaintained1048 Outdated 2143 Maintainers Packages 0 4347 1 2065 2 743 3 254 4 268 5 1 [1]: http://monitor.nixos.org [2]: http://devmanual.gentoo.org/general-concepts/herds-and-projects/ -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] GHC pointed at the wrong package
Hi, From about 2 days ago, I started having a problem of the following nature: There are problems in package regex-tdfa-1.2.0: dependency parsec-3.1.5-ca5ed8f175b69e1a085cfeaf3b95f424 doesn't exist There are problems in package regex-tdfa-rc-1.1.8.3: dependency parsec-3.1.5-ca5ed8f175b69e1a085cfeaf3b95f424 doesn't exist As you can see at [1], I *do* have parsec-3.1.5 in the checked database but the package ID doesn't match up. I don't know how I got into this situation and I also don't know how to get out of it. I think this started happening after I updated my channel. I have collected garbage earlier today, went into the nix-shell --pure --dry-run and confirmed that the regex-tdfa packages weren't there anymore and the shell wasn't broken but after nix-shell --pure, the dependencies install and the problem comes back. I hoped that I would never have such problems anymore so it's a bit disappointing. Please feel free to request extra info. [1]: http://lpaste.net/109873 -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] GHC pointed at the wrong package
On 08/23/2014 01:02 PM, Mateusz Kowalczyk wrote: Hi, From about 2 days ago, I started having a problem of the following nature: There are problems in package regex-tdfa-1.2.0: dependency parsec-3.1.5-ca5ed8f175b69e1a085cfeaf3b95f424 doesn't exist There are problems in package regex-tdfa-rc-1.1.8.3: dependency parsec-3.1.5-ca5ed8f175b69e1a085cfeaf3b95f424 doesn't exist As you can see at [1], I *do* have parsec-3.1.5 in the checked database but the package ID doesn't match up. I don't know how I got into this situation and I also don't know how to get out of it. I think this started happening after I updated my channel. I have collected garbage earlier today, went into the nix-shell --pure --dry-run and confirmed that the regex-tdfa packages weren't there anymore and the shell wasn't broken but after nix-shell --pure, the dependencies install and the problem comes back. I hoped that I would never have such problems anymore so it's a bit disappointing. Please feel free to request extra info. [1]: http://lpaste.net/109873 Even a simple nix-shell -p pkgs.haskellPackages_ghc783.regexTdfa -p pkgs.haskellPackages_ghc783.ghc --pure Replicates the problem. Might want to add .parsec in there. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Can't SSH into a root account
Hi, I while ago I put NixOS on another computer. I set it all up and it's great except for one problem: I can't SSH into the root account on it. See below for some attempts: I want to SSH from @lenalee to @yuuki. It just keeps rejecting my password even know I know it's correct: I demonstrate that by SSHing into a regular user on that box and then using ‘su’. This also shows that it's not a problem with SSH access in general, just to that user. The only thing I'm not showing here is SSHing into root@yuuki from regular user @lenalee because I set up login with a public key for convenience. This also that I can actually log into the user, just not with the password. I hoped that this would go away after I stopped messing with the users at install time but it has now been weeks and multiple reboots c and the problem persists. Below is an annotated session dump. I especially point your attention to the last part. ## -- Try logging into the root user, fail. [root@lenalee:/home/shana]# ssh root@yuuki Password: Password: ^C [root@lenalee:/home/shana]# exit -- Log into the regular user there. [shana@lenalee:~]$ ssh shana@yuuki Password: Last login: Fri Aug 22 11:10:18 2014 from lenalee -- …and switch to the root that way… [shana@yuuki:~]$ su Password: -- …which works so the password is correct. [root@yuuki:/home/shana]# exit [shana@yuuki:~]$ logout Connection to yuuki closed. [shana@lenalee:~]$ su Password: -- Keep trying, keep failing. That second way of failure and prompting -- makes me suspicious. [root@lenalee:/home/shana]# ssh root@yuuki Password: Password: Password: root@yuuki's password: Permission denied, please try again. root@yuuki's password: Permission denied, please try again. root@yuuki's password: [root@lenalee:/home/shana]# exit ## It'd be great if someone could offer some advice. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Can't SSH into a root account
On 08/22/2014 12:28 PM, Andreas Herrmann wrote: Dear Mateusz, Isn't SSH default configured to only accept public-key login for root? First thing I found on google about it: http://askubuntu.com/questions/449364/what-does-without-password-mean-in-sshd-config-file The option `permitRootLogin` should fix it: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/networking/ssh/sshd.nix#L117 Or have you tried that already? Best, Andreas Apparently that was it, guess I looked for the wrong thing when searching for solution before. Thanks Andreas and Lluís. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] GHC-bundled terminfo collides with the actual package
Hi, I want to have Agda available everywhere on my system so I wanted to stick it in systemPackages. nix-shell does not work in this scenario because I use it for its input method in emacs so it needs to be available everywhere, all the time: I don't want to have to start separate emacs sessions. That worked for a while but few weeks ago I started getting this: ## collision between `/nix/store/kb4kpcvmiiacvfabjldk7590js6v1f41-ghc-7.8.3/lib/ghc-7.8.3/terminfo-0.4.0.0/System/Console/Terminfo/Cursor.dyn_hi' and `/nix/store/rn1zydhnd5li8dh2ldn3yasdwglk3lyj-haskell-terminfo-ghc7.8.3-0.4.0.0-shared/lib/ghc-7.8.3/terminfo-0.4.0.0/System/Console/Terminfo/Cursor.dyn_hi' at /nix/store/9z6d76pz8rr7gci2n3igh5dqi7ac5xqj-builder.pl line 72. ## This stops the rebuild. Is there a clean way to proceed? A hack which overrides terminfo to produce nothing doesn't work as we end up with ## Loading package terminfo-0.4.0.0 ... command line: can't load .so/.DLL for: libncursesw.so (libncursesw.so: cannot open shared object file: No such file or directory) ## Another hack which passes terminfo = null to haskeline which is the dependency of Agda that actually pulls terminfo is doesn't work either: ## /nix/store/ngsbygsjzv0fbj1543306l0a48qqy1vs-binutils-2.23.1/bin/ld: cannot find -lncursesw ## The only thing I have in systemPackages is as follows: ## (haskellPackages.ghcWithPackages (self : [ self.Agda self.AgdaStdlib self.HTTP self.tar ])) ## Can someone advise how I can have Agda (or any terminfo-dependent program) in systemPackages? My current workaround is going to involve using nix-env to get Agda and AgdaStdlib into my user's profile but I don't like using nix-env, I have no packages active through that way and I'd hate to have to make an exception. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] 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)
On 08/15/2014 05:22 AM, Mateusz Kowalczyk wrote: Hi, I'd like to know the solution to the error message in the subject. I have encountered it in the past if inside a Haskell project I did something like nix-shell --pure eval $configurePhase eval $buildPhase eval $checkPhase While this bothered me, the workaround was to exit and re-enter the shell after buildPhase and run checkPhase then. But now I want to actually test a package that this happens in on my local Hydra and when it goes to run the test-suite, I get precisely that message. The package in question is Haddock here which is set to ‘doCheck = false’ in nixpkgs even though I personally happen to know that the tests do pass when actually ran. Not running the test-suite is obviously not acceptable when you're the package maintainer… Any ideas? I find that if I unset GHC_PACKAGE_PATH after ‘eval $buildPhase’ then the tests will run. While one can arrange this with some hooks on per-package basis, I'd be interested to hear if why we're setting GHC_PACKAGE_PATH after during the buildPhase to begin with. Perhaps the default could be that it is not set or if cabal does that, that we unset it. It seems that if this was useful then we would set it at the point build starts (before configure or after). AFAIK any packages that make use of GHC_PACKAGE_PATH just call out to ghc-pkg anyway and put together a GHC_PACKAGE_PATH from scratch. Can we just unset/never set GHC_PACKAGE_PATH by default? -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Haskell build failures
On 08/21/2014 07:14 AM, Raahul Kumar wrote:
Thanks! So can I have a list of broken package sorted by Hackage
dependencies, so I know which packages are used the most?
Sounds like there is still work to be done.
Aloha,
RK.
On Thu, Aug 21, 2014 at 3:19 PM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk
wrote:
On 08/21/2014 05:46 AM, Raahul Kumar wrote:
How? Amazing well done! But seriously how was this achieved?
On Thu, Aug 21, 2014 at 4:45 AM, Luca Bruno lethalma...@gmail.com
wrote:
Wow, awesome.
On Wed, Aug 20, 2014 at 8:33 PM, Peter Simons sim...@cryp.to wrote:
On Linux/x86_64, zero Haskell builds fail:
http://hydra.cryp.to/jobset/nixpkgs/haskell-updates
Let's hope that lasts. :-)
Best regards,
Peter
It was achieved by marking broken things as broken so that they don't
come up as failures on Hydra all the time. Once the package is fixed
(upstream or otherwise) it can be built again and we have an extra
package building.
The approach of marking stuff as broken allows one to see much better
which packages actually change build status. Users also get a message if
they try to compile a package marked as broken rather than have them try
to compile and fail which was horrible user experience.
--
Mateusz K.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
I don't have such a list but you can grep for ‘broken = true;’ in
pkgs/development/{libraries,tools}/haskell/*/*.nix. Often the commit
marking it as broken will refer to open upstream issue.
Yes, there is work to be done which is to now try to get the broken
packages into a non-broken state. Oftentimes this involves filing issues
with upstream and waiting.
--
Mateusz K.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] ghcWithPackages
On 08/20/2014 10:44 AM, Tim Barbour wrote: This message somehow did not make it to the list, so I am sending it again: Mateusz Kowalczyk writes: [...] haskellPackages_ghc783.ghcWithPackages should work just fine, I just tried it myself. Considering haskellPackages.ghcWithPackages gives you 7.6.3, it simply makes me think that you have an old set of packages. On nixos-unstable/nixpkgs-unstable, that would default to 7.8.3 and haskellPackages_ghc783.ghcWithPackages would work fine. That's what I use in my configuration.nix myself: I'm using nixos-unstable channel. That fixed it, thank you. Now I am wondering what the wisest choice of channel(s) is. I imagine the latest stable nixos for most things, but nixos-unstable for more experimental things (e.g. yi). Perhaps nixos-unstable for most Haskell packages ? What determines the choice between the nixos channel and the nixpkgs channel ? Tim --- GPG public key available at: http://phasechangeit.com/~trb/gpg-key or http://subkeys.pgp.net:11371 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev I just stay on nixos-unstable all the time, stable channel is just too damn slow. I imagine one would get along fine on stable if they aren't a programmer and just want smooth-cruising but if you need fairly recent software then unstable is the way to go. Sometimes things break but not often enough for it to ever be a problem. You can always rollback if something doesn't work after an update anyway. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] ghc-mod + nix-shell?
On 08/20/2014 11:44 AM, Mateusz Kowalczyk wrote: Hi, ghc-mod-5.x just came out so I thought I'll give it a try again – I had bad experience with it when on Gentoo as it really hates mixing GHC versions. What I did was package 5.x and then add it to buildTools of my project through shell.nix After updating the cabal file and running cabal configure so it would stop complaining, ‘ghc-mod’ command itself works: [nix-shell:~/programming/tsuntsun]$ ghc-mod check src/Main.hs src/Main.hs:62:1:The type signature for ‘unlessM’ lacks an accompanying binding but ghc-modi which is what is actually used does not: [nix-shell:~/programming/tsuntsun]$ ghc-modi NG BUG: command line: cannot satisfy -package-id text-1.1.1.3-19b1d34e1f78946a216fb2a95da8973b\n(use -v for more information) If I run ghc-pkg check then it tells me the package is broken [nix-shell:~/programming/tsuntsun]$ TERM=xterm ghc-pkg check There are problems in package ghc-mod-5.0.1: dependency djinn-ghc-0.0.2.2-c9b696804551566f24c6318e5fc83a11 doesn't exist dependency ghc-paths-0.1.0.9-7d0e6178c3518b928e3a89e76cbed29c doesn't exist dependency ghc-syb-utils-0.2.1.2-981aa43f46526d20b8f2800284ea5c4a doesn't exist dependency haskell-src-exts-1.15.0.1-2a731a74bc57b134a58a272454970c29 doesn't exist dependency hlint-1.9.3-5855c5e6c81c6eee0e4e737b366a37d4 doesn't exist dependency io-choice-0.0.5-77f5291ed82ac6c645917df71b2b8442 doesn't exist dependency monad-control-0.3.3.0-77020b8cc5cc6089930c75c98b452cd1 doesn't exist dependency monad-journal-0.2.3.0-aaa5a7e6af8534c7d3dbc5368ac0884a doesn't exist dependency split-0.2.2-7c6e2bd13c1e04b85cc7ee759efb1a08 doesn't exist dependency syb-0.4.2-3b61f5272a0cd76f5fc4924f04a86453 doesn't exist dependency transformers-base-0.4.2-6e58862b37a26c65c3a96fa2518f39c3 doesn't exist The following packages are broken, either because they have a problem listed above, or because they depend on a broken package. ghc-mod-5.0.1 Does someone know what the proper way to use ghc-mod + nix-shell is? The only thing I can find online is ghcWithPackages inside systemPackages but I don't like that ‘solution’ and I suspect it would not work anyway: it would not be able to see the packages inside my nix-shell. Seems I was too hasty and the error was coming from the fact that ghc-modi binary was unwrapped. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Haskell build failures
On 08/21/2014 05:46 AM, Raahul Kumar wrote: How? Amazing well done! But seriously how was this achieved? On Thu, Aug 21, 2014 at 4:45 AM, Luca Bruno lethalma...@gmail.com wrote: Wow, awesome. On Wed, Aug 20, 2014 at 8:33 PM, Peter Simons sim...@cryp.to wrote: On Linux/x86_64, zero Haskell builds fail: http://hydra.cryp.to/jobset/nixpkgs/haskell-updates Let's hope that lasts. :-) Best regards, Peter It was achieved by marking broken things as broken so that they don't come up as failures on Hydra all the time. Once the package is fixed (upstream or otherwise) it can be built again and we have an extra package building. The approach of marking stuff as broken allows one to see much better which packages actually change build status. Users also get a message if they try to compile a package marked as broken rather than have them try to compile and fail which was horrible user experience. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] ghcWithPackages
On 08/18/2014 02:43 PM, Tim Barbour wrote: It seems that some versions of haskellPackages define ghcWithPackages, and others do not. I have been following the approach described at https://nixos.org/wiki/Haskell#Using_cabal_in_the_direct_installation_scenario under the heading Local use via Nixpkgs config. If I use haskellPackages.ghcWithPackages with yi in the list of packages, I get installing `haskell-env-ghc-7.6.3' these derivations will be built: /nix/store/3n7dzh6c1idpjbq27wzds0784i200kpi-haskell-env-ghc-7.6.3.drv /nix/store/7kbz46k29gxgx67lxs2fymk3crkd0q1d-haskell-yi-ghc7.6.3-0.8.1.drv ... 60% ( 9 / 15) in 'Yi.Command' haddock: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): mkWWcpr: not a product details unavailable Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug builder for `/nix/store/7kbz46k29gxgx67lxs2fymk3crkd0q1d-haskell-yi-ghc7.6.3-0.8.1.drv' failed with exit code 1 cannot build derivation `/nix/store/3n7dzh6c1idpjbq27wzds0784i200kpi-haskell-env-ghc-7.6.3.drv': 1 dependencies couldn't be built error: build of `/nix/store/3n7dzh6c1idpjbq27wzds0784i200kpi-haskell-env-ghc-7.6.3.drv' failed which looks very similar to this bug: https://ghc.haskell.org/trac/ghc/ticket/9170 Since the bug is supposed to be fixed in ghc = 7.8.2, I would like to use a newer version of haskellPackages. But if I try haskellPackages_ghc783.ghcWithPackages, I get Yes, known bug but not the one I'm going to fix. I think we should simply change the Yi expression to not build docs when using 7.6.3. error: attribute `haskellPackages_ghc783.ghcWithPackages' missing OTOH, haskellPackages_ghc742.ghcWithPackages has no such error. It seems that some versions of haskellPackages define ghcWithPackages, and others do not. Why ? What is the right way to specify a particular version of ghc ? Or better still, avoid a given version of ghc ? haskellPackages_ghc783.ghcWithPackages should work just fine, I just tried it myself. Considering haskellPackages.ghcWithPackages gives you 7.6.3, it simply makes me think that you have an old set of packages. On nixos-unstable/nixpkgs-unstable, that would default to 7.8.3 and haskellPackages_ghc783.ghcWithPackages would work fine. That's what I use in my configuration.nix myself: I'm using nixos-unstable channel. Tim --- GPG public key available at: http://phasechangeit.com/~trb/gpg-key or http://subkeys.pgp.net:11371 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev -- Mateusz K. ___ 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 08/17/2014 11:18 PM, Raahul Kumar wrote: I'm interested in the Haskell failures. Anyone have a list of the most important ones, due to reverse Hackage dependencies? On Wed, Aug 13, 2014 at 12:35 AM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk wrote: On 08/12/2014 01:26 PM, Rok Garbas wrote: Quoting Domen Kožar (2014-08-12 13:31:27) Just to let everyone know, I'll have time to work on Python failures during the sprint in Ljubljana, but unfortunately not before that. Good work though! same here. we'll make sure python stuff gets fixed at ljubljana sprint. -- Rok Garbas - http://www.garbas.si ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev Will this involve splitting up python-packages.nix into more manageable pieces or will you just focus on getting things building/marking as broken? Problem with Python packages is that it's all too easy to ‘build’ them but only once you run them do the problems come up (missing depends, incompatible interpreter version, …). I can only wish you luck. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev You can get a good idea from looking at Peter Simon's Hydra job: http://hydra.cryp.to/eval/8919 -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] [PATCH] rtorrent: add xmlrpc-c
On 08/14/2014 09:21 PM, Petar Bogdanovic wrote:
Third party UIs require rtorrent to be compiled with xmlrpc-c.
---
pkgs/tools/networking/p2p/rtorrent/default.nix | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/pkgs/tools/networking/p2p/rtorrent/default.nix
b/pkgs/tools/networking/p2p/rtorrent/default.nix
index b843228..64d5183 100644
--- a/pkgs/tools/networking/p2p/rtorrent/default.nix
+++ b/pkgs/tools/networking/p2p/rtorrent/default.nix
@@ -1,5 +1,5 @@
{ stdenv, fetchurl, libtorrent, ncurses, pkgconfig, libsigcxx, curl
-, zlib, openssl
+, zlib, openssl, xmlrpc_c
}:
stdenv.mkDerivation rec {
@@ -10,7 +10,8 @@ stdenv.mkDerivation rec {
sha256 = 113yrrac75vqi4g8r6bgs0ggjllj9bkg9shv08vqzdhkwqg2q2mw;
};
- buildInputs = [ libtorrent ncurses pkgconfig libsigcxx curl zlib openssl ];
+ buildInputs = [ libtorrent ncurses pkgconfig libsigcxx curl zlib openssl
xmlrpc_c ];
+ configureFlags = --with-xmlrpc-c;
# postInstall = ''
# mkdir -p $out/share/man/man1 $out/share/rtorrent
https://github.com/NixOS/nixpkgs/pull/3597
--
Mateusz K.
___
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 08/12/2014 01:26 PM, Rok Garbas wrote: Quoting Domen Kožar (2014-08-12 13:31:27) Just to let everyone know, I'll have time to work on Python failures during the sprint in Ljubljana, but unfortunately not before that. Good work though! same here. we'll make sure python stuff gets fixed at ljubljana sprint. -- Rok Garbas - http://www.garbas.si ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev Will this involve splitting up python-packages.nix into more manageable pieces or will you just focus on getting things building/marking as broken? Problem with Python packages is that it's all too easy to ‘build’ them but only once you run them do the problems come up (missing depends, incompatible interpreter version, …). I can only wish you luck. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How to help remedy build errors of Haskell packages in Nixpkgs
On 08/12/2014 02:20 PM, emil.rang...@chas.se wrote: On 2014-08-10 14:40, Peter Simons wrote: - Compile errors. Some packages cannot deal with current versions of GHC and/or 3rd party dependencies. These errors manifest in the form of genuine compiler errors. Errors of this kind must almost always be fixed upstream. The way to go in this case is to file a report and to mark the package as broken in Nixpkgs. The package taffybar is fixed by the author, but there is no new hackage release. Can cabal2nix deal with this somehow? The only thing I came up with was dumping a 90k patch in the nixpkgs repo, but that feels perverse. /Emil ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev Mark current version as broken, ask for a release upstream, cabal2nix the new version once that's out. It's unexpected to have known-broken version of a package suddenly start compiling: if that version is broken then it's broken and the author needs to release the fixes. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Migrating Hydra database between machines
Hi, I had some success on getting Hydra running on my own computer and I'm fairly happy how it worked out. The problem is that I have limited space here and not a great CPU, Core 2 Duo. Luckily I just re-purposed a Gentoo boxed into a NixOS one and Hydra is compiling there as I type this. NixOS is great. I would like to ask how to move the Hydra database with my projects and jobsets to the other computer which will from now on run all the builds. I am mostly looking to save myself time from having to recreate every project and jobsets as it's quite tedious. Thanks! -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Passwd
On 08/12/2014 07:06 AM, Julio Cesar Campos wrote: Intalled NixOSl, and follow the instructions below The system should boot into the display manager; however, you can’t yet log in as there are no users defined, and root logins aren’t allowed on the desktop. Press CTRL+ALT+F1 to switch to a console. Now log in as root and add a user. Here is how to create the user “julio”: useradd -m juliopasswd camila You should also change the root password using “passwd”. -- by typing in slim julio and camila a terminal is open with this: [julio@nixos:}$ Then: [julio@nixos:}$sudo -i Passwd: Camila Julio is not in the sudoers file. This incident will be reported. I do not know what to do As it says, you need to be given the privileges to use sudo. Adding the user to the ‘wheel’ group and settings ‘security.sudo.enable = true;’ should be enough. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Migrating Hydra database between machines
On 08/12/2014 06:40 AM, Rob Vermaas wrote: Hi, I had some success on getting Hydra running on my own computer and I'm fairly happy how it worked out. The problem is that I have limited space here and not a great CPU, Core 2 Duo. Luckily I just re-purposed a Gentoo boxed into a NixOS one and Hydra is compiling there as I type this. NixOS is great. I would like to ask how to move the Hydra database with my projects and jobsets to the other computer which will from now on run all the builds. I am mostly looking to save myself time from having to recreate every project and jobsets as it's quite tedious. You should be able to just use pg_dump to create a postgresql dump of the hydra database, and import this on the new server. Have you tried this? Cheers, Rob No, I haven't tried it because I have no idea how to work the database. Consider this a “if I get a data dump from one Hydra, can I safely use it in another without further tweaks?” question. I have just finished manually moving all the projects but if you have precise instructions then I'm sure I'll be able to use them in the future. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Hydra on NixOS
Hi, I'm trying to set up Hydra on NixOS. After some searching I followed [1], checking out from the revision that's currently master. I did not reboot as stated on the page there so maybe that's the source of my trouble but nixos-switch started up all hydra-foo.service just fine. It did not create /var/lib/hydra/.pgpass as it was apparently meant to so when I got to the interface I could not log in. I followed to the Hydra manual which tells me to run postgres and add hydra user but hydra-init.service already handled that so I don't do it. I scroll down and find that I am meant to run hydra-init and then use hydra-create-user. I do this while still logged in as root. I now find that I still can't log in to my Hydra instance. I start messing around and thinking it might be permissions problem because I now have root files in /var/lib/hydra. I delete those and try to hydra-init again as hydra user but the result is similar, can't log in. At this point I decide to scrap it and try again, just disable hydra and postgres in my configuration.nix, rebuild, --gc, re-enable. However there is a problem: if I nixos-rebuild switch more than once with Hydra, I get ● hydra-init.service Loaded: loaded (/nix/store/pvcv6z3yzgy3vzws5is0sd5r2hz9pjv3-unit/hydra-init.service) Active: failed (Result: exit-code) since Sun 2014-08-10 09:23:33 CEST; 28ms ago Process: 6714 ExecStartPre=/nix/store/zlsf8wn19rl5qhs27lr5cs08xx718vdx-unit-script/bin/hydra-init-pre-start (code=exited, status=1/FAILURE) Aug 10 09:23:33 lenalee hydra-init-pre-start[6714]: createuser: creation of new role failed: ERROR: role hydra already exists Aug 10 09:23:33 lenalee systemd[1]: hydra-init.service: control process exited, code=exited status=1 Aug 10 09:23:33 lenalee systemd[1]: Failed to start hydra-init.service. Aug 10 09:23:33 lenalee systemd[1]: Unit hydra-init.service entered failed state. So this means I can't ever run nixos-rebuild switch more than once with Hydra around… OK. I can't run postgres as hydra user and delete it because it doesn't know where to find the db. I can't run it as root because postgres stops that as a security measure. So I am stuck here unless I disable postgres and Hydra. If I stop Hydra services, run hydra-init as root, hydra-create-user and run hydra-server then I can actually log in but I am of course stuck with a system which can't rebuild and requires I manually run Hydra as root which is two terrible things. I also notice that the postgres and hydra system users don't go away if I revert my config and rebuild which seems strange to me, is this by design? In the end my question is simply “How do I actually properly install Hydra on NixOS?!”. The manual itself makes zero mention of doing it on NixOS through configuration.nix as far as I can see. Worse, it's unclear what users are being using to execute which commands so even following that, permissions may end up being a problem. I will for now remove anything Hydra related from my config, delete generations, --gc/-d and hope it all goes away until someone can provide some guidance. [1]: https://nixos.org/wiki/Installing_hydra_as_nixos_module [2]: http://hydra.nixos.org/build/13164007/download/1/hydra/manual.html#chap-installation -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How to help remedy build errors of Haskell packages in Nixpkgs
On 08/10/2014 02:40 PM, Peter Simons wrote: Hi guys, if you're using Nix to install Haskell packages, then please consider contributing some time and effort to fix build failures! At the time of this writing, we have about 120 packages that fail to build on Hydra. You can see the complete list at this place: http://hydra.cryp.to/jobset/nixpkgs/haskell-updates Just follow the link to the latest evaluation, and you'll see the exact list of packages that don't compile in the Still failing tab. Now, pick any one of those packages that you care about and look at the build log. We typically have the following kinds of build errors: - Dependency version mismatch. These kind of errors mean that the configure stage fails with an error message along the lines of: | Configuring rest-types-1.10.1... | Setup: At least the following dependencies are missing: | aeson ==0.7.* We use aeson 0.8.0.0 by default, so this package won't compile because that version is too new. An error like this should always be reported upstream! Furthermore, you can try to add | jailbreak = true; into the failing packages Nix file, then run $ nix-build -o /tmp/haskell --option binary-caches http://hydra.cryp.to ~/src/nixpkgs -A haskellPackages.restClient to check whether that actually helped. If it did, we're fine! If it didn't help, then there's not much else we can do. You _may_ edit haskell-packages.nix to override the version of aeson passed to this package with an older one, i.e. 0.7.0.4, but this is almost never a good idea, because Haskell programs cannot mix different versions of the same library in the same executable. This means that having some parts of our package base link aeson 0.7.x and other part link 0.8.x is bound to cause trouble at some point. If in doubt, just mark the package as broken by adding the lines | hydraPlatforms = self.stdenv.lib.platforms.none; | broken = true; to the meta section. - Compile errors. Some packages cannot deal with current versions of GHC and/or 3rd party dependencies. These errors manifest in the form of genuine compiler errors. Errors of this kind must almost always be fixed upstream. The way to go in this case is to file a report and to mark the package as broken in Nixpkgs. Say a package version no longer builds with recent GHC version and upstream won't fix it or can't fix it to work with that version for some reason, what's the way to go about only blacklisting the broken GHC versions? I can think of most packages using GHC API being sensitive to this. - Test suite failures. Oftentimes, packages compile fine but fail during the check phase. The easiest way to remedy that problem is to disable the test suite by adding doCheck = false; to the Nix file. However, a test suite failure may very well indicate a serious error in the software, and we might actually prefer an older version over the one that fails. It's probably best to report the error upstream and ask for advice how to proceed. - Haddock failures. Believe it or not, but some packages cannot build their own documentation. This should be reported upstream, of course. Meanwhile, the issue can be worked around by adding noHaddock = true; to the Nix file. It's good to exercise caution here, though. Generally speaking, though, packages without documentation are highly undesirable, and using that hack to make a package build should not be used lightly. Now, let's assume that you've edited many, many packages and fixed lots of build errors. Before you run git push, please run: $ hackage4nix ~/src/nixpkgs That tool comes with cabal2nix, and it will re-generate all Haskell build in-place. Running that tool in a Nixpkgs check-out should always be a no-op, i.e. no files should be modified by hackage4nix! If there are modified files, then you should investigate the diffs. If the change made by hackage4nix is purely cosmetic, then please amend your commit to include those modifications. If the change is significant, however, then this means that cabal2nix cannot generate a proper build for that particular package! Please report any such issue at https://github.com/NixOS/cabal2nix/issues. You'll notice that hackage4nix also prints our a list of updates that might be applied to the source tree (run cabal update to update your package database!). Feel free to update packages, if you have the chance, but please run test builds for important packages such as git-annex, darcs, or hledger-web to make sure that your updates don't break anything. Attached to this e-mail you'll find a short shell script called commit-haskell-update that scans the Nixpkgs tree for modified (updated) packages and then generates git-commit calls ready for cut paste for your convenience. Furthermore, there's a script called
