ci: drop deadsnakes job

[rwgk]

Summary

• remove the deadsnakes job from ci.yml
• this drops the last remaining use of deadsnakes/action in pybind11 CI

Background

This job originally made sense as the non-Valgrind counterpart to the old deadsnakes-based debug/Valgrind job. That original job has already been disabled for a long time:

• [MAINT] CI / 🐍 3.9-dbg (deadsnakes) • Valgrind • x64: invalid file descriptor # in syscall close() #4889

At this point, the only remaining deadsnakes entry in ci.yml was a plain Linux Python 3.11 run:

• 🐍 3.11 (deadsnakes) • x64

So the old reason for keeping a non-Valgrind companion job is largely gone.

Why remove it now

The remaining deadsnakes job has become both flaky and low-value.

1. It is the only CI path that depends on Launchpad / a PPA

Everything else in the main Python matrix uses one of:

• actions/setup-python
• container images
• other setup paths already used elsewhere in the matrix

The deadsnakes job was the only one that depended on:

• deadsnakes/action
• add-apt-repository
• Launchpad / ppa:deadsnakes/ppa
• package downloads from ppa.launchpadcontent.net

That makes it more fragile than the rest of the matrix for reasons unrelated to
pybind11 itself.

2. Its failures are external and variable

Recent failures were all in the deadsnakes setup path, before any meaningful pybind11-specific testing completed. The exact symptom varied:

• timeout in add-apt-repository while talking to Launchpad
• HTTPS connection failures while fetching PPA packages
• package lookup failures after partial PPA setup

For example:

• PR 6051, run 25264752086, job 74077395238
  • failed in sudo add-apt-repository --yes ppa:deadsnakes/ppa
  • ended with TimeoutError: [Errno 110] Connection timed out
• PR 6050, run 25263057197, job 74073353943
  • same failure family: Launchpad timeout during add-apt-repository
• PR 6047, run 25198984162, job 74063792227
  • progressed further, then failed fetching .deb files from ppa.launchpadcontent.net
• PR 5850, run 25258404339, job 74063820103
  • progressed further, then failed with Unable to locate package python3.11-*

So this is not giving stable signal about pybind11 changes. It is mostly surfacing bitrot or transient problems in an external setup path.

3. The job no longer adds much unique coverage

The one thing it still tested that is somewhat special was:

• CPython 3.11 installed from Ubuntu packages via deadsnakes, rather than via actions/setup-python

That can be useful in principle, but the current matrix already has extensive Linux coverage, including:

• ubuntu-latest with CPython 3.8, 3.10, 3.11, 3.12, 3.13, 3.14, 3.14t
• Linux PyPy and GraalPy coverage
• separate specialized compiler/container jobs

There is already a standard Linux 3.11 job in the main matrix:

• ubuntu-latest, Python 3.11, -DPYBIND11_TEST_SMART_HOLDER=ON

That means the remaining deadsnakes job was mostly duplicating existing Linux coverage, while using a much less reliable provisioning path.

4. It is not even stronger than the reusable standard jobs

The remaining deadsnakes job ran the core configure/build/test targets, but it did not include some checks that the reusable standard workflow now runs, such as:

• test_cmake_build
• tests/extra_setuptools

So the deadsnakes job was not just overlapping; in some respects it was weaker than the current standard Linux jobs.

Suggested changelog entry:

• N/A