Created attachment 657194 [details]
When I build XULRunner on Aurora, I get the following error when running "make package":
adding: hyphenation/hyph_mn.dic (deflated 77%)
adding: hyphenation/hyph_cy.dic (deflated 53%)
adding: update.locale (stored 0%)
/bin/sh: /home/philipp/src/mozilla-aurora/obj-release/dist/xulrunner/run-mozilla.sh: No such file or directory
I attached the full log of make package. Maybe this is a fallout of bug 785102? How are the official packages (on FTP) build, since they seem to be ok?
Btw, obj-release/dist/bin contains a run-mozilla.sh, while obj-release/dist/xulrunner does not.
Note that we now have an alternative workaround for bug 785102: bug 785828.
(In reply to David Rajchenbach Teller [:Yoric] (may have to disappear anyday now for two weeks) from comment #2)
> Note that we now have an alternative workaround for bug 785102: bug 785828.
You have r+ on those. Can you check them in? If so than the fix for this bug is simply to revert back to using $(_ABS_RUN_TEST_PROGRAM).
This linux32 and linux64 build failure has now migrated to Aurora, nominating for tracking so that it gets fixed before 17 makes it to beta.
Created attachment 659739 [details] [diff] [review]
revert 785102 now that we lazy load xul
I did a try push with clang (which it was how bug 785102 was originally found) to:
A new try push including pr789983 is at
This needs to go to aurora as well, probably together with bug 785828? I built aurora and those two patches locally on linux64, and make package works with them. A try job with those two patches is failing on win - is this because of pushing an aurora tree to try or has it something to do with those patches?
The error is different:
Failed to import resource:///modules/services-sync/addonutils.js
so I guess it is a "aurora on try" problem, but I would suggest doing a nop push to be sure. Do I own the "aurora approval" and porting?
(In reply to Rafael Ávila de Espíndola (:espindola) from comment #10)
> The error is different:
> Failed to import resource:///modules/services-sync/addonutils.js
That's not a failure, these kind of things happen when it works.
The actual failure is this:
subprocess.CalledProcessError: Command ' e;C:\mozilla-build\msys\builds\moz2_slave\try-w32\build\obj-firefox\browser\installer\..\..\dist\bin\shlibsign.exe -v -i "firefox\freebl3.dll"' returned non-zero exit status 1
This is another case of msys being annoying by converting paths.
I don't see how the patch could have caused this error, so I suggest it's aurora-on-try's fault (pymake?). To confirm I did a plain try push with the same changeset, let's see how this goes: https://tbpl.mozilla.org/?tree=Try&rev=bea7fc3eca46
Based on the try push without any patches, the burning comes from aurora-on-try and not from the patches, so they should be good to go to aurora.
Rafael, since you did the original fix, do you want to continue with this to get this to aurora? I guess bug 785828 will need aurora-approval as well?
(In reply to Philipp Wagner [:imphil] from comment #14)
> Based on the try push without any patches, the burning comes from
> aurora-on-try and not from the patches, so they should be good to go to
> Rafael, since you did the original fix, do you want to continue with this to
> get this to aurora? I guess bug 785828 will need aurora-approval as well?
Sure, np. I will ask for 785828 approval too. I guess it is not *really* required since a gcc bug makes the second constructor run a nop, but I think we are in a more stable situation with it in than out.
Created attachment 661833 [details] [diff] [review]
backport to aurora
It is probably better to backport this after bug 785828, but I think that is not strictly required.
[Approval Request Comment]
Bug caused by (feature/regressing bug #):
User impact if declined: No XULRunner.
Testing completed (on m-c, etc.):
Risk to taking this patch (and alternatives if risky):
String or UUID changes made by this patch:
Try run on: