Closed Bug 1368699 Opened 7 years ago Closed 6 years ago

./mach build faster doesn't work properly without passing -purgecaches when running Firefox

Categories

(Firefox Build System :: General, defect, P3)

defect

Tracking

(firefox-esr52 unaffected, firefox58 wontfix, firefox59 wontfix, firefox60 fixed)

RESOLVED FIXED
mozilla60
Tracking Status
firefox-esr52 --- unaffected
firefox58 --- wontfix
firefox59 --- wontfix
firefox60 --- fixed

People

(Reporter: Gijs, Assigned: nalexander)

References

Details

(Keywords: regression, regressionwindow-wanted)

Attachments

(3 files)

It used to be that running:

./mach build faster && ./mach run -P <whatever>

would Just Work and run with my rebuilt changes.

In the last 2-3 weeks, something changed. At first, my builds would crash all the time until the second run, somewhere in JS module loader land. That went away after a day or two.

Now, the crashes have gone away but they have been replaced by something worse: some of the time (and I honestly haven't been able to figure out when, exactly), my changes have no effect. I make changes to JS modules and the modules that run do not have those changes. I don't know how this is possible, but it's very frustrating because it ends up meaning I can't be sure that any changes are actually taking effect. The worst of it is that when I use the JS debugger to try and check, it shows the up-to-date file, meaning it *looks* as if the changes are being run, but the copy the debugger sees isn't necessarily the copy being run (and so current line indications and line breakpoints become meaningless).

./mach build faster should just work.
Go help us isolate this (because I'm not sure which recent changes would cause this):

* Is this with artifact builds or compiled builds?
* Does `mach build` work or is it only `mach build faster`?
* Which file(s) are you changing?
* Which platform?
* Any special mozconfig settings?
Component: mach → Build Config
Flags: needinfo?(gijskruitbosch+bugs)
I got another problem is that $./mach build faster doesn't work on my OSX.

The error log is on following,

Traceback (most recent call last):
 0:01.84   File "/usr/local/Cellar/python/2.7.8_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/runpy.py", line 162, in _run_module_as_main
 0:01.84     "__main__", fname, loader, pkg_name)
 0:01.84   File "/usr/local/Cellar/python/2.7.8_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/runpy.py", line 72, in _run_code
 0:01.84     exec code in run_globals
 0:01.84   File "/Users/Alastor/mozilla-central/python/mozbuild/mozbuild/action/process_install_manifest.py", line 119, in <module>
 0:01.84     main(sys.argv[1:])
 0:01.84   File "/Users/Alastor/mozilla-central/python/mozbuild/mozbuild/action/process_install_manifest.py", line 106, in main
 0:01.84     defines=args.defines)
 0:01.84   File "/Users/Alastor/mozilla-central/python/mozbuild/mozbuild/action/process_install_manifest.py", line 69, in process_manifest
 0:01.84     remove_empty_directories=remove_empty_directories)
 0:01.84   File "/Users/Alastor/mozilla-central/python/mozbuild/mozpack/copier.py", line 399, in copy
 0:01.84     copy_results.append((destfile, f.copy(destfile, skip_if_older)))
 0:01.84   File "/Users/Alastor/mozilla-central/python/mozbuild/mozpack/files.py", line 469, in copy
 0:01.84     skip = not BaseFile.any_newer(dest.path, pp_deps)
 0:01.84   File "/Users/Alastor/mozilla-central/python/mozbuild/mozpack/files.py", line 138, in any_newer
 0:01.84     if dest_mtime < int(os.path.getmtime(input) * 1000):
 0:01.84   File "/Users/Alastor/build_mc_obj/_virtualenv/bin/../lib/python2.7/genericpath.py", line 54, in getmtime
 0:01.84     return os.stat(filename).st_mtime
 0:01.84 OSError: [Errno 2] No such file or directory: '/Users/Alastor/mozilla-central/browser/components/preferences/in-content/searchResults.xul'
 0:01.85 make: *** [install-dist/bin/browser] Error 1
(In reply to Alastor Wu [:alwu][please needinfo? me] from comment #2)
> I got another problem is that $./mach build faster doesn't work on my OSX.
> 
> The error log is on following,
> 
> Traceback (most recent call last):
> <snip>
>  0:01.84 OSError: [Errno 2] No such file or directory:
> '/Users/Alastor/mozilla-central/browser/components/preferences/in-content/
> searchResults.xul'
>  0:01.85 make: *** [install-dist/bin/browser] Error 1

This feels like a separate bug. You would need to clobber for ./mach build faster to work again, because one of the files it assumes it needs was removed (either that or update the relevant .deps files by hand). I thought bug 1230060 was supposed to fix this, but maybe not for whatever type of dependency this was about, or maybe it regressed. Can you file a separate bug?
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(alwu)
(In reply to :Gijs from comment #3)
> (In reply to Alastor Wu [:alwu][please needinfo? me] from comment #2)
> > I got another problem is that $./mach build faster doesn't work on my OSX.
> > 
> > The error log is on following,
> > 
> > Traceback (most recent call last):
> > <snip>
> >  0:01.84 OSError: [Errno 2] No such file or directory:
> > '/Users/Alastor/mozilla-central/browser/components/preferences/in-content/
> > searchResults.xul'
> >  0:01.85 make: *** [install-dist/bin/browser] Error 1
> 
> This feels like a separate bug. You would need to clobber for ./mach build
> faster to work again, because one of the files it assumes it needs was
> removed (either that or update the relevant .deps files by hand). I thought
> bug 1230060 was supposed to fix this, but maybe not for whatever type of
> dependency this was about, or maybe it regressed. Can you file a separate
> bug?

Ah, it could work well after running $./mach clobber.
Thanks!
Flags: needinfo?(alwu)
(In reply to Gregory Szorc [:gps] from comment #1)
> Go help us isolate this (because I'm not sure which recent changes would
> cause this):
> 
> * Is this with artifact builds or compiled builds?

Compiled builds, though I wouldn't be surprised if it happens with artifact ones, too.

> * Does `mach build` work or is it only `mach build faster`?

It seems to be intermittent. I haven't worked out what triggers this. The original issue is with `./mach build faster` not working correctly. ISTR `./mach build browser/components` had the same issue but because it's intermittent I'm having trouble isolating it to anything in particular at this point.

STR:

1. Do a full build
2. open browser/components/customizableui/PanelMultiView.jsm
3. find the handleEvent method that has:

      case "popupshowing":
        this.node.setAttribute("panelopen", "true");

and add this to the popupshowing case as the first line (ie inbetween those 2 lines):

        Cu.reportError('Look at me, opening a panel');

and save the file.

4. run ./mach build faster && ./mach run -P <extantprofile>
5. open the browser console (accel-shift-j)
6. open the panel

ER:
console gets the error message from the Cu.reportError
AR:
no error.

... but after repeating these steps a few times, it seems now everything *is* updating correctly, and I can't work out what the difference is, ie why it now works when it didn't an hour ago.

> * Which file(s) are you changing?

browser/components/customizableui/PanelMultiView.jsm

> * Which platform?

OSX, but I originally saw this on Windows. I would be surprised if it was OS-specific, though I'm aware OSX presumably uses symlinks for local builds of this file, and Windows won't.

> * Any special mozconfig settings?

Nope:

> mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../builds/opt/
> 
> ac_add_options --enable-warnings-as-errors


is all of my mozconfig.
Thanks for the info, Gijs. It's very helpful.

Your mozconfig is simple, which is good.

PanelMultiView.jsm is part of EXTRA_JS_MODULES, which has simple semantics as far as the build system goes. Combined with the fact that you can reproduce this on both Windows and OS X is... alarming. The build mechanism here is pretty basic and AFAIK there haven't been significant changes in this area recently.

You've said -purgecaches makes the problem go away. To me, that says that the build system is putting the bits in the right places but Firefox is using old, cached bits.

If you can isolate this to -purgecaches fixing the problem without running a build in between, then I'm fairly confident the bug is in the cache and not the build system. Now, we /may/ need a workaround in the build system to touch a file or something. But someone who understands the cache will need to weigh in.

The modules page says Nathan Froyd is module owner for XPCOM. So let's see what he says.
Flags: needinfo?(nfroyd)
Looks like -purgecaches controls things like:

http://dxr.mozilla.org/mozilla-central/source/toolkit/xre/nsAppRunner.cpp#2765

Which suggests that the startup cache is caching too much?...but only sometimes, because Gijs can't reproduce the problem anymore?

I don't think this is a build system problem.  Gijs, are you able to bisect this at all?
Component: Build Config → XPCOM
Flags: needinfo?(nfroyd) → needinfo?(gijskruitbosch+bugs)
So, there's one thing that is build system related:

https://dxr.mozilla.org/mozilla-central/source/config/rules.mk#1605-1609
These rules create a dist/bin/.purgecaches file.

And the startup code that tries to use that file picks it up in the application directory:
https://dxr.mozilla.org/mozilla-central/source/toolkit/xre/nsAppRunner.cpp#237
https://dxr.mozilla.org/mozilla-central/source/toolkit/xre/nsAppRunner.cpp#4126-4133

For Firefox, the application directory is dist/bin/browser, not dist/bin.

A similar bug was bug 790115 for metro, and it's bug 755724 that actually broke this by not adjusting the .purgecaches touching code to add dist/bin/browser to the list.
This happened in the past and was fixed, see bug 1211957 comment 4
(In reply to Nathan Froyd [:froydnj] from comment #7)
> Looks like -purgecaches controls things like:
> 
> http://dxr.mozilla.org/mozilla-central/source/toolkit/xre/nsAppRunner.
> cpp#2765
> 
> Which suggests that the startup cache is caching too much?...but only
> sometimes, because Gijs can't reproduce the problem anymore?
> 
> I don't think this is a build system problem.  Gijs, are you able to bisect
> this at all?

Nope. :-(

Locally, things have so far gone back to normal... but I have no idea why / how to check what was happening before.
Flags: needinfo?(gijskruitbosch+bugs)
I'm just seeing this happening again now, this time with browser/extensions/pocket/bootstrap.js .

(In reply to Mike Hommey [:glandium] from comment #8)
> So, there's one thing that is build system related:
> 
> https://dxr.mozilla.org/mozilla-central/source/config/rules.mk#1605-1609
> These rules create a dist/bin/.purgecaches file.
> 
> And the startup code that tries to use that file picks it up in the
> application directory:
> https://dxr.mozilla.org/mozilla-central/source/toolkit/xre/nsAppRunner.
> cpp#237
> https://dxr.mozilla.org/mozilla-central/source/toolkit/xre/nsAppRunner.
> cpp#4126-4133
> 
> For Firefox, the application directory is dist/bin/browser, not dist/bin.
> 
> A similar bug was bug 790115 for metro, and it's bug 755724 that actually
> broke this by not adjusting the .purgecaches touching code to add
> dist/bin/browser to the list.

gijs-mbp:firefox-unified gkruitbosch$ ls ../builds/opt/dist/bin/browser/.purgecaches
ls: ../builds/opt/dist/bin/browser/.purgecaches: No such file or directory
gijs-mbp:firefox-unified gkruitbosch$ ls ../builds/opt/dist/bin/.purgecaches
ls: ../builds/opt/dist/bin/.purgecaches: No such file or directory
gijs-mbp:firefox-unified gkruitbosch$ ls ../builds/opt/dist/.purgecaches
ls: ../builds/opt/dist/.purgecaches: No such file or directory


./mach run is running from that dir:

gijs-mbp:firefox-unified gkruitbosch$ ./mach run -P trunk
 0:00.25 /Users/gkruitbosch/dev/builds/opt/dist/Nightly.app/Contents/MacOS/firefox -P trunk -no-remote -foreground


gijs-mbp:firefox-unified gkruitbosch$ find ../builds/opt/dist/ -iname '.purgecaches'

returns nothing.

I can rerun with ./mach run multiple times, and the updated file is still not read. If I open the browser toolbox, it shows the updated file, but when stepping through it with the debugger, it is clear that the lines I added are not really being executed by the JS engine (the highlighted lines are offset by the number of lines I added, and so it highlights commented out lines etc.).
Last ./mach build faster output:

gijs-mbp:firefox-unified gkruitbosch$ ./mach build faster && ./mach run -P trunk
 0:00.32 /usr/bin/make -C /Users/gkruitbosch/dev/builds/opt -j8 -s backend
 0:00.48 /usr/bin/make -C faster -j8 -s
 0:00.66 source-repo.h
 0:00.67 buildid.h
 0:00.81 Elapsed: 0.04s; From dist/idl: Kept 1095 existing; Added/updated 0; Removed 0 files and 0 directories.
 0:01.36 application.ini
 0:01.55 Elapsed: 0.00s; From /Users/gkruitbosch/dev/builds/opt/dist/bin/gmp-clearkey/0.1: Kept 0 existing; Added/updated 1; Removed 0 files and 0 directories.
 0:01.55 Elapsed: 0.00s; From /Users/gkruitbosch/dev/builds/opt/dist/bin/gmp-fake/1.0: Kept 2 existing; Added/updated 0; Removed 0 files and 0 directories.
 0:01.55 Elapsed: 0.00s; From /Users/gkruitbosch/dev/builds/opt/dist/bin/browser/features/followonsearch@mozilla.com: Kept 1 existing; Added/updated 1; Removed 0 files and 0 directories.
 0:01.55 Elapsed: 0.01s; From /Users/gkruitbosch/dev/builds/opt/dist/bin/browser/features/shield-recipe-client@mozilla.org: Kept 31 existing; Added/updated 1; Removed 0 files and 0 directories.
 0:01.56 Elapsed: 0.01s; From /Users/gkruitbosch/dev/builds/opt/dist/bin/browser/features/firefox@getpocket.com: Kept 55 existing; Added/updated 3; Removed 0 files and 0 directories.
 0:01.57 Elapsed: 0.00s; From /Users/gkruitbosch/dev/builds/opt/dist/bin/gmp-fakeopenh264/1.0: Kept 2 existing; Added/updated 0; Removed 0 files and 0 directories.
 0:01.78 Elapsed: 0.00s; From /Users/gkruitbosch/dev/builds/opt/dist/bin/browser/features/webcompat@mozilla.org: Kept 2 existing; Added/updated 1; Removed 0 files and 0 directories.
 0:01.78 Elapsed: 0.00s; From /Users/gkruitbosch/dev/builds/opt/dist/bin/browser/features/flyweb@mozilla.org: Kept 20 existing; Added/updated 1; Removed 0 files and 0 directories.
 0:01.78 Elapsed: 0.01s; From /Users/gkruitbosch/dev/builds/opt/dist/bin/browser/features/formautofill@mozilla.org: Kept 29 existing; Added/updated 1; Removed 0 files and 0 directories.
 0:01.78 Elapsed: 0.00s; From /Users/gkruitbosch/dev/builds/opt/dist/bin/browser/features/presentation@mozilla.org: Kept 3 existing; Added/updated 2; Removed 0 files and 0 directories.
 0:01.78 Elapsed: 0.01s; From /Users/gkruitbosch/dev/builds/opt/dist/bin/browser/features/webcompat-reporter@mozilla.org: Kept 12 existing; Added/updated 3; Removed 0 files and 0 directories.
 0:01.79 Elapsed: 0.01s; From /Users/gkruitbosch/dev/builds/opt/dist/bin/browser/features/activity-stream@mozilla.org: Kept 34 existing; Added/updated 1; Removed 0 files and 0 directories.
 0:01.81 Elapsed: 0.00s; From /Users/gkruitbosch/dev/builds/opt/dist/bin/browser/features/onboarding@mozilla.org: Kept 4 existing; Added/updated 2; Removed 0 files and 0 directories.
 0:01.91 Elapsed: 0.00s; From /Users/gkruitbosch/dev/builds/opt/dist/bin/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}: Kept 0 existing; Added/updated 2; Removed 0 files and 0 directories.
 0:02.32 Elapsed: 0.41s; From /Users/gkruitbosch/dev/builds/opt/dist/bin: Kept 1603 existing; Added/updated 65; Removed 0 files and 0 directories.
 0:02.33 Elapsed: 0.77s; From /Users/gkruitbosch/dev/builds/opt/dist/bin/browser: Kept 2886 existing; Added/updated 92; Removed 0 files and 0 directories.
 0:03.49 Overall system resources - Wall time: 3s; CPU: 50%; Read bytes: 3359232; Write bytes: 38313472; Read time: 49; Write time: 432
 0:03.49 Swap in/out (MB): 1/0
 0:03.50 Your build was successful!
To view resource usage of the build, run |mach resource-usage|.
 0:00.23 /Users/gkruitbosch/dev/builds/opt/dist/Nightly.app/Contents/MacOS/firefox -P trunk -no-remote -foreground
Some observations:

- after adding .purgecaches files in dist/, dist/bin/ and dist/bin/browser, and restarting (but not rerunning ./mach build of any kind), nothing happens. Still broken.
- after then once rerunning ./mach build faster, things work and files are updated. Note that at this point, the .purgecaches files were added to the mac app bundle (they weren't before):

    gijs-mbp:firefox-unified gkruitbosch$ find ../builds/opt/dist/ -iname '.purgecaches'
    ../builds/opt/dist//.purgecaches
    ../builds/opt/dist//bin/.purgecaches
    ../builds/opt/dist//bin/browser/.purgecaches
    ../builds/opt/dist//Nightly.app/Contents/Resources/.purgecaches
    ../builds/opt/dist//Nightly.app/Contents/Resources/browser/.purgecaches 

- after that, when updating pocket's bootstrap.js, I don't need to even rerun ./mach build because the file is symlinked in, and at this point nightly re-reads it every time, it seems.
- if I remove the .purgecaches files and re-run ./mach build faster, the above 'find' command returns no files again, and things are broken again.


Finally, things in comment #11 started after a clobber build and a series of ./mach build faster builds. Not sure anymore if things updated at all between the clobber and the point where things failed, but the clobber build was done yesterday and then went unused until this morning. Also, in case it matters, this profile ('trunk') gets reused for regular nightly builds when I want to test something against vanilla mozilla-produced nightly, which seems to trigger bug 1371273, which may or may not be related.
See Also: → 1386040
See Also: → 1389778
See Also: → 1389502
Priority: -- → P3
Assignee: nobody → nalexander
Status: NEW → ASSIGNED
Depends on: 1429815
The patches on this bug are all in the build system. Moving component.
Component: XPCOM → Build Config
Attachment #8944088 - Flags: review?(core-build-config-reviews) → review?(gps)
Attachment #8944089 - Flags: review?(core-build-config-reviews) → review?(gps)
Attachment #8944090 - Flags: review?(core-build-config-reviews) → review?(gps)
Comment on attachment 8944088 [details]
Bug 1368699 - Pre: Remove MY_{CONFIG,RULES} Makefile customization hooks.

https://reviewboard.mozilla.org/r/214402/#review220394

Further evidence this feature is unused: no entries for these files in .hgignore or .gitignore. I would hope that if people were using this, they'd be tired of seeing untracked files in their repos and would have submitted a patch to the ignore files.
Attachment #8944088 - Flags: review?(gps) → review+
Comment on attachment 8944089 [details]
Bug 1368699 - Write .purgecaches sentinels every |mach build|.

https://reviewboard.mozilla.org/r/214404/#review220396

I think this needs some work before r+.

Thank you for the detailed history in the commit message. I would have asked questions like "why not in the build backend" as part of review if the context weren't there.

I'm OK with this functionality living in the build backend and only called from `mach build`. There's a slight chance some people are still not using `mach build`. But we've said for a while that we don't really support building outside the context of `mach`. So I'm fine with this direction.

::: python/mozbuild/mozbuild/backend/base.py:225
(Diff revision 1)
> +        app = config.substs['MOZ_BUILD_APP']
> +        if app == 'browser':
> +            root = mozpath.join(config.topobjdir, 'dist', 'bin', 'browser')
> +
> +        purgecaches_dirs = [root]
> +        if app == 'browser' and 'cocoa' == config.substs['MOZ_WIDGET_TOOLKIT']:

Why are we limiting this to the `browser` app? Can we not use e.g. `dist/bin/${MOZ_BUILD_APP}/`?

::: python/mozbuild/mozbuild/backend/base.py:238
(Diff revision 1)
> +                                     'Contents', 'Resources',
> +                                     'browser')
> +            purgecaches_dirs.append(bundledir)
> +
> +        for dir in purgecaches_dirs:
> +            ensureParentDir(dir)

It feels wrong that we have to `ensureParentDir` here. I think a better solution is to only call this code after a successful build. If the directory doesn't exist after successful build, let the exception be raised. That will help find logic errors and prevent us from accidentally creating `.purgecaches` files when we shouldn't be.

::: python/mozbuild/mozbuild/backend/base.py:242
(Diff revision 1)
> +        for dir in purgecaches_dirs:
> +            ensureParentDir(dir)
> +            with open(mozpath.join(dir, '.purgecaches'), 'wt') as f:
> +                f.write('\n')
> +
> +    def postbuild(self, config, output, jobs, verbose, status):

Let's rename this to `post_build`.

::: python/mozbuild/mozbuild/controller/building.py:1088
(Diff revision 1)
> +            except Exception as ex:
> +                self.log(logging.DEBUG, 'postbuild', {'ex': ex},
> +                         "Unable to run active build backend's post-build step: {ex}.")

If the post build step raises, I think we should ensure the exit code is non-0. What do you think?
Attachment #8944089 - Flags: review?(gps) → review-
Comment on attachment 8944090 [details]
Bug 1368699 - Post: Remove PURGECACHES from Make and now-unused app-rules.mk.

https://reviewboard.mozilla.org/r/214406/#review220400

Good riddance.
Attachment #8944090 - Flags: review?(gps) → review+
(In reply to Gregory Szorc [:gps] from comment #19)
> Why are we limiting this to the `browser` app? Can we not use e.g.
> `dist/bin/${MOZ_BUILD_APP}/`?

What is /really/ wanted is to use the FINAL_TARGET as per the MOZ_BUILD_APP directory. Which in the case of browser/ is dist/bin/$MOZ_BUILD_APP, and in the case of about every other app, is dist/bin.
Comment on attachment 8944088 [details]
Bug 1368699 - Pre: Remove MY_{CONFIG,RULES} Makefile customization hooks.

https://reviewboard.mozilla.org/r/214402/#review222436
Attachment #8944088 - Flags: review+
Comment on attachment 8944089 [details]
Bug 1368699 - Write .purgecaches sentinels every |mach build|.

https://reviewboard.mozilla.org/r/214404/#review222438
Attachment #8944089 - Flags: review+
Attachment #8944088 - Flags: review?(core-build-config-reviews)
Attachment #8944089 - Flags: review?(core-build-config-reviews)
Attachment #8944090 - Flags: review?(core-build-config-reviews)
Pushed by nalexander@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/7297a1e8c4ff
Pre: Remove MY_{CONFIG,RULES} Makefile customization hooks. r=gps
https://hg.mozilla.org/integration/autoland/rev/35a5db01b6ae
Write .purgecaches sentinels every |mach build|. r=gps
https://hg.mozilla.org/integration/autoland/rev/e16fc8abd345
Post: Remove PURGECACHES from Make and now-unused app-rules.mk. r=gps
Blocks: 1434482
Backout by ccoroiu@mozilla.com:
https://hg.mozilla.org/mozilla-central/rev/5454ed95c82a
Backed out 3 changesets for bustage on Android L10n nightlies a=backout
Does this need to be REOPENED due to backout ?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: mozilla60 → ---
Pushed by nalexander@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a67ac1c9a5a7
Pre: Remove MY_{CONFIG,RULES} Makefile customization hooks. r=gps
https://hg.mozilla.org/integration/autoland/rev/c3b34905b9c9
Write .purgecaches sentinels every |mach build|. r=gps
https://hg.mozilla.org/integration/autoland/rev/633e0fd655b8
Post: Remove PURGECACHES from Make and now-unused app-rules.mk. r=gps
OK, here's what happened: l10n repacks for Android call |mach configure && mach build buildid.h && mach build config/export| directly.  That's not expected to work -- it's expected that |mach build| is the first thing after |mach configure| -- and I'm confident that the expected directory isn't in place, failing the build step.  That was Greg's preference in his review (https://bugzilla.mozilla.org/show_bug.cgi?id=1368699#c19), and I think it's the right thing to do.  It just gets in the way here.

Rather than addressing this more generally, I just opted out of .purgecaches sentinels for mobile/android entirely.  That's correct enough, and fixes this issue. 

It doesn't address Desktop l10n repacks, but they're snowflakes for other reasons: l10n repacks for Desktop call |make -C ... buildid.h| so they don't feel this pain.


I have a try build with a green l10n repack at https://treeherder.mozilla.org/#/jobs?repo=try&author=nalexander@mozilla.com&selectedJob=159622877, so I'm relanding.
Flags: needinfo?(nalexander)
https://hg.mozilla.org/mozilla-central/rev/a67ac1c9a5a7
https://hg.mozilla.org/mozilla-central/rev/c3b34905b9c9
https://hg.mozilla.org/mozilla-central/rev/633e0fd655b8
Status: REOPENED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla60
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.