The shipped config.yml is generated fully commented out, so replacing the
<jwt-secret> placeholder only edited a comment. Vikunja then generated a new
random secret on every start, invalidating all sessions on restart.
Append a live service.secret block instead, unless a service section already
exists.
The postinstall script only ran `systemctl enable`, which creates the
wants-symlink and nothing else. On an upgrade the package manager
replaced the binary while the old process kept running the old inode, so
users had to restart vikunja by hand to get the new version. Changes to
vikunja.service were never picked up either, for lack of a
`daemon-reload`.
Add a daemon-reload plus `try-restart` (`rc-service restart` on OpenRC).
try-restart is a no-op while the unit is stopped, so fresh installs keep
their current behaviour of being enabled but not started.
The config fixups move above the service handling so a restart never
races a half-patched config.
The postinstall scripts generated the jwt secret with:
cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 32 | head -n 1
This relies on SIGPIPE to terminate the infinite `cat /dev/urandom`
once `head` has read its single line. Inside a dpkg/apt maintainer-script
context the SIGPIPE disposition is not reliably delivered, so
`cat /dev/urandom` spins forever, the postinstall never returns, and the
whole `dpkg -i` / upgrade hangs.
Read a bounded 512 bytes with `head -c` instead so nothing depends on
SIGPIPE to terminate. 512 random bytes yield ~124 alphanumerics on
average, so the trailing `head -c 32` reliably produces a full 32-char
secret while staying dependency-free.
Fixes#2660
New build/ Go module hosts the full release pipeline (xgo cross-compile,
upx, sha256, zip bundles, nfpm templating, deb/rpm/apk repo metadata)
for every Go binary in the monorepo. Parametric on project name —
`mage release:build vikunja` and `mage release:build veans` both flow
through the same code.
The module is intentionally self-contained: it depends on nothing but
stdlib + mage, and duplicates the small filesystem helpers (copyFile,
moveFile, sha256File) rather than importing them from a project
magefile. That keeps the release tooling free to evolve without
touching project code.
reprepro uses gpgme for signing which fails in CI environments because
gpgme cannot access pinentry. Instead, remove SignWith from the reprepro
distributions config and sign Release files manually with gpg after
reprepro finishes, producing both Release.gpg and InRelease.
kolaente
konradandkolaente
