45 releases 94 tags

RSS feed

• v1.37.0 03169df5bf

  Compare

  v1.37.0 Stable

  dvb-projekt released this 2026-10-07 14:36:15 +00:00 | 73 commits to main since this release

  Added

  • dvb-WarpTune: calibration with clock search (opt-in per miner,
    calib_clock = true; this runs the chip above the owner's validated
    point and possibly outside the maker's specification and warranty — the
    devices page warns before the start). Before each voltage stage a clock
    stage runs: the Max stage climbs in 25 MHz steps above the hand point at
    the hand voltage and keeps the highest clock that passes the stability
    rule; the Eco stage walks down from the Eco cap at the curve voltages
    and keeps the best J/TH step, which becomes the Eco cap on Apply. A
    clock candidate is stable only when, over the whole window
    ([defaults] calib_window_s, 30 min) as maxima: fan ≤ 90 %, chip ≤
    target, VR ≥ 15 °C under its shutdown line, core current ≤ 95 % of the
    warn line, power ≤ max_watts and ≤ 95 % of the firmware's board
    limit, the draw on the supply ≤ 80 % of its rating, the pool's shares
    call the point healthy, the firmware's hashrate reads no more than 2
    points under the start clock's and the 1-minute chip error rate stays
    near the baseline measured at the start clock. The start clock (hand
    point, Eco cap) is the reference: judged on the hard limits and the
    shares alone, never on the firmware's reading or the error line, so the
    method always finds the owner's point at least (Nano 2026-10-04: both
    maker points failed absolute bars with the pool at 100 %). Any failure,
    a guard move included, ends the stage with the
    last stable clock; the search never goes above the maker's maximum,
    ladder_cap_mhz or calib_clock_max_mhz, and never raises the voltage
    above the hand voltage. A found Max clock becomes a beyond_spec
    ladder step (Max mode only); the hand point stays the restore point;
    Discard, Stop and a failed job take every added step out again; a
    restart puts them back from the journal (CalibApplied carries
    eco_cap_mhz and fan_target_c). A board on maker presets (BitForge
    Nano) gets its calibration with the opt-in; its presets stay.
  • dvb-WarpTune: the fan target is part of a calibration. The job records
    the firmware's fan target, stops when it changes under it, and the card
    shows the target a result was measured under (and that the result is
    for the old target once the owner moves it). After a Max clock stage
    that ended on the fan alone the card shows the trade-off and, with
    enough fan reserve at the last stable clock, suggests +2 °C — marked as
    an estimate — with a button: fan_target goes through the command
    path (POST /api/admin/tune/calib with target_c, audited as
    tune.calib.fan_target; sidecar POST /calib/{host}/fan_target/{°C}),
    the sidecar accepts only the suggested value, sets temptarget /
    pidTargetTemp on the device, journals it (fan_target) and raises its
    own target floor to fan target + 2 °C. Never applied on its own.
  • dvb-WarpTune: in operation, a calibrated step whose automatic fan runs
    over 90 % for 30 minutes is left for the step below and held off for six
    hours (seasonal drift). Every clock verdict is journaled with the
    window's maxima, mean chip temperature and chip error rate, so the
    error rate's temperature dependence can be fitted from the journal.
  • Devices page: the clock stages on the calibration card — the candidate
    under test with the window's maxima so far, every candidate as a chip
    (verdict and measurements in the tooltip), the clock found against the
    start clock, the fan trade-off and the fan-target button; the Start and
    Apply confirmations name the clock search and its risk. Eight languages,
    reviewed.
  • dvb-WarpTune: on ESP-Miner a chip the vendor table does not know gets
    its ladder from the board's own option lists under /api/system/asic,
    as NerdOS and WarpAxe boards already do under /api/v2/settings. A
    BM1370 Bitaxe keeps the vendor table; Forge-OS publishes no lists.
  • dvb-WarpTune, clock search: power supply reserve. psu_max_watts
    is the supply's continuous rating; the window's draw on the supply
    stays under 80 % of it (the overclocking guides' 20 % reserve), the
    board limit (max_watts, firmware maxPower) under 95 % as before.
    Unset, the rating of the supply the board ships with applies (Bitaxe
    Gamma 25 W, BitForge Nano 60 W; the board's, not the chip's — a
    NerdOctaxe gets none) — and a default never fails the hand
    point itself, only candidates above it; a board with neither gets no
    clock search until it is set (the start warns, the job notes it). Miners on
    one shared supply name the same psu_group: the sum of their draw
    counts (the others from their latest snapshots).
  • dvb-WarpTune: latched chip domains. Where the firmware publishes
    the chips' counters (WarpAxe hashrateMonitor), a domain at ≤ 5 % of
    its chip's best domain on two decisions in a row while that one runs
    is latched off — the voltage counts as bad on that point: the trial
    steps up, a calibration stage fails the voltage, a clock candidate is
    unstable, the way up is blocked; journal line domain_off; the devices
    page names it (domains_off). In Eco below the cap the step is left
    for the step above (worse J/TH than it reads) and held off. Octaxe
    chip 4, 2026-10-02: ~1.5 % lost, invisible to the shares.
  • dvb-WarpTune: a share vote short of the bar by less than its own noise
    (1/√n) is confirmed on a second window (twice the shares) before it
    counts — in the calibration and in the running voltage trial alike —
    unless a domain is off, the chip errors or the rejects say the same.
    The share history keeps the second window's shares. The Octaxe's Eco
    1180 on 2026-10-02 was one noisy window; the NerdQAxe++'s Eco floor
    walked 1190 → 1200 → 1210 on 94 % / 95 % over 200 shares at a flat
    0.18 % error rate on 2026-10-03. The calibration card shows the voltage
    the device runs under test (not the last one judged) and, while a
    second window runs, its share count (calib_confirming,
    calib_shares_needed 400).
  • dvb-WarpTune, calibration: a service restart in the middle of a
    voltage search sends the miner straight back to the search position
    (one step under the last good verdict) instead of walking down again
    from the voltage the pin writes, one 200-share window per step (Gamma
    2026-10-05: pinned at the applied 1120 mV with the search at 1030, a
    seven-hour re-walk). After a failure the search goes back to the
    voltage under re-check (the lowest good one above every bad one). The
    steps already judged are not judged twice.
  • dvb-WarpTune, calibration: calib_hard_min_mv (under [defaults] or
    per miner) replaces the firmware's lowest offered core voltage as the
    search's hard stop and may lie under the firmware's list — never
    under the board regulator's clean range: with WarpAxe's
    regulatorMinMv the value (and the trial's voltage_min_mv) is held
    to it, without the field the firmware's list stays the floor; the start
    warns and journals the clamp. The card names the voltage asked for
    (requested_mv) and the one set instead (clamped_mv). Every write
    under that list is read back on the regulator's measured output
    (coreVoltageActual — WarpAxe echoes the asked value in coreVoltage
    even when its driver refused it): taken (within 5 mV), the step counts and the
    search goes on; clamped, the stage ends at once as firmware_minimum
    with the clamped voltage (clamped_mv), the clamped step is no
    measurement and live control is not tripped. The Gamma's Eco stage on
    2026-10-05 was good all the way to the firmware's 1000 mV.
  • dvb-WarpTune: WarpAxe v0.1.16's coreVoltageRefused ends a floor
    search at once (no grace tick), and two chain restarts in a row after
    silent minutes at the present voltage (chainSilentRestartsSameMv)
    count as a dead voltage without waiting the dead ticks.
  • dvb-WarpTune: a voltage at which every chip goes silent (regulator
    output 0 mV, 0 GH/s) is a failed trial voltage as well as a dead step:
    held off in the trial memory (doubling per failure), the good memory
    at or under it forgotten, so the search never loops back to it.
  • dvb-WarpTune, calibration: a voltage judged more than once counts as
    its latest verdict says — an early short-window failure (the
    regulator's hold under 200 shares) that a full window at the same
    voltage overturned is no floor; good then bad stays bad. Gamma
    2026-10-05: 1080 failed at 73 % over 106 shares, passed at 114 % over
    227, and the floor search below it would have been wasted.
  • dvb-WarpTune, calibration: the configured floor is where the search
    starts, not where it stops. A stage still good at voltage_min_mv (or
    calib_max_steps under the reference) goes on down in 10 mV steps to
    the first bad voltage, never under the chip's hard minimum (the
    firmware's lowest offered core voltage; without one 100 mV under the
    start floor). The result says how it is bounded — floor_kind:
    bracketed, hard_minimum or open — on the stage and as
    calib_floor_kind on the badge. The Gamma's run on 2026-10-04 was good
    all the way to its 1100 mV floor and could only say "at least 1100".
  • dvb-WarpTune: a firmware stop is journaled with the firmware's account
    of it — overheatCause (hot / sensor / power), overheatLatched,
    overheatTrips, faultCause, the regulator's power_fault text and
    powerFaultCodes (WarpAxe ≥ 0.1.12; stock AxeOS gives the flag only,
    NerdOS the mode) — as a stop object on the sample of every decision
    and heartbeat while the stop lasts, and in the pause reason, the hold
    label and the step_bad line ("regulator stop (overcurrent; cause
    power, codes iout_oc)"). The Nano's trip at 07:09:50Z on 2026-10-03
    stayed unexplained because only the flag was kept.
  • dvb-WarpTune: the chip error lines follow the chip temperature per
    miner — error_temp_slope_pct_per_c and error_ref_temp_c (default:
    the target) move error_down_pct / error_up_max_pct, never under
    0.1 %; the clock search's baseline rule moves with the same slope. A
    NerdAxe Gaia (BM1373) measured −0.19 points per °C (2026-10-02), with a
    healthy baseline of 4–5 % at 960 mV.

  Fixed

  • WarpTune (audit 2026-10-07): noise robustness of the share
    verdicts. A calibrated voltage was raised 10 mV in operation on any
    share vote under 95 % from 400 shares on — a one-sigma miss at 400 —
    and never lowered again; the Gamma's Eco 1020 mV walked to 1050 in
    three hours at 0 % rejects. A vote short of the bar now waits for the
    double window unless it is clearly short (bar − max(10 %, 2/√n)) or
    a second witness says the same (a latched domain, the chip error line,
    the reject line, the firmware's own reading); a raise needs one of
    those or a double window short by more than its own noise; at most two
    raises per step a day; and after six healthy hours at a raised voltage
    the step goes back one trial step toward what the apply set (the
    journal's apply line is the floor). A clearly short vote on fewer than
    100 shares is no verdict on its own (the Nano's 1050 mV failed at 69 %
    over 68 shares with the firmware at 99 % and 0.42 % errors, and passed
    at 112 % over 205 later): from 100 shares on, or with a second witness.
  • WarpTune, clock search: a member of a psu_group silent for over 90 s
    counted 0 W on the supply, so the reserve looked free while that miner
    drew on. Its last reading counts on; silent for over 10 min, a
    candidate above the start clock is not assessable and fails with the
    member named (psu_silent).
  • WarpTune: a chip domain that latched off was answered with +10 mV per
    share window, which does not bring a latched domain back (NerdQAxe++
    2026-10-06: 1.5 h at 75–80 % until a two-second excursion to the hand
    point restored all 16 domains). On a fresh latch the regulator restores
    the hand point once (past the pin), holds the latch voltage off at that
    step from then on (the learned voltage goes up two trial steps, a
    calibrated step raises its entry), and a second latch at the step
    within two hours marks it unstable and steps down. A running
    calibration pauses on the bump with the reason on the card instead of
    failing the stage; resume starts the reference over.
  • WarpTune, domain-latch follow-up (NerdQAxe++ 2026-10-07 07:10Z: after
    the bump the Eco cap walked 800 → 725 → 650 → 600 one decision each
    and, with a few OTA restores, tripped the write breaker at 12 writes):
    the way back from a bump is one write to the point the mode wants —
    the whole way down, without dwell, past steps held off; the bump and
    that return write neither ask nor count towards max_writes_per_hour
    (restores never did); a step with a latch in its past is written no
    lower than the latch voltage plus two trial steps, trial window or
    not; and more than three bumps an hour hold the miner at the hand
    point for an hour with the reason in the journal. The way down passes
    over a step marked unstable also past max_steps_down.
  • WarpTune: the latch memory lived in memory only — a service restart
    forgot the voltage floor at a latched step, the per-step bump guard
    and the hour's bump count (NerdQAxe++ 2026-10-07 07:49Z: right after
    a restart the Eco walk wrote 700 MHz @ 1180 mV, held off there 37 min
    earlier). A start seeds all three from the journal's domain_off
    lines of the present epoch (floors kept for seven days).
  • WarpTune: a latch's voltage floor could sit above the hand voltage —
    a journaled latch at the hand point itself (Octaxe 2026-10-07: 700 MHz
    @ 1210 mV, floor 1230 over the 1210 mV ceiling) — and a miner without
    a trial window would have been written there on its next arrival at
    the step. Every latch floor, live and seeded, is capped at the hand
    voltage.
  • WarpTune: a step up checked the predicted power against the budget
    but a step the miner had already run was held against the core current
    line itself, and a voltage step up (trial, calibrated raise) was not
    held against it at all. Gaia 2026-10-07 11:03Z: "up 380→400 MHz,
    predicted 31.1 W of 40.0 W allowed", fourteen seconds later the
    TPS546's overcurrent fault at ~33 A on the 31.8–32.3 A the journal
    already had for 400 MHz. Every way up — ladder step, voltage trial,
    calibrated raise, clock-search candidate — is now held under 90 % of
    the core current line: the predicted current at the target (the
    journal's reading there, the reading here scaled with f·V, or a higher
    step's reading) must stay under it, with the reason up blocked: predicted core current 31.8 A (…) ≥ 90 % of the 33.0 A fault line (config) in the decision and the journal. The line is the regulator's
    fault line when the firmware reports it (coreCurrentFaultA, no
    firmware does yet), else the miner's core_current_warn_a from the
    config (set it against the part's fault), else the firmware's warn
    limit; a board without any line is unchecked as before and the decision
    says so. The step-down at the line is unchanged. A miner may set its
    own share of the line with core_current_up_ratio (0.80–0.97,
    check-config rejects the rest; default the global 0.90): the Gaia
    measures 30.5–31.0 A at 380 MHz and 31.8–32.3 A at 400 MHz against its
    33 A fault, so core_current_warn_a = 33 with core_current_up_ratio = 0.95 (bar 31.35 A) lets 380 through and holds off 400, where 0.90
    (bar 29.7 A) would keep it on 360.
  • WarpTune: a restore went to the stock point unasked — the shutdown
    restore, "reboot detected", the dead-chip and power-collapse restores
    and the domain-latch bump (Gaia 2026-10-07 11:56Z: a WarpTune restart's
    "restore on shutdown" wrote 400 MHz @ 960 mV and the TPS546 tripped a
    second time within the hour). Every restore target is now checked like
    a step up: with the stock point's predicted core current (the journal's
    reading there, scaled) at or over the bar, the highest ladder step under
    it at or under the hand voltage whose prediction passes is written
    instead, and the reason says restore held under the current bar: 380 MHz @ 960 mV instead of 400 MHz @ 960 mV (…) in the log and the
    journal. Nothing known (no line, no reading): the stock point as before.
  • WarpTune: the settle after a service start was armed at second 0 of
    the run clock, which counts from the service start; a device that
    answered the first probe minutes later was judged with every rule
    armed on its first sample. The loop arms the settle once the run is
    prepared.
  • WarpTune: a clock the search found above the ladder top came back
    after a restart as a step whose base was the calibrated voltage, so
    the calibrated voltage was its own ceiling (no raise in operation, a
    new calibration of the step started there). The step's base is the
    top step's reference again. The last discarded result was read back
    only together with an applied one; a miner that only ever discarded
    said "not calibrated" after a restart.
  • WarpTune: an apply cleared the calibrated points of other clocks (a
    second job with a found Max clock dropped the first job's point at the
    hand clock, which then ran at the hand voltage again). The job's points
    are merged into the ones in force.
  • WarpTune calibration: a re-check of the voltage the search goes on
    from after a failure left no journal line; verdicts beyond the plan
    (an extended floor, a re-check) pushed the card to 100 % and 0 s with a
    window still open. Journal event recheck; the plan grows with the
    floor; the open stage never reads full.
  • WarpTune, clock search: the Eco clock stage took the next lower ladder
    step as its candidate even when that step was held off, which the way
    down skips — only the four-hour timeout ended it. The search takes the
    next free step below. With beyond_spec = false the ceiling was still
    the maker's beyond-spec line (BM1370: 800 MHz), so calib_clock alone
    opened the search above the maker's table; without beyond_spec the
    ceiling is the table's top step (an option-list board: its top).
  • Devices page: the reasons a stage, a clock candidate or the job ended
    were the sidecar's English free text in every language. The sidecar
    carries each reason structured (fails: kind, values, detail, text;
    badge calib_detail_fails) and the page translates the kind
    (miners.calib_fail_*, 32 kinds); an unknown kind falls back to the
    English line. The seven non-English locales carry English placeholders
    until the native review.
  • Pool: the audit line of a fan_target command names the target; the
    sidecar compares the control token in constant time.
  • WarpTune: the PV surplus budget was lifted for the duration of a
    calibration (an energy-mode miner ran the clock search at the top for
    hours without its cap). The budget stays in force: it limits the way
    up only, so a pinned step is measured as before and a clock candidate
    above the budget fails at once as "not reachable: budget"; the energy
    mode's own switches stay deferred until the job ends.
  • WarpTune calibration: a stage whose reference is its result because
    the voltage under it is held off after a failure (not because the
    floor is reached) names that (trial_hold) instead of an unexplained
    "open" result.
  • WarpTune: a fan-target write is read back on the next three samples; a
    firmware that keeps its old target gets a journal line (probe_error
    "fan target write not taken") and the regulator's target floor goes
    back to the previous target.
  • WarpTune, clock search: calib_clock_after_voltage (per miner, opt-in)
    runs the Max clock stage after the Max voltage stage, at the voltage
    that stage takes over (found plus the reserve) plus the ladder's
    0.35 mV/MHz per step above the hand point, never above the hand
    voltage — the thermal criteria are then judged where the miner will
    run (Nano 2026-10-06: at the hand voltage the fan hit 100 % and ended
    the search; at the calibrated voltage the same clock needs 58 %).
    Default off: the clock stage runs first, at the hand voltage.
  • Devices page: a miner whose last calibration result was discarded
    (hand voltages kept) said "not calibrated" once the job had left the
    card (Octaxe 2026-10-02). The last discard rides on the snapshot and
    the badge (calib_discarded_at, calib_discarded_found) when it is
    newer than the applied calibration; the card says "result discarded
    on …" and offers "Calibrate again".
  • WarpTune: the first sample after a service start was judged with every
    rule armed, settle or not (Nano 2026-10-06: the shutdown had written
    the hand point back 38 s earlier, the first sample carried a 56 W
    transient over the 55 W cap, and the regulator stepped down urgently).
    The first sample after a start arms the 45 s settle like a point
    change (from the moment the run is prepared, see above); a point
    whose age the journal knows — under a running calibration — is judged
    as before, the reboot detection and the firmware's protections are not
    held.
  • WarpTune calibration: the clock stage's power, core current and
    supply-draw criteria judge the highest mean of three consecutive polls
    instead of the highest single poll (the Nano's hand point draws 51 W
    with lone 58 W polls against a 55 W cap). Temperatures and the fan
    keep their single-poll maxima.
  • WarpTune calibration: a service restart during a clock stage failed
    the stage on the first sample after the start (Nano 2026-10-06: the
    shutdown had restored the hand point 650 MHz @ 1160 mV, which draws
    56 W over the 55 W cap; the regulator's urgent step down from there
    was read as a guard leaving the start clock 425 MHz before the miner
    had reached it). A move from a point that is not the candidate is no
    verdict on the candidate; the not-reachable rule and the timeout judge
    until the miner is on it.
  • WarpTune calibration: a voltage stage's floor could lie under the hard
    minimum (calib_hard_min_mv, WarpAxe's regulatorMinMv) when the
    reference sat within six steps of it — the Nano's Eco stage (reference
    1000 mV on the regulator's 1000 mV floor) was planned with a floor of
    940 mV and would have asked the firmware for 990 mV, which it refuses
    (three refusals → live control off). The floor never goes under the
    hard minimum; a reference at the hard minimum is measured and ends the
    stage as hard_minimum instead of failing it. A job read back from
    the journal with such a floor is held to the hard minimum again.
  • WarpTune: a step down onto a calibrated step whose voltage lies under
    the voltage window's floor was written at the floor first and only one
    settle later at the calibrated voltage (Gamma 2026-10-06, after an OTA
    reboot: 525 MHz @ 1100 mV for 90 s, then 1020 mV). The calibrated
    voltage is written directly; the window's ceiling still holds. The
    heartbeat line journals the calibrated voltages (calibrated_mv) next
    to the trial memory, which is never lowered to them.
  • Devices page: the calibration buttons showed although the pool held
    no WarpTune control key, and the command's error landed at the top of
    the page (Umbrel 2026-10-06: Apply pressed twice, nothing visible, the
    audit log said "no control token"). The badge carries pool_token;
    without the key the card says so instead of the buttons, and a
    command's error is shown on the card next to them.
  • Devices page: a day after a calibration job finished the card said
    "not calibrated" although the applied voltages were in effect (Nano,
    applied 2026-10-04, card on 2026-10-06). The sidecar now reports the
    calibration in effect independent of the job (applied: when, the
    points, the found voltages, Eco cap, fan target; badge
    calib_applied_at / calib_applied_points) and the card shows it
    permanently with Calibrate again.
  • Devices page: the "waits for PV surplus" badge showed on a miner at
    the top of its ladder, where no step up exists (NerdOctaxe at 700 MHz,
    2026-10-05); the sidecar reports at_top (the top step of the present
    mode) and the badge stays off there.
  • Devices page, network-range scan: WarpAxe is recognised by its version
    string also without an ASIC model (chipless dev kit), and the per-host
    timeout is 1.8 s instead of 0.9 s so a miner whose WiFi sleeps between
    packets still answers the first probe.
  • Devices page, add miner: a network-range scan without an admin login
    showed "active-scan: HTTP 401"; it now says to log in as admin (the
    range sweep has required a login since the July 2026 audit).
  • Devices page, voltage search line: the power figure reads as power draw
    ("approx. +16 % power draw"; German "Stromverbrauch" instead of the
    ambiguous "Leistung"), and "too many chip errors" is named as the reason
    only when the failed voltage's chip error rate was at least 0.5 % and at
    least 0.5 points above the rate now; otherwise the line says the
    hashrate was too low (NerdQAxe++ 2026-10-04: "too many chip errors
    (0.0 %, now 0.0 %)").

  ---

  dvb-WarpPool v1.37.0 — Downloads

  Docker

  git.warppool.org/dvb-projekt/dvb-warppool:v1.37.0 (multi-arch amd64+arm64, ohne v-Präfix)

  Native packages

  • Linux .deb: amd64 + arm64 → apt install ./dvb-warppool_*.deb
  • Linux .rpm: amd64 + arm64 → dnf install ./dvb-warppool-*.rpm
  • Linux AppImage: x86_64 + aarch64 portable
  • Linux tarballs: x86_64 + aarch64 for manual installs
  • macOS .dmg: added shortly after publish (built separately) — or build from source
  • Windows .msi: paused since the forge migration (no Windows runner yet)

  Signatures

  • SHA256SUMS + cosign bundle (SHA256SUMS.bundle, project key)
  • SBOM (SPDX) for all dependencies

  Verify (project public key cosign.pub in the repo root):

  cosign verify-blob \
    --key cosign.pub \
    --bundle SHA256SUMS.bundle \
    SHA256SUMS
  sha256sum --check SHA256SUMS
  

  First-time setup: run dvb-warppool-setup for the first-run wizard.

  Downloads

  • Source code (ZIP)
    0 downloads
  • Source code (TAR.GZ)
    0 downloads

  ---

  • SHA256SUMS
    1 download · 2026-10-07 14:36:52 +00:00 · 1.2 KiB
  • SHA256SUMS.bundle
    1 download · 2026-10-07 14:36:52 +00:00 · 3.6 KiB
  • dvb-WarpPool-v1.37.0-aarch64.AppImage
    0 downloads · 2026-10-07 14:36:16 +00:00 · 23 MiB
  • dvb-WarpPool-v1.37.0-aarch64.dmg
    1 download · 2026-10-07 14:36:59 +00:00 · 26 MiB
  • dvb-WarpPool-v1.37.0-x86_64.AppImage
    0 downloads · 2026-10-07 14:36:16 +00:00 · 24 MiB
  • dvb-WarpPool-v1.37.0-x86_64.dmg
    0 downloads · 2026-10-07 14:37:05 +00:00 · 28 MiB
  • dvb-warppool-1.37.0-1.aarch64.rpm
    0 downloads · 2026-10-07 14:36:16 +00:00 · 18 MiB
  • dvb-warppool-1.37.0-1.x86_64.rpm
    0 downloads · 2026-10-07 14:36:17 +00:00 · 19 MiB
  • dvb-warppool-v1.37.0-aarch64-apple-darwin.tar.gz
    0 downloads · 2026-10-07 14:37:10 +00:00 · 23 MiB
  • dvb-warppool-v1.37.0-aarch64-unknown-linux-gnu.tar.gz
    1 download · 2026-10-07 14:36:17 +00:00 · 24 MiB
  • dvb-warppool-v1.37.0-x86_64-apple-darwin.tar.gz
    0 downloads · 2026-10-07 14:37:16 +00:00 · 24 MiB
  • dvb-warppool-v1.37.0-x86_64-unknown-linux-gnu.tar.gz
    0 downloads · 2026-10-07 14:36:17 +00:00 · 25 MiB
  • dvb-warppool_1.37.0-1_amd64.deb
    1 download · 2026-10-07 14:36:18 +00:00 · 18 MiB
  • dvb-warppool_1.37.0-1_arm64.deb
    0 downloads · 2026-10-07 14:36:18 +00:00 · 16 MiB
  • sbom.spdx.json
    0 downloads · 2026-10-07 14:36:18 +00:00 · 1.3 MiB