The profile mixed vintages: most refs carried pin-era line numbers while
the Game Express note already named the HEAD position, which reads as a
blank line at the pin. Everything now describes one revision. The only
content change in the cited blocks is LoadMediaFromZipFile taking a
softpatching flag, which decides nothing about which BIOS is read.
profile_sync follows content, so a ref that drifted still anchors where
the cited text went. That is drift detection working, and it cannot
answer the only question a MAME romset ref asks: does this line declare
this set. It flagged five refs in one driver file where nineteen were
stale, the fourteen others having been relocatable somewhere plausible.
mame_ref_audit asks the stronger question and found ninety-two across
the four profiles whose upstream still moves: mame 66, mamearcade 18,
mamemess 6, groovymame 2. Each had exactly one declaration to point at.
The frozen generations, mame2009 through mame2016, come out clean, which
is the check saying it finds drift only where drift can happen.
The set name is argument 1 of the machine macro. Matching it anywhere on
the line matches every clone naming it as parent, which is most of a
driver, and comments are stripped first because a declaration can sit
behind one. A set no machine declares is reported as not judgeable, not
wrong: device archives take their DEFINE_DEVICE_TYPE shortname.
profile_sync flagged five refs in src/mame/tvgames/xavix.cpp. Checking
each entry against the line that declares its own set showed nineteen
were wrong, the whole e-kara and XaviX family: ekara cited 2956 where
the pinned revision declares it at 2878. The fourteen the tool passed
were relocatable by content, so they anchored somewhere plausible; that
is drift detection working, and it is weaker than asking whether the
cited line declares the set the entry names.
Every ref now names the CONS line of its own set at the pinned
revision, checked by matching the set name on that line rather than by
anchoring.
Saying those profiles would stay open no matter what was wrong. A dead
forge is a verifiable fact, and a fact can be recorded: upstream_gone
carries why, and the profile stops being an open problem. The refs
describe the last revision anyone could reach, which is all any reader
can ask of them.
The declaration is guarded rather than trusted, because a forge can come
back and a profile that keeps asserting a death nobody rechecks is worse
than one that fails loudly. Declared and unreachable reports as a
recorded fact; declared and answering reports as the contradiction it
is, and the profile has to be read again.
yuzu and suyu carry GitHub's 451. citron carries the loss of
git.citron-emu.org and the squatter now sitting on the .com. Each names
what was probed and when, so the next reader retraces it rather than
repeating it.
The refs carried paths from a revision newer than source_commit, so the
profiles described two trees at once. rvvm is the plain case: the file
is src/rvvm.c at the pin and src/core/rvvm.c at the revision its refs
were written against, and citing the second against the first reads as a
file that vanished.
The diagnostic added for this named all three in one pass, and each cost
one line. rvvm 3 refs, boom3 4, applewin 1, all anchored.
A ref whose file is absent at the pinned revision reported "pin revision
missing", which reads as code that vanished. When the same file is at
HEAD and the cited range fits it, nothing vanished: the ref was written
against HEAD while source_commit still names an older revision, and the
profile describes two trees at once. The reason now says so, because the
fix is the pin and not a hunt for a move that never happened.
This is the state three profiles were left in during their own
reprofiling, against a warning the repository already carries. A range
that overruns HEAD stays a plain miss, and a file absent from both
revisions is unchanged.
Refs written at the new line numbers while the pin still named the old
revision left the profile describing two trees at once. The gpu cvar is
the clearest case: at the pin it sits in xenia_main.cc, at the revision
this profile now names it moved to emulator.cc beside the code that
reads it, and citing one against the other reads as a blank line.
The rest is a plugins.toml path join that stopped embedding a backslash,
and a cvar description that says DXIL validator where it said DXIL
shader compiler. 31 refs, all anchored.
The D3D12 backend used to load dxcompiler.dll and dxil.dll and refused
to start without the compiler. It now compiles shaders through Mesa and
keeps only the signer: D3D12 rejects an unsigned shader, so
PipelineCache::Initialize stops on IsSignerAvailable() and asks for a
recent dxil.dll. dxcompiler appears nowhere in the tree any more, and
the installer extracts that one entry from the same pinned archive.
The profile still declared dxcompiler.dll required, so it sent people
after a file the emulator stopped reading. The gpu cvar moved to
emulator.cc beside the code that reads it.
flash.html, swfobject.js and manifest.json ship in the release and exist
in no revision of the source tree: the profile marks them bundled. Cited
behind the repository's own name, the resolver stripped that name and
looked for them in the tree, where they have never been. Cited behind
ArcadeFlashWeb-release they read as what they are, an artefact no
declared revision can confirm or deny. 21 refs, none left to read.
Refs were written with the repository's own name in front, so each read
as a rename to the path without it. The six changed blocks are a source
file added to the build list, XbdmModule loaded behind a console_type
check for an anti-cheat, a devkit XEX1 key compiled in beside the retail
one, a reworded log line, wider Unicode ranges for the glyph set, and a
Windows branch that picks up an already-loaded renderdoc.dll. None of
them changes a file the user supplies. 36 refs, all anchored.
emu-ex-plus-alpha carries fourteen subprojects and each holds its own
src/main/Main.cc, options.cc, EmuMenuViews.cc and system.ccm. Written
without PCE.emu/ in front, those six refs matched fourteen paths and the
directories the profile already cites could not narrow them, so each
reported absent at its own pinned revision. Every other profile in the
family already wrote the prefix. 16 refs, all anchored.
Four Switch profiles were unverifiable and said so on stderr every pass.
yuzu and suyu answer 451, citron's host stopped resolving, and
git.eden-emu.dev returns 403 to anything that is not a browser. Each
aborted its own report, so nothing could be said about any of them, and
the noise repeated on every run over the whole corpus.
A withdrawn forge is now a fact rather than a failure. GoneError covers
451, 410 and a host that does not resolve; none is retried, since three
attempts with backoff end in the same place. Those profiles land in
their own summary bucket, out of the review backlog where nobody could
act on them anyway. A 403 stays what it was, a refusal, because small
Forgejo instances behind anti-bot filters issue it routinely.
A profile can now name a source_mirror, consulted after source and
upstream so a live primary always decides attribution. Reaching it took
two more changes: a repository that refuses is muted for the rest of the
pass instead of ending it, keyed by host as well as slug because a
mirror carries the same slug on another forge; and a refused miss is not
cached, or the mute would answer for the mirror that was about to be
asked.
eden now reads from its Codeberg copy, which holds the same head and the
pinned commit: 5 refs, all anchored, where the profile could not be
checked at all. yuzu, suyu and citron have no mirror that serves
content, and now say so once instead of failing loudly.
VPX moved file location into one class. FileLocator holds the read-only
application path and the preferences path, and picks between two layout
modes from where the application ini sits: AppPrefData splits static
data, settings and tables across three roots, AppOnly keeps everything
in the application folder. The profile still described m_szMyPath and
m_szMyPrefPath, identifiers the tree no longer carries.
Script lookup changed shape with it. SearchScript walks ten locations
case-insensitively, rooted on the table's own folder rather than the
working directory, where the profile documented seven. The editor's
completion parser left that search entirely: ParseVPCore opens core.vbs
at the Scripts subfolder alone and warns when it is absent.
The PinMAME root now prefers a pinmame folder beside the table before
the global setting and the platform default. vpx.html is served by the
web server, the LiveUI no longer naming it.
Four PinMAME citations read as external again: the project word is only
recognised behind a list delimiter, and one of them sat behind "at".
41 refs, 37 anchored, 4 external, none left to read.
MIN_BIOS_SIZE fell from 4 MB to 2 MB (BiosTools.cpp:16), which is what
admits the Namco System 246/256 COH-H chip dumps: those are 2 MB where a
console image is 4. The profile still declared the old floor, so it
described a gate the code had stopped applying.
Three changes travel with it. A COH-H board is region 11 rather than 8.
Its description is built from the EXTINFO serial, because Sony left the
version and date fields identical across those BIOSes, and the three
serials the code names resolve to System 256, System 246 Rack C and the
COH-H board. The ROM window is zero-filled before the read so its unused
upper half cannot retain the previous image.
The picker follows: .7d and .8g are accepted extensions, r27v1602f a
name hint. Both dumps are already in the collection, byte-identical to
the r27v1602f members of the MAME sys246 and sys256 sets, and the .7d is
the same content as 246C.bin, which Redump catalogues as Namco System
246 Rack C with the very serial the new code maps.
97 refs, all anchored, pin moved to the revision they describe.
The cited blocks moved by seven lines and their bodies changed only
where bfunction gave way to std::function: {&DSP1::read, &dsp1} is now
memfn(&DSP1::read, &dsp1). Which ROM is loaded, under what name, size
and hash, is untouched. Diff read before the recale.
LinApple 3.0.0 moved every ROM out of hand-written byte arrays into
res/roms/*.rom, which scripts/generate_roms.sh compiles into
EmbeddedRoms.cpp behind an ENABLE_ROM_* macro. The bytes survived the
move: every hash this profile recorded against the old string literals
matches the image that replaced it.
The macros are what matters. ENABLE_ROM_CLONE_BASE64A,
ENABLE_ROM_CLONE_PRAVETS and ENABLE_ROM_CLONE_TK3000E are OFF in the
default build, so Base64A, Pravets 82/8M/8C and TK-3000 //e refuse to
start: mem_initialize finds no rom_data, names the cmake flag and the
--rom option, and returns -1. Five system ROMs the user has to supply,
none of them documented until now. The collection already held them.
Also new: icon.bmp, which the SDL frontends read from disk through the
data search path, and the J-Plus system ROM the old profile did not
list. The tree behind the old refs is gone, so the notes describe the
one that replaced it: five frontends, src/core, src/apple2, and a
program_dir still declared and never assigned.
38 refs, all anchored. 9 of 9 files present.
A ref citing a bare filename, the way prose does, was matched against the
HEAD tree alone. A file that moved since the pin then resolved to its
HEAD path, which does not exist at the pin, and the ref reported GONE
with "pin revision missing": it failed for the one reason it never
should, its own success at HEAD.
The pin tree is searched first, HEAD stays the fallback, and the rename
search carries the pin path forward as it does for any written path.
This is what the resolver already documents for prefixed and suffixed
paths; the bare-name branch was the one that did not follow it.
linapple cites Memory.cpp, src/Memory.cpp at its pin and
src/apple2/Memory.cpp today. Its refs now name where the code went
instead of reporting it missing.
Upstream moved under 145 profiles: 679 refs shifted and 452 followed a
renamed file, against 6,483 that still anchor where they were written.
The recale rewrites the located ranges only, keeping the annotations and
the sentences that carry them, and 106 pins advance in the same commit
because refs and source_commit name one revision or the profile
describes two at once.
Nothing here was guessed. The 183 refs that are CHANGED, GONE or
AMBIGUOUS are untouched, and the 57 profiles holding them keep their old
pin until someone reads the diff: profile_sync refuses to recale a
profile while any of its refs needs a re-read. trident kept its pin too,
its annotated ref being one the writer will not rewrite.
--backfill-commits and --realign-prose have always printed what they
would write. --rebase-refs and --bump-commit took the flag and printed
nothing, so the only way to read a plan was to let it happen, and the
recale and the pin had to be done in two full network passes with
--force in between.
Both now plan. The plan runs the production write path over a throwaway
copy rather than a parallel branch, so it cannot drift from the write,
and the planned bump reads the text the recale would have left: a pin
held back by prose the same pass would move is no longer reported as
blocked. One pass does both, recale before bump on each profile.
bump_commit also stopped announcing a rewrite of the pin to the value it
already held. On the corpus that was 126 of 232 announcements, which
buried the 106 profiles that did move.
SHA256SUMS.txt sat beside the artifacts it vouches for, so whoever could
rewrite a release rewrote the list with it. The packs were already
reproducible, which answers corruption and lets a third party rebuild an
archive byte for byte; nothing answered a rewritten release.
The list is now signed with an ed25519 key kept for this alone, and the
public half is allowed_signers at the repository root, so verification
does not go through the release page: ssh-keygen -Y verify against the
committed file, then sha256sum --check. Rehearsed on all three outcomes:
a good signature, a tampered pack caught by the sums, a rewritten list
caught by the signature.
The release steps sign and upload the signature, the README points a
downloader at the procedure, and the reproducibility section says what
each half proves. Rotation keeps retired lines so past releases stay
verifiable. Three tests hold the trust root, the signing step and the
documented principal in agreement.
validate.yml triggered on pull_request alone, and it holds the only
unittest invocation in the repository: deploy-site.yml stops at
validate_schemas, generation and the freshness diff. Work lands on main
by direct push far more often than by pull request, so 1,318 cases were
guarding the road almost nothing takes.
The suite and the schema check now run on both events. validate-bios and
label-pr read pull request context and carry an event guard. The
concurrency group falls back to the ref, so a push series collapses to
the tip: what stays verified is the head of main.
The path lists are spelled out per event because the workflow parser
reads no YAML anchor, which PyYAML would have accepted in silence. Four
tests hold the wiring: the suite reachable from a push, the two path
lists equal, every job reading pull request context guarded, and no
anchor in any workflow.
The field reference carried the same attribution the FAQ did:
known_hash_adler32 described as Dolphin's IPL files, when dolphin.yml
declares it on dsp_rom.bin and dsp_coef.bin. The guard now scans every
wiki page rather than the FAQ alone.
The home page and the stats export counted every file carrying a
provenance record, the provenance page and the README only the system
files. The site published 553 and 566 for the same quantity, one click
apart, and the export paired the wider count with composition.systems as
its denominator. common.count_catalog_matched is now the single source,
scoped to the systems bucket.
The FAQ had drifted from the profiles it describes: MAME pinned at 0.287
against 0.289 in mame.yml, Adler-32 attributed to Dolphin's IPL rather
than the DSP ROMs that carry known_hash_adler32, and the per-emulator
verbose report named as the only content check on an existence platform,
which skips the DISCREPANCY line the platform report raises itself.
Tests read both sides: no generator may count matches inline, and each
FAQ claim is checked against the profile or the script that owns it.
Abdessamad Derraz