Ideally I'll be able to remove this eventually; conversation in the
comments implies they might add English to the default language set.
However, it's not there _now_, so if I want working OCR, I have to add
it myself.
This isn't exactly ideal, since it means I have to build spectacle from
source, which isn't particularly quick. I feel that it probably
shouldn't require that? But that's troubleshooting for another day!
Without this, we see this error:
Feb 22 18:07:12 bert navidrome[230133]: time="2026-02-22T18:07:12-06:00" level=info msg="Watcher started for library" absoluteLibPath=/mnt/bigbird_public/media/music libraryID=1 name="Music Library" path=/mnt/bigbird_public/media/music
Feb 22 18:07:13 bert navidrome[230156]: panic: permission denied [recovered, repanicked]
Feb 22 18:07:13 bert navidrome[230156]: goroutine 1037 [running]:
Feb 22 18:07:13 bert navidrome[230156]: go.senan.xyz/taglib.init.OnceValues[...].func3.1.1()
Feb 22 18:07:13 bert navidrome[230156]: sync/oncefunc.go:98 +0x75
Feb 22 18:07:13 bert navidrome[230156]: panic({0x13a32e0?, 0x3649328?})
Feb 22 18:07:13 bert navidrome[230156]: runtime/panic.go:783 +0x132
Feb 22 18:07:13 bert navidrome[230156]: github.com/tetratelabs/wazero/internal/engine/wazevo.mmapExecutable({0xc00030f000, 0xaf0, 0xc000737800?})
Feb 22 18:07:13 bert navidrome[230156]: github.com/tetratelabs/wazero@v1.11.0/internal/engine/wazevo/engine.go:881 +0xb4
[…]
Feb 22 18:07:13 bert navidrome[230133]: time="2026-02-22T18:07:13-06:00" level=error msg="Scan failed" error="failed to read status from scanner: /nix/store/622zip549ggami2mslhabm80sfsjlrxd-navidrome-0.60.0/bin/.navidrome-wrapped scan --nobanner --subprocess --configfile /nix/store/dxsk74a7b92vkv5mwaaihqcrlqmhlnq0-navidrome.json --datafolder . --cachefolder cache exited with non-zero status code: exit status 2"
Feb 22 18:49:32 bert navidrome[230133]: time="2026-02-22T18:49:32-06:00" level=info msg="Stopping HTTP server"
mkForce is required to avoid a conflicting definition error:
error: The option `systemd.services.navidrome.serviceConfig.MemoryDenyWriteExecute' has conflicting definition values:
- In `/nix/store/jyqf4h6n1wm7kg3qrc5njvvgzkn1m2j5-nixos-25.11/nixos/nixos/modules/services/audio/navidrome.nix': true
- In `/root/config/services/navidrome.nix': false
Use `lib.mkForce value` or `lib.mkDefault value` to change the priority on any of these definitions.
I had also tried the rules terbium recommends, but was unable to get
them to work. I'm not sure all of this command is necessary/optimal, but
it works so I'm stopping tinkering here!
For next time this patch breaks, if I don't feel like fixing it, a good
approximation for this use case is sorting by modified time, e.g.:
handle /downloads/Newsletters/* {
file_server {
browse ${./caddy-browse-template.html} {
sort time desc
}
}
}
evaluation warning: chandler profile: The option `programs.git.userName' defined in `/home/chandler/projects/machine-config/sam/configuration.nix' has been renamed to `programs.git.settings.user.name'.
evaluation warning: chandler profile: The option `programs.git.extraConfig' defined in `/home/chandler/projects/machine-config/sam/configuration.nix' has been renamed to `programs.git.settings'.
evaluation warning: chandler profile: The option `programs.ssh.addKeysToAgent' defined in `/home/chandler/projects/machine-config/sam/configuration.nix' has been renamed to `programs.ssh.matchBlocks.*.addKeysToAgent'.
25.11 and unstable are using spice-vdagent 0.23.0, which doesn't seem to
work for display resizing. (It's likely that it's just a config error,
but this appears to revert it for now. I'll probably try to report/fix
the bug upstream at some point now that I've identified it.)
For future reference, here's how I bisected the problem to this package:
I didn't want to have to deal with compiling the universe from source to
check each commit, so I started with the commits that nixos-unstable
once pointed to, which would have been built by Hydra and cached. I used
`npc` for this:
git clone git@github.com:samestep/npc
NPC_REV=main NIX_BIN=`which nix` GIT_BIN=`which git` cargo build --release
~/projects/npc/target/release/npc fetch # I wasn't able to find a way around this
~/projects/npc/target/release/npc bisect start nixos-unstable
~/projects/npc/target/release/npc bisect bad nixos-unstable # currently broken
~/projects/npc/target/release/npc bisect good f02fddb8acef29a8b32f10a335d44828d7825b78 # formerly working
`npc` will then print out commit hashes for me to try, which I can
check out and run:
git -C ~/projects/nixpkgs checkout b6a8526db03f735b89dd5ff348f53f752e7ddc8e
sudo nixos-rebuild -I nixpkgs="/home/chandler/projects/nixpkgs" boot && reboot
~/projects/npc/target/release/npc bisect <good|bad> $(git -C ~/projects/nixpkgs rev-parse HEAD)
This process repeats until it identifies a good and bad commit:
$ ~/projects/npc/target/release/npc bisect good $(git -C ~/projects/nixpkgs rev-parse HEAD)
done bisecting nixos-unstable
8913c168d1c56dc49a7718685968f38752171c3b is the first bad commit
7df7ff7d8e00218376575f0acdcc5d66741351ee is the last good commit
Now, there's still a pretty big gap here, so I'll want to do some
further bisection!
[chandler@sam:~/projects/nixpkgs]$ git rev-list --count 7df7ff7d..8913c168
3099
[chandler@sam:~/projects/nixpkgs]$ git diff --shortstat 7df7ff7d..8913c168
3716 files changed, 45544 insertions(+), 38260 deletions(-)
Now I can do a regular `git bisect`:
$ git -C ~/projects/nixpkgs bisect start
$ git -C ~/projects/nixpkgs bisect good 7df7ff7d8e00218376575f0acdcc5d66741351ee
$ git -C ~/projects/nixpkgs bisect bad 8913c168d1c56dc49a7718685968f38752171c3b
$ # …
$ git -C ~/projects/nixpkgs bisect bad
1491cf86eb405b21e518f1a94763524de36ee661 is the first bad commit
commit 1491cf86eb405b21e518f1a94763524de36ee661 (HEAD)
Author: R. RyanTM <ryantm-bot@ryantm.com>
Date: Tue Sep 23 12:31:00 2025 +0000
spice-vdagent: 0.22.1 -> 0.23.0
pkgs/by-name/sp/spice-vdagent/package.nix | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
For this, I removed basically all packages, so I wouldn't have to
rebuild e.g. chromium from source! I did end up rebuilding the kernel
once, which took a while; most of the bisect steps didn't actually make
any changes so the whole process was pretty fast.
This results in a substantial speedup. Before:
[ Prompt: 2.9 t/s | Generation: 2.5 t/s ]
After (I haven't figured out what the story is with variable speeds,
these are three successive messages of increasing length in the same
conversation):
[ Prompt: 95.7 t/s | Generation: 11.7 t/s ]
[ Prompt: 2866.0 t/s | Generation: 13.4 t/s ]
[ Prompt: 133.1 t/s | Generation: 14.0 t/s ]
[ Prompt: 188.3 t/s | Generation: 13.6 t/s ]
(benchmarks on Framework 13 AMD 7640U)
