vcswatch reports that
this package seems to have new commits in its VCS but has
not yet updated debian/changelog. You should consider updating
the Debian changelog and uploading this new version into the archive.
Here are the relevant commit logs:
commit 60a84cff0f66fa14779467c4ebf83dedaffbc2c0
Author: Jonaz Thern <44526342+TheJonaz@users.noreply.github.com>
Date: Tue Sep 15 21:33:51 2026 +0200
snap: rename the personal-files plug to dot-backup-sources
Store review feedback on forum thread 53257: `dot-files` names what the plug is
rather than what it grants, and the reviewer asked for a descriptive name (their
own suggestion, `dot-backup-sources`) or a split into one plug per path. A single
descriptive plug keeps it at one `snap connect` for the user instead of six.
With the rename the reviewer gave a +1 for granting manual-connection of
personal-files. Renamed in all three places that have to agree: the commented
block in snapcraft.yaml, the request text, and the README's connect
instructions. The site and wiki only mention moraine:ssh-keys and are untouched
until the plug ships in a published revision.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TXstL26NgbYQ9wEZeUxELA
commit 0bf959178d6ea66f30fd269bf8e6d7156061a0ef
Author: Jonaz Thern <44526342+TheJonaz@users.noreply.github.com>
Date: Mon Sep 14 20:24:58 2026 +0200
snap: trim the personal-files request to what moraine recommend proposes
The drafted store request asked for nine paths, but three of them
($HOME/.local/share, .bashrc, .profile) are not in the recommender's default
source set — while the request's own strongest argument is that the list is
exactly that set and not an open-ended grab. For a super-privileged interface,
unjustified paths are what a reviewer trims, so the claim and the list now agree:
six paths, the dotfile half of the eleven the Linux manifest proposes.
The commented block in snapcraft.yaml is trimmed to match, since its comment
tells the next person to restore it verbatim once the request is granted —
restoring the old nine would ship a plug the store never approved.
Also updates the request's stale revision facts: the snap has been live in stable
since rev 3, currently rev 4 (0.3.1).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TXstL26NgbYQ9wEZeUxELA
commit c46f112635b524372f250852aef4c5984f94d706
Merge: 4569610 e014032
Author: Jonaz Thern <44526342+TheJonaz@users.noreply.github.com>
Date: Sun Sep 13 22:20:43 2026 +0200
Merge feat/distribution-channels: Docker/OCI image, GHCR workflow, root nix flake
The branch had sat unmerged since 2026-08-19. Its snap commits were already on
main — the strict recipe was copied over by hand in ef03074 when the store
turned out to accept only strict — so this merge keeps main's packaging/snap/
(0.3.1, plus the read-only-mount fix) and takes the branch's work that never
landed:
- A Docker/OCI image (packaging/docker/Dockerfile, .dockerignore) and a GHCR
publish workflow that runs on v* tags, so the next release tag publishes a
container image.
- The nix flake moves to the repo root and stops carrying a version and two
lib.fakeHash placeholders: it reads the version from Cargo.toml and builds
from `src = self` with cargoLock.lockFile. main's copy hardcoded 0.3.1 with
both hashes still fake, i.e. it could not build; nothing bumps it either, so
the move removes a drift source rather than creating one.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TXstL26NgbYQ9wEZeUxELA
commit 4569610738ba22e7ff326990069af569ee5658c5
Author: Jonaz Thern <44526342+TheJonaz@users.noreply.github.com>
Date: Sun Sep 13 18:52:09 2026 +0200
snap: upload from a writable path, not the read-only mount
The publish command I documented yesterday mounts packaging/snap read-only and
uploads straight from it, which is exactly how the 0.3.1 upload failed: a bare
`snapcraft internal error: OSError(30, 'Read-only file system')`, because
snapcraft writes next to the snap it is uploading. Copying it to /tmp inside the
container first makes it work; revision 4 went out that way.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TXstL26NgbYQ9wEZeUxELA
commit da7165198a790356775b9cd9cff5867c900b119f
Author: Jonaz Thern <44526342+TheJonaz@users.noreply.github.com>
Date: Fri Sep 11 23:16:27 2026 +0200
snap: publish from the container, and warn about the $PWD trap
The Publish section showed `snapcraft login` / `upload` as if run on the host,
but snapcraft only exists inside the build image. It now shows the container
command, run from the repository root: with a wrong $PWD, Docker silently
creates an empty directory for the -v mount and the upload fails with "is not a
valid file". The command lists the mounted snap first, so that case stops
before anything is sent.
It also uses export-login (the container has no keyring to hold a login) and
--network host (HTTPS to the store hangs behind a smaller-MTU VPN tunnel). The
$PWD trap was written down on the snap-store-request branch and never reached
main before that branch was deleted.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TXstL26NgbYQ9wEZeUxELA
commit ef0307438b0ae8a70329cdf6e26706a715b73099
Author: Jonaz Thern <44526342+TheJonaz@users.noreply.github.com>
Date: Fri Sep 11 22:26:06 2026 +0200
snap: restore the strict recipe the store accepted, at 0.3.1
main has built a classic snap since ea227a2, but the store declined classic on
eligibility, and the only revision it ever published — rev 3, 0.2.2 — is
strict: home, removable-media, network and ssh-keys, with the personal-files
plug held back until its store request is granted. That recipe was committed
on feat/distribution-channels (e014032) and never merged, so the 0.3.1 build
from main came out classic and would have gone straight back into the review
that already said no.
This takes the snap files from e014032 on their own — snapcraft.yaml, the
README describing the strict flow, the pending personal-files request, and the
classic request and reviewer reply for the record — and leaves the branch's
unrelated Docker image and nix flake work where it is. Only the release strings
are bumped to 0.3.1.
Verified: the rebuilt snap's meta/snap.yaml has confinement strict and the same
four plugs as the published rev 3.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TXstL26NgbYQ9wEZeUxELA
commit 4f41c7866b6e439fac88ae75c9eeec85ba50e56a
Author: Jonaz Thern <44526342+TheJonaz@users.noreply.github.com>
Date: Fri Sep 11 22:21:35 2026 +0200
snap: build with host networking so HTTPS survives the WireGuard tunnel
The workstation routes all traffic through a WireGuard full tunnel (wg0, MTU
1380) while docker0 stays at 1500, so a bridged container advertises an MSS the
tunnel cannot carry. DNS and TCP connects still work, then the TLS handshake's
large packets are dropped: snapcraft's `git clone` of the release tag hung and
failed with a bare "exited with code 128".
Reproduced in the same image — bridged, `git ls-remote` over HTTPS times out;
with --network host it answers in a second — and the 0.3.1 snap then built
cleanly. Both `docker build` and the pack run get the flag, since a cold image
build fetches over HTTPS too.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TXstL26NgbYQ9wEZeUxELA
commit d850e381bc50fa6af00273e203edc830758000b9
Author: Jonaz Thern <44526342+TheJonaz@users.noreply.github.com>
Date: Fri Sep 11 22:08:50 2026 +0200
flatpak: point the commit pin at the v0.3.1 tag
bump-recipes.sh moves the manifest's `tag:` but not its `commit:`, so after
the recipes job the manifest said v0.3.1 while still pinning v0.3.0's commit.
flatpak-release.sh refuses to build on that mismatch.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TXstL26NgbYQ9wEZeUxELA
commit 89489ec273624646838e0ffb4feef913926c7445
Author: Jonaz Thern <44526342+TheJonaz@users.noreply.github.com>
Date: Fri Sep 11 22:05:16 2026 +0200
debian: 0.3.1-1 — new upstream release
0.3.1 is the first version Debian can build since 0.2.2: at v0.3.0 the `gui`
feature still implied `keyring`, so `--no-default-features --features gui`
pulled in keyring-core and zbus-secret-service-keyring-store, neither of which
is in Debian. The changelog summarises what changed for Debian users across
the 0.2.2 -> 0.3.1 jump, including that the keyring backend stays off.
The Windows build-dependency patch is refreshed against the new Cargo.toml
(the hunk moved 40 lines and applied only with fuzz 2). It keeps the original
a/b format rather than quilt's `Index:` + versioned-directory default, so the
next refresh diffs as cleanly as this one.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TXstL26NgbYQ9wEZeUxELA
commit 282aedf856af33ec3d85bd4b01c8b3df995ca901
Author: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Date: Fri Sep 11 20:06:00 2026 +0000
packaging: bump downstream recipes to v0.3.1
commit e01403284aa3eb45b36e8f4b0af27053f03508f0
Author: Jonaz Thern <44526342+TheJonaz@users.noreply.github.com>
Date: Fri Aug 21 20:24:14 2026 +0200
snap: publish revision 3 (strict, no personal-files)
Revision 2 was rejected: personal-files is a super-privileged interface whose USE — not just auto-connection — needs its own store-request. Revision 3 drops the dot-files plug and published to stable with no manual review at all (home + removable-media + network + ssh-keys; ssh-keys is not super-privileged, it only denies auto-connection). The dot-files block sits commented in snapcraft.yaml, ready to restore once personal-files-request.md is granted. README rewritten for strict; the intermediate snapcraft-strict.yaml draft is folded into snapcraft.yaml.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
commit 924cd5d01bc395c3ac8a5b2975c2aebd4f6f849a
Author: Jonaz Thern <44526342+TheJonaz@users.noreply.github.com>
Date: Thu Aug 20 19:52:28 2026 +0200
snap: draft the strict rework (system-backup + personal-files)
The classic-confinement request was declined 'as of now' (an eligibility bar — project too new/small — not a technical one), and Oliver Grawert pointed to the system-backup interface plus personal-files. snapcraft-strict.yaml reworks the recipe to strict: home + personal-files (dotfiles at real paths), system-backup (arbitrary/whole-system via /var/lib/snapd/hostfs), ssh-keys/removable-media/network. Going strict sidesteps the classic-eligibility gate — publish and users 'snap connect' the privileged plugs, no store request. Open caveats (drop in-app crontab scheduling; hostfs path UX) are the two questions in oliver-reply.md (posted to thread 52730).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
commit 299a0904784fe04500d91cf069fbfe4191fb90d9
Author: Jonaz Thern <44526342+TheJonaz@users.noreply.github.com>
Date: Wed Aug 19 21:15:23 2026 +0200
snap: save the classic-confinement request text
The moraine snap v0.2.2 (rev 1) is in the store's manual-review queue because it's confinement: classic; this is the forum store-request that unblocks it. Posted 2026-08-18: forum.snapcraft.io/t/request-for-classic-confinement-moraine/52730.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
commit f0d6d34e8157489b8fb5d87b55b18374a00ea3de
Author: Jonaz Thern <44526342+TheJonaz@users.noreply.github.com>
Date: Wed Aug 19 21:15:23 2026 +0200
nix: a working root flake with no hashes to maintain
Move the flake to the repo root and build from 'src = self' with cargoLock.lockFile (all deps are crates.io), so the fetchFromGitHub source hash and cargoHash — both shipped as lib.fakeHash placeholders that never built — are gone. version is read from Cargo.toml, so releases need no flake edit. Enables 'nix run github:TheJonaz/moraine-backup'. Needs one 'nix build .' to verify (no nix on the dev box).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
commit d53cc915c26f8fa9376d1461d674a69b68750458
Author: Jonaz Thern <44526342+TheJonaz@users.noreply.github.com>
Date: Wed Aug 19 21:15:23 2026 +0200
Add a Docker/OCI image and a GHCR publish workflow
packaging/docker/Dockerfile builds the CLI (--no-default-features, no GTK/keyring) on debian-slim with rsync, the OpenSSH client and rclone bundled; runs as a non-root user. .github/workflows/docker.yml builds amd64+arm64 on native runners and publishes a multi-arch image to ghcr.io/<owner>/moraine on release tags (or manual dispatch). Built and smoke-tested locally.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
![[bug history graph]](https://qa.debian.org/data/bts/graphs/m/moraine.png){kind=link}