| Summary: | Hang due to missing asyncio loop argument: Initialising tasks at 44% | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] BitBake | Reporter: | Jate Sujjavanich <jatedev> |
| Component: | bitbake | Assignee: | Jate Sujjavanich <jatedev> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium+ | CC: | devjate, jatedev, poky.bs.watcher, poky.watcher, randy.macleod, steve |
| Version: | 3.1.12 | ||
| Target Milestone: | 3.1.14 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | Don't know | |
|
Description
Jate Sujjavanich
2022-01-18 15:48:10 UTC
We suspect but have yet to confirm that this only affects dunfell releases. We do need to support python-3.5 up to python-3.10 (F35 and more?) for dunfell. The buildtools has python-3.6 so that may be a work-around but dunfell did originally support python-3.5 so this is a bug. I have tested dunfell's bitbake with python 3.6, and the bug does not occur there. Given the minimum python requirement in hardknott, I think the bug will not occur there. It appears that the python maintainers added implied loop detection behavior to 3.6 and then added the argument deprecation in 3.7. I am updating my patch to only add loop to the call on 3.5. Also, I'm adding a reference to this bug. Jate, thanks for the explanatory comment. FYI, I reset the target milestone to 3.1.14. Some browsers seem to force it to 0.0.0. I used to have the problem but it hasn't happened for so long that I don't remember what fixed it! |