Repository navigation
🐛🧑💻 - Documented native Python setup cannot start Linux toolcache interpreter without supported library path propagation #776
Description
Is there an existing issue for this?
- Searched LD_LIBRARY_PATH. Issue 🐛🧑💻 - No supported recovery for an unpublished candidate when promotion PR CI requires a source fix #732 mentions an unrelated consumer test fixture as background; it does not cover the supported verification-setup Python example or native runtime propagation.
Which actions are affected?
Issue, Pull Request, Commits; repository-owned native verification setup and Python runtime preflight.
Which platforms are affected?
Linux reproduced in a native GitHub Actions candidate-composite job. The local macOS helper installation works.
Description
The documented Python setup example uses actions/setup-python@v6 with update-environment:false, then immediately executes its python-path output to create a private venv. On GeckoCV's Linux runner this interpreter cannot start: libpython3.11.so.1.0 is unavailable to the dynamic loader. setup-python itself reports successful installation of Python 3.11.17.
The pinned setup-python implementation exports its installDir/lib through LD_LIBRARY_PATH only when updateEnvironment is true. Copilot's native setup result accepts only PATH and JAVA_HOME; its closed verification environment also excludes LD_LIBRARY_PATH. Thus merely changing update-environment to true in the consumer does not establish that a resulting Python venv or declared python preflight will work inside the actual native verifier. Forwarding arbitrary caller library paths would weaken isolation and is not requested.
Please own a supported safe preparation/runtime contract for dynamically linked Python toolcache builds, and correct the documented example. Add a real Linux regression that executes setup, the private-venv interpreter, runtime preflight and the configured verifier after credential/tool-option filtering. Acceptable designs should derive or ownership-validate any required library directory, or document and prove an actually self-contained runtime route. Do not turn unavailable Python into a skipped check.
Reproducing the issue
Consumer issue https://github.com/vypdev/geckocv/issues/38; candidate PR https://github.com/vypdev/geckocv/pull/40 at 3f67f9af7508161a45b2059e1817984a90b8537a.
Run https://github.com/vypdev/geckocv/actions/runs/40784214768, job 123153241312. The candidate-composite job has contents:read, checkout persist-credentials:false, a fresh private HOME and no provider secrets. Java, Node and pnpm setup pass. The pinned external setup-python action ece7cb06caefa5fff74198d8649806c4678c61a1 (v6) succeeds with python-version 3.11 and update-environment:false. The next step invokes its python-path and exits 127 before the helper can run:
python: error while loading shared libraries: libpython3.11.so.1.0: cannot open shared object file: No such file or directory
The Linux setup failed in seconds, not at the five-minute limit. The later fixture, preservation, Chromium and coverage steps correctly did not run. This candidate job executes real composite uses steps, but it is not a claimed successful Copilot native continuation; trusted-main adoption and activation remain pending.
copilot Version
v3 inspected at f5e5a4c. Contract/docs: docs/security-operations/operations/verification.mdx, src/infrastructure/untrusted_command_environment.ts and verification_setup_runner.ts.
Relevant Log Output
Successfully set up CPython (3.11.17)
python: error while loading shared libraries: libpython3.11.so.1.0: cannot open shared object file: No such file or directory
Process completed with exit code 127.
Additional context and comments
https://github.com/actions/setup-python/blob/ece7cb06caefa5fff74198d8649806c4678c61a1/src/find-python.ts exports LD_LIBRARY_PATH within if(updateEnvironment). The current Copilot docs recommend update-environment:false for private-venv setup while the closed native result excludes that state. This is distinct from JVM private-home discovery issue #775, assessment diagnostics #774 and large-comparison #773.
Consumer scope, runtime declarations, frozen dependencies, complete configured commands and fail-closed behavior are retained. No runtime-global library edits, privilege escalation, wrapper rewrite or credential expansion has been used to make the candidate check green.
Metadata
Metadata
Assignees
Labels
Type
Projects
- Status
Activity
[-]Documented native Python setup cannot start Linux toolcache interpreter without supported library-path propagation[/-][+]🐛 - Documented native Python setup cannot start Linux toolcache interpreter without supported library path propagation[/+]vypbot commentedon Oct 28, 2026
Hi! I’m @vypbot, the Copilot assistant for this repository.
I can answer questions, explain the codebase, propose implementation and test plans, review issues and pull requests for potential bugs or security problems, and help authorized maintainers apply changes.
Try
/copilot helpto see the available commands, or mention @vypbot with your question.efraespada commentedon Oct 28, 2026
Consumer follow-up: the documented setup-python route's failure remains reproducible in the original Linux run. GeckoCV now exercises a separate self-contained CPython route via uv 0.13.6 without LD_LIBRARY_PATH inheritance. The actual Linux candidate composite passed at dde46cbe7bd2146b99b78b0b158c96bcb745f511: https://github.com/vypdev/geckocv/actions/runs/40787944227 (job 123165736048). Dependency setup took 42 seconds; the private interpreter/venv, hashed wheels, frozen frontend installation, consumer fixture suite and real Chromium launch passed. Downloaded coverage artifact measures the helper at 23/23 lines and 4/4 branches.
This demonstrates a viable self-contained consumer distribution route inside the existing PATH/JAVA_HOME contract. It does not repair or validate the current setup-python example, change the closed environment, or establish successful Copilot native continuation/trusted-main adoption. The independently reproduced Gradle/JVM home issue remains #775. Please retain the original documentation/runtime failure evidence when resolving this issue; no upstream source was changed from the consumer task.
8 remaining items
vypbot commentedon Oct 29, 2026
Issue closed — historical progress
Current status: closed as completed.
The last estimate is retained below as history. Closure does not certify a new percentage, tests, or branch alignment.
Action required: none for this closed issue. If work continues, reopen the issue; a fresh assessment can update this same card.
Last assessment before closure (historical)
bugfix-776-documented-native-python-setup-cannot-start-linux-toolcach…
Merge pull request #794 from vypdev/bugfix/776-documented-native-pyth…
vypbot commentedon Oct 29, 2026
Issue closed: synchronization recommendation retired
No branch synchronization is required for this closed issue.
The previous recommendation is historical. Issue closure does not certify that the branches are synchronized.