fix: bump vergen-git2 to 9.1 and pin hts-sys 2.2.0 so a fresh resolution builds again - #149
Merged
Merged
Conversation
vergen-git2 1.0.7 declares vergen ^9 and vergen-lib ^0.1. The new vergen 9.1.0 depends on vergen-lib 9.1.0, so any resolution that is not pinned by our Cargo.lock (cargo install, cargo-semver-checks in release-plz) pulls two vergen-lib versions into the build script and fails to compile. vergen-git2 9.1.0 is the matching release with the same builder API. Lockfile floor moves from rustc 1.85 to 1.91. Also correct the release-plz.toml comment: the semver check is on.
mrvollger
force-pushed
the
fix/hts-sys-pin-main
branch
from
September 18, 2026 15:08
2957af2 to
7cbf802
Compare
hts-sys 2.2.1 changed bindings that rust-htslib 0.46 relies on, so any resolution not pinned by Cargo.lock (cargo install, cargo-semver-checks) fails to compile rust-htslib. Pin hts-sys to the 2.2.0 the lockfile already held until rust-htslib is bumped. cargo-semver-checks also builds the published baseline crate from a fresh resolution. The 0.13.0 crate on crates.io still has vergen-git2 1.x, which no longer resolves against vergen 9.1.0, so the check can never pass for that baseline. Turn it off; conventional-commit bumping is what we rely on.
mrvollger
force-pushed
the
fix/hts-sys-pin-main
branch
from
September 18, 2026 15:20
7cbf802 to
6418612
Compare
hts-sys 2.2.1 did not change htslib; it regenerated bindings with bindgen 0.72, which renamed isize to isize_ and size_t to usize. And the semver check only needs to stay off until 0.13.1 is the published baseline.
mrvollger
changed the title
Open
mrvollger
added a commit
that referenced
this pull request
Sep 18, 2026
Forward-port to main of the 0.13.1 fix for #140, which shipped from `release/v0.13` in #142. ## Cause `--haps` was parsed on `CallPeaksOptions`, but `call_peaks_for_chrom` hardcoded `haps: false` when it built the pileup. The pileup never made H1/H2 tracks, so every peak printed the empty-track placeholder (`0 0 -1.0 0 0`) for both haplotypes. ## Fix `haps` moves from `CallPeaksOptions` into `PeakCallingParams`, which is what `call_peaks_for_chrom` receives. Both structs are flattened, so the flag name and help text are unchanged; `--haps` now appears among the peak-calling options in `--help` instead of last. union-peaks sets it false because BED intervals carry no HP tag. The second commit keeps `--haps` from costing more than it must. Per-haplotype tracks triple the pileup memory per chromosome, and about a third of that was FIRE element tracking on the H1/H2 tracks that nothing reads (only `all_data.fire_elements` feeds peak boundaries). The haplotype tracks are now built without it. ## Check `NAPA.bam` carries HP tags. `ft call-peaks --haps --min-fire-frac 0.5` on it: | | coverage | coverage_H1 | coverage_H2 | |---|---|---|---| | before | 95 | 0 | 0 | | after | 95 | 45 | 14 | A regression test pins these three values. The call-peaks snapshot and pileup tests pass. ## Order Merge into main after #149 and before #138. release-plz opens the 0.14.0 release PR on the first push to main after #149. Fixes #140 --------- Co-authored-by: Mitchell R. Vollger <mvollger@gmail.com>
mrvollger
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Twin of #148 for main, rebased onto #147 so the two do not conflict on the release-plz.toml comment. Merging this brings in #147's commit too; #147 can then be closed as included.
Same content as #148 plus the fix from #150:
semver_check = falselives in the[workspace]table.Do not merge until #132 (the 0.13.1 release PR on
release/v0.13) is merged. release-plz finds its open release PR by branch prefix only. A push to main with the semver check off would run release-plz-pr, find #132 by itsrelease-plz-branch name, and force-push 0.14.0 content onto it. Today the only thing preventing that is main's run dying in the semver check, which this PR removes.After #132: merge this first on main, then #141 and #138. release-plz then opens a fresh 0.14.0 release PR.