Closed Bug 600832 Opened 14 years ago Closed 10 years ago

make package fails on mac when run again

Categories

(Firefox Build System :: General, defect)

x86
macOS
defect
Not set
normal

Tracking

(blocking2.0 -)

RESOLVED WORKSFORME
Tracking Status
blocking2.0 --- -

People

(Reporter: bhearsum, Unassigned)

Details

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
Drivers, this bug needs to block beta 7 because it will break packaging on Mac release builds.
blocking2.0: --- → ?
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+
(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!
Assignee: nobody → mwu
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
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
Blocks: 600838
blocking2.0: beta7+ → betaN+
armenzg says this probably doesn't need to block on releng's behalf. bhearsum, let me know if you disagree.
blocking2.0: betaN+ → -
Agreed.
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)
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.
(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.)
Sounds like it does more than I need it to for bug 600838, but if it works I won't complain!
The workaround of running postflight_all between packagings worked fine, but it takes 5m40s to run that target on a build machine :(.
No longer blocks: 600838
AFAICT this bug isn't an issue anymore. I assume it got fixed by the packaging code rewrite.
Assignee: mwu → nobody
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.