Project

General

Profile

Actions

Task #7130

open

rust: dependency "time" fails to build on Rust nightly

Added by Jason Ish 6 months ago. Updated 5 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
Effort:
Difficulty:
Label:

Description

The Rust dependency "time" fails to build on Rust nightly, which means it is likely to fail on the next stable version of Rust.

We currently pin "time" to version 0.3.20 to meet our MSRV of 1.63. The latest version of "time" requires Rust 1.67, which is likely fine for master, but will bump the MSRV for which is not suitable for 7.

Recommendation is to set the version using configure based on the Rust version.


Subtasks 1 (0 open1 closed)

Task #7131: rust: dependency "time" fails to build on Rust nightly (7.0.x backport)RejectedJason IshActions

Related issues 1 (1 open0 closed)

Blocks Suricata - Optimization #4125: Ideal integration into oss-fuzzIn ProgressPhilippe AntoineActions
Actions #1

Updated by OISF Ticketbot 6 months ago

  • Subtask #7131 added
Actions #2

Updated by OISF Ticketbot 6 months ago

  • Label deleted (Needs backport to 7.0)
Actions #3

Updated by Jason Ish 6 months ago

Issue with doing this with configure is if make dist is run with newer Rust, a newer version of time is vendored. Which breaks building from the dist archive on systems with the older version of Rust.

Actions #4

Updated by Jason Ish 6 months ago

  • Status changed from Assigned to In Review
Actions #5

Updated by Jason Ish 6 months ago ยท Edited

Rust package renaming cannot be used due to sem-ver resolution, for example, this looks like it should work:

old-time = { package = "time", version = "=0.3.20" }
time = { package = "time", version = "=0.3.35" }

but they resolve to the same sem-ver, at least with Cargo so the build fails.

Note that this works, and we have used this for Nom:

old-time = { package = "time", version = "=0.2.20" }
time = { package = "time", version = "=0.3.35" }

as these resolve to versions that sem-ver doesn't call close enough.

Even if it did work, its unclear which one would be picked up by our dependencies that also depend on time. Use the patch feature in PR 11406 does handle this case.

Actions #6

Updated by Philippe Antoine 6 months ago

Actions #7

Updated by Victor Julien 5 months ago

  • Status changed from In Review to Resolved
  • Assignee changed from Jason Ish to Victor Julien
Actions

Also available in: Atom PDF