bos is ISO-only (release-iso.yml); it has never been bakery-distributed.
This file was a byte-for-byte copy of bos-settings/bakery.toml (name,
binaries, description all describe bos-settings, not bos) and isn't
referenced by the bread-ecosystem registry or any workflow in this repo.
DESIGN.md already documents that bos-settings — not bos — is the one
meant to get a bakery.toml and a registry entry.
- 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.
breadhelp's own repo builds cleanly but hasn't been published yet (see
git.breadway.dev/Breadway/breadhelp package.yml — needs REGISTRY_TOKEN
added to that repo's Actions secrets). Re-add once a tag publish
succeeds.
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.
Replaces the old in-window onboarding wizard with a real screen-wide
tour: dim + spotlight cutout around the actual on-screen component
(breadbar, breadbox), floating callout teaching the shortcut, and
event-driven confirmation via real Hyprland/breadd signals instead of
click-through fakery.
The sed matched snapper's default config template text exactly
(ALLOW_USERS=""), so any drift in that template across snapper versions
made it silently no-op -- leaving ALLOW_USERS empty and every non-root
snapper call (including bos-settings' Snapshots page) failing with
"No permissions." forever, with no error surfaced anywhere at install
time. `snapper -c root set-config` is the stable API regardless of
template wording.
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).
Confirmed on the test laptop's real install: /etc/snapper/configs/ was
completely empty post-install — snapper create-config failed silently and
BOS's advertised snapshot/rollback feature was entirely non-functional,
despite snapper-cleanup.timer being enabled and grub-btrfsd active (both
harmless no-ops with no config to act on).
Root cause is the known chroot-specific busy-mount race already documented
in this section's comments, but the existing recovery (retry umount 5x,
then one lazy-unmount fallback) wasn't sufficient on this hardware — a
lazy unmount detaches the mountpoint from the namespace immediately, but
whatever was holding it busy can take a moment longer to actually release,
and the immediately-following rmdir/create-config both fail if anything
still references /.snapshots at that instant.
Wrap the entire unmount → rmdir → create-config → cleanup → remount
sequence in an outer retry loop (checking whether the config file actually
exists before each attempt and after the loop), add a settle delay after
the lazy-unmount fallback, and turn the final failure into a loud ERROR
instead of a warning that's easy to miss — a system silently shipping
without snapshots is worse than one that's slow to set them up.
