-
Notifications
You must be signed in to change notification settings - Fork 42
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
Update nix
in all dependent crates
#19
Comments
Status info on the three dependencies:
|
I have successfully compiled gpio-cdev on a Raspberry Pi zeroW after updating its |
hey thanks for opening this! i was gonna today because The version of nix used in 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 ^_^ |
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 ***@***.***> 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.
|
With this effort, shouldn't linux-embedded-hal be migrated to use gpio-cdev instead of sysfs-gpio in light of its deprecation? |
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 ***@***.***> 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.
|
Makes sense. |
alright so i have maintainer access 🎉 now just waiting on publish access rust-embedded/wg#352 (comment) and for someone else on the team to review rust-embedded/rust-sysfs-gpio#55 and rust-embedded/rust-i2cdev#49 ^_^ |
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. |
New versions published to crates.io: i2cdev 0.4.2: https://crates.io/crates/i2cdev |
Nice! I’ll have to give this a try when I can.
… On May 29, 2019, at 1:02 AM, Paul Osborne ***@***.***> 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.
|
good call with the MSRV, and tested linux-embedded-hal is back to compiling for and running on armv7 ^_^ |
🎉
|
It builds again! The speed increase was a beautiful thing to see today:
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. |
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. |
You guys are too fast for me! 😆
… On Jun 7, 2019, at 1:06 AM, Paul Osborne ***@***.***> 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.
|
thanks @posborne! that one will need an explicit version bump whenever one of us has a moment |
I think this is solved now after the 0.3 release, isn't it? |
closing as we seem to have resolved this, thanks folks! |
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
, andsysfs_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 isnix
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 "(*)")
The text was updated successfully, but these errors were encountered: