The os packages previously stored the sqlite database and all other
runtime data in /opt/vikunja, next to the binary. Fresh installs now
default to /var/lib/vikunja, which is the correct FHS location for
variable state data. The package creates the directory and the service
units use it as their working directory.
BREAKING CHANGE: New installations store their data in /var/lib/vikunja
instead of /opt/vikunja. Existing installations keep their current
config and are unaffected, but setups relying on the old default path
for new machines need to move their data or adjust the config.
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
