Closed Bug 328564 Opened 19 years ago Closed 19 years ago

set up tinderboxens to repackage nightlies for 1.8 branch

Categories

(Webtools Graveyard :: Tinderbox, defect)

Product:
Webtools Graveyard
Component:
Tinderbox
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: Pike, Assigned: coop)

Details

It's a bit tricky to see what the current 1.8 tinderboxens are doing. There are current builds in http://stage.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-mozilla1.8-1.5rc2-l10n/ which are reportedly actually exactly that. There are no current builds in http://stage.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8-l10n/ We cannot do 2.0 l10n alphas of any kind without builds, or do any kind of QA of the new UI development without builds.
At the moment the tinderboxen do the following: Thunderbird 1.5rc2 / Firefox 1.5final en-US builds are repackaged with latest Mozilla_1.8_Branch l10n files. These builds end up in: http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-mozilla1.8-1.5rc2-l10n/ http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8-1.5-l10n/ Unzip one ot these builds an you can see latest l10n files and the OLD thunderbird.exe / firefox.exe
--> Tinderbox Configuration
Component: Build & Release → Tinderbox Configuration
QA Contact: preed → ccooper
Assignee: build → ccooper
(In reply to comment #1) > http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-mozilla1.8-1.5rc2-l10n/ > http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8-1.5-l10n/ Before I go and make the wrong set of changes, where are you expecting to find these files? */latest-mozilla1.8-l10n/ ? > Unzip one ot these builds an you can see latest l10n files and the OLD > thunderbird.exe / firefox.exe I'm looking at the logs for cerberus now, and it looks like it is wget-ing the most recent version build of mozilla1.8, provided that build is located here: http://stage.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8/ Should the link to download this package be pointing elsewhere?
Status: NEW → ASSIGNED
Affected machines: karma, boomer, cerberus I've verified that the Mozilla1.8 l10n tinderboxes are grabbing the latest Mozilla1.8 en-US builds from: http://stage.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8/ http://stage.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-mozilla1.8/ The resulting l10n builds will now sent here: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8-l10n/ http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-mozilla1.8-l10n/ I'll leave the bug open for a few tinderbox cycles in order to verify.
1) Still no Thunderbird OS X builds 2) Today Thunderbirds filenames changed to "thunderbird-2.0a1.en-US.......". Maybe the l10n tinderboxen have to be reconfigured again ;-)
Status update: 1) Still no OS X builds (1.8_Branch and Trunk) 2) Win32 build machine seems to be down (1.8_Branch and Trunk)
(In reply to comment #6) > 1) Still no OS X builds (1.8_Branch and Trunk) The $ssh_version was still set to 1 for all the builds on boomer, so none were being uploaded. This should be fixed now. > 2) Win32 build machine seems to be down (1.8_Branch and Trunk) Cerberus was pulling the wrong build on both branch and the trunk, and the branch tinderbox had a typo in the config file. Both problems should now be fixed.
Thunderbird: l10n builds for OS X, Linux and Win32 are okay now Firefox: l10n build machine for OS X seems to be down.
$mac_bundle_path was not set in tinder-config.pl, and the current tinderbox scripts fail silently in that case. Fixed now.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
l10n Tinderboxen are working as expected. Firefox and Thunderbird l10n trunk and 1.8_Branch nightlies are okay now.
Status: RESOLVED → VERIFIED
Last l10n tinderboxen for Linux and Win32 (both trunk and 1.8_branch) are down for some days!
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Linux l10n tinderboxen are working again, but Win32 is still down.
cerberus appears to be building again. Is there still an issue here?
Current issues: 1. cerberus-Firefox is pulling 1.6a1 builds instead of 3.0a1 to make trunk builds, and it uses 1.5 builds instead of 2.0a1 to make 1.8 branch builds. 2. karma-Firefox uses 1.6a1 instead of 3.0a1 to make trunk builds, and 1.5 instead of 2.0a1 to make 1.8 branch builds. 3. boomer-Firefox uses 1.6a1 instead of 3.0a1 to make trunk builds, and 1.5 instead of 2.0a1 to make 1.8 branch builds. 4. karma-Thunderbird uses 1.6a1 instead of 3.0a1 to make trunk builds. Is there no way to make the l10n tinderboxens pick up these version changes automagically?
to comment #14 - there isn't a way to make this automatic, yet. I'd like to see that, but that's a different issue. What we are doing is getting the tinderboxes into a known state, and the configs under version control, so these changes can at least be tracked and handled more quickly. Thank you for making the list of problems; we'll start correcting these tomorrow, and get the configs checked in so this is easier in the future.
Assignee: ccooper → rhelmer
Status: REOPENED → NEW
I've just made all the changes suggested in comment #14, this should be good for tonight's nightly builds.
All tinderboxes are now set up to use the correct versions, but I just noticed a difference in the type of builds used to make trunk builds of both Firefox and Thunderbird. On the 1.8 branch, all l10n builds are repackaged from builds in the <product>/nightly/latest-mozilla1.8/ directories. But on trunk, while cerberus(Windows) use builds from <product>/nightly/latest-trunk/, karma(Linux) and boomer(Mac) uses builds from <product>/tinderbox-builds/<tinderbox>-trunk/. The problem with that is that karma-Firefox take builds from http://stage.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/prometheus-trunk/ which are the non-Cairo builds, when Cairo is now default for Linux on trunk. A further complication is that there is no 3.0a1 tar ball in that directory, only an installer build.
The following builds are missing for a week now: - Mozilla_1.8_Branch l10n win32 Thunderbird - Trunk l10n win32 Firefox And there are no universal binaries for OS X.
<frustrated on> And another 2 weeks without win32 l10n Firefox/Thunderbird builds. Firefox 2.0b1 should be an l10n-alpha - how should we test the localized NSIS installer and the whole l10n without builds? Maybe someone could answer to all my comments in the last weeks? </frustrated on>
Don't worry too much about the NSIS installer just yet, that file is supposed to change formats again. I mailed build yesterday, too, we really need to get these builds going.
Severity: major → critical
Mac builds are also broken, the build log says: + hdiutil detach /dev/disk1 "disk1" unmounted. "disk1" ejected. + return 1 make[2]: *** [repackage-zip] Error 1 make[1]: *** [repackage-zip-pl] Error 2 make: *** [installers-pl] Error 2 So we only get Linux 1.8 builds...
Assignee: rhelmer → ccooper
(In reply to comment #22) > + hdiutil detach /dev/disk1 > "disk1" unmounted. > "disk1" ejected. > + return 1 > make[2]: *** [repackage-zip] Error 1 > make[1]: *** [repackage-zip-pl] Error 2 > make: *** [installers-pl] Error 2 The real error is actually just above that: + rsync -a /tmp/BonEcho/Firefox.app firefox link_stat "/tmp/BonEcho/Firefox.app" failed: No such file or directory rsync error: some files could not be transferred (code 23) at /SourceCache/rsync/rsync-14/rsync/main.c(633) Bitten again by the AppName issue on Mac; the real AppName is BonEcho.app. Working on this now.
Status: NEW → ASSIGNED
(In reply to comment #23) > Bitten again by the AppName issue on Mac; the real AppName is BonEcho.app. Disabling official branding in the mozconfig file on the Mac has fixed this.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → FIXED
Component: Tinderbox Configuration → Tinderbox
Product: mozilla.org → Webtools
Product: Webtools → Webtools Graveyard
You need to log in before you can comment on or make changes to this bug.