TOOL-30782 stop depending on crash-python

[prakashsurya]

Raising this for team input before it lands

This removes one of two ways to inspect a kernel crash dump on the appliance, standardising on the other. The equivalent change is already on os-upgrade (#567) because it blocks the Ubuntu 26.04 build; this PR is the question of whether we want it on develop too, or whether we would rather keep the packages and pay to maintain them.

Problem

crash-python Depends: gdb-python, and gdb-python bundles a readline old enough to predate C23. GCC 15 defaults to -std=gnu23, where an empty parameter list means (void), so readline's unprototyped termcap declarations turn every call into an argument-count error:

display.c:2805:17: error: too many arguments to function 'tputs'; expected 0, have 3
display.c:3221:16: error: too many arguments to function 'tgoto'; expected 0, have 3

Dozens of them. The cheap fix is pinning that whole tree to -std=gnu17, which is a mitigation with no end date — it defers the problem to whenever gnu17 stops being accepted, on a bundled copy of a library we do not maintain. The real fix is prototypes upstream in readline.

The two packages travel together: crash-python is the Python extension layer that runs inside gdb-python, so keeping crash-python while dropping gdb-python leaves it uninstallable.

Solution

Drop the single crash-python line from DEPENDS. Companion change removes both packages from linux-pkg (#412).

Neither repo is deleted — only the build and dependency entries go, so reversing this is cheap if the team disagrees.

We keep crash-dump analysis; we drop the second way of doing it

To be clear about what this does and does not change, because it is easy to read "remove crash-python" as "cannot debug dumps any more":

• sdb stays installed and is unaffected. It is in this same DEPENDS block, and it is the tool we actually reach for — it is ours, we maintain it, and it is where the debugging effort goes.
• drgn stays installed. That is the engine sdb is built on, so the whole analysis path is intact.
• savedump, makedumpfile, libkdumpfile all stay. Dump collection is untouched.

So the appliance keeps a complete collect-and-analyse story. What goes away is the crash-python/gdb-python path — the second, older way of inspecting the same dumps, which duplicates what sdb already does and is the only one of the two that will not build on 26.04.

Put simply: sdb is the preferred way to inspect crash dumps going forward, and this makes that the only way rather than maintaining a parallel toolchain to reach the same place.

The line also sits in the DEPENDS block whose own comment reads "tools that are intended for human convenience. The product should not rely on them programmatically. They may be updated or replaced without regard for backward compatibility" — so nothing programmatic is affected either. It is the only reference to crash-python anywhere: no other package depends on it, it is in neither auto-sync list, and appliance-build has no references.

The question for reviewers

Does anyone rely on crash-python specifically — some workflow or muscle memory that sdb does not cover? If so, the alternative is keeping both packages and carrying -std=gnu17 on gdb-python until readline's prototypes get fixed upstream. If not, this is straightforward consolidation onto the tool we already prefer.

Testing Done

Not built on this branch. The same change is being validated on os-upgrade by the resolute package build; results on TOOL-30782.