`netavark 1.8.0` build failure with release vendor crates
jpalus opened this issue · comments
Build of netavark 1.8.0
with vendor crates taken from a 1.8.0
release fails for me ie (rust 1.72.1
):
error[E0432]: unresolved imports `event_listener::Event`, `event_listener::EventListener`
--> /home/users/builder/rpm/BUILD/netavark-1.8.0/vendor/async-lock/src/barrier.rs:1:22
|
1 | use event_listener::{Event, EventListener};
| ^^^^^ ^^^^^^^^^^^^^ no `EventListener` in the root
| |
| no `Event` in the root
error[E0432]: unresolved imports `event_listener::Event`, `event_listener::EventListener`
--> /home/users/builder/rpm/BUILD/netavark-1.8.0/vendor/async-lock/src/mutex.rs:20:22
|
20 | use event_listener::{Event, EventListener};
| ^^^^^ ^^^^^^^^^^^^^ no `EventListener` in the root
| |
| no `Event` in the root
error[E0432]: unresolved imports `event_listener::Event`, `event_listener::EventListener`
--> /home/users/builder/rpm/BUILD/netavark-1.8.0/vendor/async-lock/src/once_cell.rs:10:22
|
10 | use event_listener::{Event, EventListener};
| ^^^^^ ^^^^^^^^^^^^^ no `EventListener` in the root
| |
| no `Event` in the root
error[E0432]: unresolved imports `event_listener::Event`, `event_listener::EventListener`
--> /home/users/builder/rpm/BUILD/netavark-1.8.0/vendor/async-lock/src/rwlock/raw.rs:16:22
|
16 | use event_listener::{Event, EventListener};
| ^^^^^ ^^^^^^^^^^^^^ no `EventListener` in the root
| |
| no `Event` in the root
error[E0432]: unresolved imports `event_listener::Event`, `event_listener::EventListener`
--> /home/users/builder/rpm/BUILD/netavark-1.8.0/vendor/async-lock/src/semaphore.rs:8:22
|
8 | use event_listener::{Event, EventListener};
| ^^^^^ ^^^^^^^^^^^^^ no `EventListener` in the root
| |
| no `Event` in the root
Build succeeds if crates are vendored with cargo vendor
(comparing contents of cargo vendor
output and netavark-v1.8.0-vendor.tar.gz
shows many differences).
yep. Same here. I'm surprised even after rc1 and this much of CI, such stuff happen at release . I'm so exhausted from trying to troubleshoot this (thought something was wrong with my build system) I got it confused with podman.
Need some sleep
@baude PTAL
I can reproduce even recreating the vendored deps locally with make vendor-tarball. Seems like cargo-vendor-filterer is replacing required deps for some reason.
@Luap99 Should it be manually published for aardvark-dns as well ? I suspect same issue will be there.
@Luap99 Should it be manually published for aardvark-dns as well ? I suspect same issue will be there.
Nobody complained there so I don't think it has the same problem, this seem to be a very specific bug around how dependencies and features are resolved.
Can confirm aardvark-dns 1.8.0
builds fine.
guess we can close this?
yes, although we should create CI tests for this mechanism to prevent releasing non working assets.