6b0035d19769346baffe193ef9419c269d46f8d8
max
  Wed Sep 9 06:09:41 2026 -0700
hprc2annot: pcLAI column 10 is the ancestry centroid, not a segment coordinate

Reading the pcLAI authors' own format description
(github.com/AI-sandbox/hprc-pclai, README "Output format (BED)") while building
the same annotation as a native hg38 track showed that column 10 of the source
BED had been described wrongly here. It is not the PCA coordinate of a longer
ancestry segment the window belongs to; the authors call it the centroid, the
discretized pcLAI ancestry of the window written as the PCA centroid of its
ancestry cluster. That is why it only ever takes four values -- four clusters,
not four long shared segments. The old reading also implied a segmentation step
the method does not have: pcLAI predicts one coordinate per window, and the
blocks visible in the display are runs of windows with similar predictions.

Field renamed pcaSegment -> centroid in pclai.as with the description corrected,
and the mouseOver, the detailsScript exportFields and the description page
follow. The README also settles that windows are a fixed 1000 SNPs rather than a
fixed number of bases, and that thickStart is specified to equal chromStart, so
the occasional thickStart == chromStart-1 the converter works around is a bug in
their files rather than something we misread.

A field name and its description live inside each bigBed, so editing pclai.as
does nothing to a built collection. hprc2annotRewriteAs.sh re-emits a built
bigBed with the current .as -- no re-download, no column change, item count
checked across the round trip, and safe to re-run, unlike hprc2annotFixBed.sh.
All 460 pclai.bb were rewritten with it. Worth knowing: those files had been
built from an older pclai.as than the tree and nothing had noticed, so this is
the tool to run after any .as description edit.

genark: the "...Url" inside a detailsScript value must not be rebased the way
bigDataUrl is. hgc resolves a relative detailsScript Url against the track's own
bigDataUrl when it builds the details page, and bigDataUrl has already been
rebased, so the prefix landed twice: the pcLAI scatterplot had been asking for
contrib/hprc2annot/contrib/hprc2annot/pclaiRefPanel.json and quietly getting
nothing on every GenArk hub. In this layout the panel file is symlinked beside
the .bb, so relative-to-the-.bb is the bare file name; rebaseBeside() does that
and is idempotent, so addContrib can be re-run.

refs #35415

diff --git src/utils/genark/genark src/utils/genark/genark
index 2f962cbb9d0..c645c735964 100755
--- src/utils/genark/genark
+++ src/utils/genark/genark
@@ -180,47 +180,59 @@
 
 
 def rewriteTrackDb(srcPath, name):
     """Return the trackDb text with local bigDataUrl/html paths made hub-root
     relative (contrib/<name>/...). Remote (http/https/ftp) bigDataUrls and
     already-prefixed paths are left untouched."""
     out = []
     prefix = "contrib/%s/" % name
 
     def rebase(val):
         """Make one local path hub-root relative; leave a URL or a done path alone."""
         if re.match(r"[a-z]+://", val) or val.startswith(prefix):
             return val
         return prefix + os.path.basename(val)
 
+    def rebaseBeside(val):
+        """Make one local path relative to the .bb it is resolved against, i.e. the
+        bare file name. Leaves a URL or an absolute path alone. Idempotent."""
+        if re.match(r"[a-z]+://", val) or val.startswith("/"):
+            return val
+        return os.path.basename(val)
+
     for line in open(srcPath):
         stripped = line.lstrip()
         indent = line[:len(line) - len(stripped)]
         m = re.match(r"(bigDataUrl|linkDataUrl)\s+(\S+)\s*$", stripped)
         if m:
             out.append("%s%s %s\n" % (indent, m.group(1), rebase(m.group(2))))
             continue
         m = re.match(r"html\s+(\S+)\s*$", stripped)
         if m:
             out.append("%shtml %s\n" % (indent, rebase(m.group(1))))
             continue
-        # detailsScript carries its file in a "...Url" key inside a JSON value, and
-        # the collection writes it relative to the accession dir. In this layout the
-        # data sits one level deeper (contrib/<name>/), so rebase it the same way.
+        # detailsScript carries its file in a "...Url" key inside a JSON value.
+        # This one must NOT be rebased like bigDataUrl: hgc (bigBedClick.c) resolves
+        # a relative detailsScript Url against the track's own bigDataUrl when it
+        # builds the details page, so prefixing it here as well makes the browser
+        # ask for contrib/<name>/contrib/<name>/<file> and the fetch silently fails.
+        # The collection writes it relative to the accession dir, where the file
+        # sits beside the .bb; in this layout both move into contrib/<name>/
+        # together, so relative-to-the-.bb is just the basename.
         if stripped.startswith("detailsScript."):
             line = re.sub(r'("[A-Za-z0-9_]*[Uu]rl"\s*:\s*")([^"]+)(")',
-                          lambda m: m.group(1) + rebase(m.group(2)) + m.group(3), line)
+                          lambda m: m.group(1) + rebaseBeside(m.group(2)) + m.group(3), line)
             out.append(line)
             continue
         out.append(line)
     return "".join(out)
 
 
 def dropTopLevelTracks(text, trackNames):
     """Return the hub text with the top-level stanzas of trackNames removed.
 
     The assembly build can bake a snapshot of a contrib collection straight into
     its hub file, without our markers. Left in place those stanzas would collide
     with the block we add, giving the hub two "track <name>" entries.
 
     Stanzas in a useOneFile hub are separated by a blank line, so a dropped one
     runs from its "track" line to the next blank line or the next stanza. Only a