Andrew McCreight [:mccr8] Reporter
	Description • 10 years ago

If I have an unmodified directory, then do ./mach build, near the end it says this:
   1:01.20 Packaging quitter@mozilla.org.xpi...

Then somehow tools/quitter/chrome.manifest is modified, which shows up in git:

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   tools/quitter/chrome.manifest

The diff is this:

diff --git a/tools/quitter/chrome.manifest b/tools/quitter/chrome.manifest
index feffe54..b01f046 100644
--- a/tools/quitter/chrome.manifest
+++ b/tools/quitter/chrome.manifest
@@ -1,4 +1,4 @@
-content quitter chrome/quitter/content/
+category profile-after-change @mozilla.org/quitter-observer;1 @mozilla.org/quitter-observer;1
 component {c235a986-5ac1-4f28-ad73-825dae9bad90} components/QuitterObserver.js
+content quitter chrome/quitter/content/
 contract @mozilla.org/quitter-observer;1 {c235a986-5ac1-4f28-ad73-825dae9bad90}
-category profile-after-change @mozilla.org/quitter-observer;1 @mozilla.org/quitter-observer;1

So I have to repeatedly do a git checkout -- tools/quitter/chrome.manifest which is obviously not great. :)  This is a recent regression.

	Michael Shal [:mshal]
	Comment 1 • 10 years ago

I think this was caused by bug 1005704, though I'm not totally sure why yet. Still looking into it...

	(no longer active)
	Comment 2 • 10 years ago

Hmm, I don't have any idea how this might be happening. :(  Should I back out bug 1005704?

	(no longer active)
	Comment 3 • 10 years ago

Oh... I can actually reproduce...

	(no longer active)
	Comment 4 • 10 years ago

It seems like something is sorting chrome.manifest...

	Michael Shal [:mshal]
	Comment 5 • 10 years ago

Oh, it's because using INSTALL_TARGETS makes obj/dist/xpi-stage/quitter/chrome.manifest a symlink back to the srcdir now (instead of a copy), so when jar.py tries to update chrome.manifest, it's changing the original.

	(no longer active)
	Comment 6 • 10 years ago

Ah, I see...  OK, any ideas how we should fix it?

	Michael Shal [:mshal]
	Comment 7 • 10 years ago

Not off-hand - I'm currently trying to see if we can make jar.py use an input manifest (the srcdir one) and write to the output manifest (the objdir one), then we can just remove chrome.manifest from the INSTALL_TARGET.

	Mike Hommey [:glandium]
	Comment 8 • 10 years ago

Just don't install chrome.manifest as a symlink.

	Michael Shal [:mshal]
	Comment 9 • 10 years ago

(In reply to Mike Hommey [:glandium] from comment #8)
> Just don't install chrome.manifest as a symlink.

Do we have a way to do that? Or are you suggesting a custom INSTALL call in libs:: or something? I don't see a way to have INSTALL_TARGETS not do a symlink, but maybe I'm just missing it.

	Mike Hommey [:glandium]
	Comment 10 • 10 years ago

(In reply to Michael Shal [:mshal] from comment #9)
> Do we have a way to do that? Or are you suggesting a custom INSTALL call in
> libs:: or something? I don't see a way to have INSTALL_TARGETS not do a
> symlink, but maybe I'm just missing it.

I'd say just back out the part that changed how it's installed.

	Gene Lian (I already quit Mozilla)
	Comment 11 • 10 years ago

+1 reproducing this. This will make us hard to maintain the HG patches.

	Daniel Holbert [:dholbert]
	Comment 12 • 10 years ago

FWIW, I've now seen this make it into at least one patch posted on Bugzilla: attachment 8418822 [details] [diff] [review].

In any case, this should now be fixed on m-c by ehsan's backout of bug 1005704.

	Andrew McCreight [:mccr8] Reporter
	Comment 13 • 10 years ago

fixed by backout