fastplong 0.7.1 (new formula) - #301438
Conversation
|
Status update: the upstream fix for the Once either lands in a release, the |
e225523 to
0b164ef
Compare
|
Updated to 0.7.1, released today, which is the first tag containing the upstream fix (OpenGene/fastplong#44, merged on 2026-09-04). Its install:
mkdir -p $(BINDIR)
install $(TARGET) $(BINDIR)/$(TARGET)So the The same Makefile bug exists in fastp, fixed by OpenGene/fastp#714 (merged), but no release carries it yet, so |
|
馃 An automated task has requested bottles to be published to this PR. Caution Please do not push to this PR branch before the bottle commits have been pushed, as this results in a state that is difficult to recover from. If you need to resolve a merge conflict, please use a merge commit. Do not force-push to this PR branch. |
HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>?brew test <formula>?brew audit --strict <formula>(after doingHOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>)? If this is a new formula, does it passbrew audit --new <formula>?AI-assisted contribution by Claude Code (Claude Opus 5) of ~85% of the work: the AI wrote the formula and ran
brew style,HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source,brew test,brew audit --strict --newandbrew linkage --teston my machine. I reviewed the formula and those results before opening this PR, and will answer maintainer questions and review comments myself. The commit carries no AI attribution trailer.Built and tested locally on macOS 26.6.2 running arm64.
fastplong is the long-read counterpart to
fastp, from the same authors, and shares its dependency set (highway,isa-l,libdeflate).The test writes a two-read FASTQ where the second read has a low-quality head, runs the trimmer, then parses the emitted
report.jsonto assert the input read count, so it exercises the FASTQ output and the JSON/HTML reporting rather than just the binary starting up.