LibreKAT/Ocideck
LibreKAT/Ocideck
Watch
4
0
Fork
You've already forked Ocideck
 1
Code Issues Pull requests Projects Releases 19 Packages Activity Actions

create homebrew casks for linux and macos automagically #1222

Closed
reinoud wants to merge 1 commit from reinoud/Ocideck:homebrew_support into main
pull from: reinoud/Ocideck:homebrew_support
merge into: LibreKAT:main
Conversation 2 Commits 1 Files changed 4 +181
reinoud commented 2026-08-04 16:09:30 +00:00
First-time contributor
Copy link

Summary

Changes

Checklist

  • Every commit is signed off (git commit -s) per the
    DCO, with my real name and a reachable email.
  • make check passes (format-check, analyze, full test suite).
  • Added/updated tests for the behaviour I changed. If this fixes a bug,
    the test is on the reported behaviour and was red once against the
    unfixed code     — or I explained in the summary why a test cannot prove
    anything here and what gate covers it instead.
  • New UI strings go through context.l10n.d('…') and are translated in
    every supported language. Use make add-l10n SPEC=…; the authoritative
    set is AppLocalizations.languageNames, not a list written down here.
    Not the maintainer? Supply Dutch and English, leave the other 30
    blank, and say so below — the maintainer fills them in before merge.
  • If I changed how anything is stored, I updated
    docs/FILE_FORMAT.md.
  • Docs updated where relevant (README / docs/).
  • If this touches the file format, storage, a dependency, outgoing network
    traffic, or a promise made in the UI or the docs — I described the
    trade-off in the summary: which principle I gave precedence, why, and
    what would change my mind.
  • Threat model still holds. If this change touches any of — a new or
    changed interface, the authentication/trust model, newly handled sensitive
    data, a major dependency or supplier swap, the update/distribution path, or
    a large architectural change — I re-read
    docs/SECURITY_DESIGN.md (§Threat model) and
    assurance/risicoafweging.md and either
    confirmed they still hold or updated them. (No gate enforces this: whether
    the model was genuinely revisited cannot be checked mechanically.)

Notes for reviewers

## Summary <!-- What does this change do, and why? Link any related issue (e.g. "Closes #123"). --> ## Changes <!-- Bullet the notable changes. --> - ## Checklist - [ ] Every commit is **signed off** (`git commit -s`) per the [DCO](../dco.txt), with my real name and a reachable email. - [ ] `make check` passes (format-check, analyze, full test suite). - [ ] Added/updated tests for the behaviour I changed. **If this fixes a bug, the test is on the reported behaviour and was red once against the unfixed code** — or I explained in the summary why a test cannot prove anything here and what gate covers it instead. - [ ] New UI strings go through `context.l10n.d('…')` **and** are translated in every supported language. Use `make add-l10n SPEC=…`; the authoritative set is `AppLocalizations.languageNames`, not a list written down here. **Not the maintainer?** Supply Dutch and English, leave the other 30 blank, and say so below — the maintainer fills them in before merge. - [ ] If I changed how anything is stored, I updated [`docs/FILE_FORMAT.md`](../docs/FILE_FORMAT.md). - [ ] Docs updated where relevant (README / docs/). - [ ] If this touches the file format, storage, a dependency, outgoing network traffic, or a promise made in the UI or the docs — I described the trade-off in the summary: which principle I gave precedence, why, and what would change my mind. - [ ] **Threat model still holds.** If this change touches any of — a new or changed interface, the authentication/trust model, newly handled sensitive data, a major dependency or supplier swap, the update/distribution path, or a large architectural change — I re-read [`docs/SECURITY_DESIGN.md`](../docs/SECURITY_DESIGN.md) (§Threat model) and [`assurance/risicoafweging.md`](../assurance/risicoafweging.md) and either confirmed they still hold or updated them. (No gate enforces this: whether the model was genuinely revisited cannot be checked mechanically.) ## Notes for reviewers <!-- Anything that needs extra attention, screenshots, or manual test steps (e.g. dual-screen presenting or drawing, which need real hardware). -->
create homebrew casks for linux and macos automagically
Some checks failed
scans / scans (pull_request) Has been cancelled
Details
static-gate / static-gate (pull_request) Has been cancelled
Details
0dd8a92521
brenno commented 2026-08-04 17:21:17 +00:00
Owner
Copy link

Thanks Reinoud — and apologies, my first reply here missed that you had actually implemented this, not just requested it. You did the real work: a cask template, an update script, and release wiring on both workflows, nicely guarded behind a secret. That is a solid starting point, and we would like to build on it and land it with your authorship credited.

A few things we will adjust along the way:

  • macOS cask, not Linux. Homebrew Cask is macOS-only — there are no Linux casks (brew on Linux only handles CLI formulae), and the Linux release is a Flutter bundle directory rather than a single ocideck binary, so the on_linux ... binary block cannot work. We will make the cask macOS-only. Linux does deserve a proper install path, and we are treating that as its own track — see #1227 (likely AppImage as the portable baseline, plus Flatpak).
  • Drop auto_updates true. In a cask that means "the app updates itself" and tells Homebrew not to offer upgrades — OciDeck does not self-update, so this would suppress brew upgrade.
  • Verify against the published SHA256SUMS. Instead of re-downloading and re-hashing, we will read the authoritative hash from the SHA256SUMS we already publish with each release.
  • Tap location. The tap will live on our own forge as the canonical home, mirrored to GitHub so the brew install --cask librekat/ocideck/ocideck shorthand still works.

We have opened #1227 to track the whole packaging effort (macOS cask + Linux). We will base the work on your commit, refine on top, and land it with your authorship credited. Thanks again for kicking this off.

Thanks Reinoud — and apologies, my first reply here missed that you had actually *implemented* this, not just requested it. You did the real work: a cask template, an update script, and release wiring on both workflows, nicely guarded behind a secret. That is a solid starting point, and we would like to build on it and land it with your authorship credited. A few things we will adjust along the way: - **macOS cask, not Linux.** Homebrew Cask is macOS-only — there are no Linux casks (`brew` on Linux only handles CLI *formulae*), and the Linux release is a Flutter bundle directory rather than a single `ocideck` binary, so the `on_linux ... binary` block cannot work. We will make the cask macOS-only. Linux does deserve a proper install path, and we are treating that as its own track — see #1227 (likely AppImage as the portable baseline, plus Flatpak). - **Drop `auto_updates true`.** In a cask that means "the app updates itself" and tells Homebrew *not* to offer upgrades — OciDeck does not self-update, so this would suppress `brew upgrade`. - **Verify against the published `SHA256SUMS`.** Instead of re-downloading and re-hashing, we will read the authoritative hash from the `SHA256SUMS` we already publish with each release. - **Tap location.** The tap will live on our own forge as the canonical home, mirrored to GitHub so the `brew install --cask librekat/ocideck/ocideck` shorthand still works. We have opened #1227 to track the whole packaging effort (macOS cask + Linux). We will base the work on your commit, refine on top, and land it with your authorship credited. Thanks again for kicking this off.
brenno commented 2026-08-04 17:55:16 +00:00
Owner
Copy link

Landed in main via #1229 (merge ab0b0774) — thank you, Reinoud. Your commit is the base of that branch, so your authorship is preserved in the history, and there is a word of thanks in the CHANGELOG.

Summary of what changed on top of your version before merge: the cask is now macOS-only (Homebrew Cask has no Linux equivalent), auto_updates true was dropped, the SHA-256 is read from the published SHA256SUMS, and the tap is forge-canonical with a GitHub mirror. Linux packaging continues on its own track in #1227 (AppImage / .deb / Flatpak). Closing this in favour of the merged branch.

Landed in main via #1229 (merge `ab0b0774`) — **thank you, Reinoud.** Your commit is the base of that branch, so your authorship is preserved in the history, and there is a word of thanks in the CHANGELOG. Summary of what changed on top of your version before merge: the cask is now macOS-only (Homebrew Cask has no Linux equivalent), `auto_updates true` was dropped, the SHA-256 is read from the published `SHA256SUMS`, and the tap is forge-canonical with a GitHub mirror. Linux packaging continues on its own track in #1227 (AppImage / .deb / Flatpak). Closing this in favour of the merged branch.
brenno closed this pull request 2026-08-04 17:55:17 +00:00
Some checks failed
scans / scans (pull_request) Has been cancelled
Details
static-gate / static-gate (pull_request) Has been cancelled
Required
Details

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
accepted
Assessed and will be built

  
bug
Something is broken

  
declined
Assessed and will not be built

  
docs
Documentation only

  
duplicate
Already tracked elsewhere

  
enhancement
New feature or improvement request

  
good first issue
Small, self-contained, and a good place to start

  
in-progress
Someone is working on this right now. Do not start it in parallel.

  
needs-info
Waiting for the reporter

  
privacy
Personal data can leak. Handled before anything else.

  
security
A weakness someone could use. Handled before anything else.

  
triage
Awaiting assessment

No labels
accepted
bug
declined
docs
duplicate
enhancement
good first issue
in-progress
needs-info
privacy
security
triage
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
LibreKAT/Ocideck!1222
No description provided.