From what I can tell this bot, swarm752-c4, is a GCE instance.  We currently only have Win10 images working in GCE.  Are you expecting to run Chrome on a Win7 OS?  Maybe that's the root of the problem?

Sorry, I wasn't clear.
I'm talking about Win7 NVIDIA swarmed bots that this GCE drives.
https://chromium-swarm.appspot.com/botlist?c=id&c=os&c=task&c=status&f=gpu%3A10de%3A1cb3-23.21.13.8792&f=os%3AWindows-2008ServerR2-SP1&f=cpu%3Ax86-64&f=pool%3AChrome-GPU&l=100&s=id%3Aasc
Namely, build500-m4 through build509-m4 and maybe build642-m4 (this one is dead for 24 weeks).

The I've logged into is build505-m4. Since I've ticked the checkbox not to pop up the dialog anymore, it seems to have started working.

+some Windows experts. Could this be due to the recent linker change or similar?

64-bit binary on 32-bit bot?

The "started in" link in comment 0 is at #558597. The previous still-green build was at #558553, and the one before then #558500 The lld switch landed in #558402, so several builds before the bad build.

https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Win7%20FYI%20Release%20%28NVIDIA%29/961 is at #558380, https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Win7%20FYI%20Release%20%28NVIDIA%29/962 at #558452, so 962 crossed the lld switch, but the blamelist on that build doesn't show the lld switch. Are the blamelist broken on these bots?

Nope. It's a 32-bit builder.

https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/GPU%20FYI%20Win%20Builder triggers https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Win7%20FYI%20Release%20(NVIDIA) .

I certainly hope the blamelists aren't broken! They were just switched to the brand-new LUCI infrastructure. +hinoka, dpranke, jbudorick

Re #5, looks like these are 64 bit bots, running both 32 and 64 bit binaries. Strangely, 64 bit ones succeed while 32 bit ones fail (presumably because of Windows incompatibility dialog popping up).

Re #6, LUCI bots decided to cap blamelist after 50 commits :-(

Re #9, can we raise that? 50 seems like a very low cut-off.

Going to take build507-m4 offline to post a screenshot of the pop-up I'm talking about.

I'm not sure why we decided to cap the blamelists at all?

Re: blamelists

Blamelists are capped because calculating blamelists requires a search through Git history, so the load time for the build page becomes O(N).  If there are no previous builds and blamelists aren't capped, the build page can continue to search through git history for all of eternity and never load.

The design of blamelists in LUCI assumes that builds can be scheduled out of order, so that the previous build number isn't necessarily the end point for blamelists.  This is what will allow for backfilled builds in the future.  Unfortunately this also means that blamelists are expensive to compute.

See also http://go/dynamic-blamelists 

Here is the screenshot. Going to tell build507-m4 not to show this message again.

Deleted: Screenshot from 2018-05-15 13-21-27.png 65.0 KB

	Screenshot from 2018-05-15 13-21-27.png 65.0 KB View Download

While I understand the thinking, this is a regression in the common case from buildbot, at least in user expectations. Perhaps there's something we can do to be smarter in the common case?

MS have landed a compat shim for chrome.exe? +brucedawson +robliao

can you check following registry keys:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Custom
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\InstalledSDB

and see if there is anything that mentions Chrome there?

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Custom is empty.
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\InstalledSDB does not exist.

should be able to disable this shim (whatever it is) following the steps here:

https://support.microsoft.com/en-us/help/931709/how-to-disable-program-fixes-and-program-compatibility-assistant-warni

then add the registry key to the image?

Is there an easy way for me to sign into the machine?

https://chrome-internal.googlesource.com/infra/infra_internal/+/master/doc/ssh.md#GCE-c

I'm currently unable to sign into the machine due to 
CVE-2018-0886

https://support.microsoft.com/en-us/help/4093492/credssp-updates-for-cve-2018-0886-march-13-2018

Rob: you can log on to the console using these instructions:
https://sites.google.com/a/google.com/client3d/documents/chrome-internal-gpu-pixel-wrangling-instructions?pli=1#TOC-Console-Access-via-the-IP-KVM-Raritan-

The current build looks like it might be passing. It's unfortunate that we don't know why though. ynovikov@ you didn't log on manually to all of the Win7 NVIDIA GPU bots did you?
https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Win7%20FYI%20Release%20%28NVIDIA%29/969

Alright, I got access through a Mac. Seems our servers are unpatched?

Re #23 - no, I did not, just 505 and 507. But, in build 969 shards on other bots are passing as well, so maybe compatibility dialog was a red herring.
Or it was fixed somehow.

Looks like https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Win7%20FYI%20Release%20%28AMD%29/1200 is exhibiting the same symptoms now.

+jdarpinian

The Win7 AMD bot was affected in the same way:
https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Win7%20FYI%20Release%20%28AMD%29/1200

and looks like it's clearing up as well.

Comparing these two builds' parent_got_revision_cp:
https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Win7%20FYI%20Release%20%28AMD%29/1200
https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Win7%20FYI%20Release%20%28AMD%29/1201

the blamelist that fixed this issue is probably:
http://crrev.com/558678..558758

Also comparing these two builds:
https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Win7%20FYI%20Release%20%28NVIDIA%29/968
https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Win7%20FYI%20Release%20%28NVIDIA%29/969

Yields:
http://crrev.com/558672..558716

So in sum, here's a likely blamelist for the fix:
http://crrev.com/558678..558716

If you look at NVIDIA, you can shrink it to http://crrev/558678..558716

Does anyone see anything suspicious in that blamelist? I've looked through it and can't find anything.

I've just logged in build508-m4, and it doesn't show incompatibility dialog.

So, when I've logged in to build508-m4 in #33, it was in the state after a successful task https://chromium-swarm.appspot.com/task?id=3d7a435d96bf3910&refresh=10&show_raw=1.
Now I've also logged in after a task that failed, https://chromium-swarm.appspot.com/task?id=3d7b2c1817eb5810, and saw the incompatibility dialog again.

Looks like this is due to some Chrome change that happened in http://crrev/558553..558597. However, when I compare it with AMD bot, https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Win7%20FYI%20Release%20%28AMD%29/1199 passed with revision 558663.

So, maybe this is not a Chrome change, but some infra change?

PS. Would be nice if we could see infra-side blamelist in LUCI bots.

If someone sees a case like this, check the EXE's properties dialog. I want to see if any compatibility bits have been set.

re: 35,

Good news, the LUCI team has been working on a lot of refactoring work to compartmentize both system-level and infra-level changes, such that it will be possible to provide a diff of the entire stack.  We don't have cycles for it right now, but it won't be very farfetched in the future.

Attaching the AppCompat rule from the machine.

Deleted: AppCompat Rule.PNG 42.1 KB

	AppCompat Rule.PNG 42.1 KB View Download

And the time stamp on chrome.exe is Thu Mar 19 14:44:31 2009.
This is very likely what triggered the AppCompat flow.

thakis: Is there an easy way to tell if this is an lld build?

I suspect that  issue 842978  on win7_chromium_rel_ng is root caused by the same problem.
But hard to tell, the only things common is that it's about Win7, looks like browser fails to start, and the issue appears and disappears.
Maybe someone CC'ed here can take a look?

Clarification on #39

The File time stamp is reasonable: May 15 2018
The EXE metadata time stamp is suspect: Thu Mar 19 14:44:31 2009

I've examined a failing win7_chromium_rel_ng run for  issue 842978 , and timestamp there is "Tue Apr 16 19:10:06 1985". Could it be random? That's why it sometimes passes? If this indeed is the same issue, then I think it's P0, since win7_chromium_rel_ng is out of capacity because of all the retries.

lld Sets the timestamp to a hash of the file's contents, for reproducible builds. I thought recent link.exes do this too. Is there a way to tell appcompat to not look at this field? How certain are you this is due to that?

Also, why is this Windows 7 only? Is appcompat different on different Windows versions?

Worst case, we can make lld write a real timestamp, but we had a bunch of "zap timestamp" scripting before since we don't want a real timestamp :-)

Does appcompat only complain about past timestamps? Maybe we could pick the hash in a way that it's always in the future.

OK, I wasn't certain before, since I had trouble re-running the failed chromedriver test on win7_chromium_rel_ng. Now I succeeded, and the test does try to run chrome and incompatibility dialog pops up.

 Issue 842978  has been merged into this issue.

If this is p0, feel free to revert the lld switch in the short term.

I'd like to understand our options here. On the bots we can probably just suppress this dialog, but if this happens on user machines that's obviously bad. Who controls appcompat? Does Ms have the ability to make it so that it doesn't look at timestamps for chrome.exe? How can we find out if future dates are safe even if they aren't monotonic?

Reverting in https://chromium-review.googlesource.com/c/chromium/src/+/1059860

link.exe still sets the timestamp in the EXE file header. A lot of stuff will break if it stopped doing that. It's pretty much a requirement that this date be set correctly for any other metadata inspecting tools out there.

Microsoft controls the app compat lists and for Chrome they're structured so that newer timestamps after a certain date don't trigger application compatibility.

It takes a Windows Update to update the database.

However, the main takeaway is to keep the EXE file timestamp accurate. This keeps all existing tooling working.

For the sake of completeness, also found occurrences on CI bots (was worried that I saw it only on CQ before):
https://ci.chromium.org/buildbot/chromium.win/Win7%20Tests%20(1)/79959
https://ci.chromium.org/buildbot/chromium.win/Win7%20Tests%20(1)/79957
https://ci.chromium.org/buildbot/chromium.win/Win7%20Tests%20(1)/79954

https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Win7%20Tests%20(dbg)(1)/69060

Well, except for the tools that are broken with it not being deterministic that we currently work around :-)

Can you expand on what "a lot of stuff" includes?

Could a timestamp that's potentially in the far future work?

What's the issue with setting the timestamp correctly?

dumpbin, appcompat, likely windbg and any tool trying to reason over executable timestamps with the same file name will break.

+Bruce probably has views on this especially considering he's written about this issue - https://randomascii.wordpress.com/2013/03/09/symbols-the-microsoft-way/

also see https://blogs.msdn.microsoft.com/oldnewthing/20180103-00/?p=97705

Are we embedding the debug GUID from lld?

Have we been able to reliably reproduce this lld app compat dialog on a developer machine (not a bot?)

If the goal is reproducible builds, that makes sense, but we won't be able to use the timestamp to hold a simple hash. We'll need it to be a bit more future proof.

While Win10 might be moving away from timestamps, they're still used on Win10 for the App Compat database.

In fact, it looks like they've added new entires for Win10 based off of the timestamp:

chrome.exe up until 12/31/2014 12:59:59 receives CUASAppFix (some command-line behavior change)

chrome.exe up until 12/31/2011 12:59:59 receives PopulateDefaultHKCUSettings.

Strangly enough
chrome.exe up until 12/31/2010 12:59:59 has a IgnoreChromeSandbox mitigation. Not sure what that is.

So the thing to do is to pick a fixed date in the future after which timestamps are invalid, document it as such, and then set the timestamp to
[Last Valid Date] + [Hash % Remaining Bits]

This at minimum keeps app compat happy. It does break any tools that use this for ordering, but at least all of the binaries will occur after all of the existing ones.

Fixing e-mail address

The current behavior is after talking with brucedawson in  bug 801349  -- I think windbg and symbol servers and whatnot should be happy. dumpbin works fine.

appcompat isn't happy, but if we always pick hashes that mean future dates it might be happy, as you suggest in comment 54.

A more conservative option could be to add a flag to set a date and use the logic in build/write_build_date_header.py to set the PE timestamp field too. (Lots of discussion and background about how that works in https://chromium-review.googlesource.com/#/c/564598/)

(back to p2 since the switch was reverted and emergency should be over)

Would anyone mind if I make this bug public? Doesn't look like anything internal is on here.

Please make it public.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/cff515c1274e6d66a55c5707c3d8c891455d5f88

commit cff515c1274e6d66a55c5707c3d8c891455d5f88
Author: Yuly Novikov <ynovikov@chromium.org>
Date: Wed May 16 01:08:17 2018

Revert "win: Link with lld instead of link.exe by default"

This reverts commit 1726f18fdb3865a9c0ed289c6109b823d1767bc1.

Reason for revert:  crbug.com/843199  Chrome fails to start on Win7 bots due to app compatibility dialog popping up

Original change's description:
> Reland "Reland "win: Link with lld instead of link.exe by default""
>
> This reverts commit de77cb762b49217d917f8d98de43312a2a803351.
>
> Reason for revert:  https://crbug.com/842408  should now be fixed.
>
> Original change's description:
> > Revert "Reland "win: Link with lld instead of link.exe by default""
> >
> > This reverts commit a25e3672d54282fe6ef822fadfcc03c09e3f185e.
> >
> > Reason for revert: broke Windows tests using ANGLE's GL back-end.
> > Breaks the CQ for graphics-related tests, and ANGLE's CQ.
> >
> > example builds:
> > https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Win10%20FYI%20Release%20%28NVIDIA%29/1063
> > https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Win10%20FYI%20dEQP%20Release%20%28NVIDIA%29/3528
> >
> > Original change's description:
> > > Reland "win: Link with lld instead of link.exe by default"
> > >
> > > The nacl browser_test failures on Win7 that caused the last revert are fixed.
> > > There's a known bug about this regressing binary size ( crbug.com/838449 ),
> > > but with in-progress patches binary size will soon be 200 kB smaller and
> > > these should all be rolled in by branch point, so let's reland this to find
> > > more unknown unknowns.
> > >
> > > Original change's description:
> > > > win: Link with lld instead of MSVC's link.exe by default
> > > >
> > > > lld is LLVM's linker. It produces PE/COFF and PDB files just like
> > > > link.exe, but it's significantly faster and it can also handle LLVM's
> > > > internal representation, which will enable us to do link-time
> > > > optimization and control-flow integraty checks with Clang.
> > > >
> > > > While lld is much faster at linking, it doesn't support incremental
> > > > links, meaning builds that only touch a few files and re-link a large
> > > > executable may become slower.
> > > >
> > > > This is the first attempt at switching everything over, with the
> > > > purpose of gathering data and finding unknown unknowns. It's likely
> > > > temporary until something breaks.
> > > >
> > > > is_win_fastlink is implicitly ignored when using lld, as lld without
> > > > fastlink is faster than link.exe with it.
> > > >
> > > > Also switch the CrWinClangLLD bots on chromium.clang to use MSVC's
> > > > link.exe to make sure that configuration keeps working.
> > > >
> > > > Bug:  792131 
> > >
> > > Change-Id: I18aba7a66c54c87092a13745f0ca213171ec25db
> > > Reviewed-on: https://chromium-review.googlesource.com/1054521
> > > Commit-Queue: Nico Weber <thakis@chromium.org>
> > > Reviewed-by: Reid Kleckner <rnk@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#557987}
> >
> > TBR=thakis@chromium.org,rnk@chromium.org
> >
> > Change-Id: Ida516adc6708c59407b817c8425c14bd3153d5b8
> > No-Presubmit: true
> > No-Tree-Checks: true
> > No-Try: true
> > Reviewed-on: https://chromium-review.googlesource.com/1056327
> > Reviewed-by: Jamie Madill <jmadill@chromium.org>
> > Commit-Queue: Jamie Madill <jmadill@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#558055}
>
> TBR=thakis@chromium.org,rnk@chromium.org,jmadill@chromium.org
>
> # Not skipping CQ checks because original CL landed > 1 day ago.
>
> Change-Id: Ided62bd7fb25d17d7a318539f41c308fb738797e
> Reviewed-on: https://chromium-review.googlesource.com/1057767
> Reviewed-by: Nico Weber <thakis@chromium.org>
> Commit-Queue: Nico Weber <thakis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#558402}

TBR=thakis@chromium.org,rnk@chromium.org,jmadill@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Change-Id: Ifdea343a643c790b531737be6bfac9c765a355c2
Bug:  792131 ,  843199 
Reviewed-on: https://chromium-review.googlesource.com/1059860
Commit-Queue: Yuly Novikov <ynovikov@chromium.org>
Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#558907}
[modify] https://crrev.com/cff515c1274e6d66a55c5707c3d8c891455d5f88/build/config/compiler/compiler.gni
[modify] https://crrev.com/cff515c1274e6d66a55c5707c3d8c891455d5f88/tools/mb/mb_config.pyl

> dumpbin, appcompat, likely windbg and any tool trying to reason
> over executable timestamps with the same file name will break.

dumpbin and windbg have been dealing with timestamp-as-hash for a few years now and they are fine with it. windbg even prints a message now in some contexts saying that this may not actually be a time stamp (or something like that). Symbol servers are also fine with it.

But app-compat. Sigh...

This throws a wrench into the deterministic binaries that I had not considered. A few options:
1) Use dates, perhaps with zap-timestamp or a comparable option to lld to make the dates predictable
2) Use dates/link-time-stamps for chrome.exe and use the hash for chrome.dll, chrome_child.dll, everything else (I'm not sure that helps)
3) Rob's suggestion of "set the timestamp to [Last Valid Date] + [Hash % Remaining Bits]"

Or some combination of the above.

After sleeping on this, I'm pretty sure we want to use the logic in build/write_build_date_header.py to compute a real timestamp that's fixed-ish-in-time-but-not-quite-so-that-many-different-shareholders-are-happy-with-it. It makes sense if the PE timestamp matches what base::GetBuildTime() returns, it should fix appcompat, and generally feels simple and self-consistent.

sgtm.

From a symbol server point of view we want to make sure that we don't end up with two different builds (i.e.; different source code or build flags) with the same timestamp. If that happens on a developer's machine then it could be confusing and may impair debuggability. If it happens with official release then it could cause an official release to become undebuggable.

Maybe do "normal" timestamps (the current time) for most builds and do fixed-ish-in-time... for official builds.

How careful we have to be depends on exactly what fixed-ish-in-time means. It could, for instance, be the time stamp of the last commit, on official builds.

build/write_build_date_header.py's logic had lots of people arguing about the fixed-in-time-ish algorithm used (we can't e.g. use the time of the last commit, since cert verification or something needs the build date to not be too far in the past, and if we used last-commit but then had to build an older branch without recent commits for some reason, we'd end up with a binary whose time stamp is too old), which is why I think we should just reuse that :-)

For official builds, that date increments every day at 5am, which should suffice to give each canary a different stamp.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/de0d115b29fdfdf7ccbf6b8cdaf5f31d3df6bab7

commit de0d115b29fdfdf7ccbf6b8cdaf5f31d3df6bab7
Author: Nico Weber <thakis@chromium.org>
Date: Tue May 22 02:27:10 2018

Reland "win: Link with lld instead of link.exe by default"

This reverts commit cff515c1274e6d66a55c5707c3d8c891455d5f88.

Reason for revert: As of the last clang roll, lld defaults to writing the
current time in the PE timestamp field, which should prevent  https://crbug.com/843199 

Original change's description:
> Revert "win: Link with lld instead of link.exe by default"
>
> This reverts commit 1726f18fdb3865a9c0ed289c6109b823d1767bc1.
>
> Reason for revert:  crbug.com/843199  Chrome fails to start on Win7 bots due to app compatibility dialog popping up
>
> Original change's description:
> > Reland "Reland "win: Link with lld instead of link.exe by default""
> >
> > This reverts commit de77cb762b49217d917f8d98de43312a2a803351.
> >
> > Reason for revert:  https://crbug.com/842408  should now be fixed.
> >
> > Original change's description:
> > > Revert "Reland "win: Link with lld instead of link.exe by default""
> > >
> > > This reverts commit a25e3672d54282fe6ef822fadfcc03c09e3f185e.
> > >
> > > Reason for revert: broke Windows tests using ANGLE's GL back-end.
> > > Breaks the CQ for graphics-related tests, and ANGLE's CQ.
> > >
> > > example builds:
> > > https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Win10%20FYI%20Release%20%28NVIDIA%29/1063
> > > https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Win10%20FYI%20dEQP%20Release%20%28NVIDIA%29/3528
> > >
> > > Original change's description:
> > > > Reland "win: Link with lld instead of link.exe by default"
> > > >
> > > > The nacl browser_test failures on Win7 that caused the last revert are fixed.
> > > > There's a known bug about this regressing binary size ( crbug.com/838449 ),
> > > > but with in-progress patches binary size will soon be 200 kB smaller and
> > > > these should all be rolled in by branch point, so let's reland this to find
> > > > more unknown unknowns.
> > > >
> > > > Original change's description:
> > > > > win: Link with lld instead of MSVC's link.exe by default
> > > > >
> > > > > lld is LLVM's linker. It produces PE/COFF and PDB files just like
> > > > > link.exe, but it's significantly faster and it can also handle LLVM's
> > > > > internal representation, which will enable us to do link-time
> > > > > optimization and control-flow integraty checks with Clang.
> > > > >
> > > > > While lld is much faster at linking, it doesn't support incremental
> > > > > links, meaning builds that only touch a few files and re-link a large
> > > > > executable may become slower.
> > > > >
> > > > > This is the first attempt at switching everything over, with the
> > > > > purpose of gathering data and finding unknown unknowns. It's likely
> > > > > temporary until something breaks.
> > > > >
> > > > > is_win_fastlink is implicitly ignored when using lld, as lld without
> > > > > fastlink is faster than link.exe with it.
> > > > >
> > > > > Also switch the CrWinClangLLD bots on chromium.clang to use MSVC's
> > > > > link.exe to make sure that configuration keeps working.
> > > > >
> > > > > Bug:  792131 
> > > >
> > > > Change-Id: I18aba7a66c54c87092a13745f0ca213171ec25db
> > > > Reviewed-on: https://chromium-review.googlesource.com/1054521
> > > > Commit-Queue: Nico Weber <thakis@chromium.org>
> > > > Reviewed-by: Reid Kleckner <rnk@chromium.org>
> > > > Cr-Commit-Position: refs/heads/master@{#557987}
> > >
> > > TBR=thakis@chromium.org,rnk@chromium.org
> > >
> > > Change-Id: Ida516adc6708c59407b817c8425c14bd3153d5b8
> > > No-Presubmit: true
> > > No-Tree-Checks: true
> > > No-Try: true
> > > Reviewed-on: https://chromium-review.googlesource.com/1056327
> > > Reviewed-by: Jamie Madill <jmadill@chromium.org>
> > > Commit-Queue: Jamie Madill <jmadill@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#558055}
> >
> > TBR=thakis@chromium.org,rnk@chromium.org,jmadill@chromium.org
> >
> > # Not skipping CQ checks because original CL landed > 1 day ago.
> >
> > Change-Id: Ided62bd7fb25d17d7a318539f41c308fb738797e
> > Reviewed-on: https://chromium-review.googlesource.com/1057767
> > Reviewed-by: Nico Weber <thakis@chromium.org>
> > Commit-Queue: Nico Weber <thakis@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#558402}
>
> TBR=thakis@chromium.org,rnk@chromium.org,jmadill@chromium.org
>
> # Not skipping CQ checks because original CL landed > 1 day ago.
>
> Change-Id: Ifdea343a643c790b531737be6bfac9c765a355c2
> Bug:  792131 ,  843199 
> Reviewed-on: https://chromium-review.googlesource.com/1059860
> Commit-Queue: Yuly Novikov <ynovikov@chromium.org>
> Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
> Reviewed-by: Nico Weber <thakis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#558907}

TBR=thakis@chromium.org,ynovikov@chromium.org,rnk@chromium.org,jmadill@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug:  792131 ,  843199 
Change-Id: I29e6a1b7ab50b6713f7d176f71a09e7dd585aee3
Reviewed-on: https://chromium-review.googlesource.com/1068217
Commit-Queue: Nico Weber <thakis@chromium.org>
Reviewed-by: Reid Kleckner <rnk@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#560462}
[modify] https://crrev.com/de0d115b29fdfdf7ccbf6b8cdaf5f31d3df6bab7/build/config/compiler/compiler.gni
[modify] https://crrev.com/de0d115b29fdfdf7ccbf6b8cdaf5f31d3df6bab7/tools/mb/mb_config.pyl

We made lld default to writing the current time in the PE timestamp, and turned it on again.

I'll try setting an explicit timestamp as described in comment 65 later (when I do, I'll link the CL to this bug), but for now this should be good.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ef36dc19986a90f49d0d31520c88d310d72bd038

commit ef36dc19986a90f49d0d31520c88d310d72bd038
Author: Nico Weber <thakis@chromium.org>
Date: Fri Aug 03 17:33:15 2018

win: write a deterministic-ish timestamp into the PE/COFF header instead of the current time

We used to set the timestamp to a hash of the binary, similar to
https://blogs.msdn.microsoft.com/oldnewthing/20180103-00/?p=97705
However, that caused an appcompat warning on Windows 7 to appear, which
interpreted the hash as a timestamp. (It's possible that https://llvm.org/PR38429
could help with that, but my guess it won't have an effect on Windows 7,
which likely always believes that the the coff timestamp field always stores
a timestamp).

So currently we write the current time during linking in that field, but that's
bad for build determinism and that in turn is bad for swarming test result cachability.

build/write_build_date_header.py already creates a deterministic BUILD_DATE
with several tradeoffs. Cachability wants this to change infrequently, but
things like HSTS need a "real" build date and want this to change frequently.
The compromise is: The date changes once per day in official builds, and
once a month in regular builds.

(We could use /Brepro in ldflags instead of /TIMESTAMP for unofficial builds to get
the binary hash in the timestamp, but having the header timestamp match the BUILD_DATE
define seems nice.)

So let's use that same time as timestamp in the PE/COFF header. lld-link has a
/TIMESTAMP: flag we can use to pass in an explicit timestamp.

Since tools can't have deps, we need to compute the timestamp at gn time,
so split write_build_date_header.py in two pieces: build/compute_build_timestamp.py
that just prints the timestamp we want to use, and the old write_build_date_header.py, which
now takes that timestamp and writes the header file.

Call compute_build_timestamp.py at gn time so that we can pass it in ldflags, and
pass the resultl to write_build_date_header.py which keeps running as an action
during build time (so that we at least don't need to write a file at gn time).

An additional wrinkle here is that the PE/COFF timestamp is used as one of just two
keys per binary for uploading PE binaries to the symbol server, the other being file size.
https://bugs.llvm.org/show_bug.cgi?id=35914#c0 has a good description of this, and
tools/symsrc/img_fingerprint.py's GetImgFingerprint() is our implementation of it.
But since we only upload binaries with symbols for official chrome builds to the symbol server,
a timestamp that changes once a day should be still enough. (32-bit and 64-bit chromes
have the same filename, and we might rarely build canary and beta and stable all on the
same day, but them all being the same size seems highly unlikely.)

Bug:  843199 , 804926 ,330260
Change-Id: I1d4193cc537ae0c4b2d6ac9281fad29de754dd6c
Reviewed-on: https://chromium-review.googlesource.com/1161104
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Reviewed-by: Hans Wennborg <hans@chromium.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#580585}
[modify] https://crrev.com/ef36dc19986a90f49d0d31520c88d310d72bd038/base/BUILD.gn
[add] https://crrev.com/ef36dc19986a90f49d0d31520c88d310d72bd038/build/compute_build_timestamp.py
[modify] https://crrev.com/ef36dc19986a90f49d0d31520c88d310d72bd038/build/config/win/BUILD.gn
[modify] https://crrev.com/ef36dc19986a90f49d0d31520c88d310d72bd038/build/dotfile_settings.gni
[add] https://crrev.com/ef36dc19986a90f49d0d31520c88d310d72bd038/build/timestamp.gni
[modify] https://crrev.com/ef36dc19986a90f49d0d31520c88d310d72bd038/build/write_build_date_header.py

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c234baa7e80a72e2dbd89bedd7abd047a12f68d4

commit c234baa7e80a72e2dbd89bedd7abd047a12f68d4
Author: Dirk Pranke <dpranke@chromium.org>
Date: Tue Aug 07 22:38:06 2018

Revert "win: write a deterministic-ish timestamp into the PE/COFF header instead of the current time"

This reverts commit ef36dc19986a90f49d0d31520c88d310d72bd038.

Reason for revert: This turns out to break the official android build, which apparently was relying on a broken aspect of the build that this fixed :(. See https://crbug.com/871173.

Original change's description:
> win: write a deterministic-ish timestamp into the PE/COFF header instead of the current time
> 
> We used to set the timestamp to a hash of the binary, similar to
> https://blogs.msdn.microsoft.com/oldnewthing/20180103-00/?p=97705
> However, that caused an appcompat warning on Windows 7 to appear, which
> interpreted the hash as a timestamp. (It's possible that https://llvm.org/PR38429
> could help with that, but my guess it won't have an effect on Windows 7,
> which likely always believes that the the coff timestamp field always stores
> a timestamp).
> 
> So currently we write the current time during linking in that field, but that's
> bad for build determinism and that in turn is bad for swarming test result cachability.
> 
> build/write_build_date_header.py already creates a deterministic BUILD_DATE
> with several tradeoffs. Cachability wants this to change infrequently, but
> things like HSTS need a "real" build date and want this to change frequently.
> The compromise is: The date changes once per day in official builds, and
> once a month in regular builds.
> 
> (We could use /Brepro in ldflags instead of /TIMESTAMP for unofficial builds to get
> the binary hash in the timestamp, but having the header timestamp match the BUILD_DATE
> define seems nice.)
> 
> So let's use that same time as timestamp in the PE/COFF header. lld-link has a
> /TIMESTAMP: flag we can use to pass in an explicit timestamp.
> 
> Since tools can't have deps, we need to compute the timestamp at gn time,
> so split write_build_date_header.py in two pieces: build/compute_build_timestamp.py
> that just prints the timestamp we want to use, and the old write_build_date_header.py, which
> now takes that timestamp and writes the header file.
> 
> Call compute_build_timestamp.py at gn time so that we can pass it in ldflags, and
> pass the resultl to write_build_date_header.py which keeps running as an action
> during build time (so that we at least don't need to write a file at gn time).
> 
> An additional wrinkle here is that the PE/COFF timestamp is used as one of just two
> keys per binary for uploading PE binaries to the symbol server, the other being file size.
> https://bugs.llvm.org/show_bug.cgi?id=35914#c0 has a good description of this, and
> tools/symsrc/img_fingerprint.py's GetImgFingerprint() is our implementation of it.
> But since we only upload binaries with symbols for official chrome builds to the symbol server,
> a timestamp that changes once a day should be still enough. (32-bit and 64-bit chromes
> have the same filename, and we might rarely build canary and beta and stable all on the
> same day, but them all being the same size seems highly unlikely.)
> 
> Bug:  843199 , 804926 ,330260
> Change-Id: I1d4193cc537ae0c4b2d6ac9281fad29de754dd6c
> Reviewed-on: https://chromium-review.googlesource.com/1161104
> Reviewed-by: Dirk Pranke <dpranke@chromium.org>
> Reviewed-by: Hans Wennborg <hans@chromium.org>
> Commit-Queue: Nico Weber <thakis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#580585}

TBR=thakis@chromium.org,hans@chromium.org,dpranke@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug:  843199 ,  804926 , 330260
Change-Id: Ib93697a82f8a9d3fb303b763609e82e0612887cd
Reviewed-on: https://chromium-review.googlesource.com/1166005
Reviewed-by: Alex Mineer <amineer@chromium.org>
Cr-Commit-Position: refs/branch-heads/3515@{#6}
Cr-Branched-From: 87042be6b9b11f1fe4f18fb565cadfea71f256e7-refs/heads/master@{#581084}
[modify] https://crrev.com/c234baa7e80a72e2dbd89bedd7abd047a12f68d4/base/BUILD.gn
[delete] https://crrev.com/26c10db8bff36a8b6fc073c0f38b1e9493cabb04/build/compute_build_timestamp.py
[modify] https://crrev.com/c234baa7e80a72e2dbd89bedd7abd047a12f68d4/build/config/win/BUILD.gn
[modify] https://crrev.com/c234baa7e80a72e2dbd89bedd7abd047a12f68d4/build/dotfile_settings.gni
[delete] https://crrev.com/26c10db8bff36a8b6fc073c0f38b1e9493cabb04/build/timestamp.gni
[modify] https://crrev.com/c234baa7e80a72e2dbd89bedd7abd047a12f68d4/build/write_build_date_header.py

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2df0c83aee0a00bc0f7c26a22b68b4ea3eefef80

commit 2df0c83aee0a00bc0f7c26a22b68b4ea3eefef80
Author: Dirk Pranke <dpranke@chromium.org>
Date: Wed Aug 08 06:26:08 2018

Revert "win: write a deterministic-ish timestamp into the PE/COFF header instead of the current time"

This reverts commit ef36dc19986a90f49d0d31520c88d310d72bd038.

Reason for revert: This turns out to break the official android build, which apparently was relying on a broken aspect of the build that this fixed :(. See https://crbug.com/871173.

Original change's description:
> win: write a deterministic-ish timestamp into the PE/COFF header instead of the current time
>
> We used to set the timestamp to a hash of the binary, similar to
> https://blogs.msdn.microsoft.com/oldnewthing/20180103-00/?p=97705
> However, that caused an appcompat warning on Windows 7 to appear, which
> interpreted the hash as a timestamp. (It's possible that https://llvm.org/PR38429
> could help with that, but my guess it won't have an effect on Windows 7,
> which likely always believes that the the coff timestamp field always stores
> a timestamp).
>
> So currently we write the current time during linking in that field, but that's
> bad for build determinism and that in turn is bad for swarming test result cachability.
>
> build/write_build_date_header.py already creates a deterministic BUILD_DATE
> with several tradeoffs. Cachability wants this to change infrequently, but
> things like HSTS need a "real" build date and want this to change frequently.
> The compromise is: The date changes once per day in official builds, and
> once a month in regular builds.
>
> (We could use /Brepro in ldflags instead of /TIMESTAMP for unofficial builds to get
> the binary hash in the timestamp, but having the header timestamp match the BUILD_DATE
> define seems nice.)
>
> So let's use that same time as timestamp in the PE/COFF header. lld-link has a
> /TIMESTAMP: flag we can use to pass in an explicit timestamp.
>
> Since tools can't have deps, we need to compute the timestamp at gn time,
> so split write_build_date_header.py in two pieces: build/compute_build_timestamp.py
> that just prints the timestamp we want to use, and the old write_build_date_header.py, which
> now takes that timestamp and writes the header file.
>
> Call compute_build_timestamp.py at gn time so that we can pass it in ldflags, and
> pass the resultl to write_build_date_header.py which keeps running as an action
> during build time (so that we at least don't need to write a file at gn time).
>
> An additional wrinkle here is that the PE/COFF timestamp is used as one of just two
> keys per binary for uploading PE binaries to the symbol server, the other being file size.
> https://bugs.llvm.org/show_bug.cgi?id=35914#c0 has a good description of this, and
> tools/symsrc/img_fingerprint.py's GetImgFingerprint() is our implementation of it.
> But since we only upload binaries with symbols for official chrome builds to the symbol server,
> a timestamp that changes once a day should be still enough. (32-bit and 64-bit chromes
> have the same filename, and we might rarely build canary and beta and stable all on the
> same day, but them all being the same size seems highly unlikely.)
>
> Bug:  843199 , 804926 ,330260
> Change-Id: I1d4193cc537ae0c4b2d6ac9281fad29de754dd6c
> Reviewed-on: https://chromium-review.googlesource.com/1161104
> Reviewed-by: Dirk Pranke <dpranke@chromium.org>
> Reviewed-by: Hans Wennborg <hans@chromium.org>
> Commit-Queue: Nico Weber <thakis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#580585}

TBR=thakis@chromium.org,hans@chromium.org,dpranke@chromium.org
NOTRY=true

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug:  843199 ,  804926 , 330260
Change-Id: Ib93697a82f8a9d3fb303b763609e82e0612887cd
Reviewed-on: https://chromium-review.googlesource.com/1166203
Commit-Queue: Hans Wennborg <hans@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#581485}
[modify] https://crrev.com/2df0c83aee0a00bc0f7c26a22b68b4ea3eefef80/base/BUILD.gn
[delete] https://crrev.com/35ec8d11347ddcdc425f63b8da279f3c3fcfaf92/build/compute_build_timestamp.py
[modify] https://crrev.com/2df0c83aee0a00bc0f7c26a22b68b4ea3eefef80/build/config/win/BUILD.gn
[modify] https://crrev.com/2df0c83aee0a00bc0f7c26a22b68b4ea3eefef80/build/dotfile_settings.gni
[delete] https://crrev.com/35ec8d11347ddcdc425f63b8da279f3c3fcfaf92/build/timestamp.gni
[modify] https://crrev.com/2df0c83aee0a00bc0f7c26a22b68b4ea3eefef80/build/write_build_date_header.py

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/72c03041cad06f204c6e1c09af414381e032e999

commit 72c03041cad06f204c6e1c09af414381e032e999
Author: Dirk Pranke <dpranke@chromium.org>
Date: Wed Aug 08 11:56:31 2018

Revert "win: write a deterministic-ish timestamp into the PE/COFF header instead of the current time"

This reverts commit ef36dc19986a90f49d0d31520c88d310d72bd038.

Reason for revert: This turns out to break the official android build, which apparently was relying on a broken aspect of the build that this fixed :(. See https://crbug.com/871173.

Original change's description:
> win: write a deterministic-ish timestamp into the PE/COFF header instead of the current time
>
> We used to set the timestamp to a hash of the binary, similar to
> https://blogs.msdn.microsoft.com/oldnewthing/20180103-00/?p=97705
> However, that caused an appcompat warning on Windows 7 to appear, which
> interpreted the hash as a timestamp. (It's possible that https://llvm.org/PR38429
> could help with that, but my guess it won't have an effect on Windows 7,
> which likely always believes that the the coff timestamp field always stores
> a timestamp).
>
> So currently we write the current time during linking in that field, but that's
> bad for build determinism and that in turn is bad for swarming test result cachability.
>
> build/write_build_date_header.py already creates a deterministic BUILD_DATE
> with several tradeoffs. Cachability wants this to change infrequently, but
> things like HSTS need a "real" build date and want this to change frequently.
> The compromise is: The date changes once per day in official builds, and
> once a month in regular builds.
>
> (We could use /Brepro in ldflags instead of /TIMESTAMP for unofficial builds to get
> the binary hash in the timestamp, but having the header timestamp match the BUILD_DATE
> define seems nice.)
>
> So let's use that same time as timestamp in the PE/COFF header. lld-link has a
> /TIMESTAMP: flag we can use to pass in an explicit timestamp.
>
> Since tools can't have deps, we need to compute the timestamp at gn time,
> so split write_build_date_header.py in two pieces: build/compute_build_timestamp.py
> that just prints the timestamp we want to use, and the old write_build_date_header.py, which
> now takes that timestamp and writes the header file.
>
> Call compute_build_timestamp.py at gn time so that we can pass it in ldflags, and
> pass the resultl to write_build_date_header.py which keeps running as an action
> during build time (so that we at least don't need to write a file at gn time).
>
> An additional wrinkle here is that the PE/COFF timestamp is used as one of just two
> keys per binary for uploading PE binaries to the symbol server, the other being file size.
> https://bugs.llvm.org/show_bug.cgi?id=35914#c0 has a good description of this, and
> tools/symsrc/img_fingerprint.py's GetImgFingerprint() is our implementation of it.
> But since we only upload binaries with symbols for official chrome builds to the symbol server,
> a timestamp that changes once a day should be still enough. (32-bit and 64-bit chromes
> have the same filename, and we might rarely build canary and beta and stable all on the
> same day, but them all being the same size seems highly unlikely.)
>
> Bug:  843199 , 804926 ,330260
> Change-Id: I1d4193cc537ae0c4b2d6ac9281fad29de754dd6c
> Reviewed-on: https://chromium-review.googlesource.com/1161104
> Reviewed-by: Dirk Pranke <dpranke@chromium.org>
> Reviewed-by: Hans Wennborg <hans@chromium.org>
> Commit-Queue: Nico Weber <thakis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#580585}

TBR=thakis@chromium.org,hans@chromium.org,dpranke@chromium.org
NOTRY=true

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug:  843199 ,  804926 , 330260
Change-Id: Ib93697a82f8a9d3fb303b763609e82e0612887cd
Reviewed-on: https://chromium-review.googlesource.com/1166203
Commit-Queue: Hans Wennborg <hans@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#581485}(cherry picked from commit 2df0c83aee0a00bc0f7c26a22b68b4ea3eefef80)
Reviewed-on: https://chromium-review.googlesource.com/1167162
Reviewed-by: Boris Sazonov <bsazonov@chromium.org>
Cr-Commit-Position: refs/branch-heads/3516@{#3}
Cr-Branched-From: 9cc04d3302503238bd6a70ac8f0402351e1916a1-refs/heads/master@{#581409}
[modify] https://crrev.com/72c03041cad06f204c6e1c09af414381e032e999/base/BUILD.gn
[delete] https://crrev.com/c10cfa8427d4c07ef786eaf2053dee663f6150c4/build/compute_build_timestamp.py
[modify] https://crrev.com/72c03041cad06f204c6e1c09af414381e032e999/build/config/win/BUILD.gn
[modify] https://crrev.com/72c03041cad06f204c6e1c09af414381e032e999/build/dotfile_settings.gni
[delete] https://crrev.com/c10cfa8427d4c07ef786eaf2053dee663f6150c4/build/timestamp.gni
[modify] https://crrev.com/72c03041cad06f204c6e1c09af414381e032e999/build/write_build_date_header.py

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/967d1f1e6adc9b7641a5b0174c48f0883e293880

commit 967d1f1e6adc9b7641a5b0174c48f0883e293880
Author: Nico Weber <thakis@chromium.org>
Date: Fri Aug 17 02:42:02 2018

Reland "win: write a deterministic-ish timestamp into the PE/COFF header instead of the current time"

This reverts commit 2df0c83aee0a00bc0f7c26a22b68b4ea3eefef80.

Reason for revert: official android should be fine with this after #583420

Original change's description:
> Revert "win: write a deterministic-ish timestamp into the PE/COFF header instead of the current time"
> 
> This reverts commit ef36dc19986a90f49d0d31520c88d310d72bd038.
> 
> Reason for revert: This turns out to break the official android build, which apparently was relying on a broken aspect of the build that this fixed :(. See https://crbug.com/871173.
> 
> Original change's description:
> > win: write a deterministic-ish timestamp into the PE/COFF header instead of the current time
> >
> > We used to set the timestamp to a hash of the binary, similar to
> > https://blogs.msdn.microsoft.com/oldnewthing/20180103-00/?p=97705
> > However, that caused an appcompat warning on Windows 7 to appear, which
> > interpreted the hash as a timestamp. (It's possible that https://llvm.org/PR38429
> > could help with that, but my guess it won't have an effect on Windows 7,
> > which likely always believes that the the coff timestamp field always stores
> > a timestamp).
> >
> > So currently we write the current time during linking in that field, but that's
> > bad for build determinism and that in turn is bad for swarming test result cachability.
> >
> > build/write_build_date_header.py already creates a deterministic BUILD_DATE
> > with several tradeoffs. Cachability wants this to change infrequently, but
> > things like HSTS need a "real" build date and want this to change frequently.
> > The compromise is: The date changes once per day in official builds, and
> > once a month in regular builds.
> >
> > (We could use /Brepro in ldflags instead of /TIMESTAMP for unofficial builds to get
> > the binary hash in the timestamp, but having the header timestamp match the BUILD_DATE
> > define seems nice.)
> >
> > So let's use that same time as timestamp in the PE/COFF header. lld-link has a
> > /TIMESTAMP: flag we can use to pass in an explicit timestamp.
> >
> > Since tools can't have deps, we need to compute the timestamp at gn time,
> > so split write_build_date_header.py in two pieces: build/compute_build_timestamp.py
> > that just prints the timestamp we want to use, and the old write_build_date_header.py, which
> > now takes that timestamp and writes the header file.
> >
> > Call compute_build_timestamp.py at gn time so that we can pass it in ldflags, and
> > pass the resultl to write_build_date_header.py which keeps running as an action
> > during build time (so that we at least don't need to write a file at gn time).
> >
> > An additional wrinkle here is that the PE/COFF timestamp is used as one of just two
> > keys per binary for uploading PE binaries to the symbol server, the other being file size.
> > https://bugs.llvm.org/show_bug.cgi?id=35914#c0 has a good description of this, and
> > tools/symsrc/img_fingerprint.py's GetImgFingerprint() is our implementation of it.
> > But since we only upload binaries with symbols for official chrome builds to the symbol server,
> > a timestamp that changes once a day should be still enough. (32-bit and 64-bit chromes
> > have the same filename, and we might rarely build canary and beta and stable all on the
> > same day, but them all being the same size seems highly unlikely.)
> >
> > Bug:  843199 , 804926 ,330260
> > Change-Id: I1d4193cc537ae0c4b2d6ac9281fad29de754dd6c
> > Reviewed-on: https://chromium-review.googlesource.com/1161104
> > Reviewed-by: Dirk Pranke <dpranke@chromium.org>
> > Reviewed-by: Hans Wennborg <hans@chromium.org>
> > Commit-Queue: Nico Weber <thakis@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#580585}
> 
> TBR=thakis@chromium.org,hans@chromium.org,dpranke@chromium.org
> NOTRY=true
> 
> # Not skipping CQ checks because original CL landed > 1 day ago.
> 
> Bug:  843199 ,  804926 , 330260
> Change-Id: Ib93697a82f8a9d3fb303b763609e82e0612887cd
> Reviewed-on: https://chromium-review.googlesource.com/1166203
> Commit-Queue: Hans Wennborg <hans@chromium.org>
> Reviewed-by: Dirk Pranke <dpranke@chromium.org>
> Reviewed-by: Nico Weber <thakis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#581485}

TBR=thakis@chromium.org,hans@chromium.org,dpranke@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug:  843199 ,  804926 , 330260
Change-Id: I136e405c84eba3f61a4ac96b2017a34ade0cfba6
Reviewed-on: https://chromium-review.googlesource.com/1179281
Commit-Queue: Nico Weber <thakis@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Cr-Commit-Position: refs/heads/master@{#583945}
[modify] https://crrev.com/967d1f1e6adc9b7641a5b0174c48f0883e293880/base/BUILD.gn
[add] https://crrev.com/967d1f1e6adc9b7641a5b0174c48f0883e293880/build/compute_build_timestamp.py
[modify] https://crrev.com/967d1f1e6adc9b7641a5b0174c48f0883e293880/build/config/win/BUILD.gn
[modify] https://crrev.com/967d1f1e6adc9b7641a5b0174c48f0883e293880/build/dotfile_settings.gni
[add] https://crrev.com/967d1f1e6adc9b7641a5b0174c48f0883e293880/build/timestamp.gni
[modify] https://crrev.com/967d1f1e6adc9b7641a5b0174c48f0883e293880/build/write_build_date_header.py