blackbeard/wallet
1
0
Fork 0
Code Issues 27 Pull Requests Actions Packages Projects Releases 4 Wiki Activity

a fedora rpm published to rpm.lair.cafe, following the existing signed-repo pipeline #33

New Issue
Closed
opened 2026-09-15 12:40:00 +00:00 by grenade · 5 comments
grenade commented 2026-09-15 12:40:00 +00:00
Owner
Copy Link

Parent: #5

Scope

Publish blackbeard-wallet to rpm.lair.cafe, the existing signed dnf repository, following the conventions already in use there rather than inventing a second pipeline.

What already exists (copy, do not redesign)

  • Repository layout: https://rpm.lair.cafe/fedora/$releasever/$basearch/ is the stable channel and .../$basearch/unstable/ the prerelease channel, each with its own repodata/ and a packages.json that the site at rpm.lair.cafe renders. GPG key https://rpm.lair.cafe/8b2023ce.gpg; canonical repo file https://rpm.lair.cafe/lair-cafe.repo, so a user needs only dnf config-manager addrepo --from-repofile=https://rpm.lair.cafe/lair-cafe.repo && dnf install blackbeard-wallet.
  • Publishing pattern (cichlid/cichlid .gitea/workflows/release.yml is the cleanest current example; grenade/mistralrs-package is the origin of the scripts; helexa/cortex build-prerelease.yml shows the unstable channel): a package job on the rpm runner does rpmdev-setuptree + rpmbuild -bb per Fedora version with --define "dist .fc<ver>"; a publish job under concurrency: group: rpm-publish imports RPM_SIGNING_KEY / RPM_SIGNING_KEY_ID, writes ~/.rpmmacros from rpm/rpmmacros (%_openpgp_sign_id), rpm --addsign, rsyncs as gitea_ci@oolon.kosherinata.internal:/var/www/rpm/fedora/<ver>/x86_64/, runs createrepo_c --update ., and regenerates packages.json with script/generate-packages-json.py. Changelog via https://git.lair.cafe/actions/rpm-changelog@v1. Copy rpm/rpmmacros and script/generate-packages-json.py from cichlid.
  • Spec style: the repo's packages use the prebuilt-binary spec (%build is a no-op; Source0 is the binary from the build job; %global debug_package %{nil}; License: GPL-3.0-or-later; URL is the Gitea repo). claude-desktop on the same repo is the one desktop-application precedent for the .desktop file, icons and AppStream metadata; find its spec and mirror the file layout.

What is different for a GTK application

cichlid can publish one static musl binary to a Fedora 43 + 44 matrix. The wallet links dynamically against webkit2gtk4.1, gtk3 and libsoup3, so a binary built on the rust-gtk3 runner (Fedora 44) is a Fedora 44 binary. Two honest options:

  1. v1: prebuilt-binary spec, Fedora 44 only. Build on rust-gtk3, package on rpm with Requires: webkit2gtk4.1 gtk3 libappindicator-gtk3, publish to fedora/44/x86_64/. Simplest, and 44 is what our own hosts run.
  2. Later, if 43 (or 45) matters: source build in the spec (monsoon's pattern: vendored crates tarball as Source1, BuildRequires: webkit2gtk4.1-devel gtk3-devel libsoup3-devel …, custom-protocol feature to embed the pre-built webview) run under mock per target release on the rpm runner, since that image has no GTK dev libraries and must not grow them at run time.

Either way the spec installs the binary, blackbeard-wallet.desktop, hicolor icons from crates/wallet-app/icons, and an AppStream metainfo.xml, and passes rpmlint or explains each warning in the spec.

Unstable channel

Pushes to main may publish to unstable/ with cortex's release convention (0.1.<UTC timestamp>.git<sha> so same-day builds order under rpmvercmp) once the release workflow (#32) exists; tags publish to stable. Not required for the epic's definition of done.

Operator decision to record here before starting

Fedora versions to target for v1 (option 1 above says 44 only). The signing key and repo host are already settled by the existing pipeline; nothing new is needed there.

Acceptance

On a clean Fedora 44 VM: add the repo file, dnf install blackbeard-wallet, launch from the application grid, see the version. The package appears in fedora/44/x86_64/packages.json and on rpm.lair.cafe. rpm -K verifies the signature against 8b2023ce.gpg.

Depends on

#32 (release workflow).

Parent: #5 ## Scope Publish `blackbeard-wallet` to **rpm.lair.cafe**, the existing signed dnf repository, following the conventions already in use there rather than inventing a second pipeline. ### What already exists (copy, do not redesign) - **Repository layout**: `https://rpm.lair.cafe/fedora/$releasever/$basearch/` is the stable channel and `.../$basearch/unstable/` the prerelease channel, each with its own `repodata/` and a `packages.json` that the site at rpm.lair.cafe renders. GPG key `https://rpm.lair.cafe/8b2023ce.gpg`; canonical repo file `https://rpm.lair.cafe/lair-cafe.repo`, so a user needs only `dnf config-manager addrepo --from-repofile=https://rpm.lair.cafe/lair-cafe.repo && dnf install blackbeard-wallet`. - **Publishing pattern** (`cichlid/cichlid` `.gitea/workflows/release.yml` is the cleanest current example; `grenade/mistralrs-package` is the origin of the scripts; `helexa/cortex` `build-prerelease.yml` shows the unstable channel): a `package` job on the `rpm` runner does `rpmdev-setuptree` + `rpmbuild -bb` per Fedora version with `--define "dist .fc<ver>"`; a `publish` job under `concurrency: group: rpm-publish` imports `RPM_SIGNING_KEY` / `RPM_SIGNING_KEY_ID`, writes `~/.rpmmacros` from `rpm/rpmmacros` (`%_openpgp_sign_id`), `rpm --addsign`, rsyncs as `gitea_ci@oolon.kosherinata.internal:/var/www/rpm/fedora/<ver>/x86_64/`, runs `createrepo_c --update .`, and regenerates `packages.json` with `script/generate-packages-json.py`. Changelog via `https://git.lair.cafe/actions/rpm-changelog@v1`. Copy `rpm/rpmmacros` and `script/generate-packages-json.py` from cichlid. - **Spec style**: the repo's packages use the **prebuilt-binary spec** (`%build` is a no-op; Source0 is the binary from the build job; `%global debug_package %{nil}`; `License: GPL-3.0-or-later`; `URL` is the Gitea repo). `claude-desktop` on the same repo is the one desktop-application precedent for the `.desktop` file, icons and AppStream metadata; find its spec and mirror the file layout. ### What is different for a GTK application cichlid can publish one static musl binary to a Fedora 43 + 44 matrix. The wallet links dynamically against `webkit2gtk4.1`, `gtk3` and `libsoup3`, so a binary built on the `rust-gtk3` runner (Fedora 44) is a Fedora 44 binary. Two honest options: 1. **v1: prebuilt-binary spec, Fedora 44 only.** Build on `rust-gtk3`, package on `rpm` with `Requires: webkit2gtk4.1 gtk3 libappindicator-gtk3`, publish to `fedora/44/x86_64/`. Simplest, and 44 is what our own hosts run. 2. **Later, if 43 (or 45) matters: source build in the spec** (monsoon's pattern: vendored crates tarball as Source1, `BuildRequires: webkit2gtk4.1-devel gtk3-devel libsoup3-devel …`, `custom-protocol` feature to embed the pre-built webview) run under `mock` per target release on the `rpm` runner, since that image has no GTK dev libraries and must not grow them at run time. Either way the spec installs the binary, `blackbeard-wallet.desktop`, hicolor icons from `crates/wallet-app/icons`, and an AppStream `metainfo.xml`, and passes `rpmlint` or explains each warning in the spec. ### Unstable channel Pushes to `main` may publish to `unstable/` with cortex's release convention (`0.1.<UTC timestamp>.git<sha>` so same-day builds order under rpmvercmp) once the release workflow (#32) exists; tags publish to stable. Not required for the epic's definition of done. ## Operator decision to record here before starting Fedora versions to target for v1 (option 1 above says 44 only). The signing key and repo host are already settled by the existing pipeline; nothing new is needed there. ## Acceptance On a clean Fedora 44 VM: add the repo file, `dnf install blackbeard-wallet`, launch from the application grid, see the version. The package appears in `fedora/44/x86_64/packages.json` and on rpm.lair.cafe. `rpm -K` verifies the signature against `8b2023ce.gpg`. ## Depends on #32 (release workflow).
grenade added the child label 2026-09-15 12:41:42 +00:00
grenade changed title from a fedora rpm from a spec with vendored crates, published to a signed dnf repo on our infra to a fedora rpm published to rpm.lair.cafe, following the existing signed-repo pipeline 2026-09-15 13:11:03 +00:00
grenade commented 2026-09-15 13:11:19 +00:00
Author
Owner
Copy Link

Pointer for the desktop-app precedent: the claude-desktop package on rpm.lair.cafe comes from lair/claude-desktop-package on git.lair.cafe. Both lair/vibe-kanban (rpm/vibe-kanban.spec, .gitea/workflows/host-release.yml) and its comments name that repo as the house convention for packaging a desktop application (no debuginfo, prebuilt binary, package-and-publish on the rpm runner). Start from its spec for the .desktop entry, hicolor icons and AppStream metainfo; it is not checked out on the workstation, so clone it first.

Pointer for the desktop-app precedent: the `claude-desktop` package on rpm.lair.cafe comes from **`lair/claude-desktop-package`** on git.lair.cafe. Both `lair/vibe-kanban` (`rpm/vibe-kanban.spec`, `.gitea/workflows/host-release.yml`) and its comments name that repo as the house convention for packaging a desktop application (no debuginfo, prebuilt binary, package-and-publish on the `rpm` runner). Start from its spec for the `.desktop` entry, hicolor icons and AppStream metainfo; it is not checked out on the workstation, so clone it first.
grenade commented 2026-09-15 13:28:45 +00:00
Author
Owner
Copy Link

Operator decision, 2026-09-15

Fedora 44 only for v1. Prebuilt-binary spec from the rust-gtk3 runner, packaged on rpm, published to fedora/44/x86_64/ on rpm.lair.cafe. No source build under mock for now.

If the distro/version matrix ever grows, prefer COPR over widening our own pipeline. Two reasons recorded here so the trade-off is not re-litigated later: it is free build infrastructure, and it gives an external guarantee of build-environment hygiene (clean mock chroots per target, nobody's workstation or runner image in the chain) that a self-hosted matrix cannot offer. COPR builds from a source RPM, so that path is the spec-with-vendored-crates variant (option 2 above), and the rpm runner already carries copr-cli; git.lair.cafe/actions/copr-publish exists as the action. The wallet is GPL-3.0-or-later, which COPR's licensing policy accepts. Users would then get the package from COPR rather than rpm.lair.cafe, or rpm.lair.cafe could mirror COPR's output; decide when the matrix actually grows.

## Operator decision, 2026-09-15 **Fedora 44 only for v1.** Prebuilt-binary spec from the `rust-gtk3` runner, packaged on `rpm`, published to `fedora/44/x86_64/` on rpm.lair.cafe. No source build under mock for now. **If the distro/version matrix ever grows, prefer COPR over widening our own pipeline.** Two reasons recorded here so the trade-off is not re-litigated later: it is free build infrastructure, and it gives an external guarantee of build-environment hygiene (clean mock chroots per target, nobody's workstation or runner image in the chain) that a self-hosted matrix cannot offer. COPR builds from a source RPM, so that path is the spec-with-vendored-crates variant (option 2 above), and the `rpm` runner already carries `copr-cli`; `git.lair.cafe/actions/copr-publish` exists as the action. The wallet is GPL-3.0-or-later, which COPR's licensing policy accepts. Users would then get the package from COPR rather than rpm.lair.cafe, or rpm.lair.cafe could mirror COPR's output; decide when the matrix actually grows.
grenade commented 2026-09-16 06:15:58 +00:00
Author
Owner
Copy Link

The pipeline is in the repo (release.yaml package and publish jobs, rpm/blackbeard-wallet.spec, rpm/rpmmacros, script/generate-packages-json.py), following cichlid's workflow line for line and the claude-desktop spec for the desktop entry, icons and scriptlets. Fedora 44 only, as decided. A local build from the release binary produces blackbeard-wallet-0.1.0-1.fc44.x86_64.rpm with the binary, desktop entry, AppStream metainfo and hicolor icons; rpmlint's remaining warnings are each explained at the top of the spec.

Operator action before the first publish: this repository has no Actions secrets (checked: none on the repo, none on the blackbeard org). The publish job needs the three the other rpm.lair.cafe publishers hold as repository secrets:

  • RPM_SIGNING_KEY (the armoured private key for 8b2023ce)
  • RPM_SIGNING_KEY_ID
  • RSYNC_SSH_KEY (the gitea_ci@oolon key)

Their values are only readable where they were first set, so they cannot be copied over by API. Until they are added, a v* tag still builds the bundles, attaches them to the Gitea release and builds the rpm; the run then fails at publish, and re-running that job after the secrets exist finishes the publication.

Also owed for the acceptance: the clean Fedora 44 VM install through lair-cafe.repo, once a tag has been published.

The pipeline is in the repo (release.yaml `package` and `publish` jobs, `rpm/blackbeard-wallet.spec`, `rpm/rpmmacros`, `script/generate-packages-json.py`), following cichlid's workflow line for line and the claude-desktop spec for the desktop entry, icons and scriptlets. Fedora 44 only, as decided. A local build from the release binary produces `blackbeard-wallet-0.1.0-1.fc44.x86_64.rpm` with the binary, desktop entry, AppStream metainfo and hicolor icons; rpmlint's remaining warnings are each explained at the top of the spec. **Operator action before the first publish:** this repository has no Actions secrets (checked: none on the repo, none on the `blackbeard` org). The `publish` job needs the three the other rpm.lair.cafe publishers hold as repository secrets: - `RPM_SIGNING_KEY` (the armoured private key for `8b2023ce`) - `RPM_SIGNING_KEY_ID` - `RSYNC_SSH_KEY` (the `gitea_ci@oolon` key) Their values are only readable where they were first set, so they cannot be copied over by API. Until they are added, a `v*` tag still builds the bundles, attaches them to the Gitea release and builds the rpm; the run then fails at `publish`, and re-running that job after the secrets exist finishes the publication. Also owed for the acceptance: the clean Fedora 44 VM install through `lair-cafe.repo`, once a tag has been published.
grenade commented 2026-09-16 08:05:17 +00:00
Author
Owner
Copy Link

Secrets are now in place: RSYNC_SSH_KEY at the blackbeard org level (set by the operator), and on this repository RPM_SIGNING_KEY and RPM_SIGNING_KEY_ID (rpm@lair.cafe), the same key every package on rpm.lair.cafe carries. Checked against the host: rpm -Kv on the published cichlid-0.1.9-1.fc44 reports an EdDSA header signature by fingerprint aa31689b0e504e88f99bf0176620caca8b2023ce, the certify key whose signing subkey A3EFB60854C6DC9D expires 2027-04-24; the private half lives in the operator workstation's ~/.gnupg/lair keyring, where mistralrs-package's script/setup/gpg.sh generated it. The publish job can run as soon as a v* tag exists; the AppImage step in the same run still waits on the rust-gtk3 runner image picking up librsvg2-devel (gongfoo, images workflow).

Secrets are now in place: `RSYNC_SSH_KEY` at the `blackbeard` org level (set by the operator), and on this repository `RPM_SIGNING_KEY` and `RPM_SIGNING_KEY_ID` (`rpm@lair.cafe`), the same key every package on rpm.lair.cafe carries. Checked against the host: `rpm -Kv` on the published `cichlid-0.1.9-1.fc44` reports an EdDSA header signature by fingerprint `aa31689b0e504e88f99bf0176620caca8b2023ce`, the certify key whose signing subkey `A3EFB60854C6DC9D` expires 2027-04-24; the private half lives in the operator workstation's `~/.gnupg/lair` keyring, where mistralrs-package's `script/setup/gpg.sh` generated it. The publish job can run as soon as a `v*` tag exists; the AppImage step in the same run still waits on the rust-gtk3 runner image picking up librsvg2-devel (gongfoo, images workflow).
grenade commented 2026-09-16 14:41:47 +00:00
Author
Owner
Copy Link

Published by release run 36: blackbeard-wallet-0.1.0-1.fc44.x86_64.rpm is in fedora/44/x86_64/, listed in packages.json, and rpm -Kv on the repo host reports the lair.cafe key (aa31689b…8b2023ce) OK. It ships the binary, desktop entry, AppStream metainfo and four hicolor icons.

Install check, in a clean fedora:44 container rather than a VM: dnf config-manager addrepo --from-repofile=https://rpm.lair.cafe/lair-cafe.repo && dnf install blackbeard-wallet succeeded with the repo's gpgcheck=1, and blackbeard-wallet --version printed blackbeard-wallet 0.1.0. Launching from the application grid needs a desktop session and has not been done; that is the one part of the acceptance still owed. Closing on the rest.

Published by release run 36: `blackbeard-wallet-0.1.0-1.fc44.x86_64.rpm` is in `fedora/44/x86_64/`, listed in `packages.json`, and `rpm -Kv` on the repo host reports the lair.cafe key (`aa31689b…8b2023ce`) OK. It ships the binary, desktop entry, AppStream metainfo and four hicolor icons. Install check, in a clean `fedora:44` container rather than a VM: `dnf config-manager addrepo --from-repofile=https://rpm.lair.cafe/lair-cafe.repo && dnf install blackbeard-wallet` succeeded with the repo's `gpgcheck=1`, and `blackbeard-wallet --version` printed `blackbeard-wallet 0.1.0`. Launching from the application grid needs a desktop session and has not been done; that is the one part of the acceptance still owed. Closing on the rest.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
child
One independently mergeable, verifiable step of an epic
 epic
A goal with an external definition of done; decomposes into child issues in dependency order
No Label child
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
grenade
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: blackbeard/wallet#33
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?