Any reason you are not using systemd triggers? Works the same as cron and log
output is redirected to journald.
N.
-Original Message-
From: "M. P. Ashton"
Sent: 10/16/2014 2:32 AM
To: "nix-dev"
Subject: Re: [Nix-dev] Crontab and mail / ssmtp troubles
Thanks, I'll try to find that d
Thanks, I'll try to find that discussion.
This was on the stable branch; maybe it's different in the git head?
On Wed, Oct 15, 2014, at 04:12 PM, Luca Bruno wrote:
> There was some discussion about this. The problem is probably a missing
> /var/spool for each user, or anyway something about permi
Regarding the network/network-uri split, tibbe has promised to backport
things to 2.5.
https://github.com/haskell/network/commit/fba98d81bf733bb769316b86b6675011165e59f0#commitcomment-7996263
Alexander
On Wed, Oct 15, 2014 at 9:27 PM, John Wiegley wrote:
> This message is a follow-on to a disc
There was some discussion about this. The problem is probably a missing
/var/spool for each user, or anyway something about permissions. I've
tracked down the issue once but never worked on it since I wasn't directly
interested on it.
On Wed, Oct 15, 2014 at 10:07 PM, M. P. Ashton wrote:
> I'm h
I'm having trouble getting a rather simple crontab running on a new
NixOS installation.
The crontab is supposed to run a shell script in a user account. It
doesn't work. So I tried just having it run "echo test". That got me
this in the journal:
Oct 15 15:54:01 bode cron[22272]: (mpashton) CMD (e
This message is a follow-on to a discuss Peter and I were having on GitHub,
since I believe it is of more general interest:
>> Peter Simons writes:
> Generally speaking, the two goals
>
> 1. have recent versions of all major Haskell packages and
> 2. all Haskell packages should compile
>
hi, I'd like introduce my idea, and wait for feedback.
see my latest comment in PR #4493 for code.
what I do is:
callPackageModule, a new function to define package.
using evalModules combined with a package module and config.nix
to get derivation, the customized package.
make config.nix
>Note that this proposal:
>
>* reuses packages built for different environments (packages outputs
> stay the same between boxes, it's boxes that change),
>* doesn't generate a ton of wrappers by generating a wrapper for every
> single package,
>* gives a somewhat natural way to decide which optio
Hi,
What would you say about the following idea:
(important lines in the following boiler-plate are marked with "!!!")
1) Package maintainers write something like
# packages jack and alsa-plugins need to configure for each other or
# else starting jack will seizure the default sound output and a
