Skip to content

ci(unit-tests): the tshark apt fetch of libwireshark17t64 still stalls past the 180s bound on both attempts #1432

Closed

Description

@JarryShaw

Describe the bug
The tshark apt install still stalls past its per-attempt bound. #1306 raised that bound to 180s. On 2026-10-08 the 23.7 MB libwireshark17t64 fetch from azure.archive.ubuntu.com was killed by timeout 180 on both attempts, three times:

Job Where Step
113323976331 main at d3c375ba4 parity
113470461084 main at a8cc02594 Engines (PyShark)
113485425256 #1430 PyPCAP/PyPCAPFile parity, Python 3.10

Each run's earlier packages also crawled (0.5–4s for 35–450 kB), while the index fetch was fast. Reruns on other heads took 12–17s.

Expected behavior
A slow mirror should not turn main or a PR red. The comment at unit-tests.yml:515-527 (from #974) already rules out Acquire::Retries and http::Timeout, which are noble's defaults.

Options that change the outcome:

  • cache the downloaded .deb files with actions/cache, keyed on the package versions
  • a fallback mirror on the retry
  • a larger bound, within the 10-minute step cap

Activity

  1. added
    ciPull requests that change CI or workflow configuration (ci: subject prefix)
    wipWork in flight - a covering PR is open or an agent is actively on it
    on Oct 8, 2026
  2. removed
    wipWork in flight - a covering PR is open or an agent is actively on it
    on Oct 8, 2026
  3. added this to the PyPCAPKit v1.5 milestone on Oct 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    ciPull requests that change CI or workflow configuration (ci: subject prefix)

    Projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions