Closed Bug 631864 Opened 9 years ago Closed 8 years ago

Investigate why [or fix] mac repacks being uploaded to mac64/ rather than mac/


(SeaMonkey :: Release Engineering, defect)

Not set


(Not tracked)



(Reporter: Callek, Assigned: Callek)



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:

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
cb-sea-miniosx64-01:locales seabld$ make echo-variable-TARGET_CPU
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.
(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.
No longer blocks: SM2.1b2
blocking-seamonkey2.1: --- → b3+
Depends on: 629048
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.
blocking-seamonkey2.1: b3+ → final+
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
blocking-seamonkey2.1: final+ → ---
Ok, looks like this is fixed easier than I thought.

I just pushed the fix to buildbot-configs:

This will go into affect for 2.8b3 which *will* obsolete the need to run |sh| on stage.

I'll defer any more release-affecting changes for 2.8b4 though.
Closed: 8 years ago
Resolution: --- → FIXED
Summary: Investigate why [or fix] mac (trunk) repacks being uploaded to mac/ rather than mac64/ → Investigate why [or fix] mac repacks being uploaded to mac64/ rather than mac/
You need to log in before you can comment on or make changes to this bug.