Closed
Bug 787334
Opened 12 years ago
Closed 12 years ago
make package for XULRunner builds fails with "run-mozilla.sh: No such file or directory"
Categories
(Firefox Build System :: General, defect)
Tracking
(firefox17+ fixed)
RESOLVED
FIXED
mozilla18
People
(Reporter: imphil, Assigned: espindola)
Details
(Whiteboard: [qa-])
Attachments
(3 files)
133.09 KB,
text/plain
|
Details | |
1.68 KB,
patch
|
glandium
:
review+
|
Details | Diff | Splinter Review |
1.99 KB,
patch
|
lsblakk
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
When I build XULRunner on Aurora, I get the following error when running "make package": --snip-- 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 --snip-- 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?
Reporter | ||
Comment 1•12 years ago
|
||
Btw, obj-release/dist/bin contains a run-mozilla.sh, while obj-release/dist/xulrunner does not.
Comment 2•12 years ago
|
||
Note that we now have an alternative workaround for bug 785102: bug 785828.
Assignee | ||
Comment 3•12 years ago
|
||
(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).
Comment 4•12 years ago
|
||
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.
tracking-firefox17:
--- → ?
Updated•12 years ago
|
Assignee | ||
Comment 5•12 years ago
|
||
I did a try push with clang (which it was how bug 785102 was originally found) to: https://tbpl.mozilla.org/?tree=Try&rev=7e270341ac51
Assignee | ||
Comment 6•12 years ago
|
||
A new try push including pr789983 is at https://tbpl.mozilla.org/?tree=Try&rev=8559dbd9752d
Updated•12 years ago
|
Attachment #659739 -
Flags: review?(mh+mozilla) → review+
Assignee | ||
Comment 7•12 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/8e80b52fd92c
Comment 8•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/8e80b52fd92c
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Target Milestone: --- → mozilla18
Reporter | ||
Comment 9•12 years ago
|
||
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? https://tbpl.mozilla.org/?tree=Try&rev=e40facbd4e6d
Assignee | ||
Comment 10•12 years ago
|
||
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?
Comment 11•12 years ago
|
||
(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.
Comment 12•12 years ago
|
||
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.
Reporter | ||
Comment 13•12 years ago
|
||
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
Reporter | ||
Comment 14•12 years ago
|
||
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?
Assignee | ||
Comment 15•12 years ago
|
||
(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 > 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? 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.
Assignee | ||
Comment 16•12 years ago
|
||
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: https://tbpl.mozilla.org/?tree=Try&rev=d475d0284770
Attachment #661833 -
Flags: approval-mozilla-aurora?
Updated•12 years ago
|
Attachment #661833 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Assignee | ||
Comment 17•12 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/63cc7e15cfcd
Assignee | ||
Comment 18•12 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/63cc7e15cfcd
Updated•12 years ago
|
status-firefox17:
--- → fixed
Updated•6 years ago
|
Product: Core → Firefox Build System
You need to log in
before you can comment on or make changes to this bug.
Description
•