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

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Philipp Wagner [:imphil]]

Attachment: 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?

Comment 1

[Philipp Wagner [:imphil]]

Btw, obj-release/dist/bin contains a run-mozilla.sh, while obj-release/dist/xulrunner does not.

Comment 2

[David Teller [:Yoric] - still alive but not very active]

Note that we now have an alternative workaround for bug 785102: bug 785828.

Comment 3

[Rafael Ávila de Espíndola (:espindola) (not reading bugmail)]

(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

[Nick Thomas [:nthomas] (UTC+12)]

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.

Comment 5

[Rafael Ávila de Espíndola (:espindola) (not reading bugmail)]

Attachment: 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

Comment 6

[Rafael Ávila de Espíndola (:espindola) (not reading bugmail)]

A new try push including pr789983 is at

https://tbpl.mozilla.org/?tree=Try&rev=8559dbd9752d

Comment 7

[Rafael Ávila de Espíndola (:espindola) (not reading bugmail)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/8e80b52fd92c

Comment 8

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/8e80b52fd92c

Comment 9

[Philipp Wagner [:imphil]]

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

Comment 10

[Rafael Ávila de Espíndola (:espindola) (not reading bugmail)]

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

[Mike Hommey [:glandium]]

(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

[Mike Hommey [:glandium]]

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.

Comment 13

[Philipp Wagner [:imphil]]

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

Comment 14

[Philipp Wagner [:imphil]]

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?

Comment 15

[Rafael Ávila de Espíndola (:espindola) (not reading bugmail)]

(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.

Comment 16

[Rafael Ávila de Espíndola (:espindola) (not reading bugmail)]

Attachment: 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

Comment 17

[Rafael Ávila de Espíndola (:espindola) (not reading bugmail)]

 https://hg.mozilla.org/releases/mozilla-aurora/rev/63cc7e15cfcd

Comment 18

[Rafael Ávila de Espíndola (:espindola) (not reading bugmail)]

 https://hg.mozilla.org/releases/mozilla-aurora/rev/63cc7e15cfcd