New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
initial NixOS module for LIRC #32045
Conversation
system.activationScripts.lirc = '' | ||
umask 027 | ||
mkdir -p /var/run/lirc | ||
chown -R lirc:lirc /var/run/lirc |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no need for -R
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are a few things here:
- the mkdir/chown lines can be combined using
install
instead, but - it's superfluous as the /run/lirc directory will be automatically created by the
ListenStream
bit on your socket configuration refman systemd.socket
.
description = "LIRC"; | ||
wantedBy = [ "sockets.target" ]; | ||
socketConfig = { | ||
ListenStream = "/var/run/lirc/lircd"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use /run/lirc/lircd
.
|
||
extraArguments = mkOption { | ||
type = types.str; | ||
default = ""; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Make this a list, like this:
nixpkgs/nixos/modules/services/misc/zookeeper.nix
Lines 94 to 99 in 898aedc
extraCmdLineOptions = mkOption { | |
description = "Extra command line options for the Zookeeper launcher."; | |
default = [ "-Dcom.sun.management.jmxremote" "-Dcom.sun.management.jmxremote.local.only=true" ]; | |
type = types.listOf types.str; | |
example = [ "-Djava.net.preferIPv4Stack=true" "-Dcom.sun.management.jmxremote" "-Dcom.sun.management.jmxremote.local.only=true" ]; | |
}; |
unitConfig.Documentation = [ "man:lircd(8)" ]; | ||
|
||
serviceConfig = { | ||
ExecStart = "${pkgs.lirc}/bin/lircd --nodaemon ${cfg.extraArguments} ${configFile}"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use escapeShellArgs
:
${escapeShellArgs cfg.extraCmdLineOptions} \ |
Thanks! I introduces all your good suggestions. |
description = "LIRC default options (lirc_options.conf)"; | ||
}; | ||
|
||
config = mkOption { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where is config
used?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for review. I updated the description to clarify the option. The content is written into a file, which is passed to lircd as configuration.
mkdir -p /run/lirc | ||
chown lirc:lirc /run/lirc | ||
fi | ||
''; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are a few things here:
- the mkdir/chown lines can be combined using
install
instead, but - it's superfluous as the /run/lirc directory will be automatically created by the ListenStream bit on your socket configuration ref man systemd.socket.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The folder is created to grant lircd write access. It creates a pid file and removes for any reason the socket.
I tried to follow your hints:
- I replace it with "install -o vdr -g vdr -m 0750 -d /run/lirc", but for any reason, the folder is owned by root?!
- If systemd creates the folder, the owner is root. So I used ExecStartPost to change the owner, which is to late for any reason?!
Thanks for your review, but I do not find an alternative solution.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since lirc.socket
creates the directory, my guess is that it overrides what you are doing in the .service.
You probably need to set the following in the .socket definition instead:
DirectoryMode = "750";
SocketUser = "lirc";
SocketGroup = "lirc";
Then you can get rid of the script.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
man systemd.socket
is your friend.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your suggestions, but
- SocketUser is already set,
- SocketGroup is not needed, because Systemd takes the primary group of user given at SocketUser
- DirectoryMode is by default 755, which is good enough.
Lircd needs to be owner (or at least "create rights") on the folder /run/lirc.
I removed socket activation at all, because I could not setup a working environment. |
After playing around with the new lirc-0.10.0 and making sure that no service depends on lircd.service, I could get it working. |
unitConfig.Documentation = [ "man:lircd(8)" ]; | ||
|
||
serviceConfig = { | ||
ExecStartPre = "${pkgs.coreutils}/bin/install -o lirc -g lirc -m 750 -d /run/lirc"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be RuntimeDirectory = "lirc";
instead
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, it fits perfectly. I updated PR.
I have been converting a number of services to use
Does this still work on your side? It should be perfectly fine with socket activation ref http://0pointer.net/blog/dynamic-users-with-systemd.html |
Interesting concept, but I could not fulfill following security requirements:
|
Who would be a member of the group that can write to the socket? Currently logged in user or something else? |
Yes, a logged in user could be a use-case. |
Can we revive this? Conflicts are trivial to resolve. We can merge without |
I would appreciate. PR has been updated and is ready for merge. |
@peterhoeg What do you think, can we merge as is? |
Thanks for this - I was just about to write my own version of it when I saw this PR. Someone should update https://nixos.wiki/wiki/LIRC Did you test this thoroughly? For me the |
Hi Ben,
I didn't know, that we have an wiki article about LIRC
I never stopped lircd, but now I see the problem. RuntimeDirectory removes the folder, when lircd is stopped.
Could you please add
RuntimeDirectoryPreserve = true;
into serviceConfig and retest it.
RuntimeDirectory is needed to get access rights on /run/lirc for lirc:lirc.
Best regards
Christian
Gesendet: Dienstag, 18. September 2018 um 04:29 Uhr
Von: "Ben Wolsieffer" <notifications@github.com>
An: NixOS/nixpkgs <nixpkgs@noreply.github.com>
Cc: "Christian Kögler" <ck3d@gmx.de>, Author <author@noreply.github.com>
Betreff: Re: [NixOS/nixpkgs] initial NixOS module for LIRC (#32045)
Thanks for this - I was just about to write my own version of it when I saw this PR. Someone should update https://nixos.wiki/wiki/LIRC
Did you test this thoroughly? For me the RuntimeDirectory option seems to cause the socket to be deleted when the service starts. It allows one connection but then stops working because the socket no longer exists. Changing the RuntimeDirectory fixes it. We can probably just drop that option altogether.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Also, the original problem with Some alternatives I can think of are to store the socket somewhere else, prevent lircd from creating a PID file (I don't think there is an option for this), or manually set the permissions on the directory in an |
On my environment /run/lirc is changed by lircd.service during start. And since RuntimeDirectoryPreserve not delete any more. I used irw for testing lircd.
I do not understand why our systems behave differently.
My first proposal of that PR used ExecStartPre to create and chown the folder. A reviewer proposed the option RuntimeDirectory.
The path /run/lirc/lircd is default, so I think we should not change it.
Am 18. September 2018 22:22:52 MESZ schrieb Ben Wolsieffer <notifications@github.com>:
…`RuntimeDirectoryPreserve` does not fix the problem, because
`/run/lirc` is owned by root when it is created by the `lircd.socket`
unit, and the ownership does not get changed to `lirc:lirc` when
`lircd.service` starts, so lircd is unable to write the PID file there.
If I put the PID file somewhere else, it works correctly (but then
there is no reason to use `RuntimeDirectory` in the first place). It
seems like systemd is not designed to store the socket in the
`RuntimeDirectory`.
Also, the original problem with `RuntimeDirectory` was not that the
directory is deleted when `lircd.service` stops, but that it appears to
be deleted and recreated before the service starts. When a connection
is received on the socket, the `lircd.service` is started, `/run/lirc`
is recreated and systemd passes the file descriptor of the socket to
`lircd`. This allows it to respond to one connection, but the next
fails because the socket was deleted.
Some alternatives I can think of are to store the socket somewhere
else, prevent lircd from creating a PID file (I don't think there is an
option for this), or manually set the permissions on the directory in
an `ExecStartPre` script.
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#32045 (comment)
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
|
This reproduces the problem on my system:
If I manually start |
Hi Ben,
I did the same on my side. irsend never returned an error. The journal tells following:
# systemctl stop lircd.socket lircd.service
Sep 19 21:46:14 ws10 systemd[1]: Closed LIRC daemon socket.
Sep 19 21:46:14 ws10 systemd[1]: Stopping LIRC daemon service...
Sep 19 21:46:14 ws10 lircd-0.10.1[1735]: Notice: caught signal
Sep 19 21:46:14 ws10 lircd[1735]: lircd-0.10.1[1735]: Notice: caught signal
Sep 19 21:46:14 ws10 systemd[1]: Stopped LIRC daemon service.
# systemctl start lircd.socket
Sep 19 21:46:41 ws10 systemd[1]: Starting LIRC daemon socket.
Sep 19 21:46:41 ws10 systemd[1]: Listening on LIRC daemon socket.
# irsend send_once harmony_kls_vdr_1.6 Up
Sep 19 21:46:56 ws10 irsend[2175]: lirc_command_run: Sending: send_once harmony_kls_vdr_1.6 Up
Sep 19 21:46:56 ws10 systemd[1]: Started LIRC daemon service.
Sep 19 21:46:56 ws10 lircd-0.10.1[2176]: Info: lircd: Opening log, level: Info
Sep 19 21:46:56 ws10 lircd-0.10.1[2176]: Notice: Version: lircd 0.10.1
Sep 19 21:46:56 ws10 lircd-0.10.1[2176]: Notice: System info: Linux ws10 4.14.70 #1-NixOS SMP Sat Sep 15 07:45:37 UTC 2018 x86_64 GNU/Linux
Sep 19 21:46:56 ws10 lircd-0.10.1[2176]: Info: Initial device: product=0x6015
Sep 19 21:46:56 ws10 lircd-0.10.1[2176]: Info: Initial device: product=0x6015
Sep 19 21:46:56 ws10 lircd[2176]: lircd-0.10.1[2176]: Info: lircd: Opening log, level: Info
Sep 19 21:46:56 ws10 lircd[2176]: lircd-0.10.1[2176]: Notice: Using systemd fd
Sep 19 21:46:56 ws10 lircd[2176]: lircd-0.10.1[2176]: Info: Using remote: harmony_kls_vdr_1.6.
Sep 19 21:46:56 ws10 lircd-0.10.1[2176]: Notice: Options: driver: ftdi
Sep 19 21:46:56 ws10 lircd-0.10.1[2176]: Notice: Options: output: /var/run/lirc/lircd
Sep 19 21:46:56 ws10 lircd[2176]: lircd-0.10.1[2176]: Notice: lircd(ftdi) ready, using /var/run/lirc/lircd
Sep 19 21:46:56 ws10 lircd[2176]: lircd-0.10.1[2176]: Notice: accepted new client on /var/run/lirc/lircd
Sep 19 21:46:56 ws10 lircd[2176]: lircd-0.10.1[2176]: Info: Initializing FTDI: product=0x6015
Sep 19 21:46:56 ws10 lircd-0.10.1[2176]: Notice: Options: nodaemon: 1
Sep 19 21:46:56 ws10 lircd-0.10.1[2176]: Notice: Options: plugindir: /nix/store/igydwyvngdarn0qhpn0byc93gxh1avqr-lirc-0.10.1/lib/lirc/plugins
Sep 19 21:46:56 ws10 lircd-0.10.1[2176]: Notice: Options: logfile: syslog
Sep 19 21:46:56 ws10 lircd-0.10.1[2176]: Notice: Options: immediate-init: 0
Sep 19 21:46:56 ws10 lircd-0.10.1[2176]: Notice: Options: permission: 666
Sep 19 21:46:56 ws10 lircd-0.10.1[2176]: Notice: Options: driver-options:
Sep 19 21:46:56 ws10 lircd-0.10.1[2176]: Notice: Options: pidfile: /var/run/lirc/lircd.pid
Sep 19 21:46:56 ws10 lircd-0.10.1[2176]: Notice: Options: listen: 0
Sep 19 21:46:56 ws10 lircd-0.10.1[2176]: Notice: Options: connect: (null)
Sep 19 21:46:56 ws10 lircd-0.10.1[2176]: Notice: Options: userelease: 0
Sep 19 21:46:56 ws10 lircd-0.10.1[2176]: Notice: Options: effective_user: (null)
Sep 19 21:46:56 ws10 lircd-0.10.1[2176]: Notice: Options: release_suffix: _EVUP
Sep 19 21:46:56 ws10 lircd-0.10.1[2176]: Notice: Options: allow_simulate: 0
Sep 19 21:46:56 ws10 lircd-0.10.1[2176]: Notice: Options: repeat_max: 600
Sep 19 21:46:56 ws10 lircd-0.10.1[2176]: Notice: Options: configfile: /nix/store/g5km6q3zr3yv3z6gbksbppqkc2wsxrdk-lircd.conf
Sep 19 21:46:56 ws10 lircd-0.10.1[2176]: Notice: Options: dynamic_codes: (null)
Sep 19 21:46:56 ws10 lircd-0.10.1[2176]: Notice: Current driver: ftdi
Sep 19 21:46:56 ws10 lircd-0.10.1[2176]: Notice: Driver API version: 3
Sep 19 21:46:56 ws10 lircd-0.10.1[2176]: Notice: Driver version: 0.10.0
Sep 19 21:46:56 ws10 lircd-0.10.1[2176]: Notice: Driver info: See file:///nix/store/igydwyvngdarn0qhpn0byc93gxh1avqr-lirc-0.10.1/share/doc/lirc/plugindocs/ftdi.html
Sep 19 21:46:56 ws10 lircd-0.10.1[2176]: Info: lircd: Opening log, level: Info
Sep 19 21:46:56 ws10 lircd-0.10.1[2176]: Notice: Using systemd fd
Sep 19 21:46:56 ws10 lircd-0.10.1[2176]: Info: Using remote: harmony_kls_vdr_1.6.
Sep 19 21:46:56 ws10 lircd-0.10.1[2176]: Notice: lircd(ftdi) ready, using /var/run/lirc/lircd
Sep 19 21:46:56 ws10 lircd-0.10.1[2176]: Notice: accepted new client on /var/run/lirc/lircd
Sep 19 21:46:56 ws10 lircd-0.10.1[2176]: Info: Initializing FTDI: product=0x6015
Sep 19 21:46:57 ws10 irsend[2175]: lirc_command_run, state: 0, input: "BEGIN"
Sep 19 21:46:57 ws10 lircd[2176]: lircd-0.10.1[2176]: Info: removed client
Sep 19 21:46:57 ws10 irsend[2175]: lirc_command_run, state: 1, input: "send_once harmony_kls_vdr_1.6 Up"
Sep 19 21:46:57 ws10 irsend[2175]: lirc_command_run, state: 2, input: "SUCCESS"
Sep 19 21:46:57 ws10 irsend[2175]: lirc_command_run, state: 3, input: "END"
Sep 19 21:46:57 ws10 irsend[2175]: lirc_command_run: data:END, status:0
Sep 19 21:46:57 ws10 lircd-0.10.1[2176]: Info: removed client
# irsend send_once harmony_kls_vdr_1.6 Up
Sep 19 21:47:01 ws10 lircd[2176]: lircd-0.10.1[2176]: Notice: accepted new client on /var/run/lirc/lircd
Sep 19 21:47:01 ws10 lircd[2176]: lircd-0.10.1[2176]: Info: hwftdi_init: Already initialised
Sep 19 21:47:01 ws10 lircd-0.10.1[2176]: Notice: accepted new client on /var/run/lirc/lircd
Sep 19 21:47:01 ws10 irsend[2182]: lirc_command_run: Sending: send_once harmony_kls_vdr_1.6 Up
Sep 19 21:47:01 ws10 lircd-0.10.1[2176]: Info: hwftdi_init: Already initialised
Sep 19 21:47:01 ws10 irsend[2182]: lirc_command_run, state: 0, input: "BEGIN"
Sep 19 21:47:01 ws10 lircd[2176]: lircd-0.10.1[2176]: Info: removed client
Sep 19 21:47:01 ws10 irsend[2182]: lirc_command_run, state: 1, input: "send_once harmony_kls_vdr_1.6 Up"
Sep 19 21:47:01 ws10 irsend[2182]: lirc_command_run, state: 2, input: "SUCCESS"
Sep 19 21:47:01 ws10 irsend[2182]: lirc_command_run, state: 3, input: "END"
Sep 19 21:47:01 ws10 irsend[2182]: lirc_command_run: data:END, status:0
Sep 19 21:47:01 ws10 lircd-0.10.1[2176]: Info: removed client
Could you please check in your journal why lircd denies your second irsend.
Does lircd behaviour different when /run/lirc is setuped during ExecStartPre?
Best regards
Christian
Gesendet: Mittwoch, 19. September 2018 um 00:49 Uhr
Von: "Ben Wolsieffer" <notifications@github.com>
An: NixOS/nixpkgs <nixpkgs@noreply.github.com>
Cc: "Christian Kögler" <ck3d@gmx.de>, Author <author@noreply.github.com>
Betreff: Re: [NixOS/nixpkgs] initial NixOS module for LIRC (#32045)
This reproduces the problem on my system:
# systemctl stop lircd.socket lircd.service
# rm -r /run/lirc
# systemctl start lircd.socket
# ls -la /run/lirc
total 0
drwxr-xr-x 2 root root 60 Sep 18 18:47 .
drwxr-xr-x 20 root root 540 Sep 18 18:47 ..
srw-rw---- 1 lirc lirc 0 Sep 18 18:47 lircd
# irsend send_once ...
Error running command: Protocol error
# ls -la /run/lirc
total 0
drwxr-xr-x 2 root root 60 Sep 18 18:47 .
drwxr-xr-x 20 root root 540 Sep 18 18:47 ..
srw-rw---- 1 lirc lirc 0 Sep 18 18:47 lircd
# irsend send_once ...
do_connect: could not connect to socket
connect: Connection refused
Cannot open socket /var/run/lirc/lircd: Connection refused
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
This is the log after the first connection. Systemd tries to restart the service after it fails so this is printed multiple times. The second connection fails with
|
And I suspect that RuntimeDirectory and RuntimeDirectoryPreserve is both set.
Can you prepare a PR which fixes that issue?
Am 19. September 2018 22:20:31 MESZ schrieb Ben Wolsieffer <notifications@github.com>:
…This is the log after the first connection. Systemd tries to restart
the service after it fails so this is printed multiple times. The
second connection fails with `Connection refused` because systemd
refuses to start the service after it has failed too many times.
```
Sep 19 16:13:58 Roomba systemd[1]: Started LIRC daemon service.
Sep 19 16:13:58 Roomba lircd-0.10.1[16525]: Info: lircd: Opening log,
level: Info
Sep 19 16:13:58 Roomba lircd-0.10.1[16525]: Notice: Version: lircd
0.10.1
Sep 19 16:13:58 Roomba lircd-0.10.1[16525]: Notice: System info: Linux
Roomba 4.14.50 #1-NixOS SMP PREEMPT Thu Jan 1 00:00:01 UTC 1970 aarch64
GNU/Linux
Sep 19 16:13:58 Roomba lircd-0.10.1[16525]: Info: Initial device:
/dev/lirc0
Sep 19 16:13:58 Roomba lircd-0.10.1[16525]: Info: Initial device:
/dev/lirc0
Sep 19 16:13:58 Roomba lircd-0.10.1[16525]: Notice: Options: driver:
default
Sep 19 16:13:58 Roomba lircd[16525]: lircd-0.10.1[16525]: Info: lircd:
Opening log, level: Info
Sep 19 16:13:58 Roomba lircd[16525]: can't open or create
/var/run/lirc/lircd.pid: Permission denied
Sep 19 16:13:58 Roomba lircd-0.10.1[16525]: Notice: Options: output:
/var/run/lirc/lircd
Sep 19 16:13:58 Roomba lircd-0.10.1[16525]: Notice: Options: nodaemon:
1
Sep 19 16:13:58 Roomba lircd-0.10.1[16525]: Notice: Options: plugindir:
/nix/store/4yl5yqmvnbm8yxz9mxna31z6mf3ssx8f-lirc-0.10.1/lib/lirc/plugins
Sep 19 16:13:58 Roomba lircd-0.10.1[16525]: Notice: Options: logfile:
syslog
Sep 19 16:13:58 Roomba lircd-0.10.1[16525]: Notice: Options:
immediate-init: 0
Sep 19 16:13:58 Roomba lircd-0.10.1[16525]: Notice: Options:
permission: 666
Sep 19 16:13:58 Roomba lircd-0.10.1[16525]: Notice: Options:
driver-options:
Sep 19 16:13:58 Roomba lircd-0.10.1[16525]: Notice: Options: pidfile:
/var/run/lirc/lircd.pid
Sep 19 16:13:58 Roomba lircd-0.10.1[16525]: Notice: Options: listen: 0
Sep 19 16:13:58 Roomba lircd-0.10.1[16525]: Notice: Options: connect:
(null)
Sep 19 16:13:58 Roomba lircd-0.10.1[16525]: Notice: Options:
userelease: 0
Sep 19 16:13:58 Roomba lircd-0.10.1[16525]: Notice: Options:
effective_user: (null)
Sep 19 16:13:58 Roomba lircd-0.10.1[16525]: Notice: Options:
release_suffix: _EVUP
Sep 19 16:13:58 Roomba lircd-0.10.1[16525]: Notice: Options:
allow_simulate: 0
Sep 19 16:13:58 Roomba lircd-0.10.1[16525]: Notice: Options:
repeat_max: 600
Sep 19 16:13:58 Roomba lircd-0.10.1[16525]: Notice: Options:
configfile: /nix/store/x8gl0zajkf1q8y569qfiirz7g1hfhnbd-lircd.conf
Sep 19 16:13:58 Roomba lircd-0.10.1[16525]: Notice: Options:
dynamic_codes: (null)
Sep 19 16:13:58 Roomba lircd-0.10.1[16525]: Notice: Current driver:
default
Sep 19 16:13:58 Roomba lircd-0.10.1[16525]: Notice: Driver API version:
3
Sep 19 16:13:58 Roomba lircd-0.10.1[16525]: Notice: Driver version:
0.10.0
Sep 19 16:13:58 Roomba lircd-0.10.1[16525]: Notice: Driver info: See
file:///nix/store/4yl5yqmvnbm8yxz9mxna31z6mf3ssx8f-lirc-0.10.1/share/doc/lirc/plugindocs/default.html
Sep 19 16:13:58 Roomba lircd-0.10.1[16525]: Info: lircd: Opening log,
level: Info
Sep 19 16:13:58 Roomba systemd[1]: lircd.service: Main process exited,
code=exited, status=1/FAILURE
Sep 19 16:13:58 Roomba systemd[1]: lircd.service: Failed with result
'exit-code'.
```
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#32045 (comment)
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
|
That's not the problem:
Are we sure that lircd actually supports socket activation? If not, the socket gets created by the socket unit and lircd then dies because it tries to create a socket that already exists. I don't have hardware to test this out on so I'm inclined to revert this until it's tested properly by someone with the correct hardwrae. |
This PR implements the LIRC recommended way. The lirc sources itself provides service and socket files and the histroy tells us, that systemd was integrated with 0.9.1 (2014). |
It works for me as long as I configure the PID file to be stored somewhere outside of |
OK, I opened PR #47154 . |
Motivation for this change
LIRC is not available in NixOS
Things done
build-use-sandbox
innix.conf
on non-NixOS)nix-shell -p nox --run "nox-review wip"
./result/bin/
)