- release-iso.yml's "Build bread-theme from source" step grepped
bos-settings/Cargo.toml for the bread-theme tag pin, but bos-settings was
split out into its own repo (git.breadway.dev/Breadway/bos-settings) --
that path no longer exists in this checkout, so the grep would fail (or
silently find nothing). Now fetches bos-settings' Cargo.toml directly from
its own repo (dev branch, the one its own CI actually publishes the
bos-settings pacman package from) via the Forgejo raw-file endpoint.
- calamares.yml cloned the repo's default branch instead of the branch/tag
that actually triggered the run -- bibata.yml, powerlevel10k.yml, and
yay-bin.yml (the other in-house-PKGBUILD workflows in this same family)
all correctly clone --branch "${GITHUB_REF_NAME}". Brought calamares.yml
in line with them.
- breadhelp-tour.lua interpolated an untrusted, client-controlled Wayland
window class / layer-shell namespace directly into a bread.exec shell
command string -- a session-level shell injection vector (verified
exploitable with a crafted window class before this fix, e.g.
"evil; touch ~/pwned #"). bread.exec only accepts a single shell string
(always run via `sh -lc`, per breadd/src/lua/mod.rs) -- there's no
array-exec form to bypass the shell with -- so the fix is a proper POSIX
shell_quote() helper wrapping every interpolated value in single quotes
before it reaches bread.exec.
Mirrors the bos-settings extraction (664298b): a breadhelp release no
longer requires a v* tag on the whole bos monorepo, which was
indistinguishable from an actual BOS-version release tag. Source lives
at ~/Projects/breadhelp now, full history preserved via git-filter-repo.
Root Cargo.toml/Cargo.lock and .forgejo/workflows/package.yml removed
too — breadhelp was the sole workspace member and the sole thing that
workflow built.
bos-settings moves to git.breadway.dev/Breadway/bos-settings (full history
preserved via git-filter-repo) so its release cadence is decoupled from
BOS's own. breadhelp takes its place as this repo's workspace member: a
GTK4 onboarding/help center replacing the old bos-welcome/bos-keybinds
bash scripts with searchable guides, an interactive keybind viewer
(sourced from the new keybinds.toml, not parsed out of hyprland.lua or
hardcoded), a troubleshooting wizard with one-click fixes, and a proper
first-run tour. bos-netcheck extracts bos-welcome's network-check half,
which still needs to run every login independent of breadhelp's own
first-run gating.
hyprland.lua's keybinds/settings/monitors/autostart are now JSON-driven
(binds.json/settings.json/monitors.json/autostart.json) with every
loader pcall-wrapped and falling back to hardcoded defaults per field on
bad or missing config, so bread* apps (bos-settings' new editors, and
breadhelp's keybind viewer) can read/write this config without ever
being able to leave the compositor unable to start.
CI's package.yml now builds breadhelp instead of bos-settings on tag
push; bos-settings needs its own equivalent workflow in its new repo
(not yet set up).
Verified against the actual cached mkinitcpio package (41-4), not assumed:
its shipped /etc/mkinitcpio.conf template is
HOOKS=(base systemd autodetect microcode modconf kms keyboard sd-vconsole
block filesystems fsck) — there's no "udev" token at all on a stock
install anymore, systemd is the base hook instead.
This silently broke two things:
- The existing plymouth-hook insertion (`sed 's/\budev\b/\0 plymouth/'`)
has been a no-op on every fresh install using a current mkinitcpio
package — the boot splash was never actually getting wired into the
initramfs, just failing quietly (the script's best-effort `|| echo WARN`
pattern doesn't catch a sed that "succeeds" by matching nothing).
- My own new encrypt-hook insertion from the previous commit had the same
flaw, and would have used the wrong hook regardless: `encrypt` is the
udev-based hook, systemd-based initramfs needs `sd-encrypt` instead.
post-install.sh now detects which base hook (systemd or udev) is actually
in HOOKS once, and uses the matching hook name for both plymouth
(unaffected by the choice, just needed the right anchor to insert after)
and LUKS unlocking (encrypt vs sd-encrypt — genuinely different hooks).
Also: avoid a redundant pacman -Sy in release-iso.yml's signing step —
the job already synced repos earlier in the same container.
yay (yay-bin, AUR-only like calamares/bibata) republished to [breadway] via
the same PKGBUILD + Forgejo workflow pattern, so users can reach the wider
AUR beyond bakery's bread ecosystem.
Disk encryption: Calamares' partition module already has LUKS support
enabled by default, but the checkbox led nowhere — no cryptsetup on the
live/target image, no mkinitcpio encrypt hook, no GRUB cryptodisk wiring.
An encrypted install would partition fine and then never boot. Added
cryptsetup, pinned luksGeneration to luks1 (GRUB doesn't support LUKS2 +
Argon2id), and post-install.sh now detects an encrypted root (lsblk TYPE
== crypt) and conditionally adds the encrypt hook + GRUB_ENABLE_CRYPTODISK +
--modules="cryptodisk luks luks2" on both grub-install passes. No effect on
a normal unencrypted install.
Secure Boot: self-signed via sbctl (shipped in packages.x86_64). BOS can't
ship a Microsoft-signed shim without going through Microsoft's own paid
UEFI CA process, so post-install.sh enrolls BOS's own keys automatically
only when the firmware is already in Setup Mode (sbctl status --json),
signs the kernel/bootloader, and leaves it alone otherwise — sbctl's own
pacman hook re-signs on every future kernel/GRUB update, no further
wiring needed.
Release signing: generated a dedicated Ed25519 "BOS Release Signing" key
(not reused from anything else), stored as the GPG_PRIVATE_KEY Forgejo
Actions secret. release-iso.yml now generates SHA256SUMS and a detached
SHA256SUMS.asc signature alongside every ISO upload; public key committed
at KEYS.asc with verification instructions in the README.
README updated: fixed a stale "greetd + tuigreet" line (breadgreet since
round 3), documented yay/encryption/secure-boot/verification.
github_url points to GitHub releases that aren't always published for
dev/patch versions (bread v0.6.4 exists on dl.breadway.dev but not on
GitHub). dl.breadway.dev is publicly accessible and is the canonical
source — use dl_url from the bakery index instead.
Blank lines inside a shell double-quoted string within a YAML literal
block cause the YAML parser to end the block early. Write the release
notes to a temp file with printf and pass --notes-file instead.
release-iso.yml runs on v* tag pushes (or workflow_dispatch) on the hestia
self-hosted runner. It:
- Boots an archlinux container (--privileged --network=host)
- Downloads all bakery ecosystem binaries from their pinned GitHub releases
- Builds bread-theme from source at the tag in bos-settings/Cargo.toml
- Runs build-local.sh with CI_BUILD=1 + LAPTOP_HOME=/build-home
- Uploads the ISO to a Forgejo pre-release
- Creates a GitHub release pointing to Forgejo (GitHub 2 GB limit workaround)
build-local.sh: add CI_BUILD=1 mode — rewrites the [breadway] pacman repo
URL to localhost:3002 instead of the Tailscale address, since the CI
container runs on hestia with --network=host.
bos-update: one command that updates both BOS channels — pacman -Syu (snap-pac
snapshotted) and bakery update --all — best-effort so one failing doesn't abort
the other. Baked into the live env and skel.
Shell: match the dev laptop's zsh. Ship Powerlevel10k + zsh-autosuggestions,
zsh-history-substring-search and zsh-syntax-highlighting, sourced from the distro
packages (no oh-my-zsh framework) in the correct order, plus the dev .p10k.zsh.
Powerlevel10k is AUR-only, so it's republished to [breadway] via
packaging/powerlevel10k + a CI workflow (builds libgit2 + gitstatus from source),
same pattern as bibata / zen-browser-bin. skel/.zshrc keeps the BOS QoL aliases
and pywal palette import, with `update` aliased to bos-update.
Bibata is the chosen BOS default cursor but is AUR-only, so mirror the
prebuilt -bin package into the [breadway] repo the same way calamares and
zen-browser-bin are. The workflow clones the triggering branch (not the
default branch) so it can build from iso-boot-fix, and uses the scoped
REGISTRY_TOKEN for publishing.
Calamares isn't in Arch's official repos, so BOS vendors the PKGBUILD and
publishes a built package to the [breadway] repo. All its deps are official
(kpmcore, qt6-*, yaml-cpp). Also drop the nonexistent calamares-qt6 from the
package list (calamares 3.4.x is already Qt6).
bos-settings was scaffolded but never compiled. Fixes:
- main.rs: import gtk4::prelude (connect_activate/run)
- window.rs: disambiguate WidgetExt::display(); drop unused GBox import
- hyprland.rs: Label has no set_monospace -> use the monospace CSS class
- theme.rs: drop unused prelude import
Also switch package.yml to secrets.REGISTRY_TOKEN (scoped write:package),
since the auto Actions token is not authorized for the owner registry.
- package.yml: use correct Arch registry upload (octet-stream + binary body
+ PUT /api/packages/Breadway/arch/os), drop --privileged, remove
actions/checkout (archlinux image has no Node) in favour of a manual
shell clone, use the built-in Actions token instead of a stored secret,
and --nocheck (tests belong in CI, not packaging)
- mirror.yml: clone --mirror + explicit refs/heads + refs/tags push with
--prune, instead of pushing refs/remotes pollution from a checkout
- pacman.conf: correct Server URL to the Forgejo Arch registry format
Requires only the GITHUB_MIRROR_TOKEN secret (GitHub PAT, repo scope) for
the mirror job; package publishing uses the automatic per-run token.
- .forgejo/workflows/mirror.yml: mirrors every push/tag to GitHub
- .forgejo/workflows/package.yml: builds PKGBUILD on tag and publishes
bos-settings to the Forgejo Arch package registry (distrib=breadway)
- iso/pacman.conf: replace placeholder repo.breadway.dev with the actual
Forgejo package registry URL
Requires two Forgejo secrets:
GITHUB_MIRROR_TOKEN — GitHub PAT with repo push scope
FORGEJO_TOKEN — Forgejo token with package:write scope
