Skip to content

Use rust birthday for HeaderMode::Deterministic timestamp#262

Merged
alexcrichton merged 1 commit into
composefs:masterfrom
jamessan:deterministic-time
Aug 23, 2021
Merged

Use rust birthday for HeaderMode::Deterministic timestamp#262
alexcrichton merged 1 commit into
composefs:masterfrom
jamessan:deterministic-time

Conversation

@jamessan

@jamessan jamessan commented Aug 22, 2021

Copy link
Copy Markdown
Contributor

As described in rust-lang/crates.io#3859, the current arbitrary timestamp of 123456789 leads to Debian packages being auto-rejected due to the old timestamp. This happens for any timestamps before 1975.

Instead of 123456789, use another, more recent arbitrary timestamp -- the timestamp of the first commit for what would become Rust.

graydon/rust-prehistory@b0fd440

As described in rust-lang/crates.io#3859, the current arbitrary
timestamp of 123456789 leads to Debian packages being auto-rejected due
to the old timestamp.  This happens for any timestamps before 1975.

Instead of 123456789, use another, more recent arbitrary timestamp --
the timestamp of the first commit for what would become Rust.

graydon/rust-prehistory@b0fd440
@jamessan jamessan force-pushed the deterministic-time branch from 5b924bc to 79c878e Compare August 22, 2021 22:08
@Turbo87

Turbo87 commented Aug 22, 2021

Copy link
Copy Markdown

rust-lang/crates.io#3859 talks about 1970-01-01 though, not 1973-11-29. are you sure that this is related?

@jamessan

jamessan commented Aug 22, 2021

Copy link
Copy Markdown
Contributor Author

Yes, I am. The referenced Debian bug is about the timestamps being "too old". The crate files are currently failing this test because their timestamps are set to the epoch.

However, the specific check that triggers the diagnostic is for anything with an mtime <= the year 1975.

This means that the previous deterministic timestamp of 1973 is still too old.

@alexcrichton

Copy link
Copy Markdown
Collaborator

Hm well it's a bit frustrating that it's so hard to pick something arbitrary here, but this isn't really any less arbitrary than before...

@alexcrichton alexcrichton merged commit 60c6bd8 into composefs:master Aug 23, 2021
@jamessan jamessan deleted the deterministic-time branch August 29, 2021 11:50
@JohnTitor

Copy link
Copy Markdown

@jamessan Coming from rust-lang/crates.io#3859, so should we enforce cargo to use 0.4.38 to fix the issue reported on crates.io, like rust-lang/cargo#9517?

@jamessan

jamessan commented Jun 1, 2022

Copy link
Copy Markdown
Contributor Author

Coming from rust-lang/crates.io#3859, so should we enforce cargo to use 0.4.38 to fix the issue reported on crates.io, like rust-lang/cargo#9517?

Yes, please. I had stopped tracking whether tar-rs had released with this change. Thank you!

bors added a commit to rust-lang/cargo that referenced this pull request Jun 1, 2022
Enforce to use tar v0.4.38

The latest version of `tar` crate includes composefs/tar-rs#262, which uses a bit recent timestamp when archiving.
However, [it seems rust-lang/rust uses v0.4.37](https://github.com/rust-lang/rust/blob/e0944922007e1bb4fe59809293acf4364410cccc/Cargo.lock#L5124-L5132). This PR enforces to use v0.4.38 and it would _fix_ rust-lang/crates.io#3859 eventually.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants