Skip to content
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

Release of 0.23 broke 0.22 build #391

Closed
Florob opened this issue Nov 7, 2019 · 4 comments
Closed

Release of 0.23 broke 0.22 build #391

Florob opened this issue Nov 7, 2019 · 4 comments

Comments

@Florob
Copy link

Florob commented Nov 7, 2019

The release of 0.23 seems to have broken 0.22 builds.
The specific error is

error[E0599]: no method named `to_primitive_values` found for type `pnet_base::MacAddr` in the current scope
   --> …/target/armv7-unknown-linux-gnueabihf/release/build/pnet_packet-242d82d1735b29fa/out/ethernet.rs:442:24
    |
442 |         let vals = val.to_primitive_values();
    |                        ^^^^^^^^^^^^^^^^^^^ method not found in `pnet_base::MacAddr`

After chasing the dependency chain my understanding of this is as follows:
pnet 0.22 depends on pnet_packet 0.22. This in turn depends on pnet_macros_support 0.22 and pnet_base 0.22.
pnet_macros_support however depends on pnet_base >= 0.22.
With the release of 0.23 pnet_macros_support therefore began pulling in pnet_base 0.23. This means that the ToPrimitives implementation in pnet_macros_support is now for the types defined in pnet_base 0.23, not the ones in pnet_base 0.22.

A fix would likely be releasing pnet_macro_support 0.22.1 that depends on pnet_base 0.22 instead of pnet_base >= 0.22.

@JuxhinDB
Copy link
Member

JuxhinDB commented Nov 7, 2019

@mrmonday Would you like me to handle this in a similar fashion?

@ctacke
Copy link

ctacke commented Nov 8, 2019

In the interim, you can get past the error by doing this pre-build:

cargo update -p pnet_base:0.23.0 --precise 0.22.0

@imsnif
Copy link

imsnif commented Nov 18, 2019

Just a heads up, the above solution doesn't work for binary packages without a build step (since their Cargo.lock file is generated by crates.io). I solved this by upgrading to 0.23.0 (and also PRing one of the package's dependencies to upgrade, using a fork until it was accepted :) ).

@JuxhinDB
Copy link
Member

JuxhinDB commented Jan 8, 2020

This should now be fixed with 0.25.0. Sorry for the slow reaction to this. Hope it helps :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants