A build running inside a chroot on this project has no network access, by design — every source tarball is fetched ahead of time and extracted locally, and nothing in the build process is supposed to reach outside the machine while a package compiles. One package's default configuration quietly assumes otherwise.
What the default actually does
drkonqi, KDE's crash-handler application, has a build option called WITH_PYTHON_VENDORING, on by default. When enabled, its own CMakeLists.txt runs pip install pygdbmi psutil sentry-sdk as an actual build step — not a note in documentation about optional runtime dependencies, a real command the build system executes while compiling the package, reaching out to fetch three Python packages from the internet in the middle of what's otherwise a fully offline, source-tarball-driven process.
Why this is easy to miss until it actually runs
Every other package in this build gets its sources from a tarball already sitting on disk, fetched separately and well ahead of time. A build option that triggers a live network fetch mid-compile breaks that assumption silently — nothing about reading drkonqi's package list or its book page flags this as different from any other CMake option with a default value. It only becomes visible as a problem the moment the build actually reaches that step inside a chroot that has no route to the outside world at all, and the specific command being run — a pip install, not a source-tarball extraction — is what makes clear this isn't a normal build dependency failure.
What turning it off actually costs
WITH_PYTHON_VENDORING=OFF disables exactly what it sounds like: the three vendored Python helper packages don't get bundled in. Drkonqi's actual crash-backtrace generation — the C++ code that talks to GDB and parses the resulting stack trace — is unaffected either way; the vendored Python packages exist to support optional helper functionality layered on top of that core feature, not to replace it. Losing them means losing a secondary capability, not the tool's main purpose.
The general shape of the problem
A "no network access" build environment is a constraint most packages never have to think about, because most packages get everything they need from a source tarball fetched once, ahead of time, by a completely separate process. The packages that break this assumption tend to do it exactly like this — a well-intentioned convenience feature (bundle some optional Python tooling automatically, so a user doesn't have to install it themselves later) that happens to require exactly the one thing a hermetic, offline build process was specifically designed not to need. Finding it takes noticing the shape of the failure, not just its existence: a build step failing because it can't reach a package index is a different kind of failure than a build step failing because a library is missing, and treating it as the second kind for too long is how it takes longer than it should to spot the actual cause.