-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Out of Memory error when building cryptography wheel on armv7 and armv6 #6673
Comments
This appears to be failing when trying to fetch the crates.io index before any compilation actually happens. Have you tried reducing this to see if you can replicate simply by cloning a rust repo and running |
Some comments on rust-lang/cargo#6513 may be relevant as well. (Edit: it is not, Alex has the right link) |
I do not think that issue is relevant, however this one is: rust-lang/cargo#2808 |
Ha, I literally had 2808 open but copied the link from the one I decided wasn't relevant. Sigh. |
I'm not quite sure how relevant this one is, the error doesn't say anything about Out of Memory in the issues you linked and like I said, the last build which was a month ago worked fine. Back then it used cryptography-35.0.0. |
This doesn't reproduce on other platforms, so you're going to need to do
some debugging to isolate the relevant variables here -- does building with
35.0 still work? Can you reproduce this outside a pip invocation?
…On Fri, Dec 3, 2021 at 7:26 PM shawly ***@***.***> wrote:
I do not think that issue is relevant, however this one is:
rust-lang/cargo#2808 <rust-lang/cargo#2808>
I'm not quite sure how relevant this one is, the error doesn't say
anything about Out of Memory and like I said, the last build which was a
month ago worked fine. Back then it used cryptography-35.0.0.
https://github.com/shawly/docker-crafty-web/runs/4106266429?check_suite_focus=true#step:8:2701
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#6673 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAAGBHKEMVBIOOKELX7QALUPFN4BANCNFSM5JK2O7TA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
--
All that is necessary for evil to succeed is for good people to do nothing.
|
Here is my workaround for the same issue I met before PyO3/maturin#490 (comment) cd ~/.cargo/registry/index
git clone --bare https://github.com/rust-lang/crates.io-index.git github.com-1285ae84e5963aae |
@messense the build is running for an hour now, previously it failed after around 20 minutes, so I think this is working, thanks a lot! |
Glad that workaround helped, although it'd be nice to file a bug somewhere for this. Is this a cargo bug? libgit2 on armhf? qemu issue? Something else? 😞 I'll close this for now since it's definitely not our issue, but others will run into this until the underlying problem is isolated and resolved. |
Some strange issue make so that this arch fails to build on Alpine. To not hinder the 3.0.0 release we drop this arch, and hopefully we can reintroduce it in the future. More info here: pyca/cryptography#6673 and here: rust-lang/cargo#2808
I'm trying to compile my Docker image for crafty-web, but it always fails with an Out of Memory error when it tries to build the armv6 and armv7 version.
This image was building fine just a few weeks ago, but now it doesn't anymore. I thought the out of memory issues is related to the Github runners not having enough memory but when I tried to build it with my own self-hosted runner (with 32GB of memory available) it still exits with the same error.
Pip is upgraded before the build to the latest version.
amd64, i386, arm64 and ppcle builds still work fine.
https://github.com/shawly/docker-crafty-web/runs/4412086826?check_suite_focus=true#step:8:2553
The text was updated successfully, but these errors were encountered: