Page MenuHomeFreeBSD

lang/rust: update to 1.30.0
ClosedPublic

Authored by jbeich on Oct 25 2018, 1:59 AM.
Tags
None
Referenced Files
F80181060: D17695.diff
Thu, Mar 28, 10:26 PM
Unknown Object (File)
Jan 27 2024, 7:23 PM
Unknown Object (File)
Jan 27 2024, 12:12 PM
Unknown Object (File)
Jan 27 2024, 12:12 PM
Unknown Object (File)
Jan 27 2024, 12:12 PM
Unknown Object (File)
Jan 27 2024, 12:12 PM
Unknown Object (File)
Jan 27 2024, 12:12 PM
Unknown Object (File)
Jan 27 2024, 12:12 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

Repository
rP FreeBSD ports repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

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.