A catalog photo whose bytes match another library photo got the generic develop defaults, so a raw
with no white balance or lens setting in the catalog lost its as-shot white balance and embedded
lens corrections and rendered unlike a file import. It now gets the import defaults (camera
defaults plus the default preset), as a file import does, before the catalog's settings go on top.
Show in Library selected the lowest mapped photo id, which can be a master left in Recently Deleted
whose new virtual copy the import added; All Photos doesn't show it. It now selects the lowest
mapped photo not in Recently Deleted, and the button is left out when there is none.
Tests: a content-duplicate raw with no catalog settings equals its camera defaults (as-shot WB,
lens profile on); Show in Library skips a trashed mapped photo and offers nothing when only
trashed or vanished ids are mapped.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The new record for a catalog photo whose bytes match another library photo copied that whole
record and reset a few fields, so the other photo's edits, history, versions, ratings and written
metadata (title, keywords, face regions) carried over, from a trashed photo too. It now starts as a
new photo and takes only what the bytes determine: format, size, kind, capture time, camera EXIF,
GPS, focus point, content hash, embedded lens data and preview-only state. The catalog's own
settings and metadata apply on top as before.
Tests: the duplicate test gives the other photo edits, history, a version, a title, keywords and a
Local baseline and checks none reach the new record; a reimport after a master and its virtual copy
were trashed counts each once.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A catalog photo whose file matched a photo in Recently Deleted by content was cloned with the trashed
record's `deleted` flag (and its virtual-copy fields), so it landed in Recently Deleted while the report
counted it as imported. A new virtual copy of a trashed master did the same. Both are now live records,
as Create Virtual Copy already does.
Catalog photos matched by path to a trashed photo stay there (the Lightroom import's OnDeleted::Skip,
#706); the report counts them as `inRecentlyDeleted` and the result window says so in one line.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
AGENTS.md (and CLAUDE.md where present) gets a CI workflows section: workflows only call
craft-common-actions at @main, with no other jobs; feature and fix PRs don't touch CI and
link or open a craft-common-actions issue (a PR only for a small fix that is safe for
every app and does not increase CI time); legacy jobs
aren't added to and move only as their own task, staying until a shared workflow runs them.
windows-arm64.yml moves from its SHA pin to @main. The pinned revision is on
craft-common-actions main and the workflow (and the actions it calls) is identical
there, so nothing changes in behaviour.
* Honor CARGO_BUILD_TARGET in FreeBSD packaging for aarch64 release builds
package.sh always built for the host and took the arch from uname -m, so a
cross build (aarch64 in an x86_64 FreeBSD VM) would read the wrong target
directory and name the archive after the VM. With CARGO_BUILD_TARGET set,
pass it to cargo, read target/<triple>/release, and take the arch from the
target. Unset keeps the old behavior.
* Reject unknown CARGO_BUILD_TARGET in FreeBSD packaging
Only the two FreeBSD triples are packaged. Any other target now fails before the
build instead of being labelled x86_64.
* Skip the --version smoke run for cross-built FreeBSD packages
A binary built for another target cannot run on the build host, so under set -e
the run would fail the release after the archive is written.
