Re: [Nix-dev] unequal build hash

[Guillaume Maudoux (Layus) via nix-dev]

On 07/07/17 10:28, Harmen via nix-dev wrote:

On Fri, Jul 07, 2017 at 07:59:46AM +0200, Vladimír Čunát wrote:

On 07/06/2017 07:35 PM, Harmen via nix-dev wrote:

Does that makes sense? Did I forget a 'name' somewhere?

When you use things like
   src = ./.;
the directory gets copied into nix store and the resulting path's name
is based on the name of the directory.

I see. That was rather unobvious and unexpected to me.

Anyone knows a (creative) way around that? I would like to have it build code
from ./., but where the name of the directory you happened to have checked the
project out in doesn't matter (because then the binary cache works).
Well, you could try to play with symlinks. A self-symlinks seems to be 
enough.


git checkout ... somewhere
cd somewhere
ln -s . knownName

then

src = builtins.filterSource (path: type: path != "./knownName") ./knownName; # 
syntax my not be correct here, check by yourself :-).


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

Re: [Nix-dev] If anyone is using VIM and BYOBU (or Screen or Tmux) in 256 colors - would you please send me your configuration file?

[Guillaume Maudoux (Layus)]

I do use screen+vim, but there is zero config in my configuration.nix 
related to that.


To support my terminal (rxvt-unicode-256color) I had to `ln -s 
./.nix-profile/share/terminfo .terminfo`, and install rxvt_unicode to 
the distant machine.


I also have `set t_Co=256` in my vim config. Maybe it helps when not 
autodetected by vim (wild guess here)? There may be more info in 
http://vim.wikia.com/wiki/256_colors_in_vim.


Just my two cents,

-- Layus.



On 15/05/17 15:28, Yasuaki Kudo wrote:

Yes, already tried but no luck...  Is there any good nix config file that I can 
copy from someone  that enables 256 colors,  VIM and terminal duplexer?See 
I use Windows and only use NixOS through SSH, a terminal duplexer is a must 



-Original Message-
From: Eric Sagnes [mailto:eric.sag...@gmail.com]
Sent: Monday, May 15, 2017 21:51
To: Yasuaki Kudo 
Cc: nix-dev@lists.science.uu.nl
Subject: Re: [Nix-dev] If anyone is using VIM and BYOBU (or Screen or Tmux) in 
256 colors - would you please send me your configuration file?

For tmux, having the following in your ~/.tmux.conf should be enough:

```
set -g default-terminal "screen-256color"
```

Or running tmux with the `-2` flag should force tmux to use 256 colors:

```
$ tmux -2
```

On Mon, May 15, 2017 at 09:28:21PM +0900, Yasuaki Kudo wrote:

I just can't get VIM to work in 256 colors in any terminal duplexer, I don't
know what to do.   At least, when I use Byobu from NIXOS, I can run some
256-color confirmation script and see that it's enabled.   However, if I
launch VIM, it doesn't work in 256 colors.   Exiting Byobu, VIM does work in
256 colors.

  


My version is as follows:

17.03.1013.bc11395603 (Gorilla)

  


Cheers

Yasu


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

Re: [Nix-dev] Extend wrapper created with makeWrapper

[Guillaume Maudoux (Layus)]

wrapProgram is a thin wrapper around makeWrapper, both defined in 
make-wrapper.sh

All they do is exactly the same as the custom wrapper make below.

You can nlook for uses of makeWrapper / wrapProgram across nixpkgs.
kdeWrapper, wrapQtProgram & co are refinements of this concept. They 
call wrapProgram with extra, custom settings for resp. KDE, Qt, GNOME & 
co. To avoid stacking wrappers, they sometimes provide an extension 
mechanism. kdeWrapper does not.


For now, I would keep the custom hack. It is the simplest solution.

https://github.com/abbradar/nixpkgs/blob/124e5dd3eb9e3e8fe322d3c62e4501b2043ac898/pkgs/build-support/setup-hooks/make-wrapper.sh

-- Layus.

On 07/05/17 22:40, José Luis Lafuente wrote:

The wrapper derivation approach works nicely, thanks!

I'm trying to understand how to achieve the same with stackable 
wrappers, but not sure how. The examples in 
https://github.com/NixOS/nixpkgs/pull/24858 
<https://github.com/NixOS/nixpkgs/pull/24858> are using wrapQtProgam 
and wrapPythonPrograms. In both cases there is a way to extend the 
created wrapper, you can set `makeWrapperArgs` for wrapPythonPrograms, 
or you can pass extra arguments to wrapQtProgram. But okular uses 
kdeWrapper, which doesn't seem to offer a way to extend the created 
wrapper. Is it really not possible to extend the wrapper created with 
kdeWrapper, or am I missing something?


On Fri, May 5, 2017 at 4:12 PM, Guillaume Maudoux (Layus) 
<layus...@gmail.com <mailto:layus...@gmail.com>> wrote:


Stackable wrappers are implemented in
https://github.com/NixOS/nixpkgs/pull/24858
<https://github.com/NixOS/nixpkgs/pull/24858>, but you will need
to wait for that package to land in master, and then get included
in some channel :-).

You can also create a trivial wrapper derivation:

|# file ~/.nixpkgs/config.nix { pkgs, ...}: { packageOverrides =
super: rec { customOkular = pkgs.writeScriptBin "okular" ''
#!/usr/bin/env bash export MYVAR=something exec
${pkgs.okular}/bin/okular "$@" ''; ... |

and then nix-env -iA nixos.customOkular :-).

— Layus.

On 05/05/17 15:02, José Luis Lafuente wrote:


Hi,

I want to override an existing package to use it locally. I would
like to just set an environment variable before the program is
executed, but the derivation is using `wrapProgram`, so there is
already a wrapper for the program. Is possible to override the
derivation to add another environment variable to the wrapper?
The derivation I want to modify is okular

(https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/kde/okular.nix

<https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/kde/okular.nix>)


Thanks in advance,
José Luis


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

​




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

Re: [Nix-dev] Extend wrapper created with makeWrapper

[Guillaume Maudoux (Layus)]

Stackable wrappers are implemented in 
https://github.com/NixOS/nixpkgs/pull/24858, but you will need to wait 
for that package to land in master, and then get included in some 
channel :-).


You can also create a trivial wrapper derivation:

|# file ~/.nixpkgs/config.nix { pkgs, ...}: { packageOverrides = super: 
rec { customOkular = pkgs.writeScriptBin "okular" '' #!/usr/bin/env bash 
export MYVAR=something exec ${pkgs.okular}/bin/okular "$@" ''; ... |


and then nix-env -iA nixos.customOkular :-).

— Layus.

On 05/05/17 15:02, José Luis Lafuente wrote:


Hi,

I want to override an existing package to use it locally. I would like 
to just set an environment variable before the program is executed, 
but the derivation is using `wrapProgram`, so there is already a 
wrapper for the program. Is possible to override the derivation to add 
another environment variable to the wrapper? The derivation I want to 
modify is okular 
(https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/kde/okular.nix) 



Thanks in advance,
José Luis


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


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

Re: [Nix-dev] The .nixpkgs/config.nix file and user configuration

[Guillaume Maudoux (Layus)]

Hi John,

I guess the reason you are not receiving many answers is that your 
question highlights some misconceptions, and some design issues with nix.


There does not exist any declarative configuration file for user 
environments. /etc/nixos/configuration.nix is amazing, but has not been 
parted to user environments. Installing user packages is done with 
nix-env, in an imperative fashion, and updates are based on packages 
names (nix-env -u) as explained on the [wiki]. Please see the discussion 
on [GitHub](1) about that precise topic.


To get declarative user environments, you can look at the pull-request 
for [NixUP] (nix user profiles), or use a trick to manage packages 
declaratively in a custom environment. The [wiki] has such an example. I 
personally maintain a [~/.nixpkgs/packages.nix] that I edit, install and 
activate with the following one-liner. The command replaces all the 
installed packages with the given ones (-ir). I could alias it to 
nixuser-rebuild ;-).


vim ~/.nixpkgs/packages.nix && nix-env -f ~/.nixpkgs/packages.nix 
-ir -Qk && i3-msg restart


NixUP and/or the coming update to nix (1.12) /should/ make this 
management easier.


I hope this makes it clearer!

Regards,

-- Layus.


[NixUP]: https://github.com/NixOS/nixpkgs/pull/9250
[1]: https://github.com/NixOS/nixpkgs/issues/1750
[wiki]: 
https://nixos.org/wiki/Howto_keep_multiple_packages_up_to_date_at_once
[~/nixpkgs/packages.nix]: 
https://gist.github.com/layus/427356ab4e7f46565d984686a311ca91#file-packages-nix


On 03/05/17 08:29, John Ramsden wrote:
I've been looking for some information about how exactly the 
$HOME/.nixpkgs/config.nix file works. How exactly is it intended to be 
used? Up until now I've been managing my entire system from 
/etc/nixos, but it would be nice to have a place where I can add 
something that happens only to a single user. For example, setting up 
dotfiles, or use our services. Can the config.nix file be used for 
that? Is it effectively a /etc/nixos/configuration.nix that is 
intended to be used for a single user?


I have found little bits of information about it here and there, for 
example in the nix pills. but nothing that really explains what it is 
used for in detail. Could someone point me where I can find this 
information?




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

Re: [Nix-dev] What are the rules about 'share/' directory symlinking to profile?

[Guillaume Maudoux (Layus)]

Hi,

`nix-env -i $(nix-build -A fzf.out)` works.
Somehow, `nix-env -f . -iA fzf.out` still installs `fzf.bin`.

Now, that package is quite strange. Normally, the first output in the 
outputs list should be the one that refers to all the others.
It is not the case here, because fzf.bin does not reference fzf.out for 
example.

Also, it could specify outputsToInstall, but it does not.

See http://nixos.org/nixpkgs/manual/#idm140737318250400 and related 
issues to dig deeper into this.
But please keep in mind that nix received only maintenance update since 
Jan 19, 2016.

A lot of merged features are not available in any release.

-- Layus.

On 20/04/17 13:33, Alexey Lebedeff wrote:

I've tried with fzf.out and it also doesn't add anything to 'share' in
profile folder. The only way I was able to make it work is by adding
'share' folder to 'bin' output. Looks like some magic is attached to
'bin' itself (because I've also tried reordering outputs without any
change) - but I can't figure out how and why this is happening.

1) For fzf.out 'vim-plugins' folder is not added to profile after installation

$ nix-build . -A fzf.out
/nix/store/mp5drsp2l1z7k0rp4jjmll06kjck7052-fzf-0.16.6

# 'share' is present in nix store
$ ls ./result/share/vim-plugins/ -l
total 4
lrwxrwxrwx 1 root root 91 Jan  1  1970 fzf-0.16.6 -> 
/nix/store/mp5drsp2l1z7k0rp4jjmll06kjck7052-fzf-0.16.6/share/go/src/github.com/junegunn/fzf

$ nix-env -f . -iA fzf.out

# But it's missing from profile even after explicitly installing that
$ ls -la ~/.nix-profile/share/vim-plugins
ls: cannot access '/home/binarin/.nix-profile/share/vim-plugins': No such 
file or directory

2) But everything works if I add 'share' folder to 'bin' output instead, using 
the following
lines in postInstall:

+mkdir -p $bin/share/vim-plugins
+cp -a $out/share/go/src/github.com/junegunn/fzf $bin/share/fzf-tmp
+ln -s $bin/share/fzf-tmp $bin/share/vim-plugins/${name}

$ nix-build . -A fzf.bin
/nix/store/3dzqj1xk6s5jfm1z4kwnkfdg9yw3xckr-fzf-0.16.6-bin

$ ls ./result-bin/share/vim-plugins/ -l
total 4
lrwxrwxrwx 1 root root 72 Jan  1  1970 fzf-0.16.6 -> 
/nix/store/3dzqj1xk6s5jfm1z4kwnkfdg9yw3xckr-fzf-0.16.6-bin/share/fzf-tmp

$ nix-env -f . -iA fzf.bin

$ ls -la ~/.nix-profile/share/vim-plugins
lrwxrwxrwx 1 root root 76 Jan  1  1970 
/home/binarin/.nix-profile/share/vim-plugins -> 
/nix/store/3dzqj1xk6s5jfm1z4kwnkfdg9yw3xckr-fzf-0.16.6-bin/share/vim-plugins

Best,
Alexey


Guillaume Maudoux (Layus) writes:


I guess the idea is that you need to install `fzf.out` explicitly,
because installing `fzf` installs the first output, which is `fzf.bin`.

-- Layus.


On 20/04/17 11:46, Alexey Lebedeff wrote:

Hi folks.

What are the rules about how and when 'share/' folder of (multi-output)
derivation will be merged into 'share/' folder of profile?

E.g. I can't see content of
https://github.com/NixOS/nixpkgs/blob/4a0be7837cadf9b6e9cae430d80f65a2af60dcc6/pkgs/tools/misc/fzf/default.nix#L33
anywhere in my profile 'share/' even after installing every output

Only when I move 'share/' to '$bin' output, it starts appearing in profile
'share/' folder.

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


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

Re: [Nix-dev] [Help] Accidentally removed configuration.nix

[Guillaume Maudoux (Layus)]

Hi,

system.copySystemConfiguration is far from perfect. As soon as you 
modularize your config, you will miss all the other files.


If you want a correct system.copySystemConfiguration, you really need 
https://github.com/NixOS/nix/pull/709.
It allows you to snapshot all the sources of a nix derivation, not just 
one file.


I tested it back then, and it worked pretty well.

-- Layus.


On 06/04/17 17:46, ni...@vince.lol wrote:

No I don't have `system.copySystemConfiguration=true` set :-(
Luckily I documented my recent efforts in some gists.
I managed to install NixOS on ZFS here: 
https://gist.github.com/awesomefireduck/c763e168a62a0ef559a1fb9473261459
And my (yet untested) attempt at PCI passthrough here: 
https://gist.github.com/awesomefireduck/1be07805081a4d7a51c527e452b87b26

There is still some missing, but nothing I can't handle, I guess.
This is a great time to enable my ZFS snapshots... :-/

Does anyone know why `system.copySystemConfiguration` is set to false 
by default? It seems like it would be better to default this to true, 
right?
Or at least have this listed in the generated config? 
(`nixos-generate-config`)


Anyway, I'll be okay, thanks folks!!

Sincerely,
Vince
On Thursday, April 6, 2017 4:58 PM, Sergiu Ivanov 
 wrote:


Hi Vince,

Thus quoth  ni...@vince.lol  at 14:12 on Thu, Apr 06 2017:


I acidentally removed my /etc/nixos/configuration.nix is there any way
I can get it back?


Citing directly from:

 http://stackoverflow.com/questions/28603773/recover-accidentally-deleted-configuration-nix-file 



 '''
 system.copySystemConfiguration

 If enabled, copies the NixOS configuration file $NIXOS_CONFIG (usually
 /etc/nixos/configuration.nix) to the system store path.

 Type:"boolean"

 Default:false

 Declared by:  
 '''

Do you happen to have this option set to true?

/me goes and sets it to true on his system

--
Sergiu



___
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] Banning people from the mailinglist?

[Guillaume Maudoux (Layus)]

+1

I read once an article showing that to avoid proliferation of annoying 
messages, the best action was to ignore them.
Banning people just makes them want to fight harder against the 
perceived injustice.


When new (non-constructive) "fuck systemd" messages come to this mailing 
list, I will do as for all the previous ones, ignore & archive.

Et voilà.

-- Layus.


PS : Kudos to ayone able to find a link to the aforementioned article.
I cannot lay my hand on it.

On 04/04/17 18:45, zimbatm wrote:


I'm proud of how mature the nix community is, it takes some effort to 
not respond to hate with more hate. Share the love :D



On Tue, 4 Apr 2017, 17:05 Alexey Shmalko, > wrote:


I recommend reading You Are What You Write[1] and Difficult People[2]
chapters of Producing Open Source Software[3] by Karl Fogel. They
describe how to handle similar situations; banning people is extreme
measures, and most situations can be resolved without that.

[1]: http://producingoss.com/en/you-are-what-you-write.html
[2]: http://producingoss.com/en/difficult-people.html
[3]: http://producingoss.com/
___
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 mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] paths in user's i3 configs broken by upgrade

[Guillaume Maudoux (Layus)]

On 05/04/17 03:46, Profpatsch wrote:

On 17-04-03 04:25pm, Mark Gardner wrote:

Instead of:

 bindsym $mod+d exec
/nix/store/04sx6lx7hssid7a6iwdbdvxbkp25xsx1-dmenu-4.6/bin/dmenu_run

I think it should be to be:

 bindsym $mod+d exec /run/current-system/sw/bin/dmenu_run

The problem with /run/current-system is
that it’s nixOS only.
The package should work on e.g. Darwin as well.

So probably use `/usr/bin/env dmenu_run` and similar.



User dotfiles are not managed by nix. ~/.i3/config is outside of the nix 
store, and the paths it contains are not gc roots.
We should simply revert https://github.com/NixOS/nixpkgs/pull/12873, it 
is not the right way to handle this.


It was introduced after a discussion in 
https://github.com/NixOS/nixpkgs/pull/12463, to avoid propagating dmenu2 
and i3bar when they are not needed. There is certainly an issue with 
environment.systemPackages containing too many packages, but this should 
not be solved by dirty hacks like this one.


I propose to add dmenu and i3status to 
$out/nix-support/propagated-user-env-packages, with an option to the i3 
package to disable it.
If you do not want these two convenient packages, just "i3.override { 
exportTools = false; }" somewhere. Who cares about dmenu and i3status 
being added on a gui system anyway. They are very small.


We should move this discussion to a github issue anyway.

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

Re: [Nix-dev] garbage-collection of the last 'n' generations

[Guillaume Maudoux (Layus)]

Your system generations are under /nix/var/nix/profiles.

You can `rm -i $(cd /nix/var/nix/profiles; ls *-link -1dtr | head -n -<# 
of versions to to keep> | grep -v $(readlink system) | xargs realpath 
-s)` :-)


and then do a normal gc.

-- Layus.

On 30/03/17 15:42, Azul wrote:


Hi there,

I would like to cleanup my oldest  'n' nix generations.

nix-collect-garbage seems to only provide me with a older than 'n' 
days option.


Any quick hacks to clean everything but keep my recent  'n' generations ?




___
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] With-expressions question

[Guillaume Maudoux (Layus)]

Yep, there has been previous ML discussions about this.

Short story is that local variables always take precedence over 
variables from "with" expressions.


This is kind of a security feature, otherwise the following expression 
could change its meaning when an "outer" package is added/removed from 
the "pkgs" set.


`let outer = "5"; in with pkgs; [ outer ];`


That being said, a warning would be a nice idea.

-- Layus.


On 22/03/17 16:12, José Luis Lafuente wrote:
Recently I was having a weird error running nixos-rebuild. I added 
some packages to systemPackages and I was getting this error:


cannot coerce a set to a string, at 
/etc/nixos/nixpkgs/lib/strings.nix:442:44


After some debugging I found that the guilty was the boot package, but 
I needed some time to understand why. In my configuration.nix I have this:


environment.systemPackages = with pkgs; [
  .
  boot
];

But 'boot' refers to the option 'boot', not the package 'boot'. For 
me, that behavior is confusing (at least in the programming languages 
I know the inner scope variables shadow the ones on the outer scope).
In my example, is there a way to make 'boot' refer to 'pkgs.boot'? or 
a way of getting a warning on this case?


Regards,
Jose Luis


___
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] setuidwrapper questions

[Guillaume Maudoux (Layus)]

Hi Jon,

Unless I am terribly mistaken, setuid wrappers are only needed for 
executables in the nix store because the nix store fordids to set the 
suid bit.


For your executable, just set the suid bit and... Voilà :-).

-- Layus.


On 16/03/17 17:41, Jon Parris wrote:

Hi All,

NixOS noob here. I have two questions relating to setuid.

First how do I create a wrapper for program (named buildenv) which is
outside of nixpkgs? Here are the constraits for buildenv.
* This is a internal tool - so I can't add it to the public nixpkgs.
* This tool is written in C, it calls clone and chroot.

Second buildenv is called with the wrong userid.

The buildenv tool stores the uid from getuid, chroots, then restores the userid.

What I see - buildenv is called with uid lroot.
$ whoami
parrisj
$ buildenv 3.3.1
$ whoami
lroot

Expected Behavior
$ buildenv 3.3.1
$ whoami
parrisj

How I kludged setuidwrapper to discover this.
1) Add a entry for buildenv in security.setuidPrograms in
/etc/nixos/configuration.nix
2) nixos-rebuild switch
3) Overwrite /var/setuidwrappers/buildenv.real with the corrrect path.

Thanks, Jon
___
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] How to ensure that a directory exists via configuration.nix

[Guillaume Maudoux (Layus)]

Hi Mark,

This is usually handled by systemd units. When a service requires a 
directory, we add ExecBefore scripts to setup the directory. There are 
plenty such examples in nixos modules.
If you need it for you as a user, you could make a service required by 
multiuser.target.


On the other hand, there are plenty of places where you can insert such 
commands on the initialization path.
For example, you could insert that command in the activate script 
executed on every boot and every `nixos-rebuild switch`

See the option `system.activationScripts` for details.

I would go for the second option if you need /mnt.

-- layus.

On 10/02/17 01:59, Mark Gardner wrote:
I have searched the manual and options, as well as the Internet, and 
have not found how to specify in configuration.nix that a directory 
should exist, in this case /mnt, creating it if not. One might put "if 
[ ! -d /mnt ] ; then mkdir /mnt; fi" in rc.local. What is the NixOS 
way to do this (or anything else that one might put in rc.local)?


Mark
--
Mark Gardner
--


___
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] Is it possible to limit nix access to sudoers and/or a group?

[Guillaume Maudoux (Layus)]

On 20/01/17 12:46, Profpatsch wrote:

On 17-01-20 10:59am, Danylo Hlynskyi wrote:

Nix design doesn't support quotas on filled store per-user, and let's not
forget #8.

https://github.com/NixOS/nixpkgs/pull/8 ?

That looks unrelated.


Rather https://github.com/NixOS/nix/issues/8 I would say.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] nix.buildCores and determinism

[Guillaume Maudoux (Layus)]

And because the hash does not represent the content, but the intended
content, it is very important for the build to be reproducible.
This means that the build must be deterministic, and stripped from
information such as the host name, time of build and such.

Sadly, many parallel builds are not deterministic, and parallelism must
be disabled to achieve reproducible builds.
If the builds are not reproducible, then there is no way you can confirm
that the binary substitute is correct, and you must blindly trust the
binary cache and the hydra builds.

For more details, see https://reproducible-builds.org/.

Regards,
Guillaume, aka Layus.


Le 13/10/16 à 16:35, Peter Simons a écrit :
> Hi Zimbatm,
>
>  > I think there is a misunderstanding, the hash of the package
>  > derivation depends on the build output.
>
> the $out hash for a given package is computed over the build command
> that generates that store path. Build inputs required for the process
> play into that hash because the build script is going to mention their
> store paths somewhere (i.e. when setting up $PATH, etc.), but the
> *contents* of any of those store paths don't affect the hash.
>
> Unless, of course, when we're talking about fixed output derivations
> like 'fetchurl', but these are somewhat special and suitable mostly for
> downloading source code, not so much for building things.
>
> Best regards,
> Peter
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev

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

Re: [Nix-dev] nix modules: Unsetting attrsOf options?

[Guillaume Maudoux (Layus)]

I remember having som luck with

config = {
  myattrs.a = mkForce null;
}

Depending on how the module handles null values, it could work.

-- Layus.

Le 07/09/16 à 00:35, Rickard Nilsson a écrit :
> Is it possible to unset an attrsOf option? Say I import a module that
> looks like this:
>
> options = {
>   myattrs = mkOption {
> type = types.attrsOf ...
> default = {};
>   };
> }
>
> config = {
>   myattrs = {
> a = ...
> b = ...
>   };
> };
>
> And then I want to remove the "a" attribute in the importing config:
>
> config = {
>   myattrs.a = mkForce ...
> }
>
> Is that possible in any way?
>
>
>   / Rickard
> ___
> 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] Multiple stores

[Guillaume Maudoux (Layus)]

Le 26/08/16 à 14:51, Freddy Rietdijk a écrit :
> Hi,
>
> I would like to use Nix for a certain data analysis where I will have
> several thousand files which are all together about two TB in size. At
> the moment NixOS is installed on a SSD which is a quarter that size.
> Would it be possible to install a second store elsewhere, in this case
> on a slower HDD? 
>
> I couldn't find anything about this so I guess it isn't possible. Do
> you have in that case any other suggestions? I suppose the most
> obvious solution would be to install Nix on the slower HDD. Using LVM
> with multiple SSD's gets a bit too expensive.
>
> How does Nix perform on a HDD?
Slowly ;-). I had an old laptop with HDD, and it was seriously painfull.

One solution could be to mount your SSD as a cache for the bigger HDD.
I know it is possible, but never tried it myself.

Another solution is to use a different store path for your experiments.
If you still want binary cache support, i experienced very good results
with proot.

-- Layus.
>
> Freddy
>
>
>
>
> ___
> 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] changing the default source epoch to be zip-safe

[Guillaume Maudoux (Layus)]

Le 21 août 2016 01:30:34 UTC+02:00, Daniel Hlynskyi  a 
écrit :
>still, why 1.1.1970?

Because it is a timestamp with value 0 for Linux files. Or maybe 1, to 
distinguish them from pure zero.

> One of @edolstra's commits introduced algorithm,
>that
>sets source epoch time to most recent source change date. Wouldn't that
>be
>better date for /nix/store? Currently datetime in /nix/store carries
>zero
>information.

Yes, having store path time carrying information like the sources epoch could 
be useful, but currently the NAR format used to fetch binary substitutes 
prevents this. From Nix man:

A NAR archive is like a TAR or Zip archive, but it contains only the 
information that Nix considers important. For instance, timestamps are elided 
because all files in the Nix store have their timestamp set to 0 anyway. 
Likewise, all permissions are left out except for the execute bit, because all 
files in the Nix store have 644 or 755 permission.

>
>Also, I'd like to notice that non-epoch-starttime files do exist in my
>store, probably created in nix-shell or nix-build:

Should not happen, really.

>
>[danbst@LX:~]$ ls -ld /nix/store/* | grep -v "Jan  1  1970"
>drwxr-xr-x  3 nixbld1 nixbld  4096 Aug  5 23:26
>/nix/store/7iv1251a6g03m5jjqazd5rfmbqsz67nc-nixos-shell
>drwxr-xr-x  6 rootroot4096 Aug  8 05:03
>/nix/store/pb6papnlgg62wkim7qsg8c2jw4izffx8-glibc-2.21
>-rw---  1 rootroot   0 Aug  4 22:29
>/nix/store/30q3vgn6p6abfz4xbs47v11wcikf9dqr-plasma-desktop-5.7.2.lock
>-rw---  1 rootroot   0 Aug  1 06:03
>/nix/store/59cp809rmyh12p800sln490yr0f93nx7-four-color-theorem-proof.lock
>-rw---  1 rootroot   0 Aug  5 23:26
>/nix/store/7iv1251a6g03m5jjqazd5rfmbqsz67nc-nixos-shell.lock
>-rw---  1 rootroot   0 Aug  4 00:15
>/nix/store/jv2drjhj8h0blz4lza6xsnraalsvhaf9-munin-2.999.2.lock
>-rw---  1 rootroot   0 Aug  4 22:29
>/nix/store/jxkj59ppkpna1xlmpjzdbxqzw49gbgif-plasma-desktop-5.7.2-dev.lock
>-rw---  1 rootroot   0 Aug  8 05:03
>/nix/store/pb6papnlgg62wkim7qsg8c2jw4izffx8-glibc-2.21.lock
>-rw---  1 rootroot   0 Jul 31 23:24
>/nix/store/v07q9f5k730czvabfzilnsnahdbk19hx-four-color-theorem-src.lock
>-rw---  1 rootroot   0 Aug  4 21:58
>/nix/store/vfgv4b1rgm1hkamqczmyals8s66gvq8k-ati-drivers-15.12-4.4.16.lock
>-rw---  1 rootroot   0 Aug  9 03:47
>/nix/store/y9asyqxygq39lkmc98cmbqsja5yynwd0-ruby-2.3.1-p0.lock
>-rw---  1 rootroot   0 Aug  1 00:20
>/nix/store/zlpqh99xfxqvwcwzj0hly2d07x84whz9-coq-8.3pl4.lock
>
>
>2016-08-20 12:11 GMT+00:00 Vladimír Čunát :
>
>> On 08/14/2016 04:13 PM, Ronny Pfannschmidt wrote:
>> > on nix it is a regular problem for me that zip file generating
>tools fail
>> > due to the epoch time being set to a time that's not supported in
>the
>> > zip format
>> > (mostly python wheels)
>> >
>> > i would like to propose setting that epoch by default to something
>that
>> > is supported by zip
>>
>> We discussed that zip problems aren't that bad to change timestamps
>of
>> /nix/store paths directly (1.1. 1970).
>>
>> For python and similar we have a hook that touches source files after
>> "unpacking" phase - the typical problem is after fetch* other than
>> fetchurl. Typical usage:
>>   buildInputs = [ (ensureNewerSourcesHook { year = "1980"; }) ]
>>
>> Note that our generic python builder already does use the hook
>> automatically.
>>
>> --Vladimir
>>
>>
>>
>> ___
>> 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 mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Two declarative ways to install a package?

[Guillaume Maudoux (Layus)]

Le 12 août 2016 18:02:49 UTC+02:00, Arnold Krille <arn...@arnoldarts.de> a 
écrit :
>On Fri, 12 Aug 2016 16:15:46 +0200 "Guillaume Maudoux (Layus)"
><layus...@gmail.com> wrote:
>> I would rather see it as a convenience.
>> The package is in your store anyway, so better make it available in
>> user shells.
>
>No, only expose what is needed or wanted explicit (explicit is better
>then implicit;-)). Just because I want mpd to run on my machine,
>doesn't mean I want every user to run its own mpd (and wonder why the
>default-port is already in use). For example.
>

I guess m'y use cases are only single-user machines, where the difference 
between user and system is sometimes fuzzy.

>> With mysql for example, having the mysql command in your path is not
>> strictly necessary, but it would be really annoying not to have it.
>> Forcing users to install it in their own environments could even lead
>> to version mismatches.
>
>This largely depends on the package, doesn't it?
>
>For the mysql-service to expose the mysql-commandline tool is a nice
>convenience, at the same time exposing the mysqld binary is needless
>and allows other apps to use that binary without actually depending on
>it. It also allows foes to use it directly from your environment
>without dealing specially with nix.
>
>For the nginx-package to expose the nginx-daemon binary to your
>environment isa bit useless for the same reasons explained with mysqld
>exposed. But are there user-tools for nginx that should be exposed?
>
>Maybe it would be better if there was a mysql and a mysql-server
>package and the mysql-service would use the mysql-server itself and
>expose the mysql commandline to the environment without exposing the
>server binary?
>
>> If exposing a package from its service happens to be annoying (for
>> whatever reason),
>> may I suggest suggest to pull-request an opt-out option for it ?
>
>For security and sanity reason, it should be opt-in.

I think your point ils valid. But an option is not so useful in this case. 
Adding the package to the environment directly may even be simpler than 
enabling the option.

Oh btw, What would you think of a global opt-in option ? Like noXLibs ?

>
>- Arnold
>
>
>
>
>___
>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] Two declarative ways to install a package?

[Guillaume Maudoux (Layus)]

I would rather see it as a convenience.
The package is in your store anyway, so better make it available in user
shells.

With mysql for example, having the mysql command in your path is not
strictly necessary, but it would be really annoying not to have it.
Forcing users to install it in their own environments could even lead to
version mismatches.

If exposing a package from its service happens to be annoying (for
whatever reason),
may I suggest suggest to pull-request an opt-out option for it ?


Le 12/08/16 à 15:44, Moritz Ulrich a écrit :
> If the service doesn't provide any necessary command line tools that
> would justify putting it into the global environment, I would say it's a
> bug, yes.
>
>
> Anders Lundstedt  writes:
>
>> On Thu, Aug 11, 2016 at 9:35 PM, Kevin Cox  wrote:
>>> It's also important to not that services generally (never?) actually
>>> "install" the package.
>> I did a quick check among my enabled services. Two services that add
>> their packages to environment.systemPackages are the transmission and
>> shairport-sync services. The shairport-sync.nix service file provides
>> no motivation for this. Should this be considered a bug?
>> ___
>> 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 mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] multiple versions of the same software? / collisions

[Guillaume Maudoux (Layus)]

Hi,

Here is a working example with nix-env :

nix-env -i $(nix-build --expr 'with import  {}; pkgs.buildEnv {
name = "pythons"; ignoreCollisions = true; paths = [ pkgs.python34
pkgs.python35 ]; }')

or, to pick the prioritized python version (change the priority value if
needed; prioritizing avoids colisions) :

nix-env -i $(nix-build --expr 'with import  {}; pkgs.buildEnv {
name = "pythons"; paths = [ (lib.recursiveUpdate pkgs.python34 {
meta.priority = 0; }) pkgs.python35 ]; }')

oh, and uninstall other pythons before :-).

Result (in your shell):
$ python3
/external command/
python3python3.4-config   python3.4m-config 
python3.5-config   python3.5m-config   
python3.4  python3.4m python3.5 
python3.5m python3-config

-- Layus.

PS: This is probably not the best method to use python, but it may be
helpful to have both in your shell.

Le 04/08/16 à 20:59, Freddy Rietdijk a écrit :
> A method to have access to all interpreters is to create a derivation
> that has symbolic links to each of the interpreters and install that
> one. But as has been said before nix-shell is the recommended method.
>
>  
>
> On Thu, Aug 4, 2016 at 2:13 PM, Rok Garbas <r...@garbas.si
> <mailto:r...@garbas.si>> wrote:
>
> for the python development don't use nix-env but create per project
> default.nix scripts and use nix-shell.
>
> make sure you read the python section in nixpkgs manual ->
> http://nixos.org/nixpkgs/manual/ <http://nixos.org/nixpkgs/manual/>
>
> if you're looking to generate nix expressions from requirements.txt
> checkout pypi2nix -> https://github.com/garbas/pypi2nix
> <https://github.com/garbas/pypi2nix>. also know
> that pypi2nix is in early stage - still it is giving good results for
> some - and i'm looking for feedback of packages that break since this
> is the only way i can fix it.
>
>
> On Thu, Aug 4, 2016 at 2:07 PM, Guillaume Maudoux (Layus)
> <layus...@gmail.com <mailto:layus...@gmail.com>> wrote:
> > Hi,
> >
> > I think you are putting your efforts in the wrong direction.
> > Nix is not designed to install both python 3.4 and 3.5 in the same
> > environment.
> >
> > What it can do however is cache both in the store, so you can get an
> > environment with python 3.4 with
> > nix-shell -p python34
> > and an environment with python 3.5 with
> > nix-shell -p python35
> >
> > Nix can provide you with as many different environments at the
> same time.
> > You can have a shell with python 3.4 running besides a shell
> with python
> > 3.5.
> > You should however not install both in your default environment
> (nix-env
> > -i) as it won't work.
> >
> > May I refer you to
> https://nixos.org/wiki/Development_Environments
> <https://nixos.org/wiki/Development_Environments> ?
> >
> > Regards,
> > -- Layus.
> >
> >
> > Le 03/08/16 à 16:43, Roland Koebler a écrit :
> >> Hi,
> >>
> >> I think I've now found out (at least partially), although this
> could
> >> result in a package being installed multiple times.
> >>
> >>> It appears that the flag setting only works on already
> installed packages.
> >> Yes, and if I use
> >>
> >> $ nix-env -i python3-3.5.2
> >> ...
> >> $ nix-env --set-flag priority 10 python3-3.5.2
> >> ...
> >> $ nix-env -i python3-3.4.5 python3-3.5.2
> >> replacing old ‘python3-3.5.2’
> >> installing ‘python3-3.4.5’
> >> installing ‘python3-3.5.2’
> >>
> >> it does not work, since the last command first removes
> python3-3.5.2,
> >> then probably the flag is lost, and then installs it again.
> >>
> >>> Also I'm not sure, but even if there are name collisions in
> the user
> >>> environment, it should still be possible to install both
> packages but only
> >>> use one of the names, and then create your name alias to the
> non-named
> >>> package. However I do not know how this can be done.
> >> I think I've found out. The following works:
> >>
> >> $ nix-env -i python3-3.5.2
> >> $ nix-env --set-flag priority 10 python3-3.5.2
> >> $ nix-env -i -P python3-3.4.5
&

[Nix-dev] Locking issues with Nix

[Guillaume Maudoux (Layus)]

Hi nix devs,

I am posting here an issue reported on [1], hoping to get a quick fix

With my current version of nix, I observe the following behaviour after
some calls to nix:
The command hangs forever.

|$ nix-build ... these derivations will be built:
/nix/store/-.drv waiting for locks or build slots... |

This occurs after cancelling some other builds through the daemon.
When I cancel a user nix-build (or nix-env) command, it shows me an
|error: interrupted by the user|.

This error also appears in the logs of the nix-daemon:

|aoû 07 23:05:58 ankh-morpork systemd[1]: Started Nix Daemon. aoû 07
23:05:58 ankh-morpork nix-daemon[2971]: accepted connection from pid
2970, user layus aoû 07 23:06:41 ankh-morpork nix-daemon[2971]:
accepted connection from pid 3070, user layus aoû 07 23:07:06
ankh-morpork nix-daemon[2971]: unexpected Nix daemon error:
interrupted by the user aoû 07 23:08:38 ankh-morpork
nix-daemon[2971]: accepted connection from pid 3442, user layus aoû
07 23:09:29 ankh-morpork nix-daemon[2971]: unexpected Nix daemon
error: interrupted by the user ... |

and so on. My guess is that after some such cancellations, there is no
build user available anymore.

Do you have any idea of

1) How to clear the locks without rebooting ?
2) How to investigate the issue ?

Needless to say that not being able to build anything is a huge
annoyance :-).

Regards,

-- Layus.

[1] https://github.com/NixOS/nix/issues/1015

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

Re: [Nix-dev] multiple versions of the same software? / collisions

[Guillaume Maudoux (Layus)]

Hi,

I think you are putting your efforts in the wrong direction.
Nix is not designed to install both python 3.4 and 3.5 in the same
environment.

What it can do however is cache both in the store, so you can get an
environment with python 3.4 with
nix-shell -p python34
and an environment with python 3.5 with
nix-shell -p python35

Nix can provide you with as many different environments at the same time.
You can have a shell with python 3.4 running besides a shell with python
3.5.
You should however not install both in your default environment (nix-env
-i) as it won't work.

May I refer you to https://nixos.org/wiki/Development_Environments ?

Regards,
-- Layus.


Le 03/08/16 à 16:43, Roland Koebler a écrit :
> Hi,
>
> I think I've now found out (at least partially), although this could
> result in a package being installed multiple times.
>
>> It appears that the flag setting only works on already installed packages.
> Yes, and if I use 
>
> $ nix-env -i python3-3.5.2
> ...
> $ nix-env --set-flag priority 10 python3-3.5.2
> ...
> $ nix-env -i python3-3.4.5 python3-3.5.2
> replacing old ‘python3-3.5.2’
> installing ‘python3-3.4.5’
> installing ‘python3-3.5.2’
>
> it does not work, since the last command first removes python3-3.5.2,
> then probably the flag is lost, and then installs it again.
>
>> Also I'm not sure, but even if there are name collisions in the user
>> environment, it should still be possible to install both packages but only
>> use one of the names, and then create your name alias to the non-named
>> package. However I do not know how this can be done.
> I think I've found out. The following works:
>
> $ nix-env -i python3-3.5.2
> $ nix-env --set-flag priority 10 python3-3.5.2
> $ nix-env -i -P python3-3.4.5
>
> --preserve-installed / -P was the relevant switch.
> However, this can have some strange side-effects, since -P can
> cause a package to be installed "multiple times":
>
> $ nix-env -i -P python3-3.4.5
> ...
> $ nix-env -i -P python3-3.4.5
> ...
> $ nix-env -i -P python3-3.4.5
> ...
> $ nix-env -q
> ...
> python3-3.4.5
> python3-3.4.5
> python3-3.4.5
> python3-3.4.5
> ...
>
> This could then be "resolved" by:
>
> $ nix-env -e python3-3.4.5
> uninstalling ‘python3-3.4.5’
> uninstalling ‘python3-3.4.5’
> uninstalling ‘python3-3.4.5’
> uninstalling ‘python3-3.4.5’
> $ nix-env -P -i python3-3.4.5
> installing ‘python3-3.4.5’
>
> But it still looks strange.
> Is this intentional?
>
> Roland
>
> ___
> 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] duplicate packages?

[Guillaume Maudoux (Layus)]

Le 04/08/16 à 10:57, Roland Koebler a écrit :
> Hi,
>
> I have Nix running on Debian with the default channel [*], and I noticed,
> that -- although I only have a few packages installed -- many dependencies
> are installed several times. I would like to understand, why.
>
> [*] https://nixos.org/channels/nixpkgs-unstable nixpkgs
First of all, there may be old derivations in the store.
You should look for duplicates in the output of
nix-store -qR ~/.nix-profile, not in the store directly.

Because there can exist many generation of you profile in the store.
>
>
> 1. Many packages are installed several times with the same version
>number, e.g.:
>
>2pa9z1h2m0pyik4hr1ikfl6jvdg8j4pb-acl-2.2.52
>8c5s33f5mzfn9z3yhjprxnxzl19dg7p2-acl-2.2.52
>sk0b1r840b686zc2m8mzyw8yyq1aymqh-acl-2.2.52
>
>4vgjwvgf24jl3czzksai6mwsklvhgs4k-attr-2.4.47
>8z667vv1agvpd3iknmk94j0ix6bv413i-attr-2.4.47
>m8qi9jrz51lqn7x0mifa9kpwpsp3b7dq-attr-2.4.47
>
>fxkm8r0vpv88ld82jz0a00sjvh342wfl-avahi-0.6.31
>p817p19niamk0f06r5wvqvdqnym96r7w-avahi-0.6.31
>5wi7ja71s4wdjkzfghc4lkwrwc45fnf9-avahi-0.6.32
>
>d20f169ryps7ds2qak0r5n1f4hhxr80h-bash-4.3-p42
>d44582rghk696yw704sh5nbvbpnm69iv-bash-4.3-p42
>xag5ayq906w9zhlxs8wayv4kvpiyqphq-bash-4.3-p42
>
>0y480sh5b4hny3iq8fy3ppha0zllxxaw-boehm-gc-7.2f
>bw1p8rairfwv2yif2g1cc0yg8hv25mnl-boehm-gc-7.2f
>f24zx1r39kalz01q9kw7zcg1ngj7w2db-boehm-gc-7.2f
>
>98s2znxww6x7h2ch7cj1w5givahxmdna-glibc-2.23
>phffgv3pwihmpdyk8xsz3wv8ydysch8w-glibc-2.23
>
>...
>
>I know that different build-inputs result in different hashes, but I
>would have expected a more homogeneous structure in nixpkgs (e.g.
>only one acl-2.2.52 in nixpkgs and not several ones), so that
>I don't need e.g. 3 times acl-2.2.52 or bash-4.3-p42.
You only get an homogeneous structure if you update all your packages at
the same time.
Doing nix-env -u will "[o]nly upgrade a derivation to newer versions [as
t]his is the default."

>From a tree with

+--- package a v1
|`--- 2pa9z1h2m0pyik4hr1ikfl6jvdg8j4pb-acl-2.2.52
`--- package b v1
 `--- 2pa9z1h2m0pyik4hr1ikfl6jvdg8j4pb-acl-2.2.52

Running nix-env -u may update package a and not package b.
As the new package a is built in the new nixpkgs, it comes with a new
acl (same version, but different as probably one dependency changed).

You get two different acl in your system.

+--- package a *v2*
|`--- *8c5s33f5mzfn9z3yhjprxnxzl19dg7p2*-acl-2.2.52
`+--- package b v1
 `--- 2pa9z1h2m0pyik4hr1ikfl6jvdg8j4pb-acl-2.2.52

To avoid this, you can upgrade packages with other flags like --eq.
Look an nix-env --upgrade manual section :

   --lt
   Only upgrade a derivation to newer versions. This is the default.

   --leq
   In addition to upgrading to newer versions, also “upgrade” to
derivations that have the same version. Version are not a unique
   identification of a derivation, so there may be many
derivations that have the same version. This flag may be useful to force
   “synchronisation” between the installed and available
derivations.

   --eq
   Only “upgrade” to derivations that have the same version.
This may not seem very useful, but it actually is, e.g., when there is a new
   release of Nixpkgs and you want to replace installed
applications with the same versions built against newer dependencies (to
reduce
   the number of dependencies floating around on your system).

   --always
   In addition to upgrading to newer versions, also “upgrade” to
derivations that have the same or a lower version. I.e., derivations may
   actually be downgraded depending on what is available in the
active Nix expression.

>Is this because I use nixpkgs-unstable, and everything is moving
>there, and is this reduced in the NixOS-release-channels?
>Or is there some other reason?
The problem comes from how nix-env updates packages, but is less visible
if you follow a stable branch.

>
> 2. Is there a way to clean this up?
>Either in the repository or locally?
>Or is there a reason why this should not be cleaned up?
See above flags.
>
> 3. Is there a simple way to find the nix-expression (e.g.
>default.nix-file) of an installed package / a path in
>the nix-store?
>And is there a way to know which directory in the nix-store
>belongs to which .drv-file?
Not that I know of. There was a discussion at NixCon about that, but no
implementation yet.
Your best bet is to `grep` for the name in nixpkgs tree.

To find the .drv of a derivation, provided it has not yet been
garbage-collected, you can call `nix-store --query --deriver
/nix/store/derivation`
>
>
> thanks,
> Roland
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev

___
nix-dev mailing list

Re: [Nix-dev] Seemingly inexplicable proliferation of gcc/glibc runtimes

[Guillaume Maudoux (Layus)]

Le 27/07/16 à 19:28, Kosyrev Serge a écrit :
> zimbatm  writes:
>> Is it possible some of them are kept from the bootstrap? What you need is a
>> tool that constructs the dependency tree(s).
> The key question is -- what this tool would use as source of
> information?
>
> Let me repeat the steps:
>
> 1. find out the glibcs:
>
> [deepfire@andromedae:~]$ nix-analyze-rootlike glibc   # sources 
> at [1]
> ; analyzing "/nix/store/*-glibc-*" (minus noise)
> referrers | disc  | correlation to profile
> closure   direct  | size  | user  system
> 1397  1062| 22M   | 113   25  
> /nix/store/dad9vxniabwzidvvxfsfj6vb0xncsbbb-glibc-2.23
> 210   165 | 22M   | 0 0   
> /nix/store/phffgv3pwihmpdyk8xsz3wv8ydysch8w-glibc-2.23
> 159   22  | 34M   | 0 0   
> /nix/store/i0l0jjkk82wsqz9z5yhg35iy78bjq684-glibc-2.21
> 5 5   | 22M   | 0 0   
> /nix/store/62n981f02b56wjqfdq00pq706k11xz4d-glibc-2.21
>
> 2. pick an easy-to-analyze anomaly:
>
> [deepfire@andromedae:~]$ nix-store -q --referrers-closure 
> /nix/store/62n981f02b56wjqfdq00pq706k11xz4d-glibc-2.21
> /nix/store/62n981f02b56wjqfdq00pq706k11xz4d-glibc-2.21
> /nix/store/5m6i1h71xp6r7k381hrsv5qwn3s6b93h-libXau-1.0.8
> /nix/store/kx1l6yis70h9sly7cs4b95jq0j8yxjqr-libXdmcp-1.1.2
> /nix/store/bxsi9xrrfc0qw3ndys83rppwqxbn33ma-libxcb-1.11.1
> /nix/store/62bmpi8kll9kj8il89kdaddvzib3r4pm-libX11-1.6.3
>
> What would the tool help with?  That's all the information the Nix store has.
>
> Again, it seems a contradiction to me:
>
>   - the referrer closure for the rogue glibc doesn't touch anything 
> root-related
>   - yet the GC doesn't collect it
>
> So, can anyone confirm that it indeed is a bug?
>
No, it is probably not a bug.

If you think the path is useless, you can remove it from the store with
`nix-store --delete`.
Most probably, nix-store will refuse to do that, as the derivation is
"live".

This means that while the derivation is not required by some root, it is
kept to satisfy other functionalities of nix.
In some cases it is helpful to keep access to build inputs like gcc,
even if they are not used by the running system.

Please give us the content of your /etc/nix/nix.conf.
You may also find http://nixos.org/nix/manual/#conf-gc-keep-outputs a
good introduction.

-- Layus.

PS: if you want to dig deeper, try `grep
/nix/store/62n981f02b56wjqfdq00pq706k11xz4d-glibc-2.21
/nix/store/*.drv`, you may get something.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Seemingly inexplicable proliferation of gcc/glibc runtimes

[Guillaume Maudoux (Layus)]

My intuition tells me that you have something like gc-keep-derivations or 
gc-keep-outputs pinning build inputs/outputs in the store.

You could use --option xxx false to disable these options temporarily when 
doing nix store gc.

-- Layus.

Le 25 juillet 2016 00:47:53 UTC+07:00, Kosyrev Serge 
<_deepf...@feelingofgreen.ru> a écrit :
>Kosyrev Serge <_deepf...@feelingofgreen.ru> writes:
>> What I see is this:
>
>Whoops!  I'm afraid my last minute changes slightly broke formatting --
>here goes a fixed version:
>
>[deepfire@andromedae:~]$ nix-analyze-rootlike glibc; echo;
>nix-analyze-rootlike gcc
>; analyzing "/nix/store/*-glibc-*" (minus noise)
>referrers  | disc  | correlation to profile
>closuredirect  | size  | user  system
>1073   807 | 22M   |
>10925  /nix/store/dad9vxniabwzidvvxfsfj6vb0xncsbbb-glibc-2.23
>210165 | 22M   |
>0  0   /nix/store/phffgv3pwihmpdyk8xsz3wv8ydysch8w-glibc-2.23
>15922  | 34M   |
>0  0   /nix/store/i0l0jjkk82wsqz9z5yhg35iy78bjq684-glibc-2.21
>5  5   | 22M   | 0 0   
>/nix/store/62n981f02b56wjqfdq00pq706k11xz4d-glibc-2.21
>
>; analyzing "/nix/store/*-gcc-*" (minus noise)
>referrers  | disc  | correlation to profile
>closuredirect  | size  | user  system
>38810  | 116M  |
>42 8   /nix/store/scfqn9hsh9k1b0j1y1znzrkr2a5k-gcc-5.4.0
>1485   | 91M   | 0 0   
>/nix/store/cpv8pyc772cx0spzz76sa6dvsf6555dh-gcc-4.8.4
>7  2   | 116M  | 0 0   
>/nix/store/l8y2srrkp5fflwph7vq0gllj1k1ai17w-gcc-5.3.0
>
>
>-- 
>с уважениeм / respectfully / Z poważaniem,
>Косырев Сергей
>___
>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] Too many open issues

[Guillaume Maudoux (Layus)]

Hi,

May I suggest that the culprit is the tool itself ? Clearly GitHub does a poor 
job at managing and displaying issues. It works well for pull requests and code 
exploration, but not for issues.

What we need is to maintain a pool of issues that need attention. Ideally this 
pool is quite small (max 20), and contains issues that require some action, or 
could benefit from anyone's input.

For example, a new issue requires attention. When the discussion has started, 
it can be removed from the pool.
Issues with no activity also require attention eventually.

Furthermore, I think that every issue should be assigned to someone. Being 
assigned to an issue would mean that you are responsible for its progress, like 
pinging the maintainers, not for fixing the problem by yourself (but you still 
can).

We really need a way to get a short list of items requiring global attention, 
then triage/dispatch it elsewhere to keep focus on interesting things.
If GitHub cannot do that, we may need another tool.

Regards,

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

Re: [Nix-dev] Too many open issues

[Guillaume Maudoux (Layus)]

Hi,

I have tried code triage for some weeks, and finally stopped using it.

Yes, it allows to spread attention to many issues, but many issues do not need 
attention, either because they are already in progress, or because nobody 
really cares.

Some issues are even weirder, like the 200 issues opened automatically for wiki 
migration. These are the only one that could benefit from auto close.

Codetriage is not the solution, and not really a solution.

Regards,

-- Layus.

Le 22 juillet 2016 20:12:18 UTC+07:00, Kevin Cox  a écrit 
:
>On 22/07/16 08:55, Alexey Shmalko wrote:
>> This one: https://www.codetriage.com/nixos/nixpkgs
>>
>
>That's it! I have subscribed to get a couple issues a day so hopefully
>I
>can help a bit. This site seems like a nice way to spread the load.
>
>It's open source too, and I just opened an issue asking them to
>implement filters as I'm not really interesting in seeing in-progress
>issues.
>
>https://github.com/codetriage/codetriage/issues/498
>
>
>
>
>
>
>___
>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] Nix syntax surprise.

[Guillaume Maudoux (Layus)]

Yep, that's it. In my original use case however, the issue was several
lines above the reported location.

Thanks for your fast answer!

-- Layus

Le 24/06/16 à 12:15, Vladimír Čunát a écrit :
> On 06/24/2016 11:58 AM, Guillaume Maudoux (Layus) wrote:
>> Does someone understand why the following nix expression is invalid ?
> You need to put the let-expression into parentheses. Lists are
> whitespace-separated, so most nontrivial items have to be parenthesized.
>
> --Vladimir
>
>

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

[Nix-dev] Nix syntax surprise.

[Guillaume Maudoux (Layus)]

Hi,

Does someone understand why the following nix expression is invalid ?

|[ let a = 10; in { b = "a = ${a}"; } ] |

Running |nix-instantiate --eval ./bug.nix --strict| gives |error: syntax
error, unexpected ID, expecting '{', at /home/layus/bug.nix:3:5|.

The manual says nothing about this in the “let expressions” section.

Thanks for any pointer,

— Layus.

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

Re: [Nix-dev] Overriding a Haskell package can't be that hard...

[Guillaume Maudoux (Layus)]

I have written nix examples in increasing order of complexity.
They should help you understand what is going on behind the scenes. (see
below).

As for your snippets,

|haskellPackages.override { overrides = self: super: { thrift =
self.callPackage /home/cody/sources/thrift/lib/hs {}; }; }; |

performs a deep override of thrift on haskellPackages. This means that
every package using thrift will use your definition of thrift, not the
one bundled with nixpkgs.
The expressions returns this new haskellPackages set.

Now,

|packageOverrides = oldPkgs: { haskellPackages =
oldPkgs.haskellPackages.override { ... }; }; |

is the usual way to make a deep package override on the top-level
packages set.
With this expression, haskellPackages will now refer to your updated
haskellPackges set everywhere in nixpkgs.
You HAVE TO use oldPkgs (or super, as it is called in your examples)
otherwise you get an infinite loop where packages override themselves
(bad :-)).

Now, my interactive examples
You can also look at
https://medium.com/@MrJamesFisher/nix-by-example-a0063a1a4c55#.wby41ssn0.

|# to eval this file, run `nix-instantiate --eval  --strict`.
# Result is always "high depends on low and med depends on low", #
except for the two last ones wihich read "high depends on low and med,
which depends on low". builtins.map (s: (if s ? ps' then s.ps' else
s.ps).high ) [ { # A simple recursive package set (ps). ps = rec { low =
"low"; med = "med depends on ${low}"; high = "high depends on ${low} and
${med}"; }; } rec { # A simple recursive package set, using with instead
of rec. # Note the higher level "rec" to reuse ps in the with clause. ps
= with ps; { low = "low"; med = "med depends on ${low}"; high = "high
depends on ${low} and ${med}"; }; } rec { # Again the same, but with a
function. psFun = self: with self; { low = "low"; med = "med depends on
${low}"; high = "high depends on ${low} and ${med}"; }; ps = psFun ps; #
Look at this fixpoint. # ps is the result of calling psFun on itself. #
This works thanks to lazyness. } rec { # Using with is not always
desirable. # In this case we prefer to use self directly. psFun = self:
{ low = "low"; med = "med depends on ${self.low}"; high = "high depends
on ${self.low} and ${self.med}"; }; ps = psFun ps; } ## The question is:
How do I override a package ? ## 1. Simple answer rec { psFun = self: {
low = "low"; med = "med depends on ${self.low}"; high = "high depends on
${self.low} and ${self.med}"; }; ps = psFun ps; ps' = ps // { med =
"med, which depends on ${ps'.low}"; }; } ## Here ps' contains an updated
med package, but ps'.high does not use the updated package. ## for
proof, the output is unchanged. ## 2. A method that works. ## psFun
thinks it receives itself as an argument, but we may trick it ## by
giving a sligtly different self: rec { psFun = self: { low = "low"; med
= "med depends on ${self.low}"; high = "high depends on ${self.low} and
${self.med}"; }; ps = psFun ps; ps' = (psFun ps') // { med = "med, which
depends on ${ps'.low}"; }; } ## in this case, med is overriden by our
own definition, and any package that ## uses self.med in psFun now uses
our updated package. ## We have effectively replaced med in the whole
hierarchy. ## I am a bit overextending myself here, but haskellPackages
must do something like: rec { psFun = self: { low = "low"; med = "med
depends on ${self.low}"; high = "high depends on ${self.low} and
${self.med}"; }; overrides = pkgs: { med = "med, which depends on
${pkgs.low}"; }; ps = (psFun ps) // (overrides ps); } ] |

Le 24/06/16 à 05:57, Cody Goodman a écrit :

> I was trying to use the cassandra-thrift haskell package and there was
> a bug in one if it's dependencies, thrift. I fixed the bug in thrift
> and then went to the nix haskell guide to find out how to override
> "thrift" with my bugfixed version.
>
> I came up with this from the haskell guide
> (http://nixos.org/nixpkgs/manual/#how-to-build-projects-that-depend-on-each-other):
>
> { pkgs }: {
> packageOverrides = super: let self = super.pkgs; in
>   {
> haskellPackages = super.haskellPackages.override {
>   overrides = self: super: {
> thrift = self.callPackage /home/cody/sources/thrift/lib/hs {};
>   };
> };
>   };
>
>   allowUnfree = true;
>   firefox = {
>  enableGoogleTalkPlugin = true;
>  enableAdobeFlash = true;
>   };
>
> and then finally tried the example from ocharle's wiki on nix/haskell,
> which involved putting the override in shell.nix like below:
>
> with (import  {}).pkgs;
> let modifiedHaskellPackages = haskellPackages.override {
>   overrides = self: super: {
> thrift = self.callPackage /home/cody/sources/thrift/lib/hs {};
>   };
> };
> in modifiedHaskellPackages.hscassandra.env
>
> I'm a little dismayed since I even went through all 19 or so of the
> nix
> pills(http://lethalman.blogspot.com/2014/07/nix-pill-1-why-you-should-give-it-try.html)
> thinking I just needed to brush up on nix.
>
> If someone could also explain 

Re: [Nix-dev] Broken nix database/store.

[Guillaume Maudoux (Layus)]

Le 10/06/16 à 12:09, Joachim Schiele a écrit :
> On 09.06.2016 19:21, Layus wrote:
>> Hi,
>>
>> Due to a wrong manipulation when activating dir_index on my root
>> partition, I have now plenty of live orphaned paths in my store (about
>> 5G) like this one:
>>
>> |$ nix-store -q --referrers-closure
>> /nix/store/4zhkw0g564g3ljdpnn8j5krrsvcxildn-libXcomposite-0.4.4.tar.bz2
>> /nix/store/4zhkw0g564g3ljdpnn8j5krrsvcxildn-libXcomposite-0.4.4.tar.bz2
>> $ nix-store --delete
>> /nix/store/4zhkw0g564g3ljdpnn8j5krrsvcxildn-libXcomposite-0.4.4.tar.bz2
>> finding garbage collector roots... error: cannot delete path
>> ‘/nix/store/4zhkw0g564g3ljdpnn8j5krrsvcxildn-libXcomposite-0.4.4.tar.bz2’ 
>> since
>> it is still alive 0 store paths deleted, 0.00 MiB freed $ nix-store
>> --delete --ignore-liveness
>> /nix/store/4zhkw0g564g3ljdpnn8j5krrsvcxildn-libXcomposite-0.4.4.tar.bz2
>> error: you are not allowed to ignore liveness 0 store paths deleted,
>> 0.00 MiB freed $ sudo nix-store --delete
>> /nix/store/4zhkw0g564g3ljdpnn8j5krrsvcxildn-libXcomposite-0.4.4.tar.bz2
>> finding garbage collector roots... error: cannot delete path
>> ‘/nix/store/4zhkw0g564g3ljdpnn8j5krrsvcxildn-libXcomposite-0.4.4.tar.bz2’ 
>> since
>> it is still alive 0 store paths deleted, 0.00 MiB freed $ sudo nix-store
>> --delete --ignore-liveness
>> /nix/store/4zhkw0g564g3ljdpnn8j5krrsvcxildn-libXcomposite-0.4.4.tar.bz2
>> finding garbage collector roots... deleting
>> ‘/nix/store/4zhkw0g564g3ljdpnn8j5krrsvcxildn-libXcomposite-0.4.4.tar.bz2’ 
>> deleting
>> ‘/nix/store/trash’ deleting unused links... note: currently hard linking
>> saves 1754.97 MiB 1 store paths deleted, 0.27 MiB freed |
>>
>> Is there some repair command to update liveness of paths ?
> what you could do:
> 1. create a backup of all files
> 2. remove most stuff in / except /home/, /etc/nixos/, /etc/nix,
> /nix/store (among some paths i just didn't think about)
>
> 3. boot a rescue nixos live-stick
> 4. do a nixos-install with the config you already have
>
> this basically makes sure that your store sqlite database gets properly
> repopulated.
>
> after you booted into your new system, consider:
>   nix-collect-garbage -d
>
> to get rid of unused /nix/store paths

Thanks Joachim,

I did something very similar (with a chroot in archlinux), just to
discover that the files were still present.
It turns out that they are "live" in the nix store because of the
options "gc-keep-outputs" and "gc-keep-derivations" that are enabled in
my config.

for the record, `nix-collect-garbage -d --option gc-keep-outputs false
--option gc-keep-derivations false` does the job... :-).

Guillaume.

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

Re: [Nix-dev] How to install RubyOnRails on nixos?

[Guillaume Maudoux (Layus)]

I am sure the usual Google-fu on the mailing list archive, manuals and wiki 
should get you started with ruby Gems bundling.

The usual workflow seems to get bundler, generate a gemspec and let some 
gem-to-nix tool do the packaging job.

Feel free to ask more specific questions.

Regards,
-- Layus.

Le 6 juin 2016 10:51:22 UTC+02:00, Nicolas Petton  a écrit :
>hi,
>
>I'm trying to properly install rails on nixos.  I'm not interested in
>packaging an existing rails app, but rather to do rails development.
>
>I guess using rubygems is not the nixos way (and installing the rails
>gem globally won't work anyway).
>
>Any pointers?
>
>Cheers,
>Nico
>
>
>
>
>___
>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] Latex package to handle unicode characters?

[Guillaume Maudoux (Layus)]

Bottom line is that texlive updates its packages frequently and our md5 are 
always out of sync. We mirror some packages but not the whole scheme-full.

AFAIK, you can either use scheme basic, or go trough the update procedure 
described in texlive-new/default.nix to get a (temporarily) up-to-date list of 
hashes and build against that.

Regards,
-- Layus.


Le 6 juin 2016 22:33:35 UTC+02:00, Taeer Bar-Yam  a écrit :
>actually it appears that only scheme-basic is working. scheme-full is
>giving me an error about md5 hash mismatches:
>( output path ‘/nix/store/ayq32cfk92kiysywxnb35xfhsm4j3wbq-2up.tar.xz’
>has md5 hash ‘7bb1a159a6e50d7cb807c58f471e360e’ when
>‘6160fbc7ab71be778081500b908d2648’ was expected )
>does anyone know what the problem is and how to fix it?
>> On Jun 6, 2016, at 2:16 PM, Taeer Bar-Yam  wrote:
>> 
>> I had a similar problem and started using texlive.combine.scheme-full
>or texlive.combine.scheme-basic. Maybe try that, see if it works for
>what you need?
>>> On Jun 6, 2016, at 2:07 PM, Jeffrey David Johnson 
>wrote:
>>> 
>>> I was using texLiveFull until recently, but now it's marked broken
>and a comment points users to the texlive.combine method. I tried
>checking out an older version of pkgs/tools/typesetting/tex but the
>dependencies don't line up with the rest of nixpkgs anymore. Probably I
>just want the full set of texlive-new packages, even if they're big,
>becuase I don't know what I'm doing enough to pick and choose. So I
>tried this monster (all collections + inputenc packages):
>>> 
>>>  myTexlive = with pkgs; texlive.combine {
>>>inherit (texlive)
>>>  collection-basic
>>>  collection-bibtexextra
>>>  collection-binextra
>>>  collection-context
>>>  collection-fontsextra
>>>  collection-fontsrecommended
>>>  collection-fontutils
>>>  collection-formatsextra
>>>  collection-games
>>>  collection-genericextra
>>>  collection-genericrecommended
>>>  collection-htmlxml
>>>  collection-humanities
>>>  collection-langafrican
>>>  collection-langarabic
>>>  collection-langchinese
>>>  collection-langcjk
>>>  collection-langcyrillic
>>>  collection-langczechslovak
>>>  collection-langenglish
>>>  collection-langeuropean
>>>  collection-langfrench
>>>  collection-langgerman
>>>  collection-langgreek
>>>  collection-langindic
>>>  collection-langitalian
>>>  collection-langjapanese
>>>  collection-langkorean
>>>  collection-langother
>>>  collection-langpolish
>>>  collection-langportuguese
>>>  collection-langspanish
>>>  collection-latex
>>>  collection-latexextra
>>>  collection-latexrecommended
>>>  collection-luatex
>>>  collection-mathextra
>>>  collection-metapost
>>>  collection-music
>>>  collection-omega
>>>  collection-pictures
>>>  collection-plainextra
>>>  collection-pstricks
>>>  collection-publishers
>>>  collection-science
>>>  collection-texworks
>>>  collection-wintools
>>>  collection-xetex
>>>  greek-inputenc;
>>>  };
>>> 
>>> Still the same error though. Maybe it's a pandoc issue after all.
>>> Jeff
>>> 
>>> On Wed, 1 Jun 2016 02:45:18 -0700
>>> Linus Arver  wrote:
>>> 
 On Sun, May 29, 2016 at 04:56:12PM -0700, Jeffrey David Johnson
>wrote:
> I get the following error when exporting some markdown to PDF with
>pandoc:
> 
>An error occured: PDF creation failed:
>! Package inputenc Error: Unicode char \u8:  not set up for use
>with LaTeX.
> 
>See the inputenc package documentation for explanation.
>Type  H   for immediate help.
> ...  
> 
>l.150   Evolutionary Analysis}
> 
>Try running pandoc with --latex-engine=xelatex.
> 
> I could hunt this one character down, but is there a package I
>could add to my texlive environment that might help handle this type of
>problem in general?
 
 I used to use the texliveFull package, which included xelatex.
 
 FWIW, I no longer use texliveFull; instead I use a Docker container
>for
 all TeX-related things as it is much simpler to use along with
 negligible maintenence costs, if at all.
 
> So far I just use the standard one:
> 
>myTexLive = texlive.combine {
>  inherit (texlive) scheme-small;
>};
> 
> Don't see any mention of xelatex in nixpkgs.
 
 That's probably because it still comes with texliveFull, which is
>what
 most people use I imagine.
 
> Ideally I'd like to handle all of unicode, but just skipping any
>unrenderable characters would be OK too, since I gather latex doesn't
>do that yet?
 
 AFAIK, Latex never dealt with Unicode natively. Xelatex has much
>simpler
 font support (fontspec) so I've always opted for 

Re: [Nix-dev] fetchurl and unpacker produced multiple directories

[Guillaume Maudoux (Layus)]

Why not simply set unpackPhase tout tour nées ?

Le 3 juin 2016 09:22:33 UTC+02:00, Tomas Hlavaty  a écrit :
>Rok Garbas  writes:
>> sourceRoot = ".";
>> and then you can mv/cp in postUnpack phase
>
>ah, great, thank you!
>
>Tomas
>___
>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] Latex package to handle unicode characters?

[Guillaume Maudoux (Layus)]

Hi,

`xelatex` comes with the texlive package `xetex`, which is included in
scheme-small.
I just checked that adding xetex to my texlive.combine function, and I
have access to xelatex.

You can try it yourself with
$ ls -l $(nix-build -E "with import  {}; pkgs.texlive.combine {
foo = pkgs.texlive.scheme-small; }")/bin/xelatex  
lrwxrwxrwx 7 root root 5  1 jan  1970
/nix/store/85ix8d6wy1f9lsy97cqyp0z7hp5iaapw-texlive-combined-2015/bin/xelatex
-> xetex

If you do not have xelatex in your env, there must be an issue somewhere.

Best regrads,

-- Layus.


Le 30/05/16 à 01:56, Jeffrey David Johnson a écrit :
> I get the following error when exporting some markdown to PDF with pandoc:
>
> An error occured: PDF creation failed:
> ! Package inputenc Error: Unicode char \u8:  not set up for use with 
> LaTeX.
>
> See the inputenc package documentation for explanation.
> Type  H   for immediate help.
>  ...  
>   
> l.150   Evolutionary Analysis}
>
> Try running pandoc with --latex-engine=xelatex.
>
> I could hunt this one character down, but is there a package I could add to 
> my texlive environment that might help handle this type of problem in 
> general? So far I just use the standard one:
>
> myTexLive = texlive.combine {
>   inherit (texlive) scheme-small;
> };
>
> Don't see any mention of xelatex in nixpkgs. Ideally I'd like to handle all 
> of unicode, but just skipping any unrenderable characters would be OK too, 
> since I gather latex doesn't do that yet?
>
> Thanks
> Jeff
> ___
> 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] confused using the ? operator with non literal operators

[Guillaume Maudoux (Layus)]

You are missing the only command that could enlighten you :

> foo ? bar
true

The second operant is taken as a string literal, that's why you need to
evaluate variables there.
The following also works :

> foo ? ${quux}
true

-- Layus.

Le 09/05/16 à 15:25, Samuel a écrit :
> Am I holding some false assumption here? It seems the ? operator has
> different behaviour depending on how the right hand side is evaluated:
>
> nix-repl> foo = { bar = "baz"; }
>
> nix-repl> quux = "bar"
>
> nix-repl> foo ? "bar"
> true
>
> nix-repl> foo ? quux
> false
>
> nix-repl> foo ? "${quux}"
> true
>
> nix-repl> quux == "${quux}"
> true
>
> nix-repl> builtins.typeOf quux
> "string"
>

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

Re: [Nix-dev] Accessing files in derivations.

[Guillaume Maudoux (Layus)]

Le 20/04/16 08:59, Vladimír Čunát a écrit :
> On 04/19/2016 10:03 PM, Layus wrote:
>> But your description made me think of a viable workaround.
>> We could ensure that every derivation has a fixed set of known outputs,
>> like dev, lib, out and man.
>> If there is no "lib" output, then the lib attribute could be an alias
>> for out.
> Yes, that has been suggested already and it's the current longer-term
> plan, at least as I see it. It requires nontrivial code rewrite, due to
> $outputLib and similar needing to be selected during evaluation and not
> during build.
>
> --Vladimir
If providing default outputs is just a question of symlinking attributes
to existing derivations, the following (pseudo)code would do, right ?

let
  selectFirst = drv: attrs:
if (empty attrs) then drv else
  if set ? (head attrs) then set.(head attrs) else selectFirst (tail
attrs);
  wrapDerivation = drv: {
out = selectFirst drv ["out"];
dev = selectFirst drv ["dev" "out"];
man = selectFirst drv ["man" "out"];
lib = selectFirst drv ["lib" "dev" "out"];
devdoc = selectFirst drv ["dev" "man" "out"];
  } // drv;
in
  mkDerivarion = drv: wrapDerivation (oldMkDerivation drv);

-- Layus.

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

Re: [Nix-dev] nix-shell is unable to install the package which nix-env just returned

[Guillaume Maudoux (Layus)]

Hmm.. could it be that your system is confused by multiple channels ?

What's the output of (normal user)
$ nix-channel --list

I think your best bet is `nix-shell "" -p letsencrypt`
where nixpkgs is your channel name.

You can even go further and set the nixpkgs path directly using
nix-shell
/nix/store/7kxsv9svwcaxzkxxjg0zxcb151mic8vw-nixos-16.03pre76756.885acea/nixos/nixpkgs
-p letsencrypt

nix-env can also take such a path

To inspect your system state, try to run
$ nix-instantiate --eval --expr --strict ""
$ nix-instantiate --eval --expr --strict ""
$ sudo nix-instantiate --eval --expr --strict ""
$ sudo nix-instantiate --eval --expr --strict ""

 gets evaluated in the context of the current user, so you will
get very different results when using sudo.

To ensure a consistent result, you can also pass the nixpkg tree to
nix-env with option -f.
$ nix-env -qaP -f ""

Now, there is no reason for the attribute returned by `nix-env -f
"" -qaP` to be missing when calling `nix-shell "" -p`
because the nixpkgs are exactly the same.

All this highlights the inconsistency between (and within) the tools.
But that's another story :-).

Layus.

Le 31/03/16 11:25, Dmitry Malikov a écrit :
> >> nix-shell -p nixpkgs.pkgs.letsencrypt
> error: undefined variable ‘nixpkgs’ at (string):1:66
> (use ‘--show-trace’ to show detailed location information)
>
> Any other ideas?
>
> On 31 March 2016 at 10:37, Arseniy Seroka  > wrote:
>
> nix-shell -p nixpkgs.pkgs.letsencrypt
>
> -- 
> Sincerely,
> Arseniy Seroka
>
> On 31 March 2016 02:21:40 Dmitry Malikov  > wrote:
>
>> >> sudo nix-channel --list
>> nixpkgs https://nixos.org/channels/nixpkgs-unstable
>> nixos https://nixos.org/channels/nixos-15.09
>>
>> >> nixos-version
>> 15.09.1180.e8e1cb8 (Dingo)
>>
>> >> nix-env --version
>> nix-env (Nix) 1.10
>>
>> Anything else?
>>
>>> On 31 Mar 2016, at 00:45, Jonn Mostovoy >> > wrote:
>>>
>>> Just worked for me, exactly the same command.
>>> My version of nixpkgs is way older though.
>>>
>>> On Mar 31, 2016 12:40 AM, "Dmitry Malikov"
>>> > wrote:
>>>
>>> >>
>>> nix-env -qaP '*' | grep letsencrypt
>>> nixpkgs.letsencrypt 
>>>
>>> letsencrypt-0.4.0
>>>
>>> >> nix-shell -p letsencrypt
>>> error: undefined variable ‘letsencrypt’ at (string):1:66
>>> (use ‘--show-trace’ to show detailed location information)
>>>
>>>
>>> What am I missing here?
>>>
>>> ___
>>> 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 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] Commit access

[Guillaume Maudoux (Layus)]

Le 29/02/16 18:28, Thomas Tuegel a écrit :
> On Mon, Feb 29, 2016 at 10:29 AM, Eelco Dolstra
>  wrote:
>> Then when you make a PR, you should look up the responsible maintainer and
>> assign the PR to them. Having every PR assigned to somebody should also help
>> prevent them from falling through the cracks.
> 
> If we split up the Nixpkgs repository, GitHub gives us this
> essentially for free. The main Nixpkgs repository has too much noise
> for me to subscribe to updates for Issues and Pull Requests, but it
> would be no problem for me to subscribe to such updates for the subset
> of repositories I maintain. Right now, Domen is doing an excellent job
> of managing the Pull Request and Issue trackers, but ideally, we would
> lift some of this work off him.
> 
> Now, we could easily take a hard line on Pull Request assignment by
> saying, "Your pull request will not be merged if you do not assign the
> correct person!" But, I don't think we want to do the same for Issues;
> it should be as easy as possible to open an Issue. If we split up the
> repository, it's much easier to ensure the correct people see every
> issue and pull request.
> 
> Regards,
> Tom
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
> 

I understand the desire to split the work and the amount of
notifications that such a big repo generates.

But on the other hand, I like the ability to submit a pull-request that
adds a package, a NixOS module and documentation while also bumping the
version of some dependencies. It makes it clear that one bunch of
changes are related.

Having different repos brings the difficulty to make different
pull-requests related to the same idea, and to convince different
maintainers that the change is useful. At best it slows updates as the
pull-request for the module will have to wait for the PR of the package
to be merged. At worst, we could get inconsistent decisions about merging.

The ability to find all the project history in one place is a tremendous
feature for understanding and tracking issues.

It should be easy enough nowadays to filter events based on the changed
paths in a PR, or on the project/feature declared in the issue.
I however agree that it is difficult with the minimal issue tracker
provided by github.

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

Re: [Nix-dev] Systemd User Timers: timerConfig section?

[Guillaume Maudoux (Layus)]

There is also systemd.services..startAt

that creates the timer for you :-).

  systemd.services.urlwatch = rec {
description = "Run urlwatch (${startAt})";
startAt = "hourly";
environment = {
  inherit (config.environment.variables) SSL_CERT_FILE;
};

serviceConfig = {
  User = "layus";
  ExecStart = "${urlwatch}/bin/urlwatch -v";
};
  };


Le 19/02/16 13:22, Christoph Hrdinka a écrit :
> Hi Sergiu,
>
> systemd timers are defined via systemd.timers. (systemwide) or
> systemd.user.timers. (per user) and not within *.services.*.
>
> systemd.timers.timerConfig will be used as verbatim systemd timer
> config as of:
>
> https://www.freedesktop.org/software/systemd/man/systemd.timer.html
>
> Here is an example configuration:
>
> systemd.user.timers.my-task = {
>   description = "run my-task every 5 minutes";
>   wantedBy = [ "timers.target" ]; # enable it & auto start it
>  
>   timerConfig = {
> OnCalendar = "*-*-* *:*/5:00";
>   };
> };
>
> This timer will start my-task.service every 5mins. This means you have
> to add a service as well:
>
> systemd.user.services.my-task = {
>   description = "My Task";
>   script = "echo hello world";
> };
>
> Now systemd will trigger my-task every 5mins. This is however not
> always what you want. Another way of doing this is to tell systemd to
> start the unit, wait for its completion and then start it again after
> 5mins.
>
> systemd.user.timers.my-task = {
>   description = "run my-task every 5 minutes";
>   wantedBy = [ "timers.target" ]; # enable it & auto start it
>  
>   timerConfig = {
> OnBootSec = "5m"; # first run 5min after boot up
> OnUnitInactiveSec = "5m"; # run 5min after my-task has finished
>   };
> };
>
> This timer will trigger reruns 5mins after the last run ended. A
> service of type "simple" (default) will be set to inactive immediately
> after start. If you set it to "oneshot" its activation will last as
> long as the run does:
>
> systemd.user.services.my-task = {
>   description = "My Task";
>   script = "echo hello world";
>   serviceConfig.Type = "oneshot";
> };
>
> You can test this by running `systemctl start my-task`. With "simple"
> it will return immedialtely, with "oneshot" it will return when the
> script exits. You can also mix the service/timer units of the above
> examples to get different behaviours.
>
> Best regards,
> Christoph.
>
> On Fri, 19 Feb 2016 12:11:14 +0100
> Sergiu Ivanov  wrote:
>
>> Hello,
>>
>> I am trying to set up a (custom) systemd timer running a task every
>> 5 minutes.  From what I can see, relying on
>> system.user.services.myTimer might be the way to go, but I can only
>> see the option startAt available, which starts my unit at a given
>> date/time and therefore does not really fit my needs.
>>
>> Is there a way to define other timer attributes?
>>
>> (I looked for timerConfig, which would be similar to serviceConfig or
>> unitConfig, but it doesn't seem to exist.)
>>
>> What is the recommended way to go for such periodic tasks under NixOS?
>> Do you guys all prefer cron?
>>
> ___
> 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] Custom php.ini for cli calls

[Guillaume Maudoux (Layus)]

Hi,

I found a hint on StackOverflow[1], which outlines that php is not the
product of a makeDerivation, but instead is a composableDerivation.
More info on these strange beasts can be found in the source itself[2],
with php being explicitly cited as an exception.
Once you know it, you notice it at the top of php/default.nix :-).

Basically, |overrideDerivation| is not available for php; instead you
have the choice between |merge| and |replace|

This works for me :

|# In .nixpkgs/config.nix : packageOverrides = pkgs: with pkgs; rec {
php70 = pkgs.php70.merge (oldAttrs: { installPhase = '' # use the old
installPhase if need be ${oldAttrs.installPhase} # Add custom stuff echo
"Strange option" >> $iniFile ''; }); }; |

[1]
http://stackoverflow.com/questions/23660797/nix-composable-derivation-options
[2]
https://github.com/NixOS/nixpkgs/blob/master/lib/composable-derivation.nix

Le 04/02/16 15:52, 4levels a écrit :

> Hi Nix Devs,
>
> I'm trying to increase the memory_limit settings for php cli calls.
> For the phpfpm calls I've managed (a few months ago) to append my
> custom options to the php.ini file as the phpfpm service has an option
> to do so.
> However, for php cli calls, the memory_limit value is usually set to
> unlimited, but not with the default config in the nix package: it has
> a value of 128M (instead of the expected -1).  
>
> In the php/default.nix I can see that the ini file is generated in the
> installPhase, but I'm failing to override this.
>
> Do you have any suggestions on how to achieve this?
>
>
> Kind regards,
>
> Erik
>
> Working phpfpm custom ini snippet:
>
> # Custom PHP ini file for apc / memcached
> services.phpfpm.phpIni = pkgs.runCommand "php.ini" {
>   options = ''
> date.timezone = Europe/Brussels
> extension = "${pkgs.phpPackages.apcu}/lib/php/extensions/apcu.so"
> max_execution_time = 30
> post_max_size = 100M
> upload_max_size = 100M
> upload_max_filesize = 20M
> memory_limit = 256M
> apc.enable = 1
>   '';
> }
> ''
>   cat ${pkgs.php}/etc/php-recommended.ini > $out
>   echo "$options" >> $out
> '';
>
>
> ___
> 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] Custom php.ini for cli calls

[Guillaume Maudoux (Layus)]

That being said, you can also start php with the right arguments.
It seems to me that php does not read any configuration file from the
derivation when it starts.

$ php --ini
Configuration File (php.ini) Path:
/nix/store/hr30lz6ziqinsbi525fm9han3lr9nsmj-php-5.6.16/etc
Loaded Configuration File: (none)
Scan for additional .ini files in: /etc
Additional .ini files parsed:  (none)

so you probably need to put your own php.ini file in /etc or call php -c


Nothing to do with the derivation :-).

Layus.

Le 04/02/16 17:14, Guillaume Maudoux (Layus) a écrit :
>
> Hi,
>
> I found a hint on StackOverflow[1], which outlines that php is not the
> product of a makeDerivation, but instead is a composableDerivation.
> More info on these strange beasts can be found in the source
> itself[2], with php being explicitly cited as an exception.
> Once you know it, you notice it at the top of php/default.nix :-).
>
> Basically, |overrideDerivation| is not available for php; instead you
> have the choice between |merge| and |replace|
>
> This works for me :
>
> |# In .nixpkgs/config.nix : packageOverrides = pkgs: with pkgs; rec {
> php70 = pkgs.php70.merge (oldAttrs: { installPhase = '' # use the old
> installPhase if need be ${oldAttrs.installPhase} # Add custom stuff
> echo "Strange option" >> $iniFile ''; }); }; |
>
> [1]
> http://stackoverflow.com/questions/23660797/nix-composable-derivation-options
> [2]
> https://github.com/NixOS/nixpkgs/blob/master/lib/composable-derivation.nix
>
> Le 04/02/16 15:52, 4levels a écrit :
>
>> Hi Nix Devs,
>>
>> I'm trying to increase the memory_limit settings for php cli calls.
>> For the phpfpm calls I've managed (a few months ago) to append my
>> custom options to the php.ini file as the phpfpm service has an
>> option to do so.
>> However, for php cli calls, the memory_limit value is usually set to
>> unlimited, but not with the default config in the nix package: it has
>> a value of 128M (instead of the expected -1).  
>>
>> In the php/default.nix I can see that the ini file is generated in
>> the installPhase, but I'm failing to override this.
>>
>> Do you have any suggestions on how to achieve this?
>>
>>
>> Kind regards,
>>
>> Erik
>>
>> Working phpfpm custom ini snippet:
>>
>> # Custom PHP ini file for apc / memcached
>> services.phpfpm.phpIni = pkgs.runCommand "php.ini" {
>>   options = ''
>> date.timezone = Europe/Brussels
>> extension = "${pkgs.phpPackages.apcu}/lib/php/extensions/apcu.so"
>> max_execution_time = 30
>> post_max_size = 100M
>> upload_max_size = 100M
>> upload_max_filesize = 20M
>> memory_limit = 256M
>> apc.enable = 1
>>   '';
>> }
>> ''
>>   cat ${pkgs.php}/etc/php-recommended.ini > $out
>>   echo "$options" >> $out
>> '';
>>
>>
>> ___
>> 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] [Fixed?] Re: environment in systemd services

[Guillaume Maudoux (Layus)]

Yep. Most probably SSL_CERT_FILE. Look for that string on thé github issues, or 
in the mailing list archives.

Layus.

Le 30 janvier 2016 17:35:17 UTC+01:00, zimbatm  a écrit :
>My guess is that it's probably an environnent variable that's missing
>and
>bash is sourcing the profiles.
>
>On Sat, 30 Jan 2016 17:30 Arnold Krille  wrote:
>
>> Hi all,
>>
>> I kind of fixed it. I played around with the duply config, but that
>> didn't really change anything.
>>
>> Then I went back to getting fcron installed and sending emails. And
>> there I encountered the same problem with the same backtrace with the
>> empty error message!
>>
>> So there seems to be something different between the system
>environment
>> and roots login shell. So I started not `duply amazon status` but
>`bash
>> -l -c "duply amazon status"`, thus running duply in roots login
>shell.
>> And now it works! Both when run in cron and when run in its own
>system
>> service!
>>
>> I am not sure if this is the right solution, but at least I got some
>> backups working now.
>>
>> As soon as I add backups to a local disk I will check again if duply
>> can't run with the system environment…
>>
>> Have fun,
>>
>> Arnold
>>
>> On Sat, 30 Jan 2016 14:34:21 +0100 Arnold Krille
>
>> wrote:
>> > Nope, the aws credentials are in the url given in the config file.
>> >
>> > I also tried setting serviceConfig with options privateTmp=false
>and
>> > privateNetwork=false but these options seem to be for a later
>version
>> > of systemd. I am on stock 15.09 here.
>> >
>> > - Arnold
>> >
>> > (Before anyone asks, the backup is encrypted and only the public
>part
>> > of the gpg key is present on the server.)
>> >
>> > On Sat, 30 Jan 2016 13:27:52 + zimbatm 
>> > wrote:
>> > > Did you try to pass the AWS keypair trough an environment
>> > > variable ? I don't know it that would fix it but it's a 3rd
>> > > solution, not having access to the right keys.
>>
>> ___
>> 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 mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Going through hell with systemd timers

[Guillaume Maudoux (Layus)]

Hi,

My experience with urlwatch was that the SSL_CERT_FILE env var was missing.
This may also be your issue if you are using the network.

It is however always possible to run the service manually, and see the logs.
A service declaration with a startAt attribute creates two services,
.service and .timer.
You can start your service with |# systemctl start .service|
and see the logs in journald.
(No need to wait for the timer.)

I made urlwatch work with the following snippet :

|systemd.services.urlwatch = rec { description = "Run urlwatch
(${startAt})"; startAt = "hourly"; environment = { inherit
(config.environment.variables) SSL_CERT_FILE; }; serviceConfig = { User
= "layus"; # should use a user unit... ExecStart =
"${urlwatch}/bin/urlwatch -v"; }; }; |

For debugging, I used:
|# systemctl start urlwatch.service| : Start the service once.
|$ systemctl status urlwatch.service -l -n 1000| : See the systemd logs
for the last run, up to 1000 full lines.
|# journalctl -xef --unit=urlwatch| : Print all the logs, -f follows the
output in real time.

A very simple trick is indeed to dump the environment at the start of
the script.

Layus.

Le 28/01/16 10:59, 4levels a écrit :

> Hi Zimbatm (is that your name :-)
>
> I'm currently trying to debug by using printenv to view the
> differences in both environments.  I'm not yet familiar with using
> nix-shell :-s
> But since I cannot even deploy or rebuild switch anymore (see my other
> email to this list) I'm pretty stuck.
>
> I'm currently repartitioning and reinstalling the Vultr machines
> (*sigh*) to see if that brings any changes..
>
> Thank you for your pointer to the environment vars!
>
> Erik
>
> On Thu, Jan 28, 2016 at 10:56 AM zimbatm  > wrote:
>
> One common error with system services are missing environment
> variable. When testing with your shell you will have $HOME set for
> example.
>
>
> On Thu, 28 Jan 2016 09:43 4levels <4lev...@gmail.com
> > wrote:
>
> Hi Exi,
>
> thank you for your reply.
>
> This is the timers config I'm using (note that I'm starting
> this every 5 minutes to troubleshoot, is supposed to run every
> 2 hours or so)
>
> backup = {
>   description = "Backup service";
>   after = [ "network.target" "mysql.target" ];
>   path = [ pkgs.procps pkgs.gawk pkgs.nettools pkgs.mysql pkgs.php 
> pkgs.duplicity pkgs.postfix ];
>   script =
>   ''
>   ./s3Backup.sh
>   '';
>   startAt = "*-*-* *:0/5:00";
>
>
>
> And the contents of the s3Backup.sh script:
>
> s3Backup = name:
>   ''
> #!${pkgs.bash}/bin/bash
>
> ${builtins.readFile ./src/envrc}
>
> # Your GPG key
> GPG_KEY=
>
> # export 
> PATH="$PATH:/var/setuid-wrappers:/run/current-system/sw/bin:/run/current-system/sw/sbin"
>
> # Set up some variables for logging
> LOGFILE="/var/lib/projects/${name}/log/duplicity-backup.log"
> 
> DAILYLOGFILE="/var/lib/projects/${name}/log/duplicity-backup.daily.log"
> 
> FULLBACKLOGFILE="/var/lib/projects/${name}/log/duplicity-backup.full.log"
> HOST=`hostname`
> DATE=`date +%Y-%m-%d`
> MAILADDR="d...@domain.com "
> TODAY=$(date +%d%m%Y)
>
> # The S3 destination followed by bucket name
> DEST="s3://s3.amazonaws.com/projects-backup-eu-west/${name}
> "
>
> is_running=$(ps -ef | grep duplicity  | grep python | wc -l)
>
> if [ ! -f $FULLBACKLOGFILE ]; then
>   touch $FULLBACKLOGFILE
> fi
>
> if [ $is_running -eq 0 ]; then
>   # Clear the old daily log file
>   cat /dev/null > ''${DAILYLOGFILE}
>
>   # Trace function for logging, don't change this
>   trace () {
> stamp=`date +%Y-%m-%d_%H:%M:%S`
> echo "$stamp: $*" >> ''${DAILYLOGFILE}
>   }
>
>   # Dump $PATH
>   trace "Current PATH: $PATH"
>
>   # How long to keep backups for
>   OLDER_THAN="1M"
>
>   # The source of your backup
>   SOURCE=/var/lib/projects/${name}
>
>   FULL=
>   tail -1 ''${FULLBACKLOGFILE} | grep ''${TODAY} > /dev/null
>   if [ $? -ne 0 -a $(date +%d) -eq 1 ]; then
> FULL=full
>   fi;
>
>   trace "Backup for local filesystem started"
>
>   trace "... removing old backups"
>
>   duplicity remove-older-than ''${OLDER_THAN} ''${DEST} 
> --s3-use-new-style >> ''${DAILYLOGFILE} 2>&1
>
>   trace "... backing up filesystem"
>
>   duplicity \
> 

Re: [Nix-dev] Best way to store strong passwords in nix configuration file

[Guillaume Maudoux (Layus)]

I am not sure I understand your issue.

On my side, I have

|$ cat test.nix rec { a = "ETrai_5{h'aG,MQ"; b = "${a}${a}"; } $
nix-instantiate --eval --strict test.nix { a = "ETrai_5{h'aG,MQ"; b =
"ETrai_5{h'aG,MQETrai_5{h'aG,MQ"; } |

Could it just happen that you forgot a semicolon at the end of your
strings ?

Could you provide a minimal (non) working example :-)

G.

Le 12/01/16 16:48, 4levels a écrit :

> Hi Nix Devs,
>
> I'm really struggling to get strong passwords correctly parsed in my
> nix configuration files.  I keep getting errors about unexpected $end
> or $undefined at wrong places (eg. there is no $ or ; anywhere near
> the reported failure).
> Deleting the passwords from the nix config file solves this, so the
> error is definitely related to the contents of these strings.
>
> I'm using a random password generator to create strong passwords, like
> ETrai_5{h'aG,MQ:
> I've tried writing them with double quotes, double single quotes and
> single quotes, with and without escaping, all to no avail.  I also
> can't seem to find a list of the characters that should be escaped (I
> only see " and \ and those are not in those passwords.
>
> Do you have any tips on how to store many different strong password
> and use it in nix configuration files?  I need those passwords to be
> in an object structure so I can build custom config files from them.
>
> For the record, I'm using git-crypt to prevent these files from being
> read by unauthorized clients / people
>
> Kind regards,
>
> Erik
>
>
> ___
> 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] sonarQube package

[Guillaume Maudoux (Layus)]

Le 12/01/16 06:40, Bjørn Forsman a écrit :
>
> On Jan 12, 2016 00:27, "Augustin Borsu"  > wrote:
> >
> > Hello,
> >
> > I'm a bit stuck so I thought I would try and ask the community if
> any one has an idea.
> > I'm trying to make a package to run SonarQube on a nixos server and
> so far I"ve gotten this far :
> ...
> > But now I have a very cryptic file not found error when I try to
> launch the ./bin/wrapper file that is supposed to launch it all.
>
> I guess the binary still refers to /lib/ld-linux.so (or something) as
> its interpreter. What you want is patchelf. See examples in nixpkgs repo.
>
./bin/wrapper is indeed a precompiled executable.
You will find more explanations on how to use patchelf in
https://nixos.org/wiki/How_to_package_closed-source_software

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

Re: [Nix-dev] Some hints for Perl -> C++ translation?

[Guillaume Maudoux (Layus)]

Le 06/01/16 12:59, Mateusz Czaplinski a écrit :
>
>
> On Mon, Jan 4, 2016 at 9:22 AM, Vladimír Čunát  > wrote:
>
> >   - how I might try to setup a dev environment for that, ideally in 
> NixOS?
> I think ./dev-shell is meant exactly for that.
>
>
> Thanks!
> So, I should expect something like below to work in "pristine NixOS
> with Internet connectivity", yes?
>
> $ ./dev-shell # runs bash in the new env, I assume
> $ ./configure && make && make check
> $ ./bin/nix-env --this-and-that-or-else

More or less.
See http://nixos.org/nix/manual/#chap-hacking.

The commands described there should create a "./inst" folder and install
the new nix within.
You can then call ./inst/bin/nix-* --options...
 
>
> >   - where in the codebase can I find some "main entry point" to
> "core
> > nix functionalities"?
>
> I'd think that's not a good approach to take. What's written in
> perl are
> mainly facade-like wrappers and utilities.
>
> >   - what would you suggest I start translating first? (which .pm
> files)
> > I'm open to all suggestions, including "hard but very useful"
> ones, as
> > well as "easy but close to useless".
>
> *.pm seem for usage by perl stuff (per/lib/Nix/*.pm), so it should be
> possible to completely ignore those. I suppose you know this overview
> list https://github.com/NixOS/nix/issues/341#issuecomment-58743265
>
> I think the most called ones are download-from-binary-cache.pl.in
> ,
> nix-build, and buildenv.pl . Maybe best start
> with some script that you
> (think) you understand best. From portability perspective, most of
> them
> will need to get ported to achieve the goal.
>
>
> Ok, thanks for all the hints and information. Nice overview, gives me
> some much needed perspective.
>
> Thanks,
> /Mateusz.
>
>
> ___
> 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] Letsencrypt in open beta.

[Guillaume Maudoux (Layus)]

Hi,

Now that Let’s Encrypt[1] is in open beta, I would like to try it on my
server.
Has someone sucessfully used it on a NixOS server ?

I have seen that Domen Kožar pushed the realted python tools on nixpkgs[2].
Is someone working on integrating this tool into NixOS ?

Regards,

Guillaume (layus).

[1] https://letsencrypt.org/
[2]
https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/admin/letsencrypt/default.nix
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] How to write module outside the nixpkgs tree and integrated with nixos-rebuild

[Guillaume Maudoux (Layus)]

This is not the first time this question arises on the mailing list.

Where did you expect to find this information in the docs ?
This may be the ideal place to add the info.

G.

Le 04/12/15 06:18, rohit yadav a écrit :
> Thanks! This is exactly I was looking for. I should have looked more
> before posting this query.
>
> --
> Rohit
>
> On Thu, Dec 3, 2015 at 10:14 PM, Игорь Пашев  > wrote:
>
> 2015-12-04 6:12 GMT+03:00 rohit yadav  >:
> > Hi,
> >
> > How to write a NixOS module that is outside the nixpkgs tree and
> integrate
> > it with nixos-rebuild. I particularly want to define few
> services which
> > should be run in a particular order. I believe I can define them
> directly in
> > /etc/systemd/system folder (but this defeats the purpose of nix).
> >
>
> Use imports = [  ]; in /etc/nixos/configuration.nix
>
> https://nixos.org/wiki/NixOS:extend_NixOS
>
>
>
>
> ___
> 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] nix-build -A builds everything

[Guillaume Maudoux (Layus)]

Hi,

The problem is that you build odoo within the nixpkgs defined by the
master branch.
As the master branch defines derivations more recent than the ones
installed, it needs to instantiate them.
But these derivations are so new that even hydra did not build them yet,
so you have no binary support for these.

To get binary support, you should develop on a branch based on the same
commit as you current channel.
See
https://nixos.org/wiki/Create_and_debug_nix_packages#Tracking_upstream_changes_and_avoiding_extra_rebuilding
for extra details and  step-by-step commands.

Does it answer your question or did I miss the point ?

Le 17/11/15 00:03, Dieter Vekeman a écrit :
> Hi
>
> I’m trying to create a nix package (for the odoo suite 
> https://github.com/odoo/odoo/tree/8.0).
>
> I checked out nixpkgs
> created a folder in pkgs/applications/networking/odoo
>
> This is what I have so far
> # cat ./pkgs/applications/networking/odoo/default.nix
> { stdenv, fetchurl, buildPythonPackage, pythonPackages }:
>
> buildPythonPackage {
>   name = "odoo-8.0.0";
>   namePrefix = "";
>
>   src = fetchurl {
> url = "https://github.com/odoo/odoo/archive/8.0.0.zip;;
> sha256 = 
> "dee5ca67cd314c389fe3fb924c1fc6ba84a913b60956bd0308344e9c0e0cb751";
>   };
>
>   propagatedBuildInputs = [ ];
>
>   # Testing fails.
>   doCheck = false;
>
>   meta = {
> description = "Odoo ERP / CRM business suite";
> homepage = https://www.odoo.com;
> license = stdenv.lib.licenses.agpl3;
>   };
> }
>
> When I run
> nix-build -A odoo
>
> It seems to start building everything from source, is that normal?
>
> I don’t know what kind of info is required but here are a few things
> # nix-channel --list
> nixpkgs https://nixos.org/channels/nixpkgs-unstable
> nixos https://nixos.org/channels/nixos-14.12
>
> # echo $NIX_PATH
> /nix/var/nix/profiles/per-user/root/channels/nixos:nixpkgs=/etc/nixos/nixpkgs:nixos-config=/etc/nixos/configuration.nix
>
> /etc/nixos/nixpkgs points to /src/nixpkgs where I have my clone of nixpkgs
>
> # nix-build -A odoo
> these derivations will be built:
>   /nix/store/4f93r775pgxccqiw2y999bhz84irqdi5-xz-5.2.2.drv
> …
>   /nix/store/rpa6hx6wi0l40w6q21ia6g8nd655h2hr-gcc-4.9.3.drv
>   /nix/store/a1618x2806slj88gyxc944v0xhc84j6f-gcc-wrapper-4.9.3.drv
>   /nix/store/i811yml1yxa6grhhx1glld79fs7j5vc2-stdenv-linux-boot.drv
> … etc.
>
> Thanks!
>
> ___
> 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] nix-build -A builds everything

[Guillaume Maudoux (Layus)]

Hi,

Neat trick.

Am I right however to say that this does not work if your own channel is
not up to date.
Nothing forces branch channels/nixos-unstable on
github.com/NixOS/nixpkgs-channels to point at the same revision as the
one in /nix/var/nix/profiles/per-user/root/channels/nixos/svn-revision.

As for me, I update my tag on the current channel revision after each
update, and branch/rebase on top of it.

I will update the wiki to reference the manual.

Le 19/11/15 15:50, Eelco Dolstra a écrit :
> Hi,
>
> On 19/11/15 11:46, Guillaume Maudoux (Layus) wrote:
>
>> To get binary support, you should develop on a branch based on the same
>> commit as you current channel.
>> See
>> https://nixos.org/wiki/Create_and_debug_nix_packages#Tracking_upstream_changes_and_avoiding_extra_rebuilding
>> for extra details and  step-by-step commands.
> There is an easier way than described on the wiki, namely by using the
> nixpkgs-channels repository, which contains branches corresponding to the
> current channel contents.
>
> For instance, to create a branch named "local" based on the latest
> nixos-unstable channel:
>
> $ git remote add channels git://github.com/NixOS/nixpkgs-channels.git
> $ git remote update channels
> $ git checkout -b local channels/nixos-unstable
>
> and to update it:
>
> $ git remote update channels
> $ git merge channels/nixos-unstable # or "git rebase"
>
> See http://nixos.org/nixos/manual/index.html#sec-getting-sources for more 
> info.
>

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

Re: [Nix-dev] Help with setup php xdebug

[Guillaume Maudoux (Layus)]

Dear Erik,

I am no expert on this topic, but it seems to me that writing a custom 
phpIni is the way to go.
For example, I have the following code in my config, which mimics the 
default phpIni generation.

   phpIni = pkgs.runCommand "php.ini"
 {
   options = ''
extension=${pkgs.phpPackages.imagick}/lib/php/extensions/imagick.so
 max_execution_time = 30
 post_max_size = 100M
 upload_max_size = 100M
 upload_max_filesize = 20M
 memory_limit = 256M
   '';
 }
 ''
   cat ${pkgs.php}/etc/php-recommended.ini > $out
   echo "$options" >> $out
 '';

It would not be the NixOS way to allow a newly installed package to 
modify the behaviour of another package.
What if using the new extension suddenly breaks another server ?
In fact, if PHP needs to be modified and rebuilt with php-xdebug as a 
dependency to account for it.
(Of course, PHP could also load all the extensions in 
/var/lib/php/extensions of such, but that is precisely what NixOS tries 
to avoid.)

Still, I agree that the phpIni creation could be turned into an helper 
(maybe pkgs.php.customPhpIni {extraOptions = ''...'';}).

Best regards,
Guillaume.

PS: This is just one instance of a larger problem.
For example, newly installed latex packages are expected to be 
accessible to pdflatex right after their install.
But this means that pdflatex needs to be modified and rebuilt to account 
for the new dependency ;-).


Le 29/09/15 09:52, 4levels a écrit :
> Dear Nix Devs,
>
> I'm somewhat struggling to enable the php-xdebug extension in php.
> I did manage to get the extension installed but the php interpreter 
> itself seems to ignore its existence.
>
> I did find some topics on this and as a workaround I could specify a 
> custom php-ini file but I was wondering if there is no better way.  
> Shouldn't just installing the php-package xdebug also enable it by 
> default?
>
> I'm not using apache but nginx with php-fpm as webserver so the httpd 
> options seem unusable.  I also can't seem to add options to php in the 
> php-fpm pool config, to load the extension and set some xdebug params.
>
> Any advice on how to go about this?  I'd love to see php compiled with 
> xdebug so I can use the phpunit code coverage reports.
>
> So php with xdebug - how to?
>
> Kind regards,
>
> Erik
>
>
> ___
> 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] Help with setup php xdebug

[Guillaume Maudoux (Layus)]

Hi Erik,

AFAIK, that should be enough and your setup should be correct.
How do you know phpfpm does not use your file ?

You can use `systemctl cat phpfpm.service` to see what command is used 
to start phpfpm and what php.ini file is used.


Guillaume.

Le 29/09/15 14:50, 4levels a écrit :

Hi Guillaume,

I've tried adding your approach to the phpfpm config as follows and a 
php.ini file is now being generated in the store with the added values 
from the function call, great!
I just don't see at the moment how I can tell phpfpm to use that file 
instead of the default php-recommend.ini.  I'm pretty sure I'm 
overlooking something, hopefully someone here spots the issue easily ;-)


This is what I have in /etc/nixos/configuration.nix

  ...

  # PHP FPM
  services.phpfpm.phpIni = pkgs.runCommand "php.ini" {
options = ''
  date.timezone = Europe/Brussels
  extension = 
"${pkgs.phpPackages.xdebug}/lib/php/extensions/xdebug.so"

  max_execution_time = 30
  post_max_size = 100M
  upload_max_size = 100M
  upload_max_filesize = 20M
  memory_limit = 256M
  xdebug.remote_enable = true
  xdebug.remote_host = 127.0.0.1
  xdebug.remote_port = 9000
  xdebug.remote_handler = dbgp
  xdebug.profiler_enable = 0
  xdebug.profiler_output_dir = "/tmp/xdebug"
  xdebug.remote_mode = req
'';
  }
  ''
cat ${pkgs.php}/etc/php-recommended.ini > $out
echo "$options" >> $out
  '';

  services.phpfpm.poolConfigs = { ...

On Tue, Sep 29, 2015 at 1:14 PM 4levels <4lev...@gmail.com 
<mailto:4lev...@gmail.com>> wrote:


Hi Guillaume,

Thanks for your reply and hint on regenerating the php.ini file,
I'l try that right away.
I do see the issues with what you described in other packages
being modified by installing a subpackage, but isn't that normal
in a dependency relation between php and xdebug?  How do the other
php packages accomplish this? Eg. the same goes for apcu as well:
the package can be installed and configured but is never being
used by php (neither in cli or via fpm).

Providing a hook into the phpIni generation definitely looks like
the way to go to me.  This could then be used in the various php
packages that need php.ini options to be adjusted.

For clarification: I'm nowhere near even understanding how nixos
works, let alone write my own packages, I'm just trying to setup a
valid configuration for an nginx / phpfpm / lumen/laravel server..
 so it's very possible that I'm making wrong assumptions!

Kind regards et merci beaucoup,

    Erik

On Tue, Sep 29, 2015 at 10:25 AM Guillaume Maudoux (Layus)
<layus...@gmail.com <mailto:layus...@gmail.com>> wrote:

Dear Erik,

I am no expert on this topic, but it seems to me that writing
a custom
phpIni is the way to go.
For example, I have the following code in my config, which
mimics the
default phpIni generation.

   phpIni = pkgs.runCommand "php.ini"
 {
   options = ''
extension=${pkgs.phpPackages.imagick}/lib/php/extensions/imagick.so
 max_execution_time = 30
 post_max_size = 100M
 upload_max_size = 100M
 upload_max_filesize = 20M
 memory_limit = 256M
   '';
 }
 ''
   cat ${pkgs.php}/etc/php-recommended.ini > $out
   echo "$options" >> $out
 '';

It would not be the NixOS way to allow a newly installed
package to
modify the behaviour of another package.
What if using the new extension suddenly breaks another server ?
In fact, if PHP needs to be modified and rebuilt with
php-xdebug as a
dependency to account for it.
(Of course, PHP could also load all the extensions in
/var/lib/php/extensions of such, but that is precisely what
NixOS tries
to avoid.)

Still, I agree that the phpIni creation could be turned into
an helper
(maybe pkgs.php.customPhpIni {extraOptions = ''...'';}).

Best regards,
Guillaume.

PS: This is just one instance of a larger problem.
For example, newly installed latex packages are expected to be
accessible to pdflatex right after their install.
But this means that pdflatex needs to be modified and rebuilt
to account
for the new dependency ;-).


Le 29/09/15 09:52, 4levels a écrit :
> Dear Nix Devs,
>
> I'm somewhat struggling to enable the php-xdebug extension
in php.
> I did manage to get the extension installed but the php
interpreter
> itself seems to

Re: [Nix-dev] Logo improvement ideas

[Guillaume Maudoux (Layus)]

Tim has invested some time in making great logos, and everybody seems to 
like the hex-half version.

It would be too sad to loose his job, so what is the next step ?
Who is authorized to do such a modification ?

Brand nex NixOS logo !

We can tune the logo for other media later, when we print t-shirts for 
example.


Just my two cents :-)

Le 26/08/15 03:28, Spencer Whitt a écrit :
All of the logos Tim has proposed look like clear improvements over 
the current one to me. I think we should just pick one and use it! 
There's no downside to adopting one of these logos, since they 
maintain the same basic design as the current one but with cleaner, 
modernized design.


I think we should avoid bikeshedding and turning this into some 
massive project. It doesn't need to be perfect, it just needs to be an 
improvement.


It makes sense to pick two logos, one which is print friendly and one 
which is not. There's no reason to constrain other media to be print 
friendly, and I think the subtle gradients are a nice touch.


On Tue, Aug 25, 2015 at 9:07 PM, stewart mackenzie > wrote:


Personally I really like what the current logo communicates to me:

* lambdas, lots of them
* snowflake - a unique system

I'm enjoying these logos!

/sjm

On 26 Aug 2015 00:16, "Cillian de Róiste"
>
wrote:
> 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?
>


___
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 mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Automount for usb thumb drives / other external drives

[Guillaume Maudoux (Layus)]

Hi,

Le 16/07/15 13:58, Eelco Dolstra a écrit :
 Hi,

 On 15/07/15 23:22, Paul Koerbitz wrote:

 I would like to automatically mount usb sticks that I plug into my
 laptop. I haven't been able to figure out how to do this in NixOS,
 what's the easiest option?
 The standard mechanism used for dealing with removable media is udisks, used 
 by
 desktop environments like KDE and Xfce to allow non-root users to mount disks.
 It can also be used from the command-line, e.g.

$ udisksctl mount -b /dev/sdb1
Mounted /dev/sdb1 at /run/media/eelco/USBSTICK.

 Udisks doesn't mount disks automatically on insertion, but this could be done 
 by
 having a script that listens for the D-Bus messages sent by udisks and then 
 asks
 udisks to do the mount. In fact, there already is a package that does this:

https://github.com/fernandotcl/udisks-glue

 but it's not in Nixpkgs yet.

There is also the excellent udevil[1] tool that comes with devmon,
a monitoring and automonting daemon.
But udevil is not yet in nixpkgs either.

[1] http://ignorantguru.github.io/udevil/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev