-
-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix problems installing on Raspberry Pi OS 12 (bookworm) #1408
Conversation
@delan Thank you for contributing! Sorry that you had to struggle figuring out how to use the various options. The original intention was for the script to be plug’n’play, with the command line parameters treated as hidden debug options. The fact that this script has become so bloated that it requires a dedicated help function is an issue in itself… but that’s something for another day. I agree that adding a help function now is the right course of action. Now about this PR: Did you see the failed CI job? I want to resolve that failure before merging. Looking at the standalone logs, something breaks down when building Python dependencies. Maybe --break-system-packages is causing side effects in the GitHub runner environment? Another approach may be required. Would you be able to look into this? |
Please note that I changed the base branch to “develop” — this is where are new code goes. The “main” branch gets rebased with develop after a stable release. |
After pondering this for a moment, I posit one solution: don’t call It is strictly speaking an optional routine, meant to have a local cache for pip when the Python clients initialize their venv for the first time, which is happening in their respective start.sh scripts. This is in order to work around the absence of a stable network environment, a very common state for a fresh RPi system. But it hasn’t proven to consistently solve the problem. Unfortunately pip has some kind of bug or limitation that results in a broken venv under these conditions, which it cannot recover from… It’s by far the most commonly user reported incident. There is actually a pending PR that seeks to replace it with a different solution, but it has been stalling for a long time due to complications with architecture differences for native C glue code for certain Python libraries… As you can probably tell the Python environment situation is something that has been a very long running problem in this project! |
f0272c7
to
f23f990
Compare
No worries, thanks for the feedback! I’ve removed cachePipPackages from option 1, but CI fails the same way. I tried to repro locally and here’s what I found, does this help?
Both builds seem to fail due to the x86_64-linux-gnu-gcc error: 789-web.log, 790-web.log. |
@delan the critical line is this
try adding gcc to the list of packages to install in the Dockerfile and see if that makes a difference |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, thanks for contributing!
For the record, the pip caching function is still called from two other routines: stand alone web UI and the hidden option “99” which is used by our pigen script. I think it’s appropriate to keep those intact for now.
* Fix problems installing on Raspberry Pi OS 12 (bookworm) * don’t cachePipPackages in option 1 * add gcc to required packages for web container
This patch addresses the problems in #1407 by changing easyinstall.sh as follows:
add--break-system-packages
in cachePipPackages()-h|--help|h|help
case in runChoice(), which doesn’t work--help
option, explaining that both short and long options need to use=
--help
more discoverable by suggesting it at the top of showMenu()