Closed Bug 592369 Opened 9 years ago Closed 9 years ago

Eliminate different file modified dates in omni.jar

Categories

(Firefox Build System :: General, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED
mozilla2.0b7

People

(Reporter: mwu, Assigned: mwu)

References

Details

Attachments

(1 file, 3 obsolete files)

Attached patch Set all dates to 2010-01-01 (obsolete) — Splinter Review
No description provided.
Attachment #470840 - Flags: review?(ted.mielczarek)
Attachment #470840 - Flags: review?(benjamin)
Comment on attachment 470840 [details] [diff] [review]
Set all dates to 2010-01-01

h/o this doesn't work on osx
Attachment #470840 - Attachment is obsolete: true
Attachment #470840 - Flags: review?(ted.mielczarek)
Attachment #470840 - Flags: review?(benjamin)
Attached patch Set all dates to 2010-01-01, v2 (obsolete) — Splinter Review
OSX requires a path for find
Attachment #470841 - Flags: review?(ted.mielczarek)
Attachment #470841 - Flags: review?(benjamin)
Attachment #470841 - Flags: review?(benjamin) → review+
Upon further testing, it appears that windows requires -X to really be consistent in generating zips.
Attachment #470841 - Attachment is obsolete: true
Attachment #470880 - Flags: review?(benjamin)
Attachment #470841 - Flags: review?(ted.mielczarek)
Comment on attachment 470880 [details] [diff] [review]
Set all dates to 2010-01-01, use -X in zip, v3

rs=me based on the previous version having r=bsmedberg.
Attachment #470880 - Flags: review?(benjamin) → review+
Attachment #470880 - Attachment is obsolete: true
http://hg.mozilla.org/mozilla-central/rev/2242c9c14a63

Still needs a relbranch landing if applicable.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b6
Landed on GECKO20b5_20100831_RELBRANCH

http://hg.mozilla.org/mozilla-central/rev/3c46705b7df0
(In reply to comment #5)
> Created attachment 470995 [details] [diff] [review]
> hg patch ready patch

Was it intentional that dates of _all_ files in the package are set to 20100101, or shouldn't only the files packed up in omni.jar get the modified date. By now also the binaries and shared libraries of every shipped nightly come with this date, look e.g. in http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/09/2010-09-01-03-mozilla-central/firefox-4.0b6pre.en-US.linux-i686.tar.bz2
Thus, one cannot see looking at the dates in the unpacked directory when the nightly really was built.
What was the point in doing this anyway? None of the comments I can see explain the reasoning behind this.

Also, are we going to have to bump the date to 20110101 next year? Or are we going to reference 2010 forever? If we're bumping the date, then surely we should automate that.
The reason this was done was to get the file modifications consistent between Windows Installers and MARs, which is necessary to have partial updates continue to work.

Because MARs are generated differently, based on the ZIP, this was the best solution at the time. Once bug 313956 is fixed I _think_ we can back this out. I don't recall wanting it for any other reason.
(In reply to comment #10)
> Once bug 313956 is fixed I _think_ we can back this out.

Bug 313956 is fixed.
(In reply to comment #11)
> (In reply to comment #10)
> > Once bug 313956 is fixed I _think_ we can back this out.
> 
> Bug 313956 is fixed.

Bug 600241 already landed and replaced this code with something else.
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.