| |
|
|
|
|
|
|
| |
MELPA's 2026-08-18 telega raised telega-tdlib-min-version to 1.8.66. The pinned upstream image ships 1.8.64, so telega killed its own server on every launch. Upstream's only 1.8.66 image won't start: it's missing libglycin (zevlg/telega.el#596).
docker/telega-server/Dockerfile derives from that upstream image, pinned by digest, and adds the one missing package. make telega-image builds it as cj/telega-server:1.8.66-glycin, cj/telega-docker-image defaults to that tag, and a test holds the two equal. cj/telega now refuses to launch with a make telega-image hint when the image isn't built, since docker would otherwise try to pull a local-only tag from the registry. setup-telega.sh points at the make target instead of M-x telega-server-build.
I chose the local build over pinning the telega package back to 20260706.2147. The derived image satisfies both machines' floors. package.el can't pin a version and MELPA serves only its latest build, so nothing would enforce the package pin. When #596 is fixed upstream the pin returns to a registry digest and the Dockerfile goes.
|
|
|
- A dead telega-server now raises a persistent desktop notification.
- The container image is pinned by digest, not by tag.
- A clean telega exit stays silent, so quitting never pages.
telega reports an abnormal server exit through the echo area, where it scrolls away unseen. That's how a dead server reads as a quiet Telegram. The scan stops partway, and the chats it never reached look empty. It's happened twice. Both times something downstream caught it rather than the failure announcing itself.
telega pins its image only when its TDLib min and max versions match. Here the max is nil, so the image was always the latest tag. A floating tag against a fixed elpa package means the server can change underneath it with nothing announcing that either.
Neither change fixes the crash. The root cause is still open. The assertion is a plist parse failure. Its coredump shows a smashed stack, which reads more like memory corruption than a parse rejection.
I didn't pull a newer image, which was the other half of the plan. The pull was meant to test whether an old server was failing against newer elisp. The frozen image ships libtdjson 1.8.64, exactly the version this telega requires. That theory no longer holds, so pulling would trade a matched server for an unknown one.
|
