External/tutabridge
1
0
Fork 0
mirror of https://github.com/spartanz51/tutabridge.git synced 2026-06-24 10:54:32 +02:00
Code Issues Packages Projects Releases Wiki Activity

aur: split into tutabridge-git and tutabridge-bin packages

Browse Source 
Add a prebuilt tutabridge-bin package (downloads the published x86_64 CLI
binary, no Rust build) alongside the build-from-source tutabridge-git, each
in its own directory with a PKGBUILD and .SRCINFO. Update the maintainer
address and the packaging README for the two-package layout.
This commit is contained in:
Anthony
2026-06-12 18:31:08 +02:00
parent 7313bbf715
commit 72221d470e
4 changed files with 95 additions and 24 deletions
Download Patch File Download Diff File Expand all files Collapse all files
packaging/aur/README.md
+37 -23
View File
@@ -1,15 +1,22 @@
# 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.
Two packages for the **headless TutaBridge daemon** (CLI only, no GUI, so no
Node / Tauri / webkit dependencies):
## Local build / test
| Directory | AUR package | What it does |
|-----------|-------------|--------------|
| `tutabridge-git/` | `tutabridge-git` | Builds the `tutabridge` binary from the latest commit (needs the Rust toolchain). |
| `tutabridge-bin/` | `tutabridge-bin` | Downloads the prebuilt x86_64 binary from the GitHub release. No build. |
On an Arch machine:
Each directory holds a `PKGBUILD` and a `.SRCINFO`. They install
`/usr/bin/tutabridge` plus a user systemd unit.
## Local build / test (on Arch)
```bash
cd packaging/aur
cd packaging/aur/tutabridge-bin # or tutabridge-git
makepkg -si # build + install
namcap PKGBUILD # lint
```
## First run
@@ -22,34 +29,41 @@ tutabridge # prompts for email, then Tuta pass
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`).
Connect your mail client to `127.0.0.1:1143` (IMAP) and `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:
Each AUR package is its own git repo. From an Arch host (so `makepkg` is
available to verify the `.SRCINFO`):
```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 clone ssh://aur@aur.archlinux.org/tutabridge-bin.git
cp packaging/aur/tutabridge-bin/PKGBUILD tutabridge-bin/
cd tutabridge-bin
makepkg --printsrcinfo > .SRCINFO # regenerate to be safe, then diff against the committed one
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.
Same flow for `tutabridge-git`. The `.SRCINFO` files here are committed for
convenience, but regenerate them with `makepkg --printsrcinfo` on Arch before
pushing so they match the PKGBUILD exactly.
## Updating on a new release
- `tutabridge-git` updates itself: `pkgver()` derives `0.r<commits>.<short-sha>`
from git, so a rebuild always tracks the latest commit. Only re-push if the
PKGBUILD itself changes.
- `tutabridge-bin` pins a release: bump `pkgver` and `_tag`, refresh the three
`sha256sums` (`updpkgsums`), regenerate `.SRCINFO`, and push.
## 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.
- The keyring Secret Service backend links system `libdbus` (via `libdbus-sys`),
so `dbus` is a build + runtime dependency. It is 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.
(gnome-keyring / kwallet), listed as optdepends. Without one the daemon still
works but asks for the Tuta password on every start.