In our SeaMonkey2.1beta2 run, (which is running on buildbot0.7-based automation) we have had the en-US mac build uploaded to |mac| like expected, however all the locales [repacks, xpis, and complete-updates] were uploaded to |mac64| This bug is to track why, and if there is any actual issue with it doing so.

Ok, investigation seems to indicate this should not be a problem [if I manually move the mac64 files inside stage/ftp] Read on for what I have found on "why": Firstly, buildbot itself is not the method that uploads the files (it does): make upload AB_CD=pl in dir /builds/slave/rel-comm-cen-trunk-osx64-rpk/build/comm-central/suite/locales (timeout 1200 secs) Which simply takes files already created... (done in the buildbot step before:) sh -c make installers-pl LOCALE_MERGEDIR=$PWD/merged in dir /builds/slave/rel-comm-cen-trunk-osx64-rpk/build/comm-central/suite/locales (timeout 1200 secs) Anyway, that (and upload) uses PKG_LANGPACK_PATH which is what sets where these files will go. Which itself uses MOZ_PKG_PLATFORM, which is of course, the platform we are building with/on. This is defined at: http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/mozapps/installer/package-name.mk?mark=60-70#58 Which at a glance looks right, since we do build universal binary... But this is a repack, which is configured, earlier in the buildbot process. I ssh'd into the machine that did the last repack here, and checked: cb-sea-miniosx64-01:comm-central seabld$ cd suite/locales cb-sea-miniosx64-01:locales seabld$ make echo-variable-MOZ_PKG_PLATFORM mac64 cb-sea-miniosx64-01:locales seabld$ make echo-variable-TARGET_CPU x86_64 cb-sea-miniosx64-01:locales seabld$ make echo-variable-UNIVERSAL_BINARY cb-sea-miniosx64-01:locales seabld$ which confirms my fear, that we are not properly UNIVERSAL_BINARY in the repacks. I'm not sure yet if there is an easy fix, or if we even should be [Firefox does repacks slightly differently now]. Because every other part of the repacks was correct, I feel confident (as I said above) that a manual move on ftp of these dirs to |mac/| will solve all the issues. I am doing that now.

see-also: https://bugzilla.mozilla.org/attachment.cgi?id=503814&action=diff

(In reply to comment #1) > which confirms my fear, that we are not properly UNIVERSAL_BINARY in the > repacks. AFAIK, we should not need to be UNIVERSAL_BINARY for repacks, as it *should* usually make no difference and being in UNIVERSAL_BINARY might set strange stuff lose like doing things twice where we don't need to as we're already using a finished universal package as a source. We might need to special-case some stuff as pointed out in the comment #2 reference though.

moved the files manually for current SM release; will be a beta3 blocker though, so I can get automation right here.

Pushing out to final+, I have bigger fish to fry at the moment; this releng bug I can manually fix on a release run, rather than needing the automation to do it.

This is easily fixed, even though its more human interaction than we should need for our automation of a release. Not planning on blocking on it anymore

Ok, looks like this is fixed easier than I thought. I just pushed the fix to buildbot-configs: http://hg.mozilla.org/build/buildbot-configs/rev/2c6903dc66ca This will go into affect for 2.8b3 which *will* obsolete the need to run |sh mac64tomac.sh| on stage. I'll defer any more release-affecting changes for 2.8b4 though.