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: 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: *** [make-package] Error 1 make: *** [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!
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).
armenzg says this probably doesn't need to block on releng's behalf. bhearsum, let me know if you disagree.
blocking2.0: betaN+ → -
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 :(.
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
You need to log in before you can comment on or make changes to this bug.