Revert to release version of ring #1501
Conversation
There was a problem hiding this comment.
I'm a bit surprised this works. As I recall, at the time there were some changes to the module system that caused old versions of ring to fail to compile. I know there have been some iterations on the module system; apparently this is no longer an issue.
I'm holding off on merging for now, because there are some other big PRs and I don't want to risk a merge conflict on the lock file, but I expect to be able to merge soon.
carols10cents
force-pushed
the
cargo-toml-cleanup
branch
from
45ba2a1 to
e3fd8e5
Compare
|
I rebased this on master, and now I'm getting some test failures locally. Going to see if they happen on travis too or if I have a personal problem. |
|
🎉 build passed |
|
Yep, and my tests failed locally on master too, and if I deleted my test database and recreated it, they passed. So personal problem. Let's try out the new homu setup! @bors: r+ |
|
@bors ping |
|
@bors r+ |
|
📌 Commit e3fd8e5 has been approved by |
Revert to release version of ring Doesn't seem to cause compile issues.
|
💥 Test timed out |
|
@bors: retry |
Revert to release version of ring Doesn't seem to cause compile issues.
|
💥 Test timed out |
|
@bors retry |
1 similar comment
|
@bors retry |
Revert to release version of ring Doesn't seem to cause compile issues.
|
☔ The latest upstream changes (presumably #1529) made this pull request unmergeable. Please resolve the merge conflicts. |
|
☀️ Test successful - checks-travis |
|
👀 Test was successful, but fast-forwarding failed: 422 Update is not a fast forward |
ishitatsuyuki
force-pushed
the
cargo-toml-cleanup
branch
from
e3fd8e5 to
19d3808
Compare
|
Rebased. |
|
@ishitatsuyuki I think the updates to Cargo.lock were missed in the rebase. |
Doesn't seem to cause compile issues.
ishitatsuyuki
force-pushed
the
cargo-toml-cleanup
branch
from
19d3808 to
aa4d347
Compare
|
Fixed. |
|
@bors r+ |
|
📌 Commit aa4d347 has been approved by |
Revert to release version of ring Doesn't seem to cause compile issues.
|
☀️ Test successful - checks-travis |
The author of ring has chosen to yank all versions of that crate other than the most recent. This has had the effect of making it so that we cannot modify our `Cargo.toml` without breaking the build. The long term fix will be to get us on the latest version of cookie (which requires updating some unmaintained dependencies). I haven't looked into how much work that will be beyond confirming that it is not as simple as just changing the version number. Right now, this is blocking anything that requires updating an existing dependency, or adding a new dependency. So this is a quick fix to get our builds working again until we have the time to sort out updating everything between us and ring. Unfortunately, this isn't just as simple as reverting rust-lang#1501, since `[patch]` doesn't force cargo to resolve to yanked versions. It'll instead resolve to really old versions of `cookie` in an attempt to remove `ring` from our dependency tree.
The author of ring has chosen to yank all versions of that crate other than the most recent. This has had the effect of making it so that we cannot modify our `Cargo.toml` without breaking the build. The long term fix will be to get us on the latest version of cookie (which requires updating some unmaintained dependencies). I haven't looked into how much work that will be beyond confirming that it is not as simple as just changing the version number. Right now, this is blocking anything that requires updating an existing dependency, or adding a new dependency. So this is a quick fix to get our builds working again until we have the time to sort out updating everything between us and ring. Unfortunately, this isn't just as simple as reverting rust-lang#1501, since `[patch]` doesn't force cargo to resolve to yanked versions. It'll instead resolve to really old versions of `cookie` in an attempt to remove `ring` from our dependency tree. So I've instead had to fork cookie, and change its dependency on Ring to use what we had prior to rust-lang#1501.
Doesn't seem to cause compile issues.