[Nix-commits] [NixOS/nixpkgs] f4e04c: clac: 20170416 -> 20170503

[Charles Strahan]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: f4e04c3e44ff49898fdb9b258e40d2dafd6bed4f
  
https://github.com/NixOS/nixpkgs/commit/f4e04c3e44ff49898fdb9b258e40d2dafd6bed4f
  Author: Charles Strahan 
  Date:   2017-06-28 (Wed, 28 Jun 2017)

  Changed paths:
M pkgs/tools/misc/clac/default.nix

  Log Message:
  ---
  clac: 20170416 -> 20170503


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 8e73af: zoom-us: don't add mesa to the LD_LIBRARY_PATH

[Charles Strahan]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 8e73afb2e13c3717044aea3de2ad6e7085caf589
  
https://github.com/NixOS/nixpkgs/commit/8e73afb2e13c3717044aea3de2ad6e7085caf589
  Author: Charles Strahan 
  Date:   2017-06-27 (Tue, 27 Jun 2017)

  Changed paths:
M pkgs/applications/networking/instant-messengers/zoom-us/default.nix

  Log Message:
  ---
  zoom-us: don't add mesa to the LD_LIBRARY_PATH

zoom-us was failing to launch under the proprietary nvidia drivers,
as described in the comments of #26596.

Closes #26916


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 698f33: flashplayer: 25.0.0.171 -> 26.0.0.126

[Charles Strahan]

  Branch: refs/heads/release-17.03
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 698f336e5ca9bdd7fb43e5db966c686b4e72b7df
  
https://github.com/NixOS/nixpkgs/commit/698f336e5ca9bdd7fb43e5db966c686b4e72b7df
  Author: taku0 
  Date:   2017-06-21 (Wed, 21 Jun 2017)

  Changed paths:
M pkgs/applications/networking/browsers/chromium/plugins.nix
M 
pkgs/applications/networking/browsers/mozilla-plugins/flashplayer/default.nix
M 
pkgs/applications/networking/browsers/mozilla-plugins/flashplayer/standalone.nix

  Log Message:
  ---
  flashplayer: 25.0.0.171 -> 26.0.0.126

(cherry picked from commit 264ec9242fa36b5990851af589d05f7ad32c6387)


  Commit: 0a1c41f76100b4da1e251078783c3cc15bf8ffcd
  
https://github.com/NixOS/nixpkgs/commit/0a1c41f76100b4da1e251078783c3cc15bf8ffcd
  Author: Charles Strahan 
  Date:   2017-06-21 (Wed, 21 Jun 2017)

  Changed paths:
M pkgs/applications/networking/browsers/chromium/plugins.nix
M 
pkgs/applications/networking/browsers/mozilla-plugins/flashplayer/default.nix
M 
pkgs/applications/networking/browsers/mozilla-plugins/flashplayer/standalone.nix

  Log Message:
  ---
  flash: 26.0.0.126 -> 26.0.0.131

The previous releases were 404ing.

(cherry picked from commit dda6daa4ff876d6f48cdd3538509c26c3e18af03)


Compare: https://github.com/NixOS/nixpkgs/compare/b506b9437b7a...0a1c41f76100___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] dda6da: flash: 26.0.0.126 -> 26.0.0.131

[Charles Strahan]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: dda6daa4ff876d6f48cdd3538509c26c3e18af03
  
https://github.com/NixOS/nixpkgs/commit/dda6daa4ff876d6f48cdd3538509c26c3e18af03
  Author: Charles Strahan 
  Date:   2017-06-16 (Fri, 16 Jun 2017)

  Changed paths:
M pkgs/applications/networking/browsers/chromium/plugins.nix
M 
pkgs/applications/networking/browsers/mozilla-plugins/flashplayer/default.nix
M 
pkgs/applications/networking/browsers/mozilla-plugins/flashplayer/standalone.nix

  Log Message:
  ---
  flash: 26.0.0.126 -> 26.0.0.131

The previous releases were 404ing.


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 39fd94: chrome: fix fallout from #26512

[Charles Strahan]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 39fd9444020e2de89514db9297b27a57a9369eac
  
https://github.com/NixOS/nixpkgs/commit/39fd9444020e2de89514db9297b27a57a9369eac
  Author: Charles Strahan 
  Date:   2017-06-16 (Fri, 16 Jun 2017)

  Changed paths:
M pkgs/applications/networking/browsers/chromium/default.nix
M pkgs/applications/networking/browsers/google-chrome/default.nix

  Log Message:
  ---
  chrome: fix fallout from #26512

Fixes broken save dialogue (causes chrome to crash) and missing icons.


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 3b1c4f: psensor: init at 1.2.0

[Charles Strahan]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 3b1c4fce4fc18cd8ce51fc895527ecfa273d2761
  
https://github.com/NixOS/nixpkgs/commit/3b1c4fce4fc18cd8ce51fc895527ecfa273d2761
  Author: Charles Strahan 
  Date:   2017-06-13 (Tue, 13 Jun 2017)

  Changed paths:
M pkgs/os-specific/linux/nvidia-x11/settings.nix
A pkgs/tools/system/psensor/default.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  psensor: init at 1.2.0

psensor is a graphical hardware monitoring application for Linux


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 132b50: GHCJS packages: avoid inode explosion

[Charles Strahan]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 132b503aacb7dcc181d12804dee110f68f9f3730
  
https://github.com/NixOS/nixpkgs/commit/132b503aacb7dcc181d12804dee110f68f9f3730
  Author: Charles Strahan 
  Date:   2017-05-28 (Sun, 28 May 2017)

  Changed paths:
M pkgs/development/haskell-modules/generic-builder.nix

  Log Message:
  ---
  GHCJS packages: avoid inode explosion

As noted in #25595, a change introduced in 4b77d425aa597 causes an
explosion of inodes due to the constructions of many, many `ghcEnv`
symlink forests. This commit undoes that change.

To discuss reworking the support for GHCJS plugins, please see: #26192

Fixes #25595


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 2a3cd1: slang: 2.3.0 -> 2.3.1a

[Charles Strahan]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 2a3cd13d732ca8e49518a0314d1e003bf16af0bf
  
https://github.com/NixOS/nixpkgs/commit/2a3cd13d732ca8e49518a0314d1e003bf16af0bf
  Author: Charles Strahan 
  Date:   2017-03-30 (Thu, 30 Mar 2017)

  Changed paths:
M pkgs/development/libraries/slang/default.nix

  Log Message:
  ---
  slang: 2.3.0 -> 2.3.1a


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 49207a: chromium: 56.0.2924.87 -> 57.0.2987.98 [Security]

[Charles Strahan]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 49207a62f3f14aefeddd0daf311529a9495101db
  
https://github.com/NixOS/nixpkgs/commit/49207a62f3f14aefeddd0daf311529a9495101db
  Author: Herwig Hochleitner 
  Date:   2017-03-11 (Sat, 11 Mar 2017)

  Changed paths:
M pkgs/applications/networking/browsers/chromium/upstream-info.nix

  Log Message:
  ---
  chromium: 56.0.2924.87 -> 57.0.2987.98 [Security]


  Commit: f5ccf24028982048f7ca55581435944494653a4a
  
https://github.com/NixOS/nixpkgs/commit/f5ccf24028982048f7ca55581435944494653a4a
  Author: Charles Strahan 
  Date:   2017-03-14 (Tue, 14 Mar 2017)

  Changed paths:
M pkgs/applications/networking/browsers/chromium/upstream-info.nix

  Log Message:
  ---
  Merge pull request #23737 from bendlas/update-chromium

chromium: 56.0.2924.87 -> 57.0.2987.98 [Security]


Compare: https://github.com/NixOS/nixpkgs/compare/f122f0147bb0...f5ccf2402898___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 2c0225: mesos: fix build with latest gcc/glibc

[Charles Strahan]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 2c0225add688f5c62d8011e494af6efdc2c3f660
  
https://github.com/NixOS/nixpkgs/commit/2c0225add688f5c62d8011e494af6efdc2c3f660
  Author: Charles Strahan 
  Date:   2017-03-01 (Wed, 01 Mar 2017)

  Changed paths:
M pkgs/applications/networking/cluster/mesos/default.nix

  Log Message:
  ---
  mesos: fix build with latest gcc/glibc

/cc #23253


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 1ba97d: ghcjsHEAD: unbreak

[Charles Strahan]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 1ba97d6ee9795b8c9c6ff25b0baaf988be561781
  
https://github.com/NixOS/nixpkgs/commit/1ba97d6ee9795b8c9c6ff25b0baaf988be561781
  Author: Charles Strahan 
  Date:   2017-02-27 (Mon, 27 Feb 2017)

  Changed paths:
M pkgs/development/compilers/ghcjs/base.nix
M pkgs/development/compilers/ghcjs/default.nix

  Log Message:
  ---
  ghcjsHEAD: unbreak


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 4abbe3: gocode: 20150904 -> 20170219

[Charles Strahan]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 4abbe3c5fc5edd8b1edf42a3c1513178050cfa04
  
https://github.com/NixOS/nixpkgs/commit/4abbe3c5fc5edd8b1edf42a3c1513178050cfa04
  Author: Charles Strahan 
  Date:   2017-02-24 (Fri, 24 Feb 2017)

  Changed paths:
M pkgs/development/tools/gocode/default.nix

  Log Message:
  ---
  gocode: 20150904 -> 20170219

Go completion wasn't working (at least from youcompleteme); this fixes
that.


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] b27edc: ycmd: 2016-01-12 -> 2017-02-03

[Charles Strahan]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: b27edc45374309fb30b6b7454b4115e4923b17bf
  
https://github.com/NixOS/nixpkgs/commit/b27edc45374309fb30b6b7454b4115e4923b17bf
  Author: Charles Strahan 
  Date:   2017-02-06 (Mon, 06 Feb 2017)

  Changed paths:
M pkgs/development/tools/misc/ycmd/default.nix

  Log Message:
  ---
  ycmd: 2016-01-12 -> 2017-02-03

Also, remove wrapper bash script and symlink completion backends to
ycmd can find them.


  Commit: 53a5117cde14e1905cbe67e294f9b2b974dbe09a
  
https://github.com/NixOS/nixpkgs/commit/53a5117cde14e1905cbe67e294f9b2b974dbe09a
  Author: Charles Strahan 
  Date:   2017-02-10 (Fri, 10 Feb 2017)

  Changed paths:
A pkgs/development/tools/misc/ycmd/2-ycm-cmake.patch
M pkgs/development/tools/misc/ycmd/default.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  ycmd: use vendored python libs

YouCompleteMe needs the packages to be available in ycmd's third_party
directory, and things start getting pretty complicated when we try to
use our package libs instead of the vendored ones. We can revisit this
at a later time, but we'll need to ensure that we don't break the vim
plugin.

Tested in vim.


  Commit: 4ca258e97af40905a54cada4fc1a97f17470376b
  
https://github.com/NixOS/nixpkgs/commit/4ca258e97af40905a54cada4fc1a97f17470376b
  Author: Charles Strahan 
  Date:   2017-02-10 (Fri, 10 Feb 2017)

  Changed paths:
A pkgs/development/tools/misc/ycmd/2-ycm-cmake.patch
M pkgs/development/tools/misc/ycmd/default.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  Merge pull request #22490 from cstrahan/ycmd

ycmd: 2016-01-12 -> 2017-02-03


Compare: https://github.com/NixOS/nixpkgs/compare/fc54ece4709d...4ca258e97af4___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 7ebcad: mesos: 1.0.1 -> 1.1.0

[Charles Strahan]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 7ebcada02028e5ce8199cc123fda6aa1aba72e64
  
https://github.com/NixOS/nixpkgs/commit/7ebcada02028e5ce8199cc123fda6aa1aba72e64
  Author: Charles Strahan 
  Date:   2016-12-29 (Thu, 29 Dec 2016)

  Changed paths:
M nixos/modules/services/misc/mesos-master.nix
M nixos/modules/services/misc/mesos-slave.nix
M nixos/tests/mesos.nix
A nixos/tests/mesos_test.py
M pkgs/applications/networking/cluster/mesos/default.nix
R pkgs/applications/networking/cluster/mesos/maven_repo.patch
M pkgs/applications/networking/cluster/mesos/nixos.patch
M pkgs/applications/networking/cluster/mesos/rb36610.patch
R pkgs/applications/networking/cluster/mesos/rb51324.patch
R pkgs/applications/networking/cluster/mesos/rb51325.patch
M pkgs/development/interpreters/python/build-python-package-setuptools.nix
M pkgs/development/libraries/protobuf/generic.nix
M pkgs/top-level/python-packages.nix

  Log Message:
  ---
  mesos: 1.0.1 -> 1.1.0


  Commit: d298a961f1db2356495026702dd9bbc396e000af
  
https://github.com/NixOS/nixpkgs/commit/d298a961f1db2356495026702dd9bbc396e000af
  Author: Charles Strahan 
  Date:   2017-01-21 (Sat, 21 Jan 2017)

  Changed paths:
M nixos/modules/services/misc/mesos-master.nix
M nixos/modules/services/misc/mesos-slave.nix
M nixos/tests/mesos.nix
A nixos/tests/mesos_test.py
M pkgs/applications/networking/cluster/mesos/default.nix
R pkgs/applications/networking/cluster/mesos/maven_repo.patch
M pkgs/applications/networking/cluster/mesos/nixos.patch
M pkgs/applications/networking/cluster/mesos/rb36610.patch
R pkgs/applications/networking/cluster/mesos/rb51324.patch
R pkgs/applications/networking/cluster/mesos/rb51325.patch
M pkgs/development/interpreters/python/build-python-package-setuptools.nix
M pkgs/development/libraries/protobuf/generic.nix
M pkgs/top-level/python-packages.nix

  Log Message:
  ---
  Merge pull request #21416 from cstrahan/mesos-1.1.0

mesos: 1.0.1 -> 1.1.0


Compare: https://github.com/NixOS/nixpkgs/compare/5b1b089de350...d298a961f1db___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 71f92b: nixos: provide default console_cmd for slim

[Charles Strahan]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 71f92bc8a386bcd05f74d56113fd2f408145ad7e
  
https://github.com/NixOS/nixpkgs/commit/71f92bc8a386bcd05f74d56113fd2f408145ad7e
  Author: Charles Strahan 
  Date:   2017-01-21 (Sat, 21 Jan 2017)

  Changed paths:
M nixos/modules/services/x11/display-managers/slim.nix

  Log Message:
  ---
  nixos: provide default console_cmd for slim

This provides a default console_cmd for the slim display-manager.

When the user enters "console" as the user name, slim will run this
command.

Having a default is rather important; the virtual terminals don't work
with some display drivers, so having a broken X session can leave you
locked out of your machine.


  Commit: 5b1b089de350aa67233a8be237a4eb5d263f5409
  
https://github.com/NixOS/nixpkgs/commit/5b1b089de350aa67233a8be237a4eb5d263f5409
  Author: Charles Strahan 
  Date:   2017-01-21 (Sat, 21 Jan 2017)

  Changed paths:
M nixos/modules/services/x11/display-managers/slim.nix

  Log Message:
  ---
  Merge pull request #8642 from cstrahan/slim-console-cmd

nixos: provide default console_cmd for slim


Compare: https://github.com/NixOS/nixpkgs/compare/7cb14d435373...5b1b089de350___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 351db2: mesos: 0.28.2 -> 1.0.1

[Charles Strahan]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 351db21d34249a5afee505652f393bf44815db61
  
https://github.com/NixOS/nixpkgs/commit/351db21d34249a5afee505652f393bf44815db61
  Author: Charles Strahan 
  Date:   2016-09-29 (Thu, 29 Sep 2016)

  Changed paths:
M pkgs/applications/networking/cluster/mesos/default.nix
M pkgs/applications/networking/cluster/mesos/fetch-mesos-deps.sh
M pkgs/applications/networking/cluster/mesos/mesos-deps.nix
A pkgs/applications/networking/cluster/mesos/nixos.patch
M pkgs/applications/networking/cluster/mesos/rb51324.patch
M pkgs/applications/networking/cluster/mesos/rb51325.patch
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  mesos: 0.28.2 -> 1.0.1


  Commit: ecf30981dd723576f5c143b3728ba5bf72b31550
  
https://github.com/NixOS/nixpkgs/commit/ecf30981dd723576f5c143b3728ba5bf72b31550
  Author: Charles Strahan 
  Date:   2016-11-23 (Wed, 23 Nov 2016)

  Changed paths:
M pkgs/applications/networking/cluster/mesos/default.nix
M pkgs/applications/networking/cluster/mesos/fetch-mesos-deps.sh
M pkgs/applications/networking/cluster/mesos/mesos-deps.nix
A pkgs/applications/networking/cluster/mesos/nixos.patch
M pkgs/applications/networking/cluster/mesos/rb51324.patch
M pkgs/applications/networking/cluster/mesos/rb51325.patch
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  Merge pull request #19064 from cstrahan/mesos-1.0.1

mesos: 0.28.2 -> 1.0.1


Compare: https://github.com/NixOS/nixpkgs/compare/ce6abb9495b6...ecf30981dd72___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] e4cd45: top-level: Make `overridePackages` extend rather t...

[Charles Strahan]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: e4cd45a30c92a19a240df835cdaf6da5f76ea9fc
  
https://github.com/NixOS/nixpkgs/commit/e4cd45a30c92a19a240df835cdaf6da5f76ea9fc
  Author: John Ericson 
  Date:   2016-10-13 (Thu, 13 Oct 2016)

  Changed paths:
M doc/functions.xml
M lib/trivial.nix
M pkgs/top-level/all-packages.nix
M pkgs/top-level/default.nix

  Log Message:
  ---
  top-level: Make `overridePackages` extend rather than replace existing 
overrides


  Commit: 3ca3b145ead9ce528b6b8cbf4db8e2a73a26bbe7
  
https://github.com/NixOS/nixpkgs/commit/3ca3b145ead9ce528b6b8cbf4db8e2a73a26bbe7
  Author: John Ericson 
  Date:   2016-10-13 (Thu, 13 Oct 2016)

  Changed paths:
M pkgs/top-level/default.nix

  Log Message:
  ---
  top-level: Use foldl' to make the list of package functions top to bottom


  Commit: ca2b03439f31dca0beee0d9b492dd18db78315cd
  
https://github.com/NixOS/nixpkgs/commit/ca2b03439f31dca0beee0d9b492dd18db78315cd
  Author: Charles Strahan 
  Date:   2016-10-26 (Wed, 26 Oct 2016)

  Changed paths:
M doc/functions.xml
M lib/trivial.nix
M pkgs/top-level/all-packages.nix
M pkgs/top-level/default.nix

  Log Message:
  ---
  Merge pull request #19496 from Ericson2314/overridePackages

Make `overridePackages` extend rather than replace existing overrides


Compare: https://github.com/NixOS/nixpkgs/compare/6f1f1d86c1f6...ca2b03439f31___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] da3684: nixos: make it easy to apply kernel patches

[Charles Strahan]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: da36847d925058fd86f027b64cc712c57be11ad8
  
https://github.com/NixOS/nixpkgs/commit/da36847d925058fd86f027b64cc712c57be11ad8
  Author: Charles Strahan 
  Date:   2016-10-11 (Tue, 11 Oct 2016)

  Changed paths:
M lib/trivial.nix
M nixos/modules/system/boot/kernel.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  nixos: make it easy to apply kernel patches

This makes it easy to specify kernel patches:

boot.kernelPatches = [ pkgs.kernelPatches.ubuntu_fan_4_4 ];

To make the `boot.kernelPatches` option possible, this also makes it
easy to extend and/or modify the kernel packages within a linuxPackages
set. For example:

pkgs.linuxPackages.extend (self: super: {
  kernel = super.kernel.override {
  kernelPatches = super.kernel.kernelPatches ++ [
pkgs.kernelPatches.ubuntu_fan_4_4
  ];
  };
});

Closes #15095


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] f9a383: nixos: xserver typematic configuration options

[Charles Strahan]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: f9a3835a14e9bee3fb36e7d96d332cf30a5a94af
  
https://github.com/NixOS/nixpkgs/commit/f9a3835a14e9bee3fb36e7d96d332cf30a5a94af
  Author: Charles Strahan 
  Date:   2016-10-03 (Mon, 03 Oct 2016)

  Changed paths:
M nixos/modules/services/x11/xserver.nix

  Log Message:
  ---
  nixos: xserver typematic configuration options

This allows one to set the seat defaults for keyboard auto-repeat delay
and rate.


  Commit: 7df35fd268a25093ccafab28dd750e2bd15fd45f
  
https://github.com/NixOS/nixpkgs/commit/7df35fd268a25093ccafab28dd750e2bd15fd45f
  Author: Charles Strahan 
  Date:   2016-10-03 (Mon, 03 Oct 2016)

  Changed paths:
M nixos/modules/services/x11/xserver.nix

  Log Message:
  ---
  Merge pull request #19143 from cstrahan/nixos-typematic

nixos: xserver typematic configuration options


Compare: https://github.com/NixOS/nixpkgs/compare/8cb56939554f...7df35fd268a2___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 6d3b06: Run riak with its `dataDir` as `HOME` so Erlang co...

[Charles Strahan]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 6d3b06ce37d178b50432f527d5b1583fec887399
  
https://github.com/NixOS/nixpkgs/commit/6d3b06ce37d178b50432f527d5b1583fec887399
  Author: Kevin van Zonneveld 
  Date:   2016-09-22 (Thu, 22 Sep 2016)

  Changed paths:
M nixos/modules/services/databases/riak.nix

  Log Message:
  ---
  Run riak with its `dataDir` as `HOME` so Erlang cookie can be written

See https://github.com/NixOS/nixpkgs/issues/18852


  Commit: 3fe8eca17b710a883aab8bfa4143d250f432196f
  
https://github.com/NixOS/nixpkgs/commit/3fe8eca17b710a883aab8bfa4143d250f432196f
  Author: Charles Strahan 
  Date:   2016-09-22 (Thu, 22 Sep 2016)

  Changed paths:
M nixos/modules/services/databases/riak.nix

  Log Message:
  ---
  Merge pull request #18853 from kvz/patch-2

Run riak with its `dataDir` as `HOME` so Erlang cookie can be written


Compare: https://github.com/NixOS/nixpkgs/compare/f62fef5fcba9...3fe8eca17b71___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] d5e24d: fanctl: 0.9.0 -> 0.12.0

[Charles Strahan]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: d5e24d3f8091ac04cccb1a34205fd0e93d9fa113
  
https://github.com/NixOS/nixpkgs/commit/d5e24d3f8091ac04cccb1a34205fd0e93d9fa113
  Author: Charles Strahan 
  Date:   2016-09-17 (Sat, 17 Sep 2016)

  Changed paths:
M pkgs/os-specific/linux/fanctl/default.nix

  Log Message:
  ---
  fanctl: 0.9.0 -> 0.12.0


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 358232: cnijfilter2: fix build

[Charles Strahan]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 358232f68abf341b731ef12b0e1febb40cf78808
  
https://github.com/NixOS/nixpkgs/commit/358232f68abf341b731ef12b0e1febb40cf78808
  Author: Charles Strahan 
  Date:   2016-09-17 (Sat, 17 Sep 2016)

  Changed paths:
M pkgs/misc/cups/drivers/cnijfilter2/default.nix

  Log Message:
  ---
  cnijfilter2: fix build


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 42a34a: redis-desktop-manager: fix build (#18543)

[Charles Strahan]

  Branch: refs/heads/release-16.09
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 42a34a713df5d419382e40ad2d9cb7c9efb328cf
  
https://github.com/NixOS/nixpkgs/commit/42a34a713df5d419382e40ad2d9cb7c9efb328cf
  Author: Charles Strahan 
  Date:   2016-09-13 (Tue, 13 Sep 2016)

  Changed paths:
M pkgs/applications/misc/redis-desktop-manager/default.nix

  Log Message:
  ---
  redis-desktop-manager: fix build (#18543)

We need to run the pre/post configure hooks.
(cherry picked from commit 3e7bb6579bccd885c67bca47ad1a4592769260f0)

Signed-off-by: Domen Kožar 


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 3e7bb6: redis-desktop-manager: fix build (#18543)

[Charles Strahan]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 3e7bb6579bccd885c67bca47ad1a4592769260f0
  
https://github.com/NixOS/nixpkgs/commit/3e7bb6579bccd885c67bca47ad1a4592769260f0
  Author: Charles Strahan 
  Date:   2016-09-13 (Tue, 13 Sep 2016)

  Changed paths:
M pkgs/applications/misc/redis-desktop-manager/default.nix

  Log Message:
  ---
  redis-desktop-manager: fix build (#18543)

We need to run the pre/post configure hooks.


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 4e84c6: cnijfilter2: init at 5.30 (#17048)

[Charles Strahan]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 4e84c6fc7cbf3f66267be56c2af518e6efe236fc
  
https://github.com/NixOS/nixpkgs/commit/4e84c6fc7cbf3f66267be56c2af518e6efe236fc
  Author: Charles Strahan 
  Date:   2016-07-21 (Thu, 21 Jul 2016)

  Changed paths:
A pkgs/misc/cups/drivers/cnijfilter2/default.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  cnijfilter2: init at 5.30 (#17048)

Canon InkJet printer drivers for the MG7500, MG6700, MG6600, MG5600,
MG2900, MB2000, MB2300, iB4000, MB5000, MB5300, iP110, E450, MX490,
E480, MG7700, MG6900, MG6800, MG5700, MG3600, and G3000 series.


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] cd0d09: mnemonicode: init at 2015-11-30

[Charles Strahan]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: cd0d0944f9272e7d29131cfdd3e155ad13cd171b
  
https://github.com/NixOS/nixpkgs/commit/cd0d0944f9272e7d29131cfdd3e155ad13cd171b
  Author: Charles Strahan 
  Date:   2016-05-19 (Thu, 19 May 2016)

  Changed paths:
A pkgs/misc/mnemonicode/default.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  mnemonicode: init at 2015-11-30

mnemonicode is a set of routines which implement a method for encoding
binary data into a sequence of words which can be spoken over the phone,
for example, and converted back to data on the other side.


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 612d4a: mnemonicode: fix name

[Charles Strahan]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 612d4a16847474f6cf5cc0fab93545efcd82a1da
  
https://github.com/NixOS/nixpkgs/commit/612d4a16847474f6cf5cc0fab93545efcd82a1da
  Author: Charles Strahan 
  Date:   2016-05-19 (Thu, 19 May 2016)

  Changed paths:
M pkgs/misc/mnemonicode/default.nix

  Log Message:
  ---
  mnemonicode: fix name


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 5d5403: maintainers: update cstrahan's email address

[Charles Strahan]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 5d540387713f2d29dac423f5faadafd5aea2ff09
  
https://github.com/NixOS/nixpkgs/commit/5d540387713f2d29dac423f5faadafd5aea2ff09
  Author: Charles Strahan 
  Date:   2016-05-19 (Thu, 19 May 2016)

  Changed paths:
M lib/maintainers.nix

  Log Message:
  ---
  maintainers: update cstrahan's email address


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-dev] Feedback requested: new `boot.kernelPatches` option

[Charles Strahan]

Hello,

Nahum Shalman and I were chatting on #nixos, and he was having the same
trouble I once had when trying to apply kernel patches. As a result of
that conversation, I have opened a pull request
(https://github.com/NixOS/nixpkgs/pull/15095) adding support for easily
specifying kernel patches in one's NixOS configuration, and I'd greatly
appreciate some feedback.

Here's an example of using the new boot.kernelPatches option:

  boot.kernelPatches = [ pkgs.kernelPatches.ubuntu_fan_4_4 ];

A bit of back story, as well as a description of its use and
implementation:

Back in August of 2015, I needed to apply some kernel patches. The first
thing I did was look to the wiki
(https://nixos.org/wiki/How_to_tweak_Linux_kernel_config_options), which
suggested doing something like this:

  nixpkgs.config = {
packageOverrides = pkgs: {
  stdenv = pkgs.stdenv // {
platform = pkgs.stdenv.platform // {
  kernelPatches = [
{ patch = ../patches/i915_317.patch; name = "i915-fix"; };
{ patch =
../patches/override_for_missing_acs_capabilities.patch;
  name = "acs_overrides"; };
  ];
};
  }; 
};
  };

I find that rather unintuitive (if not an outright hack). After studying
the relevant expressions, I amended the wiki page to suggest the
following (which is almost identical to the suggestion in the manual
today):

   nixpkgs.config = {
 packageOverrides = super: let self = super.pkgs; in {
   linux_3_18 = super.linux_3_18.override {
 kernelPatches = super.linux_3_18.kernelPatches ++ [
   # we'll add the Ubuntu Fan Networking patches from Nixpkgs
   self.kernelPatches.ubuntu_fan

   # and we'll also add one of our own patches
   { patch = ../patches/i915_317.patch; name = "i915-fix"; }
 ];

 # add "CONFIG_PPP_FILTER y" option to the set of kernel options
 extraConfig = "PPP_FILTER y" ;
   };
 };
   };

That's still pretty bad, as we're attempting override the kernel while
hoping that `linux_3_18` is the kernel used by the `linuxPackages`
attribute (which happens to be the default value for the
`boot.kernelPackages` NixOS option) -- too many assumptions being made,
too fragile.

Let's take another look at the new `boot.kernelPatches` option:

  boot.kernelPatches = [ pkgs.kernelPatches.ubuntu_fan_4_4 ];

Much better, no?


To implement this option, I also had to add support for overriding the
kernel and/or packages within a given `linuxPackages` set. This is done
by using the new `linuxPackages.override` attribute like so:

  pkgs.linuxPackages.override (self: super: {
kernel = super.kernel.override {
  kernelPatches = super.kernel.kernelPatches ++ [
  pkgs.kernelPatches.ubuntu_fan_4_4 ];
};
  });

As a result, setting fine grained options for one's kernel (or adjusting
each of the kernel packages) can look something like this:

  boot.kernelPackages = pkgs.linuxPackages.override (self: super: {
kernel = super.kernel.override {
  kernelPatches = super.kernel.kernelPatches ++ [
  pkgs.kernelPatches.ubuntu_fan_4_4 ];
  extraConfig = "PPP_FILTER y" ;
};
  });

I think that's a lot cleaner. Granted, the value of
`boot.kernelPackages` will not be the same value as `pkgs.linuxPackages`
(e.g. the value that the rest of nixpkgs refers to), but that's
addressed by doing the following instead:

  nixpkgs.config = {
packageOverrides = super: let self = super.pkgs; in {
  linuxPackages = super.linuxPackages.override (self: super: {
kernel = super.kernel.override {
  kernelPatches = super.kernel.kernelPatches ++ [
  pkgs.kernelPatches.ubuntu_fan_4_4 ];
  extraConfig = "PPP_FILTER y" ;
};
  });
 };
   };


(Ideally, the `boot.kernelPatches` option would effectively do the
latter, that way the system closure doesn't include two
kernels/kernelPackages: one for the running kernel (i.e.
boot.kernelPackages) and another for every occurrence of `linuxPackages`
within nixpkgs. Regardless, this pull request doesn't make things any
worse off: today, if you set the `boot.kernelPackages` options to
anything other than `pkgs.linuxPackages`, you now have *two* sets of
kernel packages in your system's build-time (and maybe also run-time)
closure. In the future, we might want to find some way to push the value
of `boot.kernelPackages` into nixpkgs, as we don't have a suitable
mechanism for that today.)


After implementing the `override` mechanism for `linuxPackages`, I
realized it would be trivial to factor out a reusable function:

  # Create an overridable, recursive attribute set. For example:
  #
  # nix-repl> obj = makeObject (self: { })
  #
  # nix-repl> obj
  # { override = «lambda»; }
  #
  # nix-repl> obj = obj.override (self: super: { foo = "foo"; })
  #
  # nix-repl> obj
  # { foo = "foo"; override = «lambda»; }
  #
  # nix-repl> obj = obj.override (sel

Re: [Nix-dev] Set up a Sufficiently Powerful Build Farm

[Charles Strahan]

This is great news :)

Rob, do you know how much of a difference the additional Mac Minis have
made?

Also, to which address can I ship a Mac Mini? If another Mini would make
a difference, I'd be more than happy to buy and ship one to the
foundation.

Charles

On Wed, Dec 23, 2015, at 12:12 PM, Rob Vermaas wrote:
> Hi,
> 
> On Tue, Dec 22, 2015 at 2:23 PM, Daniel Peebles 
> wrote:
> > I don't have a good sense of how many the foundation can keep, but for now
> > I'm not concerned about us having too many :) the more we get, the more
> > responsive we'll be.
> >
> > As it stands, I think we have two (oldish) Darwin cores on Hydra today, so
> > when my 4-core box arrives (assuming it works well) it should give us more
> > than 3x the current power :) I paid $589 for it and another $55 for shipping
> > from the US. Most of the ones for sale on eBay are the newer (but not
> > newest) generation and are thus a bit more expensive than the one I got.
> >
> > I think we'd be in a reasonably comfortable place if we could get 3 or 4
> > more of those boxes, but if we could get more I obviously wouldn't complain.
> >
> > I'd love for us to have Darwin be a nearly first-class citizen of nixpkgs,
> > but potential adopters (and thus contributors) are going to be turned off if
> > they need to recompile the world if they get anywhere near master.
> 
> Thanks to Dan for arranging an extra (powerful) Mac Mini and donating
> it to the Foundation!
> 
> Additionally, in the next few weeks, the NixOS Foundation will buy 2
> more Mac Mini's, which, together with Dan's Mac Mini and the existing
> one, should improve our Darwin build times significantly. We will look
> for further expansion of the Mac fleet once we get more information on
> the effects of the additional machines.
> 
> Cheers,
> Rob
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Logo improvement ideas

[Charles Strahan]

Wow, these logos look really nice! I agree that any of these would be an
improvement.

-Charles

On Fri, Aug 28, 2015, at 04:32 AM, Cillian de Róiste wrote:
> Woops! ... I sent this directly to Tim rather than to the list:
> 
> 
> 2015-08-26 2:09 GMT+02:00 Tim Cuthbertson :
> > On Wed, Aug 26, 2015 at 2:16 AM, Cillian de Róiste
> >  wrote:
> >> Hi Tim,
> >>
> >> Very interesting designs! There was some talk at FOSDEM this year
> >> about brushing up the design/branding in general. I was really hoping
> >> we could get a designer on board to help with that although it fell
> >> through (but maybe you are a designer?).
> >
> > Unfortunately not, I just played one in high school ;).
> 
> Ah, well that may be the closest we've got :D ... although I think
> kmicu on IRC has some design experience too.
> 
> >> Before updating the logo, I
> >> wonder if we should step back a bit and think about what the logo
> >> should communicate. I added a stub of a page to the wiki to develop a
> >> style guide, but I haven't done much with it since:
> >> https://nixos.org/wiki/Style_Guide . Would something like that be a
> >> good place to start?
> >
> > It certainly might be, but I'm not really sure of the composition of
> > folks working on Nix / NixOS - are there designer types that could
> > help with this? Personally I do a bit of graphic design as a hobbyist
> > (thus my interest in the logo), but don't have much to contribute
> > outside that in terms of branding / figuring out style guides. So this
> > is a good idea, but will only go somewhere if there are enough people
> > wanting to contribute to it.
> 
> Ah, fair enough. I think we could get help from the
> opensourcedesigners gang, but we don't have anyone at the moment. It
> would be awesome to get someone on board for this. One thing they
> suggest is to add a github ticket and label it "design". Perhaps you
> could kick this off with your work on the logo and see if it catches
> anyone's interest?
> 
> >> BTW, The issues with the overlapping lambdas in the current logo
> >> should be solved in this version:
> >> https://github.com/NixOS/nixos-artwork/blob/master/logo/nix-snowflake.svg
> >
> > I'm afraid I don't see it - this looks identical to the current logo
> > to me. Maybe that's the point (I'm not sure what "overlapping" you're
> > referring to),...
> 
> Yeah, they look identical, but in the original each lambda overlaps,
> and there's an extra shape which masks the first lambda. In this
> version they are cut at the intersections. If you open the file in
> inkscape and ungroup the lambdas and move one, I think it will be
> clear ... at any rate it's just a detail.
> 
> > but I find it hard to spot the lambdas in this version
> > for two reasons:
> >
> >  - they're not separate enough. Aside from being different colours,
> > there is no gap or other obvious distinction between each
> >
> >  - (I think) the lack of any upright lambda makes it less likely you'd
> > notice, as well.
> >
> >> I'm pretty sure we can get help with the colors from
> >> http://opensourcedesign.net (I've asked them about it before, but
> >> figured we should work on the style guide first).
> >>
> >> Personally, I'm really fond of the current logo, although I would
> >> really like if we decided on a standard font (I'm a fan of Varela
> >> Round, to go with the current logo). Most of all I'd love if we could
> >> have a style guide, and have templates everyone could use for flyers,
> >> posters, t-shirts etc. I'd really love if NixOS could be themeable
> >> from configuration.nix too, but that's another story :D
> >
> > Yes, fonts are important too, and I haven't done too much work there
> > other than flipping through my installed fonts to pick one which
> > didn't look awful ;)
> > Varela Round certainly matches the current logo's style well, although
> > I suspect it might be better to have a font which doesn't match the
> > logo's form quite so well (if the whole logo is made of rounded
> > sticks, that could get a little bland).
> 
> That makes perfect sense, thanks! I'm sure your sense of what doesn't
> look awful would already be a great improvement on what we have at the
> moment :D ... Myriad Pro is used a bit, and is nice but it's not Free,
> so that's a problem.
> 
> >> What do you think? Perhaps we could have some kind of a video
> >> conferencing session with anyone who's interested to get the ball
> >> rolling?
> >
> > Yeah, collecting interested parties is certainly a good idea (although
> > video conference might be hard to organise timezone-wise). I'm not
> > entirely sure how to solicit that - anyone else on the mailing list
> > interested?
> 
> FWIW, I'm free on Sunday (except early morning, UTC). I could see if
> anyone from the opensourcedesigners would be interested in helping out
> too. Would that suit anyone? Naturally, it will be entirely up to the
> foundation to decide whether or not they are interested in adopting
> any suggestions we might come up with

Re: [Nix-dev] vagrant-nixos-plugin

[Charles Strahan]

Hello,

I'd like to point out that I got (some) support for NixOS baked-into
vagrant itself a while back:

https://github.com/mitchellh/vagrant/pull/3830

Might be worth looking at touching-up/rewriting as you see fit, rather
than creating a plugin (unless you prefer that release model).

-Charles

On Tue, Sep 1, 2015, at 04:19 PM, Alexander Flatter wrote:
> Hello Christian,
>
> this is great - I’m looking forward to play with this.
>
>> On 01 Sep 2015, at 22:14, Christian Theune
>>  wrote:
>>
>> Hi,
>>
>> even though the "vagrant-nixos” plugin was featured on the Twitter
>> feed recently - the original author seems to be MIA and Zimbatm and I
>> want to move forward. We’ve been trying to get in contact for a
>> couple of months now and we thought it’s time to fork and move on.
>>
>> We have created “vagrant-nixos-plugin” [1] (yeah, we’re screwed, the
>> name of the ruby gem is gone until the original Chris reappears) and
>> forked it on Github. We’re currently working on cleaning it up,
>> getting a few bugs that have been annoying Zimbatm and me, and then
>> also provide pre-baked 15.09 Vagrant images.
>>
>> This will take a couple of days, but if anyone wants to jump onboard,
>> you’re obviously welcome.
>>
>> At some point we think it could be worthwhile to move those
>> repositories (for the Vagrant imaging and the plugin) under the NixOS
>> team umbrella.
>>
>> Cheers, Christian
>>
>> [1]https://github.com/zimbatm/vagrant-nixos-plugin
>>
>> — Christian Theune · c...@flyingcircus.io · +49 345 219401 0 Flying
>> Circus Internet Operations GmbH · http://flyingcircus.io
>> Forsterstraße 29 · 06112 Halle (Saale) · Deutschland HR Stendal HRB
>> 21169 · Geschäftsführer: Christian. Theune, Christian. Zagrodnick
>>
>> ___
>> 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 Email had 1
> attachment:


>  * signature.asc  1k (application/pgp-signature)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] ANN: Ruby packaging changes coming soon

[Charles Strahan]

Hello all,

In the next day or two, I intend to merge this PR:
https://github.com/NixOS/nixpkgs/pull/8612

This will greatly improve the way we handle Ruby/Bundler packages.

Before I introduce the benefits, I'd like to draw attention to a
breaking change: you should now pass `gemName` and `version` to
`buildRubyGem`, instead of passing `name`. For example:

  buildRubyGem {
name = "some-name"; # name now specifies the drv name,
# which defaults to
--
gemName = "some-gem";
version = "1.2.3";
sha256  = "08p5gx18yrbnwc6xc0mxvsfaxzgy2y9i78xq7ds0qmdm67q39y4z";
gemPath = [ /* other gem deps go here */ ];
  }

Now, on to the bundlerEnv improvements.

These changes greatly simplify things over the existing approach. A lot
of grossness originally came from the fact that Bundler _requires_ a
single prefix in order to function. So, I originally wrote enough hacks
and monkey-patches to get Bundler to install all gems in one go,
patching over internals to prevent Bundler from trying to reach out to
the internet (Bundler has practically no useful, public, stable API, so
patching is the only way to go). The hacks I wrote were incredibly ugly
and hard to follow, and they've weighed considerably on my conscience
for quite some time.

Going forward, we'll have a much, much smaller set of patches to get
Bundler to install into individual prefixes, and then we create a
symlink forest at the very end to appease Bundler. Even with a little
extra added documentation, the diff still comes out with fewer lines
added than removed, and (I think) the implementation is a little less
bat-shit-crazy.

-Charles
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Vagrant stuff - images and plugin - still alive?

[Charles Strahan]

Hey, just pulled those PRs. (If GitHub has a way to see pending PRs for
all of one's repos, I'm not aware of it...)

-Charles


On Tue, May 12, 2015, at 03:33 PM, Wout Mertens wrote:
> Yeah, Charles seems to be AWOL for a bit, it would be nice if he
> merged my PR... Charles?
>
> Wout.
>
> On Tue, May 12, 2015 at 4:30 PM Christian Theune
>  wrote:
>>
>>
> On 12 May 2015, at 16:19, Christian Theune  wrote:
>>
>
>>
>
>>
>> On 12 May 2015, at 16:11, Christian Theune
>>  wrote:
>>
>>
>>
>> Hi,
>>
>>
>>
>> I contacted a few people and got zimbatm to react. I’m trying to get
>> his 14.12 branch working. I’ll also have a look at the one from
>> cstrahan.
>>
>
>>
> Or actually the one from Wout. (*waves*)
>>
>>
So that one builds 14.12 cleanly right away for me. It also provides
partial integration points expected by oxdi’s plugin.
>>
>>
Christian
>>
>>
—
>>
Christian Theune · c...@flyingcircus.io · +49 345 219401 0
>>
Flying Circus Internet Operations GmbH · http://flyingcircus.io
>>
Forsterstraße 29 · 06112 Halle (Saale) · Deutschland
>>
HR Stendal HRB 21169 · Geschäftsführer: Christian. Theune, Christian.
Zagrodnick
>>
>>
___
>>
nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev

___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] ANNOUNCE: GHCJS support in Haskell-NG

[Charles Strahan]

I'm pleased to announce that GHCJS support for Haskell-NG has landed on
master, using the recent GHC 7.10 release. Thanks again to Ryan Trinkle
for laying the groundwork, Luite Stegeman for making GHCJS, and Peter
Simons for reviewing my work and filing off the rough edges.

https://github.com/NixOS/nixpkgs/pull/6786

Cheers,

-Charles
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Developing Haskell packages that use the FFI

[Charles Strahan]

Ian,

I have a pull request open that fixes hs-mesos:
https://github.com/NixOS/nixpkgs/pull/6824

Now, regarding ZFS:

The latest ZFS release doesn't include pkgconfig files (they were added
recently, though[1]). I'll see if I can backport the files to the
latest release in nixpkgs. Regardless, you should be able to use
zfs_git in nixpkgs, which does have the files. You should be able to do
something like:

{ mkDerivation, pkgs}: mkDerivation { # ... extraLibraries= [
pkgs.zfs_git ]; # ... }

And in your .cabal file:

pkgconfig-depends: libzfs

-Charles

On Sun, Mar 15, 2015, at 03:30 PM, Charles Strahan wrote:
> Hey Ian,
>
> It looks like the version of protobuf is propogated by the the
> pythonProtobuf passed in to the mesos package, which uses protobuf
> 2.6. Does that need to be 2.5 (or some other version)? It looks like
> the version of protobuf that mesos build is using is the one packaged
> with the source, so it might be that the version of the python package
> should be different, and we just haven't noticed it yet.
>
> I'm not sure about the libzfs problem, though. Assuming libzfs
> includes a proper pkg-config setup, you should be able to add
> `pkgconfig' to the list of buildInputs, and I think Cabal should get
> the correct paths (e.g. the $PKG_CONFIG_PATH variable should
> automatically be configured properly).
>
> I'm interested in using your hs-mesos package, so I'd be more than
> happy to help you work out the kinks on #nixos (I'm cstrahan) or some
> other medium.
>
> -Charles
>
> On Fri, Mar 6, 2015, at 11:36 PM, Ian Duncan wrote:
>> Hi there,


>> I’m pretty new to NixOS, and I’m trying to get into using it for
>> Haskell development. So far, I’ve been following the guide here
>> (http://wiki.ocharles.org.uk/Nix) with moderate success for libraries
>> that don’t directly need to interact with C/C++ libraries. However,
>> I’ve got some projects that I’m working on that use “picky” libraries
>> (for lack of a better term).


>> To be specific, I’ve got two packages that I’m working on that are
>> giving me grief:


>>  * I’m working on a package that depends on the hs-mesos cabal
>>package, but I’m ending up with the wrong version of the C++
>>protobuf library (incompatible headers) due to Nix somehow
>>automatically picking up the wrong protobuf dependency for using
>>the mesos C++ headers. How can I configure what version of
>>protobuf is used for mesos / hs-mesos? My shell.nix is:


>> with (import  {}).pkgs;
(haskellngPackages.callPackage ./. {}).env
>>
>> And my default.nix is:


>> { mkDerivation, base, hs-mesos, hzk, lens, stdenv, stm }:
mkDerivation { pname = "mesotron"; version = "0.1.0.0"; src = ./.;
isLibrary = false; isExecutable = true; buildDepends = [ base hs-mesos
hzk lens stm ]; license = stdenv.lib.licenses.unfree; }
>>
>>  * Similarly, I’m trying to write Haskell bindings for libzfs, don’t
>>know how to pull in the zfs dependency properly. This one seems to
>>be more complex– I need to add something like
>>${zfs}/include/libspl & ${zfs}/include/libzfs to the include
>>paths, but even after doing that, I get macro recursion errors in
>>glib? In file included from
>>
>> /nix/store/93zfs0zzndi7pkjkjxawlafdj8m90kg5-glibc-2.20/include/unistd.h:610:0:
, from

/nix/store/g6d4ddw286x57m5drm905fhnqac68i8q-zfs-user-0.6.3-1.2/include/libspl/unistd.h:28,
from

/nix/store/g6d4ddw286x57m5drm905fhnqac68i8q-zfs-user-0.6.3-1.2/include/libspl/sys/param.h:32,
from

/nix/store/g6d4ddw286x57m5drm905fhnqac68i8q-zfs-user-0.6.3-1.2/include/libspl/sys/types.h:34,
from
/nix/store/93zfs0zzndi7pkjkjxawlafdj8m90kg5-glibc-2.20/include/stdlib.h:315,
from

/nix/store/g6d4ddw286x57m5drm905fhnqac68i8q-zfs-user-0.6.3-1.2/include/libspl/stdlib.h:28,
from

/nix/store/g6d4ddw286x57m5drm905fhnqac68i8q-zfs-user-0.6.3-1.2/include/libspl/assert.h:34,
from

/nix/store/g6d4ddw286x57m5drm905fhnqac68i8q-zfs-user-0.6.3-1.2/include/libzfs/libzfs.h:34,
from src/ZFS.hs:4:

/nix/store/93zfs0zzndi7pkjkjxawlafdj8m90kg5-glibc-2.20/include/bits/confname.h:201:0:
error: detected recursion whilst expanding macro "_SC_UIO_MAXIOV"
_SC_IOV_MAX = _SC_UIO_MAXIOV, ^

/nix/store/93zfs0zzndi7pkjkjxawlafdj8m90kg5-glibc-2.20/include/bits/confname.h:497:0:
error: detected recursion whilst expanding macro
"_SC_LEVEL1_ICACHE_SIZE" _SC_IPV6 = _SC_LEVEL1_ICACHE_SIZE + 50, ^

In file included from
/nix/store/g6d4ddw286x57m5drm905fhnqac68i8q-zfs-user-0.6.3-1.2/include/libzfs/libzfs.h:34:0:
, from src/ZFS.hs:4:

/nix/store/g6d4ddw286x57m5drm905fhnqac68i8q-zfs-user-0.6.3-1.2/include/libspl/assert.h:39:0:
error: detecte

Re: [Nix-dev] Developing Haskell packages that use the FFI

[Charles Strahan]

Hey Ian,

It looks like the version of protobuf is propogated by the the
pythonProtobuf passed in to the mesos package, which uses protobuf 2.6.
Does that need to be 2.5 (or some other version)? It looks like the
version of protobuf that mesos build is using is the one packaged with
the source, so it might be that the version of the python package should
be different, and we just haven't noticed it yet.

I'm not sure about the libzfs problem, though. Assuming libzfs includes
a proper pkg-config setup, you should be able to add `pkgconfig' to the
list of buildInputs, and I think Cabal should get the correct paths
(e.g. the $PKG_CONFIG_PATH variable should automatically be configured
properly).

I'm interested in using your hs-mesos package, so I'd be more than
happy to help you work out the kinks on #nixos (I'm cstrahan) or some
other medium.

-Charles

On Fri, Mar 6, 2015, at 11:36 PM, Ian Duncan wrote:
> Hi there,


> I’m pretty new to NixOS, and I’m trying to get into using it for
> Haskell development. So far, I’ve been following the guide here
> (http://wiki.ocharles.org.uk/Nix) with moderate success for libraries
> that don’t directly need to interact with C/C++ libraries. However,
> I’ve got some projects that I’m working on that use “picky” libraries
> (for lack of a better term).


> To be specific, I’ve got two packages that I’m working on that are
> giving me grief:


>  * I’m working on a package that depends on the hs-mesos cabal
>package, but I’m ending up with the wrong version of the C++
>protobuf library (incompatible headers) due to Nix somehow
>automatically picking up the wrong protobuf dependency for using
>the mesos C++ headers. How can I configure what version of protobuf
>is used for mesos / hs-mesos? My shell.nix is:


> with (import  {}).pkgs;
(haskellngPackages.callPackage ./. {}).env
>
> And my default.nix is:


> { mkDerivation, base, hs-mesos, hzk, lens, stdenv, stm }:
mkDerivation { pname = "mesotron"; version = "0.1.0.0"; src = ./.;
isLibrary = false; isExecutable = true; buildDepends = [ base hs-mesos
hzk lens stm ]; license = stdenv.lib.licenses.unfree; }
>
>  * Similarly, I’m trying to write Haskell bindings for libzfs, don’t
>know how to pull in the zfs dependency properly. This one seems to
>be more complex– I need to add something like ${zfs}/include/libspl
>& ${zfs}/include/libzfs to the include paths, but even after doing
>that, I get macro recursion errors in glib? In file included from
>
> /nix/store/93zfs0zzndi7pkjkjxawlafdj8m90kg5-glibc-2.20/include/unistd.h:610:0:
, from

/nix/store/g6d4ddw286x57m5drm905fhnqac68i8q-zfs-user-0.6.3-1.2/include/libspl/unistd.h:28,
from

/nix/store/g6d4ddw286x57m5drm905fhnqac68i8q-zfs-user-0.6.3-1.2/include/libspl/sys/param.h:32,
from

/nix/store/g6d4ddw286x57m5drm905fhnqac68i8q-zfs-user-0.6.3-1.2/include/libspl/sys/types.h:34,
from
/nix/store/93zfs0zzndi7pkjkjxawlafdj8m90kg5-glibc-2.20/include/stdlib.h:315,
from

/nix/store/g6d4ddw286x57m5drm905fhnqac68i8q-zfs-user-0.6.3-1.2/include/libspl/stdlib.h:28,
from

/nix/store/g6d4ddw286x57m5drm905fhnqac68i8q-zfs-user-0.6.3-1.2/include/libspl/assert.h:34,
from

/nix/store/g6d4ddw286x57m5drm905fhnqac68i8q-zfs-user-0.6.3-1.2/include/libzfs/libzfs.h:34,
from src/ZFS.hs:4:

/nix/store/93zfs0zzndi7pkjkjxawlafdj8m90kg5-glibc-2.20/include/bits/confname.h:201:0:
error: detected recursion whilst expanding macro "_SC_UIO_MAXIOV"
_SC_IOV_MAX = _SC_UIO_MAXIOV, ^

/nix/store/93zfs0zzndi7pkjkjxawlafdj8m90kg5-glibc-2.20/include/bits/confname.h:497:0:
error: detected recursion whilst expanding macro
"_SC_LEVEL1_ICACHE_SIZE" _SC_IPV6 = _SC_LEVEL1_ICACHE_SIZE + 50, ^

In file included from
/nix/store/g6d4ddw286x57m5drm905fhnqac68i8q-zfs-user-0.6.3-1.2/include/libzfs/libzfs.h:34:0:
, from src/ZFS.hs:4:

/nix/store/g6d4ddw286x57m5drm905fhnqac68i8q-zfs-user-0.6.3-1.2/include/libspl/assert.h:39:0:
error: detected recursion whilst expanding macro "stderr"
fprintf(stderr, "%s:%i: %s: Assertion `%s` failed.\n", ^
>
> Anyways, these questions are kind of ill-formed, for which I
> apologize. I’m not really sure what I’m missing here, and I just
> don’t have enough experience with Nix yet to understand what I’m
> doing wrong.


>


>
>
>
> – Ian Duncan
>
>


> _
> nix-dev mailing list nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev

___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Apologies for my absence

[Charles Strahan]

Hey gang,

Sorry for my absence the past couple weeks. I've been sorting out some
personal matters lately and haven't been able to devote any time to the
project.

Now that I've reestablished some sanity to my daily routine, I'm going
to try to divert some of my resources back into Nix over the next couple
weeks.

-Charles
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Announcing New Ruby Support

[Charles Strahan]

> Ideally (for me as user) would be to be able to
>
> nix-env -iA pkgs.rubyGems.

I have some ideas, but I first need to get some patches into Bundler and
Rubygems.org.

> I've opened https://github.com/NixOS/nixpkgs/issues/5985 to address
documentation regarding this change.
>
> PS: we should also migrate redmine to the new infrastructure:
https://github.com/NixOS/nixpkgs/issues/5984

I'll add those to my list. Can't give a time estimate at the moment, I'm
afraid.

On Mon, Jan 26, 2015 at 5:03 AM, Domen Kožar  wrote:

> I've opened https://github.com/NixOS/nixpkgs/issues/5985 to address
> documentation regarding this change.
>
> PS: we should also migrate redmine to the new infrastructure:
> https://github.com/NixOS/nixpkgs/issues/5984
>
> On Thu, Jan 22, 2015 at 9:03 AM, Matthias Beyer 
> wrote:
>
>> Hi,
>>
>> On 21-01-2015 23:29:55, Charles Strahan wrote:
>> >Hello all,
>> >I'm pleased to announce that the Pleasant Ruby PR has landed on
>> master.
>>
>> this is awesome news!
>>
>> >The new
>> >feature - bundlerEnv - allows one to package Ruby applications with
>> >Bundler.
>> >To use the new system, first create (or copy over) a Gemfile
>> describing
>> >the
>> >required gems.
>> >Next, create a Gemfile.lock by running `bundler package
>> --no-install` in
>> >the
>> >containing directory (this also creates two folders - vendor and
>> .bundle -
>> >which you'll want to delete before committing).
>> >Now, you'll need to dump the lockfile as a Nix expression. To do so,
>> use
>> >Bundix
>> >in the target directory:
>> >A  $(nix-build '' -A bundix)/bin/bundix
>> >That will drop a gemset.nix file in your current directory, which
>> >describes the
>> >sources for all of the gems and their respective SHAs.
>> >Finally, you'll need to use bundlerEnv to build the gems. The
>> following
>> >example
>> >is how we package the sup mail reader:
>> >[...]
>>
>> Is there a way to even automat these steps?
>>
>> Ideally (for me as user) would be to be able to
>>
>> nix-env -iA pkgs.rubyGems.
>>
>> and nix figures out everything, including dependencies and so on.
>>
>> I don't know whether this is possible or not, but I guess it would be
>> really cool and also beneficial in manner of packaging/maintaining
>> effort.
>>
>> Anyways, nice to hear that Ruby support gets better!
>>
>> --
>> Mit freundlichen Grüßen,
>> Kind regards,
>> Matthias Beyer
>>
>> Proudly sent with mutt.
>> Happily signed with gnupg.
>>
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Announcing New Ruby Support

[Charles Strahan]

Hello all,

I'm pleased to announce that the Pleasant Ruby PR has landed on master. The
new
feature - bundlerEnv - allows one to package Ruby applications with Bundler.

To use the new system, first create (or copy over) a Gemfile describing the
required gems.

Next, create a Gemfile.lock by running `bundler package --no-install` in the
containing directory (this also creates two folders - vendor and .bundle -
which you'll want to delete before committing).

Now, you'll need to dump the lockfile as a Nix expression. To do so, use
Bundix
in the target directory:

  $(nix-build '' -A bundix)/bin/bundix

That will drop a gemset.nix file in your current directory, which describes
the
sources for all of the gems and their respective SHAs.

Finally, you'll need to use bundlerEnv to build the gems. The following
example
is how we package the sup mail reader:

  { stdenv, lib, bundlerEnv, gpgme, ruby, ncurses, writeText, zlib, xapian
  , pkgconfig, which }:

  bundlerEnv {
name = "sup-0.20.0";

inherit ruby;
gemfile = ./Gemfile;
lockfile = ./Gemfile.lock;
gemset = ./gemset.nix;

# This is implicit:
#
#   gemConfig = defaultGemConfig;
#
# You could just as well do the following:
#
#   gemConfig.ncursesw = spec: {
# buildInputs = [ ncurses ];
# buildFlags = [
#   "--with-cflags=-I${ncurses}/include"
#   "--with-ldflags=-L${ncurses}/lib"
# ];
#   };
#
# Where `spec` is the attributes of the corresponding gem,
# in case you wanted to make something predicated on version,
# for example.
#
# See default-gem-config.nix for more examples.

meta = with lib; {
  description = "A curses threads-with-tags style email client";
  homepage= http://supmua.org;
  license = with licenses; gpl2;
  maintainers = with maintainers; [ cstrahan lovek323 ];
  platforms   = platforms.unix;
};
  }

And that's all there is to it!

Enjoy,

-Charles
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] less: When assumptions ruin the world

[Charles Strahan]

I agree with this. I have `less` configured to restore the screen at
termination
(via smcup/rmcup), which is a bit annoying if I want to keep the results
around.

I'd rather be explicit about opting-in to the pager being used (with `|
less`)
rather than opting-out (with `| cat`).

I also have to explicitly hit 'q' to get back to my shell.

Perhaps suggesting shell aliases would be sufficient for those that may
want the
pager by default?

-Charles


On Thu, Jan 1, 2015 at 8:36 PM, Ertugrul Söylemez  wrote:

> Hi everybody,
>
> since Nix 1.8 much of the output of nix commands is piped through
> `less`, which is certainly meant to be a convenience, but that
> convenience depends on a few assumptions:
>
>   * the user uses a crappy terminal emulator,
>   * the user is interested in all of the output,
>   * the user reads using their eyes.
>
> The first assumption is wrong for me and probably for a lot of other
> people as well.  The second assumption is wrong for me most of the time;
> in most cases only the last few lines are interesting.  The third one is
> wrong for blind people.  If they can't afford an external braille
> terminal (not those single-line pads, which are expensive enough, but a
> real terminal), they will rely on text-to-speech.
>
> If not all three assumptions hold, then this "feature" makes Nix
> consistently `less` convenient to use.  Not only do I have to press `q`
> now, but `less` is an ncurses program, which means that the output
> disappears after quitting.  This does not happen when I just use my
> terminal emulator to scroll, and yes, most of them if not all allow
> scrolling with the keyboard (commonly Shift+PageUp and Shift+PageDown).
>
> Furthermore we hold in our hands an operating system that follows the
> Unix philosophy, which is about composability.  There is simply no need
> to precompose everything with `less`.  As humans we are smart beings,
> and we have a powerful shell, so that every user can decide for
> themselves when to use a pager.
>
> Also remember that we may have disabled users.  A blind person will
> dislike this new anti-feature even more than I do, because `less` is not
> exactly a text-to-speech-friendly program.
>
> Feature request 1:  Please do your part in saving the software world and
> remove this anti-feature.  Don't even consider making it optional.  It's
> useless.  Remove it.  In the future, whenever you think that some
> UX-related automation will make things easier, think again.  You are
> most likely wrong.  Just look at the huge damage that Microsoft has done
> by assuming that users are complete idiots.
>
> Feature request 2:  Also I strongly believe that `--help` should
> absolutely never open a man-page.  When we need a manual, we will use
> the `man` command, but in most cases we just need a quick reminder of
> what that one option was called that we're failing to recall, so I would
> much prefer the original purpose of the `--help` option:  Print a short
> summary to the terminal.
>
> If this appears superficial to you, please remember that many little bad
> things can do a lot of damage in the long run.  The purpose of this post
> is to wake everybody up before it's too late.
>
> I hope that some people agree with me, and if yes, I will turn these
> into actual feature requests on Github.  I'm also happy to help with
> implementing the latter one, because writing a good `--help` system for
> commands with subcommands is not necessarily easy.
>
>
> Greets,
> Ertugrul
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Announcing support for GHCJS

[Charles Strahan]

Hello all,

I'm happy to announce that support for the GHCJS compiler
 (and packages) has been merged
into master in 616bf50
.
This introduces a new top-level package set: haskellPackages_ghcjs.

And now for credit where credit is due: Ryan Trinkle and John Wiegly did
the initial heavy lifting, Bas van Dijk did an awesome job keeping the
branch up to date with Nixpkgs and ghcjs master, and Peter Simons was very
responsive and thorough with his feedback. Thanks guys!

Cheers!

-Charles
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Haskell NG

[Charles Strahan]

Wow, very exciting! Hopefully we can get GHCJS ready as a first-class
citizen by then.

Cheers!
-Charles

On Tue, Dec 30, 2014 at 4:58 AM, Peter Simons  wrote:

> Hi Charles,
>
>  > How much work remains before we can flip the switch?
>
> the 'haskell-ng' branch in [1] is pretty stable by now. According to [2],
> we
> can build approximately 50% of Hackage. There's more work to be done in
> cabal2nix, improving the generated package list to get that percentage up
> some more, but IMHO the major challenges have been solved. Anyone who wants
> to look at the code, can check out [3].
>
> Also, everyone is welcome to try out the new Haskell environment: get the
> 'haskell-ng' branch, add the attribute
>
>   provideOldHaskellAttributeNames = true;
>
> to your ~/.nixpkgs/config.nix file, and then your normal configuration
> should work just like it did before -- unless, if your configuration was
> based on the ghc-wrapper. Then you'll have to convert to ghcWithPackages,
> because the wrapper is gone.
>
> It will be 2-3 more weeks until I'll open a PR, asking for review before
> merging to 'master'.
>
> Best regards,
> Peter
>
>
> [1] https://github.com/peti/nixpkgs
> [2] http://hydra.nixos.org/jobset/nixpkgs/haskell-updates
> [3]
> https://github.com/peti/nixpkgs/blob/haskell-ng/pkgs/development/haskell-modules
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] extension error?

[Charles Strahan]

Oops, minor correction (s/nixpkgs/nixos):

sudo nix-channel --remove nixos
sudo nix-channel --add https://nixos.org/channels/nixos-unstable nixos
# ...or...
sudo nix-channel --add https://nixos.org/channels/nixos-14.12 nixos

-Charles

On Mon, Dec 29, 2014 at 1:22 AM, Charles Strahan <
charles.c.stra...@gmail.com> wrote:

> Hi Tim,
>
> It looks like you're using the latest from the stabe 14.04 release, which
> doesn't support the `extension` argument:
>
>
> https://github.com/NixOS/nixpkgs/blob/release-14.04/pkgs/top-level/haskell-defaults.nix#L230-237
>
> Compare that to master:
>
>
> https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/haskell-defaults.nix#L148-155
>
> You can see your current channel running:
>
> sudo nix-channel --list
>
> I would suggest updating your nixos channel to nixos-14.12 or
> nixos-unstable:
>
> sudo nix-channel --remove nixos
> sudo nix-channel --add https://nixos.org/channels/nixpkgs-unstable
> nixos
> # ...or...
> sudo nix-channel --add https://nixos.org/channels/nixpkgs-14.12 nixos
>
> (The above commands are assuming that you're using NixOS, as opposed to
> using Nix standalone.)
>
> Let me know if that helps!
>
> -Charles
>
> On Mon, Dec 29, 2014 at 12:48 AM, Tim Sears  wrote:
>
>> Was trying this example at
>> http://wiki.ocharles.org.uk/Nix#how-do-i-use-cabal2nix-for-local-projects
>> and I when I enter nix-shell I an error
>>
>> $ nix-shell
>> error: anonymous function at
>> /nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/pkgs/top-level/haskell-defaults.nix:230:5
>> called with unexpected argument `extension', at
>> /nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/lib/customisation.nix:58
>>
>> Anybody seen this error or have any insight to share?
>>
>> Thanks,
>> Tim
>>
>>
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] extension error?

[Charles Strahan]

Hi Tim,

It looks like you're using the latest from the stabe 14.04 release, which
doesn't support the `extension` argument:

https://github.com/NixOS/nixpkgs/blob/release-14.04/pkgs/top-level/haskell-defaults.nix#L230-237

Compare that to master:

https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/haskell-defaults.nix#L148-155

You can see your current channel running:

sudo nix-channel --list

I would suggest updating your nixos channel to nixos-14.12 or
nixos-unstable:

sudo nix-channel --remove nixos
sudo nix-channel --add https://nixos.org/channels/nixpkgs-unstable nixos
# ...or...
sudo nix-channel --add https://nixos.org/channels/nixpkgs-14.12 nixos

(The above commands are assuming that you're using NixOS, as opposed to
using Nix standalone.)

Let me know if that helps!

-Charles

On Mon, Dec 29, 2014 at 12:48 AM, Tim Sears  wrote:

> Was trying this example at
> http://wiki.ocharles.org.uk/Nix#how-do-i-use-cabal2nix-for-local-projects
> and I when I enter nix-shell I an error
>
> $ nix-shell
> error: anonymous function at
> /nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/pkgs/top-level/haskell-defaults.nix:230:5
> called with unexpected argument `extension', at
> /nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/lib/customisation.nix:58
>
> Anybody seen this error or have any insight to share?
>
> Thanks,
> Tim
>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Haskell NG

[Charles Strahan]

Peter,

Awesome work on Haskell-NG. How much work remains before we can flip the
switch?

-Charles

On Sun, Dec 28, 2014 at 3:53 PM, Charles Strahan <
charles.c.stra...@gmail.com> wrote:

>
> > I'm trying to think of a way of selling my oop library [...]
>
> What OOP library are you talking about? Is it available for me to view
> online?
>
> -Charles
>
> On Thu, Dec 18, 2014 at 12:38 PM,  wrote:
>
>> On Thu, 18 Dec 2014, Peter Simons wrote:
>>
>> > Hi Russel,
>> >
>> > >> 2) Haskell packages support 'deepOverride'.
>> > >
>> > > How would you feel about using my overrideScope functionality from my
>> > > haskellPackagesFixpoint branch instead?
>> >
>> > the first version of my re-factored Haskell code defined deep overrides
>> exactly
>> > the way you did it. Check out the "definePackage" function in [1].
>> You'll find
>> > that I studied your work thoroughly.
>> >
>> > My impressions are:
>> >
>> > 1. overrideScope and deepOverride achieve the same goal. I discovered
>> no case
>> >where one function worked but the other one didn't.
>> >
>> > 2. deepOverride is a standard function every callPackage derivation
>> supports.
>> >overrideScope, on the other hand, is not.
>> >
>> > 3. deepOverride is implemented in a simple generic algorithm (for
>> appropriate
>> >definitions of the term "simple") that requires no special support
>> from the
>> >haskellPackages record to function. overrideScope, on the other
>> hand, needs
>> >the magic nixClass attribute (__unfix__ in my code) to build a stack
>> of
>> >extension functions.
>> >
>> > Ultimately, I felt that I should stick to the standard deepOverride
>> mechanism
>> > mostly due to Occam's razor'ish reasoning: I'd rather not introduce a
>> new
>> > sophisticated tying-the-knot mechanism to haskellPackages just to do
>> the same
>> > thing that deepOverride can do already.
>> >
>> > Does that make sense?
>>
>> That is fair reasoning.
>>
>> I will add that I expect overrideScope to run exponentially faster than
>> deepOverride in worst case.  A similar change to replace-dependency took
>> the evaluation time for replacing bash in a NixOS system from 65 minutes
>> to instantaneous <https://githum.com/NixOS/nixpkgs/pull/4313>.  Replacing
>> bash in a NixOS system is probably *the* worst case scenario because bash
>> so deep in the dependency graph.  Until deepOverride starts taking
>> appreciable time, the efficencies of overrideScope is probably not yet a
>> pursuasive argument.
>>
>> So please keep an eye out for long evaluation times when using
>> deepOverride as you continue your work. :)  Haskell applications have
>> deeper and more fine grained dependencies than regular applications so
>> you might be more likely to run into evaluation time problems than others.
>>
>> What I really need to do is convince Eelco Dolstra and Michael Raskin that
>> semantics of overriding packages and semantics of object oriented
>> programmed coincide and they should adopt my oop library for implementing
>> the overriding mechanism.
>>
>> I'm trying to think of a way of selling my oop library to them that is a
>> little more light weight that flying to europe to give them a presenation.
>> Maybe I should use the Ocaml package set as a testbed to demonstrate
>> overrideScope.
>>
>> --
>> Russell O'Connor  <http://r6.ca/>
>> ``All talk about `theft,''' the general counsel of the American
>> Graphophone
>> Company wrote, ``is the merest claptrap, for there exists no property in
>> ideas musical, literary or artistic, except as defined by statute.''
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Haskell NG

[Charles Strahan]

> I'm trying to think of a way of selling my oop library [...]

What OOP library are you talking about? Is it available for me to view
online?

-Charles

On Thu, Dec 18, 2014 at 12:38 PM,  wrote:

> On Thu, 18 Dec 2014, Peter Simons wrote:
>
> > Hi Russel,
> >
> > >> 2) Haskell packages support 'deepOverride'.
> > >
> > > How would you feel about using my overrideScope functionality from my
> > > haskellPackagesFixpoint branch instead?
> >
> > the first version of my re-factored Haskell code defined deep overrides
> exactly
> > the way you did it. Check out the "definePackage" function in [1].
> You'll find
> > that I studied your work thoroughly.
> >
> > My impressions are:
> >
> > 1. overrideScope and deepOverride achieve the same goal. I discovered no
> case
> >where one function worked but the other one didn't.
> >
> > 2. deepOverride is a standard function every callPackage derivation
> supports.
> >overrideScope, on the other hand, is not.
> >
> > 3. deepOverride is implemented in a simple generic algorithm (for
> appropriate
> >definitions of the term "simple") that requires no special support
> from the
> >haskellPackages record to function. overrideScope, on the other hand,
> needs
> >the magic nixClass attribute (__unfix__ in my code) to build a stack
> of
> >extension functions.
> >
> > Ultimately, I felt that I should stick to the standard deepOverride
> mechanism
> > mostly due to Occam's razor'ish reasoning: I'd rather not introduce a new
> > sophisticated tying-the-knot mechanism to haskellPackages just to do the
> same
> > thing that deepOverride can do already.
> >
> > Does that make sense?
>
> That is fair reasoning.
>
> I will add that I expect overrideScope to run exponentially faster than
> deepOverride in worst case.  A similar change to replace-dependency took
> the evaluation time for replacing bash in a NixOS system from 65 minutes
> to instantaneous .  Replacing
> bash in a NixOS system is probably *the* worst case scenario because bash
> so deep in the dependency graph.  Until deepOverride starts taking
> appreciable time, the efficencies of overrideScope is probably not yet a
> pursuasive argument.
>
> So please keep an eye out for long evaluation times when using
> deepOverride as you continue your work. :)  Haskell applications have
> deeper and more fine grained dependencies than regular applications so
> you might be more likely to run into evaluation time problems than others.
>
> What I really need to do is convince Eelco Dolstra and Michael Raskin that
> semantics of overriding packages and semantics of object oriented
> programmed coincide and they should adopt my oop library for implementing
> the overriding mechanism.
>
> I'm trying to think of a way of selling my oop library to them that is a
> little more light weight that flying to europe to give them a presenation.
> Maybe I should use the Ocaml package set as a testbed to demonstrate
> overrideScope.
>
> --
> Russell O'Connor  
> ``All talk about `theft,''' the general counsel of the American Graphophone
> Company wrote, ``is the merest claptrap, for there exists no property in
> ideas musical, literary or artistic, except as defined by statute.''
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] FOSDEM planning Hangout

[Charles Strahan]

Is anyone planning on giving a talk? If so, who?

On Wed, Dec 17, 2014 at 1:47 PM, Wout Mertens 
wrote:

> Hi all,
>
> We got a table at FOSDEM so we'll need volunteers to man the table and we
> need to think about what we'll show/do. Swag sales would be nice too.
>
> If you'd like to help with the planning, please fill out the doodle :
> http://doodle.com/br47eeidzgrangqm
>
> 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

[Nix-dev] GHCJS support in nixpkgs

[Charles Strahan]

Hey Haskellers,

Ryan Trinkle and John Wiegley have done some awesome work on getting GHCJS
working in nixpkgs. There's still some work to do (like making the build
pure and maybe some cleanup), but I think it's pretty close.

Ryan and I are going to be hacking on it this weekend, trying to get it to
a mergeable state. Please chime in if you'd like to help us out!

-Charles
___
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

[Charles Strahan]

This sounds like a great initiative. I would be glad to help (feel free to
hand me some tasks).

> The second solution would be a large added maintenance and Hydra burden
> as the number of packages would increase dramatically. In turn we would
> have binaries for a lot of versions which while nice, is probably a
> waste of resources: users very often want latest version.

How many build servers do we currently have? What are their specs?
Would more/better machines be useful/feasible? I'd be willing to donate
about $200/month,
if it'll help. I would imagine there are companies that would be willing to
chip in too
(if that's not the case, we need to fix that).

-Charles


On Fri, Aug 8, 2014 at 12:08 PM, Paul Colomiets  wrote:

> On Fri, Aug 8, 2014 at 6:50 PM, Luca Bruno  wrote:
> > Not necessarily. Think like platforms.gnu. There may be a
> > meta.pythonVersions and a default pythonVersions.default2 and
> > pythonVersions.default3 and pythonVersions.all or such. Then adding a new
> > major version to all packages is a metter of adding it to the default
> list.
>
> Yes this approach seems better. Also many packages support >= 3.2 or
> >=3.3, so it's not just py2 or py3 choice.
>
>
>
> --
> Paul
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] 32bit on 64bit Nix

[Charles Strahan]

Tim,

I wish I had more information (I've only used NixOS in server scenarios),
but I would suggest first looking at pkgsi686Linux
,
which is the entire nix packages with `system' overridden as "i686-linux".
There's also callPackage_i686, incase you want to declare your own package
that is strictly 32bit. I'm always idling on #nixos, so feel free to ask
some questions there too, and I'll see if I can offer any advice.

-Charles



On Sat, Jul 26, 2014 at 8:45 PM, Tim Hawes  wrote:

> Greetings,
>
> I am new to NixOS, and finally tried it out, going through a bare-metal
> installation to a USB drive (I wanted to make sure I could get
> everything working on my laptop, for the possibility of switching out
> Ubuntu for NixOS). The documentation was clear and concise,
> however, it is not at all clear how to install support for running 32
> bit application on the 64bit OS. I did stumble on a logged conversation
> on the IRC channel, where installing stdenv_32bit was mentioned. But it
> was not entirely clear what that does.
>
> I am trying to run the dynamic binary for Skype. I will also be
> installing Wine, and a licensed copy of Codeweavers CrossOver Office. I
> know Skype depends on 32bit versions of Qt, and several other libraries,
> but right now, it would be progress to just get a 32bit version of libc
> installed.
>
> Any help in this regards will be greatly appreciated!
>
> Thanks!
>
> Tim Hawes
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Better support for Ruby

[Charles Strahan]

Hi all,

There was some recent talk about difficulty with Nix+Ruby
, and from
the looks of it, it's been a couple years since the Ruby infrastructure in
Nixpkgs was last touched (the `nix' rubygems plugin itself was last
released in 2011).

I will be using/supporting Ruby in my soon-to-be job (after about 7 months
of fantastic funemployment time :D), so it's very important to me that Nix
has good ruby/gem/bundler support. As I will be pushing for the production
use of NixOS, I'll have quite some skin in the game.

Given both my own interests in the success of Ruby on Nix and my experience
with Ruby and its packaging, I would like to coordinate development efforts
in this area. I would love to hear about particular use cases and any
problems with the current setup, and what features you don't care for (that
way we aren't limited by legacy design choices). I will soon begin work on
an alternative to the old `nix' gem, and I'll see if I can get Bundler
working well too.

Feel free to further develop this thread, or if you want to quickly hash
things out, you can find me on #nixos as cstrahan. I get alerts on my phone
when my name is mentioned, so I should be fairly responsive.

-Charles
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] haskell-env-ghc-7.8.3 fails to build

[Charles Strahan]

Hi Tom,

It looks like the problem is that GHC includes its own `terminfo' package,
and now that GHC uses shared libraries, it includes a `
libHSterminfo-0.4.0.0-ghc7.8.3.so' that collides with `terminfo' from
cabal. Peter Simons has a description of the problem as it relates to
`xhtml'
, and
the gist of it was that you could use `ghcWithPackagesOld' to step around
the problem for now. If I've read GHC ticket #
8919
 correctly, it looks like
commit 4caadb7cb

(which landed on master about 7 weeks ago) should resolve the problem. I'm
not sure if that's something that we might want to cherry-pick, or if we'll
just need to wait for GHC 7.8.4.

Cheers,
-Charles


On Fri, Jul 25, 2014 at 7:23 AM, Tom Dimiduk  wrote:

> I was looking forward to playing with ghc-7.8 when unstable pushed out the
> new version this week, but things won't quite build. Any advice on how to
> debug this?
>
> nixos-rebuild --upgrade
> test
> ⏎
> downloading Nix expressions from `
> http://releases.nixos.org/nixos/unstable/nixos-14.10pre46074.4e06537/nixexprs.tar.xz'.
> ..
>   % Total% Received % Xferd  Average Speed   TimeTime Time
> Current
>  Dload  Upload   Total   SpentLeft
> Speed
> 100 3738k  100 3738k0 0   286k  0  0:00:13  0:00:13 --:--:--
> 553k
> unpacking channels...
> created 2 symlinks in user environment
> building Nix...
> building the system configuration...
> these derivations will be built:
>   /nix/store/14zdm2xf0zxwcpgkipkfyljpak7qw3cd-haskell-env-ghc-7.8.3.drv
>   /nix/store/2bqxkycdz6cyn06mfzdr383yj4pzri6m-unit.drv
>   /nix/store/61qv9b7pv7fvccc7iifqsm791dx1frfz-system-crontab.drv
>   /nix/store/7zrsqigl5l4qssq31hv88s098njkljjy-dbus-conf.drv
>   /nix/store/jqr4zl9skbvnsq6sr58b4xq5jkp5azmb-etc.drv
>
> /nix/store/n1z9rzpd3dkc2d0xm08rla3gm5qwyym4-nixos-14.10pre45979.0d23cf8.drv
>   /nix/store/snl5xyrgbbddgvpi59hv1733cscx74p8-system-path.drv
>   /nix/store/vdngyxaiashq5c531dr9g3znkg6vqw1c-system-units.drv
> building path(s)
> `/nix/store/k1k6hdjd071il8z6mpl7n00rkrjix5b4-haskell-env-ghc-7.8.3'
> building /nix/store/k1k6hdjd071il8z6mpl7n00rkrjix5b4-haskell-env-ghc-7.8.3
> collision between
> `/nix/store/hb92nfw5iapmrgy7c12h04vhp6yqb85b-ghc-7.8.3/lib/ghc-7.8.3/terminfo-0.4.0.0/
> libHSterminfo-0.4.0.0-ghc7.8.3.so' and
> `/nix/store/8jq44m6r7nakl2hqfp11pbz93wr2p0gh-haskell-terminfo-ghc7.8.3-0.4.0.0-shared/lib/ghc-7.8.3/terminfo-0.4.0.0/
> libHSterminfo-0.4.0.0-ghc7.8.3.so' at /nix/store/
> 9z6d76pz8rr7gci2n3igh5dqi7ac5xqj-builder.pl line 72.
> note: keeping build directory `/tmp/nix-build-haskell-env-ghc-7.8.3.drv-7'
> builder for
> `/nix/store/14zdm2xf0zxwcpgkipkfyljpak7qw3cd-haskell-env-ghc-7.8.3.drv'
> failed with exit code 2
> cannot build derivation
> `/nix/store/snl5xyrgbbddgvpi59hv1733cscx74p8-system-path.drv': 1
> dependencies couldn't be built
> cannot build derivation
> `/nix/store/61qv9b7pv7fvccc7iifqsm791dx1frfz-system-crontab.drv': 1
> dependencies couldn't be built
> cannot build derivation
> `/nix/store/7zrsqigl5l4qssq31hv88s098njkljjy-dbus-conf.drv': 1 dependencies
> couldn't be built
> cannot build derivation
> `/nix/store/2bqxkycdz6cyn06mfzdr383yj4pzri6m-unit.drv': 1 dependencies
> couldn't be built
> cannot build derivation
> `/nix/store/vdngyxaiashq5c531dr9g3znkg6vqw1c-system-units.drv': 1
> dependencies couldn't be built
> cannot build derivation
> `/nix/store/jqr4zl9skbvnsq6sr58b4xq5jkp5azmb-etc.drv': 3 dependencies
> couldn't be built
> cannot build derivation
> `/nix/store/n1z9rzpd3dkc2d0xm08rla3gm5qwyym4-nixos-14.10pre45979.0d23cf8.drv':
> 2 dependencies couldn't be built
> error: build of
> `/nix/store/n1z9rzpd3dkc2d0xm08rla3gm5qwyym4-nixos-14.10pre45979.0d23cf8.drv'
> failed
>
> Thanks,
> Tom
>
> ___
> 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