-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
chore: downgrade to openssl v1.1.1 (again) #13731
Conversation
Why did #13674 update it if it wasn't listed as updated in the description? I would lean towards pinning it, since it has been an issue for a while. If some distro wants to use a newer version, they can patch |
@@ -78,6 +78,8 @@ | |||
matchUpdateTypes: [ | |||
'patch', | |||
], | |||
// See rust-lang/cargo#13546 and openssl/openssl#23376 for the exclusion |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
End up using excludePackageNames
, though I completely don't know if it can detect lockfile-only updates.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@epage any chance you know this is gonna work?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
RenovateBot will no try to upgrade us but if something else causes an upgrade, then it will still happen.
Granted, if they are running cargo update <dep>
then nothing should update it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know why they got upgraded by renovatebot. There was nothing preventing me from cargo update openssl --precise <oldversion>
. Weird.
I'd like to avoid pinning. Tools depending on |
@bors r+ |
☀️ Test successful - checks-actions |
1 similar comment
☀️ Test successful - checks-actions |
👀 Test was successful, but fast-forwarding failed: 422 Changes must be made through a pull request. |
Update cargo 11 commits in 28e7b2bc0a812f90126be30f48a00a4ada990eaa..74fd5bc730b828dbc956335b229ac34ba47f7ef7 2024-04-05 19:31:01 +0000 to 2024-04-10 18:40:49 +0000 - chore: downgrade to openssl v1.1.1 (again) (rust-lang/cargo#13731) - fix(cargo-fix): dont apply same suggestion twice (rust-lang/cargo#13728) - refactor: make `resolve_with_previous` clearer (rust-lang/cargo#13727) - fix(package): Normalize paths in `Cargo.toml` (rust-lang/cargo#13729) - refactor: Track when MSRV is explicitly set, either way (rust-lang/cargo#13732) - [fix]:Build script not rerun when target rustflags change (rust-lang/cargo#13560) - feat(add): Stabilize MSRV-aware version req selection (rust-lang/cargo#13608) - Fix github fast path redirect. (rust-lang/cargo#13718) - Add release notes for 1.77.1 (rust-lang/cargo#13717) - doc(semver): remove mention of deprecated tool rust-semverver (rust-lang/cargo#13715) - chore: fix some typos (rust-lang/cargo#13714) r? ghost
We excluded the packages in rust-lang#13731 but that just means they fell into the default logic, rather than bein ignored. This at least made it easier to reject the change. This shouldp revent the PR from being created.
We excluded the packages in rust-lang#13731 but that just means they fell into the default logic, rather than being ignored (see rust-lang#13835). This at least made it easier to reject the change. This should prevent the PR from being created.
chore: downgrade to openssl v1.1.1 (again) It happened again in <#14299>. See <#13546 (comment)> and <#13731>.
Accidentally updated by #13674
See #13546 (comment)
I am not sure if we should pin this. Somebody might want to build Cargo with openssl v3.