The default bug view has changed. See this FAQ.

make package for XULRunner builds fails with "run-mozilla.sh: No such file or directory"

RESOLVED FIXED in Firefox 17

Status

()

Core
Build Config
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: imphil, Assigned: espindola)

Tracking

17 Branch
mozilla18
x86_64
Linux
Points:
---
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(firefox17+ fixed)

Details

(Whiteboard: [qa-])

Attachments

(3 attachments)

(Reporter)

Description

5 years ago
Created attachment 657194 [details]
build log

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

5 years ago
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.
tracking-firefox17: --- → ?
tracking-firefox17: ? → +
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:

https://tbpl.mozilla.org/?tree=Try&rev=7e270341ac51
Assignee: nobody → respindola
Status: NEW → ASSIGNED
Attachment #659739 - Flags: review?(mh+mozilla)
A new try push including pr789983 is at

https://tbpl.mozilla.org/?tree=Try&rev=8559dbd9752d
Attachment #659739 - Flags: review?(mh+mozilla) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/8e80b52fd92c
https://hg.mozilla.org/mozilla-central/rev/8e80b52fd92c
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Target Milestone: --- → mozilla18
(Reporter)

Comment 9

5 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
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.
(Reporter)

Comment 13

5 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

5 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?
(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.
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:
https://tbpl.mozilla.org/?tree=Try&rev=d475d0284770
Attachment #661833 - Flags: approval-mozilla-aurora?
Attachment #661833 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
 https://hg.mozilla.org/releases/mozilla-aurora/rev/63cc7e15cfcd
 https://hg.mozilla.org/releases/mozilla-aurora/rev/63cc7e15cfcd

Updated

5 years ago
status-firefox17: --- → fixed
Whiteboard: [qa-]
You need to log in before you can comment on or make changes to this bug.