build(deps): bump escapepod-signal from v0.16.1 to v0.18.1 in /rust

[dependabot]

Bumps escapepod-signal from v0.16.1 to v0.18.1.

Release notes

Sourced from escapepod-signal's releases.

v0.18.1

Fixed

• signal classify no longer aborts when a tRNA body happens to contain the junction motif (#298). The CCA|adapter junction was located by requiring CCAGGC to occur exactly once per reference record, and that check ran before the common-arm check that actually identifies the junction. But the motif is just CCA plus the adapter's opening bases, and a 6-mer collides over ~75 nt of tRNA body in ~1.5% of records -- 4 of 282 in hg38, 51 of 3315 in danRer11. One such record aborted the entire run for that sample, and dropping the offenders is not neutral: 48 of danRer11's 51 are Glu, so it would remove most of one amino-acid family from a charging analysis. Candidates are now filtered by the arm first and uniqueness required of what survives, which resolves every record of both references to exactly one junction at the correct position. Two genuinely broken cases -- no arm-backed match, and several -- now report distinctly instead of being conflated with this benign one.

---

Which artifact

Artifact	Linkage	--gpu
…-x86_64-unknown-linux-musl.tar.gz	static (musl)	no
…-aarch64-unknown-linux-musl.tar.gz	static (musl)	no
…-x86_64-unknown-linux-gnu-gpu.tar.gz	dynamic, glibc ≥ 2.28	yes
…-x86_64-apple-darwin.tar.gz	dynamic	no
…-aarch64-apple-darwin.tar.gz	dynamic	no

The musl builds are the portable default and the right thing for an unattended installer to fetch. The GPU paths cannot be static — they dlopen their runtimes — so they ship in the single dynamically linked …-linux-gnu-gpu artifact instead, built against glibc 2.28 (RHEL/Rocky/Alma 8+, Ubuntu 20.04+).

What …-linux-gnu-gpu needs at run time

Only when --gpu is actually requested — otherwise it behaves exactly like the musl one. It expects a CUDA 12 runtime and cuDNN 9, with an NVIDIA driver ≥ 535 (the DTW kernels target the CUDA 12.2 driver API), and a CUDA-enabled libonnxruntime matching the ort 2.0.0-rc.13 it links.

Rather than assembling that by hand, see GPU acceleration, which covers the pixi environment that supplies it and how to confirm the CUDA execution provider actually loaded.

... (truncated)

Changelog

Sourced from escapepod-signal's changelog.

0.18.1 (2026-08-29)

Fixed

• signal classify no longer aborts when a tRNA body happens to contain the junction motif (#298). The CCA|adapter junction was located by requiring CCAGGC to occur exactly once per reference record, and that check ran before the common-arm check that actually identifies the junction. But the motif is just CCA plus the adapter's opening bases, and a 6-mer collides over ~75 nt of tRNA body in ~1.5% of records -- 4 of 282 in hg38, 51 of 3315 in danRer11. One such record aborted the entire run for that sample, and dropping the offenders is not neutral: 48 of danRer11's 51 are Glu, so it would remove most of one amino-acid family from a charging analysis. Candidates are now filtered by the arm first and uniqueness required of what survives, which resolves every record of both references to exactly one junction at the correct position. Two genuinely broken cases -- no arm-backed match, and several -- now report distinctly instead of being conflated with this benign one.

0.18.0 (2026-08-29)

Fixed

• The reads table is written in batches again, instead of one batch per file (#297). filter, merge, subset and split build the reads table with build_reads_table{,_remapped} rather than Writer, and those wrote the whole table as a single Arrow record batch however large it was — so read_batch_size on FilterOptions/MergeOptions/SubsetOptions was declared, defaulted, and never read. escpod filter asking for 10,000 rows per batch wrote 40,000 reads as one.

  Measured, for scale: MinKNOW writes ~10,000 reads per batch (1,575,748 in 158) and the pod5 Python package exactly 1,000 (17,919,658 in 17,920). Neither writes a whole file as one batch.

  It is not cosmetic for anything that reads escpod's output back. demux shards its reader threads by batch index and only emits a block at a batch boundary, so a single-batch file is read by exactly one thread whatever ESCAPEPOD_DEMUX_FILLERS says, and nothing reaches the GPU until the entire file has been decoded. On a 100k-read escpod-written file that was 11.2 s of a 19 s stage with the card idle, and it made every tuning knob look flat. Fixing it took that stage to 11.3 s with the first block arriving in 0.3 s and GPU utilisation going from 22-30% to ~60%.

  Every default is now 1,000, and the five CLI sites that overrode it (merge at 100,000, the rest at 10,000) inherit it, so the geometry has one definition. Note this never affected MinKNOW input, which was already many-batched: measured on a real 1.3M-read run, GPU utilisation is ~94% and the first block arrives in 0.4 s both before and after.

... (truncated)

Commits

• 3de501e Release 0.18.1 (#304)
• 88c5fb2 fix(classify): place the junction by the common arm, not by motif uniqueness ...
• 9d5ccd8 Release 0.18.0 (#303)
• 9c55685 build(deps): bump the noodles crates as a set (#302)
• 2a9268d fix(pod5): reads table written as one giant record batch; GPU reference scan;...
• 5e63930 perf(demux): stop the CRF GPU sessions spinning, and intern the annotate labe...
• b805647 Release 0.17.2 (#295)
• e2fba46 fix(cli): accept a directory of POD5 files, and never exit 0 on an unreadable...
• 28926e6 Release 0.17.1 (#288)
• 3b97638 ci(release): publish to PyPI last, after every build and the GitHub Release (...
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)