jack
August 25, 2024, 10:36pm
1
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?
What’s the error printed by espanso?
jack
September 22, 2024, 10:36am
3
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.
Those paths are obviously missing the username. Do you have any idea why that would be?
jack
September 22, 2024, 11:44am
5
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
Does /home/user/.config/espanso
exist?
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
8
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
9
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.
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
11
I am also running unstable, but I have never been able to get espanso to work.
Implementation:
Something should end up by default in ~/.config/espanso
. Does that not exist?
Sorry, that has been asked and answered. So, if you remove that custom config file, does that file not get created?
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
NixOS:master
← pitkling:espanso-fix-capabilities
opened 11:48AM - 21 Jul 24 UTC
## 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
15
It looks like that does not work for me. When I tried that solution, it gives me this error:
error: attribute 'security' missing
at /nix/store/zchh9iv3l65z9fdf1v6gxn20sbk0bpp8-source/nixos/modules/programs/espanso-capdacoverride/default.nix:46:43:
45| espanso-wayland = pkgs.callPackage ./espanso-capdacoverride.nix {
46| capDacOverrideWrapperDir = "${config.security.wrapperDir}";
| ^
47| espanso = cfg.package;
It happens even when I don’t have the espanso package, so I am thinking the problem is in the origin flake.