Home-manager's Espanso module does not create config directory

jack · August 25, 2024, 10:36pm

I am trying to play with Espanso and I have two problems:

home-manager does not install the espanso package, I have to also include the espanso-wayland package under the home.packages = with pkgs; [ list in my home.nix file.
it does create the ~/.config/espanso directory with the ~/.config/espanso/matches subdirectory, but it does not create the ~/.config/espanso/config directory, so espanso gives an error instead of starting. It works if I manually create the config directory.

This is my services.espanso snippet:

  services.espanso = {
    enable = true;
    configs = {
      default = {
      };
    };
    package = pkgs.espanso-wayland;
    wayland = true;
    matches = {
      matches = [
        {
          trigger = ":hello";
          replace = ''world'';
        }
      ];
      base = {
        matches = [
          {
            trigger = ":now";
            replace = "It's {{currentdate}} {{currenttime}}";
          }
        ];
      };
    };
  };

Neither setting package = pkgs.espanso-wayland; nor wayland = true; installed the package. I added the configs line in a vain attempt to create it based on the default example given in the espanso entry of man home-configuration.nix

Nobody else seems to be having these problems when I search. What am I doing wrong?

mightyiam · August 28, 2024, 1:32am

What’s the error printed by espanso?

jack · September 22, 2024, 10:36am

Sorry for the late response.

If I run espanso daemon from the terminal, it produces this output:

18:33:28 [daemon(188114)] [INFO] reading configs from: "/home/user/.config/espanso"
18:33:28 [daemon(188114)] [INFO] reading packages from: "/home/user/.config/espanso/match/packages"
18:33:28 [daemon(188114)] [INFO] using runtime dir: "/home/user/.cache/espanso"
18:33:28 [daemon(188114)] [INFO] system info: NixOS v24.11 - kernel: 6.6.52
18:33:28 [daemon(188114)] [WARN] keyboard layout watcher couldn't determine active layout.
18:33:28 [daemon(188114)] [INFO] watching for changes in path: "/home/user/.config/espanso"

(.espanso-wrapped:188119): Gdk-WARNING **: 18:33:30.355: ../gdk/wayland/gdkcursor-wayland.c:243 cursor image size (9x16) not an integermultiple of scale (2)

then creates a pop-up window where it says

[ERROR] unable to load config

Caused by:
    missing config directory

So, it appears not to be generating the configs as it should.

mightyiam · September 22, 2024, 11:05am

Those paths are obviously missing the username. Do you have any idea why that would be?

jack · September 22, 2024, 11:44am

user is the username, the path is /home/user/.config/espanso

It happens when I use it with a more inspired username as well lol

mightyiam · September 23, 2024, 12:57am

Does /home/user/.config/espanso exist?

f0rdprefect · October 7, 2024, 4:55am

I explicitly set some config:

{ pkgs, config,  ... }:

{
  services.espanso = {
    enable = true;
    package = pkgs.espanso-wayland;
    configs = {
      default = {
         toggle_key = "ALT";
         keyboard_layout = {
            layout = "us";
         };
      };
    };
    matches = {
      base = {
        matches = [
          {
            trigger = ":now";
            replace = "It's {{currentdate}} {{currenttime}}";
          }
          {
            trigger = ":hello";
            replace = "line1\nline2";
          }
          {
            regex = ":hi(?P.*)\\.";
            replace = "Hi {{person}}!";
          }
        ];
      };
      global_vars = {
        global_vars = [
          {
            name = "currentdate";
            type = "date";
            params = {format = "%d/%m/%Y";};
          }
          {
            name = "currenttime";
            type = "date";
            params = {format = "%R";};
          }
        ];
      };
    };
  };
}

does that help? I have some trouble between HM generations and will need to unregister the service and register the service. Not enough motivation to track that down until now.

jack · October 14, 2024, 10:55pm

Yes, it contains only ~/.config/espanso/configs/default.yml

But upon further inspection, that appears to be the result only of this:

  xdg.configFile = {
    "./espanso/configs/default.yml" = {
      enable = true;
      target = "./espanso/configs/default.yml";
      text =
        ''
          '';
      executable = false;
      onChange = ""; # shell command to run when file has changed between generations
    };
  };

Which I had added to try to get espanso do anything.

jack · October 14, 2024, 11:35pm

That does create the directory, but espanso still doesn’t start. When I explicitly run espanso start or espanso daemon it throws errors.

journalctl --user -xeu espanso.service results in this:

worker(4283)] [ERROR] Unable to open EVDEV devices, this usually has to do with permissions.
worker(4283)] [ERROR] You can either add the current user to the 'input' group or run espanso as root
worker(4283)] [ERROR] thread 'engine thread' panicked at 'failed to initialize detector module: detection source initialization failed': espanso/src/cli/worker/engine/mod.rs:141
worker(4283)] [ERROR] Unable to block the LinuxEventLoop: receiving on an empty and disconnected channel
worker(4283)] [ERROR] thread 'main' panicked at 'unable to run main eventloop: receiving on an empty and disconnected channel': espanso/src/cli/worker/mod.rs:160
daemon(4277)] [ERROR] received unexpected exit code from worker 101, exiting
thread 'main' panicked at espanso/src/cli/launcher/mod.rs:213:45
launch daemon: unexpected error, 'espanso daemon' returned a non-zero exit code.
with `RUST_BACKTRACE=1` environment variable to display a backtrace
in process exited, code=exited, status=101/n/a

Not sure where to go from here.

f0rdprefect · October 16, 2024, 6:51am

I am running unstable. Behavior has changed recently, but I can start it and I can register and unregister the service. Not enough time to get down to the root of the problem yet

jack · October 17, 2024, 7:45am

I am also running unstable, but I have never been able to get espanso to work.

mightyiam · October 18, 2024, 5:44am

Implementation:

github.com

nix-community/home-manager/blob/e78cbb20276f09c1802e62d2f77fc93ec32da268/modules/services/espanso.nix#L110-L119


      
          xdg.configFile = let
            configFiles = lib.mapAttrs' (name: value: {
              name = "espanso/config/${name}.yml";
              value = { source = yaml.generate "${name}.yml" value; };
            }) cfg.configs;
            matchesFiles = lib.mapAttrs' (name: value: {
              name = "espanso/match/${name}.yml";
              value = { source = yaml.generate "${name}.yml" value; };
            }) cfg.matches;
          in configFiles // matchesFiles;

Something should end up by default in ~/.config/espanso. Does that not exist?

mightyiam · October 18, 2024, 6:49am

Sorry, that has been asked and answered. So, if you remove that custom config file, does that file not get created?

f0rdprefect · October 20, 2024, 5:55am

There seems to be some general problems with espanso. While it was working fine with just the package in unstable, after a recent rebuild I was reminded that I had to use a workaround outlined in

github.com/NixOS/nixpkgs

nixos/espanso: fix wayland problems due to missing capabilities

NixOS:master ← pitkling:espanso-fix-capabilities

opened 11:48AM - 21 Jul 24 UTC

pitkling

+141 -0

## Description of changes This PR fixes #249364 ~(which I assume is actually …not only Wayland-specific)~. When enabled via `programs.espanso.capdacoverride.enable = true`, it injects an overlay that overrides `pkgs.espanso-wayland` with a package that has the DAC_OVERRIDE capability. With this in place, espanso can be used under Wayland (both in NixOS and Home Manager) via the standard way: ```nix services.espanso = { enable = true; package = pkgs.espanso-wayland; }; ``` There is also a `programs.espanso.capdacoverride.package` option that allows to set which espanso-wayland is used as a base for the DAC-OVERRIDE-enabled package version. For example, if you pulled in espanso-wayland from nixpkgs-unstable under pkgs.unstable.espanso-wayland), you can set: ```nix programs.espanso.capdacoverride.package = pkgs.unstable.espanso-wayland ``` If this module is added, one should probably add a note to the `services.espanso` module mentioning that this must be enabled for Wayland (or it won't work). Alternatively, one could detect automatically whether the user wants to use an espanso-wayland package and activate this module automatically. ## Detailed Description Under Wayland, Espanso requires the DAC_OVERRIDE capability (see the [documentation](https://espanso.org/docs/install/linux/#wayland-compile)). NixOS does not support capabilities in the Nix store but instead provides a framework to create wrapper binaries with suitable capabilities. While the wrapper does some work to maintain those capabilities across forks, this is not enough in the case of Espanso, which drops the extra capabilities early on and relies on **file capabilities** to regain those capabilities when forking a worker process (via `/proc/self/exe`). Unfortunately, the symlink under `/proc/self/exe` does not point to the capability-enabled wrapper but to the original binary in the nix store. Thus, this PR wraps the original espanso-wayland package definition and injects a wrapper library that intercepts the `readlink`-call and – if it looks up `/proc/self/exe` – returns the capability-enabled wrapper. Since `espanso-wayland` is broken without those capabilities, the wrapped espanso-wayland package is then overlayed (unless explicitly disabled via `programs.espanso.capdacoverride.enable = false`) over `pkgs.espanso-wayland` (making the original `pkgs.espanso_wayland` available under `pkgs._espanso-wayland-orig`). Note that the updated package definition **must** be created on-the-fly during evaluation of the system configuration, since the path to the capability-enabled wrapper depends on the `security.wrapperDir`. This has been working pretty well on my system for several weeks. It seems currently the only workaround for #249364 that keeps all of Espanso's features. For example, there is also #339594, but with it we lose Espanso's self-monitoring (which is used, e.g., for automatically re-loading the configuration when it changes). Happy about any feedback (especially from the corresponding maintainers @kimat @pyrox0 @n8henrie @numkem) to improve this if you think this is a viable way forward. ## Things done - Built on platform(s) - [x] x86_64-linux - [ ] aarch64-linux - [ ] x86_64-darwin - [ ] aarch64-darwin - For non-Linux: Is sandboxing enabled in `nix.conf`? (See [Nix manual](https://nixos.org/manual/nix/stable/command-ref/conf-file.html)) - [ ] `sandbox = relaxed` - [ ] `sandbox = true` - [ ] Tested, as applicable: - [NixOS test(s)](https://nixos.org/manual/nixos/unstable/index.html#sec-nixos-tests) (look inside [nixos/tests](https://github.com/NixOS/nixpkgs/blob/master/nixos/tests)) - and/or [package tests](https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md#package-tests) - or, for functions and "core" functionality, tests in [lib/tests](https://github.com/NixOS/nixpkgs/blob/master/lib/tests) or [pkgs/test](https://github.com/NixOS/nixpkgs/blob/master/pkgs/test) - made sure NixOS tests are [linked](https://nixos.org/manual/nixpkgs/unstable/#ssec-nixos-tests-linking) to the relevant packages - [ ] Tested compilation of all packages that depend on this change using `nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"`. Note: all changes have to be committed, also see [nixpkgs-review usage](https://github.com/Mic92/nixpkgs-review#usage) - [x] Tested basic functionality of all binary files (usually in `./result/bin/`) - [24.11 Release Notes](https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2411.section.md) (or backporting [23.11](https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2311.section.md) and [24.05](https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2405.section.md) Release notes) - [ ] (Package updates) Added a release notes entry if the change is major or breaking - [ ] (Module updates) Added a release notes entry if the change is significant - [ ] (Module addition) Added a release notes entry if adding a new NixOS module - [ ] Fits [CONTRIBUTING.md](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md). --- Add a :+1: [reaction] to [pull requests you find important]. [reaction]: https://github.blog/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/ [pull requests you find important]: https://github.com/NixOS/nixpkgs/pulls?q=is%3Aopen+sort%3Areactions-%2B1-desc

in particular the solution in espanso-wayland: service start failure · Issue #249364 · NixOS/nixpkgs · GitHub

works for me right now…

jack · October 30, 2024, 6:36am

It looks like that does not work for me. When I tried that solution, it still gives me this error:

The user systemd session is degraded:
  UNIT            LOAD      ACTIVE SUB    DESCRIPTION    
● espanso.service not-found failed failed espanso.service

Legend: LOAD   → Reflects whether the unit definition was properly loaded.
        ACTIVE → The high-level unit activation state, i.e. generalization of SUB.
        SUB    → The low-level unit activation state, values depend on unit type.

1 loaded units listed.

Because it says it’s degraded, I am going to reboot and see if that does anything.

REBOOTED:
It is apparently starting now, but espanso still does nothing. Nothing triggers. I think I’ll have to make a new thread about this since the issue in my original question is already resolved.


~ 
󰂃 87% ➜ :now 
:now: command not found

~ 
󰂃 87% ➜ espanso service unregister && espanso service register
disabling espanso systemd service
Removed '/home/user/.config/systemd/user/default.target.wants/espanso.service'.
deleting espanso systemd entry
service unregistered correctly!
creating service file in "/home/user/.config/systemd/user/espanso.service"
enabling systemd service
Created symlink '/home/user/.config/systemd/user/default.target.wants/espanso.service' → '/home/user/.config/systemd/user/espanso.service'.
service registered correctly!

~ 
󰂃 87% ➜ systemctl --user stop espanso.service

~ 
󰂃 87% ➜ systemctl --user start espanso.service

~ 
󰂃 87% ➜ systemctl --user status espanso.service
● espanso.service - espanso
     Loaded: loaded (/home/user/.config/systemd/user/espanso.service; enabled; preset: ignored)
     Active: activating (auto-restart) (Result: exit-code) since Thu 2024-10-31 09:43:26 CST; 2s ago
 Invocation: d7e8a616c71347e7a132e6c54c1ffedc
    Process: 168007 ExecStart=/nix/store/1kzp0d57fi1z1gr7kfpvz9ixahccai41-espanso-2.2-unstable-2024-05-14/b>
   Main PID: 168007 (code=exited, status=101)
   Mem peak: 15.6M
        CPU: 177ms

~ took 6s 
󰂃 87% ➜ espanso match exec --trigger :now
unable to exec match: Worker process is not running, please start Espanso first.

~
󰂃 86% ➜ espanso daemon
09:45:50 [daemon(169160)] [INFO] reading configs from: "/home/user/.config/espanso"
09:45:50 [daemon(169160)] [INFO] reading packages from: "/home/user/.config/espanso/match/packages"
09:45:50 [daemon(169160)] [INFO] using runtime dir: "/home/user/.cache/espanso"
09:45:50 [daemon(169160)] [INFO] system info: NixOS v24.11 - kernel: 6.6.58
09:45:50 [daemon(169160)] [WARN] keyboard layout watcher couldn't determine active layout.
09:45:50 [daemon(169160)] [INFO] espanso version: 2.2.1
09:45:50 [daemon(169160)] [INFO] spawning the worker process...
09:45:50 [daemon(169160)] [INFO] watching for changes in path: "/home/user/.config/espanso"
09:45:50 [daemon(169160)] [INFO] binded to IPC unix socket: /home/user/.cache/espanso/espansodaemonv2.sock
09:45:50 [worker(169166)] [INFO] reading configs from: "/home/user/.config/espanso"
09:45:50 [worker(169166)] [INFO] reading packages from: "/home/user/.config/espanso/match/packages"
09:45:50 [worker(169166)] [INFO] using runtime dir: "/home/user/.cache/espanso"
09:45:50 [worker(169166)] [INFO] system info: NixOS v24.11 - kernel: 6.6.58
09:45:50 [worker(169166)] [INFO] binded to IPC unix socket: /home/user/.cache/espanso/espansoworkerv2.sock
09:45:50 [worker(169166)] [INFO] using WaylandAppInfoProvider
09:45:50 [worker(169166)] [WARN] EVDEV backend is being used, but without enabling linux capabilities.
09:45:50 [worker(169166)] [INFO] monitoring the status of the daemon process
09:45:50 [worker(169166)] [WARN]   Although you CAN run espanso EVDEV backend as root, it's not recommended due
09:45:50 [worker(169166)] [WARN]   to security reasons. Espanso supports linux capabilities to limit the attack surface
09:45:50 [worker(169166)] [WARN]   area by only leveraging on the CAP_DAC_OVERRIDE capability (needed to work with
09:45:50 [worker(169166)] [WARN]   /dev/input/* devices to detect and inject text) and disabling it as soon as the
09:45:50 [worker(169166)] [WARN]   initial setup is completed.
09:45:50 [worker(169166)] [INFO] detection module will use this keyboard layout: [R=, M=, L=us, V=, O=]
09:45:50 [worker(169166)] [INFO] using EVDEVSource
09:45:50 [worker(169166)] [ERROR] Unable to open EVDEV devices, this usually has to do with permissions.
09:45:50 [worker(169166)] [ERROR] You can either add the current user to the 'input' group or run espanso as root
09:45:50 [worker(169166)] [ERROR] thread 'engine thread' panicked at 'failed to initialize detector module: detection source initialization failed': espanso/src/cli/worker/engine/mod.rs:141
09:45:50 [worker(169166)] [ERROR] Unable to block the LinuxEventLoop: receiving on an empty and disconnected channel
09:45:50 [worker(169166)] [ERROR] thread 'main' panicked at 'unable to run main eventloop: receiving on an empty and disconnected channel': espanso/src/cli/worker/mod.rs:160
09:45:50 [daemon(169160)] [ERROR] received unexpected exit code from worker 101, exiting

~ took 7s 
󰂃 85% ➜ espanso start
unable to start service: timed out
Hint: sometimes this happens because another Espanso process is left running for some reason.
      Please try running 'espanso restart' or manually killing all Espanso processes, then try again.

~ took 7s 
󰂃 85% ➜ espanso restart
espanso is not running!
unable to start service: timed out
Hint: sometimes this happens because another Espanso process is left running for some reason.
      Please try running 'espanso restart' or manually killing all Espanso processes, then try again.

So espanso basically makes no sense to me on nix