wasmtime / PR #12162 wasi-nn: update the ort library · git-wasmtime

The failing CI job is right to fail: it's indicating that pulling in the new library requires new vetting. One of the core team members will have to do a cargo vet.

I'm tagged as reviewer here but I have some high-priority stuff on my plate at the moment so it may not be until sometime next week when I get to this, sorry!

Wasmtime GitHub notifications bot (Dec 12 2025 at 22:03):

cfallin updated PR #12162.

Wasmtime GitHub notifications bot (Dec 12 2025 at 22:03):

cfallin submitted PR review:

Alright, I had some time to do the vets and the changes here look good. Thanks!

Wasmtime GitHub notifications bot (Dec 12 2025 at 22:03):

cfallin has enabled auto merge for PR #12162.

Wasmtime GitHub notifications bot (Dec 13 2025 at 08:31):

tamaroning commented on PR #12162:

Understand. Thank you!

Wasmtime GitHub notifications bot (Dec 13 2025 at 18:47):

cfallin commented on PR #12162:

@tamaroning I think this needs a Cargo.lock update as well (see the CI failures); would you mind doing that by doing cargo check or cargo build and then adding the updates as a new commit? (Please do not alter my vet commit; 0da9d0bc61b5bf64cfbd16c3f5a9ccd46fdcd32b needs to remain on this branch.)

Wasmtime GitHub notifications bot (Dec 13 2025 at 19:03):

tamaroning commented on PR #12162:

Hi, I ran cargo update at your commit but nothing in Cargo.lock changed.
Do you mean cargo update?

Wasmtime GitHub notifications bot (Dec 13 2025 at 19:03):

cfallin has disabled auto merge for PR #12162.

Wasmtime GitHub notifications bot (Dec 13 2025 at 19:03):

tamaroning updated PR #12162.

Wasmtime GitHub notifications bot (Dec 14 2025 at 22:01):

cfallin commented on PR #12162:

Hi, I ran cargo update at your commit but nothing in Cargo.lock changed. Do you mean cargo update?

No, I didn't mean cargo update -- that pulls in new versions that require more vets. Would you mind force-pushing back to the prior commit to remove your latest one? (i.e., start from 0da9d0bc61b5bf64cfbd16c3f5a9ccd46fdcd32b again)

Please see the CI job failure here: that is showing that after running several cargo check commands on different crates, the lockfile is modified. You'll need to reproduce that and then create a new, separate commit on top with those changes.

Wasmtime GitHub notifications bot (Dec 16 2025 at 10:30):

tamaroning commented on PR #12162:

Hi, I reset my local branch to https://github.com/bytecodealliance/wasmtime/commit/0da9d0bc61b5bf64cfbd16c3f5a9ccd46fdcd32b and ran all cargo check ...s and ./ci/vendor-wit.sh in the Monolith checks CI, but could not reproduce the diff in Cargo.lock.
Am I missing something?

Wasmtime GitHub notifications bot (Dec 16 2025 at 23:42):

cfallin commented on PR #12162:

Hmm, I wasn't able to reproduce that either. I re-triggered the CI jobs to see if it was some transient version issue (e.g. maybe a release of smallvec happened partway through the run or something?).

Wasmtime GitHub notifications bot (Dec 16 2025 at 23:45):

cfallin commented on PR #12162:

OK, that didn't work, and the new failures don't seem reproducible either. I think at this point I need to ask our resident CI herder @alexcrichton (when he's back in office) for help...

Wasmtime GitHub notifications bot (Dec 18 2025 at 20:37):

alexcrichton commented on PR #12162:

To reproduce the error you'll want to run a git rebase against the main branch. CI tests the merge of whatever main happens to be at the time the CI job starts with this PR. I'd love if we could turn that off, but github actions doesn't have a configuration knob for that I'm aware of...

Wasmtime GitHub notifications bot (Dec 26 2025 at 09:40):

tamaroning updated PR #12162.

Wasmtime GitHub notifications bot (Dec 26 2025 at 09:42):

tamaroning commented on PR #12162:

Thank you. I rebased the branch and could update Cargo.lock.

Wasmtime GitHub notifications bot (Jan 05 2026 at 15:39):

alexcrichton merged PR #12162.

Last updated: Jan 09 2026 at 13:15 UTC