In bug 780561, I'm going to change how universal builds are produced, and one of the changes require that the packaging happens on the x86_64 objdir for the startupcache population runs. Using the x86_64 objdir instead of i386 should have no effect, although it would be better to check everything goes fine.

Comment on attachment 688447 [details] [diff] [review] Run commands in the x86_64 objdir on OSX universal builds Does calendar/ still need/use these buildbot-configs?

Can someone from releng test this patch? (it doesn't depend on the work in bug 780561, in theory, it's essentially a no-op for current builds, but it would be better to be sure)

I'll test some Firefox & Thunderbird builds in staging.

(In reply to Mike Hommey [:glandium] from comment #3) > ... it doesn't depend on the work in > bug 780561, in theory, it's essentially a no-op for current builds, but it > would be better to be sure) This doesn't appear to be true. In a 'OS X 10.7 mozilla-central nightly' build the compile step completes, but 'make buildsymbols fails': make buildsymbols in dir /builds/slave/m-cen-osx64-ntly/build/obj-firefox/x86_64 (timeout 3600 secs) ... echo building symbol store building symbol store rm -f -r ./dist/crashreporter-symbols rm -f "./dist/firefox-20.0a1.en-US.mac.crashreporter-symbols.zip" /builds/slave/m-cen-osx64-ntly/build/obj-firefox/x86_64/config/nsinstall -D ./dist/crashreporter-symbols OBJCOPY="" \ /builds/slave/m-cen-osx64-ntly/build/obj-firefox/x86_64/_virtualenv/bin/python /builds/slave/m-cen-osx64-ntly/build/toolkit/crashreporter/tools/symbolstore.py \ -c -a "i386 x86_64" --vcs-info \ -s /builds/slave/m-cen-osx64-ntly/build \ ./dist/host/bin/dump_syms \ ./dist/crashreporter-symbols \ ./dist/universal | grep -iv test > \ ./dist/crashreporter-symbols/firefox-20.0a1-Darwin-20121204181539-x86_64-macosx64-symbols.txt make: *** [buildsymbols] Error 1 Turns out obj-firefox/x86_64/dist/universal is relative symlink to obj-firefox/i386/dist/universal, which doesn't exist.

Note from a brief look this might fix bug 609125 which means we'd be running make check against the 64-bit side of the builds rather than the 32-bit side.

(In reply to Nick Thomas [:nthomas] from comment #5) > Turns out obj-firefox/x86_64/dist/universal is relative symlink to > obj-firefox/i386/dist/universal, which doesn't exist. That's weird, it should exist after flight.mk is run at the end of the build...

Ah, the creation of the symlink is just plain wrong: ln -s obj-firefox/i386/dist/universal obj-firefox/x86_64/dist/universal Such a change to buildbot-config would need that to be fixed on all branches, wouldn't it? What branches would we be talking about?

Comment on attachment 688447 [details] [diff] [review] Run commands in the x86_64 objdir on OSX universal builds We currently only run beta builds on our own infra. Given I'd like to get rid of those builds by the next release I'm fine with these changes even if they break us. Easy to locally undo :)

So, I arranged things in the new packager such that I don't need this anymore. You may however want to do the switch for bug 609125, but note it requires the fix for bug 818394 to land and ride the trains.

(In reply to Nick Thomas [:nthomas] from comment #5) > (In reply to Mike Hommey [:glandium] from comment #3) > > ... it doesn't depend on the work in > > bug 780561, in theory, it's essentially a no-op for current builds, but it > > would be better to be sure) > > This doesn't appear to be true. In a 'OS X 10.7 mozilla-central nightly' > build the compile step completes, but 'make buildsymbols fails': You may want to give another spin at the patch now that bug 818394 has landed.

I ran a couple of builds in staging, which got mozilla-central rev 725eb8792d27. The Firefox desktop nightly had no failures, logs are at http://people.mozilla.com/~nthomas/bug818255-2-firefox-nightly.tgz. My first attempt at XULRunner died with bug 812918.

The second XULRunner build was green, logs at: http://people.mozilla.com/~nthomas/bug818255-2-xulrunner-nightly.tgz

Nick, can this be landed now? Assigning to you since you..uh..touched it last.

Comment on attachment 688447 [details] [diff] [review] [diff] [review] Run commands in the x86_64 objdir on OSX universal builds ---------AUTOMATIC COMMENT--------- -- filter pep8-callek-june-2013 -- ---------AUTOMATIC COMMENT--------- $pep8 <dir> --diff --max-line-length=159 --show-source < attachment.diff /tmp/tmp.xmjtPcFsTz/calendar/config.py:184:5: E128 continuation line under-indented for visual indent 'MOZ_OBJDIR': OBJDIR, ^ /tmp/tmp.xmjtPcFsTz/calendar/config.py:315:5: E128 continuation line under-indented for visual indent 'MOZ_OBJDIR': OBJDIR, ^ /tmp/tmp.xmjtPcFsTz/calendar/config.py:576:5: E128 continuation line under-indented for visual indent 'MOZ_OBJDIR': OBJDIR, ^ /tmp/tmp.xmjtPcFsTz/mozilla/config.py:266:32: E261 at least two spaces before inline comment 'mpfr', # required for system compiler ^ /tmp/tmp.xmjtPcFsTz/mozilla/config.py:267:42: E261 at least two spaces before inline comment 'xorg-x11-font*', # fonts required for PGO ^ /tmp/tmp.xmjtPcFsTz/mozilla/config.py:268:33: E261 at least two spaces before inline comment 'imake', # required for makedepend!?! ^ /tmp/tmp.xmjtPcFsTz/mozilla/config.py:269:89: E261 at least two spaces before inline comment 'gcc45_0moz3', 'gcc454_0moz1', 'gcc472_0moz1', 'yasm', 'ccache', # <-- from releng repo ^ /tmp/tmp.xmjtPcFsTz/mozilla/thunderbird_config.py:248:33: E261 at least two spaces before inline comment 'imake', # required for makedepend!?! ^ /tmp/tmp.xmjtPcFsTz/mozilla/thunderbird_config.py:249:89: E261 at least two spaces before inline comment 'gcc45_0moz3', 'gcc454_0moz1', 'gcc472_0moz1', 'yasm', 'ccache', # <-- from releng repo ^

If glandium doesn't need this anymore, and bug 609125 handles the one case were it might matter then lets fix that over there.