Saturday, September 26, 2026

xfce4: autologin does not work

It autologin does not work despite setting in /etc/lightdm/lightdm.conf:

autologin-user=your_user_name
autologin-user-timeout=0

Check if your your_user_name is added to autologin group or even if the group exist:

sudo groupadd autologin
sudo usermod -aG autologin your_user_name

Friday, August 28, 2026

pi-intercom over SSH: the 30-second guide

pi-intercom is same-machine only — it talks via a Unix socket at ~/.pi/agent/intercom/broker.sock. sshfs won't forward it (sockets aren't regular files). Forward the socket itself.

1. Keep the broker alive on host A

pi
ls -l ~/.pi/agent/intercom/broker.sock # must exist

2. Forward it to host B — don't use ~ after :

rm -f ~/.pi/agent/intercom/broker.sock
REMOTE=$(ssh user@hostA 'echo $HOME/.pi/agent/intercom/broker.sock')
ssh -nNT -o StreamLocalBindUnlink=yes -L $HOME/.pi/agent/intercom/broker.sock:$REMOTE user@hostA

3. Use it

pi
intercom list # shows sessions from both hosts


Troubleshooting channel 1: open failed: remote socket missing (broker died after 5s idle), ssh -v, or AllowStreamLocalForwarding no on hostA (sudo sshd -T | grep allowstreamlocalforwarding).

gentoo: Fixing Flameshot's Wrong-Monitor Bug on XFCE

If Flameshot's screenshot selector on Linux keeps popping up on the wrong monitor — even one that's turned off — check your primary display setting before anything else.

On my Gentoo + XFCE4 + X11 setup, Flameshot (Flatpak) kept opening its capture overlay on my second monitor, no matter what I did. Compositor tweaks, permissions, config resets — nothing worked.

The actual cause: my main monitor wasn't set as primary in XFCE's display settings. Flameshot just follows whatever XRandR reports as primary, regardless of which screen is actually active.

One change in Settings → Display, and it's been working perfectly since.

Wednesday, August 12, 2026

xpra: insufficient permissions to use socket path '/var/run/xpra/tux-5'

On the remote host, you have to be added to xpra group, e.g:

sudo gpasswd -a user_name xpra

Tuesday, August 04, 2026

Reasonix: use openrouter as provider for DeepSeek

In ~/.reasonix/config.toml:

[[providers]]
name = "deepseek-flash"
kind = "openai"
base_url = "https://openrouter.ai/api/v1"
model = "deepseek/deepseek-v4-flash"
api_key_env = "OPENROUTER_API_KEY"
context_window = 1000000
price = { cache_hit = 0.0028, input = 0.14, output = 0.28, currency = "$" }

And in ~/.reasonix/.env:

OPENROUTER_API_KEY=sk-or-v1-xxxx

xpra: USE flags to install on gentoo without using nvidia

/etc/portage/package.use/xpra should be:

x11-wm/xpra -video_cards_nvidia
x11-base/xorg-server xvfb

Thursday, July 30, 2026

open terminal in docker

docker run --rm --network=host -v open-terminal:/home/user -e OPEN_TERMINAL_API_KEY=your-secret-key --name open-terminal ghcr.io/open-webui/open-terminal run --host 0.0.0.0 --port 8001

open-webui: Account Activation Pending

If you get the following error: Account Activation Pending
Contact Admin for WebUI Access
Your account status is currently pending activation.
To access the WebUI, please reach out to the administrator.
Admins can manage user statuses from the Admin Panel.
Admin: User (admin@localhost)

Open WebUI stores each account's role (pending, user, admin) in its SQLite database, and normally the very first account created is auto-promoted to admin — but if that didn't happen cleanly (e.g. a previous run, crash, or port conflict interfered), your account gets stuck as pending, which blocks access even with WEBUI_AUTH=False. The fix is to update that account's role directly in the database and then just refresh the browser tab.

docker exec -it open-webui python3 -c "
import sqlite3
conn = sqlite3.connect('/app/backend/data/webui.db')
c = conn.cursor()
c.execute(\"UPDATE user SET role='admin'\")
conn.commit()
print(c.rowcount, 'user(s) updated')
"

Thursday, July 16, 2026