Fix compilation error caused by youki

[yihuaf]

Apologize for breaking the build. Historically, we did not have a good consumer for the libcontainer except youki cli. This lead us to not focus on the other usecases for the libcontainer. The error previously observed is fixed on the youki side.

I updated the commit to latest fix for youki and the build passes. I believe youki is releasing a new proper version 0.1.0 soon, so we can switch to that version after the release is made. In this way, we don't have to track specific commits.

For the oci-spec issue, I believe a good approach is for youki to re-export the oci-spec-rs that it uses, so there is no version mis-match.

[cla-bot[bot]]

In order to contribute to a Nivenly Foundation project you must sign and agree to the CLA. Reply with @cla-bot check to check again.

[yihuaf]

@cla-bot check

[cla-bot[bot]]

The cla-bot has been summoned, and re-checked this pull request!

[yihuaf]

@dmah42 The failure seems to be from cargo +nightly udeps --package auraescript. Here is the specific failure:

error[E0080]: evaluation of constant value failed
    --> /home/eng/.cargo/registry/src/github.com-1ecc6299db9ec823/v8-0.66.0/src/isolate.rs:1715:3
     |
1715 |   assert!(size_of::<TypeId>() == size_of::<u64>());
     |   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the evaluated program panicked at 'assertion failed: size_of::<TypeId>() == size_of::<u64>()', /home/eng/.cargo/registry/src/github.com-1ecc6299db9ec823/v8-0.66.0/src/isolate.rs:1715:3
     |
     = note: this error originates in the macro `assert` (in Nightly builds, run with -Z macro-backtrace for more info)

    Checking base64ct v1.5.3
For more information about this error, try `rustc --explain E0080`.
error: could not compile `v8` due to previous error
warning: build failed, waiting for other jobs to finish...
error: could not compile `v8` due to previous error
make: *** [Makefile:459: check-deps] Error 101
[eng@stardust aurae]$ 

Looks like v8 fails? I don't think it is related to this PR at all.

[yihuaf]

It seems rusty_v8 needs updated due to this change: https://github.com/denoland/rusty_v8/pull/1249 and also this issue: https://github.com/denoland/rusty_v8/issues/1248

[dmah42]

It seems rusty_v8 needs updated due to this change: denoland/rusty_v8#1249 and also this issue: denoland/rusty_v8#1248

as far as i can tell, v8 is coming in through serde_v8, which is coming in through deno_core and deno_runtime, which are pulled in by auraescript directly. we're quite a few minor versions behind on those so a bump seems reasonable.

bumping them brings in a new error though:

error: failed to select a version for `swc_ecma_codegen_macros`.
    ... required by package `deno_ast v0.27.0`
    ... which satisfies dependency `deno_ast = "^0.27.0"` of package `deno_runtime v0.117.0`
    ... which satisfies dependency `deno_runtime = "^0.117.0"` of package `auraescript v0.0.0 (/home/dma/dev/aurae-runtime/aurae/auraescript)`
versions that meet the requirements `=0.7.2` are: 0.7.2

all possible versions conflict with previously selected packages.

  previously selected package `swc_ecma_codegen_macros v0.7.1`
    ... which satisfies dependency `swc_ecma_codegen_macros = "=0.7.1"` of package `deno_ast v0.25.0`
    ... which satisfies dependency `deno_ast = "^0.25.0"` of package `auraescript v0.0.0 (/home/dma/dev/aurae-runtime/aurae/auraescript)`

failed to select a version for `swc_ecma_codegen_macros` which could resolve this conflict

so i think we need to merge this PR to get past the compile error, and then work on the deno bumps.

it's possible just bumping all of deno_{runtime,core,ast} should be enough but i'm not sure we want to mix them into one PR.