Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use rust birthday for HeaderMode::Deterministic timestamp #262

Merged
merged 1 commit into from Aug 23, 2021

Conversation

jamessan
Copy link
Contributor

@jamessan jamessan commented Aug 22, 2021

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
@Turbo87
Copy link

Turbo87 commented Aug 22, 2021

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

@jamessan
Copy link
Contributor Author

jamessan commented Aug 22, 2021

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
Owner

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 alexcrichton:master Aug 23, 2021
7 checks passed
@jamessan jamessan deleted the deterministic-time branch August 29, 2021 11:50
@JohnTitor
Copy link

@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
Copy link
Contributor Author

jamessan commented Jun 1, 2022

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 alexcrichton/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.

None yet

4 participants