[tracking bug] run L10n repackages in production-1.9 based on the *paralell* repackages code

RESOLVED FIXED

Status

Release Engineering
General
RESOLVED FIXED
9 years ago
4 years ago

People

(Reporter: armenzg, Assigned: armenzg)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

9 years ago
I want to start the L10n repackages in production-1.9 in parallel BUT to push it to nightly/experimental/latest-mozilla-1.9.0-l10n instead of nightly/latest-mozilla-1.9.0-l10n

This requires:
- buildbotcustom/l10n to be commited
- update buildbotcustom and restart buildbot master to catch changes
- add variable uploadPathExperimental
- apply changes to master.cfg and reconfig

The previous will just start doing the repackages in production without any downtime
(Assignee)

Comment 1

9 years ago
I want to run this is in parallel with the official tinderbox l10n builds that we are already generating.

To do so and to don't interfere with it until we do the full switch:
- the buildbot setup will upload to nightly/experimental/
- the TboxMailNotifier will be commented out
(Assignee)

Comment 2

9 years ago
At 8AM EST, I have started working on making the l10n repackages to happen in production-1.9

These are the steps followed:
- stop master
- updated buildbotcustom
- updated master.cfg
- rebuild buildbot (tinderbox.py change)
- started master
- restarted slaves

The l10n packages will be uploaded to:
- http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/experimental/
The build results will be reported to:
MozillaRelease and MozillaTest

I have turned off the l10n repackages in staging-1.9 so we don't have conflict of reporting to the MozillaTest page at the same time

The first batch of locales generation should be triggered at 11AM EST
(Assignee)

Comment 3

9 years ago
The first batch at 11AM failed because the master.cfg was calling a target that does not exist "prepare-upload-%" when it is called "prepare-upload-latest-%"

The l10n repackages have been able to run and uploaded to:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/experimental/latest-mozilla1.9.0-l10n/

PROBLEMS:
- I belieave the mac has to be restarted since it is not be able to mount (check log at bottom of comment)
- In an erroneous run this folder was generated:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.9.0-l10n/latest/ (which I will delete)
and
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.9.0-l10n/firefox-3.0.3pre.de.linux-i686.tar.bz2
was overwritten

MAC'S LOG:
cd ../../dist/l10n-stage && \
  set -ex; function cleanup() { hdiutil detach ${DEV_NAME} || { sleep 5 && hdiutil detach ${DEV_NAME} -force; }; return $1 && $?; }; unset NEXT_ROOT; export PAGER=true; echo Y | hdiutil attach -readonly -mountroot /tmp -private -noautoopen /Users/cltbld/trunk-automation/macosx_l10n_nightly/mozilla/dist/firefox-3.0.3pre.en-US.mac.dmg > hdi.output; DEV_NAME=`perl -n -e 'if($_=~/(\/dev\/disk[^ ]*)/) {print $1."\n";exit;}'< hdi.output`; MOUNTPOINT=`perl -n -e 'split(/\/dev\/disk[^ ]*/,$_,2);if($_[1]=~/(\/.*)/) {print $1."\n";exit;}'< hdi.output` || cleanup 1; rsync -a "${MOUNTPOINT}/GranParadiso.app" firefox || cleanup 1; test -n "/Users/cltbld/trunk-automation/macosx_l10n_nightly/mozilla/dist/branding/dsstore" && { rsync -a "${MOUNTPOINT}/.DS_Store" "/Users/cltbld/trunk-automation/macosx_l10n_nightly/mozilla/dist/branding/dsstore" || cleanup 1; }; test -n "/Users/cltbld/trunk-automation/macosx_l10n_nightly/mozilla/dist/branding/background.png" && { rsync -a "${MOUNTPOINT}/.background/`basename "/Users/cltbld/trunk-automation/macosx_l10n_nightly/mozilla/dist/branding/background.png"`" "/Users/cltbld/trunk-automation/macosx_l10n_nightly/mozilla/dist/branding/background.png" || cleanup 1; }; test -n "/Users/cltbld/trunk-automation/macosx_l10n_nightly/mozilla/dist/branding/disk.icns" && { rsync -a "${MOUNTPOINT}/.VolumeIcon.icns" "/Users/cltbld/trunk-automation/macosx_l10n_nightly/mozilla/dist/branding/disk.icns" || cleanup 1; }; cleanup 0; if test -n "/Users/cltbld/trunk-automation/macosx_l10n_nightly/mozilla/dist/branding/license.r" ; then cp /Users/cltbld/trunk-automation/macosx_l10n_nightly/mozilla/dist/firefox-3.0.3pre.en-US.mac.dmg firefox.tmp.dmg && hdiutil unflatten firefox.tmp.dmg && { /Developer/Tools/DeRez -skip plst -skip blkx firefox.tmp.dmg > "/Users/cltbld/trunk-automation/macosx_l10n_nightly/mozilla/dist/branding/license.r" || { rm -f firefox.tmp.dmg && false; }; } && rm -f firefox.tmp.dmg; fi; 
+ unset NEXT_ROOT
+ export PAGER=true
+ PAGER=true
+ echo Y
+ hdiutil attach -readonly -mountroot /tmp -private -noautoopen /Users/cltbld/trunk-automation/macosx_l10n_nightly/mozilla/dist/firefox-3.0.3pre.en-US.mac.dmg
hdiutil: attach failed - Device not configured
make[2]: *** [repackage-zip] Error 1
make[1]: *** [repackage-zip-de] Error 2
make: *** [installers-de] Error 2
program finished with exit code 2
(Assignee)

Comment 4

9 years ago
Another run will happen at 2pm EST
No more touching until later in the evening
(Assignee)

Comment 5

9 years ago
Due to the release of FF3.0.3 we will have to postpone this to later this week
(Assignee)

Updated

9 years ago
Summary: [tracking bug] run L10n repackages in production-1.9 in *paralell* → [tracking bug] run L10n repackages in production-1.9 in *paralell* and push to nightly/experimental
(Assignee)

Updated

9 years ago
Blocks: 445254
(Assignee)

Updated

9 years ago
Depends on: 457340
(Assignee)

Updated

9 years ago
Depends on: 457747
(Assignee)

Comment 6

9 years ago
bm-xserve12 has successfully pushed to http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/**old-l10n**/latest-mozilla1.9.0-l10n/
(Assignee)

Comment 7

9 years ago
restarted production-1.9 master with l10n repackages enabled
there should be the 21PM and the 1AM repackages before I check it in the morning
(Assignee)

Comment 8

9 years ago
I did a rm -rf l10n mozilla in the fx-win32-1.9-slave2 and did a successful run of the "af" locale and push to the correct place

the linux-tbox and the win32-tbox has pushed as well to old-l10n and have stopped reporting to any "Mozilla-l10n*" page

There should be a run at 9AM PDT which should succeed for all 3 platforms

This bug could be close after that run
(Assignee)

Comment 9

9 years ago
release automation production-1.9 is completely running the l10n repackages correctly

the turning off of the tbox l10n machines should be followed in another bug sometime next week

resolving fixed
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Summary: [tracking bug] run L10n repackages in production-1.9 in *paralell* and push to nightly/experimental → [tracking bug] run L10n repackages in production-1.9 based on the *paralell* repackages code
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.