Skip to content

TOOL-30782 stop depending on crash-python - #567

Merged
prakashsurya merged 1 commit into
os-upgradefrom
projects/tool-30782-drop-crash-python
Aug 10, 2026
Merged

TOOL-30782 stop depending on crash-python#567
prakashsurya merged 1 commit into
os-upgradefrom
projects/tool-30782-drop-crash-python

Conversation

@prakashsurya

@prakashsurya prakashsurya commented Aug 10, 2026

Copy link
Copy Markdown
Contributor

Problem

crash-python is no longer built — linux-pkg#412 dropped both it and gdb-python, because gdb-python bundles a readline predating C23 and GCC 15 rejects its unprototyped termcap calls; the only cheap fix was pinning that tree to -std=gnu17 indefinitely.

This DEPENDS reference is the only thing anywhere that pulls crash-python in, so left as-is it is unsatisfiable and fails the appliance build at dependency resolution.

Solution

Drop the one line.

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

Worth being explicit, since "remove crash-python" reads worse than it is:

  • sdb remains available on the appliance, exactly as before. It is in this same DEPENDS block and is untouched by this change. It is the tool we actually reach for, it is ours, and it is where the debugging effort goes.
  • drgn remains — the engine sdb is built on.
  • savedump, makedumpfile, libkdumpfile all remain. 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 older second way of inspecting the same dumps — duplicating what sdb already does, and the only one of the two that will not build on 26.04. sdb is the preferred tool going forward, and this makes it the only one rather than maintaining a parallel toolchain to reach the same place.

The line also sits in the DEPENDS block described immediately above it as "tools that are intended for human convenience. The product should not rely on them programmatically", so nothing programmatic is affected. The crash-python repo itself is left in place.

This lands on os-upgrade to unblock the resolute build. The same change is up for team discussion on develop — see #568; if the team wants crash-python kept, this is the branch to revert.

Testing Done

Not yet built; validated by the next build-packages/post-push run on os-upgrade. Results on TOOL-30782.

crash-python is no longer built. It is the Python extension layer that runs
inside gdb-python, and gdb-python bundles a readline that predates C23, so
GCC 15 rejects its unprototyped termcap calls; the only cheap fix was pinning
that tree to -std=gnu17 indefinitely. Both were dropped from linux-pkg in #412,
so this reference would otherwise be unsatisfiable.

This is the only thing anywhere that pulls crash-python in, and it sits in the
DEPENDS block described just above as "tools that are intended for human
convenience. The product should not rely on them programmatically", so nothing
programmatic is affected.

What is lost is on-appliance kernel crash-dump inspection. Dump analysis in
practice happens off-appliance with sdb against a saved vmcore, and savedump,
makedumpfile and libkdumpfile are all untouched, so collecting a dump still
works. The crash-python repo is left in place.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@prakashsurya
prakashsurya merged commit db44fa5 into os-upgrade Aug 10, 2026
2 checks passed
@prakashsurya
prakashsurya deleted the projects/tool-30782-drop-crash-python branch August 10, 2026 16:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant