http://tinderbox.mozilla.org/showlog.cgi?log=Mozilla-l10n-af/1361470833.1361471087.18997.gz&fulltext=1 IOError: [Errno 2] No such file or directory: u'e:\\builds\\moz2_slave\\m-aurora-w32-l10n-ntly-0000000\\build\\mozilla-aurora\\dist\\branding\\branding.nsi' This is because the new rules in branding copy branding.nsi during the libs:: rules, but browser/installer/windows/Makefile.in expects it in dist/branding during export::. Adding BRANDING_TARGET = export to the branding Makefiles should fix it.
I can check this once it's fixed.
QA Contact: anthony.s.hughes
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #1) > I can check this once it's fixed. Note that once builds appear on FTP our automation will run automatically, so I can check to make sure the automation succeeds and then spotcheck a few updates. Please let me know if there are locales that are a priority because we won't be able to reasonably check *all* locales. Two or three locales seems reasonable.
ashuges: Italien, French, Russian are good candidates once we have builds. Hover over the left-most column in https://l10n.mozilla.org/dashboard/tree-status/fx_aurora?starttime=2013-2-20 will give you good locales. (french is red, but only for having killed metro already)
Created attachment 717401 [details] [diff] [review] [aurora] v1 For the reasons in c#0 I believe this is the correct patch. Written against aurora, but I expect it to apply clean to central. Accepting whomever gets to it first. Approval-request-in-advance of review, for "no windows l10n on aurora"
Attachment #717401 - Flags: review?(khuey) → review+
(In reply to Justin Wood (:Callek) from comment #5) > https://hg.mozilla.org/releases/mozilla-aurora/rev/22923addc512 When can I expect to see builds? I thought they'd be available by now.
The ones I triggered last night failed, due to cset being 'nightly' from the trigger :( And the auto-scheduled ones were from the cset before my push :( I triggered new nightlies as soon as I got up today, on the correct CSET at about 7:30am ET, so I'd expect in the next hour or two to see the l10n rolling in
(In reply to Justin Wood (:Callek) from comment #7) > The ones I triggered last night failed, due to cset being 'nightly' from the > trigger :( > > And the auto-scheduled ones were from the cset before my push :( > > I triggered new nightlies as soon as I got up today, on the correct CSET at > about 7:30am ET, so I'd expect in the next hour or two to see the l10n > rolling in Callek any update if the builds rolled out as expected ? I had checked ~10am PT and did not find them on ftp
(In reply to bhavana bajaj [:bajaj] from comment #8) > Callek any update if the builds rolled out as expected ? I had checked > ~10am PT and did not find them on ftp We have a small pool of win32 machines that do these builds at the moment so my ETA was a bit overeager. We're more than 3/4's of the way through the list of windows l10n repacks now though, spot checks show green builds. Will just need QA to checkin soon to verify from their end.
(In reply to Justin Wood (:Callek) from comment #10) > https://hg.mozilla.org/integration/mozilla-inbound/rev/bb9e9d8b1d2f Thanks Justin. I've confirmed the win32 l10n builds are now working based on the following criteria: * functional automation testing against the fr builds * update automation testing against the fr builds * manual functional and update spotchecks against de, it, and ja-JP builds * all download links verified on http://www.mozilla.org/en-US/firefox/all-aurora.html Marking this bug resolved fixed based on these results. I've also added a QA sign-off checklist item so we catch l10n issues like this earlier in the future.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Callek, , ashughes : thanks a lot for getting this resolved over weekend :)
I think it's safe to call this verified fixed at this point.
Status: RESOLVED → VERIFIED
status-firefox21: fixed → verified
You need to log in before you can comment on or make changes to this bug.