build(deps): bump openssl from 0.10.68 to 0.10.70 in the cargo group across 1 directory #1828
Conversation
![dependabot[bot]](https://avatars.githubusercontent.com/in/29110?s=60&v=4){kind=small}
dependabot
bot
added
dependencies
There was a problem hiding this comment.
I expect that rerunning the jobs that did not pass (the failed job, the job that was canceled due to the failing job, and the job that depends on them) will cause them to pass.
Oddly, it also failed in my fork (EliahKagan#9), where I also have Dependabot PRs enabled under the same conditions as here, but just for the purpose of investigating oddities like this (I don't merge them to my fork, instead always synchronizing it with this upstream repository). It looks like the failures in both places were different, though both Docker-related.
If this continues happening, it may be worth trying changing the ARM runner from ubuntu-24.04-arm to ubuntu-22.04-arm for the 32-bit containerized job as well (I deliberately didn't do that in #1802).
Edit: Since another PR has been merged, commenting @dependabot rebase (as there), to have the bot rebase this onto the updated main and force push, should also run all CI jobs again.
|
@dependabot rebase |
Bumps the cargo group with 1 update in the / directory: [openssl](https://github.com/sfackler/rust-openssl). Updates `openssl` from 0.10.68 to 0.10.70 - [Release notes](https://github.com/sfackler/rust-openssl/releases) - [Commits](sfackler/rust-openssl@openssl-v0.10.68...openssl-v0.10.70) --- updated-dependencies: - dependency-name: openssl dependency-type: indirect dependency-group: cargo ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
bot
force-pushed
the
dependabot/cargo/cargo-2c68f0befb
branch
from
36e72b4 to
029124e
Compare
|
It would definitely be good to get the ARM jobs to be stable - from my point of view they fail a lot and have become quite an inconvenience. |
Is this still the case since #1802? And do you know if the test-32bit (arm32v7) job is the one that's been repeatedly failing (whether before or after #1802)? I know I've seen the test-32bit (arm32v7) job fail at least a couple other times with errors relating to Docker, so I'll go ahead and open a PR to change it from Edit: I've opened #1830 for this. |
From ubuntu-24.04-arm, which seems to be having some problems there too, as discussed in GitoxideLabs#1828. This can be viewed as a follow-up on GitoxideLabs#1802, which made the analogous change for the non-containerized test job only.
Unfortunately I never distinguished and only booked it under ARM-job, so overall I felt like they were flaky. |
One possible factor is that the Linux ARM runners are not stable: they are in public preview. (I mentioned, but did not emphasize, this in #1777.)
I think the problem may be with the runner infrastructure, runner images, or those might actually be correct, and the problem could be due to compiler or linker bugs arising from assumptions that hold on some but not all ARM64 chips. We don't seem to get failures of 32-bit ARM code in the Docker images, regardless of which ARM64 runner we use. The only step that runs inside the container that I have ever observed wrongly to fail on these runners is None of the problems I've observed with ARM runners have occurred with the ubuntu-22.04-arm runners, only the ubuntu-24.04-arm runner. This is mostly what people have observed in rust-lang/rust#135867 as well, with one exception, but it looks like that exception might be an altogether different problem. So hopefully they have all gone away now both jobs that we had using ubuntu-24.04-arm have been switched to ubuntu-22.04-arm. The problems also seem to occur far more with some versions of the Rust toolchain, which I think suggests there may be a Rust or C toolchain bug involved somehow. Nothing like this has been happening on the If the extra time and effort to deal with failures outweighs the benefit of using the ARM Linux runners on CI at this time, then I have no objection to removing them (and bringing back the old Edit: When merging #1830 to main, the merge commit had a CI failure in a test-32bit job, but it was the x86 one, not the changed ARM one. I've opened #1831 to ask about it. |
I'd hope so too, and am quite optimistic :). |
Bumps the cargo group with 1 update in the / directory: openssl.
Updates
opensslfrom 0.10.68 to 0.10.70Release notes
Sourced from openssl's releases.
Commits
a4d399bRelease openssl v0.10.70c9a33e2Release openssl-sys v0.9.105f014afbMerge pull request #2360 from sfackler/fix-alpn-lifetimes8e6e30bFix lifetimes in ssl::select_next_proto1aff280Merge pull request #2358 from alex/expose-dlts16ca5b2Merge pull request #2359 from sfackler/alex-patch-14c9fbb0Test against 3.4.0 final release5ecb31dUpdate openssl/src/ssl/mod.rs4830f5bExposeSslMethod::{dtls_client,dtls_server}bab03c4Merge pull request #2356 from botovq/rm-ec-methodDependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore <dependency name> major versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)@dependabot ignore <dependency name> minor versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)@dependabot ignore <dependency name>will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)@dependabot unignore <dependency name>will remove all of the ignore conditions of the specified dependency@dependabot unignore <dependency name> <ignore condition>will remove the ignore condition of the specified dependency and ignore conditionsYou can disable automated security fix PRs for this repo from the Security Alerts page.