Update `nix` in all dependent crates

[RandomInsano]

TL;DR: We need to version bump dependencies of dependencies here. I'm willing to do it.

I've been out of the Rust Embedded loop a little while (priorities shifted), but I've come back and have found some issues with building nix on my Raspberry Pi dev harness.

That's a critical blocker for me to release a new version of one of my crates and I believe all of i2cdev, spidev, and sysfs_gpio need a bump and a test.

I can do the first two, but I'd have to make a project to use sysfs_gpio to confirm it's working.

If we're in agreement, I think I can carve out a little time over the next few weeks to go out to each of those libraries and do the version bump to nix to 0.14. One extra improvement will be not needing to build the beast that is nix three times for my examples which will make me pretty happy.

Here's the output of cargo-tree. It shows what is getting re-compiled (packages without "(*)")

└── linux-embedded-hal v0.2.2
    ├── cast v0.2.2
    ├── embedded-hal v0.2.2 (*)
    ├── i2cdev v0.4.1
    │   ├── bitflags v1.0.4 (*)
    │   ├── byteorder v1.3.1 (*)
    │   ├── libc v0.2.55
    │   └── nix v0.11.0
    │       ├── bitflags v1.0.4 (*)
    │       ├── cfg-if v0.1.9
    │       ├── libc v0.2.55 (*)
    │       └── void v1.0.2 (*)
    ├── spidev v0.3.0
    │   ├── bitflags v0.3.3
    │   ├── libc v0.2.55 (*)
    │   └── nix v0.6.0
    │       ├── bitflags v0.4.0
    │       ├── cfg-if v0.1.9 (*)
    │       ├── libc v0.2.55 (*)
    │       └── void v1.0.2 (*)
    │       [build-dependencies]
    │       ├── rustc_version v0.1.7
    │       │   └── semver v0.1.20
    │       └── semver v0.1.20 (*)
    └── sysfs_gpio v0.5.3
        └── nix v0.10.0
            ├── bitflags v1.0.4 (*)
            ├── bytes v0.4.12
            │   ├── byteorder v1.3.1 (*)
            │   └── iovec v0.1.2
            │       └── libc v0.2.55 (*)
            ├── cfg-if v0.1.9 (*)
            ├── libc v0.2.55 (*)
            └── void v1.0.2 (*)

[RandomInsano]

Status info on the three dependencies:

• Looks like i2c-dev might be good to go but needs to be published
• It seems that sysfs-gpio has it's own problems
• And spi-dev needs a release for various reasons

[drinkdhmo]

I have successfully compiled gpio-cdev on a Raspberry Pi zeroW after updating its nix dependency to 0.14.

[ryankurte]

hey thanks for opening this! i was gonna today because linux-embedded-hal not compiling seems reasonably high priority. i'm running patched rust-sysfs-gpio (and rust-i2cdev, but, not using i2c) with linux-embedded-hal on an RPi which is far from exhaustive testing, but, seems to be working.

The version of nix used in rust-spidev is actually so old it doesn't have the issue, so fixing the build only requires the https://github.com/rust-embedded/rust-sysfs-gpio/pull/55 and https://github.com/rust-embedded/rust-i2cdev/pull/49 patches atm, and a point release with these included should alleviate the immediate problem.

i noticed there are only two maintainers on @rust-embedded/embedded-linux so i was going to open a PR to add myself / if you're interested in getting onboard its always good to have a few more ^_^

[RandomInsano]

I can’t make any promises I’ll have time, but I’m trustworthy enough that I can be another human in the loop.

On May 26, 2019, at 6:42 PM, Ryan notifications@github.com wrote:

hey thanks for opening this! i was gonna today because linux-embedded-hal not compiling seems reasonably high priority. i'm running patched rust-sysfs-gpio (and rust-i2cdev, but, not using i2c) with linux-embedded-hal on an RPi which is far from exhaustive testing, but, seems to be working.

The version of nix used in rust-spidev is actually so old it doesn't have the issue, so fixing the build only requires the rust-embedded/rust-sysfs-gpio#55 and rust-embedded/rust-i2cdev#49 patches atm, and a point release with these included should alleviate the immediate problem.

i noticed there are only two maintainers on @rust-embedded/embedded-linux so i was going to open a PR to add myself / if you're interested in getting onboard its always good to have a few more ^_^

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[drinkdhmo]

With this effort, shouldn't linux-embedded-hal be migrated to use gpio-cdev instead of sysfs-gpio in light of its deprecation?

[RandomInsano]

I’d normally agree, but here it makes sense to be fast and get things working again and the effort is really separate unless it turns out sysfs is broken somehow with newer crates.

The change should only require bumping versions and testing, so the port to gpio-cdev can happen in parallel.

On May 27, 2019, at 7:15 AM, Craig Bidstrup notifications@github.com wrote:

With this effort, shouldn't linux-embedded-hal be migrated to use gpio-cdev instead of sysfs-gpio in light of its deprecation?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[drinkdhmo]

Makes sense.

[ryankurte]

alright so i have maintainer access 🎉

now just waiting on publish access https://github.com/rust-embedded/wg/pull/352#issuecomment-496749654 and for someone else on the team to review https://github.com/rust-embedded/rust-sysfs-gpio/pull/55 and https://github.com/rust-embedded/rust-i2cdev/pull/49 ^_^

[posborne]

Getting to these now. I think the up looks good but this represents an (implicit) MSRV change so the version number change in semver should be major to avoid breakages in depedent crates and projects that may be on rustc < 1.24.1.

EDIT: After doing a little digging on i2cdev/gpio I decided that 1.24.1 is still safe for the MSRV of those. sysfs-gpio is explicit at 1.26.0 and I'm fine going with the same implicit MSRV for i2cdev. We'll want to make those more explicit moving forward.

[posborne]

New versions published to crates.io:

i2cdev 0.4.2: https://crates.io/crates/i2cdev sysf_gpio 0.5.4: https://crates.io/crates/sysfs_gpio

[RandomInsano]

Nice! I’ll have to give this a try when I can.

On May 29, 2019, at 1:02 AM, Paul Osborne notifications@github.com wrote:

New versions published to crates.io:

i2cdev 0.4.2: https://crates.io/crates/i2cdev sysf_gpio 0.5.4: https://crates.io/crates/sysfs_gpio

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[ryankurte]

good call with the MSRV, and tested linux-embedded-hal is back to compiling for and running on armv7 ^_^

[RandomInsano]

🎉

[RandomInsano]

It builds again! The speed increase was a beautiful thing to see today:

me@pi-02:~/Documents/Code/rust/pscontroller-rs $ cargo update
    Updating crates.io index
    Removing bytes v0.4.12
    Removing gcc v0.3.55
    Updating i2cdev v0.4.1 -> v0.4.2
    Removing iovec v0.1.2
    Updating libc v0.2.55 -> v0.2.58
    Removing nix v0.10.0
    Removing nix v0.11.0
      Adding nix v0.14.0
    Updating sysfs_gpio v0.5.3 -> v0.5.4
    Removing winapi v0.2.8

Thanks for the great work guys. Is there anything special needed to bump spidev to use nix 0.14.0? It'd save me a few seconds so it's still worth it to me if you're okay bumping the version again when I'm done.

https://youtu.be/WotK_qzls98

[posborne]

spidev 0.4.0 is now published as well. https://crates.io/crates/spidev. This one had some larger changes as the nix it was using was quite out of date.

[RandomInsano]

You guys are too fast for me! 😆

On Jun 7, 2019, at 1:06 AM, Paul Osborne notifications@github.com wrote:

spidev 0.4.0 is now published as well. https://crates.io/crates/spidev

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[ryankurte]

thanks @posborne!

that one will need an explicit version bump whenever one of us has a moment

[eldruin]

I think this is solved now after the 0.3 release, isn't it?

[ryankurte]

closing as we seem to have resolved this, thanks folks!