[Nix-commits] [NixOS/nixpkgs] 98bd72: systemd-boot: allow setting editor security option...

2017-01-21 Thread Linus Heckemann 
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 98bd722d1dae747c5786497b8689415d2bebf78f
  
https://github.com/NixOS/nixpkgs/commit/98bd722d1dae747c5786497b8689415d2bebf78f
  Author: Linus Heckemann <g...@sphalerite.org>
  Date:   2017-01-21 (Sat, 21 Jan 2017)

  Changed paths:
M nixos/modules/system/boot/loader/systemd-boot/systemd-boot-builder.py
M nixos/modules/system/boot/loader/systemd-boot/systemd-boot.nix

  Log Message:
  ---
  systemd-boot: allow setting editor security option (#21853)


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

Re: [Nix-dev] Explicitly selecting sources for "src" in stdenv.mkDerivation?

2017-02-16 Thread Linus Heckemann 
On 16/02/17 12:28, Freddy Rietdijk wrote:
>> src = [ ./subproject-A/schema.sql ./subproject-A/lib ];
> 
> Each of the files you mentioned here will be stored in a separate store
> path. You could write a simple function that takes a list of derivations
> and copies the contents of those derivations in a new output.

Or use symlinkJoin, which does that but without the copying.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-commits] [NixOS/nixpkgs] b4cd25: Manual: document users.users..hashedPassword

2017-02-13 Thread Linus Heckemann 
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: b4cd251c54e8a07cfcb8cb46c53083f2f6c7a573
  
https://github.com/NixOS/nixpkgs/commit/b4cd251c54e8a07cfcb8cb46c53083f2f6c7a573
  Author: Linus Heckemann <g...@sphalerite.org>
  Date:   2017-02-13 (Mon, 13 Feb 2017)

  Changed paths:
M nixos/doc/manual/configuration/user-mgmt.xml

  Log Message:
  ---
  Manual: document users.users..hashedPassword


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

[Nix-commits] [NixOS/nixpkgs] 9aca55: endless sky: init at 0.9.4

2016-12-11 Thread Linus Heckemann 
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 9aca55e79d62468ef230350026b41947d0472309
  
https://github.com/NixOS/nixpkgs/commit/9aca55e79d62468ef230350026b41947d0472309
  Author: Linus Heckemann <g...@sphalerite.org>
  Date:   2016-12-11 (Sun, 11 Dec 2016)

  Changed paths:
M lib/maintainers.nix
A pkgs/games/endless-sky/default.nix
A pkgs/games/endless-sky/fixes.patch
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  endless sky: init at 0.9.4


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

[Nix-commits] [NixOS/nixpkgs] d568cb: google-apputils: enable for py3k (#21079)

2016-12-11 Thread Linus Heckemann 
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: d568cb971be3c1a9f732e2d254baf74dff84fa2a
  
https://github.com/NixOS/nixpkgs/commit/d568cb971be3c1a9f732e2d254baf74dff84fa2a
  Author: Linus Heckemann <g...@sphalerite.org>
  Date:   2016-12-11 (Sun, 11 Dec 2016)

  Changed paths:
M pkgs/top-level/python-packages.nix

  Log Message:
  ---
  google-apputils: enable for py3k (#21079)

No apparent reason for it being disabled per #21061. I guess we'll find
out if there was a reason.


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

[Nix-commits] [NixOS/nixpkgs] da70d3: SDL2: split derivation

2016-12-25 Thread Linus Heckemann 
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: da70d3da0f11b22eac77756b39b349215e06b2e3
  
https://github.com/NixOS/nixpkgs/commit/da70d3da0f11b22eac77756b39b349215e06b2e3
  Author: Linus Heckemann <g...@sphalerite.org>
  Date:   2016-12-26 (Mon, 26 Dec 2016)

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

  Log Message:
  ---
  SDL2: split derivation


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

Re: [Nix-dev] Temporarily not using ~/.nixpkgs/config.nix

2017-03-26 Thread Linus Heckemann 
On 26/03/17 16:30, Eike wrote:
> Is there a way to temporarily disable evaluating ~/.nixpkgs/config.nix?
> I looked at http://nixos.org/nixpkgs/manual/#chap-packageconfig, but
> couldn't find anything related.

See pkgs/top-level/impure.nix (found by grepping nixpkgs for
.nixpkgs/config.nix):

> config ? let
> configFile = getEnv "NIXPKGS_CONFIG";
> configFile2 = homeDir + "/.config/nixpkgs/config.nix";
> configFile3 = homeDir + "/.nixpkgs/config.nix"; # obsolete
>   in
> if configFile != "" && pathExists configFile then import configFile
> else if homeDir != "" && pathExists configFile2 then import configFile2
> else if homeDir != "" && pathExists configFile3 then import configFile3
> else {}

If you set the environment variable NIXPKGS_CONFIG to point to a file
containing simply {} that should hopefully help.

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

Re: [Nix-dev] How do you work on big packages?

2017-03-17 Thread Linus Heckemann 
On 17/03/17 16:00, Volth wrote:
> What could be done here?
nix-shell, and the upstream recommended build procedure.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] how to find packages by file?

2017-03-15 Thread Linus Heckemann 
On 14/03/17 20:24, Roni Choudhury wrote:
> So my second question is, *how do I know whether a package
> has .lib or .dev attributes?*

I know of two options for this:

 1. Look at the expressions in a nixpkgs checkout; a good starting point
is usually all-packages.nix to find the actual expression and its
outputs attribute.

 2. Use nix-repl — `nix-repl ''` will give you a REPL for the
nix language with autocompletion for that sort of thing, which can be
very helpful.

> A followup question: *if I didn't have libpangocairo.* already in my
> store, how would I know which package delivers it?*

Hopefully by grepping a nixpkgs checkout. Sometimes the library names
don't exactly correspond to expression names, and sometimes they're not
in the expressions at all; I'm not really sure what can be done about
that, unless there's an index of the files each derivation contains
floating about somewhere — I know there's at least a subset of that, for
implementing the command-not-found functionality that tells you what to
install to make commands available. I tried this with your example of
pangocairo and found this line, from some Haskell bindings...

  "gi-pangocairo" = callPackage
({ mkDerivation, base, bytestring, Cabal, containers, gi-cairo
 , gi-glib, gi-gobject, gi-pango, gobjectIntrospection, haskell-gi
 , haskell-gi-base, pango, system-cairo, system-pango, text
 , transformers
 }:

so at that point I'd try looking in the pango and cairo-related
packages... Not really ideal, but I don't know if there is a better way.

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

Re: [Nix-dev] Overriding python with python3 in vim_configurable.customize

2017-04-04 Thread Linus Heckemann 
On 04/04/17 17:40, zimbatm wrote:
> Look into pkgs/top-level/all-packages.nix. I would start by copying the
> definition of vim_configurable from there and set the python argument.
> 
> 
> On Tue, 4 Apr 2017, 14:08 Ben Zhang,  > wrote:
> 
> From the source code, it doesn’t seem to accept a python argument
> 
> (https://github.com/nicknovitski/nixpkgs/blob/master/pkgs/misc/vim-plugins/vim-utils.nix#L291-L295).
> Is there another way to override `python` with `python3`
> (https://github.com/NixOS/nixpkgs/pull/8125#issuecomment-169471686)?
> 


Another potential option would be using package overrides [1] to pass
python3 as python to the vim package — something like

   packageOverrides = pkgs: {
  vim = pkgs.vim.override { python = pkgs.python3 };
   };

[1]: https://nixos.org/nixpkgs/manual/#sec-modify-via-packageOverrides


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

Re: [Nix-dev] Presenting nix-index: a file-not-found utility

2017-04-22 Thread Linus Heckemann 
On 22/04/17 07:45, Linus Heckemann wrote:
> On 22/04/17 07:03, Danylo Hlynskyi wrote:
>> Great!
>> A question: what does it mean when expression is in round parents?
>>
>> (wineUnstable.out)2,141 r
>> /nix/store/cl7b6kw7y8cqkpy4pnwwq4iqmaiw52d0-xextproto-7.3.0/include/X11/extensions/secur.h
>>
> 
> https://github.com/bennofs/nix-index/blob/master/src/bin/nix-locate.rs#L110-L112
> 
> That it's not a top-level package.
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
> 


No, sorry, that's wrong — I misinterpreted the source code. The long
usage description explains it though:

* we can't know the precise attribute path for every package, so if you
see the syntax `(attr)`
  in the output, that means that `attr` is not the target package but
that it
  depends (perhaps indirectly) on the package that contains the searched
file. Example:

  $ nix-locate 'bin/xmonad'
  (xmonad-with-packages.out)  0 s
/nix/store/nl581g5kv3m2xnmmfgb678n91d7ll4vv-ghc-8.0.2-with-packages/bin/xmonad

  This means that we don't know what nixpkgs attribute produces
/nix/store/nl581g5kv3m2xnmmfgb678n91d7ll4vv-ghc-8.0.2-with-packages,
  but we know that `xmonad-with-packages.out` requires it.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

[Nix-commits] [NixOS/nixpkgs] be65d2: nixpkgs manual: Remove obsolete warning (#21117)

2017-04-23 Thread Linus Heckemann 
  Branch: refs/heads/release-17.03
  Home:   https://github.com/NixOS/nixpkgs
  Commit: be65d233c1b83501e0c82fdbd67d0ecf3ebefb99
  
https://github.com/NixOS/nixpkgs/commit/be65d233c1b83501e0c82fdbd67d0ecf3ebefb99
  Author: Linus Heckemann <g...@sphalerite.org>
  Date:   2017-04-23 (Sun, 23 Apr 2017)

  Changed paths:
M doc/multiple-output.xml

  Log Message:
  ---
  nixpkgs manual: Remove obsolete warning (#21117)

PR #815 has already been cherry-picked into the default nix version 1.11.8.
(cherry picked from commit 5c7f4669a7880bc2f929271ae4fdbdc2ba8e2a8b)


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

[Nix-commits] [NixOS/nixpkgs] 5c7f46: nixpkgs manual: Remove obsolete warning (#21117)

2017-04-23 Thread Linus Heckemann 
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 5c7f4669a7880bc2f929271ae4fdbdc2ba8e2a8b
  
https://github.com/NixOS/nixpkgs/commit/5c7f4669a7880bc2f929271ae4fdbdc2ba8e2a8b
  Author: Linus Heckemann <g...@sphalerite.org>
  Date:   2017-04-23 (Sun, 23 Apr 2017)

  Changed paths:
M doc/multiple-output.xml

  Log Message:
  ---
  nixpkgs manual: Remove obsolete warning (#21117)

PR #815 has already been cherry-picked into the default nix version 1.11.8.


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

Re: [Nix-dev] Presenting nix-index: a file-not-found utility

2017-04-22 Thread Linus Heckemann 
On 22/04/17 07:03, Danylo Hlynskyi wrote:
> Great!
> A question: what does it mean when expression is in round parents?
> 
> (wineUnstable.out)2,141 r
> /nix/store/cl7b6kw7y8cqkpy4pnwwq4iqmaiw52d0-xextproto-7.3.0/include/X11/extensions/secur.h
> 

https://github.com/bennofs/nix-index/blob/master/src/bin/nix-locate.rs#L110-L112

That it's not a top-level package.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] tigervnc service?

2017-04-23 Thread Linus Heckemann 
On 23/04/17 06:07, Tim Sears wrote:
> Thanks Volth. That preStart bit got me a bit further. I am running the
> awesome window manager and getting the error:
> 
> awesome: main:619: cannot open display (error 1)
> 
> That leads to the server and ssh tunnel shutting down before anything
> appears on the remote client side.
> 
> Using lightdm and awesome for my physical workstation. Not sure I am
> starting X properly as far as vncserver is concerned.
> 
> My xstartup file looks like this...
> 
> #!/nix/store/hi4j75r312lsjhpdln9p8blyixs59hbs-bash-4.4-p12/bin/bash
> echo xstartup-start | systemd-cat -t "vncserver"
> while [ true ]; do
> /nix/store/dglxfr7ivy7hrx2scrli9acsrx0nxicj-awesome-4.1/bin/awesome :1 ;
> sleep 1; done

awesome doesn't take the display as an argument, by the looks of it. Try
using

DISPLAY=:1 ${awesome}/bin/awesome

instead of awesome :1.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] NixOS 17.03 Beta, 16.09 Security Support Timeline

2017-03-09 Thread Linus Heckemann 
On 09/03/17 10:26, Oliver Charles wrote:
> sudo: /run/current-system/sw/bin/sudo must be owned by uid 0 and have
> the setuid bit set

Are you just adding sudo to systemPackages rather than using the option
security.sudo.enable?

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

Re: [Nix-dev] 'nixos-stable' channel?

2017-03-06 Thread Linus Heckemann 
On 06/03/17 15:03, Domen Kožar wrote:
> It's something like 15min of work to parse http://nixos.org/channels/
> and point to the latest channel if someone needs this.
> 
> Officially this is a very bad idea, since people will want us to 
> support it.

Isn't the point to just have it refer to the version of NixOS that *is*
being supported? I don't see how parsing http://nixos.org/channels will
convey that information — 17.03 has existed for longer than it's been
supported, no? I.e. stable rather than latest.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] nixos-rebuild switch error

2017-03-07 Thread Linus Heckemann 
Hi Tilo,

On 07/03/17 07:30, Tilo Schwarz wrote:
> *** Downloading
> ‘https://cache.nixos.org/nar/1krfkq7lilh69g6ha7gxpck184x7nqwhxh1c51zmsc2p13fqrii4.nar.xz’
> (signed by ‘cache.nixos.org-1’) to
> ‘/nix/store/psxqsm2rx0is5yp6sh9bkh4pvsvhpw1b-appres-1.0.4’...
> curl: (6) Couldn't resolve host 'cache.nixos.org '
> /nix/store/lymkrlb84c8v3pmi9xlw8d3dh3g20q1c-xz-5.2.2-bin/bin/xz:
> (stdin): File format not recognized
> error: unexpected end-of-file
> download of
> ‘https://cache.nixos.org/nar/1krfkq7lilh69g6ha7gxpck184x7nqwhxh1c51zmsc2p13fqrii4.nar.xz’
> failed: No such file or directory
> could not download
> ‘/nix/store/psxqsm2rx0is5yp6sh9bkh4pvsvhpw1b-appres-1.0.4’ from any
> binary cache
these are the key lines; particularly
> curl: (6) Couldn't resolve host 'cache.nixos.org '
This failure is caused by a flaky internet connection, so it makes sense
that trying again would fix it. Nothing to be concerned about, besides
perhaps the poor UX, making it very unclear what the actual cause of the
failure is :)

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

Re: [Nix-dev] virutalbox ova - screen settings reset on every restart

2017-07-02 Thread Linus Heckemann 
On 02/07/17 11:42, Stephan Sahm wrote:
> Dear NixOS followers,
> 
> I tried to use the nixOS virtualbox
> from 
> https://d3g5gsiof5omrk.cloudfront.net/nixos/17.03/nixos-17.03.1449.2e983f14f6/nixos-17.03.1449.2e983f14f6-x86_64-linux.ova
> 
> 
> It starts correctly, however, if I try to adapt the display scaling or
> resolution to adapt for my 4k screen, the setting is lost on a restart.
> (As KDE tells me to restart for the settings to become active, I never
> actually see a rescaled KDE, but everything is very tiny).
> 
> So the question how to make these display settings be preserved upon
> restart.
> (I successfully isntalled git and okular and cloned some repositories
> and stuff - everything is preserved as it should, only the display
> settings seem to get lost sofar)
> 
> Any help is highly appreciated!,
> best,
> Stephan

Setting X up to inform Plasma of the right resolution might help ­— try
adding

services.xserver.monitorSection = ''
  DisplaySize width height
'';

to your config, where width and height are the real-world dimensions of
the screen (assuming you're running the VM full-screen) in millimetres.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Are mailing lists any good for managing patches? (was: okteta fix build)

2017-06-27 Thread Linus Heckemann 
On 27/06/17 19:01, Alexandre Peyroux wrote:
> Certainly but on big projects that have many developers and a lot of PR,
> it loses its charm.

I respectfully disagree. Linux has received contributions from 642 (I
think that qualifies as "many") developers in 2017 alone using this
model. Sure, it's not shiny and Web 2.0 like GitHub, but it works. And
from a maintainer's point of view (this is versus merging in patches
which have been pushed to another host than github):

 - I can view the patches without importing them or working out how to
navigate git web interface xyz (if there is a web interface).

 - I can import the patches directly into my repo. No trying to find the
clone URL on a web interface (if the contributor hasn't sent me the
clone URL itself).

 - I can comment on specific parts of the patches inline without having
to copy and paste fragments into an email, without signing up for an
account on the git host (if that's even possible) and commenting there
(again, if that's even possible).

Of course, these are all possible on github. But it's a proprietary and
centralised service. With the email process, I can do all of this
offline and using only free software.

Overall, this process has the advantage of minimising network
communication and variation in the process for performing the various
tasks that might be necessary.

Hoping but not expecting to have convinced you ;)

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

[Nix-commits] [NixOS/nixpkgs] 96b83f: weechat: fix guile plugin

2017-04-27 Thread Linus Heckemann 
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 96b83f66a2182261ecd68d9c978b60b634cba45f
  
https://github.com/NixOS/nixpkgs/commit/96b83f66a2182261ecd68d9c978b60b634cba45f
  Author: Linus Heckemann <g...@sphalerite.org>
  Date:   2017-04-27 (Thu, 27 Apr 2017)

  Changed paths:
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  weechat: fix guile plugin

Fixes #25270


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

Re: [Nix-dev] Failure to boot after hibernate

2017-04-24 Thread Linus Heckemann 
On 24/04/17 11:33, Bas van Dijk wrote:
> On 24 April 2017 at 12:20, Danylo Hlynskyi  wrote:
>> Probably too late, but can you boot with hibernate=no kernel parameter?
> 
> Hi Danylo, thanks. Unfortunately I can't edit the kernel parameters.
> My system is using the default EFI loader and isn't using grub which
> does allow editing the kernel command line.
If it's systemd-boot, which it probably is, it does in fact allow
editing unless you disable it in its config — I think you just press E
to edit the command line.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

[Nix-commits] [NixOS/nixpkgs] 995d41: nvidia stable: 375.39 -> 375.66

2017-05-11 Thread Linus Heckemann 
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 995d41c09197803624a419114b5c5cd2c90e46bc
  
https://github.com/NixOS/nixpkgs/commit/995d41c09197803624a419114b5c5cd2c90e46bc
  Author: Linus Heckemann <g...@sphalerite.org>
  Date:   2017-05-11 (Thu, 11 May 2017)

  Changed paths:
M pkgs/os-specific/linux/nvidia-x11/default.nix
M pkgs/os-specific/linux/nvidia-x11/generic.nix

  Log Message:
  ---
  nvidia stable: 375.39 -> 375.66


  Commit: 89ce83688cda03df01307bc74bfa3950a4d5266e
  
https://github.com/NixOS/nixpkgs/commit/89ce83688cda03df01307bc74bfa3950a4d5266e
  Author: Linus Heckemann <g...@sphalerite.org>
  Date:   2017-05-11 (Thu, 11 May 2017)

  Changed paths:
M pkgs/os-specific/linux/nvidia-x11/generic.nix

  Log Message:
  ---
  nvidia-x11: fix linux 4.10 patch URL


Compare: https://github.com/NixOS/nixpkgs/compare/ed5cb7311814...89ce83688cda___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-commits

Re: [Nix-dev] why has each revision / generation not a own configuration.nix

2017-05-16 Thread Linus Heckemann 
On 16/05/17 17:43, zimbatm wrote:
> How do you find back which git revision was used to produce a given
> NixOS profile?
> 
> Maybe nixos-rebuild should be extended to include that in the revision
> name, and if the git repo is dirty.

I'm planning to implement the reverse approach on my system: have some
sort of rebuild hook commit the state of the repo to a separate branch
and include useful information (nixpkgs version, derivation hash of the
resulting system) in the commit message. This allows greater
reproducibility and provides far more helpful information (a snapshot of
the full config) than simply "repo was dirty".

I'll reply if/when I get this working.

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

[Nix-commits] [NixOS/nixpkgs] 11272e: camlistore: use buildGoPackage

2017-05-09 Thread Linus Heckemann 
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 11272e930f751e726e46ca1c9c84a82f2fc33b78
  
https://github.com/NixOS/nixpkgs/commit/11272e930f751e726e46ca1c9c84a82f2fc33b78
  Author: Linus Heckemann <g...@sphalerite.org>
  Date:   2017-05-09 (Tue, 09 May 2017)

  Changed paths:
M pkgs/applications/misc/camlistore/default.nix

  Log Message:
  ---
  camlistore: use buildGoPackage

this removes go references from the package

fixes #25346


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

Re: [Nix-dev] 5 somewhat related questions

2017-06-23 Thread Linus Heckemann 
Hi Klaas,

>> That intuition holds modulo your Q3 - replaying a sequence of
>> nix-env commands would only reproduce the same generations if a)
>> the states of all channels involved were retained (i.e. you'd need
>> to know which nixpkgs-stable you installed from with each command)
>> and b) all the builds were reproduce-able or cached. Nix assumes
>> reproduce-able builds, and so retains the outcomes of building
>> derivations based on a digest of the derivation itself - but if you
>> replayed the same nix-env commands from scratch, you might get
>> (trivially) different outcomes.
>
> Out of those 2 remarks "a" is the big one, especially if the channel 
> you've subscribed to is in fact not the stable one. As far as I
> understand now, there is no solution for this (yet). Good to know
> though.

You can, instead of using nixpkgs/config.nix, write an expression for
your user environment somewhat like this (say software.nix):

let pkgs = import  {}; in
{
  inherit (pkgs) vim ripgrep ;
}

You can install this using:

nix-env -f software.nix -i

If you add the -r flag, the result will not depend on the previous
generation of your user environment. The benefit of this approach is
that you can replace pkgs in order to pin specific versions, for instance…

let
  # System nixpkgs used only to fetch pinned nixpkgs
  bootPkgs = import  {};
  pkgs = import (bootPkgs.fetchFromGitHub {
owner = "nixos";
repo = "nixpkgs";
rev = "d10fe641247e29b72139776cd316333b13ba";
sha256 = "06viplacb5w49yf3rirsn4jdcfssj98f3s1zic0l8raxng7pmdcq";
  }) {};
in {
  inherit (pkgs) vim ripgrep;
};

Which is a bit harder to maintain but should be much less stateful,
depending only on fetchFromGitHub from your current nixpkgs not breaking
compatibility and on github staying up — and importantly, it would allow
reproducing previous generations more easily. You could of course also
factor the fetching out into a separate file which you could import and
have a script to automatically update. I wouldn't be surprised if
someone had already done that somewhere.

In a similar vein of functionality, you could version your user
environment in a git repo with nixpkgs as a submodule and update it
explicitly. This would provide a similar experience and further reduce
the variability.



> The rollbacks will be as-built, so implicitly they capture the state 
> implied by the channels and configuration.nix. However, there's no 
> explicit capture of those - there was discussion relatively recently 
> about capturing configuration.nix into the generation, but it turns 
> out to be a little harder than you'd expect. Likewise, you'd have to 
> somehow capture the state of all the involved channels.
> 
> 
> Do you have a pointer to this discussion? I cannot find it using the 
> keywords you mentioned above.

This was the discussion David Izquierdo linked in his reply:
https://mailman.science.uu.nl/pipermail/nix-dev/2017-April/023403.html

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

Re: [Nix-dev] How to downgrade or patch freetype-2.7 ?

2017-06-24 Thread Linus Heckemann 
On 24/06/17 01:52, Volth wrote:
> There are still at least one place where
> "environment.sessionVariables.LD_LIBRARY_PATH = ..." does not replace
> freetype with a custom-built version: in cgi-scripts run under
> lighttpd service:
> 
> RRD rendered with stock freetype-2.7.1 http://i.imgur.com/HVZ5iPa.png
> RRD rendered with freetype-2.7.1 compiled without subpixel rendering
> (#define TT_CONFIG_OPTION_SUBPIXEL_HINTING 0):
> http://i.imgur.com/Qj4W0Lx.png

That is pretty terrible! Depending on what lighttpd does with the
environment of the scripts, one or more of the following might help (in
order of how nice I think they are as solutions):

0. Link against a working freetype in the first place
1. Set LD_LIBRARY_PATH in environment.variables instead of
environment.sessionVariables so that it affects not only interactive
sessions
2. Set systemd.services.lighttpd.environment.LD_LIBRARY_PATH
3. Use mod_setenv to set LD_LIBRARY_PATH for the CGI scripts.
4. (as an unfortunate last resort) wrap the CGI scripts.


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

Re: [Nix-dev] okteta fix build

2017-06-27 Thread Linus Heckemann 
On 27/06/17 17:01, Joachim Schiele wrote:
> aszlig pointed out that we have a pointer in the manual to send patches
> to the ML if the user in question does not like github which is a valid
> workflow for me.
> 
> BUT we are stagnating in PRs are the moment (390 open PRs) and having a
> patch per email is overkill. maybe a PR from a different git source
> instead? i would rather like a git based workflow than having to align
> the single files into a commit.

FWIW this *is* a git-based workflow, git comes with the ability to
format patches for emails and import such patches (and was designed with
this in mind for use in the development of linux) — see man
git-format-patch and git-am. I personally think it's fine receiving
patches like this — if volume increases maybe there should be another
list specifically for patches, but at current levels IMHO it's no problem.

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

Re: [Nix-dev] concatAttrs :: [attrSet] -> attrSet ?

2017-05-28 Thread Linus Heckemann 
On 28/05/17 13:18, Sergiu Ivanov wrote:
> Hello,
> 
> I found myself in the need of a function which would take a list of
> Nix attribute sets and concatenate them to produce one big attribute
> set:
> 
> nix-repl> concatAttrs [ {x=1;} {y=2;} ]
> {x=1; y=2;}
> 
> I did quite some research online and in nixpkgs source tree and found
> a lot of cool functions, but nothing resembling to concatAttrs.
> 
> Does such a function exist?
> 
> 
> In the meantime, I ended up writing the following definition:
> 
> concatAttrs = attrList: pkgs.lib.fold (x: y: x // y) {} attrList;
> 
> Do you see any isssues with such an implementation?
> 

Looks like a sensible way to do it to me, though I'd be surprised if it
doesn't already exist in nixpkgs.

Do keep in mind that // is not commutative — the order matters when the
two sets contain the same key — but other than that I don't see any
issues. You might also want to look at the merging logic used for nixos
modules (lib/modules.nix), although that's significantly more complex.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Disappearing X session on some systems

2017-05-28 Thread Linus Heckemann 
On 28/05/17 07:17, Kirill Elagin wrote:
> Is there anything noteworthy in the X log? dmesg?
> Surely it doesn’t just disappear without saying anything at all, right?

This stuff should be in the journal, but it isn't in the case of lightdm
[26172].

The X server may also crash without any further information as to why.
This could be [21026] or [25476] at play. Enabling coredumps [1] and
waiting for it to happen again could also help elucidate the issue.

[1]: https://nixos.org/nixos/options.html#coredump
[21026]: https://github.com/NixOS/nixpkgs/issues/21026
[25476]: https://github.com/NixOS/nixpkgs/issues/25476
[26172]: https://github.com/NixOS/nixpkgs/issues/26172
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Polkit action files installed via nix-env don't appear to be recognised by Polkit/Pkexec/Pkaction

2017-05-31 Thread Linus Heckemann 
On 31/05/17 07:47, Roger Qiu wrote:
> Yea that seems right, allowing users to nix-env install things,
> everything must be unprivileged, allowing the usage of such polkit files
> in nix-env means the users can make use of pkexec to elevate to root
> when executing anything.
> 
> However in non-package manager use cases, installing such a package with
> `make install` would require super user privileges to install the action
> policy file into /usr/share/polkit-1/actions. Therefore nix-env could
> make use of such a fact, and instead suggest the user to install using
> `sudo nix-env` if the package has a polkit policy file. This would
> prevent such a security hole, since the user must be root to be able to
> install such a package. Such suggestions could be encoded in the nix
> expression file.
> 
> Which brings up the next question, would installing via `sudo nix-env`
> setup the polkit policy files properly such that polkit will know about it?

No. nix-env modifies the default, not the system profile (when running
as root) because modifying the system profile requires activating it.

What you'd want in this case is usually to add the package in question
to environment.systemPackages and use nixos-rebuild switch to switch to
the new generation. This results in the policy files ending up in
/run/current-system/sw/share/polkit-1/actions, providing the
security.polkit.enable option is set to true. That way the configuration
is declarative which is more consistent with "The NixOS way".

To allow nix-env as root to install polkit actions, you could probably
add /nix/var/nix/profiles/default to polkit's search path. This is a bad
idea compared to using the systemwide declarative configuration for
several reasons though:

 - The changes won't be picked up automatically, you would have to
restart polkit.service yourself. When using the system configuration,
this is done by the activation script.

 - The packages won't be updated together with the rest of the system.
This could be a security issue depending on whether you remember to run
nix-env -u as root as frequently as nixos-rebuild.

 - The configuration isn't declarative and there's no single source of
truth for where rules come from! This is the norm on most other
distributions of course, but who really wants a less transparent system?

So overall I recommend adding any packages whose polkit actions you want
available to systemPackages rather than using nix-env to manage them.

Best regards,
Linus
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Polkit action files installed via nix-env don't appear to be recognised by Polkit/Pkexec/Pkaction

2017-05-31 Thread Linus Heckemann 
On 31/05/17 08:42, Roger Qiu wrote:
> Good response! This would be a great info in a wiki somewhere.

Thank you! Maybe I'll add it to the nixos-users wiki.


>> To allow nix-env as root to install polkit actions, you could probably
> add /nix/var/nix/profiles/default to polkit's search path.
> 
> Disregarding it being a bad idea, how is this possible? Are you
> suggesting overriding the derivation during package build of polkit?

I'm suggesting not adding it to the search path and using systemPackages
instead ;)

As for how to add it to the search path, I really don't know. In the
best case, you can do this in a configuration file somewhere; in the
worst case this would require a patch to polkit.

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

Re: [Nix-dev] Evaluation time vs build time

2017-05-31 Thread Linus Heckemann 
On 31/05/17 18:01, Judson Lester wrote:
> All,
> 
> Please take this with a grain of salt. I'm trying to clarify my
> understanding of Nix, and I've started to develop a kind of precept that
> I don't know that I've seen documented anywhere. It may well be a
> sophomore misunderstanding, and if such I don't want it to be taken up
> as gospel. I think the most succinct way to put it would be:
> 
> nix expressions cannot 'makedepend'
> 
> In other words, values in a nix expression can't be computed from the
> sources used to build an application.
> 
> This is because (and here I'm sketchier) nix-build (upon which `nix-env
> --install` /et al/ are based) evaluates the expressions, and calls to
> 'derivation' that are executed, as a side effect, "queue up" builds.
> Once a derivation is actually produced (iow, when the evaluation
> completes), the queue of derivation builds are run. Since the
> expression's evaluation is complete before the derivation builds happen,
> the sources aren't available at evaluation time.
> 
> One of the consequences of this are the family of *2nix tools that
> exist: per-language library dependency manifests (like a Gemfile or
> package.json) wouldn't be available if the corresponding builder
> function just said "gitfetch this repo and build from it", so setting
> those packages up requires the extra step of getting the appropriate
> manifest files, running a simple tool on them, and pointing the
> expression to the tool's results.
> 
> Another, more profound consequence, is that the set of expressions is in
> some sense "complete" - they fully describe where to get and how to
> build packages, where a solution that admitted "makedepend" would blur
> that line and allow code to determine at packaging time what to include
> in the store.
> 
> My question is, basically, is that true? Do I understand this correctly?
> Even if I do, I'm sure there's details an nuances that could be expanded on.

As far as I understand it, it's mostly true — I believe it *is* actually
possible, just strongly discouraged and absolutely not accepted in
nixpkgs because (iiuc) of the mess of dependencies it can create.

However, I don't fully understand all the ins and outs of this and may
be wrong.

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

[Nix-commits] [NixOS/nixpkgs] 3c3a25: jing-trang: use jre_headless

2017-06-07 Thread Linus Heckemann 
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 3c3a25acc5ccc7685b8f31db97cd8dbcd6c62cfe
  
https://github.com/NixOS/nixpkgs/commit/3c3a25acc5ccc7685b8f31db97cd8dbcd6c62cfe
  Author: Linus Heckemann <g...@sphalerite.org>
  Date:   2017-06-07 (Wed, 07 Jun 2017)

  Changed paths:
M pkgs/tools/text/xml/jing-trang/default.nix

  Log Message:
  ---
  jing-trang: use jre_headless

This halves its closure size.


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

[Nix-commits] [NixOS/nixpkgs] 4fc077: vdrift: fix build (#26522)

2017-06-13 Thread Linus Heckemann 
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 4fc077bfeee8e09980a75f19823400e46cbd5063
  
https://github.com/NixOS/nixpkgs/commit/4fc077bfeee8e09980a75f19823400e46cbd5063
  Author: Linus Heckemann <g...@sphalerite.org>
  Date:   2017-06-13 (Tue, 13 Jun 2017)

  Changed paths:
M pkgs/games/vdrift/default.nix

  Log Message:
  ---
  vdrift: fix build (#26522)

Had been broken since 7bf7f1976545666ba958034f7e61062595338f84


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

Re: [Nix-dev] weird garbage output inside nix-shell

2017-06-09 Thread Linus Heckemann 
On 07/06/17 14:24, Roni Choudhury wrote:
> On Wed, Jun 7, 2017 at 12:14 AM Samuel Leathers  > wrote:
> 
> I use nix-shell --run zsh. I alias that to nshell.
> 
> Thanks, Sam, this is a great idea! On this note, do you know of a good
> way to update the prompt to reflect the nix-shell environment I'm in?
> i.e., is there a way to *name* the nix-shell env, and get access to that
> name through an environment variable?

Since everything that's passed to stdenv.mkDerivation ends up as an
environment variable, you can use the "name" environment variable. In my
case, my prompt function contains:

if [[ $IN_NIX_SHELL ]]; then
  printf "(%s)" "${name:-nix-shell}"
fi


> I wanted to add that even if I don't drop into zsh as my first act in
> the nix-shell, I still get that weird output from executables not in the
> environment (such as `zsh` and `git`). If anyone has any insight or can
> answer my other question, that would be great.

This is guesswork, but it could be locale-related. Do you use UTF-8
locales everywhere, or do you use other encodings that might mess up if
interpreted as UTF-8? Does setting LC_ALL=en_US.UTF-8 within the shell help?


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