Linux desktop: sharp segfaults under Electron's Node mode, plus a small patch that builds an rpm/AppImage

[dahch]

I wanted a desktop build of DeepSeek Harness on Linux, so I had the harness itself work on it in a branch of the repository. Two things may be useful to others: a crash I hit on Linux, and the patch that works around it. I know external PRs aren't accepted right now (CONTRIBUTING.md), so I'm sharing this only as a reference.

Setup: Fedora 44 KDE, Wayland, x86_64, based on 0.2.1-rc.2
Branch: https://github.com/dahch/deepseek-harness/tree/linux-desktop Build steps, tested setup and limitations

The problem: sharp under Electron's Node mode

The Desktop Host starts as Electron in Node mode, and image attachments are decoded with sharp. On Linux, a small sharp decode (or metadata call) run with ELECTRON_RUN_AS_NODE=1 against the packaged Electron 44.7.0 exits with SIGSEGV (139); encoding works. The same call under the standalone Node bundled in the primary runtime succeeds. sharp's docs list "Electron and Linux" as a known conflict LINK to electron#46323.

What the patch does

• Adds a linux-x64 target to the packaging pipeline, plus electron-builder rpm and AppImage targets and Linux icons.
• On Linux only, runs the Host under the bundled standalone Node and ships the dsh tree as real files beside app.asar (standalone Node can't read ASAR). macOS and Windows keep Electron Node mode.
• On Linux, closing the last window quits the app and stops the Host.
• Updater, upload and release paths are untouched. It's a local, unsigned build.

Checked: the installed rpm opens from the KDE menu, a second launch focuses the existing window, extra windows work, closing leaves no processes, and the smoke checks pass.
Not verified: image attachments and the terminal from the GUI, the AppImage, anything outside Fedora/KDE/Wayland/x86_64. Details are in the README.

Questions

1. Is running the Host under the standalone Node on Linux a reasonable direction, or would you handle sharp differently in the Electron-hosted process?
2. Has anyone else packaging Linux builds hit this crash? I haven't compared my patch with the other ones mentioned in these discussions.

Unofficial, unsigned, rc-quality. Most of the patch was written by an agent running in the harness, and I reviewed the diff.