You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Here are a few of the failures I encountered trying to fix this. First, we get a wasmtime incompatibility issue because deislabs/wagi depends on wasmtime 0.31.0 while krustlet-wagi-provider depends on 0.30.0. updating krustlet-wagi-provider to 0.31.0 fixes that.
cargo build
Updating crates.io index
Updating git repository `https://github.com/krustlet/krustlet`
Updating git repository `https://github.com/deislabs/wagi`
error: failed to select a version for `wasmtime-fiber`.
... required by package `wasmtime v0.31.0`
... which satisfies dependency `wasmtime = "^0.31"` of package `wagi v0.4.0 (https://github.com/deislabs/wagi#d69ffd37)`
... which satisfies git dependency `wagi` of package `wagi-provider v0.1.0 (/home/azureuser/code/krustlet-wagi-provider/crates/wagi-provider)`
... which satisfies path dependency `wagi-provider` of package `krustlet-wagi-provider v0.1.0 (/home/azureuser/code/krustlet-wagi-provider)`
versions that meet the requirements `=0.31.0` are: 0.31.0
the package `wasmtime-fiber` links to the native library `wasmtime-fiber-shims`, but it conflicts with a previous package which links to `wasmtime-fiber-shims` as well:
package `wasmtime-fiber v0.30.0`
... which satisfies dependency `wasmtime-fiber = "^0.30.0"` of package `wasmtime v0.30.0`
... which satisfies dependency `wasmtime = "^0.30.0"` of package `wagi-provider v0.1.0 (/home/azureuser/code/krustlet-wagi-provider/crates/wagi-provider)`
... which satisfies path dependency `wagi-provider` of package `krustlet-wagi-provider v0.1.0 (/home/azureuser/code/krustlet-wagi-provider)`
Only one package in the dependency graph may specify the same links value. This helps ensure that only one copy of a native library is linked in the final binary. Try to adjust your dependencies so that only one package uses the links ='wasmtime-fiber' value. For more information, see https://doc.rust-lang.org/cargo/reference/resolver.html#links.
failed to select a version for `wasmtime-fiber` which could resolve this conflict
error: Recipe `build` failed on line 5 with exit code 101
after fixing that, we get a compile error from k8s-openapi. both 0.12 and 0.13 are pulled in, so I tried aligning those, and several other dependencies which are out of sync with deislabs/wagi and krustlet/krustlet (krator 0.4 -> 0.5, kube 0.58 -> 0.60, kube-runtime 0.58 -> 0.60, k8s-openapi 0.12 -> 0.13)
error: failed to run custom build command for `k8s-openapi v0.13.1`
Caused by:
process didn't exit successfully: `/home/azureuser/code/krustlet-wagi-provider/target/debug/build/k8s-openapi-47a14058d42f7a8d/build-script-build` (exit status: 101)
--- stderr
thread 'main' panicked at '
None of the v1_* features are enabled on the k8s-openapi crate.
The k8s-openapi crate requires a feature to be enabled to indicate which version of Kubernetes it should support.
If you're using k8s-openapi in a binary crate, enable the feature corresponding to the minimum version of API server that you want to support. It may be possible that your binary crate does not directly depend on k8s-openapi. In this case, add a dependency on k8s-openapi, then enable the corresponding feature.
If you're using k8s-openapi in a library crate, add a dev-dependency on k8s-openapi and enable one of the features there. This way the feature will be enabled when buildings tests and examples of your library, but not when building the library itself. It may be possible that your library crate does not directly depend on k8s-openapi. In this case, add a dev-dependency on k8s-openapi, then enable the corresponding feature.
Library crates *must not* enable any features in their direct dependency on k8s-openapi, only in their dev-dependency. The choice of Kubernetes version to support should be left to the final binary crate, so only the binary crate should enable a specific feature. If library crates also enable features, it can cause multiple features to be enabled simultaneously, which k8s-openapi does not support.
If you want to restrict your library crate to support only a single specific version or range of versions of Kubernetes, please use the k8s_* version-specific macros to emit different code based on which feature gets enabled in the end.', /home/azureuser/.cargo/registry/src/github.com-1ecc6299db9ec823/k8s-openapi-0.13.1/build.rs:9:42
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: build failed
error: Recipe `build` failed on line 5 with exit code 101
after that, you get a build error on notify, fixed by upgrading notify 5.0.0-pre.3 -> 5.0.0-pre.11:
cargo build
Compiling kubelet v1.0.0-alpha.1 (https://github.com/krustlet/krustlet#a303840c)
error[E0425]: cannot find function `recommended_watcher` in crate `notify`
--> /home/azureuser/.cargo/git/checkouts/krustlet-1c88549ea3da6cdc/a303840/crates/kubelet/src/fs_watch/mod.rs:39:55
|
39 | let mut watcher: RecommendedWatcher = notify::recommended_watcher(move |res| {
| ^^^^^^^^^^^^^^^^^^^ not found in `notify`
For more information about this error, try `rustc --explain E0425`.
error: could not compile `kubelet` due to previous error
error: Recipe `build` failed on line 5 with exit code 101
finally, that leads to build errors in krustlet-wagi-provider itself, which I haven't yet resolved, as I assume they require code changes:
cargo build
Updating crates.io index
Compiling notify v5.0.0-pre.13
Compiling kubelet v1.0.0-alpha.1 (https://github.com/krustlet/krustlet#a303840c)
Compiling wagi-provider v0.1.0 (/home/azureuser/code/krustlet-wagi-provider/crates/wagi-provider)
error[E0433]: failed to resolve: could not find `Router` in `wagi`
--> crates/wagi-provider/src/runtime.rs:52:15
|
52 | wagi::Router::builder()
| ^^^^^^ could not find `Router` in `wagi`
error[E0412]: cannot find type `Router` in crate `wagi`
--> crates/wagi-provider/src/runtime.rs:40:73
|
40 | pub(crate) async fn build_wagi_router(self) -> anyhow::Result<wagi::Router> {
| ^^^^^^ not found in `wagi`
error[E0282]: type annotations needed
--> crates/wagi-provider/src/pod/starting.rs:105:33
|
105 | let r = router.clone();
| ^^^^^^ cannot infer type
|
= note: type must be known at this point
Some errors have detailed explanations: E0282, E0412, E0433.
For more information about an error, try `rustc --explain E0282`.
error: could not compile `wagi-provider` due to 3 previous errors
error: Recipe `build` failed on line 5 with exit code 101
I'm happy to open a PR with the pinned version diff, but I may need some help fixing the code issues in order to bump all the dependencies properly. additionally wasmtime 0.30.0 has a CVE, so updating probably makes sense.
The text was updated successfully, but these errors were encountered:
main is broken due to using lots of git dependencies without version pinning. Here's a diff which pins to the last-good dependencies: https://github.com/deislabs/krustlet-wagi-provider/compare/main...alexeldeib:ace/dep?expand=1
Here are a few of the failures I encountered trying to fix this. First, we get a wasmtime incompatibility issue because deislabs/wagi depends on wasmtime 0.31.0 while krustlet-wagi-provider depends on 0.30.0. updating krustlet-wagi-provider to 0.31.0 fixes that.
after fixing that, we get a compile error from k8s-openapi. both 0.12 and 0.13 are pulled in, so I tried aligning those, and several other dependencies which are out of sync with deislabs/wagi and krustlet/krustlet (krator 0.4 -> 0.5, kube 0.58 -> 0.60, kube-runtime 0.58 -> 0.60, k8s-openapi 0.12 -> 0.13)
after that, you get a build error on notify, fixed by upgrading notify 5.0.0-pre.3 -> 5.0.0-pre.11:
finally, that leads to build errors in krustlet-wagi-provider itself, which I haven't yet resolved, as I assume they require code changes:
I'm happy to open a PR with the pinned version diff, but I may need some help fixing the code issues in order to bump all the dependencies properly. additionally wasmtime 0.30.0 has a CVE, so updating probably makes sense.
The text was updated successfully, but these errors were encountered: