[castrojo]

bluefin-common PR

What does this change?

Configure Damask's Slideshow default to use the user's existing Homebrew Bluefin Extra artwork through a stable per-user folder pointer.

• Resolve the installed bluefin-wallpapers-extra cask's existing flat images directory.
• Point ~/.local/share/backgrounds/bluefin-extra at that directory with one symlink, refreshed before the first-run settings gate so package upgrades do not leave a versioned path in app settings.
• Grant Damask read-only access to that cask root; access to the backgrounds symlink alone does not expose its target.
• Seed fresh profiles with that folder. Existing keyfiles and wallpaper/source choices remain untouched; fresh profiles keep active-source='none'.
• Skip setup without stamping when Homebrew or the artwork is absent.

No artwork downloads, copying, conversion, Containerfile changes, app fork, extra named provider, package-list changes, or existing-profile migration. This does not repair the separate outdated Lazy Days release asset.

Why?

Refs #1161.

Damask reads immediate image files from one directory. The cask's user-published wallpaper folders are nested, so the existing flat Homebrew image directory is the supported collection source. The previous default selected system wallpapers instead of the extra artwork.

Verification

• bats tests/test_damask_setup.bats tests/test_damask_service.bats: 13 passed, one systemd-analyze check skipped because the isolated Alpine environment lacks that binary.
• Shellcheck passed for 25-damask-setup.sh.
• python -m pytest -o addopts='' tests/test_skill_docs.py -q: 17 passed.
• just check and pre-commit run --all-files passed.
• Runtime smoke: stock Damask 0.3.2 enumerated all 13 installed Homebrew images. Its GNOME 50 Flatpak runtime decoded the original SVG/JXL files directly. The matching Slideshow UI rendered artwork and displayed the stable user folder; no image conversion was needed.
• The operator-requested client configuration was mirrored separately; that per-user state is not part of this PR.

How this PR merges

Prow requests two reviews from OWNERS. A reviewer who is not the author comments /lgtm (removed on every push), an OWNERS approver comments /approve or approves in GitHub, and Common also needs 2 approving GitHub reviews. With green checks, Prow puts the PR in the merge queue. /hold pauses it. See how issues and PRs work here.

Checklist

• PR title follows Conventional Commits
• just check passes
• pre-commit run --all-files passes
• Skill doc updated
• Agent/skill documentation links remain valid
• CI is green after PR creation

AI attribution

The commit includes:

Assisted-by: GPT-6.1-SOL via GitHub Copilot
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

CI results

Passed for 986b103:

• Unit Tests
• Validate PR
• Build: x86_64 and aarch64
• PR E2E: GNOME 50 common suite

[github-actions]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: castrojo

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS [castrojo]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[hivecommons-hive]

Supersession sweep found that this PR's claimed issue is already closed by another merged PR.

• Claimed issue: common#1161
• Closing PR: #1186

Decision needed (@projectbluefin): this PR appears to duplicate #1186, which already merged: every file it touches was also changed there (the sweep compares file names, not contents). Recommended: close as superseded. Other options: keep open, or merge anyway.

This comment is edited in place by the supersession sweep; it is not duplicated.