# AUR packaging

`PKGBUILD` for the **headless TutaBridge daemon** (CLI only — no GUI). It builds
just the `tutabridge` binary, so it pulls no Node / Tauri / webkit dependencies.

## Local build / test

On an Arch machine:

```bash
cd packaging/aur
makepkg -si        # build + install
```

## First run

The daemon resumes a saved keyring session on start, so sign in **once**
interactively before enabling the service:

```bash
tutabridge                                   # prompts for email, then Tuta password + TOTP
systemctl --user enable --now tutabridge     # run it in the background from now on
```

Connect your mail client to `127.0.0.1:1143` (IMAP) / `127.0.0.1:1025` (SMTP),
using the bridge password printed in the logs (`journalctl --user -u tutabridge`).

## Publishing to the AUR

This directory is the package *source*, not the AUR git repo. To publish:

```bash
git clone ssh://aur@aur.archlinux.org/tutabridge-git.git
cp packaging/aur/PKGBUILD tutabridge-git/
cd tutabridge-git
makepkg --printsrcinfo > .SRCINFO    # must be generated on Arch
git add PKGBUILD .SRCINFO
git commit -m "Initial import" && git push
```

`.SRCINFO` is intentionally not committed here — it has to be generated by
`makepkg` on an Arch host so it matches the PKGBUILD exactly.

## Notes

- `pkgver()` derives `0.r<commits>.<short-sha>` from git; `makepkg` rewrites the
  `pkgver=` line on each build.
- The keyring Secret Service backend links system `libdbus` (via
  `libdbus-sys`), so `dbus` is a build + runtime dependency. It's present on
  essentially every Linux desktop already.
- Keyring *persistence* additionally needs a running Secret Service provider
  (gnome-keyring / kwallet) — listed as optdepends. Without one the daemon
  still works but will ask for the Tuta password on every start.
- A future tagged release can add a non-`-git` `tutabridge` package built from
  a release tarball.