-
-
Notifications
You must be signed in to change notification settings - Fork 8
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
Build failure for rustix-0.37.27 #16
Comments
I did a little digging into why I have Is there any way to skip cargo-acl analysis of this crate version? |
I had a quick try to reproduce by creating a simple crate that depends on Some bits of information that might be useful for me to help reproduce this:
|
Unfortunately there isn't. Cackle runs Ah, so you're not depending on rustix directly. I'll have a look and see if I can reproduce via a dependency on |
Good news. I managed to reproduce the problem :) |
The top level source of this problem is httpmock
I have other rustix in my Cargo.lock , and cargo-acl seems to able to process them. Im using rustup ; have no |
It looks like it only reproduces if I don't enable sandboxing of build scripts. i.e. this triggers the bug: [sandbox]
kind = "Disabled" This builds fine: [sandbox]
kind = "Bubblewrap" So if it's an option to install |
Confirming that workaround. Thanks. |
My project builds correctly, and has several versions of rustix in our Cargo.lock, but with
cargo-acl
& using rust 1.80 it fails atrustix-0.37.27
with:The code in question is at https://github.com/bytecodealliance/rustix/blob/v0.37.27/src/lib.rs#L101
During cargo-acl, I get the following problems before it crashes with the above
My cackle.toml already contains the following, so I assume that cargo-acl has already gotten one version of
rustix
working on my project.My cackle.toml
common
secton only containsversion = 2
The text was updated successfully, but these errors were encountered: