Page MenuHomeFreeBSD

lang/rust: update to 1.30.0
ClosedPublic

Authored by jbeich on Oct 25 2018, 1:59 AM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Nov 9, 9:14 AM
Unknown Object (File)
Thu, Oct 31, 10:55 PM
Unknown Object (File)
Oct 11 2024, 10:03 AM
Unknown Object (File)
Oct 11 2024, 10:02 AM
Unknown Object (File)
Oct 11 2024, 10:02 AM
Unknown Object (File)
Oct 11 2024, 10:01 AM
Unknown Object (File)
Oct 11 2024, 2:30 AM
Unknown Object (File)
Oct 10 2024, 8:31 PM
Subscribers
None

Details

Summary
Should all consumers be rebuilt? Similar to major USE_GCC upgrades.
Is MFH to 2018Q4 desirable? Less versions to support and may help getting aarch64 back again.
Test Plan
  • poudriere bulk -t is green on 10.4 i386/amd64, 11.2 i386/amd64, 12.0 i386/amd64
  • poudriere bulk -t is green for DEFAULT_VERSIONS+=ssl=libressl-devel
  • poudriere bulk -t is green for all consumers on 11.2 amd64

Diff Detail

Lint
No Lint Coverage
Unit
No Test Coverage
Build Status
Buildable 20416
Build 19855: arc lint + arc unit

Event Timeline

jbeich added reviewers: dumbbell, tobik, riggs, koobs, will.

Adjust phabricator link in commit message

jbeich edited the summary of this revision. (Show Details)
jbeich edited the test plan for this revision. (Show Details)
  • Drop temporary dev- prefix
  • QA is complete: 2 consumers fixed
jbeich edited the summary of this revision. (Show Details)

Rust 1.30 has been released.

I'd appreciate if you can review before Saturday 01:00 UTC i.e., the next package build. Users would be able to grab binary package during weekend rather than wait until Tuesday if not later. In the case approval cannot be granted, please, state the rationale soon, so I can schedule landing/further work accordingly.

Should all consumers be rebuilt? Similar to major USE_GCC upgrades.

I think we should. Poudriere doesn't rebuild packages when build dependencies versions change, so we might catch problems in ports only later.

Is MFH to 2018Q4 desirable? Less versions to support and may help getting aarch64 back again.

Is there any reason not to MFH it?

This revision is now accepted and ready to land.Oct 25 2018, 7:27 PM

Is MFH to 2018Q4 desirable? Less versions to support and may help getting aarch64 back again.

Is there any reason not to MFH it?

Minor complexity:

  • consumers of different versions from /head may require additional testing
  • MFH script cannot deal with PORTREVISION bumps in non-yet-existing ports but pre-commit hook forbids incomplete mergeinfo
  • rP481972 mismerged PORTREVISION bump in devel/rust-cbindgen
This revision was automatically updated to reflect the committed changes.