Bug 15733

Summary:	pyenv may cause git warp to hang in certain scenarios.
Product:	[Build System, Metadata & Runtime] OE-Core	Reporter:	Yi Jin <jinyi_2001>
Component:	Scripts and Tools	Assignee:	Chris Laplante <chris.laplante>
Status:	NEW ---	QA Contact:
Severity:	normal
Priority:	Low	CC:	chris.laplante, jinyi_2001, randy.macleod, ross.burton
Version:	5.1.4
Target Milestone:	5.99
Hardware:	x86
OS:	Multiple
Whiteboard:
OS type for building Yocto:	---	Type of Regression:	---
Verified:		Documentation change:	No (bug/feature does not impact docs)

Description Yi Jin 2025-01-30 13:59:48 UTC

A strange bug took me several days to track down. Initially, I noticed that some recipes using git:// as SRC_URI, such as dbus-wait, would cause the do_fetch process to hang indefinitely. After days of investigation, I discovered the issue was related to pyenv. Specifically, the bug can be reproduced when pyenv is installed but switched to the system's built-in Python. Running the following command, and then executing git—which is actually a Git wrapper—would trigger the hang:

export PATH="/home/username/myproject/yocto/poky/scripts:/home/username/myproject/yocto/build/tmp/hosttools:..." # Omitted other PATH entries

Since this bug consumed a lot of my time and I couldn’t reproduce it on a fresh cloud server installation, I decided not to dig deeper into the root cause. However, I hope my bug report will help others facing the same issue. If anyone is willing to investigate further, I can provide a PVE virtual machine that reproduces the problem 100% of the time.

Comment 1 Randy MacLeod 2025-01-30 15:45:27 UTC

Thanks for the bug report.

Can you provide simple steps to try to reproduce the bug even if that's difficult.

pyenv isn't something we test so it's a lower priority.

-- YP bug review

Comment 2 Yi Jin 2025-01-31 03:52:41 UTC

I rolled back my virtual machine to the initial backup and found that the same bug does not occur. So next, I will try to recall what I did during this period:

1.Manually compiled the U-Boot source code.

2.Attempted to compile the Taishan Pi SDK (an open-source project by JLCPCB) but eventually gave up due to the Ubuntu system version being too high.

3.Tried the official Buildroot and Yocto tutorials for the Radxa Pi 5C.

4.Finally, attempted to use Yocto to compile for Radxa.

Most of the above operations were strictly following the official tutorials.

Perhaps this bug was ultimately caused by a combination of coincidences. It’s very likely that this has wasted everyone’s time unnecessarily, so it might not require too much attention.

Comment 3 Ross Burton 2025-01-31 08:10:34 UTC

One thought: if you were using a VM or container but doing builds on a volume external to the VM mounted in then sharing that build tree directly between "machines" is not supported: the build tree has a symlink farm in hosttools/ and those will point at tools in /usr. If you move the build tree between hosts, they might point at the wrong binaries. Or, for example, pyenv wrapper scripts and not the real tools.

Comment 4 Chris Laplante 2025-12-18 03:29:34 UTC

I hit this tonight. The bug is indeed because the pyenv shim gets symlinked as python3 in tmp/hosttools. See here: https://github.com/pyenv/pyenv/issues/2696

I'm going to work on adding a sanity check to base.bbclass to detect this case.

Comment 5 Chris Laplante 2025-12-19 14:43:44 UTC

Upstream pyenv has a fix for the infinite recursion itself. They suggested some changes we can/should make regarding shim handling as well: https://github.com/pyenv/pyenv/issues/2696#issuecomment-3675054650. If anyone has a chance to read and chime in I'd appreciate it. 

Regardless, I will still work on implementing a sanity check at the bitbake level.