[JarryShaw]

• Searched for similar pull requests
• Followed the coding style (make pylint, make mypy, make isort)
• make test passes, and a test case covers the change
• Changelog entry: N/A — centralised in docs(changelog): shared 1.5.0 changelog — long-lived, merges last (#610, #616, #617, #618, #620) #657

What is the purpose of your pull request?

• ci — workflows or build tooling

---

Description of your pull request and other information

Draft. This is #1958 phase 3. The blocking pypy3.11 leg stays red until #2003 and #2004 land.

PyPy now runs the curated ALL tier from the matrix that util/python_versions.py builds:

• test and integration gain a pypy3.11 leg, which blocks through Required checks passed, so no ruleset change is needed.
• test-ktlo and integration-ktlo gain a pypy3.10 leg.

The legs use the same steps, caps and selection as the other non-latest legs.

Needed to run at all:

• On PyPy 8.0, pcapkit fails to import because aenum trips on PyPy's builtin NoneType. A PyPy-gated workaround is in pcapkit/utilities/compat.py, with a test that fails on PyPy without it.
• lxml is now CPython-only in pyproject.toml and Pipfile. It has no PyPy Linux wheel, and only LATEST modules use it.
• The interpreter-limit failures are gated on sys.implementation.name, following the GraalPy gates in fix(utilities): leave GraalPy's bootstrap frames out of the importer's level, and gate its remaining limits (#1963) #1996.

PyPy 8.0.1 results, run in an Ubuntu 24.04 container:

• Integration ALL: green.
• Unit ALL: the remaining failures are fix(protocols): Info field order follows PyPy's attribute layout, not the declared fields #2003 (Info field order) and fix(corekit): a bytearray value fails to pack into an s field on PyPy #2004 (bytearray into s fields). Workers grew steadily to about 5.8 GB each and were OOM-killed (ci: PyPy workers on the ALL tier grow until they are OOM-killed #2005). A PyPy leg now runs the tier as separate pytest invocations: tests/protocols, tests/corekit, then the rest. Each invocation starts fresh workers. Measured in a 14 GB container, workers peak at 2.6 GB and the container at 8.5 GB. There are no OOM kills, and the whole tier takes 383 s, against 493 s before.

Part of #1958. Closes #2005

[github-actions]

Coverage: 91.54% (unit tier, Python 3.15, f24c1b16e, Unit Tests run success)

Package	Statements	Missed	Branches	Partial	Cover
pcapkit (top level)	104	4	20	2	95.16%
pcapkit/const	19597	881	2618	867	92.11%
pcapkit/corekit	2567	71	816	37	96.57%
pcapkit/dumpkit	282	3	102	3	98.44%
pcapkit/foundation	2930	23	1022	25	98.79%
pcapkit/interface	138	4	52	3	96.32%
pcapkit/protocols	17436	219	4582	185	98.15%
pcapkit/toolkit	872	36	298	10	95.21%
pcapkit/utilities	529	7	160	5	98.26%
pcapkit/vendor	4431	1995	1018	167	51.73%

Per-file detail: the coverage-html artifact of this run.

[JarryShaw]

First CI run at d4db362e0: the pypy3.11 leg runs the tier in three pytest invocations, with no OOM and no lost workers on the runner. They finished in 229 s, 161 s and 276 s.

All 13 failures are the known ones:

• fix(protocols): Info field order follows PyPy's attribute layout, not the declared fields #2003's Info field order: test_a_cut_frame_rebuilds_byte_exact and test_to_dict_repeated_exthdr_1453_unit, which waits on the ruling in fix(corekit): record Info's field order instead of reading it from __dict__ (#2003) #2009;
• fix(corekit): a bytearray value fails to pack into an s field on PyPy #2004's bytearray into s fields: test_bytearray_pad_matches_bytes, fixed in fix(corekit): pack a bytearray into an s or p field on PyPy too (#2004) #2007.

This stays a draft until both land.

[JarryShaw]

resolve conflicts. Unit tests failed.

[JarryShaw]

Rebased onto main as 4aa36adcc. The conflict was #2010's collect_until in test_extraction_ownership.py. I kept it and gave PyPy a 1 s grace, because PyPy runs that finaliser one collection later than CPython.

The failing unit test is the pypy3.11 leg itself. Its remaining failures are #2003's rebuilds, which depend on Info key order. The fix you ruled on, looking up the payload by protocol name, is being worked on now. This PR stays a draft until that lands.

[JarryShaw]

Rebased onto main d419d8c39. The new head is 2df292ea7, and the PR is mergeable again.

• The one conflict: tests/project/test_sweeps_on_latest_only_1732.py. ci: run the GraalPy leg's tier in shards so no worker outlives its heap (#1963) #2012 and this PR each added a helper named unsharded. I renamed main's one to rest_unsharded and kept both. The range-diff shows the rest of this PR's patch unchanged.
• New commit: the PyPy shard loop in unit-tests.yml now calls ci: run the GraalPy leg's tier in shards so no worker outlives its heap (#1963) #2012's util/pytest_shards.py. The runs, the JUnit file names and the exit status stay the same. It runs on the leg's own PyPy, through cap_file_size.py.
• Tests: the workflow and docs pins, test_extraction_ownership.py and tests/utilities pass locally.

I'll take this out of draft once the PyPy legs are green on this head. Their run is the first real check of pytest_shards.py on PyPy.

[JarryShaw]

what's it's waiting for to publish? and resolve conflicts

[JarryShaw]

It was waiting on the Ubuntu 26.04 runner failures. All four of this PR's own PyPy legs were already green at 2df292ea7: pypy3.11 and pypy3.10, unit and integration. Its red checks were the two runner bugs:

• PyShark/parity: tshark's AppArmor denial (CI: tshark can't read captures on Ubuntu 26.04 runners (AppArmor profile) #2019). Fixed by fix(ci): let tshark read the checkout past Ubuntu 26.04's AppArmor profile (#2019) #2021, which has merged.
• Project tests: uutils timeout (CI: uutils timeout on Ubuntu 26.04 runners breaks --kill-after grace (main red) #2020). Fixed by fix(ci): run GNU timeout in the experimental tests step on any image (#2020) #2022, which hasn't merged yet.

I'm rebasing onto main, which now includes #2021, to resolve the conflicts, and taking this out of draft once that is pushed. Until #2022 lands, Project tests stays red here, as it does on main.

[JarryShaw]

Rebased onto main dbfa54b20 and conflicts resolved. The new head is bc4bb3579 (2e735e174 + bc4bb3579), and it is out of draft.

Git reported a clean rebase, but it had applied the +33 unit-tests.yml:N citation shift only once, though both this PR and #2021 had moved the same citations. All 9 are re-derived against the rebased file; for example :1964 is name: Required checks passed. Apart from those citation lines, the range-diff is unchanged. #2021's AppArmor step is untouched (test_tshark_apparmor_2019.py passes), and the local pins give 258 passed. A Sonnet review is running. Project tests stays red here until #2022 lands.

[JarryShaw]

GOOD TO GO at bc4bb3579 on the diff. CI is still queued.

A Sonnet cross-review confirmed:

• aenum shim: it is gated on sys.implementation.name == 'pypy' in compat.py and is a no-op on CPython. TheAenumPremiseTests fails once aenum no longer needs it.
• lxml: pcapkit/ never imports it. It is marked == 'CPython' in pyproject.toml and Pipfile, and its tests skip with a reason.
• Sharding: util/pytest_shards.py runs each tier test exactly once: tests/protocols, then tests/corekit, then the rest. The JUnit names match the upload glob, and the exit status is that of the last failing run.
• Citations: 14 of the 15 re-derived lines checked land on the intended line.
• Tests: the related pins give 148 passed.

I corrected three stale points in the review:

• the PR is out of draft;
• fix(protocols): Info field order follows PyPy's attribute layout, not the declared fields #2003 and fix(corekit): a bytearray value fails to pack into an s field on PyPy #2004 are both closed, so pypy3.11 is no longer waiting on them;
• ci: fix shellcheck findings and trim workflow comments (#1967) #2023 does not touch unit-tests.yml.

The only expected conflict is the workflows.rst citations against #2023, re-derived by whichever PR lands second.

Not yet verified:

• the PyPy legs on this head, including the FAILED ids on the non-blocking pypy3.10 legs, which I'll check before calling it ready;
• aenum's upstream PyPy issue.

[JarryShaw]

Rebased onto main 185b3176f, which now includes #2022's GNU timeout fix. The new head is 78ee03a59 + f24c1b16e. git patch-id is unchanged for both commits, so GOOD TO GO carries over. #2022 left unit-tests.yml alone, so the citations stand. Locally the pins pass (129 passed), including #2022's test_gnu_timeout_2020 and the timeout tests. The previous head's Project tests would have failed on 26.04 without that fix; this head shouldn't.

[JarryShaw]

Ordering check, since the "Plain unittest ordering" job is skipped on PRs. I ran every leg of it, sequentially and with CI's own command, on main 185b3176f + #2024 (which contains this PR's two commits).

• OK: cli (235), const (584), dumpkit (285), foundation (699), interface (258), protocols/internet (712), protocols (rest) (1393), toolkit (425), utilities (370) and vendor (388).
• project: failed once on ci: promote free-threaded 3.14t to supported, with the GIL off (#1958) #2024's old head, in ci: promote free-threaded 3.14t to supported, with the GIL off (#1958) #2024's own conda pin test. On ci: promote free-threaded 3.14t to supported, with the GIL off (#1958) #2024's fixed head e2d2af916 it gives 1698, OK.

The KTLO legs report 0 failing test ids across 15 legs.