Upgrade ioctl-sys version to 0.8.0

[dhruvjune]

This PR upgrades the ioctl-sys version to 0.80.

[kevin-june]

I'm still coming up to speed on the details of what we want to do here, so I'll defer to Cody for correction on the details.

I do wonder - is the branching strategy that we want to use for maintaining this fork?

For other crates, we would avoid updating master and instead commit our changes in a separate branch. This was in order to make it easier to merge future changes from the upstream: we can simply pull master and reapply our change set. In this case, master hasn't moved for quite some time so we might not use the same strategy.

Regardless, you could probably start using these changes immediately by making this change in juneoslite/Cargo.toml:

[patch.crates-io]
uinput-sys = { git = "https://github.com/junelife/rust-uinput-sys", branch = "0.8.0-june"}

and this to your crate's Cargo.toml:

[dependencies]
uinput-sys = "0.1.7"

Note that the version numbers are confusing! It might be easier if we used:

juneoslite/Cargo.toml:

[patch.crates-io]
uinput-sys = { git = "https://github.com/junelife/rust-uinput-sys", branch = "0.1.7-june"}

crate's Cargo.toml:

[dependencies]
uinput-sys = "0.1.7"

This would require naming our branch in rust-uinput-sys as 0.1.7-june. In this convention, the branch name indicates which version of rust-uinput-sys we are patching, not what the patch set contains. Then, if a new version of rust-uinput-sys is released (0.1.8, 0.1.9, etc) we would create a new branch for each: 0.1.8-june, 0.1.9-june, etc.

@codysch Do you have recommendations here? I'm not sure what branching strategy we want when updating an unmaintained third-party repo.

[codysch]

I think this was resolved with discussion elsewhere, in that we want to keep this on the current (separate) branch. Merging this PR would probably break our juneoslite build (as it would delete the 0.8.0-june branch).

I agree that the name of the branch used here is not consistent with the pattern we want to use, and for the future using 0.1.7-june is the right way to do things.

Recommend closing this PR as we don't want to merge this (and instead keep things on a seperate branch)

[codysch]

#1 (comment)