make package fails on mac when run again

RESOLVED WORKSFORME

Status

Firefox Build System
General
RESOLVED WORKSFORME
8 years ago
4 months ago

People

(Reporter: bhearsum, Unassigned)

Tracking

Trunk
x86
Mac OS X

Firefox Tracking Flags

(blocking2.0 -)

Details

(Reporter)

Description

8 years ago
Ted suggested that this is fallout from omnijar, but we've already shipped releases (which use MOZ_PKG_PRETTYNAMES=1) with it on, so maybe it's omnijar + the universal build changes? Here's the error:
moz2-darwin10-slave01:i386 cltbld$ MOZ_OBJDIR=obj-firefox  MOZ_PKG_PRETTYNAMES=1 MOZ_PKG_VERSION=4.0b10 make package
make export
make[2]: Nothing to be done for `export'.
make libs
Creating package directory...
/tools/buildbot/bin/python2.6 /builds/slave/macosx64_build/build/config/optimizejars.py --optimize ../../dist/jarlog/ ../../dist/bin/chrome ../../dist/universal/firefox/chrome
No jar logs found in ../../dist/jarlog/. No jars to optimize.
Stripping package directory...
signing nss libraries

run-mozilla.sh: Cannot execute ../../../i386/dist/bin/shlibsign.


run-mozilla.sh: Cannot execute ../../../i386/dist/bin/shlibsign.


run-mozilla.sh: Cannot execute ../../../i386/dist/bin/shlibsign.

Removing unpackaged files...
cd ../../dist/universal/firefox/Firefox.app/Contents/MacOS; rm -rf core bsdecho gtscc js js-config jscpucfg nsinstall viewer TestGtkEmbed bloaturls.txt codesighs* elf-dynstr-gc mangle* maptsv* mfc* mkdepend* msdump* msmap* nm2tsv* nsinstall* res/samples res/throbber shlibsign* ssltunnel* certutil* pk12util* winEmbed.exe chrome/chrome.rdf chrome/app-chrome.manifest chrome/overlayinfo components/compreg.dat components/xpti.dat content_unit_tests necko_unit_tests *.dSYM 
/builds/slave/macosx64_build/build/obj-firefox/i386/config/nsinstall -t -m 644 removed-files ../../dist/universal/firefox/Firefox.app/Contents/MacOS
Compressing...
/builds/slave/macosx64_build/build/obj-firefox/i386/config/nsinstall -D ../../dist/mac64/en-US/
cd ../../dist && (cd universal/firefox/Firefox.app/Contents/MacOS && rm -f omni.jar components/binary.manifest && grep -h '^binary-component' components/*.manifest > binary.manifest ; sed -e 's/^binary-component/#binary-component/' components/components.manifest > components.manifest && mv components.manifest components && find . | xargs touch -t 201001010000 && zip -r9mX omni.jar chrome chrome.manifest components/*.js components/*.xpt components/*.manifest modules res defaults greprefs.js  -x chrome/icons/\* defaults/pref/channel-prefs.js res/cursors/\* res/MainMenu.nib/\*  && /tools/buildbot/bin/python2.6 /builds/slave/macosx64_build/build/config/optimizejars.py --optimize /builds/slave/macosx64_build/build/obj-firefox/i386/browser/installer/../../dist/jarlog/ ./ ./ && mv binary.manifest components && printf "manifest components/binary.manifest\n" > chrome.manifest) && /builds/slave/macosx64_build/build/build/package/mac_osx/pkg-dmg --source "universal/firefox" --target "mac64/en-US/Firefox 4.0 Beta 10.dmg" --volname "Firefox"  --copy "branding/dsstore:/.DS_Store" --mkdir /.background --copy "branding/background.png:/.background" --icon "branding/disk.icns" --symlink "/Applications:/ "
grep: components/*.manifest: No such file or directory
sed: components/components.manifest: No such file or directory
make[2]: *** [make-package] Error 1
make[1]: *** [default] Error 2
make: *** [package] Error 2


Requesting blocking
(Reporter)

Comment 1

8 years ago
Drivers, this bug needs to block beta 7 because it will break packaging on Mac release builds.
blocking2.0: --- → ?

Comment 2

8 years ago
Candidates:

4cffee2c859b - Taras Glek - Bug 589368 - Locale repacking support for jar reordering; r=ted a=blocking-betaN+

ea9e5837cf6d
2010-09-03 14:56 +1200	Michael Wu - Bug 589175 - Comment out binary-component entries, r=bsmedberg a=blocking2.0
blocking2.0: ? → beta7+
(Reporter)

Comment 3

8 years ago
(In reply to comment #2)
> ea9e5837cf6d
> 2010-09-03 14:56 +1200    Michael Wu - Bug 589175 - Comment out
> binary-component entries, r=bsmedberg a=blocking2.0

I got 'make package' to work by reversing this patch. j'accuse tu!

Updated

8 years ago
Assignee: nobody → mwu

Comment 4

8 years ago
AFAICT this has nothing to do with MOZ_PKG_PRETTYNAMES. make package just fails if we run it a second time.
Summary: make package fails on mac w/ MOZ_PKG_PRETTYNAMES=1 → make package fails on mac when run again
(Reporter)

Comment 5

8 years ago
I can reproduce that. So, that makes this less serious, and problem not worthy of blocking beta 7, but I still think we should fix it to enable easily testing the MOZ_PKG_PRETTYNAMES codepath (bug 600838).
Version: unspecified → Trunk
(Reporter)

Updated

8 years ago
Blocks: 600838
blocking2.0: beta7+ → betaN+

Comment 6

8 years ago
armenzg says this probably doesn't need to block on releng's behalf. bhearsum, let me know if you disagree.
blocking2.0: betaN+ → -
(Reporter)

Comment 7

8 years ago
Agreed.
(Reporter)

Comment 8

7 years ago
I'm hoping to fix bug 600838 in the next couple of weeks, which is blocked partly by this. Michael, any idea how to fix this? (As a refresher, this was caused by bug 589175)

Comment 9

7 years ago
An alternate workaround to rebuilding before every make package is to run make -f client.mk postflight_all . The problem is that packaging expects the staging directory to be fresh before every run, and that assumption doesn't hold in universal builds. We might be able to just workaround this by making the failing commands not fail, but it seems slightly fragile.
(Reporter)

Comment 10

7 years ago
(In reply to comment #9)
> An alternate workaround to rebuilding before every make package is to run make
> -f client.mk postflight_all .

I'll give that a try, it might work for my particular need. Are there other side effects of this that I should be aware of? Any idea if it will affect subsequent, incremental builds?

> The problem is that packaging expects the staging
> directory to be fresh before every run, and that assumption doesn't hold in
> universal builds. We might be able to just workaround this by making the
> failing commands not fail, but it seems slightly fragile.

Yeah, agreed. Perhaps 'make package' should be cleaning after itself, assuming it packaged successfully?
(In reply to comment #10)
> (In reply to comment #9)
> > An alternate workaround to rebuilding before every make package is to run make
> > -f client.mk postflight_all .
> 
> I'll give that a try, it might work for my particular need. Are there other
> side effects of this that I should be aware of? Any idea if it will affect
> subsequent, incremental builds?

The postflight_all target gets run after every top-level build from client.mk anyway:
http://mxr.mozilla.org/mozilla-central/source/build/macosx/universal/flight.mk#91

It's what merges the two individual builds into a universal binary. It's not terribly complicated, it runs stage-package in each objdir, then uses unify to zip them together. (Then it does the same thing for the test package.)
(Reporter)

Comment 12

7 years ago
Sounds like it does more than I need it to for bug 600838, but if it works I won't complain!
(Reporter)

Comment 13

7 years ago
The workaround of running postflight_all between packagings worked fine, but it takes 5m40s to run that target on a build machine :(.
(Reporter)

Updated

7 years ago
No longer blocks: 600838

Comment 14

4 years ago
AFAICT this bug isn't an issue anymore. I assume it got fixed by the packaging code rewrite.
Assignee: mwu → nobody
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME

Updated

4 months ago
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.